Linux Security on HP Servers: Securing the Network Boundary

Technical introduction This white paper -- one in a series of Linux security white papers -- discusses networking security technologies that can be used to secure an HP Red Hat Enterprise (RHEL) or SUSE Linux Enterprise Server (SLES) based system against network attacks.

Abstract The power and flexibility of Linux can be employed to greatly enhance its security in many ways. This white paper series discusses how to take full advantage of the many security features available in the Red Hat Enterprise Linux and SUSE Linux Enterprise Server operating systems, to ensure your servers and data center are as secure as possible.

This white paper, Linux Security on HP Servers: Securing the Network Boundary, covers how to ensure that network traffic to and from your HP Linux based servers is approved and secure. Topics covered by this white paper include configuring firewalls, encrypting network traffic, and the secure configuration of network services provided by your server.

Intended Audience

This white paper series is intended for administrators of HP Linux servers needing to better secure those servers by gaining a greater understanding of the full arsenal of security tools that the Red Hat Enterprise Linux (RHEL5), and SUSE Linux Enterprise Server (SLES) operating systems provide; by those evaluating Linux on HP servers to determine its security capabilities; and, by those comparing security technologies against what is available on other operating systems.

Table of Contents Table of Contents................................................................................................................................. 2 Overview............................................................................................................................................ 3

Introduction ..................................................................................................................................... 3 Focus on Server Security ............................................................................................................... 4

Securing the Network Boundary ............................................................................................................ 4 Network Application Configuration.................................................................................................... 4

Common UNIX Printing System (CUPS) ........................................................................................... 4 File Transfer Protocol (FTP)................................................................................................................. 5

Web Services (HTTP) .................................................................................................................... 6 Lightweight Directory Access Protocol (LDAP) ................................................................................... 9 Mail Services (SMTP/IMAP/POP)................................................................................................. 12 Microsoft Windows File Sharing (SMB/CIFS)................................................................................. 14 Network File System (NFS) .......................................................................................................... 17 Network Time Protocol (NTP) ....................................................................................................... 19 Secure Shell (SSH)...................................................................................................................... 21

Configuring a Firewall .................................................................................................................... 22 Understanding Firewall Basics...................................................................................................... 22 Firewall Configuration................................................................................................................. 28 Firewall Examples....................................................................................................................... 28 Protecting IPv6 Traffic ................................................................................................................. 29

Using HP Software with Linux Firewalling.......................................................................................... 31 HP Insight Control Environment .................................................................................................... 31 HP ProLiant Support Pack ............................................................................................................ 32

Encrypting Network Traffic .............................................................................................................. 32 Full Network Encryption with IPsec ............................................................................................... 32 Understanding IPsec ................................................................................................................... 33 Application Specific Encryption with SSL/TLS................................................................................. 36

Summary .......................................................................................................................................... 37 For more information.......................................................................................................................... 38

Additional Linux Security Resources.................................................................................................. 38

Overview

Introduction Unless your server is locked in a computer room and not connected to any network, it is potentially vulnerable to unauthorized access, primarily via its network ports. Unless it is properly protected, the data on your server might be retrieved, deleted, or altered by intruders.

In order to maximize the security of an HP Linux based server, it must be properly configured. That is especially true if your server can be reached from a public network. This white paper discusses how to secure the network boundary between your server and the world around it. Specifically this paper discusses:

Configuring network applications (services) running on your server to limit their use to only the users that you authorize.

Running a properly configured firewall. Encrypting sensitive network traffic traveling to and from your server.

There are many other steps you can (and should) take to secure your HP Linux servers. The following topics are covered by other white papers in this series.

Linux Security on HP Servers: General Security Topics:

Regularly install the latest available operating system and application software patches to ensure you are running the latest available security patches.

Carefully control access to all superuser accounts. Enforce good password policy, ensuring that all of your user accounts have strong passwords

that are changed regularly. Harden your server’s file systems by ensuring permissions are properly set so that access to each

file, directory, and file system is restricted to only those users that must have it. Encrypt sensitive information so that if the information is accessed without proper authorization it

will be difficult for the intruder to use it. Restrict the number of services your server provides to only those that are essential for its

operation. Log and audit events on your server so that if intrusions do occur, you can determine what was

compromised, when, and by whom. Use an intrusion detection system to regularly verify that your server’s installed software

packages and their associated configurations have not been altered.

All of the above are important, but probably the most effective thing you can do to secure your server is to supplement the discretionary access control, provided by the traditional ownerships and permissions found in Linux, with a mandatory access control mechanism:

In the Red Hat Enterprise Linux operating system, SELinux provides this protection for all aspects of the system. For information on how SELinux works, see Linux Security on HP Servers: SELinux.

In SUSE Linux Enterprise Server operating system, AppArmor provides mandatory access control for files and directories.

In summary, do not run anything that is not essential, tightly control network access, isolate processes and users from each other so that they can access only those system resources that are necessary to function, log all activity in case you need to reconstruct a chain of events, and encrypt sensitive information to limit its exposure if your system is compromised.

3

Focus on Server Security While all systems, including workstations and PCs, can benefit from many of the recommendations in this white paper, this paper will focus primarily on servers, such as those found in large data centers. These machines frequently serve many users over large geographic areas, require nearly 100% uptime, often contain sensitive and personal data that must be protected (in many cases by law), and are frequently the targets of malicious attacks.

Securing the Network Boundary Attacks on systems frequently occur via a network connection. Applications running on your system provide network-based services that users and applications from other systems use to access your system remotely. These network services, necessary for network based communication, are often targets of attacks.

Best Practices: You can reduce the chances of a successful security breach by:

Limiting which network services your system provides to only those necessary for your business.

Properly configuring a firewall to permit network traffic from (and to) only those systems necessary for your business.

Encrypting sensitive network traffic to and from your system so that someone monitoring the traffic cannot easily determine the contents.

Network Application Configuration The following services and protocols are common ways users interact with your server over the network. If your needs do not require you to provide these services from your server to other machines, remove or disable them.

Common UNIX Printing System (CUPS) CUPS, the Common UNIX Printing System, provides a printing interface that allows both local and remote printing. The remote printing features of CUPS are implemented using the Internet Printing Protocol (IPP), but CUPS also provides compatibility with legacy Windows and UNIX-based printing systems. CUPS is flexible and fairly secure in that you can both control and authenticate users wanting to print to printers that are locally connected to your system. However, unless you must support printing to locally attached printers, the most secure thing to do is disable CUPS.

To temporarily disable CUPS, use the command:

# service cupsd stop

To prevent CUPS from starting with the next system boot, use your preferred configuration tool to disable CUPS.

Note: CUPS is also used by local processes to print to remote printers, so do not disable CUPS if you need it for that purpose.

4

To configure your system to act as a print server for other networked clients, edit the file /etc/cups/cupsd.conf to only permit print requests from specific remote systems (preferred) or specific networks. For example:

<Location /printers>

Order Deny,Allow Processes “Deny” Statements before “Allow” Statements

Deny From All Denies from all systems not explicitly allowed

Allow From 127.0.0.1 Allows printing from the local system

Allow host1.example.com

Allows printing from the system host1.example.com

Allow 10.1.7.199 Allows printing from IP address 10.1.7.199

Allow *.domain7.com Allows printing from all systems in domain7.com

Allow 10.1/16 Allows printing from all systems with IP addresses in 10.1.*.*

</Location>

There are many CUPS configuration options to help you configure printing on your server as securely as possible (for example, requiring authentication, specifying encryption requirements, and limiting the maximum size of print requests). See the cupsd.conf(8) manpage for a complete list.

File Transfer Protocol (FTP) The File Transfer Protocol (FTP) was developed before many of today’s modern security technologies, and as a result, is not very secure (for example, it transfers data, user names, and passwords unencrypted). Therefore, do not enable the use of FTP unless your operation is unable to use an alternative. Though there are ways to secure FTP, users have a much better alternative with SSH, which provides a more secure FTP-like utility called sftp. See Secure Shell (SSH) for details.

As with many Linux technologies, unless your system must act as an FTP server you should disable the FTP server daemon. The FTP server is called vsftp. To disable it, use the command:

# chkconfig vsftpd off

If your system must serve as a traditional FTP server:

Make sure the vsftpd software package is installed from your installation media. vsftpd is configured using the file /etc/vsftpd/vsftpd.conf. The following

configuration options are recommended to help secure your vsftp installation:

° Enable FTP transaction logging using these two lines: xferlog_std_format=NO Sets verbose mode

° log_ftp_protocol=YES Enables logging

The default log file for vsftpd is /var/log/vsftpd.log.

° If possible, restrict access to allow only anonymous users. Use the following entry: local_enable=no Disables logins to local accounts

5

° If you choose to allow local users to login to the system via vsftp using their user accounts, limit which users can access your system via FTP by entering all of the following lines in vsftpd.conf:

− userlist_enable=YES These two lines collectively indicate that users

