Log File에 대한 포괄적 접근

초기에 Log file의 분석 및 기록에 대한 흥미는 주로 이익의 추구에 의해 고무되어왔다.
이외에도 System log와 같은 주요 File들에 대한 장기 보관, 관리 작업과 이전에는 관심을 받지 않았던 Hacker활동에 대한 분석과 Server 증설, 예측 및 자원 재분배를 위한 사용량 측정 등과 같은 원인이 있다.

대부분, 자사 Web Site의 가치 증가를 접속 수의 증가로 확인시키기를 원한다. 이 자료는 해당 Site로 통하는 Traffic 양을 통해 광고 비용과 Hosting 서비스의 가격 결정에 대한 판단 자료로 고객, 광고주, 투자자 그리고 관리자에게 보여주는데 꼭 필요하다.

추가적으로, 수년간 비공식적 시스템 관리자로 일하며, syslog와 Built-in Log Rotation System에 대한 다양하지만, 이해하기 쉽지않은 구성 Parameter를 분석한 결과, 문제를 포괄적으로 접근하고, 주요 System Event를 저장, 통보하며 원시 Data를 영구적으로 보관하는 시스템을 구성하고자 한다.

Log 대상

Server에 의해 제공되는 모든 서비스들은 기록 및 감시되어져야 한다. UNIX Host는 sendmail, Web Server, ftp, telet 및 cron과 같은 User 서비스들을 제공한다. 또한 login의 검증과 User Shell의 생성과 같은 Kernel 자체에서 제공되는 통합된 System
서비스도 제공한다.

특정 서비스의 Event에 대한 무관심으로 서비스는 사용되지도 않고, 제공될 수 없다고 생각한다.
최소한, 사용되지않은 서비스의 존재는 Server의 성능에 불필요한 영향을 주며, 어떤 서비스가 실제 필요한 것인지를 판단하기 어렵게 한다. 최악으로는, 내버려둔 서비스가 보안 취약점으로 활용되는 통로로 제공된다.

예를 들어, System 설치 동안 모든 것을 설치하려고 하는데, 이는 추가될 서비스 및 Utility들을 찾아내기 위한 추가 시간을 줄이고 향후 필요 시에 설치를 피하기 위해서이다. 그러나, 이 전체 설치 선택 시에는 일반적으로 NFS와 rshd/rlogind와 같은 보안에 취약한 서비스가 함께 설치, 활성화된다.

이러한 문제의 중요성을 파악하고 있는 관리자는 여러 방법으로 제공되어지는 서비스를 알 수 있어야 한다.

1. 모든 사용자에 의해 수행되는 전체 Process를 보기위해 ps 명령어를 Verbose Option
과 함께 사용(각 UNIX 마다 ps aux 또는 ps auxwww로 다름)
2. 현재 Port의 상태를 보기 위해 netstat -a 명령어 사용
LISTEN 상태는 Connection 시도에 대해 기다리는 서비스를 나타내고, ESTABLISHED
상태는 서비스가 연결된 Client에서 현재 사용되고 있음을 나타낸다.
3. inetd Daemon에 의해 요청될 때마다 시행되는 서비스에 대하여 /etc/inetd.conf 점검
4. rc Startup File을 점검 (각 UNIX마다 /etc/rc.* 와 같은 곳에 다르게 위치함)
5. System에 이미 존재하는 Log file의 Timestamps, 크기 및 내용을 점검
(/var/log 또는 /var/adm 과 같은 곳에 위치함)

서비스를 Disable시키는 것에 대한 내용은, 이 주제의 범위에 포함되지 않지만, 주로 /etc/inetd.conf의 해당 Line를 Comment화 시키거나, 서비스의 Package를 제거, 또는 자동적으로 시작되지 않게 rc Directory에서 Startup Scrip를 이동시키는 방법 등이
이용된다.

Syslog를 사용하는 Service

