Linux Security Administrator's Guide Dave Wreski, dave@nic.com v0.98, 22 August 1998 This document is a general overview of security issues that face the administrator of Linux systems. It covers general security philosophy and a number of specific examples of how to better secure your Linux system from intruders. Also included are pointers to security related material and programs. ______________________________________________________________________ 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: http://sunsite.unc.edu/LDP/ 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 File System Security A few minutes of preparation and planning ahead before putting your systems online can help to protect your system, and the data that is stored on it. This section discusses some of the methods in which you can use to secure the files on your system, some general guidelines for improving the overall security of the files on your system, and some ideas for preventing problems from occuring in the first place. It also discusses the commands to use to modify the permissions and ownership of files and directories on your system. Before we discuss some of these methods of improving file system security, it is important to have an understanding of basic Linux file security, ownership, and what each of the fields from a file listing actually mean. To display the ownership and permissions of a file on your system, use the long-listing option, as well as the display all files option to the ls(1) command. A typical /bin/ls -la command might show the following, with the first line being a field marker: |----1----|-2--|---3----|----4-----|---5--|-----6------|---7-----| 1. drwxrwxr-x 24 root users 1024 Aug 19 00:05 . 2. drwxr-xr-x 22 root root 1024 Aug 11 22:04 .. 3. drwxr-xr-x 3 root root 1024 Jun 19 03:40 Mail 4. -rw-rw-r-- 1 dave security 43244 Jul 20 14:11 README 5. drwxrwsr-x 17 dave security 1024 Jul 31 01:48 Security [More not shown] Each of these fields provide useful information to the security administrator. First, a description of each field (as shown from left to right), then a more in-depth explanation of the most important ones. The numbers down the left side represent the line numbers, which will be referred to later. o Field One: Permissions for this file or directory. The first nine positions from the right describe the user, group, and other permissions, in groups of three. Within each group of three, the first character denotes read access, the second denotes write access, and the last denotes execute, working from left to right. The tenth position describes the type of file, which can be either a regular file, directory, FIFO, symbolic link, or other type of special file. o Field Two: Number of hard links to this file or directory. These links can be directories, for example. In this case the current directory (line 1) most likely has 24 directories below it, of which only two are shown here (Security and Mail) o Field Three: Owner of the file or directory. This field is as important as the permissions themselves. o Field Four: The group to which the file belongs. This field, in conjunction with the owner field (field three) are necessary in order to set the permissions correctly. o Field Five: Size of file o Field Six: Modification time o Field Seven: File name 8.1. File Permissions and Ownership Continuing where we left off in the previous section, we can now discuss some of the fields described above. Particularly, field one and fields three and four are the most exiciting. Linux separates access control on files and directories according to three characteristics: owner, group, and other. There is always exactly one owner, any number of members of the group, and everyone else. The files within each of these categories have specific permissions with which they are accessed. File permissions, including regular files, special files (such as FIFOs, sockets, etc), or symbolic links (which dereference the permissions to the file they point to) can have any one, or any, of the following: Symbol Permission Description ------------------------------------------------------------------- r Read Can be opened to read the contents w Write Can be modified, including appending and deleting x Execute Can execute the file if it is a program or shell script s Special Perm setuid or setgid permission - Access Denied Cannot be read, written, or executed, depending on the position of the `-' The read, write, and execute permissions should be pretty clear as to their meaning. However, the ``s'' symbol may need to explanation. The next two sections address this symbol. 8.1.1. Set User Identification Attribute When the set user ID ac