방화벽부터 iptable까지

안녕하세요! 두루뭉실하게 알고있던 네트워크를 좀 더 이해하고 싶은 네린이입니다~ 

오늘은 방화벽이 무엇인지부터 리눅스에서 방화벽의 역사와 대표적인 방화벽 프로그램인 iptable까지 한눈에 살펴보겠습니다.

 

방화벽(firewall)이란

방화벽이란 미리 정의된 규칙에 따라 들어오고 나가는 네트워크 트래픽을 모니터링하거나 제어하는 네트워크 보안 시스템입니다. 방화벽은 서로 다른 네트워크 간의 장벽처럼 존재하여 내부의 정보 자산을 보호하기 위해 신뢰할 수 있는 요청들만 내부 네트워크로 허용하거나 해로운 트래픽을 차단합니다. 방화벽은 여러 형태로 구현될 수 있는데, 접근 제어 목록(ACL)을 만들어서 특정 접근을 허용할 수도 있고 사용자 인증을 요청할 수도 있으며 주소를 변경하거나 데이터를 암호화하기도 합니다.

https://ko.wikipedia.org/wiki/%EB%B0%A9%ED%99%94%EB%B2%BD_(%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%82%B9)

대표적인 방화벽 구현 방식에 대해서 설명해보겠습니다.

 

1. 패킷 필터링 (Packet Filtering)
2. 프록시 (Proxy)
3. 네트워크 주소 변환(NAT)

패킷 필터링 (Packet Filtering)

패킷이란 Layer 3 즉, TCP/IP 층에서 주고받는 데이터이죠. 패킷 필터링이란 바로 이 패킷을 확인해서 허용된 통과시키는 방법을 말합니다. 라우터에서 패킷 필터링을 바로 적용할 수도 있는데 이 경우 외부에서 라우터 내부로 유입되는 패킷을 필터링할 때는 `Ingress 필터링`이라 하며, 반대로 내부에서 외부로 나가는 패킷을 체크하는 것은 `Egress 필터링`이라 합니다. 패킷 필터링은 크게 Static Filtering과 Statless Filtering 두 경우로 나눌 수 있습니다.

 

먼저 Static Filtering은 미리 정의된 규칙에 따라 들어온 패킷을 처리합니다. 예를 들어 192.168.10.0/24 에 속하는 주소에서 전달된 데이터는 허용하지 않는다는 Static Filtering입니다. 규칙이 정해지면 패킷의 헤더만 검사하면 되기 때문에 구현이 쉽다는 장점이 있습니다. 그러나 들어오는 모든 패킷을 일일이 검사해야 하며, 정책이 많아질수록 쉽게 느려집니다. 

 

반면 Statless Filtering은 클라이언트와 서버간의 상태 즉, 세션(Session)에 따라 패킷을 처리합니다. 즉, 한번 허용된 패킷의 세션을 저장하여 세션에 속한 패킷들을 계속 허용해 처리 속도를 높일 수 있습니다. Stateless Filtering은 세션이라는 상태로 패킷을 검사하기 때문에 Stateful Inspection 이나 Dynamic Filtering이라고도 불립니다.

	Stateless	Stateful
철학	연결 상태와 관계 없이 모든 패킷은 독립적으로 처리한다	패킷 처리 속도 향상을 위해 상태 정보를 사용한다. session context 유지
필터링	패킷 헤더의 정보를 기반으로	세션 정보를 기반으로
기준 정보	ACL Rules (Access Control List)	State Table
자원 소모량	적다	많다
속도	느리다	빠르다
보안	낮다	높다

프록시 (Proxy)

