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 : [email protected] Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
