운영체제와 서버 시스템을 관리하다 보면 예측할 수 없는 수많은 문제와 마면하게 됩니다. 이유 없이 특정 프로세스가 종료되거나, 원인을 알 수 없는 성능 저하가 발생하거나, 인가되지 않은 사용자가 시스템 침입을 시도하는 상황 등이 대표적입니다.
이러한 문제 상황에서 엔지니어가 가장 먼저 찾아야 하는 단서이자 시스템의 블랙박스 역할을 하는 것이 바로 '로그(Log)'와 '감사(Audit) 시스템'입니다. 리눅스 환경에서 시스템의 모든 움직임을 기록하고 추적하는 로그 관리 기법과 더 강력한 보안을 위한 커널 수준의 감사 시스템에 대해 실무 예제를 중심으로 상세히 살펴보겠습니다.
리눅스 시스템에서 발생하는 대부분의 이벤트는 rsyslog 데몬을 통해 수집되어 /var/log 디렉토리 하위의 목적별 로그 파일에 기록됩니다. 시스템 관리자는 각 로그 파일의 용도와 특징을 정확히 알고 있어야 장애 발생 시 신속하게 대처할 수 있습니다.
/var/log/messages (또는 Ubuntu의 /var/log/syslog): 시스템 전체에서 발생하는 전반적인 메시지가 기록되는 가장 일반적인 로그 파일입니다. 장치 드라이버 오류, 네트워크 상태 변화, 주기적인 크론탭 실행 결과 등이 모두 이곳에 담깁니다.
/var/log/secure (또는 Ubuntu의 /var/log/auth.log): 사용자 로그인, sudo 명령어 실행, SSH 원격 접속 등 인증 및 보안과 관련된 모든 이벤트를 기록합니다. 보안 감사 시 가장 먼저 확인해야 하는 파일입니다.
/var/log/dmesg: 시스템이 부팅될 때 커널이 하드웨어를 인식하고 초기화하는 과정에서 발생한 메시지들이 기록됩니다. 시스템이 정상적으로 켜지지 않거나 특정 하드웨어가 동작하지 않을 때 유용합니다.
/var/log/cron: 예약된 작업인 크론탭(cron) 데몬이 주기적인 스크립트를 정상적으로 실행했는지 여부를 기록합니다.
rsyslog는 어떤 메시지를 어디에 저장할지 /etc/rsyslog.conf 설정 파일을 통해 제어합니다. 이때 로그 메시지는 '시설'과 '우선순위'의 조합으로 분류됩니다.
시설(Facility): 로그를 생성하는 주체 (예: auth, cron, daemon, kernel, mail 등)
우선순위(Priority): 로그의 위험도 및 심각성 수준 (예: debug < info < notice < warning < err < crit < alert < emerg)
로그인 실패나 권한 획득 오류 등 중요한 보안 경고 메시지만 별도로 모아 실시간으로 모니터링하고 싶다면 다음과 같이 설정할 수 있습니다.
Bash
# /etc/rsyslog.conf 파일 수정 (또는 /etc/rsyslog.d/ 하위에 설정 파일 추가)
# 인증 관련(auth, authpriv) 메시지 중 warning 등급 이상(*.warning)을 특정 파일에 기록하도록 지정
auth,authpriv.warning /var/log/security_alerts.log
# 설정을 적용하기 위해 rsyslog 서비스 재시작
systemctl restart rsyslog
시스템이 활발하게 운영될수록 로그 파일의 크기는 기하급수적으로 늘어납니다. 만약 로그 파일이 디스크 공간을 모두 차지해 버리면(Disk Full), 시스템 전체가 다운되거나 데이터베이스가 멈추는 치명적인 장애가 발생합니다. 이를 방지하기 위해 로그를 주기적으로 분할하고 압축하여 관리하는 도구가 logrotate입니다.
logrotate는 일 단위, 주 단위 등으로 기존 로그 파일의 이름을 변경(예: messages -> messages.1)하고 새 로그 파일을 생성하며, 오래된 로그는 자동으로 삭제하거나 압축 보관합니다.
/var/log/myapp/ 디렉토리에 생성되는 자체 개발 애플리케이션의 로그 파일(output.log)을 안전하게 관리하기 위해 다음과 같이 설정을 추가할 수 있습니다.
Bash
# /etc/logrotate.d/myapp 설정 파일 생성
cat << 'EOF' > /etc/logrotate.d/myapp
/var/log/myapp/*.log {
daily # 매일 로그를 순환(로테이트)함
rotate 30 # 최대 30일치(30개)의 과거 로그 파일만 유지하고 이전 것은 삭제
compress # 오래된 로그 파일은 gzip으로 압축하여 디스크 공간 절약
delaycompress # 최신 바로 전 단계의 로그(.1)는 압축하지 않고 다음 순환 때 압축 (가독성 확보)
missingok # 로그 파일이 없어도 에러를 내지 않고 넘어감
notifempty # 로그 파일 크기가 0이면 순환하지 않음
create 0640 myappuser myappgroup # 순환 후 새로 생성될 로그 파일의 권한과 소유주 지정
sharedscripts # 와일드카드(*)로 여러 로그가 지정되어도 스크립트는 한 번만 실행
postrotate
/usr/bin/systemctl kill -s HUP myapp.service >/dev/null 2>&1 || true
endscript # 로그 파일이 바뀌었음을 애플리케이션 데몬에 알려 새 파일에 기록하게 함
}
EOF
rsyslog가 애플리케이션이나 서비스가 자발적으로 던져주는 메시지를 수동적으로 받아 적는 방식을 취한다면, 리눅스 커널 감사 시스템인 auditd는 커널 레벨에서 발생하는 모든 시스템 호출(System Call)을 감시하는 능동적인 시스템입니다.
누가 어떤 파일을 열었는지, 어떤 프로세스가 네트워크 소켓을 열었는지, 어떤 사용자가 시스템 설정을 바꾸었는지 등 사용자의 행위를 부인방지(Non-repudiation) 형태로 명확하게 기록할 수 있어 강력한 보안 표준(ISMS-P, ISO27001 등)을 충족하기 위한 필수 솔루션입니다.
auditd는 세 가지 유형의 규칙을 가집니다.
Control 규칙: 감사 시스템 자체의 설정이나 버퍼 크기를 변경합니다.
File System 규칙: 특정 파일이나 디렉토리에 대한 접근(읽기, 쓰기, 실행, 속성 변경)을 감시합니다.
System Call 규칙: 특정 프로세스나 사용자가 호출하는 커널 시스템 콜을 가로채어 기록합니다.
규칙은 auditctl 명령어로 임시 적용하거나, /etc/audit/rules.d/audit.rules 파일에 기입하여 영구 적용할 수 있습니다.
시스템 계정 정보가 담긴 /etc/passwd 파일이나 패스워드 암호화 값이 있는 /etc/shadow 파일은 일반적인 상황에서 수정될 일이 거의 없습니다. 누군가 이 파일을 변경하거나 열어보려고 시도하는 행위를 실시간으로 감시해 보겠습니다.
Bash
# 규칙 추가 명령어 구조:
# -w [경로]: 감시할 대상 파일 경로
# -p [wa_r_x]: 감시할 행위 지정 (w: 쓰기, a: 속성 변경, r: 읽기, x: 실행)
# -k [키워드]: 나중에 로그를 쉽게 검색하기 위해 붙이는 임의의 태그명
auditctl -w /etc/shadow -p wa -k shadow_changes
이제 임의로 passwd 명령어를 수행하여 비밀번호를 변경하거나 누군가 가짜 계정을 주입하려고 하면 커널이 이 행위를 즉시 잡아내어 /var/log/audit/audit.log에 기록합니다.
외부 협력 업체 직원이나 인턴 사원 등 특정 계정(user01)이 시스템에 접속하여 어떤 명령어를 실행하고 다니는지 일일이 감시해야 하는 엄격한 보안 요구사항이 있을 때 유용합니다. 이 경우 프로세스를 생성하는 시스템 콜인 execve를 감시합니다.
Bash
# 규칙 추가 명령어 구조:
# -a always,exit: 시스템 콜이 끝나는 시점에 항상 기록함
# -S execve: execve(프로세스 실행) 시스템 콜을 지정
# -F auid=1001: 최초 로그인 시점의 실제 사용자 ID(AUID)가 1001번인 사용자 지정
# -k user_commands: 태그 지정
auditctl -a always,exit -S execve -F auid=1001 -k user_activity
이 설정을 마치면 해당 사용자가 터미널에서 입력하는 모든 명령어와 실행 파일의 인자값까지 고스란히 감사 로그에 저장됩니다.
audit.log 파일은 기계가 읽기 좋은 정형화된 형태로 빽빽하게 출력되기 때문에 cat이나 grep으로 직접 분석하기에는 가독성이 매우 떨어집니다. 따라서 전용 분석 도구인 ausearch와 통계 도구인 aureport를 사용해야 합니다.
앞서 규칙을 만들 때 설정한 태그명(-k)을 이용하면 방대한 로그 덤프 속에서 원하는 사건만 짚어낼 수 있습니다.
Bash
# 'shadow_changes' 태그가 붙은 감사 로그만 골라서 보기
ausearch -k shadow_changes
# 오늘 발생한 이벤트 중 인증 실패(failed) 건만 검색하기
ausearch --start today --success no
# 특정 프로세스 ID(PID: 2543)가 수행한 작업 추적하기
ausearch -p 2543
aureport는 시스템 전체 가동 상태에 대한 요약 보고서를 만들어 줍니다.
Bash
# 시스템에서 발생한 모든 로그인 시도와 성공/실패 여부를 요약하여 표 형태로 출력
aureport -l
# 변경되거나 실행된 시스템 파일에 대한 통계 보고서 출력
aureport -f
로그와 감사 시스템이 아무리 완벽하더라도 이를 관리하는 체계가 부실하면 무용지물이 될 수 있습니다. 침해 사고를 일으킨 해커나 악의적인 내부 사용자가 시스템 권한을 획득한 후 가장 먼저 하는 행동은 자신의 행위가 담긴 로그 파일(audit.log, secure 등)을 변조하거나 삭제하는 일이기 때문입니다.
이를 방어하기 위해 실무에서는 다음과 같은 추가 보안 전략을 연계하여 운영합니다.
원격 로그 서버(중앙 집중형 로그 저장소) 구축: 로그가 로컬 서버에만 저장되어 있으면 서버 장치 파손이나 로그 강제 삭제 시 복구가 불가능합니다. rsyslog 설정을 통해 로그가 발생하는 즉시 별도의 물리적으로 분리된 원격 보안 로그 서버(또는 SIEM 솔루션)로 실시간 전송하도록 구성해야 합니다.
로그 파일 추가 전용 속성 부여: chattr +a /var/log/messages 명령어를 사용하면 root 관리자라 할지라도 기존 로그 내용을 수정하거나 삭제할 수 없고 오직 내용을 추가(Append)하는 것만 가능하게 제한할 수 있습니다. 로그 변조를 원천 차단하는 간단하고 유용한 방법입니다.
적절한 Auditd 버퍼 설정: 감사 대상을 너무 광범위하게 설정하면(예: 모든 시스템의 읽기 행위 감시) 시스템 커널 자원을 과도하게 소모하여 서버 성능이 저하될 수 있으며, 감사 로그용 버퍼가 가득 차 시스템이 멈출 수 있으므로 핵심 자산 위주로 정밀하게 규칙을 설계해야 합니다.
로그 관리와 감사는 사후 분석만을 위한 도구가 아닙니다. 주기적인 로그 분석과 엄격한 커널 감사는 예기치 못한 시스템 오류의 전조증상을 포착하고 보안 위협을 사전에 인지하여 차단할 수 있는 훌륭한 능동형 방어 체계입니다.