48.2. 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.
48.2.1. Securing Services With TCP Wrappers and xinetd
xinetd, a super server that provides additional access, logging, binding, redirection, and resource utilization control.
xinetdto create redundancy within service access controls. Refer to Section 48.8, “Firewalls” for more information about implementing firewalls with iptables commands.
188.8.131.52. Enhancing Security With TCP Wrappers
hosts_optionsman page for information about the TCP Wrapper functionality and control language.
184.108.40.206.2. TCP Wrappers and Attack Warnings
/etc/hosts.denyfile to deny any connection attempts from that network, and to log the attempts to a special file:
ALL : 220.127.116.11 : spawn /bin/ 'date' %c %d >> /var/log/intruder_alert
%dtoken supplies the name of the service that the attacker was trying to access.
spawndirective in the
spawndirective executes any shell command, create a special script to notify the administrator or execute a chain of commands in the event that a particular client attempts to connect to the server.
18.104.22.168.3. TCP Wrappers and Enhanced Logging
emergflag in the log files instead of the default flag,
info, and deny the connection.
in.telnetd : ALL : severity emerg
authprivlogging facility, but elevates the priority from the default value of
emerg, which posts log messages directly to the console.
22.214.171.124. Enhancing Security With xinetd
xinetdto set a trap service and using it to control resource levels available to any given
xinetdservice. Setting resource limits for services can help thwart Denial of Service (DoS) attacks. Refer to the man pages for
xinetd.conffor a list of available options.
126.96.36.199.1. Setting a Trap
xinetdis its ability to add hosts to a global
no_accesslist. Hosts on this list are denied subsequent connections to services managed by
xinetdfor a specified period or until
xinetdis restarted. You can do this using the
SENSORattribute. This is an easy way to block hosts attempting to scan the ports on the server.
SENSORis to choose a service you do not plan on using. For this example, Telnet is used.
/etc/xinetd.d/telnetand change the
flagsline to read:
flags = SENSOR
deny_time = 30
deny_timeattribute are FOREVER, which keeps the ban in effect until
xinetdis restarted, and NEVER, which allows the connection and logs it.
disable = no
SENSORis 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
SENSORis running can mount a Denial of Service attack against particular hosts by forging their IP addresses and connecting to the forbidden port.
188.8.131.52.2. Controlling Server Resources
xinetdis its ability to set resource limits for services under its control.
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
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
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
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
xinetdservice from overwhelming the system, resulting in a denial of service.
48.2.2. Securing Portmap
portmapservice 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.
portmaponly affects NFSv2 and NFSv3 implementations, since NFSv4 no longer requires it. If you plan to implement an NFSv2 or NFSv3 server, then
portmapis required, and the following section applies.
184.108.40.206. Protect portmap With TCP Wrappers
portmapservice since it has no built-in form of authentication.
220.127.116.11. Protect portmap With iptables
portmapservice, it is a good idea to add iptables rules to the server and restrict access to specific networks.
portmapservice) 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_famservice 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
iptables -A INPUT -p udp -s! 192.168.0.0/24 --dport 111 -j DROP
48.2.3. Securing NIS
ypserv,--> which is used in conjunction with
portmapand other related services to distribute maps of usernames, passwords, and other sensitive information to any computer claiming to be within its domain.
/usr/sbin/rpc.yppasswdd— Also called the
yppasswddservice, this daemon allows users to change their NIS passwords.
/usr/sbin/rpc.ypxfrd— Also called the
ypxfrdservice, 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.
portmapservice as outlined in Section 48.2.2, “Securing Portmap”, then address the following issues, such as network planning.
18.104.22.168. Carefully Plan the Network
22.214.171.124. Use a Password-like NIS Domain Name and Hostname
ypcat -d <NIS_domain> -h <DNS_hostname> passwd
/etc/shadowfile by typing the following command:
ypcat -d <NIS_domain> -h <DNS_hostname> shadow
/etc/shadowfile is not stored within an NIS map.
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.
126.96.36.199. Edit the
/var/yp/securenetsfile 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
ypservonly responds to requests from the appropriate network.
188.8.131.52. Assign Static Ports and Use iptables Rules
rpc.yppasswdd— the daemon that allows users to change their login passwords. Assigning ports to the other two NIS server daemons,
ypserv, allows for the creation of firewall rules to further protect the NIS server daemons from intruders.
YPSERV_ARGS="-p 834" YPXFRD_ARGS="-p 835"
iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport 834 -j DROP
iptables -A INPUT -p tcp -s! 192.168.0.0/24 --dport 835 -j DROP
iptables -A INPUT -p udp -s! 192.168.0.0/24 --dport 834 -j DROP
iptables -A INPUT -p udp -s! 192.168.0.0/24 --dport 835 -j DROP
184.108.40.206. Use Kerberos Authentication
/etc/shadowmap is sent over the network. If an intruder gains access to an 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.
48.2.4. Securing NFS
portmapservice as outlined in Section 48.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_GSSkernel module. Information on
portmapis still included, since Red Hat Enterprise Linux supports NFSv2 and NFSv3, both of which utilize
220.127.116.11. Carefully Plan the Network
18.104.22.168. Beware of Syntax Errors
/etc/exportsfile. Be careful not to add extraneous spaces when editing this file.
/etc/exportsfile shares the directory
/tmp/nfs/to the host
bob.example.comwith read/write permissions.
/etc/exportsfile, on the other hand, shares the same directory to the host
bob.example.comwith 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)
showmountcommand to verify what is being shared:
showmount -e <hostname>
22.214.171.124. Do Not Use the
nfsnobodyuser, 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.
no_root_squashis 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.
48.2.5. Securing the Apache HTTP Server
UserDirdirective 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 enabled UserDir disabled root
/root/. To add users to the list of disabled accounts, add a space-delimited list of users on the
126.96.36.199. Do Not Remove the
188.8.131.52. Restrict Permissions for Executable Directories
chown root <directory_name>
chmod 755 <directory_name>
48.2.6. Securing FTP
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.
184.108.40.206. Anonymous Access
/var/ftp/directory activates the anonymous account.
vsftpdpackage. This package establishes a directory tree for anonymous users and configures the permissions on directories to read-only for anonymous users.
220.127.116.11.1. Anonymous Upload
chmod 730 /var/ftp/pub/upload
drwx-wx--- 2 root ftp 4096 Feb 13 20:05 upload
vsftpd, add the following line to the
18.104.22.168. User Accounts
vsftpd, add the following directive to
22.214.171.124.1. Restricting User Accounts
sudoprivileges, the easiest way is to use a PAM list file as described in Section 126.96.36.199, “Disallowing Root Access”. The PAM configuration file for
vsftpd, add the username to
188.8.131.52. Use TCP Wrappers To Control Access
48.2.7. Securing Sendmail
/etc/mail/sendmail.cfby editing the
/etc/mail/sendmail.mcand using the
184.108.40.206. Limiting a Denial of Service Attack
/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.
220.127.116.11. NFS and Sendmail
/var/spool/mail/, on an NFS shared volume.
SECRPC_GSSkernel module does not utilize UID-based authentication. However, it is considered good practice not to put the mail spool directory on NFS shared volumes.
18.104.22.168. Mail-only Users
/etc/passwdfile should be set to
/sbin/nologin(with the possible exception of the root user).
48.2.8. Verifying Which Ports Are Listening
lsof -i. This method is less reliable since these programs do not connect to the machine from the network, but rather check to see what is running on the system. For this reason, these applications are frequent targets for replacement by attackers. Crackers attempt to cover their tracks if they open unauthorized network ports by replacing
lsofwith their own, modified versions.
nmap -sT -O localhost
Starting nmap 3.55 ( http://www.insecure.org/nmap/ ) at 2004-09-24 13:49 EDT Interesting ports on localhost.localdomain (127.0.0.1): (The 1653 ports scanned but not shown below are in state: closed) PORT STATE SERVICE 22/tcp open ssh 25/tcp open smtp 111/tcp open rpcbind 113/tcp open auth 631/tcp open ipp 834/tcp open unknown 2601/tcp open zebra 32774/tcp open sometimes-rpc11 Device type: general purpose Running: Linux 2.4.X|2.5.X|2.6.X OS details: Linux 2.5.25 - 2.6.3 or Gentoo 1.2 Linux 2.4.19 rc1-rc7) Uptime 12.857 days (since Sat Sep 11 17:16:20 2004) Nmap run completed -- 1 IP address (1 host up) scanned in 5.190 seconds
portmapdue to the presence of the
sunrpcservice. However, there is also a mystery service on port 834. To check if the port is associated with the official list of known services, type:
cat /etc/services | grep 834
lsof. To check for port 834 using
netstat, use the following command:
netstat -anp | grep 834
tcp 0 0 0.0.0.0:834 0.0.0.0:* LISTEN 653/ypbind
netstatis reassuring because a cracker opening a port surreptitiously on a hacked system is not likely to allow it to be revealed through this command. Also, the
[p]option reveals the process ID (PID) of the service that opened the port. In this case, the open port belongs to
ypbind(NIS), which is an RPC service handled in conjunction with the
lsofcommand reveals similar information to
netstatsince it is also capable of linking open ports to services:
lsof -i | grep 834
ypbind 653 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 655 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 656 0 7u IPv4 1319 TCP *:834 (LISTEN) ypbind 657 0 7u IPv4 1319 TCP *:834 (LISTEN)
servicesfor more information.