Some updates on a tarpit

* * * * *

Some updates on a tarpit

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
[2] gopher://gopher.conman.org/0Phlog:2006/01/06.1
[3] gopher://gopher.conman.org/IPhlog:2006/01/07/graph_image.png
[4] http://www.lurhq.com/dipnet.html
[5] http://www.famatech.com/
[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

Email author at [email protected]