Chapter 2. Securing Your Network
2.1. Workstation Security
2.1.1. Evaluating Workstation Security
- BIOS and Boot Loader Security — Can an unauthorized user physically access the machine and boot into single user or rescue mode without a password?
- Password Security — How secure are the user account passwords on the machine?
- Administrative Controls — Who has an account on the system and how much administrative control do they have?
- Available Network Services — What services are listening for requests from the network and should they be running at all?
- Personal Firewalls — What type of firewall, if any, is necessary?
- Security Enhanced Communication Tools — Which tools should be used to communicate between workstations and which should be avoided?
2.1.2. BIOS and Boot Loader Security
2.1.2.1. BIOS Passwords
- Preventing Changes to BIOS Settings — If an intruder has access to the BIOS, they can set it to boot from a CD-ROM or a flash drive. This makes it possible for an intruder to enter rescue mode or single user mode, which in turn allows them to start arbitrary processes on the system or copy sensitive data.
- Preventing System Booting — Some BIOSes allow password protection of the boot process. When activated, an attacker is forced to enter a password before the BIOS launches the boot loader.
2.1.2.1.1. Securing Non-x86 Platforms
2.1.2.2. Boot Loader Passwords
- Preventing Access to Single User Mode — If attackers can boot the system into single user mode, they are logged in automatically as root without being prompted for the root password.
Warning
Protecting access to single user mode with a password by editing theSINGLE
parameter in the/etc/sysconfig/init
file is not recommended. An attacker can bypass the password by specifying a custom initial command (using theinit=
parameter) on the kernel command line in GRUB. It is recommended to password-protect the GRUB boot loader as specified in Section 2.1.2.2.1, “Password Protecting GRUB”. - Preventing Access to the GRUB Console — If the machine uses GRUB as its boot loader, an attacker can use the GRUB editor interface to change its configuration or to gather information using the
cat
command. - Preventing Access to Insecure Operating Systems — If it is a dual-boot system, an attacker can select an operating system at boot time (for example, DOS), which ignores access controls and file permissions.
2.1.2.2.1. Password Protecting GRUB
/sbin/grub-md5-crypt
/boot/grub/grub.conf
. Open the file and below the timeout
line in the main section of the document, add the following line:
password --md5 <password-hash>
/sbin/grub-md5-crypt
[4].
/boot/grub/grub.conf
file must be edited.
title
line of the operating system that you want to secure, and add a line with the lock
directive immediately beneath it.
title DOS lock
Warning
password
line must be present in the main section of the /boot/grub/grub.conf
file for this method to work properly. Otherwise, an attacker can access the GRUB editor interface and remove the lock line.
lock
line to the stanza, followed by a password line.
title DOS lock password --md5 <password-hash>
2.1.2.2.2. Disabling Interactive Startup
PROMPT
parameter in the /etc/sysconfig/init
file:
PROMPT=no
2.1.3. Password Security
/etc/passwd
file, which makes the system vulnerable to offline password cracking attacks. If an intruder can gain access to the machine as a regular user, he can copy the /etc/passwd
file to his own machine and run any number of password cracking programs against it. If there is an insecure password in the file, it is only a matter of time before the password attacker discovers it.
/etc/shadow
, which is readable only by the root user.
2.1.3.1. Creating Strong Passwords
randomword1 randomword2 randomword3 randomword4
1!
". Note that such a modification does not increase the security of the passphrase significantly.
- Using a single dictionary word, a word in a foreign language, an inverted word, or only numbers.
- Using less than 10 characters for a password or passphrase.
- Using a sequence of keys from the keyboard layout.
- Writing down your passwords.
- Using personal information in a password, such as birth dates, anniversaries, family member names, or pet names.
- Using the same passphrase or password on multiple machines.
2.1.4. Creating User Passwords Within an Organization
2.1.4.1. Forcing Strong Passwords
passwd
, which is Pluggable Authentication Modules (PAM) aware and therefore checks to see if the password is too short or otherwise easy to crack. This check is performed using the pam_cracklib.so
PAM module. In Red Hat Enterprise Linux, the pam_cracklib
PAM module can be used to check a password's strength against a set of rules. It can be stacked alongside other PAM modules in the password
component of the/etc/pam.d/passwd
file to configure a custom set of rules for user login. The pam_cracklib
's routine consists of two parts: it checks whether the password provided is found in a dictionary, and, if that is not the case, it continues with a number of additional checks. For a complete list of these checks, see the pam_cracklib(8)
manual page.
Example 2.1. Configuring password strength-checking with pam_cracklib
password
section of the /etc/pam.d/passwd
file:
password required pam_cracklib.so retry=3 minlen=8 minclass=4
password
section of the /etc/pam.d/passwd
file:
password required pam_cracklib.so retry=3 maxsequence=3 maxrepeat=3
Note
pam_passwdqc
(available from http://www.openwall.com/passwdqc/) or to write a new module. For a list of available PAM modules, see http://uw714doc.sco.com/en/SEC_pam/pam-6.html. For more information about PAM, see the Managing Single Sign-On and Smart Cards guide.
- John The Ripper — A fast and flexible password cracking program. It allows the use of multiple word lists and is capable of brute-force password cracking. It is available online at http://www.openwall.com/john/.
- Crack — Perhaps the most well known password cracking software, Crack is also very fast, though not as easy to use as John The Ripper.
- Slurpie — Slurpie is similar to John The Ripper and Crack, but it is designed to run on multiple computers simultaneously, creating a distributed password cracking attack. It can be found along with a number of other distributed attack security evaluation tools online at http://www.ussrback.com/distributed.htm.
Warning
2.1.4.2. Passphrases
2.1.4.3. Password Aging
chage
command or the graphical User Manager (system-config-users
) application.
Important
chage
command. For more information, see the Red Hat Enterprise Linux 6 Deployment Guide.
-M
option of the chage
command specifies the maximum number of days the password is valid. For example, to set a user's password to expire in 90 days, use the following command:
chage
-M 90
<username>
99999
after the -M
option (this equates to a little over 273 years).
chage
command, see the table below.
Option | Description |
---|---|
-d days | Specifies the number of days since January 1, 1970 the password was changed. |
-E date | Specifies the date on which the account is locked, in the format YYYY-MM-DD. Instead of the date, the number of days since January 1, 1970 can also be used. |
-I days | Specifies the number of inactive days after the password expiration before locking the account. If the value is 0 , the account is not locked after the password expires. |
-l | Lists current account aging settings. |
-m days | Specify the minimum number of days after which the user must change passwords. If the value is 0 , the password does not expire. |
-M days | Specify the maximum number of days for which the password is valid. When the number of days specified by this option plus the number of days specified with the -d option is less than the current day, the user must change passwords before using the account. |
-W days | Specifies the number of days before the password expiration date to warn the user. |
chage
command in interactive mode to modify multiple password aging and account details. Use the following command to enter interactive mode:
chage
<username>
~]#chage juan
Changing the aging information for juan Enter the new value, or press ENTER for the default Minimum Password Age [0]:10
Maximum Password Age [99999]:90
Last Password Change (YYYY-MM-DD) [2006-08-18]: Password Expiration Warning [7]: Password Inactive [-1]: Account Expiration Date (YYYY-MM-DD) [1969-12-31]:
- Set up an initial password. There are two common approaches to this step: you can either assign a default password, or you can use a null password.To assign a default password, type the following at a shell prompt as
root
:passwd
usernameTo assign a null password instead, use the following command:passwd
-d
usernameWarning
Using a null password, while convenient, is a highly insecure practice, as any third party can log in first and access the system using the insecure user name. Always make sure that the user is ready to log in before unlocking an account with a null password. - Force immediate password expiration by running the following command as
root
:chage
-d
0
usernameThis command sets the value for the date the password was last changed to the epoch (January 1, 1970). This value forces immediate password expiration no matter what password aging policy, if any, is in place.
- Click themenu on the Panel, point to and then click to display the User Manager. Alternatively, type the command
system-config-users
at a shell prompt. - Click the Users tab, and select the required user in the list of users.
- Clickon the toolbar to display the User Properties dialog box (or choose on the menu).
- Click the Password Info tab, and select the check box for Enable password expiration.
- Enter the required value in the Days before change required field, and click .
Figure 2.1. Specifying password aging options
screenshot needs to be updated
2.1.5. Locking Inactive Accounts
pam_lastlog
PAM module is used to lock out users who have not logged in recently enough, or to display information about the last login attempt of a user. The module does not perform a check on the root account, so it is never locked out.
lastlog
command displays the last login of the user, аs opposed to the last
command, which displays all current and previous login sessions. The commands read respectively from the /var/log/lastlog
and /var/log/wtmp
files where the data is stored in binary format.
- To display the number of failed login attempts prior to the last successful login of a user, add, as root, the following line to the
session
section in the/etc/pam.d/login
file:session optional pam_lastlog.so silent noupdate showfailed
- To lock out an account after 10 days of inactivity, add, as root, the following line to the
auth
section of the/etc/pam.d/login
file:auth required pam_lastlog.so inactive=10
- To lock out an account for the GNOME desktop environment, add, as root, the following line to the
auth
section of the/etc/pam.d/gdm
file:auth required pam_lastlog.so inactive=10
Note
2.1.6. Customizing Access Control
pam_access
PAM module allows an administrator to customize access control based on login names, host or domain names, or IP addresses. By default, the module reads the access rules from the /etc/security/access.conf
file if no other is specified. For a complete description of the format of these rules, see the access.conf(5)
manual page. By default, in Red Hat Enterprise Linux, pam_access
is included in the /etc/pam.d/crond
and /etc/pam.d/atd
files.
- Include the following line in the
account
section of both/etc/pam.d/login
and/etc/pam.d/gdm-*
files:account required pam_access.so
- Specify the following rule in the
/etc/security/access.conf
file:- : john : ALL
This rule prohibits all logins from user john from any location.
- Include the following line in the
account
section of/etc/pam.d/sshd
:account required pam_access.so
- Specify the following rule in the /etc/security/access.conf file:
+ : ALL EXCEPT john : 1.2.3.4
pam_access
module should be required in the respective file in the /etc/pam.d
directory.
pam_access
module for all services that call the system wide PAM configuration files (*-auth
files in the /etc/pam.d
directory) using the following command:
authconfig --enablepamaccess --update
pam_access
module using the Authentication Configuration utility. To start this utility, select → → from the top menu. From the tab, check the "enable local access control option". This will add the pam_access
module to the systemwide PAM configuration.
2.1.7. Time-based Restriction of Access
pam_time
PAM module is used to restrict access during a certain time of the day. It can also be configured to control access based on specific days of a week, user name, usage of a system service, and more. By default, the module reads the access rules from the /etc/security/time.conf
file. For a complete description of the format of these rules, see the time.conf(5)
manual page.
- Include the following line in the account section of the
/etc/pam.d/login
file:account required pam_time.so
- Specify the following rule in the
/etc/security/time.conf
file:login ; tty* ; ALL ; !root ; !Wk1730-0800
- Add the following line to the
/etc/pam.d/sshd file:
account required pam_time.so
- Specify the following rule in the
/etc/security/time.conf
file:sshd ; tty* ; john ; Wk0800-1730
Note
pam_time
module should be included in the corresponding files in the /etc/pam.d
directory.
2.1.8. Applying Account Limits
pam_limits
PAM module is used to:
- apply limits to user login sessions, such as maximum simultaneous login sessions per user,
- specify limits to be set by the ulimit utility,
- and specify priority to be set by the nice utility.
/etc/security/limits.conf
file. For a complete description of the format of these rules, see the limits.conf(5)
manual page. Additionally, you can create individual configuration files in the /etc/security/limits.d
directory specifically for certain applications or services. By default, the pam_limits
module is included in a number of files in the/etc/pam.d/
directory. A default limit of user processes is defined in the /etc/security/limits.d/90-nproc.conf
file to prevent malicious denial of service attacks, such as fork bombs. To change the default limit of user processes to 50, change the value in the /etc/security/limits.d/90-nproc.conf
, following the format in the file:
* soft nproc 50
Example 2.2. Specifying a maximum number of logins per user
- To set a maximum number of simultaneous logins for each user in a group called
office
, specify the following rule in the/etc/security/limits.conf
file:@office - maxlogins 4
- The following line should be present by default in
/etc/pam.d/system-auth
. If not, add it manually.session required pam_limits.so
2.1.9. Administrative Controls
sudo
or su
. A setuid program is one that operates with the user ID (UID) of the program's owner rather than the user operating the program. Such programs are denoted by an s
in the owner section of a long format listing, as in the following example:
~]$ ls -l /bin/su
-rwsr-xr-x. 1 root root 34904 Mar 10 2011 /bin/su
Note
s
may be upper case or lower case. If it appears as upper case, it means that the underlying permission bit has not been set.
pam_console.so
, some activities normally reserved only for the root user, such as rebooting and mounting removable media are allowed for the first user that logs in at the physical console (see Managing Single Sign-On and Smart Cards for more information about the pam_console.so
module.) However, other important system administration tasks, such as altering network settings, configuring a new mouse, or mounting network devices, are not possible without administrative privileges. As a result, system administrators must decide how much access the users on their network should receive.
2.1.9.1. Allowing Root Access
- Machine Misconfiguration — Users with root access can misconfigure their machines and require assistance to resolve issues. Even worse, they might open up security holes without knowing it.
- Running Insecure Services — Users with root access might run insecure servers on their machine, such as FTP or Telnet, potentially putting user names and passwords at risk. These services transmit this information over the network in plain text.
- Running Email Attachments As Root — Although rare, email viruses that affect Linux do exist. The only time they are a threat, however, is when they are run by the root user.
- Keeping the audit trail intact — Because the root account is often shared by multiple users, so that multiple system administrators can maintain the system, it is impossible to figure out which of those users was root at a given time. When using separate logins, the account a user logs in with, as well as a unique number for session tracking purposes, is put into the task structure, which is inherited by every process that the user starts. When using concurrent logins, the unique number can be used to trace actions to specific logins. When an action generates an audit event, it is recorded with the login account and the session associated with that unique number. Use the
aulast
command to view these logins and sessions. The--proof
option of theaulast
command can be used suggest a specificausearch
query to isolate auditable events generated by a particular session.
2.1.9.2. Disallowing Root Access
- Changing the root shell
- To prevent users from logging in directly as root, the system administrator can set the root account's shell to
/sbin/nologin
in the/etc/passwd
file.Table 2.2. Disabling the Root Shell Effects Does Not Affect Prevents access to the root shell and logs any such attempts. The following programs are prevented from accessing the root account:login
gdm
kdm
xdm
su
ssh
scp
sftp
Programs that do not require a shell, such as FTP clients, mail clients, and many setuid programs. The following programs are not prevented from accessing the root account:sudo
- FTP clients
- Email clients
- Disabling root access through any console device (tty)
- To further limit access to the root account, administrators can disable root logins at the console by editing the
/etc/securetty
file. This file lists all devices the root user is allowed to log into. If the file does not exist at all, the root user can log in through any communication device on the system, whether through the console or a raw network interface. This is dangerous, because a user can log in to their machine as root through Telnet, which transmits the password in plain text over the network.By default, Red Hat Enterprise Linux's/etc/securetty
file only allows the root user to log in at the console physically attached to the machine. To prevent the root user from logging in, remove the contents of this file by typing the following command at a shell prompt as root:echo > /etc/securetty
To enablesecuretty
support in the KDM, GDM, and XDM login managers, add the following line:auth [user_unknown=ignore success=ok ignore=ignore default=bad] pam_securetty.so
to the files listed below:/etc/pam.d/gdm
/etc/pam.d/gdm-autologin
/etc/pam.d/gdm-fingerprint
/etc/pam.d/gdm-password
/etc/pam.d/gdm-smartcard
/etc/pam.d/kdm
/etc/pam.d/kdm-np
/etc/pam.d/xdm
Warning
A blank/etc/securetty
file does not prevent the root user from logging in remotely using the OpenSSH suite of tools because the console is not opened until after authentication.Table 2.3. Disabling Root Logins Effects Does Not Affect Prevents access to the root account using the console or the network. The following programs are prevented from accessing the root account:login
gdm
kdm
xdm
- Other network services that open a tty
Programs that do not log in as root, but perform administrative tasks through setuid or other mechanisms. The following programs are not prevented from accessing the root account:su
sudo
ssh
scp
sftp
- Disabling root SSH logins
- To prevent root logins using the SSH protocol, edit the SSH daemon's configuration file,
/etc/ssh/sshd_config
, and change the line that reads:#PermitRootLogin yes
to read as follows:PermitRootLogin no
Table 2.4. Disabling Root SSH Logins Effects Does Not Affect Prevents root access using the OpenSSH suite of tools. The following programs are prevented from accessing the root account:ssh
scp
sftp
Programs that are not part of the OpenSSH suite of tools. - Using PAM to limit root access to services
- PAM, through the
/lib/security/pam_listfile.so
module, allows great flexibility in denying specific accounts. The administrator can use this module to reference a list of users who are not allowed to log in. To limit root access to a system service, edit the file for the target service in the/etc/pam.d/
directory and make sure thepam_listfile.so
module is required for authentication.The following is an example of how the module is used for thevsftpd
FTP server in the/etc/pam.d/vsftpd
PAM configuration file (the\
character at the end of the first line is not necessary if the directive is on a single line):auth required /lib/security/pam_listfile.so item=user \ sense=deny file=/etc/vsftpd.ftpusers onerr=succeed
This instructs PAM to consult the/etc/vsftpd.ftpusers
file and deny access to the service for any listed user. The administrator can change the name of this file, and can keep separate lists for each service or use one central list to deny access to multiple services.If the administrator wants to deny access to multiple services, a similar line can be added to the PAM configuration files, such as/etc/pam.d/pop
and/etc/pam.d/imap
for mail clients, or/etc/pam.d/ssh
for SSH clients.For more information about PAM, see the chapter titled Using Pluggable Authentication Modules (PAM) in the Red Hat Enterprise Linux Managing Single Sign-On and Smart Cards guide.Table 2.5. Disabling Root Using PAM Effects Does Not Affect Prevents root access to network services that are PAM aware. The following services are prevented from accessing the root account:login
gdm
kdm
xdm
ssh
scp
sftp
- FTP clients
- Email clients
- Any PAM aware services
Programs and services that are not PAM aware.
2.1.9.3. Enabling Automatic Logouts
root
, an unattended login session may pose a significant security risk. To reduce this risk, you can configure the system to automatically log out idle users after a fixed period of time:
- Make sure the screen package is installed. You can do so by running the following command as
root
:~]#
yum
install
screen
For more information on how to install packages in Red Hat Enterprise Linux, see the Installing Packages section in the Red Hat Enterprise Linux 6 Deployment Guide. - As
root
, add the following line at the beginning of the/etc/profile
file to make sure the processing of this file cannot be interrupted:trap "" 1 2 3 15
- Add the following lines at the end of the
/etc/profile
file to start ascreen
session each time a user logs in to a virtual console or remotely:SCREENEXEC="screen" if [ -w $(tty) ]; then trap "exec $SCREENEXEC" 1 2 3 15 echo -n 'Starting session in 10 seconds' sleep 10 exec $SCREENEXEC fi
Note that each time a new session starts, a message will be displayed and the user will have to wait ten seconds. To adjust the time to wait before starting a session, change the value after thesleep
command. - Add the following lines to the
/etc/screenrc
configuration file to close thescreen
session after a given period of inactivity:idle 120 quit autodetach off
This will set the time limit to 120 seconds. To adjust this limit, change the value after theidle
directive.Alternatively, you can configure the system to only lock the session by using the following lines instead:idle 120 lockscreen autodetach off
This way, a password will be required to unlock the session.
2.1.9.4. Limiting Root Access
su
or sudo
. For more information on su
and sudo
, see the Red Hat Enterprise Linux 6 Deployment Guide and the su(1)
and sudo(8)
man pages.
2.1.9.5. Account Locking
pam_faillock
PAM module allows system administrators to lock out user accounts after a specified number of failed attempts. Limiting user login attempts serves mainly as a security measure that aims to prevent possible brute force attacks targeted to obtain a user's account password.
pam_faillock
module, failed login attempts are stored in a separate file for each user in the /var/run/faillock
directory.
Note
even_deny_root
option is used.
- To lock out any non-root user after three unsuccessful attempts and unlock that user after 10 minutes, add the following lines to the
auth
section of the/etc/pam.d/system-auth
and/etc/pam.d/password-auth
files:auth required pam_faillock.so preauth silent audit deny=3 unlock_time=600 auth sufficient pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail audit deny=3 unlock_time=600
- Add the following line to the
account
section of both files specified in the previous step:account required pam_faillock.so
- To apply account locking for the root user as well, add the
even_deny_root
option to thepam_faillock
entries in the/etc/pam.d/system-auth
and/etc/pam.d/password-auth
files:auth required pam_faillock.so preauth silent audit deny=3 even_deny_root unlock_time=600 auth sufficient pam_unix.so nullok try_first_pass auth [default=die] pam_faillock.so authfail audit deny=3 even_deny_root unlock_time=600 account required pam_faillock.so
john
attempts to log in for the fourth time after failing to log in three times previously, his account is locked upon the fourth attempt:
[user@localhost ~]$ su - john Account locked due to 3 failed logins su: incorrect password
pam_faillock
is called for the first time in both /etc/pam.d/system-auth
and /etc/pam.d/password-auth
. Also replace user1
, user2
, user3
with the actual user names.
auth [success=1 default=ignore] pam_succeed_if.so user in user1:user2:user3
[root@localhost ~]# faillock
john:
When Type Source Valid
2013-03-05 11:44:14 TTY pts/0 V
faillock
--user <username> --reset
system-auth
and password-auth
files are overwritten with the settings from the authconfig utility. This can be avoided by creating symbolic links in place of the configuration files, which authconfig recognizes and does not overwrite. In order to use custom settings in the configuration files and authconfig simultaneously, configure account locking using the following steps:
- Rename the configuration files:
~]#
mv /etc/pam.d/system-auth /etc/pam.d/system-auth-local
~]#mv /etc/pam.d/password-auth /etc/pam.d/password-auth-local
- Create the following symbolic links:
~]#
ln -s /etc/pam.d/system-auth-local /etc/pam.d/system-auth
~]#ln -s /etc/pam.d/password-auth-local /etc/pam.d/password-auth
- The
/etc/pam.d/system-auth-local
file should contain the following lines:auth required pam_faillock.so preauth silent audit deny=3 unlock_time=600 auth include system-auth-ac auth [default=die] pam_faillock.so authfail silent audit deny=3 unlock_time=600 account required pam_faillock.so account include system-auth-ac password include system-auth-ac session include system-auth-ac
- The
/etc/pam.d/password-auth-local
file should contain the following lines:auth required pam_faillock.so preauth silent audit deny=3 unlock_time=600 auth include password-auth-ac auth [default=die] pam_faillock.so authfail silent audit deny=3 unlock_time=600 account required pam_faillock.so account include password-auth-ac password include system-auth-ac session include system-auth-ac
pam_faillock
configuration options, see the pam_faillock(8)
man page.
2.1.10. Session Locking
Note
2.1.10.1. Locking GNOME Using gnome-screensaver-command
- Press the key combination specified in→ → → → . The default combination is Ctrl+Alt+L.
- Select→ on the panel.
- Execute the following command from a command line interface:
gnome-screensaver-command
-l
gnome-screensaver
process to be running. You can check whether this is the case by using any command which provides information about processes. For example, execute the following command from the terminal:
pidof gnome-screensaver
gnome-screensaver
process is currently running, a number denoting its identification number (PID) will be displayed on the screen after executing the command. If the process is not currently running, the command will provide no output at all.
gnome-screensaver-command(1)
man page for additional information.
Important
2.1.10.1.1. Automatic Lock on Screen Saver Activation
gnome-screensaver-command
suggests, the locking functionality is tied to GNOME's screen saver. It is possible to tie the lock to the screen saver's activation, locking the workstation every time it is left unattended for a set period of time. This function is activated by default with a five minute timeout.
Figure 2.2. Changing the screen saver preferences
Note
2.1.10.1.2. Remote Session Locking
ssh
as long as the target workstation accepts connections over this protocol. To remotely lock the screen on a machine you have access to, execute the following command:
ssh -X <username>@<server> "export DISPLAY=:0; gnome-screensaver-command -l"
ssh
.
2.1.10.2. Locking Virtual Consoles Using vlock
vlock
. To install this utility, execute the following command as root:
~]# yum install vlock
vlock
command without any additional parameters. This locks the currently active virtual console session while still allowing access to the others. To prevent access to all virtual consoles on the workstation, execute the following:
vlock
-a
vlock
locks the currently active console and the -a
option prevents switching to other virtual consoles.
vlock(1)
man page for additional information.
Important
vlock
currently available for Red Hat Enterprise Linux 6:
- The program does not currently allow unlocking consoles using the root password. Additional information can be found in BZ#895066.
- Locking a console does not clear the screen and scrollback buffer, allowing anyone with physical access to the workstation to view previously issued commands and any output displayed in the console. Refer to BZ#807369 for more information.
2.1.11. Available Network Services
2.1.11.1. Risks To Services
- Denial of Service Attacks (DoS) — By flooding a service with requests, a denial of service attack can render a system unusable as it tries to log and answer each request.
- Distributed Denial of Service Attack (DDoS) — A type of DoS attack which uses multiple compromised machines (often numbering in the thousands or more) to direct a coordinated attack on a service, flooding it with requests and making it unusable.
- Script Vulnerability Attacks — If a server is using scripts to execute server-side actions, as Web servers commonly do, an attacker can attack improperly written scripts. These script vulnerability attacks can lead to a buffer overflow condition or allow the attacker to alter files on the system.
- Buffer Overflow Attacks — Services that connect to ports numbered 0 through 1023 must run as an administrative user. If the application has an exploitable buffer overflow, an attacker could gain access to the system as the user running the daemon. Because exploitable buffer overflows exist, attackers use automated tools to identify systems with vulnerabilities, and once they have gained access, they use automated rootkits to maintain their access to the system.
Note
Important
2.1.11.2. Identifying and Configuring Services
cupsd
— The default print server for Red Hat Enterprise Linux.lpd
— An alternative print server.xinetd
— A super server that controls connections to a range of subordinate servers, such asgssftp
andtelnet
.sendmail
— The Sendmail Mail Transport Agent (MTA) is enabled by default, but only listens for connections from the localhost.sshd
— The OpenSSH server, which is a secure replacement for Telnet.
cupsd
running. The same is true for portmap
. If you do not mount NFSv3 volumes or use NIS (the ypbind
service), then portmap
should be disabled.
Figure 2.3. Services Configuration Tool
2.1.11.3. Insecure Services
- Transmit Usernames and Passwords Over a Network Unencrypted — Many older protocols, such as Telnet and FTP, do not encrypt the authentication session and should be avoided whenever possible.
- Transmit Sensitive Data Over a Network Unencrypted — Many protocols transmit data over the network unencrypted. These protocols include Telnet, FTP, HTTP, and SMTP. Many network file systems, such as NFS and SMB, also transmit information over the network unencrypted. It is the user's responsibility when using these protocols to limit what type of data is transmitted.Remote memory dump services, like
netdump
, transmit the contents of memory over the network unencrypted. Memory dumps can contain passwords or, even worse, database entries and other sensitive information.Other services likefinger
andrwhod
reveal information about users of the system.
rlogin
, rsh
, telnet
, and vsftpd
.
rlogin
, rsh
, and telnet
) should be avoided in favor of SSH. Refer to Section 2.1.13, “Security Enhanced Communication Tools” for more information about sshd
.
finger
authd
(this was calledidentd
in previous Red Hat Enterprise Linux releases.)netdump
netdump-server
nfs
rwhod
sendmail
smb
(Samba)yppasswdd
ypserv
ypxfrd
2.1.12. Personal Firewalls
Important
system-config-firewall
). This tool creates broad iptables
rules for a general-purpose firewall using a control panel interface.
iptables
is preferable. Refer to Section 2.8, “Firewalls” for more information. Refer to Section 2.8.9, “IPTables” for a comprehensive guide to the iptables
command.
2.1.13. Security Enhanced Communication Tools
- OpenSSH — A free implementation of the SSH protocol for encrypting network communication.
- Gnu Privacy Guard (GPG) — A free implementation of the PGP (Pretty Good Privacy) encryption application for encrypting data.
telnet
and rsh
. OpenSSH includes a network service called sshd
and three command line client applications:
ssh
— A secure remote console access client.scp
— A secure remote copy command.sftp
— A secure pseudo-ftp client that allows interactive file transfer sessions.
Important
sshd
service is inherently secure, the service must be kept up-to-date to prevent security threats. Refer to Section 1.5, “Security Updates” for more information.
2.1.14. Enforcing Read-Only Mounting of Removable Media
udev
rule to detect removable media and configure them to be mounted read-only using the blockdev utility. Starting with Red Hat Enterprise Linux 6.7, a special parameter can be also passed to the udisks
disk manager to force read-only mounting of file systems.
udev
rule that triggers the blockdev utility is sufficient for enforcing read-only mounting of physical media, the udisks
parameter can be used to enforce read-only mounting of filesystems on read-write mounted media.
Using blockdev to Force Read-Only Mounting of Removable Media
udev
configuration file named, for example, 80-readonly-removables.rules
in the /etc/udev/rules.d/
directory with the following content:
SUBSYSTEM=="block",ATTRS{removable}=="1",RUN{program}="/sbin/blockdev --setro %N"
udev
rule ensures that any newly connected removable block (storage) device is automatically configured as read-only using the blockdev
utility.
Using udisks to Force Read-Only Mounting of Filesystems
udisks
parameter needs to be set through udev
. Create a new udev
configuration file named, for example, 80-udisks.rules
in the /etc/udev/rules.d/
directory with the following content (or add the following lines to this file if it already exists):
ENV{UDISKS_MOUNT_OPTIONS}="ro,noexec" ENV{UDISKS_MOUNT_OPTIONS_ALLOW}="noexec,nodev,nosuid,atime,noatime,nodiratime,ro,sync,dirsync"
80-udisks.rules
file is installed with the udisks package in the /lib/udev/rules.d/
directory. This file contains the above rules, but they are commented out.
udev
rules instruct the udisks
disk manager to only allow read-only mounting of file systems. Also, the noexec
parameter forbids direct execution of any binaries on the mounted file systems. This policy is enforced regardless of the way the actual physical device is mounted. That is, file systems are mounted read-only even on read-write mounted devices.
Applying New udev and udisks Settings
udev
rules need to be applied. The udev
service automatically detects changes to its configuration files, but new settings are not applied to already existing devices. Only newly connected devices are affected by the new settings. Therefore, you need to unmount and unplug all connected removable media to ensure that the new settings are applied to them when they are next plugged in.
udev
to re-apply all rules to already existing devices, enter the following command as root
:
~#
udevadm trigger
udev
to re-apply all rules using the above command does not affect any storage devices that are already mounted.
udev
to reload all rules (in case the new rules are not automatically detected for some reason), use the following command:
~#
udevadm control --reload