Table of Contents
1. Introduction
1.1 New Versions of this Document
1.2 Feedback
1.3 Disclaimer
1.4 Copyright Information
2. Overview
2.1 Organization of This Document
2.2 Host Security
2.3 Network Security
2.4 Security Through Obscurity
2.5 Why Do We Need Security?
2.6 How Vulnerable Are We?
2.7 How Secure Is Secure?
2.8 What Are You Trying to Protect?
2.9 Developing A Security Policy
2.10 Means of Securing Your Site
2.11 Temporary Changes
3. Network Security
3.1 Windows Networking
3.2 Identify Gateway Machines
3.3 Network Monitoring
3.4 Network Configuration Files
3.5 Check for Poor Topology Configuration
3.6 Disable Unnecessary and Unauthorized Services
3.7 Monitoring Network Services with TCP Wrappers
3.8 Running Services in a
3.9 Domain Name Service (DNS) Security
3.10 Network File System (NFS) Security
3.11 Network Information Service (NIS)
3.12 File Transport Protocol (FTP)
3.13 Simple Mail Transport Protocol (SMTP)
4. Host Security
4.1 Delete Unnecessary Packages
4.2 Default System Configuration
4.3 Make a Full Backup of Your Machine
4.4 Backup Your Red Hat or Debian File Database
4.5 Make Use of Your System Accounting Data
4.6 Apply All New System Updates
4.7 Creating New Accounts
4.8 Root Security
4.9 Workstations and DialUp Security
4.10 X11, SVGA and display security
4.10.1 X11
4.10.2 SVGA
4.10.3 GGI (Generic Graphics Interface project)
4.11 identd
5. User, System, and Process Accounting
5.1 Using Syslog
5.1.1 Storing Log Data Securely
5.2 Using User Accounting
5.3 Using Process Accounting
5.4 Managing User Accounts
6. Physical Security
6.1 Computer Locks
6.2 BIOS Security
6.3 Boot Loader Security
6.4 xlock and vlock
7. Intrusion Detection
7.1 What is Intrusion Detection?
7.2 General Indications of Intrusion
7.2.1 User Indications
7.2.2 System Indications
7.2.3 File System Indications
7.2.4 Network Indications
7.3 General Methods for Detecting Intrusions
7.4 Intrusion Detection Tools
7.4.1 Host Based Detection Tools
7.5 Integrity Checking
7.6 Using
7.7 Using The Red Hat Package Mangaer
7.8 File System Guidelines
7.9 Physical Intrusion Detection
7.10 Packet Sniffers
8. Files and File System Security
8.1 File Permissions and Ownership
8.1.1 Set User Identification Attribute
8.1.2 Set Group Identification Attribute
8.2 Directory Permissions and Ownership
8.2.1 Save Text Attribute (Sticky Bit)
8.2.2 Set Group Identification Attribute
8.3 Changing File and Directory Permissions
8.3.1 Changing File Permissions Using Octal Values (Absolute Mode)
8.3.2 Changing Directory Permissions Using Octal Values (Absolute Mode)
8.3.3 Changing Permissions Using Symbols (Symbolic Mode)
8.4 Changing File Ownership
8.5 Changing Group Ownership
8.6 Umask Settings
8.7 Monitoring Files with Special Permissions
8.8 General Guidelines
9. Data Encryption, Cryptography and Authentication
9.1 Password Security
9.2 PGP and Public Key Cryptography
9.3 SSL, S-HTTP, HTTPS and S/MIME
9.4 IPSec and S/WAN and other IP Encryption Implementations
9.5 The Secure Shell and Secure Telnet
9.6 SKIP - Simple Key management for Internet Protocols
9.7 PAM - Pluggable Authentication Modules
9.8 Cryptographic IP Encapsulation (CIPE)
9.9 Kerberos
9.10 Shadow Passwords.
9.11 Crack and John the Ripper
9.12 Cryptography and File Systems
10. Kernel Security
10.1 Securing Hosts with Many Users
10.2 Securelevel, Capabilities and Linux-Privs
10.3 Kernel Compile Options
10.4 Kernel Devices
11. Exploits
11.1 Worm Attacks
11.2 Trojan Horse Programs
11.3 Cracking Attacks
11.4 Direct Physical Access
11.5 Spoofing
11.6 Denial of Service Attacks
11.7 Program Code Exploits
11.8 Misconfigured Services
11.9 Known Vulnerabilities
11.10 WWW and CGI-BIN attacks
12. Firewalls and Border Patrol
12.1 Introduction
12.2 General Documentation
12.3 The Firewall Toolkit
12.4 Packet Filtering and Accounting
12.5 Linux Firewall Tools
12.6 Proxy Servers
12.7 Masquerading and Address Translation
13. Writing Secure Code
13.1 Preventing
13.1.1 Introduction
13.1.2 Discussion
13.1.3 Solutions
13.2 References
13.3 Preventing Buffer Overflows
14. Incident Response: Before, During, and After
14.1 Preparation
14.2 Detection
14.3 Containment
14.4 Eradication
14.5 Restoration
14.6 Follow Up
14.7 Additional Information
15. Security Sources and Tools
15.1 Network Scanners and Auditing Tools
15.1.1 Security Administrators Tool for Analyzing Networks (SATAN)
15.1.2 Security Administrator's Integrated Network Tool (SAINT)
15.1.3 Rhino9 Auditing Tool
15.1.4 Internet Security Scanner (ISS) and System Security Scanner (S3)
15.1.5 Abacus-Sentry
15.2 The Art of Port Scanning
15.2.1 Detecting Port Scans
15.3 Incident Response Contacts
15.4 Vendor Information
15.5 Mailing Lists
15.6 General References
15.7 Books - Printed Reading Material (Works Referenced)
16. Glossary
17. Frequently Asked Questions
17.1 Is Linux a secure Operating System?
17.2 Loadable modules versus compiled kernel?
17.3 How can I securely use the Apache Front Page Extensions?
17.4 How do I know whether my machine is secure?
17.5 What are the arguments for
17.6 Where do I find the most secure version of program XYZ?
17.7 Logging in as root from a remote machine always fails.
17.8 How do I enable shadow passwords?
17.9 How can I enable the Apache SSL extensions?
17.10 How can I securely manipulate user accounts?
17.11 How can I password protect specific HTML documents?
17.12 My Set-User-ID shell script does not work!
18. Conclusion
19. Thanks To
______________________________________________________________________
1. Introduction
This document covers the major security issues that affect Linux
security. General philosophy and net born resources are also
discussed.
A number of other HOWTO documents overlap with security issues, and
those have been pointed to wherever appropriate.
This document is NOT meant to be a up to date exploits document. Large
numbers of new exploits happen all the time. This document will point
you where to look for such up to date information, and some general
methods to prevent such exploits from taking place.
Additionally, while there are several resources available in various
places on the Internet regarding general security, we are trying to
consolidate much of this general information, and provide information
a general system administrator can use as a practical guide. This
should in no means substitute for reading books on the appropriate
subject, and practical experience which works for you.
The US Government has several organizations devoted to computer
security, and generally the information they have online is quite
extensive, and very useful. A general introduction to computer
security is available at http://csrc.ncsl.nist.gov/nistpubs/800-12/
which will be very useful.
See the References section for pointers to security references. It is
also a tremendous advantage if you understand how TCP/IP works, and
some of the common system administration functions. You might find
this guide helpful in a beginner introduction
http://www.sunworld.com/sunworldonline/swol-11-1995/swol-11-sysadmin.html
While it is Solaris-centric, you'll find much of this information
general enough to still be applicable.
You may also find this link helpful http://www.cis.ohio-
state.edu/~dolske/gradwork/cis694q/ for another introduction to TCP,
including how sequence numbers work, which is the foundation of ``man
in the middle'' attacks, a description of the SYN/ACK handshake used
to initiate a TCP connection, a description of a few of the problems
in TCP/IP, a few other types of attacks, and how they work, as well as
some solutions to these problems.
1.1. New Versions of this Document
New versions of this document will be periodically posted to
comp.os.linux.answers. They will also be added to the various
anonymous FTP sites who archive such information, including:
ftp://sunsite.unc.edu/pub/Linux/docs/HOWTO
In addition, you should generally be able to find this document on the
Linux Documentation Project Web home page via:
Finally, the very latest version of this document should also be
available in various formats from either of the following:
http://nic.com/~dave/Security/
1.2. Feedback
All comments, error reports, additional information and criticism of
all sorts should be directed to:
1.3. Disclaimer
No liability for the contents of this documents can be accepted. Use
the concepts, examples and other content at your own risk.
Additionally, this is an early version, with many possibilities for
inaccuracies and errors. It is provided "as is" without express or
implied warranty.
Many of the examples and descriptions in this document refer
specifically to the Red Hat distribution. We are very interested in
incorporating other distributions as well. If you have ideas on how
other distributions perform the same measures as are listed here, we
would be interested in hearing from you.
1.4. Copyright Information
This document is copyrighted (c)1998 Dave Wreski, and distributed
under the following terms:
o This document may be reproduced and distributed in whole or in
part, in any medium physical or electronic, as long as this
copyright notice is retained on all copies. Commercial
redistribution is allowed and encouraged; however, the authors
would like to be notified of any such distributions.
o All translations, derivative works, or aggregate works
incorporating any Linux documents must be covered under this
copyright notice. That is, you may not produce a derivative work
from this document and impose additional restrictions on its
distribution. Exceptions to these rules may be granted under
certain conditions; please contact the author of this document for
further information.
2. Overview
This document will discuss procedures and commonly used software to
increase the trust level of your system. It is important to discuss
the basic concepts first, and create a security foundation before we
get started.
2.1. Organization of This Document
This document has been dividedinto a number of sections. They cover
several broad kinds of security issues. So far these sections
include:
o Physical Security - covers how you need to protect your physical
machine from tampering.
o Files and File System Security - shows you how to setup your file-
systems and permissions on your files.
o Data Encryption, Cryptography and Authentication - discusses how to
use encryption to better secure your machine and network.
o Kernel Security - discusses what you can do at the kernel level to
protect yourself, as well as improve security.
o Network Security - describes how to better secure your Linux system
from network attacks.
o Incident Control - discusses the six stages in dealing with an
incident, including the preperation before one actually occurs.
o Host Security - discusses what can be done to further secure
individual hosts, and what to watch out for.
o Exploits - attempts to familiarize the reader with some of the most
common types of exploits, so you know when and how to recognize one
when it does happen.
o Security Sources - Here is a list of the resources that are most
usable to a Linux Security Administrator.
o Firewalls and Border Patrol - discusses the various types of
firewalls available for Linux, as well as pointers to general
firewall information.
o Glossary - Here is a list of the most frequently used acronyms and
definitions that a Security Administrator should be aware of to be
effective.
o Frequently Asked Questions - These FAQs should help to reduce some
of the more frequently encountered problems.
The two main points to realize when reading this document are:
o Be aware of your system. Check system logs such as
/var/log/messages and keep an eye on your system, and
o Keep your system up to date by making sure you have installed the
current versions of software and have upgraded per security alerts,
or otherwise improved the security of any suspect programs. Just
doing this will help make your system markedly more secure.
2.2. Host Security
Perhaps the area of most concentration on security is done with host-
based security. This typically involves making sure your own system
is secure, and hoping everyone else on your network does the same.
Choosing good passwords, securing your services your hosts offer,
keeping good accounting records, and upgrading programs that have
known security exploits are among the things the local Security
Administrator is responsible for doing.
Although this is absolutely necessary, it can become a daunting task
once your network of machines becomes larger. It can be said that
host-based security does not scale. A host-based security exploit
must be repaired on each machine on your network, which requires
accessing each machine individually and applying the fix.
2.3. Network Security
Network security is as necessary as local host security. With your
single system, or a distributed computing network, the Internet, or
hundreds, if not thousands or more computers on the same network, you
can't rely on each one of those systems being secure. Making sure
authorized users are the only ones permitted to use your network
resources, building firewalls, using strong encryption, and ensuring
there are no rogue, or unsecured, machines on your network are all
part of the network security administrator's duties.
This document will discuss some of the techniques used to secure your
site, and hopefully show you some of the ways to prevent an intruder
from gaining access to what you are trying to protect.
2.4. Security Through Obscurity
One type of security that must be discussed is ``security through
obscurity''. This means that by doing something like changing the
login name from 'root' to 'toor', for example, to try and obscure
someone from breaking into your system as root may be thought of as a
false sense of security, and can result in very unpleasant and
unexpected consequences.
However, it can also be used to your benefit if done properly. If you
tell all the users who are authorized to use the root account on your
machines to use the root equivilent instead, entries in the
/var/log/secure for the real root user would surely indicate an
attempted break-in, giving you some advance notice. You'll have to
decide if this advantage outweighs the additional administration
overhead.
In most cases, though, any system attacker will quickly see through
such empty security measures. Simply because you may have a small
site, or relatively low profile does not mean an intruder won't be
interested in what you have. We'll discuss what your protecting in
the next sections.
2.5. Why Do We Need Security?
In the ever-changing world of global data communications, inexpensive
Internet connections, and fast-paced software development, security is
becoming more and more of an issue. Security is now a basic
requirement because global computing is inherently insecure. As your
data goes from point A to point B on the Internet, for example, it may
pass through several other points along the way, giving other users
the opportunity to intercept, and even alter, your data. Even other
users on your system may maliciously transform your data into
something you did not intend. Unauthorized access to your system may
be obtained by intruders, also known as ``crackers'', who then use
advanced knowledge to impersonate you, steal information from you, or
even deny you access to your own resources. If you're still wondering
what the difference is between a ``Hacker'' and a ``Cracker'', see
Eric Raymond's document, ``How to Become A Hacker'', available at
http://sagan.earthspace.net/~esr/faqs/hacker-howto.html.
2.6. How Vulnerable Are We?
While it is difficult to determine just how vulnerable a particular
system is, there are several indications we can use:
o The Computer Emergency Response Team consistently reports an
increase in computer vulnerabilities and exploits.
o TCP and UDP, the protocols that comprise the Internet, were not
written with security as their first priority when it was created
more than 30 years ago.
o A version of software on one host has the same vulnerabilities as
the same version of software on another host. Using this
information, an intruder can exploit multiple systems using the
same attack method.
o Many administrators don't even take simple security measures
necessary to protect their site, or don't understand the
ramifications of implementing some services. Many administrators
are not given the additional time necessary to integrate the
necessary security measures.
2.7. How Secure Is Secure?
First, keep in mind that no computer system can ever be ``completely
secure''. All you can do is make it increasingly difficult for someone
to compromise your system. For the average home Linux user, not much
is required to keep the casual cracker at bay. For high profile Linux
users (banks, telecommunications companies, etc), much more work is
required.
Another factor to take into account is that the more secure your
system is the more intrusive your security becomes. You need to decide
where in this balancing act your system is still usable and yet secure
for your purposes. For instance, you could require everyone dialing
into your system to use a call back modem to call them back at their
home number. This is more secure, but if someone is not at home, it
makes it difficult for them to login. You could also setup your Linux
system with no network or connection to the Internet, but this makes
it harder to surf the web.
If you have more than one person logging on to your machine, or
machines, you should establish a ``Security Policy'' stating how much
security is required by your site and what auditing is in place to
check it. You can find a well-known security policy example at
http://ds.internic.net/rfc/rfc2196.txt. It has been recently updated,
and contains a great framework for establishing a security policy for
your company.
It is even advisable to generate a security policy for systems with
just two users, or even a desktop machine, used for normal Internet
dialup access.
While developing your security policy, you will have to decide on that
balance between security and ease-of-use. You will also need to
determine the current level of security on your systems. Ask yourself
questions such as these:
o How often do you change your passwords?
o How would you improve security?
o How many guessable passwords are there on your system?
o Do you have any intentional backdoors to your system?
Improving security at your site will have to be a progressive process
-- you can not secure your systems overnight, and most likely your
users will be reluctant to change, because they feel they will be
losing usability. Also, don't discount the possibility that there are
several packages and binaries on your system that are not even used,
and can be removed without affecting functionality, yet improving
security by limiting the available exploits.
2.8. What Are You Trying to Protect?
Before you attempt to secure your system, you should determine what
level of threat you have to protect against, what risks you should or
should not take, and how vulnerable your system is as a result. You
should analyze your system to know what you're protecting, why you're
protecting it, what value it has, and who has responsibility for your
data and other assets.
o Risk is the possibility that an intruder may be successful in
attempting to access your computer. Can an intruder read, write
files, or execute programs that could cause damage? Can they
delete critical data? Prevent you or your company from getting
important work done? Don't forget, someone gaining access to your
account, or your system, can also impersonate you.
Additionally, having one insecure account on your system can result
in your entire network being compromised. A single user that is
allowed to login using an rhosts file, or through the use of an
insecure service, increases the ability for the intruder using this
to ``get his foot in the door''. Once the intruder has even a
normal user account on your system, or someone else's system, the
likelihood it can be used to gain access to another system, or
another account is quite high.
o Threat is typically from someone with motivation to gain
unauthorized access to your network, or computer. You must decide
who you trust to have access to your system, and what threat they
could impose.
There are several types of intruders, and it is useful to keep the
different characteristics in mind as you are securing your systems.
o The Curious - This type of intruder is basically interested in
finding out what type of system and data, you have.
o The Malicious - This type of intruder is out to either bring down
your systems, or deface your web page, or otherwise cause you time
and money to recover.
o The High-Profile Intruder - This type of intruder is trying to use
your system to gain popularity and infamy. He might use your high-
profile system to advertise his abilities.
o The Competition - This type of intruder is interested in what data
you have on your system. It might be someone who thinks you have
something that could benefit him financially, or otherwise.
o Vulnerability - describes how well protected your computer is from
another network, and the potential for someone gaining unauthorized
access.
What's at stake if someone breaks into your system? How much is it
worth? When making the evaluation, you should consider items such
as computer hardware and software, intellectual property,
employee's, resources, such as network bandwidth, disk space, etc.
Of course the concerns of a dynamic PPP home user will be different
than those of a company connecting their machine to the Internet,
or another large network.
How much time would it take to retrieve/recreate any data that was
lost? An initial time investment now can save ten times more time
later if you have to recreate data that was lost. Have you checked
your backup strategy, and verified your data lately?
2.9. Developing A Security Policy
Create a simple, generic policy for your system that your users can
readily understand and follow. It should protect the data you're
safeguarding, as well as the privacy of the users. Some things to
consider adding are who has access to the system (Can my friend use my
account?), who's allowed to install software on the system, who owns
what data, disaster recovery, and appropriate use of the system.
A generally accepted security policy starts with the phrase:
"That which is not expressly permitted is prohibited"
This means that unless you grant access to a service for a user, that
user shouldn't be using that service until you do grant access. Make
sure the policies work on your regular user account, Saying, ``Ah, I
can't figure this permissions problem out, I'll just do it as root''
can lead to security holes that are very obvious, and even ones that
haven't been exploited yet.
Additionally, there are several questions you will need to answer to
successfully develop a security policy:
o What level of security do your users expect?
o How much is there to protect, and what is it worth?
o Can you afford the down-time of an intrusion?
o Should there be different levels of security for different groups?
o Do you trust your internal users?
o Have you found the balance between acceptable risk and secure?
You should develop a plan on who to contact when there is a security
problem that needs attention.
There are quite a few documents available on developing a Site
Security Policy. You can start with this one from Sun Microsystems
http://wwwwseast2.usec.sun.com/security/sec.policy.wp.html
2.10. Means of Securing Your Site
This document will discuss various means in which you can secure the
assets you have worked hard for: your local machine, data, users,
network, even your reputation. What would happen to your reputation
if an intruder deleted some of your user's data? Or defaced your web
site? Or published your company's corporate project plan for next
quarter? If you are planning a network installation, there are many
factors you must take into account before adding a single machine to
your network.
Even if you have a single dialup PPP account, or just a small site,
this does not mean intruders won't be interested in your systems.
Large, high profile sites are not the only targets, many intruders
simply want to exploit as many sites as possible, regardless of their
size. Additionally, they may use a security hole in your site to gain
access to other sites you're connected to.
Intruders have a lot of time on their hands, and can avoid guessing
how you've obscured your system just by trying all the possibilities.
There are also several reasons an intruder may be interested in your
systems, which we will discuss later.
See the Host Security and Network Security sections for further
information on steps to perform to secure your hosts.
2.11. Temporary Changes
Changes made for supposedly brief periods of time are also a great
security risk. Subverting your firewall so you can dial-in from home
to your workstation also allows an attacker to do the same. Also,
temporary changes easily become permanent, as we quickly forget about
such changes.
Remember, the weakest link in the security implementation is likely to
be exploited first.
3. Network Security
Network security is becoming more and more important as people spend
more and more time connected. Compromising network security is often
much easier than physical or local, and is much more common.
There are a number of good tools to assist with network security, and
more and more of them are shipping with Linux distributions.
3.1. Windows Networking
Most likely your network will also include Microsoft clients,
presumably using either NetBIOS or other inheriently insecure
networking protocols.
Among other things, NetBIOS is the protocol Microsoft uses to
publicize share names, user names, and host names within the network.
Disabling NetBIOS on any Windows workstations is a prudent idea, as is
blocking TCP and UDP ports 137 through 139 on your border routers or
firewalls.
A detailed discussion on the actual reasons for this insecurity is
available in a paper written by Hobbit, and can be found at his site
here http://avian.org:4687/web1/hak/cifs.txt
Unfortunately, disabling NetBIOS also will disable any Remote Access
Service it may be offering, as well as browsing (Network
Neighborhood). If you must retain your NT server on your network, you
may consider two NICs in the machine, one outbound via TCP/IP and one
internal only. Disable NetBIOS binding to the TCP/IP side. This keeps
enterprising folks from poking into the network via TCP/IP, then using
various NET commands to gather network information.
The hacker group called l0pht have written a utility similar to how
Crack works on UNIX, called l0phtcrack and is available at their site
http://www.l0pht.com as is other generally useful information.
The file security_level.txt, distributed with SAMBA, discusses the
various security levels that can be set using SAMBA, including
encrypted passwords, server security, share-level security, and user
security. It does a good job of explaining the general security
concerns you must deal with.
The security research group called Rhino9, have also put together in
depth information on the NetBIOS protocol and interface. You can find
it at http://207.98.195.250/texts/netbios.doc
Internet Security Systems also produces a document on Windows file
sharing security, and is available here
http://www.iss.net/vd/fileshare.html This document, titled File
Sharing: Unknown Dangers on Your Network, helps to describe some of
the security issues you should be aware of, and just how insecure
Windows 95 really is. It is a good overview, whereas Hobbit's
document is more of a low-level description at the protocol level.
3.2. Identify Gateway Machines
Special attention should be paid to gateway or firewall systems, as
they usually control access to the services running on the entire
network. Such gateways should be identified, its function within the
network shouild be assessed and owners or administrators should be
identified. These hosts, often referred to as ``bastion hosts'' are a
prime target for an intruder. They should be some of the most
fortified machines on the network.
Be sure to regularly review the current access policies and security
of the system itself.
These ``systems'' should absolutely only be running the services
necessary to perform it's operation. Your firewall should not be your
mail server, web server, contain user accounts, etc. Some of the
things you should check for, and absolutely fortify on these hosts
include:
o Turn off access to all but necessary services.
o Depending on the type of firewall, disable IP Forwarding,
preventing the system from routing packets unless absolutely
instructed to do so.
o Update machine by installing vendor patches immediately.
o Restrict network management utilities, such as SNMP, ``public''
communities, and write access.
o Be sure firewall policy includes mechanisms for preventing common
attacks such as IP Spoofing, Fragmentation attacks, Denial of
Service, etc.
o Monitor status very closely. You should develop a reference point
in which the machine normally operates to be able to detect
variations which may indicate an intrusion.
o Develop a comprehensive firewall model. Firewalls should be
treated as a security system, not just a program that runs on a
machine and has an access control list. Firewall administration
should be centrally controlled and evaluation of firewall policies
should be done prior to actual firewall deployment.
3.3. Network Monitoring
It is important to keep aware of the status of your network, so you
can not only detect when there is an intrusion, but when there is
abnormal system activity, such as system load, increased disk usage,
slower network, etc. There are many tools available for network
monitoring, most of which were developed on other platforms first,
then ported to Linux.
See the COAST archives, available at
http://www.cs.purdue.edu/coast/hotlist/ for network monitoring tools.
Matthew Franz mdfranz@txdirect.net has put together a Linux
distribution that runs on two or three floppies, and includes many of
the tools necessary to probe a network and the services it has
available. This sounds like a great method in which to test your
current security policy, as well as find otherwise unknown
vulnerabilities. You can find the latest version, as well as more
information, at http://www.txdirect.net/users/mdfranz/trinux.html
3.4. Network Configuration Files
Improperly configured network services and configuration files can
lead to a system lacking full control over its services. You can
configure your systems to be secure, yet still offer the services
necessary. As a general rule:
o Remove the /etc/hosts.equiv file. A properly configured system,
using TCP Wrappers, offers much better control over which hosts and
users are allowed access to the other machines on your network.
o Disable the use of $HOME/.rhosts files. By properly configuring
PAM, you can eliminate the risk of a user subverting system
security by allowing unauthorized access from a remote system via a
.rhosts file. This should be replaced by the functionally
equivilent SSH file called .shosts. If this is not possible,
Wietse Venema wrote a more secure rsh and rlogin daemon
replacement, available in the logdaemon package. You can find this
at ftp://ftp.win.tue.nl/pub/security/logdaemon-5.6.tar.gz
o Verify the /etc/exports configuration. Be sure if you are
exporting filesystems using NFS, be sure to configure /etc/exports
with the most restrictive access possible. This means not using
wildcards, not allowing root access, and exporting read-only
wherever possible. Verify who can mount these filesystems using
/usr/sbin/showmount -e localhost.
o Secure access to your console. Check the /etc/securetty file for
the list of tty's that root is permitted to login from. This
should only include the local tty's, and never including pseudo-
ttys (from a remote location). The absense of this file indicates
root is permitted to login from anywhere. Use /bin/su or sudo,
available at ftp://ftp.cs.colorado.edu/pub/sudo/
o Be sure to review your /etc/inetd.conf and see what services are
being offered by your inetd. Disable any that you do not need by
commenting them out (# at the beginning of the line), and then
sending your inetd process a SIGHUP. All services running from
inetd should be wrapped using TCP Wrappers.
o Disable all services such as the ``r-utilities'' including exec
(used by rsh, login (used by rlogin), and shell, (used by rcp)
should be disabled immediately from being started in
/etc/inetd.conf. These protocols are extremely insecure and have
been the cause of exploits in the past.
o Disable all unnecessary RPC services. Disable any non-essential
services that are registered with the portmapper. RPC services are
generally insecure, and have typically been replaced by newer forms
of an equivilent service. Use rpcinfo -p hostname to find the list
of RPC services running on hostname.
The best method of configuration here is to only enable the
services in which the box is intended to serve. Network-based
exploits are equally as common as other forms of exploits, and they
are performed by finding weaknesses in services, or poorly
configured services.
3.5. Check for Poor Topology Configuration
Poor network configurations can also lead to a very difficult
intrusion to track. Protecting the ``front door'' with a very well
configured firewall will not prevent someone from entering through the
``back door'' via the modem bank with poor authorization.
3.6. Disable Unnecessary and Unauthorized Services
Before you put your Linux system on ANY network the first thing to
look at is what services you need to offer. Services that you do not
need to offer should be disabled so that you have one less thing to
worry about and attackers have one less place to look for a hole.
You should check your /etc/rc.d/rcN.d, where N is your systems run
level and see if any of the servers started in that directory are not
needed. The files in /etc/rc.d/rcN.d are actually symbolic links to
the directory /etc/rc.d/init.d. Renaming the files in the init.d
directory has the effect of disabling all the symbolic links in
/etc/rc.d/rcN.d. If you only wish to disable a service for a
particular runlevel, rename the appropriate file with a lower-case
``s'', instead of the upper-case ``S'', such as in S45dhcpd.
If you have BSD style rc files, you will want to check /etc/rc* for
programs you don't need. The Red Hat distribution includes tksysv, a
graphical program to change what runlevel a particular server runs in.
The newer distributions also include linuxconf, which can also do
this.
Additionally, machines on your network running unauthorized services
can create an opportunity for a cracker to gain access to the system.
Regular port scanning of your machines, as well as running network
security scanning tools, can help to find these potential exploits
before an intruder does.
3.7. Monitoring Network Services with TCP Wrappers
Most Linux distributions ship with tcp_wrappers ``wrapping'' all your
TCP services. A tcp_wrapper (known as /usr/sbin/tcpd) is invoked from
/sbin/inetd instead of the real service, such as telnet or ftp. tcpd
then checks the host that is requesting the service and either
executes the real server or denies access from that host. tcpd allows
you to restrict access to your tcp services. You should make a
/etc/hosts.allow and add in only those hosts that need to have access
to your machines services.
By making simple changes to the inetd configuration file,
/etc/inetd.conf you can monitor and control incoming requests to
network services. Such a modification might look like the following:
Typical
telnet stream tcp nowait root /usr/sbin/in.telnetd
TCP Wrappers
telnet stream tcp nowait root /usr/sbin/tcp /usr/etc/in.telnetd
In default mode the wrappers report the name of the client host and of
the requested service. Be sure you have syslogd configure properly to
ensure correct logging.
As no information is exchanged between the wrappers and the client or
server applications there is no overhead on the actual conversation
between the client and server applications occurs.
Additionally, you can configure:
o Access control to restrict what systems can connect to what network
daemons.
o Client user name lookups with the RFC 931 (ident) protocol.
o Additional protection against hosts that pretend to have someone
else's host name.
o Additional protection against hosts that pretend to have someone
else's host address.
o Notification upon usage of specific services, such as may be used
to set trap doors for attempted intrusion.
3.8. Running Services in a chroot Environment
Several network services can now be configured to run in a restricted
environment, called a ``chroot jail''. This is an isolated
environment seperated from the ``real'' operating system. Services
such as Apache or bind can be operated in this environment. A special
root directory is created, with a complete installation of all
programs and libraries necessary to execute the service. The intention
is to prevent someone from obtaining root privilege on the ``real''
operating system, due to a bug in the service that is operating in the
chroot jail.
This should not be treated as a panacea, however. It may help to
restrict a process' filesystem access, but it doesn't affect its
ability to make privileged system calls (e.g. init_module, modify_ldt,
bind to a priviliged port, etc.) So ultimately a root process can
break out of a chroot environment; it just makes the necessary
shellcode more involved than just ``exec("/bin/sh")''. You can find
more information on it's advantages and disadvantages at
http://www.ssc.com/lg/issue30/tag_chroot.html This isn't explicitly a
chroot discussion, but is helpful, nevertheless.
3.9. Domain Name Service (DNS) Security
Keeping up-to-date DNS information about all hosts on your network can
help to increase security. In the event of an unauthorized host
becomes connected to your network, you can recognize it by its lack of
a DNS entry. Many services can be configured to not accept
connections from hosts that do not have valid DNS entries.
Descriptive hostnames are just as useful to attackers as they are to
internal users. Host names such as ``firewall.mydomain.com'' is
obvious to an attacker, as is ``ns.mydomain.com''. These are likely
to be prime targets to an attacker. A machine named
``fred.mydomain.com'' likely indicates a normal user's PC, which is
also least likely to have an updated security mechanism installed,
making it also a prime target.
Keep conscious of possible DNS spoofing. You can find more
information on this in the Exploits section of this document.
Further information on securing DNS can be obtained from
http://www.psionic.com/papers/dns-linux.html
Cricket Liu and Paul Albitz, the authors of the famed DNS and BIND
O'Reilly book, contributed an article on Sun World with hints on how
to secure DNS. You can find it, as well as some other excellent
general security information at
http://www.sunworld.com/swol-11-1997/swol-11-bind.html which discusses
information on how to prevent being DNS spoofed.
Additonally, BIND can now successfully be run in a chroot()
environment. John A. Martin has put together a set of
Red Hat packages that can be used to install BIND in a chroot jail.
You can find more information on this available at
ftp://ftp.tux.org/pub/tux/jam/
Be sure to configure a separate user for BIND. This not only
restricts the amount of damage an intruder can do after exploiting a
security hole in BIND, but also allows administration of the zone
files without having to be root. This is generally a good practice,
and more packages are configured for doing this more easily than
before possible.
3.10. Network File System (NFS) Security
NFS is a very widely used file sharing protocol. It allows servers
running nfsd(8) and mountd(8) to ``export'' entire filesystems to
other machines with nfs filesystem support built-in to their kernels
(or some other client support if they are non Linux machines).
mountd(8) keeps track of mounted filesystems in /etc/mtab, and can
display them with showmount(8).
Many sites use NFS to serve home directories to users, so that no
matter what machine in the cluster they login to, they will have all
their home files.
There is some small amount of ``security'' allowed in exporting
filesystems. You can make your nfsd map the remote root user (uid=0)
to the nobody user, denying them total access to the files exported.
However, since individual users have access to their own (or at least
the same uid) files, the remote superuser can login or su to their
account and have total access to their files. This is only a small
hindrance to an attacker that has access to mount your remote
filesystems.
If you must use NFS, make sure you export to only those machines that
you really need to export only. Never export your entire root
directory, export only directories you need to export and export read-
only wherever possible.
Filter TCP port 111, UDP port 111 (portmapper), TCP port 2049, and UDP
port 2049 (nfsd) on your firewall or gateway to prevent external
access.
The NFS HOWTO also discusses some of the security issues with NFS, and
it is available at http://sunsite.unc.edu/LDP/HOWTO/NFS-HOWTO.html for
more information on NFS.
3.11. Network Information Service (NIS)
Network Information service (formerly YP) is a means of distributing
information to a group of machines. The NIS master holds the
information tables and converts them into NIS map files. These maps
are then served over the network, allowing NIS client machines to get
login, password, home directory and shell information (all the
information in a standard /etc/passwd file), among other information.
NIS is not at all secure. It was never meant to be. It was meant to be
handy and useful. Not only was it not intended to be secure, it also
has characteristics which inherently make it insecure. Among these
are:
o Lack of access control for contents of NIS maps
o Negation of password shadowing
o Rogue servers acting as authentic ones
Anyone that can guess the name of your NIS domain (anywhere on the
net) can get a copy of your passwd file, and use Crack against your
users passwords.
If you must use NIS, make sure you are aware of the dangers.
Control the use of /etc/netgroup file for NIS systems. Explicitly
define which hosts and which users can connect from a known list of
machines.
There is a much more secure replacement for NIS, called NIS+. Check
out the NIS HOWTO for more information, available at
http://sunsite.unc.edu/LDP/HOWTO/NIS-HOWTO.html
3.12. File Transport Protocol (FTP)
The Washington University FTP server is the default server on Linux
distributions. It has the ability to run in a chroot environment,
thus (theoretically) protecting the real root environment, limiting
the damage an exploit can do.
FTP sites are easily misconfigured, and doing so can lead to a false
sense of security, as well as easily exploitable holes. Attackers can
use a misconfigured site to transfer pirate software, gain remote
access, corrupt downloadable files, cause a denial of service, among
other misuses.
Be sure to disable FTP entirely if you don't have any reason to leave
it enabled (such as replacing it with ssh) and definately enable
quotas on the FTP filesystem. Additionally, disable anonymous FTP
access if it is not necessary.
3.13. Simple Mail Transport Protocol (SMTP)
One of the most important services you can provide is a mail server.
Unfortunately, it is also one of the most vulnerable to attack, simply
due to the number of tasks it must perform and the privileges it
typically needs.
If you are using sendmail, it is very important to keep up on current
versions. Sendmail has a long long history of security exploits.
Always make sure you are running the most recent version.
http://www.sendmail.org
An alternative to sendmail is qmail, which alledges to be more secure,
and easier to configure. qmail was designed with security in mind
from the ground up. It's reported that it's fast, stable and secure.
You can find it at http://www.qmail.org
Wietse Venema is writing a mail server that is
still in testing stages, but also promotes improved security. You can
find out more about vmail at http://www.vmailer.org
Significant improvements in preventing unsolicited bulk email (spam)
have been made with recent versions of the available SMTP servers.
Starting with sendmail-8.9, anti-relaying is enabled by default, which
prevents a remote host from using your network and mail servers for
forwarding mail to other hosts. Additional filters are also available
for preventing spam.
4. Host Security
The next thing to take a look at is the security in your system
against attacks from local users. Did we just say local users? Yes!
Getting access to a local user is one of the first things that system
intruders attempt, while on their way to exploiting the root account.
With lax local security, they can then ``upgrade'' their normal user
access to root access using a variety of bugs and poorly setup local
services. If you make sure your local security is tight, then the
intruder will have another hurdle to jump.
Local users can also cause a lot of havoc with your system even
(especially) if they really are who they say they are. Providing
accounts to people you don't know or have no contact information for
is a very bad idea.
4.1. Delete Unnecessary Packages
If you know you are not going to use some particular package, you can
also delete it entirely. /bin/rpm -e under the Red Hat
distribution will erase an entire package. Under debian /bin/dpkg
likely does the same thing.
If you are configuring a new machine to be installed on the network,
only initially install the packages that are necessary for its normal
operation.
Removing unnecessary setuid and setgid binaries should be a priority.
You should always be aware of which ones are available on your system.
You can do this using the following:
user@myhost$ find / -type f -perm +6000
This will find all the setuid and setgid binaries on your system. You
can find more about the setuid and setgid permissions in the File
System Security section.
4.2. Default System Configuration
The default Linux system installation is generally far more secure
than other operating systems, due to not having to conform to older
standards and traditions.
However, installing any operating system, and connecting it to the
network is a foolish idea. Many system defaults are still more
lenient than is intended to be used in a production network system.
Spend some time to customize it to your environment. Be sure to
follow these guidelines, as well as the ones refered to herein,
including disabling any services that are not necessary, configuring
auditing, etc, before connecting a machine to the network.
4.3. Make a Full Backup of Your Machine
Discussion of backup methods and storage is beyond the scope of this
document, but a few words relating to backups and security:
If you have less than 650Mb of data to store on a partition, a CD-R
copy of your data is a good way to go (as it's hard to tamper with
later, and if stored properly can last a long time). Tapes and other
re-writable media should be write protected as soon as your backup is
complete and verified to prevent tampering. Make sure you store your
backups in a secure off line area. A good backup will ensure that you
have a known good point to restore your system from.
A six-tape cycle is an easy one to maintain. This includes four tapes
for during the week, one tape for even Friday's, and one tape for odd
Friday's. Perform an incremental backup every day, and a full backup
on the appropriate Friday tape. If you make some particular important
changes or add some important data to your system, a backup might well
be in order.
4.4. Backup Your Red Hat or Debian File Database
In the event of an intrusion, you can use your RPM database like you
would use tripwire, but only if you can be sure it too hasn't been
modified. You should copy the RPM database and /bin/rpm executable to
a floppy or Zip disk, and keep this copy off-line at all times. The
Debian distribution likely has something similar. (Would someone fill
me in here, until I get Debian re-installed?) See the section on
Integrity Checking for further information, and instructions on how to
do this.
4.5. Make Use of Your System Accounting Data
It is very important that the information that comes from your system
accounting files has not been compromised, and is installed and
configured properly. Making the files in /var/log, /var/run/utmp, and
/var/log/wtmp readable, and writable only by the root user is a good
start. Knowing which tools to use at what times is a good practice.
You can find more information on this in the User and System
Accounting section.
4.6. Apply All New System Updates
Most Linux users install from a CDROM. Due to the fast paced nature of
security fixes, new (fixed) programs are always being released. Before
you connect your machine to the network, it's a good idea to check
with your distribution's ftp site (ftp.redhat.com for example) and get
all the updated packages since you received your distribution CDROM.
Many times these packages contain important security fixes, so it's a
good idea to get them installed.
4.7. Creating New Accounts
You should make sure to provide user accounts with only the minimal
requirements for the task they need to do. If you provide your
secretary, or another general user, with an account, you might want
them to only have access to a word processor or drawing program, but
be unable to delete data that is not his or hers.
Several good rules of thumb when allowing other people legitimate
access to your Linux machine:
o Limit access privileges given to new users.
o Be aware when/where they login from, or should be logging in from.
o Make sure to remove inactive accounts
o The use of the same user-ID on all computers and networks is
advisable to ease account maintenance, as well as permit easier
analysis of log data (but I'm sure someone will dispute this).
However, it's practically essential if using NFS. There are
several other protocols that use UIDs for local and remote access
as well.
o The creation of group user-IDs should be absolutely prohibited.
User accounts also provide accountability, and this is not possible
with group accounts.
o Be sure shadow passwords are enabled. See the Password Security
section for more information.
o Regularly audit user accounts for invalid or unused accounts,
expired accounts, etc.
o Check for repeated login failures
o Be sure to enable quotas, to prevent denial of service attacks
involving filling disk partitions, or appending exploits to group-
writable files.
o Disable group accounts, and unused system accounts, such as sys or
uucp. These accounts should be locked, and given non-functional
shells.
Many local user accounts that are used in security compromises are
ones that have not been used in months or years. Since no one is using
them they provide the ideal attack vehicle.
4.8. Root Security
The most sought-after account on your machine is the superuser
account. This account has authority over the entire machine, which
may also include authority over other machines on the network.
Remember that you should only use the root account for very short
specific tasks and should mostly run as a normal user. Running as root
all the time is a very very very bad idea.
Several tricks to avoid messing up your own box as root:
o When doing some complex command, try running it first in a non
destructive way...especially commands that use globbing: e.g., you
are going to do a rm foo*.bak, instead, first do: ls foo*.bak and
make sure you are going to delete the files you think you are.
Using echo in place of destructive commands also sometimes works.
o Provide your users with a default alias to the /bin/rm command to
ask for confirmation for deletion of files.
o Only become root to do single specific tasks. If you find yourself
trying to figure out how to do something, go back to a normal user
shell until you are sure what needs to be done by root.
o The command path for the root user is very important. The command
path, or the PATH environment variable, defines the location the
shell searches for programs. Try and limit the command path for
the root user as much as possible, and never use '.', meaning 'the
current directory', in your PATH statement. Additionally, never
have writable directories in your search path, as this can allow
attackers to modify or place new binaries in your search path,
allowing them to run as root the next time you run that command.
o Never use the rlogin/rsh/rexec (called the ``r-utilities'') suite
of tools as root. They are subject to many sorts of attacks, and
are downright dangerous run as root. Never create a .rhosts file
for root.
o The /etc/securetty file contains a list of terminals that root can
login from. By default (on Red Hat Linux) this is set to only the
local virtual consoles (vtys). Be very careful of adding anything
else to this file. You should be able to login remotely as your
regular user account and then use su if you need to (hopefully over
ssh or other encrypted channel), so there is no need to be able to
login directly as root.
o Always be slow and deliberate running as root. Your actions could
affect a lot of things. Think before you type!
If you absolutely positively need to allow someone (hopefully very
trusted) to have superuser access to your machine, there are a few
tools that can help. sudo allows users to use their password to access
a limited set of commands as root. sudo keeps a log of all successful
and unsuccessful sudo attempts, allowing you to track down who used
what command to do what. For this reason sudo works well even in
places where a number of people have root access, but use sudo so you
can keep track of changes made.
Although sudo can be used to give specific users specific privileges
for specific tasks, it does have several shortcomings. It should be
used only for a limited set of tasks, like restarting a server, or
adding new users. Any program that offers a shell escape will give
the user root access. This includes most editors, for example. Also,
a program as innocuous as /bin/cat can be used to overwrite files,
which could allow root to be exploited. Consider sudo as a means for
accountability, and don't expect it to replace the root user yet be
secure.
4.9. Workstations and DialUp Security
User of computers to connect to the Internet via a dial-up line, or
workstations that otherwise offer no services to external hosts can
also improve their security with relatively easy modifications to the
stock Linux installation.
If there is never have a need to connect to your machine from another
one on the network, the quickest solution is to simply disable
/usr/sbin/inetd from even being started. This is the master Internet
daemon, which controls some normal server services, such as telnet,
ftp, etc. If you retrieve your mail from a remote host, and your
Internet Service Provider is hosting your web page, then most likely
there is not a need to enable these services.
On stock Red Hat systems, the file /etc/rc.d/rc3.d/S50inet controls
the starting and stopping of the inetd server. Simply rename the
S50inet file to s50inet to disable it, or see your Red Hat
administration manual for further information.
Alternatively, if you are a home dialup user, it is also possible to
deny all incoming connections using TCP Wrappers. TCP Wrappers,
/usr/sbin/tcpd, also logs failed attempts to access services, so this
can give you an idea that you are under attack. If you add new
services, you should be sure to configure it to use tcp_wrappers TCP
based. For example, a normal dial-up user can prevent outsiders from
connecting to your machine, yet still have the ability to retrieve
mail, and make network connections to the Internet. To do this, you
might add the following to your /etc/hosts.allow:
ALL: 127.
(including the ending period) And of course /etc/hosts.deny would
contain:
ALL: ALL
which will prevent external connections to your machine, yet still
allow you from the inside to connect to servers on the Internet. TCP
Wrappers can be combined with several other services, such as sendmail
and sshd to give even further control over access. See the respective
documentation for further information.
4.10. X11, SVGA and display security
4.10.1. X11
It's important for you to secure your graphical display to prevent
attackers from doing things such as grabbing your passwords as you
type them without you knowing it, reading documents or information you
are reading on your screen, or even using a hole to gain superuser
access. Running remote X applications over a network also can be
fraught with peril, allowing sniffers to see all your interaction with
the remote system.
X has a number of access control mechanisms. The simplest of them is
host based. You can use xhost to specify what hosts are allowed access
to your display. This is not very secure at all. If someone has access
to your machine they can xhost + their machine and get in easily.
When using xdm (X Display Manager) to login, you get a much better
access method: MIT-MAGIC-COOKIE-1. A 128bit cookie is generated and
stored in your .Xauthority file. These cookies need to be transferred
in confidence, and you really don't gain anything if your home
directory is shared via NFS. If you need to allow a remote machine
access to your display, you can use the xauth command and the
information in your .Xauthority file to provide only that connection
access. See the Remote-X-Apps mini-howto, available at
http://sunsite.unc.edu/LDP/HOWTO/mini/Remote-X-Apps.html.
You can also use ssh (see ssh, below) to allow secure X connections.
This has the advantage of also being transparent to the end user, and
means that no un-encrypted data flows across the network.
Take a look at the Xsecurity(1) man page for more information on X
security. The safe bet is to use xdm(1) to login to your console and
then use ssh to go to remote sites you wish to run X programs off of.
4.10.2. SVGA
SVGAlib programs are typically setuid-root in order to access all your
Linux machine's video hardware. This makes them very dangerous. If
they crash, you typically need to reboot your machine to get a usable
console back. Make sure any SVGA programs you are running are
authentic, and can at least be somewhat trusted. Even better, don't
run them at all.
4.10.3. GGI (Generic Graphics Interface project)
The Linux GGI project is trying to solve several of the problems with
video interfaces on Linux. GGI will move a small piece of the video
code into the Linux kernel, and then control access to the video
system. This means GGI will be able to restore your console at any
time to a known good state. They will also allow a secure attention
key, so you can be sure that there is no Trojan horse login program
running on your console. http://synergy.caltech.edu/~ggi/
4.11. identd
identd is a small program that typically runs out of your inetd. It
keeps track of what user is running what tcp service, and then reports
this to whoever requests it.
Many people misunderstand the usefulness of identd, and so they
disable it or block all off site requests for it. identd is not there
to help out remote sites. There is no way of knowing if the data you
get from the remote identd is correct or not. There is no
authentication in identd requests.
Why would you want to run it then? Because it helps you out, and is
another data-point in tracking. If your identd has not been
compromised, then you know it is telling remote sites the user-name or
user-ID of people using TCP services. If the admin at a remote site
comes back to you and tells you a user was trying to hack into their
site, you can easily take action against that user at your site who is
misusing a service. If you are not running identd, you will have to
look at lots and lots of logs, figure out who was on at the time, and
in general take a lot more time to track down the user.
The identd that ships with most distributions is more configurable
than many people think. You can disable identd for specific users
(they can make a .noident file), you can log all identd requests,
which is recommended, and identd can return a uid instead of a user
name or even NO-USER. Keep in mind it is really only useful is on a
network where nobody hostile has root access. Then it can help in
catching mail forgeries, for instance.
5. User, System, and Process Accounting
All Linux systems support system-wide process, user, and system
accounting, and it is wise to take advantage of it. You will need
this information when troubleshooting a possible security incident,
and your ability to address all aspects of a specific incident
strongly depends on the success of this analysis.
There are quite a few things, as the Security Administrator, of which
you should be aware. These include at least the following:
o Login activity
o Authorization information
o Authentication information
o Commands users have run
o Restarts and shutdowns of the system
o Network transactions records
o
5.1. Using Syslog
The system daemon called syslog is the program used to log system
events such as kernel messages, login or logout messages, general
system messages, etc.
Be sure to keep an eye on its normal operation and what gets written
to it's log files, especially under the ``auth'' facility. Multiple
login failures, for example, can indicate an attempted break-in. Keep
in mind that the lack of information does not indicate the opposite.
Where to look for your log file will depend on your distribution. In a
Linux system that conforms to the ``Linux File-system Standard'', such
as Red Hat, you will want to look in /var/log and check messages,
mail.log, and others.
You can find out where your distribution is logging to by looking at
your /etc/syslog.conf file. This is the file that tells
/usr/sbin/syslogd (the system logging daemon) where to log various
messages.
You might also want to configure your log-rotating script or daemon to
keep logs around longer so you have time to examine them. Take a look
at the logrotate package in recent Red Hat distributions. Other
distributions likely have a similar process. It seems that many
distributions default to only logging the most basic information, so
you should spend some time and customize it for your environment.
If your log files have been tampered with, see if you can determine
when the tampering started, and what sort of things they appeared to
tamper with. Are there large periods of time that cannot be accounted
for? Checking backup tapes (if you have any) for untampered log files
is a good idea.
Log files are typically modified by the intruder in order to cover his
tracks, but they should still be checked for strange happenings. You
may notice the intruder attempting to gain entrance, or exploit a
program in order to obtain the root account. You might see log entries
before the intruder has time to modify them.
You should also be sure to seperate the ``authpriv'' facility from
other log data, including attempts to switch users using /bin/su,
login attempts, and other user accounting information.
5.1.1. Storing Log Data Securely
It is also a good idea to store log data at a secure location, such as
a dedicated log server within your well-protected network. Once a
machine has been compromised, log data becomes of little use as it
most likely has also been modified by the intruder. It most likely of
little value in a criminal investigation. It helps if the log data,
which has been stored remotely, indicates when root access was gained
so that logs before that point are okay.
The syslogd daemon can be configured to automatically send log data to
a central syslogd server, but this is typically sent in cleartext
data, allowing an intruder to view data as it is being transferred.
This may reveal information about your network that is not intended to
be public. There are syslog daemons available that encrypt the data
as it is being sent.
Also be aware that faking syslog messages has been reported, with an
exploit program having been published. Syslog even accepts net log
entries claiming to come from the local host without indicating their
true origin. A more secure implementation has been written by CORE-
SDI, and is available at http://www.core-
sdi.com/ENGLISH/CoreLabs/ssyslog/index.html
If possible, configure syslogd to send a copy of the most important
data to a secure system. This will prevent an intruder from covering
his tracks by deleting his login, su, ftp, etc attempts. See the
syslog.conf(5) man page, and refer to the ``@'' option.
If you've already decided to use a central syslog server, the
additional security this provides is well worth it. However, you
should consider the additional overhead involved with sending this
data real-time across your network.
5.2. Using User Accounting
User accounting can be used to discover information about who is
currently using the system. While you cannot necessarily verify the
integrity of this information once your machine has been exploited, it
can be a useful tool to track the systems a particular user has logged
into, what time he or she logged in, when the system was last
rebooted, etc.
There are also utilities available for locking There are several tools
available to process this information, including last(1), who(1),
ac(1), utmpdump(1) (typically for debugging only), among others.
For example, using the /usr/bin/last command, you can view quite a bit
of information about your system:
root tty1 Fri Jul 3 21:02 still logged in
reboot system boot Fri Jul 3 21:01
dave ttyp2 localhost Wed Jul 1 23:11 - 23:11 (00:00)
david ttyp2 localhost Wed Jul 1 22:47 - 22:47 (00:00)
The last(1) command, which shows a listing of last logged in users,
and lastb(1), which shows a listing of failed login attempts (assuming
/var/log/btmp exists), both consult the /var/log/wtmp file, which con-
tains the following information:
o Type of Login
o Process ID of login process
o Device name of tty
o Init ID or abbreviated ttyname
o User Name
o Hostname for remote login
o Exit Status of a process
o Time entry was made
o IP address of remote host
See the man page for wtmp(5) for a description of any of the fields
you do not understand.
The file /var/run/utmp is the file that is consulted to find out who
is currently on the system (and primarily used by the who(1) command).
However, there may be more users currently using the system because
not all programs use utmp logging. This file is typically truncated
upon each system boot, by one of the /etc/rc.d/rc.* files. Be sure
this file is not writable by users other than root, as it is possible
to insert or delete entries from this file otherwise. This file
really serves very little purpose.
Finally, log files are much less useful when no one is reading them.
Take some time out every once in a while to look over your log files
(especially when you suspect an unauthorized visitor), and get a
feeling for what the look like on a normal day. Knowing this can help
make unusual things stand out.
5.3. Using Process Accounting
Process accounting support has also been integrated into the new
kernels. To use this feature, you'll need to get
ftp://sunsite.unc.edu:/pub/Linux/system/admin/accounts/acct-1.3.73.tar.gz
It no longer requires patching the kernel for this ability. This
package includes several program to manage the kernel-level functions,
including:
o accton (8) - Turn on accounting of processes
o accttrim (8) - Trim down the size of an accounting file
o lastcomm (1) - show last commands executed in reverse order
It really works quite well, and is highly recommended for systems that
have a large number of users.
5.4. Managing User Accounts
Having control over the resources and data your users have access to
is an essential part of maintaining security. Linux provides a large
number of tools including account permissions, passwords, account
aging, adding and deleting of users, etc.
Some of the programs you should become familiar with to manage users
and groups include:
o chage (1) - change user password expiry information
o groups (1) - print the groups a user is in
o newusers (8) - update and create new users in batch
o passwd (1) - update a user's authentication tokens(s)
o nologin (5) - prevent non-root users from log into the system
o su (1) - run a shell with substitute user and group IDs
o useradd (8) - Create a new user or update default new user
information
o userdel (8) - Delete a user account and related files
o usermod (8) - Modify a user account
o chgrp (1) - change the group ownership of files
o chown (1) - change the user and group ownership of files
o gpasswd (1) - administer the /etc/group file
o groupadd (8) - Create a new group
o groupdel (8) - Delete a group
o groupmod (8) - Modify a group
o groups (1) - print the groups a user is in
o grpck (8) - verify integrity of group files
o pwconv (8) - convert to and from shadow passwords
o pwunconv (8) - convert to and from shadow passwords
o grpconv (8) - convert to and from shadow passwords
o grpunconv (8)- convert to and from shadow passwords
o vipw (8) - edit the password or group files
o vigr (8) - edit the password or group files
You can read the online manual pages for these commands using a syntax
similiar to the following:
user@myhost# man 8 pwunconv
This refers to pwunconv in section 8 of the manual pages.
You can find additional account management packages at
ftp://sunsite.unc.edu:/pub/Linux/system/admin/accounts
6. Physical Security
The first ``layer'' of security you need to take into account is the
physical security of your computer systems. Who has direct physical
access to your machine? Should they? Can you protect your machine from
their tampering? Should you?
How much physical security you need on your system is very dependent
on your situation, and/or budget.
If you are a home user, you probably don't need a lot (although you
might need to protect your machine from tampering by children or
annoying relatives). If you are in a Lab environment, you need
considerably more, but users will still need to be able to get work
done on the machines. Many of the following sections will help out. If
you are in a Office, you may or may not need to secure your machine
off hours or while you are away. At some companies, leaving your
console unsecured is a termination offense.
Obvious physical security methods such as locks on doors, cables,
locked cabinets, and video surveillance are all a good idea, but
beyond the scope of this document. :)
Make use of /etc/shutdown.allow to prevent someone from rebooting your
machine. This file is consulted when the machine is rebooted using
the Control-Alt-Del keys. It contains a list of usernames that are
authorized to reboot the machine.
6.1. Computer Locks
Many more modern PC cases include a "locking" feature. Usually this
will be a socket on the front of the case that allows you to turn an
included key to a locked or unlocked position. Case locks can help
prevent someone from stealing your PC, or opening up the case and
directly manipulating/stealing your hardware. They can also sometimes
prevent someone from rebooting your computer on their own floppy or
other hardware.
These case locks do different things according to the support in the
motherboard and how the case is constructed. On many PC's they make it
so you have to break the case to get the case open. On some others
they make it so that it will not let you plug in new keyboards and
mice. Check your motherboard or case instructions for more
information. This can sometimes be a very useful feature, even though
the locks are usually very low quality and can easily be defeated by
attackers with locksmithing.
Some cases (most notably SPARC and Mac) have a dongle on the back that
if you put a cable through attackers would have to cut the cable or
break the case to get into it. Just putting a padlock or combo lock
through these can be a good deterrent to someone stealing your
machine.
6.2. BIOS Security
The BIOS is the lowest level of software that configures or
manipulates your x86 based hardware. LILO and other Linux boot methods
access the BIOS to determine how to boot up your Linux machine. Other
hardware that Linux runs on has similar software (OpenFirmware on Macs
and new Suns, Sun boot PROM, etc...). You can use your BIOS to prevent
attackers from rebooting your machine and manipulating your Linux
system.
Under Linux/x86 many PC BIOSs let you set a boot password. This
doesn't provide all that much security (BIOS can be reset, or removed
if someone can get into the case), but might be a good deterrent
(e.g., it will take time and leave traces of tampering).
Many x86 BIOSs also allow you to specify various other good security
settings. Check your BIOS manual or look at it the next time you boot
up. Some examples are: disallow booting from floppy drives and
passwords to access some BIOS features.
On Linux/SPARC, your SPARC EEPROM can be set to require a boot-up
password. This might slow attackers down.
NOTE: If you have a server machine, and you setup a boot password,
your machine will not boot up unattended. Keep in mind that you will
need to come in and supply the password in the event of a power
failure.
6.3. Boot Loader Security
The various Linux boot loaders also can have a boot password set.
Using LILO, take a look at the ``restricted'' and ``password''
settings. "password" allows you to set a boot-up password.
``restricted'' will let the machine boot _unless_ someone specifies
options at the LILO: prompt (like ``single'').
Keep in mind when setting all these passwords that you need to
remember them. :) Also remember that these passwords will merely slow
the determined attacker. This won't prevent someone from booting from
a floppy, and mounting your root partition. If you are using security
in conjunction with a boot loader, you might as well disable booting
from a floppy in your computer's BIOS, as well as password-protecting
your computer's BIOS.
If anyone has security related information from a different boot
loader, we would love to hear it. (SILO, MILO, loadlin, etc).
NOTE: If you have a server machine, and you setup a boot password,
your machine will not boot up unattended. Keep in mind that you will
need to come in and supply the password in the event of a power
failure. ;(
6.4. xlock and vlock
If you wander away from your machine from time to time, it is nice to
be able to "lock" your console so that no one tampers with or looks at
your work. Two programs that do this are: xlock and vlock.
Xlock is a X display locker. It should be included in any Linux
distributions that support X. Check out the man page for it for more
options, but in general you can run xlock from any xterm on your
console and it will lock the display and require your password to
unlock.
vlock is a simple little program that allows you to lock some or all
of the virtual consoles on your Linux box. You can lock just the one
you are working in or all of them. If you just lock one, others can
come in and use the console, they will just not be able to use your
virtual TTY until you unlock it. vlock ships with RedHat Linux, but
your mileage may vary.
Of course locking your console will prevent someone from tampering
with your work, but does not prevent them from rebooting your machine
or otherwise disrupting your work. It also does not prevent them from
accessing your machine from another machine on the network and causing
problems.
More importantly, it does not prevent someone from switching out of
the X Window System entirely, and going to a normal virtual console
login prompt, or to the VC that X11 was started from, and suspending
it, thus obtaining your privileges. For this reason, you might
consider only using it while under control of xdm. At the very least,
start X in the background, and log out of the console.
7. Intrusion Detection
Intruders are constantly attempting different mechanisms to attack
your system. You must be able to detect these varying attempts, and
know what to do when they happen. You should also be able to
distinguish the normal operating conditions from an actual attack.
You must be able to determine things like whether or not there really
was an intrusion, to what extent the attack occured.
7.1. What is Intrusion Detection?
Intrusion Detection is the method in which a security administrator
uses to detect the presence of an unauthorized intruder. An Intrusion
Detection System (IDS) are the combination of tools that a security
administrator uses to detect the intrusion. Briefly, the available
types of intrusion detection include:
o Network Based Intrusion Detection - These mechanisms typically
consist of a black box that sits on the network in promiscious
mode, listening for patterns indictive of an intrusion.
o Host Based Intrusion Detection - These mechanisms typically include
auditing for specific events that occur on a specific host. These
are not as common, due to the overhead they incur by having to
monitor each system event.
o Log File Monitoring - These mechanisms are typically programs that
parse log files after an event has already occured, such as failed
login attempts, etc.
o File Integrity Checking - These mechanisms typically check for
trojan horses, or files that have otherwise been modified,
indicating an intruder has already been there. The Red Hat Package
Manager, RPM, has this capability, as does the well-known Tripwire
package.
7.2. General Indications of Intrusion
Being capable of detecting an intrusion is as important as being able
to stop it once it happens. It is important that you are able to
detect the subtle signs left by an intruder during his attack of your
system.
Suspicious signs of intrusion include at least the following:
7.2.1. User Indications
o Failed log-in attempts
o Log-ins to accounts that have not been used for an extended period
of time
o Log-ins during hours other than non-working hours
o The presence of new user accounts that were not created by the
system administrator
o su entries or logins from strange places, as well as repeated
failed attempts
7.2.2. System Indications
o Modifications to system software and configuration files
o Gaps in system accounting that indicate that no activity has
occurred for a long period of time
o Unusually slow system performance
o System crashes or reboots
o Short or incomplete logs
o Logs containing strange timestamps
o Logs with incorrect permissions or ownership
o Missing logs
o Abnormal system performance
o Unfamiliar processes
o Unusual graphic displays or text messages.
7.2.3. File System Indications
o The presence of new, unfamiliar files or programs
o Changes in file permissions
o Unexplained changes in file size. Be sure to analyize all your
system files, including those in your $HOME/ directory such as
$HOME/.bashrc for modified $PATH entries, as well as changes in
system configuration files in /etc
o Rogue suid and sgid files on the system that do not correspond to
your master list of suid and sgid files
o Unfamiliar file names in directories
o Missing files
7.2.4. Network Indications
o Repeated probes of the available services on your machines
o Connections from unusual locations
o Repeated login attempts from remote hosts
o Arbitrary log data in log files, indicating attempt at creating
either Denial of Service, or crash service
7.3. General Methods for Detecting Intrusions
In order to determine if an intruder has violated your system, you
must be familiar with the normal system administration tools, and be
able to use them to find the ``footprint'' a cracker may have left
behind. This procedure can be relatively easy, or practically
impossible, depending on how much preparation you have done, as well
as the stage you've detected the intruder, and how skilled the
intruder is.
There are pointers throughout this document that list the various
tools available. Some of the tools and methods you should become
familiar with include:
o Log file analysis. Be sure to see the User Security section for
information on syslog(8) which is responsible for logging many
system events that are helpful in tracking connections to your
system, as well as local system events.
o Become familiar with the last(1), lastcomm(1), and netstat(8)
commands. These are available to show valuable information about
the users, commands, and connections on your system. More
information on these commands are available in the User Security
section.
o Look for signs of physical intrusion.
o Ensure that the software you are using to search for the intruder
hasn't itself been compromised. Do not place all your trust in the
tools you are using, and the output they produce. Consider placing
a set of secure binaries on external media that can be used later,
with confidence. See the
http://www.txdirect.net/users/mdfranz/trinux.html package for a
starting point.
o Follow the guidelines provided by CERT in this document
ftp://info.cert.org/pub/tech_tips/UNIX_configuration_guidelines
o Check other local systems that may have been used to attack at
yours
o Check for systems at remote sites that may be involved or affected
o Investigate unauthorized hardware attached to the network
o Observe your systems for anything unusual, and certainly
investigate anything you find
o Notify your incident response team if you find something that could
have been performed by an unauthorized user
o Use the network monitoring tools. There are also several nifty
network monitoring tools there that are also very helpful. It is
important to keep aware of the status of your network, so you know
when to be alerted to a specific event. See the Network Monitoring
section for more information.
7.4. Intrusion Detection Tools
There are many intrusion detection tools available for Linux, and many
new tools are constantly becomming available. While the majority of
the tools are host-based intrusion detection tools, there are a number
of network-based tools as well.
7.4.1. Host Based Detection Tools
o Tripwire
o Make use of the available tools. There are several tools available
to detect when someone is portscanning your network. Start with
http://www.psionic.com/abacus/abacus_sentry.html which is the
Sentry intrusion detection tool.
There are also several intrusion detection tools available at
http://www.eng.auburn.edu/users/doug/second.html including a tool
called klaxton which basically sets a trap for an intruder, then
notifies you when some is ``doorknob rattling''.
7.5. Integrity Checking
A very good way to determine if you have an unwanted visitor is to
check your local files for possible trojan horses, missing files,
files that are larger or smaller than they are supposed to be, etc.
Fortunately, there are several tools that can verify the file
integrity. Many Linux distributions use RPM for their package
management, which inherently has integrity checking. Also available
is the well-known program called tripwire.
7.6. Using tripwire
Tripwire runs a number of checksums on all your important binaries and
config files and compares them against a database of former, known-
good values as a reference. Thus, any changes in the files will be
flagged.
It's a good idea to install tripwire onto a floppy, and then
physically set the write protect on the floppy. This way intruders
can't tamper with tripwire itself or change the database. Once you
have tripwire setup, it's a good idea to run it as part of your normal
security administration duties to see if anything has changed.
You can even add a crontab entry to run tripwire from your floppy
every night and mail you the results in the morning. Something like:
# set mailto
MAILTO=kevin
# run tripwire
15 05 * * * root /usr/local/adm/tcheck/tripwire
will mail you a report each morning at 5:15am.
Tripwire can be a godsend to detecting intruders before you would
otherwise notice them. Since a lot of files change on the average
system, you have to be careful what is cracker activity and what is
your own doing, which is a solid reason to keep track of the status of
the binaries on your system.
A company called Visual Computing Corporation now apparently has been
given exclusive rights to continue development of tripwire, originally
developed at Purdue University. It looks to be so-far-so-good, as
there is still a working version for Linux. You can find more
information from them at http://www.visualcomputing.com
7.7. Using The Red Hat Package Mangaer
The Red Hat Package Manager (RPM) program includes the ability to
verify all packages that it has installed on the system.
RPM has facilities for verifying that a package is not corrupt or has
components missing. A program added or removed by a cracker will not
match the original and RPM will generally report a verification
failure.
Now, when your system is compromised, you can use the command:
root# rpm -Va
to verify each file on the system. See the RPM man page, as there are
a few other options that can be included to make it less verbose.
Keep in mind you must also be sure your RPM binary has not been com-
promised. RPM can also be combined with PGP to check a package's sig-
nature. Typical output might look like the following:
..5....T /bin/login
should sound alarm bells. RPM produces the following useful output
fields:
o S - file size changed
o M - file mode changed
o 5 - MD5 checksum failed
o U - file owner changed
o G - group changed
This means that every time a new RPM is added to the system, the RPM
database will need to be re-archived. You will have to decide the
advantages versus drawbacks. Also, keep in mind that it won't verify
programs that RPM did not install.
Specifically, the files /var/lib/rpm/fileindex.rpm and
/var/lib/rpm/packages.rpm most likely won't fit on a single floppy.
Compressed, each should fit on a separate floppy. Consider storing
this (as well as the actual /bin/rpm executable!!) on a Zip cartrige.
7.8. File System Guidelines
Intruders often either modify, delete, or replace existing files in
order to either cover their tracks, assist them in gaining access, or
to gather further information.
Ensuring the integrity of the files and programs on your system is
vital in intrusion detection. Several means can be used to determine
if files have been tampered with on your system:
o Look for suspicious files on your system, or even system files that
may have been tampered with, or missing. You can find the list of
the most recently modified files with the following command:
user@host# /usr/bin/find / -ctime -1 -print
Read the File System Security section for tips on scanning your
filesystem for changed files, as well as setuid and sgid files.
o Verify the integrity of the files. If you are prepared, you can
use your Red Hat RPM database, or Tripwire database stored on
external media at this time to verify the integrity of the most
important files on your system.
7.9. Physical Intrusion Detection
Intruders may attempt to breach your network's by physical infitration
as well as via the network. Keep in mind that one system can be used
to penetrate many others, so securing one machine is as important as
securing another.
The first thing to always note is when your machine was rebooted.
Since Linux is a robust and stable OS, the only times your machine
should reboot is when YOU take it down for OS upgrades, hardware
swapping, or the like. You should always investigate machine reboots.
Check for signs of tampering on the case and computer area. Although
many intruders clean traces of their presence out of logs, it's a good
idea to check through them all and note any discrepancy.
7.10. Packet Sniffers
One of the more common ways intruders gain access to multiple systems
on your network is by employing a packet sniffer on a already
compromised host. This software-based ``sniffer'' just listens on the
Ethernet port for things like ``password'' and ``login'' and ``su'' in
the packet stream and then logs the traffic after that. This way,
attackers gain passwords for systems they are not even attempting to
break into. Clear text passwords are very vulnerable to this attack.
An attacker doesn't even need to compromise a system to do this, they
could also bring a laptop or PC into your building and tap into your
net.
Using SSH, or other encrypted password methods, thwarts this attack.
Things like APOP for POP email accounts also prevents this attack.
(Normal POP logins are very vulnerable to this, as is anything that
sends clear text passwords over the wire.)
If you are using syslog to send your data to a central log server,
consider that the data is sent in clear text, and much information can
be gathered from this data. Consider using a secure implementation of
syslog, which encrypts and compresses the data before it is sent. See
the Using Syslog section for more information on configuring
syslogd(8) securely.
8. Files and