Article

The Use of Routers in Firewall Setup

Matej Sustic

Contrary to some opinions, a good firewall does not mean high security even if implemented properly. Even the best firewall can be an easy target if it's not protected by other means. For example, a firewall (or a proxy server) runs on top of an operating system that contains code that is not used by the firewall or proxy. This code includes bugs that can be abused to gain access to the firewall software. Many firewall vendors replace the original IP stacks with their own, but the operating system still remains the same. Some packets are processed by the operating system kernel before the firewall application even gets a chance to inspect them. A good example is an ICMP redirect message, which informs a host about a better path to a destination. Therefore, access and separation routers are used in front and behind the firewall to protect the firewall and the network.

These routers must be properly set up though, otherwise they do not perform their intended function they are supposed to. Routers do not replace the firewall or the proxy -- they are complements to the firewall and enhance packet and stream inspection. I use the word firewall for both firewall and proxy unless there is a specific proxy feature or problem discussed. The examples listed in this article are based on Cisco's IOS with IP/Firewall features. Most router vendors provide similar functionality, and the rules can be adjusted for use with other routers. In this article, I assume that readers have a good understanding of the following protocols: IP, TCP, UDP, ICMP, and routing protocols. (All listings for this article are available from: ftp.mfi.com or the Sys Admin Web site at: www.sysadminmag.com).

Exposure and Threat Analysis

Every firewall implementation starts with exposure and threat analyses. There are several basic questions to be answered:

Where are the most exposed areas of the network?
Is this exposure necessary (e.g., because of the business requirements)?
Is the network a high-risk (high-profile) network that is an interesting target for hackers?
Why is it considered as such (is it a prominent brand name or just a convenient jump point for further attacks)?
What attacks are the most probable (denial of service, data corruption, data theft, impersonation, or eavesdropping)?

The most probable points of attack include Internet connections, dial-up points, misconfigured hosts (e.g., Web server), and physical access (including stolen laptops outside the company).

Every security implementation requires trade-offs. Higher security creates a sense of restriction and loss of productivity among users. It can also create situations when users connect modems to their workstations to bypass the “high-security firewall”. Too generous access, on the other hand, exposes the network to attacks. There should be a balance between security and access that does not impair users but does also not introduce security holes. One way of increasing security is by educating users and making them responsible for the overall security of the network. This balance is necessary for the users to cooperate.

Firewall Architecture

How does the access and separation router (Figure 1) improve security? The access router is the first packet filtering point. It represents a clear entry point, and it protects the firewall from the outside world. A firewall or a proxy server is usually a standard computer running either a UNIX flavor or Windows NT operating system, and on top of that runs a firewall application or a proxy application.

The firewall is the most exposed part of the network and usually the only server that can be attacked. Having multiple firewalls one behind the other does not help much. These boxes run on the same or similar operating system (all UNIX flavors derive from the same source code) and, if configured by the same person, will share the same vulnerabilities.

The separation router has two features. It ensures that no traffic bypasses the firewall. This becomes really important if the firewall is single homed (has only one Ethernet interface and the internal and external traffic flows on the same physical cable -- see Figure 2). The separation router also protects the firewall from the internal users that could attempt to “drill” a hole from the inside.

The following example is simplified. Assume we were requested to build a high security firewall for the company BCA, Inc. The requirements are:

The firewall must be as transparent as possible for internal users.
The firewall performs NAT (network address translation) for internal users.
Incoming traffic: SMTP and Web access to the mail and Web servers only.
Outgoing traffic: SMTP from the internal mail server to the outside world, POP3, and IMAP4 to the internal mail system to the internal personnel and Web from the Web servers to anywhere in the world. The company has decided that the rules must be inserted on a temporary basis only when there is a need for them.
There is a DNS server on the DMZ that is used by Internet users and by internal users.
Routing protocols: OSPF if it can be made secure.
The rest of the traffic should be blocked and logged.

Packet Filtering

Routers are dedicated computers designed and built for forwarding packets toward their destinations. But they can also be very selective. To achieve as high a level of security as possible, the packets must be inspected by different applications (if possible running on different operating systems) to eliminate the possibility of bugs. Filters are used not only to allow or disallow the traffic through the router -- they can also apply some other rules on the traffic, such as defining traffic to be checked for a possible SYN attack.

