Does "TARPIT" have any known vulnerabilities or downsides?

Question

TARPIT can be used to waste an attacker's resources, thus slowing down their attacks and lowering their ability to attack other hosts... looks like a good idea.

It is provided as a Netfilter addon and can be used just like any other IPTables target.

Are there known downsides or vulnerabilities in this approach of dealing with (D)DoS ?

Answer 1

I used to think it was a good idea. But now I know it's a very bad idea, unfortunately.

Have you ever run an HTTP benchmark app like ApacheBench? On a single machine you can set it to create hundreds of connections per second to a target server. Get a few of those clients running and connecting to your server with tarpitting enabled and I think you will see a problem.

Think about how creating thousands of connections per second to your server will impact the server if each connection is trapped in a tarpit.

Your server will quickly consume all its available resources (or file handles) so that no more connections are allowed. This is worse than just closing the connection. It'd be better to drop the offender for a while than try to tie up their resources, which is what scripts like fail2ban achieve.

Also, you never want your normal users to be stuck in the tarpit, especially for interactive sessions. How do you decide upfront who's allowed and who's not? For some protocols like HTTP, you can't. You have to assume a client is okay until you get activity from it that tells you otherwise. Then you can decide to treat it as bad and next time it'll get caught in the tarpit. This might seem okay, except many of these attacks can come from dynamic ADSL users etc who just happen to have the latest worm virus.

Given that many attacks from PCs with dynamic IPs are infected with worm viruses without the owner even knowing, you can quickly build up an outdated tarpit blacklist. Do you start to see some problems?

Answer 2

Summary

Running a tarpit on a general purpose server does come with risks. If you know what the risks are you can mitigate them, depending on your level of comfort.

• You have to ensure you don't accidentally DOS your server w/ tarpit traffic
• You have to ensure you don't fill up your state tables w/ tarpitted connection info
• You have to ensure you don't flood your logs with tarpit connection information
• You need to ensure a long blacklist won't affect performance
• You need to ensure that your blacklist automatically expires hosts
• You need the ability to whitelist hosts (either permanently or with time-limit)

Thankfully this is all possible, and quite easy using regular iptables and ipset.

Limiting TARPIT resource usage

You can use iptables to limit how many hosts you TARPIT without using too many system resources. See example below. This includes network bandwidth, system memory, state stable entries, and other system resources. Get too many tarpitted connections, start ignoring them. If you organize your rule set in the correct order, none of the tarpitted connections end up on your state tables. Also make sure you don't log, unless you're doing realtime stats with something like a custom ulog -- Direct iptables tarpit logs can quickly fill up a disk.

In my experience my current hosts can easily hold 200+ hosts in a tarpit, with little noticeable effect on memory usage, traffic usage, or cpu usage. Likely I could push this further, but so far on average I'm only trapping around 130 hosts at any given moment.

The reason why I implemented the limits, was as stated in another suggestion, because my first tarpit host became flooded. This was a trivial workaround. I've had no issues since.

Using ipset for efficient blacklists

ipset is an great little tool that allows you to create groups of objects to use in iptables rules. Not only that, but since it can hold the objects in a hash table, the larger the ipset the faster it is compared to the equivalent linear set of iptables rules.

In addition to that, the lists can include counters (packets/bytes), timeout, and exclusion on a per object basis.

You can add/remove from ipset with most programs that automatically block, such as fail2ban, ossec, and more. Because you can set a default timeout, you can ensure that entries are expired regardless what program set the entry.

Example

Here's an example based on what I use on servers I manage that mitigates the risks listed above:

Caveat

### Note:  This does not account for all possible traffic you might need or want
###        This is only an example of mitigating common risks of using a tarpit
###        Use at your own risk

Configuring ipset

