I think I almost have my iptables setup complete on my CentOS 5.3 system. Here is my script...

# Establish a clean slate
iptables -P INPUT ACCEPT
iptables -F # Flush all rules
iptables -X # Delete all chains

# Disable routing. Drop packets if they reach the end of the chain.
iptables -P FORWARD DROP

# Drop all packets with a bad state
iptables -A INPUT -m state --state INVALID -j DROP
# Accept any packets that have something to do with ones we've sent on outbound
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# Accept any packets coming or going on localhost (this can be very important)
iptables -A INPUT -i lo -j ACCEPT
# Accept ICMP
iptables -A INPUT -p icmp -j ACCEPT

# Allow ssh
iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# Allow httpd
iptables -A INPUT -p tcp --dport 80 -j ACCEPT
# Allow SSL
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Block all other traffic 
iptables -A INPUT -j DROP

For context, this machine is a Virtual Private Server Web app host.

In a previous question, Lee B said that I should "lock down ICMP a bit more." Why not just block it altogether? What would happen if I did that (what bad thing would happen)?

If I need to not block ICMP, how could I go about locking it down more?

  • 4
    iptables -A INPUT -j DROP < wrong (opinion) you should set the policy to iptables -P INPUT DROP which is basically the same as setting a default. DENY BY DEFAULT. Nov 15, 2009 at 20:37
  • 2
    Find out why it is a bad idea to block icmp: security.stackexchange.com/a/22713/485
    – Rory Alsop
    Nov 20, 2012 at 9:06

10 Answers 10


ICMP is way, way more than "traceroute" and "ping." It is used for feedback when you run a DNS server (port unreachable) which, in a modern DNS server, may actually help select a different machine to query faster.

ICMP is also, as was mentioned above, used for path MTU discovery. Chances are your OS sets "DF" (don't fragment) on TCP packets it sends. It is expecting to get an ICMP "fragmentation required" packet back if something along the path fails to handle that size of packet. If you block all ICMP, your machine will have to use other fallback mechanisms, which basically use a timeout to detect a PMTU "black hole" and will never optimize correctly.

Additionally, you should ask yourself why you want to block ICMP. What specifically are you attempting to prevent here? It's pretty clear you don't understand what ICMP is used for, which is rather common. I'd be extremely cautious in blocking something you don't fully understand.

To make it even harder to learn about this, many common firewall books say "block ICMP" -- it's clear their authors have never read an RFC or had to solve issues surrounding such advice. It's bad advice to block all ICMP.

Now, rate limiting it can also hurt. If your machine is busy, or even if it's not, you can get a good amount of ICMP traffic. My web server probably gets about 10-100 ICMP packets per minute, most of which is PMTU discovery. Even if someone chose to attack my server with ICMP packets of some type, it's really not that big of a deal. If your machine accepts even one TCP connection (ssh, http, mail, etc) chances are that's a bigger attack vector than misunderstood ICMP ever will be.

  • 5
    Couldn't have said it any better. +1
    – Massimo
    Nov 15, 2009 at 21:47
  • 9
    There is one type of ICMP that can be harmful the redirect type. That's the only ICMP type you should ever consider blocking. Sep 29, 2011 at 22:48
  • 3
    @Hubert it would be very helpful if you could link to more advice on blocking the redirect. I understand now that I should consider it, but I'm no better off - still can't decide one way or another :) Is it a risk or not?
    – RomanSt
    Dec 12, 2011 at 14:55
  • Redirect ICMP message tells the host (routers should never accept them) that such and such subnet or host is available at a different gateway (usually by a faster router). At least that's what RFC1122 says. Dec 12, 2011 at 17:54
  • 2
    I believe redirects are ignored by default on linux. But yeah, better to filter that one.
    – Fox
    Apr 23, 2013 at 6:36

ICMP is used for a range of diagnostic (eg ping, traceroute) and network control (eg PMTU discovery) functions. Indiscriminate blocking of ICMP causes other people all sorts of heartburn, and unless you know exactly what you're doing, you should leave it alone.


