Essential Firewall Rules for Internet Facing Firewalls

1. Introduction

In a not-too-distant past I worked for a large telco company, first as a network firewall administrator and eventually made my way into the security team as a network security specialist, responsible for developing and auditing the network security standards. While I wrote many network-related standards and best-practices documents, the following was definitely one of my favorites (or favourites here in Canada, eh!). I had to convert and sanitize the content and while it is very lengthy (and not suitable for a blog), I figured I give it a shot at posting to my site. Please note, we had a mix of Check Point and Cisco PIX firewalls when this document was first authored. The newer, Next-Gen Firewalls (or Application Firewalls – layer 7) may conflict with the following rule order.

A special thanks to Yuri Kopylovski who prodded me, moderated and, otherwise, helped me co-author this guide and to the many folks at www.anti-online.com who benefited from the content over the years. This was originally published in 2007 under my alias “aciscorouter” and has since been edited to include suggestions from the Anti-Online community.

You will note that the rule order is identified in the first column I provide with the samples under all descriptions (i.e. the very first rule is a drop rule against the firewall and the very last should be a “clean-up” rule). However, this is a best-practice – order your rules any way you see fit (…and report back to me and let me know how that works for you)!

2. Purpose

The purpose of this document is to define the minimum, mandatory security policy that should be applied to all Network Firewall devices that provide demarcation between security zones (i.e. trusted, semi-trusted and un-trusted networks).  If you are old as me, you may want to understand the history of firewall types (found here).

DISCLAIMER: The policy provided herein does not include configuration examples for any particular firewall as every make and model of firewall has different ways of implementing the features, but which ever firewall you choose, whether it be a IOS Firewall or Open-source, they should have provisioning for each requirement in this document.  This document can act as a guideline of questions you may want to ask potential vendors regarding their supported features (i.e. anti-spoofing, attack protection, etc). PHEW, that was a long disclaimer!

3. Base Firewall Filters (“In the beginning”)

If you want those nefarious actors from attacking your firewall, before any other rules are added, and the firewall is “net-new”, the base firewall configuration should be to DROP EVERYTHING (security is about paranoia, right?). This is referred to as the Base Firewall Filter and incorporates two distinct rules that must always be at the top and the bottom of any firewall rule-base.

3.1 Stealth Rule (“Protect the Castle!”)

The very first “drop” rule on any firewall (prior to explicitly permitting management rules) is a rule to drop any attempts to connect to or from the firewall itself. Later, once the management station has been established a rule preceding the Stealth Rule will only allow management stations to connect on particular ports. The only rules to allow the firewall to communicate outbound will be covered in the next section “Firewall management Rules”.

3.2 Clean-up Rule (“Watch the Dirty Comms”)

The second most important rule on any firewall (whether ordered at the beginning or end of the explicit ruleset) is a rule to deny any packet that doesn’t correspond to any explicitly defined permit rule. This rule is known as the “clean-up” rule. This rule drops any traffic on any interface and writes the action to a log file.

4. Firewall Management Rules

Generally, the rule-base on any firewall or access-control mechanism is read by the system in a top-down fashion whereby the rules at the top of the list are “read first”. Given this fact, rules to permit administration and monitoring of the firewall must exist before any other rules.

*NOTE: in many cases there are more than just access rules required to permit administrators to connect to the firewall. It is not the intention of this document to identify those configuration options or suggest mechanisms to limit the number of administrators with respect to any one firewall vendor.

4.1 Administration Access Rule

The very first “permit” rule on any firewall is a rule to allow access to the firewall for administration of the firewall itself. Generally, the required access is secured and may use proprietary protocol numbers on which the firewall will listen for these connections.

No connections to the firewall from un-trusted networks are permitted unless reviewed and approved by IT Security.

SSH – The hosts connecting to the firewall via SSH must be a network management server as individual host-to-firewall connectivity in this fashion is not permitted.

GUI – Administrators connecting to the management graphical interface will generally require access directly from their local computers with the GUI software client or web browser installed.

* Firewall Management ports will vary depending on the vendor.

5. Firewall Monitoring Rules

The next rules will allow the network management servers to monitor the firewalls and allow the firewalls to send log files back to syslog servers.

Syslog – This rule need only to permit traffic out of the firewall to a syslog server on port UDP 514 within the internal trusted network.

*NOTE: In the case of Check Point Firewalls, the OPSEC Log Export API (LEA) provides an export utility which allows Log Management (LM) system or Security Information and Event Management (SIEM) solutions to pull logs from a Check Point device, listening on TCP port 18184.