sendmail, innd(Internet News Daemon) 및 named(DNS Server Daemon)과 같은 확증된 UNIX 서비스는 표준 Logging 기능인 Syslog를 기본으로 하는 Built-in Logging 기능을 가지고 있다. Syslog Daemon은 다른 서비스에서 사용되어지는 서비스이다. 이러한 Daemon들은 Syslog에게 Log 항목을 만들도록 요청하더라도 Syslog는 특별히 이런 메시지를 처리하는 방법이 언급되어있지 않으면, 이런 요청을 무시한다.

예를 들어, sendmail의 Source Code에 syslog() 라는 UNIX C Library Function의 호출이 곳곳에 쓰여지는데, 이 Function은 syslogd에 다음과 같이 구성된 메시지를 보낸다.

1. Log 항목을 요청하는 Program의 Type (즉, mail, news 또는 일반 Daemon 등)
2. 메시지의 우선 순위 (즉, info, notice, err, 또는 emerg)
3. Log 항목의 내용

Sendmail의 Daemon은 수신되는 Mail을 Accept 또는 Reject시 info 항목을 보내고, Client와 Connection이 끊어질 경우 notice 항목을 보낸다. Sendmail은 수행 중 성공 또는 실패 작업에 따라 메시지의 항목을 만드는 경우가 수백가지가 된다.그러므로, syslog에 연관된 Daemon의 경우, 문제는 서비스가 Log 항목들을 생성하는 방법이 아니라, 이들을 적절하게 처리하기 위해 어떻게 syslog를 구성하느냐에 있다.

Syslog 구성

Syslog 구성 File은 /etc/syslog.conf이며, 다음과 같다.

#
# Log everything (except mail and auth message) of level info or higher.
#
*.info;mail.!=info;authpriv.! /var/log/messages

# Log all the mail messages in one place.
mail.*/var/log/maillog
# Log authorization messages in a protected file.
Authprive /var/log/secure
# Broadcast emergency messages to all users.
*.emerg *

이 구성 File의 첫번째 항목은 mail과 인증 서비스를 제외한 모든 서비스에서 발생시키는 info에서 emergency 의 우선순위를 가지는 메시지를 /var/log/messages에 저장한다. Sendmail은 아주 많은 항목의 메시지를 발생시켜 실제 중요한 메시지들을 쉽게 확인할 수
없게하며, 인증은 Password와 같은 민감한 정보를 가질 수 있기 때문에 이것이 일반적인
형태이다.

첫번째 항목은 또한 특정 이름이 지정되지 않은 Daemon에 의해 생성된 메시지도 저장한다. 이와 같은 Daemon 중에 named라는 DNS Server Daemon은 해당 사용에 대한 시간 통계를 발생시키는데(Compile될 때 Enable 되어야 함) 좋은 예 중에 하나이다. 이와 같은 이유로, daemon.info 메시지를 별도의 Log File에 기록하고 Main log file에 대해서는 daemon.!=info를 사용하여 이를 배제시키는 것이 바람직하다.

두번째 항목은 모든 mail 메시지를 /var/log/maillog로 보내며, 세번째 항목은 인증 메시지를 /var/log/secure로 보낸다. 마지막 항목의 Destination Field의 "*"은 도움을 표시하는 구실로써 현재 Login 되어 있는 모든 사용자의 화면에 표출되게 한다.

여러 Machine들이 각각의 Machine에서 개별적으로 Log를 보관하지 않고, Loghost 라고 하는 하나의 syslog server로 보낼 수 있게 구성할 수 있다. 구성이 올바르게 되었을 때, Loghost는 다른 Machine에서 보내는 UDP Packet를 기다리며, 이 메시지를 Local Log file에 기록하게 된다. 다음의 절차는 Red Hat Linux에 대해 이런 기능을 설정하여 준다.

