Internet, Networking, & Security Home Networking Best Practices for Managing Your Network Firewall Tips to help keep you from getting burned Share Pin Email Print Lane Oatey/Blue Jean Images/Getty Images Home Networking Routers & Firewalls The Wireless Connection Network Hubs ISP Broadband Ethernet Installing & Upgrading Wi-Fi & Wireless By Andy O'Donnell Writer Andy O'Donnell, MA, is a former freelance contributor to Lifewire and a senior security engineer who is active in internet and network security. our editorial process Andy O'Donnell Updated November 15, 2018 Have you been charged with maintaining your organization's network firewall? This can be a daunting task, especially if the network protected by the firewall has a diverse community of clients, servers, and other network devices with unique communications requirements. Firewalls provide a key layer of defense for your network and are an integral part of your overall defense-in-depth network security strategy. If not managed and implemented properly, a network firewall can leave gaping holes in your security, allowing hackers and criminals in and out of your network. Know Your Network So, where do you even start in your attempt to tame this beast? If you just dive in and start messing with Access Control Lists (ACL), you could inadvertently isolate some mission-critical server which could anger your boss and get you fired. Everyone's network is different. There is no panacea or cure-all for creating a hacker-proof network firewall configuration, but there are some suggested best practices for managing your network's firewall. As every organization is unique, the following guidance may not be "best" for every situation, but at least it will provide you with a starting point for helping you get your firewall under control so you don't get burned. Form a Firewall Change Control Board Forming a firewall change control board made up of user representatives, system administrators, managers, and security staff might help facilitate dialogue between the different groups and may help to avoid conflicts, especially if proposed changes are discussed and coordinated with all whom may be affected by them prior to the change. Having each change voted on also helps ensure accountability when issues related to a specific firewall change occurs. Alert Users and Admins Prior to Firewall Rule Changes Users, administrators, and server communications may be affected by changes to your firewall. Even seemingly minor changes to firewall rules and ACLs can have major impacts on connectivity. For this reason, it is best to alert users to proposed changes to firewall rules. System administrators should be told what changes are proposed and when they are to take effect. If users or administrators have any issues with proposed firewall rule changes, ample time should be given (if possible) in order for them to voice their concerns before changes are made, unless an emergency situation occurs that requires immediate changes. Document All Rules and Use Comments to Explain the Purpose of Special Rules Trying to figure out the purpose of a firewall rule can be difficult, especially when the person who originally wrote the rule has left the organization and you are left trying to figure out who might be affected by the rule's removal. All rules should be well documented so that other administrators can understand each rule and determine if it is needed or should be removed. Comments in rules should explain: The purpose of the rule.The service that the rule is for.The users/servers/devices affected by the rule (Who is it for?).The date the rule was added and time frame that the rule is needed (i.e. Is it a temporary rule?).The name of the firewall administrator who added the rule. Avoid Use of "Any" in Firewall "Allow" Rules In Cyberoam's article regarding firewall rule best practices, they advocate avoiding the use of "Any" in "Allow" firewall rules, due to potential traffic and flow control issues. They point out that the use of "Any" may have the unintended consequence of allowing every protocol through the firewall. "Deny All" First and Then Add Exceptions Most firewalls process their rules sequentially from the top of the rules list to the bottom. The order of the rules is very important. You'll most likely want to have a "Deny All" rule as your first firewall rule. This is the most important of the rules and its placement is also crucial. Putting the "Deny All" rule in position #1 is basically saying "Keep everyone and everything out first and then we'll decide who and what we want to let in". You never want to have an "Allow All " rule as your first rule because that would defeat the purpose of having a firewall, as you have just let everyone in. Once you have your "Deny All" rule in place in position #1, you can start to add your allow rules below it to let specific traffic in and out of your network (assuming your firewall processes rules from top to bottom). Review Rules Regularly and Remove Unused Rules on a Regular Basis For both performance and security reasons, you're going to want to "spring clean" your firewall rules out periodically. The more complex and numerous your rules are, the more performance is going to be impacted. If you've got rules built for workstations and servers that aren't even in your organization anymore then you may want to remove them in order to help reduce your rules processing overhead and to help lower the total number of threat vectors. Organize Firewall Rules for Performance The order of your firewall rules can have a major impact on the throughput of your network traffic. eWEEk has a great article on best practices for organizing your firewall rules for maximizing traffic speed. One of their suggestions includes taking some of the burdens off of your firewall by filtering some unwanted traffic out via your edge routers.