General Design Considerations for Secure Networks

• By Sean Convery.
• Sample Chapter is provided courtesy of Cisco Press.
• Date: Jun 18, 2004.

Chapter Information

Contents

1. Physical Security Issues
2. Layer 2 Security Considerations
3. IP Addressing Design Considerations
4. ICMP Design Considerations
5. Routing Considerations
6. Transport Protocol Design Considerations
7. DoS Design Considerations
8. Summary
9. Applied Knowledge Questions
10. References

Chapter Description

At the beginning of any secure network design project, many best practices apply more or less uniformly to all areas of the design. This article by Sean Convery presents these practices in a single location.

From the Book

Network Security Architectures

$52.00(Save 20%)

ICMP Design Considerations

One way to spot inexperienced secure network design is to look for networksthat completely block Internet Control Message Protocol (ICMP) traffic. As anyoperator of all but the smallest networks will tell you, troubleshooting anetwork without ping is very frustrating, bordering on impossible. That said,ICMP messages should not be enabled everywhere without reservation. Somesecurity considerations must be understood, just like for any other protocol.This section assumes basic ICMP understanding. Refer to your favorite TCP/IPbook for background or read RFC 792.

ICMP security can be a very lengthy discussion because lots of nasty thingscan be done with ICMP messages when scanning networks or trying to gain a covertchannel. If you are interested in this sort of thing, Ofir Arkin's papertitled "ICMP Usage in Scanning" is available athttp://www.sys-security.com/archive/papers/ICMP_Scanning_v2.5.pdf.Rob Thomas has some guidelines for ICMP filtering that are available here:http://www.cymru.com/Documents/icmp-messages.html.

The basics behind ICMP design considerations are to define how much ICMPtraffic you should allow on your network and which messages types you shouldfilter.

ICMP Rate Limiting

Because ICMP is a troubleshooting and error-reporting tool, there should be alimit to the amount of ICMP traffic you see on a given network. For example, ona 100 Mbps Ethernet link, you might block ICMP traffic that exceeds 500 Kbps. Atechnology called committed access rate (CAR) enables this sort of filtering andis discussed later in this chapter.

ICMP Message Type Filtering

As Chapter 2 discussed, your own security policies and threat models might bedifferent from those assumed here. Deploying filters throughout your internalnetwork to permit only the ICMP message types required would be difficult. As afirst step, focus on possible boundaries of trust between two networks. Yournetwork will have its own trust boundaries, but here are a few to get youstarted. Zones of trust are detailed more fully in Chapter 12, "DesigningYour Security System."

• Internet and internal network

• Management network and production network

• Critical applications and production network

An easy first step in ICMP filtering is to deny any ICMP message that is afragment. First, the ICMP messages you must permit are generally small. Echo andecho reply, for example, default on BSD UNIX to 84 bytes: 20-byte IP header,8-byte ICMP header, and 56 bytes of ICMP data. Other required ICMP messages aresimilarly small and come nowhere near the minimum link size on today's IPnetworks. Blocking ICMP fragments is easy using an ACL:

access-list 101 deny icmp any any fragments

WARNING

The fragments keyword in a Cisco ACL has some special use rules. For adetailed discussion of this, including flow charts and examples, check the paperat the following URL:http://www.cisco.com/warp/public/105/acl_wp.html.

As a quick summary of the paper, the fragments keyword applies only tononinitial fragments (fragment offset > 0), so in the preceding example, thefirst part of a fragmented ICMP packet will not match that entry, while allsubsequent fragments will.

When filtering ICMP messages between trust boundaries, apply the securityprinciple "Expressly permit, implicitly deny." Though your specificrequirements may vary, the following ICMP types should be permitted in someform:

• ICMP echo request and ICMP echo reply

• ICMP destination unreachable—fragmentation needed but DF bitset

• ICMP time exceeded

ICMP Echo Request and ICMP Echo Reply

