[U-67] 로그 디렉터리 소유자 및 권한 설정 (중요도 : 중)

ª_ª — Sun, 15 Mar 2026 10:04:55 +0900

주요정보통신기반시설 가이드 [U-67] 유닉스/리눅스 보안 설정

항목 중요도 : 중 (로그 데이터 무결성 보호 및 변조 방지)

1. 항목 개요 및 보안 위협
2. OS별 로그 디렉터리 권한 조치 실습 (상세 명령어)
3. 법적 근거 및 관련 지침
4. 오늘 공부하며 정리한 핵심 포인트

1. 항목 개요 및 보안 위협

출처 : 2026 주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드

[ 점검 내용 ] : 시스템의 각종 로그 파일이 저장되는 디렉터리와 로그 파일 자체에 대해 비인가자의 쓰기 및 수정 권한이 차단되어 있는지 점검합니다.

[ 보안 위협 ] : 로그 파일에 일반 사용자의 쓰기 권한이 부여되어 있으면, 악의적인 사용자가 자신의 침입 흔적을 지우기 위해 로그를 삭제하거나 조작할 수 있습니다. 또한, 로그 디렉터리 권한이 과도할 경우 로그 파일을 다른 파일로 교체(심볼릭 링크 공격 등)하여 시스템 장애를 유도할 수 있는 위협이 존재합니다.

2. OS별 로그 디렉터리 권한 조치 실습

SOLARIS, LINUX 환경

/var/log/ 디렉터리 내 주요 로그 보호

# Step 1) 로그 파일 소유자를 root로 변경
# chown root /var/log/[파일 이름]

# Step 2) 로그 파일 권한을 644(또는 640)로 설정
# chmod 644 /var/log/[파일 이름]

※ 실습 대상: messages, secure, auth.log, syslog 등

AIX 환경

/var/adm/ 경로 내 로그 보안 설정

# Step 1) /var/adm/ 디렉터리 내 로그 파일 관리
# chown root /var/adm/[파일 이름]
# chmod 644 /var/adm/[파일 이름]

HP-UX 환경

/var/adm/syslog/ 경로 내 로그 무결성 확보

# Step 1) syslog 전용 디렉터리 내 파일 보호
# chown root /var/adm/syslog/[파일 이름]
# chmod 644 /var/adm/syslog/[파일 이름]

[취약 결과 예시]

# ls -l /var/log/messages
-rw-rw-rw- 1 user group ... /var/log/messages (소유자가 root가 아니거나 모든 사용자가 수정 가능한 상태)

[양호 결과 예시]

# ls -l /var/log/messages
-rw-r--r-- 1 root root ... /var/log/messages (소유자가 root이며, 타인에게는 읽기 권한만 부여된 상태)

3. 법적 근거 및 관련 지침

1. 정보통신기반보호법 제9조(취약점 분석 평가) : 로그 위·변조 방지 및 안전한 보관을 위한 기술적 조치 이행 여부 점검
2. 정보통신기반시설 보호지침 제16조(설정관리) : 시스템 로그 파일의 소유권 및 접근 권한 제한을 통한 무결성 확보 기준 준수

4. 오늘 공부하며 정리한 핵심 포인트

■ 로그 소유권의 단일화 : 시스템의 모든 주요 보안 로그는 반드시 관리자(root) 계정이 소유하도록 설정
■ 접근 권한의 최소화 : 일반 사용자가 로그를 수정하거나 삭제할 수 없도록 644(rw-r--r--) 이하의 권한 유지 권장
■ OS별 경로 차이 숙지 : Linux/Solaris(/var/log), AIX/HP-UX(/var/adm) 등 시스템별 로그 저장 위치 파악 및 전수 점검
■ 정기적 무결성 감사 : 권한 설정 변경 외에도 로그 파일의 크기 급변이나 소유자 변경 여부를 주기적으로 모니터링

다음 공부 기록 예고 : [W-01] Administrator 계정 이름 변경 등 보안성 강화 (중요도 : 상)

[U-66] 정책에 따른 시스템 로깅 설정 (중요도 : 중)

ª_ª — Sat, 14 Mar 2026 10:04:09 +0900

주요정보통신기반시설 가이드 [U-66] 유닉스/리눅스 보안 설정

항목 중요도 : 중 (시스템 로그 기록 정책 최적화)

1. 항목 개요 및 보안 위협
2. OS별 로깅 정책 설정 및 재시작 실습 (상세 예시)
3. syslog.conf 파일 형식 및 우선순위 완벽 정리
4. 오늘 공부하며 정리한 핵심 포인트

1. 항목 개요 및 보안 위협

출처 : 2026 주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드

[ 점검 내용 ] : 시스템의 용도와 보안 정책에 부합하도록 로그 파일별 기록 대상(Facility)과 수준(Level)이 적절히 설정되어 있는지 점검합니다.

