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 via email to