userlist_deny=NO listed in the file specified by “userlist_file” are allowed to log in using FTP. userlist_file=/etc/vsftpd.ftpusers

− Then, for each user who should be allowed FTP access to the system, add an entry in the vsftpd.ftpusers file.

° If your server is only to be used to distribute files and is not needed for uploads, disable uploading of files using the entry: write_enable=NO Disables file uploading

Best Practices:

If you do require both uploading and downloading of files over FTP:

° Make sure you use separate directories for the uploads and downloads. You do not want unauthorized users contaminating your downloads with unapproved files.

° Make sure your upload directory (if not both the upload and download directories) is on a separately mountable file system. You do not want users filling up a file system that is critical to other operations of your system by uploading too much data via FTP.

Configure your firewall to permit FTP traffic. For information on how to do this, see Configuring a Firewall and Firewall Examples.

Web Services (HTTP) Web server software is a common target for malicious attacks. Unless your server must serve general web content, do not install or enable a web server.

Note: Many local system administration tools provide a Web interface; some of these provide their own integrated Web server, while others rely on the system’s Web server. If you need to use an administration tool that uses the system’s Web server you may not be able to disable the system’s Web server completely. Instead, you can configure firewall rules to isolate HTTP access to only the local loopback address. For information on how to do that, see Configuring a Firewall and Firewall Examples.

If your system does need to run a web server -- probably Apache -- ensure that you install it from a trusted source such as the original installation media.

When installing Apache you should install only the minimal necessary components for Apache to operate. Reducing complexity is a security hallmark; therefore, limit the number of Apache add-on modules to those critical to your operation. Extra features, though often useful, potentially provide additional vulnerabilities for attack.

There are two types of Apache modules: built-in modules and Dynamically Shared Object (DSO) modules.

6

You need at least these DSO modules for basic operation:

auth_basic_module authn_default_module

authz_host_module authz_user_module

authz_groupfile_module authz_default_module

log_config_module logio_module

setenvif_module mime_module

autoindex_module negotiation_module

dir_module alias_module

You can verify they are loaded using the command:

# httpd -M

You can also use DSO modules to add features. You enable these in Apache’s configuration file, /etc/httpd/conf/httpd.conf, using entries similar to this:

LoadModule auth_basic_module modules mod_auth_basic.so

In addition to the “LoadModule” entry, DSO modules may require configuration to enable specific features. You accomplish this using Apache directives to enable/configure specific features. The sample directive below restricts what can be done with the Apache root directory:

<Directory / > Options None AllowOverride None Order allow, deny </Directory>

This directive says that no additional features can be enabled for accessing files in the Apache server’s root directory (Options None), settings for the Apache server’s root directory cannot be overridden using a .htaccess file (AllowOverride None), and access is allowed from all users except those specifically denied access (Order allow, deny). For details on which directives are associated with each DSO, see the official Apache documentation at http://httpd.apache.org/docs.

If you have directives in your configuration file that are not associated with a loaded module, you will get configuration errors. To check that all directives have their appropriate module loaded, use the following command on Red Hat Enterprise Linux:

# service httpd configtest

Or, the following command on SUSE Linux Enterprise Server:

# service apache2 configtest

Remember, load only what you need; unnecessary modules provide unnecessary complexity, which can lead to a less secure system.

Some Apache modules can actually enhance security. For example, the modules in the following table perform HTTP user authentication.

7

Module Name Description

authn_file_module Uses a local plain text password file (similar to /etc/passwd) to authenticate users

authn_dbm_module Uses a local DBM database file to authenticate users, often with better performance than the text file method

authn_alias_module Uses aliases to authenticate users

authz_owner_module Uses file ownership to authenticate users

authz_dbm_module Similar to authn_dbm_module but uses group identification instead of user identification

ldap_module authnz_ldap_module

Used for LDAP authentication

Other modules that can help improve Apache’s security include:

Module Name Description

mod_ssl HTTP is a plain text protocol. Using HTTP, data is exchanged without encryption. mod_ssl adds SSL/TLS encryption capabilities to Apache. With mod_ssl you install the module, create an SSL certificate, and configure the file /etc/httpd/conf.d/ssl.conf to reference the certificate. See Application Specific Encryption with SSL/TLS) for information on SSL/TLS.

mod_security Adds an application level firewall to Apache. For details on configuring this Apache firewall module, see: http://www.modsecurity.org.

mod_throttle mod_bwshare mod_limitipconn mod_dosevasive

Denial-of-Service (DoS) attacks are one of the key dangers faced by the providers of web services. DoS attacks flood a web server with traffic (to limit its performance or prevent its proper function). They are difficult to protect against while still allowing legitimate traffic to your site. If you provide critical web services over the Internet you should consider using one of these modules to facilitate the flow of traffic to your site under DoS conditions.

In addition to carefully configuring Apache’s add-on modules there are some other important protective actions you should consider:

If you must use the PHP server-side scripting language:

° Configure it to minimize or eliminate the information it provides users, other than its normal output (for example, error messages, version information).

° Make sure you log all errors.

° Use safe mode (and SQL safe mode as well, if your PHP code accesses an SQL database).

° Isolate the locations from which PHP executables can be run.

Protect the server from internal tampering by locking down critical files:

° The Apache executable should be configured with mode u=rx, g=x, o=x

° The Apache logging directory, should be configured with mode u=rwx, g=rx, o=

° The directory containing the Apache configuration files, should be configured with mode u=rwx, g=rx, o=

8

° Files within the configuration directory should be configured with mode u=rw, g=r, o=

° The configuration directory itself and all of its contents (files and sub-directories) should have ownership settings of “apache:apache” for Red Hat Enterprise Linux, or “wwwrun:www” for SUSE Linux Enterprise Server.

° Beyond the above permissions settings, you should consider using the mandatory access control provided by SELinux (on Red Hat Enterprise Linux) or AppArmor on (SUSE Linux Enterprise Server), for even greater protection. For detailed information about the extra protections SELinux will provide, see the white paper Linux Security on HP Servers: SELinux.

Configure your firewall to permit incoming traffic from common HTTP ports. For details on how to do this, see Configuring a Firewall.

Lightweight Directory Access Protocol (LDAP) The Lightweight Directory Access Protocol is a client/server technology that can have multiple clients and multiple servers. It is used to maintain a common tree structure of directory-style information among many clients; for example, enterprise-level contact information. Because LDAP is used (often in conjunction with Pluggable Authentication Modules) for central user authentication, and because it can be used to deliver other sensitive information, you need to take steps to secure it. In order to secure LDAP you need to secure every LDAP client and every LDAP server.

This section is not a complete configuration guide but rather a list of recommended settings for LDAP, to ensure access to the LDAP server is controlled. For complete information on configuring OpenLDAP, see http://www.openldap.org; and, for more detailed information about securing LDAP, see Guide to the Secure Configuration of Red Hat Enterprise Linux 5 – National Security Agency, United States of America listed in Additional Linux Security Resources.

Best Practices:

Configure all LDAP clients and servers to require secured communications using one of the following technologies:

° SSL/TLS – see Understanding SSL/TLS for more information about TLS and SSL

° SASL – the Simple Authentication and Security Layer

Install the OpenLDAP server RPM only on those machines that will function as LDAP servers. LDAP clients do not need it and wherever possible you should avoid installing unnecessary software.

Configure the firewalls of each machine to permit LDAP traffic only from appropriate network addresses for your intended use. Only LDAP servers should permit new LDAP network connections through their firewalls. For general information on configuring firewalls, see Configuring a Firewall.

Properly secure your LDAP database and application files so that they cannot be tampered with. The files in the directory tree rooted at /var/lib/ldap should be owned by ldap:root.

9

Configuring an OpenLDAP Server Configure all machines that will function as LDAP servers before configuring LDAP client machines.

LDAP Server Configuration Tools

The OpenLDAP service, /usr/sbin/slapd, can be configured on Red Hat Enterprise Linux using an automated tool called authconfig or its GUI counterpart system-config-authentication. On SUSE Linux Enterprise Server the same configuration is possible using the yast2 ldap command.

The OpenLDAP service can also be configured by editing the file /etc/openldap/slapd.conf, which gives you greater control over the configuration (specifically the ability to specify the locations of SSL certificate files); therefore, use slapd.conf to configure your LDAP servers.

NOTE: If you will have more than one LDAP server in your network, use the alternate LDAP server: /usr/sbin/slurpd instead of slapd. slurpd synchronizes changes from one LDAP server to other LDAP servers in your network.

The LDAP Server Configuration File

The file slapd.conf should be owned by root:ldap, have an access mode of u=rw,g=r,o= and contain a hashed password string that is created with the slappasswd command. The entry will look something like:

rootpw {SSHA}hashed-password-string

The configuration file should:

Identify the Distinguished Name (DN) for the root of the shared directory tree Identify the DN of the root user and any other administrators Limit access to attributes called “userPassword”:

° Users can only write (update) their own password