[ 보안 위협 ] : 로깅 정책이 미흡하여 중요 보안 이벤트(인증 실패, 시스템 오류 등)가 누락될 경우, 침해 사고 발생 시 공격자의 행위를 추적할 수 없습니다. 또한 모든 로그를 한 파일에만 기록하거나 우선순위 설정이 잘못되면 로그 데이터 폭증 시 중요한 정보를 식별하기 어려워집니다.

2. OS별 로깅 정책 설정 및 재시작 실습

SOLARIS 및 LINUX 환경

Step 1) syslog.conf / rsyslog.conf 설정 수정

# vi /etc/rsyslog.conf
*.info;mail.none;authpriv.none;cron.none    /var/log/messages
authpriv.* /var/log/secure
mail.* /var/log/maillog
cron.* /var/log/cron
*.emerg                                     *

Step 2) 설정 적용 및 서비스 재시작

# (Linux) systemctl restart rsyslog
# (Solaris) svcadm refresh svc:/system/system-log:default

AIX 및 HP-UX 환경

관리 경로(adm) 중심의 로그 설정

# [AIX/HP-UX 공통] vi /etc/syslog.conf
auth.info            /var/adm/auth.log
*.err                /var/adm/error.log
*.emerg              *

# [설정 반영]
# (AIX) refresh -s syslogd
# (HP-UX) kill -1 [syslogd_PID]

3. syslog.conf 파일 형식 및 우선순위 완벽 정리

데몬 종류 (Facility)	우선순위 (Level)
auth / authpriv: 로그인 및 인증 관련	emerg (4): 매우 위험한 상황
cron: 예약 작업 관련	alert (3): 즉각 조치 필요
kern: 커널 메시지	crit (2): 심각한 하드웨어 오류
daemon: FTP, Telnet 등 서비스 데몬	err (1): 에러 발생
mail: 메일 시스템	info (-2): 단순 프로그램 정보

※ 설정 형식: [서비스데몬].[로그레벨] [로그파일경로] (예: auth.info /var/log/auth.log)

4. 오늘 공부하며 정리한 핵심 포인트

■ 로그 기록의 세분화 : 인증(auth), 메일(mail), 예약작업(cron) 등 서비스 성격에 맞게 별도 파일로 분리 기록
■ 우선순위 최적화 : 단순 정보(info)부터 비상 상황(emerg)까지 등급별로 기록 대상을 지정하여 관리 효율성 증대
■ 실시간 가시성 확보 : 매우 위험한 상황(alert, emerg)은 콘솔(/dev/console)이나 접속 중인 모든 사용자(*)에게 즉시 출력되도록 설정
■ 설정 반영의 완결성 : 파일 수정 후 반드시 OS별 서비스 재시작 명령어(refresh, restart, kill -1)를 수행하여 실제 로깅 여부 확인

다음 공부 기록 예고 : [U-67] 로그 디렉터리 소유자 및 권한 설정 (중요도 : 중)

[U-65] NTP 및 시각 동기화 설정 (중요도 : 중)

ª_ª — Fri, 13 Mar 2026 10:04:38 +0900

주요정보통신기반시설 가이드 [U-65] 유닉스/리눅스 보안 설정

항목 중요도 : 중 (시스템 시각 동기화 및 로그 신뢰성 확보)

1. 항목 개요 및 보안 위협
2. OS별 NTP/Chrony 동기화 설정 실습 (상세 출력 예시)
3. 법적 근거 및 관련 지침
4. 오늘 공부하며 정리한 핵심 포인트

1. 항목 개요 및 보안 위협

출처 : 2026 주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드

[ 점검 내용 ] : 시스템 시각을 표준 시각과 동기화하기 위해 NTP(Network Time Protocol) 또는 Chrony 서비스가 적절히 설정되어 있는지 점검합니다.

[ 보안 위협 ] : 서버 시각이 일치하지 않을 경우 침해 사고 발생 시 각 서버의 로그 분석을 통한 타임라인 구성이 불가능해져 사고 원인 파악 및 추적이 매우 어려워집니다. 또한 시간 기반 인증(OTP 등) 실패나 시스템 간 데이터 동기화 오류로 인한 서비스 가용성 문제도 발생할 수 있습니다.

2. OS별 NTP/Chrony 동기화 설정 실습

SOLARIS, AIX, HP-UX 환경

Step 1) 동기화 상태 점검

# ntpq -pn
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*1.2.3.4         .GPS.            1 u   12   64  377    0.123    0.045   0.012

※ 핵심 확인: remote 항목 앞에 '*' 표시가 있어야 현재 해당 서버와 동기화 중임을 의미합니다.

Step 2~3) ntp.conf 설정 및 재시작

# vi /etc/ntp.conf
server [NTP_SERVER_IP]

# [서비스 재시작]
# (Solaris) svcadm restart ntp
# (AIX) stopsrc -s xntpd && startsrc -s xntpd

LINUX 환경 (NTP / Chrony)

최신 RHEL/CentOS 계열은 Chrony 사용 권장

