> Do you have any idea how much in the way of CPU time and memory > would be required to implement tarpitting as part of LPR? > I don't want to tarpitting to consume alll the resources of my firewall.
Check out the whitepaper at the LaBrea webpage for some details. In general, tarpitting, or even completely capturing connections will not take much in the way of router resources. Fundamentally, there are three resource catagories of main concern: inbound bandwidth, outbound bandwidth, and resource usage (CPU & memory) on the tarpit machine. You can't do much about the inbound bandwidth problem short of setting up a sophisticated relationship with your ISP, so if the packets get to you, they've already consumed your inbound bandwidth. Outbound bandwidth, however, is something you can control, and tarpitting or capturing connections DOES cost outbound bandwidth. To me, however, it's a good trade-off. If you don't do anything (ie drop packets for non-existant IPs), the port-scanners can steal your inbound bandwidth without cost. If you send a few scraps of data their way, however, by tarpitting or capturing their TCP connection, you have made them pay for sending unsolicited packets over your internet link. In terms of CPU and Memory usage, the LaBrea executable is pretty tiny (apx 75 K IIRC), so it should fit pretty easily on most LRP systems. CPU usage should be pretty minimal, as well. Remember, a 486 system can route the equivelent of a T3 before it starts running out of gas, and the tarpitting code isn't really doing much work. There's no connection tracking going on, and even the random number pool used for TCP responses is pre-calculated and cycled through. Of course, if you're concerned about resource usage on your router, you can always create another LRP system and run LaBrea on it. There are also RPM's available at the LaBrea web page, if you've got a more powerful server-type machine you'd prefer running it on. LaBrea overview...why it uses outbound bandwidth: TCP connections are initiated by a 3 way handshake, or conversation: client --> server : Are you there? client <-- server : Yes client --> server : OK (and starts sending data) If you simply drop the inbound start of connection packets, a port-scanner simply has to wait for the TCP start of connection timeout before moving on. Typically, start of connection timeouts are one of the shortest timeouts in the TCP stack, since until a connection is established, there's no way to be sure there's even a machine on the far end. If, however, you send the initial response packet (this was the initial "tarpitting" in LaBrea), instead of waiting about a minute for a timeout, the remote system thinks the connection is established. It knows there's another computer at the far end, and it knows it can talk to it. At this point, it will try to send some data (like a web request, probing for IIS vunerabilities). It won't ever recieve a response to it's data packets, but the remote system will take orders of magnitude longer trying to get the request through than if the machine had simply not responded at all. The latest mode of connection trapping literally holds the scanners machine forever, typically locking up the particular scanning thread until it is reset somehow. This is done by replying to the scanners data packets (ie the actual web request), but never increasing the sequence number. This is basically saying to the remote computer: "I'm here, but I'm busy and haven't processed that data you sent me...don't send any more". While you are incurring more packet traffic to capture connections, the data size is quite small (LaBrea typically sets the TCP window size to 5 bytes, so the packets aren't much bigger than a minimum sized IP packet). Essentailly, capturing an entire TCP connection just takes enough bandwidth to periodically answer the 'keepalive' packets from the far end, which will periodically ask: "are you ready for more data?". The LaBrea documentation states that 8 bytes per second of bandwidth can capture 3 code-red threads (holding one inbound connection from an NT machine takes 1215 bytes an hour). Put another way, this is one typical ping packet every five minutes...not a lot of bandwidth. You can also set the maximum bandwidth LaBrea will use to tie up connections...see the docs. Charles Steinkuehler [EMAIL PROTECTED] _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
