Firewall Deployment

Now that you have become familiar with the types of firewall technologies, it is time to discuss deploying your firewall(s). We give a number of examples that can be used in real-world scenarios to configure your firewall appropriately. Our rule set examples reflect more that of a stateless or stateful packet filter; however, the concepts themselves apply broadly to all firewall technologies.

What Is Your Default Security Posture ?

You will have to make an important decision before you configure your firewall: What is the default security posture of your firewall? What we mean by this is, will your firewall use a default open or a default closed policy? A default open policy (not recommended) allows all traffic to pass unobstructed, while blocking or dropping protocols and applications that have been explicitly specified.

A default closed policy, on the other hand, blocks or drops all network traffic unless it has been explicitly allowed (recommended).

This distinction is not a deciding factor when choosing the appropriate technology, as all firewalls will support both scenarios, but rather it will define how you create your firewall rule sets. A default closed policy is considered more secure, since only explicitly allowed traffic is permitted. This posture works well for most organizations who seek to allow only specific protocols in and out of their networks. For many academic institutions, however, this is not feasible due to the inherent open nature of their computing environments.

While these two postures are extremes, many firewalls today in practice provide a default closed posture for incoming traffic and a default open posture for outgoing connections. This allows for easy initial configuration but does not have the advantages of a bidirectional default closed policy. A default closed policy for outgoing connections provides some measure of protection against malicious code or other unauthorized software that may be attempting to "phone home" by connecting outside of your firewall. While this is not perfect, and the attacker can simply choose to use an allowed port, it will certainly thwart some attempts.

Your decision here will impact how you proceed to create your firewall rules. If you have a choice, a default closed policy is the way to go. By specifically defining which applications will be permitted through your firewall, you significantly decrease the vulnerability surface of your organization; there are no unknown or hidden vulnerable applications that attackers can access since you have defined everything that is accessible.

Most firewalls by default block all incoming traffic unless the administrator has decided to reverse this. Services must be enabled one by one in order to allow incoming connections.

What Applications Will Be Permitted In and Out of Your Network?

How you configure your firewall, and the applications that you permit, will depend on your default security posture. This will in turn drive how you both discover existing in-use applications and how you go about creating your policy.

Default Closed Security Posture

If you are starting with a default closed posture, your next step will be to determine which applications will be permitted through your firewall. There are several approaches that you can use to determine this:

• Derive them from your security policy. If your policy is specific enough, you will be able to derive the applications that will be permitted based on that policy. If your policy is not specific enough to derive this, you may want to consider revising this policy. If your policy does not dictate whether HTTP access should be permitted in and out of your network, it needs revision!

• Monitor your network using one of many network-monitoring tools to determine which applications are being used to communicate in and out of your network. You will want to evaluate this list, and eliminate any applications that you are either not aware of or that may present security risks. It is important to gather information about the protocols being used at all network layers .

• Another way to gather this information is to examine Netflow data from your routing infrastructure. This will provide you with an in-depth view of both inbound and outbound sessions. Netflow data can provide the following information useful to base- lining your network traffic:

  • Source and destination IP address

  • Source and destination TCP/UDP ports

  • Type of service (ToS)

  • Packet and byte counts

  • Start and end timestamps

  • Input and output interface numbers

  • TCP flags and encapsulated protocol (TCP/UDP)

  • Routing information (next-hop address, source Autonomous System Number (ASN), destination ASN, source prefix mask, destination prefix mask)

Default Open Security Posture

If you are starting with a default open security posture, which is not recommended, then your goal is reversed . Since you are already allowing all applications through your network, you will want to block applications that could pose security risks. Some of the common applications and protocols that you will want to consider blocking are presented here. While this list is by no means complete, it should serve as a good start against some of the most commonly targeted network services.

