KISA 2026 Unix 서버 점검 항목 U-01~U-67

ssh.permit-root-login SSH root 직접 로그인 차단

OpenSSH 서버의 전역 PermitRootLogin 설정을 확인합니다. 실행 중인 호스트에서는 sshd -T가 알려 주는 실제 적용값을 쓰므로, 설치된 버전의 기본값도 함께 반영됩니다.

왜 중요한가. root로 직접 로그인하면 누가 접속했는지 추적할 수 없고, 가장 강한 권한을 가진 계정이 비밀번호 추측과 키 유출에 그대로 노출됩니다.

조치 방법. /etc/ssh/sshd_config(또는 그 파일이 포함하는 파일)에 PermitRootLogin no를 설정하고 sshd를 다시 불러오세요. 관리자는 각자의 계정으로 로그인한 뒤 sudo나 su를 사용합니다.

ssh.match-permit-root-login SSH Match 블록의 root 로그인 허용 금지

OpenSSH 서버 설정의 Match 블록 중에서 PermitRootLogin을 "no"가 아닌 값으로 둔 것을 나열합니다. 이런 블록은 조건에 맞는 연결에 대해 root 로그인을 다시 허용합니다.

왜 중요한가. Match 블록은 조건에 맞는 연결에 대해 전역 설정을 덮어쓰므로, 전역 값을 강화해도 특정 네트워크나 사용자 그룹에 대해서는 되돌려질 수 있습니다.

조치 방법. Match 블록에서 PermitRootLogin을 지우거나, 그 블록에서도 "no"로 설정하세요.

services.review-remote-root-login telnet 등 원격 터미널 서비스의 root 로그인 검토

telnet이나 rlogin이 시작되어 있을 때 적용됩니다. 그 서비스로 root가 로그인할 수 있는지 검토할 수 있도록 서비스가 시작된 경로를 보여 줍니다. 그 밖에는 해당하지 않습니다. OpenSSH 점검은 이 서비스들을 다루지 않습니다.

왜 중요한가. telnet이나 rlogin 서버는 로그인 스택이 거부하지 않으면 root가 원격으로 로그인하게 두고, 비밀번호도 평문으로 보냅니다.

조치 방법. 서비스를 끄고(services.no-telnet, services.no-r-services) SSH를 쓰세요. 꼭 실행해야 한다면 root를 막으세요. pam_securetty가 아직 있는 시스템(오래된 배포판)에서는 그 서비스의 PAM 로그인 스택에 auth required pam_securetty.so를 넣고 /etc/securetty에서 pts/N 줄을 모두 지우세요. 그렇지 않은 곳에서는 다른 방법으로 서비스가 root를 거부하게 해야 합니다.

사람이 판단합니다. 그 서비스로 root가 로그인할 수 없는지 확인하세요(그 모듈이 있는 곳에서는 auth 스택의 pam_securetty와 /etc/securetty에 pts/N 줄이 없는 것). 더 좋은 방법은 서비스를 끄는 것입니다.

accounts.password-min-length 비밀번호에 최소 길이가 있음

passwd 서비스의 PAM 스택이 경고만 하는 모드가 아닌 상태로 비밀번호 품질 검사(pam_pwquality 또는 pam_cracklib)를 하고, 최소 길이를 min_length자 이상으로 요구하는지 확인합니다. 양수 크레딧은 합계만큼 비밀번호를 더 짧게 만들 수 있으므로 minlen에서 뺍니다.

왜 중요한가. 짧은 비밀번호는 추측과 오프라인 크래킹에 금방 무너집니다.

조치 방법. password 스택에서 pam_pwquality를 켜고(authselect, pam-auth-update), /etc/security/pwquality.conf에 minlen = 8 이상을 설정하세요. enforcing = 0이나 양수 크레딧은 설정하지 마세요.

accounts.password-complexity 비밀번호에 영문자·숫자·특수문자를 섞어 씀

경고만 하는 모드가 아닌 상태로 비밀번호 품질 검사가 숫자, 특수문자, 영문자(대문자 또는 소문자)를 각각 하나 이상 요구하는지 확인합니다. dcredit, ocredit과 ucredit 또는 lcredit이 -1 이하이거나, minclass가 4(모든 문자 종류)이거나, minclass 3에 dcredit과 ocredit이 함께 설정된 경우(이때 영문자가 세 번째 종류입니다)에 통과합니다.

왜 중요한가. 한 가지 문자 종류만으로 만든 비밀번호는 추측하기가 훨씬 쉽습니다.

조치 방법. /etc/security/pwquality.conf에 dcredit = -1, ocredit = -1, ucredit = -1, lcredit = -1을 설정하세요(또는 minclass = 4, 또는 minclass = 3에 dcredit = -1과 ocredit = -1).

accounts.password-quality-root 비밀번호 품질 검사가 root에도 적용됨

경고만 하는 모드가 아닌 비밀번호 품질 모듈에 enforce_for_root가 있는지 확인합니다. 없으면 root가 경고를 보고도 약한 비밀번호를 설정할 수 있습니다.

왜 중요한가. enforce_for_root가 없으면 root가 비밀번호를 바꿀 때 품질 규칙은 경고만 합니다.

조치 방법. /etc/security/pwquality.conf에 enforce_for_root를 추가하세요. CentOS/RHEL 7(libpwquality 1.2)의 그 파일에는 이 설정이 없으므로, 대신 /etc/pam.d/system-auth와 password-auth의 pam_pwquality 줄에 인자로 추가하세요.

accounts.password-max-age 비밀번호가 만료됨

/etc/login.defs의 PASS_MAX_DAYS, 즉 새 계정에 주는 비밀번호 최대 사용 기간을 확인합니다. 이 값이 없으면 shadow-utils는 -1을 쓰는데, 비밀번호가 만료되지 않는다는 뜻입니다.

왜 중요한가. 바뀌지 않는 비밀번호는 그것을 알아낸 사람에게 계속 쓸모가 있습니다.

조치 방법. /etc/login.defs에 PASS_MAX_DAYS 90(또는 그보다 작은 값)을 설정하고, 이미 있는 계정에는 chage로 적용하세요.

accounts.password-max-age-existing 기존 계정의 비밀번호가 만료됨

/etc/shadow에서 해당 계정 자신의 최대 사용 기간이 비어 있거나 0이거나 max_days보다 큰 비밀번호 계정을 나열합니다. login.defs의 값은 그 값을 정한 뒤에 만든 계정에만 적용되므로, 이미 있던 계정(많은 시스템에서 root는 99999를 유지합니다)은 여전히 만료되지 않을 수 있습니다.

왜 중요한가. 바뀌지 않는 비밀번호는 그것을 알아낸 사람에게 계속 쓸모가 있습니다.

조치 방법. 나열된 계정마다 chage -M 90 계정을 실행하고, 새 계정을 위해 /etc/login.defs에 PASS_MAX_DAYS 90을 설정하세요.

accounts.password-min-age 비밀번호를 바로 되돌려 바꿀 수 없음

/etc/login.defs의 PASS_MIN_DAYS, 즉 비밀번호를 바꾸는 간격의 최소 일수를 확인합니다.

왜 중요한가. 최소 사용 기간이 없으면 사용자가 몇 분 만에 비밀번호를 여러 번 바꿔 예전 비밀번호로 돌아갈 수 있어서 비밀번호 이력이 무력해집니다.

조치 방법. /etc/login.defs에 PASS_MIN_DAYS 1(또는 그 이상)을 설정하세요.

accounts.password-history 최근 비밀번호를 다시 쓸 수 없음

passwd 서비스가 최근 remember개의 비밀번호를 거부하는지, root가 비밀번호를 설정할 때도 그런지 확인합니다. enforce_for_root가 있는 pam_pwhistory가 거부하면 pam_unix가 그 비밀번호를 저장하지 못합니다. pam_unix의 remember 옵션은 인정하지 않습니다. root가 비밀번호를 바꿀 때 pam_unix가 이 검사를 건너뛰기 때문입니다.

왜 중요한가. 예전 비밀번호를 다시 쓰면 이미 알려졌을 수 있는 자격 증명이 되살아납니다.

조치 방법. password 스택에서 pam_unix보다 앞에 pam_pwhistory를 켜고, /etc/security/pwhistory.conf나 모듈 줄에 remember = 4(또는 그 이상)와 enforce_for_root를 설정하세요.

accounts.lockout-threshold 로그인에 여러 번 실패하면 계정이 잠김

login과 (SSH 서버가 있으면) sshd의 PAM 스택이 pam_faillock이나 pam_tally2로 로그인 실패 max_failures번 이내에 계정을 잠그는지 확인합니다. pam_faillock은 authfail 줄과 함께 preauth나 authsucc 줄이 있어야 잠그고, sshd는 UsePAM yes일 때만 PAM을 사용합니다.

왜 중요한가. 잠금이 없으면 공격자가 한 계정에 대해 비밀번호를 끝없이 시도할 수 있습니다.

조치 방법. pam_faillock을 켜고(authselect enable-feature with-faillock, Debian에서는 preauth, authfail, account 줄 추가), /etc/security/faillock.conf에 deny = 10 이하를 설정하고, sshd_config에는 UsePAM yes를 유지하세요.

accounts.passwd-no-hashes /etc/passwd에 비밀번호 해시나 빈 비밀번호 없음

/etc/passwd의 비밀번호 필드가 /etc/shadow를 가리키는 "x"가 아니라 해시이거나 비어 있는 계정을 나열합니다.

왜 중요한가. /etc/passwd는 모든 사용자가 읽을 수 있어서 그 안의 해시는 오프라인으로 크래킹할 수 있고, 필드가 비어 있으면 비밀번호가 아예 없다는 뜻입니다.

조치 방법. pwconv로 비밀번호를 /etc/shadow로 옮기고, 필드가 비어 있던 계정은 잠그거나 비밀번호를 설정하세요.

accounts.shadow-file 비밀번호 해시는 /etc/shadow에 보관

/etc/shadow가 있는지 확인합니다. 있어야 해시가 누구나 읽을 수 있는 /etc/passwd에 들어가지 않습니다.

왜 중요한가. /etc/shadow가 없으면 비밀번호 해시를 누구나 읽을 수 있는 /etc/passwd에 보관해야 합니다.

조치 방법. pwconv를 실행하세요(그룹은 grpconv).

accounts.uid0-only-root UID 0은 root만 가짐

root가 아닌데 UID가 0인 계정을 나열합니다.

