I am running pf under NetBSD. As far as I know it is pretty much stock OpenBSD pf. I asked this question in the NetBSD mailing list but didn't gat a useful answer. I hope that someone here has a deeper understanding of how pf works. Note the examples here are from November last year but it is still behaving the same today.
Adding to persistent tables doesn't seem to work. At least, it doesn't seem to work all the time. Here is an example from my logs. Note that most addresses detected by my intrusion system get blocked just fine. I am checking my Asterisk logs once a minute to see if there are any hack attempts. Here are the first and last lines in the log for the IP in question. [Nov 21 10:58:56] NOTICE[-1][C-00002a9d] chan_sip.c: Call from '' (62.210.91.28:8507) to extension '000' rejected because extension not found in context 'unauthenticated'. [Nov 21 13:32:41] NOTICE[-1][C-0001b146] chan_sip.c: Call from '' (62.210.91.28:8507) to extension '99999' rejected because extension not found in context 'unauthenticated'. Notice that the attempts keep coming for over 2.5 hours. However, I know that the rule was added very early. Fri Nov 21 10:59:00 EST 2014 > 62.210.91.28 That's a log entry from a changes file. I know that it took because I read the table each time and only perform add and del when there is a difference. This entry was not repeated so pfctl saw the entry. So why would packets continue to come in for 2.5 hours? My guess is that the hacker is keeping the connection open and attacking over it for 2.5 hours. Does the packet filter not apply to existing connections? Is there some way to change that behaviour? Here is a more recent example. 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. 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. Here is another example. 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. That's better than some connections and it may simply be that they stopped. Cheers. -- D'Arcy J.M. Cain System Administrator, Vex.Net http://www.Vex.Net/ IM:da...@vex.net VoIP: sip:da...@vex.net