1. Loghost에서, syslogd를 수행시키는 rc Startup Scrip에서 -r Parameter를 추가
한다.
2. 각각의 Machine에서, syslog.conf File에 다음을 추가한다.
#
# Send all message to the loghost, And let it filter them
#
** @loghost

그러나, 이런 기능은 외부 침입자에게 Loghost가 서비스 공격 및 자신의 Log file에 대한 보호를 하기 어렵게 만든다. 이런 기능은 Loghost가 방화벽의 보호 아래에 있거나, 특정 syslog Client에 제한적 접근을 할 수 있는 ipfwam 또는 ipchains와 같은 Kernel
방화벽 기능과 연계되어 쓰일 경우에만 사용된다.

syslog에 대한 man Page에서 해당 syntax, 여러 구성 예제 그리고 서비스 형태의 전체 List 및 보안 Level에 대해 다루고 있다. 여러 가능한 정보를 보기 위해, syslog, syslog.conf 그리고 syslogd의 man Page를 보는 것이 필요하다. syslog는 각각의 서비스에서 발생시키는 Client Library Function이고, syslogd는 syslog.conf에 의해 구성되는 Daemon이라는 것을 기억하여야 한다.

Syslog 문제 해결

syslog가 원하는 장소에 Message를 쓰지 못할 경우, 점검해야 될 것이 몇 가지 있다.

첫째, 구성 File을 다시 읽을 수 있게 syslogd를 재시작시킨다. syslogd를 재시작시키는 한 방법은 syslogd에 Hangup Signal을 보내는 것인데, ps 명령어로 syslogd의 pid를 찾아 kill -HUP <pid>를 수행한다. 다른 방법으로는, Linux 또는 Solaris 환경에서 /etc/rc.d/init.d/syslog restart와 같이 Startup Scrip를 restart Parameter로 수행하는 것이다.

다음은, 목적지 File이 존재하는지를 점검하여야 하는데, syslogd가 수정을 하기위해 반드시 존재하여야만 한다. touch <filename> 명령어로 Empty File을 만들 수 있다. syslog가 재시작되면, 해당 File에 적정한 메시지가 기록될 것이다.
다른 Host로 메시지를 보낼 경우, 수신할 Host에서는 이 메시지를 받을 수 있게 구성되어야 한다. 각각의 특정 UNIX Version에 대해 이를 구성하는 방법에 대한 특정 명령을 알기 위해 syslogd의 man Page를 참조하라.

Syslog를 사용하지 않는 서비스

Web server는 자체 독립적인 Logging 구조를 가지는 좋은 예제가 된다. Web server log는 사용량이 많은 Machine에서는 하루에 몇 MegaBytes정도로 아주 큰 것이 보통이다. Log에는 요청된 모든 File의 이름과 요청을 수행할 때 발생된 오류 등을 보관한다. 추가적인 구성으로 요청한 Browser Type과 현 Page에서 사용자가 마지막으로 참조한 Page를
보관할 수 있다.

Apache Web server에 대한 Logging는 httpd.conf에 의해 구성되는데, /usr/local/etc/httpd 또는 표준 Red Hat RPM Distribution에서는 /etc/httpd/conf에 일반적으로 위치한다. 정규적으로 log를 사용하기 위해 쓰여져야 할 Line은 다음과 같다.

LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%(Referer)i -> %U" referer
LogFormat "%{User-agent}i" agent

CustomLog logs/access_log common
CustomLog log/referer_log referer
CustomLog log/agent_log agent

LogFormat은 Format 특정자의 조합을 대표하여 나타내는 common, referer 및 agent와 같이 alias를 정의하는데, 여기에서 요청하는 Host를 나타내는 %h, 요청 받은 Page를
나타내는 %r등이 있다. 이 Alias들은 결과적으로 CustomLog 항목에 사용되는데, Apache가 특정 Log File에 어떻게 항목을 쓰는지를 정의한다. (Log Directory는 목적지가 "/"로 시작하지 않을 경우, 구성 file에서 설정된ServerRoot Directory에 상대 Direcory임을 주의)
위 구성은 Apache가 Pages accesses를 access_log에 쓰도록 하고있다. 현 Page를
요청하기 바로 전, Browser에 의해 보여진 최종 Page를 referer_log에, 요청을 한 Browser Type을 agent_log에 기록하도록 되어 있다.

