Linux 서버 계정 관리 보안점검 U-11~U-13 | Bash 자동화 스크립트 포함

리눅스 계정 관리 영역의 핵심 보안점검 항목인 U-11~U-13은 사용자 로그인 쉘, 세션 자동 종료 시간, 비밀번호 암호화 알고리즘을 점검하는 항목이다.

이번 글에서는 각 항목의 자동 진단 스크립트가 실제로 어떤 설정을 확인하고 어떤 조건에서 결과를 출력하는지를 중심으로 정리한다.

특히 계정의 로그인 쉘이나 PAM 설정, 비밀번호 암호화 방식을 변경하는 작업은 정상적인 사용자 로그인과 서비스 동작에 직접적인 영향을 줄 수 있으므로, 자동 진단 결과만으로 설정을 변경하지 않고 대상 시스템의 운영 목적과 실제 사용 여부를 함께 확인해야 한다.

---

1. 계정 관리 점검 항목 종합 요약

점검코드	점검 명칭	주요 점검 대상 파일	스크립트 기준 판단 방식	위험도
U-11	사용자 Shell 점검	/etc/passwd	UID 1000 이상 일반 계정 중 nologin, false, sync가 아닌 로그인 쉘을 사용하는 계정을 출력하고 수동 확인	중
U-12	세션 종료 시간 설정	/etc/profile	/etc/profile의 TMOUT 값을 확인하고 600초 이하이면 양호, 초과 또는 미설정이면 취약	중
U-13	안전한 비밀번호 암호화 알고리즘 사용	/etc/login.defs, /etc/pam.d/system-auth, /etc/pam.d/common-password	SHA512 또는 YESCRYPT 설정이 확인되면 양호, 그렇지 않으면 취약	상

중요: 위 표의 판단 방식은 일반적인 보안 가이드 전체를 설명한 것이 아니라, 현재 사용 중인 자동 진단 스크립트가 실제로 수행하는 검사 로직을 기준으로 작성했다.

---

2. 세부 항목별 진단 및 조치 가이드

2.1 [U-11] 사용자 Shell 점검

① 점검 목적 및 개요

리눅스 계정에는 로그인 시 사용할 기본 Shell이 지정된다.

일반 사용자 계정에 /bin/bash, /bin/sh와 같은 대화형 Shell이 설정되어 있으면 해당 계정을 이용한 직접 로그인이 가능하다.

반면 시스템 서비스나 애플리케이션 실행에만 사용하는 계정은 일반적인 대화형 로그인이 필요하지 않은 경우가 많기 때문에 /sbin/nologin 또는 /bin/false 등을 지정하여 로그인 기능을 제한할 수 있다.

U-11 스크립트에서는 모든 계정을 일괄적으로 취약 처리하지 않고 다음 조건에 해당하는 계정을 추출한다.

• /etc/passwd의 UID가 1000 이상
• 계정명이 nobody가 아님
• 로그인 Shell이 nologin, false, sync가 아님

따라서 해당 계정 목록을 확인한 후 실제 업무상 필요한 계정인지 수동으로 판단해야 한다.

---

② 자동 진단 스크립트

# [상세 해설] U-11 진단 코드 시작 식별자 선언
CODE "[ U-11 ] 사용자 Shell 점검"

# [상세 해설] /etc/passwd 파일에서 7번째 필드(로그인 쉘)가 nologin, false, sync가 아니며,
# [상세 해설] UID(3번째 필드)가 1000 이상인 대화형 일반 계정 목록을 필터링하여 변수에 저장
INTERACTIVE_USERS=$(awk -F: '$7 !~ /(nologin|false|sync)/ && $3 >= 1000 && $1 != "nobody" {print $1}' /etc/passwd | xargs)

# [상세 해설] 추출된 계정 목록을 관리자에게 출력하여 불필요한 계정이 포함되어 있는지 수동 검토 유도
INFO "대화형 쉘이 부여된 일반 계정 중 불필요한 계정이 있는지 수동 확인 바랍니다." "로그인 가능한 일반 계정 목록: [ ${INTERACTIVE_USERS:-없음} ]"

