121

Is there any reason why I would want to have

iptables -A INPUT -j REJECT

instead of

iptables -A INPUT -j DROP

7 Answers 7

114

As a general rule, use REJECT when you want the other end to know the port is unreachable' use DROP for connections to hosts you don't want people to see.

Usually, all rules for connections inside your LAN should use REJECT. For the Internet, with the exception of Ident on certain servers, connections from the Internet are usually DROPPED.

Using DROP makes the connection appear to be to an unoccupied IP address. Scanners may choose not to continue scanning addresses which appear unoccupied. Given that NAT can be used to redirect a connection on the firewall, the existence of a well known service does not necessarily indicate the existence of a server on an address.

Ident should be passed or rejected on any address providing SMTP service. However, use of Ident look-ups by SMTP serves has fallen out of use. There are chat protocols which also rely on a working Ident service.

EDIT: When using DROP rules:

  • UDP packets will be dropped and the behavior will be the same as connecting to an unfirewalled port with no service.
  • TCP packets will return an ACK/RST which is the same response that an open port with no service on it will respond with. Some routers will respond with and ACK/RST on behalf of servers which are down.

When using REJECT rules an ICMP packet is sent indicating the port is unavailable.

11
  • 9
    This is not true. Even when the rule says "DROP" the system will still reply to the incoming packet with a TCP SYN/ACK as if it was open. To truly drop a packet, the system needs to reply with a TCP RST/ACK - for which there is no firewall rule. As such, the best firewalling setup is one where only selected ports are forwarded. Your DROP rule will advertise your firewall and port-scanners will know that you are firewalling something and keep hammering you in the hopes of catching your firewall down.
    – Dagelf
    Jan 3, 2014 at 6:02
  • 3
    My point is, it is detectable from outside whether you are firewalling something or not because of the mere fact that your TCP stack behaves different when you DROP than to when you don't have a service running in the first place!
    – Dagelf
    Feb 25, 2014 at 15:49
  • 3
    Doesn't alter the fact that there are botnets capitalizing on the difference and monitoring your ports as a consequence.
    – Dagelf
    Feb 27, 2014 at 14:08
  • 14
    @Dagelf where are you getting the information that DROP sends a response? That's big news and runs counter to everything I've observed and been told. Do you have a link to the documentation that describes this behaviour? Jan 11, 2018 at 10:01
  • 12
    @Dagelf, you're partially correct, but made quite a mess of things. DROP will NOT reply anything! A closed port will return with RST/ACK, an open port will ACK or SYN/ACK. Now a REJECT rule will default to "reject-with icmp-port-unreachable" (replying with an icmp packet), and is thereby different from a closed port response and a DROPped (timeout) response both. If you don't like that, use a rule like -j REJECT --reject-with tcp-reset. Also see chiark.greenend.org.uk/~peterb/network/drop-vs-reject
    – nyov
    Feb 1, 2020 at 19:36
35

The difference is that the REJECT target sends a reject response to the source, while the DROP target sends nothing.

This can be useful e.g. for the ident service. If you use REJECT then the clients doesn't need to wait for timeout.

More about this: http://www.linuxtopia.org/Linux_Firewall_iptables/x4550.html

1
  • 1
    DROP will cause packet to timeout but it cannot hide existence of server. Try nmap -sS targethost sometime. It will be able to tell the difference between true closed and filtered ports based on SYN behavior. Dec 14, 2021 at 13:30
11

I see lots of conflicting answers here and given this is the first article in Google with the right keywords; here is the correct explanation.
It's simple:

DROP does nothing at all with the packet. It does not get forwarded to a host, it does not get answered. The manpage of IPtables says it drops the packet on the floor, i.e. it does nothing with the packet.

REJECT differs to DROP that it does send a packet back, but the answer is as if a server is located on the IP, but does not have the port in a listening state. IPtables will sent a RST/ACK in case of TCP or with UDP an ICMP destination port unreachable.

5
  • 4
    +1 from me, but the answers don't really disagree. They all agree, as far as I can see, except for Dagelf - who is wrong.
    – MadHatter
    Jan 11, 2016 at 12:45
  • 2
    Okay, here's a little trick for you then: do an "nmap localhost". Now pick any port that's not "open"... and add a rule that "does nothing", eg: "iptables -I INPUT -p tcp --dport 888 -j DROP". Now "nmap localhost" again. What do you see? ...
    – Dagelf
    Mar 13, 2018 at 21:55
  • Host is up, PORT 801/tcp STATE filtered
    – a55
    Dec 27, 2020 at 1:47
  • 1
    @Dagelf I tested it and you are 100% correct. Don't mind the others.
    – WGRM
    Feb 16, 2023 at 15:37
  • 1
    @Dagelf THANK YOU VERY MUCH. Im currently compiling a set of firewall rules with nftables and the rule ip protocol tcp reject with tcp reset gives the result all ports cloed. The scan is finished immediately, also. Have more useful tips?
    – WGRM
    Feb 16, 2023 at 15:40
10

Usually, you want to ignore probes from attackers to certain ports, by which I mean you do not want to send back 'connection refused'. 'Connection refused' means: 'there is a server here', and possibly gives away more information, whereas dropping a packet doesn't give away clues about software versions, possible vulnerabilities or even the fact that a server is listening at you IP.

