적용된 방화벽 설계: 이론에서 실제 운영까지

방화벽은 종종 체크리스트로만 취급된다: 배포하고 규칙을 작성하고 넘어가기. 그러나 적용된 방화벽 설계는 그 자체로 완전한 분야다—네트워크 분할이 실제로 공격자를 막는지, 아니면 허위 안정감만 주는지를 결정하는 분야다. 이 글은 잘 구축된 방화벽 배포와 임시방편 규칙 모음을 구분하는 실제 결정들을 다룬다.

규칙이 아닌 구역부터 시작하기

단 하나의 ACL을 작성하기 전에 신뢰 구역을 정의하자. 일반적인 엔터프라이즈 레이아웃은 인터넷 대면 DMZ 호스트, 내부 사용자 네트워크, 서버/데이터 계층, 관리/OOB 네트워크를 분리한다. 각 구역은 서로 다른 신뢰 수준을 나타내야 하고, 구역 간 트래픽은 기본값이 아니라 정당화가 필요한 예외여야 한다.

무엇이 실제로 통신해야 하는지 매핑하자. 이 트래픽 흐름 인벤토리는 지루하지만 나머지 모든 것이 기초하는 토대다. 이를 건너뛰면 "서브넷 간 모든 허용" 규칙이 과도하게 허용되어 분할의 목적을 완전히 무너뜨린다.

기본 거부는 필수적이다

모든 인터페이스, 모든 구역 쌍은 암시적 또는 명시적 거부로 끝나야 한다. 규칙은 열린 상태에 대한 감소 예외가 아니라 폐쇄 상태에 대한 추가 예외여야 한다. 당연해 보이지만 감사에서는 급속한 배포나 절대 제거되지 않은 "임시" 문제 해결 변경으로 인해 남겨진 허용 캐치올 규칙을 가진 방화벽을 자주 발견한다.

기본 거부가 뭔가를 깨뜨릴 때, 그건 실제로 유용한 신호다—문서화되지 않은 종속성을 발견했다는 뜻이고, 이는 자동으로 허용되기보다는 명시적으로 모델화되어야 한다.

규칙 순서와 구체성

대부분의 방화벽 엔진은 규칙을 위에서 아래로 평가하고 첫 번째 일치에서 멈춘다. 이는 순서를 사후 고려사항이 아닌 설계 결정으로 만든다. 구체적인 규칙(단일 호스트, 단일 포트)은 일반적으로 광범위한 규칙(서브넷 범위, 포트 범위)보다 먼저 나와야 한다. 일반적인 오류는 광범위한 허용 규칙을 목록 앞부분에 배치하는 것인데, 이는 그 아래의 더 제한적인 규칙을 조용히 감춘다—그 규칙들은 종이에는 존재하지만 실제로는 발동되지 않는다.

음영처리되고 중복된 규칙을 주기적으로 감사하자. 규칙 히트 수를 시각화하는 도구는 여기서 매우 귀중하다: 의미 있는 기간에 0개의 히트를 가진 규칙은 무용지물이거나, 더 나쁜 경우 트래픽이 예상하지 못한 경로를 통해 흐르고 있다는 증거다.

상태 추적 검사와 그 한계

최신 방화벽은 연결 상태를 추적하므로 초기화 방향에서만 규칙을 작성하고 엔진이 반환 트래픽을 허용하도록 신뢰할 수 있다. 이는 상태 비저장 패킷 필터링보다 큰 단순화지만, 애플리케이션 계층 인식의 대체재가 아니다. 아웃바운드 TCP/443을 허용하는 상태 추적 방화벽은 그 트래픽이 정당한 HTTPS인지 아니면 동일 포트를 통해 터널링된 C2 채널인지 알거나 신경 쓰지 않는다. 가능하면 포트 번호를 의도의 프록시로 삼기보다는 방화벽 시행을 애플리케이션 계층 가시성과 짝을 맞추자—프록시, 정책이 허용하는 경우 TLS 검사, 또는 NGFW 애플리케이션 식별.

이그레스 필터링도 동등한 관심이 필요하다

조직은 인바운드 규칙에 집중하고 아웃바운드를 무시한다. 이는 사건 대응 관점에서 역순이다: 공격자가 발판을 잡은 후, 이그레스 제어가 데이터를 유출할 수 있는지 또는 인프라에 전화할 수 있는지를 결정하는 것이다. 구역별 명시적 이그레스 정책을 정의하자—서버는 거의 제한 없는 아웃바운드 인터넷 접근이 필요하지 않으며, 워크스테이션은 거의 임의 외부 IP의 임의 포트에 대한 연결을 시작할 필요가 없다. 제한적인 이그레스는 모든 것을 막지는 못하지만 사후 악용 활동의 비용을 높이고 비정상 트래픽이 플래그될 가능성을 높인다.

변경 관리와 드리프트

방화벽 규칙세트는 시간이 지남에 따라 쓸모없는 것이 쌓인다: 수년 전 끝난 프로젝트를 위해 추가된 규칙, 영구적이 된 임시 예외, 그리고 아무도 목적을 기억하지 못하는 규칙. 방화벽 구성을 코드처럼 취급하자—버전 제어, 피어 검토, 그리고 모든 규칙에 대한 문서화된 비즈니스 정당화와 연결되어 있어야 한다. 오래된 항목을 제거하기 위해 정기적인 검토를 예약하자. 천 개의 문서화되지 않은 규칙을 가진 방화벽은 더 작고 잘 이해되는 규칙세트보다 실제 보안이 적다. 왜냐하면 아무도 그것이 실제로 무엇을 허용하는지 추론할 수 없기 때문이다.

로깅 및 상관관계

트래픽을 조용히 차단하는 방화벽은 절반만 유용하다. 거부되고 관심 있는 허용된 트래픽이 로깅되고 충분한 컨텍스트(구역, 규칙 ID, 출발지/목적지, 프로토콜)와 함께 SIEM 또는 로그 파이프라인으로 전송되는지 확인하자. 사건 대응 중 방화벽 로그는 종종 측면 이동 또는 유출 시도의 타임라인을 수립하는 가장 빠른 방법이다—하지만 보존과 충실성이 미리 구성된 경우에만.

마무리

적용된 방화벽 설계는 올바른 공급업체를 선택하거나 최신 NGFW 기능 세트에 관한 것이 아니다—규칙 있는 구역 모델링, 기본 거부 시행, 신중한 규칙 위생, 그리고 이그레스를 인그레스와 같은 심각성으로 취급하는 것에 관한 것이다. 기초를 올바르게 하면 고급 기능은 아키텍처의 대체재가 아니라 군사력 배수가 된다.

네트워크 분할, 로그 상관관계, 그리고 블루 팀 기초에 대한 더 많은 정보를 보려면 Korra Studio의 DEFENSE_GRID 라이브러리에서 관련 세그먼트를 탐색하자.