[도서] 인프라보안 - 6장: VLAN 구성을 통한 망분리

VLAN을 만드는 것과 격리하는 것은 다른 문제다

이 챕터에서 꽤 인상적이었던 부분이 있다. VLAN 10(웹), 20(오피스), 30(내부서버), 40(DB) 이렇게 4개 대역을 pfSense에서 다 만들고 나면, pfSense 대시보드에 인터페이스가 깔끔하게 줄지어 보인다. 뭔가 다 된 것 같은 느낌이 든다.

근데... 실제로는 아무것도 안 된 상태다.

책에서도 이 지점을 꽤 강조했다. 각 VLAN을 생성할 때 기본으로 붙는 룰이 "해당 VLAN에서 나가는 모든 트래픽을 허용"하는 permit all 룰이다. VLAN끼리 분리했다고 착각하기 쉽지만, 오피스 대역(10.20.x.x)에서 DB 서버(10.40.x.x)로 SSH도 되고, MySQL 3306 포트도 그냥 열려 있다. 실제로 테스트하면 접속이 돼버린다. VLAN은 물리적으로 트래픽을 분리하는 게 아니라 논리적으로 구분하는 것이고, 접근 제어는 별도로 만들어야 한다는 걸 여기서 다시 실감했다.

 

그래서 ACL 작업이 시작된다. 방식은 deny all 먼저, 그다음에 필요한 것만 하나씩 열어주는 화이트리스트 방식이다. pfSense의 방화벽 룰은 맨 위에서부터 순서대로 읽히기 때문에 룰 순서가 틀리면 결과가 완전히 달라진다. 책에서 강조한 것처럼, 맨 밑에 permit all 룰이 있다면 위에서 아무리 차단해도 결국 통과된다. 룰 위치 관리가 생각보다 훨씬 중요한 부분이다.

RFC1918 Aliases로 VLAN 간 차단을 깔끔하게

ACL을 처음 만들다 보면 금방 문제가 생긴다. VLAN이 4개면 각각 "다른 VLAN으로 가는 트래픽 차단" 룰을 따로따로 넣어야 하는데, 나중에 VLAN이 하나 추가되면 기존 룰을 전부 건드려야 한다. 꽤 비효율적인 방식이다.

책에서 제시한 해법이 pfSense의 Aliases 기능이다. Aliases에 RFC1918 사설 주소 전체를 묶어두면, 이걸 단일 오브젝트처럼 목적지에 넣을 수 있다. RFC1918은 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 세 대역을 묶은 것이고, 이 Alias를 Destination에 지정하면 "내부 사설망 전체로 나가는 트래픽 차단"이 하나의 룰로 정리된다.

 

각 VLAN 룰의 패턴은 단순하다. 맨 위에서 자기 VLAN 외의 내부 대역 전체를 Block, 그 다음에 자기 VLAN 내부 통신은 Pass, 맨 밑에 나머지 트래픽 허용. 이 세 줄 구조가 기본이 된다. 새 VLAN이 추가돼도 RFC1918 Aliases를 쓰는 차단 룰은 그대로 동작하니까, 매번 룰을 수정할 필요가 없어진다.

차단만 하면 서버 관리도 못 한다, 예외 허용의 설계

VLAN 간을 전부 차단하고 나면 새로운 문제가 생긴다. 서버에 아무도 접속을 못 한다. 유지보수도 불가능하다. 당연한 얘기지만, 차단 정책을 설계할 때는 "어디서 어디로 어떤 포트만 열어줄 것인가"를 먼저 정리해두는 게 중요하다.

책에서는 오피스 대역 VLAN 20을 기준으로 접근 시나리오를 정리했다. 핵심만 보면 이렇다. 오피스에서 웹 서버 대역으로는 80/443만 열고, 내부 서버 대역과 DB 대역으로는 SSH(22)만 허용한다. DB의 MySQL 포트 3306은 오피스에서는 접근 불가, 내부 서버에서만 접근하도록 설계한다.

그리고 특정 서버 하나만 제어해야 할 때는 Aliases에 개별 IP를 등록해서 쓸 수 있다. 책에서는 HoneyPot이라는 이름으로 10.30.1.11을 등록하는 예를 보여줬는데, 이렇게 하면 룰에 IP를 직접 박는 대신 이름으로 관리할 수 있다. IP가 바뀌면 Aliases만 수정하면 되니까 룰 자체는 건드릴 필요가 없다.

사실 이 챕터를 읽으면서 가장 와닿은 건 이거다. VLAN 구성 자체보다 "어떤 트래픽을 허용하고, 어떤 트래픽을 막을 것인가"를 먼저 정리하는 설계 작업이 훨씬 더 중요한 부분이라는 것. 룰은 설계가 나와야 만들 수 있고, 설계 없이 룰을 먼저 만들다 보면 어느 순간 방화벽 룰이 수백 개가 되어도 왜 있는지 모르는 룰들로 가득 차게 된다.