# [Chrony 상태 확인]
# chronyc sources -v
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
^* ntp.server.com               2   6    37    13    -13us[ +209us] +/-  56ms

Step 3~4) Chrony 설정 및 반영

# vi /etc/chrony.conf
server [NTP_SERVER_IP] iburst

# [서비스 재시작]
# systemctl restart chronyd

[취약 결과 예시]

# ntpq -pn
No association ID's returned (NTP 서비스가 기동되지 않았거나 서버 정보가 없는 상태)

[양호 결과 예시]

# ntpq -pn (또는 chronyc sources)
명시된 내부/외부 NTP 서버와 정상적으로 시각 동기화가 유지되고 있는 상태

3. 법적 근거 및 관련 지침

1. 개인정보 보호법 제29조 : 접속 기록의 위·변조 방지를 위한 정확한 시각 동기화 권고
2. 정보통신기반시설 보호지침 제16조 : 로그의 신뢰성 및 무결성 확보를 위한 시스템 시각 관리 기준 준수

4. 오늘 공부하며 정리한 핵심 포인트

■ 로그 분석의 정확성 확보 : 표준 시각 동기화를 통해 침해 사고 대응 시 타임라인의 일관성 유지
■ 서비스별 명령어 숙지 : 구형 시스템(NTP)과 신규 시스템(Chrony)의 상태 확인 및 설정 명령어 구분 적용
■ 동기화 상태 상시 모니터링 : 단순 서비스 가동 여부가 아닌 실제 서버와의 피어링(Peering) 상태('*' 표시 등) 주기적 점검
■ 네트워크 허용 확인 : NTP 서비스는 UDP 123 포트를 사용하므로 방화벽 등에서의 통신 허용 여부 사전 확인

다음 공부 기록 예고 : [U-66] 정책에 따른 시스템 로깅 설정 (중요도 : 중)

[U-64] 주기적 보안 패치 및 벤더 권고사항 적용 (중요도 : 상)

ª_ª — Thu, 12 Mar 2026 10:04:24 +0900

주요정보통신기반시설 가이드 [U-64] 유닉스/리눅스 보안 설정

항목 중요도 : 상 (보안 패치 및 시스템 무결성 유지)

1. 항목 개요 및 보안 위협
2. OS별 패치 확인 및 업데이트 실습 (상세 출력 예시)
3. 법적 근거 및 관련 지침
4. 오늘 공부하며 정리한 핵심 포인트

1. 항목 개요 및 보안 위협

출처 : 2026 주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드

[ 점검 내용 ] : 시스템 OS 및 커널, 주요 패키지에 대해 제조사가 배포한 최신 보안 패치가 주기적으로 적용되고 있는지 점검합니다.

[ 보안 위협 ] : 패치되지 않은 시스템은 이미 알려진 취약점(CVE) 공격에 무방비로 노출됩니다. 공격자는 패치 미적용 서버를 대상으로 원격 코드 실행(RCE)이나 권한 상승 공격을 수행하여 시스템 전체를 장악할 수 있습니다.

2. OS별 패치 확인 및 업데이트 실습

SOLARIS 환경 (pkg 관리)

Step 1) 설치된 패키지 및 IFO 상태 확인

# pkg list -af entire | head -5
NAME (PUBLISHER)                 VERSION                     IFO
entire                           11.4-11.4.42.0.0.11.0       i--
entire                           11.4-11.4.0.0.1.15.0        ---

※ IFO 필드 의미: i(Installed), f(Frozen), o(Obsolete). 설치된 버전은 반드시 'i'가 표시되어야 합니다.

Step 2) 업데이트 프리뷰 및 실행

# [프리뷰] pkg update -nv entire
# [실제 업데이트] pkg update --accept

AIX 환경 (oslevel & smitty)

Step 1) OS 레벨 및 패치 리스트 확인

# oslevel -s
7200-05-01-2038 (7.2 TL05 SP01 의미)

# instfix -i | grep ML
All items in 7200-05-00-2015_AIX_ML were found.

Step 2) smitty를 이용한 최신 패치(all-latest) 적용

1. # smitty installp
2. Install Software 선택
3. SOFTWARE to install -> [all-latest] 선택
4. ACCEPT new license agreements? -> [yes]

HP-UX 환경 (swinstall)

# [설치 리스트] swlist -l product
# [패치 압축 해제] sh PHNE_12345 (depot 파일 생성)
# [패치 설치] swinstall -x autoreboot=true -s /tmp/patch.depot

[취약 결과 예시]

# pkg list -af entire@latest
(현재 버전보다 최신 버전이 존재함에도 업데이트되지 않은 상태)

[양호 결과 예시]

# pkg list -af entire@latest
(설치된 버전이 최신 버전과 일치하며 SRU/Critical Patch가 모두 적용된 상태)

3. 법적 근거 및 관련 지침

