Date: Tue, 21 Dec 1999 13:00:50 -0600
From: "Dagmar d'Surreal" <[email protected]>
To: [email protected]Subject: Various Errors in Slackware
This message is to address some problems I noticed in Slackware (the
distro I work with) which are not huge things in an of themselves, but
are still in need of correcting. Some of these might come as an ugly
suprise to people who expected things to be 'just so'. Emails were sent
to the security address listed at slackware.com, as well as the
[email protected] address well over a month ago, so complaints that I
didn't try to tell anyone about this will go directly to /dev/null.
These really only apply to Slackware 7.0, but my only 4.0 CD was too
heavily modified to be sure whose code is whose. 4.0 users might want to
check theirs anyway. There are three problems, and they should be common
to pretty much any 2.2.x based distribution.
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.)