The above is one of the main reasons to use DROP instead of REJECT.

1
  • 12
    Without iptables rules, a closed port defaults to REJECT. If you DROP every port it's a fine alternative (your host appears down) but if you DROP only specific ports you're actually giving them more information than REJECT. If someone uses a blanket probe like nmap, specific ports that drop packets will appear as "filtered", which means they know you have a service there that you're hiding.
    – Raptor007
    Aug 18, 2016 at 4:52
6

If you're trying to hide your machine's existence entirely, -j DROP is appropriate. For example, you might use this to implement a blacklist.

If you're trying to hide the fact that a port is open, you should mimic the behavior that would occur if the port was not open:

  • TCP: -p tcp -j REJECT --reject-with tcp-reset
  • UDP: -p udp -j REJECT --reject-with icmp-port-unreachable

If a port scanner sees that a few ports are dropping packets while most are rejecting them, it can assume the dropped packets are on ports that are open but hidden.

2
  • What if you open a few ports (i.e. 22, 25, 53, 80, 443) and then DROP everything else? Now whether I have MySQL, PostgreSQL, SQLite, or Cassandra running... the scanner cannot tell, right? Nov 13, 2016 at 0:33
  • @AlexisWilke In that case, the only additional information you're giving the port scanner is that you have some sort of firewall in place with a default DROP policy.
    – Raptor007
    Nov 14, 2016 at 21:14
2

Despite of lots of correct answers, just my two cents:

Here is a short PoC FW.IDS-DROP-vs-REJECT of me to the subject as regards the rules for ban-system (firewall, IDS, etc).

Shortly:

  • DROP can be used for recidive intruders, if banning all ports (so looks like the server is down on the intruder side)
  • REJECT --reject-with tcp-reset is the best choice for multi-port banning, because it seems to behave as a real closed port
  • if some ports are answering (intruder knows that the host is alive), DROP and REJECT (without tcp-reset) will give the intruder a "signal" that something blocking is there (so that could stimulate him to continue the "attack" in hope to provide required data at some point)
-9

Yes, using DROP is pointless. Use REJECT.

Even when the rule says "DROP" the system still replies to an incoming SYN with a TCP RST/ACK - which is the default behavior for ports with no services running. (tcpdump et al doesn't log this.)

If a service is running, the SYN is met with TCP SYN/ACK.

Because the DROP does not respond as per normal with a TCP SYN/ACK, but with a RST/ACK instead, your DROP rule will advertise your firewall and port-scanners will know that you are firewalling something and might keep hammering you in the hopes of catching your firewall down.

This is now nmap can report "filtered" instead of "closed" for example:

$ nmap localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http

Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

$ iptables -I INPUT -p tcp --dport 1111 -j DROP
$ nmap localhost

Starting Nmap 6.40 ( http://nmap.org ) at 2018-03-14 00:21 SAST
Nmap scan report for localhost (127.0.0.1)
Host is up (0.0000060s latency).
Not shown: 986 closed ports
PORT     STATE SERVICE
21/tcp   open  ftp
53/tcp   open  domain
80/tcp   open  http
1111/tcp filtered lmsocialserver

Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

$ iptables -D INPUT 1

As such, the only "invisible" firewalling setup is one where a dedicated device sits between your devices and only selectively forwards ports.

If you really want to mess with the basic scanners, you can TARPIT tcp connections, which sets the TCP Window to 0 so that no data can get transferred after the connection is opened, ignoring requests to close the connection, meaning the scanner has to wait for the connection timeout to occur, if it wants to be sure. But it's trivial for an attacker to detect this and make his timeout very short.

All things considered, you're probably best off just using REJECT - or putting a dedicated port forwarding device between your server and the internet.

Or just running services on your internet-facing machines that do not require firewalling.

Generally REJECT is best for web servers, as whatever service is trying to access it (probably more often than not, you) will quickly get a response and users or other services won't be kept waiting wondering if there's a network outage.

9
  • 11
    This answer is incorrect. It can be easily shown with tcpdump that the DROP rule will result in the system not sending ANY answer - as one would expect. And your statement "To truly drop a packet, the system needs to reply with a TCP RST/ACK" does not make sense as replying anything is obviously not "truly dropping a packet". If you "truly drop" a packet, you just don't answer and this is demonstrably the effect of the DROP rule. Apr 3, 2015 at 4:55
  • 6
    Could you provide a source for the allegation that DROP will issue a SYN/ACK? I never saw this on my machines.
    – motobói
    Apr 12, 2015 at 21:24
  • 3
    @Dagelf Your article does say "DROP (aka DENY, BLACKHOLE) Prohibit a packet from passing. Send no response."
    – JeanT
    Jul 24, 2015 at 11:32
  • It doesn't send the normal response, but it sends one as explained, regardless.
    – Dagelf
    Nov 30, 2015 at 19:17
  • 5
    The document you link to says "DROP ... Send no response", and does not, as far as I can see, support your claim that DROP returns a SYN/ACK. I, too, have never seen this behaviour under any version of iptables. If you have a source that supports your claim, it would be most useful to see it; certainly, the packet dumps I've just done do not support your claim.
    – MadHatter
    Jan 11, 2016 at 12:42

You must log in to answer this question.

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