[Touch-packages] [Bug 57091] Re: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense...
FWIW Although syncookies has long-since been enabled upstream, the outdated comments in sysctl about syncookies still persist, I have now created new ubuntu bug #1773157 [please comment there]. [This also requests ECN-on-outgoing enablement which has similarly matured etc.]. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/57091 Title: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense... Status in procps package in Ubuntu: Fix Released Bug description: This is intended to be a 'wishlist' wulnerability -- w.r.t. procps and Edgy. In my opinion,the /etc/sysctl.conf should have 'proc/sys/net/ipv4/tcp_syncookies=1' in order to permit the linux SYNcookies syn-flood trivial DoS attack to be mitigated as-necessary, by default. Note that the disadvantages of connections initiated w/ SYNcookies enabled only apply when the system is under attack (SYN queue getting rather full), as the syncookies reply-with-only-one-SYN+ACK behaviour only 'kicks in' when the system has a SYN_RECVD backlog problem. (If SYNcookies were not permitted incoming TCP connections have a very low chance of succeeding at all while under SYN-flood attack). Without this setting enabled, any TCP services on the machine can be DoSed from a dial-up line sending a stream of SYN packets from weird source addresses to open TCP ports like Samba/VNC/http/whatever Does anybody have any legitimate reason tcp_syncookies should be disabled? Some people claimed that SYNcookies break some RFCs once but I have not seen any evidence to this effect, only notes from djb saying that this is not true. Comments wanted please ;-) Thankyou in advance, -- enyc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/57091/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 57091] Re: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense...
I filed a request for ufw not to override https://bugs.launchpad.net/ubuntu/+source/ufw/+bug/1737585 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/57091 Title: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense... Status in procps package in Ubuntu: Fix Released Bug description: This is intended to be a 'wishlist' wulnerability -- w.r.t. procps and Edgy. In my opinion,the /etc/sysctl.conf should have 'proc/sys/net/ipv4/tcp_syncookies=1' in order to permit the linux SYNcookies syn-flood trivial DoS attack to be mitigated as-necessary, by default. Note that the disadvantages of connections initiated w/ SYNcookies enabled only apply when the system is under attack (SYN queue getting rather full), as the syncookies reply-with-only-one-SYN+ACK behaviour only 'kicks in' when the system has a SYN_RECVD backlog problem. (If SYNcookies were not permitted incoming TCP connections have a very low chance of succeeding at all while under SYN-flood attack). Without this setting enabled, any TCP services on the machine can be DoSed from a dial-up line sending a stream of SYN packets from weird source addresses to open TCP ports like Samba/VNC/http/whatever Does anybody have any legitimate reason tcp_syncookies should be disabled? Some people claimed that SYNcookies break some RFCs once but I have not seen any evidence to this effect, only notes from djb saying that this is not true. Comments wanted please ;-) Thankyou in advance, -- enyc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/57091/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 57091] Re: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense...
Will do, Simon. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/57091 Title: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense... Status in procps package in Ubuntu: Fix Released Bug description: This is intended to be a 'wishlist' wulnerability -- w.r.t. procps and Edgy. In my opinion,the /etc/sysctl.conf should have 'proc/sys/net/ipv4/tcp_syncookies=1' in order to permit the linux SYNcookies syn-flood trivial DoS attack to be mitigated as-necessary, by default. Note that the disadvantages of connections initiated w/ SYNcookies enabled only apply when the system is under attack (SYN queue getting rather full), as the syncookies reply-with-only-one-SYN+ACK behaviour only 'kicks in' when the system has a SYN_RECVD backlog problem. (If SYNcookies were not permitted incoming TCP connections have a very low chance of succeeding at all while under SYN-flood attack). Without this setting enabled, any TCP services on the machine can be DoSed from a dial-up line sending a stream of SYN packets from weird source addresses to open TCP ports like Samba/VNC/http/whatever Does anybody have any legitimate reason tcp_syncookies should be disabled? Some people claimed that SYNcookies break some RFCs once but I have not seen any evidence to this effect, only notes from djb saying that this is not true. Comments wanted please ;-) Thankyou in advance, -- enyc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/57091/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
Re: [Touch-packages] [Bug 57091] Re: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 > Bog standard 16.04 has it turned on (from the above referenced 10 > -network-security.conf). > But, if you then enabled ufw, it gets disabled, due to the default > setting in /etc/ufw/sysctl.conf. > There seems to be serious debate as to whether or not enabling it is > correct. I haven't seen why not to enable use of adaptive syncookies, aiui this creates no _disadvantage_ if not being triggered... I CAN understand that for some scenarios the 'right thing to do' is Increase the tcp_max_syn_backlog as cookies are triggering too easily, even then it won't stop connections being accepted albeit with less tcp options possible, but then without syncookies the connections would be dropped as the syn queue fills... > What I know is that I just spent two hours trying to figure out why SANE > took forever to detect my network scanner, and this syslog entry clued > me in: > Oct 6 22:54:26 hiro kernel: [48562.817258] TCP: request_sock_TCP: > Possible SYN flooding on port 34029. Dropping request. Check SNMP > The dropped request was responsible for the delay. If I enable syn > cookies, I get: > Oct 6 22:57:28 hiro kernel: [48744.796029] TCP: request_sock_TCP: > Possible SYN flooding on port 42041. Sending cookies. Check SNMP > capture it, there's ONE SYN request and the kernel thinks it's a > "flood".. which makes no sense. Weird :). I can't say I'm familiar with uwf, but I wonder if it is somehow oversensitive in its' own ip(6)tables or they are fiddling with:- /proc/sys/net/ipv4/tcp_max_syn_backlog Do raise bug in the ufw // ufw sysctl.conf Also email me separately the relevant bug numbers etc., be curious to see!! - --Simon -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Topal (http://freshmeat.net/projects/topal) iF4EAREIAAYFAlf3SqEACgkQA62i3HuJ2aHNCwEAnK4NvLNm/tKHzFNSEK+KRNMB 6hZOZ6tcnbecljP1+dAA/3C0bmEHFXEzeLF3xYNSco+py2TbD2bNPzXbG0NKsupb =Fh0+ -END PGP SIGNATURE- -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/57091 Title: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense... Status in procps package in Ubuntu: Fix Released Bug description: This is intended to be a 'wishlist' wulnerability -- w.r.t. procps and Edgy. In my opinion,the /etc/sysctl.conf should have 'proc/sys/net/ipv4/tcp_syncookies=1' in order to permit the linux SYNcookies syn-flood trivial DoS attack to be mitigated as-necessary, by default. Note that the disadvantages of connections initiated w/ SYNcookies enabled only apply when the system is under attack (SYN queue getting rather full), as the syncookies reply-with-only-one-SYN+ACK behaviour only 'kicks in' when the system has a SYN_RECVD backlog problem. (If SYNcookies were not permitted incoming TCP connections have a very low chance of succeeding at all while under SYN-flood attack). Without this setting enabled, any TCP services on the machine can be DoSed from a dial-up line sending a stream of SYN packets from weird source addresses to open TCP ports like Samba/VNC/http/whatever Does anybody have any legitimate reason tcp_syncookies should be disabled? Some people claimed that SYNcookies break some RFCs once but I have not seen any evidence to this effect, only notes from djb saying that this is not true. Comments wanted please ;-) Thankyou in advance, -- enyc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/57091/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 57091] Re: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense...
Well, and it gets more interesting. Bog standard 16.04 has it turned on (from the above referenced 10 -network-security.conf). But, if you then enabled ufw, it gets disabled, due to the default setting in /etc/ufw/sysctl.conf. There seems to be serious debate as to whether or not enabling it is correct. What I know is that I just spent two hours trying to figure out why SANE took forever to detect my network scanner, and this syslog entry clued me in: Oct 6 22:54:26 hiro kernel: [48562.817258] TCP: request_sock_TCP: Possible SYN flooding on port 34029. Dropping request. Check SNMP counters. The dropped request was responsible for the delay. If I enable syn cookies, I get: Oct 6 22:57:28 hiro kernel: [48744.796029] TCP: request_sock_TCP: Possible SYN flooding on port 42041. Sending cookies. Check SNMP counters. and it's basically instant. On top of all of this, there isn't a lot of traffic - this is SANE talking to a vendor-provided scanner backend over localhost. If I capture it, there's ONE SYN request and the kernel thinks it's a "flood".. which makes no sense. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/57091 Title: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense... Status in procps package in Ubuntu: Fix Released Bug description: This is intended to be a 'wishlist' wulnerability -- w.r.t. procps and Edgy. In my opinion,the /etc/sysctl.conf should have 'proc/sys/net/ipv4/tcp_syncookies=1' in order to permit the linux SYNcookies syn-flood trivial DoS attack to be mitigated as-necessary, by default. Note that the disadvantages of connections initiated w/ SYNcookies enabled only apply when the system is under attack (SYN queue getting rather full), as the syncookies reply-with-only-one-SYN+ACK behaviour only 'kicks in' when the system has a SYN_RECVD backlog problem. (If SYNcookies were not permitted incoming TCP connections have a very low chance of succeeding at all while under SYN-flood attack). Without this setting enabled, any TCP services on the machine can be DoSed from a dial-up line sending a stream of SYN packets from weird source addresses to open TCP ports like Samba/VNC/http/whatever Does anybody have any legitimate reason tcp_syncookies should be disabled? Some people claimed that SYNcookies break some RFCs once but I have not seen any evidence to this effect, only notes from djb saying that this is not true. Comments wanted please ;-) Thankyou in advance, -- enyc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/57091/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 57091] Re: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense...
Here is the entry from ...10-network-security.conf from 16.04 (although from Desktop edition) " # Turn on SYN-flood protections. Starting with 2.6.26, there is no loss # of TCP functionality/features under normal conditions. When flood # protections kick in under high unanswered-SYN load, the system # should remain more stable, with a trade off of some loss of TCP # functionality/features (e.g. TCP Window scaling). net.ipv4.tcp_syncookies=1 " Guess it hasn't been removed. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/57091 Title: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense... Status in procps package in Ubuntu: Fix Released Bug description: This is intended to be a 'wishlist' wulnerability -- w.r.t. procps and Edgy. In my opinion,the /etc/sysctl.conf should have 'proc/sys/net/ipv4/tcp_syncookies=1' in order to permit the linux SYNcookies syn-flood trivial DoS attack to be mitigated as-necessary, by default. Note that the disadvantages of connections initiated w/ SYNcookies enabled only apply when the system is under attack (SYN queue getting rather full), as the syncookies reply-with-only-one-SYN+ACK behaviour only 'kicks in' when the system has a SYN_RECVD backlog problem. (If SYNcookies were not permitted incoming TCP connections have a very low chance of succeeding at all while under SYN-flood attack). Without this setting enabled, any TCP services on the machine can be DoSed from a dial-up line sending a stream of SYN packets from weird source addresses to open TCP ports like Samba/VNC/http/whatever Does anybody have any legitimate reason tcp_syncookies should be disabled? Some people claimed that SYNcookies break some RFCs once but I have not seen any evidence to this effect, only notes from djb saying that this is not true. Comments wanted please ;-) Thankyou in advance, -- enyc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/57091/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 57091] Re: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense...
Upstream kernel have decided to enable syncookies by default (according to that debian bug, since Linux 2.6.37!). This makes sense, as the main downsides have already been resolved (especially window scaling even under syncookies-activation), and this feature only kicks-in if the SYN-queue is overloaded. We might now consider taking out this (now superfluous) tcp_syncookies entry from /etc/sysctl.d/10-network-security.conf ... I think, a similar situation has now arisen with respect to the "tcp_ecn" setting, where the (conservative) (enabled by default) fallback mechanism in the kernel, along with the rarity of ecn- intolerance, along with the wide ECN-adoption in practice in Apple ios / MAC OS X now, along with the importance of ECN for smooth responsive internet in the face of congestion, means that this tcp_ecn setting should similarly be seriously considered. This should be the subject of new bug report right-soon-now =). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to procps in Ubuntu. https://bugs.launchpad.net/bugs/57091 Title: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense... Status in procps package in Ubuntu: Fix Released Bug description: This is intended to be a 'wishlist' wulnerability -- w.r.t. procps and Edgy. In my opinion,the /etc/sysctl.conf should have 'proc/sys/net/ipv4/tcp_syncookies=1' in order to permit the linux SYNcookies syn-flood trivial DoS attack to be mitigated as-necessary, by default. Note that the disadvantages of connections initiated w/ SYNcookies enabled only apply when the system is under attack (SYN queue getting rather full), as the syncookies reply-with-only-one-SYN+ACK behaviour only 'kicks in' when the system has a SYN_RECVD backlog problem. (If SYNcookies were not permitted incoming TCP connections have a very low chance of succeeding at all while under SYN-flood attack). Without this setting enabled, any TCP services on the machine can be DoSed from a dial-up line sending a stream of SYN packets from weird source addresses to open TCP ports like Samba/VNC/http/whatever Does anybody have any legitimate reason tcp_syncookies should be disabled? Some people claimed that SYNcookies break some RFCs once but I have not seen any evidence to this effect, only notes from djb saying that this is not true. Comments wanted please ;-) Thankyou in advance, -- enyc To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/procps/+bug/57091/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
