Mandatory Firewall Rules for Internet Facing Firewalls

1. Introduction

In a past life I worked for a large company, first as a network firewall administrator and eventually made my 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. 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.

A special thanks to Yuri Kopylovski who 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).

2. Purpose

The purpose of this document is to define the minimum, mandatory security policy that must be applied to all Network Firewall devices that provide demarcation between trusted, semi-trusted and un-trusted networks.  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).

3. Base Firewall Filters

Before any other rules are added and the firewall is “net-new” the base firewall configuration should be to DROP EVERYTHING. 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

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”.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
1. ANY INPUT ANY Firewall ANY ANY ANY DROP Yes
38. ANY OUTPUT Firewall ANY ANY ANY ANY DROP Yes

3.2 Clean-up Rule

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
2. ANY INPUT OUTPUT ANY ANY ANY ANY ANY DROP Yes

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
3. INSIDE INPUT NMS_Internal Firewall >1023 SSH (22) TCP ACCEPT No
4. INSIDE INPUT NMS_Internal Firewall >1023 *FW_MGMT_

PORTS

TCP

UDP

ACCEPT No

* 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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
5. INSIDE OUTPUT Firewall SYSLOG_SVR >1023 SYSLOG (514) UDP ACCEPT No

 

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
6. INSIDE OUTPUT Firewall NMS_Internal >1023 SNMP _TRAP (162) UDP ACCEPT No
7. INSIDE INPUT NMS_Internal Firewall >1023 SNMP (161) UDP ACCEPT No
8. INSIDE OUTPUT Firewall NMS_Internal SNMP (161) >1023 UDP ACCEPT No

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
9. INSIDE OUTPUT Firewall NMS_Internal ANY TACACS+ (49) TCP ACCEPT No

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
10. INSIDE OUTPUT Firewall RADIUS_SVR >1023 RADIUS (1812) UDP ACCEPT No
11. INSIDE INPUT RADIUS_SVR Firewall RADIUS (1812) >1023 UDP ACCEPT No
12. INSIDE OUTPUT Firewall RADIUS_SVR >1023 RADIUS _ACCT (1813) UDP ACCEPT No
13. INSIDE INPUT RADIUS_SVR Firewall RADIUS _ACCT (1813) >1023 UDP ACCEPT No

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
14. ANY INPUT

OUTPUT

ANY ANY ANY   ICMP (5) DENY No

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
15. ANY INPUT

OUTPUT

ANY, source-routed ANY ANY ANY IP DENY No

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. 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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
16. OUTSIDE INPUT Blocked IP ANY ANY ANY ANY DENY No

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
17. OUTSIDE INPUT 10.0.0.0/8

172.16 /12

192.168 /16

*RESRV_PUBLIC

ANY ANY ANY ANY DENY Yes

* 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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
18. ANY OUTPUT Loopback ANY ANY ANY ANY DENY Yes
19. ANY INPUT ANY Loopback ANY ANY ANY DROP No

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
20. ANY INPUT BROADCAST_DEST ANY ANY ANY ANY DROP Yes
21. ANY INPUT ANY BROADCAST _SRC ANY ANY ANY DROP Yes

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
22. ANY INPUT CLASS_D_

MULTICAST

ANY ANY ANY ANY DROP Yes

 

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
23. ANY INPUT CLASS_E_

RESERVED

ANY ANY ANY ANY DROP Yes

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
24. ANY INPUT BOGON_ADDR ANY ANY ANY ANY DROP Yes

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
25. INSIDE INPUT Trusted INTERNAL Hosts ANY ANY ANY ICMP8 ACCEPT No
26. OUTSIDE INPUT ANY Trusted INTERNAL Hosts ANY ANY ICMP0 ACCEPT No
27. OUTSIDE INPUT Trusted EXTERNAL Hosts Pre-defined INTERNAL Hosts ANY ANY ICMP8 ACCEPT No
28. INSIDE INPUT Pre-defined INTERNAL Hosts Trusted EXTERNAL Hosts ANY ANY ICMP0 ACCEPT No

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
29. INSIDE INPUT Trusted INTERNAL Hosts ANY 32768 -65535 33434 – 33523 UDP ACCEPT No
30. OUTSIDE INPUT ANY Trusted INTERNAL Hosts ANY ANY ICMP3 ACCEPT No
31. OUTSIDE INPUT ANY Trusted INTERNAL Hosts ANY ANY ICMP11 ACCEPT No
32. OUTSIDE INPUT Trusted EXTERNAL Hosts Pre-defined INTERNAL Hosts 32768 -65535 33434 – 33523 UDP ACCEPT No
33. INSIDE INPUT Pre-defined INTERNAL Hosts Trusted EXTERNAL Hosts ANY ANY ICMP3 ACCEPT No
34. INSIDE INPUT Pre-defined INTERNAL Hosts Trusted EXTERNAL Hosts ANY ANY ICMP11 ACCEPT No

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
35. ANY INPUT

