aboutsummaryrefslogtreecommitdiff
path: root/content/posts/2004-01-12-tarpitting-in-iptables.html
blob: 52108686f73be5ec84b5cf010f2032bea25439d2 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
---
date: "2004-01-12T00:10:53Z"
title: tarpitting in iptables
---

<p>
The incredible <a
href='http://www.propylon.com/news/ctoarticles/lurking_030415.html'>lurking</a>
Pablo strikes again! I saw this bit on <acronym
title='Internet Relay Chat'>IRC</acronym> an hour ago:
</p>

<pre>
23:09 &lt;ljlane&gt; wow, read some really evil tarpitting stuff
23:10 &lt;radsaq&gt; really?
23:11 &lt;ljlane&gt; yeah, <a href='http://www.securityfocus.com/infocus/1723'>http://www.securityfocus.com/infocus/1723</a>
23:11 &lt;ljlane&gt; tarpit just before your drop rule. tarpit all ports, tarpit 
               unused nets, etc
</pre>

<p>
Interesting stuff.  That said, I still prefer <a
href='http://www.snowman.net/'>Stephen's (Snow-Man)</a> more draconian
approach; hitting an invalid port tosses you in an <a
href='http://snowman.net/projects/ipt_recent/'><code>ipt_recent</code></a>
list, which drops <em>all</em> of your traffic for a few minutes.  The
tarpitting approach, while effective at slowing down and confusing a
probe, still leaves you vulnerable.  The <a
href='http://snowman.net/projects/ipt_recent/'><code>ipt_recent</code></a>
approach kills automated port scans almost completely, without using as
many resources on the firewall.
</p>