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

Solution 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 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.

Solution 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

Solution 3

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.

Solution 4

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.

Solution 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.

View more solutions

Comments

[spotchi]

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.

[BillThor]

@Dagelf See my edit. The RST/ACK does not indicate to scanners that you are firewalling anything. While some hackers may continue to probe after this response, that should be based on knowing your services not the firewall response. It definitely dropped the number and length of scans I experience.

[spotchi]

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!

[BillThor]

@Dagelf I have seen all three responses in cases where a server was not available. None of the responses necessarily indicate a server is at the address. DROP is the response which is least helpful to a scanner.

[spotchi]

Doesn't alter the fact that there are botnets capitalizing on the difference and monitoring your ports as a consequence.

[Juliane Holzt]

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.

[motobói]

Could you provide a source for the allegation that DROP will issue a SYN/ACK? I never saw this on my machines.

[spotchi]

It doesn't send the normal response, but it sends one as explained, regardless.

[MadHatter]

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]

+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.

[spotchi]

DROP used to function like a closed port on older kernels, so that you could just DROP ports you wanted to keep hidden. I see this has changed... not sure when.

[Raptor007]

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.

[Alexis Wilke]

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?

[Raptor007]

@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.

[user313114]

whatever you do, be consistent. if the attacker picks an unused port number and tries to connect, he should get the same response as if he has picked one you are purposefully blocking. giving a different response tells him that there's something there. eg it he can use purtnumber that gives a different response to determine which database server you are using he can tailor SQL injection to that server...

[Score_Under]

@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?

[spotchi]

Indeed. I was playing with raw sockets when I discovered this, there was no github and my backups are in a drawer somewhere... I'm afraid you'll have to start at linux/net/core/dev.c and net/netfilter/core.c :-(

[nyov]

@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

[spotchi]

To clarify here: this was not opinion. This was based on packet tracing through an external router. The only missing info here is the kernel versions, and whether the functionality changed at some point, and why.

[spotchi]

@nyov When I tested this on whatever the prevailing Debian kernel version was in 2018, DROP replied with RST/ACK. Do you have any info on when this started happening, and when it stopped again?

[nyov]

@Dagelf, hmm sorry, but I'm not aware of such behavior or when it might have occured. I can't say there isn't a case where this might be true; but the only reason that comes to my mind for seeing this, would be another network device/firewall responding on behalf of the host. Or some obscure iptables setup possibly.

[a55]

Host is up, PORT 801/tcp STATE filtered

[Mikko Rantalainen]

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.