Linux에서의 방화벽설정 - ipchains (2)



이전 글에서 우리는 TCP Wrapper의 사용에 관해서 알아보았다.

TCP Wrapper는 inetd 데몬에의해 서비스되는, telnet이나 ftp등 /etc/inetd.conf에 설정되어있는 특정 서비스에 대해서만 Wrapper기능이 적용되었지만, 상당히 단순한 접근통제만 가능하기 때문에 좀 더 다양한 기능을 원할 때는 적합하지 않았다.

그래서 이 이상의 좀더 세련된 접근통제를 하기 위해 필요한 것이 바로 방화벽이다.



1. Ruleset



1.1 Ruleset이란?



Ruleset(이하 '룰셋')이란 Rule들의 집합이란 의미이다. 여기서 Rule이란 네트워크 접속과 흐름에 관련된 여러 규칙들을 이야기한다. 그럼 간단히 살펴보면서 시작을 하자.



[root@m /root]# ipchains -L -n

Chain input (policy ACCEPT):

target prot opt source destination ports

ACCEPT tcp ------ 192.168.1.101 192.168.1.100 * -> 23

ACCEPT tcp ------ 192.168.1.101 192.168.1.100 * -> 21

DENY tcp ------ 0.0.0.0/0 0.0.0.0/0 * -> *

Chain forward (policy ACCEPT):

Chain output (policy ACCEPT):



우리가 다루고있는 ipchains 에서 -L 옵션을 사용하면 위와 같이 현재 설정된 Ruleset를 볼 수 있다.



chain input 아래 나열된 세 개의 룰들은 모두 위에서 아래의 방향으로 순서대로 적용된다. 즉, 외부에서 어떤 패킷이 도착하면, 맨 첫 번째 룰의 조건에 따라 검사를 받고, 해당사항이 없으면, 두 번째 룰로 넘어간다.

두 번째 룰(Any-->21: FTP 허용)의 조건에도 만족하지 않는다면, 마지막 룰로 내려간다. 그런데, 마지막 룰은 '어떤(ANY) 주소에서 어떤(ANY)주소로 향하건 간에 DENY' 다. 즉, 이 룰에 걸리는 모든 패킷들은 다 drop(버려진다.) 되는 것이다.



1.2 방화벽 정책



마지막 룰에 걸리지 않고 들어온 패킷이 무사히 목적지까지 가기 위해서는, 그 패킷이 첫 번째,두 번째 룰 중에 적어도 하나와 정확하게 일치해야한다.



이와 같은 형태의 구성이 일반적인 방화벽 룰 셋팅 시 사용하는 구성방법이다. 기본정책은 '모두 거부'이고 허락하는 것만 '허가' 라는 아주 단순하면서도 인지하기 쉬운 보안정책으로, 꽤 튼튼한 보안 설정을 가능케 해준다.



2. 실전예제



2.1 상황 설정



그러면, 이제 m.linuxpace.com이라는 서버를 설정하고, 이 서버에서 사용하고 있는 룰셋에서 잘못된 부분을 하나하나 수정해보면서 방화벽 룰셋의 효과적인 사용에 대해 알아보자.

아래는 다양한 서비스를 제공하는 서버에서 사용할 수 있는 룰셋의 한 예다.

이 서버는 외부에 DNS, WEB, MAIL서비스를 제공해주고 있다.

이러한 조건으로 아래의 룰셋을 만들었지만, 완전한 형태는 아니다.

잘못된 점을 하나씩 찾아보자. (설명을 위해 각 룰 앞에 넘버링을 하였다.)



[root@m /root]# ipchains -L

Chain input (policy ACCEPT):

target prot opt source destination ports

1. ACCEPT tcp ------ 192.168.1.101 m.linuxpace.com any -> telnet

2. ACCEPT tcp ------ 192.168.1.101 m.linuxpace.com any -> ftp

3. DENY tcp ------ 192.168.2.0/24 m.linuxpace.com any -> telnet

4. ACCEPT tcp ------ anywhere m.linuxpace.com any -> domain

5. ACCEPT tcp ------ anywhere m.linuxpace.com any -> smt

6. ACCEPT udp ------ anywhere m.linuxpace.com any -> domain

7. ACCEPT tcp ------ anywhere m.linuxpace.com any -> www

8.DENY tcp ----l- anywhere m.linuxpace.com any -> any

Chain forward (policy ACCEPT):

Chain output (policy ACCEPT):

target prot opt source destination ports

9.DENY tcp ------ m.linuxpace.com anywhere any -> telnet

10. DENY tcp ------ m.linuxpace.com anywhere any -> ftp





2.2 외부 서비스 우선 정책



