The Internet is now the world's most popular network and it is full of potential vulnerabilities. In this series of articles, we explore the vulnerabilities of the Internet and what you can do to mitigate them.
The Internet Protocol (IP) (RFC791) provides for two and only two functions. It defines a datagram that can be routed through the Internet, and it provides a means for fragmenting datagrams into packets and reassembling packets into the original datagrams. To quote from RFC791:
Here's a description of an IP datagram, also from RFC791:
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| IHL |Type of Service| Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options | Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | \ \ \ \ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Description of an IP Datagram
Note that the 4th line of the description calls for the Source Address of the datagram. In the simplest form of IP address forgery, the forger only needs to create a packet containing a false Source Address and insert it into the Internet by writing it into the output device used to send information to the rest of the Internet. For the non-expert forger, there is a tool called iptest which is part of the free and publicly available ipfilter security package that automatically forges packets for the purpose of testing configurations or routers and other IP security setups.
The infrastructure of the Internet consists primarily of a set of gateway computers and packet routers. These systems have multiple hardware interfaces. They maintain routing tables to let them decide which output interface to send a packet out on based on the input interface that it came in on and the destination IP address specified in the packet. When a forged packet arrives at an infrastructure element, that element will faithfully route the packet toward the destination address, exactly as it would a legitimate packet.
At its root, IP address forgery is a method of deception, and thus it can be used in much the same way as other forms of deception. Dunnigan95 More specifically, and using Dunnigan and Nofi's classification scheme, here are some quick ideas about how IP address forgery might be used:
Another way to view this issue is in terms of the net effect on information in information systems. Here is another way of viewing this issue with an example from each category.
These are only some of the examples of what forged IP addresses can do. Without a lot of effort, many other examples can be created.
As individuals, there is little we can do to eliminate all IP address forgery, but as a community, we can be very effective. Here's how. Instead of having all infrastructure elements route all packets, each infrastructure element could, and should, enforce a simple rule. They should only route packets from sources that could legitimately come from the interface the packet arrives on.
This may sound complicated, but it really isn't. In fact, the technology to do this is already in place, and always has been. Virtually every router and gateway in existence today allows for the filtering of packets based on their input interface and IP source and destination address. This is a necessary component of their operation and is the basis for the way they route all packets.
The only change that has to be made is for these routers and gateways to enforce the network structure that is legitimately in place. Or in other words, the routers and gateways should refuse to route ridiculous packets. Here are some of the simpler examples of known bad packets:
The next step in eliminating IP address forgery is for the routers and gateways at each type of infrastructure element to enforce standards on each interface. Generally, the Internet is broken up into Backbone providers that provide wide area packet transport services, Private Networks which are owned and operated by companies, institutions, government agencies, and other parties for their own purposes, and Internet Service Providers (ISPs) that provide connections between the backbone elements and private networks (sometimes including other ISPs). These roles can be blurred at times, but they are adequate for our purposes.
As an aide to the less technically inclined, the following examples provide some real world implementation details.
This set of rules applies to a private network (in this case, the all.net class C network 204.7.229.*) and are written in the format of the Morningstar PPP (point to point protocol) Filter file:
# Rule 1 for private networks # prevent known-bad address ranges from entering (or leaving) !172.16-32.0.0 # private network segment !192.168.0.0 # private network segment !10.0.0.0 # private network segment !127.0.0.0 # localhost network # Rule 2 for private networks # prevent internal source address packets from passing inward !recv/src/22.214.171.124 # prevent inbound from our network # Rule 5 for private networks # prevent internal destination addresses from passing outward # Note that rule 5 is placed here because the filters are order dependent !send/dst/126.96.36.199 # prevent our destinations from passing out # Rule 3 for private networks # prevent external source address packets from passing outward send/src/188.8.131.52 # allow legitimate outbound sources !send/src/0.0.0.0 # prevent illegitimate outbound sources # Rule 4 for private networks # prevent external destinations from passing inward recv/dst/184.108.40.206 # allow legitimate inbound destinations !recv/dst/0.0.0.0 # prevent illegitimate inbound destinations
The next set of rules applies to an ISP. In this case, we assume that the ISP has control over three class B networks that it uses to sell services to its clients. The class B networks used in this example have IP addresses of 123.7.*.*, 231.6.*.*, and 201.96.*.*. In this case, we have three different parts of the example:
This is the router connecting the ISP to the backbone, presented in the format of a Cisco router with interface 0 connected to the backbone and interface 1 connected to the ISP's internal network. It implements rules 1, 4, and 5 for the ISP.
# Rule 1 for an ISP # prevent all of the known-bad address ranges # this should be done on all in and out connections # on all interfaces in all access control lists All interfaces in and out deny ip 172.16-32.0.0 # private network segment deny ip 192.168.0.0 # private network segment deny ip 10.0.0.0 # private network segment deny ip 127.0.0.0 # localhost network # Rule 2 for an ISP # prevent inbound from client not in client's address range # DONE ELSEWHERE # Rule 3 for an ISP # prevent entry of packets not destined clients from passing their way # DONE ELSEWHERE # Rule 4 for an ISP # prevent exit of packets not from our class Bs # on interface 0 (backbone) out filter Interface 0 out permit ip 220.127.116.11 permit ip 18.104.22.168 permit ip 22.214.171.124 deny ip 0.0.0.0 # Rule 5 for an ISP # prevent entry of packets not destined for our class Bs. # on interface 0 (backbone) in filter Interface 0 in permit ip 126.96.36.199 permit ip 188.8.131.52 permit ip 184.108.40.206 deny ip 0.0.0.0
Next, we implement rules 2 and 3 for each client by creating separate (in this example ppp) filters on the ISP's gateway computer. Again, using the Morningstar ppp Filter format and assuming that Class C IP network 201.96.1.* is assigned to this particular client:
# Rule 1 for ISPs # prevent known-bad address ranges from entering (or leaving) !172.16-32.0.0 # private network segment !192.168.0.0 # private network segment !10.0.0.0 # private network segment !127.0.0.0 # localhost network # Rule 6 for an ISP # prevent inbound traffic from the client destined for the client # note that rule 6 is placed here because filters are order dependent !recv/dest/220.127.116.11 # prevent inbound from client to self # Rule 7 for an ISP # prevent outbound traffic to the client claimed to be from the client # note that rule 7 is placed here because filters are order dependent !send/src/18.104.22.168 # prevent outbound to client from client # Rule 2 for an ISP # prevent inbound from client not in client's address range recv/src/22.214.171.124 # allow legitimate traffic !recv/src/0.0.0.0 # prevent all other traffic # Rule 3 for an ISP # prevent entry of packets not destined clients from passing their way send/dest/126.96.36.199 # allow legitimate traffic !send/dest/0.0.0.0 # prevent all other traffic
Note that redundant protection is provided in several ways. The ISP protects the clients from backbone forgery both at the backbone router and at the client's ppp connection, and protects the backbone from IP forgery emanating from the ISP both by preventing forgery from clients and by preventing forgery from within the ISP. Similarly, the ISP provides redundant protection against improperly configured client hardware and software. The last two filter rules are to assure that even if the client is not properly configured to prevent forgery of internal addresses from the outside world or to prevent internal traffic from being sent out, this traffic is prevented.
This last example is a simplification of a wide area backbone network in which this particular router (no type specified) is at the junction between UK connections and non-UK connections. In this case, it is a reasonable assumption that all internal UK traffic should remain internal and that external traffic that gets to this node should be sent out of the UK never to return. This particular backbone node will be connected to non-UK traffic on interface 0, our previously described ISP on interface 1, and the rest of the internal UK backbone on interface 2.
# Rule 1 for a backbone # prevent all of the known-bad packets from crossing all-interfaces prevent in/out 172.16-32.0.0 # private network segment all-interfaces prevent in/out 192.168.0.0 # private network segment all-interfaces prevent in/out 10.0.0.0 # private network segment all-interfaces prevent in/out 127.0.0.0 # localhost network # Rule 2 for a backbone # prevent packets originating from any ISP with non-ISP source address interface-1 allow in from 188.8.131.52 # ISP traffic interface-1 allow in from 184.108.40.206 # ISP traffic interface-1 allow in from 220.127.116.11 # ISP traffic interface-1 prevent in from 0.0.0.0 # no other inbound traffic # Rule 3 for a backbone # prevent packets not destined for an ISP from going there interface-1 allow out to 18.104.22.168 # ISP traffic interface-1 allow out to 22.214.171.124 # ISP traffic interface-1 allow out to 126.96.36.199 # ISP traffic interface-1 prevent out to 0.0.0.0 # no other outbound traffic # Rule 4 for a backbone # prevent packets from other backbones that shouldn't come this way interface-0 allow in to UK-1 # UK traffic interface-0 allow in to UK-2 # UK traffic ... interface-0 allow in to UK-n # UK traffic interface-0 prevent in to 0.0.0.0 # no other inbound traffic # Rule 5 for a backbone # prevent packets that should stay in our backbone from going out interface-0 allow out from UK-1 # UK traffic interface-0 allow out from UK-2 # UK traffic ... interface-0 allow out from UK-n # UK traffic interface-0 prevent out from 0.0.0.0 # no other outbound traffic
In this example, we have assumed that all UK traffic is on IP addresses identified as UK-1, ..., UKn.
This solution we presented:
All that remains is for the people in each of these organizations to implement these protections. Unlike so many of the problems in the Internet that are hard to solve and will require years of evolution, this problem can be solved now. We encourage you to implement these protections at your earliest convenience and to urge other to do so as well. Together, we can eliminate IP address forgery.