mailing list archives
Re: Various Errors in Slackware
From: david+nospam () KILLERLABS COM (David Ford)
Date: Tue, 21 Dec 1999 23:34:41 -0800
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
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
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.
kuznet () ms2 inr ac ru
ak () muc de
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.)