📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 266편
이전 글: 265. Allow Policy · 다음 글: 267. Default Deny
1. 개념
Deny Policy(차단 정책) 는 조건에 맞는 트래픽을 통과시키지 않는 규칙입니다. Default Deny 환경(267. Default Deny)에서는 목록에 없는 트래픽이 자동으로 차단되는데, 그럼에도 명시적 차단 규칙을 따로 두는 이유가 있습니다. Drop과 Reject의 동작 차이와 장비별 표기는 04 영역 184. Allow와 Deny에서 다뤘습니다.
| 명시적 차단 규칙의 목적 | 위치 | 예 |
|---|---|---|
| 넓은 허용 안의 예외 제거 | 해당 허용 규칙 위 | 사용자망 → 인터넷 허용 중 SMB(445) 차단 |
| 알려진 위험 우선 차단 | 정책 최상단 | 위조 출발지, 악성 IP 목록 |
| 차단 증거 확보 | 정책 최하단 | any → any deny + log |
| 특정 행위 식별 | 해당 영역 | "DNS 직접 조회 차단" 같은 이름 있는 규칙 |
마지막 항목이 관제에 특히 중요합니다. 기본 차단은 모든 것을 한 이름으로 기록하지만, 이름 있는 차단 규칙은 로그만 보고도 "무엇을 시도했는가"를 알려 줍니다.
2. 동작 원리
차단 로그를 보면 먼저 어떤 종류의 차단인가를 구분해야 합니다.
차단 로그 1건
↓
[규칙 ID/이름 확인]
├─ 이름 있는 차단 규칙 → 규칙 목적에 해당하는 행위 시도 (의미 명확)
├─ 최하단 기본 차단 규칙 → 정책에 없는 통신 (탐색·설정 오류·신규 서비스)
└─ 규칙 없음(상태 불일치) → 세션 밖 패킷 (타임아웃·비대칭·스캔)
↓
[Drop인가 Reject인가] → 상대방이 받은 반응 추정Drop과 Reject는 상대방에게 보이는 결과가 다르고, 그래서 상대방의 다음 행동도 달라집니다.
| 구분 | 상대방이 받는 것 | 상대방의 반응 | 로그에 남는 흔적 |
|---|---|---|---|
| Drop | 아무 응답 없음 | 타임아웃까지 대기, SYN 재전송 | 같은 5-tuple 차단이 몇 초 간격으로 반복 |
| Reject | TCP RST 또는 ICMP 오류 | 즉시 실패 인지 | 1건으로 끝나는 경향 |
외부를 향한 인터페이스는 보통 Drop을, 내부 사용자 대역은 빠른 실패를 위해 Reject를 쓰는 경우가 많습니다.
3. 주요 특징
- 차단은 시도의 증거이지 실패의 증거는 아닙니다. 차단 로그가 있어도, 같은 공격자가 다른 경로(허용된 포트, 다른 목적지)로 성공했을 수 있습니다.
- 차단 규칙은 가려질 수 있습니다. 넓은 허용 규칙 아래에 둔 차단 규칙은 적용되지 않습니다(256. Firewall Rule).
- Reject는 정보를 노출합니다. RST·ICMP 응답은 "여기에 방화벽이 있고 이 포트는 거부된다"는 사실을 알려 줍니다. TCP RST로 거부하면 포트 스캔 결과가 closed로, 응답 없는 Drop은 filtered로 보입니다(ICMP 관리 금지 응답은 보통 filtered로 분류).
- 차단 로그의 양 관리가 필요합니다. 외부 기본 차단은 로그 양이 매우 많아 속도 제한이나 요약 기록을 쓰는데, 이 경우 모든 시도가 기록되지는 않습니다.
4. 예시
이름 있는 차단 규칙과 Drop·Reject를 구분하는 nftables 실습 예시입니다(Rocky/Ubuntu 공통, 값은 환경마다 다름).
# 실습 예시 (inet fw 테이블 forward 체인 일부, 사용자망 ens37 → 인터넷 ens33)
iifname "ens37" oifname "ens33" tcp dport 445 counter log prefix "FW-DENY-SMB-OUT " reject with tcp reset
iifname "ens37" oifname "ens33" udp dport 53 ip daddr != 10.20.0.53 counter log prefix "FW-DENY-EXT-DNS " reject with icmpx type admin-prohibited
iifname "ens37" oifname "ens33" tcp dport { 80, 443 } accept
counter log prefix "FW-DEFAULT-DROP " drop# 형식 예시 — 차단 로그 해석 (값은 환경마다 다름)
10:40:01 FW-DENY-EXT-DNS SRC=192.168.10.57 DST=192.0.2.53 PROTO=UDP DPT=53
10:40:05 FW-DEFAULT-DROP SRC=192.168.10.57 DST=203.0.113.77 PROTO=TCP DPT=8443 SYN
10:40:06 FW-DEFAULT-DROP SRC=192.168.10.57 DST=203.0.113.77 PROTO=TCP DPT=8443 SYN
10:40:08 FW-DEFAULT-DROP SRC=192.168.10.57 DST=203.0.113.77 PROTO=TCP DPT=8443 SYN분석 방법 — 첫 줄은 규칙 이름만으로 "내부 DNS를 거치지 않은 직접 조회"임을 알 수 있습니다. 이어지는 세 줄은 Drop으로 응답을 받지 못한 클라이언트의 SYN 재전송이며(간격이 점점 늘어남), 시도 횟수는 3회가 아니라 연결 시도 1회로 해석합니다.
5. 보안 관점
- 명시적 차단 규칙은 넓은 허용 규칙의 위험한 부분을 잘라 내는 도구입니다. 예외 차단은 반드시 해당 허용 규칙보다 위에 둡니다.
- 차단 규칙만으로 보안을 구성하는 방식(블랙리스트형)은 목록에 없는 새 위협을 막지 못합니다. 기본은 Default Deny, 차단 규칙은 보완입니다.
- 외부 인터페이스에서 Reject를 쓰면 스캐너에게 빠르고 명확한 응답을 주게 됩니다. 노출 최소화가 목적이면 Drop이 적합합니다.
- 차단 로그를 남기지 않으면 공격 시도의 규모와 추세를 알 수 없습니다.
6. SOC 관점
관제자가 확인할 질문
- 이 차단은 이름 있는 규칙인가, 기본 차단인가, 상태 불일치인가?
- 같은 출발지가 차단 직후 다른 포트·다른 목적지에서 허용된 기록이 있는가? 차단 로그만 보고 종결하지 않습니다.
- 반복된 차단 로그는 여러 번의 시도인가, 한 번의 시도에 대한 재전송인가?
| 차단 패턴 | 해석 |
|---|---|
| 차단 후 같은 출발지의 허용 로그 | 우회 경로 성공 가능성, 우선 조사 |
| 내부 호스트의 이름 있는 차단 반복 | 정책 위반 행위 또는 악성코드 |
| 외부 기본 차단의 대량·광범위 포트 | 자동화 스캔 |
오탐 주의: 정책 변경 직후 정상 업무 트래픽이 새 차단 규칙에 걸려 로그가 급증하는 경우가 많습니다. 차단 규칙 추가 시각과 로그 증가 시각을 비교합니다.
7. 핵심 정리
- 명시적 차단 규칙은 예외 제거, 우선 차단, 증거 확보, 행위 식별을 위해 둡니다.
- 차단 로그는 이름 있는 규칙·기본 차단·상태 불일치로 구분해서 해석합니다.
- Drop은 재전송으로 반복 로그를 만들고, Reject는 즉시 응답해 정보를 노출합니다.
- 차단은 시도의 증거일 뿐이며, 이후 허용된 우회 경로가 있었는지 확인해야 합니다.
- 차단 규칙은 Default Deny를 보완하는 수단이며, 넓은 허용 규칙보다 위에 있어야 효과가 있습니다.