Cisco's synonym for filters is access lists. The access lists define the action (permit or deny), source and destination IP addresses, ports and protocols (e.g., TCP, UDP, etc.). Each line contains a logical rule. The whole list is executed from top to bottom. The following example permits traffic from any IP address to the SMTP port of host 208.194.25.67 (the numbers in parentheses are for reference purposes):

(1) access-list 101 permit tcp any host 208.194.25.67 eq smtp

The last rule of every access list is deny all. This rule can be specifically entered or it is implied (not listed when reviewing the running configuration).

How is a TCP connection established? The SYN and ACK flags in TCP/IP packets are used to establish and maintain a TCP connection (Figure 3). The source computer sends the request to establish a connection with SYN flag set. The destination host replies back with SYN and ACK. The source host acknowledges the establishment with a packet with ACK flag set only.

The described access lists remain in use even if there is no traffic. A hacker could potentially spoof the traffic and bypass the rules in the middle of the night when there is nobody in the office to monitor the firewall. How could we design a set of temporary or dynamic rules? Cisco has named such temporary rules reflexive access lists. These filters wait until the SYN packet arrives to the router in the outgoing direction. The SYN packet is checked by a standard or extended access list and, if it is allowed through the router, an access list in the reverse direction is implemented that permits the return traffic to the client. This reverse access list remains active for a limited time if there is no traffic (e.g., 30 sec). After the access list times out, it disappears from the router, which means the router would automatically shut all traffic down in the evening. Let's take a look at how to implement these reflexive access lists.

(2)  ip access-list extended acc-router-in
(3)  permit tcp any host 209.1.1.9 eq smtp
(4)  permit tcp any host 209.1.1.10 eq www
(5)  evaluate outgoing-dns
(6)  evaluate outgoing-smtp
(7)  evaluate outgoing-tcp-web
(8)  ip access-list extended acc-router-out
(9)  permit udp host 209.1.1.6 any eq domain reflect outgoing-dns
(10) permit tcp host 209.1.1.9 eq smtp any
(11) permit tcp host 209.1.1.10 eq www any
(12) permit tcp host 209.1.1.9 any eq smtp reflect outgoing-smtp
(13) permit tcp host 209.1.1.6 any eq www reflect outgoing-tcp-web

Line 8 starts the outgoing access list. Lines 9 through 13 define permitted outgoing traffic. Lines 10 and 11 define static permissions, while lines 9, 12, and 13 permit temporary access lists. As soon as a SYN packet arrives that fulfils one of the reflexive (temporary) access lists, a permission is entered into the table for incoming (returning) traffic. Lines 5, 6, and 7, which are part of the incoming access list definition, define that the returning (incoming) traffic is allowed based on the evaluation of the rules implemented by the access lists in lines 9, 12, and 13.

TCP Traffic

Most of the TCP filtering will happen on the firewall. The routers on both sides will assist in this process.

The access router will be the first line of filtering for the incoming TCP packets with similar ruleset as the firewall. It should also check for other things, such as the SYN flag in packets to determine the direction of the connection establishment and to block certain unnecessary ICMP packets (described later in the article).

Most firewall vendors claim that their products protect against SYN attack. This attack is very simple, but implementing a good protection against it is difficult. A hacker sends a flood of packets to initialize lots of TCP connections (SYN packets) and thus using all the system resources on the targetted system. The firewalls might protect against SYN attack if they use a replaced IP stack. If they use the standard operating system's stack, the firewall application will not even see the SYN attack. A proxy server is even more vulnerable for SYN attacks, because it terminates all TCP connections.

Can we block SYN packets on the router and spare the operating system of the server? Yes. The usual result of a SYN attack is a hung operating system caused by lack of resources (mostly memory, but it could also be CPU). Cisco has implemented a feature called TCP Intercept. The idea is simple: The TCP intercept feature helps prevent SYN-flooding attacks by intercepting and validating TCP connection requests. In intercept mode, the TCP intercept software intercepts TCP synchronization (SYN) packets from clients to servers that match an access list. The software establishes a connection with the client on behalf of the destination server. If successful, it establishes the connection with the server on behalf of the client and knits the two half-connections together transparently. Thus, connection attempts from unreachable hosts will never reach the server. The software continues to intercept and forward packets throughout the duration of the connection. During an attack, when lots of connections remain open, the router starts dropping the oldest ones if it gets more then 1,100 connection requests per second. The times and number of connections are configurable.

