Firewall Rule-Set and Configuration Review - Sukesh Shetty (@daemon_user) 

Today’s takeaway from the session ❖ Firewall Basics ❖ Benefits of Firewall Audit ❖ Firewall Configuration Review ❖ Firewall Rule-Set Review 

Firewall Basics 

Firewall Basics ▪ A firewall is a network security device that monitors incoming and outgoing network traffic and decides whether to allow or block specific traffic based on a defined set of security rules. ▪ A firewall can be hardware, software, or both. ▪ Based on the principles of least privilege and need to know. ▪ Firewalls operate on a first match basis. ▪ Examples: Cisco ASA, Checkpoint, Fortinet, Palo-Alto, etc. 

Benefits of Firewall Audit 

Benefits of Firewall Audit ▪ Firewall hardening ▪ Discover and remove unused rules and objects ▪ Identify and remove shadowed, duplicate, and expired rules ▪ Reorder rules for optimal firewall performance while retaining policy logic ▪ Tighten overly permissive rules based on actual usage patterns 

Firewall Configuration Review 

Firewall Configuration Review Pre-requisite: ▪ Firewall configuration dump or get the firewall console access with the help of firewall admin. Below are the points that need to be checked for firewall configuration: ▪ Check if NTP server IP has been configured ▪ Check if logs are sent to centralized logging server ▪ Check if firewall firmware is updated to latest version ▪ Check if SNMP service (v3) is configured with strong community string 

Firewall Configuration Review (contd.) ▪ Check for default admin and guest account ▪ Check if Authentication, Authorization and Accounting (AAA) is implemented for user management ▪ If AAA is not implemented, check if password policy is defined as complex ▪ Check the security controls for the internal resources to which access is provided for users connecting over VPN ▪ Verify that VPN encryption uses strong algorithms (AES etc.) ▪ Check if High Availability (HA) is enabled ▪ Check for session timeout (Console Timeout, Inactivity Timeout) ▪ Check for default “deny-all” setting is configured –To be checked during rule- set review 

Firewall Rule-Set Review 

Firewall Rule-Set Review Pre-requisite: ▪ Network diagram and asset inventory in scope ▪ Firewall rule-set dump or get the firewall console access with the help of firewall admin. Below are the points that need to be checked for firewall rule-set: ❖ Insecure access rules ❖ Critical port access rules ❖ Redundant rules ❖ Inactive rules ❖ Shadow rules ❖ Grouping (Source, destination, Service) ❖ Unused rules ❖ Unused Objects ❖ Large Subnets rules ❖ Logged rules 

Insecure Access Rules ▪ An insecure access rule has “Any” defined in its source, destination, or service. ▪ Also, these are the rules where UAT to PRD, DEV to PRD & vice-versa are defined which can be analyzed based on the network diagram review ▪ Consider the following example: Impact: An insecure access rule is considered as an error as it permits traffic coming from any source, destination, or service inside the firewall and putting the network security at risk. 

Redundant Rules ▪ A redundant rule means one rule is like another rule as both the rules are having same source, destination, service, and action. ▪ Consider the following example: Impact: Redundancy is considered as an error because a redundant rule may not contribute in making the filtering decision. However, adding to the size of the filtering table, and might increase the search time and space requirements. 

Shadow Rules ▪ One rule shadows another rule if both the rules have either same source, destination, and service or one rule is subset of the other rule. However, one rule permits the traffic, whereas the other rule denies the same traffic. ▪ Consider the following example: Impact: These rules are often implemented to handle some emergency or critical worm infection. They are found to be completely in contradiction to an already existing rule.The end-result depends on the sequence of the 2 rules. 

Unused Rules ▪ As networks are dynamic, systems come and go. But firewall rules tend to remain forever. Child rules are the rules defined after the parent rule. Child rules are either subset or like the parent rule, so the child rules are never hit. Apart, from child rules, there are rules which are created for temporary/testing purpose. ▪ Consider the following example: Impact: Unused rules don’t get processed, but they consume the size of the filtering table, and might increase the search time and space requirements. 

Large Subnets Rules ▪ If a rule is defined with the source and/or destination elements having large subnets (anything with more than or equal to 255 hosts), and/or service element having more than the number of ports defined in the audit policy, this is considered as an insecure rule. ▪ Consider the following example: Impact: Such rules increase the surface area of exposure by allowing a wider range of IP addresses to communicate over a wider range of port numbers. 

Critical Port Access Rules ▪ Critical ports access rules are the ones which are defined based on service containing either any, all, ftp, telnet, also administrative access port such as TCP port 22 (for SSH), TCP port 3389 (for RDP), database ports such as TCP port 1433 (for Microsoft SQL Server), etc. ▪ Consider the following example: Impact: Rules that allow traffic to critical ports need to be scrutinized as they might create a security risk by opening access that ideally should not exist. 

Inactive Rules ▪ An inactive rules are the ones which are having status as “Disabled” and are therefore not in use. ▪ Consider the following example: Impact: The rules which are not in use are inactive rules and hence don’t get processed. But they consume firewall objects count and should ideally be deleted if no longer required. 

Grouping (Source, Destination, Service) Rules ▪ Two rules can be grouped only when the actions of these rules are same and any one element among source, destination and service differs between those two rules and remaining all are same. ▪ Consider the following example: Impact: The existence of similar kind of rules may not lead to the full optimization of the rules as it unnecessarily increase processing time and increase traffic latency. 

Unused Objects Rules ▪ Unused objects, such as hosts, host groups, services, service groups, interfaces, and zones which are not used by the firewall. ▪ Consider the following example: Impact: Firewall rule bases tend to become large and complicated. They often include rules that are either partially or completely unused, expired or shadowed. 

Logged Rules ▪ If the log option is disabled, then information about the traffic processed by these rules is not included in the firewall logs. ▪ Consider the following example: Impact: If the firewall rules are not logged then traffic processed via these rules does not get logged. Post-incident forensics often depends on being able to see what traffic flowed through the impacted network segment when the breach happened. 

THANK YOU! Questions - [email protected]