리눅스 시스템의 패치와 시각 동기화, 시스템 로깅, 로그 디렉터리 권한은 침해사고 예방뿐만 아니라 사고 발생 이후 원인을 추적하고 증적을 확보하기 위한 기본적인 관리 영역이다.
이번 글에서는 U-64~U-67 항목을 대상으로 자동 진단 스크립트가 실제로 무엇을 확인하는지 분석하고, 진단 결과를 운영 환경에서 어떻게 해석하고 조치해야 하는지 정리한다.
특히 이 그룹은 자동화 스크립트에서 확인할 수 있는 범위와 실제 운영 정책을 사람이 추가로 확인해야 하는 범위가 서로 다르다. 따라서 스크립트 결과만으로 양호·취약을 단정하기보다는 실제 패치 이력, 시간 동기화 상태, 로그 저장 정책, 권한 변경에 따른 서비스 영향까지 함께 확인해야 한다.
1. U-64~U-67 점검 항목 요약
| 점검코드 | 점검 명칭 | 주요 점검 대상 | 스크립트 기준 주요 확인 내용 | 위험도 |
| U-64 | 주기적 보안 패치 및 벤더 권고사항 적용 | /etc/os-release, 패키지 관리 이력 | OS·커널 정보와 최근 패키지 작업 이력을 확인하고 수동 점검 대상임을 안내 | 상 |
| U-65 | NTP 및 시각 동기화 설정 | /etc/chrony.conf, /etc/ntp.conf, /etc/systemd/timesyncd.conf | 시각 동기화 데몬의 동작 여부와 외부 시간 서버 설정 여부 확인 | 중 |
| U-66 | 정책에 따른 시스템 로깅 설정 | rsyslog, syslogd, systemd-journald | 주요 로깅 데몬 프로세스의 실행 여부 확인 | 상 |
| U-67 | 로그 디렉터리 소유자 및 권한 설정 | /var/log | /var/log 소유자와 기타 사용자의 쓰기 권한 확인 | 중 |
이 중 U-64와 U-66은 현재 스크립트가 실제 정책 준수 여부나 로그 보존 수준까지 모두 판정하는 구조가 아니다. 따라서 자동 점검 결과는 초기 상태 확인 및 수동 점검 대상 식별 용도로 활용하는 것이 적절하다.
2. [U-64] 주기적 보안 패치 및 벤더 권고사항 적용
2.1 점검 목적
운영체제와 주요 패키지에 알려진 취약점이 존재하더라도 보안 패치가 적용되지 않으면 공격자가 이를 악용할 가능성이 있다.
특히 공개된 취약점 중에는 원격 코드 실행(RCE), 권한 상승 등 서버 전체의 보안 수준에 직접적인 영향을 주는 취약점이 포함될 수 있다.
따라서 운영체제와 주요 패키지에 대한 보안 패치 절차를 수립하고, 벤더 보안 권고사항을 주기적으로 검토하여 필요한 패치를 적용하는 관리체계가 필요하다.
2.2 자동 진단 스크립트 분석
# [상세 해설] U-64 점검 시작 알림
CODE "[ U-64 ] 주기적 보안 패치 및 벤더 권고사항 적용"
OS_RELEASE=""
# [상세 해설] OS 버전을 확인하기 위해 /etc/os-release 파일 분석
if [ -f /etc/os-release ]; then
# [상세 해설] PRETTY_NAME 필드에서 OS 명칭과 버전 정보 추출
OS_RELEASE=$(grep -E "^PRETTY_NAME" /etc/os-release | cut -d= -f2 | tr -d '"')
elif [ -f /etc/redhat-release ]; then
# [상세 해설] 구형 RHEL 계열 파일에서 OS 정보 추출
OS_RELEASE=$(cat /etc/redhat-release)
else
# [상세 해설] 표준 파일이 없을 경우 uname 명령어로 커널 및 시스템 정보 대처
OS_RELEASE=$(uname -s -r -v)
fi
# [상세 해설] 현재 시스템의 실행 중인 커널 버전 추출
KERNEL_VER=$(uname -r)
# [상세 해설] 수동 점검 대상 안내 및 현재 시스템 정보 출력
INFO "시스템의 최신 보안 패치 및 벤더 권고사항 적용 여부를 주기적으로 수동 점검해야 합니다." "현재 OS: $OS_RELEASE / 커널: $KERNEL_VER"
LAST_UPDATE=""
# [상세 해설] YUM 패키지 매니저 존재 여부 확인
if command -v yum >/dev/null 2>&1; then
# [상세 해설] yum history 명령을 통해 가장 최근에 수행된 패키지 작업 일시 추출
LAST_UPDATE=$(yum history 2>/dev/null | grep -E -v "ID|---|Loaded|Warning" | head -n 1 | awk '{print $3, $4}')
if [ -n "$LAST_UPDATE" ]; then
INFO "YUM 패키지 관리자의 가장 최근 작업(업데이트 등) 일시를 확인했습니다." "최근 작업 일시: $LAST_UPDATE"
else
INFO "YUM 업데이트 이력을 찾을 수 없습니다." "yum history 확인 불가"
fi
# [상세 해설] APT 패키지 매니저(Ubuntu/Debian) 존재 여부 확인
elif command -v apt-get >/dev/null 2>&1; then
# [상세 해설] apt history.log 파일에서 가장 최근 업데이트 시작 시간 추출
if [ -f /var/log/apt/history.log ]; then
LAST_UPDATE=$(grep "^Start-Date:" /var/log/apt/history.log | tail -n 1 | cut -d: -f2- | xargs)
if [ -n "$LAST_UPDATE" ]; then
INFO "APT 패키지 관리자의 가장 최근 업데이트 일시를 확인했습니다." "최근 작업 일시: $LAST_UPDATE"
else
INFO "APT 업데이트 이력을 찾을 수 없습니다." "history.log 내역 없음"
fi
else
INFO "/var/log/apt/history.log 파일을 찾을 수 없습니다." "로그 유실 또는 미사용"
fi
fi
FINISH "[ U-64 ] 점검완료"
스크립트가 실제로 확인하는 범위
U-64 스크립트는 최신 보안 패치가 실제로 모두 적용되었는지를 자동으로 판정하지 않는다.
현재 스크립트가 수행하는 작업은 다음과 같다.
- 운영체제와 현재 커널 버전을 확인한다.
- YUM 또는 APT 패키지 관리자의 존재 여부를 확인한다.
- 패키지 관리 이력에서 최근 작업 일시를 확인한다.
- 최신 보안 패치 적용 여부는 별도의 수동 점검 대상으로 안내한다.
따라서 최근 작업 일시가 확인된다고 해서 최신 보안 패치가 적용된 상태라고 판단해서는 안 된다.
2.3 실무에서 주의할 점
운영 서버에서 보안 패치를 적용할 때 가장 위험한 부분은 패치 자체보다 패치 이후 서비스 영향이다.
특히 운영 환경에서 무조건적인 전체 업데이트를 실행하면 라이브러리 변경이나 패키지 의존성 변경으로 애플리케이션이 정상적으로 기동하지 않는 상황이 발생할 수 있다.
따라서 패치 전에는 대상 패키지와 영향 범위를 먼저 확인하는 절차가 필요하다.
# RHEL/CentOS 계열 보안 패치 대상 조회
yum updateinfo list security
# Ubuntu/Debian 계열 업데이트 대상 조회
apt-get --just-print upgrade
컨테이너 기반 환경이나 불변 인프라(Immutable Infrastructure)를 사용하는 경우에는 실행 중인 서버에서 직접 패치하기보다 베이스 이미지를 갱신한 뒤 신규 이미지를 배포하는 방식으로 관리할 수 있다.
2.4 안전한 조치 절차
먼저 현재 설치된 패키지 정보를 별도로 보관한다.
# RHEL 계열
rpm -qa > /root/pkg_list_$(date +%Y%m%d).txt
# Debian 계열
dpkg -l > /root/pkg_list_$(date +%Y%m%d).txt
이후 환경에 맞는 보안 패치를 선별하여 적용한다.
# RHEL/CentOS 계열 보안 패치만 선택적 적용
yum update --security -y
# Ubuntu 계열 특정 패키지 업데이트
apt-get install --only-upgrade <패키지명>
패치 적용 후에는 서비스 상태와 애플리케이션 정상 동작 여부까지 확인해야 한다.
3. [U-65] NTP 및 시각 동기화 설정
3.1 점검 목적
시스템 간 시간이 서로 다르면 동일한 침해사고에 대한 로그 분석에서도 이벤트 발생 순서를 정확하게 파악하기 어려워질 수 있다.
특히 여러 서버의 로그를 연계하여 분석하는 환경에서는 시스템 시간 동기화가 중요하다.
U-65에서는 chronyd, ntpd, systemd-timesyncd와 같은 시각 동기화 서비스가 실행되고 있는지 확인하고 설정 파일에서 동기화 서버가 지정되어 있는지를 확인한다.
3.2 자동 진단 스크립트 분석
# [상세 해설] U-65 점검 시작 알림
CODE "[ U-65 ] NTP 및 시각 동기화 설정"
NTP_RUNNING="FALSE"
NTP_CONF_SAFE="FALSE"
REASON_NTP=""
# [상세 해설] 1. chronyd 데몬의 활성화 및 프로세스 실행 여부 검사 (RHEL 7+ 기본)
if systemctl is-active --quiet chronyd 2>/dev/null || ps -ef | grep -E "chronyd" | grep -v "grep" >/dev/null; then
NTP_RUNNING="TRUE"
# [상세 해설] /etc/chrony.conf 내 외부 타임 서버(server 또는 pool) 설정 존재 여부 확인 (루프백 제외)
if grep -E -i "^[[:space:]]*(server|pool)" /etc/chrony.conf 2>/dev/null | grep -v "127.127.1.0" >/dev/null; then
NTP_CONF_SAFE="TRUE"
REASON_NTP="chronyd가 동작 중이며, /etc/chrony.conf에 외부 동기화 서버(server/pool)가 정상 설정됨."
else
REASON_NTP="chronyd는 동작 중이나, /etc/chrony.conf에 동기화 서버 설정이 누락됨."
fi
# [상세 해설] 2. ntpd 데몬의 활성화 및 프로세스 실행 여부 검사 (구형 시스템)
elif systemctl is-active --quiet ntpd 2>/dev/null || ps -ef | grep -E "ntpd|xntpd" | grep -v "grep" >/dev/null; then
NTP_RUNNING="TRUE"
CONF_FILE=$(ls /etc/ntp.conf /etc/inet/ntp.conf 2>/dev/null | head -1)
if [ -n "$CONF_FILE" ] && grep -E -i "^[[:space:]]*(server|pool)" "$CONF_FILE" | grep -v "127.127.1.0" >/dev/null; then
NTP_CONF_SAFE="TRUE"
REASON_NTP="ntpd가 동작 중이며, 설정 파일($CONF_FILE)에 외부 동기화 서버가 정상 설정됨."
else
REASON_NTP="ntpd는 동작 중이나, 외부 동기화 서버 설정이 누락되거나 설정 파일이 없음."
fi
# [상세 해설] 3. systemd-timesyncd 데몬 검사 (Ubuntu 기본)
elif systemctl is-active --quiet systemd-timesyncd 2>/dev/null; then
NTP_RUNNING="TRUE"
if grep -E -i "^[[:space:]]*NTP=" /etc/systemd/timesyncd.conf 2>/dev/null >/dev/null; then
NTP_CONF_SAFE="TRUE"
REASON_NTP="timesyncd가 동작 중이며, timesyncd.conf에 NTP 동기화 서버가 정상 설정됨."
else
REASON_NTP="timesyncd는 동작 중이나, timesyncd.conf에 NTP 서버 설정이 누락됨."
fi
fi
# [상세 해설] 판정 결과 출력 로직
if [[ "$NTP_RUNNING" == "FALSE" ]]; then
WARN "시각 동기화(NTP) 서비스가 동작하지 않아 침해사고 시 로그 타임스탬프 분석이 불가능할 수 있습니다." "ntpd, chronyd, timesyncd 등 관련 데몬 모두 미동작"
elif [[ "$NTP_CONF_SAFE" == "TRUE" ]]; then
OK "NTP/시각 동기화 서비스가 안전하게 설정되어 동작 중입니다." "$REASON_NTP"
else
WARN "시각 동기화 서비스는 동작 중이나, 동기화할 타임 서버(외부 서버) 설정이 미흡합니다." "$REASON_NTP"
fi
FINISH "[ U-65 ] 점검완료"
핵심은 “설정”과 “실제 동기화 상태”를 구분하는 것이다
현재 스크립트는 서비스가 실행 중인지, 설정 파일에 server 또는 pool 등의 설정이 존재하는지를 확인한다.
하지만 설정 파일에 서버가 등록되어 있다는 사실만으로 실제 시간 동기화가 정상적으로 이루어지고 있다고 단정할 수는 없다.
운영 환경에서는 실제 동기화 상태를 추가로 확인한다.
# chrony 동기화 상태 및 오차 확인
chronyc tracking
# 연동 타임 서버 상태 점검
chronyc sources -v
네트워크 방화벽 정책으로 UDP 123이 차단되어 있는 경우에도 설정 자체는 존재할 수 있기 때문에, 설정값과 실제 통신 상태를 함께 확인하는 것이 중요하다.
3.3 안전한 조치 절차
먼저 기존 설정을 백업한다.
cp -p /etc/chrony.conf /etc/chrony.conf.bak_$(date +%Y%m%d)
필요한 시간 서버를 설정한다.
# 기존 server 항목 수정 또는 신규 추가
server time.bora.net iburst
server ntp.kornet.net iburst
적용 후에는 서비스를 재시작하고 실제 동기화 상태를 확인한다.
systemctl restart chronyd
chronyc sources
대규모 시간 차이가 존재하는 시스템에서는 시간 변경 방식이 애플리케이션에 영향을 줄 수 있으므로 DB, 인증, 클러스터링, 배치 작업 등 시간에 민감한 서비스의 상태를 함께 확인해야 한다.
4. [U-66] 정책에 따른 시스템 로깅 설정
4.1 점검 목적
시스템 로그는 로그인, 인증, 시스템 오류, 서비스 장애, 침입 시도 등 다양한 보안 이벤트를 추적하는 핵심 증적이다.
따라서 운영체제에서 사용하는 로깅 데몬이 정상적으로 동작하는지 확인하고 조직의 로그 수집 및 보관 정책에 맞게 관리해야 한다.
4.2 자동 진단 스크립트 분석
# [상세 해설] U-66 점검 시작 알림
CODE "[ U-66 ] 정책에 따른 시스템 로깅 설정"
# [상세 해설] 현재 시스템에서 동작 중인 주요 로깅 데몬 프로세스 검색
LOG_PROCESS=$(ps -ef | grep -E "rsyslogd|syslogd|systemd-journald" | grep -v "grep")
if [ -n "$LOG_PROCESS" ]; then
# [상세 해설] 감지된 프로세스 명칭을 구분하여 변수에 할당
if echo "$LOG_PROCESS" | grep -q "systemd-journald"; then
DAEMON_NAME="systemd-journald"
elif echo "$LOG_PROCESS" | grep -q "rsyslogd"; then
DAEMON_NAME="rsyslogd"
else
DAEMON_NAME="syslogd"
fi
# [상세 해설] 로깅 데몬이 구동 중인 경우 양호 판정
OK "시스템 로깅 데몬($DAEMON_NAME)이 정상적으로 동작 중입니다." "활성화된 로깅 데몬: $DAEMON_NAME"
else
# [상세 해설] 로깅 데몬 미동작 시 취약 판정 및 조치 가이드 안내
WARN "시스템 로깅 데몬(rsyslog, syslog, systemd-journald 등)이 동작하지 않아 로그가 기록되지 않습니다." "관련 데몬 프로세스 미동작"
INFO "조치 방법: systemctl enable --now rsyslog 또는 systemd-journald 상태 확인" "참고: OS 버전에 맞는 로깅 데몬 활성화 필요"
fi
FINISH "[ U-66 ] 점검완료"
현재 스크립트의 판단 기준은 주요 로깅 데몬 프로세스가 존재하는가이다.
따라서 rsyslogd 또는 systemd-journald가 실행 중이면 양호로 판정한다.
반면 실제 로그가 정상적으로 저장되는지, 로그 보존 기간이 정책에 맞는지, 중앙 로그 서버로 전송되는지, 로그 저장 공간이 충분한지까지는 자동으로 확인하지 않는다.
즉 U-66은 프로세스 실행 여부를 확인한 뒤 실제 로그 생성·보관 상태를 추가로 확인해야 하는 항목이다.
4.3 로그 저장 공간도 함께 확인해야 한다
systemd-journald를 사용하는 환경에서는 로그 저장 정책이 서버 디스크 사용량에 직접적인 영향을 줄 수 있다.
특히 /var/log/journal 등에 로그가 계속 누적되는 환경에서는 디스크 사용량을 확인하지 않고 저장 정책을 변경할 경우 서비스 운영에 영향을 줄 수 있다.
실무에서는 다음과 같이 현재 로그 상태와 설정을 함께 확인한다.
# rsyslog 설정 파일 구문 검사
rsyslogd -N1
# 테스트 로그 생성
logger -p authpriv.info "Security Log Test"
# 테스트 로그 확인
tail -n 5 /var/log/secure
중앙 집중식 로그 수집 환경에서는 단일 서버에 로그를 저장하는 것 외에도 중앙 로그 서버 또는 SIEM으로 이벤트를 전송하여 로그 유실과 위변조 위험에 대비할 수 있다.
4.4 안전한 조치 절차
설정 파일을 변경하기 전에 백업한다.
cp -p /etc/rsyslog.conf /etc/rsyslog.conf.bak_$(date +%Y%m%d)
이후 구문을 확인하고 서비스를 활성화한다.
rsyslogd -N1
systemctl enable --now rsyslog
적용 후에는 실제 서비스 상태를 확인한다.
systemctl status rsyslog
운영 환경에서는 서비스가 active인지 확인하는 것만으로 끝내지 말고 실제 테스트 로그가 정상적으로 생성되고 지정된 위치에 기록되는지까지 확인해야 한다.
5. [U-67] 로그 디렉터리 소유자 및 권한 설정
5.1 점검 목적
/var/log는 시스템 및 서비스에서 발생하는 다양한 로그가 저장되는 영역이다.
비인가 사용자가 로그에 쓰기 권한을 가지고 있다면 침입 흔적이나 시스템 이벤트를 임의로 변경하거나 삭제할 가능성이 있다.
따라서 로그 디렉터리의 소유자와 권한을 적절히 설정하고, 필요 이상의 쓰기 권한이 부여되지 않도록 관리해야 한다.
5.2 자동 진단 스크립트 분석
# [상세 해설] U-67 점검 시작 알림
CODE "[ U-67 ] 로그 디렉터리 소유자 및 권한 설정"
LOG_DIR="/var/log"
VULN_LOGS=""
# [상세 해설] 로그 디렉터리 존재 여부 확인
if [ -d "$LOG_DIR" ]; then
# [상세 해설] /var/log 디렉터리의 소유자 계정명 추출
DIR_OWNER=$(ls -ld "$LOG_DIR" | awk '{print $3}')
# [상세 해설] /var/log 디렉터리의 권한 문자열 추출 (예: drwxr-xr-x)
DIR_PERMS=$(ls -ld "$LOG_DIR" | awk '{print $1}')
# [상세 해설] 기타 사용자(Other)의 쓰기 권한 위치(9번째 문자) 추출
DIR_O_WRITE=$(echo "$DIR_PERMS" | cut -c 9)
# [상세 해설] 소유자가 root/syslog가 아니거나, 기타 사용자에게 쓰기 권한(w)이 부여된 경우 점검
if [[ "$DIR_OWNER" != "root" && "$DIR_OWNER" != "syslog" ]] || [[ "$DIR_O_WRITE" == "w" ]]; then
WARN "시스템 로그 디렉터리($LOG_DIR)의 소유자 또는 권한이 취약하여 로그 위변조 위험이 있습니다." "소유자: $DIR_OWNER, 권한: $DIR_PERMS (권고: root 소유, 타사용자 쓰기 방지)"
else
OK "시스템 로그 디렉터리($LOG_DIR) 자체의 소유자 및 권한이 안전하게 설정되어 있습니다." "소유자: $DIR_OWNER, 권한: $DIR_PERMS (타사용자 쓰기 차단됨)"
fi
# [상세 해설] 하위 개별 로그 파일 권한 점검에 대한 안내 출력
INFO "/var/log 내 주요 개별 로그 파일(messages, secure, wtmp 등)에 비인가자 쓰기 권한 유무를 수동 확인 바랍니다." "명령어: find /var/log -type f -perm -002 -ls"
else
WARN "표준 시스템 로그 디렉터리($LOG_DIR)를 찾을 수 없습니다." "경로 누락 및 확인 필요"
fi
FINISH "[ U-67 ] 점검완료"
스크립트의 실제 점검 범위
U-67 스크립트는 /var/log 디렉터리 자체의 소유자와 기타 사용자 쓰기 권한을 확인한다.
또한 하위 로그 파일에 대해서는 자동 판정하지 않고 다음과 같은 수동 확인 방법을 안내한다.
find /var/log -type f -perm -002 -ls
따라서 /var/log 자체가 양호하더라도 하위 로그 파일에 과도한 쓰기 권한이 존재할 가능성은 별도로 확인해야 한다.
5.3 권한 변경 시 가장 주의할 부분
로그 파일의 권한을 개선한다고 해서 /var/log 아래 모든 파일에 동일한 권한을 일괄 적용하면 안 된다.
예를 들어 서비스가 별도 계정으로 실행되면서 자체 로그를 기록하는 경우, 과도한 권한 변경으로 로그 기록 자체가 실패할 수 있다.
특히 다음과 같은 방식은 운영 환경에서는 충분한 사전 검토가 필요하다.
chmod -R 700 /var/log
로그 디렉터리의 보안 강화 목적이라도 서비스별 소유자와 그룹, 로그 생성 방식, logrotate 정책을 확인한 후 필요한 범위만 변경하는 것이 안전하다.
5.4 안전한 조치 절차
먼저 현재 상태를 확인한다.
ls -ld /var/log
이후 환경에 맞게 소유자와 권한을 조정하고, 하위 파일에서는 기타 사용자 쓰기 권한을 선별적으로 제거한다.
# 디렉터리 소유자 변경 및 타사용자 쓰기 권한 제거
chown root:root /var/log
chmod 755 /var/log
# 하위 파일 중 World-Writable 권한만 제거
chmod -R o-w /var/log
적용 후에는 다시 취약 항목이 남아 있는지 확인한다.
find /var/log -type f -perm -002
또한 logrotate에 의해 새로운 로그 파일이 생성되는 환경이라면 로그 파일 생성 권한 정책도 함께 확인해야 한다.
예를 들어 create 0640 root utmp와 같은 설정이 사용되는지 확인하면 로그 순환 이후에도 권한이 다시 취약해지는 문제를 줄일 수 있다.
6. U-64~U-67 자동 진단 결과를 해석하는 방법
이번 그룹은 모두 동일한 방식으로 결과를 해석해서는 안 된다.
| 항목 | 자동 진단이 확인하는 핵심 | 수동 확인이 필요한 부분 |
| U-64 | OS·커널 정보, 최근 패키지 작업 이력 | 실제 보안 패치 수준, 벤더 권고사항 반영 여부 |
| U-65 | NTP 데몬 실행 및 서버 설정 | 실제 시간 동기화 상태, 네트워크 연동 여부 |
| U-66 | 주요 로깅 데몬 프로세스 실행 여부 | 로그 생성·보관·전송·용량 정책 |
| U-67 | /var/log 소유자 및 기타 사용자 쓰기 권한 | 하위 로그 파일 권한, 서비스별 로그 작성 권한 |
따라서 자동 진단에서 [양호]가 확인되더라도 해당 항목 전체가 보안 요구사항을 충족한다고 단정하기보다 추가 확인이 필요한 범위를 식별하는 용도로 사용하는 것이 적절하다.
7. 현재 스크립트의 한계와 개선 포인트
7.1 분할 설정 파일 미검사
현재 스크립트는 주요 설정 파일을 직접 조회하는 방식이다.
실제 운영 환경에서는 설정이 하나의 파일에만 존재하지 않고 *.d 또는 별도의 설정 디렉터리로 분리되어 있을 수 있다.
예를 들어 NTP와 rsyslog는 메인 설정 파일 외에 분할 설정을 사용하는 환경이 있으므로 현재 스크립트만으로 전체 설정을 확인하는 데에는 한계가 있다.
특히 다음과 같은 형태의 분할 설정은 현재 기본 로직에서 빠질 수 있다.
/etc/chrony.d/*.conf
/etc/rsyslog.d/*.conf
7.2 journald 영속성 저장 여부 확인 부족
U-66은 현재 systemd-journald 프로세스가 동작하는지만 확인한다.
하지만 로그를 재부팅 이후에도 보존해야 하는 환경에서는 저장 정책까지 확인할 필요가 있다.
현재 개선 로직은 Storage=persistent가 명시적으로 설정되어 있는지 확인하는 방식이다.
# [개선 스크립트] 분할 설정 경로 및 journald 영속성 검사 보완
NTP_CONF_CHECK=$(grep -E -i -h "^[[:space:]]*(server|pool)" /etc/chrony.conf /etc/chrony.d/*.conf 2>/dev/null | grep -v "127.127.1.0")
JOURNAL_PERSIST=$(grep -E -i "^[[:space:]]*Storage[[:space:]]*=[[:space:]]*persistent" /etc/systemd/journald.conf 2>/dev/null)
if [ -n "$NTP_CONF_CHECK" ]; then
NTP_CONF_SAFE="TRUE"
fi
if systemctl is-active --quiet systemd-journald 2>/dev/null && [ -z "$JOURNAL_PERSIST" ]; then
INFO "systemd-journald가 동작 중이나 로그 저장소가 휘발성(volatile)일 수 있습니다. /etc/systemd/journald.conf 내 Storage=persistent 설정을 권장합니다."
fi
다만 이 개선 로직 역시 Storage=persistent 설정의 명시 여부를 확인하는 수준이므로, 실제 로그가 영속적으로 저장되고 있는지는 운영 환경에서 추가 확인해야 한다.
8. 실무 점검 순서
U-64~U-67을 운영 서버에서 확인할 때는 단순히 스크립트 실행 결과만 보는 것보다 다음 순서로 접근하는 것이 효율적이다.
① 패치 상태 확인
uname -r
rpm -qa
또는 Debian 계열이라면 패키지 상태를 확인한다.
dpkg -l
② 시간 동기화 상태 확인
chronyc tracking
chronyc sources -v
③ 로깅 서비스와 실제 로그 확인
systemctl status rsyslog
logger -p authpriv.info "Security Log Test"
④ 로그 디렉터리와 World-Writable 파일 확인
ls -ld /var/log
find /var/log -type f -perm -002 -ls
이 순서로 점검하면 패치 → 시간 → 로그 생성 → 로그 보호라는 흐름으로 시스템의 기본적인 운영 보안 상태를 확인할 수 있다.
9. 마무리
U-64~U-67은 운영체제의 최신 상태를 유지하고, 침해사고 발생 시 신뢰할 수 있는 로그를 확보하기 위한 기본적인 시스템 관리 항목이다.
다만 네 개 항목 모두 자동화 스크립트만으로 실제 보안 상태를 완전히 판단할 수 있는 것은 아니다.
U-64는 최근 업데이트 이력을 확인하더라도 실제 보안 패치 수준을 별도로 검토해야 하며, U-65는 시간 서버 설정뿐 아니라 실제 동기화 상태를 확인해야 한다. U-66 역시 로깅 데몬 프로세스가 실행 중이라는 사실과 실제 로그가 정상적으로 저장되는 것은 구분해야 한다. U-67은 /var/log 디렉터리 자체가 양호하더라도 하위 로그 파일 권한을 추가로 확인해야 한다.
결국 자동 진단 스크립트의 역할은 전체 시스템 상태를 빠르게 선별하고 추가 점검이 필요한 영역을 식별하는 것에 있다.
운영 환경에서 설정을 변경할 때는 반드시 기존 설정을 백업하고, 문법 오류와 서비스 영향을 먼저 검증한 후 단계적으로 적용해야 한다.
주의사항
본 점검 스크립트의 결과는 자동화된 1차 진단을 위한 참고 자료이며, 실제 취약점 판단은 운영 환경의 보안정책, 시스템 구성, 서비스 특성 및 수동 점검 결과를 종합하여 판단해야 한다.
특히 패치, NTP, 로깅, 로그 권한 관련 설정은 변경 과정에서 서비스 장애 또는 로그 유실이 발생할 수 있으므로 운영 서버에 적용하기 전에 테스트 환경에서 사전 검증하는 것을 권장한다.
함께 보면 좋은 글
'보안취약점점검_요약' 카테고리의 다른 글
| [리눅스 보안취약점 점검] SNMP·로그인 배너·sudo 권한 관리 U-59~U-63 자동화 스크립트 분석 (0) | 2026.09.21 |
|---|---|
| [리눅스 보안취약점 점검] FTP·SNMP 서비스 보안 U-54~U-58 자동화 스크립트 분석 (0) | 2026.09.18 |
| [리눅스 보안취약점 점검] DNS·원격 접속·FTP 정보노출 U-49~U-53 자동화 스크립트 분석 (0) | 2026.09.17 |
| [리눅스 보안취약점 점검] 레거시 서비스와 메일 서버 보안 U-44~U-48 자동화 스크립트 분석 (0) | 2026.09.16 |
| [리눅스 보안취약점 점검] NFS·RPC·NIS 서비스 관리 U-39~U-43 자동화 스크립트 분석 (0) | 2026.09.15 |