Home > Articles > Security > Network Security

This chapter is from the book

This chapter is from the book

ICMP Design Considerations

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

ICMP security can be a very lengthy discussion because lots of nasty things can be done with ICMP messages when scanning networks or trying to gain a covert channel. If you are interested in this sort of thing, Ofir Arkin's paper titled "ICMP Usage in Scanning" is available at http://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 ICMP traffic you should allow on your network and which messages types you should filter.

ICMP Rate Limiting

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

ICMP Message Type Filtering

As Chapter 2 discussed, your own security policies and threat models might be different from those assumed here. Deploying filters throughout your internal network to permit only the ICMP message types required would be difficult. As a first step, focus on possible boundaries of trust between two networks. Your network will have its own trust boundaries, but here are a few to get you started. Zones of trust are detailed more fully in Chapter 12, "Designing Your 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 a fragment. First, the ICMP messages you must permit are generally small. Echo and echo 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 are similarly small and come nowhere near the minimum link size on today's IP networks. 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 a detailed discussion of this, including flow charts and examples, check the paper at 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 to noninitial fragments (fragment offset > 0), so in the preceding example, the first part of a fragmented ICMP packet will not match that entry, while all subsequent fragments will.

When filtering ICMP messages between trust boundaries, apply the security principle "Expressly permit, implicitly deny." Though your specific requirements may vary, the following ICMP types should be permitted in some form:

  • ICMP echo request and ICMP echo reply

  • ICMP destination unreachable—fragmentation needed but DF bit set

  • 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) are better known as the message types used by the ping command. The format of an ICMP echo message has the standard 8 bytes of ICMP header information and then 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 attack was 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 discussed in Chapter 3. It can also lead to a covert channel because information can be embedded into the data field in the ICMP echo message. An attacker that installs special software on a host internal to your network could communicate back and forth using only ICMP echo request or reply messages. Covert channels have been implemented in many different protocols, and they are impossible to completely eliminate. So, with these risks, it is understandable why a security engineer would want to stop ICMP echo messages. Unfortunately, troubleshooting would be far too difficult without it making your overall network less secure in most cases. With all that said, here are the best practices:

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

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

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

  • Permit ICMP echo reply messages from any server system to the networks where that server's users reside. Echo replies from your public web server to 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 Figure 6-15.

Figure 15Figure 6-15 Simple Internet Edge

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

! permit echo-request to Serial0 interface of the router
access-list 101 permit icmp any host 192.0.2.2 echo
! permit echo-request to public server
access-list 101 permit icmp any host 126.0.64.10 echo
! permit echo-reply from anywhere to the internal network and the public server
access-list 101 permit icmp any 126.0.128.0 0.0.0.255 echo-reply
access-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 anywhere
access-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 anywhere
access-list 103 permit icmp host 126.0.64.10 any echo
! permit echo-reply from the public web server to anywhere
access-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 your security policies, you can permit this to aid in troubleshooting, but be aware that many organizations consider public servers to be not much more trusted than the Internet. To make the change, you would add this line to the Ethernet0 ACL:

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 are situations in which you must use both and situations in which an outbound ACL makes more sense. I prefer inbound because the packets are blocked before they cross the router. Outbound ACLs allow the packet to be routed by the router and then are blocked when they try to leave. This could leave the router open to certain attacks.

Another special note on Cisco ACLs is that ACLs never apply to traffic generated by the router. So, even if you have an inbound and an outbound ACL on a router denying all traffic, the router will still be able to send any packet it 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 whole range of messages designed to alert the sending system that something is wrong with a particular message sent. This includes specific errors such as network unreachable (code 0), host unreachable (code 1), protocol unreachable (code 2), and port unreachable (code 3). These types of messages are generated by hosts and routers when a sending system tries to go somewhere that is unreachable for whatever reason. Many security administrators block most type 3 messages because the sending host will often figure out that the service is unavailable on its own without the benefit of the ICMP message (albeit more slowly). One message is required though: "fragmentation needed but DF bit set" (type 3 code 4). This message is required for path Maximum Transmission Unit (MTU) discovery to work. Path MTU discovery is the method most hosts use to determine the IP MTU size for their traffic. Without it functioning properly, large TCP segments could be dropped without a means to remedy the problem because the offending host never knows why the drop occurs.

Path MTU discovery has some interesting implications in IPsec and is discussed in more detail in Chapter 10, "IPsec VPN Design Considerations."

ICMP type 3 code 4 messages can be easily permitted by adding the following line 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 code 0) is required because it is used by traceroute. To permit these messages, add the 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 a playground for attackers. Although most of the 15 ICMP message types can be blocked, several are necessary to the healthy operation of a network. We can rebuild the previous ACLs to allow all the messages we discussed, to block fragments, and to deny any other ICMP messages. Those ACLs are as follows.

Router "police" Serial0 ACL, inbound:

! deny non-initial ICMP Fragments
access-list 101 deny icmp any any fragments
! permit echo-request to Serial0 interface of the router
access-list 101 permit icmp any host 192.0.2.2 echo
! permit echo-request to public server
access-list 101 permit icmp any host 126.0.64.10 echo
! permit echo-reply from anywhere to the internal network and the public server
access-list 101 permit icmp any 126.0.128.0 0.0.0.255 echo-reply
access-list 101 permit icmp any host 126.0.64.10 echo-reply
! permit "fragmentation needed but DF bit set" message
access-list 101 permit icmp any any packet-too-big
! permit "Time exceeded" message
access-list 101 permit icmp any any time-exceeded
! deny any other ICMP message
access-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 Fragments
access-list 102 deny icmp any any fragments
! permit echo-request from the internal network to anywhere
access-list 102 permit icmp 126.0.128.0 0.0.0.255 any echo
! permit "fragmentation needed but DF bit set" message
access-list 102 permit icmp any any packet-too-big
! permit "Time exceeded" message
access-list 102 permit icmp any any time-exceeded
! deny any other ICMP message
access-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 Fragments
access-list 103 deny icmp any any fragments
! permit echo-request from the public web server to anywhere
access-list 103 permit icmp host 126.0.64.10 any echo
! permit echo-reply from the public web server to anywhere
access-list 103 permit icmp host 126.0.64.10 any echo-reply
! permit "fragmentation needed but DF bit set" message
access-list 103 permit icmp any any packet-too-big
! permit "Time exceeded" message
access-list 103 permit icmp any any time-exceeded
! deny any other ICMP message
access-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-big and time-exceeded messages from being generated by either the public server segment or the internal network, depending on the rest of your configuration. With protocols such as ICMP (which are often used in troubleshooting), you are probably better off following the KISS principle by making your ICMP filtering consistent as much as possible.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020