Re: pf to block against DDoS?

2008-09-22 Thread Lars Noodén
Redd Vinylene wrote:
 ...
 You can also use two tables so that the first overload gets shunted to a
 slow queue and given a second chance before ending up in the second
 table which gets blocked.
 ...
 Lars Noodin: Would you happen to have an example of that?

Not really, here is an illustration of how it might be approached:

 http://www-personal.umich.edu/~lars/PF/pf.ssh-2tables.conf

I expect that the last-rule-matched takes care of the decision.  The
However, there might be some divergence between what I think it does and
what it really does.

Another question is, in which cases is that useful?

Regards
-Lars



Re: pf to block against DDoS?

2008-09-22 Thread Redd Vinylene
On Mon, Sep 22, 2008 at 10:36 AM, Lars Noodin
[EMAIL PROTECTED]wrote:

 Redd Vinylene wrote:
  ...
  You can also use two tables so that the first overload gets shunted to a
  slow queue and given a second chance before ending up in the second
  table which gets blocked.
  ...
  Lars Noodin: Would you happen to have an example of that?

 Not really, here is an illustration of how it might be approached:


http://www-personal.umich.edu/~lars/PF/pf.ssh-2tables.confhttp://www-persona
l.umich.edu/%7Elars/PF/pf.ssh-2tables.conf

 I expect that the last-rule-matched takes care of the decision.  The
 However, there might be some divergence between what I think it does and
 what it really does.

 Another question is, in which cases is that useful?

 Regards
 -Lars


This has been a very interesting example, Lars. Thanks a lot for sharing!

As for your last question though, I think I know what you mean. It is to
say, should a rapist really be given a second chance?

--
http://www.home.no/reddvinylene



Re: pf to block against DDoS?

2008-09-22 Thread Lars Noodén
Redd Vinylene wrote:
 ... a second chance?

Well ssh on port 22 does occasionally have legitmate uses and even
occasionally legitimate users.  So some kind of indicator (such as a
slowdown) could be useful for them.

-Lars



Re: pf to block against DDoS?

