linux firewall by l79y007U

VIEWS: 0 PAGES: 27

									1. Linux Firewall 이란 무엇인가?
  A. Packet Filtering Firewall 의 개념
  Packer Filtering Firewall 이란 network 로 흘러 들어오는 Packet 들의 header
  나 내용 등을 살펴보고 특정적인 Rule ( 예를 들자면 이 Packet 을 보내온 IP 가
  1.2.3.4 면 Packet 을 잡아 내겠다. 같은 방식의 Rule ) 들을 적용하여 이에 일치하
  는 Packet 에 원하는 정책 ( Policy ) 을 부여하는 방식의 Firewall 이다. 이러한
  방식의 Firewall 은 현재 인터넷을 구축하고 있는 TCP/IP 의 data 흐름 방식이
  Packet 단위에 기초하고 있기 때문에 매우 유용하다. 따라서 대부분의 Firewall 이
  이런 Packet Filtering 에 기초하고 있다고 할 수 있다.


  B. Linux Firewall.
   Linux Firewall 은 Linux kernel 에 포함되어있는 network packet filtering 을 이
  용하여 다양한 방식으로 Packet들을 제어, 관리하는 machine 이다. Linux Firewall
  은 그 목적이나 사용 방식에 따라 아주 다양한 형태로 존재한다.


  C. Linux Firewall 의 내부. Packet Filtering – Iptables.
   Linux kernel 에는 2.4.0 버전 이후부터 Iptables 라는 새로운 feature 로 Packet
  Filtering을 지원한다. ( 최근에는 Linux kernel 2.5 버전이 개발중에 있다. 이 버전
  이 안정화가 되면 2.6.0 이 나올 것이다. ) 이 Iptables 에는 기존의 2.2.X 대 버전
  Linux kernel 의 Ipchains 보다 더욱 확장된 기능이 추가되어 있다. 기본적인
  Packet Filtering 방식은 변화하지 않았지만, Network Address Translation
  ( NAT ) 이라고 하는 라우팅을 지원하는 부분이 들어가 있다. 이러한 조합은 기존
  의 Ipchains 보다 훨씬 강력한 Linux Firewall 을 구축할 수 있게 해준다.
   Iptables 의 모양을 간략히 도식화 하면 다음과 같다.
D. Iptables 의 내부.
Iptables 의 내부에는 위에서 본 바와 같이 NAT 와 몇몇의 Chain 들로 구성되어
있다. NAT 는 앞서 밝혔듯이 Routing 에 관련된 Packet 의 정보를 다룬다. Packet
Filtering Firewall 에서 주목해서 봐야 할 곳은 바로 Chain 들에 있다. Chain 은
Packet 을 Filtering 하는 Rule 들이 들어있는 곳으로써 이곳에서 Packet 들이 버
려질 것인가 , 아니면 받아들여질 것인가가 결정된다. Chain 내부의 룰들은 사용자
가 간단히 명령어를 이용하여 생성할 수 있다. 명령어의 내용은 조금 뒤에 Iptables
항목에서 다루기로 하겠다. 체인의 내부 내용을 살펴보면 다음과 같다.




input 과 Test 라는 chain 을 간단하게 예제로 만들어 보았다. Input chain 은 3개
의 Rule 로 구성되어 있고, Test chain 은 2개의 룰로 구성되어있다. C. 번의 그림
에서 보았듯이 Routing 을 거쳐 일단 내부로 들어온 Packet 은 무조건 input 이란
Chain 으로 흘러들어가게 되어있다. Input Chain 의 Rule 을 각각 설명해보면 Rule
1 은 ICMP protocol 로 들어오는 Packet은   무조건 REJECT 하라고 되어있다.
Rule 2 는 TCP protocol 로 들어오는 Packet은 Test 라는 chain 으로 넘겨서 처
리하겠다고 되어있다. Rule 3 은 UDP protocol 로 들어오는 Packet은 DENY 하라
고 되어있다. ( REJECT 는 packet 을 버리지만 이 packet 이 버려졌음을 상대방에
게 알려준다. DENY 는 packet 을 버리면서 알리지 않는다. ) Test Chain 의 Rule
1 은 192.168.1.1 로부터 들어온 Packet 을 가리킨다. ( 무엇을 할 것인가는 결정
해 주지 않았다. 이 경우 기본적으로 Chain 에 할당되어 있는 정책을 따를 것이
다. ) Rule 2 는 destination 이 192.168.1.1 인 Packet 을 가리킨다. 이러한 Chain
들에게 TCP Packet 이 1개 들어왔다고 가정해 보면 다음과 같이 흘러가게 된다.




 TCP protocol packet 이므로 input Chain 의 Rule 1 은 지나가고 Rule 2에서 걸
리게 된다. 그렇게 되면 Test Chain 으로 건너가게 되어 Rule 1 과 Rule 2 를
check 해보고 다시 input 으로 돌아와서 Rule3 를 통해 지나가게 된다.
 위에서 본 것과 같이 Chain 안에는 적절한 Rule 이 있고 이러한 Rule 들에 의해
