Before we begin exploring best practices, it is important to note that these recommendations are geared toward large organizations and government agencies and would not likely be appropriate for a home network or very small business network. For example, in a small business or home network, the firewalls and routers might be collapsed into one device. This post will primarily focus on larger, enterprise networks where the Internet router and firewall are broken out into distinct devices, as shown in the figure below
It is also important to note that this post will primarily focus on filtering of inbound traffic. Filtering of outbound traffic is also very important for organizations and will be the subject of a future post.
Let Your Routers Route
The philosophy of many network administrators is let your routers route. In a larger network with specialized devices, you want to let the Internet router do its primary job, which is to pass traffic. Having said that, there are exceptions where traffic/security issues will require some basic blocking on the Internet router. Here are some principles to keep in mind:
Don't add an access control list (ACL) entry for every suspicious IP address. I once worked for an organization that would add an ACL entry to the Internet router every time it saw an attempt from outside to do something suspicious, even if that attempt was blocked by the firewall.
The problem with this approach is that it creates a massive ACL. The Internet router now has to process every entry in the ACL when filtering traffic. This approach also makes it hard for people who manage the ACL, because network administrators must determine why a particular entry was added to the ACL, and whether that entry is still needed. Additionally, for devices that process an ACL in order from top to bottom, a longer and more complicated ACL makes it harder to be sure you've placed new entries in exactly the right place.
Protect the devices inside the border router and outside the firewall, and the outside interface of the firewall. People often forget that there are vulnerable devices sitting outside the firewall, including the Internet router itself. There is usually no reason for someone outside your network to access the devices outside your firewall. It is important to have filters on the router to prevent unauthorized users from being able to log in to the router, or to send management traffic to the router.
For devices between the Internet router and the firewall (like the switch in the diagram above), the easiest way to prevent access from the outside is to use non-routed RFC 1918 address space. A device with private addressing can't be reached directly from the Internet. That said, if you're protecting a network that already has public, registered addresses on internal network equipment (it happens), it's absolutely critical that you create ACL entries on your Internet router preventing access from the outside to your network equipment addresses. Remember to include the firewall's outside interface (if using public addressing on it) as well. If, for some reason, access to these devices is needed from the outside, you should permit only the specific source IP address and protocol needed.
Out-of-band (OOB) management offers another option for reaching your border router, or other network equipment, from the outside. If you are using an external company to monitor your infrastructure, the external company should be able to provide you specific IP addresses and protocols. You can allow those and block everything else.
Filter the bogons. The bogons list represents an entire class of private and reserved IP addresses.
According to Team Cymru, which maintains the most up-to-date list of bogons, "a bogon prefix is a route that should never appear in the Internet routing table. A packet routed over the public Internet (not including over VPNs or other tunnels) should never have a source address in a bogon range. These are commonly found as the source addresses of DDoS attacks."
While we don't want to make the Internet router act as a firewall, the bogons list represents a simple way to eliminate obviously bad traffic at your network border, without the need for deep inspection, checking state tables, or complicated ACL entries.
If you're filtering bogons, however, it's important that you keep your filters up to date. The bogons list can change as previously unallocated IP addresses are allocated by the Regional Internet Registries (RIRs).
Block inbound traffic sourced from your own IP addresses. At the Internet router, it is important to block any external traffic that is sourced from an internal IP address. For example, if you have your own allocated block of addresses, you should not see external traffic sourced from one of your internal addresses. If you see traffic sourced from your own internal IP space trying to enter your network from the Internet, it suggests either that someone is spoofing your addresses to try to do you harm or a routing problem has occurred. It is important to block this type of traffic at the Internet router because it is very possible that traffic allegedly sourced from your internal IP space is only subject to limited filtering once it gets to your internal network.
In summary, when considering filtering at the Internet router level
Don't mess with intricate filtering systems to block every suspicious IP address.
Focus on blocking bogons and anyone trying to spoof your IP addresses.
Protect the Internet router from outside traffic, and protect anything that sits between the router and the firewall.
Let Firewalls Be Firewalls
At the firewall level, your approach to filtering should be more fine-grained. As with your border router, first and foremost it is important to lock down access to the firewall itself. Unauthorized users should not have access to this device.
In addition, there are two principles for filtering at the firewall level:
Default deny. A firewall is a security device and is designed to protect your assets. Your default position when configuring the firewall should therefore be to deny traffic. Don't think of the firewall as the device that permits all traffic through, except for the things you want to block. Instead, think of your firewall as the device that blocks all traffic, except for those things you choose to permit.
Label everything. With firewall filtering, it is important to assume that someday a new firewall administrator will have to figure out what you did and why. I have seen incredibly complex firewall rule bases that were hard to understand because the logic and reasoning behind them were unclear (e.g., IP addresses in rules with no indication of what devices the IP addresses represented, with no labeling to tell you why the traffic was being permitted or denied). When it comes to firewall filtering, every new rule should take into account that a future firewall administrator must one day read these rules and understand them.
When you are creating new rules to permit inbound traffic, try to be as specific as possible. For example, if you know a particular server requires inbound traffic on just three TCP ports, don't create a rule permitting all inbound TCP to that server--create a rule allowing only the needed ports. While it may be easier to make the rule less specific "in case we need to permit more ports later on," this opens up that server to all sorts of traffic that it shouldn't be receiving, including malicious traffic designed to exploit vulnerabilities on all those TCP ports you left open.
Sometimes when a new server or application is being brought online, I've seen people say "We aren't sure which protocols are needed--just permit everything for now and we'll lock it down when we know exactly what we need to permit through." In my experience, that later lock down never happens. Think carefully about whether you want to put a device on your network without knowing exactly which protocols it's supposed to be using, and then allow traffic on any protocol to reach it.
At the same time, while you're being as specific as possible with your rule set, there are best practices you can use to make it easier on yourself. If you create an object group in your firewall to include the IP addresses of all devices of the same type, with the same security requirements (e.g., all your web servers or all your email servers), you can create a single rule permitting all the specific ports and protocols needed to the entire group of servers at once.
Similarly, if there's a particular service on your network that you need to permit a known set of external IP addresses or networks to access, you can create an object representing all of those external addresses and networks, and then create a single rule allowing those external devices access to the needed service. Remember the rule about letting future firewall administrators understand what you did and why you did it? Label that object so it's clearly understood what those addresses represent (e.g., "External B2B Partners" or "Remote Office Admins"). Moreover, if you are able to add comments to your rules, add a comment that explains what the rule is for, and whether there is an expiration date for that rule.
Finally, it is important for the firewall administrator to conduct a regular--at the very least annual--audit of firewall rules. Ideally, you would have the documentation and rule change requests in one file to ensure an easier audit. Rule requesters should be asked to verify that the rule they requested is still required, and unneeded rules should be removed.
To recap, when it comes to firewall filtering, it is important to
Ensure that your default position is to deny traffic, not to permit it.
Label everything as specifically as possible.
Conduct regular audits.
By taking a layered approach to network border filtering, you can block the most obviously bogus or potentially harmful traffic at your Internet router, while allowing the firewall to do what it's designed to do, and inspect and block the remaining threats.
Wrapping Up and Looking Ahead
As attacks become more sophisticated, our team of network analysts at CERT increasingly finds Internet-facing services that aren't well deployed within a network. As Mark Langston wrote in his recent post on DNS Best Practices, many of these services make up the foundation for the security and operation of internal and external network applications.
This article is the latest in a series of blog posts offering best practices for these foundational structures. The series is intended to help government agencies and other enterprises address hidden sources of vulnerabilities within their networks. I published the first post in this series, Distributed Denial of Service Attacks: Four Best Practices for Prevention and Response. Mark Langston followed up with Six Best Practices for Securing a Robust Domain Name System (DNS) Infrastructure, and Timur Snoke wrote a post detailing Best Practices for NTP Services in March.
No comments:
Post a Comment