As we come to rely more and more on massively interconnected networks, the stability and security of those networks becomes more vital than ever. The world of business has adopted information technology to help streamline processes, increase productivity, and cut costs. As such, a company’s IT infrastructure is often a core asset, and many businesses would cease to function if disaster (whether natural or digital) were to significantly disrupt their network operations. At the same time, the widespread adoption of the Internet as a global communications medium has also brought computer networks out of the business and academic world and into our personal lives. That largest of networks is now used not only for information and entertainment, but also as a means to keep in touch with friends, family, and loved ones.
Although this book as a whole is meant to address network security, the information it contains extends into many other areas. After all, a network is simply a means to connect machines and services so that they can communicate. This chapter, however, deals primarily with the security and integrity of the network itself. In this chapter, you’ll learn how to detect and prevent certain types of spoofing attacks that can be used to compromise the core integrity of a TCP/IP Ethernet network at its lowest level. You’ll also see how to protect against brute-force attacks against SSH, how to keep track of vulnerabilities, and how to scan for viruses on Unix servers.
Although it is not always a direct security threat, network reconnaissance is often a precursor to an attack. In this chapter, you’ll learn how to fool those who are trying to gather information about the hosts on your network, as well as ways to detect eavesdroppers who are monitoring your network for juicy bits of information.
Find out if there’s a “man in the middle” impersonating your server.
One of the biggest threats to a computer network is a rogue system pretending to be a trusted host. Once someone has successfully impersonated another host, he can do a number of nefarious things. For example, he can intercept and log traffic destined for the real host, or lie in wait for clients to connect and begin sending the rogue host confidential information.
Spoofing a host has especially severe consequences in IP networks, because it opens many other avenues of attack. One technique for spoofing a host on an IP network is Address Resolution Protocol (ARP) spoofing. ARP spoofing is limited only to local segments and works by exploiting the way IP addresses are translated to hardware Ethernet addresses.
When an IP datagram is sent from one host to another on the same physical segment, the IP address of the destination host must be translated into a MAC address. This is the hardware address of the Ethernet card that is physically connected to the network. To accomplish this, the Address Resolution Protocol is used.
When a host needs to know another host’s Ethernet address, it sends out a broadcast frame that looks like this:
01:20:14.833350 arp who-has 192.168.0.66 tell 192.168.0.62
This is called an ARP request. Since this is sent to the broadcast address, all Ethernet devices on the local segment should see the request. The machine that matches the request then responds by sending an ARP reply like the following:
01:20:14.833421 arp reply 192.168.0.66 is-at 0:0:d1:1f:3f:f1
Since the ARP request already contained the MAC address of the sender in the Ethernet frame, the receiver can send this response without making yet another ARP request.
ARP’s biggest weakness is that it is a stateless protocol . This means that it does not track responses to the requests that are sent out and therefore will accept responses without having sent a request. Someone who wanted to receive traffic destined for another host could send forged ARP responses matching any chosen IP address to that host’s MAC address. The machines that receive these spoofed ARP responses can’t distinguish them from legitimate ARP responses and will begin sending packets to the attacker’s MAC address.
Another side effect of ARP being stateless is that a system’s ARP tables usually use only the results of the last response. In order for someone to continue to spoof an IP address, it is necessary to flood the host with ARP responses that overwrite legitimate ARP responses from the original host. This particular kind of attack is commonly known as ARP cache poisoning .
Several tools—such as Ettercap (http://ettercap.sourceforge.net) and Dsniff (http://www.monkey.org/~dugsong/dsniff/)—employ techniques like this to both sniff on switched networks and perform “man-in-the-middle” attacks. This technique can, of course, be used between any two hosts on a switched segment, including the local default gateway. To intercept traffic bidirectionally between hosts A and B, the attacking host C will poison host A’s ARP cache, making it think that host B’s IP address matches host C’s MAC address. C will then poison B’s cache, to make it think A’s IP address corresponds to C’s MAC address.
Luckily, there are methods to detect just this kind of behavior, whether you’re using a shared or switched Ethernet segment. One program that can help accomplish this is Arpwatch (ftp://ftp.ee.lbl.gov/arpwatch.tar.gz), which works by monitoring an interface in promiscuous mode and recording
MAC/IP address pairings over a period of time. When it sees anomalous behavior, such as a change to one of the MAC/IP address pairs that it has learned, it will send an alert to syslog. This can be very effective in a shared network using a hub, since a single machine can monitor all ARP traffic. However, due to the unicast nature of ARP responses, this program will not work as well on a switched network.
To achieve the same level of detection coverage in a switched environment, Arpwatch should be installed on as many machines as possible. After all, you can’t know with 100% certainty what hosts an attacker will decide to target. If you’re lucky enough to own one, many high-end switches allow you to designate a monitor port that can see the traffic on all other ports. If you have such a switch, you can install a server on that port for network monitoring, and simply run Arpwatch on it.
After downloading Arpwatch, you can compile and install it in the usual manner:
# ./configure && make && make install
When running Arpwatch on a machine with multiple interfaces, you’ll probably want to specify the interface on the command line by using the -i option:
# arpwatch -i iface
As Arpwatch begins to learn the MAC/IP address pairings on your network, you’ll see log entries similar to this:
Nov 1 00:39:08 zul arpwatch: new station 192.168.0.65 0:50:ba:85:85:ca
When a MAC/IP address pair changes, you should see something like this:
Nov 1 01:03:23 zul arpwatch: changed ethernet address 192.168.0.65 0:e0:81:3:d8:8e (0:50:ba:85:85:ca) Nov 1 01:03:23 zul arpwatch: flip flop 192.168.0.65 0:50:ba:85:85:ca (0:e0:81:3:d8:8e) Nov 1 01:03:25 zul arpwatch: flip flop 192.168.0.65 0:e0:81:3:d8:8e (0:50:ba:85:85:ca)
In this case, the initial entry is from the first fraudulent ARP response that was received, and the subsequent two are from a race condition between the fraudulent and authentic responses.
To make it easier to deal with multiple Arpwatch installs in a switched environment, you can send the log messages to a central syslogd [Hack #79], aggregating all the output into one place. However, because your machines can be manipulated by the same attacks that Arpwatch is looking for, it would be wise to use static ARP table entries [Hack #63] on your syslog server, as well as all the hosts running Arpwatch.