방화벽 (네트워킹)

위키백과, 우리 모두의 백과사전.
(패킷 필터에서 넘어옴)

방화벽이 네트워크 안에 위치한 것을 나타낸 그림.

방화벽(防火壁) 또는 파이어월(firewall)은 미리 정의된 보안 규칙에 기반한, 들어오고 나가는 네트워크 트래픽을 모니터링하고 제어하는 네트워크 보안 시스템이다.[1] 방화벽은 일반적으로 신뢰할 수 있는 내부 네트워크, 신뢰할 수 없는 외부 네트워크(예: 인터넷) 간의 장벽을 구성한다.[2] 서로 다른 네트워크를 지나는 데이터를 허용하거나 거부하거나 검열, 수정하는 하드웨어소프트웨어 장치이다.

역할[편집]

방화벽의 기본 역할은 신뢰 수준이 다른 네트워크 구간들 사이에 놓여서 신뢰 수준이 낮은 네트워크로부터 오는 해로운 트래픽이 신뢰 수준이 높은 네트워크로 오지 못하게 막는 것이다. 흔히 네트워크 관리자의 입장에서 높은 신뢰도를 갖는 구간은 내부 네트워크 구간이라 하고, 낮은 신뢰도를 갖는 구간을 인터넷 구간 또는 외부 네트워크 구간이라고 한다. 이 밖에도 외부에 서비스를 제공하는 서버들을 위한 DMZ 구간이 있으며 인터넷으로부터 내부 네트워크로의 침입을 막는 동시에 내부 네트워크에서 인터넷과 자유롭게 통신할 수 있도록 도와 준다.[3]

대부분의 방화벽은 정책 기반의 방화벽이며 다양한 수준의 정책으로 네트워크 간의 트래픽을 제어한다.

  • 일반 수준의 정책: 외부에서 내부로 전송되는 모든 트래픽을 차단하거나 허용
  • 고급 수준의 정책: "외부의 경쟁회사.com으로부터 내부 서버 가짜정보.net으로 오는 길이 500바이트 이상의 http 트래픽을 허용하되 로그를 남긴다."와 같은 복잡한 정책.

역사[편집]

방화벽이라는 용어는 원래 건물 내 화재를 제한하기 위해 고안된 방벽을 의미했다.[4] 나중에 이 용어는 1980년대 말 네트워크 기술에 적용되었는데, 전 세계적인 이용 및 연결 면에서 인터넷이 매우 새롭게 등장한 당시 등장하였다.[5] 네트워크 보안을 위한 방화벽의 전신은 1980년대 말에 사용된 라우터였는데, 그 이유는 이들이 네트워크를 다른 네트워크와 분리시켰으므로 한 네트워크에서 다른 네트워크로 문제를 전파하는 것을 막아주었기 때문이다.[6]

1세대 방화벽 : 패킷 필터[편집]

패킷 자체만을 보고 미리 설정된 정책에 따라 허용 또는 거부를 결정하는 초창기 방화벽은 1세대 방화벽이라고 한다. 방화벽 내부에서 상태(세션)를 관리하지 않는 기본 형태의 방화벽이다. 이 방화벽은 특정한 IP를 허용 또는 거부하거나 특정한 포트를 허용 또는 거부하는 용도로 사용된다.

2세대 방화벽 : 스테이트풀 인스펙션[편집]

패킷 필터 방화벽은 매우 효율적이긴 하지만 다음과 같은 몇 가지 문제가 있다.

  • 모든 패킷이 모든 정책에 해당되는지 검사하므로 정책이 많아질수록 처리 속도가 느려진다.
  • 돌아오는 패킷을 허용하는 정책으로 인해 보안이 취약해질 수 있다.
  • FTP와 같이 파생 세션을 만드는 일부 프로토콜을 지원하기 위해 모든 포트를 다 열어야 될 수도 있다.

이러한 문제들을 해결하기 위해서 고안된 것이 패킷 단위의 검사가 아닌 세션 단위의 검사를 하는 스테이트풀 검사이다.

기본적인 스테이트풀 검사는 다양한 파생 세션을 모두 처리하지 못하는 경우가 있는데, FTP의 능동적/수동적 데이터 세션등 복잡한 파생세션을 별도의 정책 추가 없이 모두 처리할 수 있는 확장된 스테이트풀 검사를 하는 방화벽도 있다.

3세대 방화벽 : 애플리케이션 방화벽[편집]

초창기에 네트워크를 기반으로 하던 공격 패턴이 점차 발달하여 일상적인 트래픽과 같은 특성을 가지면서 시스템을 공격하는 형태로 발전하게 되었다. 패킷 필터 기반의 방화벽으로는 이러한 공격을 방어하기 어려워지면서 패킷의 내용을 검사하고 더 나아가서는 애플리케이션에 어떠한 영향을 미칠지를 분석하는 방화벽이 출현하기 시작한다. IPS, WAF, UTM 등으로 불리는 네트워크 장비들이 애플리케이션 방화벽이라고 할 수 있다.
다른 발전 방향으로는 IP 주소나 MAC 주소 같이 사용자가 기억하거나 이해하기 어려운 대상을 이용해서 방화벽 정책을 수립하던 과거의 방화벽과는 달리 새로운 방화벽들은 사용자에게 보다 친숙한 사람의 이름이나 도메인 주소를 이용해서 정책을 수립할 수 있게 하는 방화벽들도 속속 등장하고 있다.

분류[편집]

기능과 구성에 따른 분류[편집]

패킷 필터[편집]

패킷을 검사하여 미리 설정된 정책에 맞지 않을 경우 통과시키지 않도록 하는 형태의 방화벽을 패킷 필터라 한다. 패킷을 다룬다는 측면에서 TCP/IP의 네트워크 계층에서 동작하는 방화벽이다. 방화벽 관리자는 보호할 네트워크에 적용할 규칙 또는 정책을 설정하여야 하고 설정이 되어 있지 않다면 기본 정책이 적용된다. 흔히 커널 레벨에서 수행되고 프록시 방식에 비해 제한된 검사만을 수행하여 더 많은 트래픽을 처리할 수 있다는 장점이 있다.
패킷 필터 방화벽은 순수하게 패킷 자체를 볼 것인지, 패킷이 속하는 TCP 또는 UDP 세션 (또는 플로우 라고도 함)도 같이 관리할 것인지에 따라 다시 두 종류로 분류할 수 있다.
패킷 자체를 본다면 내부적으로 상태를 관리할 필요가 없으므로 이 종류를 스테이트리스 또는 무상태 방화벽이라 한다. 이 종류의 방화벽은 쉽게 구현할 수 있지만, 모든 패킷에 대해서 매번 정책을 검사하여야 하므로 정책이 많아질수록 속도가 느려지는 단점이 있다.
패킷이 속하는 세션을 관리하여 이 세션에 속하는 패킷들에 대해서 모두 동일한 처리를 하게 하는 방화벽의 종류를 스테이트 풀 방화벽이라 하고 "상태가 있는 방화벽" 또는 유상태 방화벽이라 번역할 수 있다. 방화벽은 두 통신 당사자 간에 세션이 생성될 수 있는 패킷 조합을 감지하여 동적 정책을 내부적으로 관리하며 이 세션에 속하는 패킷들은 방화벽 관리자에 의해서 한번 설정된 후 자주 바뀌지 않는 정적 정책에 비해서 빠르게 검색할 수 있는 동적 정책에 의해서 먼저 허용 또는 거부되므로 무상태 방화벽에 비해서 일반적으로 높은 속도를 제공할 수 있다.
유닉스 계열의 OS는 ipfw(FreeBSD), pf(OpenBSD 및 다른 BSD계열), ipf(다양한 유닉스에서 지원), iptables/ipchain(리눅스) 등의 다양한 커널 기반의 방화벽을 제공한다.

프록시 (Proxy)[편집]

세션에 포함되어 있는 정보의 유해성을 검사하기 위해서 방화벽에서 세션을 종료하고 새로운 세션을 형성하는 방식의 방화벽. 출발지에서 목적지로 가는 세션을 명시적으로 또는 암시적으로 가로채어서 출발지에서 방화벽까지의 세션과 방화벽에서 목적지까지의 두 세션으로 만든 다음 하나의 세션에서 다른 세션으로 정보를 넘겨주기 전에 검사를 수행하는 형태이다. 패킷 필터에 비해서 방화벽에 더 많은 부하를 주어서 속도는 느리지만 더 많은 검사를 수행할 수 있고, 프로토콜 변경 등 추가적인 기능을 수행할 수 있다.

네트워크 주소 변환 (NAT)[편집]

많은 방화벽은 네트워크 주소 변환 (NAT) 기능을 가진다. 내부 네트워크에서 사용하는 IP 주소와 외부에 드러나는 주소를 다르게 유지할 수 있기 때문에 내부 네트워크에 대한 어느 정도의 보안 기능을 한다. 또한 내부에서 사용하는 IP 주소 수보다 더 적은 외부 IP 주소 수만 사용할 수 있기 때문에 인터넷 통신을 위해서 사용하는 모든 컴퓨터 수 만큼의 IP 주소를 구매할 필요가 없어져 경제적이다. 동시에 IPv4 주소를 더 효율적으로 이용할 수 있게 해서 IPv4 주소의 완전 고갈을 늦추고 있는 기능이기도 하다.
내부 IP 주소 개수보다 더 적은 외부 IP 주소를 사용하므로 하나의 외부 IP 주소 당 여러 내부 IP 주소가 짝 지어져야 한다. 이 때 내부에서는 서로 다른 세션이 외부에서는 하나의 세션으로 보일 경우가 생기며, 이처럼 세션 충돌이 생겼을 경우 출발지 포트를 변경하여 충돌을 피하는데 이를 포트 주소 변환 (PAT)라고 부르기도 한다.
네트워크 주소 변환을 위해서도 방화벽 정책과 같은 정책을 수립하여야 한다. 일반적으로 RFC1918에 정해진 내부 네트워크 대역인 10.0.0.0, 172.16.0.0, 192.168.0.0 대역을 내부 네트워크의 주소로 하고 이 네트워크 전체가 적은 수의 외부 IP 주소로 변환되도록 정책이 만들어져야 한다.

<NAT 정책 예>

변환전 내부 (출발지:172.16.0.0 /12 목적지:Any ) «=» 변환 후 외부 (출발지: AAA.BBB.CCC.D1, AAA.BBB.CCC.D2 목적지: Org)
내부에서 사용하는 네트워크 주소 172.16.0.0/12가 외부에서는 AAA.BBB.CCC.D1 또는 D2로 보이게 변환하는 목적의 정책으로 내부 네트워크에서 외부의 어떤 (Any) 서버나 컴퓨터랑 연결할 때, 출발지는 변환이 되지만 목적지는 원래 그대로(Org)로 유지하도록 하겠다는 정책이다. 이 정책은 패킷이 외부로 나갈 때도 적용되어야 하지만, 외부로부터 돌아오는 응답 패킷에도 동일하게 적용되어야 한다.

구현 방법에 따른 분류[편집]

소프트웨어 방화벽[편집]

흔히 구할 수 있는 CPU를 장착한 네트워크 장비(실제로는 PC와 같은 컴퓨터)에 순수하게 소프트웨어를 이용하여 방화벽 기능을 구현한 방화벽이다.

  • 오픈소스 소프트웨어 방화벽 종류 - IPCOP, IPFIRE, PFSENSE, ENDIAN, MONOWALL, SMOOTHWALL

하드웨어 방화벽[편집]

네트워크가 복잡해지고 트래픽이 증가하면서 방화벽이 설치되는 네트워크 관문을 통과하는 네트워크 트래픽의 양은 순수 소프트웨어 방식의 방화벽으로 처리할 수 있는 한계를 넘어서기 시작했다. 소프트웨어의 발전 속도보다 네트워크 트래픽의 증가 속도가 더 빠르기 때문이다. 이에 대한 해결법으로 사람들에 의해서 고안된 것이 ASIC 등을 이용하여 방화벽의 초당 패킷처리 수를 늘리는 것이다.

NPU 기반의 방화벽[편집]

소프트웨어 기반의 방화벽은 속도를 빠르게 하기 힘들고, 순수 하드웨어 기반의 방화벽은 유연성이 떨어지기 때문에 양쪽의 장점만을 취하는 방법이 발달하기 시작했다. 공통으로 사용되는 패킷처리 함수를 하드웨어로 구현하되 프로그래밍도 가능한 NPU가 그 중 하나이다.

멀티코어 프로세서 기반의 방화벽[편집]

NPU 기반의 방화벽이 뛰어난 성능에 유연성을 겸비하였으나, 많은 경우 너무 프로그래밍하기가 어렵다. 따라서, 제품 개발에 소요되는 시간이 제품의 전체 수명 주기의 많은 부분을 차지하게 되는 문제가 있다. 시장에서 흔하게 팔리고 있는 CPU와 같은 명령어를 가지고 있어서 개발자에게 익숙한 처리 단위(CPU의 코어)를 가지고 있어서 한 번에 많은 양의 패킷을 처리할 수 있게 한 것이 멀티코어 프로세서 기반의 방화벽이다.

같이 보기[편집]

각주[편집]

  1. Boudriga, Noureddine (2010). 《Security of mobile communications》. Boca Raton: CRC Press. 32–33쪽. ISBN 0849379423. 
  2. Oppliger, Rolf (May 1997). “Internet Security: FIREWALLS and BEYOND”. 《Communications of the ACM》 40 (5): 94. doi:10.1145/253769.253802. 
  3. Hwang, Sunghan; Jeon, Seongwoo; Namkung, Seungpil; Hwang, Hyunho; Henderson, Joseph P. (2019년 6월 30일). “Establishment of an Effective Preparation System for the Preservation of DMZ Natural Ecosystem”. 《Journal of Environmental Policy and Administration》 27 (2): 39–67. doi:10.15301/jepa.2019.27.2.39. ISSN 1598-835X. 
  4. Canavan, John E. (2001). 《Fundamentals of Network Security》 1판. Boston, MA: Artech House. 212쪽. ISBN 9781580531764. 
  5. Liska, Allan (2014년 12월 10일). 《Building an Intelligence-Led Security Program》. Syngress. 3쪽. ISBN 0128023708. 
  6. Ingham, Kenneth; Forrest, Stephanie (2002). “A History and Survey of Network Firewalls” (PDF). 2011년 11월 25일에 확인함.