Chapter 1. 연습문제

Posted on October 10, 2010 by pchero

1. CPU의 관점에서 원하는 곳으로 패치시킨다는 것과 가장 관련 있는 CPU의 레지스터는 무엇인가?
-> CPU의 관점에서 바라본 “원하는 곳으로 패치(Fetch) 시킨다”는 것은 현재 실행하고 있는 명령 다음에 어떤 명령을 실행시킬 것인가와 관련이 깊다. 따라서 다음번 명령어의 주소값을 저장하고 있는 PC(Program Counter) 레지스터이다.

2. 네트워크 관점에서 원하는 곳으로 패치(Fetch)시킨다는 용어는 무엇에 해당하겠는가?
-> 네트워크 관점에서의 패치는 패킷을 전송하는 것과 같은 의미를 가진다고 이야기 할 수 있다. 이중에서도 “원하는 곳으로 패치”한다는 것은 본래의 목적과는 다른 곳으로 패킷을 전송시킨다는 것으로 이야기할 수도 있을 것이다. 패킷을 캡쳐해서 해당 패킷의 목적지를 원하는 목적지로 변경하는 등의 여러 방법이 있겠지만 대표적인 것으로 패킷 스푸핑이 있을 수 있다.

3. 튜링이 ‘계산하는 기계”에게 시켜 증명하고자 했던 것은 무엇이었는가?
-> 판정문제를 증명하고자 했다.

판정문제

계산 가능성 이론과 계산 복잡도 이론에서 판정 문제란 어떤 형식 체계에서 예-아니오 답이 있는 질문을 말한다. 결정 문제라고도 한다. 예를 들어 “두 숫자 x와 y가 있을 때 y는 x로 나누어 떨어지는가?” 하는 질문이 있다. 답은 x와 y 값에 따라 ‘예’ 또는 ‘아니오’ 중 하나가 될 수 있다.

판정 문제를 푸는 데 쓰인 방법을 알고리즘이라고 한다. 어떤 판정 문제를 푸는 알고리즘이 있으면 그 문제는 판정 가능하다고 한다. 없으면 판정 불가능하다고 한다.

4. 현재도 쓰이고 있는 일반 전화 시스템(PSTN, Public Switched Telephone Network)은 음성(Voice)뿐만 아니라 누르는 전화번호 같은 데이터(Data)도 사람이 들을 수 있는 가청 주파수로 보낸다. 존 드라퍼가 공개한 전화 해킹(Phone Phreaking)은 장거리 전화 관련 신호를 전송하던 주파수인 2,600Hz에 잡음을 주어 교환기를 교란시키는 방법이었다. 이것이 가능한 것은 2,600Hz 가 수화를 통해 들을 수도 있고 보낼 수도 있는 가청 주파수이기 때문이다. 이런 구조이기 때문에 만약 전화를 거는 곳이 시끄러운 곳이라면 전화번호를 누를 때 주위의 잡음 영향을 받기가 쉬워 전화번호가 제대로 전달되지 않을 가능성이 크다. 이 같은 취약점을 막기 위해서 전화기는 전화번호를 교환기에게 어떤 방식으로 전달하는가?

-> 전화기에서 교환기로 전화번호를 전달하는 방식은 크게 두가지로 나눌 수 있다.
DP 방식과 PB 방식이 그것이다.
DP 방식
DP방식은 다이얼 인 펄스(Dial in pulse) 신호의 전달 속도에 따라 10PPS(1초간에 10펄스를 발생)와 20PPS(1초간에 20펄스를 발생) 두 종류가 있다. 1 PPS는 1초간에 1개 펄스를 내는 것을 말한다. 우리나라는 20 PPS를 사용하고 있다.

PB방식
PB방식 다이얼 신호는 7개의 주파수 종류 중 2개 주파수의 조합으로 만들어진다. 즉, 음성대역내의 높은 3개 주파수(1209, 1336, 1447Hz)와 낮은 4개 주파수(697, 770, 852, 941Hz) 중 각각으로부터 하나의 주파수를 선정, 이를 조합해서 0에서 9까지의 숫자와 *와 #의 기능 부호로 전화를 거는 것이다.

이부분…쉽지 않다.. 두개의 주파수를 조합해서 사용한다??? 나중에 다시..

5. 1장에서는 기술발전트리 상단부의 위치에 있을수록 더 좋다는 논리를 폈다. 기술 발전 트리 상단부에 있는 기술자에 대해 상대적으로 트리 하단부에 있는 기술자가 항변할 수 있는 논거를 대보자.
-> 실생활에 기술접목을 쉽게 할 수 있다. 즉, 기술의 응용력과 적용력이 상단부에 비해 엄청난 힘을 발휘한다.

13.fwknop 소개

Posted on July 11, 2010 by pchero

* 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 패킷 내에 추가적인 인증 매개변수를 요구할 수 있다.

11.psad와 fwsnort의 결합

Posted on July 10, 2010 by pchero

* fwsnort 탐지와 psad 동작의 결합

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

** WEB-PHP Setup.php access 공격

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

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

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

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

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

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

404 Not Found

   Not Found

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

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

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

– fwsnort 를 이용한 공격 탐지

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

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

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

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

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

– psad를 이용한 경고

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

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

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

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

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

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

   Danger level: [5] (out of 5)

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

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

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

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

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

[+] TCP scan signatures:

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

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

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

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

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

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

* 다시 보는 능동적 응답

** psad와 fwsnort

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

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

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

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

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

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

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

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

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

10.fwsnort 배치

Posted on July 7, 2010 by pchero

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

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

Posted on July 5, 2010 by pchero

* 들어가며..

스노트 규칙을 항상 깔끔하게 변활할 수는 없으며, 스노트 규칙 언어는 매우 복잡하기 때문에 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 중 하나)을 통해 이런 기능을 제공한다.

탱이의 세상만사

탱이의 세상사는 이야기

Tag Archives: 해킹

Chapter 1. 연습문제

13.fwknop 소개

11.psad와 fwsnort의 결합

10.fwsnort 배치

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