리눅스에서 퍼포먼스를 확인할 때 사용가능한 툴모음. 깔끔한 내용정리가 포인트!
scalelinuxperformance-130224171331-phpapp01
출처: http://www.slideshare.net/brendangregg/linux-performance-analysis-and-tools#
리눅스에서 퍼포먼스를 확인할 때 사용가능한 툴모음. 깔끔한 내용정리가 포인트!
scalelinuxperformance-130224171331-phpapp01
출처: http://www.slideshare.net/brendangregg/linux-performance-analysis-and-tools#
* fwknop 설치
fwknop 의 설치는 http://www.cipherdyne.org/fwknop/download/ 에서 최신 소스 tarball 이나 RPM을 받는 것이다. 역시 MD5 합을 확인하는 것이 좋으며, 보안적 관점에서는 GnuPG 서명을 확인하기 위해 GnuPG를 사용하는 것이 더 좋다. 받은 파일이 안전하다고 판명되면 설치 과정을 진행할 수 있다.

이제 압축을 풀고 install.pl 스크립트를 실행하여 설치를 진행하자.
아래 보이는 에러 메시지는 필자의 서버에 make 유틸리티의 설치가 되어있지 않아 발생한 문제로, 데비안/우분투 배포판의 경우,
# apt-get install make
의 명령어로 설치가 가능하다.
fwknop 의 설치 스크립트 install.pl 은 사용자에게 권한 부여 모드(SPA 모드나 기존의 포트 노킹 모드)나 fwknop가 패킷을 스니핑할 인터페이스와 같은 몇 가지 정보를 질문할 것이다.
아래는 필자가 fwknop 프로그램을 설치하면서 선택한 옵션들이다.
[+] fwknop can act as a server (i.e. monitoring authentication packets
and sequences, and taking the appropriate action on the local system
to alter the firewall policy or execute commands), or as a client (i.e.
by manufacturing authentication packets and sequences).In which mode will fwknop be executed on the local system? (Note that
fwknop can still be used as a client even if you select “server” here).
(client/[server]): server[+] In server mode, fwknop can acquire packet through a pcap file that is
generated by a sniffer (or through the Netfilter ulogd pcap writer), or
by sniffing packets directly off the wire via the Net::Pcap perl module.
Fwknop can also acquire packet data from iptables syslog messages, but
this is only supported for the legacy port knocking mode; Single Packet
Authorization (SPA), which is used in the pcap modes, is a better
authorization strategy from every perspective (see the fwknop man page for
more information). If you intend to use iptables log messages (only makes
sense for the legacy port knocking mode), then fwknop will need to
reconfigure your syslog daemon to write kern.info messages to the
/var/lib/fwknop/fwknopfifo named pipe. It is highly recommended
to use one of the pcap modes unless you really want the old port knocking
method.Which of the following data acquistion methods would you like to use?
([pcap], file_pcap, ulogd, syslogd, syslog-ng): pcap[+] It appears that the following network interfaces are attached to the
system:
eth0
eth1
lo
Which network interface would you like fwknop to sniff packets from? eth0
[+] fwknop access alerts will be sent to:root@localhost
[+] Would you like access alerts sent to a different address ([y]/n)?
[+] To which email address(es) would you like fwknop alerts to be sent?
You can enter as many email addresses as you like; each on its own line.End with a “.” on a line by itself.
Email Address: root@localhost
Email Address: .
[+] Enable fwknop at boot time ([y]/n)? n[+] fwknop has been installed! To start in server mode, run
“/etc/init.d/fwknop start”
You may want to consider running the fwknop test suite in the test/
directory to ensure that fwknop will function correctly on your system.Note: You will need to edit /etc/fwknop/access.conf for fwknop to
function properly in server mode. More information can be found in
the fwknopd(8) manpage.
fwknop는 SPA 클라이언트로서 SPA 패킷을 전송만 할 수 있게 설치할 수도 있고 SPA 패킷을 전송하는 것뿐만 아니라 네트워크로부터 SPA 패킷을 스니핑할 수도 있게(이것이 기본 값이다) 설치할 수도 있다. fwknop를 전체 설치하면 파일 시스템에 다음과 같은 기본 동작을 지원하기 위한 다양한 파일과 디렉토리가 생성된다.
/usr/bin/fwknop : 사용자로부터 암호를 입력받고 fwknop 패킷 형식을 따르는 SPA 패킷을 구성한 후 라인달 대칭 키 알고리즘이나 GnuPG 비대칭 암호화 알고리즘(GnuPG 와 연동)으로 패킷 데이터를 암호화하고 암호화된 SPA 패킷을 UDP, TCP, 또는 ICMP 를 통해 전송하는 클라이언트 프로그램이다. 기본적으로 fwknop는 UDP 포트 62201로 SPA를 전송하지만 명령 행에서 이를 변경할 수 있다.
/usr/bin/fwknopd : SPA 패킷 데이터의 스니핑과 평문화, 재전송 공격으로부터의 보호, fwknop SPA 해킷 형식의 디코딩, 접근 권한 확인, SPA 패킷이 요청한 서비스로 일시적인 권한을 보여하기 위한 로컬 iptables 정책의 재설정을 담당하는 주요 데몬이다.
/usr/bin/fwknop_serv : SPA 패킷이 Tor 익명화 네트워크(http://tor.eff.org)를 통해 전송될 때만 쓰이는 간단한 TCP 서버다. 이 서버를 사용하면 양방향 통신을 하게 되므로 SPA 프로토콜의 통상적인 단방향 특성이 깨지게 된다.
/usr/lib/fwknop : fwknop이 사용하는 펄 모듈은 시스템 펄 라이브러리를 보존하기 위해 이 디렉토리에 설치된다. 설치되는 모듈은 Net::Pcap, Net::IPv4Addr, Net::RawIP, IPTables::Parse, IPTables::ChainMgr, Unix::Syslog, GnuPG::Interface, Crypt::CBC, Crypt::Rijndael 이다. install.pl 스크립트는 디스크 사용을 최소화하기 위해 시스템 펄 라이브러리 트리에 없는 펄 모듈만을 설치한다. 그러나 –force-mod-install 명령 행 인자를 사용해서 install.pl 이 필요한 펄 모듈 전체를 설치하게 할 수도 있다. IPTables::Parse 와 IPTables::ChainMgr 모듈은 ipfw 방화벽을 실행 중인 시스템에 설치하거나 윈도우의 시그윈(Cygwin)에 클라이언트 전용 모드로 설치하는 경우에는 절대 설ㅊ되지 않는다.
/etc/fwknop : fwknop.conf 나 access.conf와 같은 fwknop 데몬 설정 파일을 위한 주요 디렉토리이다. 이 디렉토리는 서버 모드로 실행될 때 fwknop 데몬이 사용하며, 클라이언트 모드에서 SPA 패킷을 전송할 때는 필요치 않다.
/usr/sbin/knopmd : 명명된 파이프 /var/lib/fwknop/fwknopfifo 에서 iptables 로그 메시지를 구문 분석하는 데 쓰이는 데몬이다. 이 데몬은 fwknop 가 포트 노킹 모드로 실행될 때만 쓰인다.
/usr/sbin/knoptm : fwknop가 적법한 SPA 클라이언트를 위해 접근 규칙을 추가한 iptables 체인에서 규칙 항목을 제거하는 데몬이다. 주 fwknopd 데몬은 실시간 인터페이스로부터 스니핑하며, OS는 fwknopd가 인터페이스에 의해 패킷을 수신할 때까지 fwknopd의 실행을 스케쥴링하지 않기 때문에 이 데몬이 필요하다. fwknopd가 별도의 스니퍼 프로세스나 ulogd에 의해 갱신되는 PCAP 파일에서 패킷 데이터를 읽을 때는 knoptm 데몬이 사용되지 않는다. 이 경우 fwknopd 는 인터페이스에서 패킷이 수신됐는지 여부와 무관하게 주기적으로 실행되게 스케줄링되며, iptables 규칙에 대한 시간 만료를 직접 강제할 수 있다.
/usr/sbin/knopwatched : 데몬이 죽는 경우 이를 재시작하는 감시 데몬이다. 그러나 일반적으로 fwknop는 매우 안정적이므로 knopwatchd이 실질적으로 쓰이는 경우는 거의 없다. 그러나 SPA를 실행한다는 것은 fwknop가 실행 중이지 않다면 어떤 것도 보호된 서비스로 접근할 수 없다는 것을 의미하므로 단순한 예방 조치로서 이 데몬이 필요하다.
/etc/init.d/fwknop : fwknop를 위한 초기화 스크립트로 사용자가 대부분의 리눅스 배포판과 동일한 방식(/etc/init.d/fwknop start)를 실행하는 방식으로 fwknop를 시작할 수 있게 해준다. init 스크립트를 사용하는 것은 fwknop를 서버 모드로 시작할 때만 가능하다.
* fwknop 설정
서버 모드에서 fwknop는 설정 지시어를 위해 두 개의 주요 설정 파일인 fwknop.conf 와 access.conf 를 참조한다. psad 설정 파일(5장 참조)과 마찬가지로 설정 파일의 각 행에는 설정 변수를 정의하기 위한 간단한 키-값 규약이 나온다. 주석 행은 #로 시작한다.
** /etc/fwknop/fwknop.conf
fwknop.conf 파일은 인증 모드, 방화벽 유형, 패킷을 스니핑할 인터페이스, 패킷을 무차별적으로 스니핑할지 여부(즉, fwknoop가 로컬 인터페이스의 MAC 주소를 목적지로 가지지 않는 이더넷 프레임을 처리할지 여부), 경고가 전송될 메일 주소 등과 같은 중요한 설정 변수를 정의한다.
– AUTH_MODE
AUTH_MODE 는 fwknop 데몬에게 패킷 데이터를 어떻게 수집할지 알려준다.
### This defines the general strategy fwknop uses to authenticate remote
### clients. Possible values are “PCAP” (authenticate via regular pcap; this
### is the default and puts the interface in promiscuous mode unless
### ENABLE_PCAP_PROMISC is turned off) FILE_PCAP (authenticate via a pcap file
### that is built by a sniffer), ULOG_PCAP (authenticate via the ulogd pcap
### writer). This variable can also be set to “KNOCK” if you really want to
### use the legacy port knocking mode.
AUTH_MODE PCAP;
– PCAP_INTF
PCAP_INTF 변수는 fwknop 데몬이 패킷을 감시하기 위해 사용하는 실시간 인터페이스를 정의한다. 이 변수는 AUTH_MOD 가 PCAP으로 설정된 경우에만 사용된다.
### Define the ethernet interface on which we will sniff packets. Note
### that this is only used if the AUTH_MODE keyword above is set to
### “PCAP”
PCAP_INTF eth0;
– PCAP_FILTER
실시간 인터페이스는 SPA 트래픽과 전혀 무관한 다량의 패킷을 전송하거나 수신할 수 있으며, fwknop 데몬이 이런 패킷까지 처리하게 할 필요는 없다. PCAP_FILTER 변수는 libpcap 이 네트워크 계층 주소나 전송 포트 번호 등과 같은 기준에 기반해서 fwknop에게 전달하는 패킷 유형을 제한할 수 있게 해준다.
### Define the filter used for PCAP modes; we default to udp port 62201.
### However, if an fwknop client uses the –rand-port option to send the
### SPA packet over a random port, then this variable should be updated to
### something like “udp dst portrange 10000-65535”;
PCAP_FILTER udp port 62201;
– ENALBLE_PCAP_PROMISC
이 변수는 Y로 설정될 경우 fwknop 데몬이 실시간 패킷 캡처 인터페이스를 통해 전송되는 모든 이더넷 프레임을 감시하게 한다(즉, 인터페이스가 무차별 모드로 동작한다). 이 변수는 AUTH_MODE가 PCAP으로 설정된 경우 기본적으로 활성화된다. 그러나 fwknop 데몬이 스니핑하는 인터페이스가 활성화 상태로 할당된 IP 주소를 가지고 있다면, 즉 이 인터페이스를 통해 SPA 패킷을 직접 전송할 수 있다면 기능을 비활성화 할 수 있다.
### Define whether put the pcap interface in promiscuous mode.
ENABLE_PCAP_PROMISC Y;
– FIREWALL_TYPE
FIREWALL_TYPE 변수는 fwknopd가 유효한 SPA 패킷을 수신한 후 재설정해야 하는 방화벽 유형을 알려준다. 지원되는 값은 iptables(기본 값)와 FreeBSD나 Mac OS X 시스템을 위한 ipfw 다.
### Define the firewall type. The default is “iptables” for Linux systems,
### but this can be set to “ipfw” for *BSD systems. Also supported is
### “external_cmd” to allow fwknop to invoke an external command instead of
### interfacing with the firewall at all
FIREWALL_TYPE iptables;
– IPT_AUTO_CHAIN1
IPT_AUTO_CHAIN1 변수의 기본 설정은 맞춤형 iptables 체인 FORWARD_INPUT에 ACCEPT 규칙을 추가하고 패킷을 고유 INPUT 체인에서 이 체인으로 건너뛰게 하는 것이다.
### fwknop uses the IPTables::ChainMgr module to add allow rules to a
### custom iptables chain “FWKNOP_INPUT”. This chain is called from
### the INPUT chain, and by default no other iptables chains are used.
### However, additional chains can be added (say, if access needs to
### be allowed through the local system via the FORWARD chain) by
### altering the IPT_FORWARD_ACCESS variable below. For a discussion of
### the format followed by these keywords, read on:
### Specify chain names to which iptables blocking rules will be
### added with the IPT_INPUT_ACCESS and IPT_FORWARD_ACCESS keyword.
### The format for these variables is:
### <Target>,<Direction>,<Table>,<From_chain>,<Jump_rule_position>,
### <To_chain>,<Rule_position>.
### “Target”: Can be any legitimate iptables 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 iptables 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 fwknop rules are added.
### “Rule_position”: Defines the position where rule are added within the
### To_chain.
IPT_INPUT_ACCESS ACCEPT, src, filter, INPUT, 1, FWKNOP_INPUT, 1;
### The IPT_OUTPUT_ACCESS variable is only used if ENABLE_IPT_OUTPUT is enabled
IPT_OUTPUT_ACCESS ACCEPT, dst, filter, OUTPUT, 1, FWKNOP_OUTPUT, 1;
### The IPT_FORWARD_ACCESS variable is only used if ENABLE_IPT_FORWARDING is enabled
IPT_FORWARD_ACCESS ACCEPT, src, filter, FORWARD, 1, FWKNOP_FORWARD, 1;
IPT_DNAT_ACCESS DNAT, src, nat, PREROUTING, 1, FWKNOP_PREROUTING, 1;
### The IPT_SNAT_ACCESS variable is not used unless both ENABLE_IPT_SNAT and
### ENABLE_IPT_FORWARDING are enabled. Also, the external static IP must be
### set with the SNAT_TRANSLATE_IP variable. The default is to use the
### IPT_MASQUERADE_ACCESS variable.
IPT_SNAT_ACCESS SNAT, src, nat, POSTROUTING, 1, FWKNOP_POSTROUTING, 1;
IPT_MASQUERADE_ACCESS MASQUERADE, src, nat, POSTROUTING, 1, FWKNOP_POSTROUTING, 1;
– ENABLE_MD5_PERSISTENCE
ENABLE_MD5_PERSISTENCE 변수는 fwknop 데몬이 성공적으로 평문화된 SPA 패킷의 MD5 합을 디스크에 기록할지 여부를 제어한다. (필자가 설치한 fwknop-1.9.12 버전은 약간 다르게 되어 있었다. DIGEST_TYPE 에서 암호화 방식을 결정한 후, 그것의 기록여부를 확인하는 방식이었다)
### Track digest sums associated with previous fwknop process. This allows
### digest sums to remain persistent across executions of fwknop.
ENABLE_DIGEST_PERSISTENCE Y;### Default to using all three of SHA256, SHA1, and MD5 for SPA replay attack
### detection. This is overkill, but performance is not usually a concern.
### Further, the variable can also be set to “SHA1” or “MD5”.
DIGEST_TYPE ALL;
– MAX_SPA_PACKET_AGE
MAX_SPA_PACKET_AGE 변수는 fwknop 서버가 SPA 패킷을 수용할 수 있는 최대 나이를 초로 정의한다. 기본 값은 2분이다. 이 변수는 ENABLE_SPA_PACKET_AGING 이 활성화된 경우에만 사용한다.
### This instructs fwknopd to not honor SPA packets that have an old time
### stamp. The value for “old” is defined by the MAX_SPA_PACKET_AGE variable.
### If ENABLE_SPA_PACKET_AGING is set to “N”, fwknopd will not use the client
### time stamp at all.
ENABLE_SPA_PACKET_AGING Y;### Defines the maximum age (in seconds) that an SPA packet will be accepted.
### This requires that the client system is in relatively close time
### synchronization with the fwknopd server system (NTP is good). The default
### age is two minutes.
MAX_SPA_PACKET_AGE 120;
– REQUIRE_SOURCE_ADDRESS
REQUIRE_SOURCE_ADDRESS 변수를 통해 fwknop 서버는 모든 SPA 패킷이 암호화된 페이로드에 iptables 를 통해 접근 권한을 부여 받을 IP 주소를 포함하게 요구할 수 있다. 이 기능을 활성화하면 fwknop 클라이언트 명령 행에서 -s 인자를 사용한 SPA 패킷에 위치한 0.0.0.0 와일드카드 IP 주소는 수용되지 않는다.
### Force all SPA packets to contain a real IP address within the encrypted
### data. This makes it impossible to use the -s command line argument on
### the fwknop client command line, so either -R has to be used to
### automatically resolve the external address (if the client behind a NAT) or
### the client must know the external IP.
REQUIRE_SOURCE_ADDRESS N;
– EMAIL_ADDRESS
fwknop 서버는 SPA 패킷이 수용되고 서비스로의 접근 권한이 부여될 때, 접근 권한이 제거될 때, 재전송 공격이 무력화됐을 때 등과 같은 여러 상황에서 메일 경고를 전송한다. 콤마를 이용해서 여러 개의 메일 주소를 명시할 수도 있다.
### Supports multiple email addresses (as a comma separated
### list).
EMAIL_ADDRESSES root@localhost;
– GPG_DEFAULT_HOME_DIR
GPG_DEFAULT_HOME 변수는 전자 서명 확인과 SPA 패킷의 평문화를 위해 GnuPG 키가 저장되는 디렉토리의 경로를 명시한다. 기본 값은 루트의 홈 데릭토리에 있는 .gnupg 디렉토리다.
### If GPG keys are used instead of a Rijndael symmetric key, this is
### the default GPG keys directory. Note that each access block in
### /etc/fwknop/access.conf can specify its own GPG directory to override
### this default.
GPG_DEFAULT_HOME_DIR /root/.gnupg;
– ENABLE_TCP_SERVER
ENABLE_TCP_SERVER 변수는 fwknop이 SPA 패킷 데이터를 수용하기 위해 특정 포트로 TCP 서버를 바인딩할지 여부를 제어한다. SPA 패킷이 데이터 전송에 TCP 만을 사용하는 Tor 네트워크를 통해 라우팅되길 바란다면 이 기능은 활성화해야 한다. 이 기능은 기본적으로 비활성화돼있다.
### Note that fwknopd still only gets its data via pcap (unless AUTH_MODE is
### set to ‘SOCKET’), so the filter defined by PCAP_FILTER needs to be updated
### to include the tcp or udp port if either of these variables are enabled.
ENABLE_TCP_SERVER N;
ENABLE_UDP_SERVER N;### Set the default port number for a “dummy” tcp or udp server (udp is
### best to use since nothing will be sent back to the client, so as far as a
### scanner can tell the port is ‘filtered’). The server is only spawned when
### ENABLE_TCP_SERVER or ENABLE_UDP_SERVER is set to “Y”.
TCPSERV_PORT 62201;
UDPSERV_PORT 62201;
** /etc/fwknop/access.conf
/etc/fwknop/access.conf 파일은 평문화 암호나 사용자에게 할당된 권한 부여 권리와 같은 내용을 담당한다.
#
# File: access.conf
#
# Purpose: This file defines how fwknop will modify firewall access controls
# for specific IPs/networks. It gets installed by default at
# /etc/fwknop/access.conf and is consulted by fwknop when run in
# “access control mode”, which is the default (i.e. when fwknop is
# run from the command line without any command line arguments).
# Normally fwknop is used in Single Packet Authorization (SPA) mode
# but the legacy port knocking mode is also supported. Multiple
# access controls can be specified for the same source machine, and
# access for arbitrary addresses is also defined in this file.
#
# See the fwknop man page for a comprehensive treatment of the various
# access control variables. See the README.ACCESS file for additional
# examples on how to configure access for various services.
#
##############################################################################
#
# $Id: access.conf 1145 2008-06-28 15:41:17Z mbr $
#### default Single Packet Authorization (SPA) via libpcap:
SOURCE: ANY;
OPEN_PORTS: tcp/22; ### for ssh (change for access to other services)
KEY: __CHANGEME__;
FW_ACCESS_TIMEOUT: 30;
### if you want to use GnuPG keys (recommended) then define the following
### variables
#GPG_HOME_DIR: /root/.gnupg;
#GPG_DECRYPT_ID: ABCD1234;
#GPG_DECRYPT_PW: myGpgPassword;
#GPG_REMOTE_ID: 1234ABCD;
– SOURCE
SOURCE는 fwknop가 유효한 SPA 패킷의 접근 수준을 결정하게 해주는 주요 구분 변수다.SOURCE 변수의 기본 값은 위에 나온 것처럼 fwknop가 임의의 주소로부터 온 SPA 패킷을 검증하게 하지만 개별 IP 주소나 CIDR 네트워크도 지원된다.
– OPEM_PORTS
OPEN_PORTS 변수는 fwknop 이 로컬 iptables 정책을 재설정해서 특정 포트에 접근 권한을 부여하게 한다. PERMIT_CLIENT_PORTS 변수가 Y로 설정돼있지 않는 한 클라이언트는 OPEN_PORTS에 나열된 것을 제외하고는 어떤 서비스로의 접근 권한도 얻을 수 없다.
– PERMIT_CLIENT_PORTS
– ENABLE_CMD_EXEC
– CMD_REGEX
– DATA_COLLECT_MODE
– REQUIRE_USERNAME
– FW_ACCESS_TIMEOUT
– KEY
– GPG_DECRYPT_ID
– GPG_DECRYPT_OW
– GPG_REMOTE_ID
* fwknop SPA 패킷 형식
모든 SPA 패킷은 잘 정의된 규칙들에 따라 구성된다. 이러한 규칙은 fwknop 서버가 iptables를 통해 요청되는 접속의 유형과 요청하는 ㅅ용자를 확신할 수 있게 해준다. fwknop 클라이언트 명령 행으로부터 사용자 입력을 받은 후 SPA 패킷은 다음을 포함한다.
– 무작위 데이터(16바이트) : fwknop이 생성하는 모든 SPA 패킷이 유일하게 보장하기에 충분한 무작위 정보를 제공한다. 패킷의 유일성은 최소한 펄 함수 rand()가 매호출 시마다 제공할 수 있는 무작위성 정도와 같다.
– 사용자명 : fwknop 명령을 실행하는 사용자명으로 getlogin()이나 getlogin()이 실패할 경우 gwtpwuid()가 반환하는 것과 동일하다. fwknop 서버는 원격 사용자에게 명령을 실행하거나 서비스에 접속할 권한을 줄 것인지 결정하기 위해 이 사용자명을 사용한다(fwknop 서버가 사용자명을 보는 시점에서 SPA 패킷이 성공적으로 평문화돼 있다).
– 타임 스탬프 : 로컬 시스템상의 타임 스탬프다.
– 소프트웨어 버전 : fwknop 클라이언트의 버전이다.
– 모드 : fwknop 서버는 이 값을 통해 SPA 클라이언트가 명령을 실행하고자 하는지 여부를 알 수 있다. 기본 값은 접근 모드에 해당하는 1이다. 명령 모드는 0으로 나타낸다.
– 접근 지시어 : 정책이 수정될 때 fwknop 서버에게 클라이언트가 iptables 방화벽에 의해 허용되길 바라는 트래픽 유형을 알려준다. fwknop 서버는 이 문자열은 구문 분석해서 포트와 프로토콜을 구한 후 iptables 가 이를 허용하게 정책을 적절히 재설정한다.
– 명령 문자열 : fwknop 클라이언트가 서버에서 실행하고자 하는 전체 명령이다.
– 패킷 MD5 합 : MD5 합은 fwknop 클라이언트가 게산하며 패킷이 네트워크를 통해 전소오디는 도중 변겨오디지 않았다는 것을 추가적으로 확인하기 위해 SPA 패킷에 포함된다.
– 서버 인증 방법 : 이 항목은 fwknop 0.9.6 배포판에서 패킷 형식에 추가됐다. fwknop 서버는 이 값을 통해서 SPA 패킷 내에 추가적인 인증 매개변수를 요구할 수 있다.
* 공격 수단 축소
IDS에 의해 감시되는 스푸핑된 공격은 긍정 오류를 생성하지 못하며, 기본 버리기 패킷 필터 때문에 세션이 숫립될 수 없으므로 수립된 TCP 세션을 통해 실제 공격을 전달하려는 시도도 실패한다. 그러므로 포트 노킹과 SPA는 네트워크 서비스에 대해 공격을 가할 수 있는 수단을 감소시킨다. iptables 가 제공하는 기능을 통해 효과적인 포트 노킹과 PSA 시스템을 쉽게 구현할 수 있다. SSHD와 같은 서비스에 이렇게 추가적인 보안 계층을 추가함으로써 시스템이 침투되지 않고 안전한 상태로 유지되게 할 수 있다.
* 제로 데이 공격 문제
Bugtraq, 풀-디스클로저, Vuln-dev 메일링 리스트는 매우 활발하며, 최신 공격 기술에 대해 아주 훌륭한 기술 정보와 논의를 제공한다. 회사 전체(예를 들어 iDefense, http://idefense.com 참조)가 취약점 추적에 기반한 사업 모형을 가지고 사용자를 위한 취약점 조기 경고 시스템을 제공하기도 한다. iDefense 는 새로운 취약점을 발견한 사람에게 돈을 지불하고 자신이 취약점을 먼저 공개할 권리를 사기도 한다.
상용으로 개발되는 대부분의 소프트웨어는 보안이 아니라 이익을 극대화하려는 고객을 위해 개발된다. 그러나 피싱(phishing), 스파이웨어, 신원 도난, 마이크로소프트 시스템을 목표로 하는 특히 치명적인 웜(코드 레드와 SQL 슬래머 등)과 같이 보안 문제의 분류가 세분화됨에 따라 회사들이 보안을 강조하기 시작했다.
그렇다면 한가지 의문점이 든다. 왜 이렇게 보안 취약점이 많은가?
– 소프트웨어는 항상 구현에 따라 달라지며 소프트웨어가 안전하다는 것을 엄밀히 증명해주는 방법은 존재하지 않는다. 구현상 버그로 인해 이론적으로 안전한 소프트웨어 설계가 보안 문제에 노출될 수 있다.
– OpenSSH 프로젝트(http://www.openssh.org 참조)를 살펴보자. OpenSSH는 세계에서 가장 예리하며 보안을 고려하는 개발자들이 작성하지만 이런 OpenSSH 조차 취약점을 가져왔다. 이는 버그가 없는 소프트웨어를 작성하는 것이 정말로 힘들며 최고의 보안 개발자들도 실수한다는 사실을 말해준다.
** 제로데이 공격 발견
제로 데이 공격(zero-day attack)은 소프트웨어에서 누군가가 이전에 발견되지 않은 보안 취약점을 발견한 후 이에 대한 공격을 작성할 때 발생한다. 얼마 동안은 이 사람만 이 취약점을 알고 있게 되는데, 이때 그는 선택의 기로에 놓인다. 공격을 사용하지 않고 취약점을 수정할 수 있게 소프트웨어 회사에게 알리는 길과 개인적인 이득을 위해 공격을 사용하고 누구에게도 알리지 않는 길이 있다. 후자는 분명 소프트웨어 사용자에게 가장 큰 위협이며, 제로 데이 공격은 선의의 해커와 악의의 해커 모두에 의해 점점 더 많이 발견되고 있다.
** 서명 기반 탐지의 영향
스노트 규칙집합의 일부 서명은 공격자가 특권을 얻은 후 시스템을 수상한 방식으로 사용하려는 시도를 일반적으로 탐지하게 설계됐다. 이는 때때로 스노트가 공격 자체를 탐지할 필요 없이 제로 데이 공격의 영향(즉, 공격자가 권한을 얻은 후 실제로 침투된 시스템을 사용하려고 할 때)을 탐지하게 해준다.
제로 데이 취약점 문제로 인해 네트워크 이상 탐지 시스템(Network Anomaly Detection System)을 개발하는 새로운 분류의 보안 회사가 등장했다. 네트워크 탐지 시스템은 컴퓨터 네트워크 내의 이상 행위를 탐지하게 설계된 제품이다. 이런 시스템의 목표는 공격자가 침투에 성공한 후 네트워크 내에서 시스템을 사용하는 방식을 탐지하는 것이다.
하지만 문제는 일상적인 동작과 비일상적인 동작을 구별하기에는 너무 큰 이종성이 네트워크에 존재한다는 것이다. 상용 회사와 하계 모두에서 알려지지 않은 취약점에 대한 공격의 영향을 어떻게 줄일지 활발히 연구하고 있지만 아직 일반적인 해결책은 없다.
* 포트 노킹
2003년 마틴 크리지빈스키는 시스어드민(Sysadmin)에 실은 글에서 포트 노킹(port knocking)이라는 훌륭한 개념을 보안 커뮤니티에 소개했다. 포트 노킹은 서비스(예를 들어 SSHD)가 기본 버리기 전략으로 설정된 패킷 필터에 의해 보호되게 해주는 닫힌 포트를 통한 인증 데이터의 통신이다. 기본 버리기 패킷 필터를 통해 보호되는 서비스에 연결하고자 하는 클라이언트는 우선 유효한 포트 노크 나열(port knock sequence)을 소유하고 있다는 것을 증명해야 한다. 클라이언트가 (예를 들어 적절한 순서로 포트 나열을 구성하는 포트에 연결함으로써) 올바른 노크 나열을 생성하면 패킷 필터는 보호되는 서비스에 연결하기 위해 포트 나열을 전송한 IP 주소를 잠시 허용하게 일시적으로 재설정 된다.
포트 노킹은 빠르게 전파됐으며, 보안 분야에서 알려진 포트 노킹 구현 기법만 거의 30개에 이른다. 각 구현은 포트 노킹의 개념을 약간씩 다르게 제공하는데, 예를 들어 cd00r과 포트 키(port key)는 포트 노크 나열을 전송하기 위해 TCP SYN 패킷을 사용하는 반면 텀블러(Tumbler)는 해싱된 인증 데이터를 전송하기 위해 패킷 페이로드를 사용한다.
** Nmap과 목표 식별 단계 무력화하기
포트 노킹 나열은 수동적인 방법(예를 들어 방화벽 로그 파일을 감시하거나 libpcap 과 같은 패킷 캡처 도구를 이용해서 인터페이스를 스니핑하는 방법)으로 네트워크를 감시할 수 있는 포트 노킹 서버가 감시한다. 포트 노킹 시스템을 사용하면 궁극적으로 네트워크를 오가는 트래픽을 감시할 수 없는 사람에게는 서비스가 보이지 않게 된다. Nmap 조차 기본 버리기 패킷 필터로 보호되는 서비스는 볼 수 없다. 공격자가 제로 데이 공격을 가지고 있더라도 달라지는 것은 없다.
** 공유 포트 노킹 나열
공유 포트 노킹 나열은 포트 노킹 클라이언트와 서버 가동의 한 정렬된 포트 집합이다. 네트워크에서 이 나열이 보이면 기본 버리기 패킷 필터는 나열을 전송한 것으로 보이는 IP 주소가 특정 포트에 접근할 수 있게 재설정된다. 예를 들어 TCP 포트 22번에서 실행 중인 SSHD에 접속하려면 클라이언트는 우선 SYN 패킷을 TCP 포트 5005, 5008, 1002, 1050 으로 전송해야 할 수 있다. 이런 노크 나열이 닫힌 포트로의 패킷을 기록하게 설정된 iptables 방화벽에 전송되면 로그에 접속을 시도한 포트의 로그가 나타날 것이다.
일단 포트 노킹 서버가 /var/log/messages 파일에서 포트 노크 나열을 발견하면 iptables는 SSHD와 같은 서비스로의 접근을 일시적으로 허용하게 재설정된다.
포트 노킹 나열은 TCP 외에 다른 인터넷 프로토콜을 수반할 수도 있다. UDP, ICMP, 또는 세 프로토콜이 동시에 나열을 구성할 수도 있다. 예를 들어 포트 노크 나열은 TCP/10001, UDP/2300, ICMP 에코 요청, TCP/6005, UDP/3000 과 같을 수 있다.
ICMP에는 “포트”라는 개념이 없기 때문에 포트 노킹 나열에 ICMP 패킷을 포함하는 것은 포트 노킹의 정의에서 약간 벗어난다. 그러나 포트 노킹은 사실 정보를 패킷 헤더 내에 인코딩하는 것에 대한 기술이므로 ICMP 패킷을 포함하는 것이 포트 노킹의 정의를 크게 위방하는 것은 아니다. ICMP를 나열에 사용하지 못할 이유는 전혀 없다.
사실 TCP나 UDP 헤더에서 포트 항목을 제외한 다른 항목도 포트 노킹 나열 내에 추가적인 정보를 인코딩하는 데 사용될 수 있다. 예를 들어 UDP 헤더의 16비트 크기의 체크섬 항목은 포트 노킹 클라이언트에 의해 직접 미리 결정된 값으로 설정 될 수 있으며, 포트 노킹 서버는 체크섬이 미리 정한 값과 매칭되는 경우 UDP 패킷을 포트 노킹 나열의 일부로서 수용하게 구현될 수 있다.
** 포트 노킹의 구조적 한계
포트 노킹이 발견되지 않은 보안 버그를 가질 수 있는 네트워크 서비스에 대해 추가적인 보호 계층을 제공할 수 있지만 포트 노킹은 그 구조적 특징으로 인해 회사 수준의 배치를 하기에는 적합하지 않다. 이런 한계는 애플리케이션 계층 페이로드를 사용하지않고 패킷 헤더를 데이터 전송 기법으로 사용하는 데서 기인한다.
– 나열 재전송 문제.
보안 위협이 매우 큰 요즘에는 모든 트래픽이 네트워크를 통해 전송될 때 미지의 제 3자에 의해 감시당한다고 가정해야 한다. 이런 관점에서 볼 때 민감한 정보(예를 들어 신용카드 번호)는 암호화된 형태로 전송돼야 한다.
포트 노킹의 경우 어떤 패킷도 애플리케이션 계층 데이터를 가지지 않으므로 포트 노킹 나열을 가로챌 이유는 거의 없는 것처럼 보인다.
그러나 포트 노킹의 목적은 수신측이 패킷 필터를 일시적으로 재설정해서 노트 나열을 통해 자신을 증명한 IP 주소에게 접근 권한을 부여하기 위해 필요한 정보를 네트워크로 전송하는 것이다. 포트 노킹 나열이 네트워크를 통해 전송될 때 공격자가 이를 가로챌 수 있다면 공격자는 나중에 동일한 목표에 동일한 노크 나열을 쉽게 전송할 수 있다. 공격자가 적법한 포트 노킹 클라이언트와 동일한 접근 권한을 얻기 위해 목표에게 노크 나열을 재전송하기 때문에 이를 재전송 공격(Reply attack)이라고 한다. 포트 노킹이 단순히 패킷 해더만을 사용하기 때문에 포트 노크 나열에 재전송 공격을 막을 정도로 충분한 가변성을 추가하기는 힘들다.
일부 포트 노킹 구현은 재전송 공격을 막기 위해 해쉬 함수의 연속적인 반복(RFC 1760 에서 정의하는 S/Key 인증과 유사함)을 사용하지만 이 방법을 사용하려면 클라이언트와 서버가 모두 일종의 상태 정보를 저장해야 한다. 또는 단순하게 일단 접근 권한이 부여되면 공유 포트 노크 나열이나 평문화 암호를 변경할 수도 있지만 이는 많은 사용자가 이용하는 서비스에는 쓰일 수 없다.
– 최소 데이터 전송 속도
TCP와 UDP 헤더의 포트 항목은 16비트기 때문에 포트 노킹 구현이 노크 나열의 각 패킷에서 목적지 포트 번호만 사용한다고 가정하면 패킷당 2 바이트의 정보만을 전송할 수 있다. 또 포트 노킹에는 TCP와 같이 패킷을 순서대로 전달하거나 패킷을 재전송하는 기법이 없기 때문에(포트 노킹은 철저히 단방향이다) 연속적인 패킷 사이에 시간 지연을 추가하지 않고는 전체 포트 노킹 나열을 네트워크로 전송할 수 없다. 패킷이 여러 라우팅 경로로 도착할 수 있기 때문에(즉, 어떤 패킷은 다른 패킷보다 느릴 수도 있다) 올바른 포트 노킹 나열의 정렬을 유지하기 위해서는 시간 지연이 필요하다.
모든 네트워크에 잘 적용되는 최적의 시간 지연은 없지만(그리고 실제로 포트 노킹 나열의 일부가 손실되면 전체 나열을 재전송해야 하지만) 0.5 초 정도의 시간 지연이 필요하다.
그러므로 128비트 블록 크기(Rijndael 알고리즘의 최소 블록 크기)를 가지는 대칭 키 알고리즘으로 암호화된 포트 노킹 나열의 경우 최소한 8개의 패킷이 필요하다(128 비트 / 패킷당 16 비트 = 8패킷). 패킷 사이마다 0.5 초의 지연을 추가하는 것은 나열은 전송하는 데만 4초가 필요하며 데이터를 더 전송해야 하는 경우네는 두 패킷마다 1초씩 추가된다는 의미이다. 수 바이트 이상의 데이터를 전송하는 포트 노킹 나열을 구성하는 것을 현실적으로 불가능하게 하는 것이 바로 긴 전송 시간이다.
포트 노킹의 데이터 전송 기능이 극히 제한적이기 때문에 포트 노킹 나열을 암호화하기 위해 비대칭 암호화 알고리즘을 사용하는 것은 적절하지 않다. GnuPG와 2048 비트 키를 사용하는 Elgamal로 10 바이트의 정보만을 암호화해도 수백 바이트의 암호화된 정보가 생성된다.
– 노크 나열과 포트 스캔
포트 스캔은 짧은 시간 동안 다수의 목표 시스템 포트에 연결한다. 포트 스캔과 노크 나열의 목적은 전혀 다름에도 불구하고 네트워크상에서 보면 포트 노크 나열도 포트 스캔의 정의에 정확히 일치한다. 문제는 포트 스캔을 탐지하는 침입 탐지 시스템이 두 활동을 구별하지 못해서 둘 모두에 대해 경고를 생성한다는 점이다. 이런 경고 때문에 원격 서비스에 인증하기 위해 포트 노킹을 사용하는 사람에게 불필요한 주의를 기울여야 할 수 있다.
– 스푸핑된 패킷을 이용한 노크 나열 파괴
포트 노킹은 (암호화된 애플리케이션 계층 데이터를 사용하지 않고) 패킷 헤더의 정보만을 인코딩하기 때문에 공격자는 패킷이 적법한 노크 나열의 일부인 것처럼 쉽게 꾸밀 수 있다. 패킷이 네트워크에 있는 도중에 중복 패킷을 포트 노킹 나열로 스푸핑하면 노크 서버는 이 추가적인 패킷이 포트 노킹 클라이언트가 전송한 실제 나열의 일부가 아니라는 것을 알 수 없다. 결과적으로 서버는 클라이언트가 유효한 노크 나열을 알지 못한다고 판단한다. 공격자는 서버가 적법한 포트 노킹 클라이언트에게 권한을 부여하지 못하게 할 수 있기 때문에 이는 노크 서버에 대한 서비스 거부(Dos) 공격이다. DoS 공격이 복잡한 작업일 수도 있지만(예를 들어 좀비 머신으로 구성된 네트워크에서 단일 IP 주소로의 트래픽 플러딩을 관리해야 한다) 때로는 수행하기 매우 간단할 수도 있다. 예를 들어 서버에 대한 DoS에는 하나의 패킷만이 필요하며 이런 공격은 너무도 수행하기 쉬우며 어느 곳으로부터도 스푸핑될 수 있다!
* 단일 패킷 권한 부여
단일 패킷 권한 부여(SPA, Single Packet Authorization)는 포트 노킹 구현과 유사한 방식으로 기본 버리기 패킷 필터와 수동적으로 감시하는 패킷 스니퍼를 결합한다. 그러나 패킷 헤더 항목을 이용해서 인증 데이터를 전송하는 대신 SPA는 인증 정보의 소유를 증명하기 위해 페이로드 데이터를 활용한다. 이는 대부분 네트워크의 MTU 크기가 수백 바이트 단위(예를 들어 이더넷 MTU 는 이더넷 헤더를 포함해서 1514 바이트다)기 때문에 가능하며 클라이언트는 단 하나의 패킷으로 SPA 서버에 자신의 식별 정보를 전송할 수 있다.
** 포트 노킹 한계점 해결.
포트 노킹 프로토콜이 가지는 문제를 요약하면 다음과 같다.
– 포트 노킹 나열을 감시할 수 있는 공격자의 재전송 공격을 막기 힘들다.
– 효과적인 데이터 전송 방법의 부재로 인해 전송할 수 있는 정보 유형과 나열 데이터를 암호화하는 데 사용할 수 있는 암호화 알고리즘이 제한된다.
– 포트 노크 나열이 네트워크를 통해 전송될 때 중간 IDS가 경고를 생성할 수 있다.
– 해킷 헤더의 중복과 스푸핑은 어렵지 않기 때문에 나열 파괴 공격이 매우 쉽다.
SPA 에서는 페이로드 데이터를 사용해서 이런 문제를 해결한다.
– SPA는 모든 SPA 패킷에 무작위 데이터를 포함시키는 방법으로 재전송 문제를 해결한다. SPA 패킷은 잘 정의된 평문 패킷 형식에 따라 구성된다. 이 형식에는 무작위 데이터를 위한 부분이 있으며, 패킷은 구성된 후 암호화된다. 무작위 데이터를 포함하는 것은 어떤 SPA 패킷도(SPA 서버에 동일한 접근을 요청하는 패킷끼리도) 겹치지 않게 보장해준다. 어떤 SPA 패킷도 동일한 MD5 의 합을 가지지 않는다는 것을 알기 때문에 성공적으로 편문화된 SPA 패킷의 MD5 합을 서버 측에 저장암으로써 동일한 접근 요청은 반복적으로 전송할 수 없다. 그러므로 새로운 SPA 패킷과 이전에 감시된 패킷의 MD5 합을 비교함으로써 재전송 공격을 쉽게 무력화시킬 수 있다.
– SPA는 TCP가 애플리케이션 데이터를 캡슐화하는 것과 유사한 방식으로 IP 패킷의 페이로드 부분을 사용해서 데이터 전송 문제를 해결한다. 패킷 페이로드를 사용하면 비대칭 알고리즘을 사용하기 쉬워지는데, 이는 패킷 페이로드가 (패킷 헤더만을 사용하는) 그 어떤 포트 노킹 구현보다도 많은 양의 데이터를 전송할 수 있기 때문이다. SPA를 통한 명령 채널(즉, 암호화된 SPA 페이로드에 완전한 명령을 담아 전송하는 것)도 생성할 수 있다.
– SPA는 인증 정보를 전송하기 위해 단 하나의 패킷만을 사용하기 때문에 SPA 네트워크 통신은 절대 포트 스캔처럼 보이지 않는다. 그러므로 IDS는 포트 범위에 대한 탐사들을 보지 않게 된다. SPA 페이로드는 암호화되기 때문에 IDS는 SPA 메시지의 내용도 디코딩할 수 없다. SPA 패킷은 스니핑하는 측에게 해설 불가능한 페이로드 데이터 덩어리로 보인다.
– SPA를 사용하면 공격자는 SPA 클라이언트 시스템으로부터 SPA 서버로 패킷을 스푸핑하는 방법으로 SPA 프로토콜을 쉽게 깰 수 없기 때문에 스푸핑 공격을 무력화할 수 있다(물론 네트워크 패킷 데이터를 조사하는 모든 시스템은 쓰레기 패킷 데이터로 플러딩 당할 경우 DoS 에 취약하기 쉽지만 이는 SPA 프로토콜 자체의 약점은 아니다).
** SPA의 구조적 한계
– NAT 주소를 통한 피기 백킹(Piggy-Backing) 접근
패킷 필터는 일반적으로 전송 계층이나 그 이하 계층에서 트래픽을 필터링하는 데는 우수하지만 애플리케이션 계층을 해설하는 데는 그다지 좋지 못하다. 결과적으로 SPA가 (유효한 SPA 패킷을 수신한 후) 들어오는 연결을 수용하기 위해 적용하는 필터링 기준은 현실적으로 출발지 IP 주소, 요청된 인터넷 프로토콜, 포트 번호만 포함할 수 있다. 즉, SPA 패킷이 SPA 서버에게 TCP 포트 22를 30초 동안 특정 IP 주소에 대해 열게” 지시할 때 SPA 서버는 30초 동안 출발지 IP 주소에서 TCP 포트 22로 연결하는 모든 패킷을 수용하게 패킷 필터를 설정한다. SPA 패킷 내의 IP 주소가 외부 NAT 주소라면(이는 SPA 클라이언트가 NAT 장치 뒤에 있을 때 필요하다)적법한 클라이언트와 동일한 내부 네트워크상의 누구라도 허용된 시간 동안 동일한 접근 권한을 가지게 된다.
– HTTP와 단기 세션
SPA 데몬이 TCP 연결의 수립을 허용하기 위해 패킷 필터 규칙집합에 임시 규칙을 추가할 때 적법한 클라이언트 측에는 보통 TCP 쓰리웨이 핸드쉐이크를 완료하기에 충분한 시간이 있다. 그러나 SSH 세션은 보통 TCP 연결을 수립된 상태로 만드는데 필요한 시간보다 훨씬 더 길게 지속된다.
규칙이 규칙 집합에서 삭제될 때 어떤 일이 일어나는가? 수립된 연결에 속하는 패킷이 기본 버리기 규칙에 의해 버려지기 전에 이를 수용하기 위해 (넷필터 등이 제공하는)연결 추적 기법을 사용하는 경우 연결은 세션이 수립되게 해준 초기 규칙이 삭제 됐음에도 불구하고 열린 상태로 남을 수 있다.
수립된 TCP 연결을 열린 상태로 유지하기 위한 연결추적 기법은 길게 유지되는 TCP 세션에 대해 훌륭한 해결책을 제공한다. 하지만 웹을 통해 HTTP 데이터를 전송하거나 메일 서버 간에 SMTP 데이터를 전송하는 것과 같은 단기 연결의 경우는 어떤가? 사용자가 보고자 하는 모든 웹 링크마다 새로운 SPA 패킷을 생성하는 것은 불편할 것이다. 모든 링크가 별도의 TCP 연결을 통해 전송된다는 사실은 이 문제를 더 악화시킨다. 일반적으로 SPA는 이런 서비스를 보호하는 데 적합하지 않다.
해결책의 하나로 가령 한 시간 동안 새로운 SPA 패킷이 필요 없게 단순히 클라이언트 IP 주소의 시간 만료를 확장하는 방법이 있다. 이런 확장이 SPA 유효성을 어느 정도 감소시키긴 하지만 웹서버가 중요한 애플리케이션을 실행 중이고 보안이 가장 중요한 고려사항일 때는 이런 해결책이 타당할 수 있다.
* fwsnort 탐지와 psad 동작의 결합
fwsnort는 공격을 탐지하면 iptables 로그 메시지를 생성한다. 이 메시지는 사용자에게 해당 로그 메시지를 촉발한 스노트 규칙 ID, fwsnort 체인내의 규칙 번호, 패킷이 수립된 TCP 세션의 일부인지 여부를 알려주는 로그 접두어를 포함한다.
** WEB-PHP Setup.php access 공격
스노트 규칙 ID 2281은 미디어위키 소프트웨어(원래는 위키피디아를 보조하기 위해 설계된 소프트웨어다. http://en.wikipedia.org/wiki/Mediawiki 참조)의 입력 확인 취약점을 공격하려는 시도를 탐지하게 설계됐다. 이 취약점은 Bugtraq ID 9057에서 기술하고 있으며, 스노트 규칙 ID 2281은 이를 WEB-PHP Setup.php access 공격이라고 명명한다. 이 취약점을 성공적으로 공격하면 목표 시스템이 HTTP 요청 내의 특별히 구성된 URI 매개변수를 수신할 때 목표 시스템에서 승인 받지 않은 원격 코드를 실행할 수 있다. 내부 웹서버에 대해 WEB-PHP Setup.php access 취약점을 공격하게 설계된 공격을 가상으로 실행해보자. seclab 시스템에는 기본 iptables 정책이 배치돼 있으며, 가상 공격은 soft-ftp 시스템에서 수행한다고 가정한다.
우선 텍스트 기반 웹 브라우저인 링크스(lynx)를 사용해서 seclab 시스템에서 iptables 방화벽을 통해 webserver로 웹 연결을 생성할 수 있는지 확인하자.
# lynx http://seclab.x.x.kr

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

문자열 /Setup.php만 제외하면 위의 규칙은 웹서버로부터 요청된 URI 매개변수의 내용(이는 공격자가 달성하고자 하는 것에 따라 달라질 수 있다)을 신경쓰지 않는다. 이 서명은 웹 요청의 URI 부분에서 문자열 /Setup.php 를 엄격히 검색하며, 이 데이터는 flow 키워드에서 요구하는 대로 수립된 TCP 연결에서 보여야 한다. 이 덕분에 다음과 같이 취약점에 대한 가상 공격이 매우 시워진다.
soft-ftp:~# lynx http://seclab.X.X.kr/Setup.php
404 Not Found
Not Found
The requested URL /Setup.php was not found on this server.
_________________________________________________________________Apache/2.2.11 (Ubuntu) PHP/5.2.6-3ubuntu4.5 with Suhosin-Patch
Server at seclab.kongju.ac.kr Port 80
위로부터 내부 웹서버가 취약하지 않다는 것을 알 수 있으며(내부 웹서버는 미디어위키를 실행하고 있지 않다) 예상대로 요청된 페이지가 존재하지 않는다는 것을 의미하는 404 Not Found 오류를 돌려받는다. 가상 공격을 수행하고 있다는 점을 기억하자. 가상 공격에서는 스노트 서명이 찾고자 하는 것처럼 보이는 네트워크 트래픽만 생성하면 된다.
– fwsnort 를 이용한 공격 탐지
이제 iptables로 WEB-PHP Setup.php access 공격을 탐지하기 위해 (일단은) –ipt-drop 이나 –ipt-reject 인자 없이 fwsnort를 실행하자.

/etc/fwsnort/fwsnort.sh 스크립트를 살펴보면 수립된 TCP 연결에서 /Setup.php 문자열을 탐지하기 위해 문자열 매칭 확장과 맞춤화 FWSNORT_FORWARD_ESTAB 체인을 탐지하기 위해 문자열 매칭 확장과 맞춤화 FWSNORT_FORWARD_ESTAB 체인을 사용하는 iptables 명령을 볼 수 있다. 이 명령은 아래와 같으며, 공격을 탐지하기 위해 상당한 연산을 수행한다.
$IPTABLES -A FWSNORT_FORWARD_ESTAB -p tcp –dport 80 -m string –string “/Setup.php” –algo bm -m comment –comment “sid:2281; msg:WEB-PHP Setup.php access; classtype:web-application-activity; reference:bugtraq,9057; rev:2; FWS:1.0.5;” -j LOG –log-ip-options –log-tcp-options –log-prefix “[1] SID2281 ESTAB “
$IPTABLES -A FWSNORT_INPUT_ESTAB -p tcp –dport 80 -m string –string “/Setup.php” –algo bm -m comment –comment “sid:2281; msg:WEB-PHP Setup.php access; classtype:web-application-activity; reference:bugtraq,9057; rev:2; FWS:1.0.5;” -j LOG –log-ip-options –log-tcp-options –log-prefix “[1] SID2281 ESTAB “
굵게 나타낸 부분이 iptables 로그 접두어이다. 이 접두어를 통해 iptables 로그 메시지에서 해당 규칙의 실행 여부를 확인할 수 있다. 이제 다시 공격 트래픽을 생성해보자. 공격 트래픽 생성 후, 아래의 로그 메시지를 얻을 수 있을 것이다.
Jul 11 05:30:13 seclab kernel: [4540091.006611] [1] SID2281 ESTAB IN=eth0 OUT= MAC=00:21:5e:4e:bb:da:00:11:88:42:99:43:08:00 SRC=X.X.X.X DST=Y.Y.Y.Y LEN=414 TOS=0x00 PREC=0x00 TTL=62 ID=44542 DF PROTO=TCP SPT=47966 DPT=80 WINDOW=365 RES=0x00 ACK PSH URGP=0 OPT (0101080A2FED6AD91B0F2BDB)
– psad를 이용한 경고
fwsnort는 공격을 탐지했지만 iptables로부터 로그 메시지만 생성했다. fwsnort는 whois 검색이나 메일 경고 전송 등의 기능을 가지고 있지 않기 때문에 이를 수행하지 않았다.
그러나 fwsnort가 iptables 로그 메시지를 생성하기 때문에 psad가 이를 분석한 후, 해당 이벤트에 자신의 경고와 보고 기능을 적용할 수 있다. 그러나 우선 psad는 fwsnort 로그 메시지를 적절히 처리해야 한다. 이 메시지는 애플리케이션 계층 데이터의 검사를 통해 생성된 것이지만 결국 데이터 자체는 로그 메시지에 포함되지 않는다.
로그 메시지를 해석하는 데 중요한 것이 /etc/psad/psad.conf 파일의 SNORT_SID_STR 변수다. 이 변수는 psad가 로그 메시지 fwsnort에 의해 생성됐다는 것을 유추하기 위해 봐야 할 로그 접두어 부분을 기술한다. 기본적으로 SNORT_SOD_STR은 다음과 같이 설정된다.

로깅 접두어에 부분 문자열 SID를 포함하는 iptables 로그 메시지는 fwsnort가 생성한 메시지로 거의 항상 애플리케이션 계층 공격에 대한 것이다.
이제 psad를 확실해 실행하고(/etc/init.d/psad start 를 실행) 가상 공격을 다시 한 번 수행하자. 이번에는 psad 가 iptables 로그 메시지를 가로채서 구문 분석한 후 아래와 같은 메일 경고를 생성한다.
=-=-=-=-=-=-=-=-=-=-=-= Sun Jul 11 05:30:23 2010 =-=-=-=-=-=-=-=-=-=-=-=
Danger level: [5] (out of 5)
Scanned TCP ports: [80: 1 packets]
TCP flags: [ACK PSH: 1 packets]
iptables chain: FWSNORT_INPUT_ESTAB (prefix “[1] SID2281 ESTAB”), 1 packets
fwsnort rule: 1Source: X.X.X.X
DNS: [No reverse dns info available]
OS guess: SunOS:4.1::SunOS 4.1.xDestination: Y.Y.Y.Y
DNS: seclab.kongju.ac.krOverall scan start: Thu Jul 1 23:50:42 2010
Total email alerts: 23
Complete TCP range: [1-65301]
Syslog hostname: seclabGlobal stats: chain: interface: TCP: UDP: ICMP:
INPUT eth0 11182 0 0[+] TCP scan signatures:
“MISC xfs communication attempt”
dst port: 7100 (no server bound to local port)
flags: SYN
sid: 1987
chain: INPUT
packets: 2
classtype: misc-activity“MISC Radmin Default install options attempt”
dst port: 4899 (no server bound to local port)
flags: SYN
psad_id: 100204
chain: INPUT
packets: 2
classtype: attempted-admin“WEB-PHP Setup.php access”
dst port: 80 (no server bound to local port)
flags: ACK PSH
content: “/Setup.php”
sid: 2281
chain: FWSNORT_INPUT_ESTAB
packets: 1
classtype: web-application-activity=-=-=-=-=-=-=-=-=-=-=-= Sun Jul 11 05:30:23 2010 =-=-=-=-=-=-=-=-=-=-=-=
위의 psad 메일 경고가 보통 psad가 생성하는 메일 경고라고 생각하면 되며, 여기에는 타임 스탬프, 패킷 수, TCP 플래그와 포트 등과 같은 표준 정보가 모두 포함된다.
iptables 그 자체로는 LOG 타겟을 통해 패킷의 실제 내용을 보고하는 기능을 가지지 않으며, 접두어 문자열 길이는 29글자로 제한되기 때문에 일반적으로 단순히 로그 접두어에 내용 문자열을 포함시키는 것이 합당하다. syslog 메시지에 바이너리 패킷 데이터를 포함시키는 것 역시 좋은 생각이 아니다.
* 다시 보는 능동적 응답
** psad와 fwsnort
psad는 공격이 탐지되면 공격자에 대해 영속적인 시간 만료 기반 iptables 차단 규칙을 인스턴스화 할 수는 있지만 스스로 연결을 종료시키거나 애플리있케이션 계층 서명과 매칭되는 첫 번째 패킷이 전달되는 것을 막지는 못한다.한편 fwsnort의 경우 악의적인 패킷이나 세션을 개별적으로 무력화하기 위해 DROP이나 REJECT 타겟을 사용할 수는 있지만 일정 기간 동안 공격자를 차단하는 새로운 iptables 규칙을 생성하지는 못한다.
각 도구의 강점을 고려하면 두 응답 방식을 결합하는 것이 좋다는 것을 알 수 있다. 결국 fwsnort는 특정 TCP 세션에 포함된 특정 공격을 탐지하고 저지하는 데 우수할 수 있지만 영속적인 차단 규칙을 관리하기 위한 psad가 없다면 공격자는 동일한 목표에 다른 공격을 자유롭게 시도할 수 있다. 첫 번째 공격 시도를 탐지했던 동작이 꽤 행운이었을 수 있으며, 다음 공격 시도는 전혀 탐지하지 못할 수도 있다. 이 때문에 차단 규칙이 중요하다. 공격자가 첫 번째 공격과 무관하며 서명도 존재하지 않는 취약잠에 대한 추가적인 공격을 가지고 있는 경우 특히 그렇다. 또 공격자가 TCP 서비스를 공격할 때 Tor 익명화 네트워크(http://tor.eff.org)를 사용하면 공격은 매번 다른 출구 라우터(Tor 가 각 TCP 세션마다 무작위로 선택한다)에서 오는 것처럼 보이기 때문에 개별적인 IP 주소를 차단하는 것은 의미가 없다.
다시 한 번 이야기하자면 능동적 응답 기법을 잘 아는 능숙한 공격자는 이 기능이 목표 네트워크에 반하게 만들기 위해 이를 전복하려고 할 수도 있다. 또 공격자가 공격을 수행할 다수의 호스트를 제어하는 경우(공격자 사이에서는 개인이 봇넷[botnet]을 구성하기 위해 여러 호스트를 제어하는 것이 보통이다) 공격자는 목표를 공격하는데 아직 사용하지 않은 호스트로부터 새로운 공격을 수행할 수도 있다. 네트워크를 보호하려는 사람과 이를 공격하려는 사람간에는 항상 경쟁 관계가 존재하며, 이런 관점에서 공격 측이 상당한 무장을 갖추고 있다고 가정해야 한다.
** fwsnort가 탐지한 공격으로 psad 응답을 제한
psad는 fwsnort가 생성한 로그 메시지에 대한 경고를 전송할 수 있다. 또 단순히 /etc/psad/psad.cnf 파일의 ENABLE_AUTO_IDS 를 Y 로 설정함으로써 psad는 fwsnort 로그 메시지에 대한 응답으로 iptables 차단 규칙을 설정할 수 있다.
fwsnort에 의해 탐지된 공격이 psad 에 의해 공격자에게 할당된 위험 수준을 AUTO_IDS_DANGER_LEVEL 변수에 설정된 값보다 크게 하면 psad는 공격자의 IP 주소에 대해 자유재량의 DROP 규칙을 인스턴스화한다. 그러나 fwsnort가 공격을 기록하기 때문에 포트 스캔과 백도어를 위함 탐사도 위험 수준을 할당 받는다.
하지만 쉽게 스푸핑되는 스캔과 탐사에 대해 psad 응답을 활성화하는 것은 위험하다. psad가 수립된 TCP 연결을 통한 애플리케이션 계층 데이터를 수반해야 하는 공격에만 응답하고 다른 유형의 공격에는 어떤 조치도 취하지 않게 하는 것이 좋다.
AUTO_BLOCK_REGEX 변수는 대응되는 iptables 로그 메시지가 정규식과 매칭할때만 psad가 IP 주소 차단을 수행하게 강제하는 정규식을 포함한다. AUTO_BLOCK_REGEX의 기본 값은 문자열 ESTAB며, 이는 수립된 TCP 연결에 속하는 패킷과만 매칭하게 설계된 맞춤화 체인 중 하나에 의해 기록된 fwsnort 로그 메시지와 매칭된다. 이 기능을 활성화하려면 psad 설정 파일에서 ENABLE_AUTO_BLOCK_REGEX 변수를 Y로 설정해야 한다.
psad 가 공격자를 방화벽에 접근할 수 없게 하려면 fwsnort를 실행하고 AUTO_BLOCK_REGEX 기능을 활성화해야 한다. 포트 스캔이나 기타 쉽게 스푸핑 가능한 트래픽에 응답하는 것은 너무나 쉽게 악용될 수 있다.
* fwsnort 설치
psad와 마찬가지로 fwsnort 도 인스톨 프로그램 install.pl과 함께 제공된다. 이 프로그램은 이전에 설치된 fwsnort 의 설정 보존, 두 개의 펄 모듈 설치(Net::IPv4Addr와 IPTables::Parse), 최신 블리딩 스노트 서명 집합의 (선택적인) 다운로드(http://www.bleedingsnort.com 에서 받음)를 포함해서 설치의 모든 것을 처리한다.
우분투/데비안의 경우 다음의 apt-get 을 이용한 설치가 가능하다.
# sudo apt-get install fwsnort
단, fwsnort 사용을 위해서는 iptables 문자열 매칭 기능을 사용할 수 있어야 한다. 커널 버전 2.6.14 나 그 이후 버전을 사용 중이라면 커널 내부에 이미 문자열 매칭이 컴파일 돼 있을 것이다.
만약 iptables 의 문자열 매칭기능의 지원여부를 확인하고 싶다면 아래의 명령어가 이상없이 작동하면 지원하는 것이다.
# iptables -D INPUT 1 -i lo -d 127.0.0.2 -m string –string “testing ” –algo bm -j ACCEPT
만약 오류 iptables: no chain/target/match by that name 가 반환되면 현재 커널에서 문자열 매칭 확장을 사용할 수 없는 것이다. 이는 커널 설정 파일의 CONFIG_NETFILTER_XT_MATCH_STRING 를 활성화하고 재컴파일한 후 새 커널로 재부팅함으로써 수정할 수 있다.
만약 위의 명령이 성공적으로 실행 되었다면, 다시 해당 규칙을 삭제하여 추후 다른 문제가 발생하지 않도록 하자.
# iptables -D INPUT 1
* fwsnort 의 실행
fwsnort 의 설치가 끝났다면 이제 fwsnort 를 실행하도록 하자.
커맨드 라인에서 바로 fwsnort 를 입력해도 되고, 만약 명령어 실행이 되지 않는다면, /usr/sbin/fwsnort 를 실행하도록 하자.

fwsnort 실행 후, 나오는 메시지로부터 각 스노트 규칙 파일에 대해서 성공적 변환과 변환 실패 획수(Success 와 Fail), 실행 중인 iptables 정책에 적용되는 규칙의 수(Ipt_apply), 규칙 파일에 존재하는 전체 스노트 규칙 개수(Total)를 출력한다는 것을 알 수 있다.
그리고 fwsnort 의 두 설정파일에 관한 정보를 확인할 수 있다.
** fwsnort 설정 파일
fwsnort 의 주요 설정 파일은 /etc/fwsnort/fwsnort.conf 는 네트워크, 포트 번호, 시스템 바이너리의 경로(iptables 로의 경로 등), 실행에 필요한 기타 주요 정보를 정의한다.
다음은 실제로 사용중인 fwsnort.conf 의 파일 내용이다.
root@seclab:/etc/fwsnort# cat fwsnort.conf
#
###########################################################################
#
# This is the configuration file for fwsnort. There are some similarities
# between this file and the configuration file for Snort.
#
###########################################################################
#
# $Id: fwsnort.conf 442 2008-08-09 15:14:27Z mbr $
#### Fwsnort treats all traffic directed to / originating from the local
### machine as going to / coming from the HOME_NET in Snort rule parlance.
### If there is only one interface on the local system, then there will be
### no rules processed via the FWSNORT_FORWARD chain because no traffic
### would make it into the iptables FORWARD chain.
HOME_NET any;
EXTERNAL_NET any;### List of servers. Fwsnort supports the same variable resolution as
### Snort.
HTTP_SERVERS $HOME_NET;
SMTP_SERVERS $HOME_NET;
DNS_SERVERS $HOME_NET;
SQL_SERVERS $HOME_NET;
TELNET_SERVERS $HOME_NET;### AOL AIM server nets
AIM_SERVERS [64.12.24.0/24, 64.12.25.0/24, 64.12.26.14/24, 64.12.28.0/24, 64.12.29.0/24, 64.12.161.0/24, 64.12.163.0/24, 205.188.5.0/24, 205.188.9.0/24];### Configurable port numbers
SSH_PORTS 22;
HTTP_PORTS 80;
SHELLCODE_PORTS !80;
ORACLE_PORTS 1521;### define average packet lengths and maximum frame length. This is
### used for iptables length match emulation of the Snort dsize option.
AVG_IP_HEADER_LEN 20; ### IP options are not usually used.
AVG_TCP_HEADER_LEN 30; ### Include 10 bytes for options (which
### accompany ACK packets).
MAX_FRAME_LEN 1500;### Use the WHITELIST variable to define a list of hosts/networks
### that should be completely ignored by fwsnort. For example, if you
### want to whitelist the IP 192.168.10.1 and the network 10.1.1.0/24,
### you would use (note that you can also specify multiple WHITELIST
### variables, one per line):
#WHITELIST 192.168.10.1, 10.1.1.0/24;
WHITELIST NONE;### Use the BLACKLIST variable to define a list of hosts/networks
### that for which fwsnort should DROP or REJECT all traffic. For
### example, to DROP all traffic from the 192.168.10.0/24 network, you
### can use:
### BLACKLIST 192.168.10.0/24 DROP;
### To have fwsnort REJECT all traffic from 192.168.10.0/24, you would
### use:
### BLACKLIST 192.168.10.0/24 REJECT;
BLACKLIST NONE;### define the jump position in the built-in chains to jump to the
### fwsnort chains
FWSNORT_INPUT_JUMP 1;
FWSNORT_OUTPUT_JUMP 1;
FWSNORT_FORWARD_JUMP 1;### iptables chains (these do not normally need to be changed).
FWSNORT_INPUT FWSNORT_INPUT;
FWSNORT_INPUT_ESTAB FWSNORT_INPUT_ESTAB;
FWSNORT_OUTPUT FWSNORT_OUTPUT;
FWSNORT_OUTPUT_ESTAB FWSNORT_OUTPUT_ESTAB;
FWSNORT_FORWARD FWSNORT_FORWARD;
FWSNORT_FORWARD_ESTAB FWSNORT_FORWARD_ESTAB;### fwsnort library path
FWSNORT_LIBS_DIR /usr/lib/fwsnort;### system binaries
shCmd /bin/sh;
echoCmd /bin/echo;
tarCmd /bin/tar;
wgetCmd /usr/bin/wget;
unameCmd /usr/bin/uname;
ifconfigCmd /sbin/ifconfig;
iptablesCmd /sbin/iptables;
** fwsnort.sh 의 구조
fwsnort 가 생성한 본 쉘 스크립트 /etc/fwsnort/fwsnort.sh 는 다섯 개의 섹션으로 나뉜다. 첫 번째 섹션은 fwsnort.sh 스크립트의 목적, fwsnort.sh 를 생성하기 위해 fwsnort 에게 전달하는 명령 행 인자, fwsnort 버전을 포함하는 주석으로 구성된 헤더다.
root@seclab:/etc/fwsnort# cat fwsnort.sh|more
#!/bin/sh
#
############################################################################
#
# File: /etc/fwsnort/fwsnort.sh
#
# Purpose: This script was auto-generated by fwsnort, and implements
# an iptables ruleset based upon Snort rules. For more
# information see the fwsnort man page or the documentation
# available at http://www.cipherdyne.org/fwsnort/
#
# Generated with: fwsnort
# Generated on host: seclab.XXXXXX.ac.kr
# Time stamp: Thu Jul 8 00:43:59 2010
#
# Author: Michael Rash <mbr@cipherdyne.org>
#
# Version: 1.0.5 (file revision: 472)
#
############################################################################
##==================== config ====================
ECHO=/bin/echo
IPTABLES=/sbin/iptables
#================== end config ==================###
############ Create fwsnort iptables chains. ############
###
$IPTABLES -N FWSNORT_FORWARD 2> /dev/null
$IPTABLES -F FWSNORT_FORWARD$IPTABLES -N FWSNORT_FORWARD_ESTAB 2> /dev/null
$IPTABLES -F FWSNORT_FORWARD_ESTAB
fwsnort.sh 스크립트의 두 번째 섹션은 iptables 와 에코 시스템 바이너리의 경로를 정의한다. 이 경로들은 fwsnort.conf 설정 파일의 iptablesCmd 와 echoCmd 키워드에서 상속되며 fwsnort 는 fwsnort.sh 를 작성하기 전에 해당 경로가 존재하는지 확인한다.
설정 섹션은 fwsnort.sh 가 배치되는 시스템에 맞게 경로를 수정할 수 있게 해준다.
#==================== config ====================
ECHO=/bin/echo
IPTABLES=/sbin/iptables
#================== end config ==================
fwsnort.sh 의 세 번째 섹션은 fwsnort 규칙을 위한 전용 iptables 체인을 생성한다. 모든 fwsnort 규칙(아래서 다룰 건너뛰기 규칙은 예외)은 기존 iptables 정책으로부터 엄격히 분리시키기 위해 맞춤화 체인에 추가된다.
fwsnort.sh 의 네 번째 섹션은 중량 패킷 검사가 일어나는 곳이다. 이 섹션의 규칙은 모두 앞서 언급한 fwsnort 체인 중 하나에 추가된다. 각 규칙은 출발지와 목적지 IP 주소와 포트 번호, 내용 문자열, length, ttl, tos 매칭 등과 같은 스노트 규칙 헤더와 규칙 옵션의 구성 원소를 포함한다.
기본적으로 fwsnort 가 변환하는 모든 스노트 규칙은 사용자 특정 서명을 전달하기 위해 설계된 로깅 접두어와 함께 LOG 타겟을 사용하는 Iptables 명령을 생성한다. fwsnort 가 생성한 로깅 접두어는 fwsnort 체인의 규칙 번호와 스노트 서명 ID 값을 포함하며, 서명이 수립된 TCP 연결로부터 기록됐는지 여부를 나타낸다.
fwsnort.sh 의 마지막 섹션에서는 iptables가 전체 규칙집합을 통해 트래픽을 전송하게 함으로써 커널 내부에서 규칙집합을 활성화한다. 이 시점까지 fwsnort.sh 에 의해 실행되는 모든 iptables 명령은 단순히 fwsnort 정책을 실행 중인 커널로 로딩한다.
** fwsnort 의 명령 행 옵션
일반적으로 사용되는 일부 옵션에 대한 설명이며, 다른 모든 명령 행 인자에 대한 설명은 fwsnort(8) 맨 페이지에서 볼 수 있다.
–ipt-drop: 패킷이 의도된 목표로 전달되기 전에 fwsnort 가 이를 기록하고 버리게 한다(기본적으로 fwsnort 는 악의적인 패킷을 기록만 하게 한다). 이를 통해 fwsnort 는 네트워크 공격에 능동적으로 응답할 수 있는 권한을 얻는다.
–ipt-reject: fwsnort 가 악의적인 TCP 연결을 TCP 재설정 패킷으로 종료시키고 악의적인 UDP 트래픽에 ICMP 포트 도달 불가 메시지로 응답하기 위해 REJECT 타겟을 사용하는 iptables 정책을 만들게 한다.
–snort-conf path: fwsnort가 HOME_NET, EXTERNAL_NET, HTTP_SERVERS 등과 같은 변수를 기존의 스노트 설정 파일(보통 /etc/snort/snort.conf에 위치)로부터 읽어오게 한다.
–snort-sid sids: fwsnort 변환 시도를 특정 스노트 ID나 스노트 ID 목록으로 제한한다.
–include-type type: fwsnort 가 하나의 규칙 파일에 포함된 스노트 규칙만을 변환하게 한다.
–ipt-list: 다양한 fwsnort 체인의 활설화된 규칙을 모두 보여준다.
–ipt-flush: fwsnort 체인에서 활성화된 규칙을 모두 버린다. 이 옵션은 기존 정책과 연관된 iptables 규칙은 제거하지 않고 fwsnort 규칙을 빠르게 제거할 때 유용하다.
–no-address: fwsnort가 방화벽 시스템의 인터페이스가 가지는 IP 주소를 참조하지 않게 한다.
–no-ipt-sync: 로컬 iptables 정책에 대해 보통 실행되는 모든 호환성 검사를 fwsnort가 비활성화게 한다..
–restrict-intf intf: fwsnort 규칙을 명시된 인터페이스(들)로 제한한다.
* fwsnort의 실제 동작
fwsnort의 실행은 간단하다. fwsnort 명령어의 결과로 생성된 /etc/fwsnort/fwsnort.sh 스크립트를 실행시키면 된다.
…..시스템에 따라 시간이 오래 걸릴 수 있으니 느긋한 마음을 가지는 것이 좋을 것이다.

* 허용 목록과 차단 목록 설정
애플리케이션 계층 데이터에 기반해서 네트워크 통신을 차단할 수 있는 소프트웨어는 허용 목록(whitelist)에 기반해서 특정 네트워크나 IP 주소를 차단 동작에서 제외할 수 있어야 한다.
fwsnort 에서 허용 목록과 차단 목록은 /etc/fwsnort/fwsnort.conf 파일의 WHITELIST와 BLACKLIST 변수를 통해 지원된다. 예를 들어 fwsnort 가 웹서버(192.168.10.2)에서 시작하거나 웹서버로 향하는 통신에는 어떤 조치도 취하지 않고 IP 주소 192.168.10.100 으로 오가는 모든 패킷을 DROP 하게 하려면 fwsnort.conf 에 다음을 추가한다.
WHITELIST 192.168.10.2;
BLACKLIST 192.168.10.100;