OPNsense로 방화벽 구축하기 [3편]

 지난 포스팅 OPNsense로 방화벽 구축하기 [2편]에서 이어집니다. 2편을 먼저 읽어보시길 추천드립니다.

OPNsense로 방화벽 구축하기 [2편]

---

 이전 포스팅에서 새로운 인터페이스를 생성하고 모든 트래픽을 허용하는 규칙을 통해 서로 다른 네트워크에 있는 호스트 간의 통신을 확인해 보았습니다. 이번 포스팅에서는 본격적인 방화벽 규칙 설정에 대해 다뤄보도록 하겠습니다.

 

In & Out

 방화벽 규칙을 생성할때 가장 많이 헷갈리는 요소가 바로 트래픽의 방향일 것입니다. 방화벽 규칙 리스트에 화살표 모양으로 표시되는 것으로 오른쪽(→) 화살표는 In을, 왼쪽(←) 화살표는 Out을 의미합니다.

In/Out Traffic을 의미하는 화살표 표시

 방화벽 규칙을 생성할때 Direction의 툴팁을 읽어보면 아래와 같습니다. 'IN'은 방화벽 인터페이스로 들어오는 트래픽을 의미하는 것이고, 'OUT'은 방화벽 인터페이스에서 나가는 것을 뜻한다고 하는데, 물론 아주 훌륭한 설명이고 사실 이게 핵심이긴 하지만 그럼에도 다소 애매한 면이 있습니다.

Direction of the traffic. Traffic IN is coming into the firewall interface, while traffic OUT is going out of the firewall interface. In visual terms: [Source] -> IN -> [Firewall] -> OUT -> [Destination]. The default policy is to filter inbound traffic, which means the policy applies to the interface on which the traffic is originally received by the firewall from the source. This is more efficient from a traffic processing perspective. In most cases, the default policy will be the most appropriate.

 특히, 방화벽 규칙 적용시 많이 혼동하는 부분이 바로 방화벽 내부에서의 트래픽 흐름입니다. 결론부터 말씀드리자면 이는 전혀 고려할 필요가 없습니다. 아마 이런 혼동이 오는 이유가 방화벽 장비와 그 인터페이스를 분리해서 생각하기 때문일 것입니다. 아래 그림을 보면서 이야기해 봅시다.

방화벽 트래픽 흐름에 대한 오해

 만약 'Host 1'에서 'Host 2'로 통신을 한다고 가정해 봅시다. 그럼 보통 (1)'Host 1'에서 출발한 트래픽이 'LAN 1' 포트에 도착, (2)'LAN 1' 포트에서 'LAN 2' 포트로 트래픽 전달, (3)'LAN 2'포트에서 'Host 2'로 트래픽 전송이라는 방식으로 생각할 것입니다. 이 생각은 너무나도 타당합니다. 그렇다면 여기서 어떤 것이 'IN'이고 어떤 것이 'OUT'인 트래픽일까요? (1)은 'IN'이 확실한것 같습니다. 그리고 (3)은 'OUT'이 확실한것 같구요. (2)가 좀 애매하네요. 'LAN 1'에서 출발하니 'OUT'인 것 같기도 하고... 'LAN 2'에 도착하고 있으니 'IN'이 아닌가 싶기도 합니다.

 정답은 (2)는 생각하면 안된다는 것입니다. (2)는 방화벽 내부에서 흐르는 트래픽으로 'IN'도 'OUT'도 아닙니다. 고려의 대상이 아니라는 것이죠. 방화벽에서 'IN'과 'OUT'을 구분하는 기준은, 철저히 방화벽의 입장에서 바라 보았을때 트래픽이 어떻게 흐르냐는 것입니다.

방화벽 입장에서만 'IN'과 'OUT'을 고려

 즉, 방화벽으로 향하는 트래픽은 모두 'IN'으로 인식하면 되고 방화벽 밖으로 빠져나가는 트래픽은 'OUT'으로 인식하면 된다는 것입니다. 방화벽 내부에서 움직이는 트래픽은 전혀 'IN', 'OUT'에 대해 고려할 필요가 없다는 것이죠. 이를 단순화하면 아래 그림과 같습니다.

