Firstly... You do not need to start a 'server program' as-such to get a listening port. Using bittorrent client or 'ftp' will easily create listening ports, making the system vulnerable to SYN-flood-DoS on those tcp- sockets. I.e. users can be easily 'vulnerable' without having to set up a service as-such.
Iptables does not directly solve the problem of SYN DoS.... Note that the DoS can/does happen using forged-source IP addresses and hence blocking 'source addresses' w/ iptables can only seek to mitigate the issue but not prevent it. I believe that firemalls are a separate consideration really.... This is a TCP configuration parameter that permits/denies the use of a syncookies defense under SYN-flood-attack scenarios. This is a 'TCP stack vulnerable to resource-exhaustion DoS by configuration/design' rather than 'service needs covering by firewall' sort of matter... I think I see this "issue" in a different way Jeremy Vies. The way I see this, there is no reason to disallow the use of SYNcookies when under SYN DoS. I understand the TCP stack in linux continues to answer TCP SYN w/ options etc. in the same way as without syncookies=1 until SYN queue is full -- i.e. no difference except when under DoS. *** Any facts / details to confirm or contradict anything stated above would be appreciated ;-) *** -- proc/sys/net/ipv4/tcp_syncookies=1 should be seriously considered to permit SYN flood defense... https://launchpad.net/bugs/57091 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs