015. Linux 서버 보안 — firewalld zone 설계와 점검

changseop lee·3일 전

시스템 보안 · 취약점 › A. Linux 서버 보안 설정 · 15/50편 (전체 015/450)
학습 단계: 2단계 · 설정 및 점검
실습 표기: 이 글의 명령어·출력·로그는 로컬 VMware 테스트 VM(Rocky Linux 9 / Ubuntu 22.04) 기준의 「실습 예시」이며, IP·계정·호스트명은 가상의 값입니다.

선행 학습

1. 개념

firewalld는 zone(신뢰 수준별 규칙 묶음) 단위로 정책을 관리합니다. 패킷이 들어오면 먼저 "어느 zone에 속하는가"를 결정하고, 그 zone의 규칙을 적용합니다.

들어온 패킷
   ↓
① 출발지 IP가 zone의 source에 등록돼 있나?  → 있으면 그 zone
② 아니면, 들어온 인터페이스가 속한 zone       → 예: ens160 → public
   ↓
zone 규칙 적용 (services / ports / rich rules)
   ↓
허용 or 거부(LogDenied 설정 시 커널 로그 기록)

이 구조를 이용하면 trusted 대신 관리 전용 zone을 만들어 SSH는 관리망에서만, 웹은 모든 곳에서 허용하는 설계가 가능합니다.

2. 왜 중요한가

  • 방화벽 규칙이 "모두 허용"에 가까우면 서버 내부의 리스닝 포트가 그대로 외부에 노출됩니다.
  • 공격자는 영구 규칙(permanent)을 건드리지 않고 런타임 규칙만 추가해 재부팅 전까지만 포트를 여는 방식으로 흔적을 줄일 수 있습니다.
  • 기본 설정은 차단 패킷을 로그로 남기지 않으므로(LogDenied=off), 탐지에 쓰려면 별도 설정이 필요합니다.

3. 핵심 명령어 / 설정

명령용도
firewall-cmd --get-active-zones활성 zone과 인터페이스/source
firewall-cmd --list-all --zone=publiczone의 허용 서비스·포트
firewall-cmd --list-all --permanent --zone=public영구 설정(런타임과 비교)
firewall-cmd --get-log-denied / --set-log-denied=all차단 로그 설정
firewall-cmd --direct --get-all-rulesdirect 규칙(우회 경로) 확인

4. 실습 (실습 예시)

# 1) 관리 zone 생성: 관리망에서만 SSH 허용
sudo firewall-cmd --permanent --new-zone=mgmt
sudo firewall-cmd --permanent --zone=mgmt --add-source=192.168.56.0/28
sudo firewall-cmd --permanent --zone=mgmt --add-service=ssh
# 2) public에서는 SSH 제거, 웹만 허용
sudo firewall-cmd --permanent --zone=public --remove-service=ssh
sudo firewall-cmd --permanent --zone=public --add-service=http
# 3) 차단 로그 활성화 후 적용
sudo firewall-cmd --set-log-denied=unicast
sudo firewall-cmd --reload

# 4) 런타임 vs 영구 설정 비교 (차이가 있으면 누군가 런타임만 바꾼 것)
diff <(sudo firewall-cmd --list-all --zone=public) <(sudo firewall-cmd --list-all --zone=public --permanent)

실습은 반드시 VMware 콘솔에 접속한 상태에서 진행합니다. SSH 세션에서 SSH 허용을 지우면 접속이 끊길 수 있습니다.

5. 정상 상태

$ sudo firewall-cmd --get-active-zones
mgmt
  sources: 192.168.56.0/28
public
  interfaces: ens160
$ sudo firewall-cmd --list-all --zone=public | grep -E 'services|ports'
  services: http
  ports:

런타임과 영구 설정의 diff 결과가 없어야 정상입니다.

6. 이상 상태

$ diff <(firewall-cmd --list-all --zone=public) <(firewall-cmd --list-all --zone=public --permanent)
<   ports: 4444/tcp
---
>   ports:
  • 런타임에만 4444/tcp가 열려 있음 → 재부팅/reload 시 사라지는 일시적 개방
  • 014편의 신규 리스너 점검과 함께 보면 포트를 연 프로세스까지 연결할 수 있습니다.

