Why top and ps not showing the same cpu result

왜 ps 와 top 은 서로 다른 cpu 사용률을 보여주는 것일까? 결론부터 이야기하면, top 과 ps 는 서로 다른 명령어이다.

top 은 우리가 흔히 생각하는 cpu 사용률을 보여주는 것이 맞지만, ps 는 약간 다른 부분을 보여준다. 다음은 ps 명령어의 man page 의 일부분이다.

CPU usage is currently expressed as the percentage of time spent running during the entire lifetime of a process.  This is not ideal, and it does not conform to the standards that ps otherwise conforms to.  CPU usage is unlikely to add up to exactly 100%.

즉, ps 명령어는 프로세스가 동작한 전체 시간에서의 cpu 점유율을 나타낸다는 것이다. 따라서 지정된 시간 동안에서의 cpu 점유율을 보여주는 top 과는 서로 다른 결과를 보여줄 수 밖에 없는 것이다.

top 은 모니터링, ps 는 스냅샷으로 생각을 하면 이해가 쉬워진다.

참조: http://unix.stackexchange.com/questions/58539/top-and-ps-not-showing-the-same-cpu-result

stack smashing detected

프로그램 TEST 중 아래와 같은 오류가 발생했다.

결과는 Core dump.

jonathan@jonathan-laptop:~/workspace/TEST$ ./TEST
*** stack smashing detected ***: ./TEST terminated
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6(__fortify_fail+0x50)[0xb775c390]
/lib/tls/i686/cmov/libc.so.6(+0xe233a)[0xb775c33a]
./TEST[0x804a2f4]
./TEST[0x8049189]
./TEST[0x8049258]
./TEST[0x8049205]
/lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7690bd6]
./TEST[0x8049081]
======= Memory map: ========
08048000-0804f000 r-xp 00000000 08:05 7344439    /home/jonathan/workspace/TEST/TEST
0804f000-08050000 r–p 00007000 08:05 7344439    /home/jonathan/workspace/TEST/TEST
08050000-08051000 rw-p 00008000 08:05 7344439    /home/jonathan/workspace/TEST/TEST
08051000-080fd000 rw-p 00000000 00:00 0
09a2c000-09a4d000 rw-p 00000000 00:00 0          [heap]
b763d000-b765a000 r-xp 00000000 08:05 4849747    /lib/libgcc_s.so.1
b765a000-b765b000 r–p 0001c000 08:05 4849747    /lib/libgcc_s.so.1
b765b000-b765c000 rw-p 0001d000 08:05 4849747    /lib/libgcc_s.so.1
b7678000-b767a000 rw-p 00000000 00:00 0
b767a000-b77cd000 r-xp 00000000 08:05 4984558    /lib/tls/i686/cmov/libc-2.11.1.so
b77cd000-b77ce000 —p 00153000 08:05 4984558    /lib/tls/i686/cmov/libc-2.11.1.so
b77ce000-b77d0000 r–p 00153000 08:05 4984558    /lib/tls/i686/cmov/libc-2.11.1.so
b77d0000-b77d1000 rw-p 00155000 08:05 4984558    /lib/tls/i686/cmov/libc-2.11.1.so
b77d1000-b77d4000 rw-p 00000000 00:00 0
b77ef000-b77f2000 rw-p 00000000 00:00 0
b77f2000-b77f3000 r-xp 00000000 00:00 0          [vdso]
b77f3000-b780e000 r-xp 00000000 08:05 4855235    /lib/ld-2.11.1.so
b780e000-b780f000 r–p 0001a000 08:05 4855235    /lib/ld-2.11.1.so
b780f000-b7810000 rw-p 0001b000 08:05 4855235    /lib/ld-2.11.1.so
bff3e000-bff53000 rw-p 00000000 00:00 0          [stack]
Aborted (core dumped)

원인 분석을 위해 코어 파일과 함께 gdb를 실행 시켜 보았다.

jonathan@jonathan-laptop:~/workspace/TEST$ gdb -c core TEST
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type “show copying”
and “show warranty” for details.
This GDB was configured as “i486-linux-gnu”.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>…
Reading symbols from /home/jonathan/workspace/TEST/TEST…done.
[New Thread 5966]