# [상세 해설] U-11 진단 종료
FINISH "[ U-11 ] 점검완료"

---

③ 스크립트는 어떻게 동작하는가?

핵심은 다음 awk 조건이다.

$7 !~ /(nologin|false|sync)/ && $3 >= 1000 && $1 != "nobody"

/etc/passwd는 일반적으로 다음과 같은 7개 필드 구조를 사용한다.

계정명:x:UID:GID:설명:홈디렉터리:로그인쉘

따라서 스크립트는 다음과 같이 동작한다.

 

조건	의미
$7 !~ /(nologin|false|sync)/	로그인 Shell이 제한된 Shell이 아닌 계정
$3 >= 1000	UID 1000 이상인 일반 계정
$1 != "nobody"	nobody 계정 제외

최종적으로 조건에 맞는 계정명을 INTERACTIVE_USERS 변수에 저장하고 INFO 메시지로 출력한다.

따라서 U-11은 자동으로 [양호] 또는 [취약]을 판정하는 방식이 아니다.

스크립트가 출력한 계정 목록을 확인하고 해당 계정의 실제 사용 목적을 판단해야 한다.

---

④ 수동 점검

대화형 Shell을 사용하는 일반 계정을 확인하려면 다음과 같이 점검할 수 있다.

awk -F: '$7 !~ /(nologin|false|sync)/ && $3 >= 1000 && $1 != "nobody" {print $1, $7}' /etc/passwd

 

특정 계정의 Shell만 확인하려면 다음 명령을 사용할 수 있다.

grep "^사용자계정명:" /etc/passwd

 

확인된 계정이 실제 사용자 계정인지, 배치·배포·애플리케이션 운영에 필요한 계정인지 확인해야 한다.

---

⑤ 보안실무 적용 시 주의사항

서비스 계정의 Shell을 임의로 변경하지 않는다

Nginx, Tomcat, MySQL 등 애플리케이션 실행에 사용하는 계정이라고 해서 무조건 Shell을 차단하면 안 된다.

일부 환경에서는 다음과 같이 계정으로 전환하여 명령을 실행하는 방식이 사용될 수 있다.

su - 계정명 -c "command"

이러한 구성에서 해당 계정의 Shell을 변경하면 기존 기동 또는 배치 작업에 영향을 줄 수 있다.

따라서 변경 전에 해당 계정이 어떤 프로세스와 서비스에서 사용되는지 확인해야 한다.

배포·CI/CD 계정은 별도 검토한다

Jenkins, GitLab Runner, Ansible 등의 배포 계정은 자동화 작업을 위해 Shell 접근이 필요한 환경이 있을 수 있다.

이 경우 단순히 /sbin/nologin으로 변경하기보다는 실제 접속 목적과 인증 방식을 확인하고 접근통제 정책을 별도로 적용해야 한다.

---

⑥ 안전한 조치 절차

먼저 /etc/passwd를 백업한다.

cp -p /etc/passwd /etc/passwd_backup_$(date +%Y%m%d)

불필요한 대화형 로그인이 확인된 계정의 Shell을 변경한다.

usermod -s /sbin/nologin 사용자계정명

변경 결과를 확인한다.

grep "^사용자계정명:" /etc/passwd

예를 들어 다음과 같이 변경되었다면 해당 계정의 기본 로그인 Shell이 제한된 상태다.

user01:x:1001:1001::/home/user01:/sbin/nologin

---

2.2 [U-12] 세션 종료 시간 설정

① 점검 목적 및 개요

사용자가 로그인한 터미널을 장시간 방치하면 다른 사람이 해당 세션을 이용할 가능성이 있다.

TMOUT 환경변수는 일정 시간 동안 입력이 없는 Shell 세션을 자동으로 종료하기 위한 설정이다.