ICMP echo request (Type 8 Code 0) and ICMP echo reply (Type 0 Code 0) arebetter known as the message types used by theping command. The format ofan ICMP echo message has the standard 8 bytes of ICMP header information andthen allows for a variable-length data field that can contain any kind of data.Certain size ping packets caused system crashes on some older OSs. This attackwas commonly called the Ping of Death. More information can be found here:http://www.insecure.org/sploits/ping-o-death.html.Permitting ICMP echo can lead to DoS attacks and buffer overflows as discussedin Chapter 3. It can also lead to a covert channel because information can beembedded into the data field in the ICMP echo message. An attacker that installsspecial software on a host internal to your network could communicate back andforth using only ICMP echo request or reply messages. Covert channels have beenimplemented in many different protocols, and they are impossible to completelyeliminate. So, with these risks, it is understandable why a security engineerwould want to stop ICMP echo messages. Unfortunately, troubleshooting would befar too difficult without it making your overall network less secure in mostcases. With all that said, here are the best practices:

• Permit ICMP echo request messages to leave your network destined for anynetwork you have reason to communicate with.

• Permit ICMP echo reply messages to your internal hosts from any networkyou have reason to communicate with.

• Permit ICMP echo request messages from external hosts to servers theymust access (public web servers, for example). As of this writing, a randomsampling of top websites yielded several that block inbound pings to theirservers and several more that permit them. As an organization, you must weighthe risks of allowing this traffic against the risks of denying this traffic andcausing potential users troubleshooting difficulties.

• Permit ICMP echo reply messages from any server system to the networkswhere that server's users reside. Echo replies from your public web serverto the Internet at large is an example of this.

• Deny every other ICMP echo message.

As an example, consider the very simplified Internet edge shown in Figure6-15.

Figure6-15 Simple Internet Edge

If you were writing ICMP echo access lists for router "police," theinbound Serial0 ACL would look like this:

! permit echo-request to Serial0 interface of the routeraccess-list 101 permit icmp any host 192.0.2.2 echo! permit echo-request to public serveraccess-list 101 permit icmp any host 126.0.64.10 echo! permit echo-reply from anywhere to the internal network and the public serveraccess-list 101 permit icmp any 126.0.128.0 0.0.0.255 echo-replyaccess-list 101 permit icmp any host 126.0.64.10 echo-reply

The ACL on the inbound Ethernet0 interface would look like this:

! permit echo-request from the internal network to anywhereaccess-list 102 permit icmp 126.0.128.0 0.0.0.255 any echo

The ACL on the inbound Ethernet1 interface would look like this:

! permit echo-request from the public web server to anywhereaccess-list 103 permit icmp host 126.0.64.10 any echo! permit echo-reply from the public web server to anywhereaccess-list 103 permit icmp host 126.0.64.10 any echo-reply

Based on these ACLs, internal users can ping the web server and the Internet,the Internet can ping the web server, and the web server can ping the Internet.Of special note is that the web server cannot ping internal hosts. Based on yoursecurity policies, you can permit this to aid in troubleshooting, but be awarethat many organizations consider public servers to be not much more trusted thanthe Internet. To make the change, you would add this line to the Ethernet0ACL:

access-list 102 permit icmp 192.0.128.0 0.0.0.255 host 192.0.64.10 echo-reply

NOTE

Cisco router ACLs can be applied inbound or outbound on a given interface.Security folks, myself included, tend to prefer inbound ACLs, but there aresituations in which you must use both and situations in which an outbound ACLmakes more sense. I prefer inbound because the packets are blocked before theycross the router. Outbound ACLs allow the packet to be routed by the router andthen are blocked when they try to leave. This could leave the router open tocertain attacks.

Another special note on Cisco ACLs is that ACLs never apply to trafficgenerated by the router. So, even if you have an inbound and an outbound ACL ona router denying all traffic, the router will still be able to send any packetit wants; the return packet, however, will be blocked as usual.

ICMP Destination Unreachable—Fragmentation Needed but DF Bit Set

