네트워크에서 들려주는 무서운 이야기

핼러윈이 코앞으로 다가온 지금, 실제로 있었던 방화벽 정책 공포 이야기를 소개합니다. (분위기를 살리고 싶다면 무섭고 쉰 목소리로 경고하는 장면을 상상해 보십시오… 원하신다면 모건 프리먼의 목소리도 좋습니다.)

세일즈 엔지니어로서 저는 많은 시간을 제품 데모를 진행하고 보안 엔지니어, 컴플라이언스 담당자, DevOps 매니저, CISO와 방화벽 및 네트워크 보안에 대해 이야기하며 보냅니다. 현장에서 일하는 분들의 이야기는 때로는 믿기 어렵고, 때로는 정말 오싹합니다. 다음은 모든 방화벽 엔지니어를 밤새 잠 못 이루게 할 최근 고객 사례입니다.

상황:
이 기업은 최근 “제로 트러스트” 철학을 도입하고 그 목표에 다가가기 위해 상당한 시간을 투자했습니다. 지난 1년 동안 이 기업은 방화벽 정책 정리에 집중하며, 비즈니스 요건에 딱 맞는 규칙만 작성했습니다. 그 이상은 없었고, 접근이 필요한 특정 IP와 네트워크만 허용했습니다. 순조롭게 진행되던 중, 한 엔지니어가 정책 중간에 파묻혀 있던 악명 높은 “Any – Any – Any – Accept” 규칙을 발견하는 끔찍한 일이 벌어졌습니다.

담당자들은 이 규칙이 왜 존재하는지 파악하기 위해 분주히 움직였습니다. 결국 주니어 네트워크 엔지니어가 무언가를 작동시키려다 이 규칙을 만든 것으로 밝혀졌습니다. 이 규칙 하나가 제로 트러스트 목표를 향한 모든 진전을 무력화하고 네트워크를 엄청난 위험에 노출시켰습니다.

당연히 이 규칙은 제거해야 했습니다. 그러나 이 규칙은 최소 6개월 동안 탐지되지 않은 채 정책에 남아 있었고, 분명 비즈니스 크리티컬 트래픽을 허용하고 있었습니다. 실제로 로그 트래픽을 보면 이 규칙은 매우 빈번하게 사용되고 있었습니다. 물론 비즈니스 크리티컬 트래픽뿐 아니라 악성 트래픽도 함께 허용했을 가능성이 높았습니다. 이 문제를 신속히 해결해야 했습니다.

먼저 네트워크 담당자들과 회의를 열어 어떤 트래픽이 오갈지 추정하고, 네트워크를 잘 아는 사람들이 해당 규칙을 사용할 것으로 짐작한 핵심 애플리케이션과 트래픽을 함께 정리했습니다. 그러나 결국 어쩔 수 없이 규칙을 제거하고 누가 문제를 제기하는지 지켜보기로 결정했습니다.

그래서 모든 사업부의 관리자에게 이 실수를 알렸습니다. 민망함을 무릅쓰고, 상담원이 대기하는 “핫라인”을 개설하겠다고 안내했으며, 결국 직원들이 모든 비즈니스 크리티컬 기능을 테스트하도록 해 제품과 애플리케이션, 업무 수행에 필요한 접근 권한, 고객·파트너·공급업체와의 거래에 필요한 모든 기능이 재설정 전까지만 중단되도록 했습니다. 실제로 일부 기능이 중단되었고, 문제를 해결할 새 규칙을 만들 준비도 되어 있었지만, 그야말로 악몽이었습니다.

—

위에서 설명한 것과 같은 악몽 같은 상황이 없더라도, FireMon은 방화벽 정책 정리를 지원해 업무를 한결 수월하게 만들어 드립니다. FireMon이 위와 같은 상황을 예방할 수 있는 몇 가지 방법을 소개합니다. 그리고 정책에서 지나치게 허용적인 규칙을 발견하신다면, 아래 6번에서 고통 없는 해결책을 확인해 보십시오.

1) 컴플라이언스 알림 및 보고:
이처럼 지나치게 허용적인 규칙이 적용되면 즉시 팀에 알렸을 것입니다. 규칙의 허용 범위를 “60,000개가 넘는 목적지에 대한 접근을 허용하는 규칙” 또는 “출발지가 /16 네트워크보다 큰 규칙”과 같이 원하는 수준으로 설정할 수 있습니다.

2) 변경 알림:
방화벽 벤더가 무엇이든 이 규칙은 정규화된 화면에 표시되어 추가된 사실이 명확히 드러납니다. 따라서 “몰래 끼워 넣는” 것이 불가능합니다. 일부 엔지니어와 관리자는 변경이 발생할 때마다 정책 변경 보고서를 자동으로 이메일로 받거나, 30일간의 모든 변경 사항 스냅샷을 받아 봅니다.

3) 자동화 도구인 FireMon Policy Planner가 도입되어 있었다면, 이 위험한 규칙은 배포되기도 전에 차단되었을 것입니다. “사전 변경 분석”을 통해 단 한 패킷의 트래픽도 통과하기 전에, 프로덕션에 반영되기 전 단계에서 해당 규칙이 식별되고 플래그 처리되었을 것입니다. 컴플라이언스 담당자들이 FireMon을 선호하는 이유가 바로 여기에 있습니다. 필요에 따라 규칙 생성을 권고하는 데 그치지 않고, 샌드박스 환경처럼 규칙을 자동으로 배포하기 전에 컴플라이언스 알고리즘을 실행하기 때문입니다. 일부 고객은 오직 이 기능만을 위해 Policy Planner를 도입하고, API를 통해 활용합니다.

4) 변경 알림을 통해 누가 언제 어떤 변경을 했는지도 정확히 파악할 수 있습니다. 이 사례처럼 주니어 엔지니어가 변경한 경우, 관리자나 리더가 해당 사용자가 지난 한 주 동안, 적어도 한 달 동안 수행한 변경 사항을 신속히 필터링·정렬해 어떤 유형의 변경을 했는지 확인할 수 있었을 것입니다. 이는 컴플라이언스 팀이나 해당 사용자 본인도 확인할 수 있는 내용입니다.

5) 문서화 관점에서 FireMon은 “누가 요청했는가, 애플리케이션 소유자는 누구인가, 이 규칙은 마지막으로 언제 검토되었는가” 등에 대한 단일 진실 공급원 역할을 할 수 있습니다. 따라서 규칙 문서화 정보를 기준으로 규칙을 필터링하고 정렬하면 이 문제도 더 빠르게 발견할 수 있었을 것입니다.

6) 가장 좋은 내용을 마지막에 남겨 두었습니다. 지나치게 허용적인 규칙이 있다면, 예를 들어 전임자가 지금과 다른 더 “개방적이고 유연한 규칙 생성 방식”을 따랐다면, 이러한 규칙을 손쉽게 정리할 방법이 있습니다. 트래픽 플로우 분석을 사용하면 해당 규칙을 통과하는 모든 IP 주소를 확인해 any/any/any 규칙을 개별 플로우로 분해해 줍니다. 이 플로우를 내보내어 이를 기반으로 구체적인 규칙을 생성할 수 있습니다.