Firewall Security Controls Checklist

In today’s dynamic, multi-vendor network environments, usually having tens or hundreds of firewalls running thousands of rules, a manual security audit was performed which now borders on the impossible. Firewall administrators must rely on their own experience and skills to manually perform the audit process to decide if a given firewall rule should or should not be included in the config file.

See Also: Firewall Rule Base Review and Security Checklist

In addition, it is usually lacking documentation of current rules and their evolution of changes. The time and resources required to find, organize and pour through all the firewall rules to determine compliance levels have a significant impact on IT personnel.

See Also: What are the PCI DSS Firewall and Router Configuration Requirements

As the complexity of networks grows, security controls on firewalls become more cumbersome. Unable to keep up with manual processes. Automating the process of auditing the firewall is important, because compliance must be constant, not just at a time.

See Also: Firewall Rule Configuration Best Practices For PCI Compliance

The firewall security process is arduous. Before it can be implemented, each new rule must be pre-analysed and simulated. An audit report of each adjustment must be kept complete and correct.

It’s time to look at the checklist of firewall security controls along with developing best practices for auditing to ensure continued PCI compliance.

1. Review the rulesets

Review the set of rules firewall to ensure they follow the following order:

• Anti-spoofing filters (blocked private addresses, internal addresses that come from the outside)
• User permit rules such as allowing HTTP to be used on a public web server.
• Management permit rules such as SNMP traps for network management servers
• Noise drops like discard OSPF and HSRP chatter
• Deny and Alert (Alert system administrator about suspicious traffic)
• Deny and log (log for analysis of remaining traffic)

Firewalls function on a first match basis, so the above structure is necessary to ensure that suspicious traffic is kept out, rather than enabling them unintentionally by not following the proper order.

2. Application based firewall

Ensure administrators track any attempts to break the security policy using audit logs created at the application-level firewall. Alternatively, some application level firewalls provide intrusion detection systems with the ability to log on to. In these circumstances, ensure that the application’s firewall level determines the correct host which hosts the IDS.

• Ensure that a process is in place to update the vulnerabilities of the application level firewall, checked for the most current vulnerabilities.  
• Ensure a process is in place to update the software with the latest signatures.
• In case the signatures are downloaded from the vendors’ website, make sure it’s a trusted website.
• In case the signature is sent to the system administrator via e-mail, ensure that digital signatures are used to verify the vendor and that the transmitted information has not been changed on the en-route.  

For SMTP, at the application level firewall commands below should be blocked:  

• EXPN (expand)
• VRFY (verify)
• DEBUG
• WIZARD

For FTP, commands below should be blocked:

• PUT

Review and ensure the denied URLs are suitable for blocking, for example, any URLs to malicious sites. Organizations may also want to restrict access to harmful sites in some instances. As such, they would sign up to sites which hold these harmful sites listed. Ensure the denying URLs are updated as released by the sites that warn about harmful sites.

• Ensure the application level firewall authenticates only the authorized users.  

3. Stateful inspection

Review the state tables to ensure that correct rules for source and destination IPs, source and destination ports, and timeouts are defined. Make sure the timeouts are sufficient so as not to give the attacker too much time to launch a successful attack.

For URL’s

• When using a URL filtering server, make sure the firewall application defines it appropriately. If the filtering server is outside the company make sure it is a reliable source.
• If the URL originates from a file, ensure that this file has adequate protection to ensure that no unauthorized changes are made.
• Make sure that particular traffic contains scripts; Java and ActiveX are stripped before the internal network is allowed in.
• If filtering is allowed on MAC addresses, review the filters to ensure that they are restricted to the appropriate MAC’s as defined in the security policy.  

4. Logging

• Ensure logging is enabled, and the logs are reviewed to identify any potential patterns that might indicate an attack.  

5. Patches and updates

• Make sure you are testing and installing the latest patches and updates relating to your firewall software.
• If patches and updates are downloaded automatically from the vendors’ websites, make sure the update is obtained from a trustworthy source.
• In case patches and updates are submitted to the system administrator via e-mail, ensure that digital signatures are used to verify the vendor and ensure that the information has not been altered on the path.

6. Location – DMZ

• Make sure there are two firewalls there in. One for connecting the web server to the internet and the other for connecting the web server to the phone.
• In the case of two firewalls, ensure it is of separate types and use dual NIC’s. This will improve protection as a hacker needs to know the strengths, vulnerabilities and bugs of both firewalls.
• The rulesets for both firewalls would vary from one location to another, e.g. between the web server and the internet, and between the web server and the internet.  

7. Vulnerability assessments/ Testing

• Determine whether there is a method for checking open ports using Nmap, and whether unused ports are locked. Ensure that when set up or modified, there is a process to check the collection of rules just to not establish the organization’s denial of service or to allow any vulnerabilities to remain invisible.

8. Compliance with security policies

• Make sure the ruleset is in line with the security policy of the company.