I've never understood why people clock ICMP, as said above it only ever causes headaches to yourself and others. You can determine if a host is up easily enough and so long as it is limited enough as not to be used as a DOS then I've never heard any compelling reasons to block it. (If someone can come up with a reason please post)

  • 7
    It's part of the cult of information security. Security people feel that they don't need to justify things, because mere mortals cannot possibly understand the security implications. On the other hand, Network & System admin headaches can be attributed to plain lazyness. After all, if the admins knew what was going on, things would never break... Nov 15, 2009 at 21:27
  • 1
    it just seems odd to me to kill off diagnostic tools essentially for the sake of it; as the information that an attacker would be interested in could likely be derived assuming you have any other service at all running on the machine. Your right; it does seem very "cult"y, don't question just do.
    – Antitribu
    Nov 15, 2009 at 22:49
  • 9
    I've never understood why authors of firewall books seem to totally miss that ICMP is far more than "ping" and "traceroute" and yet books and blogs and HOW-TOs all say "block ICMP." Nov 15, 2009 at 23:44
  • 2
    levels and levels of this, your answer was rightly voted up, well put. Mostly I know when it's blocked you never can quite tell whats going wrong with intermittent things, especially when there are multiple ICMP blocks along the way.
    – Antitribu
    Nov 16, 2009 at 9:13

you could just try limit-ing icmp that way it can't be used as a DOS attack. but there are way too many troubleshooting tools like ping, mtr (I forget windows equivalent), traceroute (tracert), that use icmp. dropping them entirely is just foolish. It's a good way to check if your instance is up even though you can't telnet on any ports.

--limit 10/second
to your icmp rule(s) is probably a decent limit given just how much a computer can actually handle.


Here's an alternate viewpoint, in the spirit of what security theory would suggest. Other posters are right that security practice is often overzealous, but there is a good basis to much of it.

The security theory is generally that you only enable WHAT YOU NEED. Other things (which could be useful - e.g., ping responses) can be used by an attacker to scope out your system, or possibly as an attack vector for some yet-to-be-discovered vulnerability.

So, looking at ICMP message types, what do you NEED for normal, proper operation of your system?

  • echo reply (ping) - not so much
  • destination unreachable - lots of useful information in here. Disable this and you will break access to your server for some clients.
  • source quench - deprecated since 1995, and apparently removed from host implementations since (at the latest) 2005. tools.ietf.org/html/rfc6633#section-1.
  • redirect - almost certainly not
  • router advertisement & solicitation - no need if you statically configure your routes, and could be used for DoS. I'd block it unless you know you need it, and if you need it, perhaps code a rule to accept info from only the possible known routers.
  • ttl exceeded - not just for traceroute, tells you your traffic isn't getting through to its destination

...and so on. If you really want to understand this, go learn about the various ICMP types and what they are for. The wikipedia article is a good starting point.

In practice, the really ugly one is redirect; if you want to just do something quick and useful, block that and allow the rest.

I would add that IPtables connection tracking will allow the appropriate return ICMP packets for active connections. So if you are running conntrack, you should be able to block most ICMP inbound, as long as you are accepting RELATED packets (before you block ICMP in your ruleset).

  • 2
    Actually source quench is deprecated since 1995, and apparently removed from host implementations since (at the latest) 2005 :). tools.ietf.org/html/rfc6633#section-1.
    – sourcejedi
    Apr 20, 2013 at 8:53
  • answer updated, thanks. If I'd thought a bit harder I would have remembered that, duh.
    – Dan Pritts
    Apr 23, 2013 at 6:07
  • I think ICMP PING is required for PMTU discovery (which many browsers and tools use). Disallowing it is like being unpolite to your users. Ping is also used for many diagnostic purposes, and most big players allow it. Besides, there's little benefit in disallowing it.
    – jjmontes
    Oct 2, 2014 at 14:57
  • 2
    Echo (ping) packets aren't required for PMTU discovery. PMTU discovery is done by setting the Don't Fragment (DF) bit on outgoing packets, and depends on ICMP Destination Unreachable - Fragmentation needed messages coming back from routers with smaller link MTUs. Ping is certainly useful for diagnostic purposes but it is also useful for network reconnaissance and potentially for DoS. For all you and I know there is a latent remote-root bug in the ICMP stack in Linux. If your standard is "do i need this" the answer is "no.".
    – Dan Pritts
    Oct 3, 2014 at 15:21
  • 1
    (Note that i wrote in the answer that blocking destination unreachable messages will break things. PMTU discovery was in fact what I was thinking of. :)
    – Dan Pritts
    Oct 6, 2014 at 16:44

