조회수: 0

리눅스 서버에서 보안을 강화하려면 누가 어떤 파일에 손을 대는지 먼저 알아야 한다. 단순한 로그만으로는 실제로 어떤 계정이 어느 시점에 어떤 파일을 열고 수정했는지 추적하기 어렵다. 여기서 등장하는 도구가 리눅스 감사 시스템인 auditd다.
auditd는 커널 수준에서 파일 접근과 시스템 호출을 기록해 주기 때문에 웹 로그나 애플리케이션 로그로는 잡히지 않는 저수준 활동까지 남길 수 있다. 특히 중요한 설정 파일이나 민감 데이터가 있는 디렉터리에 대해 파일 접근 모니터링을 구성하면 침해 사고 분석과 내부 통제에 큰 도움이 된다.

이 글에서는 auditd 설치부터 규칙 작성, 로그 분석 방법, 실제 운영 시 주의점까지 파일 접근 모니터링에 초점을 맞춰 정리한다.

auditd 구성 요소 간단 정리

auditd로 파일 접근 모니터링을 구성하기 전에 구성 요소를 간단히 정리해 두면 전체 흐름이 더 잘 보인다.

• auditd
  백그라운드에서 동작하는 데몬이다. 커널에서 올라오는 감사 이벤트를 받아 로그 파일에 기록한다.
• auditctl
  감사 규칙을 동적으로 추가하거나 제거할 때 사용하는 명령행 도구다.
• ausearch
  기록된 감사 로그에서 조건에 맞는 이벤트를 검색하는 도구다.
• aureport
  감사 로그를 요약해 통계와 리포트 형태로 보여 주는 도구다.
• audit 로그 파일
  기본으로는 var log audit 아래에 저장되며, 여기서 모든 감사 이벤트를 확인할 수 있다.

이 구성 요소를 이해해 두면 실제로 파일 접근 규칙을 추가하거나 로그를 분석할 때 어떤 도구를 써야 하는지 감이 잡힌다.

auditd 설치와 기본 설정

배포판에 따라 패키지 이름이 조금 다르지만 대체로 다음과 같은 방식으로 설치할 수 있다.

# RHEL 계열 예시
yum install audit

# Debian 계열 예시
apt install auditd audispd plugins

설치 후에는 부팅 시 자동으로 시작되도록 설정하고 서비스를 올린다.

systemctl enable auditd
systemctl start auditd
systemctl status auditd

상태가 활성으로 표시되면 기본적인 감사 기능은 사용할 준비가 된 것이다.

auditd 기본 설정 파일 확인

기본 설정은 보통 etc audit auditd conf 에서 관리한다. 여기서 중요한 항목 몇 가지만 짚어 보자.

• log 파일 위치
  log_file 항목으로 지정된다. 일반적으로 var log audit audit log 경로를 사용한다.
• 로그 최대 크기와 롤링
  max_log_file 값과 max_log_file_action 값으로 크기에 따른 동작을 지정한다. 디스크가 가득 차지 않도록 적절한 값으로 설정하는 것이 중요하다.
• 큐 길이와 버퍼 설정
  이벤트가 폭주하는 상황에서 감사 로그가 유실되지 않도록 큐 관련 옵션을 함께 조정할 수 있다.

초기 구축 단계에서는 기본값으로도 충분한 경우가 많지만, 운영 환경에서는 로그 용량과 디스크 사용량을 고려해 튜닝하는 편이 좋다.

파일 접근 모니터링 규칙 설계

이제 실제로 어떤 파일을 감시할지, 어떤 이벤트를 기록할지 규칙을 설계해야 한다. 이 단계에서 방향을 잘 잡지 못하면 로그가 과도하게 쌓이거나 정작 중요한 이벤트를 놓치기 쉽다.

무엇을 감시할지 우선순위 정하기

일반적으로 다음과 같은 대상에 파일 접근 모니터링을 적용한다.

• 시스템 핵심 설정 파일
  예 등 passwd shadow sudoers 관련 설정 파일
• 보안 관련 설정 디렉터리
  ssh 설정 디렉터리 웹 서버 설정 디렉터리 방화벽 정책 파일 등
• 애플리케이션 설정 디렉터리
  var www 혹은 opt app 아래의 설정 파일과 템플릿 파일 등
• 민감 데이터가 존재하는 디렉터리
  데이터 덤프 파일 로그 백업 파일 내부 보고서 등

