Saturday, January 07, 2006
Some updates on a tarpit
I played with LaBrea a lot yesterday and today. One of the things I found was that I may have not been actually “tarpitting” any connections on Thursday and early Friday. I had set the maximum bandwidth that LaBrea could use to 4 Kbps and that may have been too low to do any good. I upped the bandwidth to 32 Kbps and that's when I started seeing “Persist Activity” records in the log file. It looks like the bandwidth capped out, so since then I've upped the allowable bandwidth to 64 Kbps.
![[NETWORK TARPIT bandwidth usage]](/2006/01/07/graph_image.png "NETWORK TARPIT bandwidth usage")
Another annoying aspect to LaBrea—it's not easy to change the MAC address it uses for tarpitting. As I mentioned, the MAC address it uses is technically incorrect, as it uses a “Global” address, not a “locally assigned” address. It also makes it difficult to run more than one instance of LaBrea on a network (and we may need to do so on our network until I can get all the traffic segmented properly).
I came up with an address to use, DE:CA:FB:AD:00:01 (yes,
that spells “decaf bad”) which is distinctive enough to see in ARP tables. I found the line
of code to change in labrea.h:100
#define ETH_ADDR_BOGUS "\x00\x00\x0f\xff\xff\xff"
/* Bogus MAC addr used in IP capture */
Simple enough to change. But doing so made LaBrea unable to actually
tarpit any connections. Changing the MAC address back to 00:00:0F:FF:FF:FF and it
would work. Which means that LaBrea has hardcoded elsewhere in the
code.
Found it too, in labrea_init.c:248
static char bpf[] = "arp or (ip and ether dst host 00:00:0F:FF:FF:FF)";
Believe me, if there was an option to select the MAC address to use for tarpitting, I would have used it. So I suppose I can now add such a feature, now that I know where to look for it.
So, now that I'm properly tarpitting connections, I've pulled stats from another twelve hour run, which should be more accurate than my last chart. With the additional information, I've been able to calculate the time each connection is “held” and again, it's interesting. This time, the twelve hours resulted in a tarpitting of 27,427 connections across 1,418 unique IPs with an average “hold time” of 48 minutes, 21 seconds (although there were 302 connections held for over 11 hours, presumedly they still are). Again, the ports being scanned hold nothing surprising, with this time 63% of the scans for Microsoft specific ports:
| Port # | Port description | # connections |
|---|---|---|
| Port # | Port description | # connections |
| 139 | NetBIOS Session Service | 7127 |
| 1433 | Microsoft SQL Server | 4605 |
| 80 | Hypertext Transfer Protocol | 4425 |
| 445 | Microsoft-DS Service | 4361 |
| 135 | Microsoft-RPC service | 1290 |
| 3306 | MySQL Server | 1157 |
| 443 | Hypertext Transfer Protocol over SSL | 978 |
| 3840 | unknown | 915 |
| 22 | Secure Shell Login | 892 |
| 3380 | unknown | 455 |
| 8080 | Hypertext Transfer Protocol—typical alternative port | 403 |
| 15118 | Dipnet/Oddbob Worm | 361 |
| 4899 | Remote Administration | 249 |
| 1080 | W32.Mydoom.F@mm worm | 79 |
| 25 | Simple Mail Transfer Protocol | 64 |
| 21 | File Transfer Protocol command port | 24 |
| 57 | Mail Transfer Protocol (obsolete) | 18 |
| 6885 | Bittorrent | 6 |
| 6129 | Dameware remote administration software | 5 |
| 34153 | client-port on Red Hat Linux 9.0, Fedora Core 1, Red Hat Enterprise 3 | 4 |
| 1025 | Microsoft-RPC service (what? Another one?) | 3 |
| 18448 | unknown | 2 |
| 524 | Novell Core Protocol request | 1 |
| 20298 | unknown | 1 |
| 2008 | Microsoft terminaldb configuration | 1 |
| 18000 | unknown | 1 |
I may need to write a program to process the logging in real time, since LaBrea is quite versbose, as it looks like it'll generate about 150M per day of logging information.
