📚 네트워크 · 패킷 분석 › 06. 방화벽 · IDS 기초 — 265편
이전 글: 264. Outbound Policy · 다음 글: 266. Deny Policy
1. 개념
Allow Policy(허용 정책) 는 조건에 맞는 트래픽을 통과시키는 규칙입니다. Default Deny(267. Default Deny) 환경에서는 허용 규칙의 목록이 곧 "조직이 인정한 통신의 전체 목록" 이 됩니다. 동작(Action) 값의 장비별 표기는 04 영역 184. Allow와 Deny에서 다뤘습니다.
허용 규칙은 한 번 만들면 잘 지워지지 않고, 지나치게 넓게 만들어도 당장 장애가 나지 않습니다. 그래서 보안 점검에서 문제가 가장 많이 발견되는 곳이 허용 규칙입니다.
| 품질 기준 | 좋은 허용 규칙 | 나쁜 허용 규칙 |
|---|---|---|
| 출발지 | 필요한 대역·호스트 | any |
| 목적지 | 특정 서버·그룹 | any 또는 대역 전체 |
| 서비스 | 특정 포트 | any 또는 넓은 포트 범위 |
| 설명 | 요청 번호·목적·담당자 | 없음 또는 "임시" |
| 기한 | 만료일 또는 검토일 | 없음 |
| 로그 | 목적에 맞게 설정 | 꺼져 있음 |
2. 동작 원리
허용은 "통과"로 끝나지 않고, 장비에 따라 추가 검사로 이어지는 출발점이 됩니다.
새 연결 → 정책 비교 → Allow 규칙 일치
↓
[세션 생성] → 이후 패킷은 세션 테이블로 통과
↓
[허용 규칙에 연결된 보안 프로필이 있는가?]
├─ 예 → IPS·안티바이러스·URL 필터 등 추가 검사 → 위협이면 세션 차단
└─ 아니오 → 헤더 조건만으로 끝까지 통과
↓
[로그 설정] 세션 시작·종료 기록 (설정 시)- NGFW 계열은 허용 규칙마다 보안 프로필을 붙이는 구조가 많습니다. 프로필이 없는 허용 규칙은 내용 검사 없이 통과시킨다는 점을 알아야 합니다.
- 허용은 방화벽이 통과를 허락했다는 뜻이지, 통신이 성공했다는 뜻은 아닙니다. 서버가 RST로 거부했거나 서비스가 없을 수 있습니다.
3. 주요 특징
허용 로그가 증명하는 것과 증명하지 못하는 것을 구분해야 분석 결론이 정확해집니다.
| 허용 로그로 알 수 있는 것 | 허용 로그만으로 알 수 없는 것 |
|---|---|
| 방화벽이 해당 5-tuple 연결을 통과시켰다 | 서버가 요청을 정상 처리했는가 |
| 어느 규칙이 허용했는가 | 요청 내용이 공격이었는가 |
| 세션 지속 시간, 주고받은 바이트 수(종료 로그) | 공격이 성공했는가 |
| NAT 변환 전후 주소(기록 시) | 어떤 사용자·프로세스가 만들었는가(일반 방화벽) |
- 임시 허용은 만료일을 설정할 수 있는 장비라면 반드시 설정합니다. 만료 기능이 없으면 검토일을 설명에 기록합니다.
- 예외 허용(보안 정책상 금지된 서비스를 특정 업무로 허용)은 범위를 최소화하고 승인 근거를 남깁니다.
- 허용 규칙에 로그를 켤지는 트래픽 양과 증거 가치로 결정합니다. 외부 공개 서비스, 서버 대역 Outbound, 관리 접근 허용은 기록 가치가 높습니다.
4. 예시
설명·범위·로그를 갖춘 허용 규칙의 실습 예시입니다(값은 환경마다 다름).
# Rocky (firewalld rich rule): 관리망에서만 SSH 허용, 로그 기록(분당 3건 제한)
sudo firewall-cmd --permanent --zone=public \
--add-rich-rule='rule family="ipv4" source address="10.99.10.0/24" service name="ssh" log prefix="FW-SSH-ALLOW " level="info" limit value="3/m" accept'
sudo firewall-cmd --reload
# Ubuntu (ufw): 같은 목적, 규칙 설명 포함
sudo ufw allow from 10.99.10.0/24 to any port 22 proto tcp comment 'CHG-0930 mgmt ssh'# nftables (Rocky/Ubuntu 공통) — 세션 시작 시 한 번만 로그를 남기는 허용 규칙
ct state new ip saddr 10.99.10.0/24 tcp dport 22 counter log prefix "FW-SSH-ALLOW " accept comment "CHG-0930 mgmt ssh"ct state new 조건을 함께 쓰면 세션의 첫 패킷에서만 로그가 남아, 패킷마다 기록되는 것을 피할 수 있습니다. 규칙 문법의 전체 구조는 04 영역 181. Firewall 정책을 참고합니다.
5. 보안 관점
- 허용 규칙은 최소 권한 원칙을 따릅니다. "나중에 필요할 수도 있으니" 넓게 여는 것은 공격자에게도 같은 경로를 여는 것입니다.
- any를 포함한 허용 규칙, 설명 없는 허용 규칙, 적중 0인 허용 규칙은 정기 검토의 우선 대상입니다.
- 허용된 경로 안의 공격은 방화벽이 아니라 보안 프로필·IPS·WAF가 다룹니다. 허용 규칙마다 어떤 추가 검사가 적용되는지 알고 있어야 합니다.
- 허용 규칙 변경 권한과 승인 절차를 분리해 한 사람이 임의로 여는 것을 막습니다.
6. SOC 관점
관제자가 확인할 질문
- 이 통신을 허용한 규칙의 목적(설명) 과 실제 통신이 일치하는가? 웹 공개 규칙으로 허용된 트래픽이 웹 요청이 아니라면 이상입니다.
- 허용 규칙에 보안 프로필(IPS 등) 이 적용되어 있는가? 없다면 내용 검사 결과가 없다는 점을 분석에 반영합니다.
- 허용된 세션의 바이트 수와 지속 시간은 서비스 특성에 맞는가?
- 사건 직전에 새로 추가되거나 범위가 넓어진 허용 규칙이 있는가?
오탐 주의: 허용 로그 급증은 신규 서비스 오픈, 대규모 배포, 백업 작업 같은 정상 운영 이벤트와 겹치는 경우가 많습니다. 변경 관리 일정과 먼저 대조합니다. 허용 로그와 IDS Alert를 연결하는 방법은 296. Alert와 Firewall Log 연계에서 다룹니다.
7. 핵심 정리
- Default Deny 환경에서 허용 규칙 목록은 조직이 인정한 통신 목록입니다.
- 좋은 허용 규칙은 좁은 범위, 설명, 기한, 적절한 로그를 갖춥니다.
- 허용은 추가 검사(보안 프로필)의 출발점이며, 프로필이 없으면 내용 검사 없이 통과합니다.
- 허용 로그는 통과 사실을 증명하지만, 요청 처리 성공이나 공격 성공은 증명하지 못합니다.
- any·설명 없음·적중 0·최근 변경된 허용 규칙은 관제와 점검의 우선 확인 대상입니다.
