BLUE STUDY

우리가 시스템을 관리하고 운영하는데 있어 중요한 자료로 보는 것이 바로 로그이다. 로그는 여러 가지 목적으로 이용될 수 있다.

첫째, 로그를 통해서 우리는 모든 유형의 시스템과 어플리케이션의 문제점을 실질적으로 해결할 수 있다. 둘째, 시스템에 발생한 문제점에 대해 조기경고 신호를 제공해 준다. 셋째, 시스템 고장 또는 시스템 침입이 있은 후에 로그는 중요한 forensic 자료를 제공해 준다.

그렇기 때문에 syslog를 사용하여 시스템을 관리한다는 것은 매우 중요한 일이다. 이번에 우리가 다룰 로깅 툴은 syslog 보다 여러 측면에서 향상된 syslog-ng 이다. Syslog의 설정이나 상세설명은 여기에서는 생략하며 Syslog-NG에 초점을 맞추도록 하겠다.


1. Syslog-NG

(1) 개요

오늘날의 유닉스와 같은 시스템은 syslog가 개발될 때보다 훨씬 더 복잡해졌고, syslog의 제한적인 facility와 기본적인 네트워크 포워딩 기능을 넘어섰다.

Syslog-NG(Syslog New Generation)는 보다 향상된 필터링 및 포워딩 기능 외에 메시지 무결성과 암호화 기능을 추가하여 syslog의 유연성을 증가시켰으며, TCP와 UDP 프로토콜을 통한 원격 Logging을 지원한다.

안정성에 있어서도 좋은 평가를 받고 있으며, 게다가 고급 보안 기능들은 아직까지도 업데이트중에 있지만, 원격호스트로부터 받는 메시지를 인증하고 암호화하는 기능은 SSL Wrapper인 Stunnel와 ssh와 같은 TCP 터널링 도구와 함께 사용될 수도 있다.

(2) 설치

사내에 있는 시스템들에 대한 로그를 받아서 확인하려고 할 경우 각 시스템 내에 로그설정을 하여 사용하는 것보다는 따로 로그서버를 두어 사내 시스템의 로그를 특정로그서버로 수집하여 관리하는 편이 좋다.

로그서버의 사양은 특별히 제한 받는 부분은 없고, 일반 서버수준의 사양이면 충분하며, 로그 데이터량을 고려하여 디스크의 용량을 여유있게 확보해 두는 것이 좋다. 또한 초기 OS 설치 시에 로그를 따로 받는 파티션를 생성해 주는 것이 좋다.


그럼, 지금부터 syslog-ng를 설치하는 방법을 보도록 하겠다. 본 syslog-ng 구축 문서는 Redhat 리눅스를 대상으로 했음을 밝혀둔다.

먼저, syslog-ng의 최신 소스코드를 얻어야 하며, 가급적 가장 최신 버전 사용을 권장한다. syslog-ng는 Zorp라는 Proxy Firewall로 유명한 http://www.balabit.hu나 Freshmeat 프로젝트 사이트(http://freshmeat.net/projects/syslog-ng)에서 다운로드 받을 수 있다.

syslog-ng에 추가하여, libol 다시 말해서 syslog-ng가 지원하는 라이브러리를 위한 소스 코드가 필요하다. libol은 syslog-ng의 센서로서 syslog-ng 설치 이전에 미리 설치해야 한다. 일단 다음사이트에서 libol과 syslog-ng를 다운로드 받으면 된다.

* libol : http://www.balabit.com/downloads/syslog-ng/libol/0.3/
* syslog-ng : http://www.balabit.com/downloads/syslog-ng/stable/src/

두 개의 아카이브의 압축을 풀고, 먼저 libol을 컴파일하고 설치한다. 그런 후에 syslog-ng를 컴파일하고 설치한다. 두 패키지 모두 절차는 동일하다.

압축 해제 후 해당 디렉토리로 이동한다.

# ./configure
# make
# make install

이것은 모든 것을 기본 위치에 설치할 것이다. 즉, libol과 syslog-ng는 /usr/local(예컨대, /usr/local/lib, /usr/local/sbin 등)의 하위 디렉토리에 설치된다. 만일 다른 디렉토리에 설치하고 싶다면 [예제 1]에서처럼 -prefix=flag와 함께 설정한다.


Libol과 syslog-ng 둘을 컴파일하고 설치한 후에는, syslog-ng의 운영환경에 몇 가지를 설정할 필요가 있다.

