This is topic is a little old so I will repeat my last message below. I am still seeing this issue and cannot understand why it seems to work sometime and not others. Can anyone shed any light? Here is what happened yesterday.
At Feb 12 17:56:01 someone at 195.154.42.18 started trying to hack my phone switch. At 17:56:02 that address was added to pf. The attack continued until 18:19:09, over 23 minutes later with 9888 attempts. I just can't understand why pf didn't block this address. On Fri, 28 Nov 2014 10:19:42 -0500 "D'Arcy J.M. Cain" <[email protected]> wrote: > On Sun, 23 Nov 2014 13:22:01 -0500 > "D'Arcy J.M. Cain" <[email protected]> wrote: > > To summarize, the answer to my original issue is to NOT keep state > > on incoming UDP connections. > > After making this change the situation seems to have improved but it > is still not quite right. Here is the relevant parts of my pf.conf. > > table <AUTOBLOCK> persist > set block-policy drop > scrub in all > block in log on $ext_if > pass out all > block in quick log on $ext_if from <AUTOBLOCK> > pass in log on $ext_if proto udp from any to any port 5060 no state > > The last two lines are rules 8 and 13. > > This morning I saw three connections from 75.55.69.69 ports to 5060: > > 2014-11-28 04:32:59.283909 rule 13/0(match): pass in on bge0: > 75.55.69.69.6216 > 98.158.139.74.5060: SIP, length: 404 > 2014-11-28 04:33:08.144545 rule 13/0(match): pass in on bge0: > 75.55.69.69.5770 > 98.158.139.74.5060: SIP, length: 425 > 2014-11-28 04:33:14.645817 rule 13/0(match): pass in on bge0: > 75.55.69.69.6150 > 98.158.139.74.5060: SIP, length: 415 > > Then nothing in the pflog until; > > 2014-11-28 04:38:54.841506 rule 8/0(match): block in on bge0: > 75.55.69.69.5816 > 98.158.139.74.5060: SIP, length: 351 > > That address was added to the AUTOBLOCK table at Nov 28 04:34:00 EST > 2014. Between that time and the time it actually blocked the address > at 2014-11-28 04:38:54 there were over 8000 connections. It looks > like it took almost five minutes before the block started working. > Is this a timeout in pf before it re-reads internal tables? Can I > get around that? Can I at least lower the timeout? > > Cheers. > -- D'Arcy J.M. Cain <[email protected]> http://www.NetBSD.org/ IM:[email protected]
