TCP wrapper alternative?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

TCP wrapper alternative?

Thomas Smith-3
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?

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

Reply | Threaded
Open this post in threaded view
|

Re: TCP wrapper alternative?

torsten
HI
A much simpler option Is D.J.  Bernstein's tcpserver in combination with daemontools

I use it for all sorts of things including IP black listing into pf's tables
The packages are in the ports system

T

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Thomas Smith
Sent: 09 July 2019 19:04
To: [hidden email]
Subject: TCP wrapper alternative?

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?

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


Reply | Threaded
Open this post in threaded view
|

Re: TCP wrapper alternative?

Peter Nicolai Mathias Hansteen
In reply to this post by Thomas Smith-3


> 9. jul. 2019 kl. 20:03 skrev Thomas Smith <[hidden email]>:
>
> 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.

How about having your IP reputation system dump its data (which comes down to IP addresses and ranges plus associated rating) to something parseable that could then be loaded into whatever number of tables you need, to be used in your PF rules?

I imagine it wouldn’t be all that hard, depending on the degree of clunkiness of the reputation data export mainly, have the data refresh (data export, table reload) run from a cron job however often it seems useful.

- Peter


Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.





signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: TCP wrapper alternative?

Marc Espie-2
In reply to this post by Thomas Smith-3
On Tue, Jul 09, 2019 at 11:03:36AM -0700, Thomas Smith 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.

That's what tables are for, usually, but you don't have a hook to decide
beforehand... afaik

Reply | Threaded
Open this post in threaded view
|

Re: TCP wrapper alternative?

Peter Nicolai Mathias Hansteen
In reply to this post by Peter Nicolai Mathias Hansteen
On Tue, Jul 09, 2019 at 01:18:36PM -0700, Thomas Smith wrote:

>
> >> 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.
> >
> > How about having your IP reputation system dump its data (which comes down to IP addresses and ranges plus associated rating) to something parseable that could then be loaded into whatever number of tables you need, to be used in your PF rules?
> >
> > I imagine it wouldn’t be all that hard, depending on the degree of clunkiness of the reputation data export mainly, have the data refresh (data export, table reload) run from a cron job however often it seems useful.
>
> I'm actually already doing something similar to this--loading tables periodically. And this works reasonably well.
>
> The problem is that this isn't real time--there's always a delay between updates, leaving an opportunity for 'bad' traffic to traverse the firewall.
>
> I'm trying to workout a solution that's more real time than this--it actually does make a difference.
>
> There are times when when a new IP is added or removed from the reputation system but those changes aren't updated locally for a period of time, so traffic flow within that window may not be correct (blocking good traffic or not blocking bad traffic).

There will always be a strictly nonzero lag and a strictly nonzero error rate.

You know your particular application and data sources better than I do of course, but I have
anecdotal evidence that I might come around to writing up that changes in IP reputation in
some systems at least could take about a week to actually propagate.

It really comes down to how completely you can trust your data sources on data quality
and update rate.

It is possible to write OpenBSD applications that manipulate the contents of tables (dhcpd
and bgpd come to mind). A daemon that monitors changes in your IP reputation data could
conceivably add or remove table entries based on those changes immediately after receiving
the changes. It would take a bit of coding, but grabbing the relevant bits from existing
daemons should get you at least part of the way there.

Failing that, the dump-to-file, update table contents could easily be done by a tiny shell
script run from a frequently run cron job.

- Peter

--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.

Reply | Threaded
Open this post in threaded view
|

Re: TCP wrapper alternative?

Stuart Henderson
In reply to this post by Thomas Smith-3
On 2019-07-09, Thomas Smith <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|

Re: TCP wrapper alternative?

Gustavo Rios
In reply to this post by Thomas Smith-3
look at: http://cr.yp.to.

Em ter, 9 de jul de 2019 às 16:52, Thomas Smith <[hidden email]> escreveu:

>
> 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?
>
> 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
>


--
Pag Bem Fácil Ltda
www.pagbemfacil.com.br