No really. Watch here.

Now they just need to finish up Jarvis from the Iron Man movie and we’re all set for RL to become obsolete.

Related posts:

1. Computer Security At Hotels
2. Real Cost of Apple iPad vs Amazon Kindle 2
3. User Interfaces In Film, and the Man Who Designs Them

• So you say ‘hackers’ are constantly knocking on the perimeter door to your network.

• You claim that they are trying to ‘map’ your network.

• You insist that they will cherry pick targets based on fingerprint data, wins/dns name, or other factors.

Proposition:

• Fill up a virtual machine host with hundreds to thousands of fake hosts that each have random fingerprint appearance and different name. They don’t need to do anything except listen on a few ports (on a set of believable ports, to mimic a real OS), and maybe send a fake packet or two around (you know, like M$ boxes like to do because they get lonely.) A full blown app like vmware is overkill for this purpose. A perl script on five tiny embedded systems would suffice.

Just think of the possibilities.

1. Each would dilute any reconnaissance tool with bogus hosts
2. Each is indistinguishable from real hosts without attempting to check the function of each service for each address.
3. Each could also be setup to send alerts to your InfoSec dept when anyone attempts to connect to them; (only two categories of connectors: 1) misconfigured friendlies, and 2) bad guys.)
4. Every second the scanner spends poking around in these fake hosts, your real ones aren’t touched.
5. You can brag about how many ‘hosts’ are on the network you manage.
6. If ‘fancy’ is your middle name, you could write a script that would forward connection attempts to a honeypot and attempt to grab a fresh piece of badware.

Thoughts?

P.S. I admit I partly stole this idea from Tom Liston’s LaBrea tarpit.

Related posts:

1. Network Scanning with nmap
2. Writing a DNS sniffer
3. Computer Security At Hotels

I drive a pretty sizable distance every day to commute to work. I drive on a freeway most of the distance.

Freeways were poorly named. Congested freeways are anything but free of cars. They house traffic ‘trends’ such as ‘packs’ or ‘squadrons’ as well as ‘stop and go’ sections or often just convenient ‘parking lot’ areas while you attempt to get home before dark.
In an attempt to optimize this sad state of affairs affecting those of us in urban life, I have come up with the solution (which as I’m sure you’ve guessed by now since you read the title) is that all freeways should be replaced with conveyor belts.

Now, I don’t mean the rubber & pulley wheel variety, I have in mind something more like the catapult system found on the flight decks of American super carriers. It seems so simple it just may work!

Each car would hook up to one of these at speed and “lock in” to a spot on the freeway ‘belt.’ That way, the belt is always moving at a constant speed, no one is able to weave in and out of lanes, it’s impossible to have a fender bender, people can’t use the margins on the side of the road as ‘temp passing lanes,’ maximum fuel efficiency for all cars is enforced and no one can speed!

It’s a perfect solution! I just solved the top 5 highway issues with one ginormously expensive and implausible invention that everyone would hate.

I dare you to poke holes in my logic…

Related posts:

1. Writing a DNS sniffer
2. alltop
3. Detecting bad TCP sessions

First up is determining where all the interesting bits in each layer of the OSI stack are located within each packet. In logical order:

• Ethernet Headers & Packet Structure

• IP Headers & Packet Structure

• UDP Headers & Packet Structure

• DNS Records and DNS Headers (about half way down)

With all that reference material, you might think this is a lot of reading! Okay, fine how about a copy and paste job? Tcpdump is the perfect place to exercise your mouse wheel click skillz to get all the data structures and defines you’ll need.

One last useful tool that should be in every network programmers tool belt is of course, Wiershark (aka ethereal). In this case, it comes in handy to double check your program is disassembling the packets the same as Wireshark.

A BPF is used to speed up the filtering of interesting packets from useless ones and is passed in to the program as follows:

dns_sniffer “udp port 53″

When writing any network aware application, the best place to start for documentation is always going to be the applicable RFC for whatever protocol you plan to speak.

When figuring out what bitmasks were needed to mask out specific bits (namely the first two bits for parsing DNS compression) Conversion Table came in handy. I also found this handy page if you need to brush up on bitwise operations (I sure did, since I hardly use them.) And don’t forget your ASCII-Table!

Have you ever wondered how your lonely little-endian wintel laptop / desktop is able to communicate over the same IP network to a big-endian speaking SPARC system? It certainly kept me up at night! See for yourself how it is able to work.

More to follow… (you know, like source code)

Related posts:

1. Thousands of Sacrificial Lambs
2. Network Scanning with nmap
3. Detecting bad TCP sessions

Why not develop a feature into personal firewalls that tracks active tcp sessions (via netstat) but with some intelligence. The idea behind intelligence is to not spam the poor user every single time an application wants to talk on the NIC. How would that work?

Well, it could associate keystrokes / clicks with network events. If there is a new tcp session established or new listening local port, challenge the user with the application name associated with said session or listening port.

It sounds so simple it just might work. Do you see any false-positive scenarios?

Related posts:

1. Writing a DNS sniffer
2. Network Scanning with nmap
3. Thousands of Sacrificial Lambs

Related posts:

1. User Interfaces In Film, and the Man Who Designs Them