Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Is there any reason why I would want to have

iptables -A INPUT -j REJECT

instead of

iptables -A INPUT -j DROP
share|improve this question

4 Answers 4

up vote 30 down vote accepted

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.

share|improve this answer
    
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 at 6:02
    
@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. –  BillThor Jan 4 at 13:43
    
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 at 15:49
    
@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. –  BillThor Feb 26 at 1:30
    
Doesn't alter the fact that there are botnets capitalizing on the difference and monitoring your ports as a consequence. –  Dagelf Feb 27 at 14:08

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

share|improve this answer
1  
The DROP target doesn't send nothing. Check my comment on the accepted answer and go research the topic yourself if you are interested in the details! –  Dagelf Feb 25 at 15:50

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.

share|improve this answer

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 SURPRISE! no firewall rule.

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. (This is now nmap can report "filtered" instead of "closed" for example.)

As such, the best firewalling setup is one where a dedicated device sits on the internet and only selected ports are forwarded.

If you really want to be nasty, 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.

But it's trivial for an attacker to detect this and make his timeout very short - so all things considered, you're probably best off just using REJECT - or putting a dedicated port forwarding device between you and the internet.

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

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.