1. 정보통신기반보호법 제9조 : 관리적/기술적 보호대책 강구 및 패치 관리 체계 점검
2. 정보통신기반시설 보호지침 제16조 : 최신 보안 패치 적용을 통한 시스템 취약점 상시 제거

4. 오늘 공부하며 정리한 핵심 포인트

■ 지원 종료(EOL) 확인 : 벤더사의 지원이 끝난 OS는 즉시 업그레이드 계획 수립
■ 분기/SRU 업데이트 : 정기적인 업데이트 주기를 설정하고 Critical Patch 우선 적용
■ 검증 후 배포 : 패치 적용 시 서비스 장애 방지를 위해 사전 백업 및 테스트 환경 검증 필수
■ 재부팅 일정 조율 : 커널 패치 등은 시스템 재시작이 동반되므로 운영 부서와 사전 협의

다음 공부 기록 예고 : [U-65] 로그 기록 설정 및 보관 (중요도 : 상)

[U-63] sudo 명령어 접근 관리 (중요도 : 중)

ª_ª — Wed, 11 Mar 2026 10:04:39 +0900

주요정보통신기반시설 가이드 [U-63] 유닉스/리눅스 보안 설정

항목 중요도 : 중 (권한 상승 방지를 위한 sudoers 관리)

1. 항목 개요 및 보안 위협
2. sudoers 파일 권한 및 설정 실습 (Step-by-Step)
3. 법적 근거 및 관련 지침
4. 오늘 공부하며 정리한 핵심 포인트

1. 항목 개요 및 보안 위협

출처 : 2026 주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드

[ 점검 내용 ] : 특정 사용자가 루트 권한을 획득할 수 있게 해주는 /etc/sudoers 파일이 관리자(root) 외에는 수정할 수 없도록 철저히 보호되고 있는지 점검합니다.

[ 보안 위협 ] : 만약 일반 사용자가 /etc/sudoers 파일을 수정할 수 있다면, 공격자는 본인의 계정에 모든 루트 권한(ALL)을 부여하는 코드를 삽입하여 시스템을 완전히 장악할 수 있습니다. 이는 서버 보안의 근간을 흔드는 심각한 권한 상승 위협이 됩니다.

2. sudoers 파일 권한 및 설정 실습

SOLARIS, LINUX, AIX, HP-UX 공통 실습

Step 1) /etc/sudoers 파일 소유자 및 권한 확인

# ls -l /etc/sudoers

※ 실습 화면 예시 (취약한 경우):
-rw-rw-r-- 1 user group ... /etc/sudoers (소유자가 root가 아니거나 일반 사용자 수정 가능)

Step 2) 소유자를 root로, 권한을 640으로 변경 (문단속)

# chown root /etc/sudoers
# chmod 640 /etc/sudoers

※ 조치 후 결과:
-rw-r----- 1 root root ... /etc/sudoers (성공! 이제 root만 읽고 쓸 수 있습니다.)

Step 3) visudo를 이용한 내부 권한 설정 검토

# visudo

※ 내부 설정 화면 예시:
root ALL=(ALL) ALL (기본 관리자 설정 확인)
%wheel ALL=(ALL) ALL (wheel 그룹 사용 시 신중히 검토)

[취약 결과 예시]

파일 소유자가 root가 아니거나, 권한이 640을 초과(예: 666, 777)하여 비인가자가 수정할 수 있는 경우

[양호 결과 예시]

파일 소유자가 root이며, 권한이 640(또는 일부 시스템 권고에 따라 440)으로 설정되어 엄격히 보호되는 경우

3. 법적 근거 및 관련 지침

1. 정보통신기반보호법 제9조 : 시스템 권한 탈취를 막기 위한 기술적 취약점 분석 및 보완 조치 의무화
2. 정보통신기반시설 보호지침 제16조 : 권한 부여 설정 파일의 소유자/권한 관리 표준 가이드라인 준수

4. 오늘 공부하며 정리한 핵심 포인트

■ 파일 소유권의 엄격성 : sudoers 파일은 반드시 root 소유여야 하며, 이를 위반 시 즉각 조치 필요
■ 접근 권한의 최소화 : 640 권한 설정을 통해 그룹과 타인(Other)에 의한 무단 수정 시도 원천 차단
■ visudo 사용 습관화 : 구문 오류로 인해 시스템 관리가 불가능해지는 사고를 막기 위해 직접 편집 대신 visudo 활용
■ 권한 부여의 신중함 : 특정 계정에 권한을 줄 때는 (ALL) 대신 필요한 특정 명령어(Command)만 지정하는 방식 권장

다음 공부 기록 예고 : [U-64] 주기적 보안 패치 및 벤더 권고사항 적용 (중요도 : 상)

[U-62] 로그인 시 경고 메시지 설정 (중요도 : 하)

ª_ª — Tue, 10 Mar 2026 10:04:21 +0900

주요정보통신기반시설 가이드 [U-62] 유닉스/리눅스 보안 설정

항목 중요도 : 하 (비인가 접속에 대한 법적 경고 및 정보 노출 방지)

