Spoofing Attacks
What do you trust to establish identity? What harm can be done to you or your computer if a mistake is made in establishing identity? If you got an email like the one shown in Figure 8.1, would you believe it? Would you act upon it? In my default view, you don't even see that replies aren't going to go to the apparent Apple address, but instead to that-dll-dufus@hotmail.com. This information becomes visible only if I explicitly view the headers, or pay careful attention to the reply window if I click Reply.
Figure 8.1. A spoofed email message.
Did you know that if you have sendmail running, you can send this same message to yourself by issuing the following commands? Heck, a small amount of lying to your email client will produce much the same result! Sending it to someone else is no more difficult, but I wouldn't recommend it, as some people might think they need to see you in court about that.
[View full width]% telnet soyokaze 25 Trying 140.254.104.241 ... Connected to soyokaze.biosci.ohio-state.edu. Escape character is '^]'. 220 soyokaze.biosci.ohio-state.edu ESMTP Sendmail 8.12.8/8.12.7; Tue, 4 Mar 2003 03:04:54-0500 (EST) HELO soyokaze 250 soyokaze.biosci.ohio-state.edu Hello soyokaze.biosci.ohio-state.edu [140.254.104.241],
In this case we've spoofed some content by lying to the mail transport mechanism. It's neither particularly difficult to do nor particularly difficult to see through, but if the message content is believable, you might not be alerted to pay careful attention to the headers, and that might lead you to believe that content comes from one source when it actually comes from another. A good number of the people thought they were actually reentering and verifying their user information for the PayPal online payment site when they responded to an email that appeared to come from PayPal. Instead they were giving their credit card information to a thief who was spoofing PayPal's identity to establish trust and steal their financial information.
IP-Address Spoofing
Other types of identity can be spoofed as well. For example, the TCP/IP by which information moves around the Internet needs some way for a receiving system to know where to reply to information that is sent to it. In this system each piece of information to be transmitted is broken down into bite-sized chunks that are manageable for network transmission. These bite- sized chunks are called packets , each one of which gets stamped at creation time with a return address (an IP address) saying where it came from.
If you're paranoid about security, you may already be thinking this is a bad idea. If each packet is stamped with a return address, what's to keep someone from forging the return address, or altering it en route and claiming a packet came from somewhere it didn't, right? If you're not that security paranoid yet, you might be thinking "Why bother ”what's to be gained ?" Well, for one thing, the stolen return address would let a cracker falsify his network identity, so that you wouldn't know who's attacking you. If he can falsify the return address, there's no way for you to track incoming traffic back to the actual origin. For another, it makes for an interesting way to create a massive network-swamping denial of service attack: Someone could forge your return address onto their packets and then attack many random machines around the Internet. Everyone sees your machine as the attacker, and quite often can be induced to retaliate or at least respond (even automatically as a required part of the TCP/IP), resulting in devastating network consumption or outages for your machine.
The first scenario is something like the network version of sending your enemies (or friends , if you've a twisted sense of humor) free tickets or invitations to events that don't actually exist. The tickets or invitations have to be sent in an envelope with a falsified return address, because the lack of a return address might seem suspicious to the recipients. Those who try to go to the nonexistent event have no idea who actually sent the information on the event, because at this point, they know that the information certainly did not come from the address specified as the return address. They'd be mad, and possibly out some resources for travel time and dinner, but would have no idea who they were mad at. The second is more like writing bad checks on someone else's account. The recipients of the bad checks think the culprit is the name on the check and pursue payment accordingly , which probably has a negative impact on the account holder's credit. In either case, the misdirection as to the real source of the information can lead to considerable trouble for either the party who is mislead or the party who is spoofed as the sender.
In reality, although the idea of using return addresses attached to each packet sounds like a bad idea at first blush, it's an almost inevitable consequence of the way networks work. Data isn't transmitted directly, on an unbroken wire, from the sending machine to the receiving machine. Instead it hops from machine to machine to machine along the network, being handed from one to the next , always (in the ideal, anyway) getting closer to its target, until it finally reaches the machine that it's intended for. This model for data transmission is a result of the impossibility of wiring every machine on the planet directly to every other machine, and many of the vulnerabilities in today's networks are an inherent part of the model. Return addresses on packets, for example, are a consequence of the need for a packet at hop 5 of a 10-hop journey to have some idea of where it's come from and where it's going. The fifth machine down the line doesn't have any direct connection to either the originating machine or the receiving machine, and so it must get the information regarding where a packet came from and where it's going from somewhere. That "somewhere" might as well be information directly contained in the packet, because as easy to forge as it is, there's no other less-forgeable method for keeping the information with the packet. One might argue that if there was auxiliary information kept beside the packet, instead of in it, that perhaps the first machine to receive a packet from a sender could fill in the "this packet came from:" field with the originator's IP address, or some other identifying token. All a cracker intent on mischief would need to do then is control the machine at the first hop and get it to forge the information, and we're right back in the same boat. Because such schemes increase the complexity of the system without meaningfully increasing the trustability of the information, the TCP/IP system uses the simple, seemingly naive ”but no worse than any other ”solution of using return addresses contained in the packets.
If a machine lies about its IP address in packets that it sends, there may very well be no information to disagree with this identification. What's to say that the information is a lie? If it hasn't originated in some place where a machine of that IP really shouldn't exist, what's to say that the packet didn't really come from a machine with that IP address? Nothing. It's as if, as a person, you were given to complete trust in the identity of the sender of a letter based on the address typed on the envelope.
If you try to set your machine's IP address to one that already exists on the network, you'll be presented with a dialog that looks something like Figure 8.2, indicating that the IP that you've selected is already claimed on the network.
Figure 8.2. Macs check for other machines on the network with the same IP address they're trying to claim when they try to initialize their network interfaces.
Because there is no necessity that any other machines on the network be engaging in communications that would allow the software to make this check against duplicates in a passive manner, some active step must be being taken to determine whether any other machines are claiming the IP address your machine wants. While initializing the network interface, therefore, the Mac is sending out some sort of network broadcast query and inviting other machines to tell it that it's not allowed to have the IP it requested . What's to say that there's really a machine out there with your IP address? What if someone just wanted to keep you from using your network connection? If they simply watch for the check from your machine on the network, and spoof the response to indicate that the IP is already taken, wouldn't that constitute an effective, and quite annoying denial of service attack?
In fact, the conflictd program, available from http://ccitt5.net/archive/conflictd.tar.gz, provides a convenient way to test this theory. It requires a slightly out-of-date version of the libnet library available from http://www.packetfactory.net/libnet/dist/deprecated/. I chose libnet-1.0.2.tgz , but other pre-1.1 versions are likely to work (if you find an updated conflictd , it may work with the current libnet version, which is most easily installed using fink ). It also requires libpcap , and a few header files that aren't normally included with Jaguar. The easiest route to installation is to use fink to install libpcap and libnet , then build the older version of libnet by hand and install it in /usr/local/ rather than in /sw . Then edit the Makefile so that it includes and links from /usr/local/include and /usr/local/lib before it checks the /sw hierarchy. In its unadulterated form conflictd only annoys Macs, but the effect on Windows machines of the 95 and 98 persuasion is pronounced. Issuing the following command:
# ./conflict-DoS en1 192.168.1.8 Using interface en1 Each dot is 10 popups.. .................... causes the WinTel box living at 192.168.1.8 to display the dialog shown in Figure 8.3. Actually, it causes it to display the dialog 200 times, and the machine is effectively useless until the OK button is clicked on each of them. All this program is doing is forging a storm of reply packets to send to the Windows machine as though it had enquired about the availability of its IP address. Modifying the program to work as a daemon, watching for the Mac version of the conflict-resolution request, and spoofing equally damaging responses for Mac OS X would not be particularly difficult. The daemonization code is already provided in the conflictd source.
Figure 8.3. Wintel boxes check when the network interface is initialized , but also pop up annoying conflict dialogs whenever any other machine tries to register a duplicate IP at a later time.
More insidiously, packets carry not only their own return address that must be assumed to be correct, but they also can carry a return route via which responses are supposed to be delivered. This was a considerably more naive idea than having packets carry their own return address. Allowing packets to specify their own source routing allows an attacker to insert packets into a network with a spoofed IP address, so that you don't know who or where they're really coming from, and also to convince the network to return responses to places that the normal routing software for the Internet wouldn't send them ”places that wouldn't typically be able to receive the response. Using this capability, an attacker can slip packets into your network with spoofed IP addresses ”packets that claim to be from other trusted machines on your network. They can also specify that responses be sent to some other host outside your network, rather than to the machine on your network that matches the IP specified in the packet. Thankfully, almost all sane network software is now configured to block source-routed packets because they have a very limited potential for positive use and considerable potential for abuse.
It should be noted that both these problems with TCP/IP packets stem from the fact that packets are delivered like snail -mail letters , with no direct connection between the sender and the receiver. This allows the information in the packets to be forged with no possibility for verification of the contents. Even a complex interaction between sender and receiver with each replying about the contents of the packets received and cross-checking with the other as to the validity is not proof against a man-in-the-middle attack, whereby a machine somewhere on the Net spoofs both connections and pretends to be each machine to the other. The specifics of man-in-the-middle attacks are discussed in more detail in Chapter 9, "Everything Else," but the basic mechanism should be understood as spoofing oneself as a piece of wire along the network, while actually monitoring and potentially altering communications traveling through that wire. The fault is then, as noted previously, one of establishing and verifying trust. Any credentials can be duplicated . Which ones are sufficient?
ARP Spoofing
The IP address contained in the packet is one form of return address for the packet, and is used by the network at large to determine where the packet belongs. More accurately, routing devices on a network determine whether a packet belongs on another network by examining the packet's IP address, and move it to that other network if it does. Internal to a particular network, however, any machine is free to examine the packet and read it. Whether a machine is supposed to read the packet is based on a packet field that contains another form of identification, the MAC address . MAC (Media Access Control) addresses are (supposed to be) unique hardware IDs assigned to ethernet interfaces that are completely unique across all ethernet interfaces ever made. As a packet is delivered from network to network, the delivering router fills in a hardware ID (MAC address) that it has determined to be correct for the next machine that is supposed to receive the packet. This MAC address may be for the next routing machine that is supposed to handle the packet. Or, if the packet is being delivered into the final network where the machine with the IP address matching the packet's target is supposed to reside, it may be the MAC address of the target machine itself. The router's determination of the MAC address that corresponds to a destination IP is based on the Address Resolution Protocol (ARP). Packets placed on the network that are bound for a local machine (ones that don't need to be sent through a router), also have a MAC address that corresponds to the ethernet interface of the destination IP. This, too, is based on ARP information acquired by each host on the network.
Unfortunately , the determination of the values to place in an ARP table is based on " observed reality" on the wire: The routers and machines collect a table of IP addresses and their associated MAC addresses from the values they see in packets on the network. It's all too easy to forge packets with false MAC addresses as well as false IP addresses, and this can easily cause traffic entering a network that is supposed to be delivered to one machine to instead end up elsewhere.
Ettercap: Ethernet Monster
The ettercap program, which was covered in more detail in the previous chapter (available through fink , or as a Macintosh .pkg file directly from the authors at http://ettercap. sourceforge .net/) is capable of quite a few nifty (if you're not an admin kiddie ) ARP spoofing “based tricks, including interposing itself into and decrypting SSH1 communications. For example, in Figure 8.4 ettercap is shown sniffing the contents of an FTP session that's occurring between a pair of hosts on a different branch of a switched network.
Figure 8.4. Ettercap sniffing traffic in a switched network via ARP spoofing.
After seeing ettercap's sniffing capabilities in the previous chapter, this probably doesn't seem surprising. Note, however, that I've just said that this sniffing is occurring on a switched network, which appears to be in contradiction to what we've previously written regarding switched networks. Here, traffic that isn't supposed to be going to my machine ( Racer-X at 192.168.1.16 in this example) is clearly managing to get out of the physical branches of the network to which it's supposed to be restricted by the switches, and coming to my machine as well. The traffic isn't doing this in contravention of the switches' intent to restrict it to certain wire segments, however; it's doing it because my machine has lied to the switches and other machines on the network. Because the ARP-based routing information is gleaned from what's seen on the wire, and because most switches route solely based on the MAC addresses they've seen, the other hardware believes the lies my machine has told, and dutifully routes traffic onto my network segment, even though I'm not the actually intended recipient.
In this case, what is happening is that ettercap has spoofed ARP-response packets onto the network, claiming that the MAC address on my machine is associated with both the IP addresses of the hosts that want to communicate ( 192.168.1.17 , Sage-Rays-Computer and 192.168.1.4 , mother.killernuts.org). The ARP table on my machine, however, has been left uncorrupted. Ettercap has effectively interposed itself between 192.168.1.17 and 192.168.1.4 . Whenever Sage's computer wants to speak to mother, it looks up the MAC address associated with 192.168.1.4 from its ARP table and builds packets with that MAC address as their destination. Unfortunately for Sage's computer, my machine has poisoned Sage's ARP table. Instead of getting the MAC address that really belongs to mother, Sage's computer gets the MAC address of my machine, and dutifully puts this incorrect information into the outgoing packets. The switched network knows no better, and dutifully routes the packet to Racer-X, where ettercap lies in wait. Upon receipt, ettercap looks at the packet to see whether there's anything interesting in it, such as usernames or passwords, and then rewrites an identical outgoing packet, only with the correct MAC address for mother. The network conveys the packet to mother, who reads it and has no idea that it's been misrouted, read, and altered along the way. Replies back from mother suffer the same fate because mother's ARP table has also been poisoned so as to associate Racer-X's MAC address with Sage's computer's IP. As you can see from the following output, the only computers with poisoned ARP information regarding Sage's computer or mother as destinations are Sage's computer and mother themselves . Other computers on the network have the correct information, and are largely oblivious to the machinations of ettercap.
[Sage-Rays-Computer:~] sage% arp -a ? (192.168.1.4) at 0:30:65:19:3c:54 ? (192.168.1.13) at 0:30:65:39:ca:1 ? (192.168.1.16) at 0:30:65:19:3c:54 [root@mother ~]# arp -a cvl232001.columbus.rr.com (204.210.232.1) at 08:00:3E:19:47:CA [ether] on eth1 ? (192.168.1.16) at 00:30:65:19:3C:54 [ether] on eth0 ? (192.168.1.17) at 00:30:65:19:3C:54 [ether] on eth0 192.168.1.200 ray 154> arp -a ? (192.168.1.4) at 0:20:af:15:2a:d ? (192.168.1.16) at 0:30:65:19:3c:54 ? (192.168.1.17) at 0:30:65:aa:37:ae Racer-X conflictd 87# arp -a ? (192.168.1.4) at 0:20:af:15:2a:d ? (192.168.1.13) at 0:30:65:39:ca:1 ? (192.168.1.17) at 0:30:65:aa:37:ae Racer-X conflictd 88# ifconfig lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 inet 127.0.0.1 netmask 0xff000000 gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280 stf0: flags=0<> mtu 1280 en1: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500 inet6 fe80::230:65ff:fe19:3c54%en1 prefixlen 64 scopeid 0x4 inet 192.168.1.16 netmask 0xffffff00 broadcast 192.168.1.255 ether 00:30:65:19:3c:54 media: autoselect status: active supported media: autoselect
Ettercap can not only monitor traffic in connections it's watching in this way, but it can also inject into the connection traffic that the receiving computer will believe originated from the machine with which it's supposedly talking directly, forge almost any packet onto the network, kill most types of network connections, perform pattern-based substitutions into packets as they pass by, and extract passwords from a large number of protocols.
Fortunately, this type of manipulation of the routing information is only mostly invisible to the rest of the network, not completely invisible. ARP tables are usually updated only when some piece of software needs to use the data in them, so it's probable that some computers will never see any effect from the ARP spoofing going on, and their ARP tables will never contain poisoned data. However, it's also possible for a conscientious admin to run software that specifically watches for inconsistencies in the ARP replies bouncing around the network, and that throws up warnings if a given IP address or MAC address seems to be changing its apparent identity regularly. The arpwatch package, described in more detail in the next chapter, is one utility that is very nice for this type of examination. In its typical configuration, it runs as a daemon, and sends email to root whenever it sees something suspicious happening with MAC<->IP mappings on the network. For example, in this set of arpwatch debugging output, arpwatch is reporting on the continuing argument between Sage's computer ( 192.168.1.17 , really MAC 0:30:65:aa:37:ae ) and Racer-X ( 192.168.1.16 , really MAC 0:30:65:19:3c:54 ), and between mother ( 192.168.1.4 , really MAC 0:20:af:15:2a:d ) and Racer-X over exactly what their real MAC addresses (here called ethernet addresses ) are, as each sends out ARP responses claiming an IP<->MAC address match for other machines on the network to use.
Racer-X arpwatch 5# arpwatch -d From: arpwatch (Arpwatch) To: root Subject: flip flop hostname: <unknown> ip address: 192.168.1.4 ethernet address: 0:30:65:19:3c:54 ethernet vendor: <unknown> old ethernet address: 0:20:af:15:2a:d old ethernet vendor: <unknown> timestamp: Monday, January 20, 2003 13:14:44 -0500 previous timestamp: Monday, January 20, 2003 13:14:19 -0500 delta: 25 seconds From: arpwatch (Arpwatch) To: root Subject: flip flop hostname: <unknown> ip address: 192.168.1.4 ethernet address: 0:20:af:15:2a:d ethernet vendor: <unknown> old ethernet address: 0:30:65:19:3c:54 old ethernet vendor: <unknown> timestamp: Monday, January 20, 2003 13:14:44 -0500 previous timestamp: Monday, January 20, 2003 13:14:44 -0500 delta: 0 seconds From: arpwatch (Arpwatch) To: root Subject: flip flop hostname: <unknown> ip address: 192.168.1.17 ethernet address: 0:30:65:aa:37:ae ethernet vendor: <unknown> old ethernet address: 0:30:65:19:3c:54 old ethernet vendor: <unknown> timestamp: Monday, January 20, 2003 13:14:44 -0500 previous timestamp: Monday, January 20, 2003 13:14:44 -0500 delta: 0 seconds From: arpwatch (Arpwatch) To: root Subject: flip flop hostname: <unknown> ip address: 192.168.1.17 ethernet address: 0:30:65:19:3c:54 ethernet vendor: <unknown> old ethernet address: 0:30:65:aa:37:ae old ethernet vendor: <unknown> timestamp: Monday, January 20, 2003 13:15:14 -0500 previous timestamp: Monday, January 20, 2003 13:14:44 -0500 delta: 30 seconds Couic ”The Connection Cutter
IP and MAC-address spoofing isn't limited in its "utility" to only sniffing connections, though. Any use to which a response packet from or about a given host might be put, a spoofed packet can be used for as well. For example, RST (reset) packets that appear to be from some working machine on the network can be spoofed onto the wire by another machine. This effectively knocks the spoofed machine off the wire because any machine in communication with it will receive periodic resets to the connection, and believe that the spoofed machine has decided to drop the connection itself. The couic program is available from http://michel.arboi.free.fr/UKUSA/couic.html and bills itself as a "connection cutter" or "active filter," used to enforce network policy rules. It certainly can be used to watch for and sever almost any sort of network communication from or to any host on its local network, but it seems highly likely it'll be used for mischief. The author notes that inappropriate use in France can land the mischievous in jail for three years . Couic compiles relatively easily with the same libnet and libpcap libraries as required for conflictd. After it is compiled, it is run as couic -i <interface> -t <deny rules> . For example, the following command will deny TCP traffic to or from 192.168.1.17 :
couic -i en1 -t tcp and host 192.168.1.17
In fact, running this command while I've got an SSH connection up to 192.168.1.17 results in the following error output on my machine, as soon as I try to do anything that talks to it:
[Sage-Rays-Computer:~] sage% Read from remote host 192.168.1.17: Connection reset by peer Connection to 192.168.1.17 closed. Racer-X ray 36>
Trying to reestablish the connection while couic's still running results only in a similar error:
Racer-X ray 36> slogin 192.168.1.17 -l sage write: Broken pipe While this is happening, couic itself is reporting its activities. According to the author, arpwatch sees these attacks as well, but at this time we haven't been successful at getting arpwatch to display this information.
The rule language is in flux, so for topics beyond simple protocol denial as shown here, we recommend visiting the author's Web page.
LaBrea Tarpit
Despite some writers' insistence that spoofing lacks any possible legitimate purpose (http://www.sans.org/rr/threats/spoofing.php), at least one inspired system administrator has come up with a way to use spoofing as a tool for the good of the network. If you remember, we've mentioned several times that a typical attack mechanism for script kiddies is to run automated attacks against all IPs on a network, and you can typically defend against these by simply keeping up on patches and making your machines difficult to invade. It's always seemed like there should be an active way to defend against these, instead of simply passively ignoring the attacks. For example, a nice active defense might be to track down the attacking machines and kick them off of the network. Unfortunately, most of the time, the machines actively attacking yours aren't actually the attacker's machines; they're just zombies that the attacker has taken over. Also unfortunately, because their owners are rarely aware that their machines are taking part in an attack, they rarely take you implementing such an active defense against them kindly. Or, to put it more simply, you're likely to land in legal trouble if you take the route of attempting to mitigate attacks against your machine by attacking back.
Fortunately, system administrator Tom Liston, in a flash of inspired cleverness , realized that although the owners of a remote system might take litigious offense at your contacting their system and initiating an attack, they'd be on awfully shaky ground if it was their system that contacted yours, and yours simply refused to hang up the phone.
Tom realized that one of the signatures of many automated attacks (and specifically the Code Red worm that was traveling the Net at the time) is that the attacker rarely knows the specific IPs that are on your network. Therefore, they tend to try to attack every IP address on your IP range. This can be used against them. What if you could put a machine at each of the unused IP addresses, and have it try to tie up the attacker's connection by simultaneously being invulnerable to the attack while also refusing to hang up when it was contacted? Many networks have a larger number of unused IP addresses than they have used, so if you could populate them all with machines that would refuse to let an attacker go on to another target, it might seriously slow down the propagation of an attack. Nobody wants to set up that many "tarpit" machines just to mire inbound connections, but what if you didn't need a machine? Because the only thing the attacker gets back is network responses from the machine, why not just spoof the responses? Put together a server that watches for connections trying to make their way to machines that don't exist and spoof responses to them as though those (nonexistent) machines wanted to talk.
ARP even provides a convenient mechanism by which to perform this spoofery. When a router needs to contact a machine for which there isn't an entry in its ARP table, it sends out an ARP request asking for some machine to claim that it has that IP. The inbound router for a network segment certainly doesn't have any ARP entries for machines that don't exist, and nonexistent machines aren't going to respond and populate that table. This makes it easy for a tarpit program that wants to pretend to be "any machine that doesn't exist" to do so; all it needs to do is watch the network for ARP requests with no matching responses, and respond to them with spoofed packets itself. The router then routes all further information for that IP to the tarpit server.
Tom implemented this idea as the LaBrea package, which sits on a network and watches for incoming ARP requests that go unanswered. These it reasonably presumes to be looking for machines that don't exist. When it sees them, it spoofs responses that essentially fool the attacking zombie into thinking it's found a fresh host to infect , and then keeps it hanging on the line indefinitely. This ties up the attacker's resources, and prevents at least one zombie resource from making further attacks until the connection to your machine drops . In the grand scheme of things, it's not much, but it's far better than just shuffling the attack off onto someone else. As one system administrator put it, "You can come into work in the morning, look at your logfiles, and say 'Wow ”I'm actually saving the world.'" Saving the world might be a bit over the top, but one analysis suggested that with only a few hundred average networks cooperating by running a single LaBrea tarpit server, roughly 300,000 zombied machines could be held at bay indefinitely, for nothing more than a few percent of each cooperating site's bandwidth. If I can contribute my half-percent of helping to stop the spread of Internet worms, and I get to annoy script kiddies in the process, that's as close to saving the world as I need to get to feel I've done my job for the day.
Until recently, LaBrea had been available from http://www.threenorth.com/LaBrea/, but due to recent DMCA legislation, it is not currently available at that address. It's interesting how legislation that protects corporate security interests can interfere with protecting your security interests. Fortunately, though, you can now find a version at http://labrea.sourceforge.net/labrea- info .html. The current version requires some modification to get it running properly on OS X. Like conflictd, it requires a slightly out-of-date version of libnet , libpcap , and some headers that are missing from Jaguar. In addition, part of libpcap doesn't seem to work quite the same on OS X as on some other operating systems, and the timeout field of pcap_open_live() seems to need a value greater than zero for it to properly capture packets. Upping this value to 5ms appears to cause LaBrea to function as designed.
Although installing and configuring most network security packages is a significant task, for the benefit it provides, using LaBrea is quite simple. It's almost completely autoconfiguring to a useful default state, so although a number of command-line options are detailed in Table 8.1, you can produce a completely functional tarpit server by running the LaBrea executable with only verbose logging, and flags to direct it to talk to the proper interface and to write to the terminal ( STDOUT ) instead of syslogd . (You'll have to read the documentation that comes with it to learn about the z flag, however; the author wants it that way.) For example, if I run LaBrea on Racer-X as follows , it will quite effectively tarpit any attempted connections to machines that don't exist. Again, we've left the prompts intact in these captured dialogs so that you can more easily keep track of who's doing what to whom.
Racer-X LaBrea2_3 50# ./LaBrea -vbozi en1 Initiated on interface en1 /etc/LaBreaExclude not found - no exclusions On another computer on my network, my ARP table currently looks like this:
[Sage-Rays-Computer:~] sage% arp -a ? (192.168.1.13) at 0:30:65:39:ca:1 ? (192.168.1.16) at 0:30:65:19:3c:54 If I then try to ping a machine that doesn't exist, Sage's computer is going to try to find it via ARP requests:
[Sage-Rays-Computer:~] sage% ping 192.168.1.21 PING 192.168.1.21 (192.168.1.21): 56 data bytes ^C --- 192.168.1.21 ping statistics --- 7 packets transmitted, 0 packets received, 100% packet loss Meanwhile, tcpdump , looking at what's going on with ARP, has this to say:
Racer-X arpwatch 17# tcpdump -i en1 arp 02:17:57.741882 arp who-has 192.168.1.21 tell 192.168.1.17 02:17:58.742136 arp who-has 192.168.1.21 tell 192.168.1.17 02:17:59.742338 arp who-has 192.168.1.21 tell 192.168.1.17 02:18:00.742510 arp who-has 192.168.1.21 tell 192.168.1.17 02:18:00.755537 arp reply 192.168.1.21 is-at 0:0:f:ff:ff:ff The eventual response assigning 0:0:f:ff:ff:ff (a rather fake-looking MAC address) comes from LaBrea, which has meanwhile detected that there were no responses to those four ARP requests, and has decided to reply with a spoofed machine. The following line appears on Racer-X 's console:
Tue Jan 21 02:18:00 2003 Capturing local IP: 192.168.1.21
Sage's ARP table now looks like this:
[Sage-Rays-Computer:~] sage% arp -a ? (192.168.1.13) at 0:30:65:39:ca:1 ? (192.168.1.16) at 0:30:65:19:3c:54 ? (192.168.1.21) at 0:0:f:ff:ff:ff If I further try to ping a machine that does exist, but that isn't already in Sage's ARP table, something different happens. tcpdump shows this log:
02:18:46.206856 arp who-has 192.168.1.4 tell 192.168.1.17 02:18:46.215544 arp reply 192.168.1.4 is-at 0:0:f:ff:ff:ff 02:18:49.302675 arp reply 192.168.1.4 is-at 0:20:af:15:2a:d
And LaBrea shows another captured IP address:
Tue Jan 21 02:18:46 2003 Capturing local IP: 192.168.1.4
Yet my ping proceeds as normal:
[Sage-Rays-Computer:/Users/sage] sage# ping 192.168.1.4 PING 192.168.1.4 (192.168.1.4): 56 data bytes 64 bytes from 192.168.1.4: icmp_seq=0 ttl=255 time=1.146 ms 64 bytes from 192.168.1.4: icmp_seq=1 ttl=255 time=0.913 ms 64 bytes from 192.168.1.4: icmp_seq=2 ttl=255 time=0.929 ms 64 bytes from 192.168.1.4: icmp_seq=3 ttl=255 time=0.928 ms Pinging the IP address that LaBrea captured works because the machine at 192.168.1.4 is a bit slow (it's a Linux box running on a 486 chip, but it makes a fine router), and it responded to the ARP request sent by Sage's machine slower than LaBrea running on Racer-X did. In anticipation that such things might happen, LaBrea has been written so that it can function as a temporary packet rerouter to fix things if it has inadvertently made a mistake and grabbed an IP too quickly. In this case, after it sees the proper response from 192.168.1.4 , LaBrea redirects packets that are being written with the faked MAC address to their proper recipient until the ARP tables are updated properly and traffic for that IP is no longer being directed to the fake MAC. LaBrea can also use this functionality to discover when a new machine has appeared on the network at one of the IP addresses it's claimed, and to seamlessly relinquish spoofed IP addresses as necessary.
In short, LaBrea fights fire with fire by turning attackers ' own techniques against them. To help you fight fire with fire, Table 8.1 provides a listing of command-line options for LaBrea.
Table 8.1. Command-Line Options for the LaBrea Tarpit Server
| Option | Function |
|---|---|
| -i <interface> | Sets a nondefault interface. |
| -t <datasize> | Sets connection throttling size in bytes. Default is 10. |
| -r <rate> | Sets ARP timeout rate in seconds. Default is 3. |
-s | Safe operation in a switched environment. |
-l | Logs activity to syslog. With version 2.0.1+ you can use kill -USR1 <LaBrea_PID> to toggle logging. If logging was not enabled at start, this sets the -l flag. If logging ( -l -v ) is set, this saves the value and turns off logging. If logging is presently toggled off, it restores the saved level ( -l -v ). |
-v | Verbosely logs activity to syslog. With version 2.0.1+ you can use kill -USR1 <LaBrea_PID> to toggle logging. If logging was not enabled at start, this sets the -l flag. If logging ( -l -v ) is set, this saves the value and turns off logging. If logging is presently toggled off, it restores the saved level ( -l -v ). |
| -F <filename> | Specifies a BPF filename. Connections specified by the BPF will also be tarpitted. These connections must be firewalled to drop inbound packets or this won't work. |
-h | Hard-captures IPs. /etc/LaBreaHardExclude should contain an IP list that you never want LaBrea to hard-capture. Only necessary with the -h option. |
-x | Disables IP capture. |
-m | Specifies a netmask. The network number and netmask are normally loaded from the interface. If you're using an interface that has no IP, you'll have to provide both these numbers . These must be correct or bad things may happen. |
-n | Specifies a network number. The network number and netmask are normally loaded from the interface. If you're using an interface that has no IP, you'll have to provide both of these numbers. These must be correct or bad things may happen. |
-v | Prints version information and exits. |
-a | Does not respond to SYN/ACKs and PINGs . By default, LaBrea "virtual machines" respond to an inbound SYN/ACK with a RST and are "pingable." The -a option eliminates this behavior. |
-q | Does not report odd (out of netblock) ARPs. |
-T | Test mode ”prints out debug information but does not run. |
-R | Soft restart ”waits while recapturing active connects. |
| -p <maxrate> | Persists state capture connect attempts. LaBrea will permanently capture connect attempts within the limit of the maximum data rate specified (in bytes/sec). |
-b | Logs bandwidth usage to syslog. |
-d | Does not detach process. |
-o | Sends output to stdout rather than syslog. This sends log information to stdout rather than to syslog. This option also implies and sets the -d option. |
-P | Persists mode capture only. |
-l | Beta "Linux" window probe captures code. |
| NOTES on control files: LaBrea also uses two files to control its operation: /etc/LaBreaExclude contains a list of IPs (one per line) to exclude from LaBrea 's attention. /etc/LaBreaHardExclude contains a list of IPs that LaBrea won't hard-capture. (Use with the -h option.) The IP address can be specified either as single addresses (for example, 192.168.0.4 ) or as a range of addresses (for example, 192.168.0.1 - 192.168.0.50 ). LaBrea should never capture an IP that has an active machine sitting on it. These two files are used to give you control over "empty" IP addresses. However, it certainly doesn't hurt to "exclude" active IPs. Sending LaBrea a SIGHUP will cause it to reread the "exclusion" files and report packet statistics to syslog. | |
LaBrea can even be configured to work across a switched network, where one would normally conclude that such a server would see incoming ARP requests but not the returned reply. To overcome this difficulty, when used on a switched network, LaBrea watches for incoming ARP requests and then sends a duplicate request of its own for the same information. It does not consider an IP for building a tarpit in this situation unless its own requests for an ARP reply go unanswered. This mode may also be useful on networks where there are slow or transiently out-of-contact machines, as it induces LaBrea to more frequently check the status of apparently nonexistent machines that are enquired about often.
 |
| |
| Top |
EAN: 2147483647
Pages: 158
- Chapter VIII Personalization Systems and Their Deployment as Web Site Interface Design Decisions
- Chapter IX Extrinsic Plus Intrinsic Human Factors Influencing the Web Usage
- Chapter XI User Satisfaction with Web Portals: An Empirical Study
- Chapter XII Web Design and E-Commerce
- Chapter XIII Shopping Agent Web Sites: A Comparative Shopping Environment