1. 방화벽(Firewall) 이해
2026. 1. 12. 21:25
네트워크 보안 (1/5)

초보 보안 관리자를 위한 방화벽(Firewall) 이해 — ‘정책’과 ‘로그’부터 잡기

방화벽은 단순히 ‘막는 장비’가 아니라, 보안 운영의 기준선(Policy)과 증거(Log)를 만드는 곳입니다.

이 글의 목표
방화벽을 ‘한 장비’가 아니라 정책(Policy)과 로그(Log) 중심의 운영 체계로 이해하실 수 있도록 정리합니다. 초보 운영자 기준으로, 무엇을 보고(가시성) 무엇을 통제하는지(차단/허용)를 중심으로 설명드립니다.

1) 방화벽은 정확히 무엇을 하나요?

방화벽은 서로 다른 보안 수준(외부/내부, 사용자망/서버망, DMZ 등)을 가진 구간 사이에서 트래픽을 “통과(Allow) 또는 차단(Deny)”하는 장치(또는 소프트웨어)입니다. 핵심은 “장비”가 아니라 정책입니다.

  • 정책 결정: 출발지/목적지/서비스(포트)/애플리케이션/사용자 기준으로 허용·차단
  • 상태(State) 추적: 세션을 기억하여 정상 응답 트래픽을 안전하게 통과
  • NAT: 사설/공인 주소 변환(서비스 공개, 인터넷 접속 등)
  • 로그: 누가/언제/무엇을/왜 차단(또는 허용)됐는지 증거를 남김
 
방화벽의 기본 역할(정책/상태기반 검사/NAT/로그)을 한 장으로 정리

2) 초보 운영자가 ‘로그에서’ 가장 먼저 봐야 하는 것

방화벽 로그는 처음엔 너무 많습니다. 그래서 우선순위를 정해 보시는 게 중요합니다.

  • 차단(Deny) Top: “어디에서(소스) / 무엇을(서비스) / 어디로(목적지)”가 반복되는지
  • 비정상 급증: 특정 시간대에 세션/차단 건수가 급증(스캔, 오탐, 장애 전조)
  • 내부→외부(유출 관점): 평소 없던 목적지/포트로 대량 트래픽이 나가는지
  • 정책 변경 영향: 변경 직후 정상 트래픽 차단/지연이 생겼는지
운영 팁
‘정책을 잘 짠다’는 말은, 결국 로그가 해석 가능한 형태로 남도록 만드는 것과 같습니다. 예외 규칙은 반드시 근거/요청자/만료일을 함께 남겨 두시면 운영 난이도가 크게 내려갑니다.

3) 정책 설계의 기본 원칙(실무형)

  • 기본 차단(Default Deny) + 필요한 것만 허용(Allow-list)
  • 구간(Zone) 분리: 사용자/서버/DMZ/관리망 등 “의미 있는 경계”를 먼저 만들기
  • 최소 권한: 목적지/포트/시간/사용자를 최소로 좁히기
  • 룰 단순화: 유사 규칙은 객체화/그룹화(운영 실수 확률 감소)
  • 변경 관리: 사전 영향 분석 + 롤백(원복) 계획 + 변경 후 모니터링

4) (예시) “읽을 수 있는” 정책 한 줄

※ 아래는 개념 이해를 위한 예시이며, 실제 값은 환경에 맞게 조정하셔야 합니다.

# 예시: ‘사용자망 → 인터넷’ 웹 접속 허용(가독성 위주)
policy "USR_to_INTERNET_WEB"
  src_zone   "USR"
  dst_zone   "INTERNET"
  src_addr   "USR_SUBNETS"
  dst_addr   "ALL"
  service    "HTTPS" "HTTP"
  schedule   "always"
  action     "accept"
  log        "all_sessions"

5) 방화벽만으로는 부족한 이유

  • 앱 레벨 공격(예: SQLi/XSS)는 단순 포트 차단만으로는 어려울 수 있습니다 → WAF
  • 정상 포트(443) 악용은 로그만으로 한계가 있습니다 → IDS/IPS, NDR, EDR
  • 내부 동서 트래픽은 경계 방화벽만으로 가시성이 약할 수 있습니다 → 세그멘테이션/NDR

마무리 체크리스트

  • 정책은 ‘구간(Zone)’ 기준으로 설계되어 있나요?
  • 기본 차단(Default Deny) 원칙이 지켜지고 있나요?
  • 예외 규칙에 근거/요청자/만료일이 남아 있나요?
  • 정책 변경 전·후로 (차단 Top / 세션 급증 / 장애 징후) 모니터링을 하시나요?
  • 로그는 중앙 수집(SIEM)으로 이어지고 있나요?

참고 레퍼런스