Is there any reason why I would want to have
iptables -A INPUT -j REJECT
iptables -A INPUT -j DROP
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.
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
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.
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.
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.