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