여러 개의 Log file들에 해당 항목을 분산하는 방법 이외에, 이들을 하나의 Log File에 둘 수 있다. 다음의 정의는 각 요청에 대한 모든 정보를 access_log로 둘 수 있다.
LogFormat "%h %l %u %t \"%r\" %>s %b
\"%(Referer)i\" \"%{User-agent}i\"" combined

CustomLog logs/access_log combined

Apache에서의 오류에 대한 Logging은 오류의 정도에 따라 info, warn, error와 같은 여러 Level을 가지며, syslog와 비슷하다. 오류 Log에 보내지는 메시지의 최소 우선
순위는 LogLevel에서 직접 조정된다.

ErrorLog logs/error_log
LogLevel warn

Web Server가 자체 Log file을 유지하게 구성이 되면, 이 File들의 크기를 조정하여야 하며, 해당 File System이 Full이 되지 않게 조심하여야 한다. Server가 많이 사용
되거나, 오류 Log가 갑자기 아주 크질 수 있게 되는 구성상의 문제가 있을 경우, 이와 같은 현상은 빨리 발생이 된다. 이 때는 오래된 Log File들을 삭제하는 대신, 체계적으로 이들을 압축, 보관하는 것이 필요한데 이것에 대한 내용이 아래에 계속된다.

Log File들의 감시

여러 Machine들에 대한 Log file의 정리 내용이 주어지면, 각각의 Machine에서 어떠한 일들이 벌어지고 있는지에 대해 알 수 있는 가장 좋은 방법은 각 Log file의 최신 항목들을 살펴보는 것이다. 어떤 시스템 관리자는 각각에 대해 tail -f <logfile> 을 사용하여 최신의 정보를 감시하는 것을 선호하는데, 이보다 좀더 편리하게 항목이 쓰여질 때, 주기적으로 이에 대해 통보 받을 수 있는 방법이 있다.

첨부에 있는 logtail.pl script는 Log file이 최종 점검된 이후 발생된 항목에 대해
통보한다. (Sys Admin Web Site인 www.sysadminmag.com 또는 ftp.mfi.com의
/pub/sysadmin 에서도 구할 수 있음)
Usage: logtail.pl <logfile> <logposfile>

<logfile> Parameter는 관찰될 Log file이며, <logposfile>은 수행될 때마다 <logfile>의 크기를 저장할 수 있는 기록가능한 File이다. 이 Script는 이전에 통보된 Log 부분은 생략하며, 최신의 항목만을 stdout에 표출시킨다.
각 log file에 대해 logtail.pl을 cron job으로 수행시킬 때, 시스템 관리자는 최종 실행까지 만들어진 모든 항목이 포함되는 mail을 받게 될 것이다.

#
# Check the system log every day
#
55 3 * * * /usr/local/bin/logtail.pl /var/log/messages /var/log/messages.last

#
# Check the security log every day
#
56 3 * * * /usr/local/bin/logtail.pl /var/log/secure /var/log/secure.last

#
# Check the mail log every day
#
57 3 * * * /usr/local/bin/logtail.pl /var/log/maillog /var/log/maillog.last

logtail.pl Script가 하루에 한번만 수행될 경우, 수행 시간을 Log Rotation이 되기
직전에 두는 것이 중요한데(아래 참조), 이는 현 Log file이 Clear될 때, 모든 항목들이 전부 포함될 수 있도록 하기 위해서 이다. 매일 각 Machine에서의 Log File을 읽는 것은 번거러운 작업일 수 있으나, 메시지의 우선 순위에 따라 다른 Log로 적절히 분류되어 있으면 단순 정보가 아닌 메시지들은 특별한 관심을 가지고 읽을 필요가 있으며 이들은 logtail.pl Cron Job을 좀더 자주 수행하여(매분 정도) 새로운 몇 항목을 점검할 수 있다. 더 높은
우선순위 File에서의 문제를 파악하기 위해, 단순 정보 File은 독립적으로 읽을 수 있다.

