auditd 튜닝 : 고성능 Linux 감사를 위한 최적화

저희 Qubit Security는 성공적인 해킹 방어를 위해 syslog 외에도 다양한 수단들을 연구·활용하고 있습니다.

Audit 로그는 리눅스 커널과 integrated 된 감사용 프레임워크로, 커널단에서 이루어지는 시스템 호출을 캡쳐해 syslog가 놓칠 수 있는 틈을 메워줍니다. Audit 로그는 ruleset 기반의 유연한 필터링을 제공하는데 이는 전문가에게 막대한 자유를 선사함과 동시에, 비전문가에게는 시작할 엄두조차 내기 어려운 높은 장벽을 만들어버립니다.

프로덕션 환경에서는 필요 최소한의 로그를 수집함으로써 성능과 보안의 균형을 잡을 수 있도록 적절하게 ruleset을 스크립팅 하는 것이 매우 중요한데, 이를 위해 참고할 만한 글이 있어 번역, 공유합니다.

로깅 시스템의 최적화는 저희의 최우선 관심사항 중 하나이며 관련된 문의나 제안에 대해 항상 환영합니다.

고성능 Linux 감사

퍼포먼스를 고려한 Linux auditd 튜닝

Linux Audit 프레임 워크는 시스템 이벤트를 감사하는 강력한 도구입니다. 실행 파일의 동작부터 시스템 호출까지 모든 것을 기록할 수 있습니다. 하지만 모든 것을 기록한다면 필연적으로 성능에 부담을 주게 됩니다. 이번 글에서는 audit rule을 최적화하고 Linux 시스템을 원활하게 운영하는 방법을 살펴 봅니다.

auditd 성능을 적절하게 조정함으로써 Linux 커널에 대한 스트레스와 영향을 줄일 수 있습니다. 시스템 설정을 변경하기에 앞서 성능을 미리 측정해두기를 권장합니다. 이것을 기준으로, 튜닝 작업의 전/후를 비교할 수 있습니다.

전략 : 올바른 Rule 순서 배치

많은 소프트웨어 패키지는 “순차적 규칙 처리”를 사용합니다. 이는 Linux Audit 데몬에도 적용되어, 일치하는 하나의 규칙이 나올때 까지 규칙이 차례로 처리됩니다.

따라서 튜닝 할 가장 큰 주요한 영역 중 하나는 규칙의 순서입니다. 가장 빈번하게 발생하는 이벤트는 가장 위쪽에, 그리고 예외적인 – 빈도가 낮은 – 이벤트는 가장 아래에 위치해야 합니다.

Linux Audit rule이 알파벳 순으로 배열되었다면 이는 틀림없이 성능 최적화가 되지 않은 배열일 것입니다. 다음 순서로 넘어가봅시다.

전략 : 불필요한 이벤트 제외

이벤트 로깅에 있어 가장 핵심적인 과제는, 중요한 로그는 모두 기록하는 동시에 필요하지 않은 로그는 적절히 제외하는 것입니다.

일부 관리자는 “모든것을 기록하는” 룰을 적용합니다. 때때로 이러한 접근도 의미가 있기는 하지만, 전혀 효율적이라 할 수 없습니다. 이러한 종류의 로깅은 auditd의 처리 시간에 영향을 주는 동시에 커널 성능에도 영향을 줍니다.

효율적인 로깅을 위해서 먼저 어떤 이벤트가 빈도높게 등장하는지 확인해야 합니다.

실행 파일로 정렬

aureport -ts today -i -x –summary

시스템호출(syscall)로 정렬

aureport -ts today -i -s –summary

이를 통해 어떤 실행파일과 시스템호출이 audit 로그에서 대부분을 차지하고 있는지 알 수 있습니다. -ts today 옵션을 명령어에 추가하여 최근 이벤트만 조회할 수 있습니다.

aureport의 출력을 기초로 일부 이벤트를 비활성화하면 불필요한 로그의 양을 줄이는 데 큰 도움이됩니다. 물론 이벤트, 파일 및 기타 유형에 대해서도 동일하게 적용 가능합니다. 자세한 내용은 aureport의 매뉴얼 페이지를 참조하세요.

aureport가 출력한 [오늘 발생한 이벤트]

이벤트 무시하기

이제 우리는 어떤 유형의 파일, 이벤트 또는 다른 메시지가 있는지 알고 있기에 필요없는 로그를 무시할 수 있습니다. 이를 위해 적절한 rule을 작성해야합니다.

syscall을 사용할 때에는 exit와 함께 사용하며, 그 외의 경우에는 exclude를 사용합니다.

메시지 유형별 필터링

예를 들어 모든 “CWD”(현재 작업 디렉토리) 유형을 비활성화하기위해 다음과 같은 rule을 사용합니다.

-a always,exclude -F msgtype=CWD

위에서부터 차례로 규칙이 적용되기 때문에, 예외가 윗쪽에 먼저 배치되어야 합니다. 위의 예는 메시지 유형을 기반으로하는 필터이므로 exclude를 사용합니다.

여러 규칙을 적용한 필터링

다음 예제는 VMware 도구가 기록한 메시지를 필터링하는 것입니다. 이를 위해 다중 -F 매개 변수를 이용해 여러 규칙을 결합합니다. 최대 64 개의 필드가 허용되지만 일반적으로 몇 개의 필드만 사용해도 충분합니다. -F를 사용할 때 각 표현식은 논리적 AND 문으로 적용됩니다. 이는 audit rule 세트의 동작을 트리거하기 위해 모든 필드가 참이어야 함을 의미합니다.

-a exit,never -F arch=b32 -S fork -F success=0 -F path=/usr/lib/vmware-tools -F subj_type=initrc_t -F exit=-2
-a exit,never -F arch=b64 -S fork -F success=0 -F path=/usr/lib/vmware-tools -F subj_type=initrc_t -F exit=-2

주 : 몇가지 예제의 경우 구형 시스템에서 실행시 다른 결과가 나올 수 있습니다. 따라서 항상 작동하는지 확인하기 위해 각 규칙을 테스트 해 두는 것이 좋습니다. 아무 효과가 없는 규칙이 들어가 있는 것은 성능면에서 부정적인 효과만 초래할 뿐입니다.

전략 : 버퍼링 필요량 결정

auditctl에 -s (status) 옵션을 주면 사용하면 상태 (enabled), 관련 플래그, 프로세스 ID 및 로그 관련 통계 (백 로그, 비율, 손실) 등과 같은 통계를 제공합니다.

# auditctl -s
enabled 1
flag 1
pid 430
rate_limit 0
backlog_limit 320
lost 0
backlog 0
enabled -1
flag 0
pid 0
rate_limit 0
backlog_limit 320
lost 0
backlog 0

더 큰 버퍼를 허용하는 것은 메모리 더 많은 메모리 점유를 의미합니다. 모든 이벤트를 기록하는 것은 시스템에 따라 꽤나 영향을 미치는 결과를 낳을 수 있습니다.

최적의 버퍼 크기를 결정하기위해서는 백 로그 값을 모니터링해야 합니다. backlog_limit 옵션을 초과해선 안됩니다 (이 경우 320). 또 다른 유용한 통계는 시스템이 얼마나 많은 이벤트를 처리 할 수 없었는지 알려주는 손실값을 모니터하는 것입니다. 정상적인 시스템에서 이 값은 0에 가까워야 합니다.