Packet이 다뤄짐을 알 수 있다. 이러한 Rule 들은 아주 간단한 명령어로 추가, 삭
제 , 유지 , 보수가 가능하다.
2. Linux Firewall 의 장점은 무엇인가?
  A. 가격이 매우 저렴하다.
   Linux 는 GPL ( General Public License ) 과 Open Source 를 기반으로 이루어
  진 OS 이다. 따라서 OS 비용은 무료라고 할 수 있다. 게다가 Linux 는 일반적인
  Unix와는 달리 값비싼 Computer를 필요로 하지 않는다. 일반적인 PC로도 Linux
  Firewall 을 충분히 구현 할 수 있으며 성능 또한 일반적인 Firewall 에 못지 않을
  뿐더러 더 훌륭하기도 하다.


  B. 구현이 매우 쉽고 유지 보수가 간편하다.
   Linux Firewall 에 대한 수많은 매뉴얼과 사용방법, 구현방법이 인터넷상에 공개
  되어있다. 심지어는 자동적으로 현재의 Network 상황에 맞게 저절로 Firewall 을
  구성해주는 유틸리티들도 존재한다. Linux Firewall 은 Rule 단위로 추가, 삭제, 백
  업 등이 가능하므로 새로운 Filter 가 필요할 때마다 가볍게 명령어 1줄로 각각의
  Chain 에 Rule을 추가함으로써 유지, 보수가 가능하다. 게다가 현재 Network 상황
  만 잘 안다면 그 Network 만의 Customizing 된 Firewall 을 손쉽게 구성할 수 있
  다. 마치 맞춤 Firewall 같은 이러한 부분은 Linux Firewall 만의 큰 장점이라고
  할 수 있다.


  C. Kernel 기반이라 매우 빠르며 소스 조차도 공개되어있다.
  Linux Firewall 의 Packet Filtering 모듈은 Application 이 아닌 Kernel 에 탑재
  된 기능이다. 따라서 매우 안정적이고 빠른 성능을 보장해 준다. 그리고 Linux
  Firewall 은 Open Source 기반이므로 소스를 살펴볼 수도 있다. 소스를 고쳐서 스
  스로 더욱 유용하고 알맞은 Firewall 을 구성 할 수도 있다.


  D. 새로운 업데이트가 지속적으로 이루어지며 매우 다양한 기능이 계속적으
     로 추가된다.
  Linux Firewall 의 기능인 Packet Filtering 모듈은 Linux Kernel 안에 들어있다.
  이 Linux Kernel 은 수많은 지원자들로부터 지속적이고 아주 빠른 개발이 이루어
  지고 있으며(거의 2,3 주마다 새로운 Kernel 이 개발되고 공개되고 있다. ), 새로운
  유형의 Hacking 공격에 발빠르게 대처 할 수 있다. 다른 Firewall 에서는 이룰 수
  없는 아주 매력적인 요소이다. 또 단순히 Packet Filtering 뿐만 아니라 kernel 자
  체에 들어있는 DOS 방지 기능, Network 분산기능, Traffic 측정기능, NAT 기능,
  가속기능, VPN, 터널링, IPV6 의 지원 등 매우 다양한 요소들이 더욱 강력한
  Firewall 을 가능하게 해준다. 이러한 종합적인 Firewall 은 Linux Firewall 만이
  가진 또 다른 장점이다.
  3. Iptables 사용법과 명령어
        Iptables 는 앞서 밝혔듯이 Linux 에서 Packet Filetering 을 위해 지원되는
        kernel의 network 부분에 포함돠는 툴이다. 이 Iptables 의 사용방법을 간단하게
        살펴보면 다음과 같다.




< iptables – 전체 체인에 대한 명령어들 >
  -N    :   --new-chain < chain >
  “ 새로운 chain 을 정의하고 생성한다. “
  -F    :   --flush [ <chain> ]
  “ chain 의 전체를 flush 시킨다. 만약 뒤에 argument 가 없으면 모든 체인을 flush 한
  다.”
  -X    :   --delete-chain [ <chain> ]
  “ chain 자체를 지운다. Argument 가 없으면 모든 chain 을 지운다. “
  -P    :   --policy <chain><policy>
  “ 각 chain 에 대한 default rule 을 정의 한다. INPUT , OUTPUT , FORWARD 에
  ACCEPT 와 DROP 등으로 정의된다.”
  -L    :   --list [ <chian> ]
  “ 체인의 rule 을 모두 열거 한다. 모든 chain 을 열거 할 수도 있다.”
  -Z    :   --zerop
  “ 각 체인의 패켓을 리셋하고 바이트 카운터를 0 으로 세팅한다.”
  -h    :   <some command> -h
  “ help 이다.”




< 체인 내용을 보는 List 명령어들.>
  -L -n      :   --numeric
  “ip 주소와 포트번호를 이름이 아닌 번호로 표시한다.”
  -L -v      :   --verbose
  “각각의 rule 에 대한 상세정보 ( 바이트 및 패켓 카운터 , 룰의 옵션 , 연관된 네트웍
인터페이스 등) 를 표시한다”
  -L -x      :   --exact
  “정확한 카운터 값을 반올림 없이 보여준다.”
  -L --line-numbers
  “체인에서 이 룰이 몇번째 인가를 표시해준다.”
< 각체인에 내부적인 rule을 만드는 명령어들. >
      -A : --append <chain>
      “체인의 끝에 룰을 추가 한다.”
      -I       :   --insert <chain>
      “체인의 제일 처음에 룰을 추가한다. 혹은 특정 포지션도 된다.”
      -D :          --delete <chain> < rule number >
      “체인의 특정 룰을 지운다.”


 -R        :       --replace <chain> < rule number>
 “체인의 룰을 대체한다.”




< 체인의 기본적인 필터링 룰>
 -i : INPUT chain 으로 들어 온 것. 혹은 FORWARD 체인으로 온 것도 된다. 유저가 정
의한 chain 으로 넘어온 것도 상관없다.
 -o :      OUTPUT 으로 나가는 패켓. 혹은 FORWARD 체인으로 나갈 것도 된다.
 -p : protocol . /etc/protocols 를 참조하면 종류를 얻어 낼 수 있다.
 -s : source . address 와 mask 를 이용해 어디서부터 이 패켓이 왔는가를 matching 한
다.
 -d : destination . source 와 마찬가지지만 어디로 가는가를 본다.
 -j     : 패켓을 원하는 chain ( table ) 로 jump 시킨다.




               이러한 명령어들 뿐만 아니라 Iptables 에는 –m 이란 명령어를 이용해서 수많은
               filtering 모듈을 불러들여 쓸 수 있다. 이 module 들은 iptables – netfilter
               hacking 문서에 의해 모두 공개 되어있으며 제작 방법도 공개되어있다. 따라서 원
               한하면 사용자가 원하는 방식의 Filter 를 첨가 하는 것도 가능하다. 다양한 종류의
               Filter 들을 살펴보면 다음과 같다.




1. ah-esp patch
이 패치는 Yon Uriarte <yon@astaro.de>에 의해 작성되었고 다음의 2가지 새로운
matches를 한 것이다 :
``ah'' : Security Parameter Index (SPI)에 기초한 AH 패킷을 match할 수 있도록 한다.
``esp'' : SPI에 기초한 ESP 패킷을 match할 수 있도록 한다.
이 패치는 SPI에 기초한 연결들을 구분짓고자 IPSEC을 사용하는 사람들에게 유용할 수 있
다.
예를 들어, 다음과 같이 하면 500과 일치하는 SPI를 가지는 모든 AH 패킷을 드롭시킬수
있다.

# iptables -A INPUT -p 51 -m ah --ahspi 500 -j DROP


# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source                   destination
DROP         ipv6-auth--     anywhere                anywhere       ah spi:500


ah match가 지원하는 옵션은 다음과 같다 :
--ahspi [!] spi[:spi] -> match spi (range)
esp match도 똑같이 작용한다.

# iptables -A INPUT -p 50 -m esp --espspi 500 -j DROP
# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source                   destination
DROP         ipv6-crypt--    anywhere                 anywhere       esp spi:500


