Tarpit for pf or ipfw ?

L

Larry555

Hello,

I am wondering a switch from Linux and I wish to know if pf() is able to tarpit an IP dynamically like iptables is able to.

This is the -j TARPIT rule.

I am aware of laBrea but it requires specific IP's. I want to be able to tarpit on my main IP. I am not interested in a honeypot here (which labrea is).

Will I need to throw pf() or ipfw() out of my stack and install iptables for FreeBSD?

Thanks,
 
Larry555 said:
This is the -j TARPIT rule.
Click to expand...
This command by itself doesn't do anything. It simply passes processing on to a chain called TARPIT.
Will I need to throw pf() or ipfw() out of my stack and install iptables for FreeBSD?
Click to expand...
That's not possible, IPTables is a Linux only firewall.
 
@SirDice : almost.

When compiled in the kernel, TARPIT becomes a default rule like ACCEPT or DROP. Not one you create yourself. It is useful to slow down worms and so on not by limiting their conn / s but ignoring any connection from them and letting them think everything is alright. Very different than DROP (will not slow down). It puts the tcp stack to zero for this connection, while the offending client is waiting for a reply (which will never come). The timeout is approx 2 min but you can change it.
 
Just block or drop the traffic. Don't waste any processing power on it.
 
Larry555 said:
I am wondering a switch from Linux
Click to expand...
Definitely try it! FreeBSD is awesome :) The TARPIT functionality for iptables on GNU/Linux looks interesting. If I'm reading the website correctly, it's an add-on module and not part of the core iptables project.

I do not believe that PF or IPFW have a directly equivalent capability. You may be able to achieve something similar using traffic shaping with ALTQ(4) for PF or dummynet(4) for IPFW. In his excellent PF guide, Peter Hansteen suggests directing traffic to a low bandwidth queue using the "overload" state option. From the "Turning away the brutes" page:
You may not need to block all of your overloaders
[...]
You could for example use an overload rule to protect a mail service or a web service, and you could use the overload table in a rule to assign offenders to a queue with a minimal bandwidth allocation (see the Section called ALTQ - handling unwanted traffic in the Chapter called Directing traffic with ALTQ [1])
[...]
Click to expand...
[1] ALTQ - handling unwanted traffic in the Chapter called Directing traffic with ALTQ
 
I would asteriskRoss, but this feature is essential to me.

ALTQ is very powerful but doesn't seems to play with the tcp window size easily though..

:)
 
Larry555 said:
I would asteriskRoss, but this feature is essential to me.
Click to expand...
For what exactly do you need it for? We may have different solutions. But as I said, if it's to block spammers and all, just block the traffic. There's no sense in trying to delay these guys, they're not going to be bothered by it.
 
It has been effective in the last ddos we faced. Just blocking leads to cpu and bandwidth consumption whereas tarpiting is really effective to diminish the flow of attack.

In the meantime -> mail to isp's
 
If it's a proper DDoS the only remediation is at the ISP level, long before the traffic is sent to your network. If an attack completely saturates your uplink nothing will help on your end. But it does depend on the type of DDoS. Lately an NTP amplification and/or DNS amplification attack seems to be quite popular. As there's no 'real' connection, the responses are UDP packets to a spoofed address, a tarpit isn't going to help. Even blocking won't help as the uplink would still be saturated.
 
SirDice said:
For what exactly do you need it for? We may have different solutions. But as I said, if it's to block spammers and all, just block the traffic. There's no sense in trying to delay these guys, they're not going to be bothered by it.
Click to expand...
Excuse me for responding to a very old post but I very strongly feel that I must.
I was getting a great deal of traffic from hackers (bots probably) trying to get in through SSH. Yes the SSH port was blocked via IPFW but it was still getting a lot of traffic. I have now added a tarpit to my defences and it has greatly reduced the amount of hacker traffic. The CPU overhead has been minimal (most of the time it's just idling) and I highly recommend it. I just wish there was something a little nastier I could send back - kind of like I do with http hackers :cool:
 
You must log in or register to reply here.
Back
Top