Securing Linux

Here we go again. I decided to write another article concerning some overall security aspects of installing and running linux. To keep it short and simple, here are some good pointers to enhancing your system’s security. But remember, there’s no absolute security, so keep your eyes open, subscribe yourself to a few good mailing lists, and keep your software up-to-date.


Good partitioning does a lot of good to your system’s security as it greatly simplifies your admin duties in case of a system crash and data recovery. You can create various partitions, and have them set as read-only, nosuid or similar. By having a partition mounted as nosuid you can simply address the SUID issue, generally connected to buffer overflows and obtaining a root shell or some other possibile security compromising flaws. More about the SUID issue can be read here. If you plan to run an FTP server, setting that partition would save you a lot of trouble in the future, as it is in read-write mode, but no suid programs can be run from it. The same can be said for mounting a partition read-only, or ro. You can always alter these settings, wich are located in /etc/fstab, for any of your block devices. Of course, ‘man fstab(5)’ and ‘man mount(8)’ are your good friends to get a grip on all possible options when mounting a filesystem. /etc/fstab is human readable, so you’ll easy get into it.

Generally speaking, putting linux, or any other OS on a single partition is a major administration no-no, and with any multiuser, multitasking os, is asking for trouble, sooner or later. So, whenever possible, create at least these partitions, with sizes of your choices:

  • / – which needs little space, but will house all of your other directories if you do not create them as stand-alone partitions,so consider that also before creating it
  • /usr – houses most of your software, so you might consider allocating a lot of space here,
  • /home – is the starting point for all users on your system, so allocate space according to the number of users you plan to have
  • /var – which is required for all the administrative logs, mail, usenet news and other.

From a security point, a good thing would be to consider at least having a separate / and a /home partition. This way you can restrict access to some partitions, can easily repair damaged filesystem and keep the system running and so on. It even might be good to keep your temporary data and logs on a separate, RAM partition. That way, no information about your system and all events that took place can be traced, because all the information on the RAM disk is lost when the system is rebooted or shut down. But, you also might consider taring the files before shutting down, and copy them elswhere for later safe reading, if neccessary. It’s up to you.

You can always partition your system prior to the installation of any flavour of linux you have chosen, and most of the distributions come already equipped a partitioning tool. However, if you wish to do it yourself before installing linux, you can always do it with any fdisk, ‘man fdisk(8)’ or run fdisk and type ‘m’ for reviewing the list of all commands. Of course, there are other tools for partitioning, such as Disk Druid that comes with Red Hat, or Parted, a tool from the GNU foundation that you can find it here.


Relying solely on decent passwords is not a good security measure, but using good passwords reduces the risks of a security breach. So, use password generation utilities, and most of all, educate your users about the significance of good passwords. Sadly, the best passwords are the ones you’ll hardly ever remeber right, so it’s always a trade-off between security and usability. Usually, this means horrible passwords, written on paper.

There are various proactive password checking utilites that can simplify your job and force users to pick a right password. Shadow passwording system needs not to be mentioned, it’s a must. A good practice would be to do a dictionary attack by yourself from time to time, just to check for easy retrieveable passwords. Make sure all users create a separate password for any system they access. All passwords are vulnerable to dictionary attacks and brute force attacks, it’s only up to you to make the attacker’s job more difficult.

Services and daemons running at boot time

All that could be briefly said is: disable anything you don’t need, or don’t plan on using and also don’t install anything you don’t need.

One thing is certain, if you need a certain service, like telnet or FTP, think about it. Are they really needed? Are they safe to use, and is there a supplement to them, even more reliable? For instance, SSH replaces telnet perfectly, and FTP is pretty much obsolete, with all those web forms

these days, and, yes, even SCP from the SSH package.

Need an MTA? Why not think Qmail or some other instead of sendmail? A lot of issues exist when planning what services you will provide, and more important how.

Think how you’re going to organize your machines in production, as it’s pretty much useless to setup a perfect firewall, lose a lot of time on perfecting it, just to put an FTP behind it. Deploy servers rationally, using the least possible number of services exposed to the outside of your LAN, no matter how simple or harmless the service might be. If you really need services that have known past security issues, a wise idea would be to put them in DMZ, and separate them from all other machines, in any possible way.

Using LILO

