On Fri, 27 Feb 2015 11:46:33 +0000 (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