현재의 서버로 들어오는 모든 패킷은 1번 룰부터 9번룰까지 차례로 지나가면서 검사를 받게 된다.

이 서버는 web, dns, mail 서비스를 제공하고 있기 때문에, 외부사용자에게 조금이라도 빠른 서비스를 제공하기 위해서는 해당 서비스관련 룰들을 최대한 맨 위쪽으로 올려 주는 것이 좋다.

웹서비스(80포트)로 가는 패킷이라면, 7번룰을 1번위치로 올려 주는게, 나머지 룰들을 거칠 필요 없이 패킷을 바로 통과시킬 수 있는 방법이다.



4,6번 룰은 DNS 서비스에 관한 것들이다. DNS서비스는 대량의 도메인네임 질의를 빠르게 처리하기 위해 기본적으로 udp 53번 포트를 사용하여 질의를 받으며, 혹, udp 프로토콜을 이용한 질의가 실패할 시 tcp프로토콜을 사용해 53번 포트에 같은 질의를 던진다.

그러므로 DNS서비스를 운영하기 위해서는 방화벽에서 2개의 포트를 모두 열어 주어야 한다. 룰을 사용하기 위해서는 이와 같이 어떤 서비스에 대한 기본적인 지식도 필요하게된다.



위의 예에서는 설명한대로 tcp,udp 53번 포트가 모두 열려있기는 하지만, 서로 연속되게 배치되지 않았다. DNS서버의 질의순서인 udp,tcp 순서로 재배치해 최적화하는 것이 좋을 것이다.



그럼 이상의 내용대로 룰셋들을 정리하면 아래와 같다.



target prot opt source destination ports

7. ACCEPT tcp ------ anywhere m.linuxpace.com any -> www

5. ACCEPT tcp ------ anywhere m.linuxpace.com any -> smtp

6. ACCEPT udp ------ anywhere m.linuxpace.com any -> domain

4. ACCEPT tcp ------ anywhere m.linuxpace.com any -> domain

1. ACCEPT tcp ------ 192.168.1.101 m.linuxpace.com any -> telnet

2. ACCEPT tcp ------ 192.168.1.101 m.linuxpace.com any -> ftp

3.DENY tcp ------ 192.168.2.0/24 m.linuxpace.com any -> talent

8.DENY tcp ----l- anywhere m.linuxpace.com any -> any

Chain forward (policy ACCEPT):

Chain output (policy ACCEPT):

target prot opt source destination ports

9.DENY tcp ------ m.linuxpace.com anywhere any -> telnet

10. DENY tcp ------ m.linuxpace.com anywhere any -> ftp





2.3 내부 유저의 접속 제한



현재의 방화벽정책에서는 특별히 ACCEPT로 허가된 접속에 대한 룰셋을 만들어 주지 않으면, 기본적으로 이외의 모든 접속시도는 거부되게된다. 내부네트워크의 유저들이 현재의 서버(m.linuxpace.com)에 접속하기 위해서는 당연히 필요한 룰들을 추가해 주어야 한다.



1,2,3번 룰들은 모두 내부네트워크의 접속허가에 대한 내용을 다루고 있다. 192.168.1.101 호스트로부터 오는 사용자는 telnet과 ftp 서비스를 사용할 수 있다. 하지만, 192.168.2.0 네트워크(192.168.2.0 ~ 255)로부터 오는 사용자는 telnet 접속이 거부된다.(3번 룰)



그런데 여기서 이상한 점이 하나 있다. 과연 3번 룰이 필요한가? 이 경우엔 3번룰은 의미가 없다. 왜냐하면 마지막 룰인 9번 룰이 모든 접속에 대해 '거부'이기 때문에 192.168.2.0 네트워크로부터 m.linuxpace.com 서버의 telnet서비스로 향하는 패킷은 3번룰이 없더라도 9번룰에서 결국 drop 되기 때문이다.



2.4 8번룰의 의미?



이제 거의 마지막까지 내려왔다. 그럼 8번룰을 살펴보자.



"모든곳에서(anywhere) m.linuxpace.com의 모든(any)포트로 향하는 패킷은 로깅(l)후 drop한다"



라는 의미이고, 다음과 같이 룰셋에 생성한다.



# ipchains -A input -p tcp -s 0.0.0.0/0 -d 0.0.0.0/0 -j DENY -l



모든 패킷들이 1~7번 사이에 조건에 맞는 룰을 발견 못하고 8번룰 까지 내려 오게되면, 위의 내용대로 모두 버려지게된다. 하지만, '-l'옵션에 의해, 다음과 같이 버려지기 전에 해당 패킷에 대한 내용이 시스템 로그파일인 /var/log/messages로그파일에 남게된다.