왜 중요한가. UID 0 계정은 모두 완전한 root 권한을 가지며, 눈에 띄지 않을 수 있는 이름을 쓸 수 있습니다.

조치 방법. 그 계정에 다른 UID를 주거나(usermod -u) 계정을 지우세요.

accounts.su-wheel-only wheel 그룹 구성원만 su를 쓸 수 있음

su의 PAM 스택에 wheel 그룹(또는 group=으로 지정한 그룹) 밖의 사용자를 거부하는 pam_wheel 줄이 있는지, 또는 su 자체가 권한으로 제한되어 있는지(root 소유, 그룹은 wheel, sudo, admin, adm 중 하나, setuid, 다른 사용자는 실행 불가) 확인합니다. trust나 deny가 붙은 줄, 거부하지 않는 제어값(optional, sufficient), 스택에서 더 앞에 있는 sufficient 규칙은 su를 제한하지 못합니다.

왜 중요한가. 제한이 없으면 root 비밀번호를 알게 된 사용자는 누구나 su로 root가 될 수 있습니다.

조치 방법. /etc/pam.d/su에서 common-auth나 system-auth 포함 줄보다 앞에 auth required pam_wheel.so use_uid를 추가하고, 관리자를 wheel 그룹에 넣으세요. 또는 프로그램 자체를 관리자 그룹으로 제한하세요(chgrp wheel /usr/bin/su && chmod 4750 /usr/bin/su. Debian과 Ubuntu에서는 그룹을 sudo로 하고 dpkg-statoverride를 써야 패키지 업데이트 뒤에도 유지됩니다).

accounts.review-login-accounts 로그인할 수 있는 계정 검토

로그인 셸이 있는 모든 계정을 나열해서, 검토하는 사람이 각 계정이 아직 필요한지 확인하게 합니다.

왜 중요한가. 퇴사한 사용자나 오래된 서비스가 남긴 계정은 공격하기 쉬운 대상입니다.

조치 방법. 더 이상 필요 없는 계정은 지우세요(userdel). 남겨야 하지만 로그인은 막아야 하는 계정에는 nologin 셸을 주고 비밀번호를 잠그세요(usermod -L -s /usr/sbin/nologin).

사람이 판단합니다. 나열된 계정이 모두 아직 필요한지, 특히 퇴사한 사람의 계정이 없는지 확인하세요. lp, uucp, games 같은 기본 계정은 로그인 셸이 주어졌을 때만 여기에 나타나는데, 원래는 셸이 없어야 합니다.

accounts.review-admin-groups 관리자 그룹 구성원 검토

root(GID 0), wheel, sudo, admin 그룹의 구성원을 나열합니다. 해당 그룹을 기본 그룹으로 가진 계정(/etc/passwd, pam_wheel과 sudo는 이들도 구성원으로 봅니다)과 /etc/group에 적힌 추가 구성원이 모두 포함됩니다.

왜 중요한가. 이 그룹의 구성원은 모두 관리자 권한을 얻을 수 있거나 이미 가지고 있습니다.

조치 방법. 관리자 권한이 필요 없는 계정은 그룹에서 빼세요(gpasswd -d 사용자 그룹).

사람이 판단합니다. 나열된 그룹마다 꼭 필요한 관리자만 속해 있는지 확인하세요.

accounts.review-empty-groups 계정이 속하지 않은 그룹 검토

구성원이 없고 어떤 계정의 기본 그룹도 아닌 그룹을 나열합니다.

왜 중요한가. 쓰지 않는 그룹도 파일을 소유할 수 있고, 새 계정이 실수로 그 그룹을 다시 쓸 수 있습니다.

조치 방법. 그 그룹이 소유한 파일을 확인한 뒤, 필요 없는 그룹은 지우세요(groupdel).

사람이 판단합니다. 나열된 그룹이 아직 필요한지 확인하세요. 설치된 소프트웨어에 속한 그룹이 많고, 파일이나 장치를 소유하고 있을 수 있습니다.

accounts.unique-uids 계정마다 UID가 다름

다른 계정과 UID가 같은 계정을 나열합니다.

왜 중요한가. UID가 같은 계정은 커널에게 같은 사용자이므로, 접근 권한과 감사 기록으로는 서로 구분할 수 없습니다.

조치 방법. 계정마다 고유한 UID를 주고(usermod -u), 그 계정의 파일 소유자를 바로잡으세요.

accounts.system-account-shells 시스템 계정은 로그인할 수 없음

시스템 계정(UID 1부터 system_uid_max까지, 그리고 nobody, UID 65534, 4294967294 같은 오버플로 계정) 중에서 nologin이나 false가 아닌 로그인 셸을 가진 것을 나열합니다.

왜 중요한가. 셸이 있는 서비스 계정은 그 계정에 접근한 공격자에게 대화형으로 발판을 줍니다.

조치 방법. 셸을 /usr/sbin/nologin으로 바꾸세요(usermod -s /usr/sbin/nologin 계정).

accounts.session-timeout-set 유휴 셸이 자동으로 끝남

시스템 전체 시작 파일(/etc/environment, /etc/profile과 그 파일이 읽는 /etc/profile.d 등)이 TMOUT을 양수 초로 설정해 두어서 모든 사용자의 로그인 셸에 적용되는지 확인합니다. root 자신의 파일에만 설정한 값은 인정하지 않고, if나 case 블록 안의 대입도 인정하지 않으며, 나중에 unset하면 설정이 사라집니다.

왜 중요한가. 로그인한 채 방치된 터미널은 그 앞에 접근한 누구나 쓸 수 있습니다.

조치 방법. /etc/profile.d의 파일에 TMOUT=600, readonly TMOUT, export TMOUT을 추가하세요.

accounts.session-timeout-value 유휴 시간 제한이 충분히 짧음

비어 있거나 0이거나 max_seconds보다 긴 TMOUT 대입과, TMOUT을 unset하는 명령을 나열합니다. 일부 세션에만 적용될 수 있는 if나 case 블록 안의 것도 포함합니다.

왜 중요한가. 제한 시간이 길거나 꺼져 있으면 유휴 세션이 열린 채 남습니다.

조치 방법. TMOUT=600(또는 그보다 짧은 값)을 설정하고, 더 큰 값의 대입과 unset 명령은 지우세요.

accounts.password-hash-method 새 비밀번호가 강한 해시를 씀

새 비밀번호가 SHA-2, yescrypt, bcrypt 해시로 저장되는지 확인합니다. passwd 스택에 있는 pam_unix의 해시 옵션(passwd에 대해서는 login.defs보다 우선합니다)과, 다른 shadow-utils 도구가 쓰는 /etc/login.defs의 ENCRYPT_METHOD를 봅니다. ENCRYPT_METHOD YESCRYPT는 shadow-utils가 yescrypt를 지원하도록 빌드된 곳(Debian 12, Ubuntu 24.04, RHEL 10과 그 이후 버전)에서만 인정하고, RHEL 9나 Ubuntu 22.04 같은 곳에서는 DES로 되돌아갑니다.

왜 중요한가. DES나 MD5 crypt로 해시한 비밀번호는 해시가 유출되면 금방 크래킹됩니다.

조치 방법. /etc/login.defs에 ENCRYPT_METHOD SHA512를 설정하고, pam_unix의 password 줄에 sha512 또는 yescrypt를 쓴 다음, 사용자가 비밀번호를 바꾸게 하세요.

accounts.password-hash-strength 저장된 비밀번호가 강한 해시를 씀

/etc/shadow의 해시가 DES, MD5이거나 알 수 없는 방식인 계정을 나열합니다. /etc/shadow가 없으면 확인할 것이 없으므로 이 점검은 통과할 수 없습니다.

왜 중요한가. ENCRYPT_METHOD를 바꿔도 새 비밀번호에만 적용되므로, 예전의 약한 해시는 계속 크래킹할 수 있는 채로 남습니다.

조치 방법. 나열된 사용자가 비밀번호를 바꾸게 하세요(passwd -e 사용자는 다음 로그인 때 변경을 강제합니다).

accounts.passwd-no-hashes /etc/passwd에 비밀번호 해시나 빈 비밀번호 없음

/etc/passwd의 비밀번호 필드가 /etc/shadow를 가리키는 "x"가 아니라 해시이거나 비어 있는 계정을 나열합니다.

왜 중요한가. /etc/passwd는 모든 사용자가 읽을 수 있어서 그 안의 해시는 오프라인으로 크래킹할 수 있고, 필드가 비어 있으면 비밀번호가 아예 없다는 뜻입니다.

조치 방법. pwconv로 비밀번호를 /etc/shadow로 옮기고, 필드가 비어 있던 계정은 잠그거나 비밀번호를 설정하세요.

env.path-current-dir PATH에서 현재 디렉터리를 먼저 찾지 않음

시스템 전체 시작 파일과 root의 시작 파일에서 PATH에 현재 디렉터리(".", 빈 항목, "./bin"이나 "bin" 같은 상대 경로)를 맨 뒤가 아닌 곳에 넣은 대입을 나열합니다.

왜 중요한가. PATH 앞쪽에 현재 디렉터리가 있으면, 지금 있는 디렉터리에 시스템 명령과 같은 이름으로 만들어 둔 프로그램이 그 명령 대신 실행됩니다. 실행하는 사람의 권한으로 말입니다.

조치 방법. PATH에서 ".", 빈 항목, 상대 경로를 지우거나 맨 뒤로 옮기세요.

files.unowned 소유자·그룹이 없는 파일 없음

소유자나 그룹이 /etc/passwd나 /etc/group에 계정으로 없는 파일과 디렉터리를 로컬 파일 시스템에서 나열합니다. 디렉터리 서비스(LDAP, SSSD, NIS)만 제공하는 계정은 조회하지 않으므로, 그 계정이 소유한 파일도 여기에 나열됩니다.

왜 중요한가. 지워진 계정이 남긴 파일은 그 UID나 GID를 다음에 받는 사람의 것이 됩니다.

조치 방법. 나열된 파일마다 소유자와 그룹을 주거나(chown) 파일을 지우세요.

files.passwd-perms /etc/passwd는 root 소유, 다른 사용자 쓰기 금지

/etc/passwd를 root가 소유하고 모드가 0644 또는 더 엄격한지 확인합니다.

왜 중요한가. /etc/passwd에 쓸 수 있는 사람은 UID 0인 계정을 추가할 수 있습니다.

조치 방법. chown root /etc/passwd와 chmod 644 /etc/passwd를 실행하세요.