Proxy는 대리하다, 대신하다 라는 의미로 보안에서는 클라이언트와 서버가 서로 직접 통신하기 어려운 경우에 중간에서 대신 통신을 수행하는 기능 또는 그런 기능을 하는 서버를 일컫습니다. 프록시는 패킷 필터링과 달리 OSI 7 계층 중 Application 에서 동작하여 패킷의 헤더 내 Data 영역까지 체크합니다. Application 서비스 별로 Proxy 서버 또는 데몬이 존재할 수 있으며, 출발지 - 프록시, 프록시 - 목적지까지 각각 세션을 만들어 하나의 세션에서 다음 세션으로 패킷을 전달하기 전에 다양한 검사가 가능합니다.

프록시 서버는 두 네트워크 간의 중계기로써 기본적으로 로그인과 같은 매우 높은 보안정책 실현이 가능하며, 바이러스 검사, 로깅, 프로토콜 변경과 같은 많은 추가 기능을 제공할 수 있습니다. 그러나 패킷 필터링에 비해 부하가 크고 속도가 느린 단점이 있습니다.

 

Stateless 패킷 필터링과 프록시 기능을 합친 Hybrid 방식도 존재합니다. 패킷 필터링이 가진 빠른 속도와 투명한 처리, 그리고 프록시가 가진 높은 보안설정 및 다양한 규칙 적용 장점이 결합되어 있어 굉장히 높은 보안성을 가지지만, 두 방식을 복합한 만큼 관리가 어렵고 복잡합니다. 이 때문에 여러 상용 방화벽이 이 방식을 채택한다고 합니다.

네트워크 주소 변환 (NAT)

마지막으로 Network Address Translation 방식이 존재합니다. 내부 사설 네트워크를 보호하기 위해 소스 및 목적지 주소를 다시 기록하는 기법으로 주로 라우터에서 탑재되어 있습니다. 일반 가정에서 또는 한 사무실 내에서 사용되는 private IP와 실제로 통신사가 각 공유기에 부여하는 public IP 주소가 다른 것도 이 방식을 이용됐기 때문이죠.

방화벽 구축 환경

위에서 살펴본 다양한 방화벽 기능들은 라우터나 프록시 서버에 구현되어 있습니다. 보통 방화벽을 구축한다고 할 때, 이 라우터나 서버를 내부망(=내부 네트워크) 경계에 두게 됩니다. 여러 방식이 있지만, 크게 3가지 정도 확인하고 넘어가겠습니다.

스크리닝 라우터 (Screening Router)	단일 홈 게이트웨이 (Single Homed Gateway)	스크린드 호스트 게이트웨이 (Screened Host Gateway)
내부와 외부망 사이에 router를 설치하고, ACL을 구성해 패킷 필터링 구현	보호 방화벽으로 bastion host를 두고, 인증/모니터링/로깅 등 다양한 보안 기능 구현	스크리닝 라우터 + 베스천 호스트 Layer 3, 4에서 router로 1차 Layer 7에서 bastion host로 2차
- 라우터에 부하를 줌 - 따로 방화벽을 설비하지 않아도 됨	- 스크리닝 라우터보다 보안 성능이 높음 - bastion host 공격시에 끝	- 설비 비용 증가 - 높은 보안

Screened Host Gateway 방식

리눅스 커널 방화벽 역사

리눅스는 UNIX 를 기반으로 탄생하였기 때문에 초기에는 유닉스의 슈퍼 데몬 inetd에서 제공하는 TCP Wrapper 를 사용해 방화벽을 구현할 수 있었습니다. TCP Wrapper를 이용하면 특정 호스트이 접근을 허용하거나 차단할 수 있었지만, 세밀한 제어가 불가능했습니다. 이후 유닉스의 네트워크 기반을 다진 BSD의 ipfw를 거쳐 리눅스 1.2 버전에서 이를 보완한 ipfwadm 가 등장해 IP 주소의 일정 대역이나 포트 그리고 TCP, UDP, ICMP 패킷과 같은 특정 프로토콜까지 조합해서 패킷을 제어할 수 있게 되었습니다. 또한 패킷을 들어오는 패킷, 나가는 패킷, 매스커레이딩(Masquerading) 즉, 외부 네트워크용으로 변장한 패킷으로 나누어 세밀하게 패킷을 관리합니다.

 

