Date: Tue, 21 Dec 1999 23:34:41 -0800
From: David Ford <[email protected]>
To: [email protected]Subject: Re: Various Errors in Slackware
I would check with Alan on the SYN cookies, iirc, there is a good reason why
SYN cookies are not turned on by default. In 2.3.x it is not turned on by
default in the kernel compile and again must be explicitly enabled in /proc
after adding it to the kernel.
According to the Configure.help:
If you are SYN flooded, the source address reported by the kernel is
likely to have been forged by the attacker; it is only reported as
an aid in tracing the packets to their actual source and should not
be taken as absolute truth.
SYN cookies may prevent correct error reporting on clients when the
server is really overloaded. If this happens frequently better turn
them off.
I would then surmise that it is a tool whereby the value of it's use is
often outweighed by the "bug reports" and "kernel problems" or "this guy
attacked me" reports.
I imagine the packet forwarding is on by default in the interest of least
surprise from slackware. I.e. why you can't pass packets across the machine
even if your ipchains/iptables has the forward rule set accordingly and you
have routing setup properly. The kernel's default is off:
ip_forward - BOOLEAN
0 - disabled (default)
not 0 - enabled
Forward Packets between interfaces.
This variable is special, its change resets all configuration
parameters to their default state (RFC1122 for hosts, RFC1812
for routers)
According to the sysctl documentation in 2.3, the default value for
rp_filter is 1 however:
rp_filter - INTEGER
2 - do source validation by reversed path, as specified in RFC1812
Recommended option for single homed hosts and stub network
routers. Could cause troubles for complicated (not loop free)
networks running a slow unreliable protocol (sort of RIP),
or using static routes.
1 - (DEFAULT) Weaker form of RP filtering: drop all the packets
that look as sourced at a directly connected interface, but
were input from another interface.
0 - No source validation.
NOTE: do not disable this option! All BSD derived routing software
(sort of gated, routed etc. etc.) is confused by such packets,
even if they are valid. When enabled it also prevents ip spoofing
in some limited fashion.
NOTE: this option is turned on per default only when ip_forwarding
is on. For non-forwarding hosts it doesn't make much sense and
makes some legal multihoming configurations impossible.
authors:
Alexey Kuznetsov.
[email protected]
Updated by:
Andi Kleen
[email protected]
-d
On Tue, 21 Dec 1999, Dagmar d'Surreal wrote:
> IPV4 PACKET FORWARDING -- Should not be on by default
> -----------------------------------------------------
> There are three problems that I am aware of at the moment, and they're all
> in /etc/rc.d/rc.inet1, unfortunately. Starting at around line 19 or so is
> the section that deals with IP packet forwarding, which is being turned ON
> by default. IMHO, that's incorrect, because it really shouldn't be
> _assumed_ that the machine is supposed to forward packets. (According to
> RFCs as well--thanks for pointing that out to me Alan!) On top of this,
> the default configuration scripts only allow for one ethernet interface,
> so it doesn't make a lot of sense to turn this on either. Not much could
> be done about exploiting with without more than one interface, but people
> dialing up their ISP with pppd who have an ethernet network attaches to
> that host could possibly be exposing themselves to a bit of risk.
> It's an easy fix. Change 'IPV4_FORWARD=1' to 'IPV4_FORWARD=0' in
> /etc/rc.d/rc.inet1 unless you know what you're doing.
>
> RP_FILTER -- Probably incorrect assumption
> ------------------------------------------
> Just below the section that turns on IP forwarding is a section that
> theoretically turns on rp_filter, which is supposed to do source
> validation of incoming packets to prevent outside lusers from firing
> spoofed packets into your local network. This is supposed to go on by
> default once ip_forwarding is turned on, according to both the comments in
> the script and the kernel documentation. (Annoyingly enough, the
> interface for it in /proc still emits a 0 when ip_forwarding is turned on,
> which leads me to believe that something might be missing in the kernel,
> although I might be the only person that ever tries to read proc first to
> see what's on and what's off.) Better to be safe than sorry and change
> the logic to stuff a 1 in there if IPV4_FORWARD is true, and a zero in
> there if it's false.
>
> TCP_SYNCOOKIES -- Gobbled up by the 2.2.x kernel
> ------------------------------------------------
> If we're going to be messing around with parts of the /proc interface here
> in /etc/rc.d/rc.inet1 then we should really turn on SYN cookie support
> while we're at it. (Probably log_martians as well, but I really don't see
> where this would do anything other than nada if the machine has a default
> route, or really burn up disk space logging packets if someone
> accidentally forgot to add themselves a default route and exposed the
> machine to live internet traffic. Looks useful for spotting oddities,
> tho.) The default behaviour for syn-cookies went from having the
> protection turned on by default in 2.0.x to being turned off by default
> for 2.2.x, and frankly, I happen to like it on. Right-thinking admins
> should probably chuck in a subsection for it below the rp_filter stuff.
>
> Anyway, those are the three problems I had with 7.0. Sorry no diffs, but
> people who use Slackware are capable of editing shell scripts, and I
> figure other people have probably already modified the things themselves
> which would make applying a diff a little dodgy. Excluding the fact that
> it still uses egcs, Slackware is still my distro of choice because I can
> whip it into shape faster than any other distro, and these are really the
> only parts that seemed borked. (Well, okay, so the init scripts in
> general could use some cleaning up, but they still work fine.)
>
--