9. Spoofed, private (RFC 1918) and illegal addresses

Ensure blocking of spoofed, private (RFC 1918) and illegal addresses:

Standard unroutables

• 255.255.255.255
• 127.0.0.0

Private (RFC 1918) addresses

• 10.0.0.0 – 10.255.255.255
• 172.16.0.0 – 172.31.255.255
• 192.168.0.0  – 192.168.255.255

Reserved addresses

• 240.0.0.0

Illegal addresses

• 0.0.0.0

UDP echo

• ICMP broadcast (RFC 2644)

Ensure that the interface doesn’t relay traffic from the addresses above.

10. Loose source routing

• Ensure that the firewall blocks and logs loose source routing and the strict source routing (lsrsr & ssrr).

11. Port restrictions

The following ports should blocked outbound traffic as follows:

• Small services – TCP & UDP ports under 20
• FTP – TCP port 21
• Telnet – TCP port 23
• MS RPC – TCP & UDP port 135
• NetBIOS/IP – TCP & UDP ports 137-139
• SMB/IP – TCP port 445
• Trivial File Transfer Protocol (TFTP) – UDP port 69
• Syslog – UDP port 514
• Simple Network Management Protocol (SNMP) – UDP ports 161-162
• Internet Relay Chat (IRC) – TCP ports 6660-6669

If there is no need for an organization below ports, the outbound traffic should be blocked as follows:

• HTTP – TCP port 80
• HTTPS – TCP port 443
• DNS – UDP port 53
• SMTP – TCP port 25
• NTP – UDP port 123

12. Remote access

• When using remote access, make sure the SSH protocol (port 22) is used in place of Telnet.

13. File Transfers

• If FTP is a requirement, make sure the server, which supports FTP, is placed in a subnet other than the protected internal network or use SFTP.

14. Mail Traffic

• Find out which protocol is used to block incoming mail traffic and make sure that there is a rule, apart from internal mail.

15. ICMP (ICMP 8, 11, 3)

• Ensure a rule is in place to block requests and replies from ICMP echo.
• Ensure that there is a rule that blocks exceeded and unattainable messages from outgoing time.

16. IP Readdressing/IP Masquerading

• Ensure that the firewall rules have the readdressing option enabled, so that the external untrusted networks do not display internal IP addresses.

17. Zone Transfers

• If the firewall is stateful, provide UDP / TCP 53 packet filtering. IP packets from the Internet for UDP 53 are limited to approved internal network replies. If the packet didn’t respond to an internal DNS server request, the firewall would deny that request.
• In addition to those from approved secondary external DNS servers, the firewall also rejects IP packets for TCP 53 on the internal DNS server so as to avoid unauthorized zone transfers.

18. Egress Filtering

• Make sure there is a rule that allows only traffic originating from IP’s inside the internal network. Traffic with other than internal network IP’s should be dropped.
• Ensure all traffic that originates from IPs other than the internal network is logged.

19. Critical servers

• Ensure that there is a deny rule for traffic from external sources bound for essential internal addresses. This rule is based on the organizational requirements, as certain organizations can allow traffic to be routed via a DMZ through a web application.

20. Personal firewalls

• Ensure that users of laptops receive adequate training regarding the threats, types of elements blocked by the firewall and guidelines for personal firewall operations. This aspect is important because sometimes personal firewalls rely on user prompts to respond to attacks such as accepting / denying a request from a specific address.
• Review the personal firewall’s security settings to ensure it limits access to unique ports, defends against known threats, and provides appropriate logging and user warnings in the event of an intrusion.
• Ensure that a mechanism for upgrading the program is in place for any new threats that become documented.
• Alternatively, most devices provide the option of automated updates being transmitted over the Internet. In such cases ensure updates from trusted sites are received.

21. Distributed firewalls

• Ensure that the security policy is communicated uniformly to all hosts particularly when policy changes.
• Ensure adequate controls are in place to ensure policy integrity during the transfer, such as IPSec for policy security while in transition.
• Ensure adequate controls are in place to authenticate the host in question. Again IPSec can be used for cryptographic certificate authentication.  

22. Stealth Firewalls

• Ensure users and passwords are reset by default.
• Make sure the firewall is properly configured to know which hosts are at which interface.
• Check the access control lists for firewall to ensure that traffic is routed to the correct segments.
• A stealth firewall has no effect on the network it protects so it makes it more difficult for the hacker to determine the firewall software is being used and its variants, and to determine the network topology.  

23. ACK bit monitoring

• Ensure that ACK bit monitoring is established to ensure a remote system is unable to initiate a TCP connection, but can only respond to packets that are sent to it.

24. Continued availability of Firewalls

• Ensure the primary firewall is hot standby.

See Also: Firewall Audit Checklist

See Also: Firewall Audit Tools to Ease PCI Compliance

SANS Institute – Methodology for Firewall Reviews for PCI Compliance

SANS Institute – Firewall Checklist