첫째, /usr/local/etc/syslog-ng 디렉토리를 생성한다. 둘째, syslog-ng.conf라는 파일을 생성한다. 이 파일은 syslog-ng 디렉토리 밑에 있는 /contrib 하위에 존재하는 Redhat관련 configuration내용을 복사하여 syslog-ng.conf파일을 생성하면 된다.


그 다음, /etc/init.d 디렉토리에 syslog-ng 시작 스크립트를 생성한다. syslog-ng init 예제 스크립트는 OS별로 syslog-ng 소스 배포판의 contrib 디렉토리에 있다.

초기 스크립트를 /etc/init.d/syslog-ng라는 파일로 복사해서 생성해 준다. 생성해준 파일에 실행권한을 준 후에 vi로 열어서 다음을 편집해 주어야 한다.

INIT_PROG="/path_to/syslog-ng"

/path_to 대신에 /usr/local/sbin/syslog-ng 나 syslog-ng 의 실행 파일의 경로를 적어주면 된다.


(3) Syslog-NG 설정하기

syslog-ng를 설정할 때에는 syslog의 경우보다 포함시켜야 할 것이 더 많다. 하지만 그것은 syslog-ng의 유연성의 한 증거라고 보면 된다. syslog-ng의 설정파일의 작동방식을 이해하면, 직접 설정하는 것은 단순하고, 자신의 목적에 맞게 간단한 설정을 적용하는 것은 훨씬 쉽다.

syslog-ng.conf 파일은 options{}, source{}, destination{}, filter{}, log{} 문으로 구성된다. 각각의 표현문은 추가적인 설정을 포함할 수 있고, 세미콜론으로 경계를 나눌 수 있다.

문법적으로, syslog-ng.conf는 C와 다른 구조적 프로그래밍 언어와 유사하다. 표현문은 세미콜론으로 끝나고, 공백은 무시되고 여러 라인에 걸쳐 길이가 긴 문장을 끊어서 구분함으로써 그렇기 때문에 가독성을 높일 수 있다.

전역옵션, 메시지 소스, 메시지 목적지, 메시지 필터를 정의하기 전에, 그것을 조합하여 로깅 규칙을 만든다. 리눅스의 초기 설정파일인 /contrib/syslog-ng.con.RedHat을 참조하기 바란다.



각 함수나 해당 옵션에 대한 보다 자세한 설명은 아래 링크를 참조하기 바란다.

http://www.balabit.com/products/syslog_ng/reference/book1.html

syslog-ng의 실행은 다음과 같이 하면 된다.


(4) 타 시스템으로부터 로그 받기

로그서버의 설정파일을 변경하여 타 시스템으로부터 로그를 받기 위한 설정은 그리 어렵지 않다. 따라서 누구나 설정내용의 개별적인 사항이 어떤 내용인지를 파악하면 쉽게 설정할 수 있다.

기본적으로 시스로그 설정은 다음과 같은 형식을 갖는다. 위에서 살펴본 기본 configure에서 다음과 같이 특정 host나 방화벽의 로그를 받아볼 수 있는 설정을 추가할 수가 있다.


여기서 주의할 점은 출발지 이름, 필터 이름, 목적지 이름은 공통적으로 대문자를 사용한다는 것이다. 이점에 유의하면서 위 설정사항에 대해서 자세히 살펴보자.

① facility
- facility는 메시지를 보내는 서브시스템의 이름이며 level(priority)은 메시지의 중요성(엄격도)을 나타낸다.

auth, authpriv, cron, daemon, kern, lpr, mail, news, syslog, user, uucp, local0 - local7

② source
- source는 로그를 발생시키는 출발지를 의미하며, 방화벽 시스로그의 경우 시스템 자체에서 발생하는 것이 아니라 외부에서 udp 514 포트로 전송한다.

source S_EX { udp(); };

한편, 외부의 로그서버에서 로그를 전송할 때 프로토콜과 포트를 지정할 수 있다. 예컨대, udp 10514 포트로 로그를 전송하는 경우 다음과 같은 방법으로 로그를 받으면 된다.

source S_EX { udp(port(10514)); };

③ filter
- filter의 기능은 로그를 보내는 시스템을 개별적으로 인식하는데 있다. 이것을 사용하는 의미는 모든 로그가 udp 514 포트로 전송되고 또한 중복이 가능한 facility를 가지고 전송되는 경우가 존재하기 때문이다. filter에서 facility()와 host()를 통해서 업체별로 메시지를 분류할 수 있게 된다.

