Tread Lightly and Backup Often
Documenting and cleaning up any firewall can seem like a very daunting task and should not to be taken lightly. Over the years, it is very likely that applications have come and gone from your organization – has anyone gone back through your firewalls and removed the access legacy services once used? Depending on the complexity of your firewall, you could have 100’s or even 1000’s of rules to evaluate. One slip up can take down one or more services that your users rely upon every day. Persistence and meticulousness are key attributes to have in these situations. Backups of your configurations are KEY.
One thing I need to be very clear on – the audit process should be a recurring event. However, all timeframes listed here should be customized to your environment. You are the best judge of knowing the appropriate frequency in which an audit should take place.
Low Hanging Fruit
One of the easiest places to start is to audit all management access to the firewall. Admin or remote access users, whether configured locally or centrally, should be carefully reviewed on a monthly basis. Better yet, it’s always a good idea to have this as part of an onboarding or termination process. HR would obviously need to provide advanced notice on all employment additions or subtractions.
Also, determine locations where management access is allowed, and make sure your security devices are properly configured. A really easy place to begin is checking for access from the public IP networks on outside facing interfaces.
Review Access Control Lists
Begin with access lists assigned to outside facing interfaces and work your way inside (i.e., from least trusted to most trusted). Glaring security holes allowing access from the Internet should be found as soon as possible so it makes sense to start there first.
Zero or Low Hit Counts
Identify disabled and access control entries (ACEs) with low or zero hit counts. Add a date to the description on the ACE to act as a reminder of when the rule was verified as disabled or with a 0/low hit count. Add add your initials so the edit is easily identifiable to others: i.e. hitcnt=0 on 1/1/19 mh.
Notify appropriate application stakeholders and purge disabled rules after giving them some time to protest rule deletion. Check on the 0 hit count rules and follow up with stakeholders in the same fashion. Give them some time to respond and then disable the rule if there is still no activity. After one more period of time, the rule can be purged permanently.
Keep in mind many firewalls process rules top to bottom, and you might have redundant rules in place. If you have a very broad rule above a more restrictive rule for the same server or application, often the more restrictive rule will never be hit and will result in a zero hit count. The solution for this is to re-order the rules so more restrictive entries go first, but still group them near each other to help keep track of them. Once this has been completed, you can then question the broader ruleset to see if they are even needed or if more digging might be required to see what ports or protocols are actually necessary for the service to run successfully.
Rules with High Hit Counts
Document all the remaining rules that have hits, incrementing or not. For non-incrementing or slowly incrementing ACEs, notate the date and hit count # in the description of the rule (or you can also reset the hit count to 0 if you prefer). Wait a period of time to see if these slowly increment. You can even log traffic hitting this rule to a syslog server so you get more detailed information like source IP address. Track these back to the server/application owners and ask if access is still needed/accurate.
For incrementing ACEs, verify that the servers for which the rule is configured is still accurate. Is it a legacy rule, but the server or IP was reused for something else and no longer hosting that service?
If the rule is accurate, document the server and applications the access is allowing. Ask the application owners if access can be limited further, perhaps on ranges of ports and/or source IP addresses? Also check with the application owner to see if there are any plans for decommission or sun setting.
If the rule is inaccurate or is a remnant of a decommissioned application, correct the rule with input from the application stakeholders or you can disable the rule entirely.
After the First Audit is Completed…
The process will get much easier going through subsequent audits, just as long as you properly document any newly added rules going forward. Don’t forget to also clean up any lingering groups or other objects that any deleted access control entries were referencing as long as they are not being used elsewhere.