Tarpit usage question

Tarpit usage question

[Gary W. Smith]

Hi guys, 

I had a usage question about tarpit in respects to connection tracking.
We have a firewall that has a fairly heavy usage so we have put a
separate box external of the firewall to do tarpitting of port scanners.
Anyways, we are still being hit pretty hard by many things on this
firewall.  I was thinking about configuration tarpit on the firewall
cluster but wanted to ensure that connection tracking wasn't a problem.

Is it as simple as just sending the connection to the NOTRACK chain
before sending it to tarpit?

iptaables -t raw -A INPUT -p tcp -m tcp --dport 80 -j NOTRACK
iptables -A INPUT -p tcp -m tcp --dport 80 -j TARPIT

Is there a better approach to this?  Will this even work?  The rules
above are more or less just a sample.  I would want to block almost all
traffic destined for the input chain on the firewall on the external
interface unless it is related traffic.  

Gary Wayne Smith

Re: Tarpit usage question

[Taylor, Grant]

> Hi guys, 
> 
> I had a usage question about tarpit in respects to connection tracking.
> We have a firewall that has a fairly heavy usage so we have put a
> separate box external of the firewall to do tarpitting of port scanners.
> Anyways, we are still being hit pretty hard by many things on this
> firewall.  I was thinking about configuration tarpit on the firewall
> cluster but wanted to ensure that connection tracking wasn't a problem.
> 
> Is it as simple as just sending the connection to the NOTRACK chain
> before sending it to tarpit?
> 
> iptaables -t raw -A INPUT -p tcp -m tcp --dport 80 -j NOTRACK
> iptables -A INPUT -p tcp -m tcp --dport 80 -j TARPIT
> 
> Is there a better approach to this?  Will this even work?  The rules
> above are more or less just a sample.  I would want to block almost all
> traffic destined for the input chain on the firewall on the external
> interface unless it is related traffic.

If you were worried about just one port, as in your example, I would do what you have done.  However if you are planing on TARPITing a lot of ports (the majority of them) I would be tempted to do something like the following:

iptables -t raw -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -t raw -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -t raw -A INPUT -p tcp -j NOTRACK
iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A INPUT -p tcp -j TARPIT

This should cause any traffic that is not destined to known good ports to be not tracked and thus safe to send to the TARPIT.



Grant. . . .

RE: Tarpit usage question

[Gary W. Smith]

Grant, 

We're on the same page here.  Just one more question to confirm my
complete understanding.  We're natting some IP's in which we have
special rules and tables for.  This is all handled in the post/pre nat
table and the forward filter table.

I'm assuming that the input chain of the raw table is for locally
destined requests to the firewall itself. 

Ex.  The firewall external IP is 22.33.44.1 and I also assign 2-6 to the
firewall and NAT them in locally to 10.0.0.2-6 accordingly.  With this
said, if I setup the rules below on the raw table I'm assuming that it
will only be caught on the 22.33.44.1 IP.  Is this assumption wrong or
should I also qualify the addresses that I care about on the raw table.


Like this:

iptables -t raw -A INPUT -d 22.33.44.55 -p tcp --dport 22 -j ACCEPT
iptables -t raw -A INPUT -d 22.33.44.55 -p tcp --dport 443 -j ACCEPT
iptables -t raw -A INPUT -d 22.33.44.55 -p tcp -j NOTRACK
iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A INPUT -p tcp -j TARPIT


-----Original Message-----
From: netfilter-bounces@lists.netfilter.org
[mailto:netfilter-bounces@lists.netfilter.org] On Behalf Of Taylor,
Grant
Sent: Thursday, May 12, 2005 4:37 PM
To: netfilter@lists.netfilter.org
Subject: Re: Tarpit usage question

> Hi guys, 
> 
> I had a usage question about tarpit in respects to connection
tracking.
> We have a firewall that has a fairly heavy usage so we have put a
> separate box external of the firewall to do tarpitting of port
scanners.
> Anyways, we are still being hit pretty hard by many things on this
> firewall.  I was thinking about configuration tarpit on the firewall
> cluster but wanted to ensure that connection tracking wasn't a
problem.
> 
> Is it as simple as just sending the connection to the NOTRACK chain
> before sending it to tarpit?
> 
> iptaables -t raw -A INPUT -p tcp -m tcp --dport 80 -j NOTRACK
> iptables -A INPUT -p tcp -m tcp --dport 80 -j TARPIT
> 
> Is there a better approach to this?  Will this even work?  The rules
> above are more or less just a sample.  I would want to block almost
all
> traffic destined for the input chain on the firewall on the external
> interface unless it is related traffic.

