From owner-freebsd-pf@FreeBSD.ORG Tue Aug 21 07:49:43 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D2226106564A for ; Tue, 21 Aug 2012 07:49:43 +0000 (UTC) (envelope-from fbsdmail@dnswatch.com) Received: from udns.ultimateDNS.NET (96-26-47-11.war.clearwire-wmx.net [96.26.47.11]) by mx1.freebsd.org (Postfix) with ESMTP id 2917C8FC0C for ; Tue, 21 Aug 2012 07:49:40 +0000 (UTC) Received: from ultimatedns.net (localhost [IPv6:::1]) by udns.ultimateDNS.NET (8.14.5/8.14.5) with SMTP id q7L7Qj29025944; Tue, 21 Aug 2012 00:26:54 -0700 (PDT) (envelope-from fbsdmail@dnswatch.com) Received: from 96.26.47.11 (auth. user chrish@localhost) by ultimatedns.net with HTTP; Tue, 21 Aug 2012 01:26:40 -0600 To: "freebsd-pf" Date: Tue, 21 Aug 2012 01:26:40 -0600 X-Mailer: UDNS Messaging System/0.9.5 (On: ultimatedns.net) Message-ID: In-Reply-To: From: "Chris H" Bounce-To: "Chris H" Errors-To: "Chris H" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Subject: Re: Fighting DDOS attacks with pf X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Aug 2012 07:49:43 -0000 On 8/20/2012, "J David" wrote: >Unfortunately, I think my reference to DDOS attacks has distracted >from the underlying issue. > >PF allows a rule like this: > >pass in proto tcp from any to any port www keep state (max 100, >source-track rule, max-src-states 3) > >(adapted from the man page) > >We want this rule: > >pass in proto tcp from any to any port www keep state (max 100, >dest-track rule, max-dst-states 3) > >Obviously there is no such rule. I'm simply curious whether anyone >has found a way to bend the PF syntax to create the same behavior. > >Perhaps I can offer a couple of examples that will clarify. > >If I do this: > >table { 10.0.0.0/30 } >block drop >pass in proto tcp from any to port 80 keep state ( max 4000 ) > >This will not work for us. If traffic to 10.0.0.2 creates all 4000 >allowed states, packets to *all* of the protected IPs will stop >matching the pass rule and all of the protected IPs are effectively >knocked offline. > >If, however, I do this: > >ProtectedIPs = "{ 10.0.0.0, 10.0.0.1, 10.0.0.2, 10.0.0.3 }" >block drop >pass in proto tcp from any to $ProtectedIPs port 80 keep state ( max 1000 ) > >Then PF will create one rule for each destination IP, and will >therefore limit the number of states on a per-destination-IP basis. >Thus, when traffic to 10.0.0.2 creates 1000 states on its pass rule, >further packets match "block drop" instead, but only for that IP; >traffic for the other three IPs is unaffected. > >That is the effect we want to create. > >This works. The problem we have is that the scale is much larger. >Listing four example IP's in the PF config is not difficult, >hardcoding thousands of destination IPs into the config file >individually would be unwieldy and difficult to maintain, as well as >possibly creating performance problems within pf, as rule processing >goes from O(1) to O(n). > >Since that doesn't seem practical, we use the script I mentioned >earlier that scans the state table and adds targeted IPs to a pf table >to be blocked. This is fine, except it introduces a period of up to a >minute where spillover damage may occur. > >What I am hoping to find is a way of doing this entirely within pf, in >order to cut the response time and to gracefully flow from overflow to >non-overflow conditions. > >There are a couple of ways of doing this. > >One would be to find a couple of really clever rules that would create >the effect we are looking for. This is what I was hoping to find by >asking here. > >The other would be to find some manageable way to generate the >individual rules for each IP -- shouldn't be tough to script if the >pf.conf syntax isn't up to it -- if adding a few thousand "pass" rules >won't crush performance. If anyone has worked with ridiculously large >rulesets of that sort, I would love to hear about their experiences.. > >Thanks! Greetings, I'm coming into this thread a bit late, and while I haven't read the entire thread. I also ran into a few DDOS's and found the antispoof for inet rule to help quite a bit. It made it easier to track down the offending IP(s). So I could contact the RP's to complain. On one occasion, the actual offender was deflecting off a poor guy's IP. The pf && DNS logs I had provided the information he needed to get the actual offender. Not sure if this will help you in your case, but felt if worth a mention. Best wishes. >_______________________________________________ >freebsd-pf@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-pf >To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org