Next, we must set up the router to defend against a SYN attack (this function is implemented on high-end Cisco routers only -- check Cisco's documentation for exact models):

(14) access-list 120 permit tcp any host 209.1.1.9 eq smtp
(15) access-list 120 permit tcp any host 209.1.1.10 eq www
(16) access-list 120 permit tcp any host 209.1.1.6

This looks just like a regular access list. Well, it is. This list details the traffic to be inspected for possible SYN attacks. The difference is in the implementation of this access list. A regular access list is attached to an interface and, at that point, a direction relative to the interface is assigned (incoming or outgoing). In the case of the SYN attack protection, this access list must be implemented in global configuration mode (not the interface configuration mode):

(17) ip tcp intercept list 120
(18) ip tcp intercept mode intercept
(19) ip tcp intercept drop-mode oldest

Line 17 defines that access list 120 defines the interesting traffic. Cisco has developed two modes of preventing the SYN attack. The more aggressive protection is the “intercept” mode where the router actually intercepts all SYN packets and first tries to fully establish a connection with the client before forwarding the SYN packet to the real server. The other mode is “watch” mode, where the router watches the connections until they are fully established. The router does not intervene unless the connection is not established within 30 seconds. In this case the router sends a RST packet to the server to close the connection. Line 18 defines the intercept mode, and line 19 defines that the oldest open connections are the ones to be closed in case of too many open connections.

UDP Traffic

UDP traffic does not have a traffic flow control, such as SYN and ACK flags. Connections are not established prior to sending traffic. In most cases, the only UDP traffic that a network needs from the outside world are DNS (domain name resolution) and NTP (network time protocol for time synchronization).

There are applications that use UDP as a transport layer. If they are properly written, only one or two ports are used. I have seen applications, however, that used 512 different ports randomly. Opening all 512 UDP ports on the firewall to accommodate the application requirements would minimize the efficiency of the firewall to the point where one could start questioning the security level provided by this firewall. In such cases, it is important to educate the client about the danger of using such applications.

Cisco IOS can inspect a TCP or UDP packet stream. Context-Based Access Control feature (CBAC) provides advanced traffic filtering. The application layer information in a packet stream is inspected. For example, a TCP SMTP stream is inspected, and packets with invalid SMTP commands are dropped before they even reach the mail server. Or, CBAC denies the establishment of an ftp data connection without prior authentication through a control connection. CBAC also inspects UDP streams and approximates UDP traffic into a UDP connection. While this feature is not a real inspection of the traffic, it does detect DoS attacks and port scanning.

I'll use CBAC as an example for inspecting a DNS traffic that's coming from the DNS server back into the private network. This would be implemented on the separation router.

(20) ip inspect dns udp timeout 15
(21) interface ethernet 0
(22) ip inspect dns in
(23) ip access-group 110 in

Line 20 defines that a “connection” will time out if the stream of packets stops for more than 15 seconds. The DNS inspection rule is applied to the interface in line 22. There is an access list applied to the same interface. Only the traffic that is allowed through by the access list will be inspected. The returning permissions will be applied only to the traffic that is allowed to exit and will be valid only for the duration of the “connection”.

The return traffic is allowed by applying temporary access lists to the opposite interface in the reverse direction. As mentioned before, every access list has an implied “deny all” at the end. What will happen if there is some traffic that should go through but this decision is not based on CBAC? By default, as soon as some traffic is allowed back through CBAC, all other traffic that is not specifically permitted will be denied. Therefore, an access list should be implemented in the reverse direction specifically allowing traffic that is allowed by default (line 23).

ICMP Traffic

Most of the ICMP packets are processed within the firewall operating system's kernel before they even reach the firewall software. This is the most important reason to implement routers in front of the firewall.

ICMP traffic handling depends on the internal policies. This traffic is not required, but it's useful. The traffic that belongs into this category is represented by ping, traceroute, and ICMP redirects in most cases. ping and traceroute are network debugging tools. ping uses ICMP echo and ICMP echo-reply packets.

There are two traceroute implementations. The standard implementation requires the source host to send UDP packets to a high number UDP port (larger than 30,000) with a TTL=1, which bounces back from the first network device with an ICMP unreachable packet. Then, traceroute increments the TTL to 2 and sends the packet out again. The packet bounces back from the second network device with the same message as before. When the TTL is high enough to reach the destination, there is nothing listening on that high UDP port; therefore, the host sends back the ICMP port unreachable packet. Microsoft has somewhat changed the standard so that it sends out ICMP echo-request packets instead of UDP packets (the TTL still starts at 1 and is incremented for each hop). This complicates filtering of traceroute.

ICMP redirect packets are sent by the router in case a packet arrives, but the router knows it should be sent to another router that is closer to the destination instead. In this case, the router that has received the packet forwards it to the next hop router considering its own routing table. At the same time, it sends an ICMP redirect message to the previous hop router. These packets should be ignored by the router because they can be faked. Most firewalls do not ignore these packets because the handling of these packets is implemented in the operating system kernel. The ICMP redirects should be blocked by the use of access lists, and the firewall routers should not send these packets. To disable sending ICMP redirects, implement the following command on the interface(s):

(24) no ip redirects

Ignoring the ICMP redirects is a more complicated issue. If ICMP is blocked altogether, then ICMP redirects are blocked as well. If, on the other hand, ICMP is allowed and only ICMP redirects are to be blocked, the following access list should be attached to every interface on the router:

(25) access-list 105 deny icmp any any redirect

ICMP unreachables are sent back to the source if the source host wants to connect to a network, host, or port that does not exist. Most of the port scanners try to connect to a random port number on the target machine trying to figure out which connectivity is allowed. The port scanners expect either a SYN/ACK packet or an ICMP unreachable back. If the ICMP unreachables are not returned, the destination acts as a black hole for the packets -- the source has to time out, which means that instead of getting an answer in say 500 ms it will never receive a reply and will have to wait for a timeout. Timeouts are usually set to 30s. Port scans would take days instead of hours for such a destination. A UDP port scan would report all ports open, which would not help a hacker (it would look like the servers listens on all UDP ports). With use of the following command on every interface, the unreachables will not be sent back to the source:

(26) no ip unreachables

There is another type of ICMP that must be disabled. If a remote host tries to investigate the network topology, it sends out a request for a network mask. Routers, which have this option enabled, will reply. This represents an unnecessary help for the hacker. This option can be disabled by executing the following command on all router's interfaces (it's disabled by default, but it does not hurt to check it):

