Linux Audit System
리눅스 Audit 시스템은 해당 시스템의 보안관련 정보를 추적할 수 있도록 도와준다. 사전 설정된 규칙에 따라 Audit은 시스템에서 발생된 이벤트에 관해 많은 정보를 포함하는 로그를 생성하며 이러한 정보는 미션 크리티컬한 환경에서 보안 정책과 그들이 수행한 작업의 위반자를 파악하는데 결정적 역할을 할 수 있다. Audit은 추가적인 보안을 시스템에 제공하지 않지만 시스템에 적용된 보안정책의 위반을 파악하는데 이용되며 SELinux와 같은 추가적인 보안 수단과 조합해 사용한다면 위험을 예방하는 데에 많은 도움이 된다.
Audit이 자신의 로그로써 기록 가능한 요소들은 다음과 같다.
날짜와 시간, 유형 및 이벤트의 결과
주체와 객체의 민감도 레이블
일련의 이벤트를 발생시킨 사용자 ID
Audit의 모든 수정사항과 Audit 로그파일 접근시도
SSH나 Kerberos 등의 모든 인증메커니즘 이용기록
/etc/passwd와 같은 데이터베이스의 수정사항
시스템으로 파일을 가져오거나 시스템에서 파일을 가져가려는 행위
사용자 ID, 주체와 객체 레빌 및 기타속성을 기반으로 이벤트를 포함하거나 배제
Audit System의 사용은 수많은 보안관련 자격에 요건이 된다. Audit은 다음과 같은 자격 혹은 규정들의 요건 이상을 만족하기 위해 디자인 되었다.
Controlled Access Protection Profile (CAPP)
Labeled Security Protection Profile (LSPP)
Rule Set Base Access Control (RSBAC)
National Industrial Security Program Operating Manual (NISPOM)
Federal Information Security Management Act (FISMA)
Payment Card Industry — Data Security Standard (PCI-DSS)
Security Technical Implementation Guides (STIG)
또한 다음 내용이 해당한다.
Evaluated by National Information Assurance Partnership (NIAP) and Best Security Industries (BSI).
Certified to LSPP/CAPP/RSBAC/EAL4+ on Red Hat Enterprise Linux 5.
Certified to Operating System Protection Profile / Evaluation Assurance Level 4+ (OSPP/EAL4+) on Red Hat Enterprise Linux 6.
용례
파일 액세스 감시
Audit은 파일이나 디렉토리가 액세스, 수정, 실행되거나 또는 파일의 속성이 변경되었는지 추적 할 수 있다. 예를들어 이것을 통해 중요 파일에 대한 액세스를 감지하고 이러한 파일 중 하나가 손상되는 경우에 Audit 추적을 할 수 있다.
시스템 호출 모니터링
Audit는 특정 시스템 콜을 사용할 때마다 로그를 기록할 수 있다. 예를들어 이를통해 settimeofday, clock_adjtime 혹은 기타 시간 관련 시스템 콜을 모니터링하여 시스템 시간 변경을 추적하는데 응용될 수있다.
사용자가 실행한 명령 기록
Audit은 파일이 실행되었는지 여부를 추적 할 수 있기 때문에, 특정 명령의 모든 실행을 기록하도록 규칙을 정의할 수 있다. 예를 들어, bin 디렉토리의 모든 실행파일에 대해 감사를 정의함으로써 각 사용자별로 실행한 명령을 로그로 추적할 수 있다.
보안 이벤트 기록
pam_faillock 인증 모듈은 실패한 로그인 시도를 기록 할 수 있다. Audit 또한 실패한 로그인 시도를 기록하도록 설정될 수 있음은 물론 로그인을 시도한 사용자에 대한 추가 정보도 제공 할 수 있습니다.
이벤트 검색
Audit은 ausearch 유틸리티를 통해 로그 조건들을 필터링하고 여러 조건들에 기초한 완전한 감사추적을 제공할 수 있다.
요약 보고서
aureport 유틸리티는 이벤트 기록을 토대로 한 일일 보고서 중 생성하는데 사용된다. 시스템 관리자는 이 보고서를 분석하여 의심스러운 활동을 더 깊이 조사 할 수 있다.
네트워크 액세스 모니터링
시스템 관리자는 네트워크 액세스를 모니터링 할 수 있도록 iptables 및 ebtables 유틸리티는 Audit 이벤트를 트리거하도록 구성될 수 있다.
<Audit System 아키텍처>
감사 시스템은 크게 두 가지 부분, 사용자 공간 애플리케이션과 유틸리티 부분, 커널 측 시스템 호출 처리 부분으로 구분된다. 커널 컴포넌트는 사용자 공간 프로그램에서 시스템 호출을 수신하고 그것들을 user, task, exit로 이뤄진 3 개의 필터 중 하나를 통해 필터링한다.
시스템 호출이 필터를 통과 한 후에는 exclude 필터로 보내진 후, Audit 규칙에 기초해 추가적인 프로세스를 위해 Audit 데몬으로 전달된다. 그림 1.1 "Audit 시스템 아키텍처"는 이 과정을 보여준다.
그림 1.1. Audit 시스템 아키텍처 ( 출처 : 레드햇 도큐먼트 )
사용자 공간 Audit 데몬은 커널에서 정보를 수집하고 로그 파일에 해당 항목을 생성한다. 기타 Audit 사용자 공간 유틸리티는 Audit 데몬, 커널 Audit 구성 요소 또는 감사 로그 파일과 상호 작용한다 :
audisp : Audit 디스패처 데몬은 Audit 데몬과 상호 작용하고 추가 처리를 위해 다른 응용 프로그램에 이벤트를 전송한다. 이 데몬의 목적은 Audit 이벤트와 실시간 분석 프로그램이 상호 작용할 수 있도록 플러그 장치를 제공하는 것이다.
auditctl : Audit 제어 유틸리티는 이벤트 발생 프로세스의 수많은 설정과 파라미터들을 컨트롤하기 위해 커널의 Audit 구성요소와 상호작용한다.
나머지 Audit 유틸리티는 Audit 로그파일 내용을 이용해 유저의 요구에 따른 출력을 생성한다. 예를 들어, aureport 유틸리티는 기록 된 모든 이벤트의 보고서를 생성한다.
<Audit 패키지 설치>
Audit 시스템 사용을 위해, Audit 패키지(audit, audit-libs)가 필요하며 RHEL계열의 경우 디폴트로 설치되어 있다.
만약 설치가 필요할 경우 다음 명령을 실행한다.
~]# yum install audit
<Audit 설정>
Audit 데몬은 /etc/audit/auditd.conf 파일로 설정 가능하다. 이 파일은 Audit 데몬의 행동을 설정하는 파라미터들로 이루어져 있다. 비어있는 줄이나 해쉬(#) 뒤의 텍스트는 무시된다. 전체 설정 파라미터와 설명은 audit.conf(5) 매뉴얼 페이지에 서술되어 있다.
-CAPP 환경 하에서의 auditd 설정
auditd의 디폴트 설정은 대부분의 환경에 적합하다. 하지만 CAPP 기준에 맞추어야 하는 환경이라면, Audit 데몬을 다음과 같이 설정해야 한다.
> Audit 로그가 저장경로(보통 /var/log/audit/)는 다른 파티션에 있어야 한다. 이것은 다른 프로세스가 이 공간을 점유하는 것을 예방해 Audit 데몬이 남은 공간을 정확하게 파악하게 해 준다.
> 개별 Audit 로그 파일의 최대크기를 정의하는 max_log_file 파라미터는 Audit로그파일을 저장하는 파티션의 가용한 모든 공간을 사용하도록 설정해야 한다.
> max_log_file에서 정의된 제한에 도달했을 경우에 취할 행동이 정의된 max_log_file_action 파라미터는 keep_logs로 설정하여 덮어쓰기를 방지해야 한다.
> 디스크의 남은 용량을 명시하는 space_left 파라미터는, space_left_action 파라미터가 미리 설정된 action을 취하기 전, 시스템 관리자가 충분한 시간을 갖고 대응 및 디스크 비우기를 할 수 있도록 설정되어야 한다. space_left 값은 Audit 로그 파일이 생성되는 주기에 따라 알맞게 설정한다.
> 적시에 문제상황이 관리자에게 전파될 수 있도록 speace_left_action 파라미터에 email이나 exec 을 통한 알림설정을 권한다.
> admin_space_left_action 파라미터에 정의된 내용이 실행되기 위한 디스크 잔여공간의 절대 최소값을 정의한 admin_space_left 파라미터는 관리자가 로그에 대응했을 경우에 남게 되는 로그가 남을 수 있도록 충분한 공간이 확보되게 설정해야 한다.
> admin_space_left파라미터는 관리자가 시스템을 single-user-mode로 진입하여 디스크를 비우는 등의 동작을 보장할 수 있도록 single로 설정되어야 한다.
> Audit로그 파일을 보관하고 있는 파티션의 잔여 용량이 없을때의 행동을 정의한 disk_full_action 파라미터는 halt나 single로 설정되어야 한다. 이것은 Audit이 더 이상 로그를 기록할 수 없을 때 시스템이 셧다운되거나 single-user-mode가 되도록 한다.
> 로그 파일이 보관된 파티션의 에러를 발견했을때의 행동을 정의한 disk_error_action 파라미터는 하드웨어 오작동에 관련한 로컬 보안 정책에 기초해 syslog, single 혹은 halt로 설정되어야 한다.
> flush 설정 파라미터는 sync나 data로 설정되어야 한다. 이 파라미터는 모든 Audit 로그가 디스크의 로그파일들과 온전하게 동기화되도록 보장한다.
기타 설정 옵션은 해당 로컬 보안 정책에 맞게 세팅한다.
<Audit 서비스 실행>
auditd가 적절하게 설정되면 Audit 정보를 수집하고 로그로 남길 수 있도록 서비스를 실행한다. auditd를 실행하기 위해 root 권한으로 다음 명령을 실행한다.
~]# service auditd start
*auditd를 다룰때에는 service 커맨드를 사용해야한다. auditd를 다룸에 있어 systemctl커맨드를 사용할 수 있는 경우는 enable과 status 뿐이다.
다음 명령으로 부팅시에 자동실행되도록 할 수 있다.
~]# chkconfig auditd on
혹은 systemd를 사용할 수 있다.
~]# systemctl enable auditd
service auditd <action> 커맨드를 이용해 많은 것을 할 수 있다. 몇 가지 예를 들면 다음과 같다.
stop : auditd 정지
restart : auditd 재시작
reload 혹은 force-reload : auditd의 설정을 /etc/audit/auditd.conf 에서 다시 불러온다/
rotate : /var/log/audit/ 디렉터리의 로그 파일을 로테이트 한다.
resume : Audit 로깅을 속행하는데, 이는 로그가 기록되는 파티션 공간이 부족해 서스펜드 되어 있던 Audit 로깅을 다시 진행시키는 등의 목적으로 사용될 수 있다.
condrestart 혹은 try-restart : 이미 실행중인 auditd의 재시작을 위한 명령어.
status : auditd의 실행상황을 보여준다.
<Audit 규칙 설정>
Audit 시스템은 로그 파일로 캡쳐될 요소를 정의한 일련의 규칙에 따라 작동한다. 다음은 세 가지 Audit 규칙 타입이다.
> 제어 규칙 : Audit 시스템의 행동과 일부 설정을 수정한다.
> 파일시스템 규칙 : 파일 감시자라고도 알려져 있으며, 특정 파일이나 디렉터리로의 접근을 감사한다.
> 시스템 호출 규칙 : 특정 프로그램이 발생시키는 시스템 호출을 기록한다.
Audit 규칙은 커맨드라인에서 auditctl 유틸리티를 통해 제어하거나(이는 재부팅시 초기화된다), /etc/audit/audit.rules 파일을 수정함으로써 적용가능하다.
-auditctl 유틸리티를 이용한 Audit 규칙 정의
Audit 서비스와 Audit 로그 파일과 관련된 모든 상호작용은 root 권한을 필요로 한다.
auditctl 커맨드를 이용해 audit 시스템의 기본적인 기능을 제어할 수 있고 어떠한 Audit 이벤트를 로깅할 지에 대한 규칙을 정의할 수 있다.
> 제어 규칙 정의하기
다음은 Audit 시스템의 작동을 수정하는 몇 가지 제어규칙들이다
-b : 커널에 존재하는 Audit 버퍼의 최대량을 정한다.
ex)
~]# auditctl -b 8192
-f : 치명적 에러를 탐지했을 때의 동작을 설정한다.
ex)
~]# auditctl -f 2
위 설정에 따르면 치명적 에러 발생 시 커널패닉을 트리거 한다.
-e : Audit 시스템을 가동/중지하거나 설정을 잠근다.
ex)
~]# auditctl -e 2
위 명령어로 Audit 설정을 잠근다.
-r : 초당 발생하는 메시지의 숫자를 설정한다.
ex)
~]# auditctl -r 0
위 명령어로 메시지 생성 제한을 풀 수 있다.
-s : Audit 시스템의 상태를 보여준다.
ex)
~]# auditctl -s
AUDIT_STATUS: enabled=1 flag=2 pid=0 rate_limit=0 backlog_limit=8192 lost=259 backlog=0
-l : 현재 로드된 모든 Audit 규칙을 보여준다.
ex)
~]# auditctl -l
LIST_RULES: exit, always watch=/etc/localtime perm=wa key=time-change
LIST_RULES: exit, always watch=/etc/group perm=wa key=identity
LIST_RULES: exit, always watch=/etc/passwd perm=wa key=identity
LIST_RULES: exit, always watch=/etc/gshadow perm=wa key=identity
-D : 현재 로드된 모든 Audit 규칙을 삭제한다.
ex)
~]# auditctl -D
No rules
> 파일시스템 규칙 정의하기
파일 시스템 규칙을 정의하기 위해, 다음 구문을 사용한다.
auditctl -w <파일경로> -p <퍼미션> -k <키 이름>
<파일경로>는 Audit이 추적할 파일이나 디렉터리의 경로이다.
<퍼미션>은 로깅된 퍼미션이다. r,w,x,a로 구성되며 각각 읽기, 쓰기, 실행, 수정에 해당한다.
<키 이름>에 사용자가 로그를 볼 때 쉽게 구분할 수 있도록 규칙에 임의의 이름을 넣을 수 있다.
examples)
/etc/passwd 파일에 읽기 엑세스나 수정을 시도할 때 로그를 기록하게 정의할 수 있다.
~]# aditctl -w /etc/passwd -p wa -k passwd_changes
-k 옵션 뒤에 따라오는 값은 임의로 이름지어 붙일 수 있다.
/etc/selinux/ 디렉터리의 모든 파일에 대해 읽기 엑세스나 수정 시도를 기록하려면 다음과 같이 정의한다.
~]# aditctl -w /etc/selinux -p wa -k selinux_changes
리눅스 커널에 모듈을 삽입하는데 쓰이는 /sbin/insmod 커맨드 실행을 추적하기 위해서 다음과 같이 정의한다.
~]# aditctl -w /sbin/insmod -p x -k module_insertion
> 시스템호출 규칙 정의하기
시스템호출 규칙을 정의하기 위해서는 다음 구문을 사용한다.
auditctl -a <동작,필터> -S <시스템호출> -F <field=value> -k <키 이름>
<동작, 필터>는 어떤 이벤트가 로그로 기록되는 시점을 지정한다. ‘동작’은 always 나 never가 될 수 있다. ‘필터’는 어떤 커널 rule-matching이 이벤트에 적용되는지 특정한다. rule-matching filter는 task, exit, user 또는 exclude가 될 수 있다. 자세한 내용은 전술한 [Audit System 아키텍쳐] 부분을 참고한다.
<시스템호출>은 이름으로 시스템호출을 지정한다. 시스템호출의 전체 리스트는 /usr/include/asm/unistd_64.h 파일에서 찾을 수 있다. 몇 몇 시스템호출을 하나의 그룹으로 묶을 수 있으며 각각 -s 옵션 뒤에 입력해야 한다.
<field=vaule>는 시스템아키텍처, 그룹ID, 프로세스ID 등을 이용해 더욱 세세한 규칙을 정할 수 있게 한다. 사용가능한 전체 field type과 value은 auditctl(8) 매뉴얼 페이지에서 확인할 수 있다.
<키 이름>을 입력함으로써 규칙 구분을 위한 이름을 임의로 지을 수 있다.
examples)
64비트 아키텍처 머신에서, 프로그램에 의해 adjtimex 또는 settimeofday 시스템 호출이 이뤄질 때마다 Audit이 로그를 기록하도록 하려면 다음과 같이 규칙을 정의한다.
~]# auditctl -a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change
유저 ID 번호 500 이상(그리고 UID를 부여받지 않은 사람을 제외하기 위해 -F auid!=4294967295 옵션을 이용한다.)을 가진 사용자가 파일 삭제 혹은 파일이름 수정을 하는 것을 Audit에서 기록하려면 다음을 입력한다.
~]# auditctl -a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295 -k delete
시스템호출 규칙 구문을 이용해 파일시스템 규칙을 정의하는 것도 가능하다. 파일시스템 규칙에서 -w /etc/shadow -p wa 와 같이 정의되는 구문을 시스템호출 규칙 구문으로 다음과 같이 표현한다.
~]# auditctl -a always,exit -F path=/etc/shadow -F perm=wa
-영구적인 Audit 규칙 정의와 /etc/audit/audit.rules 파일 조작
Audit 규칙을 재부팅 후에도 지속되게 하려면 /etc/audit/audit.rules 파일에 해당 내용을 포함시켜야 한다. 이 파일은 규칙을 정의하는데 auditctl 명령어와 동일한 구문을 사용하며 빈 줄이나 해쉬(#)처리된 부분은 무시된다.
auditctl 명령에 -R 옵션을 사용하면, 특정한 파일에서 규칙을 읽어내는 것도 가능하다.
~]# auditctl -R /usr/share/doc/audit-<버전>/stig.rules
> 제어 규칙 정의하기
파일은 Audit 시스템의 행동을 수정하는 다음과 같은 몇가지 제어 규칙들을 포함할 수 있다.: -b, -D, -e, -f, -r
자세한 내용은 전술한 [제어규칙 정의하기]부분을 참조한다.
examples) audit.rules에서의 제어규칙
# Delete all previous rules
-D
#Set buffer size
-b 8192
# Make the configuration immutable -- reboot is required to change audit rules
-e 2
# Panic when a failure occurs
-f 2
# Generate at most 100 audit messages per second
-r 100
> 파일시스템 정의하기와 시스템호출 규칙
파일시스템과 시스템호출 규칙은 auditctl 구문을 이용해서 정의할 수 있다. 전술한 [auditctl 유틸리티를 이용한 Audit 규칙 정의]에 제시된 예는 다음과 같이 파일에 적용한다.
examples) audit.rules에서의 파일시스템과 시스템호출 규칙
-w /etc/passwd -p wa -k passwd_changes
-w /etc/selinux/ -p wa -k selinux_changes
-w /sbin/insmod -p x -k module_insertion
-a always,exit -F arch=b64 -S adjtimex -S settimeofday -k time_change
-a always,exit -S unlink -S unlinkat -S rename -S renameat -F auid>=500 -F auid!=4294967295 -k delete
> 사전정의된 규칙 파일
/usr/share/doc/audit-<버전>/ 디렉토리 안에는 여러 보안인증표준에 맞춰 audit 패키지에서 준비한 사전정의된 규칙 파일들이 포함되어 있다.
nispom.rules : National Industrial Security Program Operating Manual의 8장에서 상술된 조건을 충족할 수 있도록 구성된 Audit 규칙 설정.
stig.rules : Security Technical Implementation Guides (STIG) 에서 요구하는 조건을 충족할 수 있도록 구성된 Audit 규칙 설정.
이 설정 파일들을 이용하기 위해서는 기존 사용하던 /etc/audit/audit/rules 파일을 백업해둔 뒤 사전정의된 규칙 파일을 /etc/audit/rules로 복사한다.
~]# cp /etc/audit/audit.rules /etc/audit/audit.rules_backup
~]# cp /usr/share/doc/audit-version/stig.rules /etc/audit/audit.rules
<Audit 로그 파일 이해>
Audit 시스템은 디폴트로 로그를 /var/log/audit/audit.log 파일에 저장한다. 로그 로테이션이 활성화 되어 있으면 그 폴더 안에 넘버링을 해가며 계속 로그를 저장한다.
다음 Audit 규칙은 /etc/ssh/sshd_config 파일로의 모든 읽기 혹은 수정 시도를 기록한다.
-w /etc/ssh/sshd_config -p warx -k sshd_config
auditd 데몬이 실행중일 때 다음 명령을 실행하면 Audit 로그 파일에 이벤트가 기록된다.
~]# cat /etc/ssh/sshd_config
이 이벤트는 audit.log 파일 안에 다음과 같이 기록된다.
type=SYSCALL msg=audit(1364481363.243:24287): arch=c000003e syscall=2 success=no exit=-13 a0=7fffd19c5592 a1=0 a2=7fffd19c4b50 a3=a items=1 ppid=2686 pid=3538 auid=500 uid=500 gid=500 euid=500 suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=pts0 ses=1 comm="cat" exe="/bin/cat" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="sshd_config"
type=CWD msg=audit(1364481363.243:24287): cwd="/home/shadowman"
type=PATH msg=audit(1364481363.243:24287): item=0 name="/etc/ssh/sshd_config" inode=409248 dev=fd:00 mode=0100600 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:etc_t:s0
위의 이벤트는 각각 type=(키워드)로 시작하는 연속된 세 개의 레코드로 구성되어 있으며 이들은 같은 타임스탬프와 시리얼번호를 공유하고 있다. 각 레코드는 공백이나 콤마로 구분된 몇개의 name=value 쌍으로 구성되어 있다.
-첫번째 레코드
type=SYSCALL
type 필드는 레코드의 타입을 정의한다. 이번 예에서는 커널에의 시스템호출에 의해 이 로그가 기록된 것을 알 수 있다.
msg=audit(1364481363.243:24287):
msg 필드는 audit(타임스탬프:유니크ID) 형식을 취하고 있으며 같은 Audit 이벤트에 의해 생성된 레코드들의 경우 다수의 레코드가 같은 타임스탬프와 ID를 공유할 수 있다. 커널이나 사용자 공간 애플리케이션에 의해 여러가지 이벤트를 특정하는 name=value 쌍이 존재한다.
arch=c000003e
arch 필드는 시스템의 CPU 아키텍처 정보를 16진수로 보여준다. Audit 기록을 찾을 때 사용하는 ausearch 명령어에 -i 혹은 --interpret 옵션을 사용하면 이해할 수 있는 형식으로 변환해서 출력한다. 이번 예에서는 x86_64를 의미한다.
syscall=2
syscall 필드는 커널로 보내진 시스템호출 타입을 기록한다. 여기서 주어진 값 2는 /usr/include/asm/unistd_64.h 파일에서 의미를 찾아볼 수 있는데, open 시스템 호출을 의미한다. ausyscall --dump 명령어를 이용하면 모든 시스템호출 값의 리스트를 출력해 볼 수 있다. 추가 정보는 ausyscall(8) 매뉴얼 페이지를 참조한다.
success=no
success 필드를 통해 이벤트에 기록된 시스템 호출의 성공 여부를 알 수 있다. 이 경우에는 성공하지 못했다.
exit=-13
exit 필드는 시스템호출로부터 반환된 엑시트 코드 값을 보여준다. 이 값은 시스템 호출에 따라 다르며 ausearch --interpret --exit -13 명령어를 사용하면 이해할 수 있는 값으로 변환하여 보여준다.
a0=7fffd19c5592 a1=0 a2=7fffd19c4b50 a3=a
a0부터 a3까지는 시스템호출의 첫 네 개의 argument를 16진수로 나타낸 값이다. 이는 시스템호출에 따라 차이가 있으며 ausearch 유틸리티를 통해 이해할 수 있는 값으로 변환해 출력 가능하다.
items=1
items 필드는 이 이벤트의 path 레코드의 숫자를 나타낸다.
ppid=2686
ppid는 부모 프로세스 ID이며 이 경우에는 bash 프로세스이다.
pid=3538
pid는 프로세스ID이며 이 경우 cat 프로세스이다.
auid=500
Audit User ID로 이 ID는 로그인과 물려받는 모든 프로세스에 할당되며 심지어 ID가 바뀌어도 유지된다. 예를들어 su - john 커맨드를 통해 유저를 바꾸어도 지속된다.
uid=500
사용자 아이디. ausearch -i --uid <UID> 명령을 통해 이름으로 볼 수 있다.
ses=1
이벤트가 발생한 세션 ID를 나타낸다.
comm="cat"
Audit 이벤트를 발생시킨 커맨드를 알 수 있다. 이 경우 cat이다.
exe="/bin/cat"
실행 파일의 위치를 보여준다
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
SELinux 컨텍스트이다.
key="sshd_config"
최초 룰셋 설정 시에 사용자가 임의로 정한 키가 나온다.
-두번째 레코드
type=CWD
Current Working Directory를 의미하며, 따라오는 정보가 그에 관련한 내용임을 알려주고 있다. 이 정보는 상대적 경로정보와 합쳐지면 완전한 경로를 재구성하는 것이 가능하다
msg=audit(1364481363.243:24287):
msg 필드는 첫번째 레코드와 같은 타임스탬프와 유니크ID를 갖고 있다.
cwd="/home/shadowman"
cwd 필드는 시스템호출이 실행된 경로 정보를 보여준다.
-세번째 레코드
type=PATH
type필드 값이 PATH이다. Audit 이벤트는 시스템호출에 argument로써 커널로 전달된 모든 경로를 기록한다. 이번 경우에는 하나의 경로(/etc/ssh/sshd_config)만이 argument로 전달되었다.
msg=audit(1364481363.243:24287):
msg 필드는 첫번째, 두번째 레코드와 같은 타임스탬프와 유니크ID를 갖고 있다.
item=0
item 필드는 SYSCALL 타입의 레코드에 참조된 time 중 현재 레코드가 몇 번째인지 알려준다. 이 번호는 0부터 시작하며 이번 예의 경우, 이 레코드가 첫 번째 item임을 가리킨다.
name="/etc/ssh/sshd_config"
시스템호출에 argument로 넘겨진 파일이나 디렉터리의 완전한 경로를 나타낸다. 이 경우에는 /etc/ssh/sshd_config가 된다.
inode=409248
이 필드는 기록된 이벤트와 관련있는 파일이나 디렉터리의 아이노드 정보를 포함한다. 다음 명령어를 통해 아이노드 번호 409248과 관련한 정보를 조회할 수 있다.
~]# find / -inum 409248 -print
/etc/ssh/sshd_config
dev=fd:00
해당 이벤트가 기록된 파일이나 디렉터리를 포함된 디바이스의 주, 부 ID를 나타낸다. 이 경우에는 /dev/fd/00 이 해당된다. (/dev/fd에 관한 추가설명)
mode=0100600
파일이나 디렉터리의 퍼미션을 나타내며 이경우 /etc/ssh/sshd_config 파일의 퍼미션인 -r--------에 해당한다.
rdev=00:00
rdev는 특별한 경우의 파일을 위한 저장 디바이스의 인식자를 나타낸다. 이 경우 해당하지 않는다.
obj=system_u:object_r:etc_t:s0
SELinux의 컨텍스트를 보여준다.
-추가 레코드 예시
다음은 auditd 데몬의 성공적인 실행을 나타내는 Audit 로그이다. ver 필드는 실행된 Audit 데몬의 버전 정보를 보여준다.
type=DAEMON_START msg=audit(1363713609.192:5426): auditd start, ver=2.2 format=raw kernel=2.6.32-358.2.1.el6.x86_64 auid=500 pid=4979 subj=unconfined_u:system_r:auditd_t:s0 res=success
다음 레코드를 통해 유저ID 500을 가진 사용자가 root 유저로의 로그인을 시도했고, 실패 했음을 알 수 있다.
type=USER_AUTH msg=audit(1364475353.159:24270): user pid=3280 uid=500 auid=500 ses=1 subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 msg='op=PAM:authentication acct="root" exe="/bin/su" hostname=? addr=? terminal=pts/0 res=failed'
<Audit 로그 파일 검색>
ausearch 유틸리티는 특정 Audit 로그 검색을 할 수 있도록 한다. ausearch의 기본값은 /var/log/audit/audit.log 파일을 검색하도록 되어 있으나 ausearch <옵션> -if <파일경로 및 이름> 명령어를 사용해 특정할 수 있다. ausearch 커맨드 입력시에 포함된 다수의 옵션은 AND로 인식하며 필드 타입이 다수 입력될 시 타입간에는 OR로 인식된다.
-ausearch를 이용한 Audit 로그검색 예시
기본 Audit로그 경로(/var/log/audit/audit.log)에서 실패한 로그인 시도를 검색하기 위해서 다음 명령어를 이용한다.
~]# ausearch --message USER_LOGIN --success no --interpret
모든 계정, 그룹, 역할변경 내역을 검색하려면 다음과 같이 입력한다.
~]# ausearch -m ADD_USER -m DEL_USER -m ADD_GROUP -m USER_CHAUTHTOK -m DEL_GROUP -m CHGRP_ID -m ROLE_ASSIGN -m ROLE_REMOVE -i
특정 사용자에 대해 Audit이 기록한 모든 로그를 보기 위해서, 사용자의 로그인ID(auid)를 이용해서 검색한다.
~]# ausearch -ua 1000 -i
어제부터 현재까지의 모든 실패한 시스템 호출을 검색할 수도 있다.
~]# ausearch --start yesterday --end now -m SYSCALL -sv no -i
<Audit 보고서 작성>
aureport 유틸리티는 Audit 로그 파일에 기록된 자료를 기초로 정제된 보고서를 보여준다. 보고서 작성을 위해 기본값으로 /var/log/audit/audit.log 파일의 내용을 참조하며 aureport <옵션> -if <파일 경로 및 이름> 명령으로 특정가능하다.
-aureport를 이용한 Audit 보고서 작성 예시
예를들어 특정 3일간의 Audit로그 보고서를 생성하기 위해서 다음 명령어를 사용할 수 있다.
~]# aureport --start 11/08/2016 00:00:00 --end 11/11/2016 00:00:00
모든 실행파일 이벤트에 대한 보고서를 생성하는 명령어는 다음과 같다.
~]# aureport -x
위 보고서의 요약본을 출력하려면 --summary 옵션을 추가한다.
~]# aureport -x --summary
모든 사용자로부터 발생한 실패 이벤트 로그들의 요약보고서를 생성하기 위해 다음 명령어를 사용한다.
~]# aureport -u --failed --summary -i
각 사용자의 모든 실패한 로그인 시도에 대해 요약보고서를 생성한다.
~]# aureport --login --summary -i
ausearch 유틸리티도 질의해 얻은 결과에 파이프라인을 이용해 aureport로 프로세싱하는 것도 가능하다. 예를들어 ID 1000인 사용자의 모든 파일 엑세스에 대한 보고서는 다음과 같이 생성한다.
~]# ausearch --start today --loginuid 1000 --raw | aureport -f --summary
보고서에 이벤트 발생 시각을 포함하여면 -t 옵션을 사용한다.
~]# aureport -t
<부가 자료>
-리눅스 Audit 문서화 프로젝트:
-로컬 시스템에서 참조 가능한 디렉터리:
/usr/share/doc/audit/
-관련 매뉴얼
References:
(1) Steve Grubb. Investigating Kernel Return Codes with the Linux Audit System. HITB magazine. Volume 1 Issue 5 (Feb 2011): 4-13
(2) Red Hat, Inc. Product Documentation for Red Hat Enterprise Linux. https://access.redhat.com/documentation/en/red-hat-enterprise-linux/?version=7/ (Accessed 2016-11-04).
(3) Paul Moore. SPEC Writing Good Events. https://github.com/linux-audit/audit-documentation/wiki/SPEC-Writing-Good-Events (Accessed 2016-11-04).
(4) civilfritz. 2016.Tracking user actions with the Linux Audit Subsystem. http://civilfritz.net/ Tech blog. 25 March. http://civilfritz.net/journal/tracking-user-actions-with-the-linux-audit-subsystem/ (Accessed 2016-11-04).
(5) Steve Grubb. Red Hat Summit 2011, Native Host Intrusion Detection with RHEL6 and the Audit Subsystem. https://people.redhat.com/sgrubb/audit/audit_ids_2011.pdf. 2011