It's a useful diagnostic tool for solving network connectivity issues.

It also allows you to use connections elsewhere on the internet that use smaller MTUs than are on your network. If you try to send a packet somewhere that's too large and can't be fragmented, the device drops the packet and sends an ICMP fragmentation needed packet back to the sender. If you drop all ICMP packets, you lose those and weird things happen on your network.

The real question is "why block ICMP?" What do you gain? Just have good filtering rules at your border and in front of your valued assets.


ping is a nice diagnostic tool, you'll really wish you had it someday. I'm using these:

-A icmp_packets -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A icmp_packets -p icmp -m icmp --icmp-type 11 -j ACCEPT

you might also want to throttle it.

  • 8
    This is woefully inadequate for reasons others have pointed out (ICMP is way more than just ping). You should selectively block specific, potentially harmful ICMP messages, and allow other control messages through unmolested.
    – voretaq7
    Nov 19, 2012 at 23:11

Nowadays even limiting the ICMP packets in server side can create headache on DDoS attacks. Attacks mostly done by sending huge window ICMP requests to one server and if the server is trying to respond to each of it, guess what happens?

Main thing that we have a teamspeak server that gets bad packets every single day, there was few days in two months that we had some "freetime". What we had done is completely disabled/blocked ICMP responces, we have no DNS servers on the server, no NTP servers, no mail servers, no FTP servers, only two apache and teamspeak. all ports that is unneeded for the services are off. We are planing to block even the ssh and leave only two ports open. Today there is 21k (!) permanent bans.

The situation is that attackers uses mostly ICMP tunnelings and few really interesting log lines was discussed with the server admins and they said that they have server ICMP requests on, so attackers used that to tunnel the attack troughs them and attack us. Sounds weird but that's true.

If you don't need diagnostics of your server and if you are able to completely block the requests or filter them to drop huge windows for example then do it. I also suggest you to completely block: China, Korea, Thailand, Turkey because majority of the IP Addresses comes from there. I had whole inetnum lists of these countries but almost each day comes some new ones from there.

I say what I do, if you don't agree - don't do it. Simple as that. Good luck


As a minimum, you should allow to pass icmp types 3 (destination unreachable), 4 (source quench) and 11 (time exceeded). All of these types are used to deal with network problems and shouldn't be filtered.

iptables -A INPUT -p icmp -m icmp --icmp-type 3 -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 4 -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT

(Source quench type is currently deprecated, but it won't hurt to let this open)


I allow ICMP traffic from local intranet, block it from Internet. That way my server is all but invisible online (it responds only on a non standard SSH port).

iptables -I INPUT 7 -d 208.180.X.X -p icmp --icmp-type 8  -j DROP
iptables -I INPUT 8 -d 208.180.X.X -p icmp --icmp-type 0  -j DROP
iptables -I INPUT 9 -d 208.180.X.X -p icmp --icmp-type 11 -j DROP

This inserts it after the standard loopback, established, LAN whitelist, VOIP provider whitelist, and SSH port ACCEPTs. I allow the traffic I want, and then do my best to keep the server invisible to the rest of the world.

  • 1
    I think I understand what your trying to say, but it does not correlate with the tables you wrote. If your dropping specific ICMP types, than what happens to those unspecified??? I would assume Default-Allow, otherwise why specify a block when it would be intrinsic. You then state "I allow the traffic I want", which would indicate Default-Deny or Default-Drop... basically your answer is inconsistent, and confusing at best. Apr 23, 2012 at 16:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .