Holy buttons Batman! That sounds awesome, especially for an ISP to run on it's unused IPs. So Bob, what does this look like to your ISPish eyes? I know I'd pay extra to be at the other end of an ISP with that sort of defense around my IPs. Or ... jeepers. This might be cool for ipf to do too. Tarpit the people doing scans. Right now I have my firewall report all blocked ports as closed so a open but not used port looks identical to the other 0xFF02 ports that aren't even open. I suppose that would confuse the heck out of someone trying to scan the machine. Joshua Jore Minneapolis Ward 3, precinct 10 "The irony of this man being imprisoned in the United States and longing to return to once-Communist Russia so he can regain his right to free speech is simply staggering." - Paul Cantrell, St Paul area software developer On Mon, 17 Sep 2001, Austad, Jay wrote: > For those of you not on the security announcement list from securityfocus, > here's a nice little program which looks pretty sweet. I haven't tried it > yet though. If you go to their site, you can view hosts that have been > "tarpitted" and for how long. > ======================= > > First we slooooowed 'em down... > > ...Now, we're gonna' STOP 'em. > > Announcing: LaBrea 2.0 > > It all started a few weeks ago when we read this innocent little paragraph > in Chapter 22 of Steven's TCP/IP Illustrated, Vol. 1: > > "The characteristic of the persist state that is different from the > retransmission timeout in Chapter 21 is that TCP never gives up sending > window probes. These window probes continue to be sent at 60-second > intervals until the window opens up or either of the applications using the > connection is terminated." > > What a lovely word "NEVER" is.... > > As you may or may not know, LaBrea 1.x is a small Linux-based application > that puts unused IP addresses on your network to use, creating a "tarpit" > which slows down scans of your address space by establishing connections and > forcing inbound connections to time-out. LaBrea automates the process of > "grabbing" unused IP addresses and adding them to its pool of "tarpit" > addresses. > > But now, thanks to the word NEVER, we can take "active defense" to a whole > new level. > > LaBrea is beginning to generate interest in those who know that an active > stance against REAL attackers is necessary to the continued health of the > Internet: > > "LaBrea gives its users a tactical advantage over 'zombie' computers like > those compromised by the Code Red worms. The computer security industry > will find it a very intriguing utility." > -- Rob Rosenberger, editor, Vmyths.com > > **New in LaBrea 2.0** > > When LaBrea is started with the "-p" flag, it will force connection attempts > into the "persist" state. You grab 'em, hold 'em, and NEVER let 'em go. > > Yes, that's right... I said "*NEVER* LET THEM GO"... > > How does it work? Technical details: The LaBrea "server" software allows a > normal three-way handshake in response to a connect attempt. During the > handshake, the server sets a small (5 byte) TCP window. When the client > sends its first 5 bytes of data, the server responds with a TCP window of 0 > (wait). The client then shifts into the "persist" state, where it sends what > are called "window probe" packets at intervals that increase to a maximum of > 4 minutes for an NT stack. The LaBrea server answers these probes to hold > the client in the persist state. At this point, a connection can be > maintained with a throughput of approximately 1215 bytes per hour. All of > this can be done without maintaining any "state" on the connections. This > vastly simplifies LaBrea's code. > > Because you're holding connections open, and because there is a bandwidth > "cost" associated with doing that, the "-p" option requires that you specify > the maximum bandwidth (in bytes/second) that you want to allocate to doing > this. You set the maximum bandwidth, fire it off, and LaBrea takes care of > the rest. It keeps a 5 minute running window of bandwidth allocated to > holding open connections, and does it's best to keep you at or near the > maximum you allow. > (FYI: 1 byte/second is roughly equal to 3 scanning threads). > > What happens to the threads you don't grab? LaBrea still tarpit's 'em... > just like before. > > Using LaBrea before was a whole lot of fun... Now, it's just incredible. > I've had people ping scanning "virtual machines", running NMap on them, and > even some enterprising folks very interested in the version of BIND that my > LaBrea machines are running. Ladies and gentlemen, we really CAN make a > difference. > > But don't just take my word for it: check it out for yourself. At the > HackBusters site, we have a page showing the current "live" activity in our > very own tarpit. You can see the folks that are just visiting, and you can > also check out a list of the very "special" people that we're hanging onto > INDEFINITELY. While you're there, grab a copy of the source code to LaBrea, > or read our white paper entitled "Welcome to My Tarpit - The Tactical and > Strategic Use of LaBrea." > > While you're looking at the "VIPs" as we're calling them, notice something: > I've held onto some of them for more than 5 days... No, you didn't mis-read > that: *5 DAYS*... And don't be fooled by the fact that everything there > seems to be aimed at port 80. Hackbusters lil' chunk o' IP space just seems > to be sitting in the midst of CodeRed central... LaBrea will capture > anything that tries to initiate a full connection on ANY port. Over the > weekend, we had some Gnutella scanners on the line until they got a clue and > gave up... > > We believe that by using tools like LaBrea, we can actually make a strong > proactive stand to improve the "health" of the Internet. Please consider > setting up a tarpit. Please pass the word to others. > > See: http://www.hackbusters.net > > Questions and comments can be directed to the address on the HackBusters > site. > _______________________________________________ > tclug-list mailing list > tclug-list at mn-linux.org > https://mailman.mn-linux.org/mailman/listinfo/tclug-list >