2008-09-21 Thread Redd Vinylene
From: Redd Vinylene [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: pf to block against DDoS?
Date: Thursday, September 4, 2008 - 3:23 pm
   
Hello hello!
   
I was quite shocked today when I heard I could use pf to block
against DDoS
attacks, using Stateful Tracking Options,
http://www.openbsd.org/faq/pf/filter.html#stateopts.
   
But does anybody have any nice setups of this they'd want to share?
   
  
   From: Oliver Peter [EMAIL PROTECTED]
   To: Redd Vinylene [EMAIL PROTECTED]
   Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
   Subject: Re: pf to block against DDoS?
   Date: Thursday, September 4, 2008 - 4:20 pm
  
   ... nice cross-post.
  
   I can recommend reading through this as well:
 http://www.bgnett.no/~peter/pf/en/bruteforce.html
  
   --
   Oliver PETER, email: [EMAIL PROTECTED], ICQ# 113969174
   If it feels good, you're doing something wrong.
 -- Coach McTavish
  
 
  From: Peter N. M. Hansteen [EMAIL PROTECTED]
  To: Oliver Peter [EMAIL PROTECTED]
  Cc: Redd Vinylene [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL 
  PROTECTED]
  Subject: Re: pf to block against DDoS?
  Date: Friday, September 5, 2008 - 1:54 am
 
  Thanks for recommending that!  However I would generally recommend the
  maintained version which is up at lt;http://home.nuug.no/~peter/pf/gt
;,
  with the direct link to the part about state tracking and bruteforcers
  at lt;http://home.nuug.no/~peter/pf/en/bruteforce.htmlgt;.
 
  (and of course there's the book, nudge, nudge)
 
  - P
  --
  Peter N. M. Hansteen, member of the first RFC 1149 implementation team
  http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
  Remember to set the evil bit on all malicious network traffic
 
 From: Lars Noodin [EMAIL PROTECTED]
 To: Oliver Peter [EMAIL PROTECTED]
 Cc: Redd Vinylene [EMAIL PROTECTED], [EMAIL PROTECTED]
 Subject: Re: pf to block against DDoS?
 Date: Thursday, September 4, 2008 - 4:50 pm

 You can also use two tables so that the first overload gets shunted to a
 slow queue and given a second chance before ending up in the second
 table which gets blocked.

 -Lars

Much obliged to all y'all gentlemen for your valuable design insight.

Now, is there anything more I can do to secure my webserver from attacks? Or
perhaps my pf.conf can be simplified / beautified?

Peter N. M. Hansteen: Did I follow your tutorial correctly?

Lars Noodin: Would you happen to have an example of that?

My pf.conf now looks like this:

-

ext_if = rl0

int_if = ep0

set block-policy return

set skip on { lo0 }

scrub in

table bruteforce persist

nat on $ext_if from $int_if:network to any - ($ext_if)

rdr on $ext_if proto tcp from any to any port 3 - 192.168.187.2 port
3

pass out keep state

pass quick on $int_if

block in

block quick from bruteforce

pass in on $ext_if inet proto tcp from any to any port { 20, 21, 25, 53,
113, 3:35000 } keep state (max-src-conn 100, max-src-conn-rate 15/5,
overload bruteforce flush global)

pass in on $ext_if inet proto tcp from any to any port 22 keep state
(max-src-conn 15, max-src-conn-rate 5/3, overload bruteforce flush global)

pass in on $ext_if inet proto udp from any to any port 53 keep state

pass in on $ext_if inet proto icmp from any to any keep state

-

Have a great week! Cheers!

--
http://www.home.no/reddvinylene



Re: pf to block against DDoS?

2008-09-21 Thread Redd Vinylene
From: Redd Vinylene [EMAIL PROTECTED]
To: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: pf to block against DDoS?
Date: Thursday, September 4, 2008 - 3:23 pm
   
Hello hello!
   
I was quite shocked today when I heard I could use pf to block
against DDoS
attacks, using Stateful Tracking Options,
http://www.openbsd.org/faq/pf/filter.html#stateopts.
   
But does anybody have any nice setups of this they'd want to share?
   
  
   From: Oliver Peter [EMAIL PROTECTED]
   To: Redd Vinylene [EMAIL PROTECTED]
   Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
   Subject: Re: pf to block against DDoS?
   Date: Thursday, September 4, 2008 - 4:20 pm
  
   ... nice cross-post.
  
   I can recommend reading through this as well:
 http://www.bgnett.no/~peter/pf/en/bruteforce.html
  
   --
   Oliver PETER, email: [EMAIL PROTECTED], ICQ# 113969174
   If it feels good, you're doing something wrong.
 -- Coach McTavish
  
 
  From: Peter N. M. Hansteen [EMAIL PROTECTED]
  To: Oliver Peter [EMAIL PROTECTED]
  Cc: Redd Vinylene [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL 
  PROTECTED]
  Subject: Re: pf to block against DDoS?
  Date: Friday, September 5, 2008 - 1:54 am
 
  Thanks for recommending that!  However I would generally recommend the
  maintained version which is up at lt;http://home.nuug.no/~peter/pf/gt
;,
  with the direct link to the part about state tracking and bruteforcers
  at lt;http://home.nuug.no/~peter/pf/en/bruteforce.htmlgt;.
 
  (and of course there's the book, nudge, nudge)
 
  - P
  --
  Peter N. M. Hansteen, member of the first RFC 1149 implementation team
  http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
  Remember to set the evil bit on all malicious network traffic
 
 From: Lars Noodin [EMAIL PROTECTED]
 To: Oliver Peter [EMAIL PROTECTED]
 Cc: Redd Vinylene [EMAIL PROTECTED], [EMAIL PROTECTED]
 Subject: Re: pf to block against DDoS?
 Date: Thursday, September 4, 2008 - 4:50 pm

 You can also use two tables so that the first overload gets shunted to a
 slow queue and given a second chance before ending up in the second
 table which gets blocked.

 -Lars

Sorry, _this_ is my webserver's pf.conf (the other one was my home
firewall's):

-

mad = 80.202.2.3

doom = { 80.202.2.4 - 80.202.2.127 }

ext_if = rl0

set block-policy return

set skip on { lo0 }

scrub in

table bruteforce persist

pass out keep state

block in

block quick from bruteforce

pass in on $ext_if inet proto tcp from any to any port 22 keep state
(max-src-conn 15, max-src-conn-rate 5/3, overload bruteforce flush global)

pass in on $ext_if inet proto tcp from any to $mad port { 25, 53, 80, 110 }
keep state (max-src-conn 100, max-src-conn-rate 15/5, overload bruteforce
flush global)

pass in on $ext_if inet proto udp from any to $mad port 53 keep state

pass in on $ext_if inet proto tcp from any to $doom port { 20, 21, 113,
6000: } keep state (max-src-conn 100, max-src-conn-rate 15/5, overload
bruteforce flush global)

pass in on $ext_if inet proto icmp from any to any keep state

-

I hope the design adheres to: http://en.wikipedia.org/wiki/KISS_principle

--
http://www.home.no/reddvinylene



Re: pf to block against DDoS?

2008-09-05 Thread Peter N. M. Hansteen
Oliver Peter [EMAIL PROTECTED] writes:

 I can recommend reading through this as well:
   http://www.bgnett.no/~peter/pf/en/bruteforce.html

Thanks for recommending that!  However I would generally recommend the
maintained version which is up at http://home.nuug.no/~peter/pf/,
with the direct link to the part about state tracking and bruteforcers
at http://home.nuug.no/~peter/pf/en/bruteforce.html.

(and of course there's the book, nudge, nudge)

- P
-- 
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
Remember to set the evil bit on all malicious network traffic
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.



Re: pf to block against DDoS?

2008-09-04 Thread Oliver Peter
On Thu, Sep 04, 2008 at 09:23:09PM +0200, Redd Vinylene wrote:
 Hello hello!
 
 I was quite shocked today when I heard I could use pf to block against DDoS
 attacks, using Stateful Tracking Options,
 http://www.openbsd.org/faq/pf/filter.html#stateopts.
 
 But does anybody have any nice setups of this they'd want to share?
 
 Much obliged, and thanks.

... nice cross-post.

I can recommend reading through this as well:
  http://www.bgnett.no/~peter/pf/en/bruteforce.html

-- 
Oliver PETER, email: [EMAIL PROTECTED], ICQ# 113969174
If it feels good, you're doing something wrong.
  -- Coach McTavish



Re: pf to block against DDoS?

2008-09-04 Thread Subhro
What exactly are you looking for? Are you looking for example rulesets?

Thanks
Subhro



On 9/5/08, Redd Vinylene [EMAIL PROTECTED] wrote:
 Hello hello!

 I was quite shocked today when I heard I could use pf to block against DDoS
 attacks, using Stateful Tracking Options,
 http://www.openbsd.org/faq/pf/filter.html#stateopts.

 But does anybody have any nice setups of this they'd want to share?

 Much obliged, and thanks.

 --
 http://www.home.no/reddvinylene
 ___
 [EMAIL PROTECTED] mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-questions
 To unsubscribe, send any mail to [EMAIL PROTECTED]


-- 
Sent from Gmail for mobile | mobile.google.com

Subhro Kar
Software Engineer
Dynamic Digital Technologies Pvt. Ltd.
EPY-3, Sector: V
Salt Lake City
700091
India



Re: pf to block against DDoS?

2008-09-04 Thread Lars Noodén
Oliver Peter wrote:
 I can recommend reading through this as well:
   http://www.bgnett.no/~peter/pf/en/bruteforce.html

You can also use two tables so that the first overload gets shunted to a
slow queue and given a second chance before ending up in the second
table which gets blocked.

-Lars



Re: pf to block against DDoS?

2008-09-04 Thread johan beisser

On Sep 4, 2008, at 12:23 PM, Redd Vinylene wrote:
I was quite shocked today when I heard I could use pf to block  
against DDoS

attacks, using Stateful Tracking Options,
http://www.openbsd.org/faq/pf/filter.html#stateopts.

But does anybody have any nice setups of this they'd want to share?


I'd not describe that as an anti-DDoS capability. It's hard to simply  
write a direct pf.conf that'll handle most attacks like this.


On the other hand, bruteforce DDoS attacks are pretty easy to find and  
block, once you know what you're looking for. For example, too many  
requests to a specific port might be a bruteforce attack, so tagging  
that stream and assigning it to a specific low priority queue (or just  
outright blocking) may work well (basically via overload rulesets in  
pf.conf and altq).


But, most DDoS attacks aren't layer 7 (application), they're generally  
layer 3 (network), and use ICMP, UDP, or TCP, and due to how delivery  
of the packets will happen it can still saturate your line.


Of course, you can synproxy at the firewall for inbound TCP packets,  
and hopefully preserve performance for the application behind it, and  
simply permit the session to establish AFTER the handshake completed.


My likely assumption is that the same host hitting ports 80 and 443  
too rapidly with too many requests may be an attacker, but it might be  
a browser that's just configured to connect with multiple requests at  
the same time (custom network.http.pipelining.maxrequests in Firefox,  
for example). So outright blocking the IP could alienate some clients.  
It would be better to assign to a low BW or low priority queue via  
altq for a given table.


I've really put too much thought in to this.

-jb