Service (Port)	Service Description
echo (7/UDP, 7 TCP)	A debugging tool to send any requests back to the originator. This poses a risk as it can be used to launch a denial-of-service attack.
discard (9/UDP, 9/TCP)	Another debugging tool where data is sent to port 9 and the recipient simply throws it away. This data can be either a UDP packet or a TCP stream that is opened until closed by the sender.
chargen (19/UDP, 19/TCP)	Generates random characters either in one UDP packet or a TCP session. The UDP chargen server looks for a packet and responds with a packet of random characters . With TCP, the server sends as a continuous stream of packets once a connection is made until the session closes . Attackers can cause a denial-of-service attack by spoofing an IP address and causing two devices to send random traffic to each other.
telnet (23/TCP)	Allows you to remotely login to a system. Unfortunately, all session data is sent in plaintext (not encrypted) and anyone monitoring the network can sniff the username and password.
smtp (25/TCP)	Should only be allowed to your mail servers. Exposing smtp from the Internet on a widescale basis can expose servers that may unknowingly be running an smtp service.
tftp (69/UDP)	Has been plagued with security problems for years . It has also been used by worms to transfer worm code. While current versions may have resolved past vulnerabilities, there should never be a valid reason to permit this protocol in or out of your perimeter.
finger (79/TCP)	Allows for information gathering, and has also contained vulnerabilities in the past. It allows for the listing of logged-in users and should be blocked.
sunrpc (111/UDP, 111/TCP)	More commonly known as the portmap service. Provides a catalog of all other SunRPC services on a system. Many SunRPC services in general are not secure, and it is not recommended that you deploy these services on the Internet.
msrpc (135/UDP) msrpc (135/TCP)	Microsoft RPC services. These services are used primarily for local area networking, and have contained vulnerabilities in the past. 135/TCP was the target of the Blaster worm.
netbios-ns (137/UDP)	The NetBIOS name service. Used predominantly by Windows networking for local network file sharing and the resolution of local computer names . This service should not be permitted in from the Internet.
netbios-dgm (138/UDP)	The NetBIOS datagram service. Also used to support Windows networking and should not be permitted from the Internet.
netbios-ssn (139/TCP)	The NetBIOS session service. Provides the actual file sharing for Windows networking. It should be blocked at the perimeter.
snmp (161/UDP, 161/TCP)	The Simple Network Management Protocol. Should be filtered at your perimeter. In some cases you may require this to monitor edge devices; however, specific rules should permit those devices into your network.
microsoft-ds (445/UDP) microsoft-ds (445/TCP)	Microsoft directory service. Provides many of the identical services as netbios-ssn (139/TCP). It should be filtered along with other NetBIOS service ports.
rpcepmap (593/TCP)	Provides another interface to the Microsoft RPCSS service. It should be blocked to prevent exploitation of well-known vulnerabilities.
exec (512/TCP)	Allows remote command execution using a plaintext username and password.
biff (512/UDP)	Also known as the comsat service. Allows local notification when new mail has arrived. It relies on unauthenticated UDP and should not be permitted from the Internet.
login (513/TCP)	The remote login service relies on IP address authentication or on a plaintext password in order to authenticate.
who (513/UDP)	The rwhod daemon provides details on logged-in users, as well as system uptime information.
shell (514/TCP)	The remote shell service relies purely on IP address authentication, and is not recommended even on your intranet!
syslog (514/UDP)	Allows for logging of system log messages. It should not be permitted in your perimeter as it can allow an outsider to write messages to your system logs.
printer (515/TCP)	The lpd service allows printing from either local or remote systems.
talk (517/UDP) ntalk (518/UDP	UDP-based services that allow network users to have a discussion. They have no authentication and given today's alternatives should not be permitted inside your perimeter.
ms-sql-s (1433/UDP, 1433/TCP)	The Microsoft SQL server database resides on this port. Unless you permit outsiders into your databases, block this port!
ms-sql-m (1434/UDP, 1434/TCP)	The Microsoft SQL locator service was the target of the Slammer worm. This port should be blocked at the perimeter.

Note 

It should be noted that many threats target the msrpc, netbios-ns, netbios-dgm, netbios-ssn, and microsoft-ds services. It is recommended that all NetBIOS ports are blocked at the perimeter.

Building Your Rule Set

Once you have defined your applications, then it is time to build your firewall rule set. Almost all firewalls today process rules serially , which means that the first rule that matches a packet will decide its fate.

It is important to note that rules can be as general or as specific as you like. They can accept or filter

• An entire protocol

• A specific IP address or ranges of address

• A specific port or ranges of ports

If your default security posture is closed, then your rules will define applications that will be permitted through your firewall. Before defining allowed applications, you will want to define any ingress/egress rules in order to prevent spoofed addresses, since the first matching rule would otherwise permit the packet to be forwarded. You will want to define rules that are processed as follows in a default closed posture:

 FORWARD IF packet's protocol matches AND packet's source IP address matches AND packet's destination IP address matches AND packet's destination PORT matches 

Then you will add a default closed rule to deny all remaining traffic:

 DENY ALL 

Or

 DENY IF packet's protocol is ANYTHING AND packet's source address is ANYTHING AND packet's destination address is ANYTHING AND packet's destination port is ANYTHING 

If your default security posture is open, then your rules will define applications that will be blocked at your firewall:

 DENY IF packet's protocol matches AND packet's source IP address matches AND packet's destination IP address matches AND packet's destination PORT matches 

You will then want to add any ingress/egress filtering rules, followed by a default open rule in order to allow all remaining applications:

 ALLOW ALL 

Or

 ALLOW IF packet's protocol is ANYTHING AND packet's source address is ANYTHING AND packet's destination address is ANYTHING AND packet's destination port is ANYTHING 

Implement Anti-spoofing Measures

Spoofing attacks have become increasingly prevalent on the Internet, and network administrators should take every precaution possible in order to minimize their impact. It will never be possible to prevent all spoofed packets from passing through your perimeter, but there are clear situations where specific source addresses should never be seen. This involves preventing both spoofed addresses from entering your network, and preventing spoofed addresses from leaving your network. In order to implement this, you will need to implement both inbound and outbound rules. There are two mechanisms that can be used to do this:

• Traditional access control lists (ACLs) as described in RFC 2827

• Unicast reverse- path forwarding

Access Control Lists

Access control lists are implemented using the native access control mechanism on your firewall or router. Their role is to filter out packets that should clearly not be seen entering or leaving your network.

Do not allow packets that have a source address on your internal network out to the Internet. For example, if your internal network's address is 204.69.0.0/16, then any traffic originating from this network should be in that address range. Apply a rule as follows in order to deny any packets that aren't:

 IF packet's source address is not 204.69.0.0/24 THEN deny packet IF packet's source address is anything else THEN continue processing rules 

Do not let packets that have a source address the same as your internal network in from the Internet. For example, if your network's address is 204.69.207.0/24, then add an inbound rule to evaluate packets in the following way:

 IF packet's source address from within 204.69.207.0/24 THEN deny packet IF packet's source address is anything else THEN continue processing rules 

In addition to filtering spoofed packets, it is also important to prevent packets from unroutable or reserved address space from both entering and originating from your network. Three ranges of networks have been defined in RFC 1918 as reserved. Additional network ranges have also been defined that should not be routed. The following network ranges should be filtered at your perimeter:

 10.0.0.0/8                   RFC1918 172.16.0.0.0/12              RFC1918 192.168.0.0/16               RFC1918 169.254.0.0/16               Zero Configuration Networking 127.0.0.0/8                  Loopback Interface 0.0.0.0/8                    Should never be seen 

Now you should have a good understanding of building your firewall rule set, and implementing ingress/egress rules. The most important aspect of building these rules is to think of a packet flowing through your rule set. A single mistake in the ordering of this rule set can result in an unprotected network.

Unicast Reverse-Path Forwarding

More effective than a traditional access control list is unicast reverse-path forwarding (uRFP). uRPF uses a devices routing table to determine whether a source address is acceptable. A packet is accepted if the route to the source of the packet (the reverse path) points to the interface the packet came in on. If not, the packet is considered spoofed and rejected. Packets are processed as they enter an interface on the device, not as they leave.

uRFP will only be applicable to routers in most cases and as such may or may not be present on your firewall. If you do have the option to use it, it is heavily recommended on routers either in front of or behind your firewall.

There are two modes of uRFP: strict mode and loose mode. In strict mode, the incoming packet is checked to see if the source address matches a prefix in the routing table, and whether the interface expects to receive a packet with this source address prefix. If it doesn't, the packet is not accepted on the interface. When a packet is not accepted on an interface, unicast RPF counts the packet and sends it to an optional fail filter.

In loose mode, the incoming packet is checked to see if the source address matches a prefix in the routing table; however, the interface is not checked to see whether a packet is expected.

In-depth configuration details for both Cisco and Juniper routers can be found at both the Cisco and Juniper web sites. (See the section "Recommended Reading" later in this chapter.)