Essential Firewall Policy Standards

Essential Firewall Rules for Internet Facing Firewalls

Gary Freeman and Yuri Kopylovski ©2006

Table Of Contents

1. Document Purpose

2. Terms Used In This Document

3. Base Firewall Filters

3.1 Stealth Rule

3.2 Clean-up Rule

4. Firewall Management Rules

4.1 Administration Access Rule

5. Firewall Monitoring Rules

6. Firewall Protection Rules

6.1 Fragmentation and Reassembly of IP Datagrams

6.2 TCP SYN Attack Protection

6.3 Block ICMP Redirect Messages

6.4 Source Routing

6.5 Blacklisted Sites

6.6 Spoofed RFC1918 IP Addresses

6.7 Spoofed Loopback Addresses

6.8 Spoofed Broadcast Addresses

6.9 Spoofed Multicast Addresses

6.10 Spoofed Class E Addresses

6.11 Spoofed IANA Reserved

7. ICMP Message Rules

7.1 General ICMP Rules

7.2 PING

7.3 Traceroute

7.4 Source-Quench

7.5 Parameter Problem

7.6 Block Remaing ICMP Types

8. Summary Of Standard Firewall Rules

9. Firewall Content Rules

9.1 DNS Rules

9.2 HTTP/HTTPS Client Rules

9.3 HTTP/HTTPS Server Rules

9.4 SMTP Rules

9.5 FTP Rules

9.6 PASV FTP Rules

10. References

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

2. Terms Used In This Document

The terms used in the examples of firewall rules in this section to support each standard can be defined with

the following meanings:

TERM DEFINITION

ACTION

This refers to what action the firewall should take when a packet

meets the criteria of a rule;

1) Drop means silently block the packet and do not send a response

to the sender.

2) Deny means block the packet and send a reply to the sender that

access is denied.

3) Permit means allow the packet to pass though the firewall.

Bogon

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

DMZ

A Demilitarization Zone or DMZ is a small network that sits between a

trusted network (i.e. corporate LAN) and a untrusted network (i.e.

Internet). Usually, a DMZ hosts devices such as HTTP, FTP and DNS

that is accessible from the untrusted network.

DST PORT This is the destination port that the source IP address wants to

connect to on the destination host.

Firewall

A firewall is a device or software running on a server used to enforce

a boundary between two or more networks. A network can be made

up of a company's local area networks, wide area networks, and the

Internet. The firewall's role is to ensure that all communication

between an organization's networks, in both directions, conforms to

the organization's security policies.

Firewall Policy

The firewall policy is a collection of rules ranked in numerical order

that are installed onto the firewall that defines the level of access

control between two or more networks. Policies are usually

structured to deny unknown traffic and permit traffic that is explicitly

defined.

Firewall Rule

A firewall rule is a command that tells the firewall what to do with

every packet that the firewall inspects for a particular service or

subnet. A rule usually defines the interface to watch for the packet,

source address, destination address, IP or ICMP protocol number,

action to take (permit, deny, drop) and other vendor specific fields.

IN/OUT (direction) This refers to the direction the packet is traveling on a particular

interface of the firewall.

INT (interface)

The interface refers to which interface on the firewall is receiving the

packet to be analyzed by the access filter. ANY refers to any or all of

the firewall interfaces, INSIDE refers to the interfaces connected to

the trusted network, and OUTSIDE refers to any interface that faces

an un-trusted network such as the Internet or a DMZ.

IP Address (Destination)

DST ADDR

A unique 32-bit number that identifies the destination of a TCP/IP

network source request.

IP Address (Source)

SRC ADDR

A unique 32-bit number that identifies the source of a TCP/IP

network request.

IP Spoofing

Alteration of a packet's IP address to make it appear as if the packet

originated from a network or client with higher access privileges or to

incriminate an innocent party.

LOG? This column determines whether acceptance or violation of a rule

needs to be recorded in a log file.

Network Address

Translation (NAT)

Translation of internal IP addresses into "legal" or public IP

addresses. NAT can also be used to conceal the addressing used on

one side of a firewall or DMZ.

PROT (protocol) This specifies the Internet Protocol (i.e. TCP, UDP or ICMP)

RULE

Rule number refers to the order and priority that the firewall will

place on each entry on a firewall rulebase. When the firewall receives

a packet, it compares it against the first rule, then the second, then

the third, etc. When it finds a rule that matches, it stops checking

and applies that rule. The rule numbering in this document is not

intended to dictate the actual rule numbers as they must appear in a

firewall, it simply defines the priority each rule should have in the

overall rulebase.

SNMP Simple Network Monitoring Protocol is used by network devices to

communicate with a monitoring agent.

SRC PORT This is the source IP port that was opened for the destination host’s

reply.

SSH

Secure Shell is a program to log into another system through a secure

connection over a network, to execute commands in a remote

machine, and to move files from one machine to another.

SSL / HTTPS Secure Sockets Layer uses a private key to encrypt data that is

transferred over the Internet. Usually HTTP traffic.

Syslog

Referes to RFC 3164 - BSD Syslog Protocol where the system logging

data connects to a server listening on UDP port 514 that collects the

stream of logging events and stores them in a data file for centralized

view and analysis of the log files.

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.



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.



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.



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.



9. INSIDE OUTPUT Firewall NMS_Internal ANY TACACS+ (49) TCP ACCEPT No

RADIUS – The newest authentication scheme adopted by Network Services will require the firewall to

authenticate firewall administrators against a RADIUS server on the trusted corporate network. 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.



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.



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.



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.



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.



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.



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.



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.



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.



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 "bogon space" routed to a "blackhole" 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.



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 by IT Security.

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



25. INSIDE INPUT Trusted INTERNAL Hosts

ANY ANY ANY ICMP8 ACCEPT No

26. OUTSIDE INPUT ANY Trusted ANY ANY ICMP0 ACCEPT No

INTERNAL Hosts

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


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.




ANY 32768 -65535

33434 - 33523 UDP ACCEPT No

30. OUTSIDE INPUT ANY Trusted INTERNAL Hosts






32768 -65535








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.



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.



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.



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.



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


ANY ANY ANY ICMP 8 ACCEPT No










ANY 32768 -65535








32768 -65535




ANY ANY ICMP 3 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.



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



C5. OUTSIDE INPUT ANY WEB_SVR TCP TCP(80) ACCEPT No

>1024

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


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



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


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.




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.




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",

URL:

[ONLINE]

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

Matt Curtin, Marcus J. Ranum

Internet Firewalls: Frequently Asked Questions

Date post:	08-Oct-2014
Category:	Documents
Upload:	gary-freeman
View:	925 times
Download:	1 times

Essential Firewall Policy Standards

Documents