(27) no ip mask-reply

Other ICMP traffic can be usually filtered out without consequences.

Anti-Spoofing

A spoofed packet has a faked source address (usually an internal address of the targeted network). A couple of simple access list rules prevent spoofing attacks.

Incoming filters on the access router:

(28) ip access-list 160 deny host 209.1.1.6 any
(29) ip access-list 160 deny host 209.1.1.9 any
(30) ip access-list 160 deny host 209.1.1.10 any
(31) interface s 0
(32) ip access-group 160 in

Incoming filters on the separation router:

(33) ip access-list 160 deny 10.0.0.0 0.255.255.255 any
(34) interface e 0
(35) ip access-group 160 in

The access router should not forward any packets that arrive to its external interface and have a source address from the range of IP addresses that are used behind the router (between the router and the firewall, and in the DMZ). The separation router should not forward any packets that arrive to its external interface (interface facing the firewall) and have a source address of a host on the internal network.

Other Traffic

Every network has some specific requirements that cannot be “sorted” into any of the standard traffic classes. The designer should take a sound approach and analyze the protocols used and evaluate risks.

Dynamic hosts (roaming users using dial-up access) represent one example. These users do not have a static IP, but should still be able to enter the corporate network. Unfortunately, this is one of the situations where vendors have taken different approaches due to a lack of a good standard. Microsoft has developed the PPTP, Sun Microsystems uses SSL access, etc. With the development of the IPsec this should become a standardized application. Cisco already supports IPsec in its latest release of the IOS; Microsoft promises it in Windows 2000 at the time of writing. If the compatibility issues are resolved, users will be able to dial into the closest POP (e.g., the local ISP) and establish an IPsec tunnel into the access router in front of the firewall.

