Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- ************************SANS FireWall Checklist**************************
- ________________________________________________________________________
- 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.
- Page 3 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
- 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.
- 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 4 of 6
- 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
- except from external
- secondary DNS servers
- 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
- Page 5 of 6
- Small services TCP & UDP 20 and below
- FTP TCP 21
- SSH TCP 22
- Telnet TCP 23
- SMTP (except external
- mail relays)
- TCP 25
- NTP TCP & UDP 37
- Finger TCP 79
- HTTP (except to external
- web servers)
- TCP 80
- 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
- web servers)
- TCP 443
- 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
- Vulnerability)
- TCP &UDP 4045
- Cisco AUX port (binary) TCP 6001
- Common high order
- HTTP ports
- TCP 8000, 8080, 8888
- 12. Remote access
- If remote access is to be used, ensure that the SSH protocol (port 22) is used
- instead of Telnet.
- 13. 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.
- 14. 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.
- 15. 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.
- 16. 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.
- Page 6 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.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement