Re: blacklistd is now available for current (comments?)
On Jul 12, 11:26am, rein...@netbsd.org (Reinoud Zandijk) wrote: -- Subject: Re: blacklistd is now available for current (comments?) | Hi Christos, | | Thanks for your blacklistd, its soo much more lightweight that the others i've | seen in pkgsrc; really frees up my small NAS. I've installed the -current | version as in tree. thanks. | There are a few oddities though, and maybe you could enlighten me on those. | | First of all your name is still in a custom rule in the default installed | bloacklistd.conf. I'd say just comment it oug :) I will comment it out... This was really an example file. | More importantly, blacklistctl can only dump rules; it doesn't have commands | for adding or removing rules manually. So when i had to manually allow a | machine, my only option was to trunk the db file and restarting blacklistd. I | later learned that blacklistd also has a -f to do this, but its a bit odd that | there isn't say a `blacklistctl allow host port' that reverses a decision it | made. Yes, I have not had a chance to write more commands, and I am still thinking about the security implications of allowing a command protocol through the named pipe. | `blacklistctl dump' without the '-a' doesn't show anything even when there are | machines blacklisted with timeouts. This is documented; by default it shows only the embryonic ones... Perhaps it is not that useful. christos
Re: blacklistd is now available for current (comments?)
Hi Christos, Thanks for your blacklistd, its soo much more lightweight that the others i've seen in pkgsrc; really frees up my small NAS. I've installed the -current version as in tree. There are a few oddities though, and maybe you could enlighten me on those. First of all your name is still in a custom rule in the default installed bloacklistd.conf. I'd say just comment it oug :) More importantly, blacklistctl can only dump rules; it doesn't have commands for adding or removing rules manually. So when i had to manually allow a machine, my only option was to trunk the db file and restarting blacklistd. I later learned that blacklistd also has a -f to do this, but its a bit odd that there isn't say a `blacklistctl allow host port' that reverses a decision it made. `blacklistctl dump' without the '-a' doesn't show anything even when there are machines blacklisted with timeouts. With regards, Reinoud pgpIht2VI9Ey8.pgp Description: PGP signature
Re: blacklistd is now available for current (comments?)
In article <201502040803.t1483mjm021...@server.cornerstoneservice.ca>, John Nemeth wrote: > > PAM wouldn't have access to the socket, so no it wouldn't be >that easy to add. Also, PAM is primarily for things that do >interactive logins IMAP should really be using SASL. However, that >would probably have the same problem of not having access to the >socket. Well, not entirely true since PAM runs in the same process, but yes trying to deduce which is the correct file descriptor to use is not an exact science. christos
Re: blacklistd is now available for current (comments?)
On Jan 20, 10:22pm, Brook Milligan wrote: } } Interesting coincidence; I was just exploring sshguard as a means } to accomplish similar goals this weekend. } } On Jan 20, 2015, at 7:54 PM, Christos Zoulas wrote: } > This is package contains library that can be used by network daemons to } > communicate with a packet filter via a daemon to enforce opening and } > closing ports dynamically based on policy. } } Having the daemons directly record the outcome of their authentication } seems preferable to groveling through log entries as, for example, } sshguard does. However, that requires modification of the relevant } daemons and is in that sense more intrusive. } } Is your idea to modify (or encourage modification of) a broad } array of daemons that might benefit from this? I'm thinking, } for example, of daemons responsible for IMAP mail delivery and } other such things that require credentials. Is this something } that can be added to PAM and thereby avoid being so intrusive on } the daemons themselves? PAM wouldn't have access to the socket, so no it wouldn't be that easy to add. Also, PAM is primarily for things that do interactive logins IMAP should really be using SASL. However, that would probably have the same problem of not having access to the socket. }-- End of excerpt from Brook Milligan
Re: blacklistd is now available for current (comments?)
Le 23/01/2015 22:52, Rhialto a écrit : On Wed 21 Jan 2015 at 08:11:59 -0500, Christos Zoulas wrote: As you can see from the patch, the daemon modification is trivial. Yes, I am planning to add this to more daemons (I think I will do named next because it is really spammy on my machines), and yes if there is a way to do this via PAM that would be even better. Maybe what the pam_af package is doing can be used? It can even run a program when blocking a host. The issue with PAM here is that the command will necessarily run under the user associated with the service, so this means that this user can alter fw rules (which is quite problematic when it is not root). Passing file descriptors has the advantage of avoiding confused deputy. The application cannot pass a connection to blacklistd that was not accept(2)ed beforehand. Unfortunately PAM API is not helpful here, pam_handle_t has no field to pass arbitrary data to modules, nor specify what they can do with it. Blacklisting can also happen in situations where PAM is not necessarily involved (anonymous LDAP binds that thrash slapd, krb TGT bruteforce, slowloris kiddies...). -- Jean-Yves Migeon
Re: blacklistd is now available for current (comments?)
On Jan 23, 10:52pm, rhia...@falu.nl (Rhialto) wrote: -- Subject: Re: blacklistd is now available for current (comments?) | Maybe what the pam_af package is doing can be used? | It can even run a program when blocking a host. I looked at: https://github.com/stass/pam_af and it does not have seem to have access to enough information to do what I need (a file descriptor to the connection socket). christos
Re: blacklistd is now available for current (comments?)
On Wed 21 Jan 2015 at 08:11:59 -0500, Christos Zoulas wrote: > As you can see from the patch, the daemon modification is trivial. Yes, > I am planning to add this to more daemons (I think I will do named next > because it is really spammy on my machines), and yes if there is a way > to do this via PAM that would be even better. Maybe what the pam_af package is doing can be used? It can even run a program when blocking a host. > christos -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgp5y7eOB4_yU.pgp Description: PGP signature
Re: blacklistd is now available for current (comments?)
Thanks everyone for their feedback; there is a new blacklistd.tar.gz in the same place (http://www.netbsd.org/~christos/blacklistd.tar.gz) with the following new features: - udp now works - patches for named in addition to sshd - efficiency fixes - allow address selection and individual per blacklist rule npf rule names - NetBSD rc system integration - linux and macosx port (cd port; autoreconf -f -i; make) XXX: alas no iptables shell script (yet), and no packet filter is MacOS/X XXX: No packaging for linux and MacOS/X - new TODO file - multiple socket support to handle chrooted daemons (like syslogd) Simple instructions: - extract the tar, make includes && make && make install - Apply the patches to sshd and named. - Fix the named and sshd Makefiles, simply: SRCS+=pfilter.c LDADD+=-lblacklist - Build and install - Edit your npf.conf to add the blacklist dynamic ruleset, see the README file for that. - Edit your /etc/rc.conf to add: blacklistd=YES - Restart the daemons env - /etc/rc.d/blacklistd restart env - /etc/rc.d/named restart env - /etc/rc.d/sshd restart - See activity: grep blacklistd /var/log/messages - See blocked addresses npfctl rule blacklistd list Enjoy, christos
Re: blacklistd is now available for current (comments?)
On Jan 21, 5:11pm, mar...@duskware.de (Martin Husemann) wrote: -- Subject: Re: blacklistd is now available for current (comments?) | On Wed, Jan 21, 2015 at 10:48:40AM -0500, Christos Zoulas wrote: | > The current implementation of groups and rules on npf is interface-specific, | > and it is not finalized yet. I considered adding per interface rules, but | > that introduces complexity. Perhaps I will add a flag to the daemon to | > handle this, making the configuration line look like: | | Wouldn't it be better per address than per interface? Yes, I will implement that... christos
Re: blacklistd is now available for current (comments?)
On Wed, Jan 21, 2015 at 10:48:40AM -0500, Christos Zoulas wrote: > The current implementation of groups and rules on npf is interface-specific, > and it is not finalized yet. I considered adding per interface rules, but > that introduces complexity. Perhaps I will add a flag to the daemon to > handle this, making the configuration line look like: Wouldn't it be better per address than per interface? Martin
Re: blacklistd is now available for current (comments?)
On Jan 21, 3:43pm, ja...@uninett.no (Jarle Greipsland) wrote: -- Subject: Re: blacklistd is now available for current (comments?) | > # Blacklist rule | > # Port typeprotocolowner nfail disable | > ssh stream tcp * 6 60m | > ssh stream tcp6* 6 60m | What about hosts with multiple addresses and multiple instances | of the same daemon? I.e. an ssh daemon for ordinary login on IP | address a.b.c.d, and an anoncvs ssh daemon on a.b.c.e, and you | want different policies for how to blacklist remote clients? | Maybe do something like postfix, and allow a.b.c.d:ssh as a | service specifier instead of just a port number/name? The current implementation of groups and rules on npf is interface-specific, and it is not finalized yet. I considered adding per interface rules, but that introduces complexity. Perhaps I will add a flag to the daemon to handle this, making the configuration line look like: # external interface ssh stream tcp6bge0* 6 60m # internal interface ssh stream tcp6sk0 * * * and then automatically create the rule "blacklistd-bge0", etc. * again there will mean all the interfaces. This does not handle though the case of multiple addresses on the same interface. Should it handle that too? It would be easy to extend the syntax to handle address:port in the first field. christos
Re: blacklistd is now available for current (comments?)
chris...@zoulas.com (Christos Zoulas) writes: > > You can get it from http://www.netbsd.org/~christos/blacklistd.tar.gz > > Appended is the README file. I wrote this over the weekend, it seems to > work :-) Please let me know what you think? Is it useful? Should I commit > it to the base system? Do you have any suggestions to improve it? [ ... ] > The configuration file contains entries of the form: > > # Blacklist rule > # Porttypeprotocolowner nfail disable > ssh stream tcp * 6 60m > ssh stream tcp6* 6 60m What about hosts with multiple addresses and multiple instances of the same daemon? I.e. an ssh daemon for ordinary login on IP address a.b.c.d, and an anoncvs ssh daemon on a.b.c.e, and you want different policies for how to blacklist remote clients? Maybe do something like postfix, and allow a.b.c.d:ssh as a service specifier instead of just a port number/name? -jarle -- "Crime in multi-storey car parks. That is wrong on so many different levels." -- Tim Vine
Re: blacklistd is now available for current (comments?)
Le 21/01/2015 14:24, chris...@zoulas.com a écrit : | I do think it is. TBH there are tons of services out there that fail at | implementing proper blacklisting (with expiration) for sockets. And PAM | does not really fit the bill. I did not find any that does this directly (not via parsing logs), have you? Nope. The closest thing I can think of is modsecurity for Apache, but it does not set fw rules. It blocks at application layer. Spam filters do something like this too, but it also stays at application layer. Some do that directly through the firewall using rate limiting (sometimes with complex attributes evaluation), but IMHO it is a fragile approach. Counting the number of new connections over a period of time does not work well; you can maybe rate limit SSH to 1 attempt per second, less so for HTTP... And that does not really eradicate the noise. | - why have blacklist() and blacklist_r()? Make blacklist() use the | cookie and drop blacklist_r(). Makes the API simpler too; | - in case we get /etc/rc.d/backlistd, perhaps it should be integrated | with /etc/rc.d/npf so a restart from npf reloads blacklist configuration | also? I modelled it after syslog... Okay then. | - I would use CLOCK_MONOTONIC instead of REALTIME for calculation. | syslog(3) will log the wallclock anyway; Yes, that's a good idea. I like CLOCK_REALTIME for debug though :-) Problem is that time is recorded in the db file, and you can't mix debug and non-debug entries then (I don't want to add a flag to say what it is). That makes sense | - open question: is there a chance that blacklistd can get confused when | blacklist set is edited by hand through npfctl(8)? I am thinking along | the lines of rem-id collision where someone removes/adds rules to | blacklist through npfctl and forget to stop blacklistd, which will try | to remove the old rules later... I think that you always get new ids for the rules (ids are not reused). If you remove a rule manually rule removal will fail. If you add rules manually they won't be touched by blacklistd. As for syncing with npf, I might add in the future a TTL for dynamic rules in NPF so there is no state kept in blacklistd. Great. Anyway, even if it does not make get into base, I would gladly use it if it is in pkgsrc :) Cheers, -- Jean-Yves Migeon
Re: blacklistd is now available for current (comments?)
On Jan 21, 11:54am, jeanyves.mig...@free.fr (Jean-Yves Migeon) wrote: -- Subject: Re: blacklistd is now available for current =?UTF-8?Q?=28comment | I always preferred this way of tweaking fw rulesets instead of relying | on "complex" (regex-based) parsers of logfiles written in | . Tt requires a minor annoyance though: | patching the listening daemon. Yes, but this is done ones... | I do think it is. TBH there are tons of services out there that fail at | implementing proper blacklisting (with expiration) for sockets. And PAM | does not really fit the bill. I did not find any that does this directly (not via parsing logs), have you? | I do have a few recommandations and remarks, and some depend on its use | in base. I know, talk is cheap :) | - blacklist_r(3) and blacklist_r() in code do not have the same | prototype. WIP? Yes, fixed. | - ideally blacklistd would run under its own chrooted user; alas this | requires some change to the code (open /dev/npf, chroot, and use libnpf | onwards. Maybe for v2 :) ); Yes, I've been thinking amongst those lines, but its attack surface is small. Yes, for v2 I am planning to use libnpf as an option. | - why have blacklist() and blacklist_r()? Make blacklist() use the | cookie and drop blacklist_r(). Makes the API simpler too; | - in case we get /etc/rc.d/backlistd, perhaps it should be integrated | with /etc/rc.d/npf so a restart from npf reloads blacklist configuration | also? I modelled it after syslog... | - I would use CLOCK_MONOTONIC instead of REALTIME for calculation. | syslog(3) will log the wallclock anyway; Yes, that's a good idea. I like CLOCK_REALTIME for debug though :-) Problem is that time is recorded in the db file, and you can't mix debug and non-debug entries then (I don't want to add a flag to say what it is). | - open question: is there a chance that blacklistd can get confused when | blacklist set is edited by hand through npfctl(8)? I am thinking along | the lines of rem-id collision where someone removes/adds rules to | blacklist through npfctl and forget to stop blacklistd, which will try | to remove the old rules later... I think that you always get new ids for the rules (ids are not reused). If you remove a rule manually rule removal will fail. If you add rules manually they won't be touched by blacklistd. As for syncing with npf, I might add in the future a TTL for dynamic rules in NPF so there is no state kept in blacklistd. christos
Re: blacklistd is now available for current (comments?)
On Jan 20, 10:22pm, br...@nmsu.edu (Brook Milligan) wrote: -- Subject: Re: blacklistd is now available for current (comments?) | Interesting coincidence; I was just exploring sshguard as a means to accomp= | lish similar goals this weekend. | | On Jan 20, 2015, at 7:54 PM, Christos Zoulas wrote: | > This is package contains library that can be used by network daemons to | > communicate with a packet filter via a daemon to enforce opening and | > closing ports dynamically based on policy. | | Having the daemons directly record the outcome of their authentication seem= | s preferable to groveling through log entries as, for example, sshguard doe= | s. However, that requires modification of the relevant daemons and is in t= | hat sense more intrusive. =20 Yes, I hate the grovelling through logs and I could not find something that did this directly, so I wrote it. | Is your idea to modify (or encourage modification of) a broad array of daem= | ons that might benefit from this? I'm thinking, for example, of daemons re= | sponsible for IMAP mail delivery and other such things that require credent= | ials. Is this something that can be added to PAM and thereby avoid being s= | o intrusive on the daemons themselves? As you can see from the patch, the daemon modification is trivial. Yes, I am planning to add this to more daemons (I think I will do named next because it is really spammy on my machines), and yes if there is a way to do this via PAM that would be even better. christos
Re: blacklistd is now available for current (comments?)
Le 21/01/2015 03:54, chris...@zoulas.com a écrit : You can get it from http://www.netbsd.org/~christos/blacklistd.tar.gz Appended is the README file. I wrote this over the weekend, it seems to work :-) Please let me know what you think? I always preferred this way of tweaking fw rulesets instead of relying on "complex" (regex-based) parsers of logfiles written in . Tt requires a minor annoyance though: patching the listening daemon. Is it useful? I do think it is. TBH there are tons of services out there that fail at implementing proper blacklisting (with expiration) for sockets. And PAM does not really fit the bill. Should I commit it to the base system? Do you have any suggestions to improve it? I do have a few recommandations and remarks, and some depend on its use in base. I know, talk is cheap :) - blacklist_r(3) and blacklist_r() in code do not have the same prototype. WIP? - ideally blacklistd would run under its own chrooted user; alas this requires some change to the code (open /dev/npf, chroot, and use libnpf onwards. Maybe for v2 :) ); - why have blacklist() and blacklist_r()? Make blacklist() use the cookie and drop blacklist_r(). Makes the API simpler too; - in case we get /etc/rc.d/backlistd, perhaps it should be integrated with /etc/rc.d/npf so a restart from npf reloads blacklist configuration also? - I would use CLOCK_MONOTONIC instead of REALTIME for calculation. syslog(3) will log the wallclock anyway; - open question: is there a chance that blacklistd can get confused when blacklist set is edited by hand through npfctl(8)? I am thinking along the lines of rem-id collision where someone removes/adds rules to blacklist through npfctl and forget to stop blacklistd, which will try to remove the old rules later... Cheers, -- jym@
Re: blacklistd is now available for current (comments?)
Interesting coincidence; I was just exploring sshguard as a means to accomplish similar goals this weekend. On Jan 20, 2015, at 7:54 PM, Christos Zoulas wrote: > This is package contains library that can be used by network daemons to > communicate with a packet filter via a daemon to enforce opening and > closing ports dynamically based on policy. Having the daemons directly record the outcome of their authentication seems preferable to groveling through log entries as, for example, sshguard does. However, that requires modification of the relevant daemons and is in that sense more intrusive. Is your idea to modify (or encourage modification of) a broad array of daemons that might benefit from this? I'm thinking, for example, of daemons responsible for IMAP mail delivery and other such things that require credentials. Is this something that can be added to PAM and thereby avoid being so intrusive on the daemons themselves? Cheers, Brook
blacklistd is now available for current (comments?)
You can get it from http://www.netbsd.org/~christos/blacklistd.tar.gz
Appended is the README file. I wrote this over the weekend, it seems to
work :-) Please let me know what you think? Is it useful? Should I commit
it to the base system? Do you have any suggestions to improve it?
christos
--- snip ---
# Tue Jan 20 21:18:54 EST 2015
This is package contains library that can be used by network daemons to
communicate with a packet filter via a daemon to enforce opening and
closing ports dynamically based on policy.
The interface to the packet filter is in etc/control (this is currently
designed for npf) and the configuration file (inspired from inetd.conf)
is in etc/conf.
A patch to OpenSSH is in ssh.diff that adds blacklisting capabilities to
openssh.
The network daemon (for example sshd) communicates to blacklistd, via
a unix socket like syslog. The library calls are simple and everything
is handled by the library. In the simplest form the only thing the
daemon needs to do is to call:
blacklist(action, acceptedfd, message);
Where:
action = 0 -> successful login clear blacklist state
1 -> failed login, add to the failed count
acceptedfd -> the file descriptor where the server is
connected to the remote client. It is used
to determine the listening socket, and the
remote address. This allows any program to
contact the blacklist daemon, since the verification
if the program has access to the listening
socket is done by virtue that the port
number is retrieved from the kernel.
message-> an optional string that is used in debugging logs.
The configuration file contains entries of the form:
# Blacklist rule
# Port typeprotocolowner nfail disable
ssh stream tcp * 6 60m
ssh stream tcp6* 6 60m
Here note that owner is * because the connection is done from the
child ssh socket which runs with user privs. We also register for
both tcp and tcp6 since those are different listening sockets and
addresses. We use nfail = 6, because ssh allows 3 password attempts
per connection, and this will let us have 2 connections before
blocking. Finally we block for an hour; we could block forever
too by specifying * in the duration column.
blacklistd and the library use syslog(3) to report errors. The
blacklist filter state is persisted automatically in /var/db/blacklistd.db
so that if the daemon is restarted, it remembers what connections
is currently handling. To start from a fresh state (if you restart
npf too for example), you can use -f. To watch the daemon at work,
you can use -d.
The current control file is designed for npf, and it uses the
dynamic rule feature. You need to create a dynamic rule in your
/etc/npf.conf on the group referring to the interface you want to block
called blacklistd as follows:
ext_if=bge0
group "external" on $ext_if {
...
ruleset "blacklistd"
...
}
Enjoy,
christos
