방화벽 룰 설계 (최소권한, 아웃바운드, 룰감사)

최소권한, 아웃바운드, 룰감사

서버를 처음 운영해본 분이라면 방화벽 설정을 한 번 해두고 나서 "이제 됐다"고 안심한 경험이 한 번쯤 있을 겁니다. 저도 그랬습니다. 처음 서버를 띄우고 방화벽 룰을 대충 잡아두었다가, 며칠 뒤 로그에서 수천 건의 공격 시도를 목격하고 나서야 제대로 공부하기 시작했습니다. 방화벽은 설치가 끝이 아니라 시작이라는 걸 그때 배웠습니다.

최소 권한 원칙, 말은 쉬운데 실제로는

일반적으로 방화벽 설계의 기본은 최소 권한(Least Privilege) 원칙이라고 알려져 있습니다. 여기서 최소 권한이란 서비스 운영에 꼭 필요한 포트와 프로토콜만 허용하고, 나머지는 전부 막아두는 방식을 말합니다. 이와 함께 기본 거부(Default Deny) 정책을 함께 적용합니다. 기본 거부란 명시적으로 허용된 트래픽만 통과시키고, 규칙에 없는 모든 통신은 자동으로 차단하는 설정입니다.

그런데 이게 말처럼 쉽지 않습니다. 제가 직접 써봤는데, 처음에는 "일단 다 열어두고 나중에 좁혀야지"라는 생각으로 시작하게 됩니다. 문제는 그 '나중에'가 잘 오지 않는다는 겁니다. 개발 편의를 위해 SSH 22번 포트를 전체 IP에 열어두었다가, 며칠 만에 무차별 대입 공격(Brute Force Attack)이 수천 건 쌓인 것을 확인했습니다. 무차별 대입 공격이란 공격자가 가능한 모든 비밀번호 조합을 자동으로 시도해 로그인을 뚫으려는 방식입니다. 다행히 서버가 직접 침해되지는 않았지만, 그날 이후로 SSH는 반드시 특정 IP, 즉 집 IP와 VPN 출구 IP에서만 허용하는 습관이 생겼습니다.

Anti-spoofing 룰도 놓치기 쉬운 부분입니다. 외부에서 내부 사설 대역인 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16을 출발지로 위장한 패킷을 차단하는 규칙입니다. 공격자가 내부 IP를 흉내 내어 신뢰된 구간인 것처럼 속이는 시도를 막는 장치인데, 이걸 설정하지 않은 방화벽이 생각보다 많습니다.

아웃바운드를 방치하면 생기는 일

많은 분들이 인바운드, 즉 외부에서 내부로 들어오는 트래픽 차단에만 집중하고 아웃바운드는 거의 신경 쓰지 않습니다. 저도 처음엔 그랬고, 솔직히 이건 예상 밖의 실수였습니다.

한 서버에서 웹쉘이 업로드된 것을 발견한 적이 있습니다. 웹쉘이란 공격자가 웹 서버에 심어두는 악성 스크립트로, 이를 통해 서버를 원격에서 조종할 수 있게 됩니다. 당시 공격자는 리버스 쉘 연결을 시도했는데, 아웃바운드 정책에서 허용된 포트가 한정되어 있어서 연결이 실패한 흔적이 로그에 남아 있었습니다. 리버스 쉘이란 공격자 서버로 피해 서버가 먼저 연결을 시도하게 만드는 기법으로, 인바운드 차단만 있으면 막기 어렵습니다. 아웃바운드 제한이 실질적인 침해 확산을 막는다는 걸 그때 몸으로 실감했습니다.

아웃바운드에서 특히 챙겨야 할 부분은 DNS입니다. DNS 질의를 승인된 리졸버로만 제한하지 않으면 DNS 터널링 공격에 노출될 수 있습니다. DNS 터널링이란 DNS 프로토콜을 악용해 데이터를 외부로 유출하거나 C&C 서버와 통신하는 기법으로, 일반적인 트래픽으로 위장하기 때문에 탐지가 까다롭습니다. C&C란 Command and Control의 약자로, 공격자가 감염된 시스템을 원격으로 제어하는 서버를 뜻합니다.

아웃바운드 정책 설계 시 챙겨야 할 핵심 포인트를 정리하면 다음과 같습니다.

• DNS 질의는 사전에 지정된 승인 리졸버로만 허용하고 나머지는 차단
• 허용 목적지와 프로토콜을 최소화하고 불필요한 외부 IP 대역은 명시적으로 차단
• 내부 서버가 외부로 연결할 때 사용하는 포트 목록을 정기적으로 검토

룰 문서화 없이는 감사도 없다

제가 경험상 이건 좀 다릅니다. 방화벽 룰 자체보다 문서화가 더 까다롭습니다. iptables나 nftables로 룰을 관리할 때 가장 골치 아픈 건 "이 룰이 왜 있는지 모르겠다"는 상황입니다. 트러블슈팅 목적으로 임시로 만든 permit any any 룰, 즉 모든 출발지와 목적지를 전부 허용하는 룰을 삭제하지 않고 그냥 두면, 나머지 정책이 전부 무력화됩니다. 이런 사례가 실제 운영 환경에서 빈번하게 발생합니다.

