On Mon, Feb 11, 2013 at 06:00:52PM -0800, Erik Fair wrote:
> I use NetBSD as a router for my public IP network. It works pretty well, but
> I'm getting really tired of the door-knob turners who keep trying accounts &
> passwords on ssh, IMAP, etc. I would like to shut them out of the network as
> a a whole at my router efficiently.
>
> I can't do much about UDP attacks on DNS - those may or may not have a valid
> source IP address, so it would be foolish to trust that enough to use it as
> filtering source data. However, any TCP based attack has to be two-way, so
> that's worth banning.
>
> Does anyone have a fail2ban equivalent for NetBSD that has:
>
> authentication of the sources of the filtered addresses (by that I mean, any
> one of N authenticated hosts may contribute an address to the filter, but no
> one gets to lie to it - yes, I recognize that this means it must operate
> under one administrative authority),
>
> aging management of the blacklist, i.e. addresses age out, but if they come
> back, the age-out period goes up either geometrically or exponentially, and
>
> the blacklist is persistent across router reboots, e.g. a database in /var/db
> exists which an rc script will load into the operational blacklist at boot.
>
> Clearly, such a daemon/service has to use one of the filtering mechanisms
> available in NetBSD, e.g. ipf, pf; it would be helpful to know which of those
> have been exercised enough to be trusted with a potentially high rate of
> table/filter change without crashing the kernel.
I have a set of perl scripts which offers some of the features you're looking
at, but not all of them. But it could be a starting point. I'm attaching them.
The central point is band, which listen on TCP and unix sockets.
It gets BAN/UNBAN commands on the unix socket, keeps a temporary database of
banned hosts, and sends BAN/UNBAN commands to the clients over TCP.
a BAN commands includes a TTL in seconds, and band will clear this
entry when the TTL expires. A UNBAN command can also force an entry to
be removed.
clients exposed to internet (routers and a few hosts that have their own
filtering rules) runs listenban, which is also a deamon. It connects to band
and retrive banned hosts/protocols. On connect it gets the full database,
and then get updates (either ban or unban) when something changes on the
band side.
sendban is the tools that allows to send BAN/UNBAN requets to band
though the unix socket (so that I don't have to care much about auth,
the unix filesystem does it for me :)
It can be run from command line by admins, or from tools like fail2ban.
check_ban is just a nagios plugin.
In my setup, logs are centralized, this is also where band and fail2ban
are run.
--
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
NetBSD: 26 ans d'experience feront toujours la difference
--
Attachment:
listenban.pl
Description: Perl program
Attachment:
band.pl
Description: Perl program
Attachment:
sendban.pl
Description: Perl program
Attachment:
check_ban.pl
Description: Perl program