Re: [Leaf-user] LaBrea for LRP?
> 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? Not right now, but I'm looking into it. I'll post to the list if I get anything like this working... Charles Steinkuehler http://lrp.steinkuehler.net http://c0wz.steinkuehler.net (lrp.c0wz.com mirror) ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] LaBrea for LRP?
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 rang
Re: [Leaf-user] LaBrea for LRP?
On Thu, 20 Sep 2001, David Douthitt wrote: > Alec Miller wrote: > > > I don't have the tools to make [LaBrea] into an LRP package, but I think this > > could be a neat addon. > > > > (If it doesn't already exist for LRP) > > Wouldn't you know it I was just working on this; I've already done > it. > > I made a few code changes - mainly designed to make it less obtrusive if > started without options, and to make it use a standard option (-h). The > bogus -z option is removed, too, though I wonder about that some - > that's an undocumented option which forces you to read the documentation > (nice, eh?). > > Unfortunately, this program doesn't do what I had hoped for: a program > like portsentry, which sits on a port and sucks in those unlucky enough > to connect... The other thing is you need a spare IP address, which few have. Although, I suppose you could do this: RedirectMatch ^.*\.(exe|dll).* http://some.internal.IP Which is a lot more friendly than my current: RedirectMatch ^.*\.(exe|dll).* http://support.microsoft.com Maybe I'll try that later. > > I'll see if I can't put this up at > http://leaf.sourceforge.net/pub/oxygen/packages/labrea.lrp sometime > soon. > > Be sure to read the options (with LaBrea -? or LaBrea -h) - they changed > slightly with my variant - I don't know if this is best, but... > > ___ > Leaf-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/leaf-user > -- Jack Coates Monkeynoodle: A Scientific Venture... ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
Re: [Leaf-user] LaBrea for LRP?
Alec Miller wrote: > I don't have the tools to make [LaBrea] into an LRP package, but I think this > could be a neat addon. > > (If it doesn't already exist for LRP) Wouldn't you know it I was just working on this; I've already done it. I made a few code changes - mainly designed to make it less obtrusive if started without options, and to make it use a standard option (-h). The bogus -z option is removed, too, though I wonder about that some - that's an undocumented option which forces you to read the documentation (nice, eh?). Unfortunately, this program doesn't do what I had hoped for: a program like portsentry, which sits on a port and sucks in those unlucky enough to connect... I'll see if I can't put this up at http://leaf.sourceforge.net/pub/oxygen/packages/labrea.lrp sometime soon. Be sure to read the options (with LaBrea -? or LaBrea -h) - they changed slightly with my variant - I don't know if this is best, but... ___ Leaf-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user
[Leaf-user] LaBrea for LRP?
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
