I played with LaBrea [1] a lot yesterday [2] 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 (Kilobits per second) 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] [3]
Another annoying aspect to LaBrea—it's not easy to change the MAC (Media Access Control) 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 (Address Resolution Protocol) 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 (Internet Protocol) 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:
Table: Ports captured during a Labrea run of twelve hours 00:00:00 to 11:59:59 on Jan 7, 2006 Port # Port description # connections ------------------------------ 139 NetBIOS (Basic Input/Output System) Session Service 7127 1433 Microsoft SQL (Standard Query Language) Server 4605 80 Hypertext Transfer Protocol 4425 445 Microsoft-DS (Directory Service?) Service 4361 135 Microsoft-RPC (Remote Procedure Call) service 1290 3306 MySQL Server 1157 443 Hypertext Transfer Protocol over SSL (Secure Socket Layer) 978 3840 unknown 915 22 Secure Shell Login 892 3380 unknown 455 8080 Hypertext Transfer Protocol—typical alternative port 403 15118 Dipnet/Oddbob Worm [4] 361 4899 Remote Administration [5] 249 1080 W32.Mydoom.F@mm worm [6] 79 25 Simple Mail Transfer Protocol 64 21 File Transfer Protocol command port 24 57 Mail Transfer Protocol [7] (obsolete) 18 6885 Bittorrent [8] 6 6129 Dameware remote administration software [9] 5 34153 client-port on Red Hat Linux 9.0, Fedora Core 1, Red Hat Enterprise 3 [10] 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 ------------------------------ Port # Port description # connections
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 (Megabytes) per day of logging information.
[1] http://sourceforge.net/projects/labrea
[3] /boston/2006/01/07/graph_image.png
[4] http://www.lurhq.com/dipnet.html
[6] http://securityresponse.symantec.com/avcenter/venc/data/w32.mydoom.f@mm.html
[7] http://rfc.net/rfc780.html
[8] http://www.bittorrent.com/
[9] http://www.linklogger.com/TCP6129.htm
[10] http://www.seifried.org/security/ports/34000/34153.html
![[3] /boston/2006/01/07/graph_image.png](/gemini.conman.org/boston/2006/01/07/graph_image.png){kind=link}