«SANS Institute Security Consensus Operational Readiness Evaluation This checklist is from the SCORE Checklist Project. Reposting is not permited ...»
Interested in learning more
about network auditing?
Security Consensus Operational Readiness Evaluation
This checklist is from the SCORE Checklist Project. Reposting is not permited without express, written permission.
Copyright SANS Institute
Author Retains Full Rights
Prepared by: Krishni Naidu
Top Ten Blocking Recommendations Using Cisco ACL’s Securing the Perimeter with Cisco IOS 12 Routers, Scott Winters, August 2000 GIAC Firewall Practical: Implementation of Firewall Filters, Rick Thompson, August Application Layer Firewalls vs Network Layer Firewalls: Which is the better choice, Keith D. Maxon, August 2000 Top Ten Blocking Recommendations using Ipchains, Paul Tiedemann, August 2000 What is Egress filtering and how can I implement it? Egress Filtering v0.2, Chris Brenton, February 2000 IP Fragmentation attacks on Checkpoint firewalls, James Farrell, April 2001 A comparison of packet filtering vs application level firewall technology, Ernest Romanofski, March 2001 Designing a DMZ, Scott Young, March 2001 The new firewall design question, Jamie R. Blerke, March 2001 Securing your network perimeter by filtering inbound traffic on ACK and Reset bits on Nortel Routers, Oleg Krillov, February 2001 Linux comes of age with stateful firewalling, Greg Hill, February 2001 The desktop modem threat, Joe Livingston, July 2000 DNS Security, Jeff Holland, July 2000 The packet filter: A basic network security tool, Dan Strom, September 2000 Perimeter filtering in a University setting, Elizabeth Mackenzie, September 2000 Protecting your corporate laptops from Hackers, while they are on the road, Darrell Keller, May 2001 Protecting yourself with Norton personal firewall, Mark Greco, May 2001 The Distributed firewall, Daniel Wan, May 2001 A brief taxonomy of firewalls – great walls of fire, Gary Smith, May 2001 Check point firewall-1’s stateful inspection, Michael J. Nikitas, April 2001 Stealth firewalls, Brandon Gilespie, April 2001 Firewall network appliance, Craig Simmons, October 2000 Introduction This checklist should be used to audit a firewall. This checklist does not provide vendor specific security considerations but rather attempts to provide a generic listing of security considerations to be used when auditing a firewall.
Only technical aspects of security are addressed in this checklist. Manual elements like physical protection for the firewall server is not considered.
Prior to using this checklist the following elements should be considered:
• Operating system: This checklist only defines the security items relating the firewall software and not to any security elements of the operating system.
• Port restrictions: A listing of ports to be restricted are highlighted in this checklist.
However, prior to recommending that the ports be restricted, the auditor should ensure that the service associated with that port is not used by the business e.g.
remote access via telnet. Where such situations exist this checklist attempts to provide alternate security options if the service is needed e.g. use SSH instead of Telnet.
• Modems within the internal network: Modems within the internal network are the biggest threat to subvert a firewall and thus the auditor should ensure that there Page 1 of 6 are no modems within the internal network. It is senseless performing an audit on the firewall when an even bigger threat exists via the modem. The auditor should perform war dialling to identify any modems within the internal network with tools like phonesweeper.
Application level firewalls: The inherent nature of application level firewalls • require that the operating system be as secure as possible due to the close binding of these two components. Thus, the auditor should ensure that the security on the operating system is secure before evaluating the security offered by the application level firewall.
Defence in depth: It must be recognised that the firewall implementation is a not • an end to itself to provide security. Thus, it is vital that the auditor evaluate the security of the other components like IDS, operating systems, web applications, IIS/Apache, routers and databases. Some organisations have opted for firewall network appliances, which are firewalls loaded onto operating systems which have their security already preconfigured. In such instances, the auditor need only review the security of the firewall configuration instead of the operating system as well.
Rulesets: This checklist provides a listing of best practice rulesets to be applied.
• However, the organisational requirements may not need all of the rulesets. For e.g. where an organisation has a need to allow access via the internet to critical servers, the rulesets wound not include a deny rule to that internal IP address for the critical server. Instead it may provide for allow access to HTTP 80 to the critical IP and deny all other traffic to the critical IP. It must be noted that some elements of the recommended rulesets have to be applied irrespective of business requirements e.g. blocking private addresses (RFC1918), illegal addresses, standard unroutables, reserved addresses, etc.
Laptop users: Most organisations use mobile laptops for telecommuting and on • the road sales, etc. This provides a further vulnerability even if the organisation operates a VPN. The hacker could easily gain access to the laptop when it is connected to the internet and download tools to the laptop that can become a problem when the laptop is again connected to the corporate network. In a VPN situation, the hacker with access to the remote station once the tunnel is connected, can access the corporate network. In such a circumstance, it is important for the auditor to determine if laptop usage occurs and to evaluate whether personal firewalls are installed on these laptops prior to usage. This checklist provides a generic set of considerations for personal firewalls, but it does not provide any product specific security recommendations.
Page 2 of 6
2. Application based firewall Ensure that the administrators monitor any attempts to violate the security policy using the audit logs generated by the application level firewall.
Alternatively some application level firewalls provide the functionality to log to intrusion detection systems. In such a circumstance ensure that the correct host, which is hosting the IDS, is defined in the application level firewall.
Ensure that there is a process to update the application level firewall’s vulnerabilities checked to the most current vulnerabilities.
Ensure that there is a process to update the software with the latest attack signatures.
In the event of the signatures being downloaded from the vendors’ site, ensure that it is a trusted site.
In the event of the signature being e-mailed to the systems administrator, ensure that digital signatures are used to verify the vendor and that the information transmitted has not been modified en-route.
The following commands should be blocked for SMTP at the application level
• EXPN (expand)
• VRFY (verify)
The following command should be blocked for FTP:
• PUT Review the denied URL’s and ensure that they are appropriate for e.g. any URL’s to hacker sites should be blocked. In some instances organisations may want to block access to x-rated sites or other harmful sites. As such they would subscribe to sites, which maintain listings of such harmful sites. Ensure that the URL’s to deny are updated as released by the sites that warn of harmful sites.
Ensure that only authorised users are authenticated by the application level firewall.
3. Stateful inspection Review the state tables to ensure that appropriate rules are set up in terms of source and destination IP’s, source and destination ports and timeouts.
Ensure that the timeouts are appropriate so as not to give the hacker too much time to launch a successful attack.
• If a URL filtering server is used, ensure that it is appropriately defined in the firewall software. If the filtering server is external to the organisation ensure that it is a trusted source.
• If the URL is from a file, ensure that there is adequate protection for this file to ensure no unauthorised modifications.
Ensure that specific traffic containing scripts; ActiveX and java are striped prior to being allowed into the internal network.
If filtering on MAC addresses is allowed, review the filters to ensure that it is restricted to the appropriate MAC’s as defined in the security policy.
4. Logging Ensure that logging is enabled and that the logs are reviewed to identify any potential patterns that could indicate an attack.
5. Patches and updates Ensure that the latest patches and updates relating to your firewall product is tested and installed.
If patches and updates are automatically downloaded from the vendors’ websites, ensure that the update is received from a trusted site.
Page 5 of 6
17. Zone Transfers If the firewall is stateful, ensure packet filtering for UDP/TCP 53. IP packets for UDP 53 from the Internet are limited to authorised replies from the internal network. If the packet were not replying to a request from the internal DNS server, the firewall would deny it. The firewall is also denying IP packets for TCP 53 on the internal DNS server, besides those from authorised external secondary DNS servers, to prevent unauthorised zone transfers.
18. Egress Filtering Ensure that there is a rule specifying that only traffic originating from IP’s within the internal network be allowed. Traffic with IP’s other than from the Internal network are to be dropped.
Ensure that any traffic originating from IP’s other than from the internal network are logged.
19. Critical servers Ensure that there is a deny rule for traffic destined to critical internal addresses from external sources. This rule is based on the organisational requirements, since some organisations may allow traffic via a web application to be routed via a DMZ.
20. Personal firewalls Ensure that laptop users are given appropriate training regarding the threats, types of elements blocked by the firewall and guidelines for operation of the personal firewall. This element is essential, since often times personal firewalls rely on user prompt to respond to attacks e.g. whether to accept/deny a request from a specific address.
Review the security settings of the personal firewall to ensure that it restricts access to specific ports, protects against known attacks, and that there is adequate logging and user alerts in the event of an intrusion.
Ensure that there is a procedure to update the software for any new attacks that become known.
Alternatively most tools provide the option of transferring automatic updates via the internet. In such instances ensure that updates are received from trusted sites.
21. Distributed firewalls Ensure that the security policy is consistently distributed to all hosts especially when there are changes to the policy.
Ensure that there are adequate controls to ensure the integrity of the policy during transfer, e.g. IPSec to encrypt the policy when in transfer.
Ensure that there are adequate controls to authenticate the appropriate host.
Again IPSec can be used for authentication with cryptographic certificates.
22. Stealth Firewalls Ensure that default users and passwords are reset.
Ensure that the firewall is appropriately configured to know which hosts are on which interface.
Review the firewall access control lists to ensure that the appropriate traffic is routed to the appropriate segments.
A stealth firewall does not have a presence on the network it is protecting and it makes it more difficult for the hacker to determine which firewall product is being used and their versions and to ascertain the topology of the network.
23. Ensure that ACK bit monitoring is established to ensure that a remote system cannot initiate a TCP connection, but can only respond to packets sent to it.
24. Continued availability of Firewalls Ensure that there is a hot standby for the primary firewall.