If you plan to use LILO as your boot loader, some things can be achieved by adding some extra lines to your /etc/lilo.conf, and these are ‘restricted’ and ‘password=”somepassofyourchoice”‘. After making any alterations to /etc/lilo.conf make sure to re-run lilo by typing /sbin/lilo’ to have them take effect when booting next time. Adding line restricted makes it neccessary for the user to provide a password when trying to pass additional boot parameters to lilo. The password option restricts the booting of linux to local users who have the password, but the password isn’t encrypted so make the /etc/lilo conf owned by root and set to mode 600. That’s ‘chmod 600’. As always, you can ‘man lilo’ to find out more about additional options. The ultimate choice is to make lilo boot from a floppy, so nobody without that floppy can boot the system. Nothing like a dose of physical security measures! 🙂 But still, be sure to have a backup lying somewhere safe because floppies aren’t that reliable…

Of course, there are other ways of booting linux, so make sure that you read more documentation on the subject, so that you can make some good choices to enhance the security of your system.


Think about running a scanner on your system to check it for vulnerabilities, wrong file permissions, SUID, or other wrongly set UID’s, open services, ports, etc. Network scanners test your host, as would a possible attacker do, and in most cases will, looking for any services and ports open and searching for any known vulnerability. Most scanners are easy to use and configure, so I’d recommend using the ones listed below:

Of course, there are so many others I’d need to write another article just to name them all, but the above mentioned are the most commonly used and have all the functions and options you may need. Use them cautiosly, and remember, trying to scan other hosts may be in violation of some law, or could cause an un-willing Denial Of Service attack.

On the other side, scanning can be logged so beware of any consequences involved in scanning other systems. Stick to scanning only your system for checking for possible exploits and running services you don’t need.

Consider running any scanner detector or logger, in conjuction with some tools that trigger certain events on detection of scanning.

If you plan on deploying a web server with CGI’s, I urge you to use a CGI vulnerability scanner, as it will save you from a lot of harm, as CGI

vulnerabilities impose a great threat. If you use poorly made CGI scripts, you’ll undermine the safety of your web, no matter how hard you tried and worked on it.


Logging is one of the great advantages linux has to offer. Logging, by default includes reporting errors, reasons, users logged in, the duration of their login time, tracks of scanning and other valuable information. That can also be missused, but that’s an issue too long to be discussed here.

System and kernel messages are handled by syslogd and klogd, and the output is located in the /var/log/messages file. A good thing to do is to

customize /etc/syslogd.conf to suit your needs, and to make the tracking of information easier. Typing ‘man syslogd(8)’ can bring you up to speed with syslogd and syslogd.conf. Just for an example, let’s say you wanted to separate all warning and error messages in a different file, you’d do it by entering the following lines in /etc/syslogd.conf:

# all error and warning messages logged

*.warn; *.err /var/log/errmsg

Everything can be logged up to some point. Read, develop your ideas, and implement them. Log everything. Logging is good. 🙂

The downside is that the attacker can learn about your system from your logs, so think about that RAM disk mentioned at the begining, or a separate partition with restricted access. You could also encrypt that partition, but that could cause some problems if not done with care.

Don’t underestimate the importance of logging. You can learn a lot about your system and network reading logs, and logs are sometimes your only hope in finding information about possible system intrusions that have occured to your system. You can find all sorts of logging utilities just lying around, waiting for you to pick them up and put them to good use.

Intrusion detection

So, you did a stealth scan and you think you can get away with it? Nope, quite wrong. In fact, most of your activites are being logged and carefully examined by someone right now as we speak. That my fellow readers is known as intrusion detection. Intrusion detetection is a real-time detection activity of intrusion attempts or any other information gathering activites. IDS’s are an extremly useful tool for any sys admin, so grab one and play around. I’d suggest Snort, as it is very versatile.

How does an average IDS work? IDS commonly use rule-based systems, meaning that certain events trigger other events, as described in the rules they use. Naturally, many rules can be made: you can write your own, or download pre-set rules, and that’s why I recommend getting Snort, as it is equipped with an enormous set of rules. An IDS listens to your network traffic, and upon noticing a suspicious activity (that’s what rules are for) it takes approriate steps, or can do so by analyzing your logs (you did log everything, did ya?). Of course, this approach is not fault free, and many false alarms could be generated, but never the less…

IDS’s are still being developed, and as such are not bug-free. Dealing with IDS’s may mean a lot of hard work setting it up right, writing your own rules, and generally asking yourself are they really worth the effort. Well, they are. In conjunction with a decent firewall, IDS’s, when set up properly, can prove to be a real time and nerve saver, not to mention boosting your system’s security.


Most of you are well aware of problems with privacy. And most of you mind your data and information being read by other people. Well, encryption is the answer you’re looking for. Use any encryption tool whenever possible. Encrypt your files, your mail, using OpenPGP, PGP, or other tested and proved encryption tools. You might consider encrypting entire folders, or even partitons containing personal data.

