0% found this document useful (0 votes)
875 views7 pages

Firewall Audit Check List

This document provides a checklist for auditing a firewall. It lists several considerations for the audit such as ensuring the operating system and firewall software are securely configured. The checklist itself contains 9 items to check including reviewing firewall rulesets, ensuring logging is enabled, and checking that patches are applied. Compliance with the organization's security policy is also addressed.

Uploaded by

Isaiah
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
875 views7 pages

Firewall Audit Check List

This document provides a checklist for auditing a firewall. It lists several considerations for the audit such as ensuring the operating system and firewall software are securely configured. The checklist itself contains 9 items to check including reviewing firewall rulesets, ensuring logging is enabled, and checking that patches are applied. Compliance with the organization's security policy is also addressed.

Uploaded by

Isaiah
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 7

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 of 6are no
modems within the internal network. It is senseless performing an audition the firewall when an
even bigger threat exists via the modem. The auditor should perform war dialing to identify any
modems within the internal network with tools like phone sweeper.
 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.
 De fence in depth: It must be recognized that the firewall implementation is a notan 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 organizations have opted for firewall network appliances, which are firewalls loaded onto
operating systems which have their security already pre configured. 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 rule sets to be applied.However,
the organizational requirements may not need all of the rule sets. Fore.g. where an organization
has a need to allow access via the internet to critical servers, the rule sets wound not include a
deny rule to that internal IP address forthe 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 rule sets have to be applied irrespective of business
requirements e.g. blocking private addresses (RFC1918), illegal addresses, standard unroutables,
reserved addresses, etc.
 Laptop users: Most organizations use mobile laptops for telecommuting and on the road
sales, etc. This provides a further vulnerability even if the organization 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.

Checklist
Checklist

No. Security Elements

1. Review the rulesets to ensure that they follow the order as follows:
•   anti-spoofing filters (blocked private addresses, internal addresses

appearing from the outside)

•   User permit rules (e.g. allow HTTP to public webserver)

•   Management permit rules (e.g. SNMP traps to network

management server)

•   Noise drops (e.g. discard OSPF and HSRP chatter)

•   Deny and Alert (alert systems administrator about traffic that is

suspicious)

•   Deny and log (log remaining traffic for analysis)

Firewalls operate on a first match basis, thus the above structure is important

to ensure that suspicious traffic is kept out instead of inadvertently allowing

them in by not following the proper order.


 
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 firewall:
 EXPN (expand)
 VRFY (verify)
 DEBUG
 WIZARD
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.
For URL’s
 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.
5. 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.
In the event that patches and updates are e-mailed to the systems

administrator ensure that digital signatures are used to verify the vendor and

ensure that the information has not been modified en-route.

6. Location – DMZ

Ensure that there are two firewalls – one to connect the web server to the

internet and the other to connect the web server to the internal network.

In the event of two firewalls ensure that it is of different types and that dual

NIC’s are used. This would increase security since a hacker would need to

have knowledge of the strengths, weaknesses and bugs of both firewalls.

The rulesets for both firewalls would vary based on their location e.g. between

web server and the internet and between web server and the internal network.

7. Vulnerability assessments/ Testing

Ascertain if there is a procedure to test for open ports using nmap and whether

unnecessary ports are closed.

Ensure that there is a procedure to test the rulesets when established or

changed so as not to create a denial of service on the organisation or allow

any weaknesses to continue undetected.

8. Compliance with security policy

Ensure that the ruleset complies with the organisation security policy.

9. Ensure that the following spoofed, private (RFC 1918) and illegal addresses
are blocked:
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 traffic from the above addresses is not transmitted by the

interface.

10. Ensure that loose source routing and strict source routing (lsrsr & ssrr) are

blocked and logged by the firewall.

11. Port restrictions

The following ports should blocked:

Service Port Type Port Number

DNS Zone Transfers TCP 53

TFTP Daemon UDP 69

Link TCP 87

SUN RPC TCP & UDP 111

BSD UNIX TCP 512 – 514

LPD TCP 515

UUCPD TCP 540

Open Windows TCP & UDP 2000

NFS TCP & UDP 2049

X Windows TCP & UDP 6000 – 6255

Small services TCP & UDP 20 and below


 
Small services TCP & UDP 20 and below
FTP TCP 21
SSH TCP 22
Telnet TCP 23
SMTP (except external TCP 25
mail relays)

NTP TCP & UDP 37


Finger TCP 79
HTTP (except to external TCP 80
web servers)

POP TCP 109 &110


NNTP TCP 119
NTP TCP 123
NetBIOS in Windows NT TCP &UDP 135
NetBIOS in Windows NT UDP 137 & 138
NetBIOS TCP 139
IMAP TCP 143
SNMP TCP 161 &162
SNMP UDP 161 &162
BGP TCP 179
LDAP TCP &UDP 389
SSL (except to external TCP 443
web servers)

NetBIOS in Win2k TCP &UDP 445


Syslog UDP 514
SOCKS TCP 1080
Cisco AUX port TCP 2001
Cisco AUX port (stream) TCP 4001
Lockd (Linux DoS TCP &UDP 4045
Vulnerability)

Cisco AUX port (binary) TCP 6001


Common high order TCP 8000, 8080, 8888
HTTP ports
22. Remote access
If remote access is to be used, ensure that the SSH protocol (port 22) is used instead of
Telnet.
22. File Transfers
If FTP is a requirement, ensure that the server, which supports FTP, is placed in a different
subnet than the internal protected network.
22. Mail Traffic
Ascertain which protocol is used for mail and ensure that there is a rule to block incoming mail
traffic except to internal mail.
22. ICMP (ICMP 8, 11, 3)
Ensure that there is a rule blocking ICMP echo requests and replies.
Ensure that there is a rule blocking outgoing time exceeded and unreachable messages.
22. IP Readdressing/IP Masquerading
Ensure that the firewall rules have the readdressing option enabled such that internal IP
addresses are not displayed to the external untrusted networks.
22. 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.
22. 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.
22. 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.
22. 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.
22. 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.
22. 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.
22. Continued availability of Firewalls: Ensure that there is a hot standby for the primary firewall.

You might also like