Tuesday, July 19, 2011

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

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?

network firewalls ddos
linkimprove this question
asked Apr 23 at 14:27
Gilles
597112
1
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 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 – Georgios Apr 24 at 1:42
feedback
1 Answeractiveoldestvotes
up vote
5
down vote
accepted
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.

linkimprove this answer
edited Apr 23 at 20:14

answered Apr 23 at 14:41
Hendrik Brummermann
3,3272525
1
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. – Graham Lee♦ Apr 23 at 18:59
2
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 at 20:06
really useful reply, thanks :)

http://security.stackexchange.com/questions/3290/reject-ip-packets-with-an-icmp-error-or-just-drop-them