If you were worried about just one port, as in your example, I would do
what you have done.  However if you are planing on TARPITing a lot of
ports (the majority of them) I would be tempted to do something like the
following:

iptables -t raw -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -t raw -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -t raw -A INPUT -p tcp -j NOTRACK
iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT
iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
iptables -t filter -A INPUT -p tcp -j TARPIT

This should cause any traffic that is not destined to known good ports
to be not tracked and thus safe to send to the TARPIT.



Grant. . . .

Re: Tarpit usage question

[Taylor, Grant]

> Ex.  The firewall external IP is 22.33.44.1 and I also assign 2-6 to the
> firewall and NAT them in locally to 10.0.0.2-6 accordingly.  With this
> said, if I setup the rules below on the raw table I'm assuming that it
> will only be caught on the 22.33.44.1 IP.  Is this assumption wrong or
> should I also qualify the addresses that I care about on the raw table.
> 
> iptables -t raw -A INPUT -d 22.33.44.55 -p tcp --dport 22 -j ACCEPT
> iptables -t raw -A INPUT -d 22.33.44.55 -p tcp --dport 443 -j ACCEPT
> iptables -t raw -A INPUT -d 22.33.44.55 -p tcp -j NOTRACK
> iptables -t filter -A INPUT -p tcp --dport 22 -j ACCEPT
> iptables -t filter -A INPUT -p tcp --dport 443 -j ACCEPT
> iptables -t filter -A INPUT -p tcp -j TARPIT

Well the idea that I was after was that you explicitly handle anything except what you know to (likely) be valid traffic in such a way that it will not be connection tracked and ultimately TARPITed.  Thus if you have multiple valid source IP / port combinations you would want to do a series of ACCEPT targets.

iptables -t raw -A INPUT -d 22.33.44.55 -p tcp --dport 22 -j ACCEPT
iptables -t raw -A INPUT -d 22.33.44.55 -p tcp --dport 443 -j ACCEPT
iptables -t raw -A INPUT -d 22.33.44.55 -p tcp -j NOTRACK
iptables -t raw -A INPUT -d 22.33.44.1 -p tcp --dport 22 -j ACCEPT
iptables -t raw -A INPUT -d 22.33.44.1 -p tcp --dport 443 -j ACCEPT
iptables -t raw -A INPUT -d 22.33.44.1 -p tcp -j NOTRACK
iptables -t raw -A INPUT -d 22.33.44.2 -p tcp --dport 22 -j ACCEPT
iptables -t raw -A INPUT -d 22.33.44.2 -p tcp --dport 443 -j ACCEPT
iptables -t raw -A INPUT -d 22.33.44.2 -p tcp -j NOTRACK
...
iptables -t filter -A INPUT -d 22.33.44.55 -p tcp --dport 22 -j ACCEPT
iptables -t filter -A INPUT -d 22.33.44.55 -p tcp --dport 443 -j ACCEPT
iptables -t filter -A INPUT -d 22.33.44.55 -p tcp -j TARPIT
iptables -t filter -A INPUT -d 22.33.44.1 -p tcp --dport 22 -j ACCEPT
iptables -t filter -A INPUT -d 22.33.44.1 -p tcp --dport 443 -j ACCEPT
iptables -t filter -A INPUT -d 22.33.44.1 -p tcp -j TARPIT
iptables -t filter -A INPUT -d 22.33.44.2 -p tcp --dport 22 -j ACCEPT
iptables -t filter -A INPUT -d 22.33.44.2 -p tcp --dport 443 -j ACCEPT
iptables -t filter -A INPUT -d 22.33.44.2 -p tcp -j TARPIT

Something else that you might want to look in to would be using the set match extension.  The set match extension would be a good match for what you are doing as you can build a ""set of IP addresses, and / or ports, and or <bla> that can be bound together in such a way that you could match all the valid traffic in one rule vs multiple rules.  If you want help looking in to this let me know and I'll be glad to help.



Grant. . . .

RE: Tarpit usage question

[Gary W. Smith]

Grant, 

This all makes complete sense.  I should have everything I need now to
make this work.  What you have suggested is exactly what I wanted to do
anyways.  I just wanted to make sure that my overall understanding of
the raw table was correct.

> Well the idea that I was after was that you explicitly handle anything
> except what you know to (likely) be valid traffic in such a way that
it
> will not be connection tracked and ultimately TARPITed.  Thus if you
have
> multiple valid source IP / port combinations you would want to do a
series
> of ACCEPT targets.

Gary Wayne Smith