SNMP – Simple Network Management Protocol (SNMP) is used to remotely manage systems. Using ports 161 (snmp) and 162 (snmp-trap) over UDP, SNMP provides a cost effective way to gather information from clients (agents) and centralize that information on a management system (Server). This is a bi-directional rule that needs to permit SNMP between the management server and the firewall.

ICMP – See section 4.4 “ICMP Message Rules”

TACACS+ – Depending on the administrative authentication scheme used on the firewall, tacacs+ may be required. A rule allowing TCP port 49 from the firewall to a network management server hosting TCACAS+ is required.

RADIUS – Whether used to authenticate firewall administrators against a RADIUS server on the trusted corporate network or to provide auditing functions for client PCs, RADIUS has being adopted in many different scenarios on the trusted and un-trusted networks. Since authentication query uses UDP 1812, rules must be added to permit traffic from the firewall to the RADIUS server, and an additional rule will be required to allow the response from the RADIUS server. Another pair of bi-directional UDP 1813 rules between the server and firewall will be required for the accounting notifications from the firewall and accounting responses from the RADIUS server.

6. Firewall Protection Rules

The base firewall protection rules are to be the template of rules that protect a firewall before any explicitly defined content rules are configured. These rules are intended to protect the firewall operation and administration from attacks, excessive floods, spoofing and other malicious behavior targeting firewalls.

There should be no exception to these rules and they must be placed on every firewall. In the event that a particular Base Protection rule can’t be defined in a rule, then the vendor must submit, in writing, a description of the feature that provides the necessary protection in place of the rule.

*NOTE: not all of the required protection options listed below can be accomplished with a rule as vendors tend to include security mechanisms by way of configuration options instead of defining an explicit rule. To satisfy Security requirements listed herein, documentation from the vendor detailing the mechanism(s) in their product that provides the necessary protection is required.

6.1 Fragmentation and Reassembly of IP Datagrams

Any fragmented IP packets destined for the trusted or the un-trusted networks (inbound or outbound) via the firewall must be reassembled on the firewall first before passing the traffic to the intended destination. Reassembling only the initial fragments and passing to the destination is only permissible if the firewall product uses a stateful approach called “interfragment state” to keep the sequence of datagram fragments in order. When the state table detects non-initial fragments, out of sequence, destined for the same host, it must drop the session immediately. If there are no options or rules to define this functionality, then the vendor must provide a written explanation of the mechanism used to satisfy this requirement.

6.2 TCP SYN Attack/Spoof Protection

A number of mechanisms are used to protect firewalls from SYN attacks, whereby embryonic SYN connections could exhaust the systems SYN queue. Since firewalls can be deployed on a number of platforms or can be appliance based, SYN flood protection will vary from vendor to vendor.

Here are the minimal mechanisms that must be present to provide the SYN Attack protection in production firewalls:

• On firewalls hosted on a *NIX-based operating system there must be a hardened TCP stack that includes setting the maximum number of connections and enabling SYN attack protection by way of SYN Cookies. Other hardening methods could include (but aren’t mandatory) increasing the queue for embryonic connections and decreasing the time period for keeping pending connections in the SYN RECEIVE state. For more information specific to hardening TCP stacks for SYN Attack protection go to: http://www.securityfocus.com/infocus/1729
• Firewall application software must have a feature to enable SYN Attack protection and if there are no configurable features, then the vendor must provide documentation that describes the mechanism protecting the firewall from SYN attacks.
• Any hardware appliances running a vendor-claimed “hardened OS” must have configurable SYN protection features and if there are none present then the vendor must provide documentation that describes the mechanism protecting the firewall from SYN attacks.

6.3 Block ICMP Redirect Messages

If an attacker sends fake ICMP Redirect messages through a firewall destined for a bastioned target (i.e. web server) that accepts ICMP redirects then the host routing table may be poisoned with bogus routing information and eventually may not be able to reply to any network address. This condition would cause a serious denial of service for critical applications such as DNS, Mail and Web servers. The packets will eventually get to the correct location but will probably cause needless congestions and may potentially cause Distributed Denial of Services attacks.

6.4 Source Routing

As part of the IP header, source routed packets have information that indicates how the packet is to be routed. As the packet crosses routers from source to destination the router forwards the packet based on the content of the route specified in the header of the packet, not determining the best route based on its own routing tables. The problem here is that source routed packets can breach most simple routing devices (including firewalls) and open up your network to the outside world to attacks and reconnaissance. Most operating systems have options that can be turned of at the kernel level to disable source routing. Most hardware-based firewalls have this option turned off as part of the system hardening certified by the vendor. In this instance it is important to have the vendor provide this information in writing.