esp match가 지원하는 옵션은 다음과 같다 :
--espspi [!] spi[:spi] -> match spi (range)
ah 또는 esp match를 사용할때, 또는 명백한 이유로 룰 첨가를 중단하고자 할때, ``-p 50''
또는 ``-p 51'' (esp & ah 각각)을 통해 적절한 프로토콜을 명시하는 것을 잊지 말아야 한
다.
2. iplimit patch
이 패치는 Gerd Knorr <kraxel@bytesex.org>에 의해 작성되었으며, 특정 호스트나 네트
워크로부터의 TCP 연결 갯수를 어떻게 제한하는지에 대한 새로운 match를 한 것이다.
예를 들어, 한 IP 주소에 의한 HTTP 연결 갯수롤 4개로 제한하려고 하면 :

# iptables -A INPUT -p tcp --syn --dport http -m iplimit --iplimit-above 4 -j REJECT


# iptables --list
Chain INPUT (policy ACCEPT)
target   prot opt source     destination
REJECT      tcp     --   anywhere   anywhere        tcp dpt:http flags:SYN,RST,ACK/SYN
#conn/32 > 4 reject-with icmp-port-unreachable


또는 예를 들어 class A 전체의 연결 갯수를 제한하기를 원한다면 :

# iptables -A INPUT -p tcp --syn --dport http -m iplimit --iplimit-mask 8 --iplimit-
above 4 -j REJECT


# iptables --list
Chain INPUT (policy ACCEPT)
target   prot opt source      destination
REJECT      tcp     --   anywhere   anywhere        tcp dpt:http flags:SYN,RST,ACK/SYN
#conn/8 > 4 reject-with icmp-port-unreachable


iplimit patch가 지원하는 옵션은 다음과 같다 :
[!] --iplimit-above n -> 현재 tcp 연결 갯수를 n개 이상으로 하려면 (하지 않으려면)
--iplimit-mask n -> subnet mask를 사용하는 그룹 호스트들
3. ipv4options patch
이 패치는 Fabrice MARIE <fabrice@celestix.com>에 의해 작성되었으며, 설정된 IP 옵션
에 의해 패킷을 match할 수 있게 할 수 있도록 새로운 match를 한 것이다.
예를 들어, IP 옵션에 설정된 record-route 또는 timestamp를 가진 모든 패킷을 드롭하려
면 다음과 같이 설정한다 :

# iptables -A INPUT -m ipv4options --rr -j DROP
# iptables -A INPUT -m ipv4options --ts -j DROP


# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source                  destination
DROP         all    --   anywhere              anywhere            IPV4OPTS RR
DROP         all    --   anywhere              anywhere            IPV4OPTS TS


ipv4options match가 지원하는 옵션은 다음과 같다 :
--ssrr -> strict source routing flag에 match되는.
--lsrr -> loose source routing flag에 match되는.
--no-srr -> source routing을 가지지 않는 패킷에 match되는.
--rr -> record route flag에 match되는.
[!] --ts -> timestamp flag에 match되는.
[!] --ra -> router-alert option에 match되는.
[!] --any-opt -> 적어도 하나의 IP 옵션(또는 !이 선택되지 않은 모든 IP 옵션) 을 가진
패킷에 match되는.
4. length patch
이 패치는 James Morris <jmorris@intercode.com.au>에 의해 작성되었으며, 길이에 기초
한 패킷을 match할 수 있게 새로운 match를 한 것이다.
예를 들어, 85 바이트보다 큰 패킷 크기를 가진 모든 ping packet을 드롭하려면 다음과 같
이 한다 :

# iptables -A INPUT -p icmp --icmp-type echo-request -m length --length 85:0xffff
-j DROP


# ptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source             destination
DROP          icmp --    anywhere            anywhere            icmp echo-request
length 85:65535


length match에 대한 부가적인 옵션은 다음과 같다 :
[!] --length length[:length] -> value 또는 value의 범위에 대한 패킷 길이에 해당하는.
표현되지 않은 value의 범위는 내포되어 있을 것이다. 내포된 value는 최소 0, 최고 65535
이다.
5. mport patch
이 패치는 Andreas Ferber <af@devcon.net>에 의해 작성되었으며, TCP, UDP 연결에 대
해 단일포트와 포트범위를 조합해서 포트를 명시할수 있도록 새로운 match를 한 것이다.
예를 들어, 한 라인에서 ftp, ssh, telnet, http를 막기를 원한다면, 다음과 같이 할 수 있다 :

# iptables -A INPUT -p tcp -m mport --ports 20:23,80 -j DROP


# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source             destination
DROP          tcp   --   anywhere             anywhere                mport ports ftp-
data:telnet,http


mport match에 대한 부가적인 옵션은 다음과 같다 :
--source-ports port[,port:port,port...] -> source port(s)에 match된다.
--sports port[,port:port,port...] -> source port(s)에 match된다.
--destination-ports port[,port:port,port...] -> destination port(s)에 match된다.
--dports port[,port:port,port...] -> destination port(s)에 match된다.
--ports port[,port:port,port] -> source and destination port(s) 모두에 match된다.
6. nth patch
이 패치는 Fabrice MARIE <fabrice@celestix.com>에 의해 작성되었으며, 룰에 의해 받은
특정 N번째 패킷을 match할 수 있도록 새로운 match를 한 것이다.
예를 들어, 매 2번째 핑 패킷을 드롭하길 원한다면, 다음과 같이 할 수 있다 :

# iptables -A INPUT -p icmp --icmp-type echo-request -m nth --every 2 -j DROP


# iptables --list
Chain INPUT (policy ACCEPT)
target        prot opt source            destination
DROP            icmp --     anywhere          anywhere               icmp echo-request
every 2th


이 패치는 Richard Wagner <rwagner@cloudnet.com>에 의해 확장되었는데, 이는 inbound
와 outbound 연결에 대한 로드 밸런싱을 제공하는 쉽고 빠른 방법을 만들 수 있게 해준다.
예를 들어, 10.0.0.5, 10.0.0.6, 10.0.0.7의 3개 주소에 대한 로드 밸런싱을 원한다면, 다음과
같이 할 수 있다 :

# iptables -t nat -A POSTROUTING -o eth0 -m nth --counter 7 --every 3 --packet 0
-j SNAT --to-source 10.0.0.5
# iptables -t nat -A POSTROUTING -o eth0 -m nth --counter 7 --every 3 --packet 1
-j SNAT --to-source 10.0.0.6
# iptables -t nat -A POSTROUTING -o eth0 -m nth --counter 7 --every 3 --packet 2
-j SNAT --to-source 10.0.0.7


# iptables -t nat --list
Chain POSTROUTING (policy ACCEPT)
target        prot opt source            destination
SNAT            all   --   anywhere         anywhere             every 3th packet #0
to:10.0.0.5
SNAT            all   --   anywhere         anywhere             every 3th packet #1
to:10.0.0.6
SNAT            all   --   anywhere         anywhere             every 3th packet #2
to:10.0.0.7
nth match가 지원하는 옵션은 다음과 같다 :
--every Nth -> 모든 N번째 패킷과 일치
[--counter] num -> 카운터 0-15 (디폴트갑:0) 사용.
[--start] num -> 0 대신 `num'으로 카운터를 초기화. 이 num은 0에서 (Nth-1) 사이여야
한다.
[--packet] num -> `num' 패킷과 일치. 0 ~ (Nth-1) 사이여야 한다. `--packet'이 카운터
로 사용된다면 0에서 (Nth-1)사이의 모든 value를 처리하기 위해 --packet 룰에 N번째
number가 있어야 한다.


