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? -- D'Arcy J.M. Cain <[email protected]> http://www.NetBSD.org/ IM:[email protected]