° Administrators can write (update) all passwords

° Anonymous users can authenticate against (but not update) a predefined password

° No one else can access userPassword attributes

° All information (other than userPassword attributes) should be writable only by administrators but readable by everyone, unless your specific implementation dictates otherwise).

Ensure that all transactions require secure connections, for example using SSL/TLS encryption.

Securing LDAP Server Transactions with TLS

To ensure that all transactions use secure connections, you must first use OpenSSL and your site’s certificate authority (CA) machine to create a “Server Certificate” file and a “Server Certificate Key” file

for each LDAP server. You then need to put these two files, along with a copy of the CA’s certificate file (for site validation), on the LDAP server and put entries like the following in the slapd.conf configuration file to point to the certificates:

TLSCACertificateFile /etc/pki/tls/CA/cacert.pem

TLSCertificateFile /etc/pki/tls/ldap/servercert.pem

TLSCertificateKeyFile /etc/pki/tls/ldap/serverkey.pem

10

In addition to the above three entries, you should add the following line to slapd.conf, which tells the LDAP server to require clients to present passwords in encrypted form:

security simple_bind=128

Logging Transactions on the LDAP Server

Finally, you should configure machines running the LDAP server software to capture an appropriate level of log data. OpenLDAP uses the syslog facility local4 (using debug priority). The entry for /etc/syslog.conf should look like:

local4.* /var/log/ldap.log

You also need to tell the LDAP server how much to log. Do this by putting an entry such as this into the slapd.conf configuration file:

loglevel stats2

Replace “stats2” with “stats” for more detailed connection logging, but if you have a fairly large LDAP installation this might create more logging data than you need. Your auditing requirements and available disk space will dictate your choice.

Configuring an OpenLDAP Client LDAP clients are configured in a manner similar to LDAP servers. As with LDAP servers, you can use the automated configuration tool: authconfig, its graphical counterpart system-config-authentication, or yast2 ldap to configure your LDAP clients. Which you choose depends on the Linux platform you are using, and your preference. Also, as with LDAP servers, you should use the configuration file instead to configure LDAP so that you can specify the locations of the SSL certificates (in order to ensure that all LDAP transactions use encrypted and authenticated communication).

The configuration file for LDAP clients is /etc/ldap.conf. It should include the following entries to force LDAP to require SSL/TLS, and to trust certificates signed by your site’s certificate authority machine (CA). In addition to these entries, you need to insure each client has a copy of the CA certificate:

base dc=xyz,dc=org Identifies LDAP domain

uri ldap://ldapservername.xyz.org/ and how to contact the LDAP server

ssl start_tls

tls_checkpeer yes

tls_cacertdir /etc/pki/tls/CA

tls_cacertfile /etc/pki/tls/CA/cacert.pem

pam_password md5 This entry tells LDAP to expect passwords in MD5 hash format instead of plain text

For clients, there is one extra configuration file to edit: /etc/openldap/ldap.conf. It should contain the following entries:

BASE dc=xyz,dc=org Identifies LDAP domain

URI ldap://ldapservername.xyz.org/ and how to contact the LDAP server

TLS_CACERTDIR /etc/pki/tls/CA

TLS_CACERT /etc/pki/tls/CA/cacert.pem

11

If you are going to use LDAP for central user authentication (one of its most common uses), you need to adjust the Name Service Switch configuration file (/etc/nsswitch.conf) to use “ldap” for the passwd, shadow, and group entries:

passwd: files ldap

shadow: files ldap

group: files ldap

If you use PAM, see the Guide to the Red Hat Enterprise Linux 5 - National Security Agency, United States of America, listed in Additional Linux Security Resources for additional PAM configuration security measures.

Best Practice:

Do not install the OpenLDAP server RPM on machines that will be only LDAP clients. It is unnecessary and therefore creates unnecessary potential points of entry.

Mail Services (SMTP/IMAP/POP) The software that handles the routing of mail in an email system is known as a Mail Transport Agent (MTA). Unless the email is being sent only between users of the local system, the MTA communicates with the MTAs of other networked systems to exchange email messages.

Email is a form of communication that is not only subject to security issues related to technology (for example, spoofed addresses and file tampering), but also security issues related to human gullibility (for example, phishing); therefore, MTAs are often targets for attacks. You should minimize the number of systems that are mail servers, and only run the server portion of MTA software on those systems.

MTAs perform two important functions:

They listen for incoming SMTP email requests. They send mail from the local machine, periodically attempting to resend any delayed mail

(whether it originated locally or is being relayed from a remote system).

Ideally, you should set up a single system, or a small group of selected systems, on your network to perform the MTA server functions (the first of the two functions above). Other systems with users that need to communicate using email should be set up as mail clients, communicating on a local (protected) network with a designated mail server. Machines that do not need to process email in any form should be configured to completely disable the MTA software.

There are two commonly used MTAs that are shipped with Red Hat Enterprise Linux and SUSE Linux Enterprise Server:

Sendmail – A powerful, highly configurable, and frequently used MTA Postfix – Also powerful and flexible, easier to configure than sendmail

Configuring a System as a Mail Server Configuring a system to be a mail server is more involved. Because of the risks involved, a mail server is an appropriate machine to isolate and use for little else, if possible. Here are the risks you need to guard the mail server against:

People breaking into the server system and viewing or tampering with email in transit Denial of service attacks, created by flooding the MTA daemons with too much traffic,

preventing them from doing legitimate work

12

Attackers using the mail server to relay unsolicited bulk email (spam), which could potentially blacklist your server and prevent it from being used to send legitimate email

To prevent unauthorized users from tampering with email, only administrators should be allowed local access to your mail server. If that system must be used for multiple purposes, do not allow unrestricted access to the mail spool, located /var/spool/mail.

Best Practice:

Mail servers are critically important to protect. HP recommends always using mandatory access control (by using SELinux on Red Hat Enterprise Linux systems or AppArmor on SUSE Linux Enterprise Server systems). This is especially important on multi-purpose systems.

In addition to not allowing standard users to log in to the mail server, you should also prevent remote access to the mail spool (for example, no NFS, CIFS, SMB, or FTP access).

Denial of service events, which can occur when someone accidentally or deliberately floods a mail server with email at a very high rate, result in problems with the processing of legitimate mail and can also affect other system operations. By carefully configuring the following items, you can minimize the damage a flood of email can impose on your mail server:

The number of MTA daemons that can be run simultaneously The rate at which incoming email can be received How large or complex an acceptable email message can be The amount of free space that must remain available in the mail queue at all times

Certain values in the configuration files for both Sendmail and PostFix can be adjusted to control the number of MTA processes, connection limits and connection rates, minimum free space requirements in the mail queues, header sizes, message sizes, and the number of recipients a message can have. For details on what these settings are called and reasonable values for them, see the Guide to the Secure Configuration of Red Hat Enterprise Linux 5 – National Security Agency, United States of America, listed in Additional Linux Security Resources.

Though no one has yet completely solved the problem of Unsolicited Bulk Email (UBE), also known as spam, you can help prevent your server from being used to send UBE by carefully controlling who can send email messages through your mail server. This will help ensure that your server is not blacklisted, preventing you from using it to send legitimate email. System administrators can subscribe to managed lists of IP addresses known to regularly send or forward UBE. They can then set up their mail servers (via special blacklist plug-ins) to block email from IP addresses on these lists. If your system for any reason (known to you or not) sends or forwards too much UBE, it could end up on a blacklist and then even legitimate email from your system could be unable to reach its intended destination because it has been blocked.

13

If all of your mail client systems are on an internal network, or in an address range that you completely control, you can simply allow your mail server to only allow the relaying of messages from those trusted mail clients.

Figure 1: Mail Servers and Clients

