Step 161. 방화벽과 iptables — 문지기의 규칙을 설계하다

Level 2 — 네트워크 공격과 MITM | 난이도 ★★★☆☆ | 예상 소요 시간 3시간

전제: Step 28(포트 스캔), Step 29(SSH 원격 접속)를 마쳤다. iptables 실습용 리눅스(가상머신 또는 WSL)와 윈도우 파워쉘이 필요합니다.

준비물: 리눅스 환경(iptables), 윈도우 파워쉬(방화벽 읽기). 규칙 읽기는 어디서든 안전하고, 규칙 추가·삭제는 랩 전용 가상머신에서만 하세요.
주의: ⚠️ 이 챕터의 실습은 내 랩·합법 플랫폼 전용입니다. 허가 없는 시스템에 적용하면 범죄입니다. 방화벽 규칙 변경은 즉시 효력이 생기는 시스템 설정 변경입니다 — 원격 서버에서 기본 정책을 DROP으로 바꾸는 실수는 여러분 자신의 접속을 끊습니다. 이 챕터의 iptables -L 출력과 윈도우 방화벽 상태는 2026-09-09에 실측했고, 규칙 추가 명령의 출력은 환경 의존적이라 출력 예시로 표시했습니다.

지금까지 여러분은 문을 두드리는 쪽이었습니다 — nmap으로 열린 포트를 찾고, SSH로 들어가고, 트래픽을 가로챘습니다. 오늘은 반대편에 섭니다. 방화벽은 "어떤 패킷을 들이고 내쫓을지"를 규칙으로 정하는 문지기이고, iptables는 리눅스의 그 문지기에게 규칙을 내리는 말입니다. 공격자가 읽었던 nmap 출력이 사실 "방화벽이 허용한 목록"이었다는 것을 오늘 뒤집어 보세요. 문지기의 규칙을 설계해 본 사람만이, 그 규칙의 빈틈도 보입니다.

1. 학습 목표

이 챕터를 끝내면 다음을 할 수 있습니다:

체인(INPUT/OUTPUT/FORWARD)과 타깃(ACCEPT/DROP/REJECT)의 의미를 설명한다
iptables 규칙이 "위에서부터 순서대로" 검사됨을 설명한다
현재 규칙을 읽고(iptables -L -n -v) 해석한다
화이트리스트 설계(기본 DROP + 필요한 것만 ACCEPT)의 순서를 안다
윈도우 방화벽의 프로필과 기본 정책을 읽고 해석한다
공격자 관점에서 방화벽 우회 경로를 설명한다

2. 배경 지식 — 오늘의 도구와 개념

오늘의 도구 한눈에 보기

구분	내용
언어·환경	리눅스 터미널(iptables) + 윈도우 파워쉬(netsh, Get-NetFirewallRule)
오늘의 명령	`iptables -L -n -v`(규칙 읽기), `iptables -A INPUT ...`(규칙 추가), `iptables -P INPUT DROP`(기본 정책), `iptables-save`(저장), `netsh advfirewall show currentprofile`(윈도우 상태)
필요한 개념	체인, 규칙, 타깃, 기본 정책, 상태 추적(conntrack), 화이트리스트/블랙리스트
오늘의 산출물	현재 규칙 해석 메모 + 화이트리스트 설계안 + 우회 관점 정리

2-1. 체인 — 패킷이 지나는 세 관문

iptables에서 패킷은 목적에 따라 세 관문(체인, chain) 중 하나를 지납니다.

INPUT: 이 컴퓨터로 들어오는 패킷. 서버 방어의 주 무대입니다.
OUTPUT: 이 컴퓨터에서 나가는 패킷.
FORWARD: 이 컴퓨터를 경유해서 다른 곳으로 가는 패킷. 라우터 역할을 할 때만 의미가 있습니다.

각 관문에는 규칙이 위에서 아래로 붙어 있고, 패킷은 규칙을 하나씩 만나다가 처음으로 조건에 맞는 규칙의 타깃(target)을 따릅니다. 타깃은 셋입니다 — ACCEPT(통과), DROP(조용히 버림 — 보낸 쪽은 타임아웃까지 기다림), REJECT(거절했다고 회신). 어떤 규칙에도 안 걸리면 마지막으로 기본 정책(policy)이 적용됩니다.

2-2. 화이트리스트 설계 — "전부 닫고, 필요한 것만 연다"

방화벽 설계의 철칙은 화이트리스트입니다. 기본 정책을 DROP으로 두고, 필요한 문만 규칙으로 여는 것입니다. 반대 설계(기본 ACCEPT + 나쁜 것만 DROP, 블랙리스트)는 "막을 것을 전부 미리 알아야" 하므로 현실적으로 불가능합니다.

단, 순서가 생명입니다. 기본 정책을 DROP으로 바꾸기 전에 두 가지를 먼저 열어야 합니다. ① 내가 먼저 건 연결의 응답(ESTABLISHED) — 이게 없으면 내 SSH 세션의 응답 패킷까지 DROP됩니다. ② 들여보낼 서비스(예: SSH 22번). 순서를 거꾸로 하면 원격 서버에서 자기 발목을 자르는 일이 벌어집니다.

2-3. conntrack — "이건 아까 그 대화의 후속입니다"

방화벽은 개별 패킷뿐 아니라 연결의 상태를 추적할 수 있습니다. conntrack(connection tracking) 모듈이 "이 패킷은 이미 수립된 연결의 일부"를 알아채 줍니다. -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT는 "이미 시작된 대화의 후속 패킷은 통과"라는 뜻으로, 화이트리스트 설계의 사실상 첫 규칙입니다. 이 덕분에 "나가는 건 자유롭게, 들어오는 새 연결만 검사"가 가능해집니다.

2-4. 윈도우 방화벽 — 같은 철학, 다른 말

윈도우에도 같은 일을 하는 방화벽(Windows Defender Firewall)이 내장되어 있습니다. iptables의 체인 대신 프로필(Domain/Private/Public — 컴퓨터가 속한 네트워크 종류별 정책)과 인바운드/아웃바운드 규칙으로 조직되어 있고, 파워쉬의 Get-NetFirewallRule이나 netsh advfirewall로 읽고 씁니다. 기본 철학은 같습니다 — 들어오는 것은 기본 차단, 나가는 것은 기본 허용.

3. 따라 하기

3-1. 현재 규칙 읽기 — 문지기의 출근부

입력 (리눅스):

sudo iptables -L -n -v

출력 (2026-09-09 실측, WSL 우분투 — 도커가 설치된 환경):

Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 DOCKER-USER  0    --  *      *       0.0.0.0/0            0.0.0.0/0
    0     0 DOCKER-FORWARD  0 --  *      *       0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain DOCKER-USER (1 references)
 ...

읽는 법: 세 기본 체인이 보입니다. Chain INPUT (policy ACCEPT ...) — 이 랩의 들어오는 문은 기본 정책이 ACCEPT, 즉 사실상 무방비 상태입니다. 규칙 줄도 비어 있습니다. 반면 FORWARD는 policy DROP에 도커가 만든 체인들(DOCKER-USER 등)이 달려 있습니다 — 도커가 컨테이너 네트워크를 위해 규칙을 자동으로 써 둔 것입니다. "비어 있다"는 것도 정보입니다: 이 컴퓨터는 현재 들어오는 모든 연결을 받아들입니다. 여러분의 환경이 WSL이 아니면 도커 체인 없이 텅 빈 세 체인만 보일 수 있습니다 — 그것이 오히려 표준적인 초기 상태입니다.

읽는 법(옵션): -L은 목록, -n은 주소를 숫자로(이름 해석 생략으로 빠름), -v는 패킷·바이트 카운터까지. 카운터가 오르는 것으로 "규칙이 실제로 패킷을 잡고 있는가"를 확인할 수 있습니다.

3-2. 화이트리스트 설계 — 명령의 순서

이제 랩 전용 가상머신에서의 설계 절차입니다. 아래 명령은 시스템 설정을 바꾸므로 랩 VM에서만 실행하세요. 출력은 환경 의존적이라 예시로 표시합니다.

입력:

# 1. 이미 시작된 대화의 응답은 통과 (이게 첫 규칙이어야 한다)
sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# 2. 루프백은 신뢰 (로컬 서비스끼리의 통신)
sudo iptables -A INPUT -i lo -j ACCEPT
# 3. SSH만 새로 열기
sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
# 4. 나머지는 전부 닫기 (기본 정책)
sudo iptables -P INPUT DROP
# 확인
sudo iptables -L INPUT -n -v

출력 예시:

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     0    --  *      *       0.0.0.0/0    0.0.0.0/0   ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     0    --  lo     *       0.0.0.0/0    0.0.0.0/0
    0     0 ACCEPT     tcp  --  *      *       0.0.0.0/0    0.0.0.0/0   tcp dpt:22

읽는 법: 기본 정책이 DROP으로 바뀌었고, 그 위에 예외 세 줄이 있습니다. 패킷은 위에서부터 비교됩니다 — "이미 시작된 대화인가?" → "로컬 통신인가?" → "SSH로 오는가?" → 셋 다 아니면 정책 DROP. 이것이 화이트리스트입니다.

왜 순서인가: 4번을 먼저 실행하는 순간, 아직 허용 규칙이 없으므로 원격 접속 중이라면 그 즉시 응답 패킷이 끊깁니다. 1번(ESTABLISHED 허용)이 먼저 있어야 현재 세션이 살아남습니다. 방화벽 작업은 항상 "퇴로부터 확보"입니다.

3-3. 검증 — 공격자의 눈으로 확인하기

설계가 됐으면 nmap으로 밖에서 두드려 봅니다 (Kali 또는 다른 랩 머신에서).

nmap 192.168.56.103

출력 예시:

PORT   STATE SERVICE
22/tcp open  ssh

읽는 법: 스캔 결과에 22번만 보입니다. DROP된 포트는 응답이 없으니 nmap은 "filtered"(방화벽 존재 추정)로 표시하고, 규칙 없이 서비스만 안 뜬 포트는 "closed"로 표시합니다 — 이 둘의 차이가 방화벽의 지문입니다. 웹 서버를 열고 싶다면 --dport 80 규칙을 22번 규칙 뒤에 추가하고 다시 스캔해 보세요.

3-4. 저장과 초기화 — 규칙의 수명 관리

iptables 규칙은 재부팅하면 사라집니다. 저장과 복원, 그리고 비상용 초기화를 알아둡니다.

sudo iptables-save > rules.v4        # 현재 규칙을 파일로 저장
sudo iptables-restore < rules.v4     # 파일에서 복원
sudo iptables -F                     # ⚠️ 모든 규칙 삭제 (정책은 그대로 — DROP이면 여전히 닫힘)

읽는 법: -F(flush)는 규칙만 지우고 기본 정책은 건드리지 않습니다. 정책이 DROP인 채로 규칙만 지우면 모든 문이 닫히니, 초기화할 때는 sudo iptables -P INPUT ACCEPT로 정책부터 되돌리는 것이 안전한 순서입니다.

3-5. 윈도우 방화벽 읽기 — 내 PC의 문지기

리눅스가 없어도, 여러분의 윈도우에는 지금 방화벽이 켜져 있습니다. 읽기 전용 명령으로 확인합니다.

입력 (파워쉬):

netsh advfirewall show currentprofile
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction

출력 (2026-09-09 실측, 한글 윈도우):

상태                                  사용
방화벽 정책                           BlockInbound,AllowOutbound
...

Name    Enabled DefaultInboundAction DefaultOutboundAction
----    ------- -------------------- ---------------------
Domain     True        NotConfigured         NotConfigured
Private    True        NotConfigured         NotConfigured
Public     True        NotConfigured         NotConfigured

읽는 법: BlockInbound,AllowOutbound — 들어오는 새 연결은 기본 차단, 나가는 것은 기본 허용. 2-2의 화이트리스트 철학이 윈도우의 기본값으로 이미 구현되어 있습니다. 세 프로필의 NotConfigured는 "명시적 설정이 없어 기본값(인바운드 차단/아웃바운드 허용)을 따른다"는 뜻입니다. 이 컴퓨터의 규칙 수는 (Get-NetFirewallRule | Measure-Object).Count로 확인했더니 727개(2026-09-09 실측)였습니다 — 대부분은 프로그램 설치 시 등록된 예외들입니다. 공격자가 악성코드를 깔면 여기에 조용히 자기 규칙을 추가하려 한다는 점에서, 규칙 목록 감사는 침해 조사의 기본 항목입니다.

3-6. 우회 관점 — 문지기를 피하는 법을 아는 문지기

방화벽이 "22번만 열림"이라면 공격자는 어떻게 할까요? 대표적인 경로를 정리합니다.

우회	원리
열린 포트로 역접속	피해자가 밖으로 연결(OUTPUT은 보통 자유) → 그 연결을 타고 들어옴
허용된 서비스 자체를 공격	22번이 열려 있으면 SSH 무차별 대입 — 그래서 키 인증이 필수
DNS/ICMP 터널링	방화벽이 대개 허용하는 DNS 질의 속에 데이터를 숨겨 반출
웹 경유	80/443이 열려 있으면 웹 취약점으로 들어가 내부에서 움직임

읽는 법: 공통점이 보입니다 — 전부 "방화벽이 허용한 길"을 씁니다. 방화벽은 문의 수를 줄이는 도구이지, 열린 문을 지키는 도구가 아닙니다. 열린 문 뒤의 서비스 관리(패치, 인증)가 방화벽과 한 세트입니다.

4. 미션과 연습문제

미션 — 내 랩의 화이트리스트 설계서

iptables -L -n -v(또는 윈도우의 netsh advfirewall show currentprofile)의 현재 상태를 읽고, 기본 정책이 무엇인지, 어떤 체인/규칙이 있는지 해석 메모를 쓰세요.
랩 VM에서 3-2의 네 줄을 실행하고 전후의 iptables -L 출력을 나란히 붙이세요. 어느 줄이 어떤 역할인지 주석을 다세요.
nmap으로 전/후를 스캔해 결과 차이를 기록하세요 (VM이 없으면 윈도우 방화벽 규칙 중 인바운드 차단 규칙 3개를 Get-NetFirewallRule -Enabled True -Direction Inbound -Action Block로 골라 해석하는 것으로 대체).
"웹 서버(80)도 열어야 한다"는 요구가 들어왔을 때 추가할 규칙 한 줄과, 그 규칙을 어디에(몇 번째 위치에) 넣을지 이유와 함께 적으세요.

연습문제

문제 1. DROP과 REJECT는 둘 다 패킷을 막습니다. 공격자(nmap 사용자) 입장에서 둘의 차이는 무엇이며, 서버 관리자가 DROP을 선호하는 이유는 무엇인가요?

문제 2. 기본 정책을 DROP으로 바꾸기 전에 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT를 먼저 넣어야 하는 이유를, 원격 SSH 작업 상황에 빗대어 설명하세요.

문제 3. 화이트리스트(기본 DROP)가 블랙리스트(기본 ACCEPT)보다 안전한 이유를 "모른다"는 개념으로 설명하세요.

문제 4. 윈도우 방화벽의 기본값(BlockInbound, AllowOutbound)을 볼 때, 악성코드가 명령 서버(C2)와 통신하기 위해 왜 "들어오는 연결을 기다리는" 대신 "밖으로 먼저 연결하는" 방식을 택하는지 설명하세요.

5. 모범 답안과 완료 기준

미션 모범 답안

1번 해석 예 (2026-09-09 실측 랩 기준): "INPUT은 policy ACCEPT에 규칙 없음 — 들어오는 모든 연결을 받는 열린 상태. FORWARD는 policy DROP이고 도커가 관리하는 체인들이 달려 있음 — 이 머신이 컨테이너의 다리 역할을 함. OUTPUT은 열림."

2번 주석 예:

1번째 규칙: ESTABLISHED,RELATED ACCEPT — 이미 시작된 대화의 후속 패킷 통과. 이게 없으면 내 SSH 응답도 DROP됨
2번째 규칙: lo ACCEPT — 127.0.0.1끼리의 로컬 통신은 방화벽 검사 제외
3번째 규칙: tcp dpt:22 ACCEPT — 새로 들어오는 SSH 연결만 허용
정책: INPUT DROP — 위 셋에 해당 없는 들어오는 패킷은 전부 폐기

4번: sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT를 22번 규칙 뒤(-A는 끝에 추가이므로 자연스럽게 그 위치)에 둡니다. 정책(DROP)은 규칙이 아니라 체인의 기본값이라 항상 마지막에 적용되므로, -A로 추가한 규칙은 자동으로 DROP보다 먼저 검사됩니다. -I INPUT 1처럼 위치를 지정해 꽂는 방법도 있습니다.

검증하는 법: ① 전/후 출력에서 policy가 ACCEPT→DROP으로 바뀌었는가. ② ESTABLISHED 규칙이 목록의 첫 줄인가. ③ nmap 결과가 "22만 open"으로 줄었는가(또는 윈도우 대체 과제에서 차단 규칙 해석이 옳은가). ④ 80번 규칙의 위치 이유를 "검사 순서"로 설명했는가.

연습문제 해답

문제 1 해답. REJECT는 "거절한다"는 응답(ICMP 또는 TCP RST)을내므로 공격자는 "포트가 닫혀 있고 방화벽이 즉시 알려 주는구나"를 바로 알고, DROP은 아무 응답이 없어 "패킷이 사라졌다"만 압니다. DROP은 스캔을 느리게 만들고(매번 타임아웃 대기) 정보를 덜 줍니다. 다만 nmap은 응답 부재 자체로 "filtered"를 추정하므로 완벽한 은폐는 아닙니다.

문제 2 해답. SSH 세션도 결국 들어오고 나가는 패킷의 연속입니다. 기본 정책 DROP이 먼저 적용되면, 이미 연결된 내 세션의 후속 패킷(서버가 보내는 응답)까지 INPUT 검사에서 버려져 접속이 즉시 끊깁니다. ESTABLISHED 허용이 먼저 있으면 "이미 시작된 대화"는 정책과 무관하게 살아남습니다.

문제 3 해답. 블랙리스트는 "막아야 할 것을 미리 전부 알고 있다"는 가정 위에 서지만, 새로운 위협은 정의상 목록에 없습니다 — 모르는 것은 못 막습니다. 화이트리스트는 반대로 "허용할 것만 안다"고 가정하므로, 모르는 것은 자동으로 차단됩니다. 안전 쪽이 기본값이 되는 설계입니다.

문제 4 해답. AllowOutbound 때문에 나가는 새 연결은 기본적으로 허용되기 때문입니다. 악성코드가 피해자 PC에서 밖의 C2 서버로 먼저 연결하면 방화벽을 정면으로 뚫지 않고 통신 채널이 열리고, 일단 수립된 연결의 응답은 ESTABLISHED 성격으로 다시 들어올 수 있습니다. 그래서 방어는 인바운드뿐 아니라 아웃바운드 감시(비정상 외부 연결 탐지)까지 필요합니다.

완료 기준 체크리스트

[ ] INPUT/OUTPUT/FORWARD 세 체인의 역할을 설명할 수 있다
[ ] ACCEPT/DROP/REJECT의 차이를 설명할 수 있다
[ ] iptables -L -n -v 출력에서 정책과 규칙을 읽을 수 있다
[ ] 화이트리스트 규칙의 올바른 추가 순서(ESTABLISHED → lo → 서비스 → 정책)를 안다
[ ] iptables-save와 -F의 역할과 주의점을 안다
[ ] 윈도우 방화벽의 기본 정책(BlockInbound, AllowOutbound)을 읽을 수 있다
[ ] 방화벽 우회 경로 두 가지 이상을 공격자 관점으로 설명할 수 있다

6. 흔한 실수와 해결

벽 1. "정책을 DROP으로 바꿨더니 SSH가 끊겼어요"

증상: iptables -P INPUT DROP 실행 직후 원격 세션이 멈춥니다.
원인: ESTABLISHED 허용 규칙을 넣기 전에 정책부터 바꿨습니다. 순서 오류의 고전입니다.
해결: VM 콘솔(물리 화면)로 들어가 sudo iptables -P INPUT ACCEPT로 되돌리고, 3-2의 순서(예외 먼저, 정책 나중)로 다시 합니다. 원격 작업에서는 iptables-apply(일정 시간 내 확인 없으면 자동 롤백)를 쓰는 습관이 안전합니다.

벽 2. "규칙을 넣었는데 적용이 안 돼요"

증상: 80번을 열었는데 nmap에 안 보입니다.
원인: 셋 중 하나입니다. ① 규칙은 들어갔지만 서비스(웹 서버)가 안 켜져 있음 — 방화벽은 문을 여는 것이고 안에 사람이 있어야 응답합니다. ② -A로 넣은 규칙이 DROP 성격의 앞선 규칙 뒤에 갇힘. ③ 다른 체인이나 다른 테이블에 넣음.
해결: 서버에서 ss -tlnp | grep 80으로 서비스 생존을 먼저 확인하고, iptables -L INPUT -n -v --line-numbers로 규칙 순서를 봅니다.

