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 volkerdiat_private 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.)
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 15:22:11 PDT