Section 5.2 Packet Spoofing Explained
5.2 Packet Spoofing Explained
Almost everyone has heard of packet spoofing (faking), but few SysAdmins have a good understanding of it. Packet spoofing is when a cracker sends a packet of data over a network from, say, system cracker.com that claims to be from system client.pentacorp.com to server.pentacorp.com, to gain the privileges of client.pentacorp.com that server.pentacorp.com offers. Packet spoofing works due to vulnerabilities inherent in the (poor) design of the underlying protocols such as UDP, TCP, ICMP, and routing protocols and algorithms. The vulnerability is not due to a bug in the Linux kernel or application software. Understand that these protocols were written more than 20 years ago when the Internet was a smaller, friendlier, and safer place than it is today.
Each packet has a source address containing the IP address and port number that the packet claims to come from and the destination address where it wants to be sent to. The problem is that the sending system gets to create the packet, so it can lie about its own source address. This lie can be hard to detect, so how can you protect against it? Modern firewalls (including the IP firewall facilities in the Linux kernel) and some routers can be configured to know what range of IP addresses should be from the "inside" and expect all other IP addresses to be from the "outside." When such a firewall sees a packet with an inside source address coming from outside, it knows that it is a spoofed packet and will drop it. This is the purpose of ipchain's -i or --interface parameter. This parameter enables a system administrator to specify which interface (for example, which Ethernet card, ppp, or T1 interface) packets with a particular source address are accepted from.
SysAdmins should also configure their firewalls to look for bogus packets with outside source addresses coming from the inside and both drop them and record their MAC addresses (Ethernet addresses). These packets are caused by either someone inside the firewall with a misconfigured system or someone inside the firewall who is up to no good. Interlopers outside your organization trying to spoof packets that appear to come from IP addresses inside your organization might be blocked easily with a single command, as discussed in "Blocking IP Spoofing" on page 134. "Firewalls with IP Chains and DMZ" on page 514 should also be consulted. These techniques will not protect against attacks on sessions with one end outside your organization; secure encrypted communication solves this problem. Hopefully, most ISPs and large organizations are doing this filtering of packets originating from inside their organizations. This will reduce the pool of systems that can be compromised by crackers to make others on the Internet miserable. Preventing your systems from being compromised and thus used to attack third parties makes for good citizens. Eventually, the legal profession could be attracted to this problem. Organizations that fail to take reasonable steps to prevent their systems from being compromised and are used to attack other sites might get sued successfully. See also "Blocking IP Source Routing" on page 133 and "Blocking IP Spoofing" on page 134. To summarize, draw your network, including your connection to the Internet. Draw a circle around each segment that can be protected by a firewall or router that can filter packets by address, including intracompany firewalls. At each boundary, for example, a firewall, write down the ranges of IP addresses allowed to originate from each side. Consider subnetting and proxy servers. Try to be as specific as possible. Do your firewalls enforce these rules? Refer to "Network Topology Policy" on page 349. A single Linux system with multiple network cards can serve as a firewall and router, protecting various parts of a company from the Internet and from breaches of any other part. This is illustrated in Figure 5.1. Figure 5.1. Multiple subnet firewall/router.
As you can see in Figure 5.1, a single Linux box costing $500 or less can do the work of quite a bit of proprietary equipment. Larger organizations might need to have multiple firewalls and a separate router. This configuration is illustrated in Figure 5.2. Figure 5.2. Multiple firewalls and router.
As you can see in Figure 5.2, Linux firewalls can be "dropped in" wherever firewalls are needed. 5.2.1 Why UDP Packet Spoofing Is Successful
The capability of detecting spoofed UDP packets is limited to a firewall detecting whether a packet with a particular source address should have come from either an inside or outside system and dropping those packets that violate this. Consider: You have a remote location that reaches your main location via the Internet and that remote location wants to use UDP across the Internet to your main site. Maybe the application is NFS[2] or perhaps a custom application.
How can your firewall or application know if the packet is spoofed? It cannot. Because your firewall knows that your remote location is outside, it will accept the packet (if you want to run this application) but a valid packet is indistinguishable from a spoofed packet. This is why UDP is considered insecure and it is a major reason NFS is considered insecure, because usually NFS uses only UDP. All your carefully set up access controls where, for example, you configure NFS's /etc/exports file to allow only certain hosts to connect (or where your custom application has a similar configuration file) get defeated, because all these are based on the packet's source address field and this is what gets faked. Of course your server, be it NFS or something else, will send its response to the source address specified in fake client's packet and the real client system, which is the cracker's system, will not see the reply (unless he is able to sniff your network). This usually is not a problem because most applications that run on top of UDP implement a simple protocol on top of it where usually the client sends a request and the server replies with either "ok", an error message, or data in response to a query. Usually, the cracker can do lots of damage without receiving the responses. Using NFS, he can send the request rm /etc/init and your system will fail to reboot the next time you try. The cracker does not care that he did not receive the "ok" acknowledgment. He could write a new /etc/passwd file containing the root password of his choice, use NFS to write it to your server's file system, and then he "owns" the system. The use of proper permissions and the root_squash option in /etc/exports will guard against the most severe problems. The root_squash option causes remote users claiming to have UID 0, root, to be treated as the user nobody instead. It is the default NFS server behavior. The root_ squash option will not make NFS secure, however. All that a cracker needs to do is to exploit a vulnerability that does not require root privilege. One "easy win" is to take advantage of the fact that many people have their $PATH environment variable misconfigured to list "." before system directories, as discussed in "$PATH: Values of . Give Rise to Doom" on page 132. All a cracker needs to do is to spoof a NFS source address and place a fake version of a common utility program such as ls or pwd in /tmp and wait for root to issue one of the commands while in the /tmp directory. The following command will list network services that use UDP that might be running on your system, except those that do not have a symbolic name in /etc/services: grep udp /etc/services A more effective solution is to use the ports program or the netstat program, both discussed in "Turn Off Unneeded Services" on page 86. They determine which port numbers are actually in use on your system. Those that want to write their own programs to analyze open ports will want their programs to read the /proc/net/udp and /proc/net/tcp pseudo files. The local_address and rem_address are the local and remote address fields. The portion before each colon ":" is the IP address, and the portion following it is the port number. Both are in hexadecimal. 5.2.2 TCP Sequence Spoofing Explained
One of the ways that TCP differs from UDP is that TCP has an acknowledgment/retry algorithm so that a sender knows that each packet has been received and dropped packets are detected due to the missing acknowledgment packet and resent (the retry algorithm). As part of this algorithm there are sequence numbers built into the protocol to ensure that packets arrive surprise in sequence and that there are no packets in the sequence missing. In order to spoof TCP packets, the one spoofing must either know the sequence numbering scheme or else must guess it. Until recently, nobody had much concern or notion of spoofing and so the sequence numbering was predictable, though it varied between different operating systems. (Some cracker programs even determine a box's operating system from the sequence numbering.) The way a TCP connection is established is that the client will send a TCP SYN message, which is a TCP packet with the SYN bit in the header turned on (set to 1). The client includes in this message its "initial sequence number," a somewhat arbitrary number to track packet sequences. The server responds with a SYN/ACK message (SYN and ACK bits on) and will include the server's initial sequence number. Old systems would supply an initial sequence number X for the Nth connection, X + 64000 for the N + 1th connection, etc. The client finally sends an ACK message. At this point, each side may start sending data. After each side sends Y bytes of data, it must boost its sequence number by Y. Note that three packets have been sent, hence the three-way ACK to initiate a connection. As you recall from "Why UDP Packet Spoofing Is Successful" on page 242, it is trivial to fake the source address of a packet. The only reason it is hard to fake your source address for a TCP connection is that the client needs to know the server's initial sequence number or guess it. If the client uses a fake source address, the server's SYN/ACK response, which contains the precious initial sequence number, is sent to the fake source address, and the cracker will never see it. Recent versions of Linux use a hard-to-predict sequence numbering scheme to resist spoofing. See "Defeating TCP Sequence Spoofing" on page 246 for details on appropriate kernel versions. Since the sequence number is a 16-bit quantity, an attacker has one chance in 65536 of guessing it. Over a long period of time, an attacker could guess correctly if not detected. This is a good reason not to trust the IP address alone to maintain security when high security is important. To this end, a firewall should be used to block packets coming in from the Internet (or other less trusted parts of a large network) that purport to be from an system inside the firewall. Additionally, only ssh originating from outside the firewall should be allowed to come in beyond the Demilitarized Zone where mail and HTTP servers should reside. For more details, see "Build Separate Castles" on page 285. Still, a firewall or TCP Wrappers will filter out the vast majority of crackers trying to get in. 5.2.3 Session Hijacking
It is important to note that if a cracker can sniff your traffic, he can determine what the next sequence number of an ongoing connection for either side of an open connection will be. If he has access either to the server's network or to the client's network, this sniffing is trivial. He then can "inject" a packet of his own. For example, if there is an open and active telnet session, perhaps a SysAdmin logged in as root from his home system, a cracker could inject a packet that issues a command to the shell to insert a Trojan horse. A session hijacking like this will not last long before the two legitimate systems get confused and shut the session down. This also offers a DoS attack for this reason. However, because a single packet can insert a root Trojan into a telnet session where root is involved, this is dangerous. Similarly, a Web session can be hijacked to alter data during e-commerce. The solution in all of these cases is to use strong encryption, such as SSH, SSL, or a VPN product, such as FreeS/WAN. They will prevent both sniffing and session hijacking. These are discussed in "Protecting User Sessions with SSH" on page 409, "Downloading SSL" on page 745, and "VPN Using FreeS/WAN IPSec" on page 428. |
| Top |
EAN: N/A
Pages: 260