# Create the ipset blacklist
# options:
# - create         : create a new ipset
# - blacklist      : Name of the ipset we'll reference in the iptables rule
# - hash:net       : Make blacklist type hash to hold network (ip/mask) data
# - family inet    : This is for IPv4 data (inet6 for IPv6)
# - counters       : We want packet/byte stats counted for each entry
# - comment        : So we can add a comment with each entry (handy)
# - timeout 604800 : Set a default timeout of 604800 seconds (1 week) for each new entry
# - nomatch        : Allow us to enter exclusion entries (never match an entry)
ipset create blacklist hash:net family inet counters comment timeout 604800 nomatch

# Create an entry to never blacklist a trusted network
# options:
# - timeout 0      : entry never expires
# - nomatch        : Tells IPset to never match this entry (whitelist, in our usage)
ipset add blacklist 123.45.67.0/24 comment "Trusted subnet, causes breakage if blocked" timeout 0 nomatch

# Example to blacklist hosts
# no netmask implies /32 (or /128 for ipv6)
ipset add blacklist 34.56.78.90 comment "SSH Bruteforce"
ipset add blacklist 23.45.67.89 comment "SQL Injection" timeout 12345
# etc...

Configuring iptables

# Flush the input table
iptables -F INPUT

# Drop the custom flow TAR
iptables -X TAR

# Set default INPUT policy to DROP
iptables -P INPUT DROP

# Create the chain TAR
iptables -N TAR

# Send all blacklisted hosts to the tarpit
iptables -A INPUT -m set --match-set blacklist src -j TAR

# Allow established connections
# Note: after the blacklist so newly blacklisted threats are immediately ignored
#       Yes, that will cause the server to hold the state open until it times out.
#       Would you rather have a malicious host continuing its attack?
iptables -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# Allow the services we want
# Note:  These create new state table entries/use up memory
# Note:  We do not account for synflood prevention in this example
iptables -A INPUT -p tcp -m multiport --dports 22,80,443 -m tcp --syn -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -p icmp -m icmp --icmp-type 8 -m conntrack --ctstate NEW -j ACCEPT

# Send everything else to tarpit chain
iptables -A INPUT -j TAR

# This is the tarpit chain

# Tarpit up to 10 unique connections a second, any more, and pass to next rule
# Note: 10/s limit is arbitrary, adjust to your preference (experiment)
iptables -A TAR -p tcp -m limit --limit 10/sec -j TARPIT --tarpit 

# Drop everything else that makes it this far
# You can also set to REJECT which will immediately tell all connections to buzz off
iptables -A TAR -j DROP

Looking at trapped hosts realtime

$ sudo tcpdump -npi eth0 'src YOUR.HOST.IP and (tcp[14] = 0 && tcp[15] = 0)'

Answer 3

Downsides

I've been using TARPIT in my servers since forever. That's 20+ years guaranteed. The only downsides I found are:

• Installation requires compilation — the TARPIT target is not part of the stock Linux kernel, instead it is provided by the XTables-addon package. AFAIK, no major Linux distributions provide the addon as a ready-to-install binary package. So to have the TARPIT target you must get the sources and build the module yourself. Nowadays most Linux distros make this task easy, but it is still not as easy as apt install PACKAGE.

• Increased iptables rules complexity — although the TARPIT mechanism was designed to tie up only an attacker's resources, an improperly configured system can open your server to DOS attacks. Unfortunately, the most intuitive way to implement TARPIT (“oh, let's just replace -j DROP with -j TARPIT”) is wrong and is the one that leaves servers vulnerable. The reason is because the kernel does not know about your tarpitting business, and will attempt to do connection tracking in spite of it, and this will use resources on your server. An attacker who knows that your server is misconfigured like this can DOS it very easily, and to prevent that you need to do some tricks on your iptables rules, which adds complexity. Here's a gist with the technique I use and avoids this problem: https://gist.github.com/flaviovs/103a0dbf62c67ff371ff75fc62fdded3

Vulnerabilites

From an implementation perspective, as far as I can tell the only potential issue is the connection tracking DOS attack explained above, which can be exploited if you don't configure your iptables properly

If you're talking about software vulnerabilities, then it is hard to prove that any software is free of problems. Given the maturity of the project I deem it as pretty safe. AFAIK there's no reported vulnerability against it too. Of course, this is just me — you should your due diligence before using it.