이 Section에서 마지막으로 swatch라는 log에서 특정 Pattern을 점검하는 Utility를 소개한다. swatch는 원하는 Pattern(예를 들어 "panic")을 찾을 경우, Terminal Bell, mail 전송, 또는 다른 Program을 실행할 수 있다.
Swatch는 http://www.stanford.edu/group/itss-css/security/Bestuse/software.html 에서 구할 수 있다.
(첨부 참조)

특정 machine 과 서비스에 대한 swatch 구성은 원하는 Log 항목과 관심을 가질 대상에 대한 약간의 경험 지식이 있어야 한다. 이 경험은 원시 Log File을 logtail.pl로 관찰하는 것이 가장 최선의 방법이다.

Log File의 Rotating

Log Rotation은 현재 log File을 다른 이름으로 저장하고, 현재 위치에서 다시 시작한다. 표준 UNIX 구성에서는 3~4 세대까지 Log file의 가지는데, 예를 들어 현재 Log file이 message 이면, 바로 이전은 message.1이고 계속 이런 형태로 진행된다.

Solaris는 System Log Rotating에 대한 간단한 방법이 제공된다. 기본적으로 Root Account의 Cron 작업은 아래와 같은 간단한 Shell Scrip를 수행시키는데, 이는 현 System Log를 Save File로 이름을 변경하고, 기존 저장된 파일은 더 오래된 저장 File 이름으로 이동시키며, 결과적으로 가장 오래된 기존 File은 삭제 시킨다.

# Solaris usr/lib/newsyslog
#
LOG=messages
cd /var/adm
test -f $LOG.2 && mv $LOG.2 $LOG.3
test -f $LOG.1 && mv $LOG.1 $LOG.2
test -f $LOG.0 && mv $LOG.0 $LOG.1
mv $LOG $LOG.0
cp /dev/null $LOG
chmod 644 $LOG
...
kill -HUP `cat /etc/syslog.pid`

Red Hat Linux에서는 더욱 유연성을 가지는 logratate system을 소개하였다. 이것에
의해 Log File의 전체 Set는 최상위 Level인 /etc/logrotate.conf 구성 File에 의해 제어 받을 수 있고, /etc/logrotate.d에 있는 개별적인 서비스에 관련된 구성 File에 의해 제어 받을 수 있다. 기본적으로는, logrotate 구성 file에 기록된 어떤 log file도
주단위로 Rotate되고 4세대까지의 예전 Log file을 가질 수 있다. logrotate.conf에서 압축 기능이 설정되었을 경우, Rotation 동안 오래된 Log file들은 압축될 것이다.
단지 하나의 구성 File이 전체 System Log에 대한 Rotation을 책임진다.

# /etc/logrotate.d/syslog
#
/var/log/messages {
postrotate
/usr/bin/killall -HUP syslogd
endscript
}
...
# similar entries for /var/log/{secure, maillog, spooler}

이들 전략들은 모두 보관되는 log File들의 이름에 제한이 있는데, 단순히 원래 이름에 숫자의 확장자만을 더 붙이는 것이고, 위치 또한 현재 File과 동일 위치에 저장된다. 만약 보관되는 File이름이 해당 날짜에 따라 지정되고, 이들 보관 File들이 영구 저장에 별도로 할당된 영역으로 이동될 수 있으면 더욱 좋을 것이다. 다음 Section 은 이러한 Log File 보관과 Log Rotation 기능의 보완 방법에 대해 기술한다.

Log File의 보관

