Slackware's default network configuration exposes host to attack
3 Jan. 2000
Summary
Due to incorrect default settings in the /etc/rc.d/rc.inet2 script file, a Slackware host network settings opens the host to three types of common attacks: IP Forwarding, IP Spoofing (source validation) and SYN attacks. This problem might affect other distributions as well.
Slackware's default settings allows the following attacks:
IPV4 PACKET FORWARDING (On by default)
Starting at around line 19 or so is the section that deals with IP packet forwarding, which is being turned ON by default. This shouldn't be the default behavior since it's incorrect to assume that the machine is supposed to forward packets (according to the RFCs, the default behavior of a networked host is not to forward packets). The main problem is that people who dial-up to their ISP for Internet connection while having an active internal network connection are exposing themselves to attack on their local network.
Fix:
Change 'IPV4_FORWARD=1' to 'IPV4_FORWARD=0' in /etc/rc.d/rc.inet2
(NOTE: Make sure you know what this means before making the above change)
RP_FILTER (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 attackers from firing spoofed packets into your local network. This is supposed to be turned on by default once ip_forwarding is turned on (according to both the comments in the script and the kernel documentation). It seems that the interface for it in /proc still emits a '0' when ip_forwarding is turned on, meaning, that no check is done on the source of packets causing a possible vulnerability.
Fix:
To turn rp_filter off type: echo 0 > /proc/sys/net/ipv4/conf/<device>/rp_filter
or echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
(NOTE: Make sure you know what this means before making the above change)
TCP_SYNCOOKIES (Inactive under 2.2.x kernel)
The default behavior 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. Administrators should probably turn it back on, since it protects for the very commonly used 'SYN flood' attack.