리눅스 커널 2.2 버전에서 등장한 ipchains는 ipfwadm을 체계화하여 INPUT, FORWARD, OUTPUT이라는 3개의 논리 사슬(chain)에 정책(policy)를 설정해 패킷을 제어합니다. 그리고 리눅스 커널 2.4 버전에서 드디어 iptable이 ipchain의 사슬을 확장해서 테이블이라는 형태로 패킷을 관리하게 됩니다. 추가로 현재는 CentOS 7부터 iptable을 대체해 Firewalld 방화벽 프로그램이 등장해 보다 dynamic 한 방화벽 구축이 가능하다고 합니다. 그러나 아직 iptables와 완벽히 호환되지 않기 때문에 아직은 iptables로 구현된 시스템이 여전히 많은 상황입니다.

커널 버전	초기	1.0	1.2	2.2	2.4
방화벽 도구	TCP Wrapper	ipfw	ipfwadm	ipchains	iptables
설명	유닉스 슈퍼 데몬 inetd 에서 제공. 특정 호스트의 접근 허용/차단	유닉스의 네트워크 기반을 만든 BSD 계열의 도구	ipfw를 보완한 버전. 들어오는 패킷, 나가는 패킷, masquerading 패킷을 관리	INPUT, FORWARD, OUTPUT이라는 3개의 논리 chain에 정책(Policy)을 설정	ipchains를 확장해서 3개 사슬 -> 5개 테이블로 패킷을 관리

Netfilter

iptables는 Netfilter 프로젝트에서 탄생했습니다. Netfilter는 Rusty Russell 이 1998년에 시작한 프로젝트로, Russell 은 이미 선례 프로젝트인 ipchains를 개발한 바 있습니다. netfilter는 높은 확장성이 특징이며 크게 4가지의 핵심 모듈로 구성되어 있습니다.

첫번째 모듈은 이전 버전과의 하위호환을 위해 존재합니다.

• the ipchains and ipfwadm backward-compatibility modules (이전 버전과의 하위호환용)
• the iptables system
• the connection tracking system
• the NAT system

Netfilter는 5 군데에서 hooking을 제공하는데, 각 지점마다 패킷을 처리하는 모듈이 구현되어 있습니다.

위 그림은 꽤나 복잡해 보이지만, PREROUNTING, INPUT, OUTPUT, FORWARD, POSTROUTING 글씨에 맞춰서 보면 이해하기 쉽습니다.

PREROUTING	인터페이스를 통해 들어온 패킷을 가장 먼저 처리하는 곳. 목적지 주소 변경(DNAT)
INPUT	로컬 프로세스로 들어오는 패킷을 처리. 패킷 차단/허용 후 user space로 전달
OUTPUT	로컬 프로세스가 처리하여 밖으로 내보내지는 패킷을 처리. 차단/허용
FORWARD	다른 호스트로 통과시켜 보낼(⇒ 즉, 지나가는) 패킷을 처리. 차단/허용 like 방화벽, IPS
POSTROUTING	인터페이스를 통해 나갈 패킷에 대한 처리. 출발지 주소 변경(SNAT)

Iptables

iptables는 netfiler가 제공하는 5지점의 hook에 규칙을 추가해 패킷의 흐름을 제어할 수 있는 실행 프로그램으로, user space 에서 동작합니다. 각 hook에 원하는 규칙을 설정하면, 그에 맞춰 Netfilter가 kernel space에서 네트워크 제어를 수행합니다. iptable은 Table, Chain, Target이라는 3가지 개념으로 이해할 수 있습니다.

 

먼저 테이블은 Filter, NAT, Mangle, Raw, Security 등 다양한 종류가 있지만 대표적으로 3가지 테이블이 자주 쓰입니다.

Filter Table : 패킷을 걸러내거나 통과
NAT Table : 방화벽 내부 네트워크의 다른 주소로 포워딩 or 외부 네트워크로 나갈 때 다른 ip 주소로 변환
Mangle Table : 패킷의 TTL 이나 OTS 를 변경 

 

각 Table마다 가능한 Chain 조합들이 존재하며, 각 Chain은 어떤 Netfilter hook에 규칙을 적용할지 설정할 수 있습니다.

Filter Table :  INPUT, FORWARD, OUTPUT
NAT Table : PREROUTING, INPUT, OUTPUT, POSTROUTING
Mangle Table : PREROUTING, INPUT, FORWARD, OUTPUT, OUTPUT

 

그리고 마지막으로 Table-Chain에 규칙(Target)을 정의할 수 있습니다. 규칙에 따라 패킷의 미래가 결정됩니다.

ACCEPT  : 허용한다
DROP : 버린다

REJECT : 버린다 (버렸다는 응답을 전송한다)

LOG : syslog에 기록한다.
RETURN : 호출한 체인 내에서 패킷 처리를 계속한다

 

DROP은 요청에 대한 응답없이 패킷을 바로 버리지만, REJECT는 `connection refused` 라는 오류 메세지를 응답으로 돌려주여 요청자가 이를 인식하고 대처할 수 있게 도와줍니다. 

예제

간단한 실습으로 내가 원하는 주소에 대해서만 ping 요청을 허용해보도록 하겠습니다.

먼저 각 테이블별로 사용할 수 있는 체인을 알아봅니다. -t 옵션으로 보고자 하는 테이블을 지정하고 -L 로 리스트를 출력합니다. -t 옵션을 설정하지 않을 경우 기본은 filter table입니다.

iptables -t nat -vL

그 다음 먼저 모든 주소의 ping 요청을 무시하도록 설정하겠습니다. -A 옵션으로 규칙을 append 할 수 있습니다. INPUT 테이블에 icmp 프로토콜로 오는 요청은 모두 DROP 합니다. 출발지, 목적지의 IP:Port를 넣지 않으면, 모든 주소에 대해서 위 규칙이 적용됩니다.

iptables -A INPUT -p icmp -j DROP

자 이제 특정 IP 주소에 대해서만 ping을 허용해봅시다.

iptables에서는 가장 첫번째 규칙부터 우선순위로 수행하기 때문에 규칙의 순서가 중요합니다. -I 옵션을 사용하면 원하는 순서에 규칙을 삽입할 수 있습니다. ACCEPT 규칙을 1순위로 두어 기본적으로 모든 icpm 프로토콜은 방어하되 특정 주소의 요청만 통과하도록 설정합니다.

iptables -I INPUT 1 -p icmp -s 10.178.0.3 -j ACCEPT

1. INPUT 에서 목적지 주소가 10.178.0.3 이면서 icmp 프로토콜인 요청은 ACCEPT 한다.

2. 모든 ICMP 프로토콜 DROP 한다.

1번이 먼저 시행되기 때문에 10.178.0.3 에서 온 ping 요청은 통과하지만, 그 외 다른 주소는 2번 규칙에 의해 무시됩니다. ping 요청을 받아들이지 않는 것을 쉽게 확인할 수 있습니다.

간단한 실습으로 마무리했지만, iptables는 이런 패킷 필터링 외에도 connection tracking 기능을 제공하기 때문에 패킷 연결 상태에 따라 statful 한 방화벽 구축이 가능합니다. 또한 -j 옵션에 SNAT, DNAT, MASQUERADE 를 명시하여 NAT 기능을 설정할 수도 있습니다. 참고로 iptables 규칙은 서버를 재시작하면 초기화되기 때문에 bashrc 파일에 규칙을 저장해두거나 iptables-save 명령어로 설정된 iptables 규칙을 미리 파일로 추출하는 것이 필요합니다 :)

 

오늘은 여기서 마무리하고, 다음에는 또 다른 자주 헷갈리던 네트워크 개념들을 또 정리해보겠습니다~!