Is there anyway Labrea could be used if you are a simple cable user with one IP adres? Like by listening on some ports? Is this doable now or would it require a change to the sourcecode?
Kim Oppalfens On Thu, 20 Sep 2001 14:42:52 -0500, Alec Miller wrote: >Someone sent me this link in the midst of the recent Nimda attacks. > >I don't have the tools to make this into an LRP package, but I >think this >could be a neat addon. > >(If it doesn't already exist for LRP) > > >Alec > > >===================================================== > >http://www.incidents.org/LaBrea/LaBrea.txt > > > > >--------------------------------------------------------------------- >------- >---- > > > Welcome to My Tarpit > The Tactical and Strategic Use of LaBrea > > >Introduction >------------ > >LaBrea is a small Linux-based application that puts unused >IP >addresses on your network to use, creating a "tarpit" which can >stop >or slow down scans of your address space. This paper details >the >technical aspects of how LaBrea works as well as the >tactical >advantages of deploying LaBrea on your network. > >Background - Creating Virtual Machines >-------------------------------------- > >LaBrea works as a low-level network application that creates >"virtual >machines" on your network - machines that don't really exist yet >are >able to answer connection attempts in a special way that slows >and >even stops the connecting process. > >Local communication between machines on a LAN (local area network) >is >done using MAC (machine access code) addresses, not with IP >addresses. >These MAC addresses are 48 bits in length, as opposed to the 32 >bits >of an IP address. > >External attempts to access machines in the LAN are done using >IP >addresses and will go through the local router. The local >router's >job is to figure out which MAC corresponds to which IP. The >router >does this by broadcasting a special request asking "who owns" the >IP >in question. If any machine "owns" the IP it will respond with its >MAC >address to the router. This request and response is known as >the >Address Resolution Protocol or "ARP." > >The tenacious quality of the ARP protocol used in these >router >requests is what makes LaBrea possible: If at first the router >does >not find a machine with the IP in question, it will ask again - >and >again. > >LaBrea monitors these ARP requests and replies that are needed >to >connect external traffic with the local area network. If it >notes >several successive ARP requests without intervening ARP replies >LaBrea >will issue an ARP reply, effectively creating a virtual machine. > >Making Virtual Machines Real >---------------------------- >Once the virtual machine has been created, LaBrea will monitor >all >traffic destined for the MAC address it has given to the router, >and >will thereafter respond to inbound TCP/IP packets in a way that >can >tie up the connecting machines for long periods of time. Most >modern >TCP/IP implementations are very tenacious about holding >onto >established connections. LaBrea sends enough of a response to hold >the >connection open, but no more - the connecting machine is left >hanging, >waiting. > >Tarpitting >---------- >The connecting machine's TCP/IP implementation will ordinarily >not >give up easily, but will continue to attempt to use what it regards >as >an established connection over and over until it finally times >out. >The timeout value will of course vary from implementation >to >implementation, but it will always be several orders of >magnitude >longer than for a failed connection attempt. This is the "tarpit" >that >LaBrea uses to catch worms and scanners. > >Connection Trapping >------------------- >LaBrea can also trap and hold connection attempts. By moving >a >connection from the established state to the persist state, LaBrea >can >literally hold connections open for an indefinite period of time, >so >that only a process reset at the other end will end it. >Communicating >in this manner is done economically despite the potentially >wide >bandwidth involved; also, the bandwidth usage itself is configurable. > >Impersonation >------------- >To effectively trick more advanced scanning tools into >believing >virtual machines are real, LaBrea offers standard responses to >a >number of typical network probes such as echo requests and >SYN/ACK >scans. > >No Collateral Damage >-------------------- >All connection attempts aimed at LaBrea virtual machines can >be >considered suspect in nature as these machines do not really exist >nor >do they, for example, have any entries in the Domain Name System. > >Tactical Use >------------ >Monitoring connection activities can give the network >operations >center a good view of the extent and nature of any >reconnaissance >taking place: Is a broad range of addresses being targeted, or do >you >have a focused intrusion attempt? > >LaBrea also makes an excellent adjunct to other early warning >systems. >Correlating intrusion detection system warnings with LaBrea >virtual >machine access records helps you immediately gauge the severity of >an >intrusion attempt. > >An intrusion attempt aimed solely at real machines should of course >be >put at a higher priority than a simple cross-network scan. > >The virtual machines appear to have ALL ports open, and thus they >may >alert the network operator to activity that might be missed by >other, >rule-based systems. > >LaBrea can catch insiders on the intranet "in the act" while >requiring >far less maintenance than conventional intrusion detection systems. > >Strategic Benefits >------------------ >LaBrea has the capability to capture and hold scanners - >something >that is of vital importance to the overall health of the Internet. > >At its peak, the Code Red worm infected approximately 300,000 >servers, >yet a quick "back of the envelope" calculation (note 5) indicates >that >1000 sites connected to T1 lines and dedicating only 5% of their >total >bandwidth to LaBrea's "-p" option would have been able to capture >and >hold all Code Red scanning threads at once. > >And by capturing these scanning threads, LaBrea makes it possible >to >contact compromised system owners while keeping their systems >from >compromising other systems. > >Because LaBrea answers SYN/ACK packets with an RST, fully >deploying >LaBrea on all unused IP addresses makes your net block unusable >for >"IP address spoofing" attacks. > >Widespread use of LeBrea is a deterrent against malicious >activity, >making the creation of worms far less interesting and common >hacker >activities much more dangerous. The first of its kind, LaBrea is >an >effective and a very clever anti-hacking tool that should become >a >part of the standard toolkit of any professional network operation. > >Finally, it's fun. Heaps of fun. You can walk into work in the >morning >and look at your logs and think "I am actually doing something to >make >the Internet a safer place." > >Availability >------------ >LaBrea is distributed as source code under the GNU General >Public >License. You may use the source code as you see fit. HackBusters >asks >that you inform them of any improvements that you may make to >the >source code so that they can be incorporated into the public >release >of the code. > >The latest version of LaBrea can always be found >at: >http://www.hackbusters.net > > >License >------- >LaBrea is free software; you can redistribute it and/or modify >it >under the terms of the GNU General Public License as published by >the >Free Software Foundation; either version 2 of the License, or (at >your >option) any later version. > >LaBrea is distributed in the hope that it will be useful, but >WITHOUT >ANY WARRANTY; without even the implied warranty of MERCHANTABILITY >or >FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public >License >for more details. > > >Notes >----- >1. LaBrea has also been successfully compiled on NetBSD. > >2. LaBrea has a command line switch that enables it to work under >a > "switched" environment. In a switched environment, LaBrea will >see > ARP requests but might not see the resulting ARP replies. If >the > command line switch "-s" is used, LaBrea will issue a "mirror" >ARP > request for every request that it sees, listing itself as >the > destination for the answer, making it safe to use in a >switched > environment. > >3. LaBrea ACKs the first inbound data packet with a WIN 0 and >responds > to all following WIN probes with a WIN 0, causing the >connecting > machine to hang in the "persist" state. A single inbound >connection > from an NT based machine will require 1215 bytes/hour (2.7 bps) >to > maintain in the persist state. > >4. Inbound SYN/ACKs receive a RST and yes, you can really PING >LaBrea > virtual machines. > >5. LaBrea requires approximately 8 bps to hold 3 threads of Code >Red. > If there were 300,000 infected machines each with 100 >scanning > threads, then LaBrea would require approximately 80,000,000 bps >to > hold them all. Dividing this among 1,000 sites would require >80,000 > bps from each site. A T1 line runs at 1,544,000 bps; thus it >would > require a commitment of 5.2% of the full T1 bandwidth at each >site. > > > > > >_______________________________________________ >Leaf-user mailing list >[EMAIL PROTECTED] >https://lists.sourceforge.net/lists/listinfo/leaf-user -- Kim Oppalfens, [EMAIL PROTECTED] on 07/10/2001 _______________________________________________ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
