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/8 prefix) - (172.16/12 prefix) - (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 ###.###.###.###
access-list 10 deny
access-list 10 deny
access-list 10 deny
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, wild-card bits (754174 matches)
30 deny, wild-card bits (727624 matches)
40 deny, wild-card bits (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, 2008
Fragment - Current Release


IT Roles and Responsibilities
On Passwords
Spending Enough
Planning to Fail
Living With the Enemy
A Reason for Policy
Mission Critical Messaging – Do you have a policy
Globalizing the SMB
High Availability: People and Processes
Case for Project Management
Risk Management

On Routing
VLAN Tutorial
IPs 4 Golden Rules
WAN Technology primer
DHCP Primer
Your Head in the Cloud(s)
DNS: Terms and Process
VPN Surfing Challenge
Network Slowdown
Importance of Time
High Availability: Technologies

Spammers Go Full Circle
Beyond the Lock
The Guardian at the Gate
A Web of Trust
Data Breach Notification

Electricity Primer
Data Control
Open Source in the Enterprise
Closing the Loop
Helping IT to help you
Your ICT Keystone

eSubnet Services

Contact us regarding your network,
security and Internet services needs

All content © eSubnet 2003-2021