1. 항목 개요 및 보안 위협
2. OS별 서비스 배너 및 재시작 상세 실습
3. 법적 근거 및 관련 지침
4. 오늘 공부하며 정리한 핵심 포인트

1. 항목 개요 및 보안 위협

출처 : 2026 주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드

[ 점검 내용 ] : 서버 접속 및 주요 네트워크 서비스(SSH, FTP, SMTP 등) 접속 시 시스템 정보 노출을 차단하고 법적 경고 문구가 표시되는지 점검합니다.

[ 보안 위협 ] : 배너에 OS 버전이나 패치 정보가 포함되면 공격자가 맞춤형 Exploit을 선택하는 단서가 됩니다. 또한 경고 문구가 없으면 침해 사고 시 비인가자의 '고의성' 입증 등 법적 대응이 어려워질 수 있습니다.

2. OS별 서비스 배너 및 재시작 상세 실습

SOLARIS 환경

# [서버 공통] vi /etc/motd, /etc/issue 수정
# [Telnet] vi /etc/default/telnetd -> BANNER=...
# [SSH] vi /etc/ssh/sshd_config -> Banner /etc/issue.net
# [Sendmail/Postfix/Exim] vi /etc/mail/sendmail.cf (또는 main.cf) 수정 후
# svcadm refresh [service_name] (예: sendmail, postfix, vsftpd)
# [ProFTP] vi proftpd.conf -> DisplayLogin 수정 후 svcadm refresh proftpd

LINUX 환경

# [서버 공통] vi /etc/motd, /etc/issue 수정
# [SSH] vi /etc/ssh/sshd_config -> Banner /etc/issue.net 설정 후
# systemctl restart sshd
# [SMTP/FTP] sendmail.cf, main.cf, vsftpd.conf 내 banner/greeting 수정 후
# systemctl restart [sendmail|postfix|vsftpd|proftpd]
# [DNS] vi /etc/named.conf -> version "경고메시지"; 설정 후
# systemctl restart named

AIX 환경

# [Telnet] vi /etc/security/login.cfg -> herald="경고메시지"
# [SSH] sshd_config 수정 후 stopsrc -s sshd && startsrc -s sshd
# [Sendmail] sendmail.cf 수정 후 stopsrc -s sendmail && startsrc -s sendmail
# [FTP/DNS] 설정 수정 후 kill -1 [PID] 또는 stopsrc/startsrc 적용

HP-UX 환경

# [Telnet/FTP] vi /etc/inetd.conf -> 배너 경로 옵션 확인 후 inetd -c 적용
# [SSH/SMTP/DNS] 설정 파일 수정 후 서비스 프로세스에 시그널 전송
# kill -1 [PID] (sshd, sendmail, vsftpd 등)

[취약 결과 예시]

시스템 버전 정보가 그대로 노출되거나, 비인가자 접속 금지 경고 문구가 설정되지 않은 상태

[양호 결과 예시]

모든 접속 채널(서버, SSH, FTP 등)에서 시스템 정보를 숨기고 법적 경고문을 명시한 상태

3. 법적 근거 및 관련 지침

관련 법규 정보 (국가 법령 정보 센터)

1. 정보통신기반보호법 제9조(취약점 분석 평가) : 비인가 침입 방지를 위한 보안 설정 적절성 진단
2. 정보통신기반시설 보호지침 제16조(설정관리) : 시스템 접속 시 사용자 주의사항 및 법적 책임 고지 의무화

4. 오늘 공부하며 정리한 핵심 포인트

■ 정보 은닉의 원칙 : OS 버전, 호스트명 등 공격의 단서가 되는 정보 완전 제거
■ 법적 책임 명시 : 무단 접속 금지 및 위반 시 처벌 조항을 명시하여 책임 추적성 강화
■ 전수 적용 및 재시작 : 파일 수정 후 svcadm refresh, systemctl restart, inetd -c 등을 통한 즉각 반영 필수
■ 서비스별 고유 지시어 숙지 : Banner, SmtpGreetingMessage, ftpd_banner, version 등 엔진별 옵션 구분

다음 공부 기록 예고 : [U-63] sudo 명령어 접근 관리 (중요도 : 중)

[U-61] SNMP Access Control 설정 (중요도 : 상)

ª_ª — Mon, 9 Mar 2026 10:04:52 +0900

주요정보통신기반시설 가이드 [U-61] 유닉스/리눅스 보안 설정

항목 중요도 : 상 (SNMP 소스 IP 기반 접근 제어)

1. 항목 개요 및 보안 위협
2. OS별 SNMP 접근 제어(ACL) 설정 실습
3. 법적 근거 및 관련 지침
4. 오늘 공부하며 정리한 핵심 포인트

1. 항목 개요 및 보안 위협

출처 : 2026 주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드

[ 점검 내용 ] : SNMP 서비스를 이용할 때, 특정 관리자 호스트나 네트워크 대역에서만 접근할 수 있도록 소스 IP 기반의 접근 제어(ACL)가 적용되어 있는지 점검합니다.

