REJECT vs DROP when using iptables

Question

Is there any reason why I would want to have

iptables -A INPUT -j REJECT

instead of

iptables -A INPUT -j DROP

Answer 1

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 be dropped and no response will sent, rather than an ACK/RST response, which an unfirewalled port with no service 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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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)

Answer 7

Yes, using DROP is pointless. Use REJECT.

A connection is initiated with a SYN packet.

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

If a port is unused, or with REJECT, the SYN is met with RST.

If there is a DROP rule, the SYN is ignored, and that stands out.

Truly dropping a packet is no good at hiding services, it just shows that you have something to hide because the DROP does not "blend in" - ie. it does not respond as an unused port would, with RST/ACK; your DROP rule will just 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 how 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

Thus, if you have a dedicated device between your devices and only selectively forwards ports, that device will also respond with RST to all the ports that are not forwarded.

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 on their side.

All things considered, you're probably best off just using REJECT.

Nowadays the bigger threat is malware coming in through legitimate ports though, which is why application firewalls that double check the contents of the connection, have become a thing.

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.

UPDATE: Thank you to everyone trying to correct my stubbornness, you should've pointed out what lead to the behavior I saw, and that I must have swopped DROP and REJECT in my test results, where I mistakenly attributed RST/ACK to DROP instead of REJECT, I wasn't very thorough.