files.startup-scripts 시작 스크립트와 유닛은 root 소유, 다른 사용자 쓰기 금지

SysV init 스크립트, rc.local, /etc/systemd/system의 systemd 유닛(service, timer, socket, path와 그 drop-in 파일), 그리고 /usr/lib/systemd/system과 /lib/systemd/system의 서비스를 root가 소유하고 다른 사람은 쓸 수 없는지(모드 0755 또는 더 엄격) 확인합니다.

왜 중요한가. 이것들은 부팅할 때 root 권한으로 실행되므로, 하나라도 바꿀 수 있는 사람은 다음 재시작 때 root 권한을 얻습니다.

조치 방법. 나열된 파일마다 chown root와 chmod go-w를 실행하세요.

files.shadow-perms /etc/shadow는 root 소유, root만 읽기

/etc/shadow를 root가 소유하고 모드가 0400 또는 더 엄격한지 확인합니다. Debian 계열은 이 파일을 shadow 그룹의 0640으로 배포하는데, 이 점검은 그 경우를 보고합니다.

왜 중요한가. /etc/shadow의 비밀번호 해시는 읽을 수 있는 사람이 오프라인으로 크래킹할 수 있습니다.

조치 방법. chown root /etc/shadow와 chmod 400 /etc/shadow를 실행하세요.

files.hosts-perms /etc/hosts는 root 소유, 다른 사용자 쓰기 금지

/etc/hosts를 root가 소유하고 모드가 0644 또는 더 엄격한지 확인합니다.

왜 중요한가. /etc/hosts에 쓸 수 있는 사람은 호스트 이름을 자기 주소로 돌릴 수 있습니다.

조치 방법. chown root /etc/hosts와 chmod 644 /etc/hosts를 실행하세요.

files.inetd-conf-perms inetd·xinetd 설정은 root 소유, 비공개

/etc/inetd.conf, /etc/xinetd.conf와 /etc/xinetd.d의 파일을 root가 소유하고 모드가 0600 또는 더 엄격한지 확인합니다. 이 파일들이 하나도 없으면 해당하지 않습니다.

왜 중요한가. 슈퍼 서버는 이 파일들이 지정한 프로그램을 지정한 사용자 권한으로 시작합니다.

조치 방법. 나열된 파일마다 chown root와 chmod 600을 실행하세요.

files.syslog-conf-perms syslog 설정은 시스템 계정 소유, 다른 사용자 읽기 금지