처음부터 모든 파일에 감사 규칙을 걸면 로그가 폭발적으로 늘어나 운영이 어려워진다. 리스크가 높은 경로부터 순차적으로 적용하는 전략이 좋다.

audit 규칙의 기본 구조 이해

파일 접근 모니터링을 위한 가장 단순한 규칙 형식은 다음과 같다.

-a always,exit -F path=/etc/passwd -F perm=rwxa -F auid>=1000 -F auid!=unset -k passwd_watch

또는 특정 파일이나 디렉터리를 감시하는 간단한 형식도 자주 사용한다.

-w /etc/passwd -p rwxa -k passwd_watch

주요 요소를 해석해 보면 다음과 같다.

• w 옵션
  해당 경로를 감시 대상으로 등록한다.
• p 옵션
  어떤 권한 동작을 기록할지 지정한다.
  r은 읽기 w는 쓰기 x는 실행 a는 속성 변경이다.
• k 옵션
  규칙에 태그를 붙이는 역할을 한다. 나중에 ausearch에서 이 태그로 검색하기 쉽도록 의미 있는 이름을 붙이는 것이 좋다.

디렉터리 하나를 감시하면 그 디렉터리 안의 파일 접근이 함께 기록된다. 다만 깊은 서브 디렉터리 구조까지 모두 포함하려면 w 대신 dir 필터를 사용한 규칙을 별도로 추가하는 방식도 있다.

규칙 파일에 영구 적용하기

auditctl 명령으로 규칙을 추가하면 즉시 반영되지만 재부팅 후에는 사라진다. 운영 환경에서는 규칙 파일을 사용해 영구적으로 유지해야 한다.

대표적인 방법은 다음 두 가지다.

• etc audit audit rules 파일 사용
  시스템에 따라 이 파일을 직접 쓰기도 한다.
• etc audit rules d 아래에 규칙 파일 추가
  예를 들어 파일 접근과 관련된 규칙만 모아 file access rules 파일로 관리한다.

예시를 하나 만들어 보면 다음과 같다.

## 핵심 시스템 파일 감시
-w /etc/passwd -p wa -k system_passwd
-w /etc/shadow -p wa -k system_shadow

## 웹 애플리케이션 설정 디렉터리 감시
-w /var/www/html -p rwa -k web_conf

## 데이터 백업 디렉터리 감시
-w /data/backup -p rwa -k data_backup

규칙 파일을 저장한 뒤에는 다음 명령으로 규칙을 다시 로드한다.

augenrules --load

혹은 배포판에 따라 서비스 재시작 과정에서 자동으로 규칙을 불러오기도 한다.

audit 로그 확인과 분석 방법

규칙을 적용했으면 실제로 파일을 열거나 수정하면서 로그가 잘 남는지 확인해야 한다. 가장 먼저 var log audit audit log 파일을 직접 열어 보면 된다.

tail -f /var/log/audit/audit.log

로그에는 type SYSCALL PATH USER AVC 와 같은 레코드가 여러 줄 나오고 하나의 이벤트가 여러 줄로 구성된다. 이 상태로는 읽기가 불편하므로 보통 ausearch와 aureport를 함께 사용한다.

ausearch로 특정 파일과 키 검색

ausearch는 조건을 주고 감사 로그를 검색할 수 있는 도구다. 예를 들어 passwd 파일 감시 규칙에서 k 값으로 system_passwd를 사용했다면 다음처럼 검색할 수 있다.

ausearch -k system_passwd

또는 특정 파일 경로로 직접 검색할 수도 있다.

ausearch -f /etc/passwd

필요하면 시간 범위 조건을 추가해 좁혀 볼 수 있다.

ausearch -k system_passwd -ts recent
ausearch -k system_passwd -ts today

검색 결과 한 건을 자세히 보면 대략 다음과 같은 정보를 얻을 수 있다.

• 언제 발생했는지
• 실제로 명령을 실행한 계정의 UID와 로그인한 사용자의 ID
• 어느 프로세스가 어떤 시스템 호출로 파일을 건드렸는지
• 접근이 성공했는지 실패했는지

이 정보만으로도 누가 어떤 파일을 수정했는지 상당히 구체적인 추적이 가능해진다.

aureport로 요약 리포트 확인

aureport는 감사 로그를 요약해 주는 역할을 한다. 예를 들어 파일 관련 이벤트 위주로 보고 싶다면 다음과 같이 사용할 수 있다.

aureport -f

이 명령은 파일별로 접근 횟수와 성공 여부 같은 통계를 보여 준다. 필요하면 특정 기간을 지정해 트렌드를 보는 것도 가능하다.