섀도 룰(Shadowed Rules) 문제도 심각합니다. 섀도 룰이란 앞에 위치한 룰이 이미 트래픽을 처리해버려서 뒤에 있는 룰이 실제로는 절대 실행되지 않는 규칙을 말합니다. 2025년 한 핀테크 기업의 방화벽 감사에서 전체 룰의 37%가 섀도 룰이었고, 22%는 6개월간 단 한 건의 패킷도 매칭하지 않은 것으로 확인되었습니다(출처: SecureMyOrg). 사실상 쓰레기 룰이 전체의 절반 가까이 쌓여 있었던 셈입니다.

이런 문제를 예방하기 위해 저는 iptables와 nftables 룰 변경 사항을 반드시 주석과 함께 Git으로 버전 관리하는 방식을 도입했습니다. 누가, 언제, 어떤 목적으로 룰을 추가했는지 추적할 수 있어야 감사(audit)도 가능하고 필요할 때 롤백도 할 수 있기 때문입니다. Palo Alto Networks의 Panorama 같은 중앙 관리 솔루션을 사용하면 Policy Optimizer 기능을 통해 미사용 룰을 자동으로 탐지할 수 있다는 점도 나중에 배웠습니다. Panorama는 다수의 방화벽 장비를 단일 콘솔에서 통합 관리하는 중앙화 플랫폼으로, 룰 가시성을 높이는 데 효과적입니다(출처: Palo Alto Networks).

방화벽 룰, 정기 감사 없이는 의미 없다

방화벽을 한 번 설정하면 끝이라고 생각하는 분들이 많습니다. 일반적으로 방화벽은 한 번 세팅하면 알아서 작동한다고 알려져 있지만, 제 경험상 이 생각이 가장 위험합니다. 네트워크 환경은 계속 바뀌고, 새로운 서비스가 생길 때마다 룰이 하나씩 추가됩니다. 그렇게 쌓이다 보면 어느 순간 아무도 전체 그림을 파악하지 못하는 상태가 됩니다.

SSL/TLS 트래픽 미검사도 현대 환경에서는 심각한 맹점입니다. 암호화된 HTTPS나 SMTP over TLS 트래픽 안에 악성 페이로드가 숨어 있어도 기존 방화벽은 이를 그냥 통과시킵니다. 현대 차세대 방화벽(NGFW, Next-Generation Firewall)은 암호화 트래픽을 복호화해 IPS, 즉 침입 방지 시스템(Intrusion Prevention System)과 안티멀웨어 엔진이 내용을 검사할 수 있도록 지원합니다. 다만 뱅킹이나 의료처럼 개인정보 보호가 필요한 세션은 예외 목록으로 따로 관리해야 합니다.

또한 IP 기반 룰에만 의존하는 방식에도 한계가 있습니다. 공격자는 IP를 자주 바꾸거나, 이미 신뢰된 내부 기기를 먼저 침해한 뒤 그 기기를 발판으로 내부를 횡단합니다. 이 때문에 현재는 제로트러스트(Zero Trust) 모델이 주목받고 있습니다. 제로트러스트란 내부 네트워크라고 해서 무조건 신뢰하지 않고, 모든 접근 요청에 대해 사용자 ID, 디바이스 포스처(device posture), 즉 접속 기기의 보안 상태를 함께 검증하는 아키텍처를 말합니다.

최소한 분기에 한 번은 전체 룰을 검토하고, 사용되지 않는 룰은 과감하게 제거하는 것이 필요합니다. 규칙이 많다고 보안이 강한 게 아닙니다. 오히려 관리되지 않는 룰이 쌓일수록 보안의 구멍은 더 커집니다.

방화벽 정책은 작성하는 순간보다 유지하는 과정이 더 중요합니다. 룰 하나를 추가할 때 목적과 날짜를 기록하고, 정기적으로 미사용 룰을 제거하며, 아웃바운드까지 포함한 전방위 정책을 유지하는 것이 현실적으로 실천할 수 있는 최선입니다. 처음부터 완벽할 필요는 없지만, 방치하는 것만큼은 반드시 피해야 합니다. 지금 당장 자신의 방화벽 룰 목록을 한 번 열어보시길 권합니다. 마지막으로 검토한 게 언제인지 기억이 나지 않는다면, 그게 이미 신호입니다.

---

참고:

• Palo Alto Networks — Firewall Best Practices: https://www.paloaltonetworks.com/cyberpedia/firewall-best-practices
• SecureMyOrg — Common Firewall Rule Mistakes 2025: https://securemyorg.com/common-firewall-rule-mistakes-2025/
• NetworkersHome — Firewall Rules & Policies: https://www.networkershome.com/fundamentals/firewall-security/firewall-rules-policies-best-practices/
• LiquidWeb — Best Practices for Firewall Rules: https://www.liquidweb.com/blog/best-practices-for-firewall-rules/
• Microsoft Learn — Windows Firewall Rules: https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/windows-firewall/rules