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

 * 들어가며..

 스노트 규칙을 항상 깔끔하게 변활할 수는 없으며, 스노트 규칙 언어는 매우 복잡하기 때문에 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를 이용한 능동적 응답

 * 침입 방지와 능동적 응답

 오늘날 나와 있는 다양한 보안 제품, 기술, 솔루션에서 침입 탐지라는 용어는 큰 주목을 받아왔다. 이러한 주목의 대다수는 이 용어가 주는 지나치게 강한 의미에서 나온것으로 보인다. 물론 보안 침부를 사전에 방지한다는 개념 자체가 장점이 없다는 뜻은 아니다. 다만 침입 탐지 기술은 호스트 수준 스택 강화 기법(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 핑거프린팅까지

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

 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 동작: 수상한 트래픽 탐지.

 * 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 관련 주제를 살펴본다.

5. psad 소개

 * 역사

 psad 소프트웨어 프로젝트는 1999년 가을, 바스티유 개발팀이 바스티유가 경량의 네트워크 침입 탐지 컴포넌트를 제공해야 한다고 결정했을 때 Bastille 리눅스의 일부로 시작했다. 당시 피터 왓킨스는 지금까지도 Bastille 와 함께 제공되는 매우 뛰어난 방화벽 스크립트를 개발 중이었으므로 방화벽 로그가 제공하는 정보에 기반한 IDS 도구를 개발하는 것은 자연스러운 다음 작업이었다. 또 당시 PortSentry(http://sourceforge.net/projects/sentrytools 참조)에는 기본 버리기 전략으로 설정된 방화벽과 함께 사용하기에는 부적절한 구조적 설계 문제가 있었다.

 2001년 마이클 래쉬는 바스티유-NIDS 프로젝트가 바스티유를 설치할 필요 없이 독립적으로 실행될 수 있게 별도의 프로젝트로 분리시키고 포트 스캔 공격 탐지기라고 명명했다. psad의 개발 주기는 매우 활발하며 평균 3~4 달에 한 번씩 새로운 배포판이 나온다.

 * 방화벽 로그를 분석하는 이유
 좋은 네트워크 보안은 기본 네트워크 연결성과 서비스를 허용하기 위해 절대적으로 필요한 만큼만 허용하게 적절히 설정된 방화벽에서 시작된다. 방화벽은 인라인 장치이므로 네트워크 트래픽에 필터링 로직을 적용하기 좋다. 컴퓨터 네트워킹의 문맥에서 인라인 장치란 네트워크를 통해 패킷이 라우팅될 때 패킷의 직접적인 경로에 존재하는 하드웨어를 의미한다. 인라인 장치 내의 하드웨어나 소프트웨어가 오작동해서 기기의 네트워크 트래픽 전달 기능에 영향을 미친다면 네트워크 통신은 더 이상 동작하지 못한다. 인라인 장치의 예로는 라우터, 스위치, 브리지, 방화벽, 네트워크 참입 방지 시스템(IPS)이 있다

 방화벽의 기능이 좀 더 완전해지고 복자배짐에 따라 점차적으로 (애플리케이션 계층 검사와 같이) 전통적으로 침입 탐지 시스템의 점주였던 기능을 제공하고 있다. 이런 기능이 트래픽을 필터링하는 기능에 더해지면서 방화벽은 명백한 침투와 복잡한 정탐 시도로부터 서비스를 보호하고 웜 트래픽으로부터의 잠재적인 피해를 제한할 수 있는 효과적인 기법을 제공할 수 있는 양질의 침입 탐지 데이터를 생성할 수 있게 됐다. 광범위한 로깅과 필터링 기능을 갖춘 iptables 와 같은 방화벽은 무시해선 안 되는 가치 있는 보안 데이터를 제공할 수 있다.

 스노트와 같은 전용 침입 탐지 시스템이 굉장히 많은 기능과 네트워크 공격을 기술하기 위한 광범위한 규칙 언어를 제공하는 반면 iptables 는 항상 네트워크 트래픽에 인라인돼서 자세한 패킷 헤더 로그를 제공한다. 철저한 방어의 원리가 적용되므로 iptables 의 로그를 주의 깊게 보는 것이 좋다.

 * psad 의 기능

 현 버전의 psad는 Nmap과 같은 도구를 이용한 포트 스캔, 다양한 백도어 프로그램을 위한 탐사, 분산 서비스 거부 공격(DDoS) 도구, 네트워킹 프로토콜을 악용하려는 시도와 같이 다양한 유형의 의심스러운 트래픽을 탐지할 수 있다. Psad는 fwsnort와 함께 사용하는 경우 애플리케이션 계층 데이터를 조사해야 하는 규칙을 포함해서 스노트 2.3.3 전체 규칙의 60% 이상을 탐지하고 경고할 수 있다.

 psad 의 좀 더 흥미로운 기능 가운데 하나는 스캔이나 기타 악의적인 트래픽이 시작되는 원격 운영체제를 수동적으로 핑거프린팅할 수 있는 기능이다. psad가 사용하는 핑거프린트는 p0f에서 나온 것이다. 더욱이 psad는 자세한 메일과 syslog 경고, 위험 수준 임계치에 기반한 IP 자동 차단 기능(이 기능은 기본적으로 비활성화돼 있다), 통합된 whois 지원, DShield 보고 등을 제공한다.

 * psad 설치

 psad를 설치하기 전에 우선 http://www.cipherdyne.org/psad/download 에서 최신 버전을 받아야 한다. psad를 포함해서 http://www.cipherdyne.org 에서 배포하는 모든 프로그램은 각 소스 트리에 설치 프로그램인 insatll.pl 이 함께 제공된다. tarball 파일을 받은 다음에는 MD5 합과 GnuPG 서명을 모두 확인하는 것이 좋다.



 install.pl 스크립트는 메일 경고가 전송될 메일 주소, 시스템에서 현재 실행 중인 syslog 데몬의 유형(syslogd, syslog-ng, metalog), psad가 특정 로깅 접두어를 포함하는 iptables 로그 메시지만을 분석하게 할지에 대한 결정, 로그 데이터를 DShield 분산 IDS로 전송할지에 대한 결정 등과 같은 몇 가지 사용자 입력을 필요로 한다. 직접 정보를 입력하거나 기본 값(그냥 엔터 키를 누름)을 그대로 사용할 수 있다. 잠시 후면 psad의 설치가 완료된다.

 데비안 혹은 우분투 리눅스를 사용하는 경우 다음의 명령어를 이용하여 쉽고 같편하게 psad 설치를 진행할 수 있다.
 

 # sudo apt-get install psad

 리눅스에 psad를 성공적으로 설치하고 나면 로컬 파일시스템에 다량의 새 파일과 디렉토리가 생성된다.

 펄은 주요 psad 데몬(나중에 다룰 도우미 데몬 kmsgsd와 psadwatchd는 C로 작성한 것이다)을 개발하는 데 쓰인 프로그래밍 언어로, 핵심 펄 모듈에는 포함되지 않는 몇 개의 펄 모듈이 사용된다. 이러한 펄 모듈을 /usr/lib/psad 에 모두 설치함으로써 psad 는 이미 시스템 펄 라이브러리 트리에 설치된 펄 모듈(주로 /usr/lib/perl5 에 위치)과 psad 가 필요로 하는 모듈을 완전히 분리시켜 유지할 수 있다.

 psad 에는 다음과 같은 모듈이 필요하다.

 * Date::Calc
 * Net::Ipv4Addr
 * Unix::Syslog
 * IPTABLES::Parse
 * IPTABLES::ChainMgr

 psad, kmsgsd, psadwatchd 와 같은 세 개의 시스템 데몬이 psad를 구성한다. 이 데몬은 모두 /usr/sbin 에 설치되며  /etc/psad/psad.conf 파일을 참조한다.

 psad 설치 프로그램은 /etc/psad/archive 디렉토리도 생성해서 현재의 psad 데몬 설정 파일을 복사한다. 이는 psad 를 재설치할 때 이전의 설정을 보존하기 위한 것이다. install.pl 프로그램은 현재의 psad 설정 값을 새로운 설정 파일로 통합할 수 있으며, 이를 통해 업그레이드 비용을 최소화할 수 있다.

 설치 프로그램은 /var 에도 몇 개의 파일과 디렉토리를 생성한다. 우선 /var/lib/psadfifo 에 명명된 파이프를 생성하고 /var/log/psad 디렉토리와 파일 /var/log/psad/fwdata 를 생성한다. 끝으로 install.pl 스크립트는 설치 로그를 /var/log/psad/install.log 에 유지한다. 실행 시 psad 의 주요 동작 디렉토리(수상한 네트워크 트래픽과 관련된 IP 주소를 기록하는 디렉토리)도 /var/log/psad 다.

 psad가 설치되는 디렉토리는 무작위로 선택되는 것이 아니라 파일 시스템 계층 표준(FHS, Filesystem Hierarchy Standard)이라는 문서에서 정의하는 표준 디렉토리 내에 위치한 것이다. 이 문서에는 유닉스 파일시스템 디렉토리 구조 내의 각 디렉토리가 담당할 목적을 분류한다. 이 문서를 따르는 애플리케이션은 리눅스 디렉토리 구조를 예상 가능하게 사용하며 이는 수많은 디렉토리와 파일 속에서 어느 정도 정리된 모습을 유지할 수 있게 해준다. FHS는 http://www.pathname.com/fhs에서 구할 수 있다.XIW0pLyDnJ.pdf

 * psad 관리

 – psad 의 시작과 종료

 psad의 시작과 종료는 매우 간단하다. init 스크립트를 사용하면 된다.
 psad가 init 스크립트를 통해 시작되면 주 psad 데몬, kmsgsd, psadwatchd 와 같은 세 개의 데몬도 시작된다. kmsgsd 는 psad 가 iptables 로그를 실시간으로 분석할 수 있게 /var/lig/psad/psadfifo 명명된 파이프로부터 모든 iptables 로그 메시지를 읽어 와서 별도의 파일인 /var/log/psad/fwdata 에 기록한다. 이를 통해 psad 는 iptables 로그 메시지만을 포함하는 데이터 스트림을 제공받는다.

 psad는 설치 시에 시스템 syslog 데몬이 info 우선순위를 가지는 모든 커널 메시지(또는 syslog 용어로 kern.info 메시지)를 명명된 파이프 /var/lib/psad/psadfifo 에 기록하게 재설정한다.

 psadwatchd 데몬은 단순히 psad와 kmsgsd 데몬이 실행 중인지 확인하고 그렇지 않으면 이들을 재시작한다. psadwatchd 는 두 데몬 중 하나를 재시작해야 하면 /etc/psad/psad.conf 파일에 있는 메일 주소로 경고 메일을 전송한다.

 – 데몬 프로세스의 유일성

 psad 가 시작되면 세 개의 psad 데몬은 각기 자신만의 프로세스 ID(PID)를 /var/run/psad 내의 파일에 기록한다. 명령 행에서 수동으로 데몬을 시작하면 해당 데몬은 우선 다른 인스턴스가 실행 중인지 확인하고 실행 중이라면 새로운 인스턴스는 바로 종료한다. 이를 통해 이미 존재하는 psad 프로세스를 그대로 유지할 수 있다.

 – iptables 정책 설정

 기본적으로 psad 는 로그 분석기다. psad 는 자신이 설치된 시스템상의 iptables 정책이 기록 후 버리기 전략으로 설정됐다고 가정한다. 이는 iptables 가 네트워크의 동작을 위해서 꼭 필요한 패킷만을 수용하게 보장해주며 다른 모든 패킷은 기록 후 버린다. 포트 스캔, 백도어 프로그램을 위한 탐사, 시스템을 전복시키는 애플리케이션 명령, 기타 불법적인 걱듯이 수용 가능한 네트워크 트래픽 목록에서 제외되므로 이런 정책으로부터 나온 iptables 기록은 보통 전용 침입 탐지 시스템에 가치 있는 데이터를 제공할 수 있다.

 psad는 로컬 iptables 정책이 INPUT 과 FORWARD 체인 모두에서 기본 LOG와 DROP 규칙으로 설정됐는지 확인해주는 자동 기법을 제공한다. 이 기법은 /usr/sbin/fwcheck_psad 에 위치한 전용 스크립트로 (psad 실행 시 –no-fwcheck 명령 행 스위치를 주거나 psad 가 별도의 syslog 서버에서 실행 중이지 않는 한) psad 가 시작할 때 실행한다. fwcheck_psad 스크립트는 IPTables::Parse 펄 모듈을 사용해 로컬 iptables 정책의 표현(representation)을 얻어오며 LOG와 DROP 규칙이 포함됐는지 알아보기 위해 이를 해석한다. 포함돼 있지 않다면 psad는 iptables 정책이 알맞게 설정되지 않았다는 것을 알려주기 위해 설정 경고 메일을 전송한다.

 iptables 정책은 매우 복잡할 수 있기 때문에 정책이 로그와 버리기 전략을 가지는지 결정하는데에 IPTables::Parse 모듈의 구문 분석 기능이 항상 충분하지는 않다. 검사가 실패하더라도 psad는 여전히 동작할 수 있으며, psad의 효과는 iptables가 기록하는 패킷의 유형에 따라 달라진다. 실제로 SMB(윈도우에서 사용)와 같은 프로토콜은 필요 없는 내용을 너무 많이 포함하기 때문에 기로하기에 부적절하며, 이런 프로토콜을 통해 전송된 패킷은 주로 LOG 규칙과 일치될 수 있기 전에 받아들이거나 버린다. fwcheck_psad 가 올바로 구문 분석할 수 없을 정도로 복잡한 iptables 정책을 실행 중이라면 /etc/psad/psad.conf 의 ENABLE_FW_LOGGING_CHECK 변수를 N 으로 설정해서 이 검사를 비활성화할 수 있다.

 – syslog 설정

 패킷이 iptables 내에서 LOG 규칙에 매칭되면 커널은 커널 로깅 데몬인 klogd를 통해 이 사실을 보고한다. 이렇게 전달된 커널 로그 메시지는 보통 보고서 파일에 기록되기 위해 명명된 파이프나 버클리 소켓 인터페이스를 통한 별도의 시스템으로 전달된다. 이는 모두 syslog 데몬이 제공하는 기능과 syslog이 어떻게 설정됐는지에 따라 달라진다.

 syslogd와 syslog-ng 데몬은 psad와 호환되며, psad는 metalog도 제한된 방식으로 지원한다. syslogd와 syslog-ng는 명명된 파이프로 로그 메시지를 기록할 수 있으며, psad는 이를 이용하기 위해 모든 kern.info 로그 메시지가 명명된 파이프 /var/lib/psad/psadfifo에 기록되게 설정한다. 이곳으로 전달된 로그 메시지는 kmsgsd가 이용한다. kmsgsd는 psadfifo를 통해 syslog 메시지를 받으면 이 syslog 메시지가 iptables에 의해 생성됐다는 것을 보장하기 위해 두 개의 부분 문자열(IN= 과 OUT=)을 포함하는지 확인한다. 메시지가 이 검사를 통과하면 kmsgsd는 이를 psad가 볼 수 있게 파일 /var/log/psad/fwdata에 기록한다. 많은 kern.info syslog 메시지가 iptables와 아무런 관계도 없는 커널 일부에 의해 생성될 수 있으며, kmsgsd는 iptables 메시지만이 psad에 의해 분석되게 보장한다.

 IN=과 OUT= 문자열은 iptables LOG 타겟을 통해 기록된 패킷의 입력과 출력 인터페이스를 나타낸다. 이러한 문자열은 iptables 로그 메시지에 항상 포함된다.

 — syslogd
 syslogd가 설치된 시스템에서 psad가 실행중이라면 설치 시 /etc/syslog.conf 설정 파일에 다음과 같은 내용이 추가된다. 이는 syslogd가 kern.info 메시지를 /var/lib/psad/psadfifo에 기록하게 설정한다.
 

 – whois 클라이언트
 마르코 디트리(Marco d’itri)가 만든 훌륭한 whois(후이즈) 클라이언트가 psad 소스와 함께 제공된다. 이 클라이언트는 주어진 IP 주소에 대해 거의 항상 올바른 넷블록(netblock)을 질의하며, psad는 (–no-whois 명령 행 스위치를 주지 않는 한) IP 주소 소유 정보를 질의해서 메일 경고에 포함시키기 위해 이 클라이언트를 이용한다. 이런 정보를 가지면 스캔이나 기타 다른 공격이 탐지된 네트워크의 관리자 식별 과정이 단순해진다. 예를 들어 우리학교(http://www.kongju.ac.kr)의 IP(203.253.33.6)의 주소를 whois 탐지하면 다음과 같은 결과가 나온다.

 * psad 설정

 모든 psad 데몬은 /etc/psad에 있는 파일 psad.conf를 참조하며, 이 파일은 간단한 규약을 따른다. 주석은 # 기호로 시작하며 설정 매개변수는 키-값 형식으로 명시한다. 예를 들어 psad.conf의 HOSTNAME 변수는 psad가 설치된 시스템의 호스트명을 정의한다.

### Machine hostname
HOSTNAME                    extreme;

 모든 설정 변수 값은 값을 의미하는 문자열의 끝을 나타내기 위해 세미콜론으로 끝나야 한다. 그러므로 다름과 같이 문서화를 위해 세미콜론 다음에 주석을 포함시킬 수 있다.

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

 끝으로 psad 변수 값은 psad가 설정을 구문 분석할 때 확장되는 하위 변수를 포함할 수 있다. 예를 들어 psad의 주요 로깅 디렉토리는 PSAD_DIR 변수가 정의하며, 기본적으로 /var/log/psad로 설정된다. 다른 설정 변수는 다음과 같이 PSAD_DIR 변수를 참조할 수 있다.

PSAD_ERR_DIR                $PSAD_DIR/errs;

 – /etc/psad/psad.conf
 psad.conf 파일은 psad의 주요 설정 파일로 psad 동작의 다양한 면을 제어하기 위한 100개 이상의 설정 변수를 포함한다.

 설정에 관한 더 자세한 내용은 http://www.cipherdyne.org/psad/docs/index.html 에서 확인할 수 있다.

 — EMAIL_ADDRESSES
 EMAIL_ADDRESSES 변수는 psad가 스캔 경고, 정보 메시지, 기타 공지를 전송할 메일 주소를 정의한다. 콤마를 사용해서 여러 개의 메일 주소를 함께 나타낼 수도 있다.

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

—  DANGER_LEVEL{n}
 psad는 경고에 우선순위를 두기 위해 악의적인 모든 활동을 위험 수준에 따라 나눈다. 위험 수준은 1에서 5까지(5가 가장 안 좋은 것)이며, 공격이나 스캔이 탐지된 각 IP 주소에 할당된다. 위험 수준 값은 스캔의 특성(패킷 수, 포트 범위, 시간 간격), 특정 패킷이 /etc/psad/signatures 파일에 정의된 서명과 일치하는지 여부, 패킷이 /etc/psad/auto_dl 파일에 있는 IP나 네트워크로부터 시작됐는지 여부와 같은 세 가지 요소에 기반해 할당된다.

 포트 스캔의 경우 스캔의 패킷 수에 따라 DANGER_LEVEL{n} 변수 값이 달라지며, psad.conf 파일에 다음과 같이 정의돼 있다.

### 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;

 — HOME_NET
 psad는 의심스러운 네트워크 트래픽을 탐지하기 위해 수정된 스노트 규기을 사용하기 때문에 psad.conf 파일에서 psad가 사용하는 변수는 스노트가 사용하는 변수와 유사하다. HOME_NET 변수는 실행 중인 psad가 설치된 시스템의 로컬 네트워크를 정의한다. 그러나 psad와 스노트가 HOME_NET 변수를 처리하는 데에는 한가지 차이점이 있다. psad는 INPUT 체인에 기록된 모든 패킷의 목적지를 출발지 주소와 무관하게 홈 네트워크로 취급한다. 이는 iptables 방화벽 자체에서 라우팅됐기 때문이다. ENABLE_INTF_LOCAL 변수를 N으로 설정해서 이러한 동작을 재정의할 수 있다.

### 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;

 — EXTERNAL_NET
 EXTERNAL_NET 변수는 외부 네트워크를 정의한다. 기본 값은 any 이지만 HOME_NET 변수처럼 임의의 네트워크 목록으로 설정할 수 있다. 대부분의 경우 기본 값이 가장 좋을 것이다.

 — SYSLOG_DAEMON
 SYSLOG_DAEMON 변수는 psad 에게 로컬 시스템에서 실행 중인 syslog 데몬이 무엇인지 알려준다. 이 변수는 syslogd, syslog-ng, ulogd, metalog 중 하나의 값을 가진다. psad는 이 변수 값을 이용해서 해당 syslog 설정 파일이 kern.info 메시지를 명명된 파이프 /var/lib/psad/psadfifo에 기록하게 적절히 설정됐는지 확인한다. 단, psad가 ulogd를 통해 iptables 로그 메시지를 얻는 경우는 예외인데 ulogd가 메시지를 직접 디스크에 기록하기 때문에 syslog 데몬이 실행 중이지 않아도 된다. 이 경우 psad는 kmsgsd 데몬을 시작하지 않는다.

### 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;

 — CHECK_INTERVAL
 psad는 대부분의 시간을 대기하면서 보내며 새로운 iptables 로그 메시지가 /var/log/psad/fwdata 파일에 기록될 때만 활성화된다. 확인 시간 간격을 CHECK_INTERVAL 변수로 정의하며 초로 나타낸다. 기본 값은 5초다. 이 간격은 최소 1초까지 설정할 수 있지만 경고가 최대한 빨리 생성되길 원하는 경우가 아니라면 보통 이렇게 작은 값으로 설정할 필요는 없다.

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

  — SCAN_TIMEOUT
 기본적으로 SCAN_TIMEOUT 변수는 3600초(1시간)로 설정되며 psad는 이 값을 스캔이 추적되는 시간 간격으로 사용한다. 즉, 특정 IP 주소에서 악의적인 트래픽이 이 시간 간격동안 위험 수준 1에 도달하지 않으면 psad는 경고를 생성하지 않는다. ENABLE_PERSISTENCE를 Y로 설정하면 psad는 SCAN_TIMEOUT 변수를 무시한다.

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

 — ENABLE_PERSISTENCE
 포트 스캔 탐지 소프트웨어는 일반적으로 포트 스캔을 잡기 위해 두 개의 임계치를 설정해야 하는데, 조사되는 포트 수와 시간 간격이 그것이다. 공격자는 스캔되는 포트의 수를 줄이거나 스캔의 속도를 줄여서 포트 스캔이 이 임계치에 도달하지 않게 할 수 있다. ENABLE_PERSISTENCE 변수는 psad가 SCAN_TIMEOUT 변수를 스캔 탐지의 요소로 사용하지 않게 해준다. 이는 스캐너가 수일이나 수주에 걸쳐 목표 시스템을 천천히 스캔함으로써 시간 만료 임계치보다 낮은 수준에 머물게 하려는 시도를 무력화하는 데 유용하다. 스캔이 최소 DANGER_LEVEL1 변수에 의해 정의된 패킷수에 도달하면(이 수에 도달하는 데 걸린 시간이 얼마나 긴지에 무관하게) psad는 경고를 전송한다.

### 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;

 — PORT_RANGE_SCAN_THRESHOLD
 이 변수를 통해 psad가 위험 수준을 포트 스캔에 할당하기 전에 스캔돼야 하는 포트의 최소 범위를 정의할 수 있다. 기본적으로 PORT_RANGE_SCAN_THRESHOLD는 1로 설정되며, 이는 위험 수준 1에 이르기 전에 최소한 두 개의 서로 다른 포트가 스캔돼야 함을 의미한다. 한 IP 주소가 한 포트만을 반복적으로 스캔할 수 있는데, 이 경우 psad는 경고를 전송하지 않는다(최소 위험 수준 1이 할당되지 않은 활동에 대해서는 절대 경고가 전송되지 않으며, psad에서는 경고가 전송되는 최소 위험 수준을 1에서 5까지로 설정할 수 있다. “EMAIL_ALERT_DANGER_LEVEL” 참조). psad가 스캔되는 포트의 범위를 탐지 요소로 사용하게 하고 싶지 않다면 PORT_RANGE_SCAN_THRESHOLD를 0으로 설정하면 된다.

### 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;

 — EMAIL_ALERT_DANGER_LEVEL
 이 변수는 어떤 IP 주소가 최소 이 값과 동일한 위험 수준으로 할당되지 않는 한 psad가 메일 경고를 전송하지 않게 하는 위험 수준의 최소 값을 설정하는 데 쓰인다. 기본 값은 1이다.

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

 — MIN_DANGER_LEVEL
 MIN_DANGER_LEVEL 임계치는 psad가 수행하는 모든 경고와 추적기능을 위한 전역 임계치다. 예를 들어 MIN_DANGER_LEVEL이 2로 설정되면 psad는 특정 IP 주소가 위험 수준 2에 도달하기 전에는 이를 /var/log/psad/ip 디렉토리에 기록하지도 않는다. 그러므로 MIN_DANGER_LEVEL 변수는 항상 EMAIL_ALERT_DANGER_LEVEL 변수의 값보다 작거나 같게 설정해야 한다. 기본 MIN_DANGER_LEVEL 값은 1이다.

### 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;

 — SHOW_ALL_SIGNATURES
 이 변수는 psad가 모든 경고에서 IP 주소와 관련된 모든 서명 경고 정보를 포함하게 할지 여부를 결정한다. 이 변수를 활성화할 경우 특정 IP 주소가 오새동안 의심스러운 트래픽으로 한 사이트에 접속할 때 매우 긴 메일 경고가 초래될 수 있기 때문에 이는 기본적으로 비활성화된다. 그러나 SHOW_ALL_SIGNATURES가 비활성화된 경우에도 psad 메일 경고는 마지막 CHECK_INTERVAL에서 새로 촉발된 서명은 모두 포함한다.

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

 — ALERT_ALL
 이 변수가 Y로 설정되면 psad는 어떤 IP 주소로부터의 새로운 악의적인 활동이 위험 수준 1에 도달하는 한 이러한 활동이 탐지될 때마다 메일이나 syslog 경고, 또는 둘 모두를 생성한다. N으로 설정되면 IP 주소에 할당된 위험 수준이 증가할 때만 경고를 생성한다.

### 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;

 — SNORT_SID_STR
 이 변수는 어떤 iptables 로그 메시지가 스노트 규칙 하나를 완전하게 기술하는 iptables 규칙에 의해 생성됐는지 알아보기 위해 iptables 로그 메시지와 매칭시킬 부분 문자열을 정의한다. 이런 iptables 규칙은 fwsnort가 생성하며 일반적으로 로깅 접두어 SID{n}을 포함한다. 여기서 {n}은 원본 스노트 규칙에서 얻은 스노트 ID 번호다. SNORT_SID_STR의 기본 값은 단순히 SID다.

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

 — ENABLE_AUTO_IDS
 이 변수는 Y로 설정되는 경우 psad를 수동적 모니터링 데몬에서, (INPUT 체인과 OUTPUT 체인을 통해) 로컬 시스템과 (FORWARD 체인을 통해) 로컬 시스템에 의해 보호되는 모든 시스템과 연동해서 공격자 IP 주소를 차단하기 위해 로컬 iptables 정책을 동적으로 재설정함으로써 공격에 능동적으로 응답하는 프로그램으로 변환한다.

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

 — IMPORT_OLD_SCANS
 psad가 포트 스캔과 기타 의심스러운 활동에 대해 수집하는 정보는 /var/log/psad 디렉토리에 기록된다. 위험 수준 1에 도달한 모든 IP 주소에 대해 새 디렉토리 /var/log/psad/ip가 생성된다. 이 디렉토리에 저장되는 다양한 파일에는 가장 최근의 메일 경고, whois 출력, 서명 매칭, 위험 수준, 패킷 수가 포함된다. 처음 시작 시 psad는 보통 기존의 /var/log/psad/ip 디렉토리를 제거하지만 IMPORT_OLD_SCANS를 Y로 설정해서 기존의 디렉토리로부터 모든 데이터를 가져올 수 있다. 이 기능을 통해 이전 psad 인스턴스의 스탬 데이터를 잃지 않고 psad를 재시작하거나 전체 시스템을 재부팅할 수 있다.

### 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;

 — ENABLE_DSHIELD_ALERTS
 이 변수를 Y로 설정하면 psad는 스캔 데이터를 DSHield 분산 침입 탐지 시스템으로 전송한다. 스캔 정보는 민감한 정보일 수 있기 때문에 스캔 데이터를 DShield로 넘기면 해당 스캔 데이터는 더 이상 여러분의 제어 하에 있지 않으며 상대적으로 열린 데이터베이스로 구문 분석된다는 점을 알아야 한다. 그러나 DShield는 가장 일반적으로 공격당하는 서비스나 현재 대부분의 시스템을 공격하는 어떤 IP 주소가 무엇인지(이런 IP 주소는 엄격한 방화벽 규칙의 좋은 후보가 된다)에 대한 정보를 사용자가 좀 더 잘 이해할 수 있게 해준다. 필자(마이클 래쉬)는 DShield로 스캔 정보를 전송하면 안 된다는 엄격한 요구사항(예를 들어 사이트 보안 정책에서 이를 강제할 수 있다)이 없는 한 psad에서 이 기능을 활성화할 것을 강력히 권장한다. 많은 사람들이 이 기능을 활성화할수록 인터넷은 좀 더 안정해진다.

### 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;

 — IGNORE_PORTS
 많은 침입 탐지 시스템의 주요 기능은 관리자가 IDS로 하여금 완전히 무시하게 하고 싶은 데이터 조각을 필터링하는 기능이다. IGNORE_PORTS 변수는 psad가 목적지 포트 번호와 프로토콜(TCP나 UDP)에 기반해서 iptables 로그 메시지를 무시하게 한다. 포트 번위와 다중 포트, 프로토콜 조합은 다음과 같이 지정할 수 있다.

### 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;

 — IGNORE_PROTOCOLS
 IGNORE_PROTOCOLS 변수를 사용하면 psad는 전체 프로토콜을 무시할 수 있다. 대개는 iptables 정책을 조정해서 무시하고 싶은 프로토콜을 기록하지 않는 것이 더 좋지만 예를 들어 psad가 모든 ICMP 패킷을 무시하게 하고 싶다면 다음과 같이 IGNORE_PROTOCOLS를 설정하면 된다.

### 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            icmp;

 — IGNORE_LOG_PREFIXES
 iptables 정책은 매우 복잡할 수 있으며, 다수의 여러 가지 로깅 규칙을 포함할 수 있다. 또 각 로깅 규칙은 자신만의 로깅 접두어를 가질 수도 있다. psad가 특정 로깅 접두어(예를 들어 DROP:INPUT5:eth1)를 무시하게 하고 십다면 IGNORE_LOG_PREFIXES를 다음과 같이 설정하면 된다.

### Ignore these specific logging prefixes
IGNORE_LOG_PREFIXES         DROP:INPUT5:eth1;

 — EMAIL_LIMIT
 어떤 경우에는 Iptables 정책이 특정 트래픽을 기록하게 설정되는데, 이 트래픽이 네트워크상에서 여러 번 반복될 수 있다(예를 들어 특정 DNS 서버로의 DNS 요청). 이러한 트래픽이 스캔이라고 해석되면 해당 트래픽 자체가 반복되기 때문에 psad는 이 트래픽에 대해 다량의 메일 경고를 전송할 수 있다. EMAIL_LIMIT 변수를 사용하면 psad가 스캐닝 IP 주소에 대해 전송되는 메일 경고의 수에 제한을 두게 강제할 수 있다. 기본 값은 0으로 이는 제한이 없다는 것을 의미한다. 그러나 EMAIL_LIMIT 값을 50으로 설정하면 psad는 특정 IP 주소에 대해 50개 이상의 메일 경로를 전송하지 않는다.

### 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                 50;

 — ALERTING_METHODS
 대부분의 관리자는 psad가 제공하는 메일과 syslog 보고 모드를 모두 사용한다. 그러나 ALERTING_METHODS 변소를 이용하면 psad가 메일 경고와 syslog 경고 중 어떤 것을 생성하게 할지 제어할 수 있다. ALERTING_METHODS 변수는 noemail, nosyslog, ALL과 같은 세 가지 값을 가질 수 있다. noemail과 nosyslog 값은 psad가 메일이나 syslog 경고를 전송하지 않게 한다. 이 값들을 조합해서 모든 경고를 비활성화할 수도 있다. 기본 값은 둘 모두를 생성하는 것이다.

### 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;

 — FW_MSG_SEARCH
 FW_MSG_SEARCH 변수는 psad가 iptables 로그 메시지를 어떻게 검색할 지 정의한다. psad가 (iptables에 주는 –log-prefix 인자를 사용해 iptables LOG 규칙에 정의된) 특정 로그 접두어를 포함하는 로그 메시지만을 분석하게 제한하려면 FW_MSG_SEARCH 변수로 접두어를 정의하면 된다. iptables는 패킷에 FW_MSG_SEARCH 변수 값과 다른 로그 접두어를 할당하게 설정할 수 있으며 이 경우 psad는 해당 패킷을 분석하지 않는다.
 예를 들어 psad가 문자열 DROP을 포함하는 iptables 로그 메시지만을 분석하게 하려면 다음과 같이 FW_MSG_SEARCH 변수를 설정하면 된다.

### 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;

 – /etc/psad/auto_dl
 모든 IDS는 항상 높은 확률로 긍정 오류를 범한다. 그러므로 IDS는 특정 시스템, 네트워크, 프토토콜이 모든 탐지 동작과 (가장 중요하게는) 자동화된 모든 응답 기능에서 제외될 수 있게 해주는 허용 목록 기능을 갖춰야 한다. 또 특정 IP 주소나 네트워크가 공격자로 알려질 수도 있으므로 이들을 차단할 차단 목록 기능도 필요하다.

 이러한 요구사항은 다음과 같은 구문을 따르는 psad의 auto_dl 파일이 충족시킨다.

#  <IP address>  <danger level>  <optional protocol>/<optional ports>;

 위험 수준이 0으로 설정되면 psad는 해당 IP 주소나 네트워크를 완전히 무시한다. 반대로 특정 IP 주소나 네트워크가 극도로 악의적이라고 알려지는 경우에는 위험 수준을 5로 설정할 수 있다.

# Examples:
#
#  10.111.21.23    5;          # Very bad IP.
#  127.0.0.1       0;          # Ignore this IP.
#  10.10.1.0/24    0;          # Ignore traffic from this entire class C.
#  192.168.10.4    3    tcp;   # Assign danger level 3 if protocol is tcp.
#  10.10.1.0/24    3    tcp/1-1024;  # Danger level 3 for tcp port range

 – /etc/psad/signatures
 /etc/psad/signatures 파일은 약간 수정된 스노트 규칙을 약 200개 정도 포함한다. 이 규칙들을 psad가 iptables 로그 메시지로부터 바로 탐지할 수 있는 공격을 나타낸다. 이 규칙 중 어떤 것도 네트워크 트래픽에 대한 애플리케이션 계층 검사를 필요로 하지 않는다. 애플리케이션 계층 검사는 fwsnort가 수행한다. 이 파일에 있는 규칙을 하나 예로 들면 다음과 같다.

alert udp $EXTERNAL_NET any -> $HOME_NET 31335 (msg:”DDOS Trin00 Daemon to Master”; reference:arachnids,187; reference:url,www.sans.org/resources/idfaq/trinoo.php; classtype:attempted-recon; psad_dsize:>2; psad_id:100002; psad_dl:2; psad_derived_sids:223,231,232;)

 – /etc/psad/snort_rule_dl
 /etc/psad/auto_dl과 유사하게 snort_rule_dl 파일은 psad가 스노트 규치고가 매칭되는 모든 IP 주소의 위험 수준을 자동으로 설정하게 한다. 이 파일의 구문은 다음과 같다.

# Syntax: Each non-comment line of this file contains a snort ID number, and
#         the corresponding psad danger level like so: <sid> <danger level>.

 위험 수준이 0이라면 psad는 해당 서명 매칭을 무시하고 어떤 경고도 전송하지 않는다. 일부 서명 매칭은 다른 것보다 더 안 좋을 수 있다. 예를 들어 psad가 스노트 규칙 ID 1812(EXPLOIT gobbles SSH exploit attempt)와 매칭되는 트래픽을 탐지 했다면 이는 잠재적으로 스노트 규칙 ID 469(ICMP PING MAP)에 대한 매칭보다 훨씬 더 위험하다. 물론 고블스(Gobbles) SSH 공격의 효과를 제한하는 가장 좋은 전략은 애초에 취약한 SSH 데몬을 실행하지 않는 것이지만 이 공격을 탐지하는 것은 여전히 중요하다. 다음과 같이 스노트 규칙 2284와 매칭되는 IP 주소의 위험 수준을 5로 설정할 수 있다.

### The following example illustrates the syntax for Snort SID 2284
2284   5;

 – /etc/psad/ip_options
 IP 헤더의 옵션 부분이 IP 통신에서 자주 사용되지는 않지만 iptables는 –log-ip-options 명령 행 인자를 이용해서 IP 옵션을 기록할 수 있다. iptables 로그 메시지가 IP 옵션을 포함하는 경우 psad는 소스 라우팅(source routing) 시도와 같은 수상한 활동에 대해 이 옵션을 구문 분석한다. 일부 스노트 규칙은 IP 옵션의 의심스러운 사용을 정의하며, psad는 iptables 로그 메시지의 IP 옵션을 해석하기 위해 /etc/psad/ip_options 파일을 참조한다. 이 파일은 다음 구문에 따라 일반적으로 사용되는 IP 옵션과 이에 대응되는 식별 번호를 정의한다.

#  <option value> <length (-1 for variable)> <ipopts argument> <description>

 아래는 이를 활용한 예문이다.

#  <option value> <length (-1 for variable)> <ipopts argument> <description>
0    1   eol         End of options list
1    1   nop         NOP
130  11  sec         Security
131  -1  lsrr        Loose Source Route
### (lsrre is included in Snort but not documented anywhere else)
132  -1  lsrre       Loose Source Route
68   -1  ts          Timestamp

 – /etc/psad/pf.os
 psad는 원격 운영체제를 수동적으로 핑거 프린팅하기 위해 p0f 프로젝트의 OS 데이터베이스를 사용한다. 이 데이터베이스는 psad가 /etc/psad/pf.os 파일에 설치하며, psad는 처음 시작할 때(또는 Psad가 kill 명령어나 psad -H를 통해 중단(hangup)이나 HUP 신호를 받았을 때) 이를 불러온다.

 다음은 리눅스에 대한 p0f 핑거프린트의 예다.

# S1:64:0:44:M*:A:              Linux:1.2::Linux 1.2.x (XXX quirks support)
512:64:0:44:M*:                 Linux:2.0:3x:Linux 2.0.3x
16384:64:0:44:M*:               Linux:2.0:3x:Linux 2.0.3x