On 8/20/2012, "J David" <j.david.li...@gmail.com> 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 <ProtectedIPs> { 10.0.0.0/30 }
>block drop
>pass in proto tcp from any to <ProtectedIPs> 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 <internet-facing-NIC-here> 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-unsubscr...@freebsd.org
_______________________________________________
freebsd-pf@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to "freebsd-pf-unsubscr...@freebsd.org"
