[도서] 인프라보안 - 9장: VPN을 통한 외부 접근 제어

openvpn-client-export 패키지가 왜 편한가

pfSense에서 OpenVPN 서버를 구성할 때 클라이언트 배포 방식이 꽤 인상적이었다. 기본 메뉴만 써도 설정은 되는데, 굳이 openvpn-client-export 패키지를 따로 설치하는 이유가 있다. 이걸 설치하면 [VPN] → [OpenVPN]으로 가면 Client Export 탭이 생기는데, 여기서 Windows, Linux, Mac OS X, 심지어 Android, iOS용 인스톨러까지 플랫폼별로 바로 내려받을 수 있다. 스마트폰으로도 VPN에 붙을 수 있다는 거다.

그냥 config 파일만 주면 되는 거 아닌가 싶기도 한데, 실제로 VPN 에이전트와 키를 묶어서 하나의 인스톨러 패키지로 만들어 주는 거라 배포 받는 쪽에서 따로 설정할 게 없다. 사용자에게 전달하는 입장에선 훨씬 간편하다. 계정은 [System] → [User Manager]에서 만들고, 거기서 사용자 인증서도 같이 생성할 수 있다. 인증서 이름을 openvpn_certificate으로 지정하고 저장하면 이 계정으로 VPN 접속이 가능해진다.

접속이 완료되면 트레이 아이콘이 녹색으로 바뀌고, 외부로 나가는 IP가 VPN 서버의 IP로 바뀐다. whatismyipaddress.com 같은 곳에서 확인해보면 접속 전에는 117.로 시작하던 IP가 220.으로 시작하는 VPN 측 IP로 변경된다. 이미 pfSense 안쪽에 들어와 있는 것과 동일한 상태가 되는 것이다.

VPN 연결 이후 ACL 설계

사실 이게 읽으면서 가장 중요하다고 느낀 부분이다. OpenVPN 설정 위저드가 자동으로 생성해주는 룰이 하나 있는데, 내용을 보면 Source도 any, Destination도 any, Protocol도 IPv4 전체로 뚫려 있다. VPN에 접속하기만 하면 모든 포트와 모든 대역에 접근할 수 있는 상태인 거다.

오피스 내부에서는 못 들어가는 네트워크인데, 밖에서 VPN으로 연결하면 오히려 다 들어갈 수 있는 아이러니한 상황이 벌어진다. 이걸 고치려면 OpenVPN 탭의 방화벽 룰을 직접 설계해야 한다.

책에서는 VPN 엔지니어 대역을 VPN_ENG라는 Alias로 만들어서 10.50.1.0/24를 묶고, RFC1918 사설 대역 전체를 Block하는 룰을 먼저 걸어둔 뒤, VPN_ENG 소스에서 VLAN10 웹서버 대역, VLAN30 인트라넷 대역만 허용하는 룰을 순서대로 추가한다. 룰 순서가 중요한데, Block 룰을 위에 두고 Pass 룰을 아래에 두면 전체가 막혀버리므로, Pass 룰을 먼저 두고 맨 아래에 Block을 두는 식으로 구성한다.

최종 결과로 VLAN30 인트라넷과 VLAN10 웹서버 대역은 VPN으로 접근 가능하지만, 오피스 영역(VLAN20)이나 DB 영역(VLAN40)은 VPN으로도 접근이 불가능해진다. 엔지니어 계정이라도 자기가 필요한 서버 대역에만 들어갈 수 있게 제한되는 거다.

VPN 계정 관리를 절대 느슨하게 두면 안 된다

책 마지막 정리 부분에서 저자가 직접 경험한 사례를 언급하는데, 보안 점검을 통해 삭제한 VPN 계정이 1000개가 넘었다는 내용이 나온다. 만들어지기만 하고 삭제가 한 번도 안 된 계정들이 쌓인 결과다.

근데 이게 실제로 꽤 흔한 문제다. 일반 직원이 임시로 파일 서버 접근을 위해 발급받거나, 협력업체 외부인이 임시 접근하거나, 퇴사자 계정이 정리 안 된 채 남아있거나. AD(Active Directory)로 계정이 일괄 관리된다면 그나마 낫지만, 로컬 계정으로 VPN만 따로 운영하면 관리 정책이 없는 이상 좀비 계정이 쌓이게 된다.

그래서 VPN을 발급할 때는 반드시 언제부터 언제까지 쓸 건지 기간을 설정하고, 신청 목적도 함께 받아야 한다. 접근 가능한 영역에 맞는 ACL 룰을 계정마다 적용하고, 필요 없어진 계정은 즉시 삭제하는 프로세스가 있어야 한다. VPN 서버를 구성하는 것보다 이쪽이 훨씬 더 손이 많이 가는 일이지만, 운영 측면에서 가장 신경 써야 할 부분이다.