/etc/syslog.conf, /etc/rsyslog.conf, /etc/rsyslog.d/*.conf, /etc/syslog-ng/syslog-ng.conf, /etc/syslog-ng/conf.d/*.conf를 root, bin, sys 중 하나가 소유하고 모드가 0640 또는 더 엄격한지 확인합니다. syslog 데몬 설정이 없으면 해당하지 않습니다.

왜 중요한가. 로그 설정을 바꿀 수 있는 사람은 자기 흔적을 숨길 수 있습니다.

조치 방법. 나열된 파일마다 chown root와 chmod 640을 실행하세요.

files.services-perms /etc/services는 시스템 계정 소유, 다른 사용자 쓰기 금지

/etc/services를 root, bin, sys 중 하나가 소유하고 모드가 0644 또는 더 엄격한지 확인합니다. 파일이 없으면 해당하지 않습니다(netbase가 없는 최소 이미지).

왜 중요한가. /etc/services에서 서비스의 포트 번호를 바꾸면 그 서비스를 드러내거나 숨길 수 있습니다.

조치 방법. chown root /etc/services와 chmod 644 /etc/services를 실행하세요.

files.setid-outside-system-dirs 시스템 디렉터리 밖의 SUID·SGID 파일 없음

시스템 디렉터리(/usr/bin, /usr/sbin, /usr/lib, /usr/lib64, /usr/libexec, /bin, /sbin, /lib, /lib64) 밖에 있는 set-user-ID, set-group-ID 파일을 나열합니다. 홈 디렉터리, /tmp, /var, /opt, /srv 등이 해당합니다.

왜 중요한가. 배포판은 set-ID 프로그램을 시스템 디렉터리에 설치하므로, 다른 곳에 있는 것은 대개 남겨진 파일이거나 실행하는 사람에게 소유자의 권한을 주는 백도어입니다.

조치 방법. 소프트웨어가 필요로 하지 않는다면 set-ID 비트를 떼거나(chmod u-s,g-s) 파일을 지우세요.

files.review-setid SUID·SGID 파일 검토

로컬 파일 시스템에서 set-user-ID나 set-group-ID 비트가 설정된 파일을 모두 나열합니다.

왜 중요한가. set-ID 프로그램은 그 소유자나 그룹의 권한으로 실행되므로, 아무도 필요로 하지 않는 것은 위험만 더합니다.

조치 방법. 사용자가 필요로 하지 않는 프로그램에서는 set-ID 비트를 떼거나(chmod u-s,g-s), 실행할 수 있는 사람을 제한하세요.

사람이 판단합니다. 나열된 프로그램마다 set-ID 비트가 정말 필요한지 확인하세요.

homes.startup-files 사용자 시작 파일은 본인·root 소유, 다른 사용자 쓰기 금지

셸 시작 파일(.profile, .bashrc, .bash_profile 등)을 그 계정이나 root가 아닌 다른 사람이 소유하고 있거나, 그룹이나 다른 사용자가 쓸 수 있거나, 없는 파일을 가리키는 심볼릭 링크인 계정을 나열합니다.

왜 중요한가. 시작 파일은 그 사용자가 로그인할 때마다 실행되므로, 이 파일을 바꿀 수 있는 사람은 그 사용자의 권한으로 명령을 실행할 수 있습니다.

조치 방법. 나열된 파일마다 chown 사용자와 chmod go-w를 실행하고, 없는 파일을 가리키는 링크는 지우세요.

files.world-writable 모든 사용자가 쓸 수 있는 파일과 스티키 비트 없는 디렉터리가 없음

로컬 파일 시스템에서 모든 사용자가 쓸 수 있는 일반 파일과, 스티키 비트가 없는 쓰기 가능 디렉터리(누구나 다른 사람의 파일을 지우거나 바꿀 수 있습니다)를 나열합니다.

왜 중요한가. 모든 사용자가 쓸 수 있는 파일은 누구나 바꿀 수 있어서, 권한 있는 프로그램이나 사용자가 그것을 읽거나 실행하면 그 권한을 얻는 통로가 됩니다.

조치 방법. 다른 사용자의 쓰기 권한을 없애거나(chmod o-w), 여럿이 쓰는 디렉터리에는 스티키 비트를 설정하세요(chmod +t).

files.dev-regular-files /dev에 일반 파일 없음

/dev 아래의 일반 파일(/dev/shm과 /dev/mqueue는 제외)을 나열합니다. /dev에는 장치와 디렉터리만 있어야 합니다.

왜 중요한가. /dev는 들여다보는 일이 드물어서 파일을 숨기기 좋은 곳이고, 거기 있는 일반 파일은 장치가 아닙니다.

조치 방법. 나열된 파일이 무엇인지 확인하고, 있어서는 안 되는 것은 지우세요.

files.rhosts hosts.equiv와 root의 .rhosts는 root 소유, 비공개

/etc/hosts.equiv와 /root/.rhosts를 root가 소유하고 비공개인지(모드 0600 또는 더 엄격) 확인합니다. 다른 사용자의 .rhosts 파일은 files.rhosts-homes가 봅니다. r-서비스가 필요하지 않다면 이런 파일은 없어야 합니다.

왜 중요한가. 이 파일들이 있으면 해당 호스트와 사용자가 rlogin과 rsh로 비밀번호 없이 로그인할 수 있습니다.

조치 방법. 파일을 지우세요. r-서비스가 정말 필요하다면 chmod 600을 실행하고 "+" 항목은 절대 쓰지 마세요.

files.rhosts-homes 사용자의 .rhosts는 비공개

/home 아래 홈 디렉터리의 .rhosts 파일이 비공개인지(모드 0600 또는 더 엄격) 확인합니다. 소유자는 홈의 사용자와 비교하지 않습니다. 사용자 자신의 파일이 정상이기 때문입니다. r-서비스가 필요하지 않다면 이런 파일은 없어야 합니다.

왜 중요한가. .rhosts 파일이 있으면 해당 호스트와 사용자가 rlogin과 rsh로 비밀번호 없이 로그인할 수 있습니다.

조치 방법. 파일을 지우세요. r-서비스가 정말 필요하다면 chmod 600을 실행하고 "+" 항목은 절대 쓰지 마세요.

services.review-network-access 서비스에 접근할 수 있는 대상 검토

네트워크에서 이 호스트에 누가 접근할 수 있는지를 정하는 것들을 나열합니다. 활성화된 호스트 방화벽 서비스(firewalld, ufw, nftables, iptables, netfilter-persistent)와, 실행 중인 호스트에서는 루프백이 아닌 주소에서 대기 중인 소켓입니다.

왜 중요한가. 모든 주소에 열려 있는 서비스는 그곳까지 경로가 닿는 모든 사람에게 노출됩니다.

조치 방법. 모두를 위한 것이 아닌 서비스는 호스트 방화벽(nftables, iptables, firewalld, ufw)이나 서비스 자체의 접근 규칙(TCP wrappers, 허용 목록)으로 제한하거나, 필요한 주소에만 바인드하세요.

사람이 판단합니다. 호스트 방화벽(nftables, iptables, firewalld)이나 서비스 자체의 접근 규칙으로, 서비스가 필요한 주소의 접속만 받도록 되어 있는지 확인하세요. 목록에는 활성화된 방화벽 서비스와 루프백이 아닌 주소에서 대기 중인 소켓이 나옵니다.

files.hosts-lpd-perms /etc/hosts.lpd는 있으면 root 소유, 비공개

/etc/hosts.lpd가 있다면 root가 소유하고 모드가 0600 또는 더 엄격한지 확인합니다.

왜 중요한가. 이 파일은 인쇄를 허용할 호스트를 적은 것이어서, 바꿀 수 있는 사람은 인쇄 서비스를 다른 호스트에 열 수 있습니다.

조치 방법. 다른 호스트에서 인쇄할 필요가 없으면 /etc/hosts.lpd를 지우고, 필요하면 chown root와 chmod 600을 실행하세요.

env.umask-login-defs 기본 umask가 그룹·기타 사용자의 쓰기를 막음 (login.defs)

/etc/login.defs의 UMASK가 그룹과 다른 사용자의 쓰기 권한을 없애는지(022 또는 더 엄격한 값) 확인합니다. shadow-utils와 pam_umask가 새 세션과 홈 디렉터리에 이 값을 씁니다. 이 점검은 UMASK만 읽습니다. USERGROUPS_ENAB yes(Debian과 Red Hat 계열의 기본값)이면 기본 그룹이 자기 이름의 전용 그룹인 사용자는 그룹 쓰기 권한이 더해집니다.

왜 중요한가. umask가 느슨하면 새로 만든 파일을 다른 사용자가 수정할 수 있습니다.

조치 방법. /etc/login.defs에 UMASK 022(또는 027)을 설정하세요.

env.umask-startup-files 시작 파일이 느슨한 umask를 설정하지 않음

시스템 전체 시작 파일과 root의 시작 파일에서 그룹이나 다른 사용자에게 쓰기 권한을 남기는 umask 명령을 나열합니다. if나 case 블록 안의 것과, 검토가 필요한 기호식 umask도 포함합니다.

왜 중요한가. 시작 파일에 느슨한 umask가 있으면 모든 세션에서 시스템 기본값을 덮어씁니다.

조치 방법. umask 022(또는 더 엄격한 값)을 쓰고, 느슨한 umask와 기호식 umask는 지우세요.

homes.owner-perms 홈 디렉터리는 계정 본인 소유, 다른 사용자 쓰기 금지

로그인 셸이 있는 계정 중에서 홈 디렉터리를 다른 계정이 소유하고 있거나 다른 사용자가 쓸 수 있는 것을 나열합니다.

왜 중요한가. 홈 디렉터리에 쓸 수 있는 사람은 그 안의 시작 파일과 키를 바꿔치기할 수 있습니다.

조치 방법. 나열된 계정마다 chown 사용자 홈과 chmod o-w 홈을 실행하세요.

homes.exists 로그인 가능 계정의 홈 디렉터리 존재

로그인 셸이 있는 계정 중에서 홈 디렉터리가 없는 것을 나열합니다.

왜 중요한가. 홈 디렉터리가 없으면 사용자가 "/"로 로그인하게 되고, 시작 파일과 키가 엉뚱한 곳에 생깁니다.

조치 방법. 홈 디렉터리를 만들거나(mkhomedir_helper 사용자), 계정을 지우거나 잠그세요.

files.suspicious-hidden-names 점과 공백만으로 된 이름의 파일·디렉터리 없음

이름이 점과 공백만으로 된("."과 ".."은 제외) 파일과 디렉터리를 로컬 파일 시스템과 /dev에서 나열합니다. "..."이나 ". " 같은 이름입니다. 정상적인 용도로 이런 이름이 필요한 경우는 없으며, 이런 이름은 목록에서 디렉터리를 눈에 띄지 않게 숨깁니다.

왜 중요한가. "..."이나 ". "이라는 이름의 디렉터리는 ".", ".." 옆에서 놓치기 쉬워서 파일을 숨기는 곳이 됩니다.

조치 방법. 그 항목에 무엇이 들어 있는지 확인한 뒤 지우거나 이름을 바꾸세요.

files.review-hidden-files 숨김 파일·디렉터리 검토

이름이 "."으로 시작하는 숨김 파일은 사용자 설정을 담고 있지만, 목록에서 숨기고 싶은 것을 담아 두는 데도 쓰입니다.

왜 중요한가. 숨김 파일과 디렉터리는 예상치 못한 내용이 눈에 띄지 않고 남아 있기 쉬운 곳입니다.

조치 방법. 있어서는 안 되는 것은 지우세요.

사람이 판단합니다. 예상하지 못한 숨김 파일과 디렉터리(이름이 "."으로 시작하는 것)가 있는지 찾아보고(예: find / -xdev -name ".*" -type f), 있어서는 안 되는 것은 지우세요. 점과 공백만으로 된 이름은 files.suspicious-hidden-names가 따로 나열합니다.

services.no-finger finger 서비스 미사용

finger 서비스(fingerd, cfingerd)가 시작되는 경로를 활성화된 유닛, 지금 실행 중인 유닛, init 스크립트, inetd/xinetd 항목 중에서 서비스 이름이나 프로그램으로 찾아 나열합니다.

왜 중요한가. finger는 네트워크의 누구에게나 이 호스트의 사용자가 누구이고 언제 로그인하는지 알려 줍니다.

조치 방법. 서비스를 끄세요. inetd/xinetd 항목을 지우거나 그 유닛을 systemctl disable --now로 끕니다.

services.vsftpd-no-anonymous vsftpd가 익명 로그인을 허용하지 않음

vsftpd.conf의 anonymous_enable을 확인합니다. vsftpd는 이 값이 NO가 아니면 익명 로그인을 허용합니다(배포판 패키지의 설정은 NO로 둡니다). 기본 vsftpd.conf만 읽습니다(두 번째 기본 파일이나 그 옆의 다른 .conf가 있으면 결과는 ERROR입니다). vsftpd가 시작되어 있고 vsftpd.conf가 있을 때 적용되며, 그렇지 않으면 services.review-anonymous-sharing이 검토를 요청합니다.

왜 중요한가. 익명 FTP는 누구나 공유 파일을 읽을 수 있게 하고, 때로는 쓸 수도 있게 합니다.

조치 방법. vsftpd.conf에 anonymous_enable=NO를 설정하고 vsftpd를 다시 불러오세요.

services.samba-no-guest 게스트에게 열린 Samba 공유 없음

/etc/samba/smb.conf에서 "guest ok = yes"나 "public = yes"인 공유를 나열합니다. 그 공유에 적었거나 [global]의 기본값으로 정한 경우를 모두 봅니다. 프린터 섹션은 공유가 아닙니다. include나 config file 줄은 따라가지 않고 결과를 ERROR로 만들며, smb.conf 옆의 다른 .conf도 마찬가지입니다(smbd가 그것으로 시작되었을 수 있습니다). Samba가 시작되어 있고 smb.conf가 있을 때 적용되며, 그렇지 않으면 services.review-anonymous-sharing이 검토를 요청합니다.

왜 중요한가. 게스트에게 열린 공유는 서버에 닿을 수 있는 누구나 그 파일을 읽을 수 있게 하고, 때로는 쓸 수도 있게 합니다.

조치 방법. 공유에 guest ok = no를 설정하고(public = yes는 지우고), 필요한 사용자에게는 Samba 계정을 만들어 주세요.

services.review-anonymous-sharing 파일 공유 서비스 익명 접근 검토

다른 점검이 읽지 않는 파일 공유 서비스가 시작되어 있을 때 적용됩니다. NFS, vsftpd가 아닌 FTP 서버, 설정 파일이 없는 vsftpd나 Samba가 해당합니다(vsftpd.conf가 있는 vsftpd는 services.vsftpd-no-anonymous, smb.conf가 있는 Samba는 services.samba-no-guest가 봅니다). 설정을 검토할 수 있도록 그 서비스가 시작되는 경로를 보여 줍니다. 그 밖에는 해당하지 않습니다.

왜 중요한가. 공유 파일에 익명으로 접근할 수 있으면 누구나 그 파일을 읽을 수 있고, 때로는 쓸 수도 있습니다.

조치 방법. 나열된 서비스가 익명 접근을 허용하지 않는지 확인하세요. vsftpd는 anonymous_enable=NO, NFS는 아는 호스트만 허용하고 root_squash를 쓰기, Samba는 게스트 접근 금지입니다.

사람이 판단합니다. 나열된 서비스가 익명 접근을 허용하지 않는지 확인하세요. vsftpd는 anonymous_enable=NO, NFS는 아는 호스트만 허용하고 root_squash를 쓰기, Samba는 게스트 접근 금지입니다.

services.no-r-services r 계열 서비스 미사용

rsh, rlogin, rexec(inetd의 shell, login, exec 서비스나 그 유닛)가 시작되는 경로를 활성화된 유닛, 지금 실행 중인 유닛, init 스크립트, inetd/xinetd 항목 중에서 서비스 이름이나 프로그램으로 찾아 나열합니다.

왜 중요한가. r 계열 서비스는 비밀번호를 평문으로 보내고 주소만으로 호스트를 신뢰합니다.

조치 방법. rsh, rlogin, rexec를 끄고 SSH를 쓰세요.

files.cron-commands crontab·at 명령은 일반 사용자 실행 금지

/usr/bin/crontab과 /usr/bin/at을 root(Debian과 Ubuntu에서 at을 소유하는 daemon도 가능)가 소유하고, 다른 사용자가 실행할 수 없는지(다른 사용자의 실행 권한 없음, 모드 6750 또는 더 엄격) 확인합니다.

왜 중요한가. 예약 작업은 사용자가 사라진 뒤에도 계속 실행됩니다. 모든 사용자가 작업을 예약할 수 있으면 침입자가 흔적을 남겨 둘 수 있는 방법이 늘어납니다.

조치 방법. chmod o-x /usr/bin/crontab /usr/bin/at을 실행하고, 필요한 사용자는 파일의 그룹을 통해 허용하세요.

files.cron-files cron·at 설정 파일은 root 소유, 다른 사용자 읽기 금지

/etc/crontab, /etc/cron.d/*, 그리고 cron과 at의 허용·거부 파일을 root가 소유하고 모드가 0640 또는 더 엄격한지 확인합니다.

왜 중요한가. 이 파일들이 root 권한으로 정해진 시간에 무엇을 실행할지, 누가 작업을 예약할 수 있는지를 정합니다.

조치 방법. 나열된 파일마다 chown root와 chmod 640을 실행하세요.

files.cron-scripts cron 스크립트 디렉터리는 root 소유, 다른 사용자 쓰기 금지

/etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, /etc/cron.monthly와 그 안의 스크립트를 root가 소유하고 다른 사람은 쓸 수 없는지(모드 0755 또는 더 엄격) 확인합니다.

왜 중요한가. 이 스크립트들은 root 권한으로 정해진 시간에 실행되므로, 하나라도 바꿀 수 있는 사람은 다음 실행 때 root 권한을 얻습니다.

조치 방법. 나열된 스크립트나 디렉터리마다 chown root와 chmod go-w를 실행하세요.

files.cron-spool 사용자 crontab은 본인만 읽고 쓸 수 있음

/var/spool/cron/crontabs(Debian과 Ubuntu)의 crontab 파일을 소유자만 읽고 쓸 수 있는지(모드 0600 또는 더 엄격) 확인합니다. root의 crontab은 root가 소유해야 하며 files.cron-root-spool이 따로 확인합니다. RHEL 계열의 /var/spool/cron에 있는 사용자 crontab은 files.cron-spool-rhel이 봅니다.

왜 중요한가. 다른 사용자가 바꿀 수 있는 crontab은 그 소유자의 권한으로, root의 것이라면 root 권한으로 명령을 실행하게 됩니다.

조치 방법. 나열된 crontab마다 chmod 600을 실행하세요.

files.cron-spool-rhel RHEL 계열의 사용자 crontab은 본인만 읽고 쓸 수 있음

/var/spool/cron(RHEL 계열)의 crontab 파일을 소유자만 읽고 쓸 수 있는지(모드 0600 또는 더 엄격) 확인합니다. Debian과 Ubuntu는 /var/spool/cron/crontabs에 두며, 그쪽은 files.cron-spool이 봅니다. root의 crontab은 root가 소유해야 하며 files.cron-root-spool이 따로 확인합니다.

왜 중요한가. 다른 사용자가 바꿀 수 있는 crontab은 그 소유자의 권한으로, root의 것이라면 root 권한으로 명령을 실행하게 됩니다.

조치 방법. 나열된 crontab마다 chmod 600을 실행하세요.

files.cron-root-spool root의 crontab은 root 소유이며 root만 읽고 쓸 수 있음

root의 crontab(Debian과 Ubuntu는 /var/spool/cron/crontabs/root, RHEL 계열은 /var/spool/cron/root)을 root가 소유하고 root만 읽고 쓸 수 있는지(모드 0600 또는 더 엄격) 확인합니다.

왜 중요한가. root의 crontab을 바꿀 수 있는 사람은 root 권한으로 명령을 실행할 수 있습니다.

조치 방법. 나열된 crontab에 chown root와 chmod 600을 실행하세요.

files.at-spool at 작업 큐는 본인만 접근할 수 있음

at의 대기 작업과 순번 파일(RHEL 계열은 /var/spool/at, Debian과 Ubuntu는 /var/spool/cron/atjobs)을 소유자만 읽고 쓰고 실행할 수 있는지(모드 0700 또는 더 엄격) 확인합니다.

왜 중요한가. 다른 사용자가 바꿀 수 있는 작업은 그 작업 소유자의 권한으로 그 사용자의 명령을 실행하게 됩니다.

조치 방법. 나열된 작업마다 chmod 700을 실행하세요.

services.no-dos-prone 트래픽을 증폭하는 서비스 미사용

echo, discard, daytime, chargen 서비스가 시작되는 경로를 활성화된 유닛, 지금 실행 중인 유닛, init 스크립트, inetd/xinetd 항목 중에서 서비스 이름으로 찾아 나열합니다.

왜 중요한가. 이 테스트용 서비스들은 누구에게나 응답하므로, 공격자가 이를 거쳐 트래픽을 되돌리거나 증폭할 수 있습니다.

조치 방법. inetd/xinetd에서 끄세요(disable = yes).

services.no-nfs-server NFS 서버 미사용

NFS 서버가 시작되는 경로를 활성화된 유닛, 지금 실행 중인 유닛, init 스크립트, inetd/xinetd 항목 중에서 서비스 이름이나 프로그램으로 찾아 나열합니다.

왜 중요한가. NFS 서버는 파일을 네트워크로 공유하므로, 필요한 곳이 없다면 노출만 늘립니다.

조치 방법. 이 공유를 쓰는 클라이언트가 없다면 끄세요(systemctl disable --now nfs-server).

services.nfs-exports-restricted NFS 공유가 필요한 호스트로 제한됨

/etc/exports와 /etc/exports.d/*.exports의 항목 중에서 모든 호스트에 열려 있는 것(클라이언트가 "*"이거나, /srv (rw)처럼 옵션만 있는 경우. 괄호 앞에 공백을 넣는 흔한 실수입니다)과, 원격 root가 root로 동작하게 하는 것(no_root_squash)을 나열합니다. 실행 중에 exportfs로 추가한 공유는 이 파일들에 없습니다. NFS 서버가 시작되어 있고 /etc/exports나 /etc/exports.d가 있을 때 적용되며, 그렇지 않으면 services.review-nfs-other가 검토를 요청합니다.

왜 중요한가. 모두에게 열려 있거나 root_squash가 없는 공유는 네트워크의 어떤 호스트에든 공유 파일을 넘겨줍니다.

조치 방법. 공유마다 필요한 호스트나 네트워크를 나열하고(/srv/data 192.0.2.0/24(rw)), 괄호 앞에는 공백을 넣지 말고, root_squash를 유지하세요.

services.review-nfs-other NFS 공유 설정 검토

NFS 서버가 시작되어 있는데 /etc/exports와 /etc/exports.d가 없을 때 적용됩니다(공유를 부팅 때 exportfs로 만드는 등 다른 방식으로 만들었을 수 있습니다). 검토할 수 있도록 서버가 시작된 경로를 보여 줍니다. export 파일이 있으면 services.nfs-exports-restricted가 판단합니다. 그 밖에는 해당하지 않습니다.

왜 중요한가. 모두에게 열려 있거나 root_squash가 없는 공유는 네트워크의 어떤 호스트에든 공유 파일을 넘겨줍니다.

조치 방법. 공유를 확인하세요(exportfs -v). 각 공유가 필요한 호스트로만 제한되어 있고, "*"는 쓰지 않으며, root_squash를 쓰는지 봅니다.

사람이 판단합니다. 공유를 확인하세요(exportfs -v). 각 공유가 필요한 호스트로만 제한되어 있고, "*"는 쓰지 않으며, root_squash를 쓰는지 봅니다.

services.no-automount 자동 마운터(autofs) 미사용

자동 마운터(autofs)가 시작되는 경로를 활성화된 유닛, 지금 실행 중인 유닛, init 스크립트, inetd/xinetd 항목 중에서 서비스 이름이나 프로그램으로 찾아 나열합니다.

왜 중요한가. 자동 마운터는 접근할 때 파일 시스템을 마운트하므로, 로컬이나 원격 파일 시스템이 뜻하지 않게 드러날 수 있습니다.

조치 방법. 필요한 것이 없다면 autofs를 끄세요(systemctl disable --now autofs).

services.no-rpc 불필요한 RPC 서비스 미사용

오래된 RPC 서비스(rusersd, rwalld, sprayd, rstatd, rexd, CDE 달력과 tooltalk 데몬, sadmind, pcnfsd, ypupdated, rquotad, nisd)가 시작되는 경로를 활성화된 유닛, 지금 실행 중인 유닛, init 스크립트, inetd/xinetd 항목 중에서 서비스 이름이나 프로그램으로 찾아 나열합니다.

왜 중요한가. 이 RPC 서비스들은 원격 공격 사례가 오래 쌓였고 필요한 경우가 드뭅니다. rpc.statd는 NFS 클라이언트가 파일 잠금에 쓰므로 나열하지 않습니다(NFS 서버는 services.no-nfs-server가 봅니다).

조치 방법. 나열된 서비스를 모두 끄세요.

services.no-nis NIS 서비스 미사용

NIS 서버와 클라이언트 데몬(ypserv, ypbind, yppasswdd, ypxfrd)이 시작되는 경로를 활성화된 유닛, 지금 실행 중인 유닛, init 스크립트, inetd/xinetd 항목 중에서 서비스 이름이나 프로그램으로 찾아 나열합니다.

왜 중요한가. NIS는 비밀번호 해시를 포함한 계정 정보를 약한 보호만으로 내어 줍니다.

조치 방법. NIS 데몬을 끄고, TLS 위의 LDAP처럼 암호화하는 디렉터리 서비스를 쓰세요.

services.no-tftp-talk tftp, talk 서비스 미사용

tftp, talk, ntalk 서비스가 시작되는 경로를 활성화된 유닛, 지금 실행 중인 유닛, init 스크립트, inetd/xinetd 항목 중에서 서비스 이름이나 프로그램으로 찾아 나열합니다.

왜 중요한가. tftp는 인증 없이 파일을 내어 주고, talk는 오래되어 필요 없는 채팅 서비스입니다.

조치 방법. 이 서비스들을 끄세요.

services.review-mail-server 메일 서버 설정 검토

메일 서버가 시작되어 있을 때 적용됩니다. 설정을 검토할 수 있도록 그 서버가 시작된 경로와 설치된 패키지의 버전을 보여 줍니다. 그 밖에는 해당하지 않습니다.

왜 중요한가. 오래되었거나 열려 있는 메일 서버는 스팸을 보내고 계정을 알아내는 데 쓰입니다.

조치 방법. 메일 서버가 최신 상태인지, 자기 네트워크와 인증된 사용자만 대신 중계하는지, EXPN과 VRFY를 거부하는지, 큐 실행을 메일 시스템에만 허용하는지 확인하세요(Sendmail은 PrivacyOptions restrictqrun, noexpn, novrfy).

사람이 판단합니다. 메일 서버가 최신 상태인지, 자기 네트워크와 인증된 사용자만 대신 중계하는지, EXPN과 VRFY를 거부하는지, 큐 실행을 메일 시스템에만 허용하는지 확인하세요(Sendmail은 PrivacyOptions restrictqrun, noexpn, novrfy).

services.review-mail-server 메일 서버 설정 검토

메일 서버가 시작되어 있을 때 적용됩니다. 설정을 검토할 수 있도록 그 서버가 시작된 경로와 설치된 패키지의 버전을 보여 줍니다. 그 밖에는 해당하지 않습니다.

왜 중요한가. 오래되었거나 열려 있는 메일 서버는 스팸을 보내고 계정을 알아내는 데 쓰입니다.

조치 방법. 메일 서버가 최신 상태인지, 자기 네트워크와 인증된 사용자만 대신 중계하는지, EXPN과 VRFY를 거부하는지, 큐 실행을 메일 시스템에만 허용하는지 확인하세요(Sendmail은 PrivacyOptions restrictqrun, noexpn, novrfy).

사람이 판단합니다. 메일 서버가 최신 상태인지, 자기 네트워크와 인증된 사용자만 대신 중계하는지, EXPN과 VRFY를 거부하는지, 큐 실행을 메일 시스템에만 허용하는지 확인하세요(Sendmail은 PrivacyOptions restrictqrun, noexpn, novrfy).

services.postfix-no-open-relay Postfix가 아무에게나 메일을 중계하지 않음

/etc/postfix/main.cf에서 Postfix를 오픈 릴레이로 만드는 두 가지 방식을 읽습니다. 모든 주소와 맞는 항목(프리픽스 길이 0)이 있는 mynetworks와, reject_unauth_destination, defer_unauth_destination, 단독 reject나 defer가 먼저 나오지 않은 채 단독 permit이나 목록의 끝(허용으로 끝납니다)에 이르는 릴레이 목록(smtpd_relay_restrictions)입니다. 수신자 목록이 거부하는 경우는 예외입니다. Postfix 2.10 이후의 기본값은 안전하므로, main.cf가 설정한 것만 이 점검을 실패시킬 수 있습니다. 따라가지 않는 것은 조회 테이블(hash:와 cidr: 항목), 정책 서비스, mynetworks_style입니다. 이 매개변수 중 하나를 덮어쓰는 master.cf 옵션이 있으면 main.cf만으로는 판단할 수 없으므로 결과는 ERROR입니다. Postfix가 시작되어 있고 main.cf가 있을 때 적용되며, 다른 메일 서버는 services.review-mail-relay-other가 봅니다.

왜 중요한가. 오픈 릴레이는 누구의 스팸이든 대신 보내 주므로 서버가 차단당합니다.

조치 방법. mynetworks를 자기 네트워크로 정하고, 릴레이 제한을 defer_unauth_destination(또는 reject_unauth_destination)으로 끝내세요. 그보다 앞에 단독 permit을 두지 말고, 이것 없이 목록이 끝나지 않게 하세요.

services.review-mail-relay-other 메일 서버의 중계·VRFY 설정 검토

Postfix가 아닌 메일 서버가 시작되어 있거나, Postfix가 시작되어 있는데 /etc/postfix/main.cf가 없을 때 적용됩니다(main.cf가 있는 Postfix는 services.postfix-no-open-relay와 services.postfix-no-vrfy가 봅니다). 설정을 검토할 수 있도록 그 서버가 시작된 경로를 보여 줍니다. 그 밖에는 해당하지 않습니다.

왜 중요한가. 열려 있는 메일 서버는 스팸을 보내고 계정을 알아내는 데 쓰입니다.

조치 방법. 메일 서버가 자기 네트워크와 인증된 사용자만 대신 중계하는지, EXPN과 VRFY를 거부하는지 확인하세요(Sendmail은 PrivacyOptions noexpn, novrfy).

사람이 판단합니다. 메일 서버가 자기 네트워크와 인증된 사용자만 대신 중계하는지, EXPN과 VRFY를 거부하는지 확인하세요(Sendmail은 PrivacyOptions noexpn, novrfy).

services.postfix-no-vrfy Postfix가 VRFY 명령에 응답하지 않음

/etc/postfix/main.cf의 disable_vrfy_command를 확인합니다. Postfix는 이 값이 yes(또는 on, true, 1)가 아니면 주소가 존재하는지 알려 주는 VRFY에 응답합니다. 이를 덮어쓰는 master.cf 옵션이 있으면 결과는 ERROR입니다. Postfix가 시작되어 있고 main.cf가 있을 때 적용되며, 다른 메일 서버는 services.review-mail-relay-other가 봅니다.

왜 중요한가. VRFY가 있으면 누구나 서버에 어떤 계정이 있는지 시험해 볼 수 있습니다.

조치 방법. /etc/postfix/main.cf에 disable_vrfy_command = yes를 설정하고 Postfix를 다시 불러오세요.

services.review-mail-relay-other 메일 서버의 중계·VRFY 설정 검토

Postfix가 아닌 메일 서버가 시작되어 있거나, Postfix가 시작되어 있는데 /etc/postfix/main.cf가 없을 때 적용됩니다(main.cf가 있는 Postfix는 services.postfix-no-open-relay와 services.postfix-no-vrfy가 봅니다). 설정을 검토할 수 있도록 그 서버가 시작된 경로를 보여 줍니다. 그 밖에는 해당하지 않습니다.

왜 중요한가. 열려 있는 메일 서버는 스팸을 보내고 계정을 알아내는 데 쓰입니다.

조치 방법. 메일 서버가 자기 네트워크와 인증된 사용자만 대신 중계하는지, EXPN과 VRFY를 거부하는지 확인하세요(Sendmail은 PrivacyOptions noexpn, novrfy).

사람이 판단합니다. 메일 서버가 자기 네트워크와 인증된 사용자만 대신 중계하는지, EXPN과 VRFY를 거부하는지 확인하세요(Sendmail은 PrivacyOptions noexpn, novrfy).

services.review-dns-server DNS 서버 설정 검토

DNS 서버가 시작되어 있을 때 적용됩니다. 설정을 검토할 수 있도록 그 서버가 시작된 경로와 설치된 패키지의 버전을 보여 줍니다. 그 밖에는 해당하지 않습니다.

왜 중요한가. 존 전송은 공격자에게 네트워크 지도를 건네고, 열린 동적 업데이트는 그것을 바꾸게 합니다.

조치 방법. DNS 서버가 최신 상태인지, 존 전송을 secondary에게만 허용하는지(BIND의 allow-transfer), 동적 업데이트를 키가 있을 때만 허용하거나 막는지(allow-update, update-policy) 확인하세요.

사람이 판단합니다. DNS 서버가 최신 상태인지, 존 전송을 secondary에게만 허용하는지(BIND의 allow-transfer), 동적 업데이트를 키가 있을 때만 허용하거나 막는지(allow-update, update-policy) 확인하세요.

services.bind-restrict-transfer BIND 존 전송이 제한됨

/etc/named.conf(또는 /etc/bind/named.conf)와 그 파일이 포함하는 파일에서, 아무 호스트나 존 전송을 받을 수 있는 primary와 secondary 존을 나열합니다. 존에 allow-transfer가 적용되지 않거나(BIND는 이때 모두에게 허용합니다) any를 포함하는 경우입니다. allow-transfer는 존, 그 view, options에서 읽고 acl 이름도 따라갑니다. 모든 설치가 호스트 자신을 위해 정의하는 존(localhost와 루프백 역방향 존)은 뺍니다. BIND가 시작되어 있고 설정이 있을 때 적용되며, 다른 DNS 서버는 services.review-dns-other가 봅니다.

왜 중요한가. 존 전송은 존의 모든 이름을 넘겨주므로, 공격자에게 네트워크 지도를 건네는 셈입니다.

조치 방법. options에 allow-transfer { none; };을 설정하고, 전송이 필요한 존에는 secondary(또는 TSIG 키)를 지정하세요.

services.review-dns-other DNS 서버의 존 전송·업데이트 설정 검토

BIND가 아닌 DNS 서버가 시작되어 있거나, BIND가 시작되어 있는데 일반적인 위치에 named.conf가 없을 때 적용됩니다(설정이 있는 BIND는 services.bind-restrict-transfer와 services.bind-restrict-update가 봅니다). 설정을 검토할 수 있도록 서버가 시작된 경로를 보여 줍니다. 그 밖에는 해당하지 않습니다.

왜 중요한가. 존 전송은 공격자에게 네트워크 지도를 건네고, 열린 동적 업데이트는 그것을 바꾸게 합니다.

조치 방법. DNS 서버가 존 전송을 secondary에게만 허용하고, 동적 업데이트는 키가 있을 때만 허용하거나 아예 막는지 확인하세요.

사람이 판단합니다. DNS 서버가 존 전송을 secondary에게만 허용하고, 동적 업데이트는 키가 있을 때만 허용하거나 아예 막는지 확인하세요.

services.bind-restrict-update BIND 동적 업데이트가 제한됨

/etc/named.conf(또는 /etc/bind/named.conf)와 그 파일이 포함하는 파일에서, allow-update에 any가 들어 있는 primary 존을 나열합니다. allow-update나 update-policy를 설정하지 않으면 동적 업데이트는 꺼져 있습니다. 주소, 키, update-policy는 제한한 것으로 봅니다. BIND가 시작되어 있고 설정이 있을 때 적용되며, 다른 DNS 서버는 services.review-dns-other가 봅니다.

왜 중요한가. 존을 업데이트할 수 있는 사람은 그 존의 이름을 자기 호스트로 돌릴 수 있습니다.

조치 방법. 키(allow-update { key dhcp-updates; };)나 update-policy가 있을 때만 업데이트를 허용하거나, allow-update를 지우세요.

services.review-dns-other DNS 서버의 존 전송·업데이트 설정 검토

BIND가 아닌 DNS 서버가 시작되어 있거나, BIND가 시작되어 있는데 일반적인 위치에 named.conf가 없을 때 적용됩니다(설정이 있는 BIND는 services.bind-restrict-transfer와 services.bind-restrict-update가 봅니다). 설정을 검토할 수 있도록 서버가 시작된 경로를 보여 줍니다. 그 밖에는 해당하지 않습니다.

왜 중요한가. 존 전송은 공격자에게 네트워크 지도를 건네고, 열린 동적 업데이트는 그것을 바꾸게 합니다.

조치 방법. DNS 서버가 존 전송을 secondary에게만 허용하고, 동적 업데이트는 키가 있을 때만 허용하거나 아예 막는지 확인하세요.

사람이 판단합니다. DNS 서버가 존 전송을 secondary에게만 허용하고, 동적 업데이트는 키가 있을 때만 허용하거나 아예 막는지 확인하세요.

services.no-telnet 텔넷 서비스 미사용

telnet 서비스가 시작되는 경로를 활성화된 유닛, 지금 실행 중인 유닛, init 스크립트, inetd/xinetd 항목 중에서 서비스 이름이나 프로그램으로 찾아 나열합니다.

왜 중요한가. 텔넷은 비밀번호와 세션을 평문으로 보냅니다.

조치 방법. 텔넷을 끄고 SSH를 쓰세요.

services.vsftpd-banner vsftpd 접속 배너에 버전이 없음

vsftpd가 접속한 클라이언트에게 무엇을 알려 주는지 확인합니다. ftpd_banner나 banner_file이 없으면 "(vsFTPd x.y.z)"라고 알립니다. 버전 번호나 vsftpd라는 이름이 아직 들어 있는 직접 쓴 문구나 파일도 실패합니다. 기본 vsftpd.conf만 읽습니다(두 번째 기본 파일이나 그 옆의 다른 .conf가 있으면 결과는 ERROR입니다). vsftpd가 시작되어 있고 vsftpd.conf가 있을 때 적용되며, 다른 FTP 서버는 services.review-ftp-other가 봅니다.

왜 중요한가. 버전이 적힌 배너는 공격자에게 어떤 공격을 시도할지 알려 줍니다.

조치 방법. vsftpd.conf에 버전 번호도 vsftpd라는 이름도 없는 ftpd_banner=Authorized users only.를 설정하세요.

services.review-ftp-other FTP 서버의 배너·암호화·root 로그인 설정 검토

vsftpd가 아닌 FTP 서버가 시작되어 있거나, vsftpd가 시작되어 있는데 vsftpd.conf가 없을 때 적용됩니다(설정이 있는 vsftpd는 services.vsftpd-banner, services.vsftpd-tls, services.vsftpd-no-root가 봅니다). 설정을 검토할 수 있도록 그 서버가 시작된 경로를 보여 줍니다. 그 밖에는 해당하지 않습니다.

왜 중요한가. 일반 FTP는 비밀번호를 평문으로 보내고, 버전이 적힌 배너는 공격자에게 어떤 공격을 시도할지 알려 주며, FTP로 root가 로그인하면 호스트가 위험해집니다.

조치 방법. FTP 서버가 TLS를 요구하는지(또는 SFTP로 대체했는지), 배너에 버전을 감추는지, root를 거부하는지(ftpusers) 확인하세요.

사람이 판단합니다. FTP 서버가 TLS를 요구하는지(또는 SFTP로 대체했는지), 배너에 버전을 감추는지, root를 거부하는지(ftpusers) 확인하세요.

services.vsftpd-tls vsftpd가 TLS를 요구함

vsftpd.conf의 ssl_enable과, 로컬 로그인이 여전히 TLS를 쓰도록 강제되는지(force_local_logins_ssl, 기본값은 YES)를 확인합니다. 일반 FTP는 비밀번호와 파일을 평문으로 보냅니다. 기본 vsftpd.conf만 읽습니다(두 번째 기본 파일이나 그 옆의 다른 .conf가 있으면 결과는 ERROR입니다). vsftpd가 시작되어 있고 vsftpd.conf가 있을 때 적용되며, 다른 FTP 서버는 services.review-ftp-other가 봅니다.

왜 중요한가. 일반 FTP는 비밀번호를 평문으로 보냅니다.

조치 방법. vsftpd.conf에 ssl_enable=YES와 인증서(rsa_cert_file)를 설정하거나, FTP를 SFTP로 대체하세요.

services.review-ftp-other FTP 서버의 배너·암호화·root 로그인 설정 검토

vsftpd가 아닌 FTP 서버가 시작되어 있거나, vsftpd가 시작되어 있는데 vsftpd.conf가 없을 때 적용됩니다(설정이 있는 vsftpd는 services.vsftpd-banner, services.vsftpd-tls, services.vsftpd-no-root가 봅니다). 설정을 검토할 수 있도록 그 서버가 시작된 경로를 보여 줍니다. 그 밖에는 해당하지 않습니다.

왜 중요한가. 일반 FTP는 비밀번호를 평문으로 보내고, 버전이 적힌 배너는 공격자에게 어떤 공격을 시도할지 알려 주며, FTP로 root가 로그인하면 호스트가 위험해집니다.

조치 방법. FTP 서버가 TLS를 요구하는지(또는 SFTP로 대체했는지), 배너에 버전을 감추는지, root를 거부하는지(ftpusers) 확인하세요.

사람이 판단합니다. FTP 서버가 TLS를 요구하는지(또는 SFTP로 대체했는지), 배너에 버전을 감추는지, root를 거부하는지(ftpusers) 확인하세요.

services.ftp-account-shell ftp 계정 로그인 셸 제한

ftp 계정이 있다면 셸이 /sbin/nologin이나 /bin/false 같은 것인지 확인합니다.

왜 중요한가. ftp 계정은 익명 FTP를 위한 것인데, 로그인 셸이 있으면 침입 경로가 될 수 있습니다.

조치 방법. usermod -s /sbin/nologin ftp를 실행하세요.

services.review-ftp-server FTP 서버 설정 검토

FTP 서버가 시작되어 있을 때 적용됩니다. 설정을 검토할 수 있도록 그 서버가 시작된 경로를 보여 줍니다. 그 밖에는 해당하지 않습니다.

왜 중요한가. 일반 FTP는 비밀번호를 평문으로 보내고, 버전이 적힌 배너는 공격자에게 어떤 공격을 시도할지 알려 줍니다.

조치 방법. FTP 서버가 TLS를 요구하는지(또는 SFTP로 대체했는지), 배너에 버전을 감추는지, 필요한 주소의 접속만 받는지, root를 거부하는지(ftpusers, user_list) 확인하세요.

사람이 판단합니다. FTP 서버가 TLS를 요구하는지(또는 SFTP로 대체했는지), 배너에 버전을 감추는지, 필요한 주소의 접속만 받는지, root를 거부하는지(ftpusers, user_list) 확인하세요.

services.vsftpd-no-root root가 vsftpd에 로그인할 수 없음

root가 거부되는지 확인합니다. FTP 서비스의 PAM 스택에 root를 담은 파일(/etc/ftpusers, /etc/vsftpd/ftpusers)을 가리키는 pam_listfile 줄(item=user, sense=deny)이 있거나, userlist_enable 때문에 vsftpd가 root를 거부하는 경우입니다(root가 들어 있는 사용자 목록에 userlist_deny=YES이거나, 들어 있지 않은 목록에 userlist_deny=NO). 중첩된 PAM include는 따라가지 않으며, root가 pam_listfile을 건너뛰게 할 수 있는 규칙(sufficient, include)이 그 앞에 있으면 결과는 ERROR입니다. 기본 vsftpd.conf만 읽습니다(두 번째 기본 파일이나 그 옆의 다른 .conf가 있으면 결과는 ERROR입니다). vsftpd가 시작되어 있고 vsftpd.conf가 있을 때 적용되며, 다른 FTP 서버는 services.review-ftp-other가 봅니다.

왜 중요한가. FTP로 보내는 root 비밀번호는 TLS를 쓰더라도, 로그인 한 번에 호스트 전체의 운명이 달리게 만듭니다.

조치 방법. root를 /etc/ftpusers(또는 /etc/vsftpd/ftpusers)에 올리고, vsftpd PAM 서비스의 pam_listfile 줄을 유지하세요.

services.review-ftp-other FTP 서버의 배너·암호화·root 로그인 설정 검토

vsftpd가 아닌 FTP 서버가 시작되어 있거나, vsftpd가 시작되어 있는데 vsftpd.conf가 없을 때 적용됩니다(설정이 있는 vsftpd는 services.vsftpd-banner, services.vsftpd-tls, services.vsftpd-no-root가 봅니다). 설정을 검토할 수 있도록 그 서버가 시작된 경로를 보여 줍니다. 그 밖에는 해당하지 않습니다.

왜 중요한가. 일반 FTP는 비밀번호를 평문으로 보내고, 버전이 적힌 배너는 공격자에게 어떤 공격을 시도할지 알려 주며, FTP로 root가 로그인하면 호스트가 위험해집니다.

조치 방법. FTP 서버가 TLS를 요구하는지(또는 SFTP로 대체했는지), 배너에 버전을 감추는지, root를 거부하는지(ftpusers) 확인하세요.

사람이 판단합니다. FTP 서버가 TLS를 요구하는지(또는 SFTP로 대체했는지), 배너에 버전을 감추는지, root를 거부하는지(ftpusers) 확인하세요.

services.no-snmp 필요하지 않으면 SNMP 서비스를 시작하지 않음

SNMP 에이전트(snmpd)가 시작되는 경로를 활성화된 유닛, 지금 실행 중인 유닛, init 스크립트, inetd/xinetd 항목 중에서 서비스 이름이나 프로그램으로 찾아 나열합니다.

왜 중요한가. SNMP 에이전트는 시스템 정보를 드러내고, 설정이 잘못되면 다른 사람이 설정을 바꿀 수 있게 합니다.

조치 방법. SNMP로 이 호스트를 감시하는 것이 없다면 snmpd를 끄세요. 필요하다면 이 점검을 예외(waiver)로 두고 snmpd를 안전하게 설정하세요.

services.snmp-v3-only SNMP 에이전트에 SNMPv1·v2c 접근이 없음

/etc/snmp/snmpd.conf와 그 파일이 포함하는 파일에서 SNMPv1과 v2c 접근 항목(rocommunity, rwcommunity, authcommunity, com2sec)을 나열합니다. v1과 v2c는 community 문자열을 평문으로 보내고 사용자를 인증할 수 없습니다. SNMPv3 사용자(rouser, rwuser)의 보안 수준은 판단하지 않습니다. 에이전트가 시작되어 있고 설정이 일반적인 위치에 있을 때 적용되며, 그렇지 않으면 services.review-snmp-agent가 검토를 요청합니다.

왜 중요한가. community 문자열을 엿본 사람은 에이전트가 드러내는 정보를 읽을 수 있고, rwcommunity라면 바꿀 수도 있습니다.

조치 방법. community 줄을 지우고, SNMPv3 사용자를 만든 뒤(net-snmp-create-v3-user) 그 사용자에게 authPriv로 rouser나 rwuser 줄을 주세요.

services.review-snmp-agent SNMP 에이전트 설정 검토

SNMP 에이전트가 시작되어 있는데 /etc/snmp/snmpd.conf가 없을 때 적용됩니다(설정을 다른 곳에서 가져올 수 있습니다). 설정을 검토할 수 있도록 에이전트가 시작된 경로를 보여 줍니다. 파일이 있으면 services.snmp-v3-only, services.snmp-community-strong, services.snmp-access-restricted가 판단합니다. 그 밖에는 해당하지 않습니다.

왜 중요한가. SNMP v1/v2c의 community는 평문으로 오가고, 기본 community는 스캐너가 가장 먼저 시도하는 것입니다.

조치 방법. SNMP 에이전트가 인증과 암호화가 있는 SNMPv3만 받는지, 기본값이나 추측하기 쉬운 community를 쓰지 않는지, 필요한 관리 호스트에게만 응답하는지 확인하세요.

사람이 판단합니다. SNMP 에이전트가 인증과 암호화가 있는 SNMPv3만 받는지, 기본값이나 추측하기 쉬운 community를 쓰지 않는지, 필요한 관리 호스트에게만 응답하는지 확인하세요.

services.snmp-community-strong SNMP community 문자열은 추측하기 어려움

/etc/snmp/snmpd.conf와 그 파일이 포함하는 파일에서, 잘 알려진 이름(public, private 등)이거나 8자보다 짧은 community 문자열을 나열합니다. 문자열 자체는 결과에 담지 않습니다. 에이전트가 시작되어 있고 설정이 일반적인 위치에 있을 때 적용됩니다.

왜 중요한가. 기본 community 이름은 스캐너가 가장 먼저 시도하는 것이고, 짧은 문자열은 추측으로 뚫립니다.

조치 방법. 무작위 문자 8자 이상으로 community를 정하거나, SNMPv3으로 옮기세요(services.snmp-v3-only).

services.review-snmp-agent SNMP 에이전트 설정 검토

SNMP 에이전트가 시작되어 있는데 /etc/snmp/snmpd.conf가 없을 때 적용됩니다(설정을 다른 곳에서 가져올 수 있습니다). 설정을 검토할 수 있도록 에이전트가 시작된 경로를 보여 줍니다. 파일이 있으면 services.snmp-v3-only, services.snmp-community-strong, services.snmp-access-restricted가 판단합니다. 그 밖에는 해당하지 않습니다.

왜 중요한가. SNMP v1/v2c의 community는 평문으로 오가고, 기본 community는 스캐너가 가장 먼저 시도하는 것입니다.

조치 방법. SNMP 에이전트가 인증과 암호화가 있는 SNMPv3만 받는지, 기본값이나 추측하기 쉬운 community를 쓰지 않는지, 필요한 관리 호스트에게만 응답하는지 확인하세요.

사람이 판단합니다. SNMP 에이전트가 인증과 암호화가 있는 SNMPv3만 받는지, 기본값이나 추측하기 쉬운 community를 쓰지 않는지, 필요한 관리 호스트에게만 응답하는지 확인하세요.

services.snmp-access-restricted SNMP는 필요한 호스트에만 응답

/etc/snmp/snmpd.conf와 그 파일이 포함하는 파일에서, 에이전트가 agentAddress로 호스트 자신에게만 한정되어 있지 않은데 모든 출발지 주소에 응답하는 community 항목을 나열합니다. 실행 중인 호스트에서는 다른 호스트에게 열린 UDP 161번 포트 소켓도 한정되지 않은 것으로 봅니다. 명령줄의 대기 주소(예: /etc/default/snmpd)가 agentAddress를 덮어쓰기 때문입니다. 에이전트가 시작되어 있고 설정이 일반적인 위치에 있을 때 적용됩니다.

왜 중요한가. community 문자열만 맞으면 어떤 주소에든 응답하는 에이전트는 닿을 수 있는 누구나 질의할 수 있습니다.

조치 방법. 각 community에 관리 네트워크를 출발지로 지정하세요(rocommunity 이름 10.0.0.0/8). 호스트 자신만 필요하다면 agentAddress udp:127.0.0.1:161을 설정하세요.

services.review-snmp-agent SNMP 에이전트 설정 검토

SNMP 에이전트가 시작되어 있는데 /etc/snmp/snmpd.conf가 없을 때 적용됩니다(설정을 다른 곳에서 가져올 수 있습니다). 설정을 검토할 수 있도록 에이전트가 시작된 경로를 보여 줍니다. 파일이 있으면 services.snmp-v3-only, services.snmp-community-strong, services.snmp-access-restricted가 판단합니다. 그 밖에는 해당하지 않습니다.

왜 중요한가. SNMP v1/v2c의 community는 평문으로 오가고, 기본 community는 스캐너가 가장 먼저 시도하는 것입니다.

조치 방법. SNMP 에이전트가 인증과 암호화가 있는 SNMPv3만 받는지, 기본값이나 추측하기 쉬운 community를 쓰지 않는지, 필요한 관리 호스트에게만 응답하는지 확인하세요.

사람이 판단합니다. SNMP 에이전트가 인증과 암호화가 있는 SNMPv3만 받는지, 기본값이나 추측하기 쉬운 community를 쓰지 않는지, 필요한 관리 호스트에게만 응답하는지 확인하세요.

files.review-login-banners 로그인 배너 검토

배너 파일(/etc/issue, /etc/issue.net, /etc/motd)의 첫 줄, 시스템 정보를 드러내는지(getty 이스케이프 \S, \s, \r, \v, \m, \n), 그리고 SSH의 Banner 설정을 보여 줍니다. 문구가 오남용을 경고하는지는 사람이 판단합니다.

왜 중요한가. 허가받지 않은 사용을 금지한다는 경고는 침입자에 대한 조치를 뒷받침하고, 시스템이나 커널 이름을 알려 주는 배너는 공격자에게 도움이 됩니다.

조치 방법. /etc/issue, /etc/issue.net, /etc/motd에 시스템 이스케이프 없이 조직의 경고 문구를 넣고, sshd_config에 Banner /etc/issue.net을 설정하세요.

사람이 판단합니다. /etc/issue, /etc/issue.net, /etc/motd와 SSH 배너가 조직의 경고 문구를 보여 주고 시스템 정보는 드러내지 않는지 확인하세요. 목록에는 각 파일이 무엇으로 시작하는지 나옵니다.

files.sudoers-perms sudoers 파일은 root 소유, 다른 사용자 쓰기 금지

/etc/sudoers와 /etc/sudoers.d의 파일을 root가 소유하고 모드가 0640 또는 더 엄격한지 확인합니다.

왜 중요한가. sudo 규칙을 바꿀 수 있는 사람은 스스로 root가 될 수 있습니다.

조치 방법. 각 파일에 chown root와 chmod 440을 실행하세요(visudo는 이 모드를 유지합니다).

services.review-security-updates 보안 업데이트 적용 방식 검토

호스트가 업데이트를 적용하는 수단을 보여 줍니다. 릴리스와 그 릴리스가 vmsctl이 검증한 배포판 목록에 있는지, 그리고 활성화된 자동 업데이트 서비스(unattended-upgrades, apt-daily-upgrade, dnf-automatic, yum-cron)입니다. 업데이트가 제때 실제로 적용되는지는 사람이 확인해야 합니다.

왜 중요한가. 패치하지 않은 호스트는 이미 고쳐진 취약점으로 공격당합니다.

조치 방법. 보안 업데이트를 정해진 주기로(Debian과 Ubuntu는 unattended-upgrades, RHEL 계열은 dnf-automatic) 또는 조직의 패치 절차로 적용하고, 더 이상 업데이트를 받지 못하는 릴리스에서는 옮겨 가세요.

사람이 판단합니다. 보안 업데이트가 정기적으로 적용되는지(예: apt list --upgradable 또는 dnf updateinfo list --security)와 릴리스가 아직 지원되는지 확인하세요. 목록에는 릴리스와 활성화된 자동 업데이트 서비스가 나옵니다.

services.time-sync 시각 동기화 서비스 사용

chrony, ntpd, ntpsec, systemd-timesyncd 중 하나가 (유닛이나 init 스크립트로) 활성화되어 있거나, 실행 중인 호스트에서는 실행되고 있는지 확인합니다. 어떤 서버를 쓰는지는 services.review-time-sync가 봅니다.

왜 중요한가. 시계가 어긋난 호스트들의 로그는 서로 맞춰 볼 수 없고, 시간에 의존하는 프로토콜이 실패합니다.

조치 방법. 시각 동기화 서비스를 켜세요(systemctl enable --now chronyd).

services.review-time-sync 시각 동기화 서버 검토

시작된 시각 동기화 서비스를 보여 주어, 그 서버가 조직의 기준에 맞는지 확인하게 합니다.

왜 중요한가. 동기화된 시계는 그것이 따르는 서버만큼만 믿을 수 있습니다.

조치 방법. 서비스가 조직이 승인한 시각 동기화 서버를 가리키게 하세요(server나 pool 줄).

사람이 판단합니다. 시간 서비스가 조직이 승인한 서버를 쓰는지 확인하세요(chrony.conf, ntp.conf, timesyncd.conf).

files.review-logging-rules 로그 수집 규칙 검토

켜져 있는 로그 서비스(rsyslog, syslog-ng, systemd-journald)와 /etc/rsyslog.conf 및 그 파일이 포함하는 파일의 선택 규칙을, 각 규칙이 메시지를 어디로 보내는지와 함께 보여 줍니다. 정책이 요구하는 것을 기록하는지는 사람이 판단합니다.

왜 중요한가. 로그인, 권한 있는 명령, 시스템 이벤트의 로그가 없으면 침입이 일어나도 조사할 것이 남지 않습니다.

조치 방법. 인증(auth, authpriv), 권한 있는 명령, 시스템 이벤트를 파일이나 로그 서버에 기록하고, 정책이 요구하는 기간 동안 보관하세요.

사람이 판단합니다. syslog 설정이 정책대로 인증, 권한 있는 명령, 시스템 이벤트를 기록하는지, 로그를 충분히 오래 보관하는지 확인하세요. 목록에는 켜져 있는 로그 서비스와 rsyslog의 규칙이 나옵니다.

files.log-world-writable 로그 파일을 모든 사용자가 수정할 수 없음

/var/log 아래에서 모든 사용자가 쓸 수 있는 파일과 디렉터리(스티키 비트가 없는 디렉터리)를 나열합니다. 소유자는 files.review-log-files가 따로 봅니다.

왜 중요한가. 로그를 바꿀 수 있는 사람은 자기가 한 일의 흔적을 지울 수 있습니다.

조치 방법. 다른 사용자의 쓰기 권한을 없애거나(chmod o-w), 여럿이 쓰는 디렉터리에는 스티키 비트를 설정하세요(chmod +t).

files.review-log-files 로그 파일 소유자 검토

/var/log 아래에서 root가 소유하지 않은 파일과 디렉터리를 나열합니다.

왜 중요한가. 로그인 계정이 소유한 로그는 그 계정을 쓰는 사람이 고쳐 쓸 수 있습니다. 로그를 쓰는 서비스가 소유하는 것은 정상입니다.

조치 방법. 다른 계정으로 로그를 쓰는 서비스가 없는 로그에는 chown root를 실행하세요.

사람이 판단합니다. 나열된 로그가 사람의 로그인 계정이 아니라 그 로그를 쓰는 서비스(syslog, 데이터베이스, 웹 서버)의 것인지 확인하세요. root가 소유한 로그는 나열하지 않습니다.