Another example is encrypted VPN connections between remote locations. These protocols use IP as the lower layer but do not use either TCP or UDP for the transport. They use their own protocol numbers within IP. The Generic Router Encapsulation (GRE), which can transport encrypted headers and payload, uses protocol number 47. IPsec uses protocol numbers 50 and 51. Some popular firewall applications have problems opening holes for specific protocol numbers other than 6 (UDP) and 17 (TCP). Proxy servers do not have a flexible setup features set to allow this at all. I ended up opening all traffic between two specific IP addresses due to the lack of functionality on the firewall, but because I was using the access router, was able to limit the protocol number on that router.

Routing

Routing protocols are used to inform the routers (including the firewall or proxy server) about changes in network topologies. Hackers try to fake routing packets in order to create routing loops (DoS attack) or route the traffic through a box that they control (eavesdropping and data stealing).

The basic rule is that the separation router, the access router, and the firewall should not accept any routing protocols that do not support either encryption, a digital signature, or authentication of routing packets. If the firewall understands only RIPv1 routing protocol, RIP should be disabled because it does not support any of the above security measures. Static routes should be used instead. Static routing quickly becomes an administrator's nightmare unless it's very simple.

Some routing protocols have the option of encrypting, signing, or authenticating routing packets. These options are supported on the routers, but it's sometimes difficult to implement them on the firewall. If the firewall does not support them, static routes are the only option.

The following is an example of setting up static routes on a Cisco access router (see Figure 2):

(36) ip route 0.0.0.0 0.0.0.0 Serial0
(37) ip route 201.1.1.1 255.255.255.255 201.1.1.2
(38) ip route 10.0.0.0 255.0.0.0 Null0
(39) ip route 172.16.0.0 255.240.0.0 Null0
(40) ip route 192.168.0.0 255.255.0.0 Null0

The default route (line 36) points toward the Internet, so all packets that end up on our network by misconfiguration of other devices are sent back to the Internet. Only the packets that have proxy server's external IP address for destination are forwarded to the proxy (line 37) -- this line does not fit in our overall example but it is used here to demonstrate a specific routing rule. Use as specific routing rules as possible.

Lines 38, 39, and 40 create a drain for the private IP addresses. Null 0 device on Cisco routers is equal to /dev/null on UNIX -- it's a much faster way of filtering out packets than access lists.

The following routing protocols support encrypted authentication:

OSPF
RIPv2
BGP, and
EIGRP (Cisco proprietary)

Let's take a look at an OSPF example. OSPF supports MD5 authentication, and it can be used if the firewall itself supports it. Setup of the access router in this case looks like:

(41) router ospf 2
(42) network 201.1.1.0 0.0.0.255 area 2
(43) network 202.1.1.0 0.0.0.255 area 2
(44) area 2 authentication message-digest

OSPF configuration starts with line 41. Lines 42 and 43 list all networks that the access router announces and the area to which they belong (the explanation of the OSPF protocol is beyond the scope of this article, and it is assumed that the reader understands it). Line 44 defines that MD5 authentication is used for OSPF packets in area 2.

There is an option to provide a route to the specific destination within the IP packet. This option is called source routing. The routers should ignore source routed IP packets. These packets are not used for everyday Internet traffic and are usually attempts to reach a destination that is prohibited. The source routed packets will be ignored by applying the following global configuration command on the router:

(45) no ip source-route

Intrusion Detection

This article does not describe the software tools for intrusion detection, but routers can be easily used to log all denied packets to a syslog server. A simple script can be created to run over these logs every 10 or 15 minutes and search for repeated patterns of packets. This is a very simplified intrusion detection technique, but it's better than none. It will also detect attempts to telnet (connect) to the router itself.

Cisco routers log to a syslog utility using default local7 as the destination:

(46) logging trap warnings
(47) logging 209.1.1.5

