Syslog와 로그 파일들

  12. Syslog와 로그 파일들

12.1 개요
        
     로깅 정책은 사이트마다 다르나 일반적인 정책은 다음을 포함한다.

         $ 모든 데이타를 즉시 버린다.
         $ 일정한 시간 간격으로 로그 파일을 재설정한다.
         $ 로그 파일을 순환시켜서, 정해진 시간 동안만 데이터를 보관한다.
         $ 압축하여 하나로 모아서 테이프나 다른 영구적인 매체에 보관한다.

     로그 파일을 없애기

   - 모든 로그 파일을 없애라고 권장할 수는 없다. 왜냐하면 보안에 민감한
     사이트들은 일상적으로 계정 데이타와 로그 파일이 침입하였다는 중요한
     증거를 제공하기 때문이다. 또한 로그 파일은 하드웨어와 소프트웨어의 문제를
     찾아내는데 도움이 된다. 일반적으로 그러한 데이타는 한두달정도 보관한 다음
     지워버리는데 실제로 해커의 흔적을 살펴보는데는 필요한 로그 파일은 한 두
     주일 정도만 보관한다.

     로그 파일 순환시키기

   - 그날그날의 로그 정보를 압축된 포맷으로 디스크에 저장시키면 매일매일의
     파일은 명시된 기간동안 유지되고 나서 지워진다. 충분한 디스크 공간이 있으면
     로그 파일을 손쉽게 압축하지 않고 유지할 수 있다.
     이러한 정책으로 구현하는 한 가지 일반적인 방법을 '로테이션'이라고 한다.
     로테이션 시스템에서 하루전,이틀전,... 등의 백업 파일을 유지할 수 있다.
     각각의 날에 파일의 이름을 다시 붙여서 오래된 데이타를 연결의 끝으로 보낸다.
     파일을 logfile이라고 부르면, 백업 복사된 파일을 logfile.1, logfile.2, ...
     등으로 붙인다. 데이타의 가치가 일주일 동안 유지해야 한다면 파일은 logfile.8
     이 아니라 logfile.7까지 될 것이다. 매일 logfile.7에 있는 데이타는 logfile.6
     의 엎어쓰기로 사라진다. 그리고 로그 파일들은 압축될 수도 있다.

     ex) 3일 동안 내용을 보관하기를 원하는 로테이션 정책 구현한 스크립트

        #! /bin/sh
        cd /var/log
        mv logfile.2 logfile.3
        mv logfile.1 logfile.2
        mv logfile logfile.1
        cat /dev/null > logfile

     어떤 로그 파일에서는 소유권 정보가 중요하다. 루트로서보다는 로그 파일의
     소유주로서 cron으로 로테이션 스크립트를 실행시키거나, 혹은 그 순서에 chown
     명령어를 덧붙인다. 어떤 사이트에서는 logfile.tues 또는 logfile.aug26과 같이
     순서 번호보다는 날짜로 로그 파일을 구분하기도 한다.
     어떤 데몬은 항상 로그 파일을때문에 위의 스크립트는 그러한 데몬과는 같이
     사용할 수 없다. 새로운 로그 파일을 설치하기 위해서, 데몬에게 시그널을 보내
     거나, 죽이고 다시 시작해야 한다.

        #! /bin/sh
        cd /var/log
        mv logfile.2.z logfile.3.z
        mv logfile.1.z logfile.2.z
        mv logfile logfile.1
        cat /dev/null > logfile
        kill -signal pid
        compress logfile.1

     signal은 로그 파일을 작성하는 프로그램에 적절한 시그널을 나타내주고, pid는
     프로세스 넘버이다.

     로그 파일 보관

   - 어떤 사이트는 모든 계정 데이타와 로그 파일을 정책적으로 보관해야 한다.
     이러한 경우 로그 파일은 디스크에서 첫번째로 빼내져서, 테이프나 다른 영구
     매체에 기록되어야 한다. 이러한 정책은 빈번하게 테이프에게 백업하는 것을
     덜어주고, 최신의 데이터에 빠르게 접근하도록 한다.