filter F_EX { facility(local4) and host(192.168.100.1); };

④ destination
- destination은 로그를 저장하는 방식을 결정한다. 이 때 사용하는 것이 file() 옵션이다. file() 옵션에 사용될 값은 절대경로로 명기해야 한다는 점에 유의해야 한다.

destination D_EX { file("/log/EX/log"); };

로그서버에서는 자신이 받은 로그 메시지를 다른 로그서버로 재지정할 수 있다. 로그서버의 이상을 대비한 백업서버를 또 하나 만들어 로그를 재지정하여 사용할 수 있다는 말이다.

이때 udp()라는 옵션을 사용하여 로그서버와 로그를 받을 포트를 지정할 수 있고, 잘 알려지지 않은 포트를 사용하여 로그를 재지정할 수 있다. 업체구별이나 시스템구별을 위해 독립적인 포트를 사용할 수 있는 장점이 있다.

destination D_EX_SVR { udp("192.168.0.2" port(10514)); };

⑤ log
- 이런 설정들을 하나의 규칙으로 만들기 위해서 log를 사용한다. log에는 위에서 설정한 내용들에 대한 규칙 이름만 규정하면 된다. 예컨대, EX의 경우는 다음과 같이 정의할 수 있다.

log { source(S_SYSLOG); filter(F_EX); destination(D_EX); };

Priority는 다음과 같으며, 어떤 상태의 로그를 받을지를 결정할 수 있다. Pirority는 로그를 발생하는 source system에서 그 Level을 정해주어야 한다.

Priority값의 변화로 인해서도 로그량의 차이가 나기 때문에 어떤 Priority값을 설정하여 사용할 것인지도 잘 생각해야 한다. 보통 시스템 요구 상황 에러인 warning으로 설정하여 사용하는 경우가 많다.

debug, info, notice, warning, warn (same as warning),err, error (same as err), crit, alert, emerg, panic (same as emerg)

-emerg (LOG_EMERG) : 시스템을 사용할 수 없을 정도의 비상사태 (ex.시스템 충돌 )
-alert (LOG_ALERT) : 즉시 조치가 필요한 상태 (ex.변조된 시스템 데이터베이스 )
-crit (LOG_CRIT) : 위급한 상태 (ex.하드웨어 에러 )
-err (LOG_ERR) : 일반적인 에러 상태
-warning (LOG_WARNING) : 경고 상태 (ex.시스템 요구 상황 에러 )
-notice (LOG_NOTICE) : 정상적인 상태이지만 중대한 상황
-info (LOG_INFO) : 정보 메시지
-debug (LOG_DEBUG) : 디버그 메시지(ex.실행중인 프로세서의 디버깅 정보)

Syslog-ng.conf의 추가 설정이 완료 되었다면, syslog-ng를 restart시켜야 하며,로그를 받는 디렉토리에 업체나 호스트 구별할 수 있는 디렉토리를 생성한 후 실시간으로 해당 업체나 호스트의 로그가 들어오는지 확인을 해야 한다.

또한, 로그를 관리하는데 있어서 crontab을 사용하는 것이 매우 유용하다. 로그량이 많을경우 하루 단위로 백업을 하는 스크립트를 생성해서 crontab에 설정해 놔도 되며, 로그량이 많지 않을 경우에는 며칠씩 주기적인 백업설정을 해두어도 괜찮은 방법이다.


2. 결론

IT 인프라가 꾸준히 늘어나고 있으며 이와 함께 사이버를 통한 상거래, 네트워크 시스템 사용의 증가, 사이버상의 범죄 증가 등 많은 일들이 네트워크 상에서 일어나고 있다.또한 이러한 모든 것은 회사의 경제적인 면과 밀접한 관련이 있게 마련이다.

서두에서 말씀드린 것 같이 이러한 환경에서 로그는 굉장히 중요한 역할을 하게 된다. 시스템을 관리하는 관리자든지 보안을 담당하는 보안관리자든지 로그를 통하여 침해를 사전에 예방하든지, forensic에 참고하든지 또는 시스템의 오작동을 미리 감지하여 대처할
수도 있다.

100%의 예방과 대처가 될 수는 없지만 로그의 중요성은 누구나 공감하는 부분일 것이다. 로그서버의 구성과 활용을 통해 보다 나은 시스템 운영이 가능할 거라 믿어 의심치 않는다.

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.