I'll say at the outset that I feel that the title "Securing Linux" is somewhat misleading. It implies that one can somehow go through a series of steps and emerge at the end with a secure Linux system or network. That isn't true. The real intent of this two-part series is to help you improve the security of your system and to get you to think securely. One without the other is unlikely to succeed.
Security is a state of mind
Ultimately, security isn't something that is achieved as an end goal; it isn't a state. Rather, it's a way of setting up, maintaining, and running an operating system, network, or environment. Security is a process and a mind-set as well as a condition. It depends on the day-to-day actions of the system or network's users and system administrators. It also depends on the system security not being so intrusive that it encourages users and administrators alike to work around it.
But you have to start somewhere, and that somewhere is to improve the security of your system as much as possible while still meeting your operational needs. A system that isn't connected to any network or phone lines and is kept in a locked room is reasonably secure -- but it will meet few of your needs. From there we embark on a series of compromises between the best possible security and the least inconvenience and difficulty that will serve our purposes.
Some of these tips are specific to Linux systems, but many are very general principles that apply to all systems and networks -- not just to Unix (or Unix-like) OSs.
- Less is more
Applying the Principle of least privilege and the Principle of minimum access ensures that you open up your system to the least amount of risk. Users are allowed only enough privilege and access to do their work, and no more.
Principle of least privilege
Users, applications, and even systems should be granted the least amount of privilege required to accomplish their respective tasks. This approach reduces the opportunity for accidental compromise of the system. Ideally, security should not be a burden on your users. It should not get in the way of their ability to accomplish their tasks. Unfortunately, this isn't always the case. You must strike the right balance in terms of who is allowed to do what, and when.
Principle of minimum access
"That which is not explicitly permitted is denied."
This is one of the basic mantras of firewall design. It applies equally well to security in general. In a secure system, you grant access by intent and deny everything else by default. Permission takes place by will or by action. This is a simple fail-safe principle. If you "fail" to take action, you end up failing into a "safe" state (access denied).
Set up your basic security mechanisms to deny everything unless you explicitly configure it to be allowed. Set the
/etc/hosts.allowfile to allow
localhostonly, and set the
/etc/hosts.denyfile to deny everything else. With that as a starting point, you can decide who and what will be granted which access, and everything else will be blocked. The default should always be "No!"
Do the same thing with your firewall rules, whether you're using a standalone box or a networked system. Firewall code is a useful feature, even if you aren't routing traffic between systems. The Linux kernel has firewall code built in. It just needs to be enabled and configured -- which is well worth the effort.
Plan ahead and plan to distribute services. Even before you begin an installation (and, ideally, before you purchase system software solutions), make a detailed plan of your intended security defenses. On paper.
Some basic steps along the road
Before you decide how to secure your systems, you must first decide how you intend for them to be used. Decide what services each box will use on the network and what services each box you administer will offer to the network. This helps form a security policy. That policy or plan can be simple for simple systems, or it can be a large book for large sites and networks. In either case, it helps to decide what you want to do before you do it. The creation of this policy is also the most frequently overlooked step in developing a secure system.
Network layout and design considerations
If your site or networks permit it, compartmentalize functions. While this may be impractical for the home user with a single box, one should put different functions on different systems whenever possible. Your DNS, FTP, Web, mail, and firewall should not all be on the same system. If they are, and one service is compromised, they all will be compromised. Placing functions on separate systems limits the damage potential of a successful attack.
If you have a limited number of systems and must therefore combine functionality, your security issues are more complicated. You will have to depend on your authentication and authorization systems to provide the isolation that could have been provided by separate boxes.
A secure system starts with a secure install. This is one area where the various Linux distributions fail to do an adequate job. All of the distributions are guilty of making it too easy to set up insecure or misconfigured installations. Many of them enable services that the new user is unlikely to be aware of, or enable services before they are fully configured. Some vendors and consultants are now complaining that Linux is much too easy to install, because it allows users to unknowingly install poorly configured servers and shoot themselves in the foot. They are correct.
Security starts with the installation
Until the Linux distribution vendors wise up and start out with a secure configuration, it's up to the user to turn a basic installation into one with a reasonable shot at being secure.
When you're installing your system, never install software unless you intend to use it! Resist the temptation to "just install everything." Some of the things you so casually install could come back to haunt you during a system attack.
If your distribution permits it -- and not all do -- hold off on enabling services until you're familiar with them and have configured them. Some distributions assume that if you're installing a service, it should be enabled. If you aren't sure, don't install it!
- Secure services
Internet and network services are among the most vulnerable parts of your system. Whether you're planning a new installation or reviewing security on an existing system, your file servers, e-mail services, Web servers, FTP, and other network services should be among the first things you check for security holes. Some services will obey the
/etc/hosts.denyconfigurations if they've been compiled with the TCP Wrapper library, but not all will. Use the firewall code along with the TCP Wrapper configurations to secure your services.
Secure file serving
If you're exporting any filesystems via NFS, SMB, Samba, or anything else, make sure your access permissions are carefully checked.
Never run NFS, SMB, or NIS over the Internet. The risk is just too great. (NIS is jokingly referred to as "network intruder service" and some have referred to NFS as "no file security.") NFS in particular uses UDP and depends on peer addresses for authentication and authorization. But peer addresses are trivial to spoof for UDP!
If you're running POP or IMAP for remote downloading of e-mail, switch to an SSL-encrypted version. You can use stunnel or edssl to set up SSL-enabled mail servers. Several e-mail clients support SSL POP and/or SSL IMAP, including Netscape and Microsoft Outlook. SSL-enabled fetchmail is available from the North American Cryptographic Archives.
If you aren't intending to run POP or IMAP, make sure you really aren't running them. Some distributions enable these by default. Some of the "bad guys" out on the Net are now engaged in massive parallel-port scanning for IMAP servers. If you leave the backdoor open for one of them to get your number, the next time a major root compromise is discovered in IMAP (for example) he or she could promptly come knocking. If you don't know you're running IMAP, you'll have no reason to know when security patches or updates to it become available. Without these upgrades, an intruder could be root on your system before you know what hit you.
Secure Web services
If you're running a Web server, check and recheck your CGI scripts. Do not allow other users to install arbitrary CGI scripts. Do not use unrestricted server-side includes (SSIs).
If you're operating an anonymous FTP service, watch your permissions closely! Don't allow any directories to be both readable and writable by anonymous users. If you want to permit anonymous uploads to your system, provide a write-only directory and prohibit directory creation underneath it. If you permit a location to be both readable and writable, you not only allow your system to be a "warez" (pirateware) repository, but you also open up your system to being used for "FTP bounce" attacks against other systems.
If you're not running anonymous FTP -- make sure you're not. A lot of distributions enable anonymous FTP by default.
Disable telnet and finger
If you're running
rshto access your system remotely -- Why?!?!? These are seriously insecure and allow passwords and userids to be "sniffed."
For remote access, use secure shell (
ssh) connections and disable all nonencrypted remote access to the server. The
ssh package can be downloaded and installed very easily.
sshisn't available on any Linux distribution originating in the United States due to US export restrictions on cryptography. Some distributions from outside of the US do include cryptography modules and applications such as
sshand PGP in the base distributions and installations.
fingeris often configured and available on default installations. Unless you have a specific need for this service, disable it or restrict network access to it.
fingerprovides far too much information about your users to would-be intruders. It is also instrumental in certain advanced forms of denial-of-service attacks such as "nisnuke" on large networks.
- Up and running
Once your system is set up, be sure to keep track of the services you're running. Keep a close eye on services and applications by monitoring your UDP and TCP ports.
Tracking down services
Go through your system and make sure you're not running any services you don't intend to run, haven't configured, aren't using, or don't understand. I helped a Web site clean out an intruder who broke in using
innd, even though the site wasn't running a news system. Installing services that users don't need or understand is a major strike against every Linux distribution -- and most other OSs -- out there.
If you run it, they will come
/etc/inetd.confand disable any service you don't want to be running or don't understand. If you do this simply by commenting out the services you don't want, you can easily reenable a service at a later date. But very few of us need
discard. If you don't need a service, don't use it. And if you don't know what it is, don't run it until you find out. With a typical workstation configuration, it may be possible to turn off all services. For instance, if your machine isn't running any
inetdservices, you don't need to run the
Find out who's listening to what
nstat -aand look for any unusual ports or services. If you see a TCP port in the state of
LISTENand you can't identify the local port or service, track it down and decide if it's something you really want to be running.
Do the same for any UDP ports you find.
If it isn't something you specifically want, shut it down. If it's something you want locally but don't want outsiders to access, use the Linux firewall code to block outside access to it.
If you have trouble determining what application is listening on a TCP port or opening a UDP port, use the
lsofpackage to track it down.
Keep up with the times
Keep all software and distributions current with any updates released by the distributor. If the distributor doesn't have a mechanism in place for announcing updates or alerts, consider finding a different distributor. Install updates as soon as they become available. Far too many systems have been broken into because of out-of-date
imapdservers, even when updates had been available for months.
- Password and authentication security
Passwords can be the most underestimated security feature you have. Make sure that neither you nor your users are using transparent (easily guessed) passwords, and make sure that your passwords are safe from unauthorized intruders.
It is frankly stupefying to discover how lax some administrators are about secure passwords. Passwords should be at least five characters long, should mix letters with numbers or other atypical characters, and should be changed several times a year, at the least. Your users should know that password sharing isn't allowed, and former users should be deleted from systems after a reasonable amount of time has passed (i.e., former users should be allowed time to alert all correspondents of their new e-mail address). Ex-user accounts can usually be password-disabled immediately upon the employee's departure. Be aware that more attacks come from disgruntled employees than from any other source. If users are in the habit of sharing passwords, a disgruntled attacker could have access to your system even if you have disabled his or her account.
Proceed with caution before implementing this next bit of advice:
To ensure that you're not using transparent passwords, you can run the program
crackon your own password system. Running
crackon your personal system or any system on which you're the administrator is fine. But do not run this program on a system for which you do not have administrative privileges without the consent of the system's management!
Warning! Some companies and ISPs take offense at users having "cracker tools" such as
crack, or any of a variety of sniffing and scanning tools (described in the section called "Eternal Vigilance") on their systems. If you aren't an administrator on a system, make sure you have permission to possess these items and that the administrator is aware of them. Some people consider the possession of lockpicks to be no different than the possession of burglar tools. If you have tools for cracking passwords or breaking into systems, you may be setting yourself up to answer some very intense questions. Some ISPs don't even ask questions first. Providers have been known to cancel accounts merely for the possession of cracking tools. Don't take the chance. Don't even download these tools if you don't have your administrator's permission!
Not only should you never share passwords or give your passwords out to anyone, you should never leave passwords written down where they can be read. Intruders known as dumpster divers periodically go through the trash looking for scraps of paper with passwords on them. Destroy all security information before discarding.
Additional password security
If you aren't running a distribution that supports PAM (Pluggable Authentication Modules), then get one. PAM makes it relatively simple to enable advanced password checking, encryption, and longer passwords. When you have it, enable it and use it.
If you aren't in a network requiring single sign-on authentication (NIS, NIS+, Kerberos, etc.), enable shadow passwords and MD5 (Message Digest algorithm) hashing. This enables long passwords and makes them much tougher to crack with brute force, and much tougher to steal if you aren't the superuser.
- Security and the privileged user
Never perform routine operations as root! Do your routine work as a nonprivileged user and step up to root only when needed. This is a common mistake of most newbies to Linux (and Unix in general). When you (or a user or a program) must run as root, take the proper security precautions.
Don't run as root
A couple of years ago we had a Linux "virus" running around. Actually, while some were sure "Bliss" was a virus, others thought it was merely a worm or a trojan. In hindsight, it's probably safe to say that it was something of a hybrid -- mixing a little bit of each. But the important thing is that it only propagated because people were running as root, allowing it to modify system binaries. This is very bad practice. This rule can't possibly be understated! If you routinely run as the root user, you might as well be running DOS -- you have just about that much security!
By not running routinely as root, you also reduce the likelihood of "accidents." My son discovered that, if he was running as root, any changes he saved to his desktop were saved to the systemwide configurations. He found out what a bad idea this can be when he got part of the configuration wrong and was then unable to get any account to work right! This kind of accident could lead to unforeseen side-effects and security compromises.
Never use a browser or chat program when running as root! While the chance of a hostile applet --- written in Java, ActiveX, or some other language -- is remote, it isn't worth the risk. The destructive capability of such applets is magnified manyfold if you're running as root.
What you can do with sudo
sudois a useful tool to allow trusted users to perform certain functions as though they were root -- while at the same time limiting their ability to really function as the superuser. It also provides convenient access to those utilities that require root permission to run. By using
sudoyou avoid the overuse of suid.
As with any security tool,
sudoshould be used with caution. While running a command under
sudo, the user's permissions are elevated to root. This makes any potential bugs or security holes in the command or program you're running under
sudomore serious than they would be if you were running them as a normal user. For instance, a shell escape out of a
sudo-run command is a potential root backdoor.
Even some programs that expect to be run only as root can become a security hole under
sudo. If the program assumes that only root can run it, and if that program then permits the execution of external commands, there is the potential for the user calling
sudoto execute arbitrary commands as root. For this reason,
sudoshould only be used by trusted users, and with great caution.
Beware of software bearing trojans
Watch out for trojans! There is a reason why root shouldn't normally have single dots (.) anywhere in his or her path. This helps avoid the danger of having a trojan program like
lssitting in a directory waiting for the superuser to come looking to see what's there. Some distributions still allow single dots in the superuser path. Some distributions have different paths for when you log in as root and when you
suto superuser. If a single dot is in the path for either root login or for
suto superuser, it should be removed. While its removal isn't a foolproof preventative against trojans, it does help reduce that danger.
Trojans are also a serious concern for normal users when it comes to any application that prompts for a password, such as
su(since ordinary users can
suto any other username to which they have access). Programs that prompt for a password should only be executed as an absolute path to the binary. One way to encourage this is to insert
alias su /bin/suinto the files
bashusers will automatically use the absolute path.
Use the groups, Luke
Often, jobs that need root access could be done just as well and more securely through the proper use of group ownerships and secondary group membership. It takes more time to set this up properly, but once it's done right, it more effectively protects system security while granting the access required by normal users.
It's very easy and convenient when there are only one or two users on a system to simply perform all maintenance tasks by stepping up to root. But once you have a lot of users and wish to delegate the authority for various tasks to different users, it becomes impractical and dangerous to allow superuser access to everyone performing maintenance. It's well worth the effort to implement an effective group membership configuration when the system is simple, before you really need it -- or before it's too late.
- Cryptography and security
Cryptography is a good thing. It can protect our files, our e-mail, and our communications. Widespread use of cryptography will improve and change the security landscape. Take advantage of cryptography wherever its use is appropriate.
With any cryptographic system, the key is the key. The security of your cryptography depends on the security of your key. That can be a private key stored on a system, or a password, or a smart card key. If you decide on a crypto system to guard your security, your problems aren't solved, they've merely changed. Now, instead of guarding your front door, you must guard the keys to the lock on the door.
SSL began its career securing Web servers for e-commerce, and has since been applied to FTP and
telnet, as well as to POP and IMAP e-mail services. In addition to simple remote shells and secure copying,
sshis capable of forwarding many services and even tunneling PPP to provide a form of VPN service. Several remote services, such as
rdist, can take advantage of
sshto secure their underlying communications.
If you want to protect your e-mail, your open source choices are PGP and S/MIME (there are, additionally, several proprietary schemes). Both PGP and S/MIME have advantages and disadvantages, and both have interoperability problems and usability problems. When was the last time you checked the validity of a PGP signature? The "web of trust" model of PGP distributes well, but transitive trust (I trust Sue and Sue trusts Adam but do I trust Adam?) doesn't scale well. The "authority" model of S/MIME has its own scaling problems. Additionally, S/MIME has an annoying infrastructure (and some would say, tax) associated with it.
If you want to protect the files on your system, there are several cryptographic filesystems available for Linux, including Matt Blaze's CFS (Crytographic File System). These help secure your files. But on a multiuser system, you still must watch out for trojan password traps and sniffers. Your filesystem encryption is only as secure as the passwords you use to access it.
The FreeS/WAN project is developing IPSec for Linux. This is now available for both 2.0 kernels and 2.2 kernels, and it interoperates with many other IPSec implementations. For encrypting VPNs and private connections, this is the way to go. To connect gateways between two or more widely dispersed networks, this is the tool to use. Running host to host, however, it is very cumbersome and it will not operate over IP masquerading firewalls or gateways. Further, it isn't trivial to install, and you must guard your keys religiously.
Don't be lulled into a false sense of (encrypted) security
The tools mentioned here enhance the security of communications, but may or may not improve overall system security. If someone cracks a password by brute force, they're just as free to use the secure channels of access as are authorized users. A recently well-publicized break-in at RootShell was done through
ssh. The problem wasn't a vulnerability of
ssh-- the attackers had obtained the root password through other means and had simply connected in as if they belonged there.
For these reasons, even IPSec isn't the end-all, be-all of security on the Internet. It may eliminate spoofing or certain types of passive sniffing attacks, but it won't stop brute force attacks or protocol attacks. Your e-mail may not be sniffable any longer, but it can still be read if someone compromises and gains access to your system. Your credit card number won't necessarily be sniffed while it's traveling along the wire on its way to an insecure Web server -- but most credit card theft is the result of intruder access to the insecure server itself, not sniffing.
- Eternal vigilance
Once you've secured your installation and checked your basic security and services, your work isn't over. In fact, the job of keeping your system secure is never over. Even if with eternal vigilance, someone, sometime, is likely to get in. With or without the help of any one of a number of monitoring programs, you must keep a watchful eye on what is going on in your system.
If you can't block 'em, catch 'em!
Enable the firewalling code, even on single systems, and block everything that you don't understand or specifically want on your system. This can put a serious crimp in some rootkit backdoors.
Watch out for unusual suid programs.
findcan be used to locate all of the suid binaries, which can then be tracked for changes or additions.
Scan that system!
Run a network security scanner on your system! SATAN is one such scanner. Nessus is an excellent open source scanner, as is Trinux. Trinux is a tiny distribution that can boot from floppy disks and scan your network. Internet Security Systems also produces a commercial security scanner. Internet Scanner is free to download and run against your local host. Even if you don't intend to purchase Internet Scanner, or can't afford it (it can be a bit expensive), I would encourage you to get the local host evaluation copy and run it on your system (it's fully functional).
Install an intrusion-detection system. These vary greatly from package to package, and there are commercial and open source versions of most types. Some are host-based systems, monitoring for unauthorized changes to files; others monitor the network or network interfaces for suspicious activities.
Check out Tripwire. Tripwire can alert you to modified binaries and permissions. There are commercial variations of this application, including a commercially marketed and supported version of Tripwire itself. Some of the other systems are more extensive than Tripwire, some are not.
There are log-monitoring packages available from several of the security sites listed in the Resources section at the end of this article. Log monitors trigger on suspicious activity, such as repeated failed login attempts in security logs. The application can send e-mail to the system administrator or even activate a pager to inform the administrator of an attack in progress. Some are capable of performing even more drastic action, as we'll see in Part 2 of this series.
- Stay informed
New security holes and bugs are discovered and exploited constantly, and new techniques, patches, and fixes are created to counter the threat they present. The only way to safeguard the system you've worked so hard to secure is to stay on top of new information as it becomes available.
Stay on top of software updates
Subscribe to the mailing lists provided by the Linux distribution vendors to provide announcements of updates or alerts. Monitor the vendor Web sites for errata and updates.
Know thine enemy
Browse through the various "white hat hacker" sites and get a feel for some of the recent danger points. RootShell and L0pht (both listed in the Resources section) are good places to start. There are also some Linux security sites out there.
Warning! Some companies and ISPs take offense at users having "cracker tools" such as
crack, or any of a variety of sniffing and scanning tools (available from the various white hat hacker sites, among others) on their systems. These tools can be useful if you run them against your own system to find security holes before a potential intruder does. But f you aren't an administrator on a system, make sure you have permission to possess these items and that the administrator is aware of them. Some people consider the possession of lockpicks to be no different than the possession of burglar tools. If you have tools for cracking passwords or breaking into systems, you may be setting yourself up to answer some very intense questions. Some ISPs don't even ask questions first. Providers have been known to cancel accounts merely for the possession of cracking tools. Don't take the chance. Don't even download these tools if you don't have your administrator's permission!
Additional resources: Where they are, what they're for
Poke around the public databases. Internet Security Systems (where I work) has several, and we also link to outside sites.
Get on some security mailing lists, such as Linux-security or BugTraq.
You can find the addresses and subscription information -- and recommended sites for further reading -- in the Resources section.
- Up and running
The enemy within is ignorance
While advanced security can be difficult to implement, a great deal can be achieved by taking the simple steps of knowing what you're running and disabling services you aren't sure about. Even small sites and single Linux systems can take steps to reduce the risk and harden their security protection. Not all of these ideas are ideal for all circumstances. You have to understand and balance your security needs, your network design, your functionality needs, and your security policy (if you have one). In any case, knowledge is your best security tool and ignorance is your worst enemy. Use our comprehensive list of Resources for even more information, and to stay abreast of developments.
About the author
Mike Warfield is a senior security researcher on the Internet Security Systems X-Force. He is also a member of the Samba Development Team, a founding member of the Atlanta Linux Enthusiasts, and a long-standing guru with the Atlanta Unix Users Group. He has been involved in Unix systems for over 15 years and with computer security for over 25 years.
- Read Michael Warfield's previous On the Ramparts columns in the LinuxWorld archives:
(Most of the sites listed below feature additional security resources and links.)
- North American Cryptographic Archives:
- Psionic Software / Abacus Sentry:
- L0pht Heavy Industries:
- Deception Toolkit:
- "Securing Your Linux Box," Peter Vertes (Linux Gazette, Issue 34, November 1998):
- Wietse Venema's collected tools and papers:
- Solar Designer's Secure-Linux Patch:
- Internet Security Systems:
- CERT Security Improvement modules:
- CIAC (Computer Incident Advisory Capability):
- BugTraq: firstname.lastname@example.org
- Linux-Security: email@example.com
- Linux Administrator's Security Guide (LASG):