If you have clients that must connect remotely (as in Remote Mail Client #4 in the illustration above), or if you must relay mail from network addresses that you cannot completely control, you should use the SMTP AUTH mechanism to require email senders from those untrusted mail clients to authenticate themselves before submitting messages to the mail server. In addition, like both POP and IMAP, the SMTP communications should be encrypted using SSL/TLS.

To set up the SSL/TLS certificates for use by the SMTP protocol you need to generate the appropriate certificates and key files on your certificate authority (CA) system (see Managing Certificates). Securely transport and install them on both the mail server (the key file) and each untrusted mail client (a copy of the server certificate that matches the server’s key file). In addition to the server certificates for SMTP, you will need to ensure that a copy of the CA’s signing certificate is located on each machine.

Note: If your client’s incoming mail server (POP or IMAP) is the same as the outgoing mail server, SMTP, you can use the same CA certificate and keys for the two services on the same machine which should help simplify the configuration.

Microsoft Windows File Sharing (SMB/CIFS) SMB/CIFS is technology for sharing file systems and providing print services. SMB/CIFS can be used between Linux and Microsoft Windows based systems. On Linux, the Samba service implements SMB/CIFS.

14

Samba, as with many network technologies, is a client/server based service. By default, only the client portion (called samba-client) is installed. If your system will not function as a Samba server, do not install the server package (known simply as samba). If the Samba server software has been installed, and you do not need to host printers or file systems for client machines, uninstall it. To temporarily disable the service:

# chkconfig smb off

Configuring Samba You configure Samba by editing the file /etc/samba/smb.conf. You can also configure Samba using a Web-based tool called SWAT, but doing so requires you to enter an administrator password and sends that password in clear text over the network. This is a very dangerous way to administer Samba and should be avoided. If you must install and use SWAT, use it only on the Samba server you are configuring, or use stunnel to protect the communications so that sensitive information is not sent over the network unencrypted. For more information about stunnel, see Stunnel.

Setting the Samba Security Mode There are five possible security modes in Samba:

1. Share (*) 2. User 3. Domain 4. ADS 5. Server (**)

* Do not use share: it uses a common password for a share that, if known, allows anyone to access the share. With everyone using the same password, it is difficult to know specifically who accessed the share.

** Do not use server: it is an older, now obsolete, security mode.

If your Samba server will perform its own authentication (validating clients against its own password database), use the user security mode (this is the default mode if none is specified):

[global]

security mode = user

If your Samba server will use a primary or backup domain controller to authenticate clients (if it will act as a Domain Member Server), use either the domain or the ads security mode. If your Samba server is part of an older NT domain, you need to supply a netbios name for it, and if necessary the name of the server’s workgroup.

[global]

security mode = domain

workgroup = your_workgroup_name

netbios name = netbios_name_of_this_Samba_server

If your Samba server is part of an Active Directory domain, you need to supply the realm and Kerberos server name.

[global]

security mode = ads

realm = this_server’s_kerberos_realm

password server = your_kerberos_server_name

15

Controlling Local and Remote Access to Samba Shares Do not allow guest users to access local shares. Though Samba can permit local file and print shares to be accessible to guest users (users not authenticating as a specific local user), this is not recommended as it limits accountability and traceability. Require that everyone accessing shares on your Samba server have their own account. To limit guest access to a share, put the following entry in /etc/samba/smb.conf:

[share_name]

guest ok = no

share_name in the above example refers to the section of the smb.conf file that corresponds to the share you are restricting guest access to. If you put the statement in the [global] section, you will restrict access to all shares on your server.

If possible, disable local logins for users who are accessing Samba shares from client machines. If they can access the files and printers they need via Samba, and do not need access to your Samba server for other purposes, eliminating the ability to login to the system means attackers have one less point of access. To disable local login capability for a specific user, replace the shell field in their /etc/passwd entry with /bin/false.

As important as it is to prevent standard users who connect via Samba from directly logging in to your Samba server, it is even more important to ensure that users cannot remotely connect as administrators to the Samba server. To prevent that access for any given share, put the following in the smb.conf file:

[share_name]

invalid users = root @wheel

IMPORTANT: This applies to all network mounted file systems, regardless of which technology (for example: NFS, CIFS, SMB) is used to mount them. You should never permit administrator access to network mounted file systems.

As with the examples above, replace share_name with the name of the specific share you are configuring, or put the entry in the [global] section to invalidate administrator connections for all Samba shares.

Configuring Samba Communication Protocols Because Samba was introduced to allow interoperability with the Microsoft Windows operating system family, it must be capable of using the underlying networking protocols of SMB/CIFS. Depending on which version of Microsoft Windows that Samba is communicating with, one of the following protocols will likely be used:

LANMAN an older, insecure protocol NTLMv1 an older protocol NTLMv2 the preferred protocol

Unless your Samba server is communicating with older operating systems that are incapable of using the NTLMv2 protocol, disable the LANMAN protocol for each client so that it cannot be used. The preferred protocol is NTLMv2 as it is far more secure than the other protocols. The following smb.conf entries will disable LANMAN and enable NTLMv2:

[global] client lanman auth = no client ntlmv2 auth = yes

If necessary, you can apply these entries to specific shares. If you have a few client machines that must use the older protocol, enable it for those clients only! The goal is to use NTLMv2 wherever possible.

16

Minimizing Access to Samba Shares (share only what is necessary) One of the key goals of security is to enable only what is absolutely necessary, and nothing more. With Samba you should restrict which files, printers, and other information you share and carefully control with whom you share them.

There is a special share called [IPC$] that allows SMB/CIFS clients to browse which resources are being shared from your Samba server. You should restrict who can browse this information. You can do that with the following entries (substituting the appropriate network address blocks for your network):

[IPC$] hosts allow = 10.0.7/24 10.0.6/24 192.168.3.177 hosts deny = 0.0.0.0/0

The second entry (hosts deny) above, denies access to all computers who are not specifically on the hosts allow list.

By default, only users with local accounts on your Samba server will be able to access its shares, but you can further restrict access to individual shares based on client, groups, and users. The following entries specify that only users Phred and Keana, and members of the group marketing can access share1, and only from clients with IP addresses on the 10.0.1 subnet. Also, only Phred and Keana have write access to the share. Other members (the marketing group) have read-only access:

[share1] hosts allow = 10.0.1. valid users = phred keana @marketing read only = yes write list = phred keana hosts deny = 0.0.0.0/0

Similarly, you should restrict access to any printer shares so that only intended users can print via your Samba server:

[printers] hosts allow = 10.0.7/24 valid users = @pneumaticsdept @pyrotechnicsdept itmgr7 hosts deny = 0.0.0.0/0

If you have no printers to share, remove or comment out the entries for the [printers] section, and in the [global] section, comment out these lines:

[global] ; load printers = yes ; cups options = raw

Also, configure your firewall to further ensure that only clients you specify can access your server via Samba. For details on creating the needed firewall rules (see Configuring a Firewall and Firewall Examples).

Network File System (NFS) The Network File System (NFS) is a widely used protocol for remotely mounting the file systems of other computers such that they appear as part of the local directory tree. Though new versions of NFS have been released that address some of the security problems present in previous versions, the protocol has been around for quite a while and was not originally designed with modern security risks in mind.

NFS is based on network Remote Procedure Calls (RPC) that require the use of a port mapping daemon called portmap. portmap provides RPC with flexibility by enabling NFS clients to use varying port numbers. Instead, each time you boot your system, a new set of port numbers can be assigned to the NFS related daemons.

17

This weakens security in two ways:

portmap is a daemon listening for network connections (making it a potential target for an attacker).

The default configuration’s dynamic port number assignment makes it difficult to create firewall rules to limit which systems can access the NFS server

Note: NFS version 4 is more firewall friendly and does not require you to use the port mapper (though it still has other security issues). NFS version 3 is currently the default version in many installations and the issues above do apply to version 3. If you do use NFS, use the most recent version possible, disable the port mapper, and configure your system’s firewall to control which systems can connect to your NFS shares.

Disabling NFS Given its potential security problems, the best recommendation for securing NFS is to disable it unless it is mission critical. To disable NFS:

Disable all services that are used only by NFS on Red Hat Enterprise Linux with the following commands:

# chkconfig nfslock off

# chkconfig rpcgssd off

# chkconfig rpcidmapd off

And on SUSE Linux Enterprise Server with the following command:

# chkconfig nfs off

On Red Hat Enterprise Linux if you do not mount any NFS file systems at boot you should also disable the netfs service:

# chkconfig netfs off

If you are certain that a system does not need to use any RPC-based services (NFS, NIS authentication, and others), then you should also disable the port mapper:

# chkconfig portmap off

To help determine if it is safe to disable the port mapper, you can probe it to see which processes are using it using the command:

# rpcinfo –p

If only the port mapper and status services are listed, you can disable the port mapper.

Securing NFS If you must use NFS, there are a few steps you can take to limit your system’s exposure to attackers.

Be sure that all clients and servers are on an internal network, protected by a gateway with a firewall

Since you cannot disable the port mapper if you are using NFS, you should restrict which remote systems can access it. The port mapper shipped with both Red Hat Enterprise Linux and SUSE Linux Enterprise Server has TCP Wrapper support, which allows you to control which remote systems can access it by putting the following entries in the /etc/hosts.allow and /etc/hosts.deny files:

° In the hosts.deny file, put the entry: portmap: ALL Denies access to all systems (unless configured in hosts.allow)

18

° Then, in the hosts.allow file, put the entry portmap: 10.0.0.4, 10.0.0.5 Use actual IP addresses or netblocks for systems you want to allow access

Even though the port mapper will still be used, you can control which ports are used for the various NFS services, rather than letting them be randomly selected at boot time. This will enable you to use firewalling, which requires known port numbers. To use fixed NFS ports, edit the file /etc/sysconfig/nfs and add or change the following lines:

LOCKD_TCPPORT=port_number

LOCKD_UDPPORT=port_number

MOUNTD_PORT=port_number

RQUOTAD_PORT=port_number

STATD_PORT=port_number

STATD_OUTGOING_PORT=port_number

For each entry above, replace port_number with a port number that is unused by any other service on your system. You can use the netstat utility to determine which ports are currently in use on your system by running:

# netstat -nlut

NFS Client-Specific Configuration The services called nfs and rpcsvcgssd are server specific services. Because they are not needed on an NFS client, turn them off using the commands:

# chkconfig nfs off

# chkconfig rpcsvcgssd off

When you are mounting NFS file systems from an NFS server, use the options nodev, nosuid, and noexec if possible. Edit any entries in /etc/fstab for file systems of types nfs and nfs4 to be sure those entries include these three options.

NFS Server-Specific Configuration On NFS servers, the /etc/exports file defines which local directories can be made available to NFS clients, which clients can access each directory, and with which server side options. Be sure to carefully configure this file as defined in the exports(5) manpage. Make sure you include a list of authorized clients for each entry. Leaving off this information can make the file system available to clients you do not intend.

Unless you need clients to write to a local file system, export it as read-only.

Be sure you create firewall rules to allow only legitimate NFS clients to access the server. For general information about configuring a firewall, see Configuring a Firewall.

Network Time Protocol (NTP) Synchronizing the clocks of all of the computers in your network is a critical function for many reasons, including security. Kerberos and other security related protocols use timestamps to prevent certain types of attacks. Also, if you need to reconstruct the events leading up to a security breach, especially one involving multiple systems in your network, having good synchronization between the clocks will assist you in determining the correct order of events.

19

Time synchronization is so important to so many system functions that a special protocol, the Network Time Protocol (NTP), was developed. Though NTP is complex and feature rich, you can gain many of the benefits of time synchronization with even the simplest of configurations.

Best Practice:

To minimize the strain on the NTP server infrastructure, configure one computer on your network to synchronize to a known and trusted time source. Then configure the other computers on your network to synchronize their clocks to that local time server.

NTP is configured using the file /etc/ntp.conf. This file is where you configure which time sources your computer will synchronize with, and which other computers (clients) can connect to yours to retrieve time data. Because the NTP daemon ntpd runs as root and is a complex daemon, you need to protect it from unauthorized access. To do this, use the following entry in /etc/ntp.conf to deny all access to any machine (server or client) that is not specifically authorized by other policy settings:

restrict default ignore

Then add lines similar to the following for each server you want your computer to retrieve time from:

restrict server-ip-address mask 255.255.255.255 nomodify notrap noquery

server server-ip-address

You can have more than one set of the above entries (to retrieve time data from multiple time servers), so that if one is inaccessible your computer can synchronize to one of the others. The restrict command in the above pair limits the actions of remote systems on the local system. The server command allows your computer to access the remote time server.

If your computer is not going to be a time server for other hosts on your network, you do not need any further entries in your ntp.conf file. However, if other computers will contact yours to retrieve time data, additional configuration is required. You need to specify which network address blocks (ranges of IP addresses) will be allowed to contact your time server, and you need to ensure that the requests for time data from those client machines can pass through your server’s firewall.

To specify which clients can access your time server, add lines to /etc/ntp.conf of the following form:

restrict ip-address-range mask network-mask nomodify notrap

where ip-address-range specifies a set of addresses that fall within the network-mask. The nomodify option prevents the clients from modifying the state of the server, and the notrap option prevents certain types of queries used by remote event logging applications.

In addition to configuring NTP via /etc/ntp.conf, you also need to configure your server’s firewall to ensure that time requests from the clients can pass through to the NTP daemon.

Finally, you need to run the NTP daemon on a regular basis to update your system’s clock. Though there are NTP modes that will keep it running constantly, this is rarely necessary and can leave a possible port of entry for intruders. A crontab entry similar to the following will periodically update your server’s clock; once an hour is probably sufficient, though if your system’s clock drifts significantly or your timing needs are more stringent you should configure updates to occur more frequently:

17 * * * * root /usr/sbin/ntpd –q Updates the clock at 17 minutes past each hour

20

These are the basic steps you need to configure NTP. If your network requires additional security measures, NTP has many additional features including authentication and encryption. For complete details, see the http://ntp.org website.

Secure Shell (SSH) rlogin, remsh, ftp, and telnet use unencrypted transmissions; unencrypted communication over untrusted networks is extremely insecure; it can reveal passwords and other sensitive data to anyone sniffing traffic on the network.

Secure SHell (SSH) provides a secure alternative for the above commands and should always be the preferred utility for remote logins and file transfers. SSH establishes a secure, authenticated, connection with a server and ensures both data confidentiality and data integrity.

The SSH tools are easy to use and relatively easy to configure. Though SSH is fairly secure “out of the box”, there are some simple steps you can (and should) take to further improve its security. Specifically:

Disable SSH if you do not require anyone to remotely log into, or transfer data to, your server. To disable SSH:

° Use chkconfig to turn it off, and stop any currently running instances: # chkconfig sshd off # service sshd stop

° On Red Hat Enterprise Linux remove the openssh-server package from your server. Note: This only removes the SSH server daemon. Users on your system can still use SSH client applications such as ssh and sftp to securely log into other systems (that permit SSH connections).

Make sure you are using SSH Protocol 2 by editing the file /etc/ssh/sshd_config to be sure it includes the line: Protocol 2 and does not include any other “Protocol” entries.

Limit which users can access the system. You can do this by putting lines in sshd_config of the form: DenyUsers phred betty janitor4

which denies the users “phred”, “betty”, and “janitor4” the ability to log into to the server using SSH, but permits all other users. This is the form to use if you have a limited number of accounts to restrict. If you want to restrict almost everyone but permit only a few accounts to be accessed using SSH, instead of the above entry, you could use an entry of the form: AllowUsers bryan cj evan matt

which would permit the users “bryan”, “cj”, “evan”, and “matt” to use SSH to log into the server but deny everyone else.

One user that you might think should be permitted access to your server using SSH is “root”. However, allowing “root” direct access enables a malicious user to attempt a brute force attack on the root account password and it provides little, if any, audit logging of specifically who is using the

21

root account. It is better to require remote users to log in using a non-root account and then use a command like su or sudo to accomplish tasks that require administrator capabilities.

Best Practices:

Do not use empty passwords. They are easy to try and instantly admit an intruder to your system.

Disable (passwd –d) any accounts not requiring someone to directly log in.

Use a warning banner (the file /etc/issue), but be careful not to include useful information such as the operating system type or version, or other information that could be used to help an intruder determine which security exploits might work.

Set an idle timeout so that unattended SSH sessions will be automatically logged off after a short period of inactivity.

Disable ssh’s use of .rhosts files by putting the following entry in the sshd_config file: IgnoreRhosts yes

Configuring a Firewall A host based network firewall is a critical component of the network boundary. It is a shield that, when properly configured, blocks unwanted traffic from entering (or leaving) your server. A firewall is essential when connecting your server to an untrusted network.

Best Practice: Certain security implementations (for example, using a software based firewall like Netfilter/IPTables) have the potential to impact performance. For many systems this performance impact is minor and unnoticeable, for other systems it can be significant. If the performance impact of running a software based firewall on your system is too great, consider offloading the firewall tasks to a dedicated firewall system on your network, or using HP ProCurve switches that have built-in firewall protection. For information on ProCurve switches and their security features, see: http://www.procurve.com.

Understanding Firewall Basics Firewalls are highly configurable. By properly configuring your server’s firewall you can maximize its effectiveness. Both during initial installation of your server and later, when running the system’s firewall configuration tool, you are able to configure a basic firewall; however, to maximize the effectiveness of your firewall you should consider customizing your firewall settings using the Netfilter facility built into Linux. You do this using the iptables command.

Introduction to Netfilter and IPTables The Linux firewall system is composed of two main parts, Netfilter and IPtables. Netfilter is the kernel component which handles the per-packet access control. IPtables, specifically the iptables command, is the name given to the tools used by the administrator to configure the Netfilter subsystem in the kernel. Netfilter and the iptables command are extremely powerful and flexible, accommodating almost any firewall need.

22

Netfilter uses a set of rules to determine what happens to network packets flowing through the firewall. These rules are created using the iptables command and are arranged in sequential lists called chains. There are built-in chains that are always present and you can create user-defined chains for special purposes if needed. The built-in chains are:

CHAIN PURPOSE

PREROUTING Rules processed for all inbound network packets, before initial routing of the packet takes place.

FORWARD Rules that process packets destined for computers other than the one running this firewall.

INPUT Rules processed for inbound network packets that are destined for this system (the system running the firewall).

OUTPUT Rules processed for outbound packets that originate on this system (the system running the firewall).

POSTROUTING

Rules processed for all outbound network packets after all routing adjustments and decisions have been made. POSTROUTING rules are processed just before the packet leaves the system’s network interface.

23

The general flow of network packets through the firewall is illustrated below. For simplicity, the illustration only shows traffic originating from the public network and destined for the private (protected) network, however Netfilter handles traffic flowing in both directions.

Figure 2: Firewall components and flow

24

Conceptually, the individual rules represent the “links” of a chain. The rules are stored in four tables and each table can contribute rules to a chain. Not every table contributes rules to every chain. The tables have specific purposes that limit which chains will use their rules. The tables are:

Table Purpose

Raw Used only for marking a packet

Mangle

Used for altering certain specific fields in network packet headers. Specifically:

TOS

TTL

MARK

SECMARK

CONNSECMARK

NAT

NAT stands for Network Address Translation. Rules in this table are used for altering a network packet’s source and destination IP addresses. The two primary reasons for NAT are:

To share a single external IP address with multiple nodes on a private network.

To hide internal IP addresses from an external network.

Filter Used to do the actual packet filtering.

The following illustration shows the “OUTPUT chain” -- the chain that processes traffic originating from the firewall computer itself. This chain can have rules contributed from each of the four tables. Note: The phrase “OUTPUT chain” is in quotes because each table actually maintains its own OUTPUT chain. The individual OUTPUT chains in each of the four tables are processed in the order shown in the following illustration to form the longer “chain” of rules for that given point in the firewall. The actual number of rules from each table’s OUTPUT chain can vary from zero to many depending on the purpose of the table, the type of chain and the specific configuration.

25

As each chain of rules is processed, each rule of that chain is examined in order (see Traffic Matching Example 1 in the Traffic Matching section for an example of why the order is important). Each rule can have an associated target action that will be performed if the network packet being processed matches the rule. The targets can instruct Netfilter to:

Figure 3: iptables rules chain assembly

− ACCEPT the packet (processing of all further rules is stopped)

− DROP the packet (throw it away without notifying the originator of the packet)

− REJECT the packet (throw it away, but notify the packet’s originator)

− RETURN: bypass the remaining rules in the chain and execute the default action for the chain (known as the chain policy)

− JUMP to another chain

Other target actions are possible as well, such as forwarding the network packet to a user-space application for processing, or logging the packet’s arrival in the system logs. Full details are available in the iptables(8) manpage and at the Netfilter website: http://netfilter.org.

After the OUTPUT chain rules from each table have been processed, and before proceeding to the next table’s output chain rules, a default action known as a chain policy is executed.

NOTE: OUTPUT chains have been used in the above illustration, but the same processing sequence applies to all built-in chain types (PREROUTING, FILTER, etc.).

User defined chains allow you to logically group rules by function and perform specified filtering only under specific conditions. User defined chains are processed by jumping to them from the built-in chains using a JUMP target action; they are processed like sub-routines or function calls. After processing all of the rules in a user-defined chain, processing resumes with the rule in the built-in chain following the rule that jumped to the user-defined chain.

Traffic Matching

Firewall rules can be configured to match network packets based on many different attributes. In addition to connection states, discussed in the following section, here are some of the types of attributes you can use in your rule definitions:

Source / destination IP addresses Source / destination network ports Security Parameter Index (SPI) ranges for IPsec packets The number of parallel TCP connections from a given IP source address The number of packets per second destined for a given IP address Packet length

26

Protocols in use within a packet IPsec policy types contained in a packet Whether packets contain specific strings of characters When the packet arrived (day of week, or time of day)

and many more.

Here are some examples of traffic matching iptables commands:

Traffic Matching Example 1

If a firewall is protecting an internal network on eth1, with addresses in the range of 10.0.7.0/24 and you want the machine running the firewall to accept all traffic from those addresses only, and not accept traffic on eth1 from any other addresses, use the following two entries:

# iptables -A INPUT -i eth1 -s 10.0.7.0/24 -j ACCEPT

# iptables -A INPUT -i eth1 -j DROP

The order of the above two entries is important. If you switch them all traffic would be dropped. In the order they appear above, the traffic you want to accept is accepted and all other traffic proceeds to the next rule which promptly drops it.

Traffic Matching Example 2:

iptables has many built-in matching features which can be extended using the “-m” option to load match extensions. Many of the match extensions are documented in the iptables(8) manpage. For example, if your server is running a web server such as Apache (running as user apachewww) and you want to keep track of traffic to and from the web server from the computers on the internal network in the above example, you could use the entries:

# iptables –A INPUT –i eth1 –p tcp --dport 80 –m account \ --aname apachewww --aaddr 10.0.7.0/24 --ashort

# iptables –A OUTPUT –i eth1 –p tcp --sport 80 –m account \ --aname apachewww --aaddr 10.0.7.0/24 --ashort

The first of the above entries accounts for incoming traffic to the web server (tcp packets with a destination port of 80 that arrive on the network interface eth1). The second of the above entries accounts for the outgoing traffic from the web server (tcp packets with a source port of 80 that arrive on the network interface eth1). The --aname indicates the name of the list where statistics will be kept. The --ashort indicates to collect only short statistics. There are no ACCEPT or DROP targets because with these two entries you are simply setting up traffic accounting. Target actions are not required for all rules.

The iptables(8) manpage and the http://netfilter.org website are filled with many examples of the different types of traffic matching you can do with iptables. With the tremendous flexibility available you should be able to configure almost any type of firewall you can imagine (from very simple to very complex).

Stateful Connection Tracking

Network packet headers for some protocols have fields that indicate the state of the network connection they represent. Based on the values of these fields, a network connection can be:

Attempting to initiate a connection (NEW) Responding to a connection attempt (RELATED) Part of an ongoing connection (ESTABLISHED) None of the above (INVALID)

These connection states can be used to configure your firewall in a flexible and secure way. For example, a firewall might allow computers on a protected private network to initiate web connections to the outside world, and accept the associated response packets and ongoing packets for that

27

connection, yet at the same time not permit computers from the outside world to initiate a connection to computers on the private network. In the following example, interface eth0 represents web traffic (destination port 80) coming in from the unprotected network to computers on the protected network connected via interface eth1. Only network packets in the ESTABLISHED or RELATED states will be accepted, meaning a web server on the unprotected network cannot initiate a new web connection to a computer protected by this firewall, but it can respond to requests initiated by one of the computers on the protected network.

# iptables -A FORWARD -i eth0 -o eth1 –p tcp –dport 80 \ -m state –state ESTABLISHED,RELATED -j ACCEPT

Even for stateless protocols that do not provide connection status features (for example UDP), Netfilter is able to maintain information about the state of the connections it has recently established by maintaining its own private connection state which can be viewed in the file /proc/net/ip_conntrack. With this private connection state database it is still possible to base firewall settings on a connection’s status, even with connectionless protocols. However, there is one condition: for protocols such as UDP that lack connection status, their state can only be tracked in /proc/net/ip_conntrack if your firewall allows new connections. Typically you would allow new connections for outbound traffic only. For example:

# iptables -A INPUT -p udp -m state --state ESTABLISHED -j ACCEPT # iptables -A OUTPUT -p udp -m state --state NEW,ESTABLISHED \ -j ACCEPT

Firewall Configuration The preceding discussion shows some of the many possibilities for writing firewall rules, but if your needs are basic a graphical tool called system-config-securitylevel on Red Hat Enterprise Linux (or yast2 firewall on SUSE Linux Enterprise Server) will allow you to easily configure which services to trust or not trust, and will write firewall configuration rules for you.

Writing Firewall Rules It is important to know that the iptables command configures the rules for the running instance of Netfilter. Unless they are saved and restored, the chains of rules configured by iptables will not survive reboots. However, both Red Hat Enterprise Linux and SUSE Linux Enterprise Server save (to the file /etc/sysconfig/iptables) the currently active Netfilter configuration and restore it following a reboot. To manually save the currently active configuration, use the iptables-save command. See the iptables-save(8) manpage for details. To manually restore a saved configuration to active duty, use the iptables-restore command documented in the iptables-restore(8) manpage.

Firewall Examples The following are examples of firewall rules for some of the protocols described in this white paper. These are only examples, and might or might not work verbatim in your network. They are grouped here to allow you to easily view their differences and commonalities.

FTP Traffic Firewall Rules

# iptables -A INPUT -p tcp -m state --state NEW --dport 21 -j ACCEPT # iptables -A OUTPUT -p tcp -m state --state NEW --sport 21 -j ACCEPT

For tracking FTP connections, you also need to edit the file /etc/sysconfig/iptables-config to be sure it includes the line

IPTABLES_MODULES=”ip_conntrack_ftp”

28

NOTE: If you already have an IPTABLES_MODULES entry in iptables-config, simply add “ip_contrack_ftp” into the existing space-separated list of modules to be loaded.

HTTP Web Server Firewall Rules (local loopback traffic)

# iptables –A INPUT –s 127.0.0.1 –m state -–state NEW,ESTABLISHED –p tcp –dport 80 \ –j ACCEPT

# iptables –A INPUT –s 127.0.0.1 –m state -–state NEW,ESTABLISHED –p tcp –dport 443 \ –j ACCEPT

HTTP Web Server Firewall Rules (common HTTP traffic) # iptables –A INPUT –m state –-state NEW –p tcp –dport 80 –j ACCEPT

# iptables –A INPUT –m state –-state NEW –p tcp –dport 443 –j ACCEPT

Samba Firewall Rules # iptables –A INPUT –s 10.0.7/24 –m state –-state NEW –p –tcp –dport 137 –j ACCEPT

# iptables –A INPUT –s 10.0.7/24 –m state –-state NEW –p –tcp –dport 138 –j ACCEPT

# iptables –A INPUT –s 10.0.7/24 –m state –-state NEW –p –tcp –dport 139 –j ACCEPT

# iptables –A INPUT –s 10.0.7/24 –m state –-state NEW –p –tcp –dport 445 –j ACCEPT

Network Time Protocol Firewall Rules (for access by clients)

# iptables -A INPUT –s 10.0.7/24 –m state –state NEW \ –p udp –dport 123 –j ACCEPT

Protecting IPv6 Traffic IPv6 is a new version of the IP protocol that provides a larger address space, as well as a number of other improvements based on lessons learned with IPv4. IPv6 offers 128-bit addressing versus 32-bit addressing with IPv4, stateless automatic address and routing configuration, as well as improved handling of IP level functionality such as IPsec, mobility and IP option processing.

Disabling IPv6 As discussed, the best practice when it comes to securing your system is to remove components that are not needed. IPv6 is still a new protocol and not as widely deployed as IPv4; unless services on your network require the use of IPv6, it is recommended that you disable IPv6 to help prevent network intrusions.

To fully disable any use of the IPv6 protocol, do the following:

Edit the file /etc/modprobe.conf to include the following line: install ipv6 /bin/true This line tells modprobe to execute the /bin/true program instead of installing the IPv6 protocol module in the kernel. As its manpage states /bin/true “does nothing, successfully.”

Edit the file /etc/sysconfig/network to include the lines: NETWORKING_IPV6=no IPV6INIT=no

For each active network interface, edit the file in /etc/sysconfig/network-scripts/ifcfg-interface_name to be sure it includes the line:

IPV6INIT=no Firewall Considerations

As the world transitions to IPv6, there will be a long period of time when both IPv4 and IPv6 will coexist. There are important security implications for this, especially with respect to firewall configuration.

29

If you have multiple IPv6 networks that are not connected because intermediate nodes only support IPv4, the IPv6 packets can travel across these IPv4-only segments of the network by being wrapped as payloads inside of IPv4 packets. This is a great way to allow IPv6/IPv4 compatibility during the transition from IPv4 to IPv6, but it creates a security risk that you need to be aware of.

IPv6 Tunneling

Figure 4: Tunneling IPv6 traffic over IPv4 connections

If an attacker manages to find out the IP address of one of the nodes in your network, they can potentially target that node with malware. Normally, a firewall can block traffic from undesired sources, but in a mixed IPv4/IPv6 network, consider the following scenario:

If your IPv6 network is connected to other IPv6 networks through an IPv4 tunnel (for example, over an Internet uplink that only transmits IPv4 traffic), an attacker could transmit malicious traffic via an IPv6 packet that is encapsulated in an IPv4 packet and if the firewall ignores the IPv6 encapsulation the malicious traffic could go unnoticed by the firewall. Once through the IPv4 firewall, and with IPv4 encapsulation removed, the IPv6 packet containing the malicious traffic is free to travel the local IPv6 network to any number of systems that rely on the firewall for protection.

You should protect against this type of attack by ensuring that any traffic destined for your IPv6 network passes through an IPv6 firewall (see Figure 5: IPv6 Tunneling (dual firewalls).

30

Figure 5: IPv6 Tunneling (dual firewalls)

Netfilter and IPTables Support

Just as iptables configures IPv4 packet filtering in the Linux kernel, there is a corresponding utility for configuring IPv6 packet filtering: ip6tables. It is possible, though not necessary, to run both iptables (for IPv4 firewalling) and ip6tables (for IPv6 firewalling) on the same machine. What is important is that IPv6 packets travel through the IPv6 firewall before reaching their intended destination.

Using HP Software with Linux Firewalling HP provides many tools and software packages to facilitate managing Linux based systems. Because some of these require specific network ports to be opened to function properly, you might have to make some adjustments to your firewall configuration in order to use these tools.

HP Insight Control Environment The HP Insight Control Environment (HP ICE) enables you to deploy, monitor, and manage multiple Linux based physical and virtual servers from a single location. Using HP ICE you can perform Integrated Lights-Out management (iLO). HP ICE requires a Central Management Server (CMS) which communicates with, and controls, the other systems. The very nature of this product requires secure communication between the managed systems. HP ICE uses a variety of network services to perform its work, and these services must be allowed through the firewalls of each system to permit access by the CMS. The following table shows which services and firewall ports must be made available. If you use HP ICE to deploy a new managed system it will automatically set the new system’s firewall to these

31

settings. If you manually deploy the new system, or use a management suite other than HP ICE, you will need to manually adjust the firewall ports to ensure the appropriate access.

Service Inbound or Outbound Port Number Protocol

ssh Inbound 22 TCP

SNMP Inbound 161 TCP/UDP

SNMP trap listener Inbound 162 UDP

syslog-ng Outbound 514 UDP

mond Inbound 2709 TCP

nrpe Inbound 5666 TCP

HP ProLiant Support Pack The HP ProLiant Support Pack for Linux is a collection of drivers, utilities, and management agents that have been tested together to ensure proper installation and operation. There are no special firewall requirements for installing HP ProLiant Support Packs, but you might need to securely log in to the system using SSH to install or configure the ProLiant Support Pack. If you use SSH, be sure to enable a port in your system’s firewall for inbound SSH traffic (TCP port 22).

Encrypting Network Traffic Security tools can use encryption to render sensitive information unreadable when communicating over untrusted networks. They can also use tunneling and encapsulation to obscure the source and destination of your information from unknown third parties. Further, these tools can use authentication to guarantee the identity of all the parties before any communication takes place.

Full Network Encryption with IPsec You can, of course, manually encrypt data with a pre-arranged key, package it up in some way, and transmit the data over a public network. The recipient can then use the pre-arranged key to decrypt the data on the receiving end. This is time consuming for both sender and receiver and doesn’t scale well to large amounts of data, large numbers of communication channels, and does not work with dynamically generated data. For example, communications between client/server applications that require secure communications, like bank ATMs or online stock transactions. It is also difficult and cumbersome to develop the self-discipline to manually encrypt and package information each and every time. For these reasons and others, when secure communications are required, it is useful to

automatically perform the encryption.

At the network level, IPsec can provide these protections and apply them automatically, consistently, and transparently. IPSec can protect all network information sent and received across the network by the applications on your server, without requiring any changes to those applications or the network itself. IPsec can:

Automatically and transparently protect all network communications to and from your computer

Ensure that the system you are communicating with really is the system you expect it is (protecting against impersonation)

32

Encrypt all data in every network packet; and, if desired, obscure the source and destination IP addresses through IPsec tunneling (providing identity protection)

Ensure that the data and packet header information have not been tampered with in transit (ensuring data integrity)

Create a secure Virtual Private Network (VPN) tunnel, terminating on the host or on a trusted gateway, allowing you to create secure virtual “LANs” with computers that can be connected to each other using the untrusted public networks. Even though your communications must travel over the public network, they travel in a protected “tunnel”, so they are as safe as if all of the computers were attached to a private, secured, network but without the expense.

Best Practice: IPSec can be configured for host-to-host communication, but the connection processing involved with encrypting and decrypting network packets affects the overall performance of the systems doing that work.

If you need to protect more than one or two isolated systems, and if overall system performance is important, a better solution is to configure dedicated gateway systems for protected network-to-network communication. The best solution is to use HP ProCurve network switches and routers specifically designed for this purpose.

Understanding IPsec IPSec is compatible with IPv4, and an integral part of IPv6 communications. Its job is to authenticate the remote system with whom you are communicating, ensure that your communications remain confidential, and ensure that communications in both directions are not tampered with during transit.

While it is possible to manually configure all aspects of an IPsec communication channel (see the setkey(8) manpage for specific details), the preferred method is to use the Internet Key Exchange (IKE) protocol to automatically negotiate and establish IPsec communication channels. IKE is responsible for coordinating protocol details, the various encryption and authentication keys that will be used, and establishing a lifetime for the negotiated configuration (after which the configuration must be renewed). The negotiation details are used to create an IPsec Security Association (SA) which serves as the endpoint for one side of an IPsec protected communication channel, meaning that SAs are typically created in pairs to allow for bi-directional communication between systems. The SAs are stored in the system’s Security Association Database (SAD) where they are used by the system to perform per-packet tunneling, authentication, encryption and integrity verification using the IPsec protocols described below.

IPSec ensures the integrity of both information exchanges and IP header information by building an Authentication Header (AH) that is based on the packet’s data, IP header information, and a verifiable electronic signature.

IPSec protects the sensitive data in the information exchanges by encapsulating the data in an Encapsulated Security Payload (ESP), an envelope that surrounds and encrypts the data. The actual length of the data can also be hidden from third parties by varying the length of the data through the use of padding applied before encryption.

Using IPsec tunneling, even the source and destination IP addresses of the communication channel can be encrypted and wrapped with new headers that will route them from one IPsec gateway to another. The IPsec gateways tunnel all network traffic passing through the gateway using IPsec, which wraps the traffic with an additional layer of IP headers, revealing only the addresses of the two IPsec gateways. However, when the traffic is behind the IPsec gateways, the packets are unwrapped and the original IP headers are visible, revealing the source and destination addresses which can be used to route them to

33

their intended recipient. This protects both IP addresses from view while they are traveling on untrusted networks and allows the use of non-routable addresses, like 10.0.7.4, to create an internal network spanning multiple locations.

Configuring IPsec

Figure 6: IPSec example network

IPSec has two modes of communication that are configured slightly differently.

Securing Communications between Hosts

Transport Mode – Encapsulates and encrypts only the packet’s data payload. This mode is used for host-to-host communications and leaves the original IP headers accessible for routing the packets. The Authentication Header will ensure that both the data and IP headers are not tampered with in transit, but the source and destination IP addresses can still be viewed in transit when using transport mode (as shown in Figure 7: Transport Mode (Host-to-Host)). In transport mode, the security associations are established from one host to the other (Host A1 to Host B3 in the following example). The gateways appear to the hosts as typical routers, whether or not they are IPsec gateways. Traffic from host to host is encrypted and protected for the entire path.

Figure 7: Transport Mode (Host-to-Host)

Securing Communications between Networks

34

Tunneling Mode – Encapsulates and encrypts both the original IP header and the data payload while the packets are traveling in the untrusted portion of the network route. The source and destination hosts are on trusted networks, behind IPsec gateways. The untrusted portion of the network route is that which is between the two gateways. While the network packets (from Host A2 to Host B1 in the following example) are traveling on the trusted networks, behind the gateways, the packets do not utilize IPsec protection. However, when the network traffic passes through the IPsec gateways the packets are wrapped with an additional layer of IP headers and encrypted using IPsec to protect the packets as they travel across the untrusted public network. As shown in Figure 8: Tunneling Mode (Network-to-Network) the security associations in tunneling mode are established between the two IPsec gateways.

Figure 8: Tunneling Mode (Network-to-Network)

Configuring IPsec from the Command Line

The setkey command is used to configure IPsec’s two configuration databases:

The Security Policy Database (SPD) which contains the IPsec security policy The Security Association Database (SAD) which contains the established IPsec security

associations

IPsec security policies are the rules used by the kernel to determine what types of traffic should have IPsec protection applied and what type of IPsec protections should be used. The security policies are also used as input to the IKE daemon when negotiating IPsec security associations with remote systems.

IPsec security associations contain all the necessary details about how to apply the IPsec protections to individual network packets, including the necessary encryption and authentication keys. If you don’t manually establish SAs using the setkey command, the IKE daemon will create them as needed as part of its IKE negotiations.

35

Application Specific Encryption with SSL/TLS

IPsec is not the only way to encrypt data in network communications. IPsec works at the network layer of the OSI network layer model while the Secure Socket Layer (SSL) and Transport Layer Security (TLS)

protocols work one level higher in the OSI model, in the transport layer.

TLS is a successor to SSL, though SSL (now at version 3) is still in wide use. Both TLS and SSL can be used by applications to secure communications with other systems. Many client/server applications take advantage of SSL/TLS for protection on untrusted networks (HTTP and SSL/TLS combine to form the popular HTTPS protocol; as well as several other applications, including email, instant messaging, and voice-over-IP products).

Understanding SSL/TLS SSL and TLS transactions occur in three phases:

1. The local and remote systems negotiate cipher suites. Cipher suites determine which algorithms to use for key exchange, and message authentication.

2. The systems exchange the cipher keys that will be used for encryption/decryption of their pending communications. They usually accomplish the key exchange using asymmetric encryption (public-private keys), and authenticate each other using digital certificates.

3. Finally, they use the exchanged keys to communicate securely over the network. Symmetric encryption is used for the actual data exchange for performance reasons.

In the most common use of SSL/TLS, that of a web browser authenticating a server for secure transactions, the authentication occurs in only one direction – the client authenticates the server it is communicating with by examining the server’s digital certificate, but the server does not require the client to present a digital certificate.

Though not as transparent to use as IPsec, SSL and TLS do have several advantages. If you need to communicate with systems behind routers that use Network Address Translation (NAT), SSL/TLS might be a better choice. Also, both SSL and TLS can be used with more spontaneity. With IPsec, you must be sure you have policy rules in place that cover the systems you want to communicate with. However, with SSL/TLS all that is required is a valid digital certificate.

Managing Certificates SSL and TLS provide a secure communication service to applications on your server, but because SSL and TLS work within the transport layer of the OSI model they generally require that the applications participate in the security aspects of the network communications; that is to say, the applications must be SSL/TLS aware. This primarily means that the applications using SSL/TLS need to maintain a collection of digital certificates that fall into two categories:

Certificate Authority (CA) certificates – these are the digital signatures of organizations whom you trust to vouch for the identity and content of the other type of certificates you collect: server certificates.

Server Certificates – these authenticate the remote systems your applications will communicate with. Server certificates contain information regarding the identity of the server and organization they represent as well as the public key that can be used to encrypt messages destined for the applications on that server. Server certificates must also contain the digital signature of a certificate authority that will vouch for the identity of the server and other information contained in the server certificate.

36

Before exchanging sensitive data with an unknown remote system, the remote system must present an application running on your system with a server certificate containing a digital signature from a certificate authority whom you trust (a certificate authority who’s own certificate you hold, containing a digital signature that matches the one used to sign the server certificate).

NOTE: Each SSL/TLS-aware application running on your server must keep its own collection of certificates or leverage a SSL/TLS library with a common certificate store.

Securing Legacy Applications As mentioned above, both SSL and TLS require SSL/TLS-aware client/server applications; however, what if you have a non-SSL-aware application, (a legacy client/server application for example) that you need to secure? What if you cannot re-write or re-compile the application? There is a way to wrap non-SSL-aware applications such that they will be protected by SSL/TLS using a utility called stunnel.

Stunnel

Stunnel establishes a secure channel over which non-SSL/TLS-aware applications can communicate. Stunnel requires no changes to applications that will use it. Instead, after acquiring or generating the appropriate security certificates, an administrator makes a few small edits to /etc/services and sometimes /etc/hosts.allow in order to be able to redirect the client/server application to the endpoints of the secure tunnel. Administrators can even establish tunnels that standard users can use for communicating securely.

Stunnel has two basic operating modes, server mode (sometimes called daemon mode because stunnel is listening for incoming network traffic as a daemon does), and client mode.

In server mode, the stunnel process listens for secure traffic coming through the tunnel from the client system. It decrypts the traffic and passes the unencrypted packets to the intended application. In this mode the intended application might be running on the same computer as the stunnel daemon or on another computer on a protected network.

In client mode, the stunnel process listens for unencrypted traffic from a local process, encrypts the traffic and sends it through the secure tunnel to the remote host.

Summary Security is a crucial element in nearly every computing environment. There are many ways your system and information can come under attack. Many attacks come via network access; therefore, securing the network boundary using the techniques and technologies described in this white paper is critical. Using mandatory access control is one of the most effective security techniques, providing extremely fine-grained control over the resources of your computer. Deploying SELinux on Red Hat Enterprise Linux, or AppArmor on SUSE Linux Enterprise Server, significantly enhances the security of your system while remaining relatively unobtrusive. If security is important to your system, consider using one of these technologies. More information about SELinux is available in the white paper: Linux Security on HP Servers: SELinux. There are also other important ways to secure your system (for example, ensuring your system’s software and operating system are up-to-date, ensuring the use of secure passwords, and logging and auditing the activities of the users of your system). Many of these technologies are covered in the white paper Linux Security on HP Servers: General Security Topics.

37

38

For more information

Additional Linux Security Resources If you require additional information on the topics covered in this white paper, here are some important resources to reference:

The HP Linux Security website: http://www.hp.com/go/linuxsecurity Red Hat Desktop: Deployment Guide. Tech. rep., Red Hat Linux, 2005.

http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Deployment_Guide-en-US/ Guide to the Secure Configuration of Red Hat Enterprise Linux 5 – National Security Agency,

United States of America. http://www.nsa.gov/notices/notic00004.cfm?Address=/snac/os/redhat/rhel5-guide-i731.pdf

UNIX SECURITY TECHNICAL IMPLEMENTATION GUIDE Version 5, Release 1 http://iase.disa.mil/stigs/stig/unix-stig-v5r1.pdf

If you have further questions about Linux security on HP servers, go to http://www.hp.com/go/linux and click Contact HP.