7. pkttype patch
이 패치는 Michal Ludvig <michal@logix.cz>에 의해 작성되었으며, 호스트/브로드캐스트/
멀티캐스트 등 그 타입에 기초한 패킷을 match할 수 있도록 새로운 match를 한 것이다.
예를 들어, 모든 브로드캐스트 패킷을 조용히 드롭시키길 원한다면 :

# iptables -A INPUT -m pkttype --pkt-type broadcast -j DROP


# iptables --list
Chain INPUT (policy ACCEPT)
target      prot opt source           destination
DROP           all   --   anywhere             anywhere       PKTTYPE =
broadcast


pkttype match가 지원하는 옵션은 다음과 같다 :
--pkt-type [!] packettype -> 패킷 타입이 다음중 하나일 경우 패킷 타입을 일치시킨다.
host -> 모두
broadcast -> 전체
multicast -> 그룹
8. psd patch
이 패치는 Dennis Koslowski <dkoslowski@astaro.de>에 의해 작성되었으며, 포트 스캔을
탐지하는데 관한 새로운 match이다.
가장 간단한 형태로, psd match는 다음과 같이 사용될 수 있다 :

# iptables -A INPUT -m psd -j DROP


# iptables --list
Chain INPUT (policy ACCEPT)
target   prot opt source      destination
DROP      all   --   anywhere    anywhere         psd weight-threshold: 21 delay-threshold:
300 lo-ports-weight: 3 hi-ports-weight: 1


psd match가 제공하는 옵션은 다음과 같다 :
[--psd-weight-threshold threshold] -> Portscan 탐지 가중치
[--psd-delay-threshold delay] -> Portscan 탐지 지연치
[--psd-lo-ports-weight lo] -> well-known 포트(privileged port) 가중치
[--psd-hi-ports-weight hi] -> user 포트(High ports) 가중치
9. random patch
이 패치는 Fabrice MARIE <fabrice@celestix.com>에 의해 작성되었으며, 주어진 확률에
기초한 패킷을 랜덤하게 계산할 수 있도록 하는 새로운 match이다.
예를 들어, 50%의 핑 패킷을 랜덤하게 드롭하기를 원한다면, 다음과 같이 할 수 있다 :

# iptables -A INPUT -p icmp --icmp-type echo-request -m random --average 50 -j
DROP


# iptables --list
Chain INPUT (policy ACCEPT)
target      prot opt source         destination
DROP            icmp --    anywhere         anywhere           icmp echo-request    random
50%


random patch가 지원하는 옵션은 다음과 같다 :
[--average] percent -> match %에 대한 확률 생략된다면, 50%의 확률이 세팅된다. 퍼센
트는 1과 99사이의 숫자여야 한다.
10. realm patch
이 패치는 Sampsa Ranta <sampsa@netsonic.fi>에 의해 작성되었으며, 패킷 분류자에 나
타나는 키와 유사한 기준과 일치하는 것으로써 라우팅 영역 키를 사용할 수 있도록 하는 새
로운 match이다.
예를 들어, 10개의 영역에서 외부로 향하는 패킷을 모두 로그에 기록하려면, 다음과 같이
할 수 있다 :

# iptables -A OUTPUT -m realm --realm 10 -j LOG


# iptables --list
Chain OUTPUT (policy ACCEPT)
target        prot opt source               destination
LOG             all   --   anywhere              anywhere   REALM match 0xa
LOG level warning


realm match가 지원하는 옵션은 다음과 같다 :
--realm [!] value[/mask] -> 영역 일치
11. record-rpc patch
이 패치는 Marcelo Barbosa Lima <marcelo.lima@dcc.unicamp.br>에 의해 작성되었으며,
효과적인 RPC 필터링을 허용하기 위해 패킷 소스가 이전에 portmapper를 통해 포트를 요
청했을 경우, 또는 portmapper에 대한 새로운 GET 요청일 경우 match하는 데 대한 새로
운 match이다.
RPC 연결 추적 정보를 match하기 위해, 간단히 다음과 같이 할 수 있다 :

# iptables -A INPUT -m record_rpc -j ACCEPT


# iptables --list
Chain INPUT (policy ACCEPT)
target        prot opt source               destination
ACCEPT          all   --   anywhere             anywhere


record_rpc match는 어떠한 옵션도 가지지 않는다.
match 정보가 없다고 염려할 것은 없다. 이 match에 대한 print() function이 비어있기 때
문에 이는 간단하다.

/* Prints out the union ipt_matchinfo. */
static void
print(const struct ipt_ip *ip,
         const struct ipt_entry_match *match,
         int numeric)
{
}


12. string patch
이 패치는 Emmanuel Roger <winfield@freegates.be>에 의해 작성되었으며, 패킷의 한 문
자열을 match하는 것에 대한 새로운 match이다.
예를 들어, ``cmd.exe'' 문자열을 포함하고 있는 패킷을 match하고 userland IDS로 보내려
면, 다음과 같이 할 수 있다 :
# iptables -A INPUT -m string --string 'cmd.exe' -j QUEUE


# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source                   destination
QUEUE          all   --    anywhere                    anywhere                STRING match
cmd.exe


조심스럽게 이 match를 사용해야 한다. 많은 사람들이 DROP taget에 따라서 웜 바이러스
를 멈추기 위해 이 match를 사용하길 원한다. 이는 중요한 실수이다. 특정 IDS 침입 방법
은 이를 무력화할수 있다.
유사한 경향으로, 많은 사람들은 POST 문자열을 포함하는 HTTP 패킷을 드롭함으로써
POST나 GET같은 HTTP의 특정 기능을 멈추기 위한 수단으로 이 match를 사용하기를 원
했었다. 이러한 작업은 proxy를 필터링하는 것이 더 좋은 방법임을 이해하라. 부가적으로
POST란 단어를 가지고 있는 HTML content는 이전 방법(설정)에 의해 드롭될 것이다. 이
match는 더 좋은 분석을 위해 유저영역의 관심있는 패킷을 큐잉할수 있게 하기 위해 설계
되었다. 이것이 전부이다. 이 방법에 의해 패킷을 드롭하는 것은 특정 IDS 침입 방법에 의
해 무력화될 수 있다.
string match가 지원하는 옵션은 다음과 같다 :
--string [!] string -> 패킷의 문자열을 일치시킨다.