현재 자동 진단 스크립트에서는 /etc/profile에 설정된 TMOUT 값을 확인하고 600초 이하인지 여부를 기준으로 판정한다.

---

② 자동 진단 스크립트

# [상세 해설] U-12 진단 코드 시작 식별자 선언
CODE "[ U-12 ] 세션 종료 시간 설정"

# [상세 해설] /etc/profile 파일에서 주석을 제외한 TMOUT 설정 라인을 추출하고,
# [상세 해설] 공백과 따옴표를 제거하여 순수 초(second) 단위 값만 획득
TMOUT_VAL=$(grep -E "^[[:space:]]*(export[[:space:]]+)?TMOUT=" /etc/profile | tail -n 1 | cut -d= -f2 | tr -d '"; ')

# [상세 해설] TMOUT 변수 값이 존재하는지 검증
if [ -n "$TMOUT_VAL" ]; then

    # [상세 해설] TMOUT 설정값이 600초(10분) 이하인지 수치 비교 수행
    if [ "$TMOUT_VAL" -le 600 ]; then
        OK "세션 타임아웃(TMOUT)이 기준에 맞게 설정되어 있습니다." "/etc/profile 내 TMOUT 값이 ${TMOUT_VAL}초로 설정됨."
    else
        WARN "세션 타임아웃이 가이드 기준(600초)을 초과합니다." "/etc/profile 내 TMOUT 값이 ${TMOUT_VAL}초로 초과 설정됨."
    fi

else
    # [상세 해설] TMOUT 설정이 없거나 주석 처리된 경우 취약으로 판정
    WARN "세션 타임아웃(TMOUT) 설정이 적용되지 않았습니다." "/etc/profile에 TMOUT 지시어가 없거나 주석 처리됨."
fi

# [상세 해설] U-12 진단 종료
FINISH "[ U-12 ] 점검완료"

---

③ 스크립트는 어떻게 동작하는가?

먼저 /etc/profile에서 다음과 같은 형식의 설정을 찾는다.

TMOUT=600

또는

export TMOUT=600

tail -n 1을 사용하기 때문에 여러 개의 TMOUT 설정이 존재하면 마지막으로 검색된 설정값을 사용한다.

그 후 다음 조건으로 판정한다.

[ "$TMOUT_VAL" -le 600 ]

따라서 현재 스크립트 기준은 다음과 같다.

 

/etc/profile TMOUT 상태	스크립트 결과
TMOUT=600	OK
TMOUT=300	OK
TMOUT=601	WARN
TMOUT=900	WARN
설정 없음	WARN

중요한 점은 현재 스크립트가 /etc/profile만 검사한다는 것이다.

따라서 /etc/profile.d/*.sh 등에 실제 TMOUT 설정이 존재하더라도 현재 스크립트에서는 이를 확인하지 않는다.

---

④ 수동 점검

현재 스크립트와 동일한 범위에서 확인하려면 다음과 같이 점검한다.

grep -E "^[[:space:]]*(export[[:space:]]+)?TMOUT=" /etc/profile

현재 로그인 세션에 실제 적용된 값은 다음과 같이 확인할 수 있다.

echo $TMOUT

---

⑤ 보안실무 적용 시 주의사항

장시간 작업 중 세션 종료에 주의

운영 서버에서 다음과 같은 작업을 대화형 SSH 세션에서 직접 실행하는 경우 TMOUT 설정에 의해 세션이 종료될 수 있다.

• 대용량 파일 전송
• 데이터베이스 마이그레이션
• 장시간 백업
• 대규모 로그 처리
• 장시간 컴파일 작업

장시간 실행되는 작업은 운영 환경에 맞게 nohup, screen, tmux 또는 서비스·배치 형태로 실행하는 것이 안전하다.

SSH 연결 유지 설정과 구분

TMOUT은 Shell 레벨의 유휴 세션 제어이고 SSH의 ClientAliveInterval, ClientAliveCountMax와는 목적과 동작 방식이 다르다.

따라서 SSH 연결 유지 정책을 함께 사용하는 환경에서는 두 설정을 별도로 확인해야 한다.

---

⑥ 안전한 조치 절차

먼저 /etc/profile을 백업한다.

cp -p /etc/profile /etc/profile_backup_$(date +%Y%m%d)

이후 세션 타임아웃을 설정한다.

cat << 'EOF' >> /etc/profile

# 세션 자동 종료 설정 (600초 = 10분)
export TMOUT=600
readonly TMOUT
EOF

새로운 Shell 세션에서 적용 여부를 확인한다.

echo $TMOUT

정상적으로 적용되었다면 다음과 같이 확인된다.

600

기존 로그인 세션은 이미 로드된 환경변수를 사용하고 있을 수 있으므로 새 세션에서 결과를 확인하는 것이 필요하다.

---

2.3 [U-13] 안전한 비밀번호 암호화 알고리즘 사용

① 점검 목적 및 개요

비밀번호는 평문으로 저장하지 않고 단방향 암호화 방식으로 변환하여 저장해야 한다.

현재 U-13 스크립트에서는 비밀번호 암호화 알고리즘으로 SHA-512 또는 YESCRYPT가 설정되어 있는지를 확인한다.

자동 진단은 다음 순서로 진행된다.

1. /etc/login.defs의 ENCRYPT_METHOD 확인
2. SHA512 또는 YESCRYPT이면 양호
3. 해당 설정을 찾지 못하면 PAM 설정 파일 확인
4. sha512 또는 yescrypt 문자열이 확인되면 양호
5. 둘 모두 확인되지 않으면 취약

---

② 자동 진단 스크립트

# [상세 해설] U-13 진단 코드 시작 식별자 선언
CODE "[ U-13 ] 안전한 비밀번호 암호화 알고리즘 사용 (2026 신규/강화)"

# [상세 해설] 알고리즘 안전성 판별을 위한 플래그 및 사유 변수 초기화
IS_SECURE_ALGO="FALSE"
REASON_ALGO=""

# [상세 해설] /etc/login.defs 파일 내 기본 암호화 지시어(ENCRYPT_METHOD) 확인
if [ -f /etc/login.defs ]; then
    ALGO=$(grep -i -E "^[[:space:]]*ENCRYPT_METHOD" /etc/login.defs | awk '{print $2}')

    # [상세 해설] 추출된 알고리즘이 SHA512 또는 YESCRYPT인지 비교
    if [[ "$ALGO" == "SHA512" || "$ALGO" == "YESCRYPT" ]]; then
        IS_SECURE_ALGO="TRUE"
        REASON_ALGO="/etc/login.defs 에 안전한 알고리즘($ALGO)이 설정됨."
    fi
fi

# [상세 해설] login.defs에서 미확인 시 PAM 인증 모듈 설정 파일 점검
if [[ "$IS_SECURE_ALGO" == "FALSE" ]]; then
    if grep -E -q "sha512|yescrypt" /etc/pam.d/system-auth /etc/pam.d/common-password 2>/dev/null; then
        IS_SECURE_ALGO="TRUE"
        REASON_ALGO="PAM 인증 파일(system-auth 등)에 sha512 또는 yescrypt 모듈이 적용됨."
    else
        REASON_ALGO="/etc/login.defs 및 PAM 파일에 안전한 암호화 지시어가 없음."
    fi
fi

# [상세 해설] 판정 결과 출력
if [[ "$IS_SECURE_ALGO" == "TRUE" ]]; then
    OK "안전한 패스워드 암호화 알고리즘이 시스템에 적용되어 있습니다." "$REASON_ALGO"
else
    WARN "안전하지 않은 패스워드 알고리즘(MD5 등)을 사용 중이거나 설정 누락 상태입니다." "$REASON_ALGO"
fi

# [상세 해설] U-13 진단 종료
FINISH "[ U-13 ] 점검완료"

---

③ 스크립트는 어떻게 동작하는가?

먼저 /etc/login.defs에서 다음 설정을 찾는다.

ENCRYPT_METHOD SHA512

또는

ENCRYPT_METHOD YESCRYPT

둘 중 하나가 확인되면 IS_SECURE_ALGO를 TRUE로 변경한다.

만약 login.defs에서 확인되지 않으면 다음 PAM 파일을 검색한다.

/etc/pam.d/system-auth
/etc/pam.d/common-password

그리고 다음 문자열이 포함되어 있는지 검사한다.

sha512
yescrypt

 

따라서 현재 스크립트의 판정 구조는 다음과 같다.

검사 위치	확인 내용	결과
/etc/login.defs	ENCRYPT_METHOD SHA512	TRUE
/etc/login.defs	ENCRYPT_METHOD YESCRYPT	TRUE
PAM 설정	sha512 문자열 존재	TRUE
PAM 설정	yescrypt 문자열 존재	TRUE
어느 곳에서도 확인되지 않음	안전한 알고리즘 설정 미확인	WARN

여기서 중요한 점은 U-13 스크립트가 실제 /etc/shadow의 모든 비밀번호 해시를 직접 분석하는 것은 아니라는 것이다.

즉, 설정 파일에 안전한 알고리즘이 지정되어 있는지를 우선 확인하는 방식이다.

---

④ 수동 점검

login.defs 설정을 확인한다.

grep -i -E "^[[:space:]]*ENCRYPT_METHOD" /etc/login.defs

PAM 설정을 확인한다.

grep -E "sha512|yescrypt" /etc/pam.d/system-auth /etc/pam.d/common-password 2>/dev/null

실제 /etc/shadow에 저장된 해시의 식별자를 확인할 수도 있다.

awk -F: '$2 ~ /^\$6\$/ || $2 ~ /^\$y\$/ {print $1}' /etc/shadow

여기서 $6$와 $y$는 현재 개선 스니펫에서 실제 저장된 해시를 확인하기 위해 사용하는 식별자다.

---

⑤ 보안실무 적용 시 주의사항

기존 비밀번호가 자동으로 변경되는 것은 아니다

/etc/login.defs 또는 PAM 설정을 변경하더라도 이미 /etc/shadow에 저장되어 있는 기존 비밀번호 해시가 즉시 새로운 알고리즘으로 변환되는 것은 아니다.

따라서 설정 변경 이후 실제 비밀번호 변경이 필요한 환경에서는 대상 계정의 비밀번호 변경 정책과 적용 시점을 별도로 관리해야 한다.

PAM 설정 변경은 특히 주의한다

PAM 설정 파일의 문법이나 모듈 순서를 잘못 변경하면 사용자 인증이나 sudo 등에 영향을 줄 수 있다.

따라서 운영 서버에서는 작업 전에 현재 설정을 백업하고, 별도의 root 세션을 유지한 상태에서 변경하는 것이 안전하다.

RHEL 계열에서 authselect를 사용하는 환경이라면 현재 시스템의 인증 프로파일과 관리 방식을 먼저 확인한 후 적용해야 한다.

---

⑥ 안전한 조치 절차

먼저 설정 파일을 백업한다.

cp -p /etc/login.defs /etc/login.defs_backup_$(date +%Y%m%d)

ENCRYPT_METHOD 설정이 존재하는 경우 SHA512로 변경한다.

if grep -q "^ENCRYPT_METHOD" /etc/login.defs; then
    sed -i 's/^ENCRYPT_METHOD.*/ENCRYPT_METHOD SHA512/' /etc/login.defs
else
    echo "ENCRYPT_METHOD SHA512" >> /etc/login.defs
fi

변경 결과를 확인한다.

grep -i -E "^[[:space:]]*ENCRYPT_METHOD" /etc/login.defs

다만 PAM 설정은 배포판과 인증 구성에 따라 관리 방식이 다르므로, 해당 환경의 표준 관리 도구와 현재 인증 구성을 확인한 후 적용해야 한다.

---

3. 자동 진단 스크립트의 한계 및 예외 처리

현재 스크립트는 실무 환경에서 빠르게 점검할 수 있도록 구성되어 있지만, 최신 Linux의 모듈형 설정 구조를 모두 추적하는 것은 아니다.

3.1 U-11의 한계

U-11은 /etc/passwd의 로컬 계정 정보를 기준으로 검사한다.

따라서 LDAP, AD, NIS 등 외부 인증 시스템에서 제공하는 계정은 현재 스크립트의 검사 대상에 포함되지 않는다.

또한 대화형 Shell을 사용하는 계정이라고 해서 반드시 불필요한 계정인 것은 아니므로, 출력된 계정 목록에 대한 업무상 필요성 확인이 필요하다.

---

3.2 U-12의 한계

현재 U-12 스크립트는 다음 파일만 검사한다.

/etc/profile

