Re: kern.maxclusters vs syn proxy
Great! 04.10.2012 16:52 ÐÏÌØÚÏ×ÁÔÅÌØ Henning Brauer lists-open...@bsws.de ÎÁÐÉÓÁÌ: * Tyler Morgan tyl...@tradetech.net [2012-10-02 18:31]: which links to: http://www.openbsd.org/faq/pf/filter.html#synproxy which gets far from saying what Henning said. this has been fixed. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: kern.maxclusters vs syn proxy
* Tyler Morgan tyl...@tradetech.net [2012-10-02 18:31]: which links to: http://www.openbsd.org/faq/pf/filter.html#synproxy which gets far from saying what Henning said. this has been fixed. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: kern.maxclusters vs syn proxy
* Илья Шипицин chipits...@gmail.com [2012-08-23 08:44]: 2012/8/23 Claudio Jeker cje...@diehard.n-r-g.com On Thu, Aug 23, 2012 at 12:17:04AM +0600, ??? wrote: why syn proxy is not enabled by default ? Because it has bad side-effects. Like accepting a connection before the actual server accepted it. So it is hard to signal closed ports back. any other side-effect ? claudio stated this way too nice. let me be super clear here: if you are running synproxy permamnently, you are an idiot. why is synproxy there? if you are under a synflood-style attack and need to protect a backend server, it can save your a**. running synproxy to protect an OpenBSD machine, more so the local host, is retarded and counterproductive. think through how synproxy works. it accepts a connection on behalf of the destination server. once the 3whs is complete, it tries to open a connection to the backend. now if the backend doesn't take that connection, the pf synproxy box can only drop the already established connection. the semantics of establishing and dropping a connection vs ot taking it from the beginning DO have different semantics. for example, if you use round-robin dns, the client will NOT move on to the next IP address if the connection had been accepted and dropped later. moreover, you are drawing deliberate decisions by the actual daemon, like the listen backlog, close to pointless. it gets worse when some form of loadbalancing is in the picture. synproxy is there because it ca save your a** WHEN YOU ARE UNDER ATTACK. it is not suitable for all-time all-case use, and can't be. it once again comes down to think before pushing random buttons. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: kern.maxclusters vs syn proxy
but is this clear for newbies who read all the faqs? On Tue, Oct 02, 2012 at 01:17:03PM +0200, Henning Brauer wrote: * ?? chipits...@gmail.com [2012-08-23 08:44]: 2012/8/23 Claudio Jeker cje...@diehard.n-r-g.com On Thu, Aug 23, 2012 at 12:17:04AM +0600, ??? wrote: why syn proxy is not enabled by default ? Because it has bad side-effects. Like accepting a connection before the actual server accepted it. So it is hard to signal closed ports back. any other side-effect ? claudio stated this way too nice. let me be super clear here: if you are running synproxy permamnently, you are an idiot. why is synproxy there? if you are under a synflood-style attack and need to protect a backend server, it can save your a**. running synproxy to protect an OpenBSD machine, more so the local host, is retarded and counterproductive. think through how synproxy works. it accepts a connection on behalf of the destination server. once the 3whs is complete, it tries to open a connection to the backend. now if the backend doesn't take that connection, the pf synproxy box can only drop the already established connection. the semantics of establishing and dropping a connection vs ot taking it from the beginning DO have different semantics. for example, if you use round-robin dns, the client will NOT move on to the next IP address if the connection had been accepted and dropped later. moreover, you are drawing deliberate decisions by the actual daemon, like the listen backlog, close to pointless. it gets worse when some form of loadbalancing is in the picture. synproxy is there because it ca save your a** WHEN YOU ARE UNDER ATTACK. it is not suitable for all-time all-case use, and can't be. it once again comes down to think before pushing random buttons. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: kern.maxclusters vs syn proxy
On Tue, Oct 02, 2012 at 09:50:36PM +1000, David Diggles wrote: but is this clear for newbies who read all the faqs? Well, it's not default. And almost often that is a sign the option is not desirable for a typical setup.OB -0tto On Tue, Oct 02, 2012 at 01:17:03PM +0200, Henning Brauer wrote: * ?? chipits...@gmail.com [2012-08-23 08:44]: 2012/8/23 Claudio Jeker cje...@diehard.n-r-g.com On Thu, Aug 23, 2012 at 12:17:04AM +0600, ??? wrote: why syn proxy is not enabled by default ? Because it has bad side-effects. Like accepting a connection before the actual server accepted it. So it is hard to signal closed ports back. any other side-effect ? claudio stated this way too nice. let me be super clear here: if you are running synproxy permamnently, you are an idiot. why is synproxy there? if you are under a synflood-style attack and need to protect a backend server, it can save your a**. running synproxy to protect an OpenBSD machine, more so the local host, is retarded and counterproductive. think through how synproxy works. it accepts a connection on behalf of the destination server. once the 3whs is complete, it tries to open a connection to the backend. now if the backend doesn't take that connection, the pf synproxy box can only drop the already established connection. the semantics of establishing and dropping a connection vs ot taking it from the beginning DO have different semantics. for example, if you use round-robin dns, the client will NOT move on to the next IP address if the connection had been accepted and dropped later. moreover, you are drawing deliberate decisions by the actual daemon, like the listen backlog, close to pointless. it gets worse when some form of loadbalancing is in the picture. synproxy is there because it ca save your a** WHEN YOU ARE UNDER ATTACK. it is not suitable for all-time all-case use, and can't be. it once again comes down to think before pushing random buttons. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: kern.maxclusters vs syn proxy
* David Diggles da...@elven.com.au [2012-10-02 13:51]: but is this clear for newbies who read all the faqs? On Tue, Oct 02, 2012 at 01:17:03PM +0200, Henning Brauer wrote: it once again comes down to think before pushing random buttons. this basic principle SHOULD not need documentation :) quite seriously, this goes deep into the workings of tcp. OpenBSD documentation cannot and does not document the details of the implemented protocols. There are entire books about tcp. Read them to understand tcp, and read the OpenBSD documentation for the OpenBSD specific bits. There isn't much we can do to prevent people from pushing buttons they don't understand but not providing them - which is what we do where possible. But by not providing synproxy we'd steal an important tool for fighting attacks from those who understand what they're doing. We're not saving you from stabbing your eye with the spoon left in your coffee mug either. We can't. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: kern.maxclusters vs syn proxy
I think when a lot of newbies read the pf manual, they think oh... synproxy looks like it does good things, and without really understanding it, enable it by default? On Tue, Oct 02, 2012 at 02:33:11PM +0200, Henning Brauer wrote: * David Diggles da...@elven.com.au [2012-10-02 13:51]: but is this clear for newbies who read all the faqs? On Tue, Oct 02, 2012 at 01:17:03PM +0200, Henning Brauer wrote: it once again comes down to think before pushing random buttons. this basic principle SHOULD not need documentation :) quite seriously, this goes deep into the workings of tcp. OpenBSD documentation cannot and does not document the details of the implemented protocols. There are entire books about tcp. Read them to understand tcp, and read the OpenBSD documentation for the OpenBSD specific bits. There isn't much we can do to prevent people from pushing buttons they don't understand but not providing them - which is what we do where possible. But by not providing synproxy we'd steal an important tool for fighting attacks from those who understand what they're doing. We're not saving you from stabbing your eye with the spoon left in your coffee mug either. We can't. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/
Re: kern.maxclusters vs syn proxy
I would vote no based on: http://www.openbsd.org/faq/pf/example1.html For an added bit of safety, we'll make use of the TCP SYN Proxy to further protect the web server. which links to: http://www.openbsd.org/faq/pf/filter.html#synproxy which gets far from saying what Henning said. On 10/2/2012 6:30 AM, David Diggles wrote: I think when a lot of newbies read the pf manual, they think oh... synproxy looks like it does good things, and without really understanding it, enable it by default? On Tue, Oct 02, 2012 at 02:33:11PM +0200, Henning Brauer wrote: * David Diggles da...@elven.com.au [2012-10-02 13:51]: but is this clear for newbies who read all the faqs? On Tue, Oct 02, 2012 at 01:17:03PM +0200, Henning Brauer wrote: it once again comes down to think before pushing random buttons. this basic principle SHOULD not need documentation :) quite seriously, this goes deep into the workings of tcp. OpenBSD documentation cannot and does not document the details of the implemented protocols. There are entire books about tcp. Read them to understand tcp, and read the OpenBSD documentation for the OpenBSD specific bits. There isn't much we can do to prevent people from pushing buttons they don't understand but not providing them - which is what we do where possible. But by not providing synproxy we'd steal an important tool for fighting attacks from those who understand what they're doing. We're not saving you from stabbing your eye with the spoon left in your coffee mug either. We can't. -- Henning Brauer, h...@bsws.de, henn...@openbsd.org BS Web Services, http://bsws.de, Full-Service ISP Secure Hosting, Mail and DNS Services. Dedicated Servers, Root to Fully Managed Henning Brauer Consulting, http://henningbrauer.com/ -- Tyler Morgan Systems Administrator Trade Tech Inc. tyl...@tradetech.net office: 425-837-9000 (ext. 1022) cell/sms: 206-310-8340 fax: 425-837-9008
Re: kern.maxclusters vs syn proxy
On Tue, Oct 02, 2012 at 09:30, Tyler Morgan wrote: I would vote no based on: http://www.openbsd.org/faq/pf/example1.html For an added bit of safety, we'll make use of the TCP SYN Proxy to further protect the web server. which links to: http://www.openbsd.org/faq/pf/filter.html#synproxy which gets far from saying what Henning said. Congratulations, you just found a way to make the documentation better. :)
Re: kern.maxclusters vs syn proxy
2012/8/23 Claudio Jeker cje...@diehard.n-r-g.com On Thu, Aug 23, 2012 at 12:17:04AM +0600, ??? wrote: Hello! we are running high load https server on OpenBSD, so there are questions on performance: since we already had to increase kern.maxclusters value, I guess default OpenBSD settings are not very well for high load https server ? in order to protect our server from denial of service, we can either a) increase kern.maxclusters to some huge value It is OK to increase kern.maxclusters, the default is good enough for 90% of the people but some systems need more. Calculate how much memory will be consumed by the clusters and compare it to the free memory reported by top. You don't want to run userland out of memory by buffering in the kernel. On the other hand you want enough maxclusters to make the system run smoothly. so, there's no harm in huge kern.maxcluster values ? (until I keep enough memory for userland) b) turn on syn proxy in PF Syn proxy will only protect you from syn attacks. For this there is also the syn cache used by the network stack. The syn cache will only allocate a full PCB when the handshake completed so it behaves similar to the syn proxy in PF. is syn cache enabled by default ? am I right that syn cache does almost the same as syn proxy ? does someone have experience with such high load applications and tell me pro et contra for each solution? why syn proxy is not enabled by default ? Because it has bad side-effects. Like accepting a connection before the actual server accepted it. So it is hard to signal closed ports back. any other side-effect ? -- :wq Claudio
kern.maxclusters vs syn proxy
Hello! we are running high load https server on OpenBSD, so there are questions on performance: since we already had to increase kern.maxclusters value, I guess default OpenBSD settings are not very well for high load https server ? in order to protect our server from denial of service, we can either a) increase kern.maxclusters to some huge value b) turn on syn proxy in PF does someone have experience with such high load applications and tell me pro et contra for each solution? why syn proxy is not enabled by default ? Ilya Shipitsin
Re: kern.maxclusters vs syn proxy
Can you describe 'high load' ? On Thu, Aug 23, 2012 at 12:17:04AM +0600, Илья Шипицин wrote: ; Hello! ; ; ; we are running high load https server on OpenBSD, so there are questions on ; performance: ; ; since we already had to increase kern.maxclusters value, I guess default ; OpenBSD settings are not very well for high load https server ? ; in order to protect our server from denial of service, we can either ; ; a) increase kern.maxclusters to some huge value ; b) turn on syn proxy in PF ; ; does someone have experience with such high load applications and tell me ; pro et contra for each solution? ; why syn proxy is not enabled by default ? ; ; Ilya Shipitsin ; -- Sending from my VCR...
Re: kern.maxclusters vs syn proxy
On Thu, Aug 23, 2012 at 12:17:04AM +0600, ??? wrote: Hello! we are running high load https server on OpenBSD, so there are questions on performance: since we already had to increase kern.maxclusters value, I guess default OpenBSD settings are not very well for high load https server ? in order to protect our server from denial of service, we can either a) increase kern.maxclusters to some huge value It is OK to increase kern.maxclusters, the default is good enough for 90% of the people but some systems need more. Calculate how much memory will be consumed by the clusters and compare it to the free memory reported by top. You don't want to run userland out of memory by buffering in the kernel. On the other hand you want enough maxclusters to make the system run smoothly. b) turn on syn proxy in PF Syn proxy will only protect you from syn attacks. For this there is also the syn cache used by the network stack. The syn cache will only allocate a full PCB when the handshake completed so it behaves similar to the syn proxy in PF. does someone have experience with such high load applications and tell me pro et contra for each solution? why syn proxy is not enabled by default ? Because it has bad side-effects. Like accepting a connection before the actual server accepted it. So it is hard to signal closed ports back. -- :wq Claudio
