Posted on by Cyber Missionsin
By Rachel Kartch
Analysis Team Lead
When it comes to network traffic, it's important to establish a filtering process that identifies and blocks potential cyberattacks, such as worms spreading ransomware and intruders exploiting vulnerabilities, while permitting the flow of legitimate traffic. In this post, the latest in a series on best practices for network security, I explore best practices for network border protection at the Internet router and firewall.
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:
In summary, when considering filtering at the Internet router level
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:
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
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.
We welcome your feedback and suggestions for future topics regarding best practices for network security in the comments section below.
Read Mark Langston's blog post Six Best Practices for Securing a Robust Domain Name System (DNS) Infrastructure.
Read Rachel Kartch's blog post Distributed Denial of Service Attacks: Four Best Practices for Prevention and Response.
Read Timur Snoke's blog post Best Practices for NTP Services.