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
