[Courses] [security] tcp_syncookies

[Raven, corporate courtesan]

Heya --

Quoth Hamster and Kai MacTane:
> >The one I am thinking of is the SYN-flood attack. So you, I discovered 
> >/proc/sys/net/ipv4/tcp_syncookies. :)
> 
> Oddly enough, I was recently subjected to a SYN flood attack. (At least, I 
> think that's what it was. CPU load minimal, but all Net response sluggish 
> as a heroin-drowsed snail. Pings to my DSL provider came back in roughly 
> 200-5000 ms, with data errors. netstat showed lots of connections from one 
> IP, all in state SYN_RECV. If that's not what a SYN flood attack looks 
> like, I'd like to know what the heck it *was*.)

	Syn flood.  [grin]  Those symptoms are classic.
 
> So, reading your message, I just did this:
> 
>     root at surehand root# cat /proc/sys/net/ipv4/tcp_syncookies
>     0
>     root at surehand root#
> 
> D'oh!

	Not d'oh for you!  There was a vulnerability in syncookies
handling in pre 2.2.19-7 and 2.4.9-12 (that's you) kernel versions that
you'd open yourself up to if you turned it on.  

http://lwn.net/alerts/RedHat/RHSA-2001:142-15.php3

for the Red Hat advisory, though there were similar releases and posting
on Bugtraq for many other vendors.  Things like this are one of the
reasons that I think building a new kernel from new source after
installing a system is a good idea.  You get all the security patches
and fixes for the kernel itself.

	Other than that, I think syncookies are a nice insurance buffer
against synfloods.  

> >Now before I go happily "echo 1 > /proc/sys/net/ipv4/tcp_syncookies" -ing, 
> >are there any implications I should know about that makes this not such a 
> >good idea?
> 
> I'd love the answer to that one, too. Is there any reason in the world for 
> me to have that turned off (especially given that the skript kiddie who 
> apparently "0wnZ0r"s adsl-66-120-84-178.dsl.snfc21.pacbell.net could decide 
> to make my life annoying again at any time)? And, will simply echoing 1 
> into that file do anything, or do I need to do some other stuff as well? 
> (My kernel is a Slackware 2.4.5 kernel, so far unpatched.)

	There's a big argument about this.  It's a non-default way of
handling TCP.  Some folks think this is a Bad Thing.  

http://www.uwsg.iu.edu/hypermail/linux/kernel/9912.3/0043.html

Others (notably Dan Bernstein, the inventor of syncookies) think it's
grand:

http://cr.yp.to/syncookies.html

	I have heard complaints about weird performance issues for
systems with syncookies on.  I personally have never seen it happen, and
have had good luck with them.

	They should be on if you are actively getting synflooded, most
everyone agrees.  But if you're not... weigh the standards compliance vs.
safety/potential instability issues for your own system and make up your
own mind.  Vendors like EnGarde Linux that tout their security turn them
on.  I have them on on my Linux servers and have not noticed any
weirdness because of it.  YMMV.  

	Syncookies should be compiled by default into most any kernel
with TCP/IP networking capabilities.  I believe they are off by default
in most systems.  If you want to use them, just echo 1 to that file.
But get the latest kernel first.

	I did want to say something about TCP/IP stack tuning, security,
and the Linux kernel at some point.  Now is as good a time as any.
Other things you may want to do to your kernel (all the files in
/proc/sys/net/ipv4 should be there if you compiled TCP/IP networking
into your kernel, which you probably did if you're reading this message
or using a default kernel provided by your distro):

	Usually, /etc/sysctl.conf is the configuration file that sets
system-wide TCP/IP options.  If you want to specify these parameters
at boot time, you can add them to this file.  The parameters here,
you'll notice, are structured along the same lines as the filesystem in
/proc.

# Disallow source routing
net.ipv4.conf.all.accept_source_route=0
net.ipv4.conf.all.forwarding=0
net.ipv4.conf.all.mc_forwarding=0
# Drop incoming packets that come from a non-possible IP address
net.ipv4.conf.all.rp_filter=1
# Drop ICMP redirect messages
net.ipv4.conf.all.accept_redirects=0
# Don't send ICMP redirect messages
net.ipv4.conf.all.send_redirects=0
# Disallow Smurf attacks
net.ipv4.icmp_echo_ignore_broadcasts=1 
# Increase resources to mitigate SYN floods
net.ipv4.tcp_max_syn_backlog=1280
# Enable TCP syncookies to fight TCP synflood attacks
net.ipv4.tcp_syncookies=1

	[ripped from one of my machines]  You'll notice that many of
these concepts parallel things we've talked about with regards to
firewalling.  You'll also find them in books on the TCP/IP protocol
and the various implementations of it.  This is setting those same sorts
of safety nets in place, but at the machine level.

	If your machine is acting as a router, you may want to rethink
whether you want to allow ICMP redirects or not.  (I still don't, but
you may wish to.)  Note that the Smurf-attack blocking (a Smurf is a
denial-of-service attack when someone sends a ping to a network's
broadcast address spoofed "from" the victim's IP, and then the victim
gets hundreds of ping replies) only ignores ICMP echoes to the broadcast
addy.  This won't break all broadcast capability.

	After you make these changes, you'll have to rerun your
networking setup.  Look for where sysctl gets invoked in your boot
scripts -- probably /etc/rc.d/network or /etc/rc.d/init.d/network or a
similar location.  Then stop and restart that network script.  If you
are connected to the box via telnet or ssh, this *will* disconnect you.
All networking on the box drops.  What you don't want to happen (oh,
painful experience here):

You: 	"Aha!  I will make my remote server safer!"

raven at dahlia	/etc/rc.d/init.d/network stop

[network stops, kicks you out, does not start again]

You:	"Grrrrrrr."

I have done this, more than once, and then there's nothing for it but to
drive to wherever your box is, log in at the console, or have it
rebooted.  Don't shoot yourself in the foot like I did.  

Cheers,
Raven
 
"It's all part of my evil plot! Did I mention I was grown in a lab for
 specifically this purpose?"
  -- Anne, on perfection