If you've been around routers and firewalls for any amount of time, you're probably familiar with the concept of ingress filtering -- the application of a firewall rulebase to inbound traffic. Ingress filtering allows you to control the traffic that enters your network and restrict activity to legitimate purposes.
You might not be familiar with a similar security technique known as egress filtering, which controls the traffic headed out of your network. The addition of a few simple rules to your border router and/or firewall allows you to provide a good deal of protection against many categories of malicious activity. Two of the rules you may wish to consider implementing are:
- No outbound traffic bears a source IP address not assigned to your network. (This is the basic egress filtering rule.)
- No outbound traffic bears a private (non-routable) IP address. (This should be true anyway, but it's a good idea to block and log this type of traffic to determine the source of the error.)
As with any security control, exceptions to the standard egress filtering policy may be necessary depending upon your organization's unique needs. These rules should be used as the basic building blocks of policy and exceptions should be made as necessary for legitimate business purposes.
Why should you care about egress filtering? After all, isn't the point of a secure perimeter to prevent malicious traffic from entering the network? Quite simply,
The egress filtering rules also have analogs in the ingress filtering arena:
- No inbound traffic bears a source IP address assigned to your network.
- No inbound traffic bears a private (non-routable) IP address.
These rules seem like common sense, but they're often forgotten by firewall administrators caught up in the design of complex rulesets restricting activity by port. It will only take a few minutes to add these measures to your perimeter-protection devices and they could mean the prevention of a major headache in the event a malicious individual attempts to use your site as a launching point for a DDoS attack.
About the author
Mike Chapple, CISSP, currently serves as Chief Information Officer of the Brand Institute, a Miami-based marketing consultancy. He previously worked as an information security researcher for the U.S. National Security Agency. His publishing credits include the TICSA Training Guide from Que Publishing, the CISSP Study Guide from Sybex and the upcoming SANS GSEC Prep Guide from John Wiley. He's also the About.com Guide to Databases.
This was first published in March 2003