LaBrea is a program that creates a tarpit or, as some have called it, a "sticky honeypot". LaBrea takes over unused IP addresses on a network and creates "virtual machines" that answer to connection attempts. LaBrea answers those connection attempts in a way that causes the machine at the other end to get "stuck", sometimes for a very long time.
LaBrea works by watching ARP requests and replies. When the pgm sees consecutive ARP requests spaced several seconds apart, without any intervening ARP reply, it assumes that the IP in question is unoccupied. It then "creates" an ARP reply with a bogus MAC address, and fires it back to the requester.
An example (from a tcpdump of LaBrea running on my network):
There is no xx.xx.xx.13 machine on my network. In this case, the timeout was set to 3 seconds (it's a command line parameter), and when that final "who-has" came in, the "is-at" reply that you see was generated by LaBrea.
There isn't a MAC address of 0:0:f:ff:ff:ff either. It doesn't exist.
But now, the router (xx.xx.xx.1) believes that there some machine at xx.xx.xx.13, and that it resides on the MAC address 0:0:f:ff:ff:ff, and so it dutifully sends packets on. In essence, we've created a "virtual machine" on that IP address.
Now, LaBrea also watches for TCP traffic destined for the ether address 0:0:f:ff:ff:ff. When it sees an inbound TCP SYN packet, it replies with a SYN/ACK that "tarpits" that connection attempt. Everything else is ignored. (Well... sort of. LaBrea also tries to give its "virtual machines" some character... you can ping them, and they respond to a SYN/ACK with a RST...)
There's more to it than that (obviously...) but you'll need to read further.
The original concept for LaBrea started in response to the CodeRed worm. Our IP block was being scanned non-stop. I began to wonder: "Is there anything that can be done to stop this worm?" Of course, many things came to mind, but most of them were illegal. Then, late one night, I thought, "Maybe I can't stop these machines from scanning, but I bet I can slow them down..."
The following morning I posted to the INTRUSIONS list at incidents.org:
I'm pretty sure that most of you are using your allotted ip address space somewhat like I am. At any given time I'm using only about 20-30% of the ip addresses that I have available. What if I could put something on those other 80% of my ip addresses that would give "Code Red" something to play with that would slow it down to a crawl? A sort of "DoS" back at the worm.
Since those "extra" ip addresses aren't actually expecting any inbound traffic, anything fired at them can safely be assumed to be "bad" traffic. If I wrote a little piece of software that sat on those ip's and listened on port 80, anything that it heard could safely be "played" with.
My hypothetical program should be pretty simple: you see an inbound packet at port 80 with SYN set, and you craft up a return packet with SYN/ACK set and perhaps an option to set the MSS to something small... say about 60 bytes. What does that do? Well, as far as the attacking worm is concerned, after replying with an ACK, it has completed a three-way handshake... it's connected. It's also been told to send information back to you in small chunks (to keep traffic to a minimum), which it dutifully does. The only problem is, my program just answers SYN packets and ignores everything else. So now the worm has to sit around while the whole TCP connection times out. I'm not sure what the timeout NT is, but I think most stacks are pretty persistent about "good" connections, so it should hang it up for a good long time.
A few days later, Mihnea Stoenescu sent a message back to the list:
Tom's concept works - I have a living proof.
For a few hours I've been teergrubing CodeReds via three-way handshake on behalf of an entire C-block, by using only one host. At a rate of 6 hosts per minute hitting my block, I'm consuming circa 15 minutes of effective attack time every minute. A lot of hosts can be scanned in 15 minutes.
Mihnea used a modified version of a program called Couic. But Couic was written to do a lot more, so I went though, hacked it apart, and put it back together to make "CodeRedneck."
CodeRedneck did essentially what I described in my post, but it only worked on "real" connections that had some kind of firewalling that kept the underlying machines from responding. It did nothing for all of those "unused IPs".
After CodeRedneck was done, I began trying to figure out how to deal with those unused IPs. Somehow I had to "create" machines, and my first thought was to use IP aliasing under Linux. Using the Trinux distribution I was able to put together a boot disk that, using a list of unused IPs, "created" new machines, then firewalled and "tarpitted" them. I called the new version "LaBrea".
The day after I released LaBrea, someone asked if it would be able to handle a /24 network (65,535 hosts). Well, I didn't think my little program would handle it, and, well... it didn't. And so... I tried again.
That's how LaBrea came into being...
If you're a network administrator, I don't REALLY need to explain this. They're out there, every day... 24/7/365. The scanners. They're out there and you get to sit and watch them beat on your network, doing reconnissance. Now you have a chance to make their life more difficult.
Besides that... it's fun.
And, as Mihnea so wonderfully put it, you can come into work in the morning, look at your logfiles and say "Wow - I'm *actually* saving the world"
OK, maybe "saving the world" is a little much...
There's a mailing list here at the LaBrea SourceForge site for users to ask questions among other things.
To report bugs: Use the LaBrea Problem Tracker or email
lorgor <lorgor@users.sourceforge.net>Comments, hate mail, and praise can be directed to (who else?)
Tom Liston <tliston@hackbusters.net>