12.2 로그 파일 찾기

     UNIX는 비일관성으로 인해 자주 비난받고, 실제로도 여러 임의의 로그 파일
     이름을 가지고 있으며 그 외에도 종종 디렉토리와 파일 시스템에 산재해 있다.
     따라서 로그 파일들에 대한 "일반적인 장소를 언급한다.

     로그 파일을 위치시키려면, 데몬이 수행되고 있을 때 로깅되고, 그럴 때 메세지
     가 보내지는 곳을 알기 위해 시스템의 스크립트(/etc/rc* 또는 /etc/init.d/*)
     를 읽는다. 어떤 프로그램은 syslog를 통하여 로깅을 조정한다. 데이타가 어디로
     갔는지 알기 위해 syslog의 설정 파일인 /etc/syslog.conf를 점검한다.
     표 12.1은 예로든 시스템에서의 로그 파일에 대한 다음의 정보를 보여준다.

        $ 하나로 모아져 요약되고, 혹은 잘려버린 로그 파일
        $ 각각 생성된 프로그램
        $ 어떻게 각각의 파일 시스템이 명시되는지 표시
        $ 합리적인 주의 사항의 빈도수
        $ 로그 파일의 소유주와 그룹
        $ 파일 내용의 기술

     'Where'열에 있는 글자는 로그 파일이 어떻게 명시되는지 말해준다. S는 syslog
     를 사용하는 프로그램을, C는 부팅시에 명령문에 로깅 옵션이 설정되었는지를,
     F는 설정파일을 사용하는 프로그램을, H는 코드 안에서 직접 연결된 파일 이름을
     나타낸다. 'Freq'열은 우리가 제안하는 청소의 빈도를 표시한다. 로그 파일은
     보통 644모드를 갖는다. 어떤 사이트에서는 640 또는 600으로 사용권을 줄인다.
     소유주가 아닌 다른 사람에게는 절대로 쓰기 권한을 주어서는 안된다. sulog,
     authlog, sudo.log는 600 모드를 가져야 한다. mqueue/syslog, pactt는 제한된
     소유권을 가지는 좋은 예이다.

12.3 건드리지 말아야 하는 파일들

     건드려서는 안되는 /usr/adm/lastlog와 /etc/utmp의 두 로그 파일이 있다.
     lastlog는 각 사용자의 마지막 로그인을 기록하고 UID로 색인되는 보기드문
     파일이다. 고정된 범위안에서 모든 UID를 가지고 있다면 조금 작아진다. 그러나
     루트를 0에, 그리고 아무도 -2(=65534)에 사용하지 않도록 하는 것은 불가능하
     다. lastlog를 복사하지 말아라. 그렇게 되면 ls -l 이 보여주는 모든 디스크
     공간을 사용한다. utmp는 현재 로그인되어 있는 각 사용자에 대한 기록을 유지하
     려고 한다. 일반적으로 사용자의 쉘이 적절하지 못한 신호로 죽어버리고, 그 부
     모 쉘이 적절히 마무리하지 못하기 때문에, 그 기록은 종종 틀린다. utmp는 종종
     아무나 쓸 수 있다.

12.4 운영체제간의 특이사항

     시작 파일과 syslog 설정 파일로 세밀하게 살펴보면 많은 로그 파일들을 찾아낼
     수 있으나 디스크에는 숨겨진 로그 파일이 있는 것처럼 보인다. Solaris는
     가장 정리되지 않은 로그 파일들을 가지고 있다. /var/log 디렉토리에는 그렇게
     어렵지 않다.

        $ /var/log/*
        $ /var/cron/log
        $ /var/lp/logs/*
        $ /var/saf/_log
        $ /var/saf/zsmon/log
        $ /var/adm/{messages,aculog,sulog,vold.log,wtmp}
        $ /var/adm/log/asppp.log

     마지막 파일은 전화로 네트워크에 접속하는 PPP 프로토콜이다.

12.5 SYSLOG : 시스템 이벤트 기록자

     syslog는 포괄적인 로깅 시스템으로 많은 제조회사는 커널과 시스템 유틸리티가
     생성하는 정보를 관리하기 위해 syslog를 이용한다. syslog는 두 가지의 중요한
     기능을 갖고 있다. 하나는 로그 파일을 작성하는 지루한 과정에서 프로그래머를
     해방시키고, 또 하나는 관리자가 로깅을 제어하게 해준다. syslog는 세 부분으로
     구성되어 있다.

        # syslogd와 /etc/syslog.conf - 실제로 로깅하는 데몬과 설정파일
        # openlog, syslog, closelog - 프로그래머가 syslogd에 데이타를 보내는데
                                      사용하는 라이브러리 루틴
        # logger - 로그 항목을 보내는 사용자 명령어

     syslog는 /etc, /usr/etc 또는 /usr/sbin에 있다. logger 프로그램은 /usr/ucb에
     있다. syslog 라이브러리 루틴은 표준 C라이브러리의 일부분이다.

     syslogd는 부트할 때 시작되어 계속 실행된다. syslog를 인식하는 프로그램은
     시스템에 따라 다른 UNIX 도메인 소켓, 명명된 파이프, 또는 STREAMS 모듈인
     특별한 파일 /dev/log에 syslog 라이브러리 루틴을 이용하여 로그 항목을
     기록한다. syslogd는 이 파일로부터 메세지를 읽고, 설정 파일을 참조하고, 각
     메세지를 적절한 목적지로 보낸다. 많은 시스템에서 syslogd는 또한 /dev/klog
     장치로부터의 커널 메세지를 읽는다.
     행업 시그널(HUP, signal 1)은 syslogd가 로그 파일을 닫고, 설정 파일을 다시
     읽고, 그리고 로깅을 다시 시작하게 한다. syslog.conf 파일을 변경하였다면
     변경된 효과를 나타내기 위하여 HUP syslogd 를 하여야 한다. TERM 시그널은
     syslogd를 빠져나가게 한다.
     syslogd는 자신의 PID를 /etc/syslog.pid(또는 /var/run/syslog.pid) 파일에
     기록한다. 이것은 스크립트로부터 시그널을 쉽게 보내도록 한다.

        ex) kill -1 `/bin/cat /etc/syslog.pid`

     syslogd 설정

     설정 파일 /etc/syslog.conf는 syslogd의 작동을 제어한다. 비교적 간단한 형식
     의 텍스트 파일이다. 기본 형식은 다음과 같다.

        selector <Tab> action     ex) mail.info          /var/log/maillog

     selector와 action은 하나 이상의 tab으로 구별되어야 한다. selector는 로그
     메세지를 보내는 프로그램(facility)과 그 구문을 사용하는 메세지의 중요
     단계를 구분한다.

        facility.level

     facility의 이름과 간결함의 level은 모두 정의된 값의 목록에서 선택되어져야
     한다. selector는 모두를 의미하는 "*"와 아무것도 아닌 "none"을 포함할 수
     있다. 또 ,로 분리되어진 여러개의 facility를 포함할 수 있다. 여러개의
     selector는 ;로 결합되어 사용될 수도 있다.

        facility.level                                action
        facility1,facility2.level                action
        facility1.level1;facility2.level2        action
        *.level                                        action
        *.level;badfacility.none                action

     메세지의 단계는 그 중요도를 명시한다. syslog.conf 파일에서 단계는, 메세지가
     로그되기 위해서 가져야 하는 최소한의 중요도를 나타낸다. 특별한 기능과 단계
     에 로그되는 메세지, 예를 들어 facx.levx는 facx.level 형식을 갖는, 혹은  
     levx가 level보다 같거나 더 큰 값을 가지는 한, *.level 형식을 갖는
     syslog.conf 라인과 필적한다. 예를 들면, 경고 단계에서 메일 시스템으로부터의
     메세지는 mail.notice, mail.info, mail.debug, *.warnning, *.notice, *.info,
     *.debug 뿐만 아니라 mail.warnning과 필적한다. mail.info 메세지가 파일에
     로그된다고 syslog.conf가 명시하면, mail.warnning 메세지가 그 곳으로 갈
     것이다. action 필드는 메세지로 무엇을 할 것인지를 알려준다. 만약 filename
     작동이 사용된다면, 파일 이름은 절대 경로여야 하고, syslogd는 그것을 생성
     시키지 않으므로 그 파일은 반드시 있어야 한다.

     구성 파일의 예

     아래의 세 개의 syslog.conf 파일들(작은 네트워크에 고립되어 있는 컴퓨터, 커
     다란 네트워크에 있는 클라이언트 컴퓨터, 같은 커다란 네트워크에 있는 중앙
     로깅 호스트에 대한 구성 파일)이 있다. 중앙 로깅 호스트의 이름은
     "netloghost"이다.
    
        고립되어 있는 컴퓨터

        # Small network or stand-alone syslog.conf file
        # emergencies: tell everyone who is logged on
        *.emerg                                *
        
        #  important messages
        *.warnning;daemon,auth.info        /var/adm/messages

        #  printer errors
        lpr.debug                        /var/adm/lpd-errs

     첫번째 라인은 현재의 모든 사용자의 스크린에 비상메세지를 보낸다. 비상 레벨
     메세지의 예는 시스템이 꺼지고 있을 때, shutdown이 생성한다.
     두번째 라인은 중요한 메세지를 /var/adm/messages에게 보낸다. 정보 레벨은
     경고보다 아래여서, "daemon,auth.info"절은 passwd,su 그리고 데몬 프로그램으
     로부터의 부과적인 로깅을 포함한다. 세번째 라인은 /var/adm/lpr-errs에게 프린
     터 에러 메세지를 보낸다.

        네트워크 클라이언트

        # CS Department syslog.conf file: non-master machines

        # emergencies: tell everyone who is logged on
        *.emerg;user.none                        *
        
        # important messages, foward to central logger
        *.warning;lpr,local1.none                @netloghost
        daemon,auth.info                        @netloghost
        
        # local stuff to central logger too
        local0,local2,local7.debug                @netloghost

        # cardd syslogs to local1 - to boulder
        local1.debug                                @boulder.colorado.edu
        
        #  printer errors, keep them local
        lpr.debug                                /var/adm/lpd-errs
        
        #  sudo logs to local2 - keep a copy here
        local2.info                                 /var/adm/sudolog

     많은 지역 소프트웨어가 설치된 사이트에서 많은 메세지가 user.emerg로 잘못
     로그될 수 있다. 따라서 첫번째 라인에서 user.none절을 제외하도록 명시하였다.
     두번째와 세번째 라인은 중요한 모든 메세지를 중앙 로깅 호스트에게 보낸다.
     프린팅 시스템의 메세지와 캠퍼스 내의 카드 접속 시스템은 명백히 제외되어
     있다. 네번째 라인은 지역 로깅 정보를 netloghost에게 보낸다. 다섯번째 라인은
     카드 접속 로깅 정보를 캠퍼스 내의 로깅 호스인 boulder에게 보낸다. 마지막
     두 항목은 프린터 에러와 sudo 로그 메세지의 복사본을 유지시킨다.

        중앙 로깅 호스트

        # CS Department syslog.conf file, master logging host
        
        # emergencies to the console and log file, w/timing marks
        *.emerg                                        /dev/console
        *.err;kern,mark.debug;auth.notice        /dev/console
        *.err;kern,mark.debug;user.none                /var/adm/console.log
        auth.notice                                /var/adm/console.log

        # non-emergencies to usual log file
        *.err;user.none;kern.debug                /var/adm/messages
        daemon,auth.notice;mail.crit                /var/adm/messages
        lpr.debug                                /var/adm/lpd-errs
        mail.debug                                /var/adm/mail.log

        # local authorization stuff like sudo and npasswd
        local2.debug                                /var/adm/sudo.log
        local2.alert                                /var/adm/sudo-errs.log
        auth.info                                /var/adm/auth.log

        # other local stuff
        local0.info                                /var/adm/netblazer.log
        local4.notice                                /var/adm/da.log

        local6.debug                                /var/adm/annex-isn.log
        local7.debug                                /var/adm/tcp.log

        # main logging facility via pseudo-user        "netlog"
        *.notice;kern,lpr,debug;auth.info         netlog
        local3,local4,local7,mail.none                netlog

        # user stuff, default if no facility is specified
        user.info                                /var/adm/user.log

     지역 프로그램에서 오는, 그리고 네트워크의 syslogd로부터 오는 로깅 데이타는
     파일에 쓰여진다. 어떤 경우에는 각 기능으로부터의 출력이 그 자신의 파일로
     쓰여진다. 가상(pseudo) 사용자의 netlog는 모든 중요한 메세지의 복사본을
     받는다.

     syslog 출력의 예

        Dec 27 02:45:00 x-wing netinfod[71]:cannot lookup child
        Dec 27 02:50:00 bruno ftpd[27876]:open of pid file
          failed: Not a directory
        Dec 27 02:50:47 anchor vmunix:spurious VME interrupt at
          processor level 5
        Dec 27 02:50:47 anchor vmunix: VME lvl 3, vector 0xffffff
        ...

     사이트에 대한 로깅 정책 설계하기

     작은 규모의 사이트에서는 syslog를 갖기 전에 하였던 것처럼, 각 컴퓨터들이
     중요한 시스템 에러와 경고를 각 시스템 파일에 유지되도록 로깅을 구성하는
     것이 바람직하다. 커다란 규모의 네트워크에서는 중앙 로깅이 필수적이다. 이것
     은 정보의 흐름을 다루기 쉽게 유지할 뿐만 아니라, 네트워크에서 시스템의
     보안을 위배한 사람이 데이타를 검색하지 못하게 한다. 해커는 흔적을 없애기
     위해 자주 시스템 로그 파일을 편집한다. 로그 정보가 생성되자마자 추적한다면,
     그만큼 속이기 힘들 것이다. 그러나 누군가 syslog를 불러서, 로그 파일을 조작
     할 수도 있고, syslog는 안정성이 보장되지 않는 UDP 프로토콜을 사용하며, 메
     세지를 잃어버릴 수도 있다.

     syslog를 사용하는 소프트웨어

     Table 12.5

     syslog 디버깅

     logger 명령어는 쉘 스크립트에서 로그 항목을 보내는데 유용하다. syslogd의
     설정 파일에서 변경된 것을 검사하는데 사용할 수 있다. 예를 들어 다음의 라인
     (local5.warning                /tmp/evi.log) 을 첨가하고 실행되는 것을 보기
     원한다면 다음을 실행시킨다.

        logger -p local5.warning "test messages"

     "test messages"를 포함한 라인은 /tmp/evi.log에 기록되어야 한다. 만약 발생되
     지 않는다면, 아마도 evi.log 파일을 생성시키는 것을, 혹은 syslogd에게 행업
     (Hang Up) 시그널을 보내는 것을 잊어버렸을 것이다.