수안이의 컴퓨터 연구실

출처 : 시스템 로그 분석 (해킹 피해와 보안 추적의 결정적 파일) - 안정철 지음
(안정철 님에게 책 내용에 대해 발췌하는 것에 대해서 허락을 구하지 못하였습니다. 삭제를 요구하시면 바로 삭제 조취 하겠습니다.)

Session 03. 에러 로그 분석 방법

웹 서버가 어떻게 사용되고, 혹 잘못된 부분이 없는지를 분석할 때에 유용하게 사용될 수 있는 것 중의 하나가 에러 로그 파일이다. "에러 로그"는 웹 서버가 운영 중에 발생되는 잚소된 모든 기록을 포함하고 있다. 웹 서버의 시작이나 중지와 같은 통보정도에 지나치지 않는 일반 메세지까지 말이다. 에러 로그 파일은 'ErrorLog' 지시어를 이용하여 어느 곳에 기록할 지를 지정하며, 기본으로 설정되는 로그 파일의 경로는 "/usr/local/apache/logs/error_log"가 된다. 에러 로그의 기록을 원하지 않는 경우에는 다음과 같이 "null" 디바이스로 전송하면 된다.



이러한 방법은 웹 서버가 디스크에 엑세스하는 시간을 줄여, 실제로 아파치가 로그를 기록하는데 소비하는 시간을 감소시켜 준다. 이외에 유닉스 시스템 로그 데몬에 에러 메세지를 전송 하는 것도 가능하다. 이것은 한 호스트에 하나의 에러 로그만이 가능하며, 만약 여러 개의 ErrorLog를 지정하게 되면 마지막에 지정된 것이 사용될 것이다. 아파치의 에러 로그는 유닉스 시스템에서 사용하는 것과 같이 제일 하단의 'debug'에서부터 'emergency'까지의 전체 8개의 범위를 가지고 있다.

일반적으로 로그의 모든 메세지들을 에러 로그 파일에 기록하는 것은 디스크의 소모뿐만 아니라 로그를 기록하기 위한 프로세스 시간을 필요로 하게 된다. 이러한 부분들을 고려하여 아파치 웹 서버는 'LogLevel' 지시어를 이용한 각 로그 레벨 단위의 기록이 가능하도록 하고 있다. 예를 들어, 'notice' 또는 그 이상의 범위에 해당하는 내용만 기록에 남기고자 한다면 아래와 같이 입력할 수 있다.


이와 달리, 'debug' 레벨을 선택하게 되면 아파치에서 발생하는 모든 에러 메세지를 로그에 기록하게 되므로 자원의 공간과 프로세스 시간을 낭비하는 결과를 초래하게 된다. 물론 이와 같이 모든 내용을 기록한다는 것이 여러분들에게 어떠한 생각을 줄여 줄지는 모르지만, 'debug'와 같이 모든 내용을 기록한다는 것이 에러 로그에 있어서는 그리 비효율적이라 생각은 들지 않는다. 로그의 범위는 여러분들의 고민으로 남겨 두도록 하겠다.

다음 표는 각 단계별 로그 레벨의 의미를 나타낸 것이다.

로그 레벨	에러의 이미
emerg	불안정한 시스템 상황
alert	즉각적인 조치 필요
crit	중대한 에러
error	비교적 중대하지 않은 에러
warn	경고
notice	중대한 것은 아닌 일반적인 메세지
info	정보
debug	디버그 레벨

아파치의 에러를 시스템 로그 데몬인 'syslogd'를 전송하기 위해서는 다음과 같이 기존의 에러 로그 파일의 이름을 'syslog'로 변경하여야 한다.



기본적으로 에러 로그는 syslog에 'local7'의 이름으로 기록이 되며, syslog.conf에서 syslogd 데몬은 어떠한 에러 메세지들을 받을 것이지 제어하게 된다. syslog.conf에 다음의 라인을 포함하게 되면 /var/log/httpd.log에 내용을 저장하게 된다.



이외에 local7.* 과는 달리 앞쪽에서 언급하였던 로그 레벨을 기반으로 로그를 따로 저장 할 수가 있다. 아래의 예은 warn 로그 레벨 이상의 정보를 /var/log/httpd_warn.log 에 저장하는 것과 info 레벨 또는 그 이상의 메세지를 error 레벨 이하로 기준하여 /var/log/httpd_info.log 에 저장하게 된다. 쉽게 이야기하면 httpd_info.log는 info,notice,warn 레벨을 포함하는 것이다.


웹 서버의 문제 해결은 에러 로그와 함께 아파치를 처음 접하는 초보자가 설치 후 애기치 못한 문제에 봉착하였을 경우에는 당황하지 말고 에러 로그를 찾아봄으로써 문제의 대부분을 해결할 수 있다.

웹 서버에 문제가 있을 때에는 발생되는 문제를 즉시 확인하기 위하여 계속적으로 로그 파일을 확인해 보아야 하는 경우도 있기 마련이다. 이럴 때에는 유닉스에서 제공해 주는 'tail' 명령어를 이용하여 다음과 같이 사용하면 된다.



또 다른 방법으로는 펄을 이용할 수가 있다. File::Tail 모듈을 사용하면 되고 이것을 통하여 여러분들이 다양하게 응용하여 사용해 볼 수 있으며, http://www.cpan.org/modules/by-module/File/File-Tail-0.98.tar.gz에서 구할 수 있다.



"tail -f" 를 이용한 로그 파일을 살펴보면 이래와 같은 내용을 확인할 수 있다.