Apr 27 00:02:49 m kernel: Packet log: input ACCEPT eth0 PROTO=6 192.168.1.101:1102 192.168.1.100:110 L=40 S=0x00 I=11651 F=0x4000 T=1 28 (#6)



이 로그를 통해 우리는 어떤 패킷들이 버려졌는지 눈으로 직접 확인할 수 있다.



2.5 외부사이트로의 접속 차단



이상에서는 모두 외부에서 들어오는 요청에 대해 접근제어를 하는 방법만을 다루었다.

하지만, 반대로 서버 측에서 외부(인터넷)로 접속요청을 보내는 것도 제어가 가능하다. 9,10번 룰은 m.linuxpace.com서버에서 외부로 나가는 어떠한 ftp, telnet 요청도 허가하지 않고 있다.

이런 룰이 필요한 이유는 만약의 경우 서버가 해킹을 당했을 때 침입자가 m.linuxpace.com서버 내에서 외부의 다른 사이트로 이동하는 것을 막기 위함이다. 하지만 root권한까지 빼앗겼다면, 침입자는 ipchains를 모두 풀고 작업을 할 수 있을 것이다.



9,10번 룰에 대해서는 로깅을 하도록 하자.

룰에대해 모르는 누군가 시도를 한다면 로그파일에서 그 내용을 확인해볼 수 있다.



3. 최종룰셋



이제 이상의 내용을 정리해 최종 룰 셋을 구성해보자.



target prot opt source destination ports

7. ACCEPT tcp ------ anywhere m.linuxpace.com any -> www

5. ACCEPT tcp ------ anywhere m.linuxpace.com any -> smtp

6. ACCEPT udp ------ anywhere m.linuxpace.com any -> domain

4. ACCEPT tcp ------ anywhere m.linuxpace.com any -> domain

1. ACCEPT tcp ------ 192.168.1.101 m.linuxpace.com any -> telnet

2. ACCEPT tcp ------ 192.168.1.101 m.linuxpace.com any -> ftp

8.DENY tcp ----l- anywhere m.linuxpace.com any -> any

Chain forward (policy ACCEPT):

Chain output (policy ACCEPT):

target prot opt source destination ports

9.DENY tcp ----l- m.linuxpace.com anywhere any -> telnet

10. DENY tcp ----l- m.linuxpace.com anywhere any -> ftp





이상은 한대의 서버에 여러 인터넷서비스가 실행되면서, 패킷필터링 방화벽까지 올라가 있는 상황을 가정했지만, 방화벽다운 방화벽을 위해서는 네트워크 카드가 최소 2장 이상 설치된, 때론 인터넷 게이트웨이 역할까지 하는 독립된 서버가 필요하다.

위와 같은 상황에서는 모든 패킷의 목적지(destination)가 현재의 서버(m.linuxpace.com)가 될 수밖에 없지만, 독립된 방화벽에서는 목적지가 내부의 네트워크 카드 쪽에 연결된 여러 서버들이 될 수 있다.



4. 마치면서



이상에서 우리는 방화벽 룰 설정의 실제를 예를 통해 알아보았다.

맨 처음에 제시한 뒤죽박죽 섞여있던 룰셋도 제대로 작동하는 것이었지만, 우리는 룰의 순서를 바꾸고, 갯수를 줄이고, 필요에 따라 버려지는 패킷들의 내역을 로그파일에 기록하기도 하면서, 방화벽 룰셋을 최적화 시켜주었다. 이 최적화의 과정을 이해한다면, 방화벽운영의 상당부분을 이해한 것이고, 곧 이리저리 룰을 걸어보며 패킷들의 흐름을 머리 속에 그릴 수 있는 즐거움을 만끽할 여유도 가지게 될 것이다.



얘기가 거꾸로 가는 경향이 있긴 하지만... 지금까지는 ipchains라는 리눅스용 패킷필터링 툴을 이용해 신나게 configuration만 했으니, 다음 글에서는 쉬어가는 의미에서 그간 다룰 시간이 없었던 일반적인 방화벽의 몇몇 형태와 그에 관련된 여러 이야기를 가볍게 풀어보겠다.

(확실히 이건 일반적인 전개 순서는 아니지만, 필자는 이것도 나름대로 괜찮은 진행방법이라고 생각한다. ^^;;)



5. 참고문헌



http://kldp.org/Translations/IPCHAINS-HOWTOB

D. Brent Chapman & Elizabeth D. Zwicky, "Building Internet Firewalls", OReilly 1995

노병규, "침입차단시스템", 한국정보보호센터(KISA) 1999



Written and Edited by 임준형



[저작권]



이 글의 작성 및 편집자는 임준형 님(saster@hitel.net)이며 상업적인 목적이 아니라면 이 글을 원작자의 이름과 함께, 배포하는 것은 자유입니다.