[ 보안 위협 ] : 접근 제어 설정이 되어 있지 않으면, 커뮤니티 스트링을 탈취한 공격자가 전 세계 어디서든 해당 서버의 자원 정보를 조회하거나 설정을 변경할 수 있습니다. 특히 DDoS 공격의 매개체로 악용되거나 시스템 내부망 구조를 파악하는 용도로 사용될 위험이 큽니다.

2. OS별 SNMP 접근 제어(ACL) 설정 실습

SOLARIS 및 LINUX (Debian) 환경

snmpd.conf 내 허용 네트워크 명시

# vi /etc/snmp/snmpd.conf (또는 /etc/net-snmp/snmp/snmpd.conf)
rocommunity [Community_String] [허용할_네트워크_주소]
rwcommunity [Community_String] [허용할_네트워크_주소]

# 서비스 재시작
# systemctl restart snmpd (Linux)
# svcadm restart net-snmp (Solaris)

LINUX (Redhat 계열)

com2sec 지시어를 이용한 IP 제한

# vi /etc/snmp/snmpd.conf
com2sec notConfigUser [허용할_네트워크_주소] [Community_String]

# systemctl restart snmpd

AIX 및 HP-UX 환경

네트워크 주소 및 넷마스크 기반 차단

# [AIX] vi /etc/snmpdv3.conf
COMMUNITY [String] noAuthNoPriv [허용할_IP] [넷마스크]

# [HP-UX] vi /etc/snmpd.conf
trap-dest : [허용할_네트워크_주소]

# 서비스 재시작 및 적용 (stopsrc/startsrc 또는 inetd -c)

[취약 결과 예시]

SNMP 설정 내에 허용할 소스 IP나 네트워크 대역 제한이 없어 모든 호스트(any)에서 접근 가능한 상태

[양호 결과 예시]

Community String 설정 라인에 특정 관리자 IP 또는 신뢰할 수 있는 네트워크 대역이 명시된 상태

3. 법적 근거 및 관련 지침

관련 법규 정보 (국가 법령 정보 센터)

1. 정보통신기반보호법 제9조(취약점 분석 평가) : 전산 시스템의 주요 정보 노출 방지를 위한 접근 통제 적절성 평가
2. 정보통신기반시설 보호지침 제16조(설정관리) : 비인가자의 시스템 모니터링 및 정보 수집 차단을 위한 네트워크 소스 제한 기준 준수

4. 오늘 공부하며 정리한 핵심 포인트

■ 화이트리스트 기반 운영 : 허용할 IP/네트워크 주소를 명시하지 않으면 기본적으로 모든 접근이 차단되도록 설계
■ 다중 보안 적용 : Community String의 복잡성 설정과 소스 IP 제한 설정을 병행하여 보안 신뢰도 향상
■ 네트워크 대역 최소화 : 광범위한 서브넷보다는 실제 관리 서버의 단일 IP 주소 단위로 제한하는 것이 가장 안전
■ 설정 일관성 유지 : 메인 설정 파일(snmpd.conf 등) 외에도 OS 커널 방화벽(iptables 등)을 통한 추가적인 161/UDP 포트 제어 검토

다음 공부 기록 예고 : [U-62] 로그인 시 경고 메시지 설정 (중요도 : 하)

[U-60] SNMP Community String 복잡성 설정 (중요도 : 중)

ª_ª — Sun, 8 Mar 2026 10:04:51 +0900

주요정보통신기반시설 가이드 [U-60] 유닉스/리눅스 보안 설정

항목 중요도 : 중 (SNMP 인증 암호 복잡성 관리)

1. 항목 개요 및 보안 위협
2. OS별 Community String 설정 변경 실습
3. 법적 근거 및 관련 지침
4. 오늘 공부하며 정리한 핵심 포인트

1. 항목 개요 및 보안 위협

출처 : 2026 주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드

[ 점검 내용 ] : SNMP 서비스의 인증 수단인 Community String이 기본값(public, private 등)이 아닌 추측하기 어려운 복잡한 문자열로 설정되어 있는지 점검합니다.

[ 보안 위협 ] : Community String이 단순하게 설정되어 있을 경우 공격자는 SNMP 취약점 스캔을 통해 시스템의 CPU, 메모리 상태, 설치된 소프트웨어 목록, 네트워크 구성 정보 등을 무단으로 획득할 수 있습니다. 특히 쓰기(Write) 권한이 있는 문자열이 탈취될 경우 시스템 설정을 원격에서 임의로 변경하여 치명적인 장애를 유발할 수 있습니다.

2. OS별 Community String 설정 변경 실습

SOLARIS 환경

버전별 설정 파일 위치 및 지시어 확인

# [Solaris 10] /etc/snmp/conf/snmpd.conf 수정
rocommunity [복잡한_문자열]
rwcommunity [복잡한_문자열]