지금까지 아파치 서버의 대표적인 Access_log와 error_log의 분석 방법에 대하여 알아보았다. 아파치 서버는 오늘날 운영중인 웹 서버중 운영 빈도가 높은 서버중 하나이다.

아파치 서버에 저장된 로그 파일로부터 유용한 정보를 얻어내기 위해서는

- 사용자 스스로 로그 파일에서 필요한 정보만을 추출하는 방법
- 자동화된 로그 분석 프로그램을 이용하는 방법

위 2가지 방법으로 나눌 수 있다. 대부분의 경우에는 수작업에 기록된 내용을 분석하고 통계를 알아내는 방법보다는 분석 프로그램을 이용하여 다양한 정리된 자료를 원할 것이다. 그러나 경영자 입장에서 웹 로그로부터 얻을 수 있는 가장 중요한 정보중 하나는 히트(hit)와 페이지뷰(pageview)이다. 히트는 웹 서버에서 받은 모든 요청과도 같다. 페이지 상에 포함된 이미지, 사운드 파일, 그리고 기타 모든 것들이 하나의 히트로 간주되며, 이와 달리 페이지뷰는 좀 더 정확하게 전체의 각 부분이 아니라 페이지 전체를 하나로 본 것이라 이해하면 된다.

이 히트와 페이지뷰를 통하여 누가 사이트를 방문하였고, 방문한 사용자들은 어디로부터 왔으며, 어떠한 페이지를 보았고, 또 얼마나 오랫동안 머물렀는지, 그리고 사용한 브라우저는 무엇인지 등 다양한 정보를 방문객으로부터 얻어낼 수가 있다.

이러한 정보를 다양하게 분석하려면 분석 툴 보다는 수작업에 의한 것이 더 다양한 정보를 획득할 수 있다는 점을 잊지 말기 바란다. 그러나 로그 분석 툴이 사람의 수작업을 통한 것보다 좀 더 정확하고 신속한 장점도 있음을 알아두자.

아무리 웹 서버의 로그를 잘 분석하고 적절히 조치할 수 있다하더라도 서버 관리자에 의한 환경 설정에 따라 외부로부터의 공격 가능성과 웹 서버 자체 또는 사용하는 어플리케이션 프로그램의 버그로 인한 공격에는 늘 노출되어 있음을 인식하자. 특히 요즘 사회이슈로 자주 등장하는 인터넷 웜의 경우 각 서버에 공통적인 취약점을 찾아서 공격하므로 웹 서버의 경우는 로그 분석만이 아니라 보안 패치가 수시로 이루어져야 한다.

아파치의 경우 공개 소프트웨어이면서 많이 운영되다 보니 시스템 자체의 취약점이 자주 발견되고 즉시 패치자료가 공개되고 있다. 따라서 아래의 사이트에서 수시로 패치자료를 다운받아 설치해두는 점이 좀더 안정적인 시스템 운영에 도움이 되리라 생각한다.

출처 : 시스템 로그 분석 (해킹 피해와 보안 추적의 결정적 파일) - 안정철 지음
(안정철 님에게 책 내용에 대해 발췌하는 것에 대해서 허락을 구하지 못하였습니다. 삭제를 요구하시면 바로 삭제 조취 하겠습니다.)

Session 02. 접속 로그 분석 방법

아파치 웹 서버에서 기본적으로 각 클라이언트의 요청을 기록하는 'access_log'는 이름에서도 느낄 수 있는 것처럼 웹 서버에 접근되는 모든 것을 기록하게 된다. 접속 로그는 방문자 정보를 얻는데 있어서 가장 중요한 역할을 담당하고 있다. 우선, 여러분들이 정보를 가져올 'access_log'는 다음과 같이 TransferLog 지시어를 사용하여 어느 위치에 로그를 남길 것인지 결정을 할 수가 있다.
그 러나 1.3.X 버전부터 사용자 정의 로그 포맷을 지원하고 있다. 대부분의 웹 서버들은 CLF(Common Log Format)로 파일을 생성하고 있으며, 이외에도 ELF(Extended Log Format), 그리고 Combined Log Format이 있다. 몇몇 서버들은 이외의 다른 형식 포멧을 사용학 있지만 CLF와 비슷한 형식을 취하고 있으며, 아파치 웹 서버는 기본적으로 이 포맷 방식을 따르고 있다. 지금 시점에서 여러분들이 사용하는 아파치 웹 서버의 로그 파일 설정은 다음과 같이 이루어져 있을 것이다.


CLF는 각 클라이언트 요청에 한 라인으로 구성되어져 있고, 공백에 의해 각 필드는 7가지의 정보를 포함하여 구분되어 있다. 기본 포맷은 다음과 같은 형식을 갖추고 있다.


첫 번째 필드는 원격지 호스트 주소 정보를 가지고 있다. 이것은 어느 누가 여러분들의 웹 사이트를 방문하였는가를 말해주는 것이다. 기본적으로, 이곳은 원격지 호스트의 정보가 IP 주소로 기입이 된다. 물론 아파치 웹 서버에서 호스트 이름을 찾아 기록할 수 있도록 설정할 수는 있으나, 아파치 1.3.X 버전에서는 성능상의 문제로 호스트 이름 대신 IP 주소로 기록하고 있다.


아 파치 웹 서버는 IP 주소 대신 'HostNameLookups' 지시어를 사용하여 호스트 이름으로 기록을 할 수가 있다. 그러나 이러한 방법의 사용은 결과적으로 서버의 전반적인 성능을 떨어뜨릴 수 있는 요인 중의 하나가 될 수 있으므로 권장하지 않는다.

HostNameLookups on과 같이 사용하면 되며, on 이외에 double을 사용하여 역 방향 이름을 찾아 조회하는데도 사용할 수 있다.

logresolve 프로그램을 이용하여 IP 주소를 도메인으로 변경하는 방법은 아래와 같다.


두 번째 필드는 대부분의 경우 아무런 정보를 가지고 있지 않다는 '-'로 표시될 것이다. 이것은 방문자를 식별하는 정보를 얻는 경우에 이용되며, 실질적인 인증을 통한 로그인 이름이 아니라 사용자의 이메일 주소 및 식별할 수 있는 정보 등을 의미한다. 이 정보는 'identd'에 또는 브라우저의 직접적인 정보 제공에 의해 기록되어 질 수 있으나, 이러한 기능은 이미 오래 전에 사라져 사용되지 않고 있는 정보로 생각하면 된다.

세 번째 필드 또한 '-'로 표시되는 경우가 많으며, 방문자가 사용자 인증을 통하여 접속한 경우에 사용자의 로그인 이름이 기록된다. 네 번째 필드는 클라이언트가 서버의 자원을 요청한 시각이며, 다섯 번째 필드 "request"에는 요청한 자원이 어떤 것인지를 나타낸다. 주로 웹 서버의 자원을 클라이언트로 가져가기 위해 GET을 사용하며, 그 다음에는 실제적인 문서, 즉 URL을 의미한다. 클라이언트는 '/'를 시작으로 DocumentRoot 디렉토리로 지정한 경로에 기반하여 사용자에게 문서를 보여주게 된다.

URL의 마지막에는 HTTP 프로토콜 버전이 따라오게 되는데, 이 번호는 1.0 또는 1.1이 될 것이다. HTTP/1.0은 초창기의 프로토콜 버전으로 최근의 브라우저는 HTTP/1.1을 지원하고 1.0에 비해 많은 성능개선을 한 HTTP/1.1이 주로 사용되고 있다.

여 섯 번째의 필드는 웹 서버의 상태 코드를 의미하는 것으로서 클라이언트의 요청이 성공적이었는지, 또는 문제 발생이 있었는지를 코드번호로 나타내고 있다. 대부분의 경우에는 성공적인 전송을 의미하는 200번일 것이며, 서버에서 문제가 발생할 시에는 5XX번대로 시작한 에러코드가 기록될 것이다.

마지막인 일곱 번째 필드는 클라이언트에게 전송된 바이트를 나타낸다. 이것은 하루에 얼마나 데이터가 전송되었는가를 알아내고자 할 때 사용될 수 있다.

다음의 예를 살펴보자.


192.168.0.151 의 IP 주소에서 요청한 것을 보면 2005년 3월 1일 11시 43분 50초에 Test 센터를 요청하였으며 HTTP/1.1 프로토콜을 사용하였다. 상태 코드는 200을 나타내는 것으로 보아 클라이언트에게 성공적으로 전송되었음을 알 수가 있고 총 11,177bytes가 전송되어졌다. 각 필드에 해당하는 의미를 간단하게 기술해 놓은 CLF(Common Log Format)을 구성하는 각 필드는 다음과 같다.

아이템	의미
Host	클라이언트의 호스트 이름이나 IP Address
Ident	IdentityCheck가 enable 되어 있고, 클라이언트가 ident에 응답을 보내면 identity 정보를 남기게 되며, 보통은 "- "로 대체된다.
Authuser	인증이 있을 경우 여기에 사용자 이름이 기록되게 되며, 그렇지 않을 경우 "- "로 대체된다.
Date	접속한 시간과 날짜를 나타내며, 포맷은 다음과 같다 : 날짜 포맷 = [day/month/year:hour:minute:second zone] day = 2*digit month = 3*letter year = 4*digit hour = 2*digit minute = 2*digit second = 2*digit zone = (+' | -') 4*digit
Request	클라이언트가 요청한 자료
Status	요청한 것에 대한 서버의 처리 사항으로 상태 코드라 한다.
Bytes	헤더를 제외한 전송된 Byte 양

지금까지 기본 로그 포맷에 대하여 알아보았다. 이번에는 'CustomLog' 지시어를 이용한 사용자 정의 로그 포맷에 대해 살펴보고자 한다.

'CustomerLog' 지시어는 'TransferLog'의 기능을 내포하고 마찬가지로 로그 파일이 어느 위치에 저장되어야 할지를 가리키며 추가적으로 저장되는 로그의 포맷을 사용자에 의해 지정을 할 수가 있다. 이전에는 CLF(Common Log Format)이라 불리는 고정된 형식으로만 사용이 가능하였다. 그러나 지금은 CLF 포맷을 여러분들이 원하는 형태 즉, 필요한 정보로 맞춤 정장과도 같이 여러분들의 입맛대로 만들 수가 있는 것이다.

원하는 형태의 로그 파일을 만들기 위해서는 포맷을 지정하여야 하고, 이 역할을 'LogFormat' 지시어가 한다. 다음의 내용을 httpd.conf에서 찾아볼 수가 있을 것이다.


이 뜻은 인용 부호 "'' 안의 로그 포맷을 "common"의 이름으로 만드는 것이다. 각 문자들이 나타내는 것은 특정 정보를 의미하며, 기술한 순서에 따라 로그 파일에 기록된다. 로그 포맷으로 사용 가능한 변수와 이에 대한 의미는 다음 표와 같다.

포맷	의미
%a	원격지 IP 주소
%A	로컬 IP 주소
%B	HTTP 헤더를 제외하고 전송된 바이트
%b	HTTP 헤더를 제외하고 전송된 바이트. CLF 포맷에서는 전송된 것이 없을 경우 0으로 표시하기 보다는'-'로 표시한다.
%{FOOBAR}e	서버에 의해 지정된 환경변수
%f	파일 이름
%h	원격지 호스트
%H	요청한 프로토콜
%{Foobar}i	Foobar의 내용 : 클라이언트에서 서버로 요청된 헤더라인으로 예를 들자면, Referer 헤더일 경우 %{Referer}i로 사용되어 진다.
%l	원격지 사용자 이름(이것이 사용되어 지기 위해서는 IdentityCheck가 반드시 enable 되어져 있어야 한다.)
%m	요청 방식
%{Foobar}o	서버에서 응답되는 HTTP 헤더. 예를 들면 : %{Content-Type}o, %{Last-Modified}o
%p	요청을 처리하는 서버의 참조적인 포트
%P	현 요청을 처리하고 있는 아파치 자식 프로세서의 프로세스 ID
%q	쿼리 문자열(쿼리가 있을 경우 "?" 뒤로 쿼리문이 포함되며 그렇지 않을 경우 공백으로 처리된다.)
%r	HTTP 메소드를 포함한 요청의 첫 라인
%s	HTTP 상태 코드. 만약 클라이언트의 요청이 내부적인 리다이렉트를 발생시켰을 경우 %s는 초기 요청을 상태 코드를 %>s는 최종 상태 코드를 포함하게 된다. 일반저긍로 %s의 사용 보다는 %>s가 유용하다.
%t	요청한 시간과 날짜(standard english format)
%{format}t	strftime() function을 이용한 포맷 형식에 따른 시간 [Day/Month/Year:Hours:Minutes:Seconds Time Zone]
%T	요청을 처리하는데 걸린 시간(초)
%u	인증이 요청된 원격 사용자 이름
%U	요청된 URL
%v	요청을 처리하는 서버의 참조적인 서버 이름
%V	UseCannoicalName 설정에 따른 서버 이름

여기서 많이 쓰이지 않는 'ident'와 'authuser' 필드는 제거하여 로그 파일에 기록되지 않게 할 수도 있으며, 다음과 같이 에이전트와 참조 로그를 한 로그 파일에 만드는 것도 가능하다.


이와 같이 로그 포맷에 대해서 알아보았는데, 이외에 다른 방법들은 없을까? 'CustomLog'와 'LogFormat'을 이용한 효율적이고도 다양한 방법들로는 무엇이 있는지 함께 알아보도록 하자.

때 로는 HTTP의 각 상태코드 별로 로그를 취합하여 효율적인 분석이 필요한 경우도 있다. 이럴 경우에는 %와 변수 사이에 HTTP 상태 코드를 집어넣어 해당하는 이벤트가 발생하는 경우에 로그를 남길 수 있다. 예를 들어, 잘못된 링크만을 따로 저장하고 할 때에는

LogFormat %404{Referer}i BrokenLinks
CustomLog /usr/local/apache/logs/broken_links BrokenLinks

와 같이 사용하면 된다. 최근에는 멀티미디어 서비스 및 이미지의 사용이 많아지고 있는 추세로 로그 파일에 많은 양의 데이터가 쌓이고 있다. 이에 대한 해결책으로는 아파치의 'mod_setenvif' 모듈을 이용하는 것으로서 방안을 제시해 주고 있다.



(a) - (c) 까지는 gif 이미지를 gif-requests.log에, 그 이외의 것은 nongif-requests.log에 저장 하는 것이며, 나머지 (d) - (g)는 CLF 포맷으로 이미지 파일인 gif를 제외한 로그를 access_log에 남기라는 의미이다.



www.Test.net 을 통해서 들어오게 되면 apache_site_referral 변수를 설정하여 로그를 남길 수도 있다. 한 가지 주의할 점은 SetEnvIf[NoCase]에 의한 환경 변수의 지정은 CustomLog와 같이 변수를 이용한 저장일 경우에는 CustomLog 지시어 전에 설정되어 있어야 한다.

지금까지 여러 다양한 방법의 사용을 알아보았다. 마지막으로 가상 호스트를 많이 운영하는 분들을 위하여 여러 개의 로그 파일을 하나의 파일로 만드는 방법을 보자.


이 것은 기본 로그 포맷 앞에 "canonical name"과 IP 주소, 포트 번호를 나타내는 추가적인 정보가 더 기술되어 있다. 이러한 방식을 통한 운영은 OS 특성상 동시에 파일을 열 수 있는 개수의 제한 등으로 인하여 모든 가상 호스트마다 개별적인 로그 파일을 만들어 줄 수 없을 때 사용할 수가 있다.

출처 : 시스템 로그 분석 (해킹 피해와 보안 추적의 결정적 파일) - 안성철
(안성철님께 허락을 구하지는 않았고, 삭제를 요청할 시 바로 삭제 조치 하겠습니다.)


1. 해킹 피해 시스템 분석 절차

1.1 시스템 침입 흔적 조사 방법
특별한 장소 또는 행위로부터의 접속에 대한 로그 파일을 조사한다.

• last, syslog, 프로세스 로그와 그 밖에 다른 로그 파일을 조사한다.
• access-log, xferlog 등 주요 서버의 로그 파일을 조사한다.
• 방화벽 또는 라우터에 의한 로그 기록이 있을 경우 조사한다.
• 유닉스에서 기본적으로 제공하는 로그 파일들을 조사한다.
• /var/adm/messages 콘솔 상에 있는 정보
• /var/adm/utmp(x) 현재 로그인 한 사용자 정보
• /var/adm/wtmp(x) 사용자의 로그인, 로그아웃
• 시스템의 shutdown, start up 정보를 조사한다.
• /var/adm/lastlog 사용자의 최근 로그인 관련 정보
• /var/adm/acct 사용자의 command 정보
  

예) 시스템 공격에 따른 각종 로그 예

imap/ipop 공격 로그 : message 로그 파일

mscan 공격 로그 : secure 로그 파일

statd 공격 로그 : message 로그 파일

WWW 관련 공격 로그 : access-log 로그 파일

setuid, setgid 파일을 조사한다.

• 침입자는 종종 추후에 루트 권한으로 접속하기 위해 /bin/sh 또는 /bin/time 과 같은 백도어 파일을 남겨둔다.
• 다음의 방법으로 setuid, setgid 파일을 찾는다.

NFS/AFS 마운트 시스템에서는 다음과 같은 명령어를 이용한다.
[Test: /]find / -user root -perm -4000 -print -xdev

• setuid 파일을 찾는 다른 방법으로 각각의 파티션에 대해 적용하는 ncheck가 있다.

시스템의 바이너리 파일 변경 여부를 조사한다.

• 침입자는 /etc/inetd.conf가 참조하는 다음과 같은 파일들을 변경한다.
  login, su, telnet, netstat, ifconfig, ls, find, du, df, libc, sync 등
• 백업된 초기 파일과 현재의 파일을 비교하기 위한 유닉스의 sum 명령어는 트로이 목마 프로그램에 의해 거짓 정보를 나타낼 수 있으므로 다음 프로그램을 사용한다. cmp, MD5, Tripwire 등 다른 암호화 검사 유틸리티들 인가받지 않은 프로그램 및 네트워크 모니터링 프로그램의 사용을 조사한다.
• 침입자는 사용자의 계정과 패스워드 정보를 얻거나, 자신의 존재를 숨기거나, 또 다른 시스템을 공격 하기 위해 다양한 프로그램 피해 시스템을 설치하여 사용한다.

cron과 at.으로 수행되는 모든 파일을 검사한다.

• 침입자는 보통 cron과 at 명령으로 수행되는 파일들에 백도어 프로그램을 남겨둔다. 그러므로 이러한 프로그램으로 수행되는 파일들을 쓰기금지로 설정한다.

인가받지 않은 서비스를 조사한다.

• /etc/inetd.conf를 조사하여 인가받지 않은 추가되거나 변경된 서비스를 조사한다. 특히 쉘을 수행 할 수 있는 /bin/sh나 /bin/csh를 조사한다. /etc/passwd 파일을 조사하여 변경된 부분이 있는지 확인한다.
• 추가된 계정, 패스워드의 생략, uid(0로의)의 변경여부를 확인한다.

시스템과 네트워크 설정 파일의 인가받지 않은 항목을 조사한다.

• /etc/hosts.equiv, /etc/hosts.lpd와 모든 .rhosts 파일에 '+' 항목이 있는지 조사해서 제거한다.
  시스템에 숨겨지거나 '.' 으로 시작하는 특이한 파일이 있는지 조사한다.
• ls 명령어로 보이지 않는 파일을 조사한다.

일반적으로 '.xx' 파일이나 '.mail' 파일이 침입자에 의해 이용된다. 지역 네트워크의 모든 시스템을 조사한다.

1.2 침입자의 출발지 분석
침입자의 출발지는 어떻게 확인할 수 있을까? 정확하게 위치를 추적하기는 힘들더라도 개략적인 위치는 시스템에서 제공하는 명령어로도 확인할 수 있다. 이러한 정보를 확인하기 위해서는 다음과 같은 명령어를 이용하여 정보를 검색하면 된다.

• who, w : 사용자 및 사용자의 컴퓨터 확인
• last : 사용자들의 로그인/로그아웃 일시 기록 확인
• lastcomm : 사용자들의 시스템 명령 및 프로세스 기록 확인
• netstat : 네트워크 접속 현황 확인
• snmpnetstat : 네트워크 관리 시스템에서의 현황
• 라우터 정보 : 라우터의 라우팅 및 접속 등의 현황 확인
• /var/adm/messages : 전자우편 송수신 현황 기록 확인(많은 침입자들이 자신의 시스템으로 전자 우편 송신)
• syslog : 시스템 로그 확인(다른 시스템으로도 로그를 보낸다)
• wrapper 로그 : 외부 시스템 접속 차단 프로그램의 연결

시스템의 모든 사용자에게  finger를 하여 어디서 왔는지 점검


1.3 ethernet sniffer로 다른 시스템에 어떻게 침입하는지를 모니터링 하는 것이 좋다.
xinetd나 tcp_wrapper는 외부에서의 모든 접속에 대해 로그를 남길 수 있으며, 침입자가 로그를 수정하거나 지울 수 없도록 이 로그들을 다른 시스템에 옮겨두는 것이 바람직하다. 적절한 대책을 세우기 전에 침입자가 ethernet sniffer로 다른 시스템에 어떻게 침입하는지를 모니터링 하자.

1.4 외부로부터 접속하는 시스템들을 막고 특히, 침입자의 접근을 막기 위해 네트워크를 중지시킨다.
하지만 만약 침입자가 눈치 챈다면 당신의 시스템에서 "rm -rf /"를 실행하여 모든 정보를 지울 수 있다.

1.5 시스템 실행 파일의 변경 유무를 점검하는데, 특히 백도어 프로그램으로 잘 이용되는 다음 프로그램들을 중점 점검한다.

• /bin/login
• 모든 /usr/etc/in.* files (예 : in.telnetd)
• /lib/libc.so.* (on Suns)
• inetd에서 호출되는 모든 것

기타 잘 교체되는 것으로서는 다음과 같은 것이 있다.

• netstat : 정보를 감추게 한다.
• ps : 프로세스를 감추게 한다(예 : Crack).
• ls :  디렉토리를 감춘다.
• ifconfig : 이더넷에 대한 promiscuity mode를 감춘다.
• sum : sum을 수정하지 않고도 실행 파일의 체크썸을 올바르게 위장 할 수 있으므로 더 이상 교체하지는 않는다.

따라서 sum 값을 믿어서는 안된다. 파일의 실제 수정 시간을 알기 위해서는 "ls -lac"를 사용한다. /etc/wtmp를 점검하여 시스템 시간을 알아내고 CD나 테이프의 원본과 비교하거나 MD5 체크썸이 이전의 체크썸과 다른지 비교하며, 흔히 오프라인으로 저장된 미리 만들어진 체크썸과 cmp 명령으로 비교한다. 아울러 흔히 사용되는 백도어로서 /bin/time 과 같은 setuid 프로그램인데, 이들은 일반 사용자가 root로 실행할 수 있게 해준다. 이런 프로그램을 찾기 위해서는 다음 명령을 이용하면 된다.


하다보면 OS 전체를 다시 설치해야 될지도 모른다. Tripwire 보안도구는 관리자 몰래 실행 파일을 수정하거나 inetd.conf와 같은 시스템 파일의 수정을 발견할 수 있도록 도와준다.

1.6 모든 사용자의 .rhosts, .forward등을 점검한다. 만약 .rhosts가 "+"를 가지고 있으면 어떠한 시스템에서도 패스워드 체크없이 접근할 수 있다. COPS는 다음과 같은 체킹 스크립트를 가지고 있다.


의심스러운 모든 파일의 생성 및 수정 시간을 점검하는데 다음을 이용한다.


이것은 이틀 전에서 하루 이후에 수정된 파일을 찾아준다. 모든 .login, .logout, profile, .cshrc들도 적어도 수정일 및 시간 등을 점검하며, .rhosts 파일이 잠궈진 것은 없는지, news, sundiag, sync 등의 계정에 대한 쉘이 보다 안전을 위해 "/bin/false"로 되어 있어야 하며 "/bin/sh" 등으로 되어 있어서는 안된다.

또한 ".", ".." 등의 디렉토리가 없는지 점검하는데 대부분 /tmp, /var/tmp, /usr/spool/* 나 공개적으로 쓰기 할 수 있는 디렉토리에서 많이 발견된다.

1.7 NFS가 외부로 널리 공개된 것은 아닌지 점검한다.
NFSwatch는 NFS 트랜잭션에 대해 로그를 만들어 주며, "showmount -e"를 하여 올바른 NFS 구성을 점검할 수 있도록 한다. 256 바이트를 넘긴 경우에 nfsd는 버그를 가지고 있으며, 또한 여러분이 마운트하고 있는 시스템에 대한 점검도 중요하다. 가능한 "nosuid" 플래스를 사용한다.

1.8 시스템 취약점이 있는지 점검하는 리스트
원하지 않는 프로세스가 없는지, "rpcinfo -p"를 이용하여 점검한다. hosts.equiv 에 "+"가 없는지 점검한다. tftp를 사용하지 않는가, 사용하기를 원한다면 "-s" 플래그를 사용한다. 이 경우는 대부분 디스크 없는 워크스테이션을 위한 경우인데, 적절하게 NFS를 이용할 수 있다. 이것을 root로 실행하지 않도록 하며, /etc/inetd.conf에서 다음과 같이 바꾼다. tftp dgram udp wait nobody /usr/etc/in.tftpd in.ftpd -s /tftpboot 혹은 원치 않는 곳에서의 접근을 막기 위해 tcp_wrapper에서 tftpd에 한 부분을 고치고 모든 접속 상황을 로그로 남긴다.

tfp dgram udp wait nobody /usr/etc/tcpd in.tftpd -s /tftpboot 혹은 /etc/hosts.allow에서 정의된 곳에서만 접근할 수 있도록 조정한다. crontab과 at-vobs를 점검한다. 침입자가 남긴 모든 것을 정리했다고 생각한 후 이것이 어떤 작업을 할 수 있다. rc.boot, rc.local(SYSV : /etc/rc?.d/*)나 기타 시스템 시작 시 실행 파일들을 점검한다.

가장 좋은 방법은 오프라인으로 저장했다가 주기적으로 점검하는 것이며, sendmail.cf, hosts.allow, at.allow, at.deny, cron.allow, hosts, hosts.lpd 등의 시스템 구성 파일들을 점검한다. "aliases"는 메일 확장을 위한 것인데, "uudecode" 등과 같은 것을 가지고 있을 수 있다. inetd.conf 와 /etc/services 파일에서 침입자가 추가한 불법 프로그램 서비스가 있는 지 점검한다. 현재 가지고  있는 모든 로그 파일(pacct, wtmp, lastlog, sulog, syslog, authlog 등)들을 다른 안전한 곳으로 옮긴다. /tmp/* 파일들을 먼저 살펴 본 후 재시동(Reboot)한다.

/etc/passwd 파일의 여분 파일을 가능한 디스켓 등으로 저장한 후 su 및 passwd 프로그램이 백도어가 아님을 확인한 후 root 패스워드를 바꾼다. 만약 침입자가 su나 passwd 백도어를 설치하였다면 /etc/passwd 파일의 패스워드 부분을 모두 "*"로 바꾼다.

또한 침입자가 패스워드 파일을 가지고 있다면 모든 사용자들의 패스워드를 알아낼 가능성이 있으며, 장시간 사용하지 않는 사용자의 패스워드를 바꿀 수도 있다. NIS 서버에서는 단순히 /etc/passwd 뿐 아니라 NIS 맵에 해당하는 것들도 점검해야 한다. 익명 FTP나 다른 네트워크 서비스 시스템들이 적절하게 구성되어 있는지 점검한다. inetd를 다시 설치하고, 콘솔만이 "secure" 단말로 정의하여 다른 단말에서 root로 로그인할 수 없도록 한다. hosts.equiv, .rhosts, hosts.lpd에 "#"이 있는지 점검한다. 만약 침입자가 "#"을 기계이름으로 정의하였다면 누구나 신뢰하는 호스트로 정의된다. 마지막으로 침입자에 대한 경각심을 늦추지 않는다.

2. 침해사고 분석 방법

2.1 관리자 관점에서의 분석
위의 예와 같이 침입자는 다양한 방법을 이용하여 시스템에 침입하여 불법작업을 수행한다. 관리자는 이러한 침입자의 행동을 모니터링 하는 것은 쉽지 않지만 침해사고가 발생할 경우 시스템이 가지고 있는 여러 로그기록을 이용하여 침입자 확인, 침입 방법, 침입자의 출발 호스트 등의 정보를 얻을 수 있다.

그리고 침입자들이 이용하는 웹 서버, imapd 등 서비스 취약점을 이용한 공격도 서버들이 기록하는 로그 기록을 분석할 수 있는 것이다. 여기에서 유닉스 기반의 시스템에서 제공되는 로그 정보 점검에 대해 예를 들어 설명하겠다.

■ 시스템 로그 파일
유닉스 시스템에는 다양한 로그 정보를 가진 파일과 관련 명령어들이 있다. 먼저 시스템 내의 로그 파일은 주로 /var/adm 디렉토리에 존재하게 되는데 필요에 따라 파일의 위치를 변경할 수 있다. /var/adm/ 파일들은 /var/adm/messages, /var/adm/utmp(x), /var/adm/wtmp(x), /var/adm/lastlog, /var/adm /logining, /var/adm/acct 등이 제공된다.

로그 파일	보유 정보
/var/adm/messages	콘솔 상에 있는 정보
/var/adm/utmp(x)	현재 로그인 한 사용자 정보
/var/adm/wtmp(x)	사용자의 로그인, 로그아웃, 시스템의 shutdown, start up
/var/adm/lastlog	사용자의 최근 로그인 관련 정보
/var/adm/acct	사용자의 command 정보

유닉스의 기본 로그 파일들이 가지고 있는 정보를 살펴보면 다음과 같다. /var/adm/wtmp(x)는 시스템 사용자의 접속 정보를 알 수가 있는 파일이다. 이는 last 명령어를 이용하여 정보를 볼 수 있는데 그 예는 다음과 같다.


위의 경우 userone은 평소 xxx.xxx.147.46 네트워크에서 접근을 하는데 비해 비정상적인 시간대에 dialup77.xxx.xxx.xxx 호스트에서 접근한 사실을 알 수가 있다. 이는 userone의 비밀번호가 누출이 되어 이상한 호스트에서 접근한 것을 알 수가 있는 것이다.

syslog 데몬을 이용하여 시스템 접속 오류 등에 대한 로그를 설정하였을 경우 messages 파일을 점검함으로써 불법적인 접근 시도가 있었는지도 살펴볼 수 있다. 이 역시 시스템 사용사으이 오류를 포함한 외부로부터의 불법적인 접근 등을 검사할 수 있다.


위의 경우는 외부로부터 named 버그를 이용하여 시스템에 침입하기 위한 침입자에 의해 named 데몬이 재시동되는 것을 알 수 있다. 이와 같이 다양한 로그 정보들을 검토함으로써 외부로부터의 불법적인 접근 시도 또는 접근 사실을 알 수 있다.

■ 주요 서버의 로그 정보 분석

- 웹 서버의 로그 정보 분석
관리자는 웹 서버의 로그 파일인 Access log나 error log 파일을 점검함으로써 외부 침입 자가 시스템 내의 중요 파일을 가져갔는지 알아보아야 한다. 주로 access_log, error_log 등은 /var/adm/httpd/logs와 같은 디렉토리에 존재하며, 이는 httpd 설치 시 사용자에 따라 설정할 수 있다. 다음은 xxx.xxx.com 으로부터 http 서버 phf 버그를 이용하여 패스워드 파일을 가져간 예이다.


- IMAPD, POPD 로그 정보 분석
다음은 최근 개인 전자우편 관련하여 많이 사용하고 있는 Imapd(Popd)를 이용하는 방법이다. 이 방법은 데몬에 많은 데이터를 보내 버퍼오버플로우를 발생시켜 새로운 쉘(Shell)을 실행하는 방법으로써 /var/adm/messages 파일에서 알 수 있다.

다음 사례는 xxx.xxx.198.78 호스트에서 시스템의 Imapd로 접근한 내용을 보여주고 있다.


아래 표에서는 위에서 언급한 해킹 방법들로 해커들이 공격했을 경우에 어떠한 시스템 로그나 서버 로그를 점검해야 하는지를 요약해 놓았다.

해킹 방법	utmp wtmp	access_log	messages	news log	su log	secure log	spooler log	syslog	비고
SPAM relay								O
popd			O			O
imapd			O			O
named			O
innd				O			O
identd			O
phf/php 등 CGI		O
portscan									모니터링
mscan			O
su 시도			O		O
원격 login 시도	O		O			O
원격 ftp 시도	O		O			O
서비스 거부									모니터링

2.2 공격자 관점에서의 분석
시스템 관리자 관점에서 분석한 침해사고의 시스템 점검을 통해 얻어지는 결과물에 대해서도 얻을 것이 많지만 경험이 많은 침입자의 경우 일반적으로 로그들은 삭제하고 가는 일이 많기 때문에 해커의 관점에서 시스템 침입시 하는 행동들을 예측하고 그 흔적을 알아내어 시스템이 남기는 정상적인 로그 이외의 해킹 흔적들을 찾아야 한다.

■ 트로이 목마(trojan horse)와 백도어 프로그램 점검
백도어 프로그램이란 일명 뒷구멍이라고 해서 해커들이 임의의 시스템을 해킹한 후 해킹한 시스템에 흔적 없이 다시 들어오려할 때 주로 사용한다. 해커들이 설치하는 프로그램은 원격 접근을 위한 백도어 프로그램 뿐 아니라 내부 사용 흔적을 감추기 위해서, 또는 일반 사용자가 쉽게 관리자(root)가 되기 위해서 기존 프로그램과 이름은 동일하지만 프로그램 내부동작은 침입자의 의도를 만족하는 기능을 갖게 된다.

다음은 실제 해킹을 당한 피해 시스템을 점검하면서 발견된 사례를 보도록 하자.

- .rhosts, /etc/hosts.equiv 백도어 프로그램


- 백도어로 이용된 서버데몬(inetd 이용)
- 시스템 분석 시 발겨된 백도어 프로그램 구성 사례
해커들은 백도어 프로그램이 숨겨야 할 정보들을 다음과 같은 구성 파일을 만들어 저장하기도 한다. 물론 이 구성 파일은 관리자나 사용자가 찾기 어려운 위치에 만든다.


- ps 명령에서 감추고 싶은 파일들을 등록
[Test: /]more ps.
2 .linsniffer
2 pepsi
2 smurf

- 발견된 트로이 목마 쉘(Trojaned Shell)백도어
rc 파일이나 .cshrc, .profile 파일에 백도어용 코드를 삽입하고, 쉘을 숨겨놓는다.



- /etc 디렉토리에 위치한 쉘

■ 백도어 디렉토리 점검
해커들은 자신이 공격한 시스템에 백도어를 유지하거나 새로운 공격을 시도하기 위하여 일반적인 방법으로는 보이지 않는 디렉토리를 생성한다. 숨겨져 있는 디렉토리를 찾이 위해서는 우선 해커들의 손이 닿지 않은 깨끗한 "ls" 프로그램이 필요하다. 숨겨져 있는 디렉토리는 스페이스 문자나 탭키, ... 등 특수키의 혼용으로 일반적인 "ls" 명령으로는 잘 보이지가 않는다.

전체 파일 시스템에 대하여 find 명령을 이용한 스크립트를 작성하여 백도어 디렉토리를 찾는다. 주로 파일 개수가 아주 많거나 사용자가 자주 이용하지 않는 위치에 백도어 디렉토리가 존재한다.
[Test: /]ls /var/spool/at/spool/.h/
exploits pen regs.h~ ts2
ipw.c reg.tgz screen ts2.c
ircbnc.c regq.h~ screen-3.7.4.tar.gz tt
login regr.h~ ssh-1.2.20 web

■ 각종 서버 원격 취약점 점검
호스트에 서버(데몬)로 인하여 해커들은 침입의 발판되므로 모든 서버들에 대하여 해커들의 원격 침입이 있었는지 알기 위해 관리자는 취약성 여부를 확인한 후 해킹 가능성을 추측할 수 있다. 시스템의 messages 로그는 주요 서버들의 접근 흔적을 따로 유지하고 있다.


- <popd/imapd>


- <statd>


- <httpd>

오늘 학과 내에 서버실에 위치한 HP BladeServer를 오랜만에 콘솔로 들어왔다.

지금은 아무것도 안하는 서버지만, 뭔일이 있었나? 싶어서 Log를 출력해 보았다.

헏!

/var/log에 있는 secure 파일을 cat을 이용해 살펴본 결과!




내가(webdizen) 접속 하기 전까지 누군가가 지속적으로 접속을 시도하고 있었다.

좀 더 자세한 리스트를 출력해 보기 위해 grep을 이용해 봤다.





무차별로 돌리는 것 같은데...;

일반적인 ID들로 시도를 해온다.

test, db, guest, barbara 말고도 화면을 위로 올리면 엄청나게 많다;;

어디서 접근해 오는 건지 어떻게 알아내야 할까?

추적이 힘들거 같고, 한번 traceroute 명령어를 쳐봤다.




도대체 누굴까? ㅎㅎ

HP BladeServer에 5개가 들어가 있는데...

5대 모두 저런 현상이...;;

결론은 역으로 추적해 보고 싶으면, 열심히 네트워크 공부 해야겠다.