[Bug 57091] Re: proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense...

[Matthew Caron]

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
Foundations Bugs, 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