warning: Can’t read pathname for load map: Input/output error.
Reading symbols from /lib/tls/i686/cmov/libc.so.6…(no debugging symbols found)…done.
Loaded symbols for /lib/tls/i686/cmov/libc.so.6
Reading symbols from /lib/ld-linux.so.2…(no debugging symbols found)…done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libgcc_s.so.1…Reading symbols from /usr/lib/debug/lib/libgcc_s.so.1…done.
done.
Loaded symbols for /lib/libgcc_s.so.1
Core was generated by `./TEST’.
Program terminated with signal 6, Aborted.
#0  0xb77f2430 in __kernel_vsyscall ()
(gdb) where
#0  0xb77f2430 in __kernel_vsyscall ()
#1  0xb76a4651 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb76a7a82 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb76db49d in ?? () from /lib/tls/i686/cmov/libc.so.6
#4  0xb775c390 in __fortify_fail () from /lib/tls/i686/cmov/libc.so.6
#5  0xb775c33a in __stack_chk_fail () from /lib/tls/i686/cmov/libc.so.6
#6  0x0804a2f4 in TestHeadMake () at test.c:515
#7  0x08049189 in TestLog (loglvl=1, title=0x804df59 “TEST”, fmt=0x804df57 “n”) at test.c:196
#8  0x08049258 in StartMessage () at test.c:237
#9  0x08049205 in main (argc=1, argv=0xbff509a4) at test.c:218

문제는 간단했다.

함수 TestHeadMake() 내에서 사용하는 문자열 버퍼 timeStr 의 사이즈가 데이터를 담기에 작았던 것.

바로 찾아서 해결을… 했으면 좋았겠지만 한참을 찾았다…;;

배포판에 설치된 GCC 버전정보

 Linux/Unix 프로그래밍을 하다보면 GCC 버전에 영향을 받는 경우가 있다.

 예를 들면 ACE 라이브러리를 컴파일 할 경우, gcc-4.x 대의 버전에는 컴파일 오류가 발생한다.

 그래서 부득이 gcc/g++ 을 다시 설치하려고 해도 여의치 않는 경우가 많다. 이럴 경우 다른 배포판을 찾아보게 되는데, 여기에 배포판마다 가지고 있는 gcc의 버전 정보를 싣는다.

Distribution Version Compiler version Provided by Date
BeOS R5.1, Zeta gcc 2.9-beos-000224 Yuri Kiryanov 18 June 2004
Debian Release 2.2 gcc 2.95.2 Craig Southeren <craigs@postincrement.com> 15 June 2004
Release 3.0
(Woody)
gcc 2.95.4 Craig Southeren <craigs@postincrement.com> 11 June 2004
Sarge gcc 3.3.5 (final stable version)
gcc 3.3.3 (interim releases)

Kilian Krause <kk@verfaction.de>
15 June 2005
Sid gcc 4.0.1 Kilian Krause <kk@verfaction.de> 19 July 2004
FreeBSD Release 4.8 gcc 2.95.4 Craig Southeren <craigs@postincrement.com> 15 June 2004
Release 4.9
(Stable)
gcc 2.95.4 20020320 Pavel Pavlov <block111@mail.ru> 14 June 2004
Gentoo Stable gcc 3.3.3 Brian Raymond <brian.raymond@dataline.com> 11 June 2004
Mandrake Release 7 (Air) gcc 2.95.2 Craig Southeren <craigs@postincrement.com> 11 June 2004
Release 9.1 gcc 3.2.2 Rene Schallner <rs@rocksolid.at> 11 June 2004
Release 9.2 (FiveStar) gcc 3.3.1 Alexandre Aractingi <aaractingi@libertysurf.fr> 11 June 2004
Release 10.0 gcc 3.3.2 Rene Schallner <rs@rocksolid.at> 11 June 2004
Release 10.1 gcc 3.4.1 Frederic Crozat <fcrozat@mandrakesoft.com> 30 Sep 2004
MontaVista Professional 3.1
for XScale
gcc version 3.3.1 (MontaVista 3.3.1-3.0.10.0300532 2003-12-24) Yuri Kiryanov 18 June 2004
NetBSD Release 1.6.1 gcc 2.95.3 Craig Southeren <craigs@postincrement.com> 15 June 2004
OSX 10.1 Server Edition gcc 2.95.2 Craig Southeren <craigs@postincrement.com> 15 June 2004
10.2 Jaguar gcc 3.1 Malcolm Caldwell <malcolm.caldwell@ntu.edu.au> 11 June 2004
10.2 Server Edition gcc 3.3 20030304 Craig Southeren <craigs@postincrement.com> 15 June 2004
10.3 Panther gcc 3.3 20030304 Brian Raymond <brian.raymond@dataline.com> 22 June 2004
10.4 Tiger gcc 4.0.0
(powerpc-apple-darwin8-gcc-4.0.0)
Hannes Friederich <hannesf@ee.ethz.ch> 15 June 2005
OpenBSD Release 3.4 gcc 2.95.3 Craig Southeren <craigs@postincrement.com> 15 June 2004
Red Hat Release 6.1
(Cartman)
gcc egcs-2.91.66 Bruce Ferrell <bferrell@baywinds.org> 11 June 2004
Release 6.2 (Zoot) gcc egcs-2.91.66 Alexandre Aractingi <aaractingi@libertysurf.fr>  
Release 7.3 (Valhalla) gcc 2.96 20040412 Malcolm Caldwell <malcolm.caldwell@ntu.edu.au> 11 June 2004
Release 8.0A (Second-Edition) gcc 3.2 20020903
(Red Hat Linux 8.0 3.2-7)
Federico Pinna <f.pinna@reitek.com> 11 June 2004
Release 9 (Shrike) gcc 3.2.2
(gcc 2.96 available as “gcc296”)
Craig Southeren <craigs@postincrement.com> 11 June 2004
Advanced Server release 2.1AS/m
(Pensacola)
gcc 2.96 Malcolm Caldwell <malcolm.caldwell@ntu.edu.au> 11 June 2004
Enterprise Linux AS release 3
(Taroon Update 2)
gcc 3.2.3 Malcolm Caldwell <malcolm.caldwell@ntu.edu.au> 11 June 2004
Fedora Core 1 gcc 3.2.2 / gcc 3.2.3 Craig Southeren
<craigs@postincrement.com>
11 June 2004
Fedora Core 2 gcc 3.4.0 / gcc 3.3.3 Derek Smithies <derek@indranet.co.nz> 11 June 2004
Fedora Core 3 gcc 3.4.2 / gcc 4.0.0 Craig Southeren
<craigs@postincrement.com>
14 June 2005
Fedora Core 4 gcc 4.0.0 Craig Southeren
<craigs@postincrement.com>
14 June 2005
Slackware Version 9.1 gcc 3.2.3 Craig Southeren <craigs@postincrement.com> 11 June 2004
Version 10.0 gcc 3.3.4 Craig Southeren <craigs@postincrement.com> 24 June 2004
Suse Release 8 ES on AMD64 gcc 3.2.2 Craig Southeren <craigs@postincrement.com> 15 June 2004
Version 9.0 gcc 3.3.1 Jan Willamowius <jan@willamowius.de> 11 June 2004
Version 9.1 gcc 3.3.3 Kilian Krause <kk@verfaction.de> 17 June 2004
Tornado
(VxWorks)
2.0.1 for ARM gcc 2.7.9-970819
egcs-971225 tornado 2.0
Mark DeBruin
mark.de.bruin@philips.com
11 June 2004
2.1.1 for ARM gcc 2.9-010413 Mark DeBruin
mark.de.bruin@philips.com
11 June 2004
2.1.1 for MIPS gcc 2.96 Mark DeBruin
mark.de.bruin@philips.com
11 June 2004
2.2.1 for MIPS gcc 2.96-mips3264-010729 Mark DeBruin
mark.de.bruin@philips.com
26 August 2004
2.2.1 for XScale gcc 2.9-010413 Mark DeBruin
mark.de.bruin@philips.com
11 June 2004

 출처 : http://www.voxgratia.org/docs/compilers.html#intro

11.psad와 fwsnort의 결합

 * 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 기능을 활성화해야 한다. 포트 스캔이나 기타 쉽게 스푸핑 가능한 트래픽에 응답하는 것은 너무나 쉽게 악용될 수 있다.