방화벽으로 향하는 트래픽은 'IN', 방화벽에서 출발하는 트래픽은 'OUT'

 철저하게 방화벽으로 향하는 트래픽은 모두 'IN'으로 인식하고 방화벽에서 출발하는 트래픽은 모두 'OUT'으로 이해하면 된다는 것이죠. 이러한 개념에 대한 이해를 돕는 영상을 하나 추천드립니다.

Youtube - Home Network Guy

인바운드는 'All deny', 아웃바운드는 'All pass'

 방화벽 규칙을 적용할때는 'IN' 즉, inbound(인바운드) 규칙을 생성하는 것이 가장 기본적이며 일반적인 접근법입니다. 그 이유는 인바운드 규칙을 통해 외부 네트워크에서 내부 네트워크로 들어오는 트래픽을 제어할 수 있기 때문입니다. 기본적으로 WAN 인터페이스나 새로 생성된 인터페이스의 경우에는 초기에 아무런 규칙(자동 설정 규칙 제외)이 설정되어 있지 않습니다. 그 이유는, 아무런 규칙이 설정되어 있지 않는 경우 방화벽은 기본적으로 인바운드 트래픽에 대해서는 'All deny' 정책이 적용되기 때문입니다.

아무런 규칙을 적용하지 않으면 모든 인바운드 트래픽을 차단

 외부와의 경계가 되는 WAN 인터페이스의 경우 인바운드 트래픽에 대해서 'All deny' 정책이 기본이 되어야 하는 것은 당연하다고 할 수 있겠습니다. 반대로 'OUT' 즉, outbound(아웃바운드)의 경우에는 기본적으로 트래픽이 통과되도록 되어 있습니다. 역시 이러한 설정 때문에 WAN 인터페이스에 아무런 규칙이 없어도 내부의 호스트들이 외부 인터넷과 통신이 가능했던 것입니다.

 

기본적인 방화벽 규칙

 그럼 몇가지 기본적인 방화벽 규칙에 대해서 살펴보도록 하겠습니다. 이러한 규칙을 잘 조합하거나 응용하면 원하는 환경에 맞는 방화벽 규칙을 생성할 수 있을 것입니다.

 

1. 특정 네트워크로의 접근을 허용

 우리의 실습 환경에서 Internal 인터페이스에 할당된 네트워크인 192.168.11.0/24에서 LAN 네트워크인 192.168.1.0/24로 접근을 허용해 보겠습니다. 왼쪽 메뉴에서 Firewall > Rules > Internal로 이동합니다. 화면 오른쪽에 '+' 아이콘을 눌러 새로운 규칙을 생성합니다.

규칙 생성

  Action은 Pass로 지정합니다. Interface는 해당 룰이 적용되는 인터페이스를 의미하며 현재 우리는 Internal 인터페이스에 이 룰을 적용시킬 것이므로 기본으로 설정되어 있는 Internal을 그대로 둡니다. Direction은 in으로 설정합니다. 혹시나 192.168.11.0/24 네트워크에서 192.168.1.0/24로의 접근이니까 192.168.11.0/24에서 나가는 트래픽이라고 생각해서 out으로 설정하면 안 됩니다. 다시 한번 강조하면, 방화벽 규칙은 철저하게 방화벽 입장에서 생각해야 한다는 것입니다. 방화벽 입장에서는 192.168.11.0/24 네트워크에서 출발한 트래픽이 들어오는 것이므로 in이 맞습니다. TCP/IP Version은 IPv4로, Protocol은 any로 둡니다.

 Source의 경우 드롭다운 메뉴를 보면 여러 가지 카테고리가 나옵니다. Network 카테고리에는 방화벽 인터페이스 이름이 나타나며, 각 인터페이스는 하나의 네트워크를 의미합니다. 각 인터페이스마다 net과 address가 존재하는 것을 볼 수 있는데 여기서 net은 해당 인터페이스에 할당된 네트워크 전체를 의미하며 address는 해당 인터페이스의 주소, 그러니까 Internal address의 경우 192.168.11.1을 의미합니다. 지금 설정하려는 방화벽 규칙은 192.168.11.0/24 네트워크에 속한 호스트들이 192.168.1.0/24 네트워크의 호스트와 통신을 해야 하므로 Internal net으로 설정해야 합니다. Destination의 경우 192.168.1.0/24 네트워크 즉, LAN net을 선택합니다.

Source와 Destination 설정

 그리고 하단에 Save 버튼을 누르면 다시 이전 화면으로 돌아오면서 방금 설정한 규칙이 해당 인터페이스에 생성된 것을 확인할 수 있습니다. 그리고 화면 우측 상단에 Apply changes라는 버튼이 나타나는데 이는 방금 생성한 규칙을 실제로 적용하도록 하는 버튼으로 이것을 눌러주어야 규칙이 작동하기 시작합니다.

Apply changes를 통해 규칙을 활성화

 이렇게 되면 Internal 네트워크에 속한 호스트들이 LAN 네트워크에 속한 호스트들과 통신을 할 수 있게 됩니다. 그리고 하나 더, 규칙이 많이 추가되면 해당 규칙이 어떤 용도였는지 혼란스러운 경우가 생길 수 있습니다. 따라서 규칙을 생성할 때 Description에 해당 규칙에 대한 설명을 적어 두는 것을 추천드립니다. OPNsense는 한글을 지원하므로 한글로 메모를 해둔다면 시간이 흘러도 해당 방화벽 규칙이 무엇을 위한 것이었는지 쉽게 파악할 수 있을 것입니다.

Host-02(192.168.11.2)에서 192.168.1.0/24 네트워크와의 통신 테스트

 규칙이 적용되면 위와 같이 192.168.1.0/24 네트워크의 게이트웨이 인터페이스(192.168.1.1), 그리고 Host-01(192.168.1.2)와도 통신이 잘 되는 것을 확인할 수 있습니다.

2. 특정 네트워크로의 접근을 차단

 차단 규칙의 설정은 앞선 접근 규칙의 설정에서 Action만 변경해 주면 됩니다. 기존 동작인 Pass에서 Block 또는 Reject 중 하나를 선택하면 됩니다. 두 선택지 모두 차단을 위한 규칙이지만 그 동작에는 약간의 차이가 존재합니다. Action의 툴팁을 살펴보면 아래와 같습니다.

Choose what to do with packets that match the criteria specified below. Hint: the difference between block and reject is that with reject, a packet (TCP RST or ICMP port unreachable for UDP) is returned to the sender, whereas with block the packet is dropped silently. In either case, the original packet is discarded.

 Block과 Reject에 대해서 비교를 해보면 아래와 같습니다.

Block	Reject
- 패킷이 조용히 삭제 - 발신자에게 어떠한 응답도 보내지 않음 - 발신자는 패킷이 어떻게 되었는지 알 수 없음 - Silent drop 또는 Balck hole이라고도 불림	- 패킷이 삭제되지만, 발신자에게 오류 메시지가 반환 - TCP 연결의 경우 TCP RST(Reset) 패킷이 반환 - UDP 연결의 경우 ICMP로 "port unreachable" 메세지 반환 - 발신자는 패킷이 차단되었다는 것을 명확히 알 수 있음

 Block의 경우 완벽하지는 않지만(여러 우회 경로로 확인이 가능하기 때문) 서버의 존재를 숨길 수 있어서 보안적으로 유리한 점이 있습니다. 다만 어떤 요청을 하는 클라이언트가 그 응답에 대해서 타임아웃이 될 때까지 하염없이 기다리기 때문에 네트워크의 효율성 측면에서는 불리한 점이 있습니다.

Block으로 설정한 경우 ssh 연결이 타임 아웃될때까지 기다림

 Reject의 경우 그 반대로, 즉각적인 오류 응답으로 네트워크의 효율성이 증가합니다. 단, 오류 응답이 있다는 것은 그곳에 무언가 응답의 주체가 있다는 뜻으로 해석될 수 있기 때문에 보안적인 측면에서는 다소 불리한 면이 있습니다.

Reject의 경우 즉각적으로 'Connection refused' 메시지 응답

3. 인터넷 연결은 허용하면서 Private Network 접근은 차단

 내부적으로 Private Network가 많이 존재한다고 가정해 보겠습니다(편의상 네트워크 A, B, C라고 칭함). 그리고 여기에 또 새로운 Private Network(네트워크 D라 칭함)가 생성되었다고 가정해 봅시다. 그런데 D 네트워크는 보안상 확실한 격리가 필요한 네트워크라서 기존 네트워크인 A, B, C와 서로 격리되어야 하며 그럼에도 불구하고 외부(인터넷)로는 빠져나갈 수 있어야 합니다.

 이런 경우에 방화벽 규칙을 적용한다고 해 보겠습니다. 우선 A 네트워크 인터페이스에 새로 생성된 네트워크 D로의 접근을 차단해야 하고, B와 C 네트워크 역시 이러한 규칙을 생성해야 합니다. D 네트워크는 인터넷에 대한 접근이 필요하므로 목적지를 0.0.0.0/0으로 하는 통과 규칙을 생성해야 하는데, 이렇게 되면 다른 Private Network에도 접근을 할 수 있게 됩니다. 만약 A, B, C 네트워크 역시 보안상 이유로 접근을 차단해야 한다면 D 네트워크의 규칙에도 각 네트워크에 대해서 접근 차단 규칙을 설정해야 합니다. 이 모든 것을 만족시키기 위해 단순 반복 작업인 네트워크 규칙 생성을 7번이나 수행해야 합니다. 거기다가, 네트워크가 10개, 20개로 늘어난다면? 이런 단순 반복 작업을 수동으로 수행해서는 답이 없습니다.

네트워크가 추가될 때 마다 늘어나는 규칙 추가 작업

 Aliases와 Destination invert를 사용하면 이러한 문제를 해결할 수 있습니다. 우선 Firewall > Aliases 메뉴로 접근합니다. 여기 Private Network 주소에 대한 Alias를 생성합니다.

Alias 추가

Private Netwokrs 정보 입력

 위와 같이 Private Network에 대한 정보를 입력합니다. Type을 Network(s)로 하고 Content에 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16을 '콤마'로 구분하여 입력합니다. 그리고 저장한 후 다시 Firewall > Rules > Internal 메뉴로 이동하여 새로운 규칙을 생성합니다. 앞서 살펴본 '1. 특정 네트워크로의 접근을 허용'에서와 같이 Action은 Pass, Source는 해당 인터페이스의 net(Internal net)으로 설정합니다. 여기서 핵심은 Destination 설정입니다. 우선 Destination을 방금 Aliases에서 만든 PrivateNetwork로 합니다.

Destination을 PrivateNetwork로 설정

Destination / Invert 체크 박스 활성화

하나의 규칙으로 인터넷 접근 허용, Private Network 접근 차단

 

 그리고, Destination / Invert의 체크박스를 활성화합니다. 이렇게 되면 Destination에 대해서 반전이 일어납니다. 그럼 'Private Network를 목적지로 하는 패킷을 제외한 나머지' 패킷에 대해서만 Pass가 되고 나머지는 Block이 되게 됩니다. 이렇게 설정을 하게 되면 향후 다른 Private Network가 생성되어도 기본적으로 해당 네트워크에 대한 접근을 차단할 수 있게 됩니다. 그럼 앞서 예시로 들었던 새로운 번거로운 반복 작업을 피할 수 있게 됩니다.

Private Network 접근은 차단되었지만 인터넷 접근은 허용된 것을 확인

4. 특정 호스트의 특정 포트 또는 서비스에 대한 접근을 허용

 방금 전 '3. 인터넷 연결은 허용하면서 Private Network 접근은 차단'에서 설정한 규칙으로 Host-02에서는 Host-01로 접근이 불가능합니다. 그러나 특정 호스트의 특정 포트나 서비스에 접근을 허용해야 한다면 어떻게 해야 할까요?

192.168.1.2의 http(80 포트) 접근에 대해서 Time out 발생

 이번에는 Host-02(192.168.11.2)에서 Host-01(192.168.1.2)의 웹 서비스에 접근해야 한다는 가정하에 방화벽 규칙을 생성해 보겠습니다. 다시 한번 Firewall > Rules > Internal로 이동합니다. 그리고 새로운 규칙을 생성해 줍니다. 역시 이번에도 Action은 Pass, Direction은 in, Source는 Internal net입니다. Protocol 설정부터 차이가 나는데 이번에는 http 연결이므로 TCP로 설정해 줍니다. 그리고 Destination은 Single host or Network를 선택합니다. 그러면 그 아래에 입력이 가능한 창이 활성화되는데 여기에 Host-01의 IP 주소인 192.168.1.2를 입력합니다. 그리고 Destination port range에 from과 to 모두 HTTP로 설정합니다.

웹 서비스 허용 방화벽 규칙

Host-01의 http(80 포트)에 대한 접근 허용

 그리고 Save 한 후 Apply change를 잊지 말고 눌러주어 새로 생성된 방화벽 규칙이 잘 작동하도록 적용해 줍니다. 그리고 다시 curl 명령어와 웹 브라우저를 통해 Host-01의 웹 서비스에 접근이 가능한지 확인해 보면 아래와 같은 결과를 얻습니다.

Host-01(192.168.1.2)의 http(80 포트)에 대해서 접근은 가능하지만 ping은 실패하는 것 확인

 curl 명령어와 웹 브라우저는 문제없이 잘 작동하는 것을 확인할 수 있습니다. 하지만 ICMP 프로토콜을 사용하는 ping 명령어는 실패하는 것을 볼 수 있습니다. 이를 통해 특정 호스트에 대한 특정 포트나 서비스에 대한 접근을 허용하는 규칙도 알아보았습니다.

 

기본 규칙 정리

 지금까지 살펴본 규칙을 표로 정리하면 다음과 같습니다. 이를 기본으로 하여 여러 가지 규칙을 생성할 수 있을 것입니다.

규칙	Action	Direction	Protocol	Source	Destination	Invert	Destination port range
특정 네트워크 접근 허용	Pass	in	any	규칙이 적용될 네트워크의 net	목적지 net	X	any
특정 네트워크 접근 차단	Block or Reject	in	any	규칙이 적용될 네트워크의 net	목적지 net	X	any
인터넷 허용 & Private Network 접근 차단	Pass	in	any	규칙이 적용될 네트워크의 net	Private Network(aliase로 설정)	O	any
특정 호스트의 특정 서비스 접근 허용	Pass	in	서비스가 사용하는 프로토콜	규칙이 적용될 네트워크의 net 또는 호스트	서비스를 제공하는 호스트 또는 net	X	서비스가 사용하는 포트

 

 또한 방화벽에서 중요한 것은 규칙이 순서대로 적용된다는 것입니다. 인터페이스에 도착한 패킷은 첫 번째 방화벽 규칙부터 시작하여 차례로 검증을 하고 가장 먼저 매칭되는 규칙을 적용받게 됩니다. 따라서 규칙 적용 시 순서를 잘 고려해야 엉뚱하게 패킷이 드랍되거나 통과되는 것을 막을 수 있습니다.

---

 이번 OPNsense 시리즈 포스팅을 통해 OPNsense 설치부터 기본적인 사용법과 방화벽 규칙 적용하는 방법에 대해서 알아보았습니다. 이 외에도 OPNsense에는 DNS, DHCP, VPN과 같은 기능을 기본적으로 제공하며 BGP, HAproxy와 같은 다양한 기능들도 플러그인과 패키지로 제공하고 있습니다. 기회가 된다면 이러한 기능들도 꾸준히 포스팅해보려고 합니다.

 

 추가로 OPNsense 공식 문서와, 홈 랩 구성시 참고했던 Youtube 채널 링크를 남기고 포스팅을 마치겠습니다.

Welcome to OPNsense’s documentation! — OPNsense documentation

Home Network Guy