Re: pf add not working

["D'Arcy J.M. Cain" <darcy%NetBSD.org@localhost>]

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" <darcy%NetBSD.org@localhost> wrote:
> On Sun, 23 Nov 2014 13:22:01 -0500
> "D'Arcy J.M. Cain" <darcy%NetBSD.org@localhost> 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 <darcy%NetBSD.org@localhost>
http://www.NetBSD.org/ IM:darcy%Vex.Net@localhost