7. 로그 분석 (분석 방법)

LogDenied를 켜면 차단 패킷이 커널 로그로 남고, firewalld 설정 변경은 auditd·journal로 추적합니다(가상의 예시 로그).

Oct  1 09:15:02 rocky9-web01 kernel: filter_IN_public_REJECT: IN=ens160 OUT= MAC=00:0c:29:aa:bb:cc:00:0c:29:11:22:33:08:00 SRC=192.168.56.77 DST=192.168.56.10 LEN=60 TOS=0x00 PREC=0x00 TTL=64 ID=40121 DF PROTO=TCP SPT=51544 DPT=22 WINDOW=64240 RES=0x00 SYN URGP=0
Oct  1 09:20:31 rocky9-web01 sudo[7301]:  admin1 : TTY=pts/0 ; PWD=/root ; USER=root ; COMMAND=/usr/bin/firewall-cmd --add-port=4444/tcp
필드의미
filter_IN_public_REJECTpublic zone 인바운드 거부
SRC/DST/DPT=22외부(비관리망)에서 SSH 시도 → zone 설계대로 차단됨
SYN연결 시작 패킷
--add-port (permanent 없음)런타임 전용 개방 명령

차단 로그 형식은 iptables LOG와 같아 네트워크 영역의 271. Firewall Logging에서 다룬 분석 방법을 그대로 적용할 수 있습니다.

8. SOC 관제 포인트

  • firewall-cmd의 --add-*, --remove-*, --set-default-zone, --direct 실행은 모두 수집합니다.
  • 런타임/영구 설정 불일치를 주기적으로 점검합니다.
  • 차단 로그는 양이 많으므로 SIEM에서 출발지별 집계로 보고, 특정 포트(22, 3389, 445 등) 집중 여부를 봅니다.

9. 탐지 규칙

<rule id="100220" level="9">
  <if_sid>5402</if_sid>
  <regex type="pcre2">COMMAND=\S*firewall-cmd .*--add-port|COMMAND=\S*firewall-cmd .*--direct|COMMAND=\S*firewall-cmd .*--add-rich-rule</regex>
  <description>방화벽 허용 규칙 추가 명령 실행</description>
</rule>

Kibana에서 차단 로그 집계: message : "filter_IN_public_REJECT" 후 시각화에서 SRC 기준 Top N

10. 대응 방법

  1. 초기 확인 — 런타임/영구 설정 차이와 최근 firewall-cmd 실행 이력을 확인합니다.
  2. 범위 확인 — 열린 포트로 실제 연결이 있었는지 방화벽·연결 로그(ss -tn)를 확인합니다.
  3. 증거 확보 — firewall-cmd --list-all-zones 결과와 sudo/journal 로그를 보존합니다.
  4. 차단/조치 — 비인가 규칙을 제거(--remove-port)하고 --reload로 영구 설정 기준으로 복원합니다.
  5. 재발 방지 — 방화벽 설정을 기준선에 포함하고 허용 규칙 추가 명령을 탐지합니다.

11. 핵심 정리

구분핵심 내용
zone 결정 순서source 매칭 → 인터페이스 zone
설계 패턴관리 zone(source=관리망) + public(서비스만)
런타임 vs 영구불일치 = 일시적 개방 의심
차단 로그--set-log-denied, kernel: filterIN_REJECT
면접 포인트"permanent 없이 추가된 규칙은 재부팅 시 사라지는 흔적 최소화 기법"

12. 다음 편 예고

다음 편 016. Linux 서버 보안 — nftables 규칙셋 점검과 차단 로깅 에서는 firewalld 아래에서 실제로 동작하는 nftables 규칙셋 점검과 차단 로깅을 다룹니다.


이전 편: 014. Linux 서버 보안 — 열린 포트 기준선 비교 점검
📚 시리즈 전체 보기: 시스템 보안 · 취약점

profile
코드에 숨겨진 위협을 읽고 AI로 보안의 미래를 설계합니다. 프론트엔드 개발 경험을 자산 삼아 더 견고하고 지능적인 보안 운영 시스템을 구축해 나가는 과정을 기록합니다

0개의 댓글