The Guardian at the Gate
Not every Internet-sourced packet destined for your servers needs to be inspected by your fi rewall. By blocking packets that shouldn’t be there in the fi rst place, you can save both resources and log space by intelligently reducing the number of packets you are inspecting, and thereby effectively protect against packet-layer attacks.
Which packets are safe to block?
With Internet Protocol (IP), the basic communication method on the Internet, every packet which travels on the network contains 2 addresses; the destination address (where it is going) and the source address (where it is from). Every Internet Protocol (IP) packet is structured like this. The source IP address is what we are concerned with for the purposes of this article.
There are four source network address ranges which should never, ever, enter the outside interface of your router. These are ranges internal to the network or used for private networks.
The first is the address range of the network which is attached to the inside interface of the router. This may seem obvious and while blocking inbound packets that appear to be sent from this range may seem a daunting task, it is not as diffi cult as it seems. You can easily stop ‘spoofi ng’. ‘Spoofi ng’, the act of replacing legitimate information with misleading information, has been around for years in many formats, the most popular target has recently been email.
The three other ranges are those that have been set aside for ‘internal’ use. There is a technical document discussing these, “Address Allocation for Private Internets (RFC 1918). The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private internets and networks:
10.0.0.0 - 10.255.255.255 (10/8 prefix)
172.16.0.0 - 172.31.255.255 (172.16/12 prefix)
192.168.0.0 - 192.168.255.255 (192.168/16 prefi x)
These can be spoofed as well.
In the example provided below I am using a Cisco router Access-List to stop packets within the RFC-1918 address space. The second line after the remark statement is where your site specific IP address range goes:
access-list 10 remark RFC1918 and inside - deny list
access-list 10 deny ###.###.###.### 0.0.0.128
access-list 10 deny 192.168.0.0 0.0.255.255
access-list 10 deny 172.16.0.0 0.15.255.255
access-list 10 deny 10.0.0.0 0.255.255.255
access-list 10 permit any
Use the “show access-list” command to see how many times or ‘hits’ the access-list has blocked packets. Here is a real example from a router which has been up and running for just over a year:
Standard IP access list 10
10 deny ###.###.###.### (1013 matches)
20 deny 192.168.0.0, wild-card bits 0.0.0.255 (754174 matches)
30 deny 172.16.0.0, wild-card bits 0.15.255.255 (727624 matches)
40 deny 10.0.0.0, wild-card bits 0.255.255.255 (779295 matches)
50 permit any (1331736505 matches)
Line 10, which I sanitized with hash marks, shows the network which is directly connected to the inside interface.
Lines 20 through 40 show the results for packets which are reserved for the private network -- seven hundred thousand seems to be pretty high, don’t you think?
Why do they spoof?
The main reason for IP address spoofi ng is malicious behaviour, for example ‘smurf’ attacks. A decade ago smurf attacks were all the rage with the ‘Denial-of-Service’ (DoS) crowd. These days, they prefer using BOT-nets.
For 10 years we have not seen smurf or other packet-layer DoS attacks. We will see them return, if attention to network confi gurations is not maintained to disallow this kind of behaviour. As always, if a weakness is found, it will be exploited.
“no ip directed-broadcast”
Another tool in the fi ght against smurf attacks is the “no ip directedbroadcast” command. This command disallows packets destined for a known broadcast address from passing through the router. The very last IP address in a network range is the broadcast address, and is equivalent to “all hosts”. Given access to the broadcast address someone can create so much traffic they can bring down your network.
With a better understanding of IP source and destination addressing, and by utilizing these tools, you can reduce the traffi c that would normally require further inspection, thereby safely reducing the resources necessary to protect your networks.
Originally published July, 2008Fragment - Current Release