대상 OS: Rocky Linux 9

firewalld를 쓰면서 사고가 나는 대표 이유는 “규칙을 추가했다/삭제했다”가 아니라, 그 규칙이 어떤 zone 문맥에 적용되는지를 놓치기 때문입니다. zone을 이해하지 못하면 다음 두 가지가 동시에 발생합니다.

  • 열었다고 생각했는데 안 열림(서비스 장애)
  • 닫았다고 생각했는데 열려 있음(보안 사고)

1) zone을 빠르게 이해하기(핵심만)

  • zone: 인터페이스/소스 대역에 매핑되는 “정책 묶음”
  • default zone: 명시적 할당이 없는 인터페이스에 적용될 수 있는 기본 문맥
  • runtime vs permanent: 즉시 적용(재부팅/리로드 시 사라질 수 있음) vs 영구 적용

2) 현재 상태를 먼저 ‘사실 기반’으로 확인

# 활성 zone(인터페이스가 어떤 zone에 붙어 있는지)
sudo firewall-cmd --get-active-zones

# 기본 zone
sudo firewall-cmd --get-default-zone

# zone별 상세(예: public)
sudo firewall-cmd --zone=public --list-all

3) zone 개념을 모르면 생기는 사고 3가지

사고 1) permanent에만 추가하고 reload를 안 해서 “지금은 안 열림”

운영자가 영구 규칙만 추가해놓고 즉시 반영이 안 된 상태에서 장애로 이어지는 케이스입니다.

# 영구 규칙 추가(이 시점에서는 runtime에 반영 안 됨)
sudo firewall-cmd --permanent --zone=public --add-service=https

# 반드시 반영
sudo firewall-cmd --reload

# 확인
sudo firewall-cmd --zone=public --list-services

사고 2) 규칙을 public에 열었는데, 실제 인터페이스는 다른 zone에 붙어 있음

가장 흔한 유형입니다. 예를 들어 NIC가 trusted나 internal에 붙어 있는데 public에만 규칙을 추가하면, 열리지 않습니다(또는 반대로 예상보다 과하게 열릴 수도 있습니다).

# 인터페이스가 실제로 어느 zone인지 확인
sudo firewall-cmd --get-active-zones

# 예: eth0가 public이 아니라 internal에 붙어 있다면
sudo firewall-cmd --zone=internal --add-service=https
sudo firewall-cmd --permanent --zone=internal --add-service=https

사고 3) 테스트/긴급 대응으로 runtime 규칙만 열어두고 “영구로 닫았다고 착각”

긴급 대응 때 runtime으로 열어두고, 나중에 permanent만 정리하면서 “이제 닫혔다”고 믿는 케이스가 있습니다. 또는 그 반대로 runtime만 닫고 permanent에 구멍이 남아 있는 경우도 있습니다.

# runtime과 permanent를 모두 확인(동일 zone 기준)
sudo firewall-cmd --zone=public --list-all
sudo firewall-cmd --permanent --zone=public --list-all

# 필요 시 runtime 쪽도 명시적으로 제거 후 reload
sudo firewall-cmd --zone=public --remove-port=8443/tcp
sudo firewall-cmd --permanent --zone=public --remove-port=8443/tcp
sudo firewall-cmd --reload

4) 안전한 운영 절차(권장 루틴)

  1. 변경 전: 활성 zone/인터페이스 매핑을 먼저 기록

    sudo firewall-cmd --get-active-zones
sudo firewall-cmd --get-default-zone


  2. 추가/삭제는 “zone을 명시”하고, runtime+permanent를 같이 맞춤

    # 예: public에 443 허용
sudo firewall-cmd --zone=public --add-service=https
sudo firewall-cmd --permanent --zone=public --add-service=https


  3. reload 후 재확인

    sudo firewall-cmd --reload
sudo firewall-cmd --zone=public --list-all
sudo firewall-cmd --permanent --zone=public --list-all


5) 사례(현장에서 자주 겪는 상황)

  • “클라우드 보안그룹에서는 열었는데 서버에서만 접속이 안 됨”: firewalld에서 zone을 잘못 보고 다른 zone에 규칙을 추가한 경우가 많습니다(활성 zone부터 확인).
  • “점검한다고 잠깐 열어둔 포트가 몇 주 뒤에도 열려 있었음”: runtime/permanent 불일치 + 변경 이력 관리 부재. 변경 전후 스냅샷을 남기고, permanent/runtme 동기화 루틴을 정합니다.
  • “서버 두 대가 똑같이 설정했는데 한 대만 동작이 다름”: NIC 매핑(zone 할당)이 다르거나 default zone이 다를 수 있습니다.

6) 트러블슈팅(증상→원인→해결)

  • 증상: 서비스를 열었는데 외부에서 접속 불가
    원인: 규칙을 추가한 zone과 인터페이스가 붙은 zone이 다름
    해결: firewall-cmd --get-active-zones로 인터페이스 zone 확인 후 해당 zone에 규칙 적용
  • 증상: 재부팅 후 규칙이 사라짐
    원인: runtime에만 변경함(permanent 미반영)
    해결: --permanent로 동일 변경 적용 후 --reload
  • 증상: 목록에는 규칙이 있는데도 차단되는 것처럼 보임
    원인: 다른 보안 계층(클라우드 SG/NACL, 라우팅, 서비스 리슨 주소) 문제
    해결: 로컬 리슨 확인(ss -lntp), 클라우드 방화벽 확인, zone/소스 제한 규칙 확인

root.so · Linux/Security 운영 노트

firewalld 운영의 핵심은 “무엇을 열었나”보다 “어떤 zone 문맥에 적용됐나”입니다. 활성 zone/인터페이스 매핑부터 확인하는 습관이 사고를 줄입니다.