벽 3. "재부팅했더니 규칙이 다 사라졌어요"

증상: 어제 만든 규칙이 iptables -L에 없습니다.
원인: iptables 규칙은 메모리에만 존재합니다.
해결: sudo iptables-save > /etc/iptables/rules.v4로 저장하고 부팅 시 복원되게 합니다(배포판마다 iptables-persistent 패키지 또는 systemd 서비스 사용). 저장 없이 실험만 하는 랩에서는 사라지는 게 오히려 깨끗합니다.

벽 4. "WSL에서 iptables가 텅 비어 있어요"

증상: 실측 환경처럼 도커 체인만 있거나 아예 아무것도 없습니다.
원인: WSL의 방화벽은 실질적으로 윈도우 호스트의 방화벽 뒤에 있습니다. WSL 안의 iptables는 완전한 경계가 아닙니다.
해결: 개념 실습은 그대로 가능하지만(규칙을 넣고 -L로 읽는 연습), "진짜 문지기" 실습은 랩 전용 리눅스 VM에서 하세요. WSL에서는 절대 호스트 방화벽을 건드리지 마세요.

벽 5. "파워쉬에서 Get-NetFirewallRule이 너무 많이 나와요"

증상: 수백 줄이 쏟아집니다.
원인: 정상입니다 — 실측 머신에도 727개가 있었습니다.
해결: 좁혀서 보세요. Get-NetFirewallRule -Enabled True -Direction Inbound -Action Allow | Select-Object -First 10 DisplayName처럼 조건과 개수를 제한합니다. 침해 조사에서는 "최근 만들어진 규칙"부터 보는 것이 팁입니다.

7. 정리

오늘의 개념

개념	한 줄 설명
방화벽	규칙으로 패킷의 통과를 결정하는 문지기
체인(INPUT/OUTPUT/FORWARD)	들어오는 / 나가는 / 경유하는 패킷의 세 관문
타깃(ACCEPT/DROP/REJECT)	통과 / 조용히 폐기 / 거절 회신
기본 정책(policy)	아무 규칙에도 안 걸린 패킷의 최종 처분
화이트리스트	기본 DROP + 필요한 것만 ACCEPT — 모르는 것은 자동 차단
conntrack / ESTABLISHED	연결 상태 추적 — "이미 시작된 대화"를 알아보는 장치
iptables-save / -F	규칙 저장 / 전부 삭제(정책은 남음에 주의)
프로필(윈도우)	Domain/Private/Public 네트워크별 정책 묶음 — 기본 BlockInbound

오늘의 명령어

명령	하는 일
`sudo iptables -L -n -v`	현재 규칙과 정책 읽기(카운터 포함)
`sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT`	이미 시작된 대화 통과 — 첫 규칙
`sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT`	SSH 신규 연결 허용
`sudo iptables -P INPUT DROP`	기본 정책을 DROP으로 — 반드시 마지막에
`sudo iptables-save > rules.v4` / `sudo iptables-restore < rules.v4`	규칙 저장 / 복원
`sudo iptables -F`	규칙 전부 삭제(⚠️ 정책은 유지됨)
`netsh advfirewall show currentprofile`	윈도우 방화벽 현재 프로필 상태
`Get-NetFirewallRule -Enabled True -Direction Inbound -Action Block`	윈도우 차단 규칙 읽기

명령어보다 중요한 감각

방화벽의 본질은 "차단 기술"이 아니라 "순서 있는 판단"입니다. 위에서부터 읽히는 규칙, 마지막에 기다리는 정책 — 이 구조를 이해하면, nmap 출력이 "열린 문의 목록"이 아니라 "누군가가 설계한 판단의 결과"로 보이기 시작합니다.

그리고 공격과 방어가 같은 표를 읽는다는 것을 기억하세요. 여러분이 -A INPUT으로 여는 문은 침입자가 찾는 문이고, 여러분이 DROP으로 닫는 문은 침입자가 우회할 동기가 됩니다. 문지기를 설계해 본 오늘의 경험이, 다음에 누군가의 방화벽을 진단할 때 "설계자의 의도"를 읽는 눈이 됩니다.

전부 체크되면 Step 161 완료입니다. 사이드바의 체크박스를 눌러 진도를 저장하세요.