또는 계정별 활동을 보고 싶다면 다음 명령을 사용할 수 있다.

aureport -u

이렇게 요약된 리포트는 월간 보안 점검이나 감사 보고서를 작성할 때 유용하다.

실전 운영에서 자주 겪는 이슈와 팁

파일 접근 모니터링이 잘 동작하더라도 실제 운영 단계에서 몇 가지 이슈를 자주 마주치게 된다. 미리 알고 있으면 설계 단계에서 예방할 수 있다.

로그 용량과 성능 부담 관리

가장 흔한 문제는 로그가 너무 많이 쌓이는 상황이다. 파일 접근 규칙을 과도하게 설정하면 매 초마다 엄청난 이벤트가 기록되어 디스크를 금방 채워 버릴 수 있다.

이를 막으려면 다음 원칙을 참고하는 것이 좋다.

• 잦은 접근이 발생하는 캐시 디렉터리나 세션 디렉터리는 가능하면 제외한다.
• 읽기만 잦고 실제 보안 리스크는 낮은 파일은 w 권한만 감시하도록 조정한다.
• max_log_file 값과 로그 롤링 정책을 운영 환경에 맞게 조정한다.
• 너무 세밀하게 모든 파일을 감시하기보다는 진짜 중요한 경로 몇 개에 집중한다.

성능 부하 역시 마찬가지다. 규칙이 많을수록 커널이 이벤트를 평가하는 비용이 늘어나기 때문에, 의미 없는 규칙은 과감하게 제거하는 편이 전체 성능에 도움 된다.

규칙 태그와 운영 절차 정리

k 태그는 단순한 이름을 넘어서 운영 절차와 직접 연결되는 단위로 설계하는 것이 좋다.

예를 들어

• system_passwd
• web_conf
• db_backup

처럼 규칙을 나눠 두면

• 어떤 태그에 해당하는 이벤트가 발생했을 때
• 누구에게 알리고
• 어떤 조치를 취할지

를 문서화하기 쉽다. 모니터링 시스템에서 특정 태그가 포함된 이벤트만 알람으로 보내도록 연동하는 것도 좋다.

알람과 모니터링 시스템 연동

audit 로그는 기본적으로 로컬 파일이지만 보안 관제나 중앙 로깅 시스템과 연동하면 훨씬 효율적으로 활용할 수 있다.

보통 다음과 같은 흐름으로 구성한다.

1. 로컬에서 auditd가 로그를 기록한다.
2. 파일 비트비트나 에이전트를 통해 중앙 로그 서버로 전송한다.
3. 중앙 서버에서 k 태그와 필드를 기준으로 룰을 구성해 이상 징후를 탐지한다.
4. 특정 규칙에 해당하는 이벤트가 발생하면 메일이나 메시지로 알림을 발송한다.

이렇게 구성해 두면 단순한 감사 로그를 넘어 실시간 침입 탐지 수단으로 쓸 수 있다.

파일 접근 모니터링 구성 절차 정리

마지막으로 지금까지 내용을 토대로 auditd를 활용한 파일 접근 모니터링 구성 절차를 간단히 정리해 보자.

1. auditd와 관련 도구를 설치하고 서비스가 정상적으로 동작하는지 확인한다.
2. 감시가 필요한 파일과 디렉터리를 선정해 우선순위를 정한다.
3. etc audit rules d 아래에 규칙 파일을 만들고 w p k 옵션을 사용해 규칙을 작성한다.
4. augenrules 또는 서비스 재시작을 통해 규칙을 로드한다.
5. 테스트 계정으로 파일을 열고 수정 삭제를 시도해 var log audit audit log와 ausearch를 통해 로그가 잘 남는지 확인한다.
6. aureport로 요약 리포트를 살펴보면서 규칙이 과도한지 부족한지 조정한다.
7. 로그 용량과 성능에 영향을 주지 않는 범위에서 모니터링 시스템이나 관제 시스템과 연동해 알람을 구성한다.

이 흐름을 한 번 경험해 두면 새로운 서버나 애플리케이션이 생길 때마다 같은 패턴으로 빠르게 파일 접근 모니터링을 붙일 수 있다.
결국 auditd를 활용한 파일 접근 모니터링은 단순히 로그를 남기는 작업을 넘어, 누가 언제 무엇을 했는지를 재현할 수 있는 토대를 만드는 일이다. 이 토대가 탄탄해야 사고가 발생했을 때 흔들리지 않고 원인을 찾고 재발을 막을 수 있다.