13. time patch
이 패치는 Fabrice MARIE <fabrice@celestix.com>에 의해 작성되었으며, 출발 혹은 도착
(로컬에서 생성된 패킷) 시간에 기초한 패킷을 match할 수 있도록 하는 새로운 match이다.
예를 들어, 월요일부터 금요일까지 8:00부터 18:00까지 도착 시간을 가진 패킷을 허용하려
면 다음과 같이 할 수 있다 :

#   iptables   -A    INPUT   -m   time    --timestart      8:00   --timestop   18:00   --days
Mon,Tue,Wed,Thu,Fri -j ACCEPT


# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT         all   --   anywhere           anywhere             TIME from 8:0 to 18:0 on
Mon,Tue,Wed,Thu,Fri


time match가 지원하는 옵션은 다음과 같다 :
--timestart value -> 최소 HH:MM
--timestop value -> 최대 HH:MM
--days listofdays -> 적용되는 요일 리스트, (대소문자 구분)
Mon
Tue
Wed
Thu
Fri
Sat
Sun
14. ttl patch
이 패치는 Harald Welte <laforge@gnumonks.org>에 의해 작성되었으며, TTL에 기초한
패킷을 match할 수 있도록 하는 새로운 match이다.
예를 들어, TTL이 5보다 적은 패킷을 로그에 기록하려면, 당신은 다음과 같이 할 수 있다 :

# iptables -A INPUT -m ttl --ttl-lt 5 -j LOG


# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
LOG          all    --   anywhere              anywhere   TTL match TTL < 5
LOG level warning


ttl match가 지원하는 옵션은 다음과 같다.
--ttl-eq value -> time to live 값과 일치
--ttl-lt value -> TTL < value 한 것과 일치
--ttl-gt value -> TTL > value 한 것과 일치




<NAT 부분의 module들>
1. ftos patch
이 패치는 Matthew G. Marsh <mgm@paktronix.com>에 의해 작성되었으며, 임의의 값으
로 TOS 패킷을 셋팅할 수 있도록 하는 새로운 match이다.
예를 들어, 15의 outgoing 패킷의 모든 TOS를 셋팅하려면, 다음과 같이 할 수 있다.

# iptables -t mangle -A OUTPUT -j FTOS --set-ftos 15
# iptables -t mangle --list
Chain OUTPUT (policy ACCEPT)
target     prot opt source                  destination
FTOS         all    --     anywhere            anywhere         TOS set 0x0f


FTOS target이 지원하는 옵션은 다음과 같다 :
--set-ftos value -> 패킷 헤더의 TOS field를 어떤 값으로 설정. 이 값이 10진수가 될 수
있고 (ex: 32) 16진수로도 될 수 있다. (ex: 0x20)


2. IPV4OPTSSTRIP patch
이 패치는 Fabrice MARIE <fabrice@celestix.com>에 의해 작성되었으며 IPv4 패킷의 모
든 IP 옵션을 제거(strip)할 수 있도록 하는 새로운 target이다.
다음과 같이 가장 간단하게 로드할 수 있다 :

# iptables -t mangle -A PREROUTING -j IPV4OPTSSTRIP


# iptables -t mangle --list
Chain PREROUTING (policy ACCEPT)
target     prot opt source                  destination
IPV4OPTSSTRIP        all    --   anywhere            anywhere


이 타겟은 어떠한 옵션도 지원하지 않는다.


3. NETLINK patch
이 패치는 Gianni Tedesco <gianni@ecsc.co.uk>에 의해 작성되었으며 netlink 소켓을 통
해 유저 영역으로 드롭된 패킷을 보낼 수 있도록 하는 새로운 타겟이다.
예를 들어, 모든 핑 패킷을 드롭하고 유저영역의 netlink 소켓으로 패킷들을 보내려면, 다음
과 같이 할 수 있다 :

# iptables -A INPUT -p icmp --icmp-type echo-request -j NETLINK --nldrop


# iptables --list
Chain INPUT (policy ACCEPT)
target     prot opt source                  destination
NETLINK       icmp --       anywhere             anywhere         icmp echo-request
nldrop
NETLINK 타겟이 지원하는 옵션은 다음과 같다 :
--nldrop -> 패킷을 드롭한다.
--nlmark <number> -> 패킷을 표시한다.
--nlsize <bytes> -> 패킷 크기를 제한한다.
netlink socket에 대한 더 많은 정보를 원한다면, Netlink Sockets Tour를 참고하라.


4. NETMAP patch
이 패치는 Svenning Soerensen <svenning@post5.tele.dk>에 의해 작성되었으며 원래의
호스트주소를 유지하는 동안 네트워크 주소와 정적으로 1:1 매핑을 만들게 할 수 있는 새
로운 타겟이다.
예를 들어, 1.2.3.0/24에서 5.6.7.0/24로 향하는 incomming 연결의 목적지를 변경하길 원한
다면, 다음과 같이 할 수 있다 :

# iptables -t nat -A PREROUTING -d 1.2.3.0/24 -j NETMAP --to 5.6.7.0/24


# iptables -t nat --list
Chain PREROUTING (policy ACCEPT)
target     prot opt source            destination
NETMAP         all   --    anywhere        1.2.3.0/24        5.6.7.0/24


NETMAP 타겟이 지원하는 옵션은 다음과 같다 :
--to address[/mask] -> 매핑할 네트워크 주소




5. SAME patch
이 패치는 Martin Josefsson <gandalf@wlug.westbo.se>에 의해 작성되었으며 SNAT와 유
사하고 각각 연결에 대해 한 클라이언트에 같은 주소를 부여할 수 있는 새로운 타겟이다.
예를 들어, 연결에 대한 소스 주소를 1.2.3.4-1.2.3.7로 변경하려면 다음과 같이 할 수 있
다 :

# iptables -t nat -A POSTROUTING -j SAME --to 1.2.3.4-1.2.3.7


# iptables -t nat --list
Chain POSTROUTING (policy ACCEPT)
target     prot opt source            destination
SAME          all    --   anywhere        anywhere              same:1.2.3.4-1.2.3.7


SAME target이 지원하는 옵션은 다음과 같다 :
--to <ipaddr>-<ipaddr> -> 소스에 매핑된 주소. 아마도 다수의 영역에 대한 한번 이상 기
술되었을 것이다.
--nodst -> 소스 선택에 대해 도착 IP를 사용하지 말라.


6. tcp-MSS patch
이 패치는 Marc Boucher <marc+nf@mbsi.ca>에 의해 작성되었으며 연결에 대한 최대 크
기를 제어할 수 있도록, TCP SYN 패킷의 MSS 값을 변경하고 검사할수 있도록 하는 새로
운 target이다.
Marc     자신이    설명한        바에    의하면,      이것은   해킹인데(THIS    IS    A   HACK),   ICMP
Fragmentation이 패킷을 요구하는 것을 막는 뇌사 상태의 ISP들 또는 서버들을 극복하는데
사용된다.
전형적인 사용방법은 다음과 같은 것이다 :

# iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-
to-pmtu


# iptables --list
Chain FORWARD (policy ACCEPT)
target     prot opt source                 destination
TCPMSS              tcp   --    anywhere                 anywhere                 tcp
flags:SYN,RST/SYN TCPMSS clamp to PMTU


tcp-MSS target이 지원하는 옵션은 다음과 같다 (상호 배제) :
--set-mss value 특정값으로 MSS 옵션을 명백히 셋팅
--clamp-mss-to-pmtu MSS 값을 자동으로 고정시킴 (path_MTU - 40)


7. TTL patch
이 패치는 Harald Welte <laforge@gnumonks.org>에 의해 작성되었으며, 주어진 값에 의
해 IP 패킷의 TTL 값을 증가/감소시키거나 유저가 셋팅할 수 있도록 하는 새로운 target이
다.
예를 들어, 모든 outgoing 연결의 TTL값을 126으로 셋팅하려고 한다면, 다음과 같이 할
수 있다 :

# iptables -t mangle -A OUTPUT -j TTL --ttl-set 126


# iptables -t mangle --list
Chain OUTPUT (policy ACCEPT)
target     prot opt source                 destination
TTL       all   --   anywhere          anywhere   TTL set to 126


TTL target이 지원하는 옵션은 다음과 같다 :
--ttl-set value -> TTL을 <value>로 셋팅
--ttl-dec value -> TTL을 <value>만큼 감소
--ttl-inc value -> TTL을 <value>만큼 증가


