COMMAND
kernel
SYSTEMS AFFECTED
Linux Slackware 7.0
PROBLEM
Dagmar d'Surreal found following. Some of these might come as an
ugly suprise to people who expected things to be 'just so'.
These really only apply to Slackware 7.0. 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.inet2, 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.
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 to
believe that something might be missing in the kernel, although
one might be the only person that ever tries to read proc first
to see what's on and what's off.)
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.inet2 then we should really turn
on SYN cookie support while we're at it. (Probably log_martians
as well, but can you 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.
SOLUTION
IPV4 PACKET FORWARDING -- Should not be on by default
-----------------------------------------------------
It's an easy fix. Change
IPV4_FORWARD=1
to
IPV4_FORWARD=0
in /etc/rc.d/rc.inet2 unless you know what you're doing. Above
is true for Slackware 4.0
RP_FILTER -- Probably incorrect assumption
------------------------------------------
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.
It also applyes to Slackware 4.0, but it isn't kernel problem.
Kernel documentation says:
# rp_filter
# Integer value deciding if source validation should be made.
# 1 means yes, 0 means no. Disabled by default, but
# local/broadcast address spoofing is always on.
#
"Disabled by default"! Patrick Volkerding was noticed long time
before Slackware 7 (as soon as found in 4.0).
TCP_SYNCOOKIES -- Gobbled up by the 2.2.x kernel
------------------------------------------------
Right-thinking admins should probably chuck in a subsection for it
below the rp_filter stuff. 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.
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. So.... SYN cookies don't default to on purely because
they are strictly not "the standard". In fact its normally
standards compliant stuff that causes problems
SACK - with buggy VJ compressors
PAWS - with broken load balancers
MTU discovery - with assholes who block all ICMP out and
in (some very big names in the business
meet this criteria btw)
RST cookies were also in Linux 2.0, those did cause problems with
some setups and were dropped.