| Security GuideWhen a system is used as a server on a public network, it becomes a target for attacks. Hardening the system and locking down services is therefore of paramount importance for the system administrator. Before delving into specific issues, review the following general tips for enhancing server security: Keep all services current, to protect against the latest threats. Use secure protocols whenever possible. Serve only one type of network service per machine whenever possible. Monitor all servers carefully for suspicious activity.
2.2.1. Securing Services With TCP Wrappers and xinetdTCP Wrappers provide access control to a variety of services. Most modern network services, such as SSH, Telnet, and FTP, make use of TCP Wrappers, which stand guard between an incoming request and the requested service. The benefits offered by TCP Wrappers are enhanced when used in conjunction with xinetd, a super server that provides additional access, logging, binding, redirection, and resource utilization control. It is a good idea to use iptables firewall rules in conjunction with TCP Wrappers and xinetd to create redundancy within service access controls. Refer to Section 2.8, "Firewalls" for more information about implementing firewalls with iptables commands. The following subsections assume a basic knowledge of each topic and focus on specific security options. 2.2.1.1. Enhancing Security With TCP WrappersTCP Wrappers are capable of much more than denying access to services. This section illustrates how they can be used to send connection banners, warn of attacks from particular hosts, and enhance logging functionality. Refer to the hosts_options man page for information about the TCP Wrapper functionality and control language. Refer to the xinetd.conf man page available online at http://linux.die.net/man/5/xinetd.conf for available flags, which act as options you can apply to a service. 2.2.1.1.1. TCP Wrappers and Connection BannersDisplaying a suitable banner when users connect to a service is a good way to let potential attackers know that the system administrator is being vigilant. You can also control what information about the system is presented to users. To implement a TCP Wrappers banner for a service, use the banner option. This example implements a banner for vsftpd. To begin, create a banner file. It can be anywhere on the system, but it must have same name as the daemon. For this example, the file is called /etc/banners/vsftpd and contains the following lines: 220-Hello, %c 220-All activity on ftp.example.com is logged.220-Inappropriate use will result in your access privileges being removed. The %c token supplies a variety of client information, such as the username and hostname, or the username and IP address to make the connection even more intimidating. For this banner to be displayed to incoming connections, add the following line to the /etc/hosts.allow file: vsftpd : ALL : banners /etc/banners/ 2.2.1.1.2. TCP Wrappers and Attack WarningsIf a particular host or network has been detected attacking the server, TCP Wrappers can be used to warn the administrator of subsequent attacks from that host or network using the spawn directive. In this example, assume that a cracker from the 206.182.68.0/24 network has been detected attempting to attack the server. Place the following line in the /etc/hosts.deny file to deny any connection attempts from that network, and to log the attempts to a special file: ALL : 206.182.68.0 : spawn /bin/echo `date` %c %d >> /var/log/intruder_alert The %d token supplies the name of the service that the attacker was trying to access. To allow the connection and log it, place the spawn directive in the /etc/hosts.allow file. Because the spawn directive executes any shell command, it is a good idea to create a special script to notify the administrator or execute a chain of commands in the event that a particular client attempts to connect to the server. 2.2.1.1.3. TCP Wrappers and Enhanced LoggingIf certain types of connections are of more concern than others, the log level can be elevated for that service using the severity option. For this example, assume that anyone attempting to connect to port 23 (the Telnet port) on an FTP server is a cracker. To denote this, place an emerg flag in the log files instead of the default flag, info, and deny the connection. To do this, place the following line in /etc/hosts.deny: in.telnetd : ALL : severity emerg This uses the default authpriv logging facility, but elevates the priority from the default value of info to emerg, which posts log messages directly to the console. 2.2.1.2. Enhancing Security With xinetdThis section focuses on using xinetd to set a trap service and using it to control resource levels available to any given xinetd service. Setting resource limits for services can help thwart Denial of Service ( DoS) attacks. Refer to the man pages for xinetd and xinetd.conf for a list of available options. 2.2.1.2.1. Setting a TrapOne important feature of xinetd is its ability to add hosts to a global no_access list. Hosts on this list are denied subsequent connections to services managed by xinetd for a specified period or until xinetd is restarted. You can do this using the SENSOR attribute. This is an easy way to block hosts attempting to scan the ports on the server. The first step in setting up a SENSOR is to choose a service you do not plan on using. For this example, Telnet is used. Edit the file /etc/xinetd.d/telnet and change the flags line to read: flags = SENSOR Add the following line: deny_time = 30 This denies any further connection attempts to that port by that host for 30 minutes. Other acceptable values for the deny_time attribute are FOREVER, which keeps the ban in effect until xinetd is restarted, and NEVER, which allows the connection and logs it. Finally, the last line should read: disable = no This enables the trap itself. While using SENSOR is a good way to detect and stop connections from undesirable hosts, it has two drawbacks: It does not work against stealth scans. An attacker who knows that a SENSOR is running can mount a Denial of Service attack against particular hosts by forging their IP addresses and connecting to the forbidden port.
2.2.1.2.2. Controlling Server ResourcesAnother important feature of xinetd is its ability to set resource limits for services under its control. It does this using the following directives: cps = <number_of_connections> <wait_period> - Limits the rate of incoming connections. This directive takes two arguments:
<number_of_connections> - The number of connections per second to handle. If the rate of incoming connections is higher than this, the service is temporarily disabled. The default value is fifty (50).
<wait_period> - The number of seconds to wait before re-enabling the service after it has been disabled. The default interval is ten (10) seconds.
instances = <number_of_connections> - Specifies the total number of connections allowed to a service. This directive accepts either an integer value or UNLIMITED.
per_source = <number_of_connections> - Specifies the number of connections allowed to a service by each host. This directive accepts either an integer value or UNLIMITED.
rlimit_as = <number[K|M]> - Specifies the amount of memory address space the service can occupy in kilobytes or megabytes. This directive accepts either an integer value or UNLIMITED.
rlimit_cpu = <number_of_seconds> - Specifies the amount of time in seconds that a service may occupy the CPU. This directive accepts either an integer value or UNLIMITED.
Using these directives can help prevent any single xinetd service from overwhelming the system, resulting in a denial of service. The portmap service is a dynamic port assignment daemon for RPC services such as NIS and NFS. It has weak authentication mechanisms and has the ability to assign a wide range of ports for the services it controls. For these reasons, it is difficult to secure. Securing portmap only affects NFSv2 and NFSv3 implementations, since NFSv4 no longer requires it. If you plan to implement an NFSv2 or NFSv3 server, then portmap is required, and the following section applies. If running RPC services, follow these basic rules. 2.2.2.1. Protect portmap With TCP WrappersIt is important to use TCP Wrappers to limit which networks or hosts have access to the portmap service since it has no built-in form of authentication. Further, use only IP addresses when limiting access to the service. Avoid using hostnames, as they can be forged by DNS poisoning and other methods. 2.2.2.2. Protect portmap With iptablesTo further restrict access to the portmap service, it is a good idea to add iptables rules to the server and restrict access to specific networks. Below are two example iptables commands. The first allows TCP connections to the port 111 (used by the portmap service) from the 192.168.0.0/24 network. The second allows TCP connections to the same port from the localhost. This is necessary for the sgi_fam service used by Nautilus. All other packets are dropped. ~]# iptables -A INPUT -p tcp -s ! 192.168.0.0/24 --dport 111 -j DROP~]# iptables -A INPUT -p tcp -s 127.0.0.1 --dport 111 -j ACCEPT To similarly limit UDP traffic, use the following command: ~]# iptables -A INPUT -p udp -s ! 192.168.0.0/24 --dport 111 -j DROP The Network Information Service ( NIS) is an RPC service, called ypserv, which is used in conjunction with portmap and other related services to distribute maps of usernames, passwords, and other sensitive information to any computer claiming to be within its domain. A NIS server is comprised of several applications. They include the following: /usr/sbin/rpc.yppasswdd - Also called the yppasswdd service, this daemon allows users to change their NIS passwords.
/usr/sbin/rpc.ypxfrd - Also called the ypxfrd service, this daemon is responsible for NIS map transfers over the network.
/usr/sbin/yppush - This application propagates changed NIS databases to multiple NIS servers.
/usr/sbin/ypserv - This is the NIS server daemon.
NIS is somewhat insecure by today's standards. It has no host authentication mechanisms and transmits all of its information over the network unencrypted, including password hashes. As a result, extreme care must be taken when setting up a network that uses NIS. This is further complicated by the fact that the default configuration of NIS is inherently insecure. It is recommended that anyone planning to implement a NIS server first secure the portmap service as outlined in Section 2.2.2, "Securing Portmap", then address the following issues, such as network planning. 2.2.3.1. Carefully Plan the NetworkBecause NIS transmits sensitive information unencrypted over the network, it is important the service be run behind a firewall and on a segmented and secure network. Whenever NIS information is transmitted over an insecure network, it risks being intercepted. Careful network design can help prevent severe security breaches. 2.2.3.2. Use a Password-like NIS Domain Name and HostnameAny machine within a NIS domain can use commands to extract information from the server without authentication, as long as the user knows the NIS server's DNS hostname and NIS domain name. For instance, if someone either connects a laptop computer into the network or breaks into the network from outside (and manages to spoof an internal IP address), the following command reveals the /etc/passwd map: ypcat -d <NIS_domain> -h <DNS_hostname> passwd
If this attacker is a root user, they can obtain the /etc/shadow file by typing the following command: ypcat -d <NIS_domain> -h <DNS_hostname> shadow
If Kerberos is used, the /etc/shadow file is not stored within a NIS map. To make access to NIS maps harder for an attacker, create a random string for the DNS hostname, such as o7hfawtgmhwg.domain.com. Similarly, create a different randomized NIS domain name. This makes it much more difficult for an attacker to access the NIS server. 2.2.3.3. Edit the /var/yp/securenets FileIf the /var/yp/securenets file is blank or does not exist (as is the case after a default installation), NIS listens to all networks. One of the first things to do is to put netmask/network pairs in the file so that ypserv only responds to requests from the appropriate network. Below is a sample entry from a /var/yp/securenets file: 255.255.255.0 192.168.0.0 Never start a NIS server for the first time without creating the /var/yp/securenets file. This technique does not provide protection from an IP spoofing attack, but it does at least place limits on what networks the NIS server services. 2.2.3.4. Assign Static Ports and Use iptables RulesAll of the servers related to NIS can be assigned specific ports except for rpc.yppasswdd - the daemon that allows users to change their login passwords. Assigning ports to the other two NIS server daemons, rpc.ypxfrd and ypserv, allows for the creation of firewall rules to further protect the NIS server daemons from intruders. To do this, add the following lines to /etc/sysconfig/network: YPSERV_ARGS="-p 834"YPXFRD_ARGS="-p 835" The following iptables rules can then be used to enforce which network the server listens to for these ports: ~]# iptables -A INPUT -p ALL -s ! 192.168.0.0/24 --dport 834 -j DROP~]# iptables -A INPUT -p ALL -s ! 192.168.0.0/24 --dport 835 -j DROP This means that the server only allows connections to ports 834 and 835 if the requests come from the 192.168.0.0/24 network, regardless of the protocol. 2.2.3.5. Use Kerberos AuthenticationOne of the issues to consider when NIS is used for authentication is that whenever a user logs into a machine, a password hash from the /etc/shadow map is sent over the network. If an intruder gains access to a NIS domain and sniffs network traffic, they can collect usernames and password hashes. With enough time, a password cracking program can guess weak passwords, and an attacker can gain access to a valid account on the network. Since Kerberos uses secret-key cryptography, no password hashes are ever sent over the network, making the system far more secure. Refer to Managing Single Sign-On and Smart Cards for more information about Kerberos. The version of NFS included in Red Hat Enterprise Linux 6, NFSv4, no longer requires the portmap service as outlined in Section 2.2.2, "Securing Portmap". NFS traffic now utilizes TCP in all versions, rather than UDP, and requires it when using NFSv4. NFSv4 now includes Kerberos user and group authentication, as part of the RPCSEC_GSS kernel module. Information on portmap is still included, since Red Hat Enterprise Linux 6 supports NFSv2 and NFSv3, both of which utilize portmap. 2.2.4.1. Carefully Plan the NetworkNFSv2 and NFSv3 traditionally passed data insecurely. All versions of NFS now have the ability to authenticate (and optionally encrypt) ordinary file system operations using Kerberos. Under NFSv4 all operations can use Kerberos; under v2 or v3, file locking and mounting still do not use it. When using NFSv4.0, delegations may be turned off if the clients are behind NAT or a firewall. Refer to the section on pNFS in the Storage Administration Guide for information on the use of NFSv4.1 to allow delegations to operate through NAT and firewalls. 2.2.4.2. Securing NFS Mount OptionsThe use of the mount command in the /etc/fstab file is explained in the Storage Administration Guide. From a security administration point of view it is worthwhile to note that the NFS mount options can also be specified in /etc/nfsmount.conf, which can be used to set custom default options. 2.2.4.2.1. Review the NFS ServerOnly export entire file systems. Exporting a subdirectory of a file system can be a security issue. It is possible in some cases for a client to "break out" of the exported part of the file system and get to unexported parts (see the section on subtree checking in the exports(5) man page. Use the ro option to export the file system as read-only whenever possible to reduce the number of users able to write to the mounted file system. Only use the rw option when specifically required. Refer to the man exports(5) page for more information. Allowing write access increases the risk from symlink attacks for example. This includes temporary directories such as /tmp and /usr/tmp. Where directories must be mounted with the rw option avoid making them world-writable whenever possible to reduce risk. Exporting home directories is also viewed as a risk as some applications store passwords in clear text or weakly encrypted. This risk is being reduced as application code is reviewed and improved. Some users do not set passwords on their SSH keys so this too means home directories present a risk. Enforcing the use of passwords or using Kerberos would mitigate that risk. Restrict exports only to clients that need access. Use the showmount -e command on an NFS server to review what the server is exporting. Do not export anything that is not specifically required. The secure option is the server-side export option used to restrict exports to "reserved" ports. By default, the server allows client communication only from "reserved" ports (ports numbered less than 1024), because traditionally clients have only allowed "trusted" code (such as in-kernel NFS clients) to use those ports. However, on many networks it is not difficult for anyone to become root on some client, so it is rarely safe for the server to assume that communication from a reserved port is privileged. Therefore the restriction to reserved ports is of limited value; it is better to rely on Kerberos, firewalls, and restriction of exports to particular clients. Most clients still do use reserved ports when possible. However, reserved ports are a limited resource, so clients (especially those with a large number of NFS mounts) may choose to use higher-numbered ports as well. Linux clients may do this using the "noresvport" mount option. If you wish to allow this on an export, you may do so with the "insecure" export option. It is good practice not to allow users to login to a server. While reviewing the above settings on an NFS server conduct a review of who and what can access the server. 2.2.4.2.2. Review the NFS ClientUse the nosuid option to disallow the use of a setuid program. The nosuid option disables the set-user-identifier or set-group-identifier bits. This prevents remote users from gaining higher privileges by running a setuid program. Use this option on the client and the server side. The noexec option disables all executable files on the client. Use this to prevent users from inadvertently executing files placed in the file system being shared. The nosuid and noexec options are standard options for most, if not all, file systems. Use the nodev option to prevent "device-files" from being processed as a hardware device by the client. The resvport option is a client-side mount option and secure is the corresponding server-side export option (see explanation above). It restricts communication to a "reserved port". The reserved or "well known" ports are reserved for privileged users and processes such as the root user. Setting this option causes the client to use a reserved source port to communicate with the server. All versions of NFS now support mounting with Kerberos authentication. The mount option to enable this is: sec=krb5. NFSv4 supports mounting with Kerberos using krb5i for integrity and krb5p for privacy protection. These are used when mounting with sec=krb5, but need to be configured on the NFS server. Refer to the man page on exports (man 5 exports) for more information. The NFS man page (man 5 nfs) has a "SECURITY CONSIDERATIONS" section which explains the security enhancements in NFSv4 and contains all the NFS specific mount options. 2.2.4.3. Beware of Syntax ErrorsThe NFS server determines which file systems to export and which hosts to export these directories to by consulting the /etc/exports file. Be careful not to add extraneous spaces when editing this file. For instance, the following line in the /etc/exports file shares the directory /tmp/nfs/ to the host bob.example.com with read/write permissions. /tmp/nfs/ bob.example.com(rw) The following line in the /etc/exports file, on the other hand, shares the same directory to the host bob.example.com with read-only permissions and shares it to the world with read/write permissions due to a single space character after the hostname. /tmp/nfs/ bob.example.com (rw) It is good practice to check any configured NFS shares by using the showmount command to verify what is being shared: showmount -e <hostname>
2.2.4.4. Do Not Use the no_root_squash OptionBy default, NFS shares change the root user to the nfsnobody user, an unprivileged user account. This changes the owner of all root-created files to nfsnobody, which prevents uploading of programs with the setuid bit set. If no_root_squash is used, remote root users are able to change any file on the shared file system and leave applications infected by trojans for other users to inadvertently execute. 2.2.4.5. NFS Firewall ConfigurationThe ports used for NFS are assigned dynamically by rpcbind, which can cause problems when creating firewall rules. To simplify this process, use the /etc/sysconfig/nfs file to specify which ports are to be used: MOUNTD_PORT - TCP and UDP port for mountd (rpc.mountd)
STATD_PORT - TCP and UDP port for status (rpc.statd)
LOCKD_TCPPORT - TCP port for nlockmgr (rpc.lockd)
LOCKD_UDPPORT - UDP port nlockmgr (rpc.lockd)
Port numbers specified must not be used by any other service. Configure your firewall to allow the port numbers specified, as well as TCP and UDP port 2049 (NFS). Run the rpcinfo -p command on the NFS server to see which ports and RPC programs are being used. 2.2.5. Securing the Apache HTTP ServerThe Apache HTTP Server is one of the most stable and secure services that ships with Red Hat Enterprise Linux. A large number of options and techniques are available to secure the Apache HTTP Server - too numerous to delve into deeply here. The following section briefly explains good practices when running the Apache HTTP Server. Always verify that any scripts running on the system work as intended before putting them into production. Also, ensure that only the root user has write permissions to any directory containing scripts or CGIs. To do this, run the following commands as the root user: chown root <directory_name>
chmod 755 <directory_name>
System administrators should be careful when using the following configuration options (configured in /etc/httpd/conf/httpd.conf): FollowSymLinksThis directive is enabled by default, so be sure to use caution when creating symbolic links to the document root of the Web server. For instance, it is a bad idea to provide a symbolic link to /. IndexesThis directive is enabled by default, but may not be desirable. To prevent visitors from browsing files on the server, remove this directive. UserDirThe UserDir directive is disabled by default because it can confirm the presence of a user account on the system. To enable user directory browsing on the server, use the following directives: UserDir enabledUserDir disabled root These directives activate user directory browsing for all user directories other than /root/. To add users to the list of disabled accounts, add a space-delimited list of users on the UserDir disabled line. ServerTokensThe ServerTokens directive controls the server response header field which is sent back to clients. It includes various information which can be customized using the following parameters: ServerTokens Full (default option) - provides all available information (OS type and used modules), for example:
Apache/2.0.41 (Unix) PHP/4.2.2 MyMod/1.2 ServerTokens Prod or ServerTokens ProductOnly - provides the following information:
Apache ServerTokens Major - provides the following information:
Apache/2 ServerTokens Minor - provides the following information:
Apache/2.0 ServerTokens Min or ServerTokens Minimal - provides the following information:
Apache/2.0.41 ServerTokens OS - provides the following information:
Apache/2.0.41 (Unix)
It is recommended to use the ServerTokens Prod option so that a possible attacker does not gain any valuable information about your system.
Do not remove the IncludesNoExec directive. By default, the Server-Side Includes ( SSI) module cannot execute commands. It is recommended that you do not change this setting unless absolutely necessary, as it could, potentially, enable an attacker to execute commands on the system. Removing httpd ModulesIn certain scenarios, it is beneficial to remove certain httpd modules to limit the functionality of the HTTP Server. To do so, simply comment out the entire line which loads the module you wish to remove in the /etc/httpd/conf/httpd.conf file. For example, to remove the proxy module, comment out the following line by prepending it with a hash sign: #LoadModule proxy_module modules/mod_proxy.so Note that the /etc/httpd/conf.d/ directory contains configuration files which are used to load modules as well. httpd and SELinuxThe File Transfer Protocol ( FTP) is an older TCP protocol designed to transfer files over a network. Because all transactions with the server, including user authentication, are unencrypted, it is considered an insecure protocol and should be carefully configured. Red Hat Enterprise Linux provides three FTP servers. gssftpd - A Kerberos-aware xinetd-based FTP daemon that does not transmit authentication information over the network.
Red Hat Content Accelerator (tux) - A kernel-space Web server with FTP capabilities. vsftpd - A standalone, security oriented implementation of the FTP service.
The following security guidelines are for setting up the vsftpd FTP service. 2.2.6.1. FTP Greeting BannerBefore submitting a username and password, all users are presented with a greeting banner. By default, this banner includes version information useful to crackers trying to identify weaknesses in a system. To change the greeting banner for vsftpd, add the following directive to the /etc/vsftpd/vsftpd.conf file: ftpd_banner=<insert_greeting_here> Replace <insert_greeting_here> in the above directive with the text of the greeting message. For mutli-line banners, it is best to use a banner file. To simplify management of multiple banners, place all banners in a new directory called /etc/banners/. The banner file for FTP connections in this example is /etc/banners/ftp.msg. Below is an example of what such a file may look like: ######### Hello, all activity on ftp.example.com is logged. ######### To reference this greeting banner file for vsftpd, add the following directive to the /etc/vsftpd/vsftpd.conf file: banner_file=/etc/banners/ftp.msg 2.2.6.2. Anonymous AccessThe presence of the /var/ftp/ directory activates the anonymous account. The easiest way to create this directory is to install the vsftpd package. This package establishes a directory tree for anonymous users and configures the permissions on directories to read-only for anonymous users. By default the anonymous user cannot write to any directories. If enabling anonymous access to an FTP server, be aware of where sensitive data is stored. 2.2.6.2.1. Anonymous UploadTo allow anonymous users to upload files, it is recommended that a write-only directory be created within /var/ftp/pub/. To do this, run the following command as root: ~]# mkdir /var/ftp/pub/upload Next, change the permissions so that anonymous users cannot view the contents of the directory: ~]# chmod 730 /var/ftp/pub/upload A long format listing of the directory should look like this: ~]# ls -ld /var/ftp/pub/uploaddrwx-wx---. 2 root ftp 4096 Nov 14 22:57 /var/ftp/pub/upload Administrators who allow anonymous users to read and write in directories often find that their servers become a repository of stolen software. Additionally, under vsftpd, add the following line to the /etc/vsftpd/vsftpd.conf file: anon_upload_enable=YES Because FTP transmits unencrypted usernames and passwords over insecure networks for authentication, it is a good idea to deny system users access to the server from their user accounts. To disable all user accounts in vsftpd, add the following directive to /etc/vsftpd/vsftpd.conf: local_enable=NO 2.2.6.3.1. Restricting User AccountsTo disable FTP access for specific accounts or specific groups of accounts, such as the root user and those with sudo privileges, the easiest way is to use a PAM list file as described in Section 2.1.4.2, "Disallowing Root Access". The PAM configuration file for vsftpd is /etc/pam.d/vsftpd. It is also possible to disable user accounts within each service directly. To disable specific user accounts in vsftpd, add the username to /etc/vsftpd/ftpusers 2.2.6.4. Use TCP Wrappers To Control AccessPostfix is a Mail Transfer Agent (MTA) that uses the Simple Mail Transfer Protocol (SMTP) to deliver electronic messages between other MTAs and to email clients or delivery agents. Although many MTAs are capable of encrypting traffic between one another, most do not, so sending email over any public networks is considered an inherently insecure form of communication. It is recommended that anyone planning to implement a Postfix server address the following issues. 2.2.7.1. Limiting a Denial of Service AttackBecause of the nature of email, a determined attacker can flood the server with mail fairly easily and cause a denial of service. By setting limits to the following directives in /etc/postfix/main.cf, the effectiveness of such attacks is limited. smtpd_client_connection_rate_limit - The maximum number of connection attempts any client is allowed to make to this service per time unit (described below). The default value is 0, which means a client can make as many connections per time unit as Postfix can accept. By default, clients in trusted networks are excluded.
anvil_rate_time_unit - This time unit is used for rate limit calculations. The default value is 60 seconds.
smtpd_client_event_limit_exceptions - Clients that are excluded from the connection and rate limit commands. By default, clients in trusted networks are excluded.
smtpd_client_message_rate_limit - The maximum number of message deliveries a client is allowed to request per time unit (regardless of whether or not Postfix actually accepts those messages).
default_process_limit - The default maximum number of Postfix child processes that provide a given service. This limit can be overruled for specific services in the master.cf file. By default the value is 100.
queue_minfree - The minimum amount of free space in bytes in the queue file system that is needed to receive mail. This is currently used by the Postfix SMTP server to decide if it will accept any mail at all. By default, the Postfix SMTP server rejects MAIL FROM commands when the amount of free space is less than 1.5 times the message_size_limit. To specify a higher minimum free space limit, specify a queue_minfree value that is at least 1.5 times the message_size_limit. By default the queue_minfree value is 0.
header_size_limit - The maximum amount of memory in bytes for storing a message header. If a header is larger, the excess is discarded. By default the value is 102400.
message_size_limit - The maximum size in bytes of a message, including envelope information. By default the value is 10240000.
Never put the mail spool directory, /var/spool/postfix/, on an NFS shared volume. Because NFSv2 and NFSv3 do not maintain control over user and group IDs, two or more users can have the same UID, and receive and read each other's mail. With NFSv4 using Kerberos, this is not the case, since the SECRPC_GSS kernel module does not utilize UID-based authentication. However, it is still considered good practice not to put the mail spool directory on NFS shared volumes. To help prevent local user exploits on the Postfix server, it is best for mail users to only access the Postfix server using an email program. Shell accounts on the mail server should not be allowed and all user shells in the /etc/passwd file should be set to /sbin/nologin (with the possible exception of the root user). 2.2.7.4. Disable Postfix Network ListeningBy default, Postfix is set up to only listen to the local loopback address. You can verify this by viewing the file /etc/postfix/main.cf. View the file /etc/postfix/main.cf to ensure that only the following inet_interfaces line appears: inet_interfaces = localhost This ensures that Postfix only accepts mail messages (such as cron job reports) from the local system and not from the network. This is the default setting and protects Postfix from a network attack. For removal of the localhost restriction and allowing Postfix to listen on all interfaces the inet_interfaces = all setting can be used. Sendmail is a Mail Transfer Agent (MTA) that uses the Simple Mail Transfer Protocol (SMTP) to deliver electronic messages between other MTAs and to email clients or delivery agents. Although many MTAs are capable of encrypting traffic between one another, most do not, so sending email over any public networks is considered an inherently insecure form of communication. It is recommended that anyone planning to implement a Sendmail server address the following issues. 2.2.8.1. Limiting a Denial of Service AttackBecause of the nature of email, a determined attacker can flood the server with mail fairly easily and cause a denial of service. By setting limits to the following directives in /etc/mail/sendmail.mc, the effectiveness of such attacks is limited. confCONNECTION_RATE_THROTTLE - The number of connections the server can receive per second. By default, Sendmail does not limit the number of connections. If a limit is set and reached, further connections are delayed.
confMAX_DAEMON_CHILDREN - The maximum number of child processes that can be spawned by the server. By default, Sendmail does not assign a limit to the number of child processes. If a limit is set and reached, further connections are delayed.
confMIN_FREE_BLOCKS - The minimum number of free blocks which must be available for the server to accept mail. The default is 100 blocks.
confMAX_HEADERS_LENGTH - The maximum acceptable size (in bytes) for a message header.
confMAX_MESSAGE_SIZE - The maximum acceptable size (in bytes) for a single message.
2.2.8.2. NFS and SendmailNever put the mail spool directory, /var/spool/mail/, on an NFS shared volume. Because NFSv2 and NFSv3 do not maintain control over user and group IDs, two or more users can have the same UID, and receive and read each other's mail. With NFSv4 using Kerberos, this is not the case, since the SECRPC_GSS kernel module does not utilize UID-based authentication. However, it is still considered good practice not to put the mail spool directory on NFS shared volumes. To help prevent local user exploits on the Sendmail server, it is best for mail users to only access the Sendmail server using an email program. Shell accounts on the mail server should not be allowed and all user shells in the /etc/passwd file should be set to /sbin/nologin (with the possible exception of the root user). 2.2.8.4. Disable Sendmail Network ListeningBy default, Sendmail is set up to only listen to the local loopback address. You can verify this by viewing the file /etc/mail/sendmail.mc to ensure that the following line appears: DAEMON_OPTIONS(`Port=smtp,Addr=127.0.0.1, Name=MTA')dnl This ensures that Sendmail only accepts mail messages (such as cron job reports) from the local system and not from the network. This is the default setting and protects Sendmail from a network attack. For removal of the localhost restriction, the Addr=127.0.0.1 string needs to be removed. Changing Sendmail's configuration requires installing the sendmail-cf package, then editing the .mc file, running /etc/mail/make and finally restarting sendmail. The .cf configuration file will be regenerated. Note that the system clock must be correct and working and that there must not be any system clock time shifts between these actions in order for the configuration file to be automatically regenerated. 2.2.9. Verifying Which Ports Are Listening Unnecessary open ports should be avoided because it increases the attack surface of your system. If after the system has been in service you find unexpected open ports in listening state, that might be signs of intrusion and it should be investigated. Issue the following command, as root, from the console to determine which ports are listening for connections from the network: ~]# netstat -tanp | grep LISTENtcp 0 0 0.0.0.0:45876 0.0.0.0:* LISTEN 1193/rpc.statd tcp 0 0 192.168.122.1:53 0.0.0.0:* LISTEN 1241/dnsmasq tcp 0 0 127.0.0.1:631 0.0.0.0:* LISTEN 1783/cupsd tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 7696/sendmail tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1167/rpcbind tcp 0 0 127.0.0.1:30003 0.0.0.0:* LISTEN 1118/tcsd tcp 0 0 :::631 :::* LISTEN 1/init tcp 0 0 :::35018 :::* LISTEN 1193/rpc.statd tcp 0 0 :::111 :::* LISTEN 1167/rpcbind Review the output of the command with the services needed on the system, turn off what is not specifically required or authorized, repeat the check. Proceed then to make external checks using nmap from another system connected via the network to the first system. This can be used verify the rules in iptables. Make a scan for every IP address shown in the netstat output (except for localhost 127.0.0.0 or ::1 range) from an external system. Use the -6 option for scanning an IPv6 address. See man nmap(1) for more information. The following is an example of the command to be issued from the console of another system to determine which ports are listening for TCP connections from the network: ~]# nmap -sT -O 192.168.122.1 Refer to the man pages for netstat, nmap, and services for more information. 2.2.10. Disable Source RoutingSource routing is an Internet Protocol mechanism that allows an IP packet to carry information, a list of addresses, that tells a router the path the packet must take. There is also an option to record the hops as the route is traversed. The list of hops taken, the "route record", provides the destination with a return path to the source. This allows the source (that is to say, the sending host) to specify the route, loosely or strictly, ignoring the routing tables of some or all of the routers. It can allow a user to redirect network traffic for malicious purposes. Therefore, source-based routing should be disabled. The accept_source_route option causes network interfaces to accept packets with the Strict Source Route ( SSR) or Loose Source Routing ( LSR) option set. The acceptance of source routed packets is controlled by sysctl settings. Issue the following command as root to drop packets with the SSR or LSR option set: ~]# /sbin/sysctl -w net.ipv4.conf.all.accept_source_route=0 Disabling the forwarding of packets should also be done in conjunction with the above when possible (disabling forwarding may interfere with virtualization). Issue the commands listed below as root: These commands disable forwarding of IPv4 and IPv6 packets on all interfaces. ~]# /sbin/sysctl -w net.ipv4.conf.all.forwarding=0 ~]# /sbin/sysctl -w net.ipv6.conf.all.forwarding=0 These commands disable forwarding of all multicast packets on all interfaces. ~]# /sbin/sysctl -w net.ipv4.conf.all.mc_forwarding=0 ~]# /sbin/sysctl -w net.ipv6.conf.all.mc_forwarding=0 Accepting ICMP redirects has few legitimate uses. Disable the acceptance and sending of ICMP redirected packets unless specifically required. These commands disable acceptance of all ICMP redirected packets on all interfaces. ~]# /sbin/sysctl -w net.ipv4.conf.all.accept_redirects=0 ~]# /sbin/sysctl -w net.ipv6.conf.all.accept_redirects=0 This command disables acceptance of secure ICMP redirected packets on all interfaces. ~]# /sbin/sysctl -w net.ipv4.conf.all.secure_redirects=0 This command disables acceptance of all IPv4 ICMP redirected packets on all interfaces. ~]# /sbin/sysctl -w net.ipv4.conf.all.send_redirects=0 There is only a directive to disable sending of IPv4 redirected packets. Refer to RFC4294 for an explanation of "IPv6 Node Requirements" which resulted in this difference between IPv4 and IPv6. In order to make the settings permanent they must be added to /etc/sysctl.conf. Refer to the sysctl man page, sysctl(8), for more information. Refer to RFC791 for an explanation of the Internet options related to source based routing and its variants. Ethernet networks provide additional ways to redirect traffic, such as ARP or MAC address spoofing, unauthorized DHCP servers, and IPv6 router or neighbor advertisements. In addition, unicast traffic is occasionally broadcast, causing information leaks. These weaknesses can only be addressed by specific countermeasures implemented by the network operator. Host-based countermeasures are not fully effective. 2.2.11. Reverse Path FilteringReverse path filtering is used to prevent packets which arrived via one interface from leaving via a different interface. When outgoing routes and incoming routes are different it is sometimes referred to as "asymmetric routing". Routers often route packets this way but most hosts should not need to do this. Exceptions are such applications as sending traffic out over one link and receiving traffic over another link from a different service provider. For example, using leased lines in combination with xDSL, or Satellite links with 3G modems. If such a scenario is applicable to you then turning off reverse path filtering on the incoming interface is necessary. In short, unless you know that it is required, it is best disabled as it prevents users spoofing IP addresses from local subnets and reduces the opportunity for DDoS attacks. Red Hat Enterprise Linux 6 (unlike Red Hat Enterprise Linux 5) defaults to using Strict Reverse Path filtering. Red Hat Enterprise Linux 6 follows the "Strict Reverse Path" recommendation from RFC 3704, Ingress Filtering for Multihomed Networks. This currently only applies to IPv4 in Red Hat Enterprise Linux 6. If forwarding is enabled, then Reverse Path Filtering should only be disabled if there are other means for source address validation (such as iptables rules for example). -
rp_filter Reverse Path Filter is enabled by means of the rp_filter directive. The rp_filter option is used to direct the kernel to select from one of three modes. It takes the following form when setting the default behavior: ~]# /sbin/sysctl -w net.ipv4.conf.default.rp_filter=INTEGER where INTEGER is one of the following: 0 - No source validation.
1 - Strict mode as defined in RFC3704.
2 - Loose mode as defined in RFC3704.
The setting can be overridden per network interface using net.ipv4.interface.rp_filter. To make these settings persistent across reboot, modify the /etc/sysctl.conf file.
2.2.11.1. Additional ResourcesThe following are resources which explain more about Reverse Path Filtering. 2.2.11.1.1. Installed Documentation-
usr/share/doc/kernel-doc-version/Documentation/networking/ip-sysctl.txt This contains a complete list of files and options available in the /proc/sys/net/ipv4/ directory.
2.2.11.1.2. Useful Websites |
| |