8. ulog patch
이 패치는 Harald Welte <laforge@gnumonks.org>에 의해 작성되었으며, 표준 LOG target
보다 진보된 로깅 메커니즘을 제공하는 새로운 match이다. `libiptulog/'는 ULOG 메세지를
받는 라이브러리를 포함한다.
     4. Linux Firewall 의 최적화에 대한 개념.


       A. Optimization 은 왜 필요한가.

앞서 살펴보았던 부분을 다시 살펴 보겠다. 상황을 다시 생각해 보면, Packet 이 Input
Chain 이란곳으로 흘러가서 그곳에서 적절한 필터링을 거쳐 Drop 이나 Accept 여부를 판
별 받아 빠져나가게 된다. 이러한 필터링 룰은 Chain 내부에 존재하는데, 그 룰들과 Packet
을 matching 시키는 방법이 Linear 하다. 예를 들어 input chain 과 Test chain 이란 2개의
chain 을 만들어, 각각에 일정한 룰들을 입력시킨다고 하자. 즉,




이렇게 input 이란 chain 에 룰을 넣고 Test 에도 룰을 넣었다. 이렇게 되면 실재로
packet 이 어떻게 지나가는가 살펴보기 위해 TCP 에 관한 packet 을 하나 넣어보기로 하
자.




       < both pictures are ref. from Linux IPCHAINS-HOWTO
                                     Paul Russell, Paul.Russell@rustcorp.com.au>


이렇게 차례로 input chain 에서 1번째 rule 과 matching 시켜보고 일치 하지 않았으므로
Reject 하지 않고, 다시 2번째 rule 과 matching 시켜본다. TCP packet 이었으므로 Test
Chain 으로 Jump 한다. 이렇게 되면 이제 Test chain 에 packet 이 와서 또 Test Chain
의 Rule1 과 matching 시키게 된다. 이런식으로 흘러가면서 적절히 packet 이 처리될 것이
다. 이렇게 packet의 일련의 흐름이 Linear 하다. 물론 jump 를 통해 다른 chain 으로 가
지만 그 chain 사이에서나 chain 안에서는 Linear 한 흐름을 보이고 있다.
Linear 한 matching 은 rule 이 많아지면 많아질수록 비례하여 이 chain 을 빠져나가는
것이 느려진다는 문제가 있다. 따라서 되도록이면 최소한으로 이 chain 의 rule 개수를 줄
이거나 적절히 jump 를 사용하여 되도록이면 적은 rule 과 matching 시켜보고 패켓을 빠져
나가게 해야 한다. Packet 이 빠져나가는 것이 느려지면 결국 CPU 에 load가 걸릴 뿐만 아
니라 중요한 network packet 을 제때 받지 못하여 문제가 생기는 경우도 발생한다. 즉 이
Linear 한 matching 의 optimization 이 필요하다는 것이다.




      B. 최적화에 대한 가정과 방법.

Firewall 은 그 목적에 따라 내부 rule이 완전히 달라질 수 있다. 게다가 목적자체도 달라
질 수 있다. Optimized 된 Firewall을 이미 사용하고 있더라도, 내부적으로 목적이 변하거
나 혹은 새로운 공격 pattern을 방비하고자 rule 을 추가할 경우 이 optimized 된 firewall
은 이미 더 이상 optimized 된 상태가 아닐 수도 있다. 또, 시시각각 변하는 네트워크
packet 의 pattern 이라던가 또는 새로운 방식의 도입으로 언제든지 firewall 은 더 최적화
될 수도 있는 것이다. 따라서 완벽하게 Optimized 된 Firewall 은 실재로 존재하지는 않는
다고 생각할 수 있다. 하지만 적어도 명백하게 성능을 높일 수 있는 몇 가지 방법은 존재한
다. 이러한 방법을 사용하여 Optimization 한 firewall 이 적어도 최선은 아니지만 좋은
solution 이 될 수 있다고 가정한다.
Linux packet filtering 을 통한 Firewall 은 앞서 보았듯이 chain 이라는 단위로 구성되어
있고, 그 각각의 chain 안에 rule 이 구성되어 있다. 그렇다면 optimization 방법은 크게 2
가지를 생각해 볼 수 있다.
       <1> chain 자체의 rule 에서 빠르게 하는 방법.
       <2> chain 간의 packet jump로 빠르게 하는 방법.
이러한 2가지의 optimization 을 동시에 적용하여 되도록 빠른 firewall 정책을 수립하는
것이 가능하다.
물론 이러한 방법 이외에 전체적인 firewall system 을 살펴 우선적으로 positive 냐
netgative 냐의 정책부터 수립하여 각각의 zone 을 나누는 방법도 반드시 필요하다. 이러
한 방법은 이미 “Linux Firewalls second edition – Rebet L. Ziegler” 에 의해 정리되어 있
으므로 나중에 고려하도록 하겠다. 즉, 이러한 Zone 단위의 Optimization 보다 각 내부적
인 chain 단위의 firewall 의 optimization 에 주안점을 두고 생각하겠다. ( 물론 Zone 단
위로 잘 설립된 Firewall 의 성능은 매우 우수하다. 그러나 이것에다가 내부적인 최적화
까지 곁들인다면 더욱 성능이 향상될 것이다. )
< Optimization 1. Chain - internal optimization >
앞서 언급한 chain 자체를 빠르게 하는 방법에 대해서 생각해 보았다.
Chain 1개를 하나의 system 이라고 생각하고 이 chain 에서 다른 곳으로 jump 된 것은
모두 이 Chain 을 빠져 나간 것이라고 할 수 있다. 필요한 것은 되도록 빠르게 이 Chain
을 빠져 나가는 것이다. 그러기 위해선 필요한 것이 몇 가지 있다.


1. 각 룰에 대해 packet 이 matching 되어지고 그 rule 에 의해 걸러지거나 혹은 통과하
는데 걸리는 load. ( 룰의 종류에 따라 이 load 가 다르다고 할 수 있다. 이유는 각
matching 방식이 아주 여러가지인데, IP matching 부터 mac address , 심지어는 string
matching 도 있다. 이러한 경우 각각 걸리는 load 가 다름은 명백하다. )


2. 각 룰에 대해 matching 되어 chain 을 빠져나가는 packet 량. ( 즉, 각 룰에 matching
되는 packet이 올 확률이다. 많은 양의 packet이 matching 되는 rule 이 있고 적은 양의
packet이 matching 되는 rule 이 존재 할 것이다. )


이 2가지가 필요한 이유는 Chain 을 빠져나가는데 걸리는 평균시간을 구하려면 packet이
어떤 룰에 matching 되어 빠져나갈 확률 및 그 룰을 만나기 위해 지나간 룰들에 걸린 시간
이 고려 되야 하기 때문이다. 즉, 한 Chain 에서 평균적으로 packet 이 빠져나가는데 걸리
는 시간은 다음과 같이 생각해 볼 수 있다.


              Packet



   Rule 1 .              Rule 1 matching time * Rule 1 에 packet 이 걸릴 확률.
                          + ( Rule 1 + Rule 2 matching time ) * Rule2 에 packet
   Rule 2 .
                         이 걸릴확률.
                          + ( Rule1 + Rule2 + Rule3 matching time ) * Rule3 에
                         packet 이 걸릴확률.
                          + ( Rule 1 + Rule2 + Rule3 matching time ) * 나머지
   Rule3
                          = < 평균 packet 이 이 chain 를 빠져나가는데 걸리는 시
                         간 T>.




우리는 이 평균시간 T 를 최소화해야 한다. 그러나 이를 위해서 취할 수 있는 방법은 Rule
의 순서를 바꿀 수 있는 것뿐이다. 우리가 Packet 자체를 조작 할 수는 없으므로 확률을
바꾸지는 못한다. 또 rule 을 마음대로 빼거나 할 수도 없다. ( rule 은 firewall 의 정책에
해당한다. 정책 자체를 바꾸는 것은 목적한 내부 firewall 의 최적화와는 다른 것이다. ) 결
국 Rule 의 순서를 바꾸는 것 만으로 이를 최적화 하는 수밖에 없다. T 를 가장 작게 하려
면 우선 각각의 packet이 빠져나갈 확률 * rule 의 maching time 을 하여 큰 값부터 순서
대로 rule 로써 넣으면 된다.


< Optimization 2. Chain - external optimization : via chains. >
앞서 말한 부분에서 한 Chain 을 최대한 빨리 빠져 나가게 함으로써 최적화가 이루어 진
다고 생각하였다. 그러나, 이 방법에는 문제점이 있다. 어떤 Chain 에서 Accept 나 Deny
가 되어 최종적으로 Packet 이 빠져나간 것이 아니라 다른 Chain 으로 Packet 이 jump 되
었다면, 이는 분명히 빠져나간 것이 아니다. 다른 Chain 에서 분명 다른 Rule 로 Check 를
해봐야 하는 것이다. 개개의 Chain 에서 Packet 이 최대한 빠르게 나왔다고 해서 최적화가
이루어 진 것은 아니다.
그러나 최소한 다른 Chain 으로 jump 가 없는 Chain 이 분명히 존재한다. ( 증명은 간단
하다. 다른 Chain 으로 jump 가 없는 Chain 이 없다면, 항상 다른 Chain 의 처음 Rule 로
Jump 되야만 하기 떄문에, loop 가 생기게 되고 만다. 이는 Packet 이 무한대로 빙글빙글
돌게되는 상황이 발생하기 때문에, 문제가 된다. 따라서 accept , deny , reject 로만 이루어
진 Chain 은 반드시 존재한다. ) 이를 “말단 Chain” 이라고 정의하겠다.
말단 Chain 은 앞서 말한 Optimization 1 이 충실히 지켜진다. 분명 다른 Chain 으로의
jump 가 없으므로 여기서 빠져나간 Packet 은 완전히 처리가 된 Packet 임이 분명하다.
따라서 먼저 말단 Chain 들을 최적화 하여 각각의 Chain 에 대해 Packet 이 빠져나가는데
걸리는 시간 평균 T 를 구할 수 있다. 이를 구하고 나면, 말단 Chain 이외의 Chain 들은
비슷한 방법으로 최적화를 할 수 있다.
우선 말단 Chain 으로 jump 되는 부분과 accept , deny , reject 만으로 구성된 Chain 을
찾을 수 있을 것이다. ( 말단 Chain 을 accept 나 deny 라고 생각하면 마찬가지 방법으로
이러한 Chain 도 반드시 존재한다. ) 이러한 Chain 은 다음과 같이 최적화 할 수 있다.




   Rule 1 .              Rule 1 matching time * Rule 1 에 packet 이 걸릴 확률.
                          + ( Rule 1 + Rule 2 + Chain 평균시간 ) * Rule2 에
   Rule 2 .
                         packet 이 걸릴확률.
   Jump to Another
                          + ( Rule1 + Rule2 + Chain 평균시간 + Rule3 matching
   Chain
                         time ) * Rule3 에 packet 이 걸릴확률.
                          + ( Rule 1 + Rule2 + Rule3 matching time ) * 나머지
   Rule3
                          = < 평균 packet 이 이 chain 를 빠져나가는데 걸리는 시
                         간 T>.
마찬가지 인 것 같지만 다른 점은 Rule 이 만약 말단 Chain 으로의 Jump 였다면 그 Rule
에 걸리는 시간에 Jump 되는 말단 Chain 의 평균 시간 T 를 더하여 계산을 해야 한다. 즉
한 룰에 걸리는 시간이 다른 Chain 으로 Jump 하여 그 Chain 을 빠져나오는 데 걸리는 시
간만큼 더 걸리게 되는 것이다. 이렇게 하면 이 Chain 도 말단 Chain 처럼 생각할 수 있다.
이렇게 방법을 반복하면 ( recursively ) 모든 Chain 에 대해 최적화를 이룰 수 있다.


       C. Optimization 을 위해 필요한 것들.

1.   앞서 말한 특정 rule 을 통과하는 데 걸리는 시간과 각 rule 에 걸릴 packet 의 양을
     어떻게 알아 낼 수 있는가에 대한 방법이 필요하다. ( 각 rule 에 걸리는 시간은 test
     로 알아 낼 수 있을 것이다. Packet 을 생성하여 test 해 볼 수 있는 옵션이 iptables
     에 존재한다. 각 rule 에 걸릴 packet 의 양은 log 옵션을 통해 기록해서 조사하는 방
     법이 유용할 듯 하다. )
2.   Log 를 기록할 때 시간 정보를 모두 기록해야 한다. 시간을 기록하여 대체적인
     Packet이 어떻게 오는가에 대한 분석이 필요하다.
3.   Rule 의 개수 자체를 줄이는데 주목해야 한다. 즉, 내부 적으로 Optimization 하는 방
     법만을 살펴본다고 하였는데, 우선적으로 외부에서 최적화가 되어야 전체적인 최적화
     를 논할 수 있다.
5. Design & 앞으로의 계획
  A. Log
  앞서 밝혔듯이 Packet 의 양이 어떠한 룰에 얼마나 걸리는 가에 대한 Log 가 반
  드시 필요하다. 이 Log 는 수집하는 방법밖에 없을 것이다. 어떠한 Rule 에서
  Packet 이 빠져나왔나에 대한 여부는 Log 의 Tag 옵션을 사용할 것이다. 즉 각
  Rule 마다 Log 를 남기되 Tag 옵션을 이용하여, “______ Chain _____ th rule “ 이
  란 log 를 일일이 남기면, 모든 룰에 대해 어느정도의 양의 Packet 이 걸리는 가를
  확실히 알 수 있다.
  Ex)
        iptables -A INPUT -p tcp -j LOG --log-prefix "INPUT Chain 3 th rule"
        “ Input chain 에 들어오는 Packet 중에 tcp 인 것을 모두 로깅하되 3번째
        rule 이었다고 로깅한다. “


  B. Rule 의 시간 Test
   Iptable 의 Rule 기술 방식은 Iptables 사용법과 명령어 부분에서 보았듯이, 종류
  도 다양할 뿐더러 –m 방식으로 모듈 확장도 가능하다. 따라서 일반적인 모듈을 포
  함한 각 Rule 마다 Packet 이 빠져나가는 시간을 미세한 차이라도 찾아 보아야 할
  것이다. 이를 위해서는 1개의 Rule 로만 이루어진 Chain 에 많은 수의 Pakcet 을
  통과 시킨후 걸리는 평균 시간을 이용해 알아 보겠다. Iptables 에는 자체적으로 특
  정 Chain 에 임의의 Packet 을 보내 볼 수 있는 명령어가 존재한다. 따라서 이를
  이용할 예정이다.


  C. 다른 알고리즘의 모색
   분명 이 방법이 최선이라고 할 수 있는 근거는 없다. 따라서 많은 다른 방법을 탐
  색해 봐서 비교해 봐야 하겠다. Graph Theory 가 현재로서는 가장 밀접해 보인다.


  D. 다른 최적화 방법의 연구
   최근의 Firewall 최적화에 대한 연구에 대한 내용을 잠시 들을 기회가 있었다.
  Iptables 의 한 module 인 state 를 이용한 최신의 방법이다. 우선 state 라는 모
  듈을 자세히 살펴보아야 하겠다.


  State 는 conntrack 이라는 접속에 대한 기록을 사용하여 접속상태를 check하는
  모듈이다. 새로운 종류의 Packet 이 올때마다 conntrack 을 생성하고, 이를 바탕
  으로 packet 이 accept 되었는가 reject 되었는가의 여부를 최종적으로 기록한다.
  만약 packet 이 accept 되었던 것이면 이 접속은 최소한 안전한 것이고 믿을 만
한 것이므로, 이 connection 에 대해선 지속적으로 packet 을 accept 해도 안전하
다고 할 수 있다. 그러나 packet filtering firewall 은 분명 모든 packet 에 대해
각각의 rule 을 적용해 보고 나서 accept 하기 때문에, 한번 accept 된 packet 이
온 connection 이라고 해도 계속적으로 check 를 한다. 이것은 분명히 낭비이다.
따라서 같은 접속이라면 지속적으로 accept 를 하기 위해, conntrack 을 남기고 이
에 일치하는 packet 은 룰 검사없이 바로 accept 로 가게 한다. ( 현재 iptables
의 자체 기능만으로는 불가능 하지만, 간단히 source 를 고쳐 만들 수 있다고 한
다. )
( state module 은 iptables 에서 –m state 옵션으로 사용 할 수 있다. 그리고 이후
에 콤마로 분리되는 적용할 상태들의 리스트가 온다.('!' 지시자는 사용되어지지 않
는 다.) 이 상태들은
NEW
       새로운 접속을 만드는 패킷


ESTABLISHED
       존재하는 접속에 속하는 패킷 (즉, 응답 패킷을 가졌던 것)


RELATED
       기존의 접속의 부분은 아니지만 연관성을 가진 패킷으로 . ICMP 에러 나
       (FTP 모듈이 삽입 되어있으면) ftp 데이터 접속을 형성하는 패킷.


INVALID
       어떤 이유로 확인할 수 없는 패킷: 알려진 접속과 부합하지 않는 ICMP 에
       러와 'out of memory' 등을 포함한다. 보통 이런 패킷은 DROP 된다.


등으로 구분되어져 인식 될 수 있다. )


 Conntrack 을 이용하는 state 모듈은 Accept 부분에 대해 빠른 일종의 bypass
를 제공하는 셈이다. Reject 나 Deny 에 대한 부분은 다른 방식으로 최적화 방식
을 도입했다.
 한번 Reject 된 Packet 은 분명 다시 Reject 된다. 따라서 이러한 Packet 에 대
해서는 Cache 를 이용한다. 즉 일정량의 Cache 를 만든뒤 거기에 최근 사용된
Reject 나 Deny Rule 을 넣어 둔다. 이 Cache 의 Hit Ratio 를 높이는 방법에 대
해서는 일반적인 Cache 알고리즘이 많이 있으므로 생략하겠다. 이 Cache 는 일단
Packet 이 올 때 우선적으로 처리되어 그 안의 Rule 들을 먼저 Check 해 본다.
이러한 방식은 DOS 같이연속적인 공격이 올 때에 매우 강력할 것이다.
      <과제연구A>
< 주제 : Linux firewall 의 최적화>




                 연구실 : HPC 랩
            담당교수님 : 김종 교수님.
                 19981248 컴공과
                        신준희

								
To top