39

There's an example of iptables rules on archlinux wiki:

# Generated by iptables-save v1.4.18 on Sun Mar 17 14:21:12 2013
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]
:TCP - [0:0]
:UDP - [0:0]
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate INVALID -j DROP
-A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -p udp -m conntrack --ctstate NEW -j UDP
-A INPUT -p tcp -m tcp --tcp-flags FIN,SYN,RST,ACK SYN -m conntrack --ctstate NEW -j TCP
-A INPUT -p udp -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p tcp -j REJECT --reject-with tcp-reset
-A INPUT -j REJECT --reject-with icmp-proto-unreachable
COMMIT
# Completed on Sun Mar 17 14:21:12 2013

A few days ago my friend asked me why is there REJECT in the last three rules. He told me that there should be DROP instead, and he mentioned something about better security in case of DROP.

So, I have two questions:

  1. What do the three rules do?

  2. Does it make any difference when I put there DROP in place REJECT --reject-with ? If yes, what is the difference?

1

1 Answer 1

41

What do the three rules do?

Those 3 rules seem pretty self-explanatory:

  1. Reject incoming UDP packets with an ICMP message "port unreachable"
  2. Reject incoming TCP packets with "tcp reset"
  3. Reject incoming packets (of any other protocol) with ICMP message "protocol unreachable"

If you're looking for more detail (about UDP/TCP packets, ICMP), you need to dig into networking docs, and perhaps the man iptables too.

Does it make any difference when I put there DROP in place REJECT --reject-with ? If yes, could someone explain the difference to me, I'll really appreciate it.

It makes a difference. And contrary to popular belief, DROP does not give better security than REJECT. It inconveniences legitimate users, and it's effectively no protection from malicious ones. This post explains the reasoning in detail:

http://www.chiark.greenend.org.uk/~peterb/network/drop-vs-reject

A common reason for using DROP rather than REJECT is to avoid giving away information about which ports are open, however, discarding packets gives away exactly as much information as the rejection.

With REJECT, you do your scan and categorise the results into "connection established" and "connection rejected".

With DROP, you categorise the results into "connection established" and "connection timed out".

The most trivial scanner will use the operating system "connect" call and will wait until one connection attempt is completed before starting on the next. This type of scanner will be slowed down considerably by dropping packets. However, if the attack sets a timeout of 5 seconds per connection attempt, it is possible to scan every reserved port (1..1023) on a machine in just 1.5 hours. Scans are always automated, and an attacker doesn't care that the result isn't immediate.

A more sophisticated scanner will send packets itself rather than relying on the operating system's TCP implementation. Such scanners are fast, efficient and indifferent to the choice of REJECT or DROP.

CONCLUSION

DROP offers no effective barrier to hostile forces but can dramatically slow down applications run by legitimate users. DROP should not normally be used.

6
  • @janos -- could you write a little bit more about what actually happens when a packet reaches each of the three rules? Jan 15, 2014 at 15:54
  • 4
    @Kiwy - Read the link and try it yourself. DROP does not give better security than REJECT. It inconveniences legitimate users, and it's effectively no protection from malicious ones. This is because legitimate users suffer from a slow connection while waiting for the conection to time out and crackers merely configure their tools to not wait for a time out. the fact that the connection is slow (due to the wait for a time out) shows your server is there and firewalled.
    – Panther
    Jan 15, 2014 at 15:55
  • 2
    I do not go with that conclusion. Reject generates an ICMP-answer that can by analysed. Based on this analysis good attack engines can derive the OS that is being used. So on a system where all ports are known drop might be better. This applies to servers in a production environment.
    – Nils
    Jan 20, 2014 at 12:16
  • 1
    A firewall that only forwards certain ports is even better. DROP an REJECT are not the same as absolutely no service running the first place. Many port scanners mark your host as a potential target for future scans in the hopes of catching your firewall down if they find REJECTS or DROPS there, as both can be detected from outside. chiark.greenend.org.uk/~peterb/network/drop-vs-reject
    – Dagelf
    Jul 16, 2015 at 13:03
  • 3
    Note that the quoted text has one more paragraph, an update, that says DROP is better if you have a DDoS attack, which is relatively rare, but when it happens, it's probably good to have it... what do you think? Nov 13, 2016 at 0:54

You must log in to answer this question.

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