# [Solaris 11] /etc/net-snmp/snmp/snmpd.conf 수정
# svcadm refresh net-snmp (설정 반영)

LINUX 환경 (Redhat/Debian)

snmpd.conf 파일 수정 및 서비스 재시작

# vi /etc/snmp/snmpd.conf
# [Redhat 계열] com2sec notConfigUser default [변경값]
# [Debian 계열] rocommunity [변경값] default

# systemctl restart snmpd

AIX / HP-UX 환경

독자적인 설정 지시어 반영

# [AIX] vi /etc/snmpdv3.conf
COMMUNITY [새로운_String] [새로운_String] noAuthNoPriv 0.0.0.0 0.0.0.0 -

# [HP-UX] vi /etc/snmpd.conf
get-community-name : [변경값]
set-community-name : [변경값]

[취약 결과 예시]

Community String이 public 또는 private 등 기본값으로 설정되어 누구나 정보 조회가 가능한 경우

[양호 결과 예시]

기본 Community String을 삭제하고, 대소문자/숫자/특수문자가 포함된 복잡한 문자열을 적용한 경우

3. 법적 근거 및 관련 지침

관련 법규 정보 (국가 법령 정보 센터)

1. 정보통신기반보호법 제9조(취약점 분석 평가) : 비인가자의 시스템 정보 수집을 유발하는 취약한 인증 설정 개선 의무
2. 정보통신기반시설 보호지침 제16조(설정관리) : 시스템 관리 서비스에 대한 비밀번호 복잡성 정책 준수 및 정기적 변경 기준 규정

4. 오늘 공부하며 정리한 핵심 포인트

■ 기본값 제거의 필수성 : 유추하기 쉬운 'public', 'private' 문자열은 공격자의 1순위 타겟임을 명심
■ 복잡성 규칙 적용 : 일반 계정 패스워드와 동일하게 영문 대소문자, 숫자, 특수문자를 조합하여 생성
■ 권한별 차등 관리 : 읽기 전용(RO)과 읽기/쓰기(RW) 문자열을 다르게 설정하여 권한 노출 범위 최소화
■ 설정 반영의 완결성 : 파일 수정 후 반드시 OS별 서비스 재시작(systemctl restart, svcadm refresh 등)을 통해 실제 반영 여부 확인

다음 공부 기록 예고 : [U-61] SNMP Access Control 설정 (중요도 : 상)

[U-59] 안전한 SNMP 버전 사용 (중요도 : 상)

ª_ª — Sat, 7 Mar 2026 10:04:04 +0900

주요정보통신기반시설 가이드 [U-59] 유닉스/리눅스 보안 설정

항목 중요도 : 상 (SNMP 프로토콜 보안 강화)

1. 항목 개요 및 보안 위협
2. SNMP v3 설정 및 사용자 관리 실습
3. 법적 근거 및 관련 지침
4. 오늘 공부하며 정리한 핵심 포인트

1. 항목 개요 및 보안 위협

출처 : 2026 주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드

[ 점검 내용 ] : SNMP 서비스를 사용하는 경우, 보안성이 결여된 구버전(v1, v2c) 대신 인증과 암호화가 강화된 SNMP v3를 사용하고 있는지 점검합니다.

[ 보안 위협 ] : 구버전 SNMP는 커뮤니티 스트링(Community String)이 평문으로 전송되어 스니핑 공격에 매우 취약합니다. 공격자가 이를 가로챌 경우 시스템 정보 수집은 물론, 쓰기 권한을 이용한 설정 변경 등 심각한 침해 사고로 이어질 수 있습니다. 반면 v3는 개별 사용자 기반의 인증과 구간 암호화를 지원하여 이러한 위험을 방어할 수 있습니다.

2. SNMP v3 설정 및 사용자 관리 실습

SNMP v3 사용 여부 점검

snmpwalk 명령어를 이용한 v3 접속 테스트

# snmpwalk -v3 -l authPriv -u myuser -a SHA -A myauthpass -x AES -X myprivpass [서버IP]
(SHA 인증 및 AES 암호화 프로토콜 사용 예시)

v3 사용자 생성 및 설정 방법

Step 1) 유틸리티를 이용한 사용자 생성

# net-snmp-create-v3-user -ro -A myauthpass -X myprivpass -a SHA -x AES myuser

Step 2) snmpd.conf 파일 직접 수정 및 권한 부여

# vi /etc/snmp/snmpd.conf
createUser myuser SHA myauthpass AES myprivpass
rouser myuser

# 서비스 재시작
# systemctl restart snmpd

[취약 결과 예시]

보안이 취약한 SNMP v1 또는 v2c 버전을 여전히 사용 중이거나, v3 설정이 누락된 상태

[양호 결과 예시]

구버전 SNMP(v1, v2c) 사용을 중단하고, 인증/암호화 옵션이 적용된 SNMP v3를 운영 중인 상태

3. 법적 근거 및 관련 지침

