-----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

Reply via email to