One is, as you described, that it leaves the attacker in an unknown status. Not only will it take some resources to sit and wait for the timeout, but also, it’s likely that some algorithm will later again attempt to contact your host because it’s possible that your server was offline the first time it tried to hit you.

The second is that at high volumes of traffic you’re making a performance gain. By not bothering to put together a reject packet, you’re eliminating some CPU cycles(which are quite precious on an anti-spam device) and also you’re using a bit less bandwidth, which while cheap, is not free.

Thanks the for the link.

The Linux kernel can now be patched to allow tarpitting of incoming connections instead of the more usual dropping of packets. This is implemented in iptables by the addition of a TARPIT target. The same packet inspection and matching features can be applied to tarpit targets as are applied to other targets.

While its similar, the (very) basic idea that you should DROP packets instead of REJECTing them from malicious hosts is distinct from the tarpitting as described in the article. DROPing instead of REJECTing when you are specifically targeting a single host or subnet I would consider, a good practice. Whereas tarpitting seems to be a fully developed method of operation.

Agreed, but its not always followed. I know of admin’s who use REJECT as the default. I wanted to describe WHY you should DROP instead of REJECT.

> What exactly does this have to do with bash, other than the fact that you are using bash as your shell when you invoke iptables?

I quite often stray off the command line. For example, see my ftp/kernel debugging articles.

However when I do so, I try and provide some insight into command line, commands. In this example, I am showing how to use netcat as both a client and server in addition to some basics of iptables.

What exactly does this have to do with bash, other than the fact that you are using bash as your shell when you invoke iptables?

“If you are filtering outbound traffic from an internal trusted network, you certainly want to use reject, so internal users get a better ‘user experience’, even when you are not allowing the traffic out.”

I agree. In my explanation as I talked about malicious hosts.

“Also, if you use drop, many hosts will continue trying to connect to you. You will receive far more packets than if you use the reject target”

Its possible that this could be a problem. If the number of packets they are sending is a problem and their logic is such that if they receive a REJECT, they move on.

“A ‘always use drop’ motto may be a bit too broad of a brush.”

I agree there are situations where you want to REJECT. However, I’d have to see a situation where using DROP causes a problem in regards to malicious hosts before I changed my opinion.

If you are filtering outbound traffic from an internal trusted network, you certainly want to use reject, so internal users get a better ‘user experience’, even when you are not allowing the traffic out.

Also, if you use drop, many hosts will continue trying to connect to you. You will receive far more packets than if you use the reject target — the connecting host would likely closed the socket much quicker with a reject target. The tradeoff is that naughty folks would know your box was there, and that the port was being filtered.

So..talking myself back in a circle, I think it depends on what you are doing. A ‘always use drop’ motto may be a bit too broad of a brush.