Sloppy States [WAS: Re: Anyone can't access bsdly.net like I did? (and some other sites)]
nature of PF, which
I'm
I think you might find PF's 'sloppy' states useful if the problem is
only when using more than one upstream.
C.
Hi,
I read man [5] pf.conf, and currently in process of trying PF 'sloppy'
states. I'd really hope it could work. Right know, I tried to put it on
each rule. I'll get back with the result. If anyone had any example of
using sloppy states, I'd love to hear it. This is my filter rules.
pass in quick on {$back_if0 $upstream_if0} inet to keep state
(sloppy source-track global) tag GL_ASYMM_IN
pass in quick on $core_if inet from keep state (sloppy
source-track global) tag GL_ASYMM_OUT
pass out quick on $upstream_if0 inet tagged GL_ASYMM_OUT keep state
(sloppy source-track global)
pass out quick on $core_if inet tagged GL_ASYMM_IN keep state (sloppy
source-track global)
--
insandotpraja(at)gmaildotcom
Re: sloppy states and dsr
> * Ted Unangst <[EMAIL PROTECTED]> [2008-06-20 20:50]: > > One would only use sloppy state tracking on the load balancer, right? > > not necessarily only, but that would be the most common use I bet. > In general, you use it when you cannot avoid it, as in, the other > option is to not filter stateful at all since you don't see all of the > packets for the connection. sloppy state handling use, follow these two rules: rule one: if you exactly understand how to use sloppy state safely, use it NO:otherwise, don't even dream of using it, unless you come from an linux ipfilter world, in which case, it is probably as good as that it is that simple. really. the second basic rule is: if the regular 'strict' state handling does not work for you in specific situations, you probably already already know the problem in enough detail and can use sloppy, for very specific situations which you understand in excruciating detail. if you don't understand those situations exactly go back to NO.
Re: sloppy states and dsr
* Ted Unangst <[EMAIL PROTECTED]> [2008-06-20 20:50]: > One would only use sloppy state tracking on the load balancer, right? not necessarily only, but that would be the most common use I bet. In general, you use it when you cannot avoid it, as in, the other option is to not filter stateful at all since you don't see all of the packets for the connection. > The firewall in front of everything still uses normal tracking? absolutely! -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: sloppy states and dsr
On Sat, Jun 21, 2008 at 09:12:22AM +0900, Ryan McBride wrote: > On Fri, Jun 20, 2008 at 12:49:43PM -0700, Darrin Chandler wrote: > > > Yes, you use sloppy state only on the host(s) seeing half of the trafic. > > > > So to say it even more plainly... anywhere you are forced to deal with > > asymetric routing you can use sloppy state in place of not having any > > stateful option. Would that be a fair statement? > > It's a fair statement if by 'forced' you mean, 'compelled beyond your > control, with no other options, having fully understood the consequences > and informed all relevant parties of the risks involved'. This > "feature" is NOT a substitute for good network design. > > sloppy state performs basically NO security checks on the TCP stream; > more importantly the TCP state tracking is extremely loose and it's > trivial for an attacker to spoof creation of "fully-established" TCP > connections, which will not time out for an extremely long time, filling > your state table and blocking legitimate traffic. It's dangerous. Yes, that is what I meant. Thanks for saying it so much better. :) -- Darrin Chandler| Phoenix BSD User Group | MetaBUG [EMAIL PROTECTED] | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: sloppy states and dsr
On Fri, Jun 20, 2008 at 02:47:18PM -0400, Ted Unangst wrote: | One would only use sloppy state tracking on the load balancer, right? | The firewall in front of everything still uses normal tracking? This is why the router should also be running pf/OpenBSD ;) Cheers, Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Re: sloppy states and dsr
On Fri, Jun 20, 2008 at 12:49:43PM -0700, Darrin Chandler wrote: > > Yes, you use sloppy state only on the host(s) seeing half of the trafic. > > So to say it even more plainly... anywhere you are forced to deal with > asymetric routing you can use sloppy state in place of not having any > stateful option. Would that be a fair statement? It's a fair statement if by 'forced' you mean, 'compelled beyond your control, with no other options, having fully understood the consequences and informed all relevant parties of the risks involved'. This "feature" is NOT a substitute for good network design. sloppy state performs basically NO security checks on the TCP stream; more importantly the TCP state tracking is extremely loose and it's trivial for an attacker to spoof creation of "fully-established" TCP connections, which will not time out for an extremely long time, filling your state table and blocking legitimate traffic. It's dangerous.
Re: sloppy states and dsr
On Fri, Jun 20, 2008 at 08:58:36PM +0200, Pierre-Yves Ritschard wrote: > * Ted Unangst ([EMAIL PROTECTED]) wrote: > > One would only use sloppy state tracking on the load balancer, right? > > The firewall in front of everything still uses normal tracking? > > > > Yes, you use sloppy state only on the host(s) seeing half of the trafic. So to say it even more plainly... anywhere you are forced to deal with asymetric routing you can use sloppy state in place of not having any stateful option. Would that be a fair statement? -- Darrin Chandler| Phoenix BSD User Group | MetaBUG [EMAIL PROTECTED] | http://phxbug.org/ | http://metabug.org/ http://www.stilyagin.com/ | Daemons in the Desert | Global BUG Federation
Re: sloppy states and dsr
* Ted Unangst ([EMAIL PROTECTED]) wrote: > One would only use sloppy state tracking on the load balancer, right? > The firewall in front of everything still uses normal tracking? > Yes, you use sloppy state only on the host(s) seeing half of the trafic.
sloppy states and dsr
One would only use sloppy state tracking on the load balancer, right? The firewall in front of everything still uses normal tracking?
Re: Sloppy states
On Tuesday 10 June 2008 22:42:26 Henning Brauer wrote: [snip] > > I'm looking around and don't quite get sloppy states. Looking at the > > code isn't quite helping. Anything else I can read? > > like, pf.conf(5)? > > sloppy >Uses a sloppy TCP connection tracker that does not check > sequence numbers at all, which makes insertion and ICMP teardown attacks > way easier. This is intended to be used in situations where one does not > see all packets of a connection, e.g. in asymmetric routing situations. > Cannot be used with modulate or synproxy state. > > comes down to "do not use them". > there are some very special circumstances where they make things > possible that didn't work before, like relayd setups with that direct > server return stuff (where you should run another pf box with real > state tracking in front of the relayd box) or cases where you only see > half of the connection, and there one stillhas to be very careful. > > anyone using sloppy statekeeping on regular firewalls deserves more > than a spanking. Crud. I did not look there. Sorry for the noise, but perhaps you've warned some folks and they'll listen. --STeve Andre'
Re: Sloppy states
* STeve Andre' <[EMAIL PROTECTED]> [2008-06-11 04:34]: > On Tuesday 10 June 2008 20:40:02 you wrote: > > * Reyk Floeter <[EMAIL PROTECTED]> [2008-06-11 01:13]: > > > CVSROOT: /cvs > > > Module name: src > > > Changes by: [EMAIL PROTECTED] 2008/06/10 17:12:36 > > > > > > Modified files: > > > usr.sbin/relayd: pfe_filter.c relayd.conf.5 > > > > > > Log message: > > > set the inactivity timeout of redirections to a shorter timeout of 600 > > > seconds by default (pf's default is 86400s), they can be cranked with > > > the "session timeout" directive and it is consistent to relay session > > > timeouts. also remove the hack to modify the closing timeout because > > > pf's sloppy state handling is taking care about half connection > > > closing now. > > > > can you guess how much reyk was prodding me for the sloppy states? :) > > I'm looking around and don't quite get sloppy states. Looking at the code > isn't quite helping. Anything else I can read? like, pf.conf(5)? sloppy Uses a sloppy TCP connection tracker that does not check sequence numbers at all, which makes insertion and ICMP teardown attacks way easier. This is intended to be used in situations where one does not see all packets of a connection, e.g. in asymmetric routing situations. Cannot be used with modulate or synproxy state. comes down to "do not use them". there are some very special circumstances where they make things possible that didn't work before, like relayd setups with that direct server return stuff (where you should run another pf box with real state tracking in front of the relayd box) or cases where you only see half of the connection, and there one stillhas to be very careful. anyone using sloppy statekeeping on regular firewalls deserves more than a spanking. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Sloppy states
* Sam Fourman Jr. <[EMAIL PROTECTED]> [2008-06-11 04:41]: > I also would like some insight on , > 1:) exactly what is sloppy states meant to do > 2:) what are some specific instances where we should use sloppy states that has just been explained. comes down to "don't". > 3:) what is a case where it would be bad to use sloppy states. pretty much any. -- Henning Brauer, [EMAIL PROTECTED], [EMAIL PROTECTED] BS Web Services, http://bsws.de Full-Service ISP - Secure Hosting, Mail and DNS Services Dedicated Servers, Rootservers, Application Hosting - Hamburg & Amsterdam
Re: Sloppy states
> I'm looking around and don't quite get sloppy states. Looking at the code > isn't quite helping. Anything else I can read? > > --STeve Andre' > > I also would like some insight on , 1:) exactly what is sloppy states meant to do 2:) what are some specific instances where we should use sloppy states 3:) what is a case where it would be bad to use sloppy states. Sam Fourman Jr.
Sloppy states
On Tuesday 10 June 2008 20:40:02 you wrote: > * Reyk Floeter <[EMAIL PROTECTED]> [2008-06-11 01:13]: > > CVSROOT:/cvs > > Module name:src > > Changes by: [EMAIL PROTECTED] 2008/06/10 17:12:36 > > > > Modified files: > > usr.sbin/relayd: pfe_filter.c relayd.conf.5 > > > > Log message: > > set the inactivity timeout of redirections to a shorter timeout of 600 > > seconds by default (pf's default is 86400s), they can be cranked with > > the "session timeout" directive and it is consistent to relay session > > timeouts. also remove the hack to modify the closing timeout because > > pf's sloppy state handling is taking care about half connection > > closing now. > > can you guess how much reyk was prodding me for the sloppy states? :) I'm looking around and don't quite get sloppy states. Looking at the code isn't quite helping. Anything else I can read? --STeve Andre'