첨부에 있는 archive.pl Script는 임의의 File을 한 Directory에서 다른 Directory로 이동 또는 복사를 하고, 이동 또는 복사 중에 압축 또는 이름을 Timestamp에 의거하여 변경한다. 이 Script는 System에서 개별적으로, 또는 기존의 Log Rotation 설계와 통합되어 사용될 수 있다.

Usage: archive.pl -- from <srcfile> --to <destdir>
[ -- suffix <pattern>] [--ifexists]
[--overwrite] [--compress]
[--keepsrc] [--keepdate]
[--keepbase] [--keepsuffix]

선택 Parameter들은 Script가 보관전에 원시 또는 목적 File들이 존재하는지를 확인할 것인가, 그리고 보관되는 이름을 어떵게 지정할 것인가를 제어 할 수 있는 Boolean 스위치를 나타낸다.

기본적으로, archive.pl은 '\..*' pattern 을 사용하여 확장자를 Matching하여 첫번째 Dot(.) 이후의 모든 것을 확장자로 인식한다. boot.log.0이라는 File에 대해서는 기본적으로 boot.19990801로 보관되어 바람직하게 되지 않는다. 이 File을 boot.log.19990801로 보관하기 위해, 확장자 Pattern을 '\.\d*'를 사용하여 숫자로 된 확장자 만을 인식할 수 있게 할 필요가 있다.

Solaris newsyslog Script(위에서 언급된)는 가장 오래된 Log File을 제거하지 않고
별도의 Directory에 Timestamp에 의해 이름을 변경하여 보관하도록 보완되어 있다. 다음과 같은 Line 이 Script의 첫 줄에 삽입되어 질 수 있다.

/usr/local/bin/archive.pl -- from $LOG.3 --to archive
--ifexists --compress -keepdate -keepbase
이 Line은 messages.3을 현재 Directory에서 archive/ Directory로 이동시키며, Timestamp에 따라 이름이 변경되고 마지막으로 archive/messages.19990801.gz 라는 file로 압축되어 진다.

Linux 환경에서, 유사하 명령을 logrotate 구성 File에 삽입시킬 수 있다. 다음은 수정된 Apache rotation File이다.

# Enhanced /etc/logrotate.d/apache
#
/var/log/httpd/access_log {
prerotate
/usr/local/bin/archive.pl \
-- from /var/log/httpd/access_log.3 \
-- to /var/log/httpd/archive \
-- ifexists --compress --keepdate \
-- keepbase --suffix '\.\d*'
endscript
postrotate
/usr/bin/killall -HUP httpd
endscript
}

/var/log/httpd/error_log {
prerotate
/usr/local/bin/archive.pl \
-- from /var/log/httpd/error_log.3 \
-- to /var/log/httpd/archive \
-- ifexists --compress --keepdate \
-- keepbase --suffix '\.\d*'
endscript
postrotate
/usr/bin/killall -HUP httpd
endscript
}

Apache의 logrotate file에 대한 이 수정은 access_log.3 과 error_log.3을 Rotate되어 삭제되는 대신, 예를 들어 access log는 /var/log/httpd/archive/access_log.19990801.gz로 저장되어 Log File 분석 Tool에 의해 계속 점검될 수 있다.

저장된 Log File들의 분석

일단 Log file들이 영구적으로 보관되면, 시스템 관리자는 System 활동, 보안 침해, 구성상 문제 와 같은 이전 내용을 분석할 수 있다. System에서의 정상적, 비정상적 활동에 대한 유용한 자료를 가지고, 시스템 관리자는 swatch(이전 언급한)를 새로운 System의 Event를 감지하고 경고를 줄 수 있게 구성할 수 있다.

