At least, it doesn't seem to work all the time. Here is an example
from yesterday. 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 t.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?