OUTPUT

ANY ANY ANY ANY ICMP4 ACCEPT No

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
36. ANY INPUT

OUTPUT

ANY ANY ANY ANY ICMP12 ACCEPT No

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
37. ANY INPUT ANY ANY ANY ANY ICMP 13:255 DROP No

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.

RULE INT IN/OUT SRC ADDR DST ADDR SRC PORT DST PORT PROT ACTION LOG?
1. ANY INPUT ANY Firewall ANY ANY ANY DROP Yes
2. ANY INPUT OUTPUT ANY ANY ANY ANY ANY DROP Yes
3. INSIDE INPUT NMS_Internal Firewall >1023 SSH (22) TCP ACCEPT No
4. INSIDE INPUT NMS_Internal Firewall >1023 *FW

_MGT

_PORTS

TCP

UDP

ACCEPT No
5. INSIDE OUTPUT Firewall SYSLOG

_SVR

>1023 SYSLOG (514) UDP ACCEPT No
6. INSIDE OUTPUT Firewall NMS_Internal >1023 SNMP _TRAP (162) UDP ACCEPT No
7. INSIDE INPUT NMS_Internal Firewall >1023 SNMP

(161)

UDP ACCEPT No
8. INSIDE OUTPUT Firewall NMS_Internal SNMP (161) >1023 UDP ACCEPT No
9. INSIDE OUTPUT Firewall NMS_Internal ANY TACACS (49) TCP ACCEPT No
10. INSIDE OUTPUT Firewall RADIUS_SVR >1023 RADIUS (1812) UDP ACCEPT No
11. INSIDE INPUT RADIUS_SVR Firewall RADIUS (1812) >1023 UDP ACCEPT No
12. INSIDE OUTPUT Firewall RADIUS

_SVR

>1023 RADIUS _ACCT (1813) UDP ACCEPT No
13. INSIDE INPUT RADIUS_SVR Firewall RADIUS _ACCT (1813) >1023 UDP ACCEPT No
14. ANY INPUT

OUTPUT

ANY ANY ANY   ICMP5 DENY No
15. ANY INPUT

OUTPUT

ANY,

source-routed

ANY ANY ANY IP DENY No
16. OUTSIDE INPUT Blocked IP ANY ANY ANY ANY DENY No
17. OUTSIDE INPUT 10.0.0.0/8

172.16 /12

192.168 /16

*RESRV_PUB

ANY ANY ANY ANY DENY Yes
18. ANY OUTPUT Loopback ANY ANY ANY ANY DENY Yes
19. ANY INPUT ANY Loopback ANY ANY ANY DROP No
20. ANY INPUT BROADCAST

_DEST

ANY ANY ANY ANY DROP Yes
21. ANY INPUT ANY BROADCAST _SRC ANY ANY ANY DROP Yes
22. ANY INPUT CLASS_D_

MULTICAST

ANY ANY ANY ANY DROP Yes
23. ANY INPUT CLASS_E_

RESERVED

ANY ANY ANY ANY DROP Yes
24. ANY INPUT BOGON

_ADDR

ANY ANY ANY ANY DROP Yes
25. INSIDE INPUT Trusted INTERNAL Hosts ANY ANY ANY ICMP 8 ACCEPT No
26. OUTSIDE INPUT ANY Trusted INTERNAL Hosts ANY ANY ICMP0 ACCEPT No
27. OUTSIDE INPUT Trusted EXTERNAL Hosts Pre-defined INTERNAL Hosts ANY ANY ICMP8 ACCEPT No
28. INSIDE INPUT Pre-defined INTERNAL Hosts Trusted EXTERNAL Hosts ANY ANY ICMP0 ACCEPT No
29. INSIDE INPUT Trusted INTERNAL Hosts ANY 32768 -65535 33434 – 33523 UDP ACCEPT No
30. OUTSIDE INPUT ANY Trusted INTERNAL Hosts ANY ANY ICMP3 ACCEPT No
31. OUTSIDE INPUT ANY Trusted INTERNAL Hosts ANY ANY ICMP11 ACCEPT No
32. OUTSIDE INPUT Trusted EXTERNAL Hosts Pre-defined INTERNAL Hosts 32768 -65535 33434 – 33523 UDP ACCEPT No
33. INSIDE INPUT Pre-defined INTERNAL Hosts Trusted EXTERNAL Hosts ANY ANY ICMP 3 ACCEPT No
34. INSIDE INPUT Pre-defined INTERNAL Hosts Trusted EXTERNAL Hosts ANY ANY ICMP11 ACCEPT No
35. ANY INPUT

