Thursday, January 05, 2006
Stupid PC tricks
I had so much fun with the MegaRAC® K1 that I
hooked the device up to my workstation at The Office (and you can hook a
keyboard, video and mouse up to it, and still remote desktop into
the system), then from my system used rdesktop
to get to the Windows
box, from which I remote desktopped (um … yeah) back into my
workstation.
The effect was much like pointing a video camera to a TV displaying what the video camera sees.
Just because I can.
Slogging through the 'pit
Today was the first day I ran the Labrea tarpit on the network. I almost didn't leave the office since the results were most interesting. The first hour it ran (from 19:04:31 Eastern to 20:04:31) it “pitted” 9,309 connections from 865 unique IPs. And the ports involved:
Port # | Port description | # connections |
---|---|---|
135 | Microsoft-RPC service | 4,996 |
445 | Microsoft-DS Service | 3,724 |
139 | NetBIOS Session Service | 295 |
22 | Secure Shell Login | 231 |
80 | Hypertext Transport Protocol | 62 |
6348 | unassigned (possible worm?) | 1 |
That Microsoft specific ports are at the top of the list are totally unexpected here.
I did learn a few things about LaBrea though. One, it only works on a single netblock. Unfortunately for us at The Company, we have several network blocks to worry about and that means either a few machines running this, or several instances (and given that LaBrea puts the network interface in promiscuous mode, I'm not sure how multiple instances would react with each other on the same interface) on different interfaces on one box.
Two, the network block does not have to match the network block the actual system is in, which saves an unsused IP address (ha ha).
A puzzling thing though. I got home, it was still running. I checked back a few hours later, and nothing past 20:21:17. LaBrea was still running, but either we captured all that could be captured, or something else was up.
Or down, as it turned out.
The interface that LaBrea was running on just died. I don't know if the switch doesn't like it (unlikely), the network cable is bad (could be—I did make the cable) or the interface just blew up (also a possibility). Even a reboot of the system didn't fix the problem. I'm hoping it's just the cable.
Packets from Mars
Another thing I'm seeing with the LaBrea Tarpit software—wierd ARP packets.
I've got the logging set to “verbose” (in case any problems come up) and one result is that it logs all the ARP requests that it sees, but can't answer (can't answer them because they're outside the normal netblock LaBrea is “answering” for). So I see a bunch for other public IP addresses we have. And the various private IP addresses that I'm not exactly sure what they're being used for, but hey, they're private.
And then … there are the ARP requests that shouldn't exist:
Jan 6 00:55:40 ltp : IP address not in netblock - ARP WHO-HAS 64.76.67.1 TELL 64.76.67.64 Jan 6 00:55:42 ltp : IP address not in netblock - ARP WHO-HAS 64.76.67.1 TELL 64.76.67.248 Jan 6 00:55:43 ltp : IP address not in netblock - ARP WHO-HAS 64.76.67.254 TELL 64.76.67.236 Jan 6 00:55:43 ltp : IP address not in netblock - ARP WHO-HAS 64.76.67.1 TELL 64.76.67.248 Jan 6 00:55:44 ltp : IP address not in netblock - ARP WHO-HAS 64.76.67.1 TELL 66.252.226.46 Jan 6 00:55:44 ltp : IP address not in netblock - ARP WHO-HAS 64.76.67.254 TELL 64.76.67.236 Jan 6 00:55:44 ltp : IP address not in netblock - ARP WHO-HAS 64.76.67.1 TELL 64.76.67.248 Jan 6 00:55:45 ltp : IP address not in netblock - ARP WHO-HAS 64.76.67.254 TELL 64.76.67.236 Jan 6 00:55:47 ltp : IP address not in netblock - ARP WHO-HAS 64.76.67.1 TELL 64.76.67.248
I have no clue where these are coming from.
None, and I mean none of our addresses are from the
64.0.0.0/8
block. That doesn't appear to be any of our
upstream providers. I can traceroute to 64.76.67.248
but why I'm seeing ARP requests from it is beyond me. Especially since
ARP requests
can't be routed! It's something local sending it out, or it's
LaBrea misinterpreting the ARP packet (since it can be used for more than just
IP→MAC address translations).
One thing for sure, I'll have to check the code, and possibly modify LaBrea to log the MAC address so I can track this down. Then again, I have to hit the code anyway, since technically, the MAC address LaBrea uses is wrong (the “global/local” bit in the address is not set, and it should be).