Redhat ENTERPRISE LINUX 3 User Manual

Red Hat Enterprise Linux 3

Security Guide

Red Hat Enterprise Linux 3: Security Guide

Red Hat, Inc.

1801 Varsity Drive Raleigh NC 27606-2072 USA Phone: +1 919 754 3700 Phone: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Research Triangle Park NC 27709 USA

rhel-sg(EN)-3-Print-RHI (2003-07-25T17:12) Copyright © 2003 by Red Hat, Inc. This material may be distributedonly subject to the terms and conditions set forth in the Open Publication License, V1.0 or later (the latest version is presentlyavailableat http://www.opencontent.org/openpub/). Distribution of substantively modiﬁed versions of this document is prohibitedwithout the explicit permission of the copyright holder. Distribution of the work or derivative of the work in any standard (paper)book form for commercial purposes is prohibited unless prior permission is obtained from the copyright holder. Red Hat, Red Hat Network, the Red Hat "ShadowMan" logo, RPM, Maximum RPM, the RPM logo, Linux Library,

PowerTools,Linux Undercover, RHmember, RHmember More, Rough Cuts, Rawhide and all Red Hat-based trademarksand logos are trademarks or registered trademarks of Red Hat, Inc. in the United States and other countries. Linux is a registered trademark of Linus Torvalds. Motif and UNIX are registeredtrademarks of The Open Group. XFree86 is a trademark of The XFree86 Project, Inc, and is pending registration. Intel and Pentium are registered trademarksof Intel Corporation. Itanium and Celeron are trademarksof Intel Corporation. AMD, Opteron, Athlon, Duron, and K6 are registered trademarks of AdvancedMicro Devices, Inc. Netscape is a registeredtrademark of Netscape Communications Corporation in the United States and other countries. Java and Swing are trademarks or registered trademarks of Sun Microsystems, Inc. in the U.S. or other countries. Oracle is a registered trademark, and Oracle8i, Oracle9i, and interMedia are trademarks or registeredtrademarks of Oracle Corporation. Microsoft and Windows are either registeredtrademarks or trademarksof Microsoft Corporation in the United States and/or other countries. SSH and Secure Shell are trademarks of SSH CommunicationsSecurity, Inc. FireWire is a trademark of Apple Computer Corporation. IBM, AS/400, OS/400, RS/6000, S/390, and zSeries are registeredtrademarks of International Business Machines Corporation. eServer, iSeries, and pSeries are trademarks of InternationalBusiness Machines Corporation.

All other trademarks and copyrights referredto are the property of their respectiveowners. The GPG ﬁngerprint of the security@redhat.comkey is: CA 20 86 86 2B D6 9D FC 65 F6 EC C4 21 91 80 CD DB 42 A6 0E

Table of Contents

Introduction.......................................................................................................................................... i

1. Document Conventions.........................................................................................................ii

2. More to Come ...................................................................................................................... iv

2.1. Send in Your Feedback ......................................................................................... iv

I. A General Introduction to Security ................................................................................................ i

1. Security Overview................................................................................................................. 1

1.1. What is Computer Security? .................................................................................. 1

1.2. Security Controls ...................................................................................................5

1.3. Conclusion ............................................................................................................. 6

2. Attackers and Vulnerabilities................................................................................................ 7

2.1. A Quick History of Hackers ..................................................................................7

2.2. Threats to Network Security .................................................................................. 7

2.3. Threats to Server Security...................................................................................... 8

2.4. Threats to Workstation and Home PC Security ................................................... 10

II. Conﬁguring Red Hat Enterprise Linux for Security................................................................ 11

3. Security Updates ................................................................................................................. 13

3.1. Updating Packages...............................................................................................13

4. Workstation Security........................................................................................................... 19

4.1. Evaluating Workstation Security .........................................................................19

4.2. BIOS and Boot Loader Security ..........................................................................19

4.3. Password Security................................................................................................22

4.4. Administrative Controls....................................................................................... 27

4.5. Available Network Services ................................................................................. 33

4.6. Personal Firewalls................................................................................................35

4.7. Security Enhanced Communication Tools........................................................... 36

5. Server Security....................................................................................................................37

5.1. Securing Services With TCP Wrappers and xinetd .......................................... 37

5.2. Securing Portmap.................................................................................................40

5.3. Securing NIS........................................................................................................ 40

5.4. Securing NFS .......................................................................................................42

5.5. Securing the Apache HTTP Server...................................................................... 43

5.6. Securing FTP ....................................................................................................... 44

5.7. Securing Sendmail ............................................................................................... 47

5.8. Verifying Which Ports Are Listening ..................................................................48

6. Virtual Private Networks .....................................................................................................51

6.1. VPNs and Red Hat Enterprise Linux ...................................................................51

6.2. Crypto IP Encapsulation (CIPE) .......................................................................... 51

6.3. Why Use CIPE? ...................................................................................................52

6.4. CIPE Installation..................................................................................................53

6.5. CIPE Server Conﬁguration .................................................................................. 53

6.6. Conﬁguring Clients for CIPE .............................................................................. 54

6.7. Customizing CIPE ...............................................................................................56

6.8. CIPE Key Management ....................................................................................... 57

6.9. IPsec..................................................................................................................... 57

6.10. IPsec Installation................................................................................................ 58

6.11. IPsec Host-to-Host Conﬁguration...................................................................... 58

6.12. IPsec Network-to-Network conﬁguration .......................................................... 60

7. Firewalls..............................................................................................................................65

7.1. Netﬁlter and IPTables ..........................................................................................66

7.2. Using IPTables..................................................................................................... 66

7.3. Common iptables Filtering.............................................................................. 68

7.4. FORWARD and NAT Rules..................................................................................... 69

7.5. DMZs and iptables .......................................................................................... 70

7.6. Viruses and Spoofed IP Addresses ......................................................................70

7.7. IP6Tables..............................................................................................................70

7.8. Additional Resources ........................................................................................... 71

III. Assessing Your Security............................................................................................................. 73

8. Vulnerability Assessment....................................................................................................75

8.1. Thinking Like the Enemy .................................................................................... 75

8.2. Deﬁning Assessment and Testing........................................................................ 75

8.3. Evaluating the Tools.............................................................................................77

IV. Intrusions and Incident Response.............................................................................................81

9. Intrusion Detection..............................................................................................................83

9.1. Deﬁning Intrusion Detection Systems ................................................................. 83

9.2. Host-based IDS ....................................................................................................83

9.3. Network-based IDS.............................................................................................. 86

10. Incident Response .............................................................................................................89

10.1. Deﬁning Incident Response ............................................................................... 89

10.2. Creating an Incident Response Plan .................................................................. 89

10.3. Implementing the Incident Response Plan......................................................... 90

10.4. Investigating the Incident...................................................................................91

10.5. Restoring and Recovering Resources ................................................................93

10.6. Reporting the Incident........................................................................................ 94

V. Appendixes.................................................................................................................................... 95

A. Hardware and Network Protection..................................................................................... 97

A.1. Secure Network Topologies................................................................................97

A.2. Hardware Security............................................................................................. 100

B. Common Exploits and Attacks.........................................................................................101

C. Common Ports.................................................................................................................. 105

Index.................................................................................................................................................117

Colophon.......................................................................................................................................... 123

Introduction

Welcome to the Red Hat Enterprise Linux Security Guide!

The Red Hat Enterprise Linux Security Guide is designed to assist users of Red Hat Enterprise Linux in learning the processes and practices of securing workstations and servers against local and remote intrusion, exploitation, and malicious activity. The Red Hat Enterprise Linux Security Guide details the planning and the tools involved in creating a secured computing environment for the data center, workplace, and home. With proper administrative knowledge, vigilance, and tools, systems running Red Hat Enterprise Linux can be both fully functional and secured from most common intrusion and exploit methods.

This guide discusses several security-related topics in great detail, including:

• Firewalls

• Encryption

• Securing Critical Services

• Virtual Private Networks

• Intrusion Detection

The manual is divided into the following parts:

• General Introduction to Security

• Conﬁguring Red Hat Enterprise Linux for Security

• Assessing Your Security

• Intrusions and Incident Response

• Appendix

We would like to thank Thomas Rude for his generous contributions to this manual. He wrote the Vulnerability Assessments and Incident Response chapters. Thanks, "farmerdude."

This manual assumes that you have an advanced knowledge of Red Hat Enterprise Linux. If you are a new user or only have basic to intermediate knowledge of Red Hat Enterprise Linux and need more information on using the system, refer to the following guides which discuss the fundamental aspects of Red Hat Enterprise Linux in greater detail than the Red Hat Enterprise Linux Security Guide:

• The Red Hat Enterprise Linux Installation Guide provides information regarding installation.

• The Red Hat Enterprise Linux Introduction to System Administration contains introductory infor-

mation for new Red Hat Enterprise Linux system administrators.

• The Red Hat Enterprise Linux System Administration Guide offers detailed information about con-

ﬁguring Red Hat Enterprise Linux to suit your particular needs as a user. This guide includes some services that are discussed (from a security standpoint) in the Red Hat Enterprise Linux Security Guide.

• Red Hat Enterprise Linux Reference Guide provides detailed information suited for more experi-

enced users to refer to when needed, as opposed to step-by-step instructions.

HTML, PDF, and RPM versions of the manuals are available on the Red Hat Enterprise Linux Documentation CD and online at http://www.redhat.com/docs/.

ii Introduction

Note

Although this manual reﬂects the most current information possible, read the Red Hat Enterprise Linux Release Notes for information that may not have been available prior to our documenta-

tion being ﬁnalized. They can be found on the Red Hat Enterprise Linux CD #1 and online at http://www.redhat.com/docs/.

1. Document Conventions

When you read this manual, certain words are represented in different fonts, typefaces, sizes, and weights. This highlighting is systematic; different words are represented in the same style to indicate their inclusion in a speciﬁc category. The types of words that are represented this way include the following:

command

Linux commands (and other operating system commands, when used) are represented this way. This style should indicate to you that you can type the word or phrase on the command line and press [Enter] to invoke a command. Sometimes a command contains words that would be displayed in a different style on their own (such as ﬁle names). In these cases, they are considered to be part of the command, so the entire phrase is displayed as a command. For example:

Use the cat testfile command to view the contents of a ﬁle, named testfile, in the current working directory.

file name

File names, directory names, paths, and RPM package names are represented this way. This style should indicate that a particular ﬁle or directory exists by that name on your system. Examples:

The .bashrc ﬁle in your home directory contains bash shell deﬁnitions and aliases for your own use.

The /etc/fstab ﬁle contains information about different system devices and ﬁle systems.

Install the webalizer RPM if you want to use a Web server log ﬁle analysis program.

application

This style indicates that the program is an end-user application (as opposed to system software). For example:

Use Mozilla to browse the Web.

[key]

A key on the keyboard is shown in this style. For example:

To use [Tab] completion, type in a character and then press the [Tab] key. Your terminal displays the list of ﬁles in the directory that start with that letter.

[key]-[combination]

A combination of keystrokes is represented in this way. For example:

The [Ctrl]-[Alt]-[Backspace] key combination exits your graphical session and return you to the graphical login screen or the console.

Introduction iii

text found on a GUI interface

A title, word, or phrase found on a GUI interface screen or window is shown in this style. Text shown in this style is being used to identify a particular GUI screen or an element on a GUI screen (such as text associated with a checkbox or ﬁeld). Example:

Select the Require Password checkbox if you would like your screensaver to require a password before stopping.

top level of a menu on a GUI screen or window

A word in this style indicates that the word is the top level of a pulldown menu. If you click on the word on the GUI screen, the rest of the menu should appear. For example:

Under File on a GNOME terminal, the New Tab option allows you to open multiple shell prompts in the same window.

If you need to type in a sequence of commands from a GUI menu, they are shown like the following example:

Go to Main Menu Button (on the Panel) => Programming => Emacs to start the Emacs text editor.

button on a GUI screen or window

This style indicates that the text can be found on a clickable button on a GUI screen. For example:

Click on the Back button to return to the webpage you last viewed.

computer output

Text in this style indicates text displayed to a shell prompt such as error messages and responses to commands. For example:

The ls command displays the contents of a directory. For example:

Desktop about.html logs paulwesterberg.png Mail backupfiles mail reports

The output returned in response to the command (in this case, the contents of the directory) is shown in this style.

prompt

A prompt, which is a computer’s way of signifying that it is ready for you to input something, is shown in this style. Examples:

[stephen@maturin stephen]$

leopard login:

user input

Text that the user has to type, either on the command line, or into a text box on a GUI screen, is displayed in this style. In the following example, text is displayed in this style:

To boot your system into the text based installation program, you must type in the text command at the boot: prompt.

replaceable

Text used for examples which is meant to be replaced with data provided by the user is displayed in this style. In the following example,



version-numberis displayed in this style:

iv Introduction

The directory for the kernel source is /usr/src/



version-numberis the version of the kernel installed on this system.

version-number/, where



Additionally, we use several different strategies to draw your attention to certain pieces of information. In order of how critical the information is to your system, these items are marked as note, tip, important, caution, or a warning. For example:

Note

Remember that Linux is case sensitive. In other words, a rose is not a ROSE is not a rOsE.

Tip

The directory /usr/share/doc/ contains additional documentation for packages installed on your system.

Important

If you modify the DHCP conﬁguration ﬁle, the changes will not take effect until you restart the DHCP daemon.

Caution

Do not perform routine tasks as root — use a regular user account unless you need to use the root account for system administration tasks.

Warning

Be careful to remove only the necessary Red Hat Enterprise Linux partitions. Removing other partitions could result in data loss or a corrupted system environment.

2. More to Come

The Red Hat Enterprise Linux Security Guide is part of Red Hat’s growing commitment to provide useful and timely support and information to Red Hat Enterprise Linux users. As new tools and security methodologies are released, this guide will be expanded to include them.

Introduction v

2.1. Send in Your Feedback

If you spot a typo in the Red Hat Enterprise Linux Security Guide, or if you have thought of a way to make this manual better, we would love to hear from you! Submit a report in Bugzilla (http://bugzilla.redhat.com/bugzilla/) against the component rhel-sg.

Be sure to mention the manual’s identiﬁer:

rhel-sg(EN)-3-Print-RHI (2003-07-25T17:12)

By mentioning the identiﬁer, we know exactly which version of the guide you have.

If you have a suggestion for improving the documentation, try to be as speciﬁc as possible. If you have found an error, include the section number and some of the surrounding text so we can ﬁnd it easily.

vi Introduction

I. A General Introduction to Security

This part deﬁnes information security, its history, and the industry that has developed to address it. It also discusses some of the risks that computer users or administrators face.

Table of Contents

1. Security Overview...........................................................................................................................1

2. Attackers and Vulnerabilities ........................................................................................................ 7

Chapter 1.

Security Overview

Because of the increased reliance on powerful, networked computers to help run businesses and keep track of our personal information, industries have been formed around the practice of network and computer security. Enterprises have solicited the knowledge and skills of security experts to properly audit systems and tailor solutions to ﬁt the operating requirements of the organization. Because most organizations are dynamic in nature, with workers accessing company IT resources locally and remotely, the need for secure computing environments has become more pronounced.

Unfortunately, most organizations (as well as individual users) regard security as an afterthought, a process that is overlooked in favor of increased power, productivity, and budgetary concerns. Proper security implementation is often enacted postmortem — after an unauthorized intrusion has already occurred. Security experts agree that the right measures taken prior to connecting a site to an untrusted network such as the Internet is an effective means of thwarting most attempts at intrusion.

1.1. What is Computer Security?

Computer security is a general term that covers a wide area of computing and information processing. Industries that depend on computer systems and networks to conduct daily business transactions and access crucial information regard their data as an important part of their overall assets. Several terms and metrics have entered our daily business vocabulary, such as total cost of ownership (TCO) and quality of service (QoS). In these metrics, industries calculate aspects such as data integrity and high-availability as part of their planning and process management costs. In some industries, such as electronic commerce, the availability and trustworthiness of data can be the difference between success and failure.

1.1.1. How did Computer Security Come about?

Many readers may recall the movie "Wargames," starring Matthew Broderick in his portrayal of a high school student who breaks into the United States Department of Defense (DoD) supercomputer and inadvertently causes a nuclear war threat. In this movie, Broderick uses his modem to dial into the DoD computer (called WOPR) and plays games with the artiﬁcially intelligent software controlling all of the nuclear missile silos. The movie was released during the "cold war" between the former Soviet Union and the United States and was considered a success in its theatrical release in 1983. The popularity of the movie inspired many individuals and groups to begin implementing some of the methods that the young protagonist used to crack restricted systems, including what is known as war dialing — a method of searching phone numbers for analog modem connections in a deﬁned area code and phone preﬁx combination.

More than 10 years later, after a four-year, multi-jurisdictional pursuit involving the Federal Bureau of Investigation (FBI) and the aid of computer professionals across the country, infamous computer cracker Kevin Mitnick was arrested and charged with 25 counts of computer and access device fraud that resulted in an estimated US$80 Million in losses of intellectual property and source code from Nokia, NEC, Sun Microsystems, Novell, Fujitsu, and Motorola. At the time, the FBI considered it the largest computer-related criminal offense in U.S. history. He was convicted and sentenced to a combined 68 months in prison for his crimes, of which he served 60 months before his parole on January 21, 2000. He was further barred from using computers or doing any computer-related consulting until

2003. Investigators say that Mitnick was an expert in social engineering — using human beings to gain access to passwords and systems using falsiﬁed credentials.

Information security has evolved over the years due to the increasing reliance on public networks to disclose personal, ﬁnancial, and other restricted information. There are numerous instances such as the Mitnick and the Vladimir Levin case (refer to Section 1.1.2 Computer Security Timeline for

2 Chapter 1. Security Overview

more information) that prompted organizations across all industries to rethink the way they handle information transmission and disclosure. The popularity of the Internet was one of the most important developments that prompted an intensiﬁed effort in data security.

An ever-growing number of people are using their personal computers to gain access to the resources that the Internet has to offer. From research and information retrieval to electronic mail and commerce transaction, the Internet has been regarded as one of the most important developments of the 20th century.

The Internet and its earlier protocols, however, were developed as a trust-based system. That is, the Internet Protocol was not designed to be secure in itself. There are no approved security standards built into the TCP/IP communications stack, leaving it open to potentially malicious users and processes across the network. Modern developments have made Internet communication more secure, but there are still several incidents that gain national attention and alert us to the fact that nothing is completely safe.

1.1.2. Computer Security Timeline

Several key events contributed to the birth and rise of computer security. The following lists some of the most important events that brought attention to computer and information security and its importance today.

1.1.2.1. The 1960s

• Students at the Massachusetts Institute of Technology (MIT) form the Tech Model Railroad Club

(TMRC) begin exploring and programming the school’s PDP-1 mainframe computer system. The group eventually use the term "hacker" in the context it is known today.

• The DoD creates the Advanced Research Projects Agency Network (ARPANet), which gains pop-

ularity in research and academic circles as a conduit for the electronic exchange of data and information. This paves the way for the creation of the carrier network known today as the Internet.

• Ken Thompson develops the UNIX operating system, widely hailed as the most "hacker-friendly"

OS because of its accessible developer tools and compilers, and its supportive user community. Around the same time, Dennis Ritchie develops the C programming language, arguably the most popular hacking language in computer history.

1.1.2.2. The 1970s

• Bolt, Beranek, and Newman, a computing research and development contractor for government

and industry, develops the Telnet protocol, a public extension of the ARPANet. This opens doors to public use of data networks once restricted to government contractors and academic researchers. Telnet, though, is also arguably the most insecure protocol for public networks, according to several security researchers.

• Steve Jobs and Steve Wozniak found Apple Computer and begin marketing the Personal Computer

(PC). The PC is the springboard for several malicious users to learn the craft of cracking systems remotely using common PC communication hardware such as analog modems and war dialers.

• Jim Ellis and Tom Truscott create USENET, a bulletin-board style system for electronic commu-

nication between disparate users. USENET quickly becomes one the most popular forums for the exchange of ideas in computing, networking, and, of course, cracking.

Chapter 1. Security Overview 3

1.1.2.3. The 1980s

• IBM develops and markets PCs based on the Intel 8086 microprocessor, a relatively inexpensive

architecture that brought computing from the ofﬁce to the home. This serves to commodify the PC as a common and accessible tool that was fairly powerful and easy to use, aiding in the proliferation of such hardware in the homes and ofﬁces of malicious users.

• The Transmission Control Protocol, developed by Vint Cerf, is split into two separate parts. The

Internet Protocol is born from this split, and the combined TCP/IP protocol becomes the standard for all Internet communication today.

• Based on developments in the area of phreaking, or exploring and hacking the telephone system, the

magazine 2600: The Hacker Quarterly is created and begins discussion on topics such as cracking computers and computer networks to a broad audience.

• The 414 gang (named after the area code where they lived and hacked from) are raided by author-

ities after a nine-day cracking spree where they break into systems from such top-secret locations as the Los Alamos National Laboratory, a nuclear weapons research facility.

• The Legion of Doom and the Chaos Computer Club are two pioneering cracker groups that begin

exploiting vulnerabilities in computers and electronic data networks.

• The Computer Fraud and Abuse Act of 1986 was voted into law by congress based on the exploits of

Ian Murphy, also known as Captain Zap, who broke into military computers, stole information from company merchandise order databases, and used restricted government telephone switchboards to make phone calls.

• Based on the Computer Fraud and Abuse Act, the courts were able to convict Robert Morris, a

graduate student, for unleashing the Morris Worm to over 6,000 vulnerable computers connected to the Internet. The next most prominent case ruled under this act was Herbert Zinn, a high-school dropout who cracked and misused systems belonging to AT&T and the DoD.

• Based on concerns that the Morris Worm ordeal could be replicated, the Computer Emergency

Response Team (CERT) is created to alert computer users of network security issues.

• Clifford Stoll writes The Cuckoo’s Egg, Stoll’s account of investigating crackers who exploit his

system.

1.1.2.4. The 1990s

• ARPANet is decommissioned. Trafﬁc from that network is transferred to the Internet.

• Linus Torvalds develops the Linux kernel for use with the GNU operating system; the widespread

development and adoption of Linux is largely due to the collaboration of users and developers communicating via the Internet. Because of its roots in UNIX, Linux is most popular among hackers and administrators who found it quite useful for building secure alternatives to legacy servers running proprietary (closed-source) operating systems.

• The graphical Web browser is created and sparks an exponentially higher demand for public Internet

access.

• Vladimir Levin and accomplices illegally transfer US$10 Million in funds to several accounts by

cracking into the CitiBank central database. Levin is arrested by Interpol and almost all of the money is recovered.

• Possibly the most heralded of all crackers is Kevin Mitnick, who hacked into several corporate sys-

tems, stealing everything from personal information of celebrities to over 20,000 credit card numbers and source code for proprietary software. He is arrested and convicted of wire fraud charges and serves 5 years in prison.

4 Chapter 1. Security Overview

• Kevin Poulsen and an unknown accomplice rig radio station phone systems to win cars and cash

prizes. He is convicted for computer and wire fraud and is sentenced to 5 years in prison.

• The stories of cracking and phreaking become legend, and several prospective crackers convene at

the annual DefCon convention to celebrate cracking and exchange ideas between peers.

• A 19-year-old Israeli student is arrested and convicted for coordinating numerous break-ins to US

government systems during the Persian-Gulf conﬂict. Military ofﬁcials call it "the most organized and systematic attack" on government systems in US history.

• US Attorney General Janet Reno, in response to escalated security breaches in government systems,

establishes the National Infrastructure Protection Center.

• British communications satellites are taken over and ransomed by unknown offenders. The British

government eventually seizes control of the satellites.

1.1.3. Security Today

In February of 2000, a Distributed Denial of Service (DDoS) attack was unleashed on several of the most heavily-trafﬁcked sites on the Internet. The attack rendered yahoo.com, cnn.com, amazon.com, fbi.gov, and several other sites completely unreachable to normal users, as it tied up routers for several hours with large-byte ICMP packet transfers, also called a ping ﬂood . The attack was brought on by unknown assailants using specially created, widely available programs that scanned vulnerable network servers, installed client applications called trojans on the servers, and timed an attack with every infected server ﬂooding the victim sites and rendering them unavailable. Many blame the attack on fundamental ﬂaws in the way routers and the protocols used are structured to accept all incoming data, no matter where or for what purpose the packets are sent.

This brings us to the new millennium, a time where an estimated 400 Million people use or have used the Internet worldwide. At the same time:

• On any given day, there are approximately 225 major incidences of security breach reported to the

CERT Coordination Center at Carnegie Mellon University. [source: http://www.cert.org]

• In 2002, the number of CERT reported incidences jumped to 82,094 from 52,658 in 2001. As of

this writing, the number of incidences reported in only the ﬁrst quarter of 2003 is 42,586. [source: http://www.cert.org]

• The worldwide economic impact of the three most dangerous Internet Viruses of the last two years

was estimated at US$13.2 Billion. [source: http://www.newsfactor.com/perl/story/16407.html]

Computer security has become a quantiﬁable and justiﬁable expense for all IT budgets. Organizations that require data integrity and high availability elicit the skills of system administrators, developers, and engineers to ensure 24x7 reliability of their systems, services, and information. To fall victim to malicious users, processes, or coordinated attacks is a direct threat to the success of the organization.

Unfortunately, system and network security can be a difﬁcult proposition, requiring an intricate knowledge of how an organization regards, uses, manipulates, and transmits its information. Understanding the way an organization (and the people that make up the organization) conducts business is paramount to implementing a proper security plan.

1.1.4. Standardizing Security

Enterprises in every industry rely on regulations and rules that are set by standards making bodies such as the American Medical Association (AMA) or the Institute of Electrical and Electronics Engineers (IEEE). The same ideals hold true for information security. Many security consultants and vendors agree upon the standard security model known as CIA, or Conﬁdentiality, Integrity, and Availability.

Chapter 1. Security Overview 5

This three-tiered model is a generally accepted component to assessing risks of sensitive information and establishing security policy. The following describes the CIA model in further detail:

• Conﬁdentiality — Sensitive information must be available only to a set of pre-deﬁned individuals.

Unauthorized transmission and usage of information should be restricted. For example, conﬁdentiality of information ensures that a customer’s personal or ﬁnancial information is not obtained by an unauthorized individual for malicious purposes such as identity theft or credit fraud.

• Integrity — Information should not be altered in ways that render it incomplete or incorrect. Unau-

thorized users should be restricted from the ability to modify or destroy sensitive information.

• Availability — Information should be accessible to authorized users any time that it is needed.

Availability is a warranty that information can be obtained with an agreed-upon frequency and timeliness. This is often measured in terms of percentages and agreed to formally in Service Level Agreements (SLAs) used by network service providers and their enterprise clients.

1.2. Security Controls

Computer security is often divided into three distinct master categories, commonly referred to as controls:

• Physical

• Technical

• Administrative

These three broad categories deﬁne the main objectives of proper security implementation. Within these controls are sub-categories that further detail the controls and how to implement them.

1.2.1. Physical Controls

The Physical control is the implementation of security measures in a deﬁned structure used to deter or prevent unauthorized access to sensitive material. Examples of physical controls are:

• Closed-circuit surveillance cameras

• Motion or thermal alarm systems

• Security guards

• Picture IDs

• Locked and dead-bolted steel doors

1.2.2. Technical Controls

The Technical control uses technology as a basis for controlling the access and usage of sensitive data throughout a physical structure and over a network. Technical controls are far-reaching in scope and encompass such technologies as:

• Encryption

• Smart cards

• Network authentication

• Access control lists (ACLs)

6 Chapter 1. Security Overview

• File integrity auditing software

1.2.3. Administrative Controls

Administrative controls deﬁne the human factors of security. It involves all levels of personnel within an organization and determines which users have access to what resources and information by such means as:

• Training and awareness

• Disaster preparedness and recovery plans

• Personnel recruitment and separation strategies

• Personnel registration and accounting

1.3. Conclusion

Now that you have learned about the origins, reasons, and aspects of security, you can determine the appropriate course of action with regards to Red Hat Enterprise Linux. It is important to know what factors and conditions make up security in order to plan and implement a proper strategy. With this information in mind, the process can be formalized and the path becomes clearer as you delve deeper into the speciﬁcs of the security process.

Chapter 2.

Attackers and Vulnerabilities

To plan and implement a good security strategy, ﬁrst be aware of some of the issues which determined, motivated attackers exploit to compromise systems. But before detailing these issues, the terminology used when identifying an attacker must be deﬁned.

2.1. A Quick History of Hackers

The modern meaning of the term hacker has origins dating back to the 1960s and the Massachusetts Institute of Technology (MIT) Tech Model Railroad Club, which designed train sets of large scale and intricate detail. Hacker was a name used for club members who discovered a clever trick or workaround for a problem.

The term hacker has since come to describe everything from computer buffs to gifted programmers. A common trait among most hackers is a willingness to explore in detail how computer systems and networks function with little or no outside motivation. Open source software developers often consider themselves and their colleagues to be hackers, and use the word as a term of respect.

Typically, hackers follow a form of the hacker ethic which dictates that the quest for information and expertise is essential, and that sharing this knowledge is the hackers duty to the community. During this quest for knowledge, some hackers enjoy the academic challenges of circumventing security controls on computer systems. For this reason, the press often uses the term hacker to describe those who illicitly access systems and networks with unscrupulous, malicious, or criminal intent. The more accurate term for this type of computer hacker is cracker — a term created by hackers in the mid1980s to differentiate the two communities.

2.1.1. Shades of Grey

Within the community of individuals who ﬁnd and exploit vulnerabilities in systems and networks are several distinct groups. These groups are often described by the shade of hat that they "wear" when performing their security investigations and this shade is indicative of their intent.

The white hat hacker is one who tests networks and systems to examine their performance and determine how vulnerable they are to intrusion. Usually, white hat hackers crack their own systems or the systems of a client who has speciﬁcally employed them for the purposes of security auditing. Academic researchers and professional security consultants are two examples of white hat hackers.

A black hat hacker is synonymous with a cracker. In general, crackers are less focused on programming and the academic side of breaking into systems. They often rely on available cracking programs and exploit well known vulnerabilities in systems to uncover sensitive information for personal gain or to inﬂict damage on the target system or network.

The grey hat hacker, on the other hand, has the skills and intent of a white hat hacker in most situations but uses his knowledge for less than noble purposes on occasion. A grey hat hacker can be thought of as a white hat hacker who wears a black hat at times to accomplish his own agenda.

Grey hat hackers typically subscribe to another form of the hacker ethic, which says it is acceptable to break into systems as long as the hacker does not commit theft or breach conﬁdentiality. Some would argue, however that the act of breaking into a system is in itself unethical.

Regardless of the intent of the intruder, it is important to know the weaknesses a cracker may likely attempt to exploit. The remainder of the chapter focuses on these issues.

8 Chapter 2. Attackers and Vulnerabilities

2.2. Threats to Network Security

Bad practices when conﬁguring the following aspects of a network can increase the risk of attack.

2.2.1. Insecure Architectures

A misconﬁgured network is a primary entry point for unauthorized users. Leaving a trust-based, open local network vulnerable to the highly-insecure Internet is much like leaving a door ajar in a crimeridden neighborhood — nothing may happen for an arbitrary amount of time, but eventually someone will exploit the opportunity.

2.2.1.1. Broadcast Networks

System administrators often fail to realize the importance of networking hardware in their security schemes. Simple hardware such as hubs and routers rely on the broadcast or non-switched principle; that is, whenever a node transmits data across the network to a recipient node, the hub or router sends a broadcast of the data packets until the recipient node receives and processes the data. This method is the most vulnerable to address resolution protocol (arp) or media access control (MAC) address spooﬁng by both outside intruders and unauthorized users on local nodes.

2.2.1.2. Centralized Servers

Another potential networking pitfall is the use of centralized computing. A common cost-cutting measure for many businesses is to consolidate all services to a single powerful machine. This can be convenient as it is easier to manage and costs considerably less than multiple-server conﬁgurations. However, a centralized server introduces a single point of failure on the network. If the central server is compromised, it may render the network completely useless or worse, prone to data manipulation or theft. In these situations a central server becomes an open door, allowing access to the entire network.

2.3. Threats to Server Security

Server security is as important as network security because servers often hold a great deal of an organization’s vital information. If a server is compromised, all of its contents may become available for the cracker to steal or manipulate at will. The following sections detail some of the main issues.

2.3.1. Unused Services and Open Ports

A full installation of Red Hat Enterprise Linux contains up to 1200 application and library packages. However, most server administrators do not opt to install every single package in the distribution, preferring instead to install a base installation of packages, including several server applications.

A common occurrence among system administrators is to install the operating system without paying attention to what programs are actually being installed. This can be problematic because unneeded services may be installed, conﬁgured with the default settings, and possibly turned on. This can cause unwanted services, such as Telnet, DHCP, or DNS, to run on a server or workstation without the administrator realizing it, which in turn can cause unwanted trafﬁc to the server, or even, a potential pathway into the system for crackers. Refer To Chapter 5 Server Security for information on closing ports and disabling unused services.

Chapter 2. Attackers and Vulnerabilities 9

2.3.2. Unpatched Services

Most server applications that are included in a default installation are solid, thoroughly tested pieces of software. Having been in use in production environments for many years, their code has been thoroughly reﬁned and many of the bugs have been found and ﬁxed.

However, there is no such thing as perfect software and there is always room for further reﬁnement. Moreover, newer software is often not as rigorously tested as one might expect, because of its recent arrival to production environments or because it may not be as popular as other server software.

Developers and system administrators often ﬁnd exploitable bugs in server applications and publish the information on bug tracking and security-related websites such as the Bugtraq mailing list (http://www.securityfocus.com) or the Computer Emergency Response Team (CERT) website (http://www.cert.org). Although these mechanisms are an effective way of alerting the community to security vulnerabilities, it is up to system administrators to patch their systems promptly. This is particularly true because crackers have access to these same vulnerability tracking services and will use the information to crack unpatched systems whenever they can. Good system administration requires vigilance, constant bug tracking, and proper system maintenance to ensure a more secure computing environment.

Refer to Chapter 3 Security Updates for more information about keeping a system up-to-date.

2.3.3. Inattentive Administration

Administrators who fail to patch their systems are one of the greatest threats to server security. According to the System Administration Network and Security Institute (SANS), the primary cause of computer security vulnerability is to "assign untrained people to maintain security and provide neither the training nor the time to make it possible to do the job."1This applies as much to inexperienced administrators as it does to overconﬁdent or amotivated administrators.

Some administrators fail to patch their servers and workstations, while others fail to watch log messages from the system kernel or network trafﬁc. Another common error is to leave unchanged default passwords or keys to services. For example, some databases have default administration passwords because the database developers assume that the system administrator changes these passwords immediately after installation. If a database administrator fails to change this password, even an inexperienced cracker can use a widely-known default password to gain administrative privileges to the database. These are only a few examples of how inattentive administration can lead to compromised servers.

2.3.4. Inherently Insecure Services

Even the most vigilant organization can fall victim to vulnerabilities if the network services they choose are inherently insecure. For instance, there are many services developed under the assumption that they are used over trusted networks; however, this assumption fails as soon as the service becomes available over the Internet — which is itself inherently untrusted.

One category of insecure network services are those that require unencrypted usernames and passwords for authentication. Telnet and FTP are two such services. If packet snifﬁng software is monitoring trafﬁc between the remote user and such a service usernames and passwords can be easily intercepted.

Inherently, such services can also more easily fall prey to what the security industry terms the man- in-the-middle attack. In this type of attack, a cracker redirects network trafﬁc by tricking a cracked name server on the network to point to his machine instead of the intended server. Once someone opens a remote session to the server, the attacker’s machine acts as an invisible conduit, sitting quietly

1. Source: http://www.sans.org/newlook/resources/errors.html

10 Chapter 2. Attackers and Vulnerabilities

between the remote service and the unsuspecting user capturing information. In this way a cracker can gather administrative passwords and raw data without the server or the user realizing it.

Another category of insecure services include network ﬁle systems and information services such as NFS or NIS, which are developed explicitly for LAN usage but are, unfortunately, extended to include WANs (for remote users). NFS does not, by default, have any authentication or security mechanisms conﬁgured to prevent a cracker from mounting the NFS share and accessing anything contained therein. NIS, as well, has vital information that must be known by every computer on a network, including passwords and ﬁle permissions, within a plain text ACSII or DBM (ASCII-derived) database. A cracker whogains access to this database can then access every user account on a network, including the administrator’s account.

By default, Red Hat turns off such services. However, since administrators often ﬁnd themselves forced to use these services, careful conﬁguration is critical. Refer to Chapter 5 Server Security for more information about setting up services in a safe manner.

2.4. Threats to Workstation and Home PC Security

Workstations and home PCs may not be as prone to attack as networks or servers, but since they often contain sensitive data, such as credit card information, they are targeted by system crackers. Workstations can also be co-opted without the user’s knowledge and used by attackers as "slave" machines in coordinated attacks. For these reasons, knowing the vulnerabilities of a workstation can save users the headache of reinstalling the operating system, or worse, recovering from data theft.

2.4.1. Bad Passwords

Bad passwords are one of the easiest ways for an attacker to gain access to a system. For more on how to avoid common pitfalls when creating a password, Refer to Section 4.3 Password Security.

2.4.2. Vulnerable Client Applications

Although an administrator may have a fully secure and patched server, that does not mean remote users are secure when accessing it. For instance, if the server offers Telnet or FTP services over a public network, an attacker can capture the plain text usernames and passwords as they pass over the network, and then use the account information to access the remote user’s workstation.

Even when using secure protocols, such as SSH, a remote user may be vulnerable to certain attacks if they do not keep their client applications updated. For instance, v.1 SSH clients are vulnerable to an X-forwarding attack from malicious SSH servers. Once connected to the server, the attacker can quietly capture any keystrokes and mouse clicks made by the client over the network. This problem was ﬁxed in the v.2 SSH protocol, but it is up to the user to keep track of what applications have such vulnerabilities and update them as necessary.

Chapter 4 Workstation Security discusses in more detail what steps administrators and home users should take to limit the vulnerability of computer workstations.

II. Conﬁguring Red Hat Enterprise Linux for Security

This part informs and instructs administrators on proper techniques and tools to use when securing Red Hat Enterprise Linux workstations, Red Hat Enterprise Linux servers, and network resources. It also discusses how to make secure connections, lock down ports and services, and implement active ﬁltering to prevent network intrusion.

Table of Contents

3. Security Updates ........................................................................................................................... 13

4. Workstation Security ....................................................................................................................19

5. Server Security ..............................................................................................................................37

6. Virtual Private Networks .............................................................................................................51

7. Firewalls......................................................................................................................................... 65

Chapter 3.

Security Updates

As security vulnerabilities are discovered, the effected software must be updated in order to limit any potential security risks. If the software is part of a package within an Red Hat Enterprise Linux distribution that is currently supported, Red Hat, Inc. is committed to releasing updated packages that ﬁx the vulnerability as soon as possible. Often, announcements about a given security exploit are accompanied with a patch (or source code that ﬁxes the problem). This patch is then applied to the Red Hat Enterprise Linux package, tested by the Red Hat quality assurance team, and released as an errata update. However, if an announcement does not include a patch, a Red Hat developer works with the maintainer of the software to ﬁx the problem. Once the problem is ﬁxed, the package is tested and released as an errata update.

If an errata update is released for software used on your system, it is highly recommended that you update the effected packages as soon as possible to minimize the amount of time system is potentially vulnerable.

3.1. Updating Packages

When updating software on a system, it is important to download the update from a trusted source. An attacker can easily rebuild a package with the same version number as the one that is supposed to ﬁx the problem but with a different security exploit and release it on the Internet. If this happens, using security measures such as verifying ﬁles against the original RPM does not detect the exploit. Thus, it is very important to only download RPMs from trusted sources, such as from Red Hat, Inc. and check the signature of the package to verify its integrity.

Red Hat offers two ways to retrieve security errata updates:

1. Download them from Red Hat Network.

2. Download them from the Red Hat Errata website.

3.1.1. Using Red Hat Network

Red Hat Network allows the majority of the update process to be automated. It determines which RPM packages are necessary for the system, downloads them from a secure repository, veriﬁes the RPM signature to make sure they have not been tampered with, and updates them. The package install can occur immediately or can be scheduled during a certain time period.

Red Hat Network requires a System Proﬁle for each machine to be updated. The System Proﬁle contains hardware and software information about the system. This information is kept conﬁdential and not given to anyone else. It is only used to determine which errata updates are applicable to each system, and, without it, Red Hat Network can not determine whether a given system needs updates. When a security errata (or any type of errata) is released, Red Hat Network sends an email with a description of the errata as well as a list of systems which are affected. To apply the update, use the Red Hat Update Agent or schedule the package to be updated through the website http://rhn.redhat.com.

Tip

Red Hat Enterprise Linux includes the Red Hat Network Alert Notiﬁcation Tool, a convenient panel icon that displays visible alerts when there is an update for a Red Hat Enterprise Linux system. Refer to the following URL for more information about the applet: http://rhn.redhat.com/help/basic/applet.html

14 Chapter 3. Security Updates

To learn more about the beneﬁts of Red Hat Network, refer to the Red Hat Network Reference Guide available at http://www.redhat.com/docs/manuals/RHNetwork/ or visit http://rhn.redhat.com.

Important

Before installing any security errata, be sure to read any special instructions contained in the errata report and execute them accordingly. Refer to Section 3.1.3 Applying the Changes for general instructions about applying the changes made by an errata update.

3.1.2. Using the Red Hat Errata Website

When security errata reports are released, they are published on the Red Hat Errata website available at http://www.redhat.com/apps/support/errata/. From this page, select the product and version for your system, and then select security at the top of the page to display only Red Hat Enterprise Linux Security Advisories. If the synopsis of one of the advisories describes a package used on your system, click on the synopsis for more details.

The details page describes the security exploit and any special instructions that must be performed in addition to updating the package to ﬁx the security hole.

To download the updated package(s), click on the package name(s) and save to the hard drive. It is highly recommended that you create a new directory, such as /tmp/updates, and save all the downloaded packages to it.

All Red Hat Enterprise Linux packages are signed with the Red Hat, Inc. GPG key. The RPM utility within Red Hat Enterprise Linux automatically tries to verify the GPG signature of an RPM package before installing it. If the Red Hat, Inc. GPG key is not installed, install it from a secure, static location such as an Red Hat Enterprise Linux installation CD-ROM.

Assuming the CD-ROM is mounted in /mnt/cdrom, use the following command to import it into the keyring:

rpm --import /mnt/cdrom/RPM-GPG-KEY

To display a list of all keys installed for RPM veriﬁcation, execute the following command:

rpm -qa gpg-pubkey*

For the Red Hat, Inc. key, the output includes the following:

gpg-pubkey-db42a60e-37ea5438

To display details about a speciﬁc key, use the rpm -qi command followed by the output from the previous command, as in this example:

rpm -qi gpg-pubkey-db42a60e-37ea5438

It is extremely important to verify the signature of the RPM ﬁles before installing them to ensure that they have not been altered from the Red Hat, Inc. release of the packages. To verify all the downloaded packages at once, issue the following command:

rpm -K /tmp/updates/*.rpm

For each package, if the GPG key veriﬁes successfully, the command returns gpg OK.

Chapter 3. Security Updates 15

After verifying the GPG key and downloading all the packages associated with the errata report, install the packages as root at a shell prompt.

This can be done safely for most packages (except kernel packages) by issuing the following command:

rpm -Uvh /tmp/updates/*.rpm

For kernel packages it is advised that the following command be used:

rpm -ivh /tmp/updates/



kernel-package



Replacekernel-packagein the previous example with the name of the kernel RPM.

Once the machine has been safely rebooted using the new kernel, the old kernel may be removed using the following command:



rpm -e

old-kernel-package



Replaceold-kernel-packagein the previous example with the name of the older kernel RPM.

Note

It is not a requirement that the old kernel be removed.

Important

3.1.3. Applying the Changes

After downloading and installing security errata via Red Hat Network or the Red Hat errata website, it is important to halt usage of the older software and begin using the new software. How this is done depends on the type of software that has been updated. The following list itemizes the general categories of software and provides instructions for using the updated versions after a package upgrade.

Note

In general, rebooting the system is the surest way to ensure that the latest version of a software package is used; however, this option is not always available to the system administrator.

16 Chapter 3. Security Updates

Applications

User-space applications are any programs which can be initiated by a system user. Typically, such applications are used only when a user, script, or automated task utility launches them and do not persist for long periods of time.

Once such a user-space application is updated, halt any instances of the application on the system and launch the program again to use the updated version.

Kernel

The kernel is the core software component for the Red Hat Enterprise Linux operating system. It manages access to memory, the processor, and peripherals as well as schedules all tasks.

Because of its central role, the kernel cannot be restarted without also stopping the computer. Therefore, an updated version of the kernel cannot be used until the system is rebooted.

Shared Libraries

Shared libraries are units of code, such as glibc, which are used by a number of applications and services. Applications utilizing a shared library typically load the shared code when the application is initialized, so any applications using the updated library must be halted and relaunched.

Todetermine which running applications link against a particular library, use the lsof command, as in the following example:

lsof /usr/lib/libwrap.so*

This command returns a list of all the running programs which use TCP wrappers for host access control. Therefore, any program listed must be halted and relaunched if the tcp_wrappers package is updated.

SysV Services

SysV services are persistent server programs launched during the boot process. Examples of SysV services include sshd, vsftpd, and xinetd.

Because these programs usually persist in memory as long as the machine is booted, each updated SysV service must be halted and relaunched after the package is upgraded. This can be done using the Services Conﬁguration Tool or by logging into a root shell prompt and issuing the

/sbin/service command as in the following example:

/sbin/service

service-namerestart



In the previous example, replaceservice-namewith the name of the service, such as

sshd.

Refer to the chapter titled Controlling Access to Services in the Red Hat Enterprise Linux System Administration Guide for more information regarding the Services Conﬁguration Tool.

xinetd Services

Services controlled by the xinetd super service only run when a there is an active connection. Examples of services controlled by xinetd include Telnet, IMAP, and POP3.

Because new instances of these services are launched by xinetd each time a new request is received, connections that occur after an upgrade are handled by the updated software. However, if there are active connections at the time the xinetd controlled service is upgraded, they are serviced by the older version of the software.

To kill off older instances of a particular xinetd controlled service, upgrade the package for the service then halt all processes currently running by ﬁrst determining if the process is running using the ps command and then using the kill or killall command to halt current instances of the service.

For example, if security errata imap packages are released, upgrade the packages, then type the following command as root into a shell prompt:

Chapter 3. Security Updates 17

ps -aux | grep imap

This command returns all active IMAP sessions. Individual sessions can then be terminated by issuing the following command:





kill -9

PID

In the previous example, replacePIDwith the process identiﬁcation number for an IMAP session.

To kill all active IMAP sessions, issue the following command:

killall imapd

Refer to the chapter titled TCP Wrappers and xinetd in the Red Hat Enterprise Linux Reference Guide for general information regarding xinetd.

18 Chapter 3. Security Updates

Chapter 4.

Workstation Security

Securing a Linux environment begins with the workstation. Whether locking down a personal machine or securing an enterprise system, sound security policy begins with the individual computer. After all, a computer network is only as secure as the weakest node.

4.1. Evaluating Workstation Security

When evaluating the security of a Red Hat Enterprise Linux workstation, consider the following:

• BIOS and Boot Loader Security — Can an unauthorized user physically access the machine and

boot into single user or rescue mode without a password?

• Password Security — How secure are the user account passwords on the machine?

• Administrative Controls — Who has an account on the system and how much administrative control

do they have?

• Available Network Services — What services are listening for requests from the network and should

they be running at all?

• Personal Firewalls — What type of ﬁrewall, if any, is necessary?

• Security Enhanced Communication Tools — Which tools should be used to communicate between

workstations and which should be avoided?

4.2. BIOS and Boot Loader Security

Password protection for the BIOS (or BIOS equivalent) and the boot loader can prevent unauthorized users who have physical access to systems from booting using removable media or attaining root through single user mode. But the security measures one should take to protect against such attacks depends both on the sensitivity of the information the workstation holds and the location of the machine.

For instance, if a machine is used in a trade show and contains no sensitive information, than it may not be critical to prevent such attacks. However, if an employee’s laptop with private, unencrypted SSH keys for the corporate network is left unattended at that same trade show, it could lead to a major security breech with ramiﬁcations for the entire company.

On the other hand, if the workstation is located in a place where only authorized or trusted people have access, then securing the BIOS or the boot loader may not be necessary at all.

4.2.1. BIOS Passwords

The following are the two primary reasons for password protecting the BIOS of a computer1:

1. Preventing Changes to BIOS Settings — If an intruder has access to the BIOS, they can set it to boot off of a diskette or CD-ROM. This makes it possible for them to enter rescue mode or single user mode, which in turn allows them to seed nefarious programs on the system or copy sensitive data.

1. Since system BIOSes differ between manufacturers, some may not support password protection of either

type, while others may support one type but not the other.

20 Chapter 4. Workstation Security

2. Preventing System Booting — Some BIOSes allow password protection of the boot process. When activated, an attacker is forced to enter a password before the BIOS launches the boot loader.

Because the methods for setting a BIOS password vary between computer manufacturers, consult the computer’s manual for speciﬁc instructions.

If you forget the BIOS password, it can either be reset with jumpers on the motherboard or by disconnecting the CMOS battery. For this reason, it is good practice to lock the computer case if possible. However, consult the manual for the computer or motherboard before attempting this procedure.

4.2.1.1. Securing Non-x86 Platforms

Other architectures use different programs to perform low-level tasks roughly equivalent to those of the BIOS on x86 systems. For instance, Intel® Itanium™ computers use the Extensible Firmware Interface (EFI) shell.

For instructions on password protecting BIOS-like programs on other architectures, refer to the manufacturer’s instructions.

4.2.2. Boot Loader Passwords

The following are the primary reasons for password protecting a Linux boot loader:

1. Preventing Access to Single User Mode — If an attacker can boot into single user mode, he becomes the root user.

2. Preventing Access to the GRUB Console — If the machine uses GRUB as its boot loader, an attacker can use the use the GRUB editor interface to change its conﬁguration or to gather information using the cat command.

3. Preventing Access to Non-Secure Operating Systems — If it is a dual-boot system, an attacker can select at boot time an operating system, such as DOS, which ignores access controls and ﬁle permissions.

There are two boot loaders that ship with Red Hat Enterprise Linux for the x86 platform, GRUB and LILO. For a detailed look at each of these boot loaders, consult the chapter titled Boot Loaders in the Red Hat Enterprise Linux Reference Guide.

4.2.2.1. Password Protecting GRUB

GRUB can be conﬁgured to address the ﬁrst two issues listed in Section 4.2.2 Boot Loader Passwords by adding a password directive to its conﬁguration ﬁle. To do this, ﬁrst decide on a password, then open a shell prompt, log in as root, and type:

/sbin/grub-md5-crypt

When prompted, type the GRUB password and press [Enter]. This returns an MD5 hash of the password.

Next, edit the GRUB conﬁguration ﬁle /boot/grub/grub.conf. Open the ﬁle and below the

timeout line in the main section of the document, add the following line:

password --md5password-hash



Chapter 4. Workstation Security 21

Replacepassword-hashwith the value returned by /sbin/grub-md5-crypt2.

The next time the system boots, the GRUB menu does not allow access to the editor or command interface without ﬁrst pressing [p] followed by the GRUB password.

Unfortunately, this solution does not prevent an attacker from booting into a non-secure operating system in a dual-boot environment. For this, a different part of the /boot/grub/grub.conf ﬁle must be edited.

Look for the title line of the non-secure operating system and add a line that says lock directly beneath it.

For a DOS system, the stanza should begin similar to the following:

title DOS lock

Warning

A password line must be present in the main section of the /boot/grub/grub.conf ﬁle for this method to work properly. Otherwise, an attacker can access the GRUB editor interface and remove the lock line.

To create a different password for a particular kernel or operating system, add a lock line to the stanza followed by a password line.

Each stanza protected with a unique password should begin with lines similar to the following example:

title DOS lock password --md5



password-hash



4.2.2.2. Password Protecting LILO

LILO is a much simpler boot loader than GRUB and does not offer a command interface, so an attacker cannot gain interactive access to the system before the kernel is loaded. However, it is still possible for an attacker to boot into single-user mode or into an insecure operating system.

Password protecting LILOcan be accomplished by adding a password directive in to the global section of its conﬁguration ﬁle. To do this, open a shell prompt, log in as root, and edit /etc/lilo.conf. Before the ﬁrst image stanza, add a password directive similar to the following example:

password=



password



In the above directive, replacepasswordwith the password for LILO.

2. GRUB also accepts unencrypted passwords, but it is recommended that an md5 hash be used for added

security.

22 Chapter 4. Workstation Security

Important

When editing /etc/lilo.conf, the /sbin/lilo -v -v command must be run for the changes to take effect. If a password has been conﬁgured and anyone other than root can read the ﬁle, LILO installs properly, but notiﬁes the user that the permissions on the conﬁguration ﬁle are incorrect.

If a global password is not desirable, the password directive can be added to any stanza corresponding to any kernel or operating system. To do this, add the password directive immediately below the

image line. When ﬁnished, the beginning of the password-protected stanza resembles the following:

image=/boot/vmlinuz-

password=password



version



In the previous example, replaceversionwith kernel version andpasswordwith the LILO password for that kernel.

It is also possible to allow the booting of a kernel or operating system without password veriﬁcation, while preventing users from specifying arguments without a password. To do this, add the

restricted directive on the line below the password line within the stanza. Such a stanza begins

similar to the following example:

image=/boot/vmlinuz-

password=password restricted

version





Replaceversionwith kernel version andpasswordwith the LILO password for that kernel.

If using the restricted directive, there must also be a password line within the stanza.

Warning

The /etc/lilo.conf ﬁle is world-readable. If you are password protecting LILO, it is essential to only allow the root user to read and edit the ﬁle since all passwords are in plain text. To do this, type the following command as root:

chmod 600 /etc/lilo.conf

4.3. Password Security

Passwords are the primary method Red Hat Enterprise Linux uses to verify a users identity. This is why password security is enormously important for protection of the user, the workstation, and the network.

For security purposes, the installation program conﬁgures the system to use Message-Digest Algo- rithm (MD5) and shadow passwords. It is highly recommended that you do not alter these settings.

If MD5 passwords are deselected during installation, the older Data Encryption Standard (DES) format is used. This format limits passwords to eight alphanumeric character passwords (disallowing punctuation and other special characters) and provides a modest 56-bit level of encryption.

If shadow passwords are deselected during installation, all passwords are stored as a one-way hash in the world-readable /etc/passwd ﬁle, which makes the system vulnerable to ofﬂine password

Chapter 4. Workstation Security 23

cracking attacks. If an intruder can gain access to the machine as a regular user, he can copy the

/etc/passwd ﬁle to his own machine and run any number of password cracking programs against

it. If there is an insecure password in the ﬁle, it is only a matter of time before the password cracker discovers it.

Shadow passwords eliminate this type of attack by storing the password hashes in the ﬁle

/etc/shadow, which is readable only by the root user.

This forces a potential attacker to attempt password cracking remotely by logging into a network service on the machine, such as SSH or FTP. This sort of brute-force attack is much slower and leaves an obvious trail as hundreds of failed login attempts are written to system ﬁles. Of course, if the cracker starts an attack in the middle of the night on a system with weak passwords, the cracker may have gained access before dawn and edited the log ﬁles to cover his tracks.

Beyond matters of format and storage is the issue of content. The single most important thing a user can do to protect his account against a password cracking attack is create a strong password.

4.3.1. Creating Strong Passwords

When creating a secure password, it is a good idea to follow these guidelines:

Do Not Do the Following:

• Do Not Use Only Words or Numbers — Never use only numbers or words in a password.

Some insecure examples include the following:

• 8675309

• juan

• hackme

• Do Not Use Recognizable Words — Words such as proper names, dictionary words, or even

terms from television shows or novels should be avoided, even if they are bookended with numbers.

Some insecure examples include the following:

• john1

• DS-9

• mentat123

• Do Not Use Words in Foreign Languages — Password cracking programs often check against

word lists that encompass dictionaries of many languages. Relying on foreign languages for secure passwords is of little use.

Some insecure examples include the following:

• cheguevara

• bienvenido1

• 1dumbKopf

• Do Not Use Hacker Terminology — If you think you are elite because you use hacker termi-

nology — also called l337 (LEET) speak — in your password, think again. Many word lists include LEET speak.

24 Chapter 4. Workstation Security

Some insecure examples include the following:

• H4X0R

• 1337

• Do Not Use Personal Information — Steer clear of personal information. If the attacker knows

your identity, the task of deducing your password becomes easier. The following is a list of the types of information to avoid when creating a password:

Some insecure examples include the following:

• Your name

• The names of pets

• The names of family members

• Any birth dates

• Your phone number or zip code

• Do Not Invert Recognizable Words — Good password checkers always reverse common

words, so inverting a bad password does not make it any more secure.

Some insecure examples include the following:

• R0X4H

• nauj

• 9-DS

• Do Not Write Down Your Password — Never store a password on paper. It is much safer to

memorize it.

• Do Not Use the Same Password For All Machines — It is important to make separate pass-

words for each machine. This way if one system is compromised, all of your machines are not immediately at risk.

Do the Following:

• Make the Password At Least Eight Characters Long — The longer the password, the better.

If using MD5 passwords, it should be 15 characters or longer. With DES passwords, use the maximum length (eight characters).

• Mix Upper and Lower Case Letters — Red Hat Enterprise Linux is case sensitive, so mix

cases to enhance the strength of the password.

• Mix Letters and Numbers — Adding numbers to passwords, especially when added to the

middle (not just at the beginning or the end), can enhance password strength.

• Include Non-Alphanumeric Characters — Special characters such as &, $, and



improve the strength of a password (this is not possible if using DES passwords).

• Pick a Password You Can Remember — The best password in the world does little good if you

cannot remember it; use acronyms or other mnemonic devices to aid in memorizing passwords.

can greatly

Chapter 4. Workstation Security 25

With all these rules, it may seem difﬁcult to create a password meeting all of the criteria for good passwords while avoiding the traits of a bad one. Fortunately, there are some steps one can take to generate a memorable, secure password.

4.3.1.1. Secure Password Creation Methodology

There are many methods people use to create secure passwords. One of the more popular methods involves acronyms. For example:

• Think of a memorable phrase, such as:

"over the river and through the woods, to grandmother’s house we go."

• Next, turn it into an acronym (including the punctuation).

otrattw,tghwg.

• Add complexity by substituting numbers and symbols for letters in the acronym. For example,

substitute 7 for t and the at symbol (@) for a:

o7r@77w,7ghwg.

• Add more complexity by capitalizing at least one letter, such as H.

o7r@77w,7gHwg.

• Finally, do not use the example password above for any systems, ever.

While creating secure passwords is imperative, managing them properly is also important, especially for system administrators within larger organizations. The following section details good practices for creating and managing user passwords within an organization.

4.3.2. Creating User Passwords Within an Organization

If there are a signiﬁcant number of users within an organization, the system administrators have two basic options available to force the use of good passwords. They can create passwords for the user, or they can let users create their own passwords, while verifying the passwords are of acceptable quality.

Creating the passwords for the users ensures that the passwords are good, but it becomes a daunting task as the organization grows. It also increases the risk of users writing their passwords down.

For these reasons, system administrators prefer to have the users create their own passwords, but actively verify that the passwords are good and, in some cases, force users to change their passwords periodically through password aging.

4.3.2.1. Forcing Strong Passwords

To protect the network from intrusion it is a good idea for system administrators to verify that the passwords used within an organization are strong ones. When users are asked to create or change passwords, they can use the command line application passwd, which is Pluggable Authentication Manager (PAM) aware and therefore checks to see if the password is easy to crack or too short in length via the pam_cracklib.so PAM module. Since PAM is customizable, it is possible to add further password integrity checkers, such as pam_passwdqc (available from http://www.openwall.com/passwdqc/) or to write a new module. For a list of available PAM modules, see http://www.kernel.org/pub/linux/libs/pam/modules.html. For more information about PAM, refer to the chapter titled Pluggable Authentication Modules (PAM) in the Red Hat Enterprise Linux Reference Guide.

26 Chapter 4. Workstation Security

It should be noted, however, that the check performed on passwords at the time of their creation does not discover bad passwords as effectively as running a password cracking program against the passwords within the organization.

There are many password cracking programs that run under Red Hat Enterprise Linux although none ship with the operating system. Below is a brief list of some of the more popular password cracking programs:

Note

None of these tools are supplied with Red Hat Enterprise Linux and are therefore not supported by Red Hat, Inc. in any way.

• John The Ripper — A fast and ﬂexible password cracking program. It allows the use of

multiple word lists and is capable of brute-force password cracking. It is available online at http://www.openwall.com/john/.

• Crack — Perhaps the most well known password cracking software, Crack is also

very fast, though not as easy to use as John The Ripper. It can be found online at http://www.crypticide.org/users/alecm/.

• Slurpie — Slurpie is similar to John The Ripper and Crack, but it is designed to run

on multiple computers simultaneously, creating a distributed password cracking attack. It can be found along with a number of other distributed attack security evaluation tools online at http://www.ussrback.com/distributed.htm.

Warning

Always get authorization in writing before attempting to crack passwords within an organization.

4.3.2.2. Password Aging

Password aging is another technique used by system administrators to defend against bad passwords within an organization. Password aging means that after a set amount of time (usually 90 days) the user is prompted to create a new password. The theory behind this is that if a user is forced to change his password periodically, a cracked password is only useful to an intruder for a limited amount of time. The downside to password aging, however, is that users are more likely to write their passwords down.

Their are two primary programs used to specify password aging under Red Hat Enterprise Linux: the

chage command or the graphical User Manager (redhat-config-users) application.

The -M option of the chage command speciﬁes the maximum number of days the password is valid. So, for instance, to set a user’s password to expire in 90 days, type the following command:

chage -M 90

username





In the above command, replaceusername with the name of the user. To disable password expiration, it is traditional to use a value of 99999 after the -M option (this equates to a little over 273 years).

Chapter 4. Workstation Security 27

The graphical User Manager application may also be used to create password aging policies. To access this application, go to the Main Menu Button (on the Panel) => System Settings => Users & Groups or type the command redhat-config-users at a shell prompt (for example, in an XTerm or a GNOME terminal). Click on the Users tab, select the user from the user list, and click Properties from the button menu (or choose File => Properties from the pull-down menu).

Then click the Password Info tab and enter the number of days before the password expires, as shown in Figure 4-1.

Figure 4-1. Password Info Pane

For more information about user and group conﬁguration (including instructions on forcing ﬁrst time passwords), refer to the chapter titled User and Group Conﬁguration in the Red Hat Enterprise Linux System Administration Guide. For an overview of user and resource management, refer to the chapter titled Managing User Accounts and Resource Access in the Red Hat Enterprise Linux Introduction to System Administration.

4.4. Administrative Controls

When administering a home machine, the user must perform some tasks as the root user or by acquiring effective root privileges via a setuid program, such as sudo or su. A setuid program is one that operates with the user ID (UID) of the program’s owner rather than the user operating the program. Such programs are denoted by a lower case s in the owner section of a long format listing, as in the following example:

-rwsr-xr-x 1 root root 47324 May 1 08:09 /bin/su

For the system administrators of an organization, however, choices must be made as to how much administrative access users within the organization should have to their machine. Through a PAM module called pam_console.so, some activities normally reserved only for the root user, such as rebooting and mounting removable media are allowed for the ﬁrst user that logs in at the physical console (see the chapter titled Pluggable Authentication Modules (PAM) in the Red Hat Enterprise Linux Reference Guide for more about the pam_console.so module). However, other important system administration tasks such as altering network settings, conﬁguring a new mouse, or mounting

28 Chapter 4. Workstation Security

network devices are impossible without administrative access. As a result system administrators must decide how much administrative access the users on their network should receive.

4.4.1. Allowing Root Access

If the users within an organization are a trusted, computer-savvy group, then allowing them root access may not be a bad thing. Allowing root access by users means that minor issues like adding devices or conﬁguring network interfaces can be handled by the individual users, leaving system administrators free to deal with network security and other important issues.

On the other hand, giving root access to individual users can lead to the following issues (to name a few):

• Machine Misconﬁguration — Users with root access can misconﬁgure their machines and require

assistance or worse, open up security holes without knowing it.

• Running Insecure Services — Users with root access may run insecure servers on their machine,

such as FTP or Telnet, potentially putting usernames and passwords at risk as they pass over the network in the clear.

• Running Email Attachments As Root — Although rare, email viruses that affect Linux do exist. The

only time they are a threat, however, is when they are run by the root user.

4.4.2. Disallowing Root Access

If an administrator is uncomfortable allowing users to log in as root for these or other reasons, the root password should be kept secret and access to runlevel one or single user mode should be disallowed through boot loader password protection (refer to Section 4.2.2 Boot Loader Passwords for more on this topic).

Table 4-1 shows ways an administrator can further ensure that root logins are disallowed:

Method Description Effects Does Not Affect

Changing the root shell.

Edit the /etc/passwd ﬁle and change the shell from

/bin/bash to /sbin/nologin.

Prevents access to the root shell and logs the attempt. The following programs are prevented from accessing the root

account:

gdm kdm

xdm

ssh scp

sftp

Programs that do not require a shell, such as FTP clients, mail clients, and many setuid programs. The following programs are not prevented from accessing the root

account:

sudo

FTP clients

Email clients

Chapter 4. Workstation Security 29

Method Description Effects Does Not Affect

Disabling root access via any console device (tty).

Disabling root SSH logins.

Use PAM to limit root access to services.

An empty

/etc/securetty ﬁle

prevents root login on any devices attached to the computer.

Edit the

/etc/ssh/sshd_config

ﬁle and set the

PermitRootLogin

parameter to no.

Edit the ﬁle for the target service in the

/etc/pam.d/ directory.

Make sure the

pam_listfile.so is

required for authentication. Refer to Section 4.4.2.4

Disabling Root Using PAM

for details.

Prevents access to the root account via the console or the network. The following programs are prevented from accessing the root account:

gdm

kdm

xdm

Other network services

that open a tty

Prevents root access via the OpenSSH suite of tools. The following programs are prevented from accessing the root account:

ssh

scp

sftp

Prevents root access to network services that are PAM aware. The following services are prevented from accessing the root account:

FTP clients

Email clients

gdm

kdm

xdm

ssh

scp

sftp

Any PAM aware services

Programs that do not log in as root, but perform administrative tasks through through setuid or other mechanisms. The following programs are not prevented from accessing the root account:

sudo

ssh

scp

sftp

This only prevents root access to the OpenSSH suite of tools.

Programs and services that are not PAM aware.

Table 4-1. Methods of Disabling the Root Account

4.4.2.1. Disabling the Root Shell

To prevent users from logging in directly as root, the system administrator can set the root account’s shell to /sbin/nologin in the /etc/passwd ﬁle. This prevents access to the root account through commands that require a shell, such as the su and the ssh commands.

Important

Programs that do not require access to the shell, such as email clients or the sudo command, can still access the root account.

30 Chapter 4. Workstation Security

4.4.2.2. Disabling Root Logins

To further limit access to the root account, administrators can disable root logins at the console by editing the /etc/securetty ﬁle. This ﬁle lists all devices the root user is allowed to log into. If the ﬁle does not exist at all, the root user can log in through any communication device on the system, whether via the console or a raw network interface. This is dangerous as a user can Telnet into his machine as root, sending his password in plain text over the network. By default, Red Hat Enterprise Linux’s /etc/securetty ﬁle only allows the root user to log at the console physically attached to the machine. To prevent root from logging in, remove the contents of this ﬁle by typing the following command:

echo > /etc/securetty

Warning

A blank /etc/securetty ﬁle does not prevent the root user from logging in remotely using the OpenSSH suite of tools because the console is not opened until after authentication.

4.4.2.3. Disabling Root SSH Logins

To prevent root logins via the SSH protocol, edit the SSH daemon’s conﬁguration ﬁle (/etc/ssh/sshd_config). Change the line that says:

# PermitRootLogin yes

to read as follows:

PermitRootLogin no

4.4.2.4. Disabling Root Using PAM

PAM, through the /lib/security/pam_listfile.so module, allows great ﬂexibility in denying speciﬁc accounts. This allows the administrator to point the module at a list of users who are not allowed to log in. Below is an example of how the module is used for the vsftpd FTP server in the /etc/pam.d/vsftpd PAM conﬁguration ﬁle (the \ character at the end of the ﬁrst line in the following example is not necessary if the directive is on one line):

auth required /lib/security/pam_listfile.so item=user \ sense=deny file=/etc/vsftpd.ftpusers onerr=succeed

This tells PAM to consult the ﬁle /etc/vsftpd.ftpusers and deny access to the service for any user listed. The administrator is free to change the name of this ﬁle, and can keep separate lists for each service or use one central list to deny access to multiple services.

If the administrator wants to deny access to multiple services, a similar line can be added to the PAM conﬁguration services, such as /etc/pam.d/pop and /etc/pam.d/imap for mail clients or

/etc/pam.d/ssh for SSH clients.

Chapter 4. Workstation Security 31

For more information about PAM, refer to the chapter titled Pluggable Authentication Modules (PAM) in the Red Hat Enterprise Linux Reference Guide.

4.4.3. Limiting Root Access

Rather than completely deny access to the root user, the administrator may wish to allow access only via setuid programs, such as su or sudo.

4.4.3.1. The su Command

Upon typing the su command, the user is prompted for the root password and, after authentication, is given a root shell prompt.

Once logged in via the su command, the user is the root user and has absolute administrative access to the system. In addition, once a user has attained root, it may be possible for them to use the su command to change to any other user on the system without being prompted for a password.

Because this program is so powerful, administrators within an organization may wish to limit who has access to the command.

One of the simplest ways to do this is to add users to the special administrative group called wheel. To do this, type the following command as root:

usermod -G wheel

username

In the previous command, replace%username&with the username being added to the wheel group.

To use the User Manager for this purpose, go to the Main Menu Button (on the Panel) => System Settings => Users & Groups or type the command redhat-config-users at a shell prompt. Select the Users tab, select the user from the user list, and click Properties from the button menu (or choose File => Properties from the pull-down menu).

Then select the Groups tab and click on the wheel group, as shown in Figure 4-2.

Figure 4-2. Groups Pane

32 Chapter 4. Workstation Security

Next, open the PAM conﬁguration ﬁle for su (/etc/pam.d/su) in a text editor and remove the comment [#] from the following line:

auth required /lib/security/pam_wheel.so use_uid

Doing this permits only members of the administrative group wheel to use the program.

Note

The root user is part of the wheel group by default.

4.4.3.2. The sudo Command

The sudo command offers another approach for giving users administrative access. When a trusted user precedes an administrative command with sudo, the user is prompted for his password. Then, once authenticated and assuming that the command is permitted, the administrative command is executed as if by the root user.

The basic format of the sudo command is as follows:

command

sudo

(

In the above example,)command*would be replaced by a command normally reserved for the root user, such as mount.

Important

Users of the sudo command should take extra care to log out before walking away from their machines since sudoers can use the command again without being asked for a password for a ﬁve minute period. This setting can be altered via the conﬁguration ﬁle, /etc/sudoers.

The sudo command allows for a high degree of ﬂexibility. For instance, only users listed in the

/etc/sudoers conﬁguration ﬁle are allowed to use the sudo command and the command is executed

in the user’s shell, not a root shell. This means the root shell can be completely disabled, as shown in Section 4.4.2.1 Disabling the Root Shell.

The sudo command also provides a comprehensive audit trail. Each successful authentication is logged to the ﬁle /var/log/messages and the command issued along with the issuer’s user name is logged to the ﬁle /var/log/secure.

Another advantage of the sudo command is that an administrator can allow different users access to speciﬁc commands based on their needs.

Administrators wanting to edit the sudo conﬁguration ﬁle, /etc/sudoers, should use the visudo command.

To give someone full administrative privileges, type visudo and add a line similar to the following in the user privilege speciﬁcation section:

juan ALL=(ALL) ALL

This example states that the user, juan, can use sudo from any host and execute any command.

The example below illustrates the granularity possible when conﬁguring sudo:

Chapter 4. Workstation Security 33

%users localhost=/sbin/shutdown -h now

This example states that any user can issue the command /sbin/shutdown -h now as long as it is issued from the console.

The man page for sudoers has a detailed listing of options for this ﬁle.

4.5. Available Network Services

While user access to administrative controls is an important issue for system administrators within an organization, keeping tabs on which network services are active is of paramount importance to anyone who installs and operates a Linux system.

Many services under Red Hat Enterprise Linux behave as network servers. If a network service is running on a machine, then a server application called a daemon is listening for connections on one or more network ports. Each of these servers should be treated as potential avenue of attack.

4.5.1. Risks To Services

Network services can pose many risks for Linux systems. Below is a list of some of the primary issues:

• Buffer Overﬂow Attacks — Services which connect to ports numbered 0 through 1023 must run as

an administrative user. If the application has an exploitable buffer overﬂow, an attacker could gain access to the system as the user running the daemon. Because exploitable buffer overﬂows exist, crackers use automated tools to identify systems with vulnerabilities, and once they have gained access, they use automated rootkits to maintain their access to the system.

• Denial of Service Attacks (DoS) — By ﬂooding a service with requests, a denial of service attack

can bring a system to a screeching halt as it tries to log and answer each request.

• Script Vulnerability Attacks — If a server is using scripts to execute server-side actions, as Web

servers commonly do, a cracker can mount an attack on improperly written scripts. These script vulnerability attacks can lead to a buffer overﬂow condition or allow the attacker to alter ﬁles on the system.

To limit exposure to attacks over the network all services that are unused should be turned off.

4.5.2. Identifying and Conﬁguring Services

To enhance security, most network services installed with Red Hat Enterprise Linux are turned off by default. There are, however some notable exceptions:

• cupsd — The default print server for Red Hat Enterprise Linux.

• lpd — An alternate print server.

• portmap — A necessary component for the NFS, NIS, and other RPC protocols.

• xinetd — A super server that controls connections to a host of subordinate servers, such as

vsftpd, telnet, and sgi-fam (which is necessary for the Nautilus ﬁle manager).

• sendmail — The Sendmail mail transport agent is enabled by default, but only listens for connec-

tions from the localhost.

• sshd — The OpenSSH server, which is a secure replacement for Telnet.

34 Chapter 4. Workstation Security

When determining whether to leave these services running, it is best to use common sense and err on the side of caution. For example, if a printer is not available, do not leave cupsd running. The same is true for portmap. If you do not mount NFS volumes or use NIS (the ypbind service), then portmap should be disabled.

Red Hat Enterprise Linux ships with three programs designed to switch services on or off. They are the Services Conﬁguration Tool (redhat-config-services), ntsysv, and chkconfig. For information on using these tools, refer to the chapter titled Controlling Access to Services in the Red Hat Enterprise Linux System Administration Guide.

Figure 4-3. Services Conﬁguration Tool

If unsure of the purpose for a particular service, the Services Conﬁguration Tool has a description ﬁeld, illustrated in Figure 4-3, that may be of some use.

But checking to see which network services are available to start at boot time is not enough. Good system administrators should also check which ports are open and listening. Refer to Section 5.8 Verifying Which Ports Are Listening for more on this subject.

4.5.3. Insecure Services

Potentially, any network service is insecure. This is why turning unused services off is so important. Exploits for services are revealed and patched routinely, making it very important to keep packages associated with any network service updated. Refer to Chapter 3 Security Updates for more information about this issue.

Some network protocols are inherently more insecure than others. These include any services which do the following things:

• Pass Usernames and Passwords Over a Network Unencrypted — Many older protocols, such as

Telnet and FTP, do not encrypt the authentication session and should be avoided whenever possible.

• Pass Sensitive Data Over a Network Unencrypted — Many protocols pass data over the network

unencrypted. These protocols include Telnet, FTP, HTTP, and SMTP. Many network ﬁle systems, such as NFS and SMB, also pass information over the network unencrypted. It is the user’s responsibility when using these protocols to limit what type of data is transmitted.

Chapter 4. Workstation Security 35

Also, remote memory dump services, like netdump, pass the contents of memory over the network unencrypted. Memory dumps can contain passwords or, even worse, database entries and other sensitive information.

Other services like finger and rwhod reveal information about users of the system.

Examples of inherently insecure services includes the following:

• rlogin

• rsh

• telnet

• vsftpd

All remote login and shell programs (rlogin, rsh, and telnet) should be avoided in favor of SSH. (refer to Section 4.7 Security Enhanced Communication Tools for more information about sshd).

FTP is not as inherently dangerous to the security of the system as remote shells, but FTP servers must be carefully conﬁgured and monitored to avoid problems. Refer to Section 5.6 Securing FTP for more information on securing FTP servers.

Services which should be carefully implemented and behind a ﬁrewall include:

• finger

• identd

• netdump

• netdump-server

• nfs

• portmap

• rwhod

• sendmail

• smb (Samba)

• yppasswdd

• ypserv

• ypxfrd

More information on securing network services is available in Chapter 5 Server Security.

The next section discusses tools available to set up a simple ﬁrewall.

4.6. Personal Firewalls

Once the necessary network services are conﬁgured, it is important to implement a ﬁrewall.

Firewalls prevent network packets from accessing the network interface of the system. If a request is made to a port that is blocked by a ﬁrewall, the request is ignored. If a service is listening on one of these blocked ports, it does not receive the packets and is effectively disabled. For this reason, care should be taken when conﬁguring a ﬁrewall to block access to ports not in use, while not blocking access to ports used by conﬁgured services.

For most users, the best tool for conﬁguring a simple ﬁrewall is the straight-forward, graphical ﬁrewall conﬁguration tool which ships with Red Hat Enterprise Linux: the Security Level Conﬁguration Tool

36 Chapter 4. Workstation Security

(redhat-config-securitylevel). This tool creates broad iptables rules for a general-purpose ﬁrewall using a control panel interface.

For more information about using this application and what options it offers, refer to the chapter titled Basic Firewall Conﬁguration in the Red Hat Enterprise Linux System Administration Guide.

For advanced users and server administrators, manually conﬁguring a ﬁrewall with iptables is likely the best option. Refer to Chapter 7 Firewalls for more information. For a comprehensive guide to the

iptables command, consult the chapter titled iptables in the Red Hat Enterprise Linux Reference

Guide.

4.7. Security Enhanced Communication Tools

As the size and popularity of the Internet has grown, so has the threat from communication interception. Over the years, tools have been developed to encrypt communications as they are transferred over the network.

Red Hat Enterprise Linux ships with two basic tools that use high-level, public-key-cryptographybased encryption algorithms to protect information as it travels over the network.

• OpenSSH — A free implementation of the SSH protocol for encrypting network communication.

• Gnu Privacy Guard (GPG) — A free implementation of the PGP (Pretty Good Privacy) encryption

application for encrypting data.

OpenSSH is a safer way to access a remote machine and replaces older, unencrypted services like

telnet and rsh. OpenSSH includes a network service called sshd and three command line client

applications:

• ssh — A secure remote console access client.

• scp — A secure remote copy command.

• sftp — A secure pseudo-ftp client that allows interactive ﬁle transfer sessions.

It is highly recommended that any remote communication with Linux systems occur using the SSH protocol. For more information about OpenSSH, refer to the chapter titled OpenSSH in the Red Hat Enterprise Linux System Administration Guide. For more information about the SSH Protocol, refer to the chapter titled SSH Protocol in the Red Hat Enterprise Linux Reference Guide.

Important

Although the sshd service is inherently secure, the service must be kept up-to-date to prevent security threats. Refer to Chapter 3 Security Updates for more information about this issue.

GPG is a great way to keep private data private. It can be used both to email sensitive data over public networks and to protect sensitive data on hard drives.

For more information about using GPG, refer to the appendix titled Getting Started with Gnu Privacy Guard in the Red Hat Enterprise Linux System Administration Guide.

Chapter 5.

Server Security

When a system is used as a server on a public network, it becomes a target for attacks. For this reason, hardening the system and locking down services is of paramount importance for the system administrator.

Before delving into speciﬁc issues, review the following general tips for enhancing server security:

• Keep all services up to date to protect against the latest threats.

• Use secure protocols whenever possible.

• Serve only one type of network service per machine whenever possible.

• Monitor all servers carefully for suspicious activity.

5.1. Securing Services With TCP Wrappers and xinetd

TCP wrappers provide access control to a variety of services. Most modern network services, such as SSH, Telnet, and FTP, make use of TCP wrappers, which stands guard between an incoming request and the requested service.

The beneﬁts offered by TCP wrappers are enhanced when used in conjunction with xinetd, a super service that provides additional access, logging, binding, redirection, and resource utilization control.

Tip

It is a good idea to use IPTables ﬁrewall rules in conjunction with TCP wrappers and xinetd to create redundancy within service access controls. Refer to Chapter 7 Firewalls for more information about implementing ﬁrewalls with IPTables commands.

More information on conﬁguring TCP wrappers and xinetd can be found in the chapter titled TCP Wrappers and xinetd in the Red Hat Enterprise Linux Reference Guide.

The following subsections assumes a basic knowledge of each topic and focus on speciﬁc security options.

5.1.1. Enhancing Security With TCP Wrappers

TCP wrappers are capable of much more than denying access to services. This section illustrates how it can be used to send connection banners, warn of attacks from particular hosts, and enhance logging functionality. For a thorough list of TCP wrapper functionality and control language, refer to the hosts_options man page.

5.1.1.1. TCP Wrappers and Connection Banners

Sending clients connecting to a service an intimidating banner is a good way to disguise what system the server is running while letting a potential attacker know that system administrator is vigilant. To implement a TCP wrappers banner for a service, use the banner option.

This example implements a banner for vsftpd. To begin, create a banner ﬁle. It can be anywhere on the system, but it must bear same name as the daemon. For this example, the ﬁle is called

/etc/banners/vsftpd.

38 Chapter 5. Server Security

The contents of the ﬁle look like this:

220-Hello, %c 220-All activity on ftp.example.com is logged. 220-Act up and you will be banned.

The %c token supplies a variety of client information, such as the username and hostname, or the username and IP address to make the connection even more intimidating. The Red Hat Enterprise Linux Reference Guide has a list of other tokens available for TCP wrappers.

For this banner to be presented to incoming connections, add the following line to the

/etc/hosts.allow ﬁle:

vsftpd : ALL : banners /etc/banners/

5.1.1.2. TCP Wrappers and Attack Warnings

If a particular host or network has been caught attacking the server, TCP wrappers can be used to warn the administrator of subsequent attacks from that host or network via the spawn directive.

In this example, assume that a cracker from the 206.182.68.0/24 network has been caught attempting to attack the server. By placing the following line in the /etc/hosts.deny ﬁle, the connection attempt is denied and logged into a special ﬁle:

ALL : 206.182.68.0 : spawn /bin/ ’date’ %c %d >> /var/log/intruder_alert

The %d token supplies the name of the service that the attacker was trying to access.

To allow the connection and log it, place the spawn directive in the /etc/hosts.allow ﬁle.

Note

Since the spawn directive executes any shell command, create a special script to notify the administrator or execute a chain of commands in the event that a particular client attempts to connect to the server.

5.1.1.3. TCP Wrappers and Enhanced Logging

If certain types of connections are of more concern than others, the log level can be elevated for that service via the severity option.

In this example, assume anyone attempting to connect to port 23 (the Telnet port) on an FTP server is a cracker. To denote this, place a emerg ﬂag in the log ﬁles instead of the default ﬂag, info, and deny the connection.

To do this, place the following line in /etc/hosts.deny:

in.telnetd : ALL : severity emerg

This uses the default authpriv logging facility, but elevate the priority from the default value of

info to emerg, which posts log messages directly to the console.

Chapter 5. Server Security 39

5.1.2. Enhancing Security With xinetd

The xinetd super server is another useful tool for controlling access to its subordinate services. This section focuses on how xinetd can be used to set a trap service and control the amount of resources any given xinetd service can use to thwart denial of service attacks. For a more thorough list of the options available, refer to the man pages for xinetd and xinetd.conf.

5.1.2.1. Setting a Trap

One important feature of xinetd is its ability to add hosts to a global no_access list. Hosts on this list are denied subsequent connections to services managed by xinetd for a speciﬁed length of time or until xinetd is restarted. This is accomplished using the SENSOR attribute. This technique is an easy way to block hosts attempting to port scan the server.

The ﬁrst step in setting up a SENSOR is to choose a service you do not plan on using. For this example, Telnet is used.

Edit the ﬁle /etc/xinetd.d/telnet and change the line flags line to read:

flags = SENSOR

Add the following line within the braces:

deny_time = 30

This denies the host that attempted to connect to the port for 30 minutes. Other acceptable values for the deny_time attribute are FOREVER, which keeps the ban in effect until xinetd is restarted, and NEVER, which allows the connection and logs it.

Finally, the last line should read:

disable = no

While using SENSOR is a good way to detect and stop connections from nefarious hosts, it has two drawbacks:

• It does not work against stealth scans.

• An attacker who knows a SENSOR is running can mount a denial of service attack against particular

hosts by forging their IP addresses and connecting to the forbidden port.

5.1.2.2. Controlling Server Resources

Another important feature of xinetd is its ability to control the amount of resources services under its control can utilize.

It does this by way of the following directives:

• cps =

number_of_connections

,-+

wait_period

— Dictates the connections allowed

to the service per second. This directive accepts only integer values.

• instances =

number_of_connections

— Dictates the total number of connections al-

lowed to a service. This directive accepts either an integer value or UNLIMITED.

• per_source =

number_of_connections

— Dictates the connections allowed to a service

by each host. This directive accepts either an integer value or UNLIMITED.

• rlimit_as =

number[K|M]

— Dictates the amount of memory address space the service

can occupy in kilobytes or megabytes. This directive accepts either an integer value or UNLIMITED.

40 Chapter 5. Server Security

• rlimit_cpu =

number_of_seconds

— Dictates the amount of time in seconds that a ser-

vice may occupy the CPU. This directive accepts either an integer value or UNLIMITED.

Using these directives can help prevent any one xinetd service from overwhelming the system, resulting in a denial of service.

5.2. Securing Portmap

The portmap service is a dynamic port assignment daemon for RPC services such as NIS and NFS. It has weak authentication mechanisms and has the ability to assign a wide range of ports for the services it controls. For these reasons, it is difﬁcult to secure.

If running RPC services, follow these basic rules.

5.2.1. Protect portmap With TCP Wrappers

It is important to use TCP wrappers to limit which networks or hosts have access to the portmap service since it has no built-in form of authentication.

Further, use only IP addresses when limiting access to the service. Avoid using hostnames, as they can be forged via DNS poisoning and other methods.

5.2.2. Protect portmap With IPTables

To further restrict access to the portmap service, it is a good idea to add IPTables rules to the server restricting access to speciﬁc networks.

Below is are two example IPTables commands that allow TCP connections to the portmap service (listening on port 111) from the 192.168.0/24 network and from the localhost (which is necessary for the sgi_fam service used by Nautilus). All other packets are dropped.

iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport 111 -j DROP iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT

To similarly limit UDP trafﬁc, use the following command.

iptables -A INPUT -p udp -s! 192.168.0.0/24 --dport 111 -j DROP

Tip

Refer to Chapter 7 Firewalls for more information about implementing ﬁrewalls with IPTables commands.

5.3. Securing NIS

NIS stands for Network Information Service. It is an RPC service called ypserv which is used in conjunction with portmap and other related services to distribute maps of usernames, passwords, and other sensitive information to any computer claiming to be within its domain.

An NIS server is comprised of several applications. They include the following:

Chapter 5. Server Security 41

• /usr/sbin/rpc.yppasswdd — Also called the yppasswdd service, this daemon allows users to

change their NIS passwords.

• /usr/sbin/rpc.ypxfrd — Also called the ypxfrd service, this daemon is responsible for NIS

map transfers over the network.

• /usr/sbin/yppush — This application propagates changed NIS databases to multiple NIS

servers.

• /usr/sbin/ypserv — This is the NIS server daemon.

NIS is rather insecure by todays standards. It has no host authentication mechanisms and passes all of its information over the network unencrypted, including password hashes. As a result, extreme care must be taken to set up a network that uses NIS. Further complicating the situation, the default conﬁguration of NIS is inherently insecure.

It is recommended that anyone planning to implement an NIS server ﬁrst secure the portmap service as outlined in Section 5.2 Securing Portmap, then address the following issues.

5.3.1. Carefully Plan the Network

Because NIS passes sensitive information unencrypted over the network, it is important the service be run behind a ﬁrewall and on a segmented and secure network. Any time NIS information is passed over an insecure network, it risks being intercepted. Careful network design in these regards can help prevent severe security breaches.

5.3.2. Use a Password-Like NIS Domain Name and Hostname

Any machine within an NIS domain can use commands to extract information from the server without authentication, as long as the user knows the NIS server’s DNS hostname and NIS domain name.

For instance, if someone either connects a laptop computer into the network or breaks into the network from outside (and manages to spoof an internal IP address) the following command reveals the

/etc/passwd map:

ypcat -d

If this attacker is a root user, they can obtain the /etc/shadow ﬁle by typing the following command:

ypcat -d0NIS_domain1-h0DNS_hostname1shadow

NIS_domain1-h0DNS_hostname1passwd

Note

If Kerberos is used, the /etc/shadow ﬁle is not stored within an NIS map.

To make access to NIS maps harder for an attacker, create a random string for the DNS hostname, such as o7hfawtgmhwg.domain.com. Similarly, create a different randomized NIS domain name. This makes it much more difﬁcult for an attacker to access the NIS server.

5.3.3. Edit the /var/yp/securenets File

NIS listens to all networks if the /var/yp/securenets ﬁle is blank or does not exist (as is the case after a default installation). One of the ﬁrst things to do is put netmask/network pairs in the ﬁle so that

ypserv only responds to requests from the proper network.

42 Chapter 5. Server Security

Below is a sample entry from a /var/yp/securenets ﬁle:

255.255.255.0 192.168.0.0

Warning

Never start an NIS server for the ﬁrst time without creating the /var/yp/securenets ﬁle.

This technique does not provide protection from an IP spooﬁng attack, but it does at least place limits on what networks the NIS server services.

5.3.4. Assign Static Ports and Use IPTables Rules

All of the servers related to NIS can be assigned speciﬁc ports except for rpc.yppasswdd — the daemon that allows users to change their login passwords. Assigning ports to the other two NIS server daemons, rpc.ypxfrd and ypserv, allows for the creation of ﬁrewall rules to further protect the NIS server daemons from intruders.

To do this, add the following lines to /etc/sysconfig/network:

YPSERV_ARGS="-p 834" YPXFRD_ARGS="-p 835"

The following IPTables rules can be issued to enforce which network the server listens to for these ports:

iptables -A INPUT -p ALL -s! 192.168.0.0/24 --dport 834 -j DROP iptables -A INPUT -p ALL -s! 192.168.0.0/24 --dport 835 -j DROP

Tip

Refer to Chapter 7 Firewalls for more information about implementing ﬁrewalls with IPTables commands.

5.3.5. Use Kerberos Authentication

One of the most glaring ﬂaws inherent when NIS is used for authentication is that whenever a user logs into a machine, a password hash from the /etc/shadow map is send over the network. If an intruder gains access to an NIS domain and sniffs network trafﬁc, usernames and password hashes can be quietly collected. With enough time, a password cracking program can guess weak passwords, and an attacker can gain access to a valid account on the network.

Since Kerberos using secret-key cryptography, no password hashes are ever sent over the network, making the system far more secure. For more about Kerberos, refer to the chapter titled Kerberos in the Red Hat Enterprise Linux Reference Guide.

Chapter 5. Server Security 43

5.4. Securing NFS

The Network File System or NFS is an RPC service used in conjunction with portmap and other related services to provide network accessible ﬁle systems for client machines. For more information on how NFS works, refer to the chapter titled Network File System (NFS) in the Red Hat Enterprise

Linux Reference Guide. For more information about conﬁguring NFS, refer to the Red Hat Enterprise Linux System Administration Guide. The following subsections assume basic knowledge of NFS.

Important

It is recommended that anyone planning to implement an NFS server ﬁrst secure the portmap service as outlined in Section 5.2 Securing Portmap, before addressing the following issues.

5.4.1. Carefully Plan the Network

Because NFS passes all information unencrypted over the network, it is important the service be run behind a ﬁrewall and on a segmented and secure network. Any time information is passed over NFS on an insecure network, it risks being intercepted. Careful network design in these regards can help prevent security breaches.

5.4.2. Beware of Syntax Errors

The NFS server determines which ﬁle systems to export and which hosts to export these directories to via the /etc/exports ﬁle. Be careful not to add extraneous spaces when editing this ﬁle.

For instance, the following line in the /etc/exports ﬁle shares the directory /tmp/nfs/ to the host

bob.example.com with read and write permissions.

/tmp/nfs/ bob.example.com(rw)

This line in the /etc/exports ﬁle, on the other hand, shares the same directory to the host

bob.example.com with read-only permissions and shares it to the world with read and write

permissions due to a single space character after the hostname.

/tmp/nfs/ bob.example.com (rw)

It is good practice to check any conﬁgured NFS shares by using the showmount command to verify what is being shared:

showmount -e

hostname

5.4.3. Do Not Use the no_root_squash Option

By default, NFS shares change the root user to user nfsnobody, an unprivileged user account. This way all root-created ﬁles are owned by user nfsnobody, which prevents uploading of programs with the setuid bit set.

If no_root_squash is used, remote root users will be able to change any ﬁle on the shared ﬁle system and leave trojaned applications for other users to inadvertently execute.

44 Chapter 5. Server Security

5.5. Securing the Apache HTTP Server

The Apache HTTP Server is one of the most stable and secure services that ships with Red Hat Enterprise Linux. There are an overwhelming number of options and techniques available to secure the Apache HTTP Server — too numerous to delve into deeply here.

It is important when conﬁguring the Apache HTTP Server to read the documentation available for the application. This includes the the chapter titled Apache HTTP Server in the Red Hat

Enterprise Linux Reference Guide, the chapter titled Apache HTTP Server Conﬁguration in the Red Hat Enterprise Linux System Administration Guide, and the Stronghold manuals, available at

http://www.redhat.com/docs/manuals/stronghold/.

Below is a list of conﬁguration options administrators should be careful using.

5.5.1. FollowSymLinks

This directive is enabled by default, so be careful when creating symbolic links to the document root of the Web server. For instance, it is a bad idea to provide a symbolic link to /.

5.5.2. The Indexes Directive

This directive is enabled by default, but may not be desirable. To prevent visitors from browsing ﬁles on the server, remove this directive.

5.5.3. The UserDir Directive

The UserDir directive is disabled by default because it can conﬁrm the presence of a user account on the system. To enable user directory browsing on the server, use the following directives:

UserDir enabled UserDir disabled root

These directives activate user directory browsing for all user directories other than /root/. To add users to the list of disabled accounts, add a space delimited list of users on the UserDir disabled line.

5.5.4. Do Not Remove the IncludesNoExec Directive

By default, the server-side includes module cannot execute commands. It is ill advised to change this setting unless absolutely necessary, as it could potentially enable an attacker to execute commands on the system.

5.5.5. Restrict Permissions for Executable Directories

Be certain to only assign write permissions to the root user for any directory containing scripts or CGIs. This can be accomplished by typing the following commands:

chown root chmod 7554directory_name

Also, always verify that any scripts running on the system work as intended before putting them into production.

directory_name

Chapter 5. Server Security 45

5.6. Securing FTP

The File Transport Protocol (FTP) is an older TCP protocol designed to transfer ﬁles over a network. Because all transactions with the server, including user authentication, are unencrypted, it is considered an insecure protocol and should be carefully conﬁgured.

Red Hat Enterprise Linux provides three FTP servers.

• gssftpd — A kerberized xinetd-based FTP daemon which does not pass authentication infor-

mation over the network.

• Red Hat Content Accelerator (tux) — A kernel-space Web server with FTP capabilities.

• vsftpd — A standalone, security oriented implementation of the FTP service.

The following security guidelines are for setting up the vsftpd FTP service.

5.6.1. FTP Greeting Banner

Before submitting a user name and password, all users are presented with a greeting banner. By default, this banner includes version information useful to crackers trying to identify weaknesses in a system.

To change the greeting banner for vsftpd, add the following directive to

/etc/vsftpd/vsftpd.conf:

ftpd_banner=

Replace8insert_greeting_here9in the above directive with the text of the greeting message.

For mutli-line banners, it is best to use a banner ﬁle. To simplify management of multiple banners, place all banners in a new directory called /etc/banners/. The banner ﬁle for FTP connections in this example is /etc/banners/ftp.msg. Below is an example of what such a ﬁle may look like:

########################################## ########## # Hello, all activity on ftp.example.com is logged.# ########################################## ##########

insert_greeting_here

Note

It is not necessary to begin each line of the ﬁle with 220 as speciﬁed in Section 5.1.1.1 TCP Wrappers and Connection Banners.

To reference this greeting banner ﬁle for vsftpd, add the following directive to

/etc/vsftpd/vsftpd.conf:

banner_file=/etc/banners/ftp.msg

It also is possible to send additional banners to incoming connections using TCP wrappers as described in Section 5.1.1.1 TCP Wrappers and Connection Banners.

46 Chapter 5. Server Security

5.6.2. Anonymous Access

The presence of the /var/ftp/ directory activates the anonymous account.

The easiest way to create this directory is to install the vsftpd package. This package sets a directory tree up for anonymous users and conﬁgures the permissions on directories to read-only for anonymous users.

By default the anonymous user cannot write to any directories.

Caution

If enabling anonymous access to an FTP server, be aware of where sensitive data is stored.

5.6.2.1. Anonymous Upload

To allow anonymous users to upload, it is recommended that a write-only directory be created within

/var/ftp/pub/.

To do this type:

mkdir /var/ftp/pub/upload

Next change the permissions so that anonymous users cannot see what is within the directory by typing:

chmod 730 /var/ftp/pub/upload

A long format listing of the directory should look like this:

drwx-wx--- 2 root ftp 4096 Feb 13 20:05 upload

Warning

Administrators who allow anonymous users to read and write in directories often ﬁnd that their servers become a repository of stolen software.

Additionally under vsftpd, add the following line to /etc/vsftpd/vsftpd.conf:

anon_upload_enable=YES

5.6.3. User Accounts

Because FTP passes unencrypted usernames and passwords over insecure networks for authentication, it is a good idea to deny system users access to the server from their user accounts.

To disable user accounts in vsftpd, add the following directive to /etc/vsftpd/vsftpd.conf:

local_enable=NO

Chapter 5. Server Security 47

5.6.3.1. Restricting User Accounts

The easiest way to disable a speciﬁc group of accounts, such as the root user and those with sudo privileges, from accessing an FTP server is to use a PAM list ﬁle as described in Section 4.4.2.4 Disabling Root Using PAM. The PAM conﬁguration ﬁle for vsftpd is /etc/pam.d/vsftpd.

It is also possible to disable user accounts within each service directly.

To disable speciﬁc user accounts in vsftpd, add the username to /etc/vsftpd.ftpusers.

5.6.4. Use TCP Wrappers To Control Access

Use TCP wrappers to control access to either FTP daemon as outlined in Section 5.1.1 Enhancing Security With TCP Wrappers.

5.7. Securing Sendmail

Sendmail is a Mail Transport Agent (MTA) that uses the Simple Mail Transport Protocol (SMTP) to deliver electronic messages between other MTAs and to email clients or delivery agents. Although many MTAs are capable of encrypting trafﬁc between one another, most do not, so sending email over any public networks is considered an inherently insecure form of communication.

For more information about how email works and an overview of common conﬁguration settings, refer to the chapter titled Email in the Red Hat Enterprise Linux Reference Guide. This section assumes a basic knowledge of how to generate a valid /etc/mail/sendmail.cf by editing the

/etc/mail/sendmail.mc and running the m4 command as explained in the Red Hat Enterprise

Linux Reference Guide.

It is recommended that anyone planning to implement a Sendmail server address the following issues.

5.7.1. Limiting Denial of Service Attack

Because of the nature of email, a determined attacker can ﬂood the server with mail fairly easily and cause a denial of service. By setting limits to the following directives to /etc/mail/sendmail.mc the effectiveness of such attacks are limited.

• confCONNECTION_RATE_THROTTLE — The number of connections the server can receive per

second. By default, Sendmail does not limit the number of connections. If a limit is set and reached, further connections are delayed.

• confMAX_DAEMON_CHILDREN — The maximum number of child processes that can be spawned

by the server. By default, Sendmail does not assign a limit to the number of child processes. If a limit is set and reached, further connections are delayed.

• confMIN_FREE_BLOCKS — The minimum number of free blocks which must be available for the

server to accept mail. The default is 100 blocks.

• confMAX_HEADERS_LENGTH — The maximum acceptable size (in bytes) for a message header.

• confMAX_MESSAGE_SIZE — The maximum acceptable size (in bytes) for any one message.

5.7.2. NFS and Sendmail

Never put the mail spool directory, /var/spool/mail/, on an NFS shared volume.

48 Chapter 5. Server Security

Because NFS does not maintain control over user and group IDs, two or more users can have the same UID and therefore receive and read each other’s mail.

5.7.3. Mail-only Users

To help prevent local user exploits on the Sendmail server, it is best for mail users to only access the Sendmail server using an email program. Shell accounts on the mail server should not be allowed and all user shells in the /etc/passwd ﬁle should be set to /sbin/nologin (with the possible exception of the root user).

5.8. Verifying Which Ports Are Listening

After conﬁguring network services, it is important to pay attention to which ports are actually listening on the system’s network interfaces. Any open ports can be evidence of an intrusion.

There are two basic approaches for listing the ports that are listening on the network. The less reliable approach is to query the network stack by typing commands such as netstat -an or lsof -i. This method is less reliable since these programs do not connect to the machine from the network, but rather check to see what is running on the system. For this reason, these applications are frequent targets for replacement by attackers. In this way, crackers attempt to cover their tracks if they open unauthorized network ports.

A more reliable way to check which ports are listening on the network is to use a port scanner such as

nmap.

The following command issued from the console determines which ports are listening for TCP connections from the network:

nmap -sT -O localhost

The output of this command looks like the following:

Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Interesting ports on localhost.localdomain (127.0.0.1): (The 1596 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 111/tcp open sunrpc 515/tcp open printer 834/tcp open unknown 6000/tcp open X11 Remote OS guesses: Linux Kernel 2.4.0 or Gentoo 1.2 Linux 2.4.19 rc1-rc7)

Nmap run completed -- 1 IP address (1 host up) scanned in 5 seconds

This output shows the system is running portmap due to the presence of the sunrpc service. However, there is also a mystery service on port 834. To check if the port is associated with the ofﬁcial list of known services, type:

cat /etc/services | grep 834

This command returns no output. This indicates that while the port is in the reserved range (meaning 0 through 1023) and requires root access to open, it is not associated with a known service.

Next, check for information about the port using netstat or lsof. To check for port 834 using

netstat, use the following command:

Chapter 5. Server Security 49

netstat -anp | grep 834

The command returns the following output:

tcp 0 0 0.0.0.0:834 0.0.0.0:* LISTEN 653/ypbind

The presence of the open port in netstat is reassuring because a cracker opening a port surreptitiously on a hacked system would likely not allow it to be revealed through this command. Also, the

[p] option reveals the process id (PID) of the service which opened the port. In this case the open

port belongs to ypbind (NIS), which is an RPC service handled in conjunction with the portmap service.

The lsof command reveals similar information since it is also capable of linking open ports to services:

lsof -i | grep 834

Below is the relevant portion of the output for this command:

ypbind 653 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 655 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 656 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 657 0 7u IPv4 1319 TCP *:834 (LISTEN)

These tools reveal a great deal about the status of the services running on a machine. These tools are ﬂexible and can provide a wealth of information about network services and conﬁguration. Consulting the man pages for lsof, netstat, nmap, and services is therefore highly recommended.

50 Chapter 5. Server Security

Chapter 6.

Virtual Private Networks

Organizations with several satellite ofﬁces often connect to each other with dedicated lines for efﬁciency and protection of sensitive data in transit. For example, many businesses use frame relay or Asynchronous Transfer Mode (ATM) lines as an end-to-end networking solution to link one ofﬁce with others. This can be an expensive proposition, especially for small to medium sized businesses (SMBs) that want to expand without paying the high costs associated with enterprise-level, dedicated digital circuits.

Engineers have developed a cost-effective solution to this problem in the form of Virtual Private Networks (VPNs). Following the same functional principles as dedicated circuits, VPNs allow for secured digital communication between two parties (or networks), creating a Wide Area Network (WAN) from existing LANs. Where it differs from frame relay or ATM is in its transport medium. VPNs transmit over IP using datagrams (UDP) as the transport layer, making it a secure conduit through the Internet to an intended destination. Most free software VPN implementations incorporate open standard, open source encryption to further mask data in transit.

Some organizations employ hardware VPN solutions to augment security, while others use the software or protocol-based implementations. There are several vendors with hardware VPN solutions such as Cisco, Nortel, IBM, and Checkpoint. There is a free software-based VPN solution for Linux called FreeS/Wan that utilizes a standardized IPsec (or Internet Protocol Security) implementation. These VPN solutions act as specialized routers that sit between the IP connection from one ofﬁce to another.

When a packet is transmitted from a client, it sends it through the router or gateway, which then adds header information for routing and authentication called the Authentication Header (AH). The data is encrypted and is enclosed with decryption and handling instruction called the Encapsulating Security Payload (ESP). The receiving VPN router strips the header information and routes it to its intended destination (either a workstation or node on a network). Using a network-to-network connection, the receiving node on the local network receives the packets decrypted and ready for processing. The encryption/decryption process in a network-to-network VPN connection is transparent to a local node.

With such a heightened level of security, a cracker must not only intercept a packet, but decrypt the packet as well (which, in the case of most VPNs, usually employ the triple Data Encryption Standard [3DES] 168-bit cipher). Intruders who employ a man-in-the-middle attack between a server and client must also have access to the keys exchanged for authenticating sessions. VPNs are a secure and effective means to connect multiple remote nodes to act as a uniﬁed Intranet.

6.1. VPNs and Red Hat Enterprise Linux

Red Hat Enterprise Linux users and administrators have various options in terms of implementing a software solution to connect and secure their WAN. There are, however, two methods of implementing VPN connections that are currently supported in Red Hat Enterprise Linux. An equivalent solution that can be used as a secure substitute to using a VPN involves running OpenSSH as a tunnel between two remote nodes. This solution is a sound alternative to Telnet, rsh, and other remote host communication methods, but it does not completely address the usability needs of all corporate telecommuters and branch ofﬁces. Two supported solutions included with Red Hat Enterprise Linux that are more adherent to the deﬁnition of a VPN are Crypto IP Encapsulation (CIPE) and the Internet Protocol Security (IPsec).

52 Chapter 6. Virtual Private Networks

6.2. Crypto IP Encapsulation (CIPE)

CIPE is a VPN implementation developed primarily for Linux. CIPE uses encrypted IP packets that are encapsulated, or wrapped, in datagram (UDP) packets. CIPE packets are given destination header information and are encrypted using the default CIPE encryption mechanism. The packets are then transferred over IP as UDP packets via the CIPE virtual network device (cipcbx) over a carrier network to an intended remote node. Figure 6-1 shows a typical CIPE setup connecting two Linux-based networks:

Figure 6-1. A Network and Remote Client Connected by CIPE

This diagram shows a network running CIPE on the ﬁrewall, and a remote client machine acting as a CIPE-enabled node. The CIPE connection acts as a tunnel through which all Intranet-bound data is routed between remote nodes. All data is encrypted using dynamically-generated 128-bit keys and can be further compressed for large ﬁle transfers or to tunnel X applications to a remote host. CIPE can be conﬁgured for communication between two or more CIPE-enabled Linux machines and has network drivers for Win32-based operating systems.

6.3. Why Use CIPE?

There are several reasons why CIPE would be a smart choice for security and system administrators:

• Red Hat Enterprise Linux ships with CIPE, so it is available to all Red Hat Enterprise Linux edge

machines (for example, ﬁrewalls or gateways) and individual clients that you want to connect to your Intranet. Red Hat Enterprise Linux also includes CIPE-supported encryption ciphers.

• CIPE supports encryption using either of the standard Blowﬁsh or IDEA encryption algorithms.

Depending on encryption export regulations in your country, you may use the default (Blowﬁsh) to encrypt all CIPE trafﬁc on your Intranet.

• Because CIPE is software based, any older or redundant machine that is able to run Red Hat Enter-

prise Linux can become a CIPE gateway, saving an organization from having to purchase expensive dedicated VPN hardware to connect two LANs securely.

Chapter 6. Virtual Private Networks 53

• CIPE is actively developed to work in conjunction with iptables, ipchains, and other rules-

based ﬁrewalls. Peer acceptance of incoming CIPE UDP packets is all that is needed to coexist with existing ﬁrewall rules.

• CIPE conﬁguration is done through text ﬁles, allowing administrators to conﬁgure their CIPE

servers and clients remotely without the need for bulky graphical tools that can function poorly over a network. CIPE can also be conﬁgured via the Network Administration Tool.

6.4. CIPE Installation

The installation of CIPE is equivalent to installing a network interface under Linux. The cipe RPM package contains conﬁguration ﬁles found in /etc/cipe/, the CIPE daemon (/usr/sbin/ciped-cb), network scripts that load the kernel module and activates/deactivates the CIPE interface (if*-cipcb), and sample conﬁguration ﬁles found in

/usr/share/doc/cipe-

the CIPE protocol and various implementation details.

The following guide details a sample conﬁguration involving aworkstation client that wants to connect securely to a remote LAN with a CIPE gateway. The workstation uses a dynamic IP address from a cable modem connection, while the CIPE-enabled gateway machine employs the 192.168.1.0/24 range. This is what is known as a "typical" CIPE conﬁguration. Figure 6-1 illustrates the typical CIPE setup.

Installing CIPE between the client and the CIPE server allows for a secured peer-to-peer connection using the Internet as a medium for transmission of WAN trafﬁc. The client workstation then transfers a ﬁle through the Internet to the CIPE-enabled ﬁrewall, where each packet will be timestamped and given the peer address of the receiving CIPE-enabled ﬁrewall. The destination ﬁrewall then reads the header information, strips it, and sends it through to the remote LAN router to be then routed to its destination node. This process is seamless and completely transparent to end users. The majority of the transaction is done between the CIPE-enabled peers.

version;/samples/. There is also a detailed texinfo page explaining

6.5. CIPE Server Conﬁguration

To setup the CIPE server, install the cipe RPM package from the Red Hat Enterprise Linux CD-ROM or via Red Hat Network.

Important

If you are using an older version of Red Hat Enterprise Linux and/or have an older version of CIPE, you should upgrade to the latest version.

Next, copy the sample conﬁguration ﬁles from /usr/share/doc/cipe-version/samples/ (where version is the version of CIPE installed on your system) to /etc/cipe/. Once they are copied, you will need to edit the /etc/cipe/options.cipcbx (x is incremental starting from 0, for those who want to have more than one CIPE connection on the CIPE server) to include your LAN subnet addresses and publicly routable ﬁrewall IP addresses. The following is the example

options ﬁle included with the Red Hat Enterprise Linux cipe RPM which, for this example, is

renamed to options.cipbcb0:

# Surprise, this file allows comments (but only on a line by themselves) # This is probably the minimal set of options that has to be set # Without a "device" line, the device is picked dynamically

# the peer’s IP address

54 Chapter 6. Virtual Private Networks

ptpaddr 6.5.4.3

# our CIPE device’s IP address ipaddr 6.7.8.9

# my UDP address. Note: if you set port 0 here, the system will pick # one and tell it to you via the ip-up script. Same holds for IP 0.0.0.0. me bigred.inka.de:6789

# ...and the UDP address we connect to. Of course no wildcards here. peer blackforest.inka.de:6543

# The static key. Keep this file secret! # The key is 128 bits in hexadecimal notation. key xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The ptpaddr is the remote LAN’s CIPE address. The ipaddr is the workstation’s CIPE IP address. The me address is the client’s publicly routable IP address that sends the UDP packets over the Internet, while peer is the publicly routable IP address of CIPE server. Note that the client workstation’s IP address is 0.0.0.0 because it uses a dynamic connection. The CIPE client handles the connection to the host CIPE server. The key ﬁeld (represented by x’s; the key should be secret) is the shared static key. This key must be the same for both peers or connection is not possible. Refer to Section 6.8 CIPE Key Management for information on how to generate a shared static key for your CIPE machines.

Here is the edited /etc/cipe/options.cipcb0 that the client workstation will use:

ptpaddr 10.0.1.2 ipaddr 10.0.1.1 me 0.0.0.0 peer LAN.EXAMPLE.COM:6969 key 123456ourlittlesecret7890shhhh

Here is the /etc/cipe/options.cipcb0 ﬁle for the CIPE server:

ptpaddr 10.0.1.1 ipaddr 10.0.1.2 me LAN.EXAMPLE.COM:6969 peer 0.0.0.0 key 123456ourlittlesecret7890shhhh

6.6. Conﬁguring Clients for CIPE

After successfully conﬁguring the CIPE server and testing for functionality, you can now deploy the connection on the client machine.

The CIPE client should be able to connect and disconnect the CIPE connection in an automated way. Therefore, CIPE contains built-in mechanisms to customize settings for individual uses. For example, a remote employee can connect to the CIPE device on the LAN by typing the following:

/sbin/ifup cipcb0

The device should automatically come up; ﬁrewall rules and routing information should also be conﬁgured along with the connection. The remote employee should be able to terminate the connection with the following:

/sbin/ifdown cipcb0

Conﬁguring clients requires the creation of localized scripts that are run after the device has loaded. The device conﬁguration itself can be conﬁgured locally via a user-created ﬁle called

Chapter 6. Virtual Private Networks 55

/etc/sysconfig/network-scripts/ifcfg-cipcb0. This ﬁle contains parameters that

determine whether the CIPE connection occurs at boot-time, what the name of the CIPE device is, and more. The following is the ifcfg-cipcb0 ﬁle for a remote client connecting to the CIPE server:

DEVICE=cipcb0 ONBOOT=yes BOOTPROTO=none USERCTL=no

# This is the device for which we add a host route to our CIPE peer through. # You may hard code this, but if left blank, we will try to guess from # the routing table in the /etc/cipe/ip-up.local file. PEERROUTEDEV=

# We need to use internal DNS when connected via cipe. DNS=192.168.1.254

The CIPE device is named cipcb0. The CIPE device is activated at boot-time (conﬁgured via the

ONBOOT ﬁeld) and does not use a boot protocol (for example, DHCP) to receive an IP address for the

device. The PEERROUTEDEV ﬁeld determines the CIPE server device name that connects to the client. If no device is speciﬁed in this ﬁeld, one is determined after the device has been loaded.

If the internal networks are behind a ﬁrewall, set rules to allow the CIPE interface on the client machine to send and receive UDP packets. Refer to Chapter 7 Firewalls for information on conﬁguring a ﬁrewall. For this example conﬁguration, iptables rules are implemented.

Note

Clients should be conﬁgured such that all localized parameters are placed in a user-created ﬁle called

/etc/cipe/ip-up.local. The local parameters should be reverted when the CIPE session is shut

down using /etc/cipe/ip-down.local.

Firewalls should be conﬁgured on client machines to accept the CIPE UDP encapsulated packets. Rules may vary widely, but the basic acceptance of UDP packets is required for CIPE connectivity. The following iptables rules allow UDP CIPE transmissions on the remote client machine connecting to the LAN; the ﬁnal rule adds IP Masquerading to allow the remote client to communicate to the LAN and the Internet:

/sbin/modprobe iptables /sbin/service iptables stop /sbin/iptables -P INPUT DROP /sbin/iptables -F INPUT /sbin/iptables -A INPUT -j ACCEPT -p udp -s 10.0.1.1 /sbin/iptables -A INPUT -j ACCEPT -i cipcb0 /sbin/iptables -A INPUT -j ACCEPT -i lo /sbin/iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE

Add routing rules to the client machine to access the nodes behind the CIPE connection as if they were on the local network. This can be done by running the route command. In this example, the client workstation needs to have the following network route:

route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.0.1.2

The following shows the ﬁnal /etc/cipe/ip-up.local script for the client workstation:

#!/bin/bash -v if [ -f /etc/sysconfig/network-scripts/ifcfg-$ 1 ] ; then

56 Chapter 6. Virtual Private Networks

else

Cannot find config file ifcfg-$1. Exiting. EOF

if [ -n ${PEERROUTEDEV} ]; then

Cannot find a default route to send cipe packets through! Punting and hoping for the best. EOT

########################################## ########## # Add The routes for the remote local area network # ########################################## ##########

route add -host 10.0.1.2 dev $PEERROUTEDEV route add -net 192.168.1.0 netmask 255.255.255.0 dev $1

########################################## ########## # IP TABLES Rules to restrict traffic # ########################################## ##########

/sbin/modprobe iptables /sbin/service iptables stop /sbin/iptables -P INPUT DROP /sbin/iptables -F INPUT /sbin/iptables -A INPUT -j ACCEPT -p udp -s 10.0.1.2 /sbin/iptables -A INPUT -j ACCEPT -i $1 /sbin/iptables -A INPUT -j ACCEPT -i lo /sbin/iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -o eth0 -j MASQUERADE

. /etc/sysconfig/network-scripts/ifcfg-$1

cat

<=<

EOT | logger

exit 1

cat

<=<

EOT | logger

# Use routing table to determine peer gateway export PEERROUTEDEV=‘/sbin/route -n | grep ^0.0.0.0 | head -n 1 \

| awk ’{ print $NF }’‘

6.7. Customizing CIPE

CIPE can be conﬁgured in numerous ways, from passing parameters as command line arguments when starting ciped to generating new shared static keys. This allows a security administrator the ﬂexibility to customize CIPE sessions to ensure security as well as increase productivity.

Note

The most common parameters should be placed in the /etc/cipe/options.cipcb x ﬁle for automatic loading at runtime.

Be aware that any parameters passed at the command line as options will override respective parameters set in the /etc/cipe/options.cipc bx conﬁguration ﬁle.

Table 6-1 details some of the command-line parameters when running the ciped daemon.

Chapter 6. Virtual Private Networks 57

Parameter Description

arg Passes arguments to the /etc/cipe/ip-up initialization script

cttl Sets the Carrier Time To Live (TTL) value; recommended value is 64

debug Boolean value to enable debugging

device Names the CIPE device

ipaddr Publicly-routable IP address of the CIPE machine

ipdown Choose an alternate ip-down script than the default

ipup Choose an alternate ip-up script than the default /etc/cipe/ip-up

key Speciﬁes a shared static key for CIPE connection

maxerr Number of errors allowable before the CIPE daemon quits

me UDP address of the CIPE machine

mtu Set the device maximum transfer unit

nokey Do not use encryption

peer The peer’s CIPE UDP address

ping Set CIPE-speciﬁc (non-ICMP) keepalive ping interval

socks IP address and port number of the SOCKS server for proxy connections

tokey Set dynamic key lifetime; default is 10 minutes (600 seconds)

tokxc Timeout value for shared key exchange; default is 10 seconds

tokxts Shared key exchange timestamp timeout value; default is 0 (no

/etc/cipe/ip-down

timestamps)

toping Timeout value for keepalive pings; default is 0

Table 6-1. CIPE Parameters

6.8. CIPE Key Management

As previously mentioned, CIPE incorporates a secure combination of static link keys and encrypted trafﬁc to create a secure tunnel over carrier networks such as the Internet. The use of static link keys provide a common point of reference for two CIPE-enabled networks to pass information securely. Therefore, it is imperative that both CIPE-enabled network gateways share the exact same key, or CIPE communication will not be possible.

Generating CIPE keys requires knowledge of what kind of keys are compatible. Random alphanumeric generators do not work. Static keys must be 128-bit, 32-character strings. These can be created by running the following command, which uses od to create a hexadecimal key using the

/dev/random random number device:

od -N 16 /dev/random -t x4 | awk ’{print $2 $3 $4 $5}’

Place the output in the /etc/cipe/options.cipcb0 ﬁle for all CIPE servers and clients.

58 Chapter 6. Virtual Private Networks

6.9. IPsec

Red Hat Enterprise Linux supports a protocol for connecting remote hosts and networks to each other using a secure tunnel on a common carrier network such as the Internet. The protocol, called IPsec, can be implemented using a host-to-host (one computer workstation to another) or network-to-network (one LAN/WAN to another). The IPsec implementation in Red Hat Enterprise Linux uses Internet Key Exchange (IKE), which is a protocol implemented by the IETF to be used for mutual authentication and secure associations between connecting systems.

The Red Hat Enterprise Linux implementation of IPsec uses IKE for sharing keys between hosts across the Internet. The racoon keying daemon handles the IKE key distribution and exchange.

6.10. IPsec Installation

Implementing IPsec requires that the ipsec-tools RPM package be installed on all IPsec hosts (if using a host-to-host conﬁguration) or routers (if using a network-to-network conﬁguration). The RPM package contains essential libraries, daemons, and conﬁguration ﬁles to aid in setup of the IPsec connection:

• /lib/libipsec.so — library that contains the PF_KEY trusted key management socket interface

between the Linux kernel and the IPsec implementation used in Red Hat Enterprise Linux.

• /sbin/setkey — manipulates the key management and security attributes of IPsec in the kernel.

This executable is controlled by the racoon key management daemon. For more information on

setkey, refer to the setkey(8) man page.

• /sbin/racoon — the IKE key management daemon, used to manage and control security as-

sociations and key sharing between IPsec-connected systems. This daemon can be conﬁgured by editing the /etc/racoon/racoon.conf ﬁle. For more information about racoon, refer to the

racoon(8) man page.

• /etc/racoon/racoon.conf — the racoon daemon conﬁguration ﬁle used to conﬁgure various

aspects of the IPsec connection, including authentication methods and encryption algorithms used in the connection. For a complete listing of directives available, refer to the racoon.conf(5) man page.

Conﬁguring IPsec on Red Hat Enterprise Linux can be done via the Network Administration Tool or by manually editing networking and IPsec conﬁguration ﬁles. For more information about using the Network Administration Tool, refer to the Red Hat Enterprise Linux System Administration Guide.

To connect two network-connected hosts via IPsec, refer to Section 6.11 IPsec Host-to-Host Con-

ﬁguration. To connect one LAN/WAN to another via IPsec, refer to Section 6.12 IPsec Network-toNetwork conﬁguration.

6.11. IPsec Host-to-Host Conﬁguration

IPsec can be conﬁgured to connect one desktop or workstation to another by way of a host-to-host connection. This type of connection uses the network to which each host is connected to create the secure tunnel to each other. The requirements of a host-to-host connection are minimal, as is the conﬁguration of IPsec on each host. The hosts need only a dedicated connection to a carrier network (such as the Internet) and Red Hat Enterprise Linux to create the IPsec connection.

The ﬁrst step in creating a connection is to gather system and network information from each workstation. For a host-to-host connection, you need the following information:

• The IP address for both hosts

Chapter 6. Virtual Private Networks 59

• A unique name to identify the IPsec connection and distinguish it from other devices or connections

(for example, ipsec0)

• A ﬁxed encryption key or one automatically generated by racoon

• A pre-shared authentication key that is used to initiate the connection and exchange encryption keys

during the session

For example, suppose Workstation A and Workstation B want to connect to each other through an IPsec tunnel. They want to connect using a pre-shared key with the value of foobarbaz and the users agree to let racoon automatically generate and share an authentication key between each host. Both host users decide to name their connections ipsec0.

The following is the ifcfg ﬁle for host-to-host IPsec connection for Workstation A. The unique name to identify the connection in this example is ipsec0, so the resulting ﬁle is named

/etc/sysconfig/network-scripts/ifcfg-ipsec0.

DST=X.X.X.X TYPE=IPsec ONBOOT=yes IKE_METHOD=PSK

Workstation A would replace X.X.X.X with the IP address of Workstation B, while Workstation B replaces X.X.X.X with the IP address of Workstation A. The connection is set to initiate upon boot-up (ONBOOT=yes) and uses the pre-shared key method of authentication (IKE_METHOD=PSK).

The following is the pre-shared key ﬁle (called

/etc/sysconfig/network-scripts/keys-ipsec0 that both

workstations use to authenticate each other. The contents of this ﬁle should be identical on both workstations and only the root user should be able to read or write this ﬁle.

IKE_PSK=foobarbaz

Important

To change the keys-ipsec0 ﬁle so that only the root user can read or edit the ﬁle, perform the following command after creating the ﬁle:

chmod 600 /etc/sysconfig/network-scripts/keys-ipse c0

To change the authentication key at any time, edit the keys-ipsec0 ﬁle on both workstations. Both keys must be identical for proper connectivity.

The /etc/racoon/racoon.conf ﬁle should be identical except for the include

"/etc/racoon/X.X.X.X.conf" statement. This statement (and the ﬁle it references) is generated

when the IPsec tunnel is activated. For Workstation A, the X.X.X.X in the include statement is Workstation B’s IP address. The opposite is true of Workstation B. The following shows a typical

racoon.conf ﬁle when IPsec connection is activated.

# Racoon IKE daemon configuration file. # See ’man racoon.conf’ for a description of the format and entries.

path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; path certificate "/etc/racoon/certs";

sainfo anonymous {

60 Chapter 6. Virtual Private Networks

pfs_group 2; lifetime time 1 hour ; encryption_algorithm 3des, blowfish 448, rijndael ; authentication_algorithm hmac_sha1, hmac_md5 ;

compression_algorithm deflate ; } include "/etc/racoon/X.X.X.X .conf"

To start the connection, either reboot the workstation or execute the following command as root on each host:

/sbin/ifup ipsec0

To test the IPsec connection, run the tcpdump utility to view the network packets being transfered between the hosts (or networks) and verify that they are encrypted via IPsec. The packet should include an AH header and should be shown as ESP packets. ESP means it is encrypted. For example:

17:13:20.617872 pinky.example.com > ijin.example.com: \

AH(spi=0x0aaa749f,seq=0x335): ESP(spi=0x0ec0441e,seq=0x335) (DF)

6.12. IPsec Network-to-Network conﬁguration

IPsec can also be conﬁgured to connect an entire network (such as a LAN or WAN) to a remote network by way of a network-to-network connection. A network-to-network connection requires the setup of IPsec routers on each side of the connecting networks to process and route information from one node on a network to a node on the remote network. Figure 6-2 shows a network-to-network IPsec tunneled connection.

Figure 6-2. A Network-to-network IPsec tunneled connection

The diagram shows two separate LANs separated by the Internet. These networks use IPsec routers to authenticate and initiate a connection using a secure tunnel through the Internet. Packets that are intercepted in transit would require brute-force decryption in order to crack the cipher protecting the packets between these LANs. The process of communicating from one node on the 192.168.1.0/24 IP range to another on 192.168.2.0/24 is completely transparent to the nodes as the processing, encryption/decryption, and routing of the IPsec packets are completely handled by the IPsec router.

The information needed for a network-to-network connection include:

• The externally-accessible IP addresses of the dedicated IPsec routers

• The network address ranges of the LAN/WAN served by the IPsec routers (such as 192.168.0.0/24

or 10.0.1.0/24)

• The IP addresses of the gateway devices that route the data from the network nodes to the Internet

Chapter 6. Virtual Private Networks 61

• A unique name to identify the IPsec connection and distinguish it from other devices or connections

(for example, ipsec0)

• A ﬁxed encryption key or one automatically generated by racoon

• A pre-shared authentication key that is used to initiate the connection and exchange encryption keys

during the session

For example, suppose LAN A (lana.example.com) and LAN B (lanb.example.com) want to connect to each other through an IPsec tunnel. The network address for LAN A is in the 192.168.1.0/24 range, while LAN B uses the 192.168.2.0/24 range. The gateway IP address is 192.168.1.254 for LAN A and 192.168.2.254 for LAN B. The IPSEC routers are separate from each LAN gateway and uses two network devices: eth0 is assigned an externally-accessible static IP address which accesses the Internet, while eth1 acts as a routing point to process and transmit LAN packets from one network node to the remote network nodes.

The IPsec connection between each network uses a pre-shared key with the value of r3dh4tl1nux, and the administrators of A and B agree to let racoon automatically generate and share an authentication key between each IPsec router. The administrator of LAN A decides to name the IPSEC connection ipsec0, while the administrator of LAN B names the IPSEC connection ipsec1..

The following is the ifcfg ﬁle for a network-to-network IPsec connection for LAN A. The unique name to identify the connection in this example is ipsec1, so the resulting ﬁle is named

/etc/sysconfig/network-scripts/ifcfg-ipsec1.

TYPE=IPsec ONBOOT=yes IKE_METHOD=PSK SRCGW=192.168.1.254 DSTGW=192.168.2.254 SRCNET=192.168.1.0/24 DSTNET=192.168.2.0/24 DST=X.X.X.X

The connection is set to initiate upon boot-up (ONBOOT=yes) and uses the pre-shared key method of authentication (IKE_METHOD=PSK). The administrator for LAN A enters the destination gateway, which is the gateway for LAN B (DSTGW=192.168.2.254) as well as the source gateway, which is the gateway IP address for LAN A (SRCGW=192.168.1.254). The administrator then enters the destination network, which is the network range for LAN B (DSTNET=192.168.2.0/24) as well as the source network (SRCNET=192.168.1.0/24). Finally, the administrator enters the destination IP address, which is the externally-accessible IP address for LAN B (X.X.X.X ).

The following is the pre-shared key ﬁle (called

/etc/sysconfig/network-scripts/keys-ipsecX where X is 0 for

LAN A and 1 for LAN B) that both networks use to authenticate each other. The contents of this ﬁle should be identical and only the root user should be able to read or write this ﬁle.

IKE_PSK=r3dh4tl1nux

Important

To change the keys-ipsec0 ﬁle so that only the root user can read or edit the ﬁle, perform the following command after creating the ﬁle:

chmod 600 /etc/sysconfig/network-scripts/keys-ipse c1

62 Chapter 6. Virtual Private Networks

To change the authentication key at any time, edit the keys-ipsecX ﬁle on both IPsec routers. Both keys must be identical for proper connectivity.

The following is the /etc/racoon/racoon.conf conﬁguration ﬁle for the IPsec connection. Note that the include line at the bottom of the ﬁle appears only if presently connected to the IPsec tunnel because it is automatically generated each time the IPsec connection is activated.

# Racoon IKE daemon configuration file. # See ’man racoon.conf’ for a description of the format and entries.

path include "/etc/racoon"; path pre_shared_key "/etc/racoon/psk.txt"; path certificate "/etc/racoon/certs";

sainfo anonymous {

pfs_group 2; lifetime time 1 hour ; encryption_algorithm 3des, blowfish 448, rijndael ; authentication_algorithm hmac_sha1, hmac_md5 ;

compression_algorithm deflate ; } include "/etc/racoon/X.X.X.X.conf"

The following is the speciﬁc conﬁguration for the connection to the remote network. The ﬁle is named

X.X.X.X.conf (replace X.X.X.X with the IP address of the remote IPsec router). Note that this ﬁle

is automatically generated once the IPsec tunnel is activated and should not be edited directly.

; remote X.X.X.X {

}

exchange_mode aggressive, main; my_identifier address; proposal {

}

encryption_algorithm 3des; hash_algorithm sha1; authentication_method pre_shared_key; dh_group 2 ;

Prior to starting the IPsec connection, IP forwarding should be enabled in the kernel. As root at a shell prompt, enable IP forwarding:

1. Edit /etc/sysctl.conf and set net.ipv4.ip_forward to 1.

2. Execute the following command to enable the change:

sysctl -p /etc/sysctl.conf

To start the IPsec connection, either reboot the IPsec routers or execute the following command as root on each router:

/sbin/ifup ipsec0

The connections are activated and both LAN A and B are able to communicate with each other. The routes are created automatically via the initialization script called by running ifup on the IPsec connection. To show a list of routes for the network, run the following command:

/sbin/ip route list

Chapter 6. Virtual Private Networks 63

To test the IPsec connection, run the tcpdump utility on the externally-routable device (eth0 in this example) to view the network packets being transfered between the hosts (or networks) and verify that they are encrypted via IPsec. For example, to check the IPsec connectivity of LAN A, type the following:

tcpdump -n -i eth0 host lana.example.com

The packet should include an AH header and should be shown as ESP packets. ESP means it is encrypted. For example (back slashes denote a continuation of one line):

12:24:26.155529 lanb.example.com > lana.example.com: AH(spi=0x021c9834,seq=0x358): \

lanb.example.com > lana.example.com: ESP(spi=0x00c887ad,seq=0x358) (DF) \ (ipip-proto-4)

64 Chapter 6. Virtual Private Networks

Chapter 7.

Firewalls

Information security is commonly thought of as a process and not a product. However, standard security implementations usually employ some form of dedicated mechanism to control access privileges and restrict network resources to users who are authorized, identiﬁable, and traceable. Red Hat Enterprise Linux includes several powerful tools to assist administrators and security engineers with network-level access control issues.

Aside from VPN solutions such as CIPE or IPsec (discussed in Chapter 6 Virtual Private Networks), ﬁrewalls are one of the core components of network security implementation. Several vendors market ﬁrewall solutions catering to all levels of the marketplace: from home users protecting one PC to data center solutions safeguarding vital enterprise information. Firewalls can be standalone hardware solutions, such as ﬁrewall appliances by Cisco, Nokia, and Sonicwall. There are also proprietary software ﬁrewall solutions developed for home and business markets by vendors such as Checkpoint, McAfee, and Symantec.

Apart from the differences between hardware and software ﬁrewalls, there are also differences in the way ﬁrewalls function that separate one solution from another. Table 7-1 details three common types of ﬁrewalls and how they function:

Method Description Advantages Disadvantages

NAT Network Address

Translation (NAT) places

internal network IP subnetworks behind one or a small pool of external IP addresses, masquerading all requests to one source rather than several

Packet Filter

Packet ﬁltering ﬁrewalls read each data packet that passes within and outside of a LAN. It can read and process packets by header information and ﬁlters the packet based on sets of programmable rules implemented by the ﬁrewall administrator. The Linux kernel has built-in packet ﬁltering functionality through the netﬁlter kernel subsystem.

Can be conﬁgured transparently to machines on a LAN

Protection of many machines and services behind one or more external IP address(es), simplifying administration duties

Restriction of user access to and from the LAN can be conﬁgured by opening and closing ports on the NAT ﬁrewall/gateway

Customizable through the

iptables front-end

utility

Does not require any customization on the client side, as all network activity is ﬁltered at the router level rather than at the application level

Since packets are not transmitted through a proxy, network performance is faster due to direct connection from client to remote host

Cannot prevent malicious activity once users connect to a service outside of the ﬁrewall

Cannot ﬁlter packets for

content like proxy ﬁrewalls

Processes packets at the protocol layer, but cannot ﬁlter packets at an application layer

Complex network architectures can make establishing packet ﬁltering rules difﬁcult, especially if coupled with IP masquerading or local subnets and DMZ networks

66 Chapter 7. Firewalls

Method Description Advantages Disadvantages

Proxy Proxy ﬁrewalls ﬁlter all

requests of a certain protocol or type from LAN clients to a proxy machine, which then makes those requests to the Internet on behalf of the local client. A proxy machine acts as a buffer between malicious remote users and the internal network client machines.

Gives administrators control over what applications and protocols function outside of the LAN

Some proxy servers can cache data so that clients can access frequently requested data from the local cache rather than having to use the Internet connection to request it, which is convenient for cutting down on unnecessary bandwidth consumption

Proxy services can be

logged and monitored

Proxies are often application speciﬁc (HTTP, telnet, etc.) or protocol restricted (most proxies work with TCP connected services only)

Application services cannot run behind a proxy, so your application servers must use a separate form of network security

Proxies can become a network bottleneck, as all requests and transmissions are passed through one source rather than direct client to remote service

connections closely, allowing tighter control over resource utilization on the network

Table 7-1. Firewall Types

7.1. Netﬁlter and IPTables

The Linux kernel features a powerful networking subsystem called netﬁlter. The netﬁlter subsystem provides stateful or stateless packet ﬁltering as well as NAT and IP masquerading services. Netﬁlter also has the ability to mangle IP header information for advanced routing and connection state management. Netﬁlter is controlled through the IPTables utility.

7.1.1. IPTables Overview

The power and ﬂexibility of netﬁlter is implemented through the IPTables interface. This commandline tool is similar in syntax to its predecessor, IPChains; however, IPTables uses the netﬁlter subsystem to enhance network connection, inspection, and processing; whereas IPChains used intricate rule sets for ﬁltering source and destination paths, as well as connection ports for both. IPTables features advanced logging, pre- and post-routing actions, network address translation, and port forwarding all in one command-line interface.

This section provides an overview of IPTables. For more detailed information about IPTables, refer to the Red Hat Enterprise Linux Reference Guide.

7.2. Using IPTables

The ﬁrst step in using IPTables is to start the IPTables service. This can be done with the command:

service iptables start

Chapter 7. Firewalls 67

Warning

The IP6Tables services should be turned off to use the IPTables service with the following commands:

service ip6tables stop chkconfig ip6tables off

To make IPTables start by default whenever the system is booted, you must change runlevel status on the service using chkconfig.

chkconfig --level 345 iptables on

The syntax of IPTables is separated into tiers. The main tier is the chain. A chain speciﬁes the state at which a packet will be manipulated. The usage is as follows:

iptables -A chain -j target

The -A appends a rule at the end of an existing ruleset. The chain is the name of the chain for a rule. The three built-in chains of IPTables (that is, the chains that affect every packet which traverses a network) are INPUT, OUTPUT, and FORWARD. These chains are permanent and cannot be deleted.

Important

When creating an IPTables ruleset, it is critical to remember that order is important. For example, if a chain that speciﬁes that any packets from the local 192.168.100.0/24 subnet be dropped, and then a chain is appended (-A) which allows packets from 192.168.100.13 (which is within the dropped restricted subnet), then the appended rule is ignored. You must set a rule to allow 192.168.100.13 ﬁrst, and then set a drop rule on the subnet.

To aribitrarily insert a rule in an existing chain of rules, use -I, followed by the chain in which you want to insert the rule, and a rule number (1,2,3,...,n) where you want to rule to reside. For example:

iptables -I INPUT 1 -i lo -p all -j ACCEPT

The rule is inserted as the ﬁrst rule in the INPUT chain to allow local loopback device trafﬁc.

7.2.1. Basic Firewall Policies

Some basic policies established from the beginning can aid as a foundation for building more detailed, user-deﬁned rules. IPTables uses policies (-P) to create default rules. Security-minded administrators usually elect to drop all packets as a policy and only allow speciﬁc packets on a case-by-case basis. The following rules block all incoming and outgoing packets on a network gateway:

iptables -P INPUT DROP iptables -P OUTPUT DROP

Additionally, it is recommended that any forwarded packets — network trafﬁc that is to be routed from the ﬁrewall to its destination node — be denied as well, to restrict internal clients from inadvertent exposure to the Internet. To do this, use the following rule:

iptables -P FORWARD DROP

68 Chapter 7. Firewalls

Note

There is a distinction between the REJECT and DROP target actions when dealing with appended rules. The REJECT target denies access and returns a connection refused error to users who attempt to connect to the service. The DROP, as the name implies, drops the packet without any warning to

telnet users. Administrators can use their own discretion when using these targets; however, to

avoid user confusion and attempts to continue connecting, the REJECT target is recommended.

After setting the policy chains, create new rules for your particular network and security requirements. The following sections outline some rules you may implement in the course of building your IPTables ﬁrewall.

7.2.2. Saving and Restoring IPTables Rules

Firewall rules are only valid for the time the computer is on. If the system is rebooted, the rules are automatically ﬂushed and reset. To save the rules so that they will load later, use the following command:

/sbin/service iptables save

The rules are stored in the ﬁle /etc/sysconfig/iptables and are applied whenever the service is started or restarted, including when the machine is rebooted.

7.3. Common iptables Filtering

Keeping remote attackers out of a LAN is an important aspect of network security, if not the most important. The integrity of a LAN should be protected from malicious remote users through the use of stringent ﬁrewall rules. However, with a default policy set to block all incoming, outgoing, and forwarded packets, it is impossible for the ﬁrewall/gateway and internal LAN users to communicate with each other or externally. To allow users to perform network-related functions and use networking applications, administrators must open certain ports for communication.

For example, to allow access to port 80 on the ﬁrewall, append the following rule:

iptables -A INPUT -p tcp -m tcp --sport 80 -j ACCEPT iptables -A OUTPUT -p tcp -m tcp --dport 80 -j ACCEPT

This allows regular Web browsing from websites that communicate via port 80. To allow access to secure websites (such as https://www.example.com/), you must open port 443, as well.

iptables -A INPUT -p tcp -m tcp --sport 443 -j ACCEPT iptables -A OUTPUT -p tcp -m tcp --dport 443 -j ACCEPT

There may be times when you require remote access to the LAN from outside the LAN. Secure services, such as SSH and CIPE, can be used for encrypted remote connection to LAN services. For administrators with PPP-based resources (such as modem banks or bulk ISP accounts), dialup access can be used to circumvent ﬁrewall barriers securely, as modem connections are typically behind a ﬁrewall/gateway because they are direct connections. However, for remote users with broadband connections, special cases can be made. Youcan conﬁgure IPTables to accept connections from remote SSH and CIPE clients. For example, to allow remote SSH access, the following rules may be used:

iptables -A INPUT -p tcp --dport 22 -j ACCEPT iptables -A OUTPUT -p udp --sport 22 -j ACCEPT

Chapter 7. Firewalls 69

CIPE connection requests from the outside can be accepted with the following command (replacing x with your device number):

iptables -A INPUT -p udp -i cipcbx -j ACCEPT iptables -A OUTPUT -p udp -o cipcbx -j ACCEPT

Since CIPE uses its own virtual device which transmits datagram (UDP) packets, the rule allows the

cipcb interface for incoming connections, instead of source or destination ports (though they can be

used in place of device options). For information about using CIPE, refer to Chapter 6 Virtual Private Networks.

There are other services for which you may need to deﬁne rules. Refer to the Red Hat Enterprise Linux Reference Guide for comprehensive information on IPTables and its various options.

These rules allow access to regular and secure services on the ﬁrewall; however, they do not allow nodes behind the ﬁrewall access to these services. To allow LAN access to these services, you can use NAT with IPTables ﬁltering rules.

7.4. FORWARD and NAT Rules

Most organizations are allotted a limited number of publicly routable IP addresses from their ISP. Due to this limited allowance, administrators must ﬁnd creative ways to share access to Internet services without giving scarce IP addresses to every node on the LAN. Using private IP address is the common way to allow all nodes on a LAN to properly access network services internally and externally. Edge routers (such as ﬁrewalls) can receive incoming transmissions from the Internet and route the packets to the intended LAN node; at the same time, ﬁrewall/gateways can also route outgoing requests from a LAN node to the remote Internet service. This forwarding of network trafﬁc can become dangerous at times, especially with the availability of modern cracking tools that can spoof internal IP addresses and make the remote attacker’s machine act as a node on your LAN. To prevent this, iptables provides routing andforwarding policies that can be implemented to prevent aberrant usage of network resources.

The FORWARD policy allows an administrator to control where packets can be routed within a LAN. For example, to allow forwarding for the entire LAN (assuming the ﬁrewall/gateway has an internal IP address on eth1), the following rules can be set:

iptables -A FORWARD -i eth1 -j ACCEPT iptables -A FORWARD -o eth1 -j ACCEPT

Note

By default, the IPv4 policy in Red Hat Enterprise Linux kernels disables support for IP forwarding, which prevents boxes running Red Hat Enterprise Linux from functioning as dedicated edge routers. To enable IP forwarding, run the following command:

sysctl -w net.ipv4.ip_forward=1

If this command is run via shell prompt, then the setting is not remembered after a reboot. You can permanently set forwarding by editing the /etc/sysctl.conf ﬁle. Find and edit the following line, replacing 0 with 1:

net.ipv4.ip_forward = 0

Execute the following command to enable the change to the sysctl.conf ﬁle:

sysctl -p /etc/sysctl.conf

70 Chapter 7. Firewalls

This allows LAN nodes to communicate with each other; however they are not allowed to communicate externally (for example, to the Internet). To allow LAN nodes with private IP addresses to communicate with external public networks, conﬁgure the ﬁrewall for IP masquerading, which masks requests from LAN nodes with the IP address of the ﬁrewall’s external device (in this case, eth0):

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

7.5. DMZs and iptables

Rules can also be set to route trafﬁc to certain machines, such as a dedicated HTTP or FTP server, preferably one that is isolated from the internal network on a de-militarized zone (DMZ). To set a rule for routing all incoming HTTP requests to a dedicated HTTP server at IP address 10.0.4.2 and port 80 (outside of the 192.168.1.0/24 range of the LAN), network address translation (NAT) calls a

PREROUTING table to forward the packets to the proper destination:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j DNAT \

--to-destination 10.0.4.2:80

With this command, all HTTP connections to port 80 from the outside of the LAN are routed to the HTTP server on a separate network from the rest of the internal network. This form of network segmentation can prove safer than allowing HTTP connections to a machine on the network. If the HTTP server is conﬁgured to accept secure connections, then port 443 must be forwarded as well.

7.6. Viruses and Spoofed IP Addresses

More elaborate rules can be created that control access to speciﬁc subnets, or even speciﬁc nodes, within a LAN. You can also restrict certain dubious services such as trojans, worms, and other client/server viruses from contacting their server. For example, there are some trojans that scan networks for services on ports from 31337 to 31340 (called the elite ports in cracking lingo). Since there are no legitimate services that communicate via these non-standard ports, blocking it can effectively diminish the chances that potentially infected nodes on your network independently communicate with their remote master servers.

iptables -A OUTPUT -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP iptables -A FORWARD -o eth0 -p tcp --dport 31337 --sport 31337 -j DROP

You can also block outside connections that attempt to spoof private IP address ranges to inﬁltrate your LAN. For example, if your LAN uses the 192.168.1.0/24 range, a rule can set the Internet facing network device (for example, eth0) to drop any packets to that device with an address in your LAN IP range. Because it is recommended to reject forwarded packets as a default policy, any other spoofed IP address to the external-facing device (eth0) will be rejected automatically.

iptables -A FORWARD -s 192.168.1.0/24 -i eth0 -j DROP

7.7. IP6Tables

The introduction of the next-generation Internet Protocol, called IPv6, expands beyond the 32-bit address limit of IPv4 (or IP). IPv6 supports 128-bit addresses and, as such, carrier networks that are IPv6 aware are able to address a larger number of routable addresses than IPv4.

Chapter 7. Firewalls 71

Red Hat Enterprise Linux supports IPv6 ﬁrewall rules using the Netﬁlter 6 subsystem and the IP6Tables command. The ﬁrst step in using IP6Tables is to start the IP6Tables service. This can be done with the command:

service ip6tables start

Warning

The IPTables services must be turned off to use the IP6Tables service exclusively:

service iptables stop chkconfig iptables off

To make IP6Tables start by default whenever the system is booted, change the runlevel status on the service using chkconfig.

chkconfig --level 345 ip6tables on

The syntax is identical to IPTables in every aspect except that IP6Tables supports 128-bit addresses. For example, SSH connections on a IPv6-aware network server can be enabled with the following rule:

ip6tables -A INPUT -i eth0 -p tcp -s 3ffe:ffff:100::1/128 --dport 22 -j ACCEPT

For more information about IPv6 networking, refer to the IPv6 Information Page at http://www.ipv6.org/.

7.8. Additional Resources

There are several aspects to ﬁrewalls and the Linux Netﬁlter subsystem that could not be covered here. For more information, refer to the following resources.

7.8.1. Installed Documentation

• The Red Hat Enterprise Linux Reference Guide has a comprehensive chapter on IPTables, including

deﬁnitions for all command options.

• The IPTables manual page contains a brief summary of the various options, as well.

• A list of common services and their port numbers can be found in Appendix C Common Ports and

in /etc/services.

7.8.2. Useful Websites

• http://www.netﬁlter.org/ — The ofﬁcial homepage of the Netﬁlter/IPTables project.

• http://www.tldp.org/ — The Linux Documentation Project contains several useful guides relating

to ﬁrewall creation and administration.

• http://www.iana.org/assignments/port-numbers — The ofﬁcial list of registered and common ser-

vice ports as assigned by the Internet Assigned Numbers Authority.

72 Chapter 7. Firewalls

7.8.3. Related Documentation

• Linux Firewalls, by Robert Ziegler; New Riders Press. — contains a wealth of information on

building ﬁrewalls using both 2.2 kernel IPChains as well as Netﬁlter and IPTables. Additional security topics such as remote access issues and Intrusion Detection Systems are also covered.

III. Assessing Your Security

This part provides an overview of the theory and practice of security assessment. From network monitors to cracking tools, an administrator can learn more about securing a system and a network by cracking into it.

Table of Contents

8. Vulnerability Assessment .............................................................................................................75

Chapter 8.

Vulnerability Assessment

Given the time, resources, and motivation, a cracker can break into nearly any system. At the end of the day, all the security procedures and technologies currently available cannot guarantee any systems are safe from intrusion. Routers can help to secure gateways to the Internet. Firewalls help secure the edge of the network. Virtual Private Networks can safely pass data in an encrypted stream. Intrusion detection systems can warn you of malicious activity. However, the success of each of these technologies is dependent upon a number of variables, including:

• The expertise of the staff responsible for conﬁguring, monitoring, and maintaining the technologies.

• The ability to patch and update services and kernels quickly and efﬁciently.

• The ability of those responsible to keep constant vigilance over the network.

Given the dynamic state of data systems and technologies, securing corporate resources can be quite complex. Due to this complexity, it is often difﬁcult to ﬁnd expert resources for all of your systems. While it is possible to have personnel knowledgeable in many areas of information security at a high level, it is difﬁcult to retain staff who are experts in more than a few subject areas. This is mainly because each subject area of information security requires constant attention and focus. Information security does not stand still.

8.1. Thinking Like the Enemy

Suppose you administer an enterprise network. Such networks are commonly comprised of operating systems, applications, servers, network monitors, ﬁrewalls, intrusion detection systems, and more. Now imagine trying to keep current with every one of these. Given the complexity of today’s software and networking environments, exploits and bugs are a certainty. Keeping current with patches and updates for an entire network can prove to be a daunting task in a large organization with heterogeneous systems.

Combine the expertise requirements with the task of keeping current, and it is inevitable that adverse incidents occur, systems are breached, data is corrupted, and service is interrupted.

To augment security technologies and aid in protecting systems, networks, and data, think like a cracker and gauge the security of systems by checking for weaknesses. Preventative vulnerability assessments against your own systems and network resources can reveal potential issues that can be addressed before a cracker exploits it.

A vulnerability assessment is an internal audit of your network and system security; the results of which indicate the conﬁdentiality, integrity, and availability of your network (as explained in Section

1.1.4 Standardizing Security). Typically, vulnerability assessment starts with a reconnaissance phase during which important data regarding the target systems and resources is gathered. This phase leads to the system readiness phase, whereby the target is essentially checked for all known vulnerabilities. The readiness phase culminates in the reporting phase, where the ﬁndings are classiﬁed into categories of high, medium, and low risk; and methods for improving the security (or mitigating the risk of vulnerability) of the target are discussed.

If you were to perform a vulnerability assessment of your home, you would likely check each door to your home to see if they are shut and locked. You would also check every window, making sure that they shut completely and latch correctly. This same concept applies to systems, networks, and electronic data. Malicious users are the thieves and vandals of your data. Focus on their tools, mentality, and motivations, and you can then react swiftly to their actions.

76 Chapter 8. Vulnerability Assessment

8.2. Deﬁning Assessment and Testing

Vulnerability assessments may be broken down into one of two types: Outside looking in and inside looking around.

When performing an outside looking in vulnerability assessment you are attempting to compromise your systems from the outside. Being external to your company provides you with the cracker’s viewpoint. You see what a cracker sees — publicly-routable IP addresses, systems on your DMZ, external interfaces of your ﬁrewall, and more.

When you perform an inside looking around vulnerability assessment you are somewhat at an advantage since you are internal and your status is elevated to trusted. This is the viewpoint you and your co-workers have once logged on to your systems. You see print servers, ﬁle servers, databases, and other resources.

There are striking distinctions between these two types of vulnerability assessments. Being internal to your company gives you elevated privileges — more so than any outsider. Still today in most organizations, security is conﬁgured in such a manner as to keep intruders out. Very little is done to secure the internals of the organization (such as departmental ﬁrewalls, user-level access controls, authentication procedures for internal resources, and more). Typically, there are many more resources when inside looking around as most systems are internal to a company. Once you set yourself outside the company, you immediately are given untrusted status. The systems and resources available to you externally are typically much more limited.

Consider the difference between vulnerability assessments and penetration tests. Think of a vulnerability assessment as the ﬁrst step to a penetration test. The information gleaned from the assessment will be used in the testing. Whereas, the assessment is checking for holes and potential vulnerabilities, the penetration testing actually attempts to exploit the ﬁndings.

Assessing network infrastructure is a dynamic process. Security, both information and physical, is dynamic. Performing an assessment shows an overview, which can turn up false positives and false negatives.

Security administrators are only as good as the tools they use and the knowledge they retain. Take any of the assessment tools currently available, run them against your system, and it is almost a guarantee that there will be at least some false positives. Whether by program fault or user error, the result is the same. The tool may ﬁnd vulnerabilities which in reality do not exist (false positive); or, even worse, the tool may not ﬁnd vulnerabilities that actually do exist (false negative).

Now that the difference between vulnerability assessment and penetration test is deﬁned, it is often good practice to take the ﬁndings of the assessment and review them carefully before conducting a penetration test.

Warning

Attempting to exploit vulnerabilities on production resources can have adverse effects to the productivity and efﬁciency of your systems and network.

The following list examines some of the beneﬁts to performing vulnerability assessments.

• Proactive focus on information security

• Finding potential exploits before crackers ﬁnd them

• Typically results in systems being kept up to date and patched

• Promotes growth and aids in developing staff expertise

• Financial loss and negative publicity abated

Chapter 8. Vulnerability Assessment 77

8.2.1. Establishing a Methodology

To aid in the selection of tools for vulnerability assessment, it is helpful to establish a vulnerability assessment methodology. Unfortunately, there is no predeﬁned or industry approved methodology at this time; however, common sense and best practices can act as a sufﬁcient guide.

What is the target? Are we looking at one server, or are we looking at our entire network and everything within the network? Are we external or internal to the company? The answers to these questions

are important as they will help you determine not only which tools to select but also the manner in which the they will be used.

To learn more about establishing methodologies, refer to the following websites:

• http://www.isecom.org/projects/osstmm.htm — The Open Source Security Testing Methodology

Manual (OSSTMM)

• http://www.owasp.org/ — The Open Web Application Security Project

8.3. Evaluating the Tools

A typical assessment can start by using some form of information gathering tool. When assessing the entire network, map the layout ﬁrst to ﬁnd the hosts that are running. Once located, examine each host individually. Focusing on these hosts will require another set of tools. Knowing which tools to use may be the most crucial step in ﬁnding vulnerabilities.

Just as in any aspect of everyday life, there are many different tools that perform the same job. This concept applies to performing vulnerability assessments as well. There are tools speciﬁc to operating systems, applications, and even networks (based on protocols used). Some tools are free; others are not. Some tools are intuitive and easy to use, while others are cryptic and poorly documented but have features that other tools do not.

Finding the right tools may be a daunting task. In the end, experience counts. If possible, set up a test lab and try out as many tools as you can, noting the strengths and weaknesses of each. Review the README ﬁle or man page for the tool. In addition, look to the Internet for more information, such as articles, step-by-step guides, or even mailing lists speciﬁc to a tool.

The tools discussed below are just a small sampling of the available tools.

8.3.1. Scanning Hosts with Nmap

Nmap is a popular tool included in Red Hat Enterprise Linux that can be used to determine the layout of a network. Nmap has been available for many years and is probably the most often used tool when gathering information. An excellent man page is included that provides a detailed description of its options and usage. Administrators can use Nmap on a network to ﬁnd host systems and open ports on those systems.

Nmap is a competent ﬁrst step in vulnerability assessment. You can map out all the hosts within your network and even pass an option that allows it to attempt to identify the operating system running on a particular host. Nmap is a good foundation for establishing a policy of using secure services and stopping unused services.

8.3.1.1. Using Nmap

Nmap can be run from a shell prompt. At a shell prompt, type the nmap command followed by the hostname or IP address of the machine to scan.

nmap foo.example.com

78 Chapter 8. Vulnerability Assessment

The results of the scan (which could take up to a few minutes, depending on where the host is located) should look similar to the following:

Starting nmap V. 3.00 ( www.insecure.org/nmap/ ) Interesting ports on localhost.localdomain (127.0.0.1): (The 1591 ports scanned but not shown below are in state: closed) Port State Service 22/tcp open ssh 25/tcp open smtp 111/tcp open sunrpc 515/tcp open printer 950/tcp open oftep-rpc 6000/tcp open X11

Nmap run completed -- 1 IP address (1 host up) scanned in 0 seconds

Nmap tests the most common network communication ports for listening or waiting services. This knowledge can be helpful to an administrator who wants to close down unnecessary services.

For more information about using Nmap, refer to the ofﬁcial homepage at the following URL:

http://www.insecure.org/

8.3.2. Nessus

Nessus is a full-service security scanner. The plug-in architecture of Nessus allows users to customize it for their systems and networks. As with any scanner, Nessus is only as good as the signature database it relies upon. Fortunately, Nessus is frequently updated. It features full reporting, host scanning, and real-time vulnerability searches. Remember that there could be false positives and false negatives, even in a tool as powerful and as frequently updated as Nessus.

Note

Nessus is not included with Red Hat Enterprise Linux and is not supported. It has been included in

this document as a reference to users who may be interested in using this popular application.

For more information about Nessus, refer to the ofﬁcial website at the following URL:

http://www.nessus.org/

8.3.3. Nikto

Nikto is an excellent CGI scanner. Nikto has the capability to not only check for CGI vulnerabilities but do so in an evasive manner, so as to elude intrusion detection systems. It comes with excellent documentation which should be carefully reviewed prior to running the program. When you have found your Web servers serving up CGI scripts, Nikto can be an excellent resource for checking the security of these servers.

Chapter 8. Vulnerability Assessment 79

Note

Nikto is not included with Red Hat Enterprise Linux and is not suppor ted. It has been included in this document as a reference to users who may be interested in using this popular application.

More information about Nikto can be found at the following URL:

http://www.cirt.net/code/nikto.shtml

8.3.4. VLAD the Scanner

VLAD is a scanner developed by the RAZOR team at Bindview, Inc. which may be used to check for vulnerabilities. It checks for the SANS Top Ten list of common security issues (SNMP issues, ﬁle sharing issues, etc.). While not as full-featured as Nessus, VLAD is worth investigating.

Note

VLAD is not included with Red Hat Enterprise Linux and is not supported. It has been included in this document as a reference to users who may be interested in using this popular application.

More information about VLAD can be found on the RAZOR team website at the following URL:

http://razor.bindview.com/tools/vlad/index.shtml

8.3.5. Anticipating Your Future Needs

Depending upon your target and resources, there are many tools available. There are tools for wireless networks, Novell networks, Windows systems, Linux systems, and more. Another essential part of performing assessments may include reviewing physical security, personnel screening, or voice/PBX network assessment. New concepts, such as war walking — scanning the perimeter of your enterprise’s physical structures for wireless network vulnerabilities — are some emerging concepts that you can investigate and, if needed, incorporate in your assessments. Imagination and exposure are the only limits of planning and conducting vulnerability assessments.

80 Chapter 8. Vulnerability Assessment

IV. Intrusions and Incident Response

It is inevitable that a network falls to intrusion or malicious use of network resources. This part discusses some proactive measures an administrator can take to prevent security breaches, such as forming an emergency response team capable of quickly and effectively responding to security issues. This part also details the steps an administrator can take to collect and analyze evidence of a security breach after the fact.

Table of Contents

9. Intrusion Detection ....................................................................................................................... 83

10. Incident Response ....................................................................................................................... 89

Chapter 9.

Intrusion Detection

Valuable property needs to be protected from the prospect of theft and destruction. Some homes are equipped with alarm systems that can deter burglars, notify authorities when a break-in has occurred, and even warn owners when their home is on ﬁre. Such measures are necessary to ensure the integrity of homes and the safety of homeowners.

The same assurance of integrity and safety should also be applied to computer systems and data. The Internet has facilitated the ﬂow of information, from personal to ﬁnancial. At the same time, it has fostered just as many dangers. Malicious users and crackers seek vulnerable targets such as unpatched systems, systems infected with trojans, and networks running insecure services. Alarms are needed to notify administrators and security team members that a breach has taken place so that they can respond in real-time to the threat. Intrusion detection systems have been designed as such a warning system.

9.1. Deﬁning Intrusion Detection Systems

An intrusion detection system (IDS) is an active process or device that analyzes system and network activity for unauthorized entry and/or malicious activity. The way that an IDS detects anomalies can vary widely; however, the ultimate aim of any IDS is to catch perpetrators in the act before they do real damage to resources.

An IDS protects a system from attack, misuse, and compromise. It can also monitor network activity, audit network and system conﬁgurations for vulnerabilities, analyze data integrity, and more. Depending on the detection methods you choose to deploy, there are several direct and incidental beneﬁts to using an IDS.

9.1.1. IDS Types

Understanding what an IDS is, and the functions it provides, is key in determining what type is appropriate to include in a computer security policy. This section discusses the concepts behind IDSes, the functionalities of each type of IDS, and the emergence of hybrid IDSes that employ several detection techniques and tools in one package.

Some IDSes are knowledge-based, which preemptively alert security administrators before an intrusion occurs using a database of common attacks. Alternatively, there are behavioral IDSes that track all resource usage for anomalies, which is usually a positive sign of malicious activity. Some IDSes are standalone services that work in the background and passively listen for activity, logging any suspicious packets from the outside. Others combine standard system tools, modiﬁed conﬁgurations, and verbose logging, with administrator intuition and experience to create a powerful intrusion detection kit. Evaluating the many intrusion detection techniques can assist in ﬁnding one that is right for your organization.

9.2. Host-based IDS

A host-based IDS analyzes several areas to determine misuse (malicious or abusive activity inside the network) or intrusion (breaches from the outside). Host-based IDSes consult several types of log ﬁles (kernel, system, server, network, ﬁrewall, and more), and compare the logs against an internal database of common signatures for known attacks. UNIX and Linux host-based IDSes make heavy use of syslog and its ability to separate logged events by their severity (for example, minor printer messages versus major kernel warnings). The host-based IDS ﬁlters logs (which, in the case of some

84 Chapter 9. Intrusion Detection

network and kernel event logs, can be quite verbose), analyzes them, re-tags the anomalous messages with its own system of severity rating, and collect them in its own specialized log for administrator analysis.

Host-based IDSes can also verify the data integrity of important ﬁles and executables. It checks a database of sensitive ﬁles (and any ﬁles added by the administrator) and creates a checksum of each ﬁle with a message-ﬁle digest utility such as md5sum (128-bit algorithm) or sha1sum (160-bit algorithm). The host-based IDS then stores the sums in a plain text ﬁle and periodically compares the ﬁle checksums against the values in the text ﬁle. If any of the ﬁle checksums do not match, the IDS alerts the administrator by email or cellular pager. This is the process used by Tripwire, which is discussed in Section 9.2.1 Tripwire.

9.2.1. Tripwire

Tripwire is the most popular host-based IDS for Linux. Tripwire, Inc., the developers of Tripwire, opened the software source code for the Linux version and licensed it under the terms of the GNU General Public License. Tripwire is available from http://www.tripwire.org/.

Note

Tripwire is not included with Red Hat Enterprise Linux and is not supported. It has been included in this document as a reference to users who may be interested in using this popular application.

9.2.2. RPM as an IDS

The RPM Package Manager (RPM) is another program that can be used as a host-based IDS. RPM contains various options for querying packages and their contents. These veriﬁcation options can be invaluable to an administrator who suspects that critical system ﬁles and executables have been modiﬁed.

The following list details some options for RPM that can verify ﬁle integrity on a Red Hat Enterprise Linux system. Refer to the Red Hat Enterprise Linux System Administration Guide for complete information about using RPM.

Important

Some of the commands in the following list require the importation of the Red Hat GPG public key into the system’s RPM keyring. This key veriﬁes that packages installed on the system contain an Red Hat package signature, which ensures that the packages originated from Red Hat. The key can be imported by issuing the following command as root (substituting RPM installed on the system):

rpm --import /usr/share/doc/rpm-BversionC/RPM-GPG-KEY

rpm -V package_name

versionAwith the version of

The -V option veriﬁes the ﬁles in the installed package called package_name. If it shows no output and exits, this means that none of the ﬁles have been modiﬁed in anyway since the last time the RPM database was updated. If there is an error, such as the following

S.5....T c /bin/ps

Chapter 9. Intrusion Detection 85

then the ﬁle has been modiﬁed in some way and you need to assess whether to keep the ﬁle (such as with modiﬁed conﬁguration ﬁles in the /etc/ directory) or delete the ﬁle and reinstall the package that contains it. The following list deﬁnes the elements of the 8-character string

(S.5....T in the above example) that notiﬁes of a veriﬁcation failure.

• . — The test has passed this phase of veriﬁcation

• ? — The test has found a ﬁle that could not be read, which is most likely a ﬁle permission

issue

• S — The test has encountered a ﬁle that that is smaller or larger than it was when originally

installed on the system

• 5 — The test has found a ﬁle whose md5 checksum does not match the original checksum of

the ﬁle when ﬁrst installed

• M — The test has detected a ﬁle permission or ﬁle type error on the ﬁle

• D — The test has encountered a device ﬁle mismatch in major/minor number

• L — The test has found a symbolic link that has been changed to another ﬁle path

• U — The test has found a ﬁle that had its user ownership changed

• G — The test has found a ﬁle that had its group ownership changed

• T — The test has encountered mtime veriﬁcation errors on the ﬁle

rpm -Va

The -Va option veriﬁes all installed packages and ﬁnds any failure in its veriﬁcation tests (much like the -V option, but more verbose in its output since it is verifying every installed package).

rpm -Vf /bin/ls

The -Vf option veriﬁes individual ﬁles in an installed package. This can be useful when performing a quick veriﬁcation of a suspect ﬁle.

rpm -K application-1.0.i386.rpm

The -K option is useful for checking the md5 checksum and the GPG signature of an RPM package ﬁle. This is useful for checking whether a package about to be installed is signed by Red Hat or any organization for which you have the GPG public key imported into a GPG keyring. A package that has not been properly signed triggers an error message similar to the following:

application-1.0.i386.rpm (SHA1) DSA sha1 md5 (GPG) NOT OK

(MISSING KEYS: GPG#897da07a)

Exercise caution when installing packages that are unsigned as they are not approved by Red Hat, Inc. and could contain malicious code.

RPM can be a powerful tool, as evidenced by its many veriﬁcation tools for installed packages and RPM package ﬁles. It is strongly recommended that the contents of the RPM database directory (/var/lib/rpm/) be backed up to read-only media, such as CD-ROM, after installation of Red Hat Enterprise Linux. Doing so allows veriﬁcation of ﬁles and packages against the read-only database, rather than against the database on the system, as malicious users may corrupt the database and skew the results.

9.2.3. Other Host-based IDSes

The following list discusses some of the other popular host-based intrusion detection systems available. Refer to the websites of the respective utilities for more information about installing and conﬁguring them.

86 Chapter 9. Intrusion Detection

Note

These applications are not included with Red Hat Enterprise Linux and are not supported. They have been included in this document as a reference to users who may be interested in evaluating such applications.

• SWATCH http://www.stanford.edu/~atkins/swatch/ — The Simple WATCHer (SWATCH) uses log

ﬁles generated by syslog to alert administrators of anomalies based on user conﬁguration ﬁles. SWATCH was designed to log any event that the user wants to add into the conﬁguration ﬁle; however, it has been adopted widely as a host-based IDS.

• LIDS http://www.lids.org/ — The Linux Intrusion Detection System (LIDS) is a kernel patch and

administration tool that can also control ﬁle modiﬁcation with access control lists (ACLs) and protect processes and ﬁles, even from the root user.

9.3. Network-based IDS

Network-based intrusion detection systems operate differently from host-based IDSes. The design philosophy of a network-based IDS is to scan network packets at the router or host-level, auditing packet information, and logging any suspicious packets into a special log ﬁle with extended information. Based on these suspicious packets, a network-based IDS can scan its own database of known network attack signatures and assign a severity level for each packet. If severity levels are high enough, a warning email or pager call is placed to security team members so they can further investigate the nature of the anomaly.

Network-based IDSes have become popular as the Internet grows in size and trafﬁc. IDSes that can scan the voluminous amounts of network activity and successfully tag suspect transmissions are wellreceived within the security industry. Due to the inherent insecurity of the TCP/IP protocols, it has become imperative to develop scanners, sniffers, and other network auditing and detection tools to prevent security breaches due to such malicious network activity as:

• IP Spooﬁng

• Denial-of-service attacks

• arp cache poisoning

• DNS name corruption

• Man-in-the-middle attacks

Most network-based IDSes require that the host system network device be set to promiscuous mode, which allows the device to capture every packet passed on the network. Promiscuous mode can be set through the ifconfig command, such as the following:

ifconfig eth0 promisc

Running ifconfig with no options reveals that eth0 is now in promiscuous (PROMISC) mode.

eth0 Link encap:Ethernet HWaddr 00:00:D0:0D:00:01

inet addr:192.168.1.50 Bcast:192.168.1.255 Mask:255.255.252.0 UP BROADCAST RUNNING PROMISC MULTICAST MTU:1500 Metric:1 RX packets:6222015 errors:0 dropped:0 overruns:138 frame:0 TX packets:5370458 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100

Chapter 9. Intrusion Detection 87

RX bytes:2505498554 (2389.4 Mb) TX bytes:1521375170 (1450.8 Mb) Interrupt:9 Base address:0xec80

lo Link encap:Local Loopback

inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:21621 errors:0 dropped:0 overruns:0 frame:0 TX packets:21621 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1070918 (1.0 Mb) TX bytes:1070918 (1.0 Mb)

Using a tool such as tcpdump (included with Red Hat Enterprise Linux), we can see the large amounts of trafﬁc ﬂowing throughout a network:

tcpdump: listening on eth0 02:05:53.702142 pinky.example.com.ha-cluster > \

heavenly.example.com.860: udp 92 (DF)

02:05:53.702294 heavenly.example.com.860 > \

pinky.example.com.ha-cluster: udp 32 (DF)

02:05:53.702360 pinky.example.com.55828 > dns1.example.com.domain: \

PTR? 192.35.168.192.in-addr.arpa. (45) (DF)

02:05:53.702706 ns1.example.com.domain > pinky.example.com.55828: \

6077 NXDomain* 0/1/0 (103) (DF)

02:05:53.886395 shadowman.example.com.netbios-ns > \

172.16.59.255.netbios-ns: NBT UDP PACKET(137): QUERY; BROADCAST

02:05:54.103355 802.1d config c000.00:05:74:8c:a1:2b.8043 root \

0001.00:d0:01:23:a5:2b pathcost 3004 age 1 max 20 hello 2 fdelay 15

02:05:54.636436 konsole.example.com.netbios-ns > 172.16.59.255.netbios-ns: \

NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

02:05:56.323715 pinky.example.com.1013 > heavenly.example.com.860:\

udp 56 (DF)

02:05:56.323882 heavenly.example.com.860 > pinky.example.com.1013:\

udp 28 (DF)

Notice that packets that were not intended for our machine (pinky.example.com) are still being scanned and logged by tcpdump.

9.3.1. Snort

While tcpdump is a useful auditing tool, it is not considered a true IDS because it does not analyze and ﬂag packets for anomalies. Instead, tcpdump prints all packet information to the screen or to a log ﬁle without any analysis. A proper IDS analyzes the packets, tags potentially malicious packet transmissions, and stores them in a formatted log.

Snort is an IDS designed to be comprehensive and accurate in successfully logging malicious network activity and notifying administrators when potential breaches occur. Snort uses the standard libcap library and tcpdump as a packet logging backend.

The most prized feature of Snort, in addition to its functionality, is its ﬂexible attack signature subsystem. Snort has a constantly updated database of attacks that can be added to and updated via the Internet. Users can create signatures based on new network attacks and submit them to the Snort signature mailing lists (located at http://www.snort.org/lists.html) so that all Snort users can beneﬁt. This community ethic of sharing has developed Snort into one of the most up-to-date and robust network-based IDSes available.

88 Chapter 9. Intrusion Detection

Note

Snort is not included with Red Hat Enterprise Linux and is not supported. It has been included in this document as a reference to users who may be interested in evaluating it.

For more information about using Snort, refer to the ofﬁcial website at http://www.snort.org/.

Redhat ENTERPRISE LINUX 3 User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual