Tag Archives: psad

11.psad와 fwsnort의 결합

Posted on by
Reply

 * fwsnort 탐지와 psad 동작의 결합

 fwsnort는 공격을 탐지하면 iptables 로그 메시지를 생성한다. 이 메시지는 사용자에게 해당 로그 메시지를 촉발한 스노트 규칙 ID, fwsnort 체인내의 규칙 번호, 패킷이 수립된 TCP 세션의 일부인지 여부를 알려주는 로그 접두어를 포함한다.

 ** WEB-PHP Setup.php access 공격

 스노트 규칙 ID 2281은 미디어위키 소프트웨어(원래는 위키피디아를 보조하기 위해 설계된 소프트웨어다. http://en.wikipedia.org/wiki/Mediawiki 참조)의 입력 확인 취약점을 공격하려는 시도를 탐지하게 설계됐다. 이 취약점은 Bugtraq ID 9057에서 기술하고 있으며, 스노트 규칙 ID 2281은 이를 WEB-PHP Setup.php access 공격이라고 명명한다. 이 취약점을 성공적으로 공격하면 목표 시스템이 HTTP 요청 내의 특별히 구성된 URI 매개변수를 수신할 때 목표 시스템에서 승인 받지 않은 원격 코드를 실행할 수 있다. 내부 웹서버에 대해 WEB-PHP Setup.php access 취약점을 공격하게 설계된 공격을 가상으로 실행해보자. seclab 시스템에는 기본 iptables 정책이 배치돼 있으며, 가상 공격은 soft-ftp 시스템에서 수행한다고 가정한다.

 우선 텍스트 기반 웹 브라우저인 링크스(lynx)를 사용해서 seclab 시스템에서 iptables 방화벽을 통해 webserver로 웹 연결을 생성할 수 있는지 확인하자.

# lynx http://seclab.x.x.kr


 iptables 방화벽을 통한 웹 연결성을 확인했으니 공격에 대해 예상할 수 있는 응답을 보기 위해 fwsnort psad를 배치하기 전에 가상 공격을 수행해보자. 우선 Bugtraq ID 9057 취약점을 공격하려는 시도를 탐지하게 설계된 스노트 규칙 ID 2281은 다음과 같다.(원래 책에는 /etc/fwsnort/snort_rules/emerging-all.rules 파일에 적혀있다고 하였으나, 이상하게 필자의 서버에서는 그 내용을 찾을 수가 없었다. 그래서 아래와 같이 따로이 제일 마지막 라인에 해당 규칙을 기술해넣었다.)

 문자열 /Setup.php만 제외하면 위의 규칙은 웹서버로부터 요청된 URI 매개변수의 내용(이는 공격자가 달성하고자 하는 것에 따라 달라질 수 있다)을 신경쓰지 않는다. 이 서명은 웹 요청의 URI 부분에서 문자열 /Setup.php 를 엄격히 검색하며, 이 데이터는 flow 키워드에서 요구하는 대로 수립된 TCP 연결에서 보여야 한다. 이 덕분에 다음과 같이 취약점에 대한 가상 공격이 매우 시워진다.

soft-ftp:~# lynx http://seclab.X.X.kr/Setup.php

                                                                  404 Not Found

                                   Not Found

   The requested URL /Setup.php was not found on this server.
     _________________________________________________________________

    Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.5 with Suhosin-Patch
    Server at seclab.kongju.ac.kr Port 80

 위로부터 내부 웹서버가 취약하지 않다는 것을 알 수 있으며(내부 웹서버는 미디어위키를 실행하고 있지 않다) 예상대로 요청된 페이지가 존재하지 않는다는 것을 의미하는 404 Not Found 오류를 돌려받는다. 가상 공격을 수행하고 있다는 점을 기억하자. 가상 공격에서는 스노트 서명이 찾고자 하는 것처럼 보이는 네트워크 트래픽만 생성하면 된다.

 – fwsnort 를 이용한 공격 탐지

 이제 iptables로 WEB-PHP Setup.php access 공격을 탐지하기 위해 (일단은) –ipt-drop 이나 –ipt-reject 인자 없이 fwsnort를 실행하자.


 /etc/fwsnort/fwsnort.sh 스크립트를 살펴보면 수립된 TCP 연결에서 /Setup.php 문자열을 탐지하기 위해 문자열 매칭 확장과 맞춤화 FWSNORT_FORWARD_ESTAB 체인을 탐지하기 위해 문자열 매칭 확장과 맞춤화 FWSNORT_FORWARD_ESTAB 체인을 사용하는 iptables 명령을 볼 수 있다. 이 명령은 아래와 같으며, 공격을 탐지하기 위해 상당한 연산을 수행한다.

$IPTABLES -A FWSNORT_FORWARD_ESTAB -p tcp –dport 80 -m string –string “/Setup.php” –algo bm -m comment –comment “sid:2281; msg:WEB-PHP Setup.php access; classtype:web-application-activity; reference:bugtraq,9057; rev:2; FWS:1.0.5;” -j LOG –log-ip-options –log-tcp-options –log-prefix “[1] SID2281 ESTAB “
$IPTABLES -A FWSNORT_INPUT_ESTAB -p tcp –dport 80 -m string –string “/Setup.php” –algo bm -m comment –comment “sid:2281; msg:WEB-PHP Setup.php access; classtype:web-application-activity; reference:bugtraq,9057; rev:2; FWS:1.0.5;” -j LOG –log-ip-options –log-tcp-options –log-prefix “[1] SID2281 ESTAB “

 굵게 나타낸 부분이 iptables 로그 접두어이다. 이 접두어를 통해 iptables 로그 메시지에서 해당 규칙의 실행 여부를 확인할 수 있다. 이제 다시 공격 트래픽을 생성해보자. 공격 트래픽 생성 후, 아래의 로그 메시지를 얻을 수 있을 것이다.

Jul 11 05:30:13 seclab kernel: [4540091.006611] [1] SID2281 ESTAB IN=eth0 OUT= MAC=00:21:5e:4e:bb:da:00:11:88:42:99:43:08:00 SRC=X.X.X.X DST=Y.Y.Y.Y LEN=414 TOS=0x00 PREC=0x00 TTL=62 ID=44542 DF PROTO=TCP SPT=47966 DPT=80 WINDOW=365 RES=0x00 ACK PSH URGP=0 OPT (0101080A2FED6AD91B0F2BDB)

 – psad를 이용한 경고

 fwsnort는 공격을 탐지했지만 iptables로부터 로그 메시지만 생성했다. fwsnort는 whois 검색이나 메일 경고 전송 등의 기능을 가지고 있지 않기 때문에 이를 수행하지 않았다.

 그러나 fwsnort가 iptables 로그 메시지를 생성하기 때문에 psad가 이를 분석한 후, 해당 이벤트에 자신의 경고와 보고 기능을 적용할 수 있다. 그러나 우선 psad는 fwsnort 로그 메시지를 적절히 처리해야 한다. 이 메시지는 애플리케이션 계층 데이터의 검사를 통해 생성된 것이지만 결국 데이터 자체는 로그 메시지에 포함되지 않는다.

 로그 메시지를 해석하는 데 중요한 것이 /etc/psad/psad.conf 파일의 SNORT_SID_STR 변수다. 이 변수는 psad가 로그 메시지 fwsnort에 의해 생성됐다는 것을 유추하기 위해 봐야 할 로그 접두어 부분을 기술한다. 기본적으로 SNORT_SOD_STR은 다음과 같이 설정된다.


 로깅 접두어에 부분 문자열 SID를 포함하는 iptables 로그 메시지는 fwsnort가 생성한 메시지로 거의 항상 애플리케이션 계층 공격에 대한 것이다.

 이제 psad를 확실해 실행하고(/etc/init.d/psad start 를 실행) 가상 공격을 다시 한 번 수행하자. 이번에는 psad 가 iptables 로그 메시지를 가로채서 구문 분석한 후 아래와 같은 메일 경고를 생성한다.

=-=-=-=-=-=-=-=-=-=-=-= Sun Jul 11 05:30:23 2010 =-=-=-=-=-=-=-=-=-=-=-=

         Danger level: [5] (out of 5)

    Scanned TCP ports: [80: 1 packets]
            TCP flags: [ACK PSH: 1 packets]
       iptables chain: FWSNORT_INPUT_ESTAB (prefix “[1] SID2281 ESTAB”), 1 packets
         fwsnort rule: 1

               Source: X.X.X.X
                  DNS: [No reverse dns info available]
             OS guess: SunOS:4.1::SunOS 4.1.x

          Destination: Y.Y.Y.Y
                  DNS: seclab.kongju.ac.kr

   Overall scan start: Thu Jul  1 23:50:42 2010
   Total email alerts: 23
   Complete TCP range: [1-65301]
      Syslog hostname: seclab

         Global stats: chain:   interface:   TCP:   UDP:   ICMP: 
                       INPUT    eth0         11182  0      0     

[+] TCP scan signatures:

   “MISC xfs communication attempt”
       dst port:  7100 (no server bound to local port)
       flags:     SYN
       sid:       1987
       chain:     INPUT
       packets:   2
       classtype: misc-activity

   “MISC Radmin Default install options attempt”
       dst port:  4899 (no server bound to local port)
       flags:     SYN
       psad_id:   100204
       chain:     INPUT
       packets:   2
       classtype: attempted-admin

   “WEB-PHP Setup.php access”
       dst port:  80 (no server bound to local port)
       flags:     ACK PSH
       content:   “/Setup.php”
       sid:       2281
       chain:     FWSNORT_INPUT_ESTAB
       packets:   1
       classtype: web-application-activity

=-=-=-=-=-=-=-=-=-=-=-= Sun Jul 11 05:30:23 2010 =-=-=-=-=-=-=-=-=-=-=-=

 위의 psad 메일 경고가 보통 psad가 생성하는 메일 경고라고 생각하면 되며, 여기에는 타임 스탬프, 패킷 수, TCP 플래그와 포트 등과 같은 표준 정보가 모두 포함된다.

 iptables 그 자체로는 LOG 타겟을 통해 패킷의 실제 내용을 보고하는 기능을 가지지 않으며, 접두어 문자열 길이는 29글자로 제한되기 때문에 일반적으로 단순히 로그 접두어에 내용 문자열을 포함시키는 것이 합당하다. syslog 메시지에 바이너리 패킷 데이터를 포함시키는 것 역시 좋은 생각이 아니다.

 * 다시 보는 능동적 응답

 ** psad와 fwsnort

 psad는 공격이 탐지되면 공격자에 대해 영속적인 시간 만료 기반 iptables 차단 규칙을 인스턴스화 할 수는 있지만 스스로 연결을 종료시키거나 애플리있케이션 계층 서명과 매칭되는 첫 번째 패킷이 전달되는 것을 막지는 못한다.한편 fwsnort의 경우 악의적인 패킷이나 세션을 개별적으로 무력화하기 위해 DROP이나 REJECT 타겟을 사용할 수는 있지만 일정 기간 동안 공격자를 차단하는 새로운 iptables 규칙을 생성하지는 못한다.

 각 도구의 강점을 고려하면 두 응답 방식을 결합하는 것이 좋다는 것을 알 수 있다. 결국 fwsnort는 특정 TCP 세션에 포함된 특정 공격을 탐지하고 저지하는 데 우수할 수 있지만 영속적인 차단 규칙을 관리하기 위한 psad가 없다면 공격자는 동일한 목표에 다른 공격을 자유롭게 시도할 수 있다. 첫 번째 공격 시도를 탐지했던 동작이 꽤 행운이었을 수 있으며, 다음 공격 시도는 전혀 탐지하지 못할 수도 있다. 이 때문에 차단 규칙이 중요하다. 공격자가 첫 번째 공격과 무관하며 서명도 존재하지 않는 취약잠에 대한 추가적인 공격을 가지고 있는 경우 특히 그렇다. 또 공격자가 TCP 서비스를 공격할 때 Tor 익명화 네트워크(http://tor.eff.org)를 사용하면 공격은 매번 다른 출구 라우터(Tor 가 각 TCP 세션마다 무작위로 선택한다)에서 오는 것처럼 보이기 때문에 개별적인 IP 주소를 차단하는 것은 의미가 없다.

 다시 한 번 이야기하자면 능동적 응답 기법을 잘 아는 능숙한 공격자는 이 기능이 목표 네트워크에 반하게 만들기 위해 이를 전복하려고 할 수도 있다. 또 공격자가 공격을 수행할 다수의 호스트를 제어하는 경우(공격자 사이에서는 개인이 봇넷[botnet]을 구성하기 위해 여러 호스트를 제어하는 것이 보통이다) 공격자는 목표를 공격하는데 아직 사용하지 않은 호스트로부터 새로운 공격을 수행할 수도 있다. 네트워크를 보호하려는 사람과 이를 공격하려는 사람간에는 항상 경쟁 관계가 존재하며, 이런 관점에서 공격 측이 상당한 무장을 갖추고 있다고 가정해야 한다.

 ** fwsnort가 탐지한 공격으로 psad 응답을 제한

 psad는 fwsnort가 생성한 로그 메시지에 대한 경고를 전송할 수 있다. 또 단순히 /etc/psad/psad.cnf 파일의 ENABLE_AUTO_IDS 를 Y 로 설정함으로써 psad는 fwsnort 로그 메시지에 대한 응답으로 iptables 차단 규칙을 설정할 수 있다.

 fwsnort에 의해 탐지된 공격이 psad 에 의해 공격자에게 할당된 위험 수준을 AUTO_IDS_DANGER_LEVEL 변수에 설정된 값보다 크게 하면 psad는 공격자의 IP 주소에 대해 자유재량의 DROP 규칙을 인스턴스화한다. 그러나 fwsnort가 공격을 기록하기 때문에 포트 스캔과 백도어를 위함 탐사도 위험 수준을 할당 받는다.

 하지만 쉽게 스푸핑되는 스캔과 탐사에 대해 psad 응답을 활성화하는 것은 위험하다. psad가 수립된 TCP 연결을 통한 애플리케이션 계층 데이터를 수반해야 하는 공격에만 응답하고 다른 유형의 공격에는 어떤 조치도 취하지 않게 하는 것이 좋다.

 AUTO_BLOCK_REGEX 변수는 대응되는 iptables 로그 메시지가 정규식과 매칭할때만 psad가 IP 주소 차단을 수행하게 강제하는 정규식을 포함한다. AUTO_BLOCK_REGEX의 기본 값은 문자열 ESTAB며, 이는 수립된 TCP 연결에 속하는 패킷과만 매칭하게 설계된 맞춤화 체인 중 하나에 의해 기록된 fwsnort 로그 메시지와 매칭된다. 이 기능을 활성화하려면 psad 설정 파일에서 ENABLE_AUTO_BLOCK_REGEX 변수를 Y로 설정해야 한다.

 psad 가 공격자를 방화벽에 접근할 수 없게 하려면 fwsnort를 실행하고 AUTO_BLOCK_REGEX 기능을 활성화해야 한다. 포트 스캔이나 기타 쉽게 스푸핑 가능한 트래픽에 응답하는 것은 너무나 쉽게 악용될 수 있다.

10.fwsnort 배치

Posted on by
Reply

 * fwsnort 설치

 psad와 마찬가지로 fwsnort 도 인스톨 프로그램 install.pl과 함께 제공된다. 이 프로그램은 이전에 설치된 fwsnort 의 설정 보존, 두 개의 펄 모듈 설치(Net::IPv4Addr와 IPTables::Parse), 최신 블리딩 스노트 서명 집합의 (선택적인) 다운로드(http://www.bleedingsnort.com 에서 받음)를 포함해서 설치의 모든 것을 처리한다.

 우분투/데비안의 경우 다음의 apt-get 을 이용한 설치가 가능하다.

 # sudo apt-get install fwsnort

단, fwsnort 사용을 위해서는 iptables 문자열 매칭 기능을 사용할 수 있어야 한다. 커널 버전 2.6.14 나 그 이후 버전을 사용 중이라면 커널 내부에 이미 문자열 매칭이 컴파일 돼 있을 것이다.

 만약 iptables 의 문자열 매칭기능의 지원여부를 확인하고 싶다면 아래의 명령어가 이상없이 작동하면 지원하는 것이다.

 # iptables -D INPUT 1 -i lo -d 127.0.0.2 -m string –string “testing ” –algo bm -j ACCEPT

 만약 오류 iptables: no chain/target/match by that name 가 반환되면 현재 커널에서 문자열 매칭 확장을 사용할 수 없는 것이다. 이는 커널 설정 파일의 CONFIG_NETFILTER_XT_MATCH_STRING 를 활성화하고 재컴파일한 후 새 커널로 재부팅함으로써 수정할 수 있다.

 만약 위의 명령이 성공적으로 실행 되었다면, 다시 해당 규칙을 삭제하여 추후 다른 문제가 발생하지 않도록 하자.

 # iptables -D INPUT 1

 * fwsnort 의 실행

 fwsnort 의 설치가 끝났다면 이제 fwsnort 를 실행하도록 하자.

 커맨드 라인에서 바로 fwsnort 를 입력해도 되고, 만약 명령어 실행이 되지 않는다면, /usr/sbin/fwsnort 를 실행하도록 하자.


 fwsnort 실행 후, 나오는 메시지로부터 각 스노트 규칙 파일에 대해서 성공적 변환과 변환 실패 획수(Success 와 Fail), 실행 중인 iptables 정책에 적용되는 규칙의 수(Ipt_apply), 규칙 파일에 존재하는 전체 스노트 규칙 개수(Total)를 출력한다는 것을 알 수 있다.

 그리고 fwsnort 의 두 설정파일에 관한 정보를 확인할 수 있다.

 ** fwsnort 설정 파일

 fwsnort 의 주요 설정 파일은 /etc/fwsnort/fwsnort.conf 는 네트워크, 포트 번호, 시스템 바이너리의 경로(iptables 로의 경로 등), 실행에 필요한 기타 주요 정보를 정의한다.

 다음은 실제로 사용중인 fwsnort.conf 의 파일 내용이다.

root@seclab:/etc/fwsnort# cat fwsnort.conf
#
###########################################################################
#
#  This is the configuration file for fwsnort.  There are some similarities
#  between this file and the configuration file for Snort.
#
###########################################################################
#
# $Id: fwsnort.conf 442 2008-08-09 15:14:27Z mbr $
#

### Fwsnort treats all traffic directed to / originating from the local
### machine as going to / coming from the HOME_NET in Snort rule parlance.
### If there is only one interface on the local system, then there will be
### no rules processed via the FWSNORT_FORWARD chain because no traffic
### would make it into the iptables FORWARD chain.
HOME_NET                any;
EXTERNAL_NET            any;

### List of servers.  Fwsnort supports the same variable resolution as
### Snort.
HTTP_SERVERS            $HOME_NET;
SMTP_SERVERS            $HOME_NET;
DNS_SERVERS             $HOME_NET;
SQL_SERVERS             $HOME_NET;
TELNET_SERVERS          $HOME_NET;

### AOL AIM server nets
AIM_SERVERS             [64.12.24.0/24, 64.12.25.0/24, 64.12.26.14/24, 64.12.28.0/24, 64.12.29.0/24, 64.12.161.0/24, 64.12.163.0/24, 205.188.5.0/24, 205.188.9.0/24];

### Configurable port numbers
SSH_PORTS               22;
HTTP_PORTS              80;
SHELLCODE_PORTS         !80;
ORACLE_PORTS            1521;

### define average packet lengths and maximum frame length.  This is
### used for iptables length match emulation of the Snort dsize option.
AVG_IP_HEADER_LEN       20;   ### IP options are not usually used.
AVG_TCP_HEADER_LEN      30;   ### Include 10 bytes for options (which
                              ### accompany ACK packets).
MAX_FRAME_LEN           1500;

### Use the WHITELIST variable to define a list of hosts/networks
### that should be completely ignored by fwsnort.  For example, if you
### want to whitelist the IP 192.168.10.1 and the network 10.1.1.0/24,
### you would use (note that you can also specify multiple WHITELIST
### variables, one per line):
#WHITELIST             192.168.10.1, 10.1.1.0/24;
WHITELIST               NONE;

### Use the BLACKLIST variable to define a list of hosts/networks
### that for which fwsnort should DROP or REJECT all traffic.  For
### example, to DROP all traffic from the 192.168.10.0/24 network, you
### can use:
###     BLACKLIST            192.168.10.0/24    DROP;
### To have fwsnort REJECT all traffic from 192.168.10.0/24, you would
### use:
###     BLACKLIST            192.168.10.0/24    REJECT;
BLACKLIST               NONE;

### define the jump position in the built-in chains to jump to the
### fwsnort chains
FWSNORT_INPUT_JUMP      1;
FWSNORT_OUTPUT_JUMP     1;
FWSNORT_FORWARD_JUMP    1;

### iptables chains (these do not normally need to be changed).
FWSNORT_INPUT           FWSNORT_INPUT;
FWSNORT_INPUT_ESTAB     FWSNORT_INPUT_ESTAB;
FWSNORT_OUTPUT          FWSNORT_OUTPUT;
FWSNORT_OUTPUT_ESTAB    FWSNORT_OUTPUT_ESTAB;
FWSNORT_FORWARD         FWSNORT_FORWARD;
FWSNORT_FORWARD_ESTAB   FWSNORT_FORWARD_ESTAB;

### fwsnort library path
FWSNORT_LIBS_DIR        /usr/lib/fwsnort;

### system binaries
shCmd           /bin/sh;
echoCmd         /bin/echo;
tarCmd          /bin/tar;
wgetCmd         /usr/bin/wget;
unameCmd        /usr/bin/uname;
ifconfigCmd     /sbin/ifconfig;
iptablesCmd     /sbin/iptables;

 ** fwsnort.sh 의 구조

 fwsnort 가 생성한 본 쉘 스크립트 /etc/fwsnort/fwsnort.sh 는 다섯 개의 섹션으로 나뉜다. 첫 번째 섹션은 fwsnort.sh 스크립트의 목적, fwsnort.sh 를 생성하기 위해 fwsnort 에게 전달하는 명령 행 인자, fwsnort 버전을 포함하는 주석으로 구성된 헤더다.

root@seclab:/etc/fwsnort# cat fwsnort.sh|more
#!/bin/sh
#
############################################################################
#
# File:  /etc/fwsnort/fwsnort.sh
#
# Purpose:  This script was auto-generated by fwsnort, and implements
#           an iptables ruleset based upon Snort rules.  For more
#           information see the fwsnort man page or the documentation
#           available at http://www.cipherdyne.org/fwsnort/
#
# Generated with:     fwsnort
# Generated on host:  seclab.XXXXXX.ac.kr             
# Time stamp:         Thu Jul  8 00:43:59 2010
#
# Author:  Michael Rash <mbr@cipherdyne.org>
#
# Version: 1.0.5 (file revision: 472)
#
############################################################################
#

#==================== config ====================
ECHO=/bin/echo
IPTABLES=/sbin/iptables
#================== end config ==================

###
############ Create fwsnort iptables chains. ############
###
$IPTABLES -N FWSNORT_FORWARD 2> /dev/null
$IPTABLES -F FWSNORT_FORWARD

$IPTABLES -N FWSNORT_FORWARD_ESTAB 2> /dev/null
$IPTABLES -F FWSNORT_FORWARD_ESTAB

 fwsnort.sh 스크립트의 두 번째 섹션은 iptables 와 에코 시스템 바이너리의 경로를 정의한다. 이 경로들은 fwsnort.conf 설정 파일의 iptablesCmd 와 echoCmd 키워드에서 상속되며 fwsnort 는 fwsnort.sh 를 작성하기 전에 해당 경로가 존재하는지 확인한다.

 설정 섹션은 fwsnort.sh 가 배치되는 시스템에 맞게 경로를 수정할 수 있게 해준다.

#==================== config ====================
ECHO=/bin/echo
IPTABLES=/sbin/iptables
#================== end config ==================

 fwsnort.sh 의 세 번째 섹션은 fwsnort 규칙을 위한 전용 iptables 체인을 생성한다. 모든 fwsnort 규칙(아래서 다룰 건너뛰기 규칙은 예외)은 기존 iptables 정책으로부터 엄격히 분리시키기 위해 맞춤화 체인에 추가된다.

 fwsnort.sh 의 네 번째 섹션은 중량 패킷 검사가 일어나는 곳이다. 이 섹션의 규칙은 모두 앞서 언급한 fwsnort 체인 중 하나에 추가된다. 각 규칙은 출발지와 목적지 IP 주소와 포트 번호, 내용 문자열, length, ttl, tos 매칭 등과 같은 스노트 규칙 헤더와 규칙 옵션의 구성 원소를 포함한다.

 기본적으로 fwsnort 가 변환하는 모든 스노트 규칙은 사용자 특정 서명을 전달하기 위해 설계된 로깅 접두어와 함께 LOG 타겟을 사용하는 Iptables 명령을 생성한다. fwsnort 가 생성한 로깅 접두어는 fwsnort 체인의 규칙 번호와 스노트 서명 ID 값을 포함하며, 서명이 수립된 TCP 연결로부터 기록됐는지 여부를 나타낸다.

 fwsnort.sh 의 마지막 섹션에서는 iptables가 전체 규칙집합을 통해 트래픽을 전송하게 함으로써 커널 내부에서 규칙집합을 활성화한다. 이 시점까지 fwsnort.sh 에 의해 실행되는 모든 iptables 명령은 단순히 fwsnort 정책을 실행 중인 커널로 로딩한다.

 ** fwsnort 의 명령 행 옵션
 
 일반적으로 사용되는 일부 옵션에 대한 설명이며, 다른 모든 명령 행 인자에 대한 설명은 fwsnort(8) 맨 페이지에서 볼 수 있다.

 –ipt-drop: 패킷이 의도된 목표로 전달되기 전에 fwsnort 가 이를 기록하고 버리게 한다(기본적으로 fwsnort 는 악의적인 패킷을 기록만 하게 한다). 이를 통해 fwsnort 는 네트워크 공격에 능동적으로 응답할 수 있는 권한을 얻는다.

 –ipt-reject: fwsnort 가 악의적인 TCP 연결을 TCP 재설정 패킷으로 종료시키고 악의적인 UDP 트래픽에 ICMP 포트 도달 불가 메시지로 응답하기 위해 REJECT 타겟을 사용하는 iptables 정책을 만들게 한다.

 –snort-conf path: fwsnort가 HOME_NET, EXTERNAL_NET, HTTP_SERVERS 등과 같은 변수를 기존의 스노트 설정 파일(보통 /etc/snort/snort.conf에 위치)로부터 읽어오게 한다.

 –snort-sid sids: fwsnort 변환 시도를 특정 스노트 ID나 스노트 ID 목록으로 제한한다.

 –include-type type: fwsnort 가 하나의 규칙 파일에 포함된 스노트 규칙만을 변환하게 한다.

 –ipt-list: 다양한 fwsnort 체인의 활설화된 규칙을 모두 보여준다.

 –ipt-flush: fwsnort 체인에서 활성화된 규칙을 모두 버린다. 이 옵션은 기존 정책과 연관된 iptables 규칙은 제거하지 않고 fwsnort 규칙을 빠르게 제거할 때 유용하다.

 –no-address: fwsnort가 방화벽 시스템의 인터페이스가 가지는 IP 주소를 참조하지 않게 한다.

 –no-ipt-sync: 로컬 iptables 정책에 대해 보통 실행되는 모든 호환성 검사를 fwsnort가 비활성화게 한다..

 –restrict-intf intf: fwsnort 규칙을 명시된 인터페이스(들)로 제한한다.

 * fwsnort의 실제 동작

 fwsnort의 실행은 간단하다. fwsnort 명령어의 결과로 생성된 /etc/fwsnort/fwsnort.sh 스크립트를 실행시키면 된다.

 …..시스템에 따라 시간이 오래 걸릴 수 있으니 느긋한 마음을 가지는 것이 좋을 것이다.

 * 허용 목록과 차단 목록 설정

 애플리케이션 계층 데이터에 기반해서 네트워크 통신을 차단할 수 있는 소프트웨어는 허용 목록(whitelist)에 기반해서 특정 네트워크나 IP 주소를 차단 동작에서 제외할 수 있어야 한다.

 fwsnort 에서 허용 목록과 차단 목록은 /etc/fwsnort/fwsnort.conf 파일의 WHITELIST와 BLACKLIST 변수를 통해 지원된다. 예를 들어 fwsnort 가 웹서버(192.168.10.2)에서 시작하거나 웹서버로 향하는 통신에는 어떤 조치도 취하지 않고 IP 주소 192.168.10.100 으로 오가는 모든 패킷을 DROP 하게 하려면 fwsnort.conf 에 다음을 추가한다.

 WHITELIST 192.168.10.2;
 BLACKLIST 192.168.10.100;

8.psad를 이용한 능동적 응답

Posted on by
Reply

 * 침입 방지와 능동적 응답

 오늘날 나와 있는 다양한 보안 제품, 기술, 솔루션에서 침입 탐지라는 용어는 큰 주목을 받아왔다. 이러한 주목의 대다수는 이 용어가 주는 지나치게 강한 의미에서 나온것으로 보인다. 물론 보안 침부를 사전에 방지한다는 개념 자체가 장점이 없다는 뜻은 아니다. 다만 침입 탐지 기술은 호스트 수준 스택 강화 기법(http://pax.grseurity.net 의 PaX 프로젝트 참조)에서부터 악의적인 패킷이 의도된 목표에 도달하지 못하게 방지하는 동시에 다른 트래픽은 모두 통과시킬 수 있는 소프트웨어를 갖춘 인라인 네트워크 장치까지 다양하다.

 이와 달리 능동적 응답은 (공격이 탐지된 경우) 공격자에게 취할 수 있는 기법들을 말하며 이것이 꼭 공격을 무력화하는 기법만을 의미하는 것은 아니다. 능동적 응답이 항상 초기 공격을 막을 수 없다는 사실이 중요한 차이며, 이것이 침입 방지와 능동적 응답 간의 차이점을 명확히 서술해준다.

 * 능동적 응답의 트레이드오프

 세션 파괴(session-busting) 트래픽을 생성하거나 방화벽 정책을 수정해서 공격에 자동으로 응답하는 것에는 결과가 따른다. 공격자는 목표 시스템과의 TCP 세션이 종료되는 중이라거나 목표 시스템과의 모든 연결이 끊어졌다는 것을 재빨리 알아챌 수 있다. 이로부터 이끌어 낼 수 있는 가장 논리적인 결론은 특정 유형의 능동적 응답기법이 목표를 보호하기 위해 설치됐다는 것이다. 능동적 응답 시스템이 포트 스캔이나 포트 스윕과 같이 상대적으로 악의가 없는 트래픽에 응답하게 설정됐다면 공격자가 응답 기법을 남용해서 이것이 목표 시스템에 반하게 바꾸는 것은 매우 쉬워진다. 이는 목표와의 양방향 통신을 필요로 하지 않는 방식으로 전달될 수 있는 악의적인 트래픽(즉, 공격이 스푸핑될 수 있는 경우)에도 적용되며 위티 웜이 바로 그 예다.

 – 공격의 종류
 능동적인 응답 기능을 제공하는 많은 소프트웨어(psad 포함)가 특정 호스트나 네트워크를 허용 리스트(whitelist)에 추가하는 기능을 제공한다. 이는 공격자가 허용 리스트에 속한 네트워크로부터 포트 스캔이나 기타 악의적인 트래픽을 스푸핑하더라도 응답 기법이 아무런 조치를 취하지 않게 하기 위함이다. 그러나 소프트웨어 관리자가 이 목록에 중요한 시스템을 모두 포함시키지 않을 수 있으므로 공격자는 자신의 창의력에 따라 공격을 송공할 수 있다. 심지어 TCP 유휴 스캔조차 올바로 동작하려면 스캔이 스푸핑돼야 한다.

 공격에 응답하는 좀 더 나은 전략은 공격자와 목표 사이에 양방향 통신을 필요로하는 공격에만 응답하게 응답 기법을 활성화하는 것이다. 이는 일반적으로 공격자가 TCP 연결을 수립했고 공격(웹 애플리케이션에 대한 SQL 인젝션 공격이나 TCP 포트에서 대기중인 애플리케이션에서 버퍼 오버플로우 취약점을 통해 목표 시스템이 쉘 코드를 실행하게 강제하려는 시도)을 전달하는 데 수립한 TCP 연결을 사용 중이라는 것을 의미한다.

 수립된 TCP 연결에서 공격을 탐지하려면 탐지 시스템이 수립된 연결에 대한 표를 유지하면서 이미 수립된 연결들 내에서 공격을 찾아야 한다. 실제처럼 보이는 순서 번호와 승인 번호를 가지는 TCP 패킷도 결국 스푸핑될 수 있지만 이런 패킷은 실제로 수립된 연결의 일부가 아니며 스푸핑 성공 여부는 이를 결정하는 탐지 기법에 달려있다.

 – 긍정오류
 침입 탐지 시스템은 어떤 것이든 모두 긍정 오류(정상적인 활동을 악의적인 것으로 잘못 판단하는 경고)를 생성하기도 한다. 부정 오류나 실제 악의적인 트래픽이 존재할 대 이벤트를 생성하지 못하는 것 역시 상대적으로 흔한 일이다.

 psad도 이 규칙에 예외가 아니며 psad를 실행하다 보면 정상적인 트래픽에 대해 이벤트를 생성하는 경우를 볼 수 있다. 긍정 오류는 주의 깊게 설정해서 최소화할 수 있지만 완전히 제거할 수는 없다. 그러므로 악의적이라고 잘못 판단된 트래픽에 자동으로 응답하는 것은 일반적인 네트워크 연결성을 유지하는 데 좋지 않다.

 그럼에도 여전히 많은 보안 관리자가 어떤 유형의 이벤트는 그것이 잘못 식별된 활동으로부터 생성된 것이라 할지라도 엄격하게 응답할 만큼 충분히 잠재적으로 위험하다고 판단한다. 예를 들어 새로운 웜의 출현이 네트워크와 구성 시스템을 완전히 무력화할 수 있으므로 이런 웜에 감열될 가능성이 존재하는 한 피해를 최소화하는 시도로 능동적 응답을 사용할 수 있다.

 * psad를 이용해 공격에 응답하기
 psad가 공격에 응답하는데 사용하는 주요 방법은 설정 가능한 시간 동안 공격자의 출발지 IP 주소로부터의 모든 접속을 차단하게 로컬 필터링 정책을 동적으로 재설정하는 것이다.

 Tcpwrappers 에 대한 노트
 psad도 tcpwrappers 가 공격자의 출발지 IP 주소로부터의 접근을 부인하게 /etc/hosts.deny 파일을 재설정할 수도 있다. 그러나 이 기법은 몇 가지 이유에서 iptables를 사용하는 것보다 안 좋다. 우선 tcpwrappers 는 tcpwrappers 를 사용하게 설정된 데몬으로의 접근만 차단할 수 있다. 이와 달리 iptables 의 일반적인 차단 규칙은 공격자가 목표 시스템의 IP 스택을 통한 통신을 전혀 수행할 수 없게 한다. 둘째로, tcpwrappers 는 로컬 시스템에서 실행 중인 데몬을 보호하는 데에만 효과적인 반면 psad는 FORWARD 체인의 스캔이나 기타 악의적인 트래픽도 탐지할 수 있다. 끝으로 tcpwrappers 로 데몬을 보호하는 경우 공격자는 iptables와 연동할 수 있는 방법보다 훨씬 더 많은 방법으로 목표 시스템과 연동할 수 있으며, 이 중에서 어떤 것(커널과 사용자 공간 중 어디에 있는 것이든)이라도 보안 취약점을 가질 가능성이 존재한다.

로컬 iptables 정책을 동적으로 재설정하는 기능은 응답이 네트워크 계층에서 일어난다는 것을 의미한다. 예를 들어 공격자의 IP 주소는 IP 스택을 통한 통신을 못하게 차단된다. 차단 규칙이 인스턴스화될 때 공격자가 로컬 네트워크의 서버 중 하나와 수립된 TCP 세션을 가지고 있다면 (차단 규칙과 함께 생성된 TCP 재설정이 없기 때문에) 모든 TCP 패킷은 버려질 것이며, 말단 TCP 스택은 시간 만료 때까지 재전송을 시도할 것이다.

 ** 기능

 psad는 다음과 같은 능동적 응답 기능을 지원한다.

 – iptables 차단 규칙이 추가되기 전에 공격자가 도달해야 하는 사용자 설정 가능 최소 위험 수준
 – 설정 가능한 시간 만료에 기반해서 영속적이거나 일시적인 차단 규칙을 생성하는 기능
 – 기존의 로컬 시스템 iptables 정채고가 충돌하지 않게 모든 차단 규칙에 별도의 iptables 체인을 사용하는 기능
 – psad나 시스템 재시작 사이에도 차단 규칙을 보존하는 기능(이 기능은 설정 가능하지만 기본 설정은 psad가 시작할 때 기존의 차단 규칙을 모두 버리는 것)
 – 현재 차단된 모든 IP 주소의 상태 출력을 관련 iptables 차단 규칙이 제거될 때까지 남은 초와 함께 포함하는 기능
 – 외부 프로세스가 –fw-block-ip 와 –fw-rm-block-ip 명령 행 인자를 사용해서 psad에게 특정 IP 주소에 대한 차단 규칙을 추가하거나 제거하게 지시할 수 있는 기능
 – psad 차단 체인에서 IP 주소가 추가되거나 삭제될 때 메일로 통지하는 기능

 ** 설정 변수
 psad가 능동적 응답 모드에 진입할지 여부를 결정하는 가장 중요한 변수는 ENABLE_AUTO_IDS 로 /etc/psad/psad.conf 파일에서 Y이나 N으로 설정할 수 있다. 이 기능이 활성화되면 다른 일부 변수는 psad가 공격자를 자동으로 차단하려고 할 때 psad의 다양한 동작을 제어한다.

 AUTO_IDS_DANGER_LEVEL 변수는 차단 규칙이 인스턴스화되기 전에 IP 주소가 도달해야 할 최소 위험 수준에 대해 1 ~ 5 의 임계치를 설정한다. 포트 스캔 임뎨치, 개별적인 서명 위험 수준(/etc/psad/signatures 참조), 자동 위험 수준 할당(/etc/psad/auto_dl 참조)을 조절함으로써 psad는 IP 주소를 자동으로 차단할지에 대해 세밀한 결정을 내릴 수 있다. 예를 들어 특정 IP 주소나 네트워크(예를 들어 192.168.1.0/24)가 과거의 스캔이나 침입 시도로 인해 공격자로 알려져 있다면 /etc/psad/auto_dl 파일에 다음을 추가해서 이 주소와의 통신을 억제한 상태로 유지할 수 있다

 192.168.1.0/24     5;

이제 192.168.1.0/24 클래스 C 네트워크에 속하는 모든 IP 주소는 AUTO_IDS_DANGER_LEVEL이 얼마나 높게 설정됐는지와 무관하게 필터링 정책에 위배되며 이 IP 주소에 대한 차단 규칙이 추가된다.

 일반적인 상황에서 iptables는 중요한 서비스로의 적법한 트래픽(예를 들면 DNS)을 기록하지 않게 설정되므로 iptables가 패킷을 기록하게 유발하지 않는 한 192.168.1.0/24 네트워크 내의 모든 IP 주소는 이런 서비스에 접근할 수 있다.

 AUTO_BLOCK_TIMEOUT 변수는 iptables 차단 규칙이 유효한 시간을 초로 정의한다. 기본값은 360초, 즉 한시간이다. AUTO_BLOCK_TIMEOUT을 0으로 설정하면 모든 차단 규칙이 영속적으로 유지되며 FLUSH_IPT_AT_INIT 가 비활성화돼 있지 않는 한 psad가 재시작되거나 시스템이 재부팅될 때만 제거된다.

 IPTABLES_BLOCK_METHOD와 TCPWRAPPERS_BLOCK_METHOD 변수는 psad가 공격 IP 주소를 차단하기 위해 iptables나 tcpwrappers를 사용할지 여부를 제어한다. psad를 공격에 응답하게 설정했다면 추천 설정은 iptables 차단을 활성화하는 것이다.

 ENABLE_AUTO_IDS_REGEX와 AUTO_BLOCK_REGEX 변수를 사용하면 로깅 접두어가 특정 정규식과 매칭되는지 여부와 IP 주소에 대한 차단 규칙의 추가 동작을 결합할 수 있다. 이는 수립된 TCP 세션을 통한 양방향 통신을 필요로 하는 공격을 감시한 경우의 IP 주소 차단에만 가장 유용하다. 포트 스캔은 쉽게 스푸핑되기 때문에 이 기능은 공격자에 의해 단순히 스푸핑되지 않은 IP 주소들로 차단 규칙을 제한하는 강력한 기법을 제공한다.

 끝으로 공격자를 자동으로 차단하는 데 중요한 나머지 설정 변수는 iptables 규칙이 생성되는 방식을 제어한다. 이러한 변수는 모두 IPT_AUTO_CHAIN 문자열로 시작하며 그 뒤에 정수가 나온다(DANGER_LEVEL{n} 변수와 마찬가지다). 이 변수들은 psad가 iptables에 규칙을 추가하는 방식에 7가지의 기준을 명시한다.

 – 규칙에 대한 iptables 타겟(예를 들어 DROP)
 – 규칙을 출발지나 목적지(또는 둘 모두)에 적용할지 여부
 – 규칙이 추가되는 테이블(예를 들어 filter 테이블)
 – 맞춤화 psad 체인을 위해 건너뛰기 규칙이 추가될 iptables 체인
 – iptables 체인 내에서 건너뛰기 규칙이 추가될 위치
 – 맞춤화 psad 체인의 이름
 – 맞춤화 psad 체인 내에서 새로운 규칙이 추가될 위치

 psad는 차단 규칙 자체뿐만 아니라 맞춤화 psad 체인과 건너뛰기 규칙의 생성과 유지도 관리한다.

 기본 IPT_AUTO_CHAIN{n} 변수는 psad가 AUTO_IDS_DANGER_LEVEL 임계치에 도달한 IP 주소에 대해 총 네 개의 차단 규칙을 추가하게 한다.

 – 패킷이 PSAD_BLOCK_INPUT 체인으로 건너뛰게 강제해서 로컬 시스템이 목적지인 공격자로부터의 패킷이 로컬 소켓과 통신할 수 없게 공격 IP 주소에 대한 DROP 규칙을 PSAD_BLOCK_INPUT 체인에 추가

 – 로컬 시스템에서 시작된 패킷이 공격자에게 전송될 수 없게 PSAD_BLOCK_OUTPUT 체인에 공격 IP 주소에 대한 DROP 규칙 추가

 – 공격 IP 주소에서 시작됐거나 공격 IP 주소로 전송되는 패킷을 제한하는 공격 IP 주소에 대한 두 개의 DROP 규칙을 PSAD_BLOCK_FORWARD 체인에 추가. iptables 방화벽이 이런 식으로 내부 네트워크의 시스템을 보호하면 어떤 공격자도 해당 시스템과 연결할 수 없다.

 * 능동적 응답의 예

 다음은 필자가 사용하는 psad.conf 파일의 내용이다.

#
##############################################################################
#
#  This is the configuration file for psad (the Port Scan Attack Detector).
#  Normally this file gets installed at /etc/psad/psad.conf, but can be put
#  anywhere in the filesystem and then the path can be specified on the
#  command line argument “-c <file>” to psad.  All three psad daemons (psad,
#  kmsgsd, and psadwatchd) reference this config file.
#
#  Each line has the form  “<variable name>    <value>;”.  Note the semi-
#  colon after the <value>.  All characters after the semicolon will be
#  ignored to provide space for comments.
#
##############################################################################
#
# $Id: psad.conf 2179 2008-06-07 15:21:55Z mbr $
#

### Supports multiple email addresses (as a comma separated
### list).
EMAIL_ADDRESSES             root@localhost;

### Machine hostname
HOSTNAME                    extreme;

### Specify the home and external networks.  Note that by default the
### ENABLE_INTF_LOCAL_NETS is enabled, so psad automatically detects
### all of the directly connected subnets and uses this information as
#@@ the HOME_NET variable.
HOME_NET                    any;
EXTERNAL_NET                any;

### The FW_SEARCH_ALL variable controls has psad will parse iptables
### messages.  If it is set to “Y” then psad will parse all iptables
### messages for evidence of scan activity.  If it is set to “N” then
### psad will only parse those iptables messages that contain logging
### prefixes specified by the FW_MSG_SEARCH variable below.  Logging
### prefixes are set with the –log-prefix command line option to iptables.
### Setting FW_SEARCH_ALL to “N” is useful for having psad only analyze
### iptables messages that are logged out of a specific iptables chain
### (multiple strings can be searched for, see the comment above the
### FW_MSG_SEARCH variable below) or a specific logging rule for example.
### FW_SEARCH_ALL is set to “Y” by default since usually people want psad
### to parse all iptables messages.
FW_SEARCH_ALL               Y;

### The FW_MSG_SEARCH variable can be modified to look for logging messages
### that are specific to your firewall configuration (specified by the
### “–log-prefix” option.  For example, if your firewall uses the
### string “Audit” for packets that have been blocked, then you could
### set FW_MSG_SEARCH to “Audit”;  The default string to search for is
### “DROP”.  Both psad and kmsgsd reference this file.  NOTE: You can
### specify this variable multiple times to have psad search for multiple
### strings.  For example to have psad search for the strings “Audit” and
### “Reject”, you would use the following two lines:
#FW_MSG_SEARCH               Audit;
#FW_MSG_SEARCH               REJECT;
FW_MSG_SEARCH               DROP;

### Set the type of syslog daemon that is used.  The SYSLOG_DAEMON
### variable accepts four possible values: syslogd, syslog-ng, ulogd,
### or metalog.
SYSLOG_DAEMON               syslogd;

### Danger levels.  These represent the total number of
### packets required for a scan to reach each danger level.
### A scan may also reach a danger level if the scan trips
### a signature or if the scanning ip is listed in
### auto_ips so a danger level is automatically
### assigned.
DANGER_LEVEL1               5;    ### Number of packets.
DANGER_LEVEL2               15;
DANGER_LEVEL3               150;
DANGER_LEVEL4               1500;
DANGER_LEVEL5               10000;

### Set the interval (in seconds) psad will use to sleep before
### checking for new iptables log messages
CHECK_INTERVAL              5;

### Search for snort “sid” values generated by fwsnort
### or snort2iptables
SNORT_SID_STR               SID;

### Set the minimum range of ports that must be scanned before
### psad will send an alert.  The default is 1 so that at
### least two port must be scanned (p2-p1 >= 1).  This can be set
### to 0 if you want psad to be extra paranoid, or 30000 if not.
PORT_RANGE_SCAN_THRESHOLD   1;

### If “Y”, means that scans will never timeout.  This is useful
### for catching scans that take place over long periods of time
### where the attacker is trying to slip beneath the IDS thresholds.
ENABLE_PERSISTENCE          Y;

### This is used only if ENABLE_PERSISTENCE = “N”;
SCAN_TIMEOUT                3600;  ### seconds

### If “Y”, means all signatures will be shown since
### the scan started instead of just the current ones.
SHOW_ALL_SIGNATURES         N;

### Allow reporting methods to be enabled/restricted.  This keyword can
### accept values of “nosyslog” (don’t write any messages to syslog),
### “noemail” (don’t send any email messages), or “ALL” (to generate both
### syslog and email messages).  “ALL” is the default.  Both “nosyslog”
### and “noemail” can be combined with a comma to disable all logging
### and alerting.
ALERTING_METHODS            ALL;

### By default, psad acquires iptables log data from the /var/log/psad/fwdata
### file which is written to by kmsgsd.  However, psad can just read an
### existing file that syslog writes iptables log data to (commonly
### /var/log/messages).  On some systems, having syslog communicate log data
### to kmsgsd can be problematic (syslog configs and external factors such
### as Apparmor and SELinux can play a role here), so using this feature can
### simplify a psad deployment.
ENABLE_SYSLOG_FILE          N;
IPT_WRITE_FWDATA            Y;
IPT_SYSLOG_FILE             /var/log/messages;

### When enabled, this instructs psad to write the “msg” field
### associated with Snort rule matches to syslog.
ENABLE_SIG_MSG_SYSLOG       Y;
SIG_MSG_SYSLOG_THRESHOLD    10;
SIG_SID_SYSLOG_THRESHOLD    10;

### TTL values are decremented depending on the number of hops
### the packet has taken before it hits the firewall.  We will
### assume packets will not jump through more than 20 hops on
### average.
MAX_HOPS                    20;

### Do not include any timestamp included within kernel logging
### messages (Ubuntu systems commonly have this)
IGNORE_KERNEL_TIMESTAMP     Y;

### FIXME: try to mitigate the affects of the iptables connection
### tracking bug by ignoring tcp packets that have the ack bit set.
### Read the “BUGS” section of the psad man page.  Note that
### if a packet matches a snort SID generated by fwsnort (see
### http://www.cipherdyne.org/fwsnort/)
### then psad will see it even if the ack bit is set.  See the
### SNORT_SID_STR variable.
IGNORE_CONNTRACK_BUG_PKTS   Y;

### define a set of ports to ignore (this is useful particularly
### for port knocking applications since the knock sequence will
### look to psad like a scan).  This variable may be defined as
### a comma-separated list of port numbers or port ranges and
### corresponding protocol,  For example, to have psad ignore all
### tcp in the range 61000-61356 and udp ports 53 and 5000, use:
### IGNORE_PORTS        tcp/61000-61356, udp/53, udp/5000;
IGNORE_PORTS                NONE;

### allow entire protocols to be ignored.  This keyword can accept
### a comma separated list of protocols.  Each protocol must match
### the protocol that is specified in a Netfilter log message (case
### insensitively, so both “TCP” or “tcp” is ok).
### IGNORE_PROTOCOL             tcp,udp;
IGNORE_PROTOCOLS            NONE;

### allow packets to be ignored based on interface (this is the
### “IN” interface in Nefilter logging messages).
IGNORE_INTERFACES           NONE;

### Ignore these specific logging prefixes
IGNORE_LOG_PREFIXES         NONE;

### Minimum danger level a scan must reach before any logging or
### alerting is done.  The EMAIL_ALERT_DANGER_LEVEL variable below
### only refers to email alerts; the MIN_DANGER_LEVEL variable
### applies to everything from email alerts to whether or not the
### IP directory is created within /var/log/psad/.  Hence
### MIN_DANGER_LEVEL should be set less than or equal to the value
### assigned to the EMAIL_ALERT_DANGER_LEVEL variable.
MIN_DANGER_LEVEL            1;

### Only send email alert if danger level >= to this value.
EMAIL_ALERT_DANGER_LEVEL    1;

### Treat all subnets on local interfaces as part of HOME_NET (this
### means that these networks do not have to be manually defined)
ENABLE_INTF_LOCAL_NETS      Y;

### Include MAC addresses in email alert
ENABLE_MAC_ADDR_REPORTING   N;

### Look for the Netfilter logging rule (fwcheck_psad is executed)
ENABLE_FW_LOGGING_CHECK     Y;

### Send no more than this number of emails for a single
### scanning source IP.  Note that enabling this feature may cause
### alerts for real attacks to not be generated if an attack is sent
### after the email threshold has been reached for an IP address.
### This is why the default is set to “0”.
EMAIL_LIMIT                 0;

### By default, psad maintains a counter for each scanning source address,
### but by enabling this variable psad will maintain email counters for
### each victim address that is scanned as well.
ENABLE_EMAIL_LIMIT_PER_DST  N;

### If “Y”, send a status email message when an IP has reached the
### EMAIL_LIMIT threshold.
EMAIL_LIMIT_STATUS_MSG      Y;

### If “Y”, send email for all newly logged packets from the same
### source ip instead of just when a danger level increases.
ALERT_ALL                   Y;

### If “Y”, then psad will import old scan source ip directories
### as current scans instead of moving the directories into the
### archive directory.
IMPORT_OLD_SCANS            Y;

### syslog facility and priority (the defaults are usually ok)
### The SYSLOG_FACILITY variable can be set to one of LOG_LOCAL{0-7}, and
### SYSLOG_PRIORITY can be set to one of LOG_INFO, LOG_DEBUG, LOG_NOTICE,
### LOG_WARNING, LOG_ERR, LOG_CRIT, LOG_ALERT, or LOG_EMERG
SYSLOG_IDENTITY             psad;
SYSLOG_FACILITY             LOG_LOCAL7;
SYSLOG_PRIORITY             LOG_INFO;

### Port thresholds for logging and -S and -A output.
TOP_PORTS_LOG_THRESHOLD     500;
STATUS_PORTS_THRESHOLD      20;

### Signature thresholds for logging and -S and -A output.
TOP_SIGS_LOG_THRESHOLD      500;
STATUS_SIGS_THRESHOLD       50;

### Attackers thresholds for logging and -S and -A output.
TOP_IP_LOG_THRESHOLD        500;
STATUS_IP_THRESHOLD         25;

### Specify how often to log the TOP_* information (i.e. how many
### CHECK_INTERVAL iterations before the data is logged again).
TOP_SCANS_CTR_THRESHOLD     1;

### Send scan logs to dshield.org.  This is disabled by default,
### but is a good idea to enable it (subject to your site security
### policy) since the DShield service helps to track the bad guys.
### For more information visit http://www.dshield.org
ENABLE_DSHIELD_ALERTS       Y;

### dshield.org alert email address; this should not be changed
### unless the guys at DShield have changed it.
DSHIELD_ALERT_EMAIL         reports@dshield.org;

### Time interval (hours) to send email alerts to dshield.org.
### The default is 6 hours, and cannot be less than 1 hour or
### more than 24 hours.
DSHIELD_ALERT_INTERVAL      6;  ### hours

### If you have a DShield user id you can set it here.  The
### default is “0”.
DSHIELD_USER_ID             0;

### If you want the outbound DShield email to appear as though it
### is coming from a particular user address then set it here.
DSHIELD_USER_EMAIL          NONE;

### Threshold danger level for DShield data; a scan must reach this
### danger level before associated packets will be included in an
### alert to DShield.  Note that zero is the default since this
### will allow DShield to apply its own logic to determine what
### constitutes a scan (_all_ iptables log messages will be included
### in DShield email alerts).
DSHIELD_DL_THRESHOLD        0;

### List of servers.  Fwsnort supports the same variable resolution as
#### Snort.
HTTP_SERVERS                $HOME_NET;
SMTP_SERVERS                $HOME_NET;
DNS_SERVERS                 $HOME_NET;
SQL_SERVERS                 $HOME_NET;
TELNET_SERVERS              $HOME_NET;

#### AOL AIM server nets
AIM_SERVERS                 [64.12.24.0/24, 64.12.25.0/24, 64.12.26.14/24, 64.12.28.0/24, 64.12.29.0/24, 64.12.161.0/24, 64.12.163.0/24, 205.188.5.0/24, 205.188.9.0/24];

### Configurable port numbers
HTTP_PORTS                  80;
SHELLCODE_PORTS             !80;
ORACLE_PORTS                1521;

### If this is enabled, then psad will die if a rule in the
### /etc/psad/signatures file contains an unsupported option (otherwise
### a syslog warning will be generated).
ENABLE_SNORT_SIG_STRICT     Y;

### If “Y”, enable automated IDS response (auto manages
### firewall rulesets).
ENABLE_AUTO_IDS             Y;

### Block all traffic from offending IP if danger
### level >= to this value
AUTO_IDS_DANGER_LEVEL       5;

### Set the auto-blocked timeout in seconds (the default
### is one hour).
#AUTO_BLOCK_TIMEOUT          36000;
AUTO_BLOCK_TIMEOUT          360;

### Enable regex checking on log prefixes for active response
ENABLE_AUTO_IDS_REGEX       N;

### Only block if the Netfilter log message matches the following regex
AUTO_BLOCK_REGEX            ESTAB;  ### from fwsnort logging prefixes

### Control whether “renew” auto-block emails get sent.  This is disabled
### by default because lots of IPs could have been blocked, and psad
### should not generate a renew email for each of them.
ENABLE_RENEW_BLOCK_EMAILS   N;

### By setting this variable to N, all auto-blocking emails can be
### suppressed.
ENABLE_AUTO_IDS_EMAILS      Y;

### Enable iptables blocking (only gets enabled if
### ENABLE_AUTO_IDS is also set)
IPTABLES_BLOCK_METHOD       Y;

### Specify chain names to which iptables blocking rules will be
### added with the IPT_AUTO_CHAIN{n} keyword.  There is no limit on the
### number of IPT_AUTO_CHAIN{n} keywords; just increment the {n} number
### to add an additional IPT_AUTO_CHAIN requirement. The format for this
### variable is: <Target>,<Direction>,<Table>,<From_chain>,<Jump_rule_position>,
###              <To_chain>,<Rule_position>.
### “Target”: Can be any legitimate Netfilter target, but should usually
###           just be “DROP”.
### “Direction”: Can be “src”, “dst”, or “both”, which correspond to the
###              INPUT, OUTPUT, and FORWARD chains.
### “Table”: Can be any Netfilter table, but the default is “filter”.
### “From_chain”: Is the chain from which packets will be jumped.
### “Jump_rule_position”: Defines the position within the From_chain where
###                       the jump rule is added.
### “To_chain”: Is the chain to which packets will be jumped. This is the
###             main chain where psad rules are added.
### “Rule_position”: Defines the position where rule are added within the
###                  To_chain.
###
### The following defaults make sense for most installations, but note
### it is possible to include blocking rules in, say, the “nat” table
### using this functionality as well.  The following three lines provide
### usage examples:
#IPT_AUTO_CHAIN1              DROP, src, filter, INPUT, 1, PSAD_BLOCK_INPUT, 1;
#IPT_AUTO_CHAIN2              DROP, dst, filter, OUTPUT, 1, PSAD_BLOCK_OUTPUT, 1;
#IPT_AUTO_CHAIN3              DROP, both, filter, FORWARD, 1, PSAD_BLOCK_FORWARD, 1;
IPT_AUTO_CHAIN1             DROP, src, filter, INPUT, 1, PSAD_BLOCK_INPUT, 1;
IPT_AUTO_CHAIN2             DROP, dst, filter, OUTPUT, 1, PSAD_BLOCK_OUTPUT, 1;
IPT_AUTO_CHAIN3             DROP, both, filter, FORWARD, 1, PSAD_BLOCK_FORWARD, 1;

### Flush all existing rules in the psad chains at psad start time.
FLUSH_IPT_AT_INIT           Y;

### Prerequisite check for existence of psad chains and jump rules
IPTABLES_PREREQ_CHECK       1;

### Enable tcp wrappers blocking (only gets enabled if
### ENABLE_AUTO_IDS is also set)
TCPWRAPPERS_BLOCK_METHOD    N;

### Set the whois timeout
WHOIS_TIMEOUT               60;  ### seconds

### Set the number of times an ip can be seen before another whois
### lookup is issued.
WHOIS_LOOKUP_THRESHOLD      20;

### Set the number of times an ip can be seen before another dns
### lookup is issued.
DNS_LOOKUP_THRESHOLD        20;

### Enable psad to run an external script or program (use at your
### own risk!)
ENABLE_EXT_SCRIPT_EXEC      N;

### Define an external program to run after a scan is caught.
### Note that the scan source ip can be specified on the command
### line to the external program through the use of the “SRCIP”
### string (along with some appropriate switch for the program).
### Of course this is only useful if the external program knows
### what to do with this information.
### Example:  EXTERNAL_SCRIPT       /path/to/script –ip SRCIP -v;
EXTERNAL_SCRIPT             /bin/true;

### Control execution of EXTERNAL_SCRIPT (only once per IP, or
### every time a scan is detected for an ip).
EXEC_EXT_SCRIPT_PER_ALERT   N;

### Disk usage variables
DISK_CHECK_INTERVAL         300;  ### seconds

### This can be set to 0 to disable disk checking altogether
DISK_MAX_PERCENTAGE         95;

### This can be set to 0 to have psad not place any limit on the
### number of times it will attempt to remove data from
### /var/log/psad/.
DISK_MAX_RM_RETRIES         10;

### Enable archiving of old scan directories at psad startup.
ENABLE_SCAN_ARCHIVE         N;

### Truncate fwdata file at startup
TRUNCATE_FWDATA             Y;

### Only archive scanning IP directories that have reached a danger
### level greater than or equal to this value.  Archiving old
### scanning ip directories only takes place at psad startup.
MIN_ARCHIVE_DANGER_LEVEL    1;

### Email subject line config.  Change these prefixes if you want
### psad to generate email alerts that say something other than
### the following.
MAIL_ALERT_PREFIX           [psad-alert];
MAIL_STATUS_PREFIX          [psad-status];
MAIL_ERROR_PREFIX           [psad-error];
MAIL_FATAL_PREFIX           [psad-fatal];

### URL for getting the latest psad signatures
SIG_UPDATE_URL              http://www.cipherdyne.org/psad/signatures;

### These next two are psadwatchd vars
PSADWATCHD_CHECK_INTERVAL   5;  ### seconds
PSADWATCHD_MAX_RETRIES      10;

### Directories
PSAD_DIR                    /var/log/psad;
PSAD_RUN_DIR                /var/run/psad;
PSAD_FIFO_DIR               /var/lib/psad;
PSAD_LIBS_DIR               /usr/lib/psad;
PSAD_CONF_DIR               /etc/psad;
PSAD_ERR_DIR                $PSAD_DIR/errs;
CONF_ARCHIVE_DIR            $PSAD_CONF_DIR/archive;
SCAN_DATA_ARCHIVE_DIR       $PSAD_DIR/scan_archive;
ANALYSIS_MODE_DIR           $PSAD_DIR/ipt_analysis;
SNORT_RULES_DIR             $PSAD_CONF_DIR/snort_rules;

### Files
FW_DATA_FILE                $PSAD_DIR/fwdata;
ULOG_DATA_FILE              $PSAD_DIR/ulogd.log;
FW_CHECK_FILE               $PSAD_DIR/fw_check;
DSHIELD_EMAIL_FILE          $PSAD_DIR/dshield.email;
SIGS_FILE                   $PSAD_CONF_DIR/signatures;
ICMP_TYPES_FILE             $PSAD_CONF_DIR/icmp_types;
AUTO_DL_FILE                $PSAD_CONF_DIR/auto_dl;
SNORT_RULE_DL_FILE          $PSAD_CONF_DIR/snort_rule_dl;
POSF_FILE                   $PSAD_CONF_DIR/posf;
P0F_FILE                    $PSAD_CONF_DIR/pf.os;
IP_OPTS_FILE                $PSAD_CONF_DIR/ip_options;
PSAD_FIFO_FILE              $PSAD_FIFO_DIR/psadfifo;
ETC_HOSTS_DENY_FILE         /etc/hosts.deny;
ETC_SYSLOG_CONF             /etc/syslog.conf;
ETC_RSYSLOG_CONF            /etc/rsyslog.conf;
ETC_SYSLOGNG_CONF           /etc/syslog-ng/syslog-ng.conf;
ETC_METALOG_CONF            /etc/metalog/metalog.conf;
STATUS_OUTPUT_FILE          $PSAD_DIR/status.out;
ANALYSIS_OUTPUT_FILE        $PSAD_DIR/analysis.out;
INSTALL_LOG_FILE            $PSAD_DIR/install.log;

### PID files
PSAD_PID_FILE               $PSAD_RUN_DIR/psad.pid;
PSAD_CMDLINE_FILE           $PSAD_RUN_DIR/psad.cmd;
KMSGSD_PID_FILE             $PSAD_RUN_DIR/kmsgsd.pid;
PSADWATCHD_PID_FILE         $PSAD_RUN_DIR/psadwatchd.pid;

### List of ips that have been auto blocked by iptables
### or tcpwrappers (the auto blocking feature is disabled by
### default, see the psad man page and the ENABLE_AUTO_IDS
### variable).
AUTO_BLOCK_IPT_FILE         $PSAD_DIR/auto_blocked_iptables;
AUTO_BLOCK_TCPWR_FILE       $PSAD_DIR/auto_blocked_tcpwr;

### File used internally by psad to add Netfilter blocking
### rules to a running psad process
AUTO_IPT_SOCK               $PSAD_RUN_DIR/auto_ipt.sock;

FW_ERROR_LOG                $PSAD_ERR_DIR/fwerrorlog;
PRINT_SCAN_HASH             $PSAD_DIR/scan_hash;

### /proc interface for controlling ip forwarding
PROC_FORWARD_FILE           /proc/sys/net/ipv4/ip_forward;

### Packet counters for tcp, udp, and icmp protocols
PACKET_COUNTER_FILE         $PSAD_DIR/packet_ctr;

### Top scanned ports
TOP_SCANNED_PORTS_FILE      $PSAD_DIR/top_ports;

### Top signature matches
TOP_SIGS_FILE               $PSAD_DIR/top_sigs;

### Top attackers
TOP_ATTACKERS_FILE          $PSAD_DIR/top_attackers;

### Counter file for Dshield alerts
DSHIELD_COUNTER_FILE        $PSAD_DIR/dshield_ctr;

### Counter file for iptables prefixes
IPT_PREFIX_COUNTER_FILE     $PSAD_DIR/ipt_prefix_ctr;

### iptables command output and error collection files; these are
### used by IPTables::ChainMgr
IPT_OUTPUT_FILE             $PSAD_DIR/psad.iptout;
IPT_ERROR_FILE              $PSAD_DIR/psad.ipterr;

### system binaries
iptablesCmd      /sbin/iptables;
shCmd            /bin/sh;
wgetCmd          /usr/bin/wget;
gzipCmd          /bin/gzip;
mknodCmd         /bin/mknod;
psCmd            /bin/ps;
mailCmd          /usr/bin/mail;
sendmailCmd      /usr/sbin/sendmail;
ifconfigCmd      /sbin/ifconfig;
killallCmd       /usr/bin/killall;
netstatCmd       /bin/netstat;
unameCmd         /bin/uname;
# we do not need to compile the whois client
# stripped the extention ../whois_psad
whoisCmd         /usr/bin/whois;
dfCmd            /bin/df;
fwcheck_psadCmd  /usr/sbin/fwcheck_psad;
psadwatchdCmd    /usr/sbin/psadwatchd;
kmsgsdCmd        /usr/sbin/kmsgsd;
psadCmd          /usr/sbin/psad;

 이 능동적 응답 설정에 대해 살펴볼 것이 많다. 우선 psad는 AUTO_BLOCK_TIMEOUT 변수를 통해 공격자를 영속적으로 차단하지 않는다(psad는 공격자에 대한 차단 규칙을 3600초, 즉 한시간 동안만 추가한다). 둘째로 차단 규칙이 인스턴스화되기 전에 공격자는 최소한 DANGER_LEVEL3에 도달해야 한다. 이는 최소한 150개의 패킷을 수반하지 않거나 /etc/psad/signature 에서 psad_dl이 3으로 설정된 서명과 매칭되지 않거나 /etc/psad/auto_dl 에서 위험 수준이 최소한 3으로 자동 할당되지 않는 스캔에 대해서는 어떤 조치도 취해지지 않는다는 것을 의미한다. 끝으로 ENABLE_AUTO_IDS_REGEX가 N 이기 때문에 IP 주소 차단을 위해 필터링 정책이 특수 로깅 접두어를 생성할 필요는 없다.

 ** SYN 스캔 응답

 공격자가 iptables 방화벽에 대해 표준 Nmap SYN 스캔을 수행해보자.

soft-ftp:/etc# nmap -sS -P0 -n X.X.X.X

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2010-07-04 23:48 KST
Interesting ports on 117.17.172.120:
Not shown: 1674 filtered ports
PORT    STATE  SERVICE
20/tcp  closed ftp-data
21/tcp  open   ftp
22/tcp  open   ssh
53/tcp  closed domain
80/tcp  open   http
443/tcp closed https

Nmap finished: 1 IP address (1 host up) scanned in 153.357 seconds

 실제로 psad는 (앞서 설명한대로 IPT_AUTO_CHAIN{n} 변수에 정의된 맞춤화 psad 체인에 차단 규칙을 추가해서 공격자를 차단했으며, iptables -v -n -L 의 출력을 자세히 검색하는 대신 사용자가 psad 체인에서 새로운 차단 규칙을 쉽게 볼 수 있게 해준다.

root@seclab:/etc/psad# psad –fw-list
[+] Listing chains from IPT_AUTO_CHAIN keywords…

Chain PSAD_BLOCK_INPUT (1 references)
 pkts bytes target     prot opt in     out     source               destination        
  347 15268 DROP       all  —  *      *       X.X.X.X      0.0.0.0/0              

Chain PSAD_BLOCK_OUTPUT (1 references)
 pkts bytes target     prot opt in     out     source               destination        
    0     0 DROP       all  —  *      *       0.0.0.0/0            X.X.X.X
  

Chain PSAD_BLOCK_FORWARD (1 references)
 pkts bytes target     prot opt in     out     source               destination        
    0     0 DROP       all  —  *      *       0.0.0.0/0            X.X.X.X     
    0     0 DROP       all  —  *      *       X.X.X.X       0.0.0.0/0                  

 상태 측면에서 보면 psad –Status 명령어를 사용해서 IP 주소에 대한 차단 규칙이 앞으로 얼마 동안 더 유효한지 확인할 수도 있다. 이 명령어의 전체 출력은 여기에 보이지 않지만 끝부분에는 다음과 같은 두 줄이 나온다. 이 경우 아래의 두 줄을 통해 IP X.X.X.X 가 총 65초 동안 더 차단된다는 것을 알 수 있다.

    iptables auto-blocked IPs:
      X.X.X.X (65 seconds remaining)

 끝으로 목표가 공격자로부터 접근할 수 없게 됐다는 것을 확인하기 위해 스캔을 다시 시도해보자. 이번에는 그 어떤 포트도 도달할 수 없을 것이다.

 * 써드파티 도구와 psad 능동적 응답의 통합

 많은 소프트웨어 업체가 써드파티 소프트웨어가 자사 소프트웨어를 관리하거나 자사 소프트웨어와 연동하기 쉽게 API 를 만든다. API 를 이용하지 않으면 얻을 수 없는 융통성, 플러그인 가능성, 스크립트화 가능성이 API를 통해 제공되기 때문에 API는 사용자나 설치 기반을 증가시킬 수 있다.

 ** 명령 행 인터페이스

 psad는 동적으로 추가되는(그리고 삭제되는) iptables 규칙을 통해 공격 IP 주소를 차단하는 것 이상의 기능을 제공한다. 능동적 응답 기능 역시 (응답 기능을 쉽게 스크립트화 가능하게 해주는) 명령 행 인터페이스를 통하거나 유닉스 도메인 소켓을 통해 실행 중인 psad 데몬과 좀 더 직접적으로 통신함으로써 써드파티 도구와 쉽게 통합될 수 있다. 다음은 제3자 애플리케이션에 iptables 규칙집합 관리 기능을 직접 만드는 대신 이를 위해 psad를 사용하는 것이 가지는 장점이다.

 – 타이머에 기반해서 규칙을 만료시킬 수 있는 기능이 psad에 내장돼 있으므로 따로 개발할 필요가 없다.
 – psad는 동적으로 생성된 규칙의 삽입과 삭제를 자신만의 체인에서 관리한다. 이는 psad 규칙을 기존의 iptables 정책과 완전히 분리시킨다.
 – psad는 psad 체인에 이미 차단 규칙이 있는 경우 해당 IP 주소나 네트워크에 대해 중복 규칙을 추가하지 않는다.
 – psad는 /etc/psad/auto_dl 파일을 이용해서 허용된 IP 주소나 네트워크가 차단되지 않게 보장한다.
 – 현재 차단 중인 IP 주소에 대한 상태 정보는 psad –Status 명령을 통해 쉽게 확인할 수 있다.
 – psad 맞춤화 체인의 목록은 psad –fw-list 명령을 통해 확인할 수 있다. 이를 통해 psad를 통해 생성된 iptables 규칙과 복잡한 필터링 정책 내의 다른 규칙을 쉽게 구별할 수 있다.

 psad의 명령 행 호출을 통해 이용할 수 있는 능동적 응답 기능을 사용하려면 시스템에 데몬으로 실행 중인 psad 인스턴스가 있어야 한다. 실행 중인 psad 데몬이 없다면 현재 psad가 실행 중이지 않다는 오류가 발생한다.

 – 차단 규칙 추가

 –fw-block-ip 명령 행 인자를 사용하면 직접 특정 IP 주소나 네트워크에 대한 차단 규칙을 맞춤화 psad 체인에 추가할 수 있다. 다음의 예를 보자.

root@seclab:/etc/psad# psad –fw-block-ip 192.168.10.1
[+] Writing 192.168.10.1 to socket; psad will add the IP
    within 5 seconds.

일단 실행 중인 psad 데몬에서 CHECK_INTERVAL 타이머가 만료되면 해당 IP 주소는 AUTO_BLOCK_TIMEOUT 변수에 해당하는 기간 동안 차단 체인에 추가된다.

Jul  5 01:13:25 seclab psad: added iptables auto-block against 192.168.10.1 for 360 seconds

 – 차단 규칙 제거

 특정 IP 주소나 네트워크에 대한 모든 차단 규칙을 제거하려면 –fw-rm-block-ip 명령 행 인자를 사용한다.

root@seclab:/etc/psad# psad –fw-rm-block-ip 192.168.10.1
[+] Writing 192.168.10.1 to socket; psad will remove the IP
    within 5 seconds.

 실제로 실행 중인 psad가 차단 규칙을 만료시킨다.

Jul  5 01:17:00 seclab psad: removed iptables auto-block against 192.168.10.1

 – 모든 차단 규칙 제거

 때때로 기본적인 네트워크 연결성에 문제가 생길 수 있으며, 어떤 경우에는 능동적 응답 기법 때문에 이런 연결성 문제가 악화될 수 있다. 특정 IP 주소나 네트워크를 허용 목록에 추가할 수 있는 제공하는 것 외에도 능동적 응답 기법은 네트워크에 자신이 미치는 영향을 쉽게 제거할 수 있게 해줘야 한다. psad의 경우에는 동적으로 생성되는 iptables 규칙뿐만 아니라 맞춤화 psad 체인에 존재하는 모든 규칙을 쉽게 제거할 수 있는 방법도 제공해야 한다. psad –Flush 명령이 이 기능을 제공한다.

root@seclab:~# psad –Flush
[+] Flushing psad chains.

 일단 CHECK_INTERVAL 타이머가 만료되면 실행 중인 psad 데몬이 다음과 같은 syslog 메시지를 생성한다.

Jul  6 00:28:52 seclab psad: flushing existing psad iptables auto-response chains
Jul  6 00:28:52 seclab psad: flushed: PSAD_BLOCK_INPUT
Jul  6 00:28:52 seclab psad: flushed: PSAD_BLOCK_OUTPUT
Jul  6 00:28:52 seclab psad: flushed: PSAD_BLOCK_FORWARD

7.psad 고급 주제: 서명 매칭에서 OS 핑거프린팅까지

Posted on by
Reply

 * 스노트 규칙을 사용한 공격 탐.

 iptables 로깅 형식은 매우 완전하기 때문에 psad는 애플리케이션 계층 기준이 없는 스노트 규칙과 매칭되는 트래픽을 탐지할 수 있다. 예를 들어 다음과 같은 스노트 규칙을 생각해보자. 이 규칙은 출발지 포트가 10101이고 승인 값이 0이며 SYN 플래그가 설정됐고, IP 헤더의 TTL 값이 220보다 큰 TCP 패킷을 찾는다.

alert tcp $EXTERNAL_NET 10101 -> $HOME_NET any (msg:”SCAN myscan”; flags:S; ttl:>220; reference:arachnids,439; classtype:attempted-recon; sid:613; psad_id:100065; psad_dl:2;)

 이 스노트 규칙에는 애플리케이션 계층 데이터를 검사하는 부분이 없으며, 스노트 규칙집합에는 이런 규칙이 약 150개 정도 있다. psad는 /etc/psad/signatures 파일로부터 이러한 규칙의 수정된 버전을 들여온다. BAD-TRAFFIC data in TCP SYN packet(아래 참조)과 같은 /etc/psad/signature 파일의 서명을 하나 무작위로 살펴보면 psad가 추가적인 키워드를 사용해서 일반적인 스노트 규칙 구문을 확장했음을 알 수 있다.


 이와 같은 키워드 첨가는 서명을 psad와 호환되게 해주는 특정 정보를 서명에 추가한다. 스노트 규칙에 추가된 모든 psad 키워드 첨가의 정의는 다음과 같다.

 – psad_id : 이 키워드는 서명을 추적하고 psad가 새로운 서명을 추가할 수 있게 유일한 ID 숫자를 정의한다. psad_id 항목은 스노트의 sid 항목과 유사하다. 모든 psad_id 값은 6자리이며, 스노트 sid 값과 구별하기 위해 10000에서 시작한다. ID 값을 정의하는 이런 방법은 서명 ID 값이 7자리며, 일반적으로 서명이 생성된 연도수로 시작하는 블리딩 스노트 프로젝트(http://www.bleedingsnort.com)와 유사하다.

 – psad_dl : 이 키워드는 psad가 서명을 촉발한 IP 주소에 할당해야 하는 위험 수준을 명시한다. psad_dl 항목은 1 ~ 5 사이의 값을 취한다.

 – psad_dsize : 이 키워드는 iptables LEN 항목의 값에서 헤더의 길이를 빼는 방법으로 패킷 페이로드 크기에 대한 매칭 기준을 명시한다. 이 옵션은 스노트의 dsize와 유사하지만 iptables 로그 메시지의 LEN 항목은 기록된 패킷의 전체 길이로 IP 헤더까지 포함하기 때문에 psad는 헤더 길이를 빼야 한다. 예를 들어 페이로드 크기가 1000 바이트보다 큰지 검사하려면 서명에 psad_dsize:>1000 를 추가한다.

 – psad_derived_sids : psad는 이 키워드를 이용해서 특정 psad 서명이 유도된 원본 스노트 sid 값을 추적할 수 있다. 일부 psad 서명은 몇 가지 스노트 규칙을 합쳐서 생성되며, 이 키워드가 이러한 스노트 규칙을 기록한다.

 – psad_ip_len : 이 키워드는 iptables 로그 메시지의 LEN 항목에 대한 매칭 기준을 명시한다.(이는 psad_dsize 와 비슷하지만 네트워크와 전송 계층 헤더의 길이를 빼지 않는다). psad_dsize와 마찬가지로 psad_ip_len 키워드도 n:m, n<, n> 과 같은 형식의 범위 매칭을 지원한다. 예를 들어 LEN 항목이 100바이트에서 200바이트 사이인지 검사하려면 psad_ip_len: 100:200 를 서명에 추가한다.

 ** LAND 공격 탐지

LAND 공격은 오래된 고전적 공격으로 윈도우 시스템을 목표로 하는 서비스 거부 공격이다. LAND 공격에는 자신의 목적지 IP 주소와 동일한 출발지 IP 주소를 가지는 TCP SYN 패킷을 생성하는 것이 포함된다. 스노트 서명 집합에서 LAND 공격 탐지의 핵심은 sameip 패킷 헤더 검사다. 스노트 규칙 ID 527( 원래 스노트의 /etc/psad/snort_rules/bad-traffic.rules 파일에 존재)의 수정된 버전을 통해 psad는 iptables 로그에서 LAND 공격을 탐지할 수 있다.

alert ip any any -> any any (msg:”BAD-TRAFFIC same SRC/DST”; sameip; reference:bugtraq,2666; reference:cve,1999-0016; reference:url,www.cert.org/advisories/CA-1997-28.html; classtype:bad-unknown; sid:527; psad_id:100103; psad_dl:2;)

 psad는 iptables 로그에서 SRC와 DST 항목이 동일한지 확인하는 방법으로 sameip 검사를 수행한다. 그러나 긍정 오류를 줄이기 위해 루프백(loopback) 인터페이스에 대해 기록된 트래픽은 이 검사에서 제외한다.

 SRC와 DST 항목은 항상 iptables 로그 메시지에 의해 포함되므로 psad가 LAND 공격과 관련된 트래픽을 탐지하게 하기 위한 LOG 규칙을 만들 때는 특별한 명령 행 옵션을 입력할 필요가 없다.

 ** 윈도우 메신저 팝업 스팸 탐지

 스팸은 인터넷 공간 어디에나 존재하는 문제로 모두가 이 골칫거리의 영향을 체감하고 있다. 자신의 스팸을 좀 더 많은 사용자가 보게 하기 위해 스패머(스팸 전송자)가 주로 사용하는 방법 중 하나는 윈도우 메신저 서비스를 통해 스팸을 직접 전송하는 것이다. 이 트래픽이 외부 네트워크로부터 오는 경우 이를 탐지하는 것은 매우 쓸모 없음에도 불구하ㄱ(스팸 메시지는 스푸핑될 수 있으며, 메시지가 크지 않는 한 이를 전송하는 데는 UDP 패킷 하나만 필요하기 때문이다) 내부 네트워크에서 전송되는 스팸 메시지를 탐지하는 것은 중요할 수 있다. 인트라넷이서 이런 트래픽을 생성하는 시스템은 원격에서 시스템을 제어하고 있는 누군가에 의해 이미 침투당해서 스팸을 존송하는 데 이용되는 중일 수도 있다.

 psad는 (내부 주소에서 전송됐는지와 무관하게) INPUT 체인에 기록된 패킷을 홈 네트워크에서 라우팅된 것으로 취급하기 때문에 다음과 같은 서명은 윈도우 팝업 스팸 시도가 방화벽으로 라우팅될 때 이를 탐지한다(목적지 포트 범위 1026 ~ 1029를 가지는 UDP와 psad_size 검사를 이용하는 100바이트 초과의 애플리케이션 계층 데이터 크기 부분에 주목하자).

alert udp $EXTERNAL_NET any -> $HOME_NET 1026:1029 (msg:”MISC Windows popup spam attempt”; classtype:misc-activity; reference:url,www.linklogger.com/UDP1026.htm; psad_dsize:>100; psad_id:100196; psad_dl:2;)

 * psad 서명 갱신

 psad 배포는 주로 psad tar 압축 파일이나 RPM 파일에 “signatures” 파일로서 갱신된 서명 집합을 포함한다. 그러나 서명 개발은 진행 중인 과정이며, 어떤 경우에는 psad의 다음 배포가 나오기 전에 새로운 서명이 개발되기도 한다.

 사용자가 최대한 빨리 서명을 이용할 수 있게 하기 위해 http://www.cipherdyne.org/psad/signatures 에서 최신 서명 집합을 배포한다. psad –sig-update 명형 행 인자를 이용하면 psad는 다음과 같이 이 파일을 받아서 파일시스템의 /etc/psad/signatures 에 위치시킨다.


 위에서 알 수 있듯이 최신 서명 집합이 다운로드됐으며, 사용자는 init 스크립트(/etc/init.d/psad restart)를 이용해서 psad 를 재시작하거나 실행 중인 psad 데몬에 HUP 신호(psad -H)를 전송해서 새로운 서명 집합을 들여오게 할 수 있다.

 * OS 핑거프린팅

 네트워크 트래픽을 통해 운영체제를 원격으로 핑거프린팅하는 기술에는 몇 가지가 있으며, 크게 능동형과 수동형의 두 분류로 나눌 수 있다.

 – 운영체제 핑거프린팅이라는 용어는 다소 잘못된 표현이다. 사실 이 용어가 의미하는 것은 네트워크 스택 핑거프린팅이기 때문이다. 네트워크 스택이 OS 마자 다르기 때문에 네트워크 스택을 핑거프린팅해서 이에 대응되는 운영체제를 유추할 수 있다.

 ** Nmap을 이용한 능동적 OS 핑거프린팅

 사용자가 기여하는 1600개 이상의 OS 핑거프린트 데이터 베이스를 이용하면 Nmap의 -O 옵션은 가장 잘 알려진 능동적 OS 핑거프린팅 구현이다. Nmap은 주로 TCP의 틀징적인 동작을 이용해서 원격 운영체제를 추측하는데, 다음과 같은 것이 있다.

 – Nmap이 전송한 SYN 패킷에 대한 응답으로 목표 스택이 TCP 헤더의 옵션 부분을 구성하는 방식
 – 닫힌 포트로 UDP 패킷을 전송해서 목표 시스템으로부터 알아낸 ICMP 포트 도달 불가 메시지의 특성을 통해 알아내는 방식. 운영체는 ICMP 포트 도달 불가 메시지에 닫힌 포트로 전송된 원본 UDP 패킷의 일부를 방환해야 하지만 많은 스택이 이를 완전하게 수행하지는 않는다. 체크섬, IP ID 값, 총 IP 길이 항목 등이 왜곡될 수 있다. 이 값들이 왜곡되는 정도와 방식은 원격 스택의 핑거프린팅을 돕는 척도로 이용될 수 있다.

 – Xprobe도 흥미로운 능동적 OS 핑거 프린터다(http://www.sys-security.com). Xprobe는 핑거 프린팅을 보조하기 위해 굉장히 많은 ICMP을 사용한다. 어떤 경우 Xprobe는 OS 를 핑거프린팅할 때 Nmap 보다 훨씬 적은 패킷을 전송하기도 한다. 때때로 Nmap은 하나의 원격 호스트에 대한 핑거프린트를 생성하는 데 1400개 정도의 패킷을 생성할 수 있다. 능동적 핑거프린팅 기술에 대한 자세한 정보는 논문 [Remote OS Detection via TCP/IP Stack FingerPrinting] (http://www.insecure.org)과 [The Present and Future of Xprobe2-The Next Generation of Active Operating System Fingerprinting](http://www.sys-security.com)에서 찾아볼 수 있다.

 * DShield 보고

 DShiled 분산 침입 탐지 시스템(http://www.dshield.org)은 보안 이벤트 데이터를 수집하고 보고하는 데 있어 중요한 도구다. DShield는 침입 탐지 시스템, 라우터, 방화벽 등을 포함해서 다양한 공개 소스와 상용 소프트웨어가 제공하는 데이터에 대한 중앙집중식 저장소 역할을 수핸한다.

 이러한 제품의 다수가 메일이나 웹 인터페이스를 통해 DShield 에게 보안 경고를 제출할 수 있다. 이벤트 데이터를 DShield 에게 제출할 수 있는 클라이언트 프로그램의 전체 목록은 http://www.dshield.org/howto.php 에서 찾아볼 수 있다.

 DSheild 데이터베이스는 전역 자원으로 설계됐다. 즉, 어떤 IP 주소가 가장 많은 수의 임의 목표를 공격 중인지, 가장 일반적으로 공격되는 포트와 프로토콜이 무엇인지 등을 알기 위해 누구나 DShield 데이터베이스를 이용할 수 있다.

 DShield 에 제출하는 이벤트 데이터의 형태는 중요하다. 방화벽이나 침입 탐지 시스템이 기록한 이벤트 데이터 중 일부는 공개적인 인터넷상에서 악의적인 트래픽을 의미하는 것이 아닐 수 있으므로 DShield 데이터베이스에 포함시키는 것이 부적절하다. 이런 데이터는 RFC 1918 주소 공간의 내부 네트워크에 존재하는 호스트 간 공격, 로컬 보안을 검사하기 위해 실즈 업(https://www.grc.com)과 같은 외부 사이트로부터 요청된 포트 스캔 등이 있다.

 psad 는 자동적으로 스캔 데이터를 DShield에게 메일로 제출할 수 있다. DShield 웹사이트에 가입하면 /etc/psad/psad.conf 의 DSHIELD_USER_ID 변수를 수정해서 메일 제출에 사용자명을 포함시킬 수도 있지만 DShield 는 익명 출처로부터의 로그정보도 수용하므로 굳이 가입할 필요는 없다. 기본적으로 DShield 보고가 활성화되면 psad는 6시간마다 제출 메일을 전송하지만 이 간격은 DSHIELD_ALERT_INTERVAL 변수를 조절해 변경할 수 있다(psad는 RFC 1918 주소나 /etc/psad/auto_dl 에서 위험 수준이 0으로 설정됐기 때문에 무시해야 하는 주소로부터 시작되는 스캔 데이터를 포함시키지 않는다).

 psad 에서 DShield 보고가 기본적으로 활성화대 있지는 않지만 psad 설치 프로그램인 install.pl 은 이를 활성화할지 묻는다. 보안 정책에서 명시적으로 DShield로의 보안 이벤트 데이터 전송을 금지하지 않는 한 이 기능을 활성화할 것을 경력 추천한다.

 * psad 상태 출력 보기

 psad는 iptables 로그를 감시하면서 다양한 데이터를 /var/log/psad 디렉토리에 저장하기 때문에 사용자는 자신의 시스템이 얼마나 많이 스캔됐는지에 대한 정보를 얻기 위해 이 디렉토리를 자세히 살펴볼 수 있다.

 물론 대부분의 사람들이 수없이 많은 /var/log/psad/ip 디렉토리와 그 안의 파일을 직접 분류하는 것을 즐기지 않기 때문에 psad는 실행 중인 psad 데몬에 대한 상태 정보를 로컬 파일시스템에 질의하는 기능을 통해 이 과정을 자도오하한다. 이를 위해서는 psad를 실행할 때 목록 7-1과 같이 –Status 명령 행 인자를 입력해야 한다.

[+] psadwatchd (pid: 29253)  %CPU: 0.0  %MEM: 0.0
    Running since: Sun Jul  4 13:29:20 2010

[+] kmsgsd (pid: 29251)  %CPU: 0.0  %MEM: 0.0
    Running since: Sun Jul  4 13:29:19 2010

[+] psad (pid: 29248)  %CPU: 0.1  %MEM: 0.7
    Running since: Sun Jul  4 13:29:19 2010
    Command line arguments: -c /etc/psad/psad.conf
    Alert email address(es): root@localhost

[+] Version: psad v2.1.4

[+] Top 50 signature matches:
      “POLICY vncviewer Java applet communication attempt” (tcp),  Count: 12,  Unique sources: 1,  Sid: 1846
      “BACKDOOR DeepThroat 3.1 Server Response [3150]” (udp),  Count: 12,  Unique sources: 3,  Sid: 1982
      “BACKDOOR DeepThroat 3.1 Server Response [4120]” (udp),  Count: 10,  Unique sources: 1,  Sid: 1984
      “BACKDOOR DoomJuice file upload attempt” (tcp),  Count: 8,  Unique sources: 1,  Sid: 2375
      “MISC PCAnywhere communication attempt” (tcp),  Count: 8,  Unique sources: 1,  Sid: 100073
      “BACKDOOR netbus Connection Cttempt” (tcp),  Count: 8,  Unique sources: 1,  Sid: 100028
      “BACKDOOR DeepThroat 3.1 Server Response” (udp),  Count: 6,  Unique sources: 3,  Sid: 195
      “MISC HP Web JetAdmin communication attempt” (tcp),  Count: 4,  Unique sources: 1,  Sid: 100084

[+] Top 25 attackers:
….

[+] Top 20 scanned ports:
….

[+] iptables log prefix counters:
….

DShield stats:
….

[+] IP Status Detail:
….

 위 출력에는 현재 psad가 추적 중인 모든 공격을 특징에 따라 나눈 일부 집합을 사용자에게 알려주게 설계된 여러 부분이 있다(가장 높은 수준의 정보가 위쪽에 위치한다). 각 부분은 다음과 같다.

 – psad 프로세스 상태 정보.
 먼저 psad 프로세스 상태 정보를 볼 수 있으며 여기에는 프로세스 ID, 프로세스가 실행된 시간, 현재 사용 중인 CPU와 주 메모리의 %가 있다. 특히 psad 데몬의 경우 실행 시 주어진 명령 행 인자가 있다면 이것도 출력에 포함되며, psad가 경고 메일을 전송하게 설정된 메일 주소도 포함된다.

 – 서명 매칭 상위 50개
 다음으로는 서명 매칭의 상위 50개가 나와 있다. 50개 이상 출력되게 하려면 /etc/psad/psad.conf 파일의 STATUS_SIGS_THRESHOLD 변수 값을 증가시키면 된다.

 – 공격자 상위 25개
 다음으로는 공격 IP 주소의 상위 25개가 나열돼있다. psad가 25개 이상 출력되게 하려면 psad.conf 파일의 STATUS_IP_THRESHOLD 변수 값을 증가시키면 된다. 상위 공격자들의 목록을 알면 사용자 시스템에 잠재적으로 위험할 수 있는 인터넷상의 IP 주소에 대해 좀 더 나은 결정을 할 수 있다.

 – 스캔된 포트 상위 20개
 다음으로는 상위 20개의 스캔된 TCP와 UDP 포트가 나온다. psad.conf 파일의 STATUS_PORT_THRESHOLD 변수를 증가시켜서 20개 이상 출력하게 할 수 있다. 특정 서비스에 대해 전파 중인 웜이 있다면 상위 20개의 스캔된 포트 정보가 해당 서비스에 대해 증가된 웜의 활동을 알아내는 데 도움이 된다. 이런 웜을 이용한 공격한 취약한 네트워크에 시스템이 존재하는 경우 상위 20개의 스캔된 포트 목록은 인프라스트럭처에서 취약점을 제거하는 데 도움이 될 수 있다.

 – 로깅 접두어
 다음에는 psad가 추정 중인 로깅 접두어가 있다. fwsnort를 실행하는 경우 각각의 fwsnort iptables 규칙이 서로 다른 스노트 서명에 대응되는 자신만의 로깅 접두어를 가지기 때문에 이 부분의 양이 많을 수 있다. 이 부분을 통해 iptables 정책에서 가장 일반적으로 촉발되는 로깅 접두어를 알 수 있다. 로깅 접두어는 가장 많이 촉발된는 순으로 정렬돼있다.

 – DShield 통계
 다음은 DShield 분산 IDS로 전송된 메일 경고의 갯수다. 함께 나와 있는 것은 psad가 수집해서 추가적인 분석을 위해 DShield로 전송한 총 패킷 수다.

 – 자동 차단된 IP 주소
 위의 예제에는 나오지 않지만 다음에는 psad가 차단한 IP 주소가 나온다. 자동 차단을 이용하려면 ENABLE_AUTO_IDS를 Y로 설정해야 한다. 자동 응답 정보는 ENABLE_AUTO_IDS 가 N 으로 설정된 경우에도 항상 상태 정보 출력에 포함된다. 이는 psad가 자동 응답 기능을 활성화했던 이전 실행(현재 실행 중인 psad 인스턴스에서는 활성화하지 않음)에서 여러 IP 주소를 차단했을 수 있기 때문이다.
 
 – 스캐닝 IP 주소의 상세 정보
 마지막으로는 psad가 현재 추적 중이며 각 주소로부터 감시된 수상한 트래픽의 심각도가 최소 DANGER_LEVEL_1 로 할당된 출발지 주소의 전체 목록으로 시작한다. 각 IP 주소행에는 수상한 패킷을 기록한 iptables 체인과 입력 인터페이스, 출발지 IP 주소로부터의 TCP, UDP, ICMP 패킷의 개수, 현재 위험 수준, 메일 경고 개수, 수상한 트래픽을 생성한 운영체제에 대한 추측 값도 함께 출력된다.

 psad가 /var/log/psad 디렉토리에 스캔 정보를 잘 기록하지만 실행 중인 psad 데몬이 어떻게 수행 중인지에 대한 정보를 얻는 다른 방법이 있다. 명령어 psad -U 를 (root 권한으로) 실행하면 현재 실행 중인 psad 인스턴스가 스캔 정보를 디스크에 기록하기 위해 내부적으로 사용하는 주 해시 자료 구조의 내용을 덤프하기 위해 Data::Dumper 펄 모듈을 사용하게 지시하는 USRI 신호를 수신한다. 결과는 /var/log/psad/scan_hasb.pid 에 기록되며, 여기서 pid는 현재 실행 중인 psad 데몬의 프로세스 ID다. 이 출력의 예는 http://www.cipherdyne.org/LinuxFirewalls 에서 구할 수 있다.

 * 포렌식 모드

 많은 사람들이 iptables 로그 데이터를 포함하는 오래된 syslog 파일을 가지고 있다. psad를 포렌식(forensics) 모드로 사용하면 이런 오래된 로그 파일을 사용해서 과거에 발생했던 수상한 트래픽을 알아낼 수 있다. 이 정보는 실제 침입을 추적하는 중이거나 침투 시점에 어떤 IP 주소가 시스템을 스캔했는지 알아보고자 할 때 특히 유용할 수 있다. psad를 포렌식 모드로 실행하려면 아래와 같이 -A 명령행 스위치를 지정한다(IP 주소는 모두 변경하였다)

root@seclab:/etc/psad# psad -A
[+] Entering analysis mode.  Parsing /var/log/messages
[+] Found 17130 iptables log messages out of 19807 total lines.
    This may take a while…
[+] Processed 1000 packets…
[+] Processed 2000 packets…
[+] Processed 3000 packets…
[+] Processed 4000 packets…
[+] Processed 5000 packets…
[+] Processed 6000 packets…
[+] Processed 7000 packets…
[+] Processed 8000 packets…
[+] Processed 9000 packets…
[+] Processed 10000 packets…
[+] Processed 11000 packets…
[+] Processed 12000 packets…
[+] Processed 13000 packets…
[+] Processed 14000 packets…
[+] Processed 15000 packets…
[+] Processed 16000 packets…
[+] Processed 17000 packets…
[+] Assigning scan danger levels…
    Level 1: 0 IP addresses
    Level 2: 0 IP addresses
    Level 3: 0 IP addresses
    Level 4: 2 IP addresses
    Level 5: 0 IP addresses

    Tracking 2 total IP addresses
[+] Version: psad v2.1.4

[+] Top 50 signature matches:
        [NONE]

[+] Top 25 attackers:
      117.17.X.X  DL: 4, Packets: 8462, Sig count: 0
      117.17.X.X  DL: 4, Packets: 3033, Sig count: 0

[+] Top 20 scanned ports:
      tcp 25    2044 packets

      udp 57321 8460 packets
      udp 1947  2952 packets
      udp 5353  1262 packets
      udp 67    1254 packets
      udp 138   587 packets
      udp 137   341 packets
      udp 9999  212 packets
      udp 11702 7 packets
      udp 2343  7 packets

[+] iptables log prefix counters:
      “DROP”: 17126
      “DROP INVALID”: 4

    Total packet counters: tcp: 2044, udp: 15082, icmp: 0

[+] IP Status Detail:

SRC:  117.17.Z.Z, DL: 4, Dsts: 1, Pkts: 8462, Unique sigs: 0

    DST: 255.255.255.255
        Scanned ports: UDP 2343-57321, Pkts: 8462, Chain: INPUT, Intf: eth0

SRC:  117.17.A.A, DL: 4, Dsts: 2, Pkts: 3033, Unique sigs: 0

    DST: 255.255.255.255
        Scanned ports: UDP 1947-9999, Pkts: 2962, Chain: INPUT, Intf: eth0
    DST: 224.0.0.251
        Scanned ports: UDP 5353, Pkts: 71, Chain: INPUT, Intf: eth0

    Total scan sources: 2
    Total scan destinations: 2

[+] These results are available in: /var/log/psad/analysis.out

[+] Finished –Analyze cycle.

  위 출력물은 psad가 로그 파일로부터 구문 분석한 iptables 로그 메시지의 총수를 알려주는 정보가 포함된다. 또 출력은 5개의 위험 수준에 해당하는 IP 주소의 총수도 나열한다. 포렌식 출력의 나머지 부분은 이전 절의 –Status 출력과 유사해서 가장 많이 스캔된 포트, 상위 공격자, 서명 매칭 등에 대한 정보가 포함된다.

 psad는 포렌식 모드일 때 기본적으로 /var/log/messages 파일로부터 iptables 로그 메시지를 구문 분석한다. 이 경로는 다음과 같이 -m 명령 행 인자를 사용해서 변경할 수 있다.

 # psad -A -m /some/file/path

 * 상세/디버그 모드

 psad가 iptables 로그 메시지를 감시할 때 psad의 내부 동작을 알아보려면 –debug 스위치를 이용해서 psad를 상세 모드로 실행하면 된다.

# psad –debug

 이 스위치를 입력하면 psad는 데몬이 되지 않으며, 실행 도중 STDERR로 정보를 표시할 수 있게 된다. 이 정보에는 MAC 주소에서 수동적 OS 핑거프린팅 정보까지 모든 것이 포함된다.

6.psad 동작: 수상한 트래픽 탐지.

Posted on by
1

 * psad를 이용한 포트 스캔 탐지.

 TCP/IP 슈트 전체를 모두 구현하면 대규모의 복잡한 코드가 되며, 이러한 복잡도는 정탐 시도에서 서비스 거부 공격에 이르는 모든 공격의 좋은 목표가 된다.

 포트 스캔은 원격 목표에서 정보를 얻기 위한 중요한 기술로 psad는 기본적으로 리눅스 시스템을 위한 고급 포트 스캔 탐지 기능을 제공할 목적으로 개발됐다.

 3장에서와 마찬가지로 시스템을 포트 스캔하기 위해 Nmap을 사용한다. 그러나 이번에는 스캔 목표가 iptables 로그를 분석하기 위한 psad를 실행 중이다. Nmap을 사용해서 다음과 같은 종류의 포트 스캔을 생성하고 이를 psad가 어떻게 탐지하는지 알아보자.

 TCP connect() 스캔
 TCP SYN이나 반개방 스캔
 TCP FIN, XMAS, NULL 스캔
 UDP 스캔

 먼저 psad를 실행시키자.

 NMAP과 왕복시간.

 이 절의 스캔 예제 대부분에서 Nmap의 시간 관련 옵션(예를 들어 -T와 –max-rtt-timeout)은 Nmap이 얼마나 빨리 목표를 스캔할 수 있는지에 영향을 미친다. iptables는 로컬 스택이 각 스캔 탐사에게 전송할 수 있는 응답을 강하게 제한하기 때문에 Nmap이 절대로 받지 못한 응답을 기다리는 시간을 제한하는 것이 좋다. 예를 들어 Nmap이 포트 5000으로 SYN 패킷을 전송하는 경우 iptables는 이것을 버리기 때문에 목표 스택은 절대 Nmap이 기다리는 SYN/ACK이나 RST/ACK를 전송하지 않는다. (–max-rtt-timeout 옵션을 사용해서) Nmap이 이러한 응답을 기다리는 시간을 줄임으로써 시스템 스캔에 필요한 전체 시간을 단출할 수 있다(–max-rtt-timeout 값의 적절한 상향 값을 결정하는 방법 중 하나는 스캔 시작 전에 목표까지의 왕복 시간을 측정하기 위해 ping 유틸리티를 사용하는 것이다).

 – TCP connect() 스캔

 Nmap TCP connect() 스캐닝 모드(-sT)는 유닉스 방식의 운영체제에서는 특권을 가지지 않은 사용자도 이를 사용할 수 있다. 우선 목표 IP 주소 X.X.X.X에 대한 TCP connect() 스캔을 살펴보자.

soft-ftp:/etc# nmap -sT -n 117.17.172.120 –max-rtt-timeout 500

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2010-07-01 23:34 KST
Interesting ports on 117.17.172.120:
Not shown: 1672 filtered ports
PORT    STATE  SERVICE
20/tcp  closed ftp-data
21/tcp  open   ftp
22/tcp  open   ssh
43/tcp  closed whois
53/tcp  closed domain
80/tcp  open   http
443/tcp closed https
873/tcp closed rsync

 chd 1672 개 이상의 포트를 스캔 했지만, iptables 가 connection 시도의 대부분을 버리기 때문에 예상대로 거의 전부 필터링됐다. 스캔이 끝나면 psad가 스캔을 탐지했는지 알아보기 위해 /var/log/message 파일을 보자.

Jul  1 23:51:01 seclab psad: scan detected: Y.Y.Y.Y -> X.X.X.X tcp: [1-65301] flags: SYN tcp pkts: 1498 DL: 4
 Jul  1 23:51:06 seclab psad: scan detected: Y.Y.Y.Y -> X.X.X.X tcp: [44-13701] flags: SYN tcp pkts: 51 DL: 4

 psad syslog 메시지에서는 출발지와 목적지 IP 주소, 스캔된 TCP 포트의 범위(1 ~ 655301), 전송된 플래그(이 경우 SYN), 전송된 전체 패킷 수, psad가 이 스캐너에 할당한 위험 수준(DL:4)을 확인할 수 있다.

 이 경우 psad가 감시한 패킷 수는 1498 + 51개이며 이는 (/etc/psad/psad.conf 에 DANGER_LEVEL4 변수로 정의된) 위험 수준 4에 도달하기 위한 1500개를 넘는 수치이다. psad는 메일 경고도 생성하며 메일 경고에는 한 줄짜리 syslog 메시지에 담을 수 있는 것보다 훨씬 더 많은 정보가 포함된다.

 스캔하기 위해 psad가 사용한 iptables 로그 메시지를 보기 위해서 /var/log/psad/fwdata 파일을 살펴보자.

Jul  1 23:50:41 seclab kernel: [3742118.695465] DROP IN=eth0 OUT= MAC=00:21:5e:4e:bb:da:00:11:88:42:99:43:08:00 SRC=Y.Y.Y.Y DST=X.X.X.X LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=37394 DF PROTO=TCP SPT=50333 DPT=25 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A240A475B0000000001030304)
Jul  1 23:50:41 seclab kernel: [3742118.695615] DROP IN=eth0 OUT= MAC=00:21:5e:4e:bb:da:00:11:88:42:99:43:08:00 SRC=Y.Y.Y.Y DST=X.X.X.X LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=35732 DF PROTO=TCP SPT=43748 DPT=3389 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A240A475B0000000001030304)
Jul  1 23:50:41 seclab kernel: [3742118.695676] DROP IN=eth0 OUT= MAC=00:21:5e:4e:bb:da:00:11:88:42:99:43:08:00 SRC=Y.Y.Y.Y DST=X.X.X.X LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=44122 DF PROTO=TCP SPT=47712 DPT=1723 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A240A475B0000000001030304)
Jul  1 23:50:41 seclab kernel: [3742118.696293] DROP IN=eth0 OUT= MAC=00:21:5e:4e:bb:da:00:11:88:42:99:43:08:00 SRC=Y.Y.Y.Y DST=X.X.X.X LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=931 DF PROTO=TCP SPT=45962 DPT=389 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A240A475B0000000001030304)

  이제 로그를 분석해보자.

 먼저 출력 인터페이가 빈칸인 문자열 OUT= 은 로그 메시지를 생성한 패킷이 iptables INPUT 체인 내에서 LOG 규칙과 매칭됐는지 아니면 커널에서 라우팅 계산을 수행하기 전에 어떤 체인(예를 들어 raw 테이블의 PREROUTING 체인)의 LOG 규칙과 매칭됐는지 알려준다.

 iptables 로깅 형식은 LOG 규칙을 포함하는 iptables 체인을 명시적으로 포함하지 않기 때문에 위 로그 메시지로부터는 패킷이 INPUT 체인과 PREROUTING 체인 중 어느 쪽으로부터 기록됐는지 알 수 없다. 그러나 iptables 정책이 PREROUTING이나 POSTROUTING 체인보다는 INPUT, FORWARD, OUTPUT 체인에 더 많은 기본 LOG 규칙을 두기 때문에 psad는 오든 iptables 로그 메시지에 다음과 같은 규칙이 적용된다고 가정한다.

 – 출력 인터페이스를 포함하지 않는 메시지는 INPUT 체인에서 기록된 것이다.
 – 입력 인터페이스를 포함하지 않는 메시지는 OUTPUT 체인에서 기록된 것이다.
 – 입력과 출력 인터페이스를 모두 포함하는 메시지는 FORWARD 체인에서 기록된 것이다. 

 그러므로 앞서 논의한 TCP connect() 스캔의 경우 psad는 스캔이 INPUT 체인을 통해 기록됐다고 가정하며, iptables.sh 스크립트가 생성한 iptables 정책으로부터 따져보면 이것이 사실임을 알 수 있다. 출발지 IP 주소 Y.Y.Y.Y 는 로그 메시지에 포함되므로 psad는 스캔이 시작된 지점을 알 수 있다.

 – 때때로 스캔이 정교하게 스푸핑될 수 있기 때문에 이 IP 주소가 스캔의 실제 출발지라고 전적으로 믿을 수 없다는 사실을 기억하자. Nmap은 루트로 실행될 때 미끼(decoy) 옵션(-D)을 사용해서 스푸핑된 스캔을 전송할 수 있으며, Idle 스캔은 필수 구성 요소로 IP 스푸핑을 사용한다.

  다음으로 굵게 표시된 PROTO=TCP 와 이후의 항목들을 조합해 보면 스캔된 프로토콜과 포트, 사용된 플래그 등을 알 수 있다. 이 예에서 스캔 수행자는 TCP 포트에 관심이 있으며, 스캔 패킷은 SYN 플래그만을 설정하고 있다.

 앞선 connect() 스캔에서는 총 1672 개의 포트를 스캔했지만 /var/log/psad/fwdata 파일에 기록된 iptables 로그 메시지는 1498 + 51 개 뿐이라는 것을 상기하자. 이 차이는 iptables가 로그 메시지를 생성하는 속도와 Nmap으로부터의 SYN 패킷 재전송이라는 두 가지 요소에서 기인한다. 내부적으로는 iptables는 커널 내의 고리 버퍼에 기록하기 때문에 이전 메시지를 명명된 파이프 /var/lib/psad/psadfifo 에 기록하기 전에 새로운 메시지로 고리 버퍼를 덮어쓸 수 있을 정돞포 트래픽 속도가 빠르다면 이전 메시지는 손실된다. 트레이드 오프는 몇 개의 로깅 메시지를 잃는 대신 시스템이 어느 정도 안정된 수준을 유지하며 작업을 지속할 수 있다는 것이다.(이는 좋은 트레이드오프로 볼 수 있다). Nmap은 주로 응답하지 않는 포트당 하나의 재시도 패킷을 전송하기 때문에 이 예의 스캔에서 Nmap은 실제로 이보다 더 많은 패킷을 전송했다.

 – TCP SYN 이나 반개방 스캔

 이제 Nmap의 SYN(또는 반개방) 스캔 방법을 살펴보자. SYN 스캔은 Nmap이 특권 사용자에 의해 실행될 때의 기본 스캔 방식이다(실제로 이 스캔을 포함한 기타 흥미로누 Nmap 스캔 방식이 원시 소켓으로의 접근을 필요로 하기 째문에 특권 사용자만이 실행할 수 있다).

 목표 시스템의 iptables 방화벽이 TCP 포트 80으로 전송되는 모든 SYN 패킷을 버리게 설정됐기 때문에 네트워크상에서 SYN 스캔은 정규 TCP connect() 스캔과 거의 동일하게 보이는데, 이는 스캐너의 TCP 스택이 응답해야 하는 SYN/ACK 패킷이 거의 없기 때문이다. 동일한 출발지 주소로부터의 SYN 패킷을 볼 수 있을 뿐 그 밖의 어떤 것도 볼 수 없다.

 이러한 논증이 이론적으로는 일반적으로 정당해 보이지만 실제로는 SYN 스캔과 connect() 스캔 모두에서 iptables이 초기 SYN 패킷을 버림에도 불구하고 두 스캔간에는 몇 가지 중대한 차이점이 존재한다. 이러한 차이점은 SYN 스캔 모드의 Nmap이 전송한 SYN 패킷과 Nmap connect() 스캔을 통해 TCP 스택 자체가 전송한 SYN 패킷과 Nmap connect() 스캔을 통해 TCP 스택 자체가 전송한 SYN 패킷의 특정 패킷 헤더 항목에 존재한다. 3장에서 살펴보았듯이 SYN 스캔보다 connect() 스캔에 의해 전송되는 TCP 옵션이 훨씬 더 많다.

 아래 명령어를 통해 IP 주소가 X.X.X.X 에 대한 SYN 스캔을 시작한다.

soft-ftp:/etc# nmap -n X.X.X.X –max-rtt-timeout 500

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2010-07-02 01:01 KST
Interesting ports on X.X.X.X:
Not shown: 1672 filtered ports
PORT    STATE  SERVICE
20/tcp  closed ftp-data
21/tcp  open   ftp
22/tcp  open   ssh
43/tcp  closed whois
53/tcp  closed domain
80/tcp  open   http
443/tcp closed https
873/tcp closed rsync

Nmap finished: 1 IP address (1 host up) scanned in 19.909 seconds

 /var/log/message 파일을 보면 psad가 이 스캔을 탐지 했음을 알 수 있다.

Jul  2 01:17:54 seclab psad: scan detected: Y.Y.Y.Y -> X.X.X.X tcp: [5-61439] flags: SYN tcp pkts: 1002 DL: 4
Jul  2 01:18:01 seclab psad: scan detected: Y.Y.Y.Y -> X.X.X.X tcp: [2-65301] flags: SYN tcp pkts: 1166 DL: 4
Jul  2 01:18:06 seclab psad: scan detected: Y.Y.Y.Y -> X.X.X.X tcp: [7-44334] flags: SYN tcp pkts: 469 DL: 4

  3차례에 걸쳐 1500 개가 넘는 패킷이 전송됐으며, 이는 psad.conf 파일의 DANGER_LEVEL4 보다 크기 때문에 스캐너는 위험 수준 4에 도달했다.

 connect() 스캔에서와 같이 목표 시스템의 iptables는 tmzosdml SYN 패킷을 기록했다.

Jul  2 01:18:02 seclab kernel: [3747359.638824] DROP IN=eth0 OUT= MAC=00:21:5e:4e:bb:da:00:11:88:42:99:43:08:00 SRC=210.125.219.48 DST=117.17.172.120 LEN=44 TOS=0x00 PREC=0x00 TTL=53 ID=14339 PROTO=TCP SPT=61604 DPT=1413 WINDOW=4096 RES=0x00 SYN URGP=0 OPT (020405B4)

이번에는 iptables 로그 메시에서 TCP connect() 스캔과 다른 부분을 굵게 나타냈다. 이 항목과 이들이 connect() 스캔과 다른 이유는 다음과 같다.

 – LEN : IP 헤더의 길이 항목으로 실제 TCP 스택은 SYN 패킷에 connect() 스캔을 통해 전송하는 SYN 패킷보다 더 많은 옵션을 포함하기 때문에 SYN 스캔이 14 바이트만큼 짧다.

 – TTL : IP 헤더의 해킷 유지 시간(TTL, Time-to-Live) 값은 TCP connect() 스캔 동안 클라이언트 시스템의 실제 IP 스택에 의해 항상 동일한 값으로 초기화된다. 그러나 SYN 스캔 시 Nmap은 TCP SYN 패킷을 직접 생성하기 때문에 TTL 값을 어떤 값으로도 설정할 수 있으며, Nmap은 37과 60 사이의 TTL 값 중 하나를 무작위로 선택한다.

 – WINDOW : Nmap이 SYN 스캔 동안 설정하는 TCP 윈도우 크기는 1024, 2048, 3072, 4096 중 하나다. 반면 실제 TCP 스택은 TCP 연결을 항상 윈도우 크기 5840으로 초기화한다.

 – OPT : TCP 헤더의 옵션 부분은 Nmap SYN 스캔의 경우가 훨씬 더 짧다. 이 예에서 Nmap은 최대 세그먼트 크기 옵션만을 사용하며 이를 1460으로 설정한다. 대부분의 실제 TCP 스택은 최대 세그먼트 크기 외에도 타임스탬프, 연산 없음(NOP), 선택적 승인이 가능한지 여부(SACK)와 같이 다수의 옵션을 전송한다.

 * psad 를 이용한 경고와 보고.

 psad는 일단 iptables에 대해 수상한 하나의 이벤트나 이벤트들이 발생했다고 판단하면 관리자에게 경고한다. psad 의 목표는 관리자가 적절한 응답을 선택할 수 있게 최대한 많은 정보를 제공하는 것이다.

 – psad 메일 경고.

 메일 메시지는 syslog 경고보다 훨씬 더 많은 정보를 포함할 수 있으며, 어디서나 확인할 수 있고 휴대폰이나 기타 휴대 장비와 잘 통합돼 있기 때문에 메일은 psad의 제 1차 경고 기법이다.

Message 1054537:
From root@A.B.C.D  Thu Jul  1 23:23:40 2010
X-Original-To: root@localhost
To: root@localhost
Subject: [psad-alert] DL5 src: 169.254.X.X dst: 255.255.255.255
Date: Thu,  1 Jul 2010 23:23:39 +0900 (KST)
From: root@A.B.C.D (root)

=-=-=-=-=-=-=-=-=-=-=-= Thu Jul  1 23:23:39 2010 =-=-=-=-=-=-=-=-=-=-=-=

* 스캔 위험 수준, 포트, 플래그——————————————-
         Danger level: [5] (out of 5)

    Scanned UDP ports: [67: 1 packets, Nmap: -sU]
       iptables chain: INPUT (prefix “DROP”), 1 packets

* 출발지와 목적지 IP 주소 ——————————————–
               Source: 169.254.X.X
                  DNS: [No reverse dns info available]

          Destination: 255.255.255.255
                  DNS: [No reverse dns info available]

* syslog 호스트명, 시간 간격, 요약 정보 ———————————
   Overall scan start: Tue Nov 24 21:47:43 2009
   Total email alerts: 167109
      Syslog hostname: seclab

         Global stats: chain:   interface:   TCP:   UDP:   ICMP: 
                       INPUT    eth0         0      36101  0     

* whois 데이터베이스 정보 ——————————————–
[+] Whois Information:

OrgName:    Internet Assigned Numbers Authority
OrgID:      IANA
Address:    4676 Admiralty Way, Suite 330
City:       Marina del Rey
StateProv:  CA
PostalCode: 90292-6695
Country:    US

NetRange:   169.254.0.0 – 169.254.255.255
CIDR:       169.254.0.0/16
NetName:    LINKLOCAL-RFC3927-IANA-RESERVED
NetHandle:  NET-169-254-0-0-1
Parent:     NET-169-0-0-0-0
NetType:    IANA Special Use
NameServer: BLACKHOLE-1.IANA.ORG
NameServer: BLACKHOLE-2.IANA.ORG
Comment:    This is the “link local” block. It was set
Comment:    aside for this special use in the Standards
Comment:    Track document, RFC 3927 and was further
Comment:    documented in the Best Current Practice
Comment:    RFC 5735, which can  be found at:
Comment:    http://www.rfc-editor.org/rfc/rfc3927.txt
Comment:    http://www.rfc-editor.org/rfc/rfc5735.txt
Comment:    It is allocated for communication between hosts
Comment:    on a single link. Hosts obtain these addresses
Comment:    by auto-configuration, such as when a DHCP
Comment:    server cannot be found.
Comment:    A router MUST NOT forward a packet with an IPv4
Comment:    Link-Local source or destination address,
Comment:    irrespective  of the router’s default route configuration
Comment:    or routes obtained from dynamic routing protocols.
Comment:    A  router which receives a packet with an IPv4
Comment:    Link-Local source or destination address MUST NOT
Comment:    forward the packet. This prevents forwarding of
Comment:    packets back onto the network segment from which
Comment:    they originated, or to any other segment.
RegDate:    1998-01-27
Updated:    2010-03-15

OrgAbuseHandle: IANA-IP-ARIN
OrgAbuseName:   Internet Corporation for Assigned Names and Number
OrgAbusePhone:  +1-310-301-5820
OrgAbuseEmail:  abuse@iana.org

OrgTechHandle: IANA-IP-ARIN
OrgTechName:   Internet Corporation for Assigned Names and Number
OrgTechPhone:  +1-310-301-5820
OrgTechEmail:  abuse@iana.org

# ARIN WHOIS database, last updated 2010-06-30 20:00
# Enter ? for additional hints on searching ARIN’s WHOIS database.
#
# ARIN WHOIS data and services are subject to the Terms of Use
# available at https://www.arin.net/whois_tou.html
#
# Attention! Changes are coming to ARIN’s Whois service on June 26.
# See https://www.arin.net/features/whois for details on the improvements.

 * psad syslog 보고.

 메일 경고와 함께 syslog도 psad의 중요한 보고 기법이다. 보통 psad는 동작하는 동안 세 종류의 syslog 경고를 생성한다.

 – 정보 메시지

 psad는 주기적으로 psad가 수행한 관리 동작을 관리자에게 알려주기 위해 설계된 정보 syslog 메시지를 생성하며, 이에는 설정 파일 읽어오기와 이전 psad 실행으로부터의 스캔 정보 등이 있다.

 예를 들어 psad는 시작할때 다음과 같은 syslog 메시지를 생성한다.

Jul  1 23:50:13 seclab psad: imported valid icmp types and codes
Jul  1 23:50:13 seclab psad: imported p0f-based passive OS fingerprinting signatures
Jul  1 23:50:13 seclab psad: imported TOS-based passive OS fingerprinting signatures
Jul  1 23:50:13 seclab psad: imported auto_dl, got 0 IP addresses and 1 networks
Jul  1 23:50:14 seclab psad: imported original Snort rules in /etc/psad/snort_rules/ for reference info
Jul  1 23:50:14 seclab psad: imported 205 psad Snort signatures from /etc/psad/signatures
Jul  1 23:50:16 seclab psad: imported 239 scanning IP addresses from previous psad instance

 – 스캔과 서명 매칭 메시지

 syslog 메시지의 가장 중요한 부분은 스캔과 기타 수상한 트래픽에 대해 알려준다. 이러한 메시지는 출발지 IP 주소에서 포트, 프로토콜, 스노트 규칙 매칭에 이르는 모든 것을 포함하며, 다음과 같은 syslog 메시지는 psad 스캔 경고를 보여준다. 이 메시지는 psad가 탐지한 스캔 유형을 사용자가 식별할 수 있게 TCP 플래그 정보도 포함한다.

Jul  1 23:50:25 seclab kernel: [3742102.777745] DROP IN=eth0 OUT= MAC=ff:ff:ff:ff:ff:ff:00:25:11:48:00:69:08:00 SRC=X.X.X.X DST=255.255.255.255 LEN=68 TOS=0x00 PREC=0x00 TTL=128 ID=10689 PROTO=UDP SPT=1037 DPT=1947 LEN=48
Jul  1 23:50:41 seclab kernel: [3742118.698007] DROP IN=eth0 OUT= MAC=00:21:5e:4e:bb:da:00:11:88:42:99:43:08:00 SRC=X.X.X.X DST=Y.Y.Y.Y LEN=60 TOS=0x00 PREC=0x00 TTL=62 ID=42913 DF PROTO=TCP SPT=50650 DPT=1453 WINDOW=5840 RES=0x00 SYN URGP=0 OPT (020405B40402080A240A475B0000000001030304)

 – 자동 응답 메시지
 
 트래픽 출발지 IP 주소에 대해 iptables 차단 규칙을 적용함으로써 psad를 사용해서 수상한 트래픽에 응답할 수 있다. 이 기능은 기본적으로 비활성화돼 있다.

 * 정리

 6장에서는 Nmap을 이용해서 iptablesfw 시스템에 수행한 포트 스캔을 psad가 탐지하고 보고하는 것과 같은 psad 동작 측면을 소개했다. 메일 경고가 psad의 제1차 경고 기법이지만 psad는 syslog 경고도 제공한다. 7장에서는 iptables 로그 메시지를 통해 스노트 규칙과 매칭되는 트래픽의 탐지와 같이 좀 더 어려운 psad 관련 주제를 살펴본다.