OUTPUT

ANY ANY ANY ANY ICMP4 ACCEPT No
36. ANY INPUT

OUTPUT

ANY ANY ANY ANY ICMP12 ACCEPT No
37. ANY INPUT ANY ANY ANY ANY ICMP 13:255 DROP No
à Start Content-Based Firewall Rules                  
à Stop Content-Based Firewall Rules                  
38. ANY OUTPUT Firewall ANY ANY ANY ANY DROP No

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.

Rule# Interface Direction SRC ADDR DST ADDR SRC PORT DST PORT Action Log?
C1. ANY INPUT ANY DNS_SVR UDP

>1024

UDP(53) ACCEPT No
C2. ANY OUTPUT DNS_SVR ANY UDP(53)

TCP(53)

UDP >1024

TCP >1024

ACCEPT No
*C3. ANY OUTPUT DNS_SVR ANY ANY ANY with SYN flag set DENY Yes
* The last rule is optional as the clean up rule will perform the same action                

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.

Rule# Interface Direction SRC ADDR DST ADDR SRC PORT DST PORT Action Log?
C4. INSIDE INPUT All Corporate Address Ranges ANY TCP

>1024

TCP(80)

TCP(443)

ACCEPT No

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.).

Rule# Interface Direction SRC ADDR DST ADDR SRC PORT DST PORT Action Log?
C5. OUTSIDE INPUT ANY WEB_SVR TCP

>1024

TCP(80) ACCEPT No
C6. OUTSIDE OUTPUT WEB_SVR ANY TCP(80) without SYN flag set >1024 ACCEPT No
C7. OUTSIDE INPUT ANY WEB_SVR TCP

>1024

TCP(443) ACCEPT No
C8. OUTSIDE OUTPUT WEB_SVR ANY TCP(443) without SYN flag set >1024 ACCEPT No
*C9. OUTSIDE OUTPUT WEB_SVR ANY TCP

>1024

ANY with SYN flag set DENY Yes
* The last rule is optional as the clean up rule will perform the same action                

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).

Rule# Interface Direction SRC ADDR DST ADDR SRC PORT DST PORT Action Log?
C10. OUTSIDE INPUT ANY SMTP_SVR TCP

>1024

TCP(25) ACCEPT No
C11. OUTSIDE OUTPUT SMTP_SVR ANY TCP(25) without SYN flag set. >1024 ACCEPT No
*C12 OUTSIDE OUTPUT SMTP_SVR ANY TCP

>1024

ANY with SYN flag set DENY Yes
* The last rule is optional as the clean up rule will perform the same action                

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.

Rule# Interface Direction SRC ADDR DST ADDR SRC PORT DST PORT Action Log?
C13. INSIDE INPUT All Corporate Address Ranges ANY TCP

>1024

TCP(21) ACCEPT No
C14. OUTSIDE INPUT ANY All Corporate Address Ranges TCP(21) TCP

>1024

ACCEPT No
C15. OUTSIDE INPUT ANY All Corporate Address Ranges TCP

>1024

TCP(20) ACCEPT No
C16. OUTSIDE INPUT All Corporate Address Ranges ANY TCP(20) TCP

>1024

ACCEPT No

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.

Rule# Interface Direction SRC ADDR DST ADDR SRC PORT DST PORT Action Log?
C17. INSIDE INPUT All Corporate Address Ranges ANY TCP

>1024

TCP(21) ACCEPT No
C18. OUTSIDE INPUT ANY All Corporate Address Ranges TCP(21) TCP

>1024

ACCEPT No
C19. OUTSIDE INPUT All Corporate Address Ranges ANY TCP

>1024

TCP

>1024

ACCEPT No
C20. OUTSIDE INPUT ANY All Corporate Address Ranges TCP

>1024

TCP

>1024

ACCEPT No

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

 

Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

6 Responses to Mandatory Firewall Rules for Internet Facing Firewalls

  • Dude, this is a book! Great job putting this together. Cool how you laid out the rules by purpose and made sequential in the rule order. This reminds me of old school Check Point rule base. I used your idea about bogons to block my WiFi router from allowing IANA reserved ingress. Do you have this in PDF?

    Cheers,
    Nightwish

  • Great article. Everything I’ve been looking for !! Speaks to many of the things i’m trying to achieve. I would be happy to get a copy of the PDF as well.

  • Great stuff. Well put together and detail explanation. I would like a PDF copy if that is ok. Thanks in advance.

  • Great article Dude!
    I would very very happy to have a copy by mail at [[email protected]]
    Thanks in advance

Leave a Reply

Your email address will not be published. Required fields are marked *

Are You Human? * Time limit is exhausted. Please reload CAPTCHA.