로그 집계 분석에서 가장 중요한 데이터 '전처리' 과정
이직을 앞두고 있는 회사의 '전처리(Pre-processing)' 개념
금일 본인이 사는 지역의 사전 투표를 하고 왔다. 이른 아침 여섯 시 이십삼 분경에 동사무소에 들려서 여유 있게 도장 찍고 나왔지만, 사전 투표인데도 불구하고 이미 젊은 사람부터 몇몇 어르신들을 비롯하여 제법 많은 이가 투표를 하고 나오고 있었다. 사전투표의 집계 결과를 통해 경선지의 투표율과 당선 결과를 미리 추측할 수 있다. 그러니까 시답잖은 갤럽 리포트의 여론조사보다 왜곡이 낮은 당선 확률을 사전투표를 통해서도 알 수 있다.
저번 총선 때도 그랬듯이 사전투표의 결과와 당선결과가 어긋나는 경우는 뉴스의 집계 현황에서 정말 보기 드물었다. 그만큼 표본집단의 일부를 통해 미리 선거 결과를 예측하는 확률은 기정 사실화된다. 이런 사전 투표 집계와 같이 데이터 처리에 있어서도 마찬가지로 '전처리(Pre-processing)'라는 사전에 데이터의 불필요한 노이즈(noise)를 제거하는 작업을 통해 인공지능(AI)의 예측모델의 정확성(correctness)과 정밀성(proficiency)을 높일 수 있다. 왜냐하면 이 전처리라는 과정이 충분하지 않고 집계 분석에 이용할 데이터의 종류가 적으면 데이터에서 얻을 수 있는 시사점(유의미한 데이터)이 줄어들기 때문이다.
그러므로 이 전처리는 어떠한 데이터를 기반으로 한 조사에서라도 집계 분석의 '품질'에 영향을 가장 크게 미친다. 이번 섹션에서는 이전의 섹션에서 다룬 윈도 시스템에서 로그를 확인하기 위한 이벤트 뷰어와 필터링 정책을 할 수 있는 로컬 정책 설정과 동일한 기능을 가진 유닉스 및 리눅스 운영체제에서 할 수 있는 방법을 알아보고자 한다.
가상 환경에 리눅스를 설치하거나(WSL, Windows Subsystem for Linux라고 윈도에서 바로 리눅스 환경의 설치가 가능하다), 실무진이라면 유닉스 서버에서 실제로 웹서버나 시스템 서버의 로그를 수집하고 분석하는데 가장 많이 쓰이는 명령어가 tail 일 것이다. 실시간으로 관련 로그를 원하는 위치에 저장하기 위해 보통 아래와 같은 명령어를 커맨드 단에서 실행한다.
$ tail -f /var/log/messages
-
WSL(Windows Subsystem for Linux)로 설치한 Ubuntu에서 실행한 tail 명령. /var/log /lastlog(마지막으로 실패한 로그온 기록)를 감시함이후 어떠한 시스템 이벤트 발생 시 명령어 아래의 깜빡이는 커서에서 자동으로 해당 로그가 뜨는 것을 감시(모니터링)할 수 있는데, 해당 로그의 심각도에 따라 저장되는 위치(일반적으로 /var/log/messages나 /var/log/secure)를 설정하는 것을 syslogd(데몬)이라는 프로세스가 담당한다. 즉 이 syslogd가 리눅스나 유닉스의 로그를 집계해서 어디다 떨굴지를 설정할 수 있는 프로그램이며, 리눅스는 윈도와 달리 시스템 자체에서 로그를 서버 관리자의 콘솔뿐만 아니라 원격으로도 보낼 수 있다.
시스템이 365일 무중단으로 서비스가 가동되는데 '로그의 최대 크기'를 적절히 산정하는 것도 서버 보안담당자의 몫이다. 즉, 시스템 장애 대비 최대 이벤트 로그 크기를 미리 산정해서 해당 로그를 바탕으로 필요한 데이터를 추출 및 분석해야 한다. 그 기준은 각 서버의 특성이나 애플리케이션의 특성에 따라 달라진다. 만약 메인 서버라면 조금이라도 이상한 경우에도 모두 로그를 남겨야 하고, 상대적으로 보안이 덜 중요한 서버라면 상당히 의심되는 경우에만 로그를 남겨야 로그의 적재용량을 적절하게 산정할 수 있다(이상진, 2014).
예를 들어 유닉스 로그 환경 설정과 관련해서 심각한 에러(Alert)인 경우 모든 형태로 로그를 남기려면 어떻게 해야 할까?
vi /etc/syslog.conf
*.emerg *
*.alert *
authpriv.none /var/log/messages
authpriv.* /var/log/secure
syslog 데몬의 설정 파일인 syslog.conf를 편집기를 통해 수정한다. 위에서 편집기 텍스트 수정 모드의 문두에 있는 *는 시스템의 모든 로그를 뜻하며 이어진 .emerg는 Emergency의 약자로 비상사태 즉, 시스템이 패닉에 빠진 상태일 경우 *(모든 형태, 별표(asterisk)로 전부를 뜻하는 메타 문자)로 남겨라는 뜻이다. 모든 형태란 /dev/console(사용자 콘솔)에까지 표시하라는 뜻으로 이 설정에 해당하는 로그 이벤트가 발생하면 아까 전에 tail 명령어로 모니터링하고 있을 때 해당 로그가 뜨는 것을 확인할 수 있다.
다음행의 '*.alert *'가 질문으로 던진 로그 설정에 해당한다. 그리고 한 칸 띄우고 이어지는 authpriv 문구는 로그온 실패 등의 보안 로그의 설정을 할 때의 키워드이다. 첫 번째 행의 authpirv에 이은 .none은 말 그대로 남기지 않는다라는 뜻으로 뒤의 경로(/var/log/messages)에는 보안 로그를 남기지 말라는 뜻이다. 다음 라인의 'authpriv.* /var/log/secure'는 보안 로그에 해당하는 모든 로그 수준(Emergency > Alert > Critical > Error > Warning > Notice > Informational > Debug)에 대해서 해당 경로에 남겨라는 뜻이다.
로그 수준에 해당하는 용어 중 Debug가 가장 약한 수준을 나타내는 데, 개발 과정에서 테스트 과정에 해당하는 디버깅과 같은 의미로 '문제가 있는 것이 아니라, 문제 해결을 돕기 위해 부가적인 정보를 제공하기 위한 경우'를 뜻한다(이상진, 2014).
위의 심각도에 따른 설정에 필터링되어서 남겨지는 로그는 최근 우분투인 경우 /var/log/syslog 에 저장되기도 한다. 부팅에 관련된 로그는 /var/etc/boot.log 에 남긴다. 2016년도 정보보안 산업기사 8회차 실기 문제로 출제된 logrotate를 이용하여 로그 보관을 하기 위한 스크립트 설정을 마지막으로 유닉스 및 리눅스 로그 관리는 이쯤에서 마무리하겠다. 다음 섹션에서는 우분투에서 윈도우 이벤트 로그 관련 자동화 설정을 위한 쉘 스크립트를 코딩해보고, 서두에서 말한 해당 로그 데이터를 전처리하기 위한 로그 스태시(Logstash)라는 ELK(Elastic search-Logstash-Kibana) 오픈 소스의 사용법을 확인해 보겠다. 실제 빅데이터 분석에서 요하는 전처리를 위한 확률과 통계학적 지식은 없어도 된다.
cf.] 리눅스 시스템에서 웹서버의 로그를 logrotate를 이용하여 보관하려고 한다. 다음 설명에 적절한 옵션을 기술하시오.
(A) : 1주일 단위로 로테이트(rotate) 한다.
(B) : 4개의 순환 파일을 사용한다.
(C) : 로그 파일을 압축하여 보관한다.
/etc/logrotate.d# cat httpd
/var/log/httpd/*log {
( A )
( B )
( C )
missingok
notifempty
sharedscripts
postrotate
/bin/kill -HUP 'cat /var/run/httpd/httpd.pid 2> /dev/null' 2> /dev/null
endscript
}
정답) A - weekly (매주)
B - rotate 4 (4개만큼 로그 순환 파일을 사용)
C - compress (로그 파일을 압축해서 보관)
해설
missingok - 로그 파일이 없어도 오류를 발생시키지 않는다.
notifempty - "not if empty"의 의미로 로그 파일이 비어있는 경우 순환하지 않음
sharedscripts - 로그파일이 여러 개 있어도 스크립트를 공유하여 prerotate, postrotate 스크립트를 한 번만 실행
postrotate/endscript - 순환 후 이 사이에 있는 스크립트 파일(kill) 실행
* /bin/kill(프로세스 강제 종료 명령) -HUP ~ 표준 오류 출력(2)을 /dev/null(휴지통)에 함.
실제 logrotate.d 디렉터리 하위에 설정되어 있는 rsyslog 파일의 로그 순환 설정 예.| 참조
1) 이상진. (2014). 정보보안 가이드북. (초판, pp. 80-86). 서울: 프리렉.
2) 정일영 외 2. (2017). 2017 알기 쉬운 정보보안기사 산업기사 실기. (pp. 35). 서울: 탑스팟.
