Tag Archives: iptables

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

9.스노트 규칙을 iptables 규칙으로 변환

Posted on by
Reply

 * 들어가며..

 스노트 규칙을 항상 깔끔하게 변활할 수는 없으며, 스노트 규칙 언어는 매우 복잡하기 때문에 fwsnort는 스노트 버전 2.3.3 에 포함된 규칙의 약 60% 정도를 변환할 수 있다.

 fwsnort가 전체 스노트 서명 집합을 iptables 규칙으로 변활할 수는 없지만 fwsnort 는 항상 네트워크 트래픽에 인라인으로 배치된다. 스노트는 주로 수동적 전략으로 배치되며 네트워크 트래픽에서 수상한 활동을 감시하는 데 쓰인다. 즉, 스노트는 인라인 기능을 지원함에도 불구하고 대개 인라인으로 배치되지 않는다. fwsnort가 생성한 모든 정책은 수동적 패킷 조사에 국한되지 않는다. fwsnort가 생성한 모든 정책은 수동적 패킷 조사에 국한되지 않는다. fwsnort 정책은 iptables DROP 타켓을 통해 악의적인 패킷을 버리게 설정할 수 있다.

 스노트 규칙 언어의 융통성과 완결성은 스노트가 네트워크 기반 공격의 설명적 표현을 검색할 수 있게 해주며, 공격이 네트워크를 통해 전송될 때 이에 응답할 수 있게 해준다. 이것이 스노트를 최고의 네트워크 침입 탐지와 방지 도구의 하나로 굳게 자리매김해준 기능이다.

 그러나 좋은 침입 방지 시스템(IPS)이 효과적인 방화벽의 완벽한 대체 수단이 되는 것은 절대 아니다. 방화벽과 침입 방지 시스템은 일반적으로 서로 반대 관점에서 보안 강화에 접근한다. 방화벽은 보안 정책에 기반해서 허용 가능한 트래픽을 정의하고 정책을 따르지 않는 트래픽을 차단(그리고 기록)한다. 반면 침입 방지 시스템은 허용할 수 없는 네트워크 트래픽을 정의하고 이런 활동만 차단(또는 응답)한다.

 이와 동시에 방화벽과 IPS 구현의 경계는 이 둘이 융합하면서 점차 불분명해지기 시작했다. 방화벽은 좀 더 많은 애플리케이션 계층 처리 기능(오랫동안 침입 탐지 시스템만의 기능이었다)을 가지게 됐고 침입 방지 시스템은 애플리케이션 계층 처리와 독립적인 기본적인 필터링 기능을 제공하게 되었다.

 * fwsnort를 사용해야 하는 이유

 fwsnort 프로젝트는 리눅스 시스템과 통신하게 허용되는 패킷의 유형을 제어하는 리눅스 커널의 기능을 향상시키는 데 초점을 두고 있다. 스노트 서명 언어의 강력함에 리눅스 커널의 속도와 iptables 명령의 간결성을 결합함으로써 fwsnort는 기존 IPD/IPS 인프라스트럭처의 보안 전략을 보완할 수 있다. fwsnort 는 단순히 iptables 명령을 실행(주로 말단 호스트에서 실행)하는 쉘 스크립트를 작성하기 때문에 fwsnort를 다른 IDS/IPS와 함께 배치하는 것은 매우 쉽다. 더욱이 iptables는 네트워크 트래픽에 항상 인라인이기 때문에 안정성과 속도 측면에서 엄격하게 테스트됐다.

 ** 철저한 방어

 긍정 오류를 생성하게 하는 방법으로 IDS 경고 기능을 전복하려는 시도에서 IDS 내에 존재하는 취약점을 이용해서 코드를 실행하려는 시도에 이르기까지 침입 탐지 시스템 자체가 공격 목표가 되는 경우도 많다.

 철저한 방어의 원리는 전형적인 컴퓨터 시스템(서버와 데스크톱)뿐만 아니라 방화벽이나 침입 탐지 시스템과 같은 보안 인프라스트럭처에도 적용된다. 그러므로 기존의 침입 탐지/방지 시스템을 추가적인 방법으로 보충할 여지가 있다.

 ** 목표 기반 침입 탐지와 네트워크 계층 비단편화

 IDS 에 탐지 동작과 말단 호스트의 특징을 결합할 수 있게 해주는 기능을 추가하는 것을 목표 기반 침입 탐지(target-based intrusion detection)이라고 한다.

 예를 들어 윈도우 시스템에 대해 단편화된 공격이 전송되는데, 스노트는 리눅스 IP 스택이 사용하는 알고리즘으로 공격을 비단편화한다면 공격을 놓치거나 잘못 보고할 수 있다.

  fwsnort 의 경우(공격자가 목표로 삼은 동일한 시스템에 로컬하게 배치될 때는 특히) 단편화 문제에 대해 신경 쓸 필요가 없다. fwsnort 에 적용된 단편화 알고리즘은 실제 공격 대상 IP 스택의 알고리즘이기 때문이다. fwsnort를 사용하면 네트워크 단편화는 (패킷을 올바른 연결로 분류하기 위해 트래픽을 비단편화해야 하는) 넷필터 연결추적 하위시스템을 fwsnort 정책과 함께 사용하는 방법으로 수행된다. fwsnort가 수행하는 애플리케이션 계층 조사는 리눅스 IP 스택이 이미 트래픽을 단편화한 후에 일어난다.

 – fwsnort와 iptables를 이용하면 단편화된 공격에 대해서는 덜 걱정해도 되지만 목표 기반 침입 탐지의 장점이 네트워크 단편화 문제 때문에 제한되는 것은 아니며 단편화 문제는 IDS 커뮤니티에서 활발한 연구 개발이 진행 중인 분야다. 예를 들어 IDS는 잠재적인 긍정 오류를 판별하거나 보고된 공격의 심각성을 좀 더 정확히 판단하기 위해 OS와 애플리케이션 정보를 사용할 수 있다. 예를 들어 마이크로소프트 IIS 웹서버의 버퍼 오버플로우를 이용하는 공격은 아파치 웹서버로 전송되면 목표에 절대 침투할 수 없다. IDS가 이공격을 탐지하는 경우 이벤트의 심각성은 공격이 실제 IIS 서버로 전달됐을 때보다 상당히 낮아야 한다.

 ** 적은 자원 사용

 사용량이 많은 시스템은 침입 탐지를 위해 사용자 프로세스(예를 들어 스노트)를 추가로 실행하기에는 자원이 부족할 수 있다. fwsnort의 경우 패킷 조사가 리눅스 커널 내부에서 직접 일어나며, 이는 주로 시스템 자원을 조금만 사용한다. (일반적인 IPS와 달리) 커널 공간에서 사용자 공간 프로세스로 메모리를 복사할 필요가 없다. 자원 제약 때문에 IDS/IPS 를 설치하기 힘든 시스템이라면 fwsnort 가 적절한 대안이다.

 ** 인라인 응답

 fwsnort가 생성하는 iptables 서명 정책은 항상 네트워크 트래픽에 인라인이기 때문에 특히 악의적인 특정 공격에 조치를 취할 때에는 iptables 이 이상적일 수 있다.

 서버의 가동 시간이 서비스 수준 계약서 (SLA, Service Level Agreement)를 따라야 하는 경우에는 서버를 중단하고 패치하기 전에 대기 시간이 있을 수 있다. 물론 이는 취약점을 수정할 패치가 존재한다고 가정한다(그러나 패치가 항상 존재하는 것은 아니다). 패치를 적용하기 위해 서비스 중단 시간을 잡을 수 있기 전까지는 사용자가 서버 소프트웨어를 이용할 수 있어야 한다면 인라인 방지 기법이 취약점에 대한 공격으로부터 서버를 적절히 보호할 수 있다(또 fwsnort 정책은 경량이기 때문에 대개는 인라인 모드로 실행중인 스노트와 같은 다른 방지 기법과 함께 배치될 수 있다).

 – fwsnort는 단순히 iptables를 실행하기 위한 쉘 스크립트를 작성하기 때문에 SSH를 통해 한번에 여러 원격 시스템에 명령어를 실행할 수 있는 제노스(Zenoss, http://www.zenos.org)와 같은 것을 갖춘 시스템에 쉽게 배치할 수 있다. Zenoss 는 시스템 인프라스터럭처의 모든 리눅스 시스템에 fwsnort 를 쉽게 배치할 수 있게 해준다.

 * fwsnort의 스노트 규칙 해석

 스노트가 제공하는 기능에 비해 iptables가 제공하는 기능이 가지는 한계 때문에 모든 스노트 규칙이 변환될 수 있는 건 아니다. 뒤에서 설명하겠지만 스노트가 제공하는 기능에 비해 iptables가 제공하는 기능이 가지는 한계 때문에 모든 스노트 규칙이 변환될 수 있는 건 아니다.

 네트워크 기반 공격은 굉장히 큰 가변성을 가진다. 엄청난 속도로 모든 종류의 소프트웨어에 대해 새로 발표되는 취약점뿐만 아니라 불명확한 방식으로 이런 취약점을 사용하는 TCP/IP 와 애플리케이션 API도 공격 전달을 가능하게 한다. 패킷 단편화, TCP 세션 결합(TCP session spicing), 다양한 애플리케이션 인코딩, 그리고 이와 유사한 것 때문에 단순히 트래픽이 네트워크를 통해 아무 문제없이 전송될 때 이를 감시하는 수동적 감시 시스템이 공격을 탐지하기는 더욱 어렵다.

 ** 스노트 규칙 헤더 변환

  스노트 규칙은 규칙 헤더와 규칙 옵션이라는 두 개의 주요 부분으로 나뉜다. 규칙 헤더는 네트워크와 전송 계층의 매칭 기준을 엄격히 정의한다. 애플리케이션 계층 매칭 기준은 스노트 규칙 헤더에 존재할 수 없다.

 – 스노트 규칙 헤더

 예를 들어 스노트가 임의의 출발지 IP 주소에서 192.168.10.0/24 서브넷에 존재하는 임의의 IP 주소의 포트 53으로 전송되는 모든 TCP 트래픽과 매칭시키게 지시하는 스노트 규칙 헤더는 다음과 같다.

 alret tcp any any -> 192.168.10.0/24 53

 서명 관점에서 이 헤더는 다음과 같이 iptables 명령과 비슷하다.

# iptables -A FORWARD -p tcp -d 192.168.10.0/24 –dport 53 -j LOG

  우선 스노트는 규칙 헤더에서 직접 IP, ARP, UDP, ICMP, TCP 를 지원한다(다른 프로토콜은 뒤에서 보이지 않게 지원한다). 다음으로 스노트 규칙은 스노트 규칙 헤더의 주소 부분을 통해 네트워크나 개별 IP 주소에 적용될 수 있다. 네트워크는 CIDR 표기법(예를 들어 192.168.10.0/24)이나 표준 도트 4자리 표기법(예를 들어 192.168.10.0/255.255.255.0)으로 명시할 수 있다.

 끝으로 전송 계층 출발지와 목적지 포트 번호가 정의 된다. 포트 범위는 콜론(:)으로 명시할 수 있으며(예를 들어 :2123 은 포트 21에서 23까지를 의미한다), 포트 번호 역시 느낌표(!)로 부정할 수 있다(예를 들어 !80은 포트 80을 제외한 모든 포트에 적용된다).

 – 스노트 헤더 와일드 카드와 변수 결정
 스노트 규칙 헤더의 모든 매칭 기준(프로토콜은 제외)은 스노트가 특정 IP 주소나 포트 번호로 조사를 제한하지 않게 하기 위해 와일드카드로 설정할 수 있다. 또 스노트는 snort.conf 설정 파일에 값(예를 들어 IP 주소나 포트 번호의 목록)이 명시된 변수의 정의도 지원한다.

 예를 들어 스노트의 많은 웹 기반 규칙이 다음과 같은 헤더를 포함한다.

 alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS

 – 규칙 동작과 iptables 에뮬레이션

 규칙 동작은 alert, log, pass, activate, dynamic 중 하나가 될 수 있으며, 대부분의 스노트 규칙은 alert 를 기본 동작으로 가진다. alert 동작이 가장 중요하다(alert 는 스노트가 이벤트를 생성하고 이 경고를 일으킨 패킷을 기록하게 한다). 나머지 동작은 어떤 조치도 없이 패킷을 통과시키거나(pass) 패킷을 기록하거나(log) 특정 규칙이 매칭될 때까지 비활성 상태에 있다가 매칭 시점에 활성화돼서 패킷을 기록하게 일부 규칙을 설정하는 (activate 와 dynamic) 부가적인 기능을 제공한다.

 지금까지 살펴본 바로는 스노트 규칙 헤더에서 activate과 dynamic 동작을 제외한 모든 것이 iptables 와 fwsnort 에서도 유사한 기능에 의해 지원된다.

 -s IP 나 -d IP 인자를 사용하면 각기 출발지와 목적지 IP 주소나 네트워크를 iptables에 명시할 수 있으며 둘 모두 CIDR와 도트 4자리 표기법을 지원한다. 출발지와 목적지 포트 번호는 –sport port 와 –dport port 옵션을 사용해서 줄 수 있으며, 스노트와 마찬가지로 포트 범위는 콜론(:)으로 명시한다. 프로토콜은 -p protocol 로 명시할 수 있다.

 예를 들어 TCP 트래픽에 적용되는 iptables 규칙을 만들고자 한다면 iptables 명령에 -p tcp 인자를 사용한다. 규칙을 목적지 포트 53으로 제한하고 싶다면 –dport 53 을 사용한다. 규칙의 목적지 주소를 192.168.10.0/24 서브넷의 모든 IP 주소로 적용하려면 -d 192.168.10.0/24 를 사용한다.

 – 스노트 동작과 경고

 스노트는 경고를 생성하고 패킷 데이터를 기록하는 몇 가지 훌륭한 옵션을 제공한다. fwsnort를 이용하면 다음과 같은 스노트 동작을 에뮬레이션하기 위해 이런 기능을 결합할 수 있다.

 — 경고 : 주요 스노트 규칙 동작이며, fwsnort 내에서 경고는 로그 메시지 나머지 부분의 로그 접두어와 패킷 헤더 정보 내에 있는 스노트 서명 msg 항목을 기록하기 위해 iptables LOG 타겟을 사용하는 것과 같다. iptables 로는 애플리케이션 계층 데이터를 기록할 수 없지만 (ulogd PCAP 작성기와 함께 ULOG 타겟을 사용하면 가능하다) 적어도 msg 항목을 통해 공격은 기록된다.

 — 기록 : fwsnort 내에서 이 동작은 좀 더 포괄적인 패킷 로깅을 위해 ulogd PCAP 작성기를 사용하는 할 때의 iptables ULOG 타겟과 동일하다.

 — 통과 : 이 동작은 스노트 규칙 집합에서 때때로 패킷을 무시하기 위해 쓰이며, fwsnort 내에서는 iptables ACCEPT 타겟과 동일하다. ACCEPT 타겟은 매칭되는 트래픽이 iptables 의 어떠한 수정이나 추가적인 동작 없이 통과하게 해준다.

 ** 스노트 규칙 옵션 변환: iptables 패킷 로깅

 스노트의 복잡한 패킷 처리는 주로 규칙 옵션(TCP 스트림 재조립이나 포트 스캔 탐지와 같은 특정 문제를 해결하는 전담 전처리기가 수행하는 작업은 예외)에 의해 구현된다.

 fwsnort는 iptables에 동등한 매칭/필터링 옵션이 없는 다음 목록과 같은 옵션을 포함하는 스노트 규칙은 변환하지 않는다.

ack : TCP 헤더의 32비트 승인 번호와 매칭시킨다.

 icmp_id : 일부 ICMP 패킷에 존재하는 ID 값과 매칭시킨다.

 icmp_seq : 일부 ICMP 패킷에 존재하는 순서 번호 값과 매칭시킨다.

 id : IP 헤더의 16비트 IP ID 항목과 매칭시킨다.

 sameip : 동일한 출발지와 목적지 IP 주소를 검색한다.

 seq : TCP 헤더의 32 비트 순서 번호와 일치시킨다.

 window : TCP 헤더의 16 비트 윈도우 값과 일치시킨다.

 그러나 위 목록의 모든 패킷 헤더 정보는 psad와 같은 애플리케이션이 쉽게 분석할 수 있게 iptables 로그에 포함된다.

 ** 스노트 옵션과 iptables 패킷 필터링

지금까지는 iptables 의 로깅 기능만 이용하는 스노트 규칙 옵션을 논했다. 이제 iptables가 명시적인 매칭과 필터링을 지원하는 스노트 규칙 옵션을 살펴보자. 이런 옵션을 사용하는 스노트 규칙은 동등한 iptables 규칙으로 변환 가능하며, 표준 iptables 타겟 보두가(LOG, DROP, REJECT 등) 패킷을 매칭하는 데 적용될 수 있다. 이런 분류에 속하는 스노트 규칙 옵션은 다음과 같다.

 content, flags, dsize, uricontent, itype, ip_proto, offset, icode, flow, depth, ttl, replace, distance, tos, resp, within, ipopts

– content
 스노트 규칙 언어의 content 옵션에는 인자가 바이트의 나열 형태, 예를 들어 /bin/sh 여야 하며 스노트는 보이어-무어 문자열 검색 알고리즘을 사용해서 애플리케이션 계층 데이터에서 이런 바이트 나열을 검색한다. iptables 매칭 확장은 커널에 구현된 동일한 알고리즘(사용자가 선택)을 사용해서 패킷이 네트워킹 스택으로 들어올 때 패킷의 애플리케이션 페이로드에 있는 바이트 나열을 검색한다.

 – uricontent
 uicontent 스노트 옵션은 스노트가 HTTP를 통해 전송되는 URL 인코딩된 애플리케이션 데이터를 처리하게 해준다. 이 옵션은 스노트 규칙 언어에 직접 통합돼 있으며(전처리기에 구현되는 것과 다르다) 이는 웹 애플리케이션 통신의 중요성이 커지면서 이들을 대상으로 하는 공격을 탐지할 필요성도 커졌기 때문이다. URL 인코딩된 데이터를 지원하는 웹서버에 대한 공격은 인코딩 방식의 제약 조건 하에서 어떤 형태도 취할 수 있으며, 그 결과 공격은 네트워크상에서 데이터를 정규화하는 방법 없이는 디코딩하기 어려운 수준의 가변성을 가지게 됐다. 엄격히 말해서 iptables의 문자열 매칭 확장은 URL 인코딩된 데이터를 직접 디코딩할 수 없기 때문에 iptables에 uricontent 스노트 옵션에 대한 직접적인 변환은 없다.

 정규식과 iptables
 iptables에 (역 참조나 반복과 같은 기능이 제거된) 제한된 형태의 정규식 지원을 추가하는 것은 전부터 iptables 프로젝트 관리자에게 제안되고 있다. 그러나 커널에 (펄, 파이선, GNU Emacs, vi, grep 등과 같이 많은 언어, 유틸리티, 편집기에서 사용되는 것과 비슷한) 비결정적 유한 오토마타, 즉 NFA(nondeterministic finite automaton)과 같은 일반화된 정규식 엔진을 구현하는 것은 위험하다. 때로는 데이터에 대한 특정 정규식의 실행 시간이 수천 년이 될 수도 있는 악의적 데이터를 생성하는 것도 가능하다. 단순히 시스템 인터페이스를 통과하는 악의적으로 구성된 패킷에 의해 시스템이 쉽게 다운되길 원하는 사람은 아무도 없다.

 – offset
 offset 스노트 옵션은 스노트가 패킷의 페이로드 데이터 시작 부분으로부터 특정 바이트만큼 떨어진 곳에서 애플리케이션 내용 매칭 동작을 시작하게 한다. 이는 스노트 규칙의 모든 내용 매칭에 적용되는 절대 값으로 여러 내용 매칭 간의 상대적인 바이트 수에 종속적이지 않다(distance 스노트 옵션이 이를 위해 사용된다). iptables에서 offset 옵션은 페이로드 데이터에서 패턴을 검색할 때 문자열 매칭 확장에 –from 명령 행 인자를 사용함으로써 지원된다(이 인자는 커널 버전 2.6.14 와 그 이후 버전에서만 지원된다).

 – depth
 depth 스노트 옵션은 패킷 페이로드 데이터 내용을 매칭하려는 모든 시도가 페이로드 시작 지점에서 특정 바이트 수를 넘지 않게 한다.

 – distance
 스노트는 패턴 매칭 사이에 건너뛸 바이트 수를 명시하기 위해 distance 옵션을 사용한다.

 – within
 within 옵션은 스노트가 처음 매칭 다음의 패턴 매칭이 특정 바이트 수 이내에서 일어나게 요구하게 한다.

 – flags
 flags 스노트 옵션은 TCP 헤더의 제어 비트에 검색 기준을 적용한다. 제어 비트는 TCP 연결의 상태에 따라 달라지며 iptables는 –tcp-flags 인자를 통해 특정 조합을 매칭할 수 있다.

 – itype과 icode
 itype과 icode 옵션은 각기 ICMP 헤더의 8비트 ICMP 유형과 코드 항목의 특정 숫자 값과 매칭된다.

 – ttl
 스노트는 ttl 옵션을 이용해서 IP 헤더의 패킷 유지 시간(TTL, Time-to-Live)값과 매칭할 수 있다.

 – tos
 tos 옵션은 스노트가 IP 헤더의 서비스 유형(TOS, Type Of Service) 비트를 조사하게하며, 이 옵션은 숫자 값과 부정 기호 !를ㄹ 붙인 숫자값만 받아들일 수 있기 때문에 스노트 규칙에서 상대적으로 간단하다.

 – ipopts
 ipopts 스노트 옵션은 검색 기준이 IP 헤더의 옵션 부분에도 적용되게 해준다. IP 옵션은 적법한 IP 트래픽에서 거의 사용되지 않지만 소스 라우팅 IP 옵션(공격자가 다른 방법으로는 도달할 수 없는 네트워크를 통해 패킷을 라우팅하려는 시도에 사용할 수 있는 옵션)을 사용하려는 시도를 탐지하는 것은 중요하다.

 – dsize
 dsize 스노트 옵션은 패킷 페이로드 데이터의 크기에 조건을 건다. dsize 옵션은 양의 정수를 취하며 규칙이 매칭되기 위해 피킷의 애플리케이션 부분에 존재해야할 바이트 수를 나타내는 < 와 > 연산자를 사용할 수도 있다.

 fwsnort 에서는 /etc/fwsnort/fwsnort.conf 의 AVG_IP_HEADER_LEN 와 AVG_TCP_HEADER_LEN 키워드를 통해 IP와 TCP 헤더의 평균 헤더 길이를 설정할 수 있다.

 – ip_proto
 ip_proto 스노트 옵션은 스노트 규칙이 IP 헤더의 프로토콜 항목으로 가능한 값 256개 중 임의의 것으로 제한할 수 있게 해준다. 이 값들은 /etc/protocols 파일에 정의되 있다.

 – flow
 flow 스노트 옵션은 스노트 규칙 언어에서 좀 더 중요한 기능 중 하나로 스트림 전처리기와 함께 사용된다. 흐름 옵션은 스노트 규칙이 재조립된 TCP 스트림에 대해 상태와 방향 기준을 적용할 수 있게 해준다.

 – replace
 replace 스노트 옵션은 스노트가 인라인 모드로 실행 중이고 패킷 데이터 경로에 인라인으로 배치됐을 때만 적용될 수 있다. 이 모드에서 스노트는 보호된 니테으쿼ㅡ 안팎으로 스노트의 탐지 엔진이 패킷을 조사한 후에만 이를 전달하는 기능을 갖춘 진정한 침입 방지 시스템이 된다. replace 옵션은 애플리케이션 계층 데이터에 대해 동작하며 content 옵션에 의해 탐지된 바이트 나열이 동일한 길이의 다른 나열로 대체되게 해준다.

– resp
 flexresponse 와 flexresponse2 스노트 탐지 플러그인이 제공하는 resp 옵션은 스노트가 서명 매칭을 종료시키기 위해 TCP RST/ACK 패킷을 전송하는 것과 ICMP 네트워크, 호스트, 포트 도달 불가 패킷을 생성하는 것이 있다. iptables REJECT 타켓은 TCP 연결에 대해서 인자 -j REJECT –reject-with tcp-reset, UDP 패킷에 대해 인자 -j REJECT –reject-with icmp-*-unreachable(*는 net, host, port 중 하나)을 통해 이런 기능을 제공한다.
 

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

4. 어플리케이션 계층 공격과 방어

Posted on by
Reply

 * iptables를 이용한 애플리케이션 계층 문자열 매칭

 모든 IDS가 가지는 가장 중요한 기능 중 하나는 애플리케이션 계층 데이터에서 악의적인 바이트를 암시라는 바이트 나열을 검색하는 것이다. 그러나 일반적으로 애플리케이션의 구조는 네트워크나 전송 계층 프로토콜보다 훨씬 덜 엄격하게 정의되기 때문에 침입 탐지 시스템은 애플리케이션 계층 데이터를 조사할 때 융통성을 가져야 한다.

 네트워크 트래픽에서 애플리케이션 부분 전체에 대해 문자열 매칭을 수행하는 것은 좋은 출발점이며, iptables 의 문자열 매칭 확장이 이를 제공한다.

 – 문자열 매칭 확장의 동작
 다음의 규칙은 TCP 포트 5001에서 대기 중인 Netcat 서버로 문자열 “tester”가 전송될 때 syslog 메시지를 생성하기 위해 iptables LOG 타겟을 사용한다

 #iptables -I INPUT 1 -p tcp –dport 5001 -m string –string “tester” –algo bm -m state –state ESTABLISHED -j LOG –log-prefix “tester”

 # iptables -I INPUT 2 -p tcp –dport 5001 -j ACCEPT

  명령어의 –algo bm 인자에 주목하자. 문자열 매칭 확장은 리눅스 커널의 텍스트 검색 기능 위에서 구현된다. 리눅스 커널의 텍스트 검색 기능은 보이어-무어 문자열 검색 알고리즘(위의 bm)과 크누스-모리스-프랫 문자열 검색 알고리즘(kmp) 등과 같이 다양한 알고리즘을 지원한다.

 * 애플리케이션 계층 공격 정의
 
 애플리케이션 계층 공격은 애플리케이션, 애플리케이션 사용자, 애플리케이션이 관리하는 데이터를 애플리케이션 소유자나 관리자가 허용하는 것 이외의 목적으로 전복하려는 시도로 정의한다.

 애플리케이션 계층 공격은 다음의 세 가지로 분류할 수 있다.

 — 프로그래밍 버그에 대한 공격 : 애플리케이션 개발은 복잡한 과정이며 프로그래밍 오류는 반드시 존재한다. 어떤 경우에는 이런 버그가 네트워크를 통해 원격으로 접근 가능한 심각한 취약점을 유발할 수 있다. 좋은 예로 안전하지 않은 C 라이브러리 함수의 사용으로부터 야기되는 버퍼 오버플로우 취약점, 부적절한 질의를 제대로 제거하지 않고 후단 데이터베이스로 넘기거나(SQL 인젝션 공격으로 이어질 수 있다), 사용자가 입력한 필터링되지 않은 내용을 사이트에 세재하는(크로스 사이트 스크립팅이나 XSS 공격을 야기할 수 있다) 웹서버와 같이 웹 중심 취약점이 있다.

 — 신뢰 관계에 대한 공격 : 어떤 공격은 애플리케이션 프로그래밍 버그 대신 신뢰 관계를 공격한다. 이러한 공격은 애플리케이션 그 자체와의 연동만 고려하면 완전하게 정당한 것처럼 보인다. 하지만 공격은 해당 애플리케이션의 사용자들이 가지는 신뢰를 대상으로 삼는다. 피싱 공격이 대표적이다. 피싱의 목표는 웹 애플리케이션이나 메일 서버가 아니라 피싱 웹사이트나 메일 메시지를 해석하는 사람이다.

 — 자원 소진 : 네트워크나 전송 계층 DoS 공격과 같이 애플리케이션도 때때로 다량의 데이터 입력을 받을 수 있다. 이러한 공격은 모든 사용자가 애플리케이션을 사용할 수 없게 한다.

 * 애플리케이션 계층 악용

 일반적인 네트워크와 전송 계층 프로토콜의 구현이 RFC에 정의된 사항을 거의 따르는 반면 특정 CGI 애플리케이션이 웹서버를 통해 사용자 입력을 처리하는 방법을 제어하거나 애플리케이션이 자동 경계 검사나 메모리 관리를 수행하지 않는 프로그래밍 언어(C 등)로 작성됐는지 제어하는 표준은 없다.

 – 스노트 서명
 애플리케이션 계층 공격을 이해하는 가장 좋은 방법의 하나는 스노트 서명 집합을 살펴보는 것이다. 최근의 스노트 서명은 스노트 소스 코드와 함께 배포되지 않지만 블리딩 스노트(Bleeding Snort) 프로젝트에서 최신 공격에 대한 서명을 스노트 형식으로 생성하고 있다(http://www.bleedingsnort.com 참조)

 – 버퍼 오버플로우 공격
 버퍼 오버플로우 공격은 애플리케이션 소스 코드에서 버퍼에 복사되는 데이터의 양을 충당하기에 버퍼의 크기가 충분하지 않은 부분에서 발생하는 프로그래밍 오류를 이용하는 공격이다. 그러므로 오버플로우라는 용어는 인접한 메모리 위치가 덮어쓰일 때 사용된다. 스택 기반 버퍼 오버플로우의 경우 성공적인 공격은 함수의 복귀 주소(스택에 존재)가 공격자의 코드를 가리키게 덮어 쓴다. 이를 통해 공격자는 그때부터 쭉 프로세스의 실행을 제어할 수 있다. 또 다른 분류의 버퍼 오버플로우 공격은 힙으로부터 동적으로 할당되는 메모리 영역에 적용된다.

 – SQL 인젝션 공격
 SQL 인젝션 공격은 사용자 입력이 데이터베이스 질의에 포함되기 전에 이것이 올바른지 확인하거나 필터링하지 않는 애플리케이션을 공격한다. 영악한 공격자는 새로운 질의를 생성해서 잠재적으로 데이터베이스의 정보를 수정하거나 추출하기 위해 SQL 언어의 충첩(nesting) 기능을 사용할 수 있다. SQL 인젝션 공격의 일반적인 목표는 웹서버를 통해 실행되며, 후단 데이터베이스로의 인터페이스를 제공하는 CGI 애플리케이션이다.

 – 그레이 매터 해킹(Gray Metter Hacking)
 오늘날 인터넷에서 가장 문제가 되는 공격의 일부는 직접 사람들이 사용하는 애플리케이션을 통해서 사람들을 목표로 하는 공격이다. 강력한 시스템, 애플리케이션, 암호화 기법의 취약점을 찾는 것보다 사람을 공격하는 것이 때로는 쉽다.

 — 피싱(Phishing)
 피싱(Phishing)은 사용자가 은행과 같은 온라인 계좌에 대한 인증 정보를 신뢰할 수 없는 곳에 제공하게 속이는 공격이다. 이 공격은 주로 공식적인 것처럼 보이는 메일을 사용자게 전송해서 이뤄지는데, 메일의 내용은 사용자가 온라인 계좌에 접속해서 보안상 “긴급한” 작업(예를 들어 암호 변경)을 수행해야 한다는 것이다. 정상적인 것처럼 보이는 웹 링크가 제공되지만 이는 원래의 웹사이트를 비슷하게 흉내낸 공격자 제어하의 웹사이트로 사용자를 유도하는 교묘한 링크다. 일단 피싱 공격을 당하는 사용자가 사이트에 방문해서 자신의 계정 정보를 입력하는 공격자는 재빨리 계정 정보를 가로챈다.

 — 백도어와 키보드 입력 로깅
 백도어(backdoor)란 공격자는 사용할 수 있지만 정당한 사용자는 사용할 수 없는 기능을 포함하는 실행 파일이다.  예를 들어 Sdbot 트로이목마는 공격자의 명령어 전송을 기자리는 IRC 채널로 연결하기 위해 특정 IRC 클라이언트를 사용해서 백도어를 연다. 하지만 백도어는 어떤 동작도 취하기 전에 공격자가 유효한 암호를 입력하게 만든 프로그램이다. 이는 백도어 통신의 인증 수준을 높여주며, 시스템에 성공적으로 침투한 공격자만이 그 시스템을 제어할 수 있게 해준다.

 * 암호호와 애플리케이션 인코딩

 애플리케이션 계층 공격을 탐지하기 어렵게 만드는 요소로 암호화와 애플리케이션 인코딩 기법의 두 가지를 곱을 수 있다. 암호화는 암호 키가 없는 한 암호를 평문화하는 것이 현실적으로 불가능하게 설계되며, 보통의 IDS, IPS 방화벽 장치는 이러한 키에 접근할 수 없기 때문에 특히 문제가 된다.

 그러나 일부 애플리케이션 계층 공격의 경우에는 성공을 위해 암호화가 필요가 없다. 예를 들어 SSH 서버에 대한 특정 공격을 탐지하는 스노트 서명(“평문 상태”에서 동작해야 함)이 있다. 이러한 서명이 사용되면 스노트는 SSH 암호화 키에 접근하지 않고 페이로드 데이터를 검색한다. 이러한 서명의 존재는 암호화만으로는 완벽한 방어를 할 수 없다는 것을 의미하며, 때때로 공격자는 통상적으로 요구되는 암호화 계층이 어떤 차이도 만들어내지 못하는 애플리케이션 취약점을 공격할 수 있다. 즉, 암호화되지 않은 수단을 통해 접근 가능한 함수 내부에 취약점이 존재할 수도 있다.

 인코딩 기술 역시 IDS가 다루기 어려울 수 있다. 예를 들어 보통 느린 네트워크로 압축하지 않은 데이터를 전송하는 것보다 빠른 CPU로 데이터를 압축하거나 압축 해제하는 것이 빠르기 때문에 많은 웹 브라우저가 네트워크를 통해 전송되는 데이터의 크기를 줄이기 위해 gzip 인코딩을 지원한다. 공격자가 약간의 무작위 데이터를 섞은 후 gzip으로 압축하면 IDS는 공격을 탐지하기 위해 이 데이터가 네트워크로 전송될 때 해당 데이터의 압축을 해제해야 한다. 무작위 데이터는 압축된 공격이 매번 달라 보이게 한다. 이러한 무작위화를 거치지 않으면 IDS는 공격을 식별하기 위해 압축 문자열 자체를 검색할 수 있다. 분주한 네트워크에는 악의적이지 않은 대용량 압축 파일을 다운로드 하는 웹 세션이 매우 많기 때문에 모든 웹 세션을 시시간으로 압축 해제하는 것은 계산상 비현실적이다.

 – IDS가 모든 애플리케이션 인코딩을 디코딩할 수 없는 것은 아니다. 예를 들어 웹 세션에서 URL 인코딩된 데이터는 스노트 서명 언어의 uricontent 키워드를 이용해서 스노트 HTTP 전처리기에 의해 실시간으로 디코딩된다. 이는 URL 인코딩이 16진수 코드와 % 기호를 사용하는 단순한 치환 연산을 통해 수행되기 때문에 가능하다. 예를 들어 A는 %41이 되며, 이는 동일한 방식으로 쉽게 복원할 수 있다. 이러한 인코딩 기법은 많은 계산을 필요로 하지 않는다.

 * 애플리케이션 계층 응답

 기술적으로 애플리케이션 계층 공격에 대한 순수한 애플리케이션 계층 응답은 애플리케이션 계층에 존재하는 구성소만을 포함해야 한다. 예를 들어 사용자가 애플리케이션을 악용하고 있다면 단순히 해당 계정을 비활성해야 되며, 공격자가 웹서버에서 실행되는 CGI 애플리케이션을 통해 SQL 인젝션을 시도한다면 질의를 무시하고 클라이언트로 HTTP 오류 코드를 반환해야 한다. 이러한 응답은 애플리케이션 계층 아래에 존재하는 패킷 헤더 정보의 변경을 필요로 하지 않는다.

 그러나 엄격한 애플리케이션 계층 응답은 방화벽과 네트워크 침입 방지 시스템에 적합하지 않다. 이는 방화벽과 네트워크 침입 방지 시스템이 보통 애플리케이션 자체와 긴밀히 통합돼 있지 않기 때문이다. 더욱이(양방향 통신을 필요로 하는) TCP 세션상에서 특정 IP 주소로부터 매우 악의적인 공격이 발견됐다면 그때부터는 공격자 IP 주소로부터의 모든 통신을 차단하는 것이 좀 더 유용할 수 있다. 이는 애플리케이션 계층 공격에 대한 네트워크 계층 응답이다.

3. 전송 계층 공격과 방어

Posted on by
Reply

 TCP는 연결형 프로토콜이다. 이는 클라이언트와 서버가 실제 데이터 교환 이던에 데이터 전송 방법을 정의하는 매개변수들을 협의하며 연결의 시작과 끝에 명확한 구분이 있다는 뜻이다. TCP 는 두 노드 사이에서 신뢰할 수 있고 순서를 유지하는 방식으로 데이터를 전송하므로 애플리케이션 계층 프로토콜은 이런 기능을 자체적으로 내장할 필요가 없다.

 반면 UDP 는 비연결형 프로토콜이다. 그러므로 데이터가 의도된 목적지에 도달하리라는 보장도 없고 전송을 보장하는 데이터 형태에 대한 보장도 없다(심지어 UDP 헤더에서는 TCP와 달리 체크섬 계산초자 옵션이다). UDP 소켓을 통해 데이터를 전송하는 애플리케이션은 데이터를 신뢰할 수 있게 전송하기 위한 추가적인 기법을 구현할 수 있지만 이러한 기능은 UDP 소켓이 사용될 때 애플리케이션 계층에 내장되야 한다.

  * iptables 를 이용한 전송 계층 헤더의 기록

 iptables LOG 타겟은 TCP와 UDP 헤더 기록을 위한 광범위한 장치를 가지고 있다. TCP 헤더는 UDP 헤더보다 훨씬 더 복잡하며, TCP 헤더 항목의 일부는 iptables 정책에 LOG 규칙이 추가될 때 iptables 에 특정 명령 행 인자가 주어질 경우에만 기록된다.

 – TCP 헤더의 기록
 TCP 헤더는 RFC 793에 정의돼 있으며 TCP 세그먼트(패킷)의 헤더 길이는 포함된 옵션의 수에 따라 다양하다. 옵션(유일한 가변 길이 항목)을 제외한 헤더의 길이는 항상 20바이트다.

 INPUT, OUTPUT, FORWARD 체인의 LOG 규칙은 모두 –log-tcp-options 인자를 포함한다. 그러므로 로그 메시지는 TCP 세그먼트가 옵션을 포함할 때마다 알아볼 수 없는 16진수 코드를 포함한다.

 iptables 가 TCP 순서번호와 승인 값도 포함하게 하려면 –log-tcp-sequence 인자를 사용하면 된다.

 – UDP 헤더의 기록
 UDP 헤더는 RFC 768에 정의돼 있다. 길이가 8바이트밖에 되지 않으며 가변 길이 항목은 없다.

 LOG 타겟이 UDP 헤더를 나타내는 방법에 영향을 줄 수 있는 특수 명령 행 인자는 없기 때문에 iptables는 UDP 헤더를 항상 동일한 방식으로 기록한다.

 앞서 작성한 iptables 정책의 기본 LOG 규칙은 –log-tcp-options 인자를 사용하지만 iptables 는 UDP 패킷이 이런 규칙 중 하나와 일치하는 경우에도 제대로 동작하며, 실제 패킷에 들어있는 정보만을 기록한다. 즉, 존재하지도 않는 TCP 헤더의 옵션 부분을 기록하려고 하지 않는다. UDP 체크섬은 기록되지 않지만 나머지 세 항목(SPT, DPT, LEN)은 모두 포함한다.

 * 전송 계층 공격 정의

 네트워크 계층 공격의 정의와 마찬가지로 전송 계층 공격은 말단 호스트의 전송 스택 구현에 존재하는 취약점이나 오류 조건(error condition)을 공격하기 위해 전송 계층 헤더의 항목을 악용하는 패킷이나 패킷들로 정의된다.

 전송 계층 공격은 다음과 같이 세 분류로 나뉜다.

 — 연결 자원 소진 : 목표 호스트나 호스트 집합에서 새로운 연결을 서비스하는 데 사용할 수 있는 자원을 모두 포화시키기 위해 설계된 패킷. 대표적인 예로 SYN 플러딩 형태의 DDoS 공격이 있다.

 — 헤더 악용 : 악의적으로 구성됐거나 깨진, 또는 변조된 전송 계층 헤더를 포함하는 패킷. 대표적인 예로는 TCP 연결을 파괴하기 위해 설계된 가짜 RST 패킷이 있다. 스캔 자체가 악의적인 것은 아니지만 포트 스캔도 이 범주에 포함된다.

 — 전송 스택 공격 : 말단 스택에 존재하는 취약점에 대한 전송 계층 소택 공격을 포함하는 패킷. 즉, 전송 계층 정보를 처리하는 커널 코드 자체가 공격 목표다. 대표적인 예로는 넷필터 TCP 옵션 처리 코드에 존재하는 취약점에 대해 2004년에 발표된 공격이 있다. 이 공격은 TCP 패킷 자체를 공격하지는 않지만 넷필터 프레임워크를 통해 스택으로 직접 후킹되는 코드를 공격한다.

 * 전송 계층 악용

 어떤 면에서 전송 계층은 네트워킹된 애플리케이션과 스택 위로 통신하기 전에 나오는 마지막 게이트웨이기 때문에 공격자에게 매력적인 공격 목표다. 전송 계층 정보를 포함하는 수상한 활동의 다수는 노골적인 공격이 아니라 정탐이다.

 – 포트 스캔
 포트 스캔은 특정 IP 주소에서 어떤 TCP나 UDP 서비스가 접근 가능한지 알아보기 위해 호스트의 정보를 얻어내는 기술이다. 공격자는 시스템 스캔을 통해 접근이나 공격할 서비스의 정보를 얻기 때문에 이는 성공적인 침투의 중요한 단계일 수 있다.

 반면 포트 스캔은 단지 어떤 서비스가 이용 가능한지 알아보는 데에도 중요한 단계일 수 있다. 포트 스캔 자체에는 본질적으로 악의적인 어떤 것도 없다. 포트 스캔은 집의 모든 문을 두드려보는 사람에 비유할 수 있다. 그러나 누군가가 집의 모든 문을 두드린다면 이는 그가 집에 침입할 가장 좋은 방법에 대한 정보를 모으고 있을 수도 있다는 의미기 때문에 이를 알아채는 것은 중요한 일이다.

 마찬가지로(긍정 오류를 줄이기 위한 튜닝 연습을 한다는 가정하에) 포트 스캔을 탐지하는 것은 좋은 생각이며, 대부분의 네트워크 침입 탐지 시스템은 스캔될 때 알림을 전송할 수 있는 기능을 제공한다.

 — 취약한 서비스로 포트 스캔 일치 시키기
 포트 스캔을 위해 목표 시스템의 가능한 모든 포트에 대해 전체 시험을 수행할 필요는 없다. 예를 들어 OpenSSH 3.3과 BIND 4.9 서버의 침투에 능숙한 공격자라면 나머지 65,533 개의 포트도 모두 바인딩된 서버를 가진다는 사실을 알아내는 것은 별 소용이 없다. 더욱이 시스템의 모든 포트를 시험하기 위해 생성한 떠들썩한 스캔은 보통의 포트 스캔 임계치를 넘을 가능성이 매우 높기 때문에 IDS 의 경고를 유발하기 십상이다. 공격자 입장에서는 불필요한 주목을 받지 않는 것이 좋다. 공격자는 IDS가 스캔의 실제 출발지를 결정하기 더 어렵게 하기 위해 Nmap의 미끼 (-D) 옵션을 사용할 수 있다. 이 옵션은 포트 스캔을 여러 개의 스푸핑된 출발지 주소로 중복되게 함으로써 목표 시스템이 동시에 여러 개의 독립적인 출발지에 의해 스캔되고 있는 것처럼 보이게 한다. 목적은 IDS 알림을 본 보안 관리자가 실제 스캔 출발지를 알아내기 힘들게 하는 것이다.

 — TCP 포트 스캔 기술
 TCP 포트의 포트 스캔에는 엄청나게 많은 기술을 사용할 수 있다. 여기서는 Nmap을 사용하여 포트 스캔 기술을 다룰 것이다.
 TCP connect() 스캔 – (Nmap -sT)
 TCP SYN 또는 반개방(half-open) 스캔 – (Nmap -sS)
 TCP FIN, XMAS, NULL 스캔 – (Nmap -sF, -sX, -sN)
 TCP ACK 스캔 – (Nmap -sA)
 TCP 유휴 스캔(idle) 스캔 – (Nmap -sI)
 UDP 스캔 – (Nmap -sU)

 또 스캔에서는 Nmap이 스캔을 전송하기 전에 해당 방화벽 시스템의 동작 여부를 알아보지 않게(즉, 호스트의 발견을 생략하게) 강제하기 위해 Nmap -P0 명령 행 옵션을 사용한다. Nmap의 관점에서 볼 때 스캔된 포트는 다음의 세 상태 중 하나에 속한다.

 열림 : 포트에 바인딩된 서버가 있으며 접근 가능하다.
 닫힘 : 포트에 바인딩된 서버가 없다.
 필터링됨 : 포트에 바인딩된 서버가 있을 수 있지만 이와 통신하기 위한 시도는 차단되며 Nmap은 포트가 열려있는지 또는 닫혀있는지 알 수 없다.

 — TCP connect() 스캔
 통상적인 클라이언트 애플리케이션이 네트워크를 통해 TCP 포트와 바인딩된 서버와 통신하고자 할 때는 로컬 TCP 스택이 클라이언트 입장에서 원격 스택과 연동한다. 두 스택은 애플리케이션 계층 데이터가 전송되기 전에 클라이언트와 서버 사이에 있을 통신을 관리하는 매개변수를 협상해야 한다. 이 협상을 표준 TCP 쓰리웨이 핸드셰이킹(three-way handshake) 이라고 한다.

 TCP connect() 스캔의 문맥에서 스캐너는 스캔되는 각 포트에 SYN과 마지막 ACK 패킷을 전송한다. 일반 사용자는 Nmap을 사용해서 이런 방식으로 원격 시스템을 스캔할 수 있다. 어떤 특수 권한도 필요치 않다

 — TCP SYN이나 반개방 스캔
 SYN 이나 반개방 스캔은 목표 포트가 열렸는지 아니면 닫혔는지를 알려주는 SYN/ACK 이나 RST/ACK 응답을 모으기 위해 스캐너가 각 TCP 포트로 SYN 패킷을 전송한다는 점에서 connect() 스캔과 유사하다. 그러나 이 경우 스캔 시스템은 고의적으로 SYN/ACK 로 응답하는 열린 포트로 ACK 패킷을 반환하지 못하게 하기 때문에 쓰리웨이 핸드쉐이크는 완료되지 않는다. 그러므로 SYN 스캔은 핸드쉐이크가 정상적으로 완료될 수 없다는 점에서 반개방 스캔이라고도 한다.

 connect() 시스템 호출은 목표로부터 수신한 SYN/ACK 에 대해 ACK으로 응답하는 바닐라 TCP 스택 코드를 호출하기 때문에 SYN 스캔에는 사용할 수 없다. 그러므로 SYN 스캔에서 전송되는 모든 SYN 패킷은 TCP 스택 전체를 우회하는 기법을 이용해서 생성해야 한다. 이 작업에는 보통 OS 커널의 전송 시 SYN 패킷을 모방하는 데이터 구조를 만들기 위해 원시 소켓을 사용한다.

 — 원시 소켓과 원하지 않은 SYN/ACK
 원격 시스템에 대한 TCP SYN 패킷을 생성하기 위해 connect() 시스템 호출 대신 원시 소켓을 사용하는 것은 흥미로운 쟁점을 유발한다. 원격 호스트가 SYN/ACK 로 응답하면 스캔 시스템상의 로컬 TCP 스택은 SYN/ACK 를 수신하지만 아웃바운드 SYN 패킷은 로컬 스택으로부터 온 것이 아니다(원시 소켓을 통해 SYN을 생성했기 때문). 그러므로 SYN/ACK 는 스택이 관련되는 한 정당한 TCP 핸드쉐이크의 일부가 아니다. 그러므로 스캐너의 로컬 스택은 SYN/ACK 패킷을 원하지 않은 패킷으로 보고 목표 시스템에 RST을 전송한다. 이러한 스캔 시스템의 동작은 명령어로 스캔을 시작하기 전에 다음과 같은 iptables 규칙을 OUTPUT 체인에 추가해서 막을 수 있다.

 # iptables -I OUTPUT 1 -d target -p tcp –tcp-flags RST RST -j DROP

 Nmap은 SYN 스캔 모드(-sS, 특수 권한을 가진 사용자를 위한 기본 스캔 모드)에 사용되는 TCP SYN 패킷을 직접 만들기 위해 원시 소켓을 사용한다. 이러한 패킷의 특징은 (로컬 TCP 스택을 사용하지 않고) Nmap 에 의해 직접 결정되기 때문에 스택이 일반적으로 생성하는 TCP SYN 패킷과는 상당히 다르다.

 실제 TCP 스택이 생성하는 SYN 패킷과 달리 Nmap은 실제 TCP 세션의 협상을 신경쓰지 않는다. Nmap의 유일한 관심사는 원격 호스트의 포트가 열렸는지 (Nmap은 SYN/ACK를 수신함), 닫혀있는지(Nmap은 RST/ACK을 수신함), 아니면 필터링됐는지(Nmap은 아무것도 수신하지 않음)다. 그러므로 Nmap이 전송하는 TCP SYN 패킷은 원격 TCP 스택이 SYN/ACK, RST/ACK으로 응답하거나 응답하지 않게(포트가 필터링된 경우) SYN 플래그를 설정한 TCP 패킷으로서 원격 호스트에 적합하기만 하면 된다.

 — TCP FIN, XMAS, NULL 스캔
 FIN, XMAS, NULL 스캔은 (RFC를 따르는) 모든 TCP 스택이 포트에서 SYN, ACK, RST 제어 비트를 설정하지 않은 뜻밖의 TCP 패킷을 수신한 경우 특정한 방법으로 응답해야 한다는 사실에 기반해서 동작한다. 포트가 닫혀있다면 TCP는 RST/ACK으로 응답하지만 포트가 열려있다면 TCP는 어떤 패킷으로도 응답하지 않는다.

 — TCP ACK 스캔
 TCP ACK 스캔 (Nmap -sA)은 스캔되는 각 패킷에 TCP ACK 패킷을 전송하고 열린 포트와 닫힌 포트로부터 RST 패킷(RST/ACK 패킷이 아님)을 기다린다. 목표 포트에서 RST 패킷이 반환되지 않으면 Nmap은 해당 포트가 필터링된 것으로 추정한다.

 ACK 스캔의 목적은 포트가 열려있거나 닫혀있는지를 결정하는 것이 아니라 포트가 상태유지형 방화벼에 의해 필터링되는지 여부를 결정하는 것이다. 넷필터 연결추적 하위시스템(상태 매칭을 통해)사용될 때마다 iptables 방화벽은 상태유지형이기 때문에 뜻밖의 ACK 패킷은 방화벽 시스템의 TCP 스택에 도달할 수 없다. 그러므로 RST 패킷이 스캐너로 반환되지 않는다.

 — TCP 유휴 스캔
 TCP 유휴(Idle) 스캔은 세 개의 시스템(스캔을 시작하는 시스템, 스캔 목표, 이용률이 작은[여기서 이 스캔 이름의 “유휴” 부분이 나왔다] TCP 서버를 실행 중인 좀비 호스트)을 필요로 하는 고급 스캔 방식이다.

 유휴 스캔은 IP가 IP 스캑을 통해 전송되는 모든 패킷에 대해 IP ID 값을 1씩 증가시킨다는 사실을 이용해서 공격할 수 있다. 유휴 스캔은 이 사실과 함께 TCP 스캔이 열린 포트로의 SYN 패킷에 대한 응답으로 SYN/ACK 패킷을 전송하거나 닫힌 포트로의 SYN 패킷에 대한 응답으로 RST/ACK 패킷을 전송해야 한다는  요구사항도 이용한다. 또 모든 TCP 스택은 원하지 않은 RST/ACK 패킷을 무시해야 한다. 스캐너는 이러한 사실을 이용해서 좀비 호스트가 스캐너에서 좀비 호스트로 유지되는 TCP 세션동안 IP ID 값을 어떻게 증가되는지 지켜본다. 이와 동시에 스캐너는 목표 시스템에서 좀비 호스트의 IP 주소로 SYN 패킷을 스푸핑한다. 결과적으로 스캐너는 좀비 시스템으로부터 전송되는 패킷의 IP 헤더에 있는 IP ID 값을 감시할 수 있으며, 이 정보를 이용해서 목표 시스템의 포트가 열려있는지 아니면 닫혀있는지를 예측할 수 있다.

 스캐너가 좀비의 IP 주소로 스푸핑된 출발지 IP 주소를 가지는 SYN 패킷을 목표 시스템의 열린 포트로 전송하면 목표는 SYN/ACK 으로 (좀비 시스템에) 응답한다. 좀비가 수신한 SYN 패킷은 실제로 원하지 않은 것이기 때문에(스캐너가 스푸핑한 것) 좀비는 RST로 응답하며, 이때 IP Id 카운터를 1만큼 증가시킨다. 스캐너가 닫힌 포트로 SYN 패킷을 전송하면(역시 출발지 IP 주소는 스푸핑됨) 목표 시스템은 RST/ACK 로 좀비에 응답하며, 좀비는 원하지 않은 패킷을 무시한다. 이 경우 좀비로부터 어떤 패킷도 전송되지 않으므로 IP ID 값은 증가되지 않는다.

 스캐너는 IP ID 값이 어떻게 증가되는지를 감시해서(목표 시스템의 열린 포트에 대해서는 1만큼 증가되며 닫힌 포트에 대해서는 증가되지 않음) 목표의 어느 포트가 열려있는지 유후할 수 있다. 그러나 idel 스캔의 성공에 가장 중요한 요소는 좀비에서 이용할 수 있는 서비스의 이용률이다. 널리 쓰이는 웹서버는 좀비로 적합하지 않다. 이 경우 모든 TCP 연결이 IP ID 값을 증가시키기 때문에 대부분의 경우 스캐너가 제어할 수 없는 속도로 IP ID 값이 증가되며, 결국 IP ID 값의 변화를 스캔된 포트에 적용할 수 없게 된다.

 유휴 스캔의 목표가 되는 시스템은 좀비 호스트로부터 전송된 스푸핑된 SYN 패킷만을 보기 때문에 스캔의 실제 출발지를 알 수 없다. 목표 시스템의 iptables 로그는 정상적인 SYN 스캔처럼 보인다.

 — 좀비 호스트에서 기본 버리기 방화벽이 실행 중이라면 유휴 스캔이 동작할 수 있는 유일한 방법은 스캐너가 출발지 포트를 좀비의 열린 TCP 포트로 하드 코딩하는 것이다. 좀비 TCP 스택은 필터링된 SYN/ACK 을 볼 수 없으므로 RST를 전송하지 않을 것이며, IP ID도 증가되지 않기 때문이다. 방화벽이 설치된 경우에는 이용률이 낮은 서비스가 유일하게 이용 가능한 포트일 수도 있다.

 – UDP 스캔
 UDP는 연결을 수립하기 위한 제어 메시지를 구현하지 않기 때문에 UDP 서비스에 대한 공격은 간단하며, UDP 포트로 데이터를 전송한 후 적당한 시간 내에 응답이 오는지 알아보는 방식으로 수행된다. 서버가 대기하고 있지 않는 필터링되지 않은 포트로 UDP 패킷을 전송하면 ICMP 포트 도달 불가 메시지를 받기 때문에 스캐너는 UDP 포트가 닫혔는지 여부를 쉽게 알 수 있다.

 반면 열린 포트로 UDP 패킷을 전송하면 이 패킷이 필터링되지 않았다 하더라도 응답을 전혀 받지 못할 수도 있다. 이는 UDP 서버가 응답해야 할 의무를 가지지 않기 때문이다. 서버가 응답하는지 여부는 전적으로 포트에 바인딩된 특정 서버 애플리케이션의 결정에 달려있다.

 방화벽이 특정 포트에 대한 UDP 패킷을 스캐너로부터 차단하면 스캐너 입장에서는 아무 응답도 받지 못하므로 포트에 바인딩된 UDP 애플리케이션이 응답을 하지 않는 것처럼 보인다(이는 필터링 되는 포트가 Nmap에 의해 open|filtered 로 보고되기 때문이다).

 – 포트 스윕
 포트 스윕(sweep)은 포트 스캔과 유사한 정탐 방법이다. 그러나 포트 스윕은 단일 호스트에서 접근 가능한 서비스를 알아보는 것이 아니라 여러 호스트에 대해 단일 서비스의 이용 가능성을 확인하는 것이다. 보안 관점에서 보면 포트 스윕은 한 시스템이 웜에 의해 침투당해서 새로 감염시킬 목표를 찾고 있는 경우가 많기 때문에 포트 스캔보다 더 심각한 것이다. 네트워크에 다수의 윈도우 시스템(보통 웜의 주요 목표)이 실행 중이면 포트 스윕을 탐지하는 것은 포트 스캔을 탐지하는 것보다 더 중요하다. 그러나 웜에 직면했을 때는 수분 만에 전 세계 수천 대의 시스템을 감염시킨 SQL 슬래머(Slammer) 때처럼 빠른 탐지조차 큰 의미를 지니지 못할 수도 있다. 웜이 탐지된 시점에는 조치를 취하기엔 너무 늦은 경우가 대부분이기 때문이다.

 Nmap의 기능을 이용하면 특정 서비스에 대해 네트워크 전체를 쉽게 스윕할 수 있다. 예를 들어 공격자가 SSH 데몬을 공격한다면 Nmap은 다음과 같이 10.0.0.8/8 서브넷 전체에서 SSH 서비스를 이용할 수 있는 모드 개체를 찾을 수 있다.

 # nmap -P0 -p 22 -sS 10.0.0.0/8

 – TCP 순서 번호 예측 공격
 수립된 TCP 연결에 데이터를 삽입하기 위해서 공격자는 데이터 전달을 추적하기 위해 사용되는 현재의 순서 번호를 알아야 한다(또는 추측해야 한다). 순서 번호는 데이터를 전송하기 전에 연결 양측이 각기 선택한 초기 순서 번호에 따라 달라진다. 초기 순서 번호가 무작위로 선택되게 보장하기 위해 일부 TCP 스택에서는 상당한 작업이 수행되며 순서 번호 항목의 크기 역시 공격자가 TCP 연결을 스니핑하지 못할 때 순서 번호의 예측을 어렵게 한다.

 네트워크 게이트웨이가 iptables를 실행 중일 때 내부 네트워크의 누군가가 외부 TCP 세션에 대한 순서 번호 예측 공격을 하지 못하게 막는 가장 좋은 방법 중 하나는 내부 네트워크에서 시작된 스푸핑된 패킷을 버리는 규칙을 만드는 것이다.

 – SYN 플러딩
 SYN 플러딩(flooding)은 스푸핑된 출발지 주소로부터 엄청난 양의 TCP SYN 패킷을 생성한 후 이를 특정 TCP 서버로 전달한다. SYN 플러딩의 목적은 목표 TCP 스택이 SYN/ACK 패킷을 전송하는 데 자신의 자원을 모두 소비하고 절대 받을 수 없는 ACK 패킷을 기다리게 만들어서 서버가 본래 작업을 하지 못하게 하는 것이다. SYN 플러딩은 서비스 거부 공격이다. iptables 는 limit 매치를 통해 어느 정도 SYN 플러딩 공격을 막을 수 있다.

 # iptables -I FORWARD 1 -p tcp –syn -m limit –limit 1/s -j ACCEPT

 * 전송 계층 응답

 – TCP 응답
 TCP 문맥에서 전송 계층은 통신을 종료하기 위한 고유의 응답 메커니즘을 가지며, TCP RST(재설정)나 RST/ACK(재설정/승인) 패킷의 형태로 구현된다. 이 패킷은 더 이상 데이터를 전송할 수 없으며 현재 상태와 무관하게 연결이 종료될 거라고 수신 TCP 스택에게 알린다. RST 플래그는 TCP 헤더에서 6비트 단위의 제어 비트 항목의 한 요소다. 이 패킷은 TCP 클라이언트나 서버가 더 이상 지속할 수 없는 상황에 봉착했을 때마다 쓰이며 연결의 양쪽 모두 RST를 전송할 수 있다.

 — RST와 RST/ACK
 RFC 793에 따르면 TCP 스택이 RST/ACK 패킷을 생성해야 하는 경우는 세 가지 뿐이다. 나머지 경우 ACK 비트를 설정하지 않은 RST 패킷이 전송된다. 더욱이 TCP 세션에서 마지막에 전송된 패킷의 ACK 플래그와 연결을 종료하기 위해 사용되는 RST 패킷 사이에는 반대 관계가 존재한다. 즉, 마지막 패킷이 ACK 플래그를 가지고 있다면 RST 패킷은 ACK 플래그를 포함할 수 없다. 반대로 마지막 패킷이 ACK 플래그를 포함하고 있지 않았다면 RST 패킷은 ACK 플래그를 포함해야 한다.

 — 침입 탐지 시스템과 RST 생성
 RFC 793은 RST 패킷이 승인 값과 이에 대응되는 ACK 제어 비트를 포함하는 상황을 매우 명확히 명시히고 있지만 많은 침입 탐지 시스템이 TCP 연결을 종료시키기 위해 RST를 생성할 때 RFC를 따르지 않는다.

 — SYN 쿠키
 SYN 플러딩 공격 하에서 TCP 스택이 잘 동작하게 할 수 있는 흥미로운 방법은 SYN 쿠기를 활성화하는 것이다. 수동형 IDS가 공격에 대한 응답으로 SYN 쿠키를 구현할 수는 없지만 커널이 CONFIG_SYN_COOKIES 지원을 활성화하고 컴파일된 리눅스에서는 다음과 같은 명령어를 이용해서 /proc 파일시스템을 통해 SYN 쿠키를 쉽게 활성화할 수 있다.

 # echo 1 > /proc/sys/net/ipv4/tcp_syncookies

 – UDP 응답
 UDP 스택은 기본적인 응답 매커니즘으로 ICMP를 활용한다. UDP서버가 대기 중이지 않은 포트로 UDP 패킷이 전송되면 보통 응답으로 ICMP 포트 도달 불가(ICMP Port Unreachable) 메시지가 전송된다.

 침입 탐지 시스템과 방화벽은 UDP 트래픽에 대한 응답으로도 ICMP 포트 도달 불가 메시지를 생성할 수 있다. iptables REJECT 타겟은 –reject-with icmp-port-unreachable 명령 행 인자를 통해 이러한 응답을 지원한다.

 — 방화벽 규칙과 라우터 ACL(Access Control List)
 RST로 의심스러운 TCP 연결을 종료시키거나 UDP 트래픽에서 공격을 탐지한 후 ICMP 포트 도달 불가 메시지를 전송하는 것과 같은 전송 계층 응답은 많은 경우에 유용하다. 그러나 이러한 응답은 개별적인 TCP 연결이나 UDP 패킷에만 적용된다. 공격자가 새로운 공격을 시도하지 못하게 막는 영속적인 방어 기술은 없다.

 다행히 TCP RST나 ICMP 포트 도달 불가 메시지를 전송하는 것은 방화벽 정책의 차단 규칙이나 공격자 IP와 공격을 받고 있는 서비스에 대한 라우터 ACL과 동적으로 결합될 수 있다.

 그러나 일단 공격자에 대한 차단 규칙이 시작되면 이 규칙은 설정 가능한 시간 후에 이를 제거할 수 있는 별도의 코드를 이용해서 관리해야 한다.