Reject IP packets with an ICMP error, or just drop them?

Question

Consider an internet-facing host (the outer firewall). What should be done with undesired traffic: just drop it, or send back an ICMP error such as port unreachable? (In Linux terms: iptables -P DROP or iptables -j REJECT?)

This isn't about the security of our network, the packets aren't getting in either way. It's about being a good citizen. REJECT could make our firewall participate in a DDoS, if the incoming packets have a spoofed origin. But is it always the right choice? Are there circumstances where it's better to send back a proper ICMP error?

as I mentioned on Unix SE, I would suggest putting a limit on any reject, that way if someone is sitting there sending packets you aren't sending a ton the other direction. I can't suggest how many to allow. — xenoterracide, Apr 23 '11 at 18:01
@xenoterracide the way DDoS reflection attacks work (the attack being initiated from thousands of bots that could theoretically use any "reflector), it's still enough for an interconnected host to produce just a little bit of unintended traffic in order to contribute to a major attack. Still such limits on rejects should be considered "Good Internet Citizen" practices — George, Apr 24 '11 at 01:42
This question was prompted by a discussion about [iptables: allow certain ips and block all other connection](http://unix.stackexchange.com/questions/11851/iptables-allow-certain-ips-and-block-all-other-connection) Another question on [unix.se] on this topic: [Is it better to set -j REJECT or -j DROP in iptables?](http://unix.stackexchange.com/questions/109459/is-it-better-to-set-j-reject-or-j-drop-in-iptables) — Gilles 'SO- stop being evil', Jan 16 '14 at 01:28

Hendrik Brummermann · Accepted Answer · 2011-04-23T20:14:05.797

I usually vote for sending back an ICMP error for UDP and a RST packet for TCP. It does make debugging issues so much easier. And it prevents annoying timeouts: Mail and IRC servers often attempt to do an ident query or check that the client is not an open proxy.

If it is done at the out-most firewall there will be no relevant information disclosed. Depending on the setup it may even conceal that there is a firewall. If there were no answer, it would be obvious that there is a black hole.

It's important that servers send no answer for packets sent to a broadcast address in order to prevent an amplifying effect in a DoS situation. It's okay for the firewall to send the error message in this situation, resulting in only one answer.

ICMP-errors and TCP-RST packets are not larger than the smallest original packet. So these are not interesting for DDoS attacks.

Edit: DNS authoritative servers (and missconfigured DNS resolvers) are a lot more interesting for reflective DDoS attacks because the DNS answers are larger than the queries and therefore grant the attacker an amplification free of charge.

Regarding your last paragraph: what about the case when a DDoS wants to hide which systems are infected? The bot, B, sends a packet to server S that claims to be from source address V, the victim. Then S sends an error/reset packet to V. There are many B, and many S. — , Apr 23 '11 at 18:59
While this is theoretically possible, this is an extremely inefficient way for two reasons: a) ICMP unreachable and unsolicited TCP-RST are very easily filterable at or before the victim. And b) more important: The TCP-RST und ICMP unreachable packets are very small, so the botnet needs to be extremely large. As such large botnets are expensive, an attacker will likely try to get the amplification behind the botnet for free. That's why reflection attacks without amplification are not seen in the wild. You should worry about your DNS server more than about error responses. — Hendrik Brummermann, Apr 23 '11 at 20:06

score 5 · Answer 2 · edited Oct 07 '21 at 06:58

You mention iptables, so you are implying linux (at least as an example for an OS with tunable network policies).

Since a very long time, linux has had a limit on the number of ICMP error message sent. The default is very low: 1 message/s.

This behaviour of linux is tunable with network sysctl parameters: the icmp_ratelimit sysctl

icmp_ratelimit - INTEGER
    Limit the maximal rates for sending ICMP packets whose type matches
    icmp_ratemask (see below) to specific targets.
    0 to disable any limiting,
    otherwise the minimal space between responses in milliseconds.
    Default: 1000

Note that by default icmp_ratelimit only applies to ICMP error messages and source quench, not all ICMP replies:

icmp_ratemask - INTEGER
    Mask made of ICMP types for which rates are being limited.
    Significant bits: IHGFEDCBA9876543210
    Default mask:     0000001100000011000 (6168)

    Bit definitions (see include/linux/icmp.h):
        0 Echo Reply
        3 Destination Unreachable *
        4 Source Quench *
        5 Redirect
        8 Echo Request
        B Time Exceeded *
        C Parameter Problem *
        D Timestamp Request
        E Timestamp Reply
        F Info Request
        G Info Reply
        H Address Mask Request
        I Address Mask Reply

    * These are rate limited by default (see default mask above)

so this rate limiting does not apply to echo reply by default.

With the default settings, DOSing a target with ICMP error messages sent by a linux box seems very hard.

The (...) ICMP unreachable packets are very small

No, they are not always tiny: under linux, the ICMP error message will capture as much as possible context from the packet that caused it, up to the 576 (or the destination MTU), to make it possible to demultiplex the error message even when complex encapsulation in IP have been used, following RFC 1812:

4.3.2.3 Original Message Header

   Historically, every ICMP error message has included the Internet
   header and at least the first 8 data bytes of the datagram that
   triggered the error.  This is no longer adequate, due to the use of
   IP-in-IP tunneling and other technologies.  Therefore, the ICMP
   datagram SHOULD contain as much of the original datagram as possible
   without the length of the ICMP datagram exceeding 576 bytes.

How does this limit help against *distributed* denials of service? All it means is that *my* firewall isn't going to send more than X packets per second to each target. But the principle of a DDoS is to have many innocent parties send packets, each at a slow rate, to the target. There's no way for the innocent party to know how many packets are reaching the target in total and limit its rate to a fraction of that. — Gilles 'SO- stop being evil', Sep 25 '11 at 10:55
@Gilles 576 B/s is not slow, it's sluggish! With 2,000 such "innocent parties" you can send 1 MB/s. You wouldn't overload my DSL link with that! If you are into that, why not use DNS for your DDoS? ;) It least you can have an interesting multiplication factor. — curiousguy, Sep 25 '11 at 15:23

Reject IP packets with an ICMP error, or just drop them?

2 Answers2

Linked