6.5 “Blacklisted” Sites

There must be a rule defined to allow firewall administrators to block traffic from external IP addresses deemed malicious or in violation of security policies (a Blacklist). This rule may or may not need to be active at all times depending on the reason for blocking the “bad” sites in the first place. This rule can help facilitate response to a security breach, denial of service or other suspicious security incident.

6.6 Spoofed IP Addresses

Spoofing is a technique where the IP address of a packet is altered to make it appear as though the packet has originated from the internal, trusted network. The target system can be fooled into believing that the attacker’s machine is really a trusted machine. Traffic coming into the network from the Internet or any third-party network should never originate from what appears to be an trusted private or reserved address space used on the internal corporate network.

Popular spoofed addresses used in an attack include the private reserved address range enumerated in RFC 1918 listed as follows:

• Class A: 10.x.x.x
• Class B range: 172.16.0.0-172.31.0.0
• Class C range: 192.168.1.x-192.168.254.x

Additionally, public address space has been reserved and has a number of systems addressed both internally and externally with this addressing. Any of these addresses that exist in a protected DMZ or are on an internal network must be listed in an anti-spoofing rule as being internal addresses and any external interfaces receiving packets claiming to be from any of these addresses must be blocked as well.

Depending on the firewall product used, an RFC 1918 anti-spoofing mechanism (also referred to as ingress filtering) may be a feature of the firewall configuration, defined by a rule or a combination of both. Reserved public addressing is not be supported by generic anti-spoofing mechanisms and will still require a rule to block packets from external interfaces claiming to be trusted systems internally.

* Public IP addressing reserved and used on the inside and DMZ’s.

6.7 Loopback Address As Source or Destination

The address 127.0.0.1 is used internally by systems in an Inter-Processor Control (IPC) mechanism that enables the client and server portion an application running on the same machine to communicate, an so it is trusted. It should never be used as the source IP address of an inbound or outbound transmission. The loopback object should have the address of 127.0.0.0/8.

Rule #18 will block any attempt from the firewall or any network to pass any packets claiming to be from a loopback address.

Rule #19 will block any attempts to connect to the firewall loopback interface.

6.8 Spoofed Broadcast Addresses

Since broadcast SOURCE addresses are 0.0.0.0 and broadcast DESTINATION address are usually 255.255.255.255 (unless subnetted), the firewall should intercept and block any attempt by an attacker to spoof the source or destination of a broadcast packet. This rule will block any attempt to fool the firewall into believing the broadcast packet originated from a DESTINATION broadcast or is being sent to a SOURCE broadcast address.

6.9 Multicast Address As Source

Any firewall interface that receives a packet with a forged source address claiming to be from a multicast address must block and log these datagrams. The multicast addresses for the source object should be 224.0.0.0/4.

 

6.10 Reserved Class E IP Addresses As Source

Any firewall interface that receives a packet with a forged source address claiming to be from the reserved class “E” address space must block and log these datagrams. The reserved class “E” addresses for the source object should be 240.0.0.0/5.

6.11 IANA Reserved IP Addresses As Source or Destination

An area of the IP address space reserved, but not yet allocated or delegated by the Internet Assigned Numbers Authority (IANA) is commonly referred to as “bogon space”. Any packet received by any external, un-trusted interface on a firewall must be blocked.

Internal networks should have requests to the “bogon space” routed to a “sink-hole” defined in RFC3882 and should not traverse a firewall outbound from the corporate network, therefore a rule to block outbound “bogon” traffic is not required.

A group object should be created that incorporates subsequent objects with the “bogon” addresses found at http://www.iana.org/assignments/ipv4-address-space. Addresses that have the listed purpose of “IANA – Reserved” are the most current bogon addresses that should be listed in the proceeding rule.

*NOTE:* since the IANA is constantly changing the status of their reserved addresses as more addresses blocks are released to the public Internet, this rule should be reviewed on a monthly basis to ensure legitimate networks aren’t being blocked access to publicly available resources.

7. ICMP Message Rules

ICMP is an important protocol that is used for troubleshooting the TCP/IP network but it is also frequently used for a multitude of known attacks. Examples are Denial of Service attacks and Trojan horses that misuse ICMP to transmit information out of compromised networks. Company has experienced numerous attacks, both internally and externally in the past with ICMP being the protocol used in the attack. This has lead to standards that were adopted during incidents that are still in practice today. The following are the standard rules that apply to processing numerous ICMP messages.

7.1 General ICMP Rules

• Outbound: No workstation in the corporate environment may send icmp messages outbound to any un-trusted networks with the exception of those icmp types listed below for the purpose of basic network functionality. Network Management stations and select servers may have this functionality out of the corporate environment with approval of IT Security. The reason for this is in the event of DDoS type attacks, multiple slave PCs on the local network could be infected and saturate the Internet gateway.
• Inbound: No ICMP messages are allowed into the corporate environment from an un-trusted source address with the exception of those listed below for the purpose of basic network functionality. This means by general rule, echo-request/reply, traceroute and destination unreachable are not permitted into the corporate environment from any systems other than those that are approved by IT Security.

7.2 Packet Internet Groper (PING) Utility

PING requires two icmp types: Echo-request (8) and Echo-reply (0). For hosts on an internal network to PING a host outside of the firewall an echo-request must be allowed out of the network and then a reply from the external host must be allowed back in to the host internally that originated the request. This rule should only be implemented for approved systems on the internal network that require PING outbound for troubleshooting un-trusted networks. In some cases we may allow our upstream providers or trusted vendors to ping devices on our internal DMZs or Networks and allow the reply back out to the external host.

7.3 TRACEROUTE Utility

Traceroute requires rules to allow icmp destination-unreachable (type 3) and icmp time-exceeded (11) messages from external, un-trusted addresses back into the network to the hosts that initiated the traceroute. For most implementations, UDP is required to start the probing of hosts and requires a source port between 32768 and 65535 and a destination port between 33434 and 33523. This rule should only be implemented for approved systems on the internal network that require traceroute outbound for troubleshooting un-trusted networks. Microsoft’s TRACERT application does not use UDP for the traceroute probe, it uses icmp echo-requests. In some cases we may allow our upstream providers or trusted vendors to traceroute to devices on our internal DMZs or Networks and allow the reply back out to the external host.

7.4 ICMP(4): SOURCE-QUENCH

Source Quench is an ICMP message sent by IP to request that a sender throttle back to control the demand of the receiver’s capacity. This ICMP message is integral in controlling congestion within IP sessions. When a gateway responds to congestion by dropping datagrams, it may send an ICMP Source Quench message to the source of the dropped datagram. This is a congestion recovery policy. Since ICMP(4) is necessary for layer 3 flow control it is imperative to allow this ICMP type in either direction.

7.5 ICMP(12): PARAM-PRBLM

The Parameter Problem message is sent if a gateway or host processing a datagram finds a problem with the header parameters such that it cannot complete processing the datagram. Since ICMP(12) is necessary for layer 3 and 4 functionality, it is imperative to allow this ICMP type in either direction.

7.6 Block Remaining ICMP Types

All additional ICMP messages from type 13 to 255 (41-255 are reserved) are not needed for proper TCP/IP communications and cannot be used for troubleshooting purposes. These must be blocked from any interface in any direction and logged.

8. Summary of Standard Firewall Rules

Here is the complete summary of rules that were discussed in this section. Any firewall that is placed into production must have these mandatory rules in place at a minimum.

9. Firewall Content Rules

The rules covered in this section are just an example of the more popular host-to-host communications that are filtered by the firewall. Actual specifics of the rule will vary depending on the architecture. Note that the numbers assigned to these rules are alpha-numeric so that they don’t get confused with the priorities assigned to the Base Firewall Rules.

One thing to note for the management of a firewall content ruleset is to create a document that lists the “as-built” policy before any content rules are introduced.  Next, a database or spreadsheet should be kept to record additional rule requests with dates, firewall, requested rules, who requested the rules, who approved them, who and when they were implemented.

9.1 Domain Name Service (DNS) Rules – Server

A DNS server uses the well-known port 53 for both client and server connection requests, choosing either UDP or TCP as a transport based on the nature of the request. A client to DNS server query uses a client side port above 1023 with the destination server port being 53. The server to client response uses the reverse, port 53 back to a port above 1023. If there is a server-to-server query or response, the source and destination ports are both 53 and use UDP as a transport. However, if the data contained in the DNS datagram exceeds 512 bytes, the transport used is TCP with the source port being 53 and the destination a port number above 1023. The DNS zone transfer uses TCP with the primary DNS server listening on port 53 for the request from the secondary DNS server.

