Slackware Linux Essentials - Chapter 14 Security
Warning: file_get_contents(http://ecs.amazonaws.com/onca/xml?Service=AWSECommerceService&AWSAccessKeyId=1TJ8QTQ6ZFCVAJ3X1T02&AssociateTag=ii0c3-20&Operation=ItemSearch&SearchIndex=Books&ResponseGroup=Small,Images&Keywords=domain) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 400 Bad Request in /home/manusia2/public_html/wp-content/plugins/amazonfeed/php/amazonfeed.class.php on line 271
Security on any system is important; it can prevent people launching attacks from your machine, as well as protect sensitive data. This chapter is all about how to start securing your Slackware box against script kiddies, crackers and rogue hamsters alike. Bear in mind that this is only the start of securing a system; security is a process, not a state.
14.1 Disabling Services
The first step after installing Slackware should be to disable any services you don’t need. Any services could potentially pose a security risk, so it is important to run as few services as possible (i.e. only those that are needed). Services are started from two main places - inetd and init scripts.
14.1.1 Services started from inetd
A lot of the daemons that come with Slackware are run from inetd(8). inetd is a daemon that listens on all of the ports used by services configured to be started by it and spawns an instance of the relevant daemon when a connection attempt is made. Daemons started from inetd can be disabled by commenting out the relevant lines in /etc/inetd.conf. To do this, open this file in your favorite editor (e.g. vi) and you should see lines similar to this:
telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
You can disable this service, and any others you don’t need, by commenting them out (i.e. adding a # (hash) symbol to the beginning of the line). The above line would then become:
#telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd
After inetd has been restarted, this service will be disabled. You can restart inetd with the command:
# kill -HUP $(cat /var/run/inetd.pid)
14.1.2 Services started from init scripts
The rest of the services started when the machine starts are started from the init scripts in /etc/rc.d/. These can be disabled in two different ways, the first being to remove the execute permissions on the relevant init script and the second being to comment out the relevant lines in the init scripts.
For example, SSH is started by its own init script at /etc/rc.d/rc.sshd. You can disable this using:
# chmod -x /etc/rc.d/rc.sshd
For services that don’t have their own init script, you will need to comment out the relevant lines in the init scripts to disable them. For example, the portmap daemon is started by the following lines in /etc/rc.d/rc.inet2:
# This must be running in order to mount NFS volumes. # Start the RPC portmapper: if [ -x /sbin/rpc.portmap ]; then echo "Starting RPC portmapper: /sbin/rpc.portmap" /sbin/rpc.portmap fi # Done starting the RPC portmapper.
This can be disabled by adding # symbols to the beginnings of the lines that don’t already start with them, like so:
# This must be running in order to mount NFS volumes. # Start the RPC portmapper: #if [ -x /sbin/rpc.portmap ]; then # echo "Starting RPC portmapper: /sbin/rpc.portmap" # /sbin/rpc.portmap #fi # Done starting the RPC portmapper.
These changes will only take effect after either a reboot or changing from and back to runlevel 3 or 4. You can do this by typing the following on the console (you will need to log in again after changing to runlevel 1):
# telinit 1 # telinit 3
14.2 Host Access Control
14.2.1 iptables
iptables is the packet filtering configuration program for Linux 2.4 and above. The 2.4 kernel (2.4.5, to be exact) was first introduced into Slackware (as an option) in version 8.0 and was made the default in Slackware 8.1. This section only covers the basics of its usage and you should check http://www.netfilter.org/ for more details. These commands can be entered into /etc/rc.d/rc.firewall, which has to be set as executable for these rules to take effect at startup. Note that incorrect iptables commands can essentially lock you out of your own machine. Unless you are 100% confident in your skills, always ensure you have local access to the machine.
The first thing most people should do is set the default policy for each inbound chain to DROP:
# iptables -P INPUT DROP # iptables -P FORWARD DROP
When everything is denied, you can start allowing things. The first thing to allow is any traffic for sessions which are already established:
# iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
So as not to break any applications that communicate using the loopback address, it is usually wise to add a rule like this:
# iptables -A INPUT -s 127.0.0.0/8 -d 127.0.0.0/8 -i lo -j ACCEPT
This rules allows any traffic to and from 127.0.0.0/8 (127.0.0.0 - 127.255.255.255) on the loopback (lo) interface. When creating rules, it is a good idea to be as specific as possible, to make sure that your rules do not inadvertently allow anything evil. That said, rules that allow too little mean more rules and more typing.
The next thing to do would be to allow access to specific services running on your machine. If, for example, you wanted to run a web server on your machine, you would use a rule similar to this:
# iptables -A INPUT -p tcp --dport 80 -i ppp0 -j ACCEPT
This will allow access from any machine to port 80 on your machine via the ppp0 interface. You may want to restrict access to this service so that only certain machines can access it. This rule allows access to your web service from 64.57.102.34:
# iptables -A INPUT -p tcp -s 64.57.102.34 --dport 80 -i ppp0 -j ACCEPT
Allowing ICMP traffic can be useful for diagnostic purposes. To do this, you would use a rule like this:
# iptables -A INPUT -p icmp -j ACCEPT
Most people will also want to set up Network Address Translation (NAT) on their gateway machine, so that other machines on their network can access the Internet through it. You would use the following rule to do this:
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
You will also need to enable IP forwarding. You can do this temporarily, using the following command:
# echo 1 > /proc/sys/net/ipv4/ip_forward
To enable IP forwarding on a more permanent basis (i.e. so that the change is kept after a reboot), you will need to open the file /etc/rc.d/rc.inet2 in your favorite editor and change the following line:
IPV4_FORWARD=0
…to this:
IPV4_FORWARD=1
For more information on NAT, see the NAT HOWTO.
14.2.2 tcpwrappers
tcpwrappers controls access to daemons at the application level, rather than at the IP level. This can provide an extra layer of security at times when IP-level access controls (e.g. Netfilter) are not functioning correctly. For example, if you recompile the kernel but forget to include iptables support, your IP level protection will fail but tcpwrappers will still help protect your system.
Access to services protected by tcpwrappers can be controlled using /etc/hosts.allow and /etc/hosts.deny.
The majority of people would have a single line in their /etc/hosts.deny file to deny access to all daemons by default. This line would be:
ALL : ALL
When this is done, you can concentrate on allowing access to services for specified hosts, domains, or IP ranges. This can be done in the /etc/hosts.allow file, which follows the same format.
A lot of people would start by accepting all connections from localhost. This can be achieved using:
ALL : 127.0.0.1
To allow access to SSHd from 192.168.0.0/24, you could use either of the following rules:
sshd : 192.168.0.0/24 sshd : 192.168.0.
It is also possible to restrict access to hosts in certain domains. This can be done using the following rule (note that this relies on the reverse DNS entry for the connecting host being trustworthy, so I would recommand against its use on Internet-connected hosts):
sshd : .slackware.com
14.3 Keeping Current
14.3.1 slackware-security mailing list
Whenever a security problem affects Slackware, an email is sent to all subscribers to the slackware-security@slackware.com mailing list. Reports are sent out for vulnerabilities of any part of Slackware, apart from the software in /extra or /pasture. These security announcement emails include details on obtaining updated versions of Slackware packages or work-arounds, if any.
Subscribing to Slackware mailing lists is covered in Section 2.2.2.
14.3.2 The /patches directory
Whenever updated packages are released for a version of Slackware (usually only to fix a security problem, in the case of already released Slackware versions), they are placed in the /patches directory. The full path to these patches will depend on the mirror you are using, but will take the form /path/to/slackware-x.x/patches/.
Before installing these packages, it is a good idea to verify the md5sum of the package. md5sum(1) is a commandline utility that creates a “unique” mathematical hash of the file. If a single bit of the file has been changed, it will generate a different md5sum value.
% md5sum package-<ver>-<arch>-<rev>.tgz 6341417aa1c025448b53073a1f1d287d package-<ver>-<arch>-<rev>.tgz
You should then check this against the line for the new package in the CHECKSUMS.md5 file in the root of the slackware-$VERSION directory (also in the /patches directory for patches) or in the email to the slackware-security mailing list.
If you have a file with the md5sum values in it, you can source it instead with the -c option to md5sum.
# md5sum -c CHECKSUMS.md5 ./ANNOUNCE.10_0: OK ./BOOTING.TXT: OK ./COPYING: OK ./COPYRIGHT.TXT: OK ./CRYPTO_NOTICE.TXT: OK ./ChangeLog.txt: OK ./FAQ.TXT: FAILED
As you can see, any files that md5sum evaluates as correct are listed “OK” while files that fail are labelled “FAILED”. (Yes, this was an insult to your intelligence. Why do you put up with me?)
Tags: domain, email, inetd, protection, slackware, Slackware Linux Essentials, software, ssh, telnet