1. Account Management
Deleting Default Accounts (Importance: High)
Delete system Default accounts and unused accounts
Criteria
A. Delete Default accounts (lp, uucp, nuucp) B. Delete accounts of employees who have resigned, transferred, taken leave, or had their contracts terminated ※ Both items A and B must be applied.
Configuration Method
# userdel lp # userdel uucp # userdel nuucp
Detailed Description
Check for and delete unused Default accounts and suspicious unusual accounts on the system. Accounts that are clearly unused on most systems, and any suspicious accounts, must be deleted. (If an account must be created for server testing or maintenance, the principle is to delete it after the work is finished.)
In general, system accounts that do not need to log in should be denied login by referring to the “Restricting the shell for accounts that do not need to log in” item. Accounts created by default when an OS or package is installed often use a Default password, so they can be abused in password-guessing attacks.
- Delete accounts of employees who have resigned, transferred, taken leave, or had their contracts terminated, if such accounts exist
- Delete lp, uucp, nuucp, suspicious unusual accounts (for example, guest, test), and unused accounts
- Changing the login shell to /bin/false can create a security problem, so deletion is recommended
Managing root Privileges of General Accounts (Importance: High)
Check general accounts that have root privileges
Criteria
A. Set the UID of general accounts, excluding the root account and group, to 100 or higher
Configuration Method
# Open /etc/passwd and change the UID of any general account whose UID is 0 to 100 or higher
Example) Changing the UID of the wiki account to 2002
# usermod –u 2002 wiki
Detailed Description
The system administrator should regularly review and delete directories and files for every account, including root, and periodically review and remove unnecessary user accounts. This is required for security.
- Check whether any other general account has root privileges
- If a UID is duplicated with root, another user can use administrator privileges. If UIDs are duplicated between users,
user audit tracking is difficult, and user privileges are duplicated
- If a general account other than root has UID ‘0’, delete it or assign an appropriate UID (change it to a number of 100 or higher), and register general accounts that belong to the root group in a group with appropriate privileges
- Exclude system accounts (daemon, bin, adm, uucp, nuucp, lp, and so on)
<Distinguishing general accounts and their directories – distinguished in the contents of the “/etc/passwd” file>
The following is a sample of the /etc/passwd file. Fields are separated by “:”. If the third field is “0”, the account has superuser privileges. Accounts other than “0” can be treated as general accounts, and the sixth field is that account’s home directory
root:!:0:0::/:/bin/ksh daemon:!:1:1::/etc: bin:!:2:2::/bin: sys:!:3:3::/usr/sys: adm:!:4:4::/var/adm: uucp:!:5:5::/usr/lib/uucp: lpd:!:9:4294967294::/:
<passwd file fields>
loginID:x:UID:GID:comment:home_directory:login_shell
/etc/passwd File Permission Settings (Importance: High)
Check the permissions of /etc/passwd, which contains system user account information
Criteria
A. Set the permissions of /etc/passwd to 644 or stricter, owned by root
Configuration Method
# chmod 644 /etc/passwd # chown root /etc/passwd
Detailed Description
The /etc/passwd file contains the account information required to authenticate system users. This check assesses the risk of a security incident (obtaining general user privileges or /root privileges) that can result from mistakes or errors in file permission settings and administration.
/etc/group File Permission Settings (Importance: High)
Check the permissions of /etc/group, which contains system user group information
Criteria
A. Set the permissions of /etc/group to 644 or stricter, owned by root (or bin)
Configuration Method
# chmod 644 /etc/group # chown root /etc/group
Detailed Description
If a general user can access and modify the group file, an unauthorized user can be registered in the root group and obtain root privileges.
Check that general users are prevented from modifying the group file, and restrict write permission for other users.
/etc/shadow File Permission Settings (Importance: High)
Restrict access permissions on /etc/shadow, where passwords of system user accounts are stored
Criteria
A. Set the permissions of /etc/shadow to “400”, owned by root
Configuration Method
# chmod 400 /etc/shadow # chown root /etc/shadow
Detailed Description
A security incident can occur because of mistakes or errors in file permission settings and administration. The shadow file, where passwords are stored in encrypted form, must be readable only by the root account and requires special administration.
- Set the permissions of /etc/security/passwd to “400”, owned by root
<How to tell whether passwords are shadowed – distinguished in the contents of the “/etc/security/passwd” file>
The following is a sample of the /etc/security/passwd file.
root:
password = Mqdw08CvS5DvU
lastupdate = 1293494187
flags =
daemon:
password = *
bin:
password = *
Applying Password Usage Rules (Importance: High)
Prohibit weak passwords when setting passwords for user accounts (both root and general accounts)
Criteria
A. Configure password usage rules
- Run the Control-SA and RedOwl solutions
- Settings when the solutions are not running
Set the minimum password length, maximum password age, minimum password age, and account lockout threshold
# Run vi /etc/login.defs and apply settings such as the following (unit: days)
PASS_MIN_LEN 8 PASS_MAX_DAYS 70 PASS_MIN_DAYS 7
B. Password settings
- At least 8 characters using a combination of 2 of the character types (letters, digits, and special characters), or at least 10 characters using 3 types
※ Both items A and B must be applied
Configuration Method
[Security control 1] When an Identity Management solution is running
- Password rules are applied when the Control-SA program is running
(The current policy requires at least one letter, one digit, and one special character.) Check the Control-SA process
$ ps -ef|grep p_ctsc /bmc/ctsa/control-sa/exe/HP-UX-11/p_ctsce /bmc/ctsa/control-sa/exe/HP-UX-11/./p_ctscs /bmc/ctsa/control-sa/exe/ HP-UX-11/./p_ctscd
- Password rules are applied when the RedOwl program is running
Check the RedOwl process
$ ps -ef|grep cmmd ngmseos 417792 1 0 Jan 28 - 0:07 /usr/src/cmm/system/cmmd ngmseos 847942 417792 0 Jan 28 - 0:02 /usr/src/cmm/system/cmmd
[Security control 2] When an Identity Management solution is not running
1. Minimum password length
Check that a minimum password length is set in order to avoid password-guessing attacks
If a minimum password length is not set, or is set too short, a malicious user can easily guess the password because a weak password is in use
2. Maximum password age
Check the password age limit so that, if a password is leaked through some path, a user who connected arbitrarily cannot connect again at any time
3. Minimum password age
Check the password age limit so that, if a password is leaked through some path, a user who connected arbitrarily cannot connect again at any time
4. Remember previous passwords
Remember previously used passwords and prohibit reuse of a previously used password when the password is changed
- A password length of at least 8 characters is recommended
- Set the maximum password age to 70 days (10 weeks) or less
- Set the minimum password age to 7 days (1 week) or more
- Remember at least 12 previous passwords
5. Account lockout threshold
If an account lockout threshold is not set, an attacker can obtain a user password with little effort through a brute-force attack by an automated tool (Brute-Force Attack)
- Allow no more than 10 failed login attempts, and lock the account after 10 failures
- Configure the account so that login is possible again after 60 minutes
1) # Run vi /etc/security/user and configure it as follows (unit: weeks)
minlen = 8 maxage = 10 minage = 1 histsize = 12
2) Set the account lockout threshold
# Run vi /etc/security/user and configure it as follows (unit: number of attempts)
Loginretries = 10 (for the root account, set the value to 0 because problems can occur)
# Run vi /etc/security/login.cfg and configure it as follows (unit: minutes)
Loginreenable = 60
※ If these are set in the default section of /etc/security/user, the result is judged compliant
However, if separate settings are assigned per account, both the default section and the specified account’s settings must meet the four criteria above
Example) default :
minlen = 8
maxage = 10
minage = 1
Histsize = 12
sac :
minlen = 8
maxage = 10
minage = 1
Histsize = 12
[Reference] The default settings of #vi /etc/security/user are as follows
default:
minage - minimum period that must elapse before a password can be changed
maxage - minimum period that can elapse without changing the password
maxexpired - maximum period by which maxage can be exceeded
Minalpha - minimum number of alphabetic characters that a new password must contain
Minother - minimum number of non-alphabetic characters that a new password must contain
Minlen - minimum number of characters (length) that a new password must contain
maxrepeats - maximum number of times a single character can be repeated in a new password
Mindiff - minimum number of characters that must differ between the old password and the new password
histexpire - minimum period during which a password cannot be reused (unit: weeks)
Histsize - number of previous passwords that cannot be reused
dictionlist - list of dictionary files to check when a password is changed
pwdchecks - list of restrictions that must be observed when a password is changed
Detailed Description
When a password is set for a user account (both root and general accounts), if a password that is generally easy to guess is used, an unauthorized user can access the system by obtaining a general account or root privileges.
If a password is set differently from the criteria below, change the password according to the password policy.
<Password configuration criteria>
1) A password must be composed of at least two of the four character types below with a minimum length of 10, or at least three types with a minimum length of 8
(1) Uppercase letters (26), lowercase letters (26), digits (10), special characters (32)
<A password must be designed to reflect the following so that it is difficult for an unauthorized person to guess>
- Do not use a null password
- Do not use only letters or only digits
- Do not use a password that is identical to the user ID
- Do not use consecutive characters or digits (for example, 1111, 1234, abcd)
- Do not reuse passwords on a periodic basis
- Do not use passwords that are easy to guess, such as a phone number, birthday, account name, or hostname
* Check for weak passwords using the “John The Ripper” tool
Restricting the shell for accounts that do not need to log in
Check shell restrictions for system accounts that do not need to log in
Criteria
A. Restrict the shell for accounts that do not need to log in
Configuration Method
Example) Configure the daemon account so that it cannot log in
# vi /etc/passwd (Before) daemon:x:1:1::/:/sbin/ksh (After) daemon:x:1:1::/:/bin/false
Detailed Description
For users who rarely need access, restrict the shell so that unauthorized users are prevented from using the system.
- For system accounts that do not need to log in, restrict executable shells such as ‘/bin/sh’, and assign an ‘nologin’ (/bin/false) shell to prohibit login.
<Accounts that do not need an executable shell – “nologin” for accounts that do not need to log in>
[All accounts with typical system account names, such as daemon, bin, sys, adm, listen, nobody, nobody4, noaccess, diag, listen, operator, games, and gopher]
The following is a sample of the /etc/passwd file. Fields are separated by “:”
If the last field is “nologin” (or /bin/false), a shell with no function has been applied to the account
root:x:0:1:Super-User:/:/sbin/sh daemon:x:1:1::/etc/false: bin:x:2:2:: /etc/false: sys:x:3:3::/etc/false: adm:x:4:4:Admin:/etc/false: lp:x:71:8:Line Printer Admin:/etc/false: smtp:x:0:0:Mail Daemon User:/: uucp:x:5:5:uucp Admin:/etc/false:
<Account settings when a shell login is not required>
# useradd account -c "account finger information" -d /home/{account} -m -s /bin/false
Restricting Use of SU (Select User) (Importance: High)
Restrict the su command for users without privileges
Criteria
A. Create a wheel group and configure users in order to restrict use of the su command
Configuration Method
<Method 1> 1) In the vi /etc/security/user file, specify the group allowed to use the su command
# vi /etc/security/user
Example) default :
admin = false
login = true
sugroups = wheel (specify the group allowed to use the su command)
<Method 2> 1) Create a group (request the group to be created; wheel is generally used)
# mkgroup wheel
2) Change the group of the /usr/bin/su file to the wheel group
# chgrp wheel /usr/bin/su
3) Change the permissions of the /usr/bin/su file (4750)
# chmod 4750 /usr/bin/su
4) Add accounts that need to use the su command to the wheel group
# chgroup users=[account name] wheel
Detailed Description
A general user without administrator privileges can obtain root privileges by using the su command and then guessing the password (Password Guessing).
Therefore, use of the su command by general users must be restricted. (Configure the system so that only the wheel group can use the su command.)
2. File System
User UMASK (User MASK) Settings (Importance: Low)
Set UMASK so that permissions are applied to files and directories created by users on the system
Criteria
A. Set the user UMASK to 022 in /etc/profile or /etc/bashrc
Configuration Method
# vi /etc/profile
umask 022 (add this line)
or
# vi /etc/security/user
default :
umask=022 (add this line)
Detailed Description
The permissions applied when a user creates a file or directory on the system depend on the umask value. A low umask value can allow an unauthorized person to access files and directories that only an administrator should access.
To display the umask value set for the current user, run “umask” at the command prompt.
A umask value of “022” is recommended. A umask of “022” creates files with “rw-r–r–“ access permissions.
If the command is added to the account’s start profile (/etc/profile, /etc/default/login, .cshrc, .kshrc, .bashrc, .login, .profile, and so on), the user receives the changed umask value after login as well.
SUID (Set User-ID) and SGID (Set Group-ID) Settings (Importance: Low)
Remove unnecessary files owned by root that have SUID or SGID set
Criteria
A. Remove SUID (Set User-ID) and SGID (Set Group-ID)
※ However, files created by an application, or files created because they are required for operations, are treated as exceptions
Configuration Method
# chmod –s [file name]
| LINUX | ||
|---|---|---|
| /sbin/dump | /usr/bin/lpq-lpd | /usr/bin/newgrp |
| /sbin/restore | /usr/bin/lpr | /usr/sbin/lpc |
| /sbin/unix_chkpwd | /usr/bin/lpr-lpd | /usr/sbin/lpc-lpd |
| /usr/bin/at | /usr/bin/lprm | /usr/sbin/traceroute |
| /usr/bin/lpq | /usr/bin/lprm-lpd | |
Detailed Description
Files with SUID (Set User-ID) and SGID (Set Group-ID) set, especially files owned by root, are frequently used in buffer overflow attacks and local attacks and require strict security administration. These files must be managed periodically.
For setuid files owned by root that are weak from a security standpoint, remove the setuid and setgid attributes from setuid and setgid files other than those that are strictly required, and periodically assess and manage whether they are misconfigured and pose a security threat.
If an unusual file is found, such as a file created by an application or a file created arbitrarily by a user, setuid must be removed.
When removing setuid, proceed carefully while confirming that the OS and applications and other services continue to operate normally.
Example of how to remove it
# chmod -s file-name
Example of a periodic audit method:
# find / -user root -type f \( -perm -4000 -o -perm -2000 \) -exec ls -lg {} \;
If a setuid file must be used, restrict it so that only a specific group can use it.
Example of restricting use to a specific group:
Restrict general users from using setuid (only an arbitrary group is allowed)
# /usr/bin/chgrp <Group_Name> <Setuid_File_Name> # /usr/bin/chmod 4750 <Setuid_File_Name>
If you want to place the account wiki, which should be allowed to use setuid, into an arbitrary group, configure it as follows.
# usermod –G100 wiki G : change the setting for a list of supplementary groups 100 : the numerical value of the <Group>’s ID
/etc/inetd.conf File Permission Settings (Importance: High)
Remove write permission for other users on the daemon configuration file (/etc/inetd.conf), which is owned by root
Criteria
A. Restrict write permission for other users on /etc/inetd.conf, which is owned by root
Configuration Method
# chown root /etc/inetd.conf # chmod o-w /etc/inetd.conf
※ If the file is a link, change ownership of the original file that is linked
Detailed Description
Check whether access permissions are restricted on inetd.conf, the Internet super-daemon service configuration file.
The Internet super-daemon runs the daemons of the Internet services, which are internal programs registered in /etc/inetd.conf, when a request arrives from an external network. If the access permissions of inetd.conf are misconfigured, an unauthorized attacker can register a malicious program in this file and run it with root account privileges.
history File Permission Settings (Importance: Medium)
Manage permissions on the script files that store the commands of every user who has logged in to the system
Criteria
A. Permissions on history-related files are 600 or stricter
Configuration Method
# chmod 600 [user home directory path]/.history # chmod 600 [user home directory path]/.sh_history
Detailed Description
History files (.history, .sh_history, and so on) are scripts that store the commands of every user who logs in, so they require security administration.
Set the permissions of every user’s history file to “600”, and set the owner to the user.
Crontab File Permission Settings and Management (Importance: High)
Set permissions on Crontab-related files and on files that are scheduled to run with root privileges inside Crontab
Criteria
A. Remove write permission for other users on crontab-related files B. Set permissions on crontab files
- Set file permissions to 744 and the owner to root
- Set an absolute path for scheduled files
- Every file configured in crontab exists
※ Both items A and B must be applied
b. How to apply 1) Remove write permission for other users on crontab-related files
# chmod o-w /var/spool/cron/crontabs/*
2) Check the permissions of each file and then change them
# ls –al [file] # chmod 744 [file] # ls -al /backup/OS_backup.sh -rwxr--r-- 1 root sys 84 Aug 10 05:01 /backup/OS_backup.sh # ls -al /opt/sfm/vacuum -rwxr--r-- 1 root sys 67 Dec 18 14:47 /opt/sfm/vacuum
3) Change the owner of files that appear as a UID
# ls -al [file] -rw-r--r-- 1 102 other 0 Jun 5 11:00 /tmp/user3 # chown root [file] # ls -al [file] -rw-r--r-- 1 root other 0 Jun 5 11:00 /tmp/user3
※ If a file scheduled inside Crontab does not exist at the actual path, delete it from the Crontab list
Detailed Description
Check whether malicious access by general users to cron-related files is restricted.
Cron is a program that provides job scheduling and automatically performs a specific task at a specific time. If the access permissions of Cron-related files are misconfigured, an unauthorized person can change the user environment in various ways and cause a security incident.
Review is required of the permissions of executable files that are scheduled inside Crontab and configured to run from Crontab with root privileges. (Review by the responsible person is required.)
If the file is configured with general user privileges rather than root privileges, a malicious attacker can cause it to run on schedule. If a relative PATH is used, the file cannot be executed.
If a file is registered in Crontab but does not exist at the actual path, a malicious attacker can create an identical file and cause it to run on schedule.
While checking the permissions of files registered in Crontab, a problem can occur in which the owner of various files created by a deleted user remains as that user’s UID after the user who previously existed is deleted. An appropriate user must be assigned to such files.
- For executable files configured to run from Crontab with root privileges, set the permissions to 744 and the owner to root
- If a file scheduled inside Crontab is set with a relative PATH, change it to an absolute PATH
- If the owner of a file scheduled inside Crontab remains as a UID, assign an appropriate owner (root)
- Confirm whether a file scheduled inside Crontab exists at its actual path
# crontab –ㅣ 1 15 * * /backup/OS_backup.sh 30 * * * * /opt/sfm/vacuum
/etc/profile File Permission Settings (Importance: Medium)
Restrict access permissions on /etc/profile, the user configuration file
Criteria
A. Remove write permission for other users on /etc/profile, which is owned by root (or bin)
Configuration Method
# chown root /etc/profile # chmod o-w /etc/profile
Detailed Description
/etc/profile is the login script that sets the default environment for every user who logs in. If the access permissions of /etc/profile are misconfigured, an unauthorized person can change the user environment in various ways and cause a security incident.
/etc/hosts File Permission Settings (Importance: Medium)
Restrict access permissions on /etc/hosts, the hostname registration file
Criteria
A. Remove write permission for other users on /etc/issue, which is owned by root (or bin)
Configuration Method
# chown root /etc/hosts # chmod o-w /etc/hosts
※ If the file is a link, change ownership of the original file that is linked
Detailed Description
The /etc/hosts file is used to map an IP address to a hostname. If its access permissions are misconfigured, a malicious system will be trusted.
Managing User Home Directories and Files (Importance: Medium)
Restrict permissions on user home directories and environment-variable files inside home directories
Criteria
A. Remove write permission for other users on user home directories and environment-variable files
Configuration Method
# chmod o-w [home directory] # chmod o-w [file name] # chmod o-w [home directory path] [file name] (when removing permissions from a configuration file in the home directory)
Detailed Description
If an unauthorized user accesses files in a user home directory and tampers with configuration files and other files, the legitimate user’s service is restricted. Check that general users other than the home directory account are prevented from modifying that home directory and its environment-variable files.
If the access permissions of environment-variable files are misconfigured, an unauthorized person can change the user environment in various ways and cause a security incident.
Remove write permission for other users on environment-variable files such as “.profile”, “.kshrc”, “.cshrc”, “.bashrc”, “.bash_profile”, “.login”, “.exrc”, “.netrc”, “.dtprofile”, and “.Xdefaults”.
Permission Settings for Important Directory Files (Importance: Medium)
Set permissions on important directories and on files inside those directories
Criteria
A. Remove write permission for other users on important directories owned by root (or bin)
Configuration Method
# chown root [directory name] # chmod o-w [directory name]
Detailed Description
If the access permissions of important directories are misconfigured, an unauthorized person can change the user environment in various ways and cause a security incident.
Set the permissions of the /sbin, /etc/, /bin, /usr/bin, /usr/sbin, and /usr/lbin directories to remove write permission for other users, with ownership by root (or bin).
# ls -ldb /sbin /etc/ /bin /usr/bin /usr/sbin /usr/lbin
drwxrwxr-x 13 root bin 2048 Aug 25 14:53 /sbin
drwxrwxr-x 16 root bin 2048 Aug 26 09:27 /etc/
drwxrwxr-x 18 root bin 1024 Jun 10 1996 /bin
drwxrwxr-x 3 root bin 6144 Aug 25 14:53 /usr/bin
drwxrwxr-x 7 root bin 1024 Aug 25 14:53 /usr/sbin
drwxrwxr-x 5 root bin 4096 Aug 25 14:53 /usr/lbin
PATH Environment Variable Settings (Importance: Medium)
Set the PATH in the root account’s environment-variable files
Criteria
A. In the root account’s environment-variable configuration files, “.” is absent from the PATH, or is placed at the end
Configuration Method
“.”, which means the current directory, must not be placed at the beginning or in the middle of PATH. If “.” must be used because of the application layout, move “.” to the end of the PATH environment variable
Detailed Description
If “.” (indicating the current directory) is included in the root account’s PATH environment variable, a command located in the current directory can be executed unintentionally by an authorized user of the root account.
In other words, if “.” is placed ahead of directories that contain commands, such as /usr/bin, /bin, and /sbin, then when an authorized user of the root account runs a command, a file that an unauthorized person placed illegally can be executed unintentionally, producing unexpected results.
In addition, not only “.” but also a directory created illegally by an unauthorized person can be referenced first, producing unexpected results.
Remove “.”, which represents the current directory, from the PATH environment variable in the root account’s environment-variable configuration files (.profile, .cshrc, and so on) and in “/etc/profile”.
※ Confirm with echo $PATH (applies only to the root account)
FTP (File Transfer Protocol) Access-Control File Permission Settings (Importance: High)
Remove write permission for other users on FTP access-control configuration files, which are owned by root
Criteria
A. Remove write permission for other users on /etc/ftpusers and /etc/ftpd/ftpusers, which are owned by root
Configuration Method
# chown root /etc/ftpusers # chown root /etc/ftpd/ftpusers # chmod o-w /etc/ftpusers # chmod o-w /etc/ftpd/ftpusers
※ For vsftp, the FTP access-control file is
when userlist_enable=YES in vsftpd.conf: vsftpd.userlist
when userlist_enable=NO in vsftpd.conf, or when the option does not exist: vsftpd.ftpusers
Detailed Description
If general users who are not administrators can access and change the FTP access-control configuration file, an unauthorized user can be registered through it and can connect to the server and take illegal actions, so a security incident is possible. Check that general users are prevented from modifying the FTP access-control configuration file.
root Remote Access-Control File Permission Settings (Importance: Medium)
Remove write permission for other users on the root remote access-control configuration file, which is owned by root
Criteria
A. Remove write permission for other users on /etc/security/user, which is owned by root
Configuration Method
# chown root /etc/security/user # chmod o-w /etc/security/user
Detailed Description
If general users who are not administrators can access and change the root access-control configuration file, access as root can be restricted and a service outage is possible. Check that general users are prevented from modifying the root access-control configuration file.
NFS (Network File System) Access-Control File Permission Settings (Importance: Medium)
Remove write permission for other users on the NFS access-control file, which is owned by root
Criteria
A. Remove write permission for other users on /etc/export, which is owned by root (or bin)
Configuration Method
# chown root /etc/exports # chmod o-w /etc/exports
Detailed Description
If general users who are not administrators can access and change the NFS (Network File System) access-control configuration file, an unauthorized user can be registered through it and can mount the file system and attempt illegal modification. Check that general users are prevented from modifying the NFS access-control configuration file.
/etc/services File Permission Settings (Importance: High)
Remove write permission for other users on the services file, which is owned by root
Criteria
A. Remove write permission for other users on /etc/services, which is owned by root (or bin)
Configuration Method
# chown root w /etc/services # chmod o-w /etc/services
Detailed Description
If general users who are not administrators can access and change the services file, they can restrict a legitimate service or run a service that is not allowed, creating a risk of a security incident.
Boot Script File Permission Settings (Importance: High)
Check whether access permissions are restricted on the boot script files used by the OS.
Criteria
A. Remove write permission for other users from the permissions of boot script files
Configuration Method
For boot-script-related files that are found to be vulnerable, remediate them with the command below
# chmod o-w [file name or directory name]
Detailed Description
Access permissions on boot script files that are important to system operation must allow access only by users who truly need it. If write permission for other users is granted, remove it.
- /etc/rc*.d/*
- /etc/inittab, and others
Network Services
Restricting RPC (Remote Procedure Call) Services (Importance: Medium)
Remove RPC (Remote Procedure Call) services
Criteria
A. Remove unused RPC services
- Remove RPC-related services from /etc/inetd.conf
※ RPC services used because they are required for operations are treated as exceptions
Configuration Method
<How to remove an inetd service> (1) Comment out the corresponding line in “/etc/inetd.conf” with #, then restart inetd
# vi /etc/inetd.conf (Before) rpc dgram udp wait root /usr/lib/netsvc/rstat/rpc.rstatd 100001 2-4 rpc.rstatd (After) #rpc dgram udp wait root /usr/lib/netsvc/rstat/rpc.rstatd 100001 2-4 rpc.rstatd
(2)
# ps -ef | grep inetd
root 141 1 0 15:03:22 ? 0:01 /usr/sbin/inetd -s
# kill -HUP 141
※ If the system is difficult to restart, stop the rpc.statd process
# ps –ef |grep rpc
rpc 3136 1 0 Oct11 ? 00:00:01 rpc.statd
# kill –HUP 3136
Detailed Description
An RPC (Remote Procedure Call) service is a call that accesses a server application in a distributed environment and requests a specific task. It is widely used because it makes development in a distributed processing environment easier, so Unix systems provide the service by default. However, RPC services have many remote buffer overflow vulnerabilities, so the risk of a security incident is very high.
A buffer overflow means entering more data than the size of the designated buffer so that the program operates abnormally. At the moment the buffer overflows, an arbitrary command chosen by the user can be executed, allowing various attacks such as obtaining root privileges.
The unused RPC services below must be removed. If a service is in use, the security patch appropriate to that service must be applied.
| rpc.cmsd | A database management program used by Calendar Manager in OpenWindows and by the Calendar program in CDE |
| users | Responds to queries from the rusers command |
| rstd | Returns performance statistics obtained from the kernel |
| rpc.statd | A tool that supports the lockd program provided by NFS to recover files when the system fails |
| kcms_server | APIs and libraries related to Kodak color management are used to create or manage profiles that can control the color performance of digital images on the desktop |
| rpc.ttdberverd | An RPC-based ToolTalk database server program |
| Walld | Used to send messages to other users |
| rpc.nids | NIS server Daemon |
| rpc.ypupdated | Updates information in Network Information Services (NIS) maps |
| cachefsd | Cache file system daemon |
| sadmind | A program used to administer the system from a remote location |
| srayd | Receives packets sent by the spra command, which sends a specified number of packets to a host and reports performance statistics |
| rpc.pcnfsd | Handles service requests from PC-NFS (Personal Computer Network File System) clients |
| rexd | Runs a program for a remote system |
| rpc.rquotad | Returns the quota limit on the local machine requested by the user for a file system that is NFS-mounted on the listed machine |
- Remove RPC-related services from /etc/inetd.conf
Remove services such as ttdb, cmsd, rstatd, sadmind, rusersd, rexd, rwalld, sprayd, kcms_server, and cachefsd
Restricting NFS (Network File System) (Importance: High)
Remove the NFS (Network File System) service when it is not used for a special purpose
Criteria
A. When the service is required
- Unmount systems that are not authorized
- Restrict system mounts as everyone
B. When the service is not required
- Stop the NFS daemons (nfsd, statd, lockd)
Configuration Method
<When the NFS service is required> After checking systems that are mounting NFS remotely, unmount systems that are not authorized
Check mounts (the command does not run if the NFS service is stopped)
# Run showmount -e hostname and check whether the system is mounted as everyone
# showmount Umount # umount “file system name”
If the NFS service is used, list only the shared directories that are strictly required in the “/etc/exports” file. The system must not be mounted as everyone, and NFS-related security patches must be applied
<When the NFS service is not required> Stop the NFS daemons (nfsd, statd, lockd)
# ps -ef | grep nfsd root 3809 3721 0 08:44:40 ? 0:00 /usr/lib/nfs/nfsd # ps -ef | grep statd daemon 156 1 0 May 14 ? 0:00 /usr/lib/nfs/statd # ps –ef | grep lockd daemon 749 1 0 May 27 ? 0:00 /usr/lib/nfs/lockd # kill –9 3809 # kill –9 156 # kill -9 749
2) Prevent the NFS client from starting when the system restarts
# After running vi /etc/inittab: rcnfs:a:wait:/etc/rc.nfs > /dev/console 2>&1 # Configure Start NFS Daemons: and delete the daemons # ps -ef |grep statd daemon 778396 516258 0 Jun 01 - 0:00 /usr/sbin/rpc.statd jhpark 1859662 1745028 0 16:43:09 pts/3 0:00 grep statd # ps -ef | grep lockd root 991390 516258 0 Jun 01 - 0:00 /usr/sbin/rpc.lockd jhpark 2850942 1745028 0 16:43:14 pts/3 0:00 grep lockd # ls -al /etc/rc.nfs -rwxr-xr-x 1 root system 3879 Sep 17 2002 /etc/rc.nfs
Detailed Description
NFS is designed to share a file system over a network. It is widely used by sites that provide large-capacity services, or when many service servers share the files of one server, but the risk of a security incident that uses it is high.
If it is not used for a special purpose, remove the NFS service and stop statd and lockd, which are part of the NFS service.
If the NFS service must be used, confirm that unauthorized systems do not mount the NFS system, so that access by unauthorized systems and file tampering do not occur.
Removing the Automountd Service (Importance: Low)
Remove the Automount service when it is not used for a special purpose
Criteria
A. Remove the Automount service
Configuration Method
<When the service is not required> 1) Stop the running service
# ps -ef | grep automount root 650 1 0 Mar 30 ? 0:30 /usr/lib/netsvc/fs/automount/automount -f /etc/auto_master # kill –9 650
2) Prevent automount from starting when the system restarts (the exact file location differs by OS)
# mv /etc/rc2.d/S74autofs /etc/rc2.d/_S74autofs
c. Detailed settings. Autofs lets a user on a client system mount a directory or file system on a remote system when needed, and automatically unmounts the corresponding mount point when it is not in use.
The Autofs daemon automountd handles file system mount and unmount requests from autofs through RPC, and automountd has a vulnerability that allows a local attacker to send RPC to the daemon.
Restricting NIS (Network Information Service) (Importance: High)
Remove the NIS service when it is not used for a special purpose
Criteria
A. Remove the NIS service ※ NIS services used because they are required for operations are treated as exceptions
Configuration Method
1) Stop the NIS service
# /usr/lib/netsvc/yp/ypstop
2) Remove the boot script
# cd /etc/rc*/ # mv S88ypserv _S88ypserv
Detailed Description
NIS (Network Information Service) provides administrators and users with a consistent system environment by sharing important system database files over the network. NIS+ is a later version that adds security and convenience features.
<How to check the service> Check the processes below. If a process is absent, the result is normal
| Process and daemon | Description |
|---|---|
| Ypserv | Runs on the master and slave servers and responds to ypbind requests from clients |
| Ypbind | Runs on every NIS system and binds and initializes the client and the server |
| rpc.yppasswdd | Used by users to change passwords |
| ypxfrd | Runs only on the NIS master server and transfers NIS maps at high speed |
| rpc.ypupdated | Runs only on the NIS master server and transfers NIS maps at high speed with encryption |
Removing ‘r’ commands Services (Importance: High)
Remove ‘r’ commands services when they are not used for a special purpose
Criteria
A. When the service is required
- Set the permissions of /etc/hosts.equiv and ./$HOME/rhosts to 400, owned by root
- Set a fixed IP that is allowed to access in /etc/hosts.equiv and /$HOME/.rhosts
B. When the service is not required
- Remove ‘r’ commands services such as rsh, rlogin, and rexec
- Set the permissions of /etc/hosts.equiv and /$HOME/.rhosts to 000 owned by root, or link them to /dev/null
※ The .rhosts file must be created in the root home directory
Configuration Method
<When the ‘r’ command service is required>
In /etc/hosts.equiv and $HOME/.rhosts, remove “+” from the host and account portions, and register only the required hosts and accounts, as in the example below
Example) # vi /etc/hosts.equiv ( or $HOME/.rhosts)
Wiki security
Specify the permissions and owner of “/etc/hosts.equiv” and “$HOME/.rhosts”
# chown root /etc/hosts.equiv # chmod 400 /etc/hosts.equiv # chown root /root/.rhosts # chmod 400 /root/.rhosts
※ Using a symbolic link is recommended, and changing the permissions is not required
Managing it periodically by placing it in cron is recommended, and configuring the “/etc/hosts.equiv” file as follows is recommended
# /bin/touch /.netrc /etc/hosts.equiv # /bin/chmod 400 /.netrc /etc/hosts.equiv
<When the ‘r’ command service is not required>
Remove the service and change the permissions of /etc/hosts.equiv and /$HOME/.rhosts
<Example of how to remove the service>
Comment out the corresponding line in “/etc/inetd.conf” with #, then restart inetd
# vi /etc/inetd.conf
(Before)
shell stream tcp nowait root /usr/sbin/in.rshd in.rshd
shell stream tcp6 nowait root /usr/sbin/in.rshd in.rshd
login stream tcp6 nowait root /usr/sbin/in.rlogind in.rlogind
exec stream tcp nowait root /usr/sbin/in.rexecd in.rexecd
exec stream tcp6 nowait root /usr/sbin/in.rexecd in.rexecd
(After)
# shell stream tcp nowait root /usr/sbin/in.rshd in.rshd
# shell stream tcp nowait root /usr/sbin/in.rshd in.rshd
# shell stream tcp6 nowait root /usr/sbin/in.rshd in.rshd
# login stream tcp6 nowait root /usr/sbin/in.rlogind in.rlogind
# exec stream tcp nowait root /usr/sbin/in.rexecd in.rexecd
# exec stream tcp6 nowait root /usr/sbin/in.rexecd in.rexecd
# ps -ef | grep inetd
root 141 1 0 15:03:22 ? 0:01 /usr/sbin/inetd -s
# kill -HUP 141
<Method 1 for changing the permissions of /etc/hosts.equiv and /$HOME/.rhosts>
# chown root /etc/hosts.equiv # chmod 000 /etc/hosts.equiv # chown root /root/.rhosts # chmod 000 /root/.rhosts
<Method 2 for changing the permissions of /etc/hosts.equiv and /$HOME/.rhosts>
# ln –s /dev/null /etc/hosts.equiv (after deleting the /etc/hosts.equiv file) # ln –s /dev/null /root/.rhosts (after deleting the /root/.rhosts file)
※ The .rhosts file must be created in the root home directory with root privileges, as permission 000 or as a link to /dev/null
Managing it periodically by placing it in cron is recommended, and configuring the “/etc/hosts.equiv” and “/etc/.rhosts” files as follows is recommended
# /bin/touch /root/.netrc /etc/hosts.equiv # /bin/chmod 0 /root/.netrc /etc/hosts.equiv # /bin/touch /.netrc /root/.rhosts # /bin/chmod 0 /.netrc /root/.rhosts
Detailed Description
‘r’ commands such as rsh, rlogin, and rexec allow an administrator to connect remotely without authentication. They are sometimes used for NET Backup or other purposes, but use of ‘r’ commands is very weak from a security standpoint, and if the service port is open there is a risk of a security incident.
If they are not used for a special purpose such as NET Backup, remove the services below.
| shell(514) | login(513) | exec(512) |
If the service must be used, allow access only to the servers that truly need it, and set the permissions of the related configuration files appropriately.
- Remove Berkeley R-Command services from /etc/inetd.conf
: Remove the rsh, rlogin, and rexec services
The “/etc/hosts.equiv” file registers TRUSTED systems and allows access without authentication using ‘r’ commands. The “.rhosts” file performs almost the same function as “/etc/hosts.equiv”, but “.rhosts” can be configured so that a connection through ‘r’ commands is possible per user.
If an ‘r’ command is used, carefully list only specific servers. Allowing every server to access, as with “+”, is very dangerous from a security standpoint, so configure it with care.
If it is used, carefully list only specific servers. Allowing every server to access, as with “+”, is very dangerous, so configure it with care.
If it is used, set it to “400” owned by root.
- Do not set ‘+’ in the /etc/hosts.equiv file
: when the file is not used, permission 000 or a link to null : when the file is used, owner: root, permission: 400
+ + : trust every account on every host + wiki : trust the wiki account on every host Wiki + : trust every account on the Wiki host
Removing Unnecessary Services (Importance: Medium)
Remove services that are unnecessary from a security standpoint
Criteria
A. Stop unnecessary services
Configuration Method
<Example of how to remove a service>
- Comment out the corresponding line in “/etc/inetd.conf” with #, then restart inetd
- Completely delete unnecessary services from the boot script
# vi /etc/inetd.conf (Before) echo stream tcp6 nowait root internal (After) # echo stream tcp6 nowait root internal # ps -ef | grep inetd root 141 1 0 15:03:22 ? 0:01 /usr/sbin/inetd -s # kill -HUP 141
If a service must be used, in the short term strengthen access control first on network equipment and the firewall, and in the long term re-examine whether providing the service is justified and change the application (change the procedure call that uses the service)
Detailed Description
If unnecessary service ports are open on the server, important system information can be exposed and a denial of service (DoS) can be caused.
Remove the unused services below.
| echo(7) | Simply retransmits messages sent by the client |
| chargen(19) | A service that returns a string of arbitrary length |
| finger(79) | Displays user information |
| nntp(119) | NNTP (Network News Transfer Protocol), a standard service that can create discussion groups on the Internet |
| netbios_dgm(138) | NetBIOS Datagram service, used to broadcast to a host, a group, or everyone |
| ldap(389) | A service for accessing a directory service |
| ntalk(518) | A service that enables chat between different systems |
| ldaps(636) | LDAP over SSL |
| nfsd(2049) -When NFS is not used | NFS server daemon service |
| discard(9) | A service that discards data received from an arbitrary user |
| time(37) | The TCP version of the RFC 868 time server used by the rdate daemon |
| sftp(115) | ftp over SSH |
| ntp(123) | ntp (Network Time Protocol) synchronizes the time of the client and the server |
| netbios_ssn(139) | NetBIOS session service, used to send and receive actual data through network shares and similar means |
| printer(515) | Used for spooling on a remote printer |
| uucp(540) | Copies files between different Unix systems and sends commands to be executed on another system |
| ingreslock(1524) | Ingre database lock service |
| dtspcd(6112) | Desktop subprocess control daemon service |
| daytime(13) | daytime is a daemon that prints the current time and date in ASCII form in response to a client query |
| tftp(69) | A protocol for file transfer. On an OS, the tftp protocol is used to download configuration files and start the installation process for workstations without a boot diskette or for network-aware printers |
| uucp-path(117) | UUCP path service |
| netbios_ns(137) | NetBIOS name service, used to identify resources on the network |
| bftp(152) | binary File Transfer Protocol |
| talk(517) | A user connects to the system remotely and starts a conversation session with a user who is logged in on another system |
| pcserver(600) | ECD Integrated PC board srvr, used in RPC-related attacks |
| www-ldap-gw(1760) | HTTP to LDAP gateway, used when LDAP sends database information to the web server |
Service Banner Management (Importance: Medium)
Configure the banner displayed when general services (TELNET, FTP, SMTP, and so on) are accessed on the system
Criteria
A. When Telnet, FTP, SMTP, and DNS services are used, display a warning in the connection banner and prevent information disclosure
Configuration Method
[Telnet Banner]
- Banner configuration
# vi /etc/security/login.cfg
Add herald = "\n Authorized users only. \n login: " at the end of the default: line
Example)
default:
sak_enabled = false
logintimes =
logindisable = 0
logininterval = 0
loginreenable = 0
logindelay = 0
herald = "\n Authorized users only. \n login: "
- Remove the hostname
Edit the /tmp/telnetd.msg file
# dspcat -g /usr/lib/nls/msg/en_US/telnetd.cat > /tmp/telnetd.msg # Run vi /tmp/telnetd.msg On the telnet (%s)\r\n" line, remove %s and change it to telnet ()\n\n" # gencat /tmp/telnetd.cat /tmp/telnetd.msg # cp -p /tmp/telnetd.cat /usr/lib/nls/msg/en_US/telnetd.cat
[FTP Banner]
- Banner configuration / remove the hostname
Edit the ftpd.cat file
# dspcat -g /usr/lib/nls/msg/en_US/ftpd.cat > /tmp/ftpd.msg # Edit line 9 of vi /tmp/ftpd.msg as follows (remove %s) (Before) "(%s) FTP server (%s) ready. " (After) FTP Server (Unauthorized Access Prohibited.) ready # gencat /tmp/ftpd.cat /tmp/ftpd.msg # cp -p /tmp/ftpd.cat /usr/lib/nls/msg/en_US/ftpd.cat
[SMTP Banner]
# vi /etc/mail/sendmail.cf # SMTP initial login message (old $e macro) (Before) O SmtpGreetingMessage=$j Sendmail $v/$Z; $b (After) O SmtpGreetingMessage= WARNING:Authorized use only
※ The location of sendmail.cf may differ depending on the SMTP configuration
[DNS Banner]
# vi /etc/named.conf version "Contact Another Administrator!";
Detailed Description
Manage the banner displayed when general services (TELNET, FTP, SMTP, and so on) are accessed on the system, in order to prevent disclosure of the service version.
- State the range of server users, and indicate that all activity is being monitored
- Delete the default banner, or insert a warning message, in each daemon configuration file
- Configure the banner so that the version of the process and the system hostname are not disclosed
Session Timeout Settings (Importance: Low)
Configure the server to disconnect a connected session if it is not used for a specified time
Criteria
A. Apply a session timeout setting in the /etc/profile file
Configuration Method
1) For sh (Bourne shell) and ksh (Korn shell), edit /etc/profile or .profile and insert TMOUT=300, export TMOUT # vi /etc/profile
(After) TMOUT = 300
export TMOUT
2) When using the csh or tcsh shell (unit: minutes)
# After running vi /etc/.login, apply the following set autologout=5
Detailed Description
If a timeout is not set for unused sessions, problems can occur not only for confidentiality but also for availability.
It is necessary to configure the server to disconnect a connected session if it is not used for a specified time. (Timeout after 300 seconds)
Restricting telnet and ssh Access for the root Account (Importance: High)
Restrict direct telnet and ssh access with the root account
Criteria
A. Restrict connection as the root account for telnet and ssh connections
Configuration Method
[telnet]
# Edit the /etc/security/user file as follows root: rlogin = false
[ssh]
# Edit the /etc/ssh/sshd_config file and then restart sshd PermitRootLogin no
※ If the PermitRootLogin entry does not exist, create it
Detailed Description
Direct access with the root account is dangerous from a security standpoint, so direct remote connection of the root account must be restricted. For security, set the options below so that a switch to the root account is made through a general user.
Applying Firewall Policy (Importance: High)
Apply a firewall policy to block external attacks
Criteria
A. The firewall can be opened after the security assessment request is completed ※ However, Any Open can be opened only after security vulnerabilities have been remediated
Configuration Method
A. Before the service is opened, complete the security assessment request through ISS-D
Detailed Description
When a new service is opened, the firewall can be opened only after the security assessment request is completed. Any Open (including internal-network Any Open and opening many IPs on the external network) can be opened on the firewall only after vulnerabilities found in the security assessment have been remediated.
Log Management
System Log Settings (Importance: High)
Check su logging and syslog settings, and the permissions of log files and directories
Criteria
A. su logging records
- /etc/pam.conf settings
B. syslog.conf log settings
- *.notice, *.alert, *.emerg
C. Permission settings for log files and directories
- Remove write permission for other users, with ownership by root (or bin)
※ All items A, B, and C must be applied
Configuration Method
1. su log settings
# Change the settings of vi /etc/pam.conf # # AIX su configuration # su auth sufficient /usr/lib/security/pam_allowroot su auth required /usr/lib/security/pam_aix su account sufficient /usr/lib/security/pam_allowroot su account required /usr/lib/security/pam_aix su session required /usr/lib/security/pam_aix su password required /usr/lib/security/pam_aix
2. syslog settings 1) # Check the vi /etc/syslog.conf file
- .notice /var/log/syslog.log
- .alert /dev/console
- .emerg *
2) After editing the /etc/syslog.conf file as above, refresh syslogd with the command below so that the change is applied
# Use refresh –s syslogd or the kill –HUP command # ps –ef | grep syslogd root 7524 6970 0 Apr 23 - 0:02 /usr/sbin/syslogd # kill –HUP 7524
3. Log file permission settings
- For the log file permissions below, remove write permission for other users from the system user owner (root, adm, bin, and so on)
<Targets for strengthened security>
| Log file | (Redhat) Linux |
|---|---|
| wtmp, utmp | /var/log(wtmp) /var/run(utmp) |
| btmp | /var/log/ |
| pacct | /var/log/ |
| messages | /var/log/ |
| lastlog | /var/log/ |
| Other | /var/log/secure |
# chown root [log file name] # chmod o-w [log file name]
To change the permissions with which the /var/adm/message file is created, edit the /usr/lib/newsyslog file
# vi /usr/lib/newsyslog (Before) chmod 644 $LOG (After) chmod 640 $LOG
Detailed Description
1. su log settings
A security setting is required so that su usage is logged, in order to leave a record of use from a general user to superuser. If an incident occurs that compromises system availability, integrity, and similar properties, the incident generally proceeds with superuser privileges, so logging of su is required.
The syslog configuration file must be edited so that su logs are recorded, and logs related to auth.notice must be written to a file.
2. syslog settings
Check that the security settings of the “syslog.conf” file are in place so that records of info, alert, and similar events that occur during system operation are left by default.
The syslog daemon is a dedicated daemon that records system logs. It monitors kernel messages and system logs of remote or local systems. If the settings are not correct, appropriate logs are not left in the system log file, and an intruder’s traces or system errors cannot be analyzed.
3. Log file permission settings
There is no need to grant general users other than the administrator permission to read the system’s basic logging records. Security must be strengthened by restricting the owner and read permissions of the files that store logging records.
Log Retention Period (Importance: High)
Apply the minimum log retention period specified by law
Criteria
A. Apply the minimum retention period for log files B. Regularly review and supervise log records C. Back up log files to a separate storage device and restrict write permission
Configuration Method
The retention period for log files can be adjusted according to the business environment, but under the Act on Promotion of Information and Communications Network Utilization and Information Protection, the Personal Information Protection Act, company regulations, and similar requirements, they must be retained for at least the periods below
1) User access information records
User login, logout, and information changes: at least 6 months
2) Access records of personal information handlers on the personal information processing system
Data subject identification information, personal information handler identification information, access date and time, access location information, duties performed according to the type of privilege granted, and so on: at least 2 years
3) Records of changes to personal information handler privileges
Creation, change, and deletion of personal information handler privileges: at least 3 years
The responsible person must regularly review and supervise log records so that, if an error or misconduct related to user access occurs or is expected, it is reported and acted on immediately
To prevent log files from being tampered with or forged, it is preferable to keep a backup on a separate storage device and to store them with write permission restricted. Even if modification is otherwise possible, a separate protective measure can be taken using information that can confirm whether tampering or forgery occurred (an HMAC value or a digital signature value)
Detailed Description
Under the Act on Promotion of Information and Communications Network Utilization and Information Protection, the Personal Information Protection Act, company regulations, and similar requirements, log files must be retained for at least 6 months, and the responsible person must regularly back up, review, and supervise log records.
Major Application Settings
Restricting FTP (File Transfer Protocol) Service Users (Importance: High)
Whether the FTP service is used, and, when it is used, the user UMASK and Anonymous FTP settings
Criteria
A. Restrict the FTP service for root and unnecessary accounts B. Set the FTP UMASK to ‘077’ C. Restrict Anonymous FTP
※ Items A, B, and C must all be applied
Configuration Method
1. Restrict FTP use by root and unnecessary accounts. Check whether FTP use by root and unnecessary system accounts is restricted. Configuration files: /etc/ftpusers, /etc/ftpd/ftpusers
- Add the root account and system accounts to the /etc/ftpusers file to restrict FTP login
# vi /etc/ftpusers
root … (Example of how to restrict the FTP service) # Run echo root >> /etc/ftpusers Open “/etc/ftpusers” with vi and insert root
- When vsftp is used
When userlist_enable=YES in vsftpd.conf: put the root account in /etc/vsftpd/user_list or /etc/vsftpd.user_list (if there is a # in front of root, remove it)
When userlist_enable=NO in vsftpd.conf, or when the option does not exist: put the root account in /etc/vsftpd/ftpusers or /etc/vsftpd.ftpusers (if there is a # in front of root, remove it)
- When Proftpd is used
Configure the following in the /usr/local/proftpd/etc/proftpd.conf file
(The path of the proftpd.conf file may differ)
RootLogin off
2. FTP UMASK restriction
# Run vi /etc/inetd.conf and edit it as follows ftp stream tcp6 nowait root /usr/sbin/ftpd ftpd -u 077 (-u : option that sets umask)
3. Anonymous FTP restriction
- Check whether the ftp account has been deleted from the /etc/passwd file, and delete it if it is present
# cat /etc/passwd | grep ftp
# cat /etc/shadow | grep ftp # userdel ftp
- When vsftp is used
# Edit the /etc/vsftpd/vsftpd.conf file as follows
anonymous_enable=NO # service vsftpd restart
Detailed Description
1. Restrict FTP use by root and unnecessary accounts
FTP is a program for exchanging files between computers connected over the Internet or an internal network. It is usually arranged so that an FTP server is operated on the server and clients can receive the FTP service. Because of bugs and risks in the FTP server itself, use of the FTP server must be restricted except when it is strictly necessary.
If the FTP service is used, high-privilege accounts must not be able to use FTP, which reduces the risk associated with system operation.
2. Set the FTP UMASK to ‘077’
Check that the access permissions of files transferred using FTP are set appropriately.
If the FTP UMASK is misconfigured, anyone can delete and modify files created using FTP.
3. Anonymous FTP restriction
If Anonymous FTP is used, an unauthorized person can obtain information about the system. If write permission is set on a directory, various attacks are possible using a local exploit.
Configure the system so that only users who are strictly necessary can connect. This is also preferable from the standpoint of system availability.
SNMP (Simple Network Management Protocol) Service Settings (Importance: High)
Check the SNMP service and configure Community String security
Criteria
A. When the service is required
- The SNMP Community String is not public or private (an SNMP BruteForce Attack or SNMP Dictionary Attack is possible, so it must be set in a strong password form of at least 8 characters, mixing digits and symbols)
B. When the service is not required
- Stop the service and configure it so that the service does not run when the system restarts
Configuration Method
<When the SNMP service is required>
- The community string in the /etc/snmpd.conf file needs to be changed to a difficult value
Change public in the ‘read-community public’ section to <an arbitrary name> and then restart the service. Caution is required when the ‘set-community-name:’ section is used (easy community names such as public, admin, and private are restricted)
<When SNMP is not required>
# ps -ef | grep snmp root 9546 6970 0 Dec 05 - 1:11 /usr/sbin/snmpd # kill –9 9546 or # /usr/sbin/snmpd stop # Run vi /etc/rc.tcpip and comment out the following line (Before) start /usr/sbin/snmpd "$src_running" (After) # start /usr/sbin/snmpd "$src_running"
Detailed Description
The SNMP service is provided by default on UNIX systems for an NMS that determines system status in real time. The Community String, a kind of password for receiving that information, is often set to the default values public and private. If it is not changed, an unauthorized user can abuse this string and determine the system’s important information and configuration. That vulnerability exists.
If the server does not use the SNMP service, that is, if the NMS does not monitor that server, it is preferable to remove the SNMP service.
When the SNMP service is used, the community string in the “/etc/snmpd.conf” file needs to be changed to a difficult value.
- When the SNMP service is not used, or when the Community String is not public or private
An SNMP BruteForce Attack or SNMP Dictionary Attack is possible, so it must be set in a strong password form of at least 8 characters, mixing digits and symbols
SMTP (Send Mail Transfer Protocol) Service Settings (Importance: Medium)
Whether the SMTP service is used, and its settings
Criteria
A. When the service is required
- How to prevent Sendmail abuse, and restrict use of the q option by general users
- Use Sendmail 8.14.4 or later
B. When the service is not required
- Stop the service and configure it so that the service does not run when the system restarts
Configuration Method
<When the SMTP service is required> (1) How to prevent Sendmail abuse, and restrict use of the q option by general users
- Configure VRFY and EXPN, which are basic Sendmail services, as follows, and restrict the q option
# Edit the /etc/mail/sendmail.cf file as follows
O PrivacyOptions=authwarnings, noexpn, novrfy, restricqrun
(2) Restrict use of a vulnerable Sendmail version
1) Check whether the Sendmail service is running
# ps –ef | grep sendmail
2) Check the Sendmail version
# telnet localhost 25
3) Check the Sendmail version, and ftp://ftp.sendmail.org/pub/sendmail confirm whether a security patch exists
4) The configuration method may differ by OS, so on the website (http://www.sendmail.org/) check the information for the relevant OS and then upgrade
<When the SMTP service is not required>
# ps –ef | grep sendmail root 441 1 0 Sep19 ? 00:00:00 sendmail: accepting connections # kill -9 441
To prevent the SMTP server from starting when the system restarts, do the following
# Run vi /etc/rc.tcpip and comment out the following line
(Before) start /usr/lib/sendmail "$src_running" "-bd -q${qpi}"
(After) # start /usr/lib/sendmail "$src_running" "-bd -q${qpi}"
Detailed Description
SMTP includes many security vulnerabilities and potential risks exist. Review the purpose of using SMTP on the server, and if there is no need to use it, it is preferable to remove the service.
When operating the SMTP service, VRFY and EXPN, which are basic Sendmail services, must be blocked to prevent Sendmail abuse. Execution of Sendmail by general users with the q option must also be prevented, so that they cannot view the mail queue contents and the Sendmail configuration, or forcibly drop the mail queue.
In addition, most vulnerabilities in Sendmail were found in versions 8.13.8 and earlier, so version 8.14.4 or later is recommended. The following are recent Sendmail vulnerabilities, and systems using a vulnerable version need to be upgraded.
SSL Certificate NULL Character Spoofing (CVE-2009-4565) vulnerability: versions earlier than 8.14.3
Heap-based buffer overflow (CVE-2009-1490) vulnerability: versions earlier than 8.13.1.2
If it is not used for a special purpose, remove the SMTP service.
- Confirm that the latest Sendmail version and settings are applied
① Remove the vrfy and expn commands, and prevent execution by general users using the q option
② Use Sendmail 8.14.4 or later
③ Restrict the mail relay function
④ A patch for the Address Parser vulnerability is required
※ The location of sendmail.cf may differ depending on the SMTP configuration
DNS (Domain Name Service) Security Settings (Importance: Medium)
Whether the DNS service is used, and its settings
Criteria
A. When the service is required
- Restrict IP addresses so that transfer is possible only to specific servers
- Update to BIND 9.9.2-P1 or a later current version is recommended
B. When the service is not required
- Stop the service and configure it so that the service does not start when the system restarts
Configuration Method
<When the DNS service is required>
<Example of editing BIND 8 DNS settings (/etc/named.conf)>
options {
allow-transfer {IP addresses to which zone file transfer is to be allowed;};
};
<Example of editing BIND 4.9 DNS settings (/etc/named.boot)>
Options xfrnets IP addresses to be allowed
<When the service is not required>
1) Stop the running service
# ps -ef | grep named root 279 1 0 Sep 22 ? 1:17 /usr/sbin/in.named # kill -9 279
2) Prevent the DNS server from starting when the system restarts
# Run vi /etc/rc.tcpip and edit it as follows (Before) start /usr/sbin/named "$src_running" (After) # start /usr/sbin/named "$src_running"
Detailed Description
In general, zone transfer is performed so that the zone information of the primary name server and the secondary name server stays consistent, so it is sufficient to allow zone transfer only to the secondary name server.
If zone transfer is allowed to a user who is not permitted, an attacker can use the received zone information to determine a great deal of information, such as host information and the form of the network configuration. If a DNS server is installed with the defaults, any user is allowed to perform zone transfer.
If the default configuration is used as-is after the initial system installation, the DNS service may be running even though the DNS service is not used. Unnecessary DNS services must be removed.
If the DNS service is used, DNS settings must be changed so that internal zone files cannot be transferred by an arbitrary external server and so that just anyone cannot receive query responses, and a version patch for security must be applied.
BIND (Berkeley Internet Name Domain) has almost every vulnerability in versions BIND 9.9.2-P1 and earlier.
Because security and system update support for ISC BIND 8 ended on 2007.8.27, an upgrade to BIND 9 is recommended in order to prepare for security vulnerabilities that may arise later and to improve system performance.\\(https://www.isc.org/downloads/all)
- Almost every version of BIND is vulnerable, so an update to BIND 9.9.2-P1 or later is required
- The following are recent BIND vulnerabilities. Systems using a vulnerable version need to be upgraded
Denial-of-Service (CVE-2009-4022) vulnerability: versions earlier than 9.6.0
If it is not used for a special purpose, remove the DNS service.
SWAT (Samba Web Administration Tool) Security Settings (Importance: High)
Whether the SWAT service is used, and its settings
Criteria
A. Remove the SWAT service
※ Treated as an exception when port 901 is filtered using an intrusion prevention system
Configuration Method
<When the SWAT service is required>
If an intrusion prevention system is used, contact the intrusion prevention system administrator and filter port 901 so that SWAT access from the external network is blocked. This is recommended
<When the SWAT service is not required>
1) If SWAT does not need to be used, stop it as follows
# Run vi /etc/inetd.conf and edit the contents as follows (Before) swat stream tcp nowait.400 root /usr/sbin/swat swat (After) #swat stream tcp nowait.400 root /usr/sbin/swat swat
2) Restart inetd
# ps -e | inetd.conf 538 ? 00:00:00 inetd # kill -HUP 538
Detailed Description
SWAT (Samba Web Administration Tool) prints different messages, as follows, when an incorrect user or password is entered.
When the user ID is correct and only the password is wrong: 401 Authorization Required. You must be authenticated to use this service. When both the user ID and the password are wrong: 401 Bad Authorization username/password must be supplied
Using these different messages, a brute-force attack that systematically tries user IDs and passwords can determine the user ID from the message.
Samba Version Vulnerabilities (Importance: High)
Whether the Samba service is used, and its version
Criteria
A. When the service is required
- Upgrade to version 4.0.1
B. When the service is not required
- Remove the service
Configuration Method
<When the Samba service is required>
When it is used for the service, upgrade to version 3.6.2
<When the Samba service is not required>
1) If Samba does not need to be used, stop it as follows
# ps –ef | grep smb 538 ? 00:00:00 smbd # kill -9 538
2) Delete the boot script
# mv /etc/rc3.d/S90samba /etc/rc3.d/_S90samba
Detailed Description
Many vulnerabilities have been found in the Samba server. If a lower version of Samba is used, it can become a target of brute-force attacks, buffer overflow attacks, and similar attacks.
- Most Samba vulnerabilities were found in versions 3.4 and earlier. As of the current baseline (2012.11), Samba 4.0.1 is the latest version, so Samba 4.0.1 or later is recommended
- The following are recent Samba vulnerabilities. Systems using a vulnerable version need to be upgraded
Samba Information Disclosure and Denial of Service (CVE-2009-2906) vulnerability: versions earlier than 3.4
※ Patches are provided for vulnerable Samba versions, so applying the patch for the vulnerability is recommended (http://www.samba.org/samba/history/security.html)
SSH (Secure Shell) Version Vulnerabilities (Importance: Medium)
Check the version according to whether openSSH is used
Criteria
A. When the service is required
- Install and operate the latest version of SSH (openSSH 6.1 as of 2012.11)
B. When the service is not required
- Remove the running SSH service
Configuration Method
<When the service is required>
1) Installing and operating the latest version of SSH is recommended
The latest SSH version as of the current baseline (2012.11) is openSSH 6.1, and openSSH 6.1 or later is recommended (openSSH can be downloaded from http://www.openssh.org)
<When the service is not required>
1) Stop the running service
# ps –ef | grep sshd root 414 0.0 0.7 2672 1692 /usr/sbin/sshd # kill -9 414
2) Rename the startup script file so that SSH does not start (the startup script location differs by OS)
# ls –al /etc/rc*.d/* | grep sshd (check the startup script file location) # mv /etc/rc2.d/S55sshd /etc/rc2.d/_S55sshd
※ The location of /etc/ssh/sshd_config may differ depending on the SSH configuration
Detailed Description
SSH is an open source program that implements the SSH (Secure Shell) protocol. It replaces telnet, ftp, rlogin, rsh, and similar tools, and encrypts network traffic so that important data can be protected from attacks such as packet sniffing.
However, many vulnerabilities have been found in lower versions of SSH. Because of these vulnerabilities, it can become a target of various attacks, such as obtaining root account privileges and DoS attacks.
- The following are SSH vulnerabilities. Systems using a vulnerable version need to be upgraded
Plaintext Recovery Attack Against SSH vulnerability: versions earlier than 5.1
X11UseLocalhost=no hijacking attack (CVE-2008-1483) vulnerability: SSH versions earlier than 5.0
x-server Connection Restriction Settings (Importance: High)
Restrict x-server connections to the target system from an arbitrary host
Criteria
A. Remove x-server connection settings such as ‘xhost +’ from every user’s automatic startup files
Configuration Method
Remove every command such as ‘xhost +’ from every user’s automatic startup files (.login, .profile, .cshrc, .xinitrc, .xsession, and so on)
Detailed Description
GUI programs on Unix systems run on the basis of X-Window. If a system that uses this X-Window allows a connection to the target system’s X-Server from an arbitrary host, an attacker can connect to the target system’s X-Server and then do the following.
- It is possible to read various information that the user types (for example, a password) from the keyboard
- It is possible to see all information output to the screen
- Arbitrary information can be output to the screen
- An arbitrary application can be started or stopped
- The user’s session can be controlled
Security Patches
Applying Security Patches (Importance: Medium)
Apply security patches periodically to prevent server compromise
Criteria
A. Apply the latest security patches and patches in which bugs have been fixed
Configuration Method
Check the list of patches applied to the server with “instfix -iv | grep ML”
For version 4.3, the patch version can be downloaded from the site below by the following method
http://techsupport.services.ibm.com/ The desired ML level can be found, current is registered as the current version level, and update to selects the latest target patch version
<Example of applying a patch> Click on the package name below. Put the package (a tar.gz file) in /usr/sys/inst.images Extract the filesets from the package. cd /usr/sys/inst.images gzip -d -c 4330910.tar.gz | tar -xvf - Back up your system. Install the package by creating a table of contents for install to use. Then update the install subsystem itself. Run SMIT to complete the installation. inutoc /usr/sys/inst.images installp -acgXd /usr/sys/inst.images bos.rte.install smit update_all Reboot your system. This maintenance package replaces critical operating system code.
- Sites related to security patch checks
http://www-912.ibm.com/eserver/support/fixes/
Securing security and system stability through periodic patch application is an important element of system operation. For a system that is in service, applying many patches is very difficult because of problems that follow patch application (unexpected stoppage of applications currently in operation, bugs in the patch itself, and so on) and the difficulty of rebooting, so many factors must be considered when a patch is applied.
It is preferable to apply patches periodically for the security and safety of the system. However, after considering the items below, and after sufficient review by an OS vendor engineer, the patch must be applied under the work of the OS vendor engineer when it is judged that there is no effect on the services running on the server.
| No | Items to consider and observe when applying a patch |
|---|---|
| 1 | The OS vendor reviews the effect the patch can have on the system itself, and the patch is applied when there is no problem |
| 2 | The OS vendor and the developers of the service program (that is, the application) together review the effect the patch can have on service programs running on the system, and the patch is applied when there is no problem |
| 3 | In preparation for an unexpected service stoppage after the patch is applied, a rollback and emergency recovery procedure must be established and tested before the patch work is carried out |
| 4 | Perform a full backup of the system before and after the patch is applied |