Rules 32 and 33 are for client DNS queries and replies from the server. Since we are allowing ANY to connect to DNS and DNS to connect to ANY on both UDP and TCP 53 there is no need to define a rule to allow zone-transfers from trusted, external DNS servers. There is also no reason to only permit the corporate DNS server to communicate out if the SYN flag is NOT set as the DNS server will need to initiate zone transfers and query other DNS servers on the Internet.

9.2 Web Client HTTP and HTTPS Rules

The rules below refer strictly to outbound HTTP and HTTPS traffic from anywhere on the internal trusted network destined for the Internet (or any other un-trusted network). Generally, users on the internal network have full access to the Internet and this rule will be covered in a general ANY—INTERNET—ANY—PERMIT rule, allowing access to any service on the Internet.

*NOTE: DMZ networks are deemed as un-trusted and should have specific rules permitting access to specific destination addresses.

9.3 Web Server HTTP and HTTPS Rules

The rules below refer strictly to inbound HTTP and HTTPS traffic from anywhere destined for a hosted web server. This usually refers to web servers that are sitting within a DMZ network and have been bastioned. Block all other incoming and outgoing traffic from the Web server to any external destination with the SYN flag set.

*NOTE: depending on the architecture the Web Server may be proxied through another network device (i.e. SSL Proxy, Load-Balancer). The same rules will apply to allowing ANY to talk to the proxy device. Also, HTTP or HTTPS can be hosted on a number of different ports other than TCP-80 (i.e. 8080, 8001, 8002, etc.).

9.4 Simple Mail Transfer Protocol (SMTP) Rules

The rules below refer strictly to inbound SMTP traffic from anywhere destined for an SMTP mail server. This usually refers to mail servers that are sitting within a DMZ network and have been bastioned. Block all outgoing traffic from the mail server to any external destination.

SMTP sends all traffic unencrypted over a network with header information, destination and source email addresses, being easily accessible to someone sniffing traffic. SMTP uses TCP port 25. Packet filtering SMTP to enable inbound mail should be directed from external hosts to a trusted bastion host, and from the bastion host to internal main servers. Outgoing SMTP from the trusted network should be sent from the internal SMTP server to the external SMTP server acting as the Internet gateway.

Internal mail servers and mail clients should not have any reason to communicate with the external SMTP server directly (except for management purposes that is not covered in this document).

9.5 File Transfer Protocol (FTP) Client Rules

The rules below refer strictly to outbound FTP traffic from anywhere on the internal trusted network destined for the Internet (or any other un-trusted network). Generally, users on the internal network have full access to the Internet and this rule will be covered in a general ANY—INTERNET—ANY—PERMIT rule, allowing access to any service on the Internet. FTP is established between client and server on TCP-21 and then once there is an established connection the client tells the server to establish a data-connection on TCP port 20 to start transferring data.

*NOTE: FTP is an un-secured method of transferring data as all packets are transferred in clear-text. SFTP or SCP, which are provided with the SSH client, is mandatory when transferring data from the Internal network or DMZs and the Internet. DMZ networks are deemed as un-trusted and should have specific rules permitting access to specific destination addresses.

9.6 Passive Mode FTP Client Rules

Passive mode FTP is used when all FTP connections must start from the inside of the network, not requiring the client to allow the FTP server to establish a data channel. In passive mode the client tells the server to create the second port above 1024 using the PASV command. The server then replies with the random port number accepts the data channel from the client on this port.

Generally, users on the internal network have full access to the Internet and this rule will be covered in a general ANY—INTERNET—ANY—PERMIT rule, allowing access to any service on the Internet.

10. References

[IANA]

http://www.iana.org/assignments/ipv4-address-space

– IANA reserved IP address networks

[RFC1918]

http://www.isi.edu/in-notes/rfc1918.txt

– RFC describing reserved networks

[PRICIPLELOGIC]

http://www.principlelogic.com/docs/Firewall_Best_Practices.pdf

– Firewall Best Practices

[RFC 791]

ftp://ds.internic.net/rfc791.txt

– Internet Protocol

[BOOK]

D.Brent Chapman, Elizabeth D. Zwicky, Simon Cooper

“Building Internet Firewalls, 2nd Edition”,

O’Reilly&Associates, 2000

[ONLINE]

ftp://ftp.greatcircle.com/pub/firewalls/pkt_filtering.ps.z

D.Brent Chapman,

“Network (In)Security Through IP Packet Filtering”,

[ONLINE]

http://www.interhack.net/pubs/fwfaq/

Matt Curtin, Marcus J. Ranum

Internet Firewalls: Frequently Asked Questions