1. Account Management
Deletion of Default Accounts (Priority: High)
Delete system default accounts and unused accounts.
Criteria
A. Delete default accounts (lp, uucp, nuucp).
B. Delete accounts for resigned, transferred, on-leave, or contract-terminated employees.
※ Both items A and B must be applied.
Configuration Method
# userdel lp # userdel uucp # userdel nuucp
Detailed Description
Identify and delete default accounts not used by the system and suspicious or unusual accounts. Accounts that are certainly not used by most systems, as listed below, and any suspicious accounts must be deleted. (In principle, if account creation is unavoidable for server testing or specific tasks, the account should be deleted immediately after the work is completed.)
Generally, system accounts that do not require login should be prohibited from logging in by referring to the “Shell Restriction for Accounts Not Requiring Login (Priority: Medium)” item. Accounts generated by default during OS or package installation often use default passwords, which can be exploited for password guessing attacks.
- Delete accounts of resigned, transferred, on-leave, or contract-terminated employees.
- Delete
lp,uucp,nuucp, suspicious unusual accounts (e.g.,guest,test), and unused accounts. - Modifying the login shell to
/bin/falsemay still cause security issues, so deletion is recommended.
Root Privilege Management for General Accounts (Priority: High)
Check for general accounts that possess root privileges.
Criteria
A. Set the UID of general accounts (excluding the root account and group) to 100 or higher.
Configuration Method
Execute # vi /etc/passwd and modify the UID of any general account with a UID of 0 to 100 or higher.
Example: To change the UID of the wiki account to 2002: # usermod –u 2002 wiki
Detailed Description
System administrators should regularly inspect and delete directories and files of all suspicious accounts, including the root account. It is necessary for security to periodically investigate and remove unnecessary user accounts.
- Check if there are other general accounts with
rootprivileges. - If a UID overlaps with
root(0), another user can use administrator privileges. Overlapping UIDs between users make audit tracking difficult and cause overlapping user permissions. - If the UID of a general account (excluding
root) is0, delete it or assign an appropriate UID (change to a number above100). Register general accounts belonging to therootgroup into a group with appropriate permissions. - System accounts (
daemon,bin,adm,uucp,nuucp,lp,hpdb, etc.) are excluded.
<Distinguishing General Accounts and Directories – From /etc/passwd file content> The following is a sample of the /etc/passwd file. The field separator is :, and if the third field is 0, it has superuser privileges. Accounts with a UID other than 0 are considered general accounts, and the sixth field is the home directory of that account.
root:!:0:0::/:/bin/ksh
daemon:!:1:1::/etc:
bin:!:2:2::/bin:
sys:!:3:3::/usr/sys:
adm:!:4:4::/var/adm:
lpd:!:9:4294967294::/:
<passwd file fields>
loginID:x:UID:GID:comment:home_directory:login_shell
/etc/passwd File Permission Settings (Priority: High)
Check the permissions of the /etc/passwd file, which contains system user account information.
Criteria
A. Set the permissions of the /etc/passwd file to 644 or lower, owned by root.
Configuration Method
# chmod 644 /etc/passwd # chown root /etc/passwd
# chmod 400 /tcb/files/auth/계정이니셜/계정명 # chown root /tcb/files/auth/계정이니셜/계정명
# chmod 400 /etc/shadow # chown root /etc/shadow
Detailed Description
The /etc/passwd file contains account information necessary for system user authentication. This diagnosis assesses the risk of security incidents (such as obtaining general user or root privileges) that may arise due to issues like incorrect file permission settings or management errors.
<Standard Mode>
- Set the permissions of the
/etc/passwdfile to644, owned byroot.
<Trusted Mode>
- Set the permissions of the
/etc/passwdfile to644, owned byroot. - For files under
/tcb/files/auth/[initial]/[username], set the permissions of loggable accounts (excluding system accounts) to400, owned byroot.
<Shadow Password>
- For HP-UX 11.11, the
shadowfile is created by runningpwconvafter installing the Shadow Password Bundle. - For HP-UX 11.23, the Shadow Password product is installed by default.
- Set the permissions of the
/etc/shadowfile to400, owned byroot.
※ Reference site: https://h20392.www2.hp.com/portal/swdepot/displayProductInfo.do?productNumber=ShadowPassword&lc=EN_US
/etc/group File Permission Settings (Priority: High)
Check the permissions of the /etc/group file, which contains information about user groups.
Criteria A.
Set the permissions of the /etc/group file to 644 or lower, owned by root (or bin).
Configuration Method
# chmod 644 /etc/group # chown root /etc/group
Detailed Description
If a general user accesses and modifies the group file, an unauthorized user can be registered to the root group, enabling them to obtain root privileges. You must check whether modification of the group file is restricted for general users and ensure that write permissions for other users are limited.
Applying Password Usage Rules (Importance: High)
Prohibit the use of weak passwords when setting passwords for user accounts (both root and general accounts).
Criteria
A. Password Usage Rule Configuration
- When Identity Management solutions (Control-SA, RedOwl) are running:
Password rules are managed automatically by the solution. - When solutions are NOT running:
Configure minimum length, maximum/minimum usage period, and account lockout thresholds.
# Edit /etc/login.defs to apply the following (Unit: Days):
PASS_MIN_LEN 8 PASS_MAX_DAYS 70 PASS_MIN_DAYS 7
B. Password Settings
- Combination rules: At least 8 characters with a mix of 2 types (letters/numbers/special chars) OR at least 10 characters with a mix of 3 types.
※ Note: Both items A and B must be applied.
Configuration Method
[Security Application 1] When Identity Management Solutions are running
- Control-SA: Rules are applied (currently requiring at least one letter, number, and special character).수문자 1자 이상 사용하도록 되어 있음)
→ Check 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
- RedOwl: Rules are applied.
→ Check 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 Application 2] When Identity Management Solutions are NOT running
1. Minimum Password Length
Check if a minimum password length is set to avoid password-guessing attacks. If it is not set or is set too short, malicious users can easily guess passwords due to the use of weak credentials.
2. Maximum Password Usage Period
Check password date limits to prevent an environment where an unauthorized user who obtained a password through an arbitrary path can reconnect at any time.
3. Minimum Password Usage Period
Check password date limits to prevent an environment where an unauthorized user who obtained a password through an arbitrary path can reconnect at any time.
4. Remember Previous Passwords
Prohibit the reuse of previously used passwords by remembering them when a password change occurs.
- Recommended minimum password length: 8 characters or more.
- Recommended maximum password usage period: 70 days (10 weeks) or less.
- Recommended minimum password usage period: 7 days (1 week) or more.
- Recommended password history depth: at least 12 previous passwords.
5. Account Lockout Threshold
If an account lockout threshold is not set, there is a possibility that an attacker can obtain a user’s password without much effort through Brute-Force attacks using automated tools.
- Allow only up to 10 login failures; the account is locked upon the 10th failure.
<Account Lockout Threshold Setting, applicable to HP-UX 11.v3 or higher>
Run # vi /etc/default/security and apply the following settings (Unit: Attempts): AUTH_MAXTRIES=10
<Standard Mode>
1) Run # vi /etc/default/security and apply the following settings:
MIN_PASSWORD_LENGTH=8 PASSWORD_MAXDAYS=70 PASSWORD_MINDAYS=7 PASSWORD_HISTORY_DEPTH=12
2) To unlock a locked account, log in as root and execute the following command:
# userdbset –d –u username auth_failures
<Trusted Mode>
1) Run # /usr/sbin/sam and check the following (Navigate using the Tab key):
(1) Check the following in Auditing and Security → System Security Policies → Password Format Policies:
- Ensure Allow Null Passwords is unchecked.
- Ensure Use Restriction Rules is checked.
(2) Check the following in Auditing and Security → System Security Policies → Password Aging Policies:
- Password Aging : Enable
- Time Between Password Changes (days) : 7
- Password Life Time (days) :70
(3) Run # vi /etc/default/security and apply the following settings:
MIN_PASSWORD_LENGTH=8 PASSWORD_HISTORY_DEPTH=12
2) To unlock a locked account, log in as root and execute the following command:
# audusr –d –u username auth_failures
Detailed Description
When setting passwords for user accounts (both root and general accounts), if easily guessable passwords are used, unauthorized users may gain access to the system by obtaining general account or root privileges. If passwords are set differently from the criteria below, they must be changed according to the password policy.
<Password Configuration Criteria>
1. Passwords must be composed of a combination of at least 2 types of the 4 character types listed below with a minimum length of 10 characters, or a combination of at least 3 types with a minimum length of 8 characters.
Character Types:
- Uppercase letters (26)
- Lowercase letters (26)
- Numbers (10)
- Special characters (32)
<Design Requirements to Prevent Guessing by Unauthorized Persons>
- Prohibit the use of Null passwords.
- Prohibit compositions consisting of only letters or only numbers.
- Prohibit passwords identical to the User ID.
- Prohibit the use of sequential characters or numbers (e.g., 1111, 1234, abcd).
- Prohibit the reuse of cyclic passwords.
- Prohibit the use of easily guessable information such as phone numbers, birthdays, account names, or hostnames.
- Use the “John The Ripper” tool to check for weak passwords.
Restricting Shell for Non-Login Accounts (Importance: Medium)
Restricting shell access for system accounts that do not require login privileges.
Criteria
A. Restricting Shell Access for Non-Login Accounts
Configuration Method
Example: Setting the daemon account to prevent login
# vi /etc/passwd
(Before) daemon:x:1:1::/:/sbin/ksh
(After) daemon:x:1:1::/:/bin/false
Detailed Description
Unauthorized system utilization should be prevented by restricting shell access for users who do not require system entry. System accounts that do not need to log in should have their execution shell (e.g., /bin/sh) restricted and be assigned a “nologin” (/bin/false) shell to prohibit login.
<Target Accounts Not Requiring an Execution Shell>
This includes all accounts with general system account names such as: daemon, bin, sys, adm, listen, nobody, nobody4, noaccess, diag, operator, games, gopher, etc.
The following is a sample of the /etc/passwd file. Fields are delimited by “:”. If the final field is nologin or /bin/false, it indicates that a non-functional shell has been applied to the account.
bin:x:1:1:bin:/bin:/sbin/nologin daemon:x:2:2:daemon:/sbin:/sbin/nologin adm:x:3:4:adm:/var/adm:/sbin/nologin operator:x:11:0:operator:/root:/sbin/nologin games:x:12:100:games:/usr/games:/sbin/nologin gopher:x:13:30:gopher:/var/gopher:/sbin/nologin nobody:x:99:99:Nobody:/:/sbin/nologin
<Account Configuration When Shell Login is Not Required>
# useradd account -c "account finger_info" -d /home/{account} -m -s /bin/false
Restricting SU (Select User) Command Usage (Importance: High)
Restricting the su command to prevent unauthorized users from switching to privileged accounts.
Criteria
A. Creation of the Wheel Group and User Configuration
Configuration Method
<Method 1>
1) Specify the group that will use the su command in the /etc/default/security file.
# vi /etc/default/security
SU_ROOT_GROUP=wheel (Specify the group that will use the su command)
<Method 2>
1) Create a group (Request the group to be created; typically wheel is used).
# groupadd 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 require the use of the su command to the wheel group.
# usermod –G wheel [계정명]
Detailed Description
General users without administrative privileges can obtain root authority through Password Guessing after using the su command. Therefore, the 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) Configuration (Importance: Low)
Configuring UMASK to apply proper file and directory permissions for files created by users within the system.
Criteria
A. Set user UMASK to 022 in /etc/profile or /etc/bashrc
Gemini said
2. File System
User UMASK (User MASK) Configuration (Importance: Low)
Configuring UMASK to apply proper file and directory permissions for files created by users within the system.
Criteria
A. Set user UMASK to 022 in /etc/profile or /etc/bashrc
Configuration Method
1) Edit /etc/profile
umask 022
2) Edit /etc/default/security
UMASK=022
Detailed Description
The permissions applied when a user creates a file or directory within the system depend on the umask value. A low umask value may allow unauthorized persons to access files and directories that should only be accessible by administrators.
To view the umask value set for the current user, execute “umask” at the command prompt. It is recommended that the umask value be “022.” A umask value of “022” creates files with “rw-r–r–” access permissions.
By adding the command to the account’s Start Profile (/etc/profile, .cshrc, .kshrc, .bashrc, .login, .profile, etc.), the changed umask value will be applied after the user logs in.
SUID (Set User-ID) and SGID (Set Group-ID) Configuration (Priority: Low)
Restriction of SUID and SGID bits on root-owned files vulnerable to security threats.
Criteria
A. Removal of SUID (Set User-ID) and SGID (Set Group-ID)
※ Exception Handling: Files created by applications or files created for operational necessity are exempt.
Configuration Method
Verify the filenames in the table below and remove the SUID/SGID bits.
# chmod –s [Filename]
HP-UX
/opt/perf/bin/glance /usr/dt/bin/dtprintinfo /usr/sbin/swreg
/opt/perf/bin/gpm /usr/sbin/arp /usr/sbin/swremove
/opt/video/lbin/camServer /usr/sbin/lanadmin
/usr/bin/at /usr/sbin/landiag
/usr/bin/lpalt /usr/sbin/lpsched
/usr/bin/mediainit /usr/sbin/swacl
/usr/bin/newgrp /usr/sbin/swconfig
/usr/bin/rdist /usr/sbin/swinstall
/usr/contrib/bin/traceroute /usr/sbin/swmodify
/usr/dt/bin/dtappgather /usr/sbin/swpackage
Detailed Description
Files with SUID (Set User-ID) and SGID (Set Group-ID) enabled—especially those owned by root—are frequently utilized in Buffer Overflow and local attacks. These files require periodic management as they are critical from a security perspective.
For root-owned setuid files that are vulnerable, attributes should be removed from all such files except for those that are absolutely necessary. Periodic diagnosis and management are required to ensure that misconfigurations do not become security threats.
The list of Setuid and Setgid files to be removed is provided in the configuration method table. Setuid should also be removed if unusual files, such as those created by applications or arbitrarily by users, are discovered outside of this list. When removing Setuid, proceed carefully while verifying the normal operation of services, including the OS and applications.
Example of removal method: # chmod -s file-name
Example of periodic audit method:
# find / -user root -type f \( -perm -4000 -o -perm -2000 \) -exec ls -lg {} \;
If a Setuid file must be used, restrict its use to a specific group only.
Example of restricting use to a specific group: Restrict Setuid use by general users (allow only a designated group).
# /usr/bin/chgrp <Group_Name> <Setuid_File_Name> # /usr/bin/chmod 4750 <Setuid_File_Name>
If you wish to add an account, such as ‘wiki’, to a designated group to allow Setuid use, configure it as follows:
# usermod –G100 wiki
G : Change the configuration of the supplementary group list.
100 : the numerical value of the <Group>’s ID
/etc/inetd.conf File Permission Settings (Priority: High)
Configuration to remove write permissions for other users on the daemon configuration file (/etc/inetd.conf) owned by root.
Criteria
A. Restrictions on write access for other users to the /etc/inetd.conf file owned by root.
Configuration Method
# chown root /etc/inetd.conf # chmod o-w /etc/inetd.conf
※ If the file is a symbolic link, change the ownership of the original source file.
Detailed Description
This check determines whether access permissions are restricted for inetd.conf, the configuration file for the Internet Super-Daemon service.
The Internet Super-Daemon executes internal program daemons registered in /etc/inetd.conf upon receiving requests from the external network. If the permissions for inetd.conf are misconfigured, an unauthorized attacker could register a malicious program in this file and execute it with root privileges.
History File Permission Settings (Priority: Medium)
Permission management for script files that store the commands executed by all users logged into the system.
Criteria
A. Set permissions for history-related files to 600 or less.
Configuration Method
# chmod 600 [User Home Directory Path]/.history
# chmod 600 [User Home Directory Path]/.sh_history
Detailed Description
History files (.history, .sh_history, etc.) are scripts that record the commands of every user who logs in; therefore, they require strict security management.
If these files are world-readable, sensitive information such as plain-text passwords included in commands, internal directory structures, or administrative activities could be exposed. You must set the permissions for all users’ history files to “600” (read/write for owner only) and ensure the owner is set to the user themselves.
Crontab File Permission Setting and Management (Priority: High)
Inspection of permissions for Crontab-related files and the files scheduled to run with root privileges within Crontab.
Criteria
A. Removal of write permissions for other users on Crontab-related files.
B. Configuration of Crontab file permissions:
- Set file permissions to 744 and owner to root.
- Use absolute paths for scheduled files.
- Ensure all files scheduled in Crontab actually exist
※ Both items A and B must be applied.
Configuration Method
1) Remove write permissions for other users on Crontab-related files:
# chmod o-w /var/spool/cron/crontabs/*
2) Check and change the permissions of each file:
# 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 displayed as UIDs:
# 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 in Crontab does not exist in the actual path, delete it from the Crontab list.
Detailed Description
This check determines whether access permissions are restricted to prevent general users from maliciously accessing cron-related files.
Cron is a program that provides job scheduling, automatically performing specific tasks at specific times. If the access permissions for Cron-related files are misconfigured, unauthorized individuals can change the user environment through various methods, leading to security incidents.
A review of execution file permissions for files set to run in Crontab with root privileges is required (administrator review required).
If a file is set with general user privileges instead of root, an attacker can perform scheduled tasks. If relative paths are used, the file may fail to execute. If a file registered in Crontab does not exist in the actual path, an attacker can create a file with the same name as the registered file and execute it.
Additionally, when checking the permissions of files registered in Crontab, a problem may occur where the owner of files created by a deleted user remains as that user’s UID; appropriate ownership must be assigned to such files.
- Set permissions to 744 and owner to root for execution files set to run in Crontab with root privileges.
- Modify relative paths to absolute paths for files scheduled in Crontab.
- If the owner of a file scheduled in Crontab remains as a UID, assign a proper owner (root).
- Verify the existence of scheduled files in their actual paths.
# crontab –ㅣ 1 15 * * /backup/OS_backup.sh 30 * * * * /opt/sfm/vacuum
/etc/profile File Permission Settings (Priority: Medium)
Restricting access permissions for the user configuration file /etc/profile.
Criteria
A. Removal of write permissions for other users on the /etc/profile file owned by root (or bin).
Configuration Method
# chown root /etc/profile # chmod o-w /etc/profile
Gemini said
/etc/profile File Permission Settings (Importance: Medium)
Description: Restricting access permissions for the user configuration file /etc/profile.
Criteria
A. Removal of write permissions for other users on the /etc/profile file owned by root (or bin).
Configuration Method
Bash
# chown root /etc/profile
# chmod o-w /etc/profile
Detailed Description
The /etc/profile file is a login script used to configure the default environment for all users who log in to the system. If the access permissions for the /etc/profile file are incorrectly set, an unauthorized person can change user environments through various methods, potentially leading to a security breach.
For example, an attacker with write access could insert a malicious script into this file, which would then be executed with the privileges of any user (including root) who logs into the system.
/etc/hosts File Permission Settings (Priority: Medium)
Restricting access permissions for /etc/hosts, the hostname registration file.
Criteria
A. Removal of write permissions for other users on the /etc/hosts file owned by root (or bin).
Configuration Method
# chown root /etc/hosts # chmod o-w /etc/hosts
※ If the file is a symbolic link, change the ownership and permissions of the original source file.
Detailed Description
The /etc/hosts file is used to map IP addresses to hostnames. If the access permissions for this file are incorrectly configured, an attacker could modify the mappings to redirect traffic to a malicious system.
/etc/issue File Permission Settings (Priority: Medium)
Restricting access permissions for the /etc/issue file related to terminal settings.
Criteria
A. Removal of write permissions for other users on the /etc/issue file owned by root (or bin).
Configuration Method
# chown root /etc/issue # chmod o-w /etc/issue
Detailed Description
The /etc/issue file requires security management because it displays a message to users connecting through a terminal, Telnet session, or console.
User Home Directory and File Management (Priority: Medium)
Restricting access permissions for user home directories and environment variable files within home directories.
Criteria
A. Removal of write permissions for other users on user home directories and environment variable files.
Configuration Method
# chmod o-w [Home Directory]
# chmod o-w [Filename]
# chmod o-w [Home Directory Path] [Filename]
(When removing permissions from configuration files in the home directory)
Detailed Description
This check ensures that general users other than the account owner are restricted from modifying the home directory and environment variable files. If unauthorized users access and tamper with files or configuration files within a user’s home directory, the normal user’s services may be restricted.
If the access permissions for environment variable files are incorrectly configured, an unauthorized person can change the user environment through various methods, potentially leading to a security breach.
Remove write permissions for other users on environment variable files such as “.profile”, “.kshrc”, “.cshrc”, “.bashrc”, “.bash_profile”, “.login”, “.exrc”, “.netrc”, “.dtprofile”, and “.Xdefaults”.
Important Directory and File Permission Settings (Priority: Medium)
Configuration of permissions for important directories and the files contained within them.
Criteria
A. Removal of write permissions 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 access permissions for important directories are incorrectly configured, unauthorized persons can change the user environment through various methods, potentially causing security incidents.
Configure the removal of write permissions for other users on the /sbin, /etc/, /bin, /usr/bin, /usr/sbin, and /usr/lbin directories, ensuring they are owned 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 Configuration (Priority: Medium)
Configuration of the PATH environment variable in the root account’s environment variable files.
Criteria
A. Ensure the current directory symbol . is either removed or placed at the end of the PATH variable in the root account’s environment variable configuration files.
Configuration Method
The symbol ., which represents the current directory, must not be located at the beginning or in the middle of the PATH variable. If . must be used due to application configuration requirements, move . to the very end of the PATH environment variable.
Detailed Description
If the PATH environment variable of the root account includes . (referring to the current directory), an authorized root user may unintentionally execute a command located in the current directory.
Specifically, if . is positioned with higher priority than directories where standard commands are located (such as /usr/bin, /bin, or /sbin), a root user executing a command might unintentionally run a file illegally placed by an unauthorized person, leading to unexpected results. Furthermore, unexpected outcomes can occur if not only . but also any directory illegally created by an unauthorized person is given priority in the PATH.
Remove . (representing the current directory) from the PATH environment variable in the root account’s environment configuration files (e.g., .profile, .cshrc) and in /etc/profile.
※ Verify using echo $PATH (Applicable to the root account only).
FTP (File Transfer Protocol) Access Control File Permission Settings (Priority: High)
Configuration to remove write permissions for other users on FTP access control files owned by root.
Criteria
A. Removal of write permissions for other users on the /etc/ftpusers and /etc/ftpd/ftpusers files 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
※ When using vsftpd:
If userlist_enable = YES in vsftpd.conf: Check /etc/vsftpd/user_list or /etc/vsftpd.user_list.
# chown root /etc/vsftpd/user_list 또는 # chown root /etc/vsftpd.user_list # chmod o-w /etc/vsftpd/user_list 또는 # chmod o-w /etc/vsftpd.user_list
If userlist_enable = NO or the option does not exist in vsftpd.conf: Check /etc/vsftpd/ftpusers.
# chown root /etc/vsftpd/ftpusers # chmod o-w /etc/vsftpd/ftpusers
Detailed Description
If general users other than the administrator are allowed to access and modify FTP access control configuration files, security incidents may occur, such as unauthorized users being registered to access the server and perform illegal actions. Therefore, it is necessary to check whether restrictions are in place to prevent general users from modifying FTP access control configuration files.
Root Remote Access Control File Permission Settings (Priority: Medium)
Configuration to remove write permissions for other users on the /etc/security directory (or file), which is the root remote access control configuration setting, ensuring it is owned by root.
Criteria
A. Removal of write permissions for other users on the /etc/security path owned by root (or bin).
Configuration Method
# chown root /etc/security # chmod o-w /etc/security
Detailed Description
If general users other than the administrator are allowed to access and modify root access control configuration files, service failures—such as the restriction of root access—may occur. Therefore, it is necessary to check whether restrictions are in place to prevent general users from modifying root access control configuration files.
NFS (Network File System) Access Control File Permission Settings (Priority: High)
Removal of write permissions for other users on NFS access control files owned by root.
Criteria
A. Removal of write permissions for other users on the /etc/exports file owned by root (or bin).
Configuration Method
# chown root /etc/exports # chmod o-w /etc/exports
Detailed Description
If general users other than the administrator are allowed to access and modify the NFS (Network File System) access control configuration files, they could register unauthorized users or mount file systems to attempt illegal tampering. Therefore, it is necessary to check whether restrictions are in place to prevent general users from modifying the NFS access control configuration files.
/etc/services File Permission Settings (Priority: Medium)
Removal of write permissions for other users on the service file owned by root.
Criteria
A. Removal of write permissions for other users on the /etc/services file owned by root (or bin).
Configuration Method
# chown root w /etc/services # chmod o-w /etc/services
Detailed Description
If the service file can be accessed and modified by general users instead of the administrator, there is a risk of security incidents, such as restricting normal services or executing unauthorized services through the file.
Boot Script File Permission Settings (Priority: High)
Restricting access permissions for boot script files used within the OS.
Criteria
A. Removal of write permissions for other users from boot script files.
Configuration Method
Remediate files identified as vulnerable among those involved in boot scripts using the following command:
# chmod o-w [Filename or Directory Name]
Detailed Description
Access permissions for boot script files, which are critical for system operation, must be restricted so that only necessary users can access them. If write permissions are granted to other users, they must be removed.
/etc/rc*.d/*
/etc/inittab, etc.
3. Network Services
RPC (Remote Procedure Call) Service Restriction (Priority: Medium)
Removal of security-vulnerable RPC (Remote Procedure Call) services.
Criteria
A. Removal of unused RPC services.
※ Exception Handling: RPC services used for operational necessity are exempt.
Configuration Method
<Example of service removal for inetd>
- Comment out (add
#) the corresponding lines in the/etc/inetd.conffile. - Restart the
inetddaemon. - Completely delete the RPC service from the boot script.
# 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
# ps -ef | grep inetd
root 141 1 0 15:03:22 ? 0:01 /usr/sbin/inetd -s
# inetd -c (Restart/Reload)
# kill -HUP 141
※ If a system restart is difficult, manually stop the rpc.statd process:
# ps –ef |grep rpc rpc 3136 1 0 Oct11 ? 00:00:01 rpc.statd # kill –HUP 3136
Detailed Description
RPC (Remote Procedure Call) services allow calls to server applications in a distributed environment to request specific tasks. They are widely used because they facilitate development in distributed processing environments and are provided by default in Unix systems. However, RPC services possess numerous remote Buffer Overflow vulnerabilities, posing a very high risk of security incidents.
A Buffer Overflow occurs when more data is input than the designated buffer size, causing the program to behave abnormally. At the moment the buffer overflows, an attacker can execute arbitrary commands to gain root privileges or perform various other attacks.
The following unused RPC services should be removed. If a service must be used, the appropriate security patches must be applied.
| Service | Description |
| rpc.cmsd | Database management program used by Open Windows Calendar Manager and CDE Calendar. |
| rusersd | Responds to queries from the rusers command. |
| rstatd | Returns performance statistics obtained from the kernel. |
| rpc.statd | Supports the lockd program for file recovery in NFS during system failures. |
| kcms_server | Used to create or manage profiles controlling color performance for desktop digital images. |
| rpc.ttdbserverd | RPC-based ToolTalk database server program. |
| rwalld | Used to send messages to other users. |
| rpc.nisd | NIS server daemon. |
| rpc.ypupdated | Updates information in Network Information Services (NIS) maps. |
| cachefsd | Cache file system daemon. |
| sadmind | Program used for remote system administration. |
| sprayd | Receives packets sent by the spray command, which reports performance statistics. |
| rpc.pcnfsd | Handles service requests from PC-NFS (Personal Computer Network File System) clients. |
| rexd | Executes programs for remote systems. |
| rpc.rquotad | Returns local machine quotas for file systems mounted via NFS on remote machines. |
Remove the following RPC-related services from /etc/inetd.conf: ttdb, cmsd, rstatd, sadmind, rusersd, rexd, rwalld, sprayd, kcms_server, cachefsd, etc.
NFS (Network File System) Restriction (Priority: High)
Removal of NFS (Network File System) services that are not being used for a specific purpose.
Criteria
A. When the service is required:
- Unmount unauthorized systems.
- Restrict system mounting to “everyone” (unrestricted access).
B. When the service is not required:
- Stop NFS daemons (
nfsd,statd,lockd).
Configuration Method
<When using the service>
Identify systems that are remotely mounting NFS and unmount any unauthorized systems.
1. Check mounts: (Command will not run if the NFS service is stopped) Run # showmount -e hostname to check if the system is mounted to “everyone.”
# showmount
Umount
2. Unmount:
# umount "File_System_Name"
※ When using NFS services, list only essential shared directories in the /etc/exports file. The system must not be mounted to “everyone,” and NFS-related security patches must be applied.
<When not using the service>
1. Stop running services: Terminate the NFS daemon (nfsd) and mountd.
# ps -ef | grep mountd
root 163 1 0 Sep 27 ? 0:04 /usr/lib/autofs/automountd
# kill –9 163
# ps -ef | grep nfs
root 146 1 0 Sep 27 ? 0:16 /usr/lib/nfs/nfs
# kill –9 146
2. Disable automatic startup: Remove NFS from the startup list to prevent the NFS Server from starting upon reboot.
# vi /etc/rc.config.d/nfsconf (Change to: NFS_SERVER=0)
# mv /sbin/rc2.d/S900nfs.Server /sbin/rc2.d/_S900nfs.Server
Gemini의 응답
NFS (Network File System) Restriction (Priority: High)
Description: Removal of NFS (Network File System) services that are not being used for a specific purpose.
Criteria
A. When the service is required:
- Unmount unauthorized systems.
- Restrict system mounting to “everyone” (unrestricted access).
B. When the service is not required:
- Stop NFS daemons (
nfsd,statd,lockd).
Configuration Method
<When using the service>
Identify systems that are remotely mounting NFS and unmount any unauthorized systems.
- Check mounts: (Command will not run if the NFS service is stopped) Run
# showmount -e hostnameto check if the system is mounted to “everyone.”Bash# showmount -e - Unmount:Bash
# umount [File_System_Name]
※ When using NFS services, list only essential shared directories in the /etc/exports file. The system must not be mounted to “everyone,” and NFS-related security patches must be applied.
<When not using the service>
- Stop running services: Terminate the NFS daemon (
nfsd) andmountd.Bash# ps -ef | grep mountd root 163 1 0 Sep 27 ? 0:04 /usr/lib/autofs/automountd # kill –9 163 # ps -ef | grep nfs root 146 1 0 Sep 27 ? 0:16 /usr/lib/nfs/nfs # kill –9 146 - Disable automatic startup: Remove NFS from the startup list to prevent the NFS Server from starting upon reboot.Bash
# vi /etc/rc.config.d/nfsconf (Change to: NFS_SERVER=0) # mv /sbin/rc2.d/S900nfs.Server /sbin/rc2.d/_S900nfs.Server
Detailed Description
NFS is designed for sharing file systems over a network and is frequently used by high-capacity sites or service servers that need to share files from a single server. However, it carries a high risk of security incidents.
If not used for a specific purpose, the NFS service and its components (statd, lockd) should be stopped. If the use of NFS is unavoidable, you must ensure that unauthorized systems cannot mount the NFS system, preventing unauthorized access and file tampering.
Automountd Service Removal (Priority: Low)
Removal of the Automount service when it is not being used for a specific purpose.
Criteria
A. Removal of the Automount service.
Configuration Method
1) Stop the running service:
# ps -ef | grep automount root 650 1 0 3월 30 ? 0:30 /usr/lib/netsvc/fs/automount/automount -f /etc/auto_master # kill –9 650
2) Prevent automount from starting upon system restart: (The exact file location may vary depending on the OS)
# vi /etc/rc.config.d/nfsconf
(Before) AUTOFS=1
(After) AUTOFS=0
Detailed Description
Autofs enables a client system to automatically mount a remote directory or file system when a user needs it and automatically unmount it when the mount point is no longer in use.
The Autofs daemon, automountd, handles mount and unmount requests from Autofs via RPC. A vulnerability exists in the automountd daemon that allows a local attacker to send RPC requests to the daemon, potentially leading to security issues.
NIS (Network Information Service) Restriction (Priority: High)
Removal of NIS services that are not being used for a specific purpose.
Gemini의 응답
NIS (Network Information Service) Restriction (Priority: High)
Description: Removal of NIS services that are not being used for a specific purpose.
Criteria
A. NIS service stop
※ Exception Handling: NIS services used for operational necessity are exempt.
Configuration Method
1) NIS service stop
# /usr/lib/netsvc/yp/ypstop
2) Removal of boot scripts
# cd /etc/rc*/ # mv S88ypserv _S88ypserv
Detailed Description
NIS (Network Information Service) provides a consistent system environment to administrators and users by sharing important system database files through the network, and NIS+ is a subsequent version with added security and convenience features.
<Service check method> If the processes below are not present, it is normal.
| Process and Daemon | Description |
| ypserv | Runs on master and slave servers and responds to ypbind requests from clients. |
| ypbind | Runs on all NIS systems and binds and initializes clients and servers. |
| 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. |
‘r’ commands Service Removal (Priority: High)
Removal of ‘r’ commands services that are not being used for a specific purpose.
Criteria
A. When the service is required:
- Set the permissions of
/etc/hosts.equivand$HOME/.rhostsfiles to 400 with root ownership. - Use fixed IP settings in
/etc/hosts.equivand$HOME/.rhostsconfigurations to allow access.
B. When the service is not required:
- Remove ‘r’ commands services such as
rsh,rlogin, andrexec. - Set the permissions of
/etc/hosts.equivand$HOME/.rhostsfiles to 000 with root ownership, or link them to/dev/null. - ※ The
.rhostsfile must be created in the root home directory.
Configuration Method
<When using ‘r’ commands>
Remove any “+” signs from the host and account sections in the /etc/hosts.equiv and $HOME/.rhosts files, and register only the necessary hosts and accounts as shown in the example: Example: # vi /etc/hosts.equiv (or $HOME/.rhosts)
Wiki security
Designate permissions and ownership for files:
# chown root /etc/hosts.equiv # chmod 400 /etc/hosts.equiv # chown root /root/.rhosts # chmod 400 /root/.rhosts
※ Symbolic Links are recommended; permission changes are not required for them.
Recommended periodic management via cron:
# /bin/touch /.netrc /etc/hosts.equiv # /bin/chmod 400 /.netrc /etc/hosts.equiv
<When not using ‘r’ commands>
Remove the services and change the permissions of the /etc/hosts.equiv and $HOME/.rhosts files.
Example of service removal: Comment out (add #) the corresponding lines in the /etc/inetd.conf file and 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: Changing file permissions
# chown root /etc/hosts.equiv # chmod 000 /etc/hosts.equiv # chown root /root/.rhosts # chmod 000 /root/.rhosts
Method 2: Linking to /dev/null
# ln –s /dev/null /etc/hosts.equiv (/etc/hosts.equiv 파일 삭제 후) # ln –s /dev/null /root/.rhosts (/root/.rhosts 파일 삭제 후)
※ The .rhosts file must be created in the root home directory with 000 permissions or as a link to /dev/null.
Recommended periodic management via cron:
# /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 remote access for administrators without authentication. While they are sometimes used for NET Backup or other purposes, the use of ‘r’ commands is very vulnerable in terms of security; if service ports are open, there is a risk of security incidents.
If not used for a specific purpose like NET Backup, remove the following services: shell(514), login(513), exec(512)
If the services must be used, access should be allowed only for essential servers, and the permissions of related configuration files must be set appropriately. (Refer to “3.6. Trust Relationship Settings”)
Removal of Berkeley R-Command services from /etc/inetd.conf: Remove rsh, rlogin, and rexec services.
The /etc/hosts.equiv file is used to register TRUSTED systems and enable access without authentication using ‘r’ commands. The .rhosts file performs almost the same function but can be configured per user.
When using ‘r’ commands, register specific servers cautiously. Using “+” (which allows access from all servers) is extremely dangerous and must be configured with caution. When in use, set ownership to root and permissions to 400.
Prohibition of ‘+’ settings in the /etc/hosts.equiv file:
If the file is in use: Owner: root, Permissions: 400.
| Setting | Meaning |
| + + | Trust all accounts from all hosts. |
| + wiki | Trust the ‘wiki’ account from all hosts. |
| Wiki + | Trust all accounts from the ‘Wiki’ host. |
Removal of Unnecessary Services (Priority: High)
Removal of security-vulnerable or unnecessary services.
Criteria
A. Removal of unnecessary services.
Configuration Method
< Example of service removal >
- Comment out (add
#) the corresponding lines in the/etc/inetd.conffile and restartinetd. - Completely delete unnecessary services from the boot script.
# vi /etc/inetd.conf
(Before) # 100068/2-5 dgram rpc/udp wait root /usr/dt/bin/rpc.cmsd rpc.cmsd
(After) # 100068/2-5 dgram rpc/udp wait root /usr/dt/bin/rpc.cmsd rpc.cmsd
# inetd -c
If there are services that must be used, strengthen access control primarily through network equipment or firewalls in the short term. In the long term, re-evaluate the validity of providing the service and modify the application (e.g., changing the procedure calls that use the service).
Detailed Description
Unnecessary service ports open on a server can lead to the exposure of major system information and cause Denial of Service (DoS) attacks.
The following unused services should be removed:
| Service | Port | Description |
| echo | 7 | Simply retransmits messages sent by the client. |
| discard | 9 | Discards data received from any user. |
| daytime | 13 | Outputs the current time and date in ASCII format in response to client queries. |
| chargen | 19 | Service that returns a string of arbitrary length. |
| time | 37 | TCP version of the RFC 868 time server used by the rdate daemon. |
| tftp | 69 | Protocol for file transfer; used for downloading configuration files or starting installation processes for diskless workstations or network printers. |
| finger | 79 | Displays user information. |
| sftp | 115 | FTP over SSH. |
| uucp-path | 117 | UUCP path service. |
| nntp | 119 | Network News Transfer Protocol; standard service for creating discussion groups on the Internet. |
| ntp | 123 | Network Time Protocol; synchronizes time between clients and servers. |
| netbios_ns | 137 | NetBIOS name service; used to identify resources on the network. |
| netbios_dgm | 138 | NetBIOS Datagram service; used for broadcasting to hosts, groups, or the entire network. |
| netbios_ssn | 139 | NetBIOS session service; used to transmit and receive actual data using network shares, etc. |
| bftp | 152 | Binary File Transfer Protocol. |
| ldap | 389 | Service for directory service access. |
| printer | 515 | Used for spooling on remote printers. |
| talk | 517 | Starts a conversation session with a user logged into another system. |
| ntalk | 518 | Enables chatting between different systems. |
| uucp | 540 | Copies files between Unix systems and transmits commands to be executed on other systems. |
| pcserver | 600 | ECD Integrated PC board server; used in RPC-related attacks. |
| ldaps | 636 | LDAP over SSL. |
| ingreslock | 1524 | Ingre database lock service. |
| www-ldap-gw | 1760 | HTTP to LDAP gateway; used when LDAP transmits database information to a web server. |
| nfsd | 2049 | NFS server daemon service (if NFS is not in use). |
| dtspcd | 6112 | Desktop sub-process control daemon service. |
Service Banner Management (Priority: Medium)
Configuration of banners displayed when accessing general services (TELNET, FTP, SMTP, etc.) on the system.
Criteria
A. Prevention of information exposure and display of warning messages in access banners when using Telnet, FTP, SMTP, and DNS services.
Configuration Method
[Telnet Banner]
- Banner Configuration / Hostname Removal
Add the following to /etc/inetd.conf:
telnet stream tcp6 nowait root /usr/lbin/telnetd telnetd -b /etc/issue
(/etc/issue is the file containing the banner text)
(-b: Option to use the specified banner file)
Insert banner content into the /etc/issue file.
[FTP Banner]
- Banner Configuration / Hostname Removal
Add the following to /etc/inetd.conf:
ftp stream tcp nowait root /usr/lbin/ftpd ftpd -a /etc/ftpd/ftpaccess
(- a : Option to use the specified configuration file)
For wu-ftpd below v2.4:
Add the following to /etc/ftpd/ftpaccess:
suppresshostname yes (Hides hostname)
suppressversion yes (Hides version information)
banner /etc/ftpd/ftp_banner(File containing the FTP banner)
For wu-ftpd v2.4 or higher:
Add the following to /etc/ftpd/ftpaccess:
greeting terse (Hides hostname and version information)
※ If /etc/ftpd/ftpaccess does not exist, copy it as follows:
cp /usr/newconfig/etc/ftpd/examples/ftpaccess /etc/ftpd/ftpaccess
[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 the sendmail.cf file may vary depending on the SMTP configuration.
[DNS Banner]
# vi /etc/named.conf version "Contact Another Administrator!";
Detailed Description
By managing the banners output when accessing general services (TELNET, FTP, SMTP, etc.), you can prevent the leakage of service versions.
- Clearly state the scope of authorized server users and indicate that all activities are being monitored.
- Delete default banners or insert warning messages in each daemon configuration file.
- Configure banners so that the version of the corresponding process and the system’s hostname are not exposed.
Session Timeout Configuration (Priority: Low)
Configuration of session timeouts for connected sessions that remain idle for a specified period.
Criteria
A. Configuration of session timeout within the /etc/profile file.
Configuration Method
1) For sh (Bourne shell) and ksh (Korn shell): Modify /etc/profile or .profile by inserting TMOUT=300 and export TMOUT.
# vi /etc/profile
(After) TMOUT = 300
export TMOUT
2) For csh (C shell): Add set autologout=5 (for 5 minutes) or the relevant timeout variable to the /etc/csh.login file.
Detailed Description
Failure to set a timeout for idle sessions can lead to issues not only in terms of confidentiality but also in terms of availability.
It is necessary to configure the server to disconnect connected sessions if they are not used for a specified amount of time. (Timeout occurs after 300 seconds of inactivity.)
Root Account Telnet and SSH Access Restriction (Priority: High)
Configuration to restrict direct remote access to the root account via telnet and ssh.
Criteria
A. Restriction of root account login during telnet and ssh access.
Configuration Method
[telnet]
# Create the /etc/securetty file and insert "console".
# echo console > /etc/securetty
[ssh]
# Modify the /opt/ssh/etc/sshd_config file and restart the sshd daemon.
(Before) #PermitRootLogin no
(After) PermitRootLogin no
※ When restarting, you must terminate all connected sessions, then execute the /sbin/init.d/secsh stop command followed by start.
Detailed Description
Direct access to the root account is risky in terms of security; therefore, direct remote access to the root account must be restricted. It is necessary for security to configure the options below so that access to the root account is only possible by switching from a general user account.
Firewall Policy Application (Priority: High)
Application of firewall policies to block external attacks.
Criteria
A. Firewall ports can only be opened after the security assessment application is completed.
※ Note: “Any Open” configurations can only be opened after all identified security vulnerabilities have been remediated.
Configuration Method
A. Complete the security assessment application through ISS-D before opening the service.
Detailed Description
When opening a new service, the security assessment application must be completed before the firewall can be opened. In the case of “Any Open” (including Any Open within the internal network or opening a large number of IPs on external networks), the firewall can only be opened after the remediation of vulnerabilities discovered during the security assessment is finalized.
4. Log Management
System Log Configuration (Priority: High)
Configuration of su logs and syslog, along with permission settings for log files and directories.
Criteria
A. su logging records: Configure via /etc/syslog.conf.
B. syslog.conf log levels: Ensure logging for *.notice, *.alert, and *.emerg.
C. Permission settings for log files and directories: Ownership by root (or bin) and removal of write permissions for other users.
※ All items (A, B, and C) must be applied.
Configuration Method
1. su Log Configuration
# Check the /etc/syslog.conf file and add the following if it does not exist:
auth.notice /var/adm/sulog/syslog.log
or
*.notice /var/adm/sulog/syslog.log
(Use the TAB key to separate the selector and the file path.)
2. syslog Configuration
1) Inspect the /etc/syslog.conf file:
- .notice /var/log/messages
- .alert /dev/console
- .emerg *
2) After modifying /etc/syslog.conf, restart the syslogd daemon to apply changes:
# ps –ef | grep syslogd root 7524 6970 0 Apr 23 - 0:02 /usr/sbin/syslogd # kill –HUP 7524
3. Log File Permission Configuration
Set ownership to system users (root, adm, bin, etc.) and remove write permissions for other users for the following files:
| Log File | HP-UX 9.x Path | HP-UX 10.x or higher Path |
| wtmpx, utmpx | /usr/adm | /var/adm |
| wtmp, utmp | /usr/adm | /var/adm |
| btmp | /usr/adm | /var/adm |
| syslog | /usr/adm/syslog/syslog.log | /var/adm/syslog/syslog.log |
| sulog | /usr/adm | /var/adm |
| pacct | /usr/adm | /var/adm |
| messages | /usr/adm | /var/adm |
| lastlog | /usr/adm | /var/adm |
# chown root [Log_Filename]
# chmod o-w [Log_Filename]
Detailed Description
1. su Log Configuration It is essential to log the use of su (Switch User) to record instances where general users transition to Super User status. Since incidents compromising system availability or integrity typically involve Super User privileges, su logging is critical for auditing. The syslog configuration must be modified to record auth.notice logs in a file.
2. syslog Configuration This check ensures that syslog.conf is configured to record information and alerts generated during system operation. The syslog daemon is dedicated to monitoring kernel messages and system logs locally or remotely. If improperly configured, critical traces of intruders or system errors may not be recorded, making forensic analysis impossible.
3. Log File Permission Configuration Since general users do not need access to system logs, security should be strengthened by restricting file ownership and removing read/write permissions for unauthorized users.
Log Retention Period (Priority: High)
Application of the minimum log retention period as specified by law.
Criteria
A. Application of minimum retention periods for log files.
B. Regular review and supervision of log records.
C. Backup of log files to separate storage devices and restriction of write permissions.
Configuration Method
While log retention periods can be adjusted based on the business environment, they must be kept for at least the following periods in accordance with the “Act on Promotion of Information and Communications Network Utilization and Information Protection,” the “Personal Information Protection Act,” and “Company Regulations.”
1) User Access Information Records
- User Login / Logout / Information Changes: 6 months or longer
2) Access Records of Personal Information Processing Systems by Personal Information Handlers
- Identification of data subjects/handlers, access date/time, access location info, tasks performed according to granted authority types, etc.: 2 years or longer
3) Authority Change Records for Personal Information Handlers
- Creation / Change / Deletion of personal information handler permissions: 3 years or longer
The person in charge must regularly check and supervise log records. In cases where errors or fraudulent acts related to user access occur or are expected, immediate reporting and action must be taken.
To prevent log files from being forged or altered, it is desirable to keep them backed up on a separate storage device and restrict write permissions. Even if modification is possible, separate protective measures using information that can verify forgery (such as HMAC values or digital signatures) should be implemented.
Detailed Description
According to the “Act on Promotion of Information and Communications Network Utilization and Information Protection,” the “Personal Information Protection Act,” and “Company Regulations,” log files must be kept for at least 6 months. The person in charge must regularly backup, verify, and supervise the log records.
5. Major Application Configuration
FTP (File Transfer Protocol) Service User Restriction (Priority: High)
Checking whether FTP service is used, and if so, configuring User UMASK and Anonymous FTP settings.
Criteria
A. Restriction of FTP service for root and unnecessary accounts. B. Setting FTP UMASK to ‘077’. C. Disabling Anonymous FTP settings.
※ All items (A, B, and C) must be applied.
Configuration Method
- Restricting FTP use for root and unnecessary accounts
Check if FTP use is restricted for root and unnecessary system accounts.
Configuration Files:/etc/ftpusers,/etc/ftpd/ftpusers
Add the root account and system accounts to the/etc/ftpusersfile to restrict FTP login.
# vi /etc/ftpusers
root
...
(Example of FTP service restriction)
# echo root >> /etc/ftpd/ftpusers
# vi /etc/ftpd/ftpusers (Insert root)
When using vsftpd:
- If
userlist_enable=YESinvsftpd.conf: Checkvsftpd.userlist - If
userlist_enable=NO(or option missing) invsftpd.conf: Checkvsftpd.ftpusers
2. FTP UMASK Restriction
Modify /etc/inetd.conf as follows:
ftp stream tcp nowait root /usr/lbin/ftpd ftpd -u 077 3. Anonymous FTP Restriction
Check if the ftp account exists in the /etc/passwd file and delete it if present.
# cat /etc/passwd | grep ftp
# cat /etc/shadow | grep ftp
# userdel ftpDetailed Description
<Restricting FTP for root and unnecessary accounts> FTP is a program for exchanging files between computers connected over the internet or internal networks. Due to bugs and risks inherent in FTP servers, its use should be restricted unless absolutely necessary. When FTP service is used, prohibiting high-privileged accounts from logging in reduces the operational risk to the system.
<FTP UMASK Setting> If FTP use is unavoidable, the FTP UMASK must be configured to ensure that the access permissions of transferred files are set appropriately. If the FTP UMASK is incorrectly configured, files created via FTP may be deleted or modified by anyone.
<Anonymous FTP Restriction> Anonymous FTP must be disabled. If enabled, unauthorized persons can acquire system information. Furthermore, if write permissions are set on directories, various attacks can be executed using local exploits. Restricting access to authorized users only is also desirable for system availability.
SNMP (Simple Network Management Protocol) Service Configuration (Priority: Medium)
Verification of SNMP service and security configuration of the Community String.
Criteria
A. When the service is required:
The SNMP Community String must not be set to public or private.
(To prevent SNMP Brute-Force or Dictionary attacks, set a strong password format using at least 8 characters including a mix of numbers and symbols.)
B. When the service is not required:
Stop the service and configure it so that it does not execute upon system restart.
Configuration Method
<When SNMP service is not required>
# ps -ef | grep snmp root 9546 6970 0 Dec 05 - 1:11 /usr/sbin/snmpd # kill –9 9546 or # /sbin/SnmpAgtStart.d/S560SnmpMaster stop # mv /sbin/ /sbin/SnmpAgtStart.d/S560SnmpMaster /sbin/SnmpAgtStart.d/_S560SnmpMaster
<When SNMP service is required>
Change the community string in the /etc/snmp/snmpd.conf file to a value that others cannot guess.
- Change the
publicpart inread-community publicto an<arbitrary name>and restart the service. - Exercise caution when using the
set-community-name:section. - (Restrict the use of simple community names such as
public,admin, orprivate.)
| Vulnerability Item | Content | Countermeasure |
| Default Community String | If default strings like public or private are not changed, crackers can extract critical system information. | Modify or remove permissions; grant different permissions based on policy for special cases. |
| Network Interface Info | Remote hosts can obtain a list of network interfaces through SNMP. | Set community strings that are difficult to guess when using SNMP. |
| SNMP RPC Service | Default community strings allow remote discovery of system/network equipment info and modification of settings. | Change community strings to values that are difficult to guess. |
| OS Type Acquisition | Server OS and version information can be identified using SNMP. | Modify or remove permissions; grant different permissions based on policy for special cases. |
Detailed Description
The SNMP service is a basic service provided by UNIX systems for NMS (Network Management Systems) to monitor system status in real-time. Since the Community String (a type of password required to receive information) is often left at default values like public or private, a vulnerability exists where unauthorized users can exploit these strings to identify key system information and configuration status.
If the SNMP service is not used on the server—for example, if the NMS is not monitoring the server—it is desirable to remove the SNMP service. When using the service, it is necessary to change the community string to a complex value in the /etc/snmp/conf/snmpd.conf or /etc/snmp/snmpd.conf file.
SMTP (Simple Mail Transfer Protocol) Service Configuration (Priority: Medium)
Checks whether the SMTP service is in use and its configuration settings.
Criteria
A. If the service is required:
- Implement Sendmail abuse prevention and restrict the use of the
qoption for general users. - Use Sendmail version 8.14.4 or higher.
B. If the service is not required:
- Stop the service and ensure it does not execute upon system reboot.
Configuration Method
< When SMTP Service is Required >
1. Sendmail Abuse Prevention and Restriction of q Option for General Users
Disable default services VRFY and EXPN, and restrict the q option:
# Edit the /etc/mail/sendmail.cf file as follows:
O PrivacyOptions=authwarnings, noexpn, novrfy, restricqrun
2. Restriction of Vulnerable Sendmail Versions
1) Check if the Sendmail service is running:
# ps –ef | grep sendmail
2) Check the Sendmail version:
# telnet localhost 25
3) Verify the version and check for security patches at ftp://ftp.sendmail.org/pub/sendmail.
4) Since configuration methods vary by OS, check for specific information and upgrade at the official website (http://www.sendmail.org/).
< When SMTP Service is Not Required >
1) Stop Running Services
# ps –ef | grep sendmail root 441 1 0 Sep19 ? 00:00:00 sendmail: accepting connections # kill -9 441
2) Prevent Auto-start on System Reboot
# mv /etc/rc2.d/S88sendmail /etc/rc2.d/_S88sendmail
Detailed Description
SMTP contains many security vulnerabilities and poses potential risks. It is desirable to review the purpose of using SMTP on the server and remove the service if it is not necessary.
When operating the SMTP service, VRFY and EXPN must be blocked to prevent Sendmail abuse. Additionally, general users must be prevented from executing Sendmail with the q option to block functions that allow viewing mail queue contents/settings or forcibly dropping the mail queue.
Most vulnerabilities in Sendmail have been discovered in versions 8.13.8 and below; therefore, version 8.14.4 or higher is recommended. Below are recent Sendmail vulnerabilities, and systems using these versions require an upgrade:
SSL Certificate NULL Character Spoofing (CVE-2009-4565): Affects versions prior to 8.14.3.
Heap-based buffer overflow (CVE-2009-1490): Affects versions prior to 8.13.1.2.ㅍ
Remove SMTP services unless used for a specific purpose.
Verify the application of the latest Sendmail version and settings:
- Disable
VRFYandEXPNcommands and prevent execution with theqoption by general users. - Use Sendmail 8.14.4 or higher.
- Restrict mail relay functions.
- Apply patches for Address Parser vulnerabilities.
※ Note: The location of the sendmail.cf file may vary depending on the SMTP configuration.
DNS (Domain Name Service) Security Configuration (Priority: Medium)
Checks whether the DNS service is in use and its configuration settings.
Criteria
A. If the service is required:
- Restrict IP addresses so that Zone Transfers are only possible to specific servers.
- Recommendation to update to the latest version, BIND 9.9.2-P1 or higher.
B. If the service is not required:
- Stop the service and ensure it does not execute upon system reboot.
Configuration Method
< When DNS Service is Required >
Example of modifying BIND8 DNS settings (/etc/named.conf):
options {
allow-transfer { [IP addresses permitted for zone file transfer]; };
};
Example of modifying BIND4.9 DNS settings (/etc/named.boot):
Options
xfrnets 허용하고자 하는 IP
< When DNS Service is Not Required >
1) Stop Running Services
# ps -ef | grep named root 279 1 0 Sep 22 ? 1:17 /usr/sbin/in.named # kill -9 279
2) Prevent Auto-start on System Reboot
# mv /etc/rc3.d/ S79named /etc/rc3.d/_S79named
Detailed Description
Generally, a Zone Transfer is performed to maintain consistency between the Primary Name Server and the Secondary Name Server. Therefore, it is sufficient to allow Zone Transfers only to the Secondary Name Server.
If Zone Transfers are allowed to unauthorized users, an attacker can use the transferred zone information to identify significant details such as host information and network configuration. By default, DNS server installations often allow any user to perform a Zone Transfer.
In some cases, the DNS service may be active even if it is not in use if the default configuration is maintained after the initial system installation. Unnecessary DNS services must be removed.
If the DNS service is used, settings must be modified to prevent internal zone files from being transferred to arbitrary external servers, ensure that unauthorized users cannot receive query responses, and apply security version patches.
As of November 2012, BIND (Berkeley Internet Name Domain) version 9.9.2-P1 has been released, and almost all versions below this contain vulnerabilities. Since support for security and system updates for ISC BIND version 8 was discontinued on August 27, 2007, it is recommended to upgrade to BIND version 9 to prepare for potential security vulnerabilities and improve system performance (https://www.isc.org/downloads).
- Since almost all older versions of BIND are vulnerable, an update to version 9.9.2-P1 or higher is required.
- The following is a recent BIND vulnerability; systems using vulnerable versions must be upgraded:
Denial-of-Service (CVE-2009-4022): Affects versions prior to 9.6.0.
Remove the DNS service unless it is used for a specific purpose.
SWAT (Samba Web Administration Tool) Security Configuration (Priority: High)
Checks whether the SWAT service is in use and its configuration settings.
Criteria
A. Removal of SWAT Service
※ Exception: If using an intrusion prevention system (firewall) to filter port 901.
Configuration Method
< When SWAT Service is Required >
If using an intrusion prevention system, it is recommended to contact the firewall administrator to filter port 901, thereby blocking SWAT access from external networks.
< When SWAT Service is Not Required >
1) If there is no need to use SWAT, stop its operation as follows:
# Execute # vi /etc/inetd.conf and modify the content:
(Before) swat stream tcp nowait.400 root /opt/samba/bin/swat swat
(After) #swat stream tcp nowait.400 root /opt/samba/bin/swat swat
2) Restart inetd:
# inetd –c
Detailed Description
SWAT (Samba Web Administration Tool) outputs different messages when an incorrect username or password is entered, as shown below:
When the User ID is correct but only the password is incorrect:
401 Authorization Required.
You must be authenticated to use this service.
When both the User ID and password are incorrect:
401 Bad Authorization
username/password must be supplied
By exploiting these different messages, an attacker performing a brute-force attack (systematically trying various IDs and passwords) can determine valid User IDs based on the response received.
Samba Version Vulnerability
Checks whether the Samba service is in use and verifies its version.
Criteria
A. If the service is required:
- Upgrade to Version 4.0.1 or higher.
B. If the service is not required:
- Remove the service.
Configuration Method
< When Samba Service is Required >
When using the service, upgrade to Version 4.0.1 (Note: While the Korean text mentions 3.6.2 in the configuration section, the latest recommendation in the description is 4.0.1).
< When Samba Service is Not Required >
If there is no need to use Samba, stop its operation as follows:
# ps –ef | grep smb 538 ? 00:00:00 smbd # kill -9 538
Disable the boot script:
# mv /etc/rc3.d/S90samba /etc/rc3.d/_S90samba
Detailed Description
Numerous vulnerabilities have been discovered in Samba servers. Using legacy versions of Samba can make the system a target for attacks such as brute-force and buffer overflows.
Most vulnerabilities in Samba have been found in versions 3.4 and below. As of November 2012, Samba 4.0.1 is the latest release; therefore, it is recommended to use version 4.0.1 or higher.
The following are recent Samba vulnerabilities, and systems using these vulnerable versions require an upgrade:
Samba Information Disclosure and Denial of Service (CVE-2009-2906): Affects versions prior to 3.4.
※ Since patches are provided for vulnerable Samba versions, it is highly recommended to apply them. (Reference: http://www.samba.org/samba/history/security.html)
SSH (Secure Shell) Version Vulnerability (Priority: Medium)
Checks whether the SSH service is in use and verifies its version.
Criteria
A. If the service is required:
- Install and operate the latest version of SSH (OpenSSH 6.1 as of Nov 2012).
B. If the service is not required:
- Remove the running SSH service.
Configuration Method
< When SSH Service is Required >
1) It is recommended to install and operate the latest version of SSH.
As of November 2012, the latest version is OpenSSH 6.1. It is recommended to use OpenSSH 6.1 or higher. (OpenSSH can be downloaded at http://www.openssh.org)
< When SSH 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 to prevent SSH from starting (The location of the startup script varies by OS):
# ls –al /etc/rc*.d/* | grep sshd (시작스크립트 파일 위치 확인) # mv /etc/rc2.d/S55sshd /etc/rc2.d/_S55sshd
※ Note: The location of the sshd_config file may vary depending on the configuration (e.g., /opt/ssh/etc/sshd_config).
Detailed Description
OpenSSH is an open-source implementation of the SSH (Secure Shell) protocol, replacing tools like telnet, ftp, rlogin, and rsh. It protects sensitive data from attacks such as packet sniffing by encrypting network traffic.
However, numerous vulnerabilities have been discovered in older versions of OpenSSH. These vulnerabilities can make the system a target for various attacks, including root privilege acquisition and Denial of Service (DoS) attacks.
- The following are OpenSSH vulnerabilities; systems using these versions require an upgrade:
- Plaintext Recovery Attack Against SSH: Affects versions prior to 5.1.
- X11UseLocalhost=no hijacking attack (CVE-2008-1483): Affects versions prior to OpenSSH 5.0.
X-Server Access Restriction Configuration (Priority: High)
Restricting X-Server access to the target system from arbitrary hosts.
Criteria
A. Removal of X-Server access settings, such as xhost +, from all users’ auto-execution files.
Configuration Method
Remove any commands such as xhost + from all users’ auto-execution files (e.g., .login, .profile, .cshrc, .xinitrc, .xsession).
Detailed Description
Since GUI programs on Unix systems operate based on X-Window, if a system using X-Window allows arbitrary hosts to connect to its X-Server, an attacker can perform the following actions after connecting:
- Read various information typed by the user (e.g., passwords) from the keyboard.
- View all information displayed on the screen.
- Output arbitrary information to the screen.
- Execute or terminate arbitrary applications.
- Control the user’s session.
6. Major Application Configuration
Security Patch Application (Priority: Medium)
Periodic application of security patches to prevent server compromise.
Criteria
A. Apply the latest security patches and bug-fix patches.
Configuration Method
Install the latest security patches and bug-fix patches.
Verify the list of patches currently applied to the server using: swlist –l fileset | grep patch
HP-UX does not release “General Security Patches” due to its diverse hardware platforms and OS versions. However, you can obtain a list of vulnerable security patches by installing and running a program (Perl script) called security_patch_check.
security_patch_check is a tool that analyzes the currently applied patch list and provides information on applicable and missing patches in a report format. It automatically checks and notifies the system of error information regarding security patches.
To use security_patch_check, the Service Control Manager tool must be installed on the server. Please refer to the remarks for details on using security_patch_check.
< Examples of Patch Application >
1) Manual Patch Application
Administrators can apply patches manually following these steps:
- Access: http://www11.itrc.hp.com/service/patch/mainPage.do
- Select HP-UX to move to the relevant page.
- Select the appropriate H/W and OS.
- Search by selecting options like Keyword, Patch-ID, or Patch List.
- Receive the search results.
- Select and download the required patches.
- Determine which patches to apply while considering inter-patch dependencies.
2) Patch Application via Custom Patch Manager (CPM)
- CPM is a tool that helps select and download patches suitable for a specific system. It allows for automatic patch application at scheduled intervals and determines which patches to apply by automatically analyzing dependencies or conflicts.
- Go to the ITRC website (http://itrc.hp.com) and log in.
- Click the maintenance/support link and select customized patch bundles.
- Download and run the
cpm_collect.shscript to gather information on the current configuration. - Upload the results obtained from
cpm_collect.shto the ITRC page. - Click Perform Patch Analysis to get the candidate patch list.
- Check for conflicts between the selected patches.
- Download the selected patches using the Package button and install them.
< Patch Implementation >
- Verify applied patches:
swlist –l product - Patch files categorized by OS, product, and security are provided at: http://itrc.hp.com/
- Reference: http://www.software.hp.com/cgi-bin/swdepot_parser.cgi/cgi/displayProductInfo.pl?productNumber=B6834AA
< Patch Installation Example >
Create a directory to manage patch files:
# mkdir /var/spool/patch
Installation sequence (Example: Applying PHCO_16341 HP AutoRAID Manager cumulative patch):
# swlist –l fileset | grep PHCO_16341 (Check if already installed)
PHCO_16341.txt
# sh PHCO_16341.txt
# ls
PHCO_16341.txt PHCO_16341.depot PHCO_16341.text
# swinstall –s /var/spool/patch /PHCO_16341.depot
#swlist –l fileset | grep PHCO_16341 (Verify installation)
< Installation Precautions >
※ Some patches require a reboot. Always read the README-Patch-ID file carefully before proceeding.
Detailed Description
Securing security and system stability through periodic patch application is a critical element of system operation. For systems currently in service, applying many patches can be difficult due to potential issues (unexpected termination of running applications, bugs within the patch itself, etc.) and the difficulty of rebooting. Therefore, many factors must be considered.
While periodic patching is desirable, it should be performed by an OS vendor engineer after a thorough review. Patches should only be applied when it is determined that there will be no impact on active services, following these considerations:
| No | Considerations and Compliance for Patch Application |
|---|---|
| 1 | The OS vendor must review the impact the patch may have on the system itself; apply only if no issues are found. |
| 2 | The OS vendor and application developers must jointly review the patch’s impact on service programs; apply only if no issues are found. |
| 3 | To prepare for unexpected service interruptions, establish and test Roll-Back and emergency recovery procedures before patching. |
| 4 | Perform a Full Backup of the system both before and after applying patches. |