관련 법규 정보 (국가 법령 정보 센터)

1. 정보통신기반보호법 제9조(취약점 분석 평가) : 네트워크 관리 데이터 유출 방지를 위한 보안 기술 적용 의무
2. 정보통신기반시설 보호지침 제16조(설정관리) : 비암호화 통신 채널의 지양 및 보안성이 확보된 최신 프로토콜 사용 기준 준수

4. 오늘 공부하며 정리한 핵심 포인트

■ SNMP v3의 3가지 핵심 보안 요소 : 사용자 인증(USM), 메시지 무결성 보호, 데이터 암호화 지원
■ 권장 프로토콜 사용 : 취약한 MD5/DES 대신 SHA 인증 및 AES 암호화 프로토콜 적용 필수
■ 최소 권한 제어 : rouser(읽기 전용)와 rwuser(읽기/쓰기)를 구분하여 용도에 맞는 사용자 권한 부여
■ 설정 무결성 확보 : createUser 명령어를 통한 보안 자격 증명 생성 후 snmpd.conf 파일 내 영구 반영 및 서비스 재시작

다음 공부 기록 예고 : [U-60] 사용자별 SNMP Community String 복잡성 설정 (중요도 : 중)

[U-58] 불필요한 SNMP 서비스 구동 점검 (중요도 : 중)

ª_ª — Fri, 6 Mar 2026 10:04:43 +0900

주요정보통신기반시설 가이드 [U-58] 유닉스/리눅스 보안 설정

항목 중요도 : 중 (네트워크 관리 프로토콜 보안)

1. 항목 개요 및 보안 위협
2. OS별 SNMP 서비스 비활성화 조치 실습
3. 법적 근거 및 관련 지침
4. 오늘 공부하며 정리한 핵심 포인트

1. 항목 개요 및 보안 위협

출처 : 2026 주요정보통신기반시설 기술적 취약점 분석·평가 방법 상세가이드

[ 점검 내용 ] : 시스템 모니터링 및 네트워크 관리를 위한 SNMP 서비스의 활성화 여부를 점검하고, 사용하지 않는 경우 이를 중지 및 비활성화합니다.

[ 보안 위협 ] : SNMP 서비스가 활성화되어 있으면 커뮤니티 스트링(Community String) 추측을 통해 시스템의 프로세스 정보, 네트워크 설정, 사용자 리스트 등 민감한 정보가 외부로 노출될 수 있습니다. 또한, SNMP v1/v2 등 취약한 버전을 사용할 경우 스니핑 공격에 의해 관리 권한이 노출될 수 있는 위험이 있습니다.

2. OS별 SNMP 서비스 비활성화 조치 실습

SOLARIS 환경

버전에 따른 SMF 또는 init 스크립트 제어

# [5.10 이상] svcadm disable svc:/application/management/snmpd:default

# [5.9 이하]
# /etc/init.d/init.snmpdx stop
# mv /etc/rc3.d/S76snmpdx /etc/rc3.d/_S76snmpdx

LINUX 환경

systemctl을 이용한 서비스 중지 및 자동 시작 방지

# systemctl list-units --type=service | grep snmpd
# systemctl stop snmpd
# systemctl disable snmpd

AIX / HP-UX 환경

데몬 중지 및 시동 설정 주석 처리

# [AIX] stopsrc -s snmpd
# vi /etc/rc.tcpip (start /usr/sbin/snmpd 관련 라인 주석 처리)

# [HP-UX] /sbin/init.d/snmpd stop

[취약 결과 예시]

snmpd 서비스(161/udp)가 활성화되어 시스템 관리 정보가 수집 가능한 상태

[양호 결과 예시]

불필요한 SNMP 서비스가 비활성화되어 관련 프로세스가 존재하지 않는 상태

3. 법적 근거 및 관련 지침

관련 법규 정보 (국가 법령 정보 센터)

1. 정보통신기반보호법 제9조(취약점 분석 평가) : 네트워크 관리 프로토콜의 취약한 설정 및 정보 노출 가능성 점검 의무
2. 정보통신기반시설 보호지침 제16조(설정관리) : 불필요한 네트워크 모니터링 서비스의 제거 및 관리 기준 준수

4. 오늘 공부하며 정리한 핵심 포인트

■ 시스템 정보 보호 : SNMP를 통해 노출되는 시스템 리소스 및 네트워크 구성 정보 유출 차단
■ 서비스 제거 우선 : 관리 목적으로 필수적인 경우가 아니라면 UDP 161 포트의 폐쇄 권장
■ 영구적 조치 반영 : 현재 구동 중인 데몬 종료와 함께 OS별 자동 실행 설정 파일(rc 스크립트 등) 수정
■ 버전 선택의 중요성 : 사용이 불가피한 경우 v1/v2 대신 암호화와 인증이 강화된 v3 사용 검토

다음 공부 기록 예고 : [U-59] 안전한 SNMP 버전 사용 (중요도 : 상)