When accesing remote systems, use OpenSSH, don’t use Telnet, protect your data in transit. Network sniffers and other tools make the usage of a secure shell is a must these days. If you’re building a network use SSH, discard Telnet, as it is unsecure. SSH uses several algorithms, like RSA, IDEA, Triple DES, wich makes it an ideal choice for protecting your data in transit. Naturally, it also has some security history, so it would be good to keep your SSH up-to-date by applying patches and upgrading regularly.

Keep your system clean

Maintain your system clean and trojan free by using a tool like Tripwire. Viruses are not such big of an issue when it comes to linux, as they try to do some damage to the system. In order to do so, they first must obtain root access. Trojans, on the other hand, are a common thing on any system including linux. What is a trojan? A trojan is a program pretending to do something, but is in fact doing something else, and you guess it, that ‘something else’ is a no-no. Nowadays with everything

being downloaded from the internet, a major security issue has came up, concerning trojans. One could make sure by compiling everthing on their own system, and skimming through source code prior to compiling, but that’s not something most people have in mind when thinking about installing new software. Nor it is easy. Hell, I wouldn’t do it, unless I was extremly bored and had a looooot of spare time…

You might try to keep your system clean by making a fresh linux installation, and afterwards using Tripwire to preserve a snapshot of your system. Tripwire maintains a checksum database of everything installed, and if you should notice any odd activites, you can compare what exactly has changed since the last check, and therefore find out about any suspicious files on your system. Neat… Another must for any system administrator. But remember, make a fresh install, it can’t help you with a system that has been up and running for who knows how long, and could already contain malicious code.


Let’s dwell further into this subject. A firewall is basically a device, program or script, that prevents others from accessing your network, or your services. Different types of firewalls exist- both hardware and software based. I’ll deal with the software solution here. The firewall is not the ultimate in protecting your network, but can make a lot of good if used properly.Configuring a firewall is not easy and is time consuming but when set right can make your life much easier.

Linux is perfect for such duties. Depending on your kernel, or your distribution, you may find ipchains, or older ipfwadm installed to do the magic. Kernel 2.4.x supports a new utility called iptables. They all do the same, more or less efficiently, but as with anything security related, the newer – the better. What they all do is known as ‘packet filtering’, they analyze incoming packets and decide what to do with them, based on the rules that you set up. By using several variables, such as the port number, protocol or IP address, you can set up various rules for various situations.

When constructing firewall rules by yourself, a good idea is to use the policy ‘drop’ instead of ‘reject’ when controling unwanted IP packet traffic, as rejecting will let the possible attacker know about the firewall. With the ‘drop’ policy he will not be aware of what exactly happened to the packet, but he’ll be forced to guess. Try it out.

You can always go for the commercial software solutions, or even hardware, but it’s a good idea to try and create your own little firewall no matter how small, or even unefficient it may be, just to see how it works. Actually, free firewalls, firewall tools, and commercial ones will do the trick probably better than any of us can write in a short amount of time, so it’s a good idea to stick with a pre-made, just make sure it has no significant security history.

Remember, relying solely on a firewall is asking for trouble. Use it in conjunction with other tools.

Kernel patches

One of the fine things with linux is the kernel. You can re-model an re-fit it to suit you needs, whatever those may be. A plain and ordinary kernel, re-compiled for you specific needs is good, but there are a lot of kernel add-ons or patches that can only do good for your system. Various scheduling, other tune-up patches and patches alike are available.

A number of kernel patches exist designed solely to spice up your system’s security, fix possible problems, or even holes in the kernel. A good example of such patch is the Openwall, which deals with various issues that may prove to be of some significance, like the non-executable user stack area, for those pesky buffer overflows, restricted links in /tmp, restricted /proc and so on. I suggest you visit the URL mentioned above and see what you make of it.

Aside from kernel patches, there are a couple of good scripts lying around designed to harden the security of your system, especially default installations maintained by novice linux users. Some of them may not do much that an experienced system administrator couldn’t, but are a helping thing for the unexperienced.

Usualy, the vendor has an archive for the patches, and there are sites dedicated to such things, so you can track down the latest patch with ease. Apply them, ASAP. It’s a bad enough fact that your system has a security hole, let alone keeping it like that for some time.

Physical security

Last but not least, do not underestimate the importance of physical security. You’ve maybe created the perfect fortress, but think twice about it’s location. Who will have access, where it will be located, a lot of questions will arise during this process, questions to which should make you think twice before giving any answers.

But, to keep a short story short, we’ll stop here.

By combining many different utilities and aspects of keeping your system secure you’ll be able to reap multiple benefits, no to mention keep your nerves in a good shape. I hope you found good information in this one, ’till next time…