Re: pf add not working
On Fri, 27 Feb 2015 11:46:33 + (UTC) Stuart Henderson s...@spacehopper.org wrote: On 2015-02-26, D'Arcy J.M. Cain da...@vex.net wrote: On Thu, 26 Feb 2015 21:49:15 +0100 Otto Moerbeek o...@drijf.net wrote: What are you looking for specifically? I thought I posted all the relevant rules and outputs. In particular I showed that the problem IP was in the AUTOBLOCK table with pfctl -tAUTOBLOCK -Ts. Well, from what you describe it is likely there is a rule creating state. It could very well be that one of the rules you left out is the culprit. OK, here is everything: http://www.vex.net/~darcy/pf.conf Use pfctl -ss -v to identify the rule number that created state. Use pfctl -sr -R number to display how that rule was added to the kernel. I have done that and I am pretty sure of which rules are being called. This morning I dumped the pf log and extracted info on an attack. I have added pfctl -k $ip to my script when I add an IP to the AUTOBLOCK table that I created. It did block in a timely fashion this morning suggesting that it is keeping state even though I told it not to. Lines trimmed to avoid email wraparound but the rest of the line is minor variations of 192.186.133.60.5071 98.158.139.74.5060: SIP, length: 777 00:00:51.568629 rule 14/0(match): pass in on bge0:... 00:01:38.128375 rule 14/0(match): pass in on bge0:... 00:03:09.457203 rule 14/0(match): pass in on bge0:... 00:00:01.571262 rule 14/0(match): pass in on bge0:... 00:00:09.944745 rule 14/0(match): pass in on bge0:... 00:00:03.561522 rule 14/0(match): pass in on bge0:... 00:00:07.233853 rule 14/0(match): pass in on bge0:... 00:00:09.424476 rule 14/0(match): pass in on bge0:... 00:00:01.180593 rule 14/0(match): pass in on bge0:... 00:02:19.325087 rule 9/0(match): block in on bge0:... Here are the two rules mentioned: @9 block drop in log quick on bge0 from AUTOBLOCK:32 to any @14 pass in log on bge0 proto udp from any to any port = sip no state Past experience suggests that if I had not added pfctl -k $ip that the attack would have continued for a much longer time. Few of us here know what level of PF that NetBSD are using and how it interprets rulesets. There doesn't seem to be a version flag. I couldn't find anything relevant with strings. Additionally: why don't you want to create state? A state check is very much faster than a rule traversal, that's something you probably want on at least the voip media. I didn't want to create state on incoming UDP specifically so that I could block these attacks. Perhaps I don't need that any more since I manually kill the state now but it still seems like the option should work as advertised. Additionally #2: dropping packets often doesn't stop SIP floods. https://jcs.org/notaweblog/2010/04/11/properly_stopping_a_sip_flood/ might be interesting. Not sure that it applies but it's an interesting read anyway. -- D'Arcy J.M. Cain System Administrator, Vex.Net http://www.Vex.Net/ IM:da...@vex.net VoIP: sip:da...@vex.net
Re: pf add not working
On 2015-02-26, D'Arcy J.M. Cain da...@vex.net wrote: On Thu, 26 Feb 2015 21:49:15 +0100 Otto Moerbeek o...@drijf.net wrote: What are you looking for specifically? I thought I posted all the relevant rules and outputs. In particular I showed that the problem IP was in the AUTOBLOCK table with pfctl -tAUTOBLOCK -Ts. Well, from what you describe it is likely there is a rule creating state. It could very well be that one of the rules you left out is the culprit. OK, here is everything: http://www.vex.net/~darcy/pf.conf Use pfctl -ss -v to identify the rule number that created state. Use pfctl -sr -R number to display how that rule was added to the kernel. Few of us here know what level of PF that NetBSD are using and how it interprets rulesets. Additionally: why don't you want to create state? A state check is very much faster than a rule traversal, that's something you probably want on at least the voip media. Additionally #2: dropping packets often doesn't stop SIP floods. https://jcs.org/notaweblog/2010/04/11/properly_stopping_a_sip_flood/ might be interesting.
Re: pf add not working
On Thu, Feb 26, 2015 at 05:02:48PM -0500, Ted Unangst wrote: D'Arcy J.M. Cain wrote: On Thu, 26 Feb 2015 15:22:36 -0500 Ted Unangst t...@tedunangst.com wrote: Well, there's what should happen and what does happen. The behavior described sounds a lot like it's keeping state. You can check with pfctl -ss. all udp 98.158.139.74:5060 - 207.35.13.14:5060 MULTIPLE:MULTIPLE What does MULTIPLE:MULTIPLE mean? multiple packets have passed, in both directions. i.e., you have a state. Add -v and you'll see which rule created that state. -Otto
pf add not working
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-2a9d] 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 '9' 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
Re: pf add not working
D'Arcy J.M. Cain wrote: 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? Yes, that's how stateful firewalls work. Existing states don't evaluate the ruleset. You probably want to look into pfctl -k.
Re: pf add not working
On Thu, Feb 26, 2015 at 12:11:34PM -0500, Ted Unangst wrote: D'Arcy J.M. Cain wrote: 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? Yes, that's how stateful firewalls work. Existing states don't evaluate the ruleset. You probably want to look into pfctl -k. The OP has a no state on the relevant rule. But no full ruleset has been posted, so it's hard to tell what's going on exactly. Looking at the state table with pfctl might help. -Otto
Re: pf add not working
D'Arcy J.M. Cain wrote: On Thu, 26 Feb 2015 12:11:34 -0500 Ted Unangst t...@tedunangst.com wrote: D'Arcy J.M. Cain wrote: 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? Yes, that's how stateful firewalls work. Existing states don't evaluate the ruleset. You probably want to look into pfctl -k. I set no state on all UDP rules which is what this one is. What does -k do? NetBSD's pf doesn't seem to have it. Well, there's what should happen and what does happen. The behavior described sounds a lot like it's keeping state. You can check with pfctl -ss. pfctl -k kills an existing state.
Re: pf add not working
On Thu, 26 Feb 2015 12:11:34 -0500 Ted Unangst t...@tedunangst.com wrote: D'Arcy J.M. Cain wrote: 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? Yes, that's how stateful firewalls work. Existing states don't evaluate the ruleset. You probably want to look into pfctl -k. I set no state on all UDP rules which is what this one is. What does -k do? NetBSD's pf doesn't seem to have it. -- D'Arcy J.M. Cain System Administrator, Vex.Net http://www.Vex.Net/ IM:da...@vex.net VoIP: sip:da...@vex.net
Re: pf add not working
On Thu, 26 Feb 2015 18:25:49 +0100 Otto Moerbeek o...@drijf.net wrote: On Thu, Feb 26, 2015 at 12:11:34PM -0500, Ted Unangst wrote: Yes, that's how stateful firewalls work. Existing states don't evaluate the ruleset. You probably want to look into pfctl -k. The OP has a no state on the relevant rule. But no full ruleset has been posted, so it's hard to tell what's going on exactly. Looking at the state table with pfctl might help. What are you looking for specifically? I thought I posted all the relevant rules and outputs. In particular I showed that the problem IP was in the AUTOBLOCK table with pfctl -tAUTOBLOCK -Ts. -- D'Arcy J.M. Cain System Administrator, Vex.Net http://www.Vex.Net/ IM:da...@vex.net VoIP: sip:da...@vex.net
Re: pf add not working
On Thu, Feb 26, 2015 at 01:53:38PM -0500, D'Arcy J.M. Cain wrote: On Thu, 26 Feb 2015 18:25:49 +0100 Otto Moerbeek o...@drijf.net wrote: On Thu, Feb 26, 2015 at 12:11:34PM -0500, Ted Unangst wrote: Yes, that's how stateful firewalls work. Existing states don't evaluate the ruleset. You probably want to look into pfctl -k. The OP has a no state on the relevant rule. But no full ruleset has been posted, so it's hard to tell what's going on exactly. Looking at the state table with pfctl might help. What are you looking for specifically? I thought I posted all the relevant rules and outputs. In particular I showed that the problem IP was in the AUTOBLOCK table with pfctl -tAUTOBLOCK -Ts. Well, from what you describe it is likely there is a rule creating state. It could very well be that one of the rules you left out is the culprit. But if you do not have pfctl -k you are not running something close to current OpenBSD pf. So I'm afraid you have to diagnose things yourelf, we can give only general directions. -Otto
Re: pf add not working
On Thu, 26 Feb 2015 21:49:15 +0100 Otto Moerbeek o...@drijf.net wrote: What are you looking for specifically? I thought I posted all the relevant rules and outputs. In particular I showed that the problem IP was in the AUTOBLOCK table with pfctl -tAUTOBLOCK -Ts. Well, from what you describe it is likely there is a rule creating state. It could very well be that one of the rules you left out is the culprit. OK, here is everything: http://www.vex.net/~darcy/pf.conf But if you do not have pfctl -k you are not running something close to current OpenBSD pf. So I'm afraid you have to diagnose things yourelf, we can give only general directions. My mistake. I do have that option. Not sure how I missed it before. -- D'Arcy J.M. Cain System Administrator, Vex.Net http://www.Vex.Net/ IM:da...@vex.net VoIP: sip:da...@vex.net
Re: pf add not working
On Thu, 26 Feb 2015 15:22:36 -0500 Ted Unangst t...@tedunangst.com wrote: Well, there's what should happen and what does happen. The behavior described sounds a lot like it's keeping state. You can check with pfctl -ss. all udp 98.158.139.74:5060 - 207.35.13.14:5060 MULTIPLE:MULTIPLE What does MULTIPLE:MULTIPLE mean? pfctl -k kills an existing state. But with my ruleset there shouldn't be any state to kill, right? http://www.vex.net/~darcy/pf.conf -- D'Arcy J.M. Cain System Administrator, Vex.Net http://www.Vex.Net/ IM:da...@vex.net VoIP: sip:da...@vex.net
Re: pf add not working
D'Arcy J.M. Cain wrote: On Thu, 26 Feb 2015 15:22:36 -0500 Ted Unangst t...@tedunangst.com wrote: Well, there's what should happen and what does happen. The behavior described sounds a lot like it's keeping state. You can check with pfctl -ss. all udp 98.158.139.74:5060 - 207.35.13.14:5060 MULTIPLE:MULTIPLE What does MULTIPLE:MULTIPLE mean? multiple packets have passed, in both directions. i.e., you have a state.
Re: pf add not working
pass in log on $ext_if proto udp from any to any port 5060 no state I didn't see anywhere in pf.conf(5) that shows no state as an option.
Re: pf add not working
On Thu, 26 Feb 2015 14:53:28 -0800 Philip Guenther guent...@gmail.com wrote: On Thu, Feb 26, 2015 at 2:40 PM, Edgar Pettijohn ed...@pettijohn-web.com wrote: pass in log on $ext_if proto udp from any to any port 5060 no state I didn't see anywhere in pf.conf(5) that shows no state as an option. Hmm? It's *first* mention is on line 139 of the manpage: pass The packet is passed; state is created unless the no state option is specified. and it can be reached in the syntax via the filteropt non-terminal: filteropt = ... ( no | keep | modulate | synproxy ) state Philip Guenther Yep there she is. I had skipped down to Stateful Filtering and didn't see it. Perhaps under Options the set timeout interval may be useful. -- Edgar Pettijohn ed...@pettijohn-web.com
Re: pf add not working
On Thu, Feb 26, 2015 at 2:40 PM, Edgar Pettijohn ed...@pettijohn-web.com wrote: pass in log on $ext_if proto udp from any to any port 5060 no state I didn't see anywhere in pf.conf(5) that shows no state as an option. Hmm? It's *first* mention is on line 139 of the manpage: pass The packet is passed; state is created unless the no state option is specified. and it can be reached in the syntax via the filteropt non-terminal: filteropt = ... ( no | keep | modulate | synproxy ) state Philip Guenther
Re: pf add not working
On Thu, 26 Feb 2015 17:02:48 -0500 Ted Unangst t...@tedunangst.com wrote: all udp 98.158.139.74:5060 - 207.35.13.14:5060 MULTIPLE:MULTIPLE What does MULTIPLE:MULTIPLE mean? multiple packets have passed, in both directions. i.e., you have a state. And yet; # pfctl -vv -sr | grep sip @14 pass in log on bge0 proto udp from any to any port = sip no state Clearly no state. Is it just ignoring the option? Maybe I have to modify my script. pfctl -t AUTOBLOCK -T add $ip pfctl -k $ip -- D'Arcy J.M. Cain System Administrator, Vex.Net http://www.Vex.Net/ IM:da...@vex.net VoIP: sip:da...@vex.net
Re: pf add not working
On 26 Feb 2015 at 23:16, D'Arcy J.M. Cain wrote: On Thu, 26 Feb 2015 17:02:48 -0500 Ted Unangst t...@tedunangst.com wrote: all udp 98.158.139.74:5060 - 207.35.13.14:5060 MULTIPLE:MULTIPLE What does MULTIPLE:MULTIPLE mean? multiple packets have passed, in both directions. i.e., you have a state. And yet; # pfctl -vv -sr | grep sip @14 pass in log on bge0 proto udp from any to any port = sip no state This particular rule does not have the quick keyword, which means it might not be final -- any subsequent rule that also matches will have execution priority and may introduce state. Clearly no state. Is it just ignoring the option? Maybe I have to modify my script. pfctl -t AUTOBLOCK -T add $ip pfctl -k $ip -- D'Arcy J.M. Cain System Administrator, Vex.Net http://www.Vex.Net/ IM:da...@vex.net VoIP: sip:da...@vex.net
