On 2019-07-09, Thomas Smith <anon1...@icloud.com> wrote: > Hi, > > I'm considering an option to evaluate connecting IPs before they're evaluated > by `pf` in order to make some decisions about the "reputation" of a > connecting IP. Then if that reputation is low enough, some action could > either be taken: in `pf` to protect the associated application (say by > blocking the connection); or in the app responsible for the listening port. > > `pf`, unfortunately, isn't able to make routing decisions based on external > factors (insofar as I understand)--I'm hoping to add some additional (very > simple) intelligence to that. Just another metric or two for determining if a > connection is legitimate. > > I've been looking into TCP wrappers for OpenBSD but it seems that this > functionality was removed in version 5. Is my understanding of that correct?
TCP wrappers was removed in 5.6, but it likely wouldn't have done what you wanted anyway, it worked for programs run from inetd or daemons that linked directly to libwrap, neither of which are typically the case for most modern network daemons. > If so, is there an alternate way to achieve what I mentioned? > > I know I can use something like sshguard or fail2ban, but I'm looking for a > much simpler option and one that preferably doesn't rely on tailing log files > (if there aren't viable alternatives, I may consider these, however). > > ~ Tom > > I can't think of anything already written so you'll likely need to write code to do this. I would look at something where you use divert-to in PF to pass packets to a userland proxy. This would listen for incoming diverted connections, do the reputation check on the source address, if good then make a second connection from itself to the destination (which could be on the same machine) and connect the two sockets together. This can use the SO_SPLICE socket option so that the kernel joins the two directly after the connection is setup, which means the userland program only needs to deal with initial connection and can then get out of the way of most of the network traffic. If you need to maintain the original source address on the connection to the end server that's possible too but I think will need the SO_BINDANY socket option + divert-reply. For inspiration look at things like relayd, spamd, ftp-proxy and /usr/src/regress/sys/kern/sosplice/perf/relay.c. You could alternatively do something with PF's divert-packet (similarly named to the above but quite different), there is basic example code on how to use this in divert(4). This would likely be a bit easier to get running initially, but performance of forwarded connections is likely to be bad as it the program will need to deal with every packet and can't "get out of the way" after setup.
