Re: [Sshguard-users] How do I use a custom backend .h, and other newbie Qs

[Mike B. <mi...@sk...>]

Mij wrote:
> > On my FreeBSD system, I've been using route(4) to manually manipulate my 
> > routing tables, setting up blackhole routes for IPs from which attacks 
> > originate. This works much more efficiently than ipfw, and very thoroughly 
> > blocks all communication with the compromised hosts.
> 
> thanks, in general I appreciate contributions and customization so I look 
> fwd to include this into the trunk as soon as it becomes a convenient 
> solution.
> 
> In which circumstances does this work more efficiently than ipfw or another 
> firewall? I consider quite negligible the load of rejecting connections: 
> what is the load at which you see this improvement?

Thanks for replying. You ask good questions.

I must admit, I've done no research of my own into this; I'm just relying 
entirely on the info in this message:

http://lists.freebsd.org/pipermail/freebsd-questions/2005-July/092090.html

(quoting the OP): "This is executed in the IP stack and is faster than in the 
firewall when you have over 20 of those special 'deny this IP address' rules 
in the firewall."


A little Googling shows that someone else asked about the technique here (a 
couple years earlier):

http://osdir.com/ml/os.freebsd.devel.net/2003-05/msg00168.html

Opinions on efficiency differed but were inconclusive.
This reply offered another route-based approach: 
http://osdir.com/ml/os.freebsd.devel.net/2003-05/msg00225.html
(rather than routing to localhost with the 'blackhole' option, route to a 
specially configured pseudo-device with the same functionality)

> A benefit that I see is that there is no dependency on specific firewalls 
> anymore. A drawback is that routing tables are not meant for this, so it 
> might be tricky to manage sshguard rules and avoid messing up with "manual" 
> ones. If you're interested in contributing this, please have a look at the 
> question of the portability across systems different from linux.

The solution seems to rely on features/efficiencies of FreeBSD, but I don't 
know anything about Linux's TCP/IP stack, so maybe the situation there is 
similar. I'm not qualified to judge.

(I'll respond to the rest later)

Thanks again,
-Mike