따라서 다음과 같은 위치에 실제 TMOUT 설정이 존재하는 경우 현재 스크립트에서는 확인하지 못할 수 있다.

/etc/profile.d/*.sh

예를 들어 /etc/profile.d/session.sh에 다음 설정이 존재하더라도 현재 U-12 스크립트는 이를 직접 검사하지 않는다.

export TMOUT=600

따라서 최신 시스템에서는 /etc/profile뿐 아니라 실제 Shell 초기화 과정에서 적용되는 설정까지 확인할 필요가 있다.

---

3.3 U-13의 한계

U-13 역시 모든 PAM Include 구조를 재귀적으로 분석하지 않는다.

예를 들어 PAM 설정에서 다른 파일을 include 또는 substack 방식으로 호출하는 경우 현재 스크립트가 직접 검색하는 파일에 sha512 또는 yescrypt 문자열이 없으면 실제 적용 상태와 스크립트 결과가 다를 가능성이 있다.

또한 /etc/login.defs의 설정만 확인하는 것과 실제 /etc/shadow에 저장된 각 계정의 해시 알고리즘을 확인하는 것은 서로 다른 검사다.

따라서 U-13 결과를 보다 정확하게 검증하려면 설정값 확인과 실제 저장 해시 확인을 구분하여 수행하는 것이 필요하다.

---

4. 최신 Linux 환경을 고려한 개선 검사 예시

4.1 U-12 TMOUT 설정 범위 확대

현재 /etc/profile만 검사하는 방식에서 /etc/profile.d/*.sh까지 검사 범위를 확대할 수 있다.

# /etc/profile 및 /etc/profile.d/ 내 TMOUT 설정 확인
TMOUT_VAL=$(grep -h -E "^[[:space:]]*(export[[:space:]]+)?TMOUT=[0-9]+" \
    /etc/profile /etc/profile.d/*.sh 2>/dev/null |
    tail -n 1 |
    cut -d= -f2 |
    tr -d '"; ')

이 방식은 현재 U-12 기본 스크립트와 달리 profile.d에 분리된 설정까지 검색한다.

---

4.2 U-13 실제 저장 해시 확인

설정 파일의 알고리즘 지정 여부와 별도로 /etc/shadow에 저장된 해시 식별자를 직접 확인할 수 있다.

SHADOW_HASH_CHECK=$(awk -F: \
    '$2 ~ /^\$6\$/ || $2 ~ /^\$y\$/ {print $1}' \
    /etc/shadow | wc -l)

계정별 실제 해시 식별자를 확인하려면 다음과 같이 점검할 수 있다.

awk -F: '
$2 ~ /^\$6\$/ {print $1 " : SHA-512"}
$2 ~ /^\$y\$/ {print $1 " : YESCRYPT"}
' /etc/shadow

이 검사는 설정 파일에 지정된 기본 알고리즘과 현재 계정에 실제 저장된 해시 알고리즘을 구분하여 확인할 수 있다는 점에서 의미가 있다.

---

5. U-11~U-13 자동화 스크립트 판정 기준 정리

 

항목	자동화 스크립트의 핵심 검사	자동 판정	추가 확인
U-11	UID 1000 이상 계정의 대화형 Shell 추출	INFO	계정 사용 목적
U-12	/etc/profile의 TMOUT ≤ 600	OK/WARN	profile.d 및 실제 세션 적용 여부
U-13	SHA512/YESCRYPT 설정 확인	OK/WARN	PAM Include 구조 및 실제 /etc/shadow 해시

이번 U-11~U-13에서 특히 중요한 부분은 자동화 스크립트가 모든 보안 상태를 완전히 판정하는 것이 아니라는 점이다.

U-11은 계정 목록을 출력하고 관리자가 필요성을 판단하는 구조이며, U-12와 U-13은 특정 설정 파일과 문자열을 기준으로 자동 판정한다.

따라서 자동화 점검 결과는 1차 진단 자료로 활용하고, 실제 운영 환경에서는 설정 적용 경로와 계정 사용 목적까지 함께 확인하는 것이 필요하다.

---

6. 자동화 스크립트를 활용한 점검 순서

실제 서버 점검에서는 다음 순서로 진행하면 된다.

① 자동 진단 스크립트 실행

U-11~U-13의 결과를 먼저 확인한다.

[ U-11 ] 사용자 Shell 점검
[ U-12 ] 세션 종료 시간 설정
[ U-13 ] 안전한 비밀번호 암호화 알고리즘 사용

② 자동 진단 결과의 원본 설정 확인

U-11은 /etc/passwd, U-12는 /etc/profile, U-13은 /etc/login.defs와 PAM 설정을 확인한다.

③ 운영 영향도 확인

특히 다음 항목은 설정 변경 전에 실제 사용 여부를 확인한다.

• 서비스 계정
• 배치 계정
• 배포 계정
• 장시간 실행 작업
• PAM 인증 구성
• 기존 사용자 비밀번호

④ 설정 파일 백업

설정 변경 전 원본 파일을 별도로 백업한다.

⑤ 변경 후 재점검

설정 변경이 완료되면 동일한 자동 진단 스크립트를 다시 실행하여 변경 결과를 확인한다.

⑥ 서비스 및 로그인 정상 여부 확인

보안 설정이 정상적으로 변경되었더라도 실제 사용자 로그인, sudo, 애플리케이션 서비스 및 배치 작업이 정상적으로 동작하는지 확인한다.

---

 

주의사항
본 포스팅의 스크립트 및 조치 방법은 Linux 시스템의 계정 관리 및 인증 보안점검과 보안 강화를 목적으로 작성되었다. Linux 배포판, 버전, 설치된 서비스 및 인증 구성에 따라 설정 파일과 적용 방식이 다를 수 있다.
특히 사용자 로그인 Shell, TMOUT, PAM 및 비밀번호 암호화 관련 설정을 변경하면 정상적인 로그인이나 장시간 실행 작업, 서비스 인증에 영향을 줄 수 있으므로 운영 서버에 적용하기 전에 반드시 테스트 환경에서 검증한 후 적용해야 한다.
계정의 Shell을 변경하기 전에는 해당 계정이 서비스, 배치 또는 배포 작업에서 사용되고 있는지 확인해야 한다. 또한 PAM 및 비밀번호 인증 설정을 변경할 경우 현재 인증 구성과 백업 상태를 확인한 후 적용하는 것이 필요하다.
스크립트 실행 및 설정 변경으로 인해 발생하는 시스템 장애에 대해서는 사용 환경에 맞는 사전 검증이 필요하다.

---

함께 보면 좋은 글

Linux 보안취약점 점검 자동화 스크립트 공통 함수 및 환경 설정

Linux 보안취약점 점검 스크립트를 여러 항목에서 공통으로 사용하기 위한 함수와 환경 설정에 대한 내용은 별도의 글에서 확인할 수 있다.

자동화 스크립트 공통 함수 및 환경 설정