ICMP destination unreachable messages (type 3 code 0–15) are a wholerange of messages designed to alert the sending system that something is wrongwith a particular message sent. This includes specific errors such as networkunreachable (code 0), host unreachable (code 1), protocol unreachable (code 2),and port unreachable (code 3). These types of messages are generated by hostsand routers when a sending system tries to go somewhere that is unreachable forwhatever reason. Many security administrators block most type 3 messages becausethe sending host will often figure out that the service is unavailable on itsown without the benefit of the ICMP message (albeit more slowly). One message isrequired though: "fragmentation needed but DF bit set" (type 3 code4). This message is required for path Maximum Transmission Unit (MTU) discoveryto work. Path MTU discovery is the method most hosts use to determine the IP MTUsize for their traffic. Without it functioning properly, large TCP segmentscould be dropped without a means to remedy the problem because the offendinghost never knows why the drop occurs.

Path MTU discovery has some interesting implications in IPsec and isdiscussed in more detail in Chapter 10, "IPsec VPN DesignConsiderations."

ICMP type 3 code 4 messages can be easily permitted by adding the followingline to the ACLs built for Figure 6-15:

access-list 101 permit icmp any any packet-too-big

ICMP Time Exceeded

ICMP time exceeded: Time-to-Live (TTL) equals 0 during transit (type 11 code0) is required because it is used by traceroute. To permit these messages, addthe following line to the ICMP ACLs you have seen in this section:

access-list 101 permit icmp any any time-exceeded

ICMP Filtering Recommendations

As you can see, there was a reason that ICMP was created beyond as aplayground for attackers. Although most of the 15 ICMP message types can beblocked, several are necessary to the healthy operation of a network. We canrebuild the previous ACLs to allow all the messages we discussed, to blockfragments, and to deny any other ICMP messages. Those ACLs are as follows.

Router "police" Serial0 ACL, inbound:

! deny non-initial ICMP Fragmentsaccess-list 101 deny icmp any any fragments! permit echo-request to Serial0 interface of the routeraccess-list 101 permit icmp any host 192.0.2.2 echo! permit echo-request to public serveraccess-list 101 permit icmp any host 126.0.64.10 echo! permit echo-reply from anywhere to the internal network and the public serveraccess-list 101 permit icmp any 126.0.128.0 0.0.0.255 echo-replyaccess-list 101 permit icmp any host 126.0.64.10 echo-reply! permit "fragmentation needed but DF bit set" messageaccess-list 101 permit icmp any any packet-too-big! permit "Time exceeded" messageaccess-list 101 permit icmp any any time-exceeded! deny any other ICMP messageaccess-list 101 deny icmp any any! from here you would continue with other non ICMP related ACL entries

Router "police" Ethernet0 ACL, inbound:

! deny non-initial ICMP Fragmentsaccess-list 102 deny icmp any any fragments! permit echo-request from the internal network to anywhereaccess-list 102 permit icmp 126.0.128.0 0.0.0.255 any echo! permit "fragmentation needed but DF bit set" messageaccess-list 102 permit icmp any any packet-too-big! permit "Time exceeded" messageaccess-list 102 permit icmp any any time-exceeded! deny any other ICMP messageaccess-list 102 deny icmp any any! from here you would continue with other non ICMP related ACL entries

Router "police" Ethernet1 ACL, inbound:

! deny non-initial ICMP Fragmentsaccess-list 103 deny icmp any any fragments! permit echo-request from the public web server to anywhereaccess-list 103 permit icmp host 126.0.64.10 any echo! permit echo-reply from the public web server to anywhereaccess-list 103 permit icmp host 126.0.64.10 any echo-reply! permit "fragmentation needed but DF bit set" messageaccess-list 103 permit icmp any any packet-too-big! permit "Time exceeded" messageaccess-list 103 permit icmp any any time-exceeded! deny any other ICMP messageaccess-list 103 deny icmp any any! from here you would continue with other non ICMP related ACL entries

NOTE

If you want to get very picky, you could probably block the packet-too-bigand time-exceeded messages from being generated by either the public serversegment or the internal network, depending on the rest of your configuration.With protocols such as ICMP (which are often used in troubleshooting), you areprobably better off following the KISS principle by making your ICMP filteringconsistent as much as possible.

5. Routing Considerations | Next SectionPrevious Section

From

http://www.ciscopress.com/articles/article.asp?p=174313&seqNum=4