보관된 Web Server Log와 관련하여 Server의 시작 시점에서 부터의 모든 Web server의 이전 활동에 대한 요약을 지속적으로 유지하는 것은 특별히 가치 있는 시도이다. Server의 활동에 대한 최신 요약을 고객에게 제시할 수 있다면 Web Site에 광고를 고려하는 고객이나, Web site의 Traffic을 이용하고자 하는, 또는 전체 Domain을 구매하려고 하는 잠재적인 투자자에게 깊은 감동을 줄 수 있을 것이다.

이전 개요를 구성하기 위해서는 On-line으로 모든 이전 access log를 저장하고 이들을 시간대별, 또는 일별로 Analog와 같은 분석 Tool을 써서 처리하여야 한다.
(첨부 FILE 또는 http://www/statslab.cam.ac.uk/~sret1/analog/ 참조)

Analog 는 Web Server Log File들을 점검하여 Server Directory, 특정 Files, Browser Domains, 그리고 Browser Type에 따라, Access되어지고 몇몇 형태로 구성되어진 Page 및 files의 수 개요를 만들어 낸다.

Analog 구성 File은 일반적으로 /usr/local/etc/httpd/analog/analog.cfg 또는 제공된 RPM에 의해 다른 곳에 저장된다. 이 구성 File은 분석될 Logs의 위치가 수정되고, Web Server Log가 기록되는 방법을 지정하는 Format 형식을 가져야만 한다. LOGFORMAT은 Apache 구성 File에서의 LogFormat line에 해당한다.

# /usr/local/etc/httpd/conf/analog.cfg
#
LOGFORMAT (%S %j %u [%d/%M/%Y:%h:%n:%j] \
%j %r %j" %c %b "%f" "%B" )
LOGFORMAT COMMON

LOGFILE /var/log/httpd/access_log*
LOGFILE /var/log/httpd/archive/access_log*

HOSTNAME "Company X"
LOGO companyx.gif

BROWSER ON
FULLBROWSER ON
REFERER ON
REFSITE ON
OUTFILE "home/httpd/html/status/current.html"

DNSFILE "/usr/local/etc/httpd/analog/dnsfile.txt"
DNS WRITE

이 구성 File은 Analog가 httpd/ 와 httpd/archive/ Directory에 있는 Log Files을 해석하는 방법을 나타내고, Browser Types과 참조 Sites에 따라 Analog에서 다른
개요를 만들 수 있게 하고 있다. 해당 개요의 결과는 수행되는 Web Site 계층의 status/ Directory에 기록 된다.

최신 개요에 더하여, 최종적으로 완성해야 할 것은 Web Site 주기 동안 증대에 대한 이전 검토의 일별 개요를 보관하는 것이다. 다음 명령어는 archive.pl Script를 사용하여 Analog에서 발생되는 현재의 개요를 timestamp를 포함하는 다른 이름으로 변경을 시킨다. 그 결과 status/ Directory 아래에 모든 일별 개요들이 나타나게 된다.

/usr/local/bin/archive.pl \
--from /home/httpd/html/status/current.html \
--to /home/httpd/html/stats -keepsrc \
--keepdate --keepsuffix -suffix '\.html'

보관된 개요들의 집합은 19990801.html 과 같은 이름을 가질 것이다.

결 론

자신의 Server에 대해 누구도 hacking을 시도한 적이 없다고 자랑하는 시스템 관리자는 자신의 System을 감시하는 방법을 모른다고들 한다. 일반 UNIX 서비스는 시스템 Log에 그들의 문제 유무와 활동 내용을 이미 기록하고 있고, 이는 시스템 관리자가 적어도 매일 점검해야 하는 가장 중요한 Files이다. 이번 Article에서 다룬 Filtering, 감시, 그리고 Logs의 보관 방법들은 UNIX 서비스에 대한 보안 위협과 일반적 문제를 찾아내는 중요한 Tool을 제공한다.
Server의 Traffic에 재정이 의존되는 Web Site에 대해, 세심한 Log File 관리를 통해 얻은 기술이 바로 이익으로 나타난다는 것을 잊지 말아야 할 것이다.