fail2ban for NetBSD-based routers & networks

[Erik Fair]

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.

thanks,

Erik <***@netbsd.org>


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[matthew sporleder]

Post by Erik Fair
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.
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.
thanks,

fail2ban is in wip

I started working on a fork many weekends ago but didn't get very far
due to the path assumptions made in the software.

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Erik E. Fair]

The key question for me is not just banning peer host on a given host from
reading its logs, but forwarding host ban information to my router in an
authenticated (and possibly encrypted) manner such that the offending host's
packets never reach my LAN at all for the duration of the ban.

One answer is to forward logs (ah, syslog ...) to the router for it to parse
directly, but that has issues, too. I'd argue that the data reduction
should be done on the attacked host.

Erik <***@netbsd.org>

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Adrian Steinmann]

You could see if http://www.webgroup.ch/ipfw_ban/ might be
configured/extended for your case. It monitors arbitrary log files
and does the selective blocking on IPs gleaned from them for a
configurable period.

Alas, it is ipfw-based and IPFW_BAN::housekeeping() would need to
be broken out to support an arbitrary user action, like in your
case notifying the router. This could be easily done by letting the
user pass a code reference for the actual block/unblock actions.

If you are so inclined, we can generalize the above and then I'll
put it into pkgsrc/wip - I had written it a while back because
fail2ban was just too unwieldy for my purposes (NIH).

Ast

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Manuel Bouyer]

Post by Erik Fair
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.
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.