|
|
| On the Ramparts |
Securing Linux, Part 1Elementary security for your Linux boxSummaryBy Michael H. Warfield |
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.
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.allow file to allow localhost
only, and set the /etc/hosts.deny file 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.
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.
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!
/etc/hosts.accept and
/etc/hosts.deny configurations 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!
E-mail security
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).
IRC is one common example of a chat system -- many other chat systems also work with Web servers. If you have any kind of chat server running on your system, make sure common users can't insert arbitrary HTML (hostile JavaScript anyone?) into pages where your Web server can serve them up.
Securing FTP
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 telnet, rlogin, or rsh
to access your system remotely -- Why?!?!? These are
seriously insecure and allow passwords and userids to be
"sniffed."
For remote access, use secure shell (
Tracking down services
If you run it, they will come
Find out who's listening to what
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
Keep up with the times
Good passwords
Proceed with caution before implementing this next bit of advice:
To ensure that you're not using transparent passwords, you
can run the program
Warning! Some companies and ISPs take offense at users having
"cracker tools" such as
Password handling
Additional password security
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.
Don't run as root
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
As with any security tool,
Even some programs that expect to be run only as root can become
a security hole under
Beware of software bearing trojans
Trojans are also a serious concern for normal users when it
comes to any application that prompts for a password, such as
Use the groups, Luke
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.
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.
Encrypted 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.
Encrypted files
FreeS/WAN
Don't be lulled into a false sense of (encrypted) security
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.
If you can't block 'em, catch 'em!
Watch out for unusual suid programs.
Scan that system!
Burglar alarms
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 on top of software updates
Know thine enemy
Warning! Some companies and ISPs take offense at users having
"cracker tools" such as
Additional resources: Where they are, what they're for
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.
ssh) connections and
disable all nonencrypted remote access to the server. The ssh isn'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 ssh and PGP in the base distributions and
installations.
finger is often configured and available on
default installations. Unless you have a specific need for this service,
disable it or restrict network access to it. finger provides 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.
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.
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.
Examine /etc/inetd.conf and 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 echo,
chargen, or 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 inetd services, you don't need to
run the inetd at all.
Run nstat -a and look for any unusual ports or services. If
you see a TCP port in the state of LISTEN and you can't identify the
local port or service, track it down and decide if it's something
you really want to be running.
lsof
package to track it down.
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 imapd servers,
even when updates had been available for months.
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.
crack on your own password system.
Running crack on 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!
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.
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.
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.
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!
The program sudo is 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 sudo
you avoid the overuse of suid.
sudo should 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 sudo more 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.
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 sudo to execute arbitrary commands as root. For this
reason, sudo should only be used by trusted users, and with
great caution.
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 ls sitting 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 su to superuser. If a single dot
is in the path for either root login or for su to superuser, it
should be removed. While its removal isn't a foolproof
preventative against trojans, it does help reduce that
danger.
su (since ordinary users can su to
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/su into
the files /etc/profile and /etc/bashrc
so that bash users will automatically use the absolute path.
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.
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.
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,
ssh is capable of forwarding many services and even tunneling PPP to provide a
form of VPN service. Several remote services, such as cvs,
rsync, and rdist, can take advantage of ssh
to secure their underlying communications.
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.
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.
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.
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.
find can be used to
locate all of the suid binaries, which can then be tracked for
changes or additions.
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.
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.
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.
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.
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!
Poke around the public databases. Internet Security Systems
(where I work) has several, and we also link to outside sites.
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.
Resources
URL: http://www.linuxworld.comlw-05-ramparts_p.html
(c) 1999 LinuxWorld, published by Web Publishing Inc.