Logging defines the level (line 46) and the server's IP address or hostname (47). The server collects all messages from the routers and writes them to a log file. Routers report multiple duplicate log entries as one line item with the number of duplicates to save disk space.

Securing the Routers

The access and separation routers are of no use if they are not secured themselves. All minor services on the router should be shut down:

(48) no service tcp-small-server
(49) no service udp-small-server
(50) no service finger

Lines 48 and 49 shut down the basic TCP and UDP minor services, such as echo, discard, chargen, and daytime ports. Let's take a look at one example of DoS attacks using UDP small servers. There are two routers on a low-speed serial line (Figure 4). A hacker sends a stream of packets to the echo port of the router2 with the source port and address of echo port on the router1. The routers start sending back and forth these packets and saturate the line. Line 50 shuts down the finger service (which is very similar to the UNIX finger command) and reveals the usernames created and logged in on the router.

The router should not accept any telnet connection request. The telnet application sends passwords in clear text over the network. If there is an eavesdropper on the network, he or she can intercept the password and change the router configuration.

(51) access-list 99 deny any log
(52) line vty 0 4
(53) access-class 99 in
(54) no login

Line 51 defines an access list that does not allow any traffic, and it logs all matching packets to the syslog server. This access list is then applied to the virtual interfaces vty, which are used to terminate telnet sessions on the router. Altogether no telnet traffic is allowed to the router, and any attempts to connect to the router are logged to the syslog server.

A similar problem exists with the management protocol SNMP version 1. The passwords, called community strings, are sent over the network in clear text. SNMP distinguishes between read-only and read-write community strings. Shut down SNMP with the following command:

(55) no snmp-server

SNMP is useful, so a read-only community string can be defined to collect the statistics from the router, but it would not allow any changes to the router's configuration:

(56) snmp-server community asdf ro

asdf is a community string (password) used to collect statistics in this example. Another option is to use filtering and allow SNMP access only from your management workstation in addition to using the community string:

(57) snmp-server community asdf 1300

Access list 1300 has to define which hosts the SNMP requests may come from.

Cisco Discovery Protocol is a proprietary protocol designed to allow routers to discover each other and perform automatic self-configuration. The protocol does not use any encryption or authentication, and it should be shut down with the following global command:

(58) no cdp run

Another protocol that should be shut down on the router is the NTP (Network Time Protocol). Perform the following command on all interfaces where NTP is not needed:

(59) ntp disable

The router uses proxy ARP, as defined in RFC 1027, to help hosts with no knowledge of routing determine the media addresses of hosts on other networks or subnets. For example, if the router receives an ARP request for a host that is not on the same interface as the ARP request sender, and if the router has all of its routes to that host through other interfaces, then it generates a proxy ARP reply packet giving its own local data link address. The host that sent the ARP request sends its packets to the router, which forwards them to the intended host. Proxy ARP is enabled by default. The firewall router should not respond to ARP requests (except for its own interfaces); therefore, this service should be shut down by executing the following command on its interfaces:

(60) no proxy-arp

Conclusion

Routers are not a replacement for a good firewall -- they are complements. As every bank has several layers of security guards in front of its safe, so should a well-protected network have several layers of packet protection. Each layer should be using a different technology so that packets are checked several times using the same set of rules. Features could be similar, but some technologies offer us specific options that cannot be found in standard firewalls.

This article has provided some ideas on how to protect a firewall or a proxy server by using a couple of routers around it. The article is by no means a full tutorial on how to build a protected firewall. This subject is very complex and the implementation depends on actual requirements and situations.

The author does not accept any responsibility whatsoever for any consequences that might arise from using or omitting the methods and ideas mentioned in this article.

Literature

Cisco Connection Online (http://www.cisco.com).

Security Seminar, Roland Acra, Cisco Systems.

TCP/IP Illustrated, W. Richard Stevens. 1994, Addison-Wesley.

Building Internet Firewalls, D. Brent Chapman and Elizabeth D. Zwicky. 1995, O'Reilly & Associates.

About the Author

Matej Sustic is based in Vancouver, BC (Canada) and works as an independent network and security consultant in western Canada. He has been working with ISPs in Europe and Canada for the past six years. He is a Cisco Certified Network Professional. Matej can be reached at: msustic@european-consultants.com.