Step 162. 프록시와 익명화 — 대리인 뒤에 숨는 기술과 그 한계

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

전제: Step 132(Burp Suite 프록시 가로채기)와 Step 85(HTTP vs HTTPS)를 마쳤다.

준비물: 개념 챕터 — 종이와 펜(또는 다이어그램 도구)이면 충분합니다. Step 132의 미니 프록시 코드를 다시 열어 두면 좋습니다.
주의: ⚠️ 이 챕터의 실습은 내 랩·합법 플랫폼 전용입니다. 허가 없는 시스템에 적용하면 범죄입니다. 익명화 기술은 억압 환경의 언론인과 활동가를 지키는 방패이기도 하지만, 불법 행위의 보호막이 아닙니다 — 그리고 오늘 배우듯 완벽한 보호막은 존재하지 않습니다. 이 챕터는 개념 중심이며, 프록시 중계 로그는 Step 132의 실측(2026-09-09)을 재인용합니다.

Step 132에서 여러분은 프록시를 "요청을 가로채서 보는 도구"로 썼습니다. 오늘은 같은 구조를 반대 방향에서 봅니다 — 서버에게 내 IP를 숨기는 도구로서의 프록시, 그리고 그 아이디어를 극한까지 밀어붙인 Tor입니다. "내 대신 요청해 주는 사람"이라는 단순한 구조가 어떻게 추적 회피의 인프라가 되는지, 그리고 왜 그 인프라도 완전하지 않은지를 정리합니다. 익명성의 한계를 아는 것이 익명성을 올바르게 쓰는 조건입니다.

1. 학습 목표

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

포워드 프록시와 리버스 프록시의 차이를 "누구를 대리하는가"로 설명한다
프록시가 서버에게 IP를 숨기는 원리와, 그만큼 프록시가 많이 보는 이유를 설명한다
프록시 체인과 proxychains의 구조를 설명한다
Tor의 3중 릴레이(양파 라우팅) 구조와 각 노드가 아는 것을 설명한다
익명성을 무너뜨리는 요인(종단 노드 감청, 핑거프린팅, 타이밍 분석, 행동 습관)을 열거한다

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

오늘의 도구 한눈에 보기

구분	내용
언어·환경	개념 챕터 — Step 132의 파이썬 미니 프록시(원리 재확인용)
오늘의 개념	포워드/리버스 프록시, HTTP vs SOCKS 프록시, 프록시 체인, Tor(입구-중계-출구 노드), 브라우저 핑거프린팅
필요한 개념	Step 132의 프록시 중계 구조, Step 85의 평문/암호문, IP 주소와 신원의 관계
오늘의 산출물	프록시 종류별 구조도 + Tor 신원 보호 범위 표 + 익명성 한계 정리

2-1. 포워드 프록시 — 클라이언트의 대리인

프록시(proxy)는 "대리인"입니다. 포워드 프록시(forward proxy)는 클라이언트를 대리합니다. 내 브라우저가 서버에 직접 가는 대신 프록시에게 부탁하면, 프록시가 자기 IP로 대신 가서 결과를 가져옵니다. 서버의 로그에는 내 IP가 아니라 프록시의 IP가 남습니다.

용도는 셋입니다. ① 숨기기 — 서버가 내 주소를 모르게. ② 우회 — 회사·학교 망의 출구를 통하거나 지역 제한을 피하기. ③ 관찰 — Step 132의 Burp처럼, 지나가는 내용을 보기. 같은 구조가 사용 목적에 따라 방어 도구, 우회 도구, 공격 도구가 됩니다.

2-2. 리버스 프록시 — 서버의 대리인

방향이 반대인 리버스 프록시(reverse proxy)도 있습니다. 이쪽은 서버를 대리합니다. 사용자는 example.com에 접속했다고 생각하지만 실제로 응답한 것은 앞단의 리버스 프록시(nginx, Cloudflare 같은)이고, 진짜 서버는 그 뒤에 숨어 있습니다. 서버 관리자는 이로 부하 분산, 공격 표면 축소, TLS 종료를 얻습니다. 포워드 프록시가 "나를 숨기는 도구"라면, 리버스 프록시는 "서버를 숨기는 도구"입니다.

구별법은 하나입니다 — 누가 그 대리인을 골랐는가. 클라이언트가 고르면 포워드, 서버가 고르면 리버스입니다.

2-3. HTTP 프록시와 SOCKS 프록시

대리인에게 부탁하는 방식에도 종류가 있습니다. HTTP 프록시는 웹 요청만 이해합니다 — "이 URL을 가져와 줘"라고 부탁하는 방식. SOCKS 프록시(SOCKS5가 현재 표준)는 더 아래층에서 일합니다 — "이 주소와 포트로 연결을 터줘"라고 부탁하므로, 웹이든 SSH든 어떤 TCP 트래픽이든 실어 나릅니다. proxychains나 Tor가 SOCKS를 쓰는 이유입니다.

2-4. Tor — 세 명의 대리인이 릴레이하는 구조

프록시 하나는 치명적 약점이 있습니다. 그 프록시는 나와 목적지를 둘 다 압니다. 프록시 운영자가 로그를 남기면 익명성은 끝입니다. Tor(The Onion Router)는 이 문제를 "대리인을 셋으로 나누는 것"으로 풉니다.

입구 노드(guard): 나의 IP를 알지만, 목적지는 모릅니다.
중계 노드(middle): 앞사람과 뒷사람만 알고, 나도 목적지도 모릅니다.
출구 노드(exit): 목적지 서버와 이야기하지만, 나의 IP는 모릅니다.

데이터는 양파처럼 세 겹으로 암호화되어, 각 노드는 자기 껍질 하나만 벗기고 다음 사람에게 넘깁니다 — 그래서 양파 라우팅입니다. 어느 한 노드도 "누가, 어디와, 무엇을"을 전부 알지 못하게 설계된 것입니다.

2-5. 익명성의 한계 — Tor는 무적이 아니다

그래도 무너지는 지점이 있습니다.

출구 노드의 감청: 출구에서 목적지까지는 일반 인터넷입니다. 그 구간이 평문 HTTP라면 출구 운영자가 내용을 읽습니다(그래서 HTTPS는 Tor 안에서도 필수).
브라우저 핑거프린팅: IP를 숨겨도, 브라우저의 화면 크기·글꼴·플러그인 조합은 세계에서 몇 없는 지문이 될 수 있습니다.
타이밍 분석: 입구와 출구 양쪽을 동시에 관찰할 수 있는 강력한 감시자는, 패킷이 들어간 시각과 나온 시각의 상관으로 경로를 추정합니다.
행동 습관: Tor로 접속해 평소 계정에 로그인하는 순간, 익명성은 스스로 버린 셈입니다. 기술이 아니라 습관이 무너뜨리는 가장 흔한 경로입니다.

2-6. VPN은 프록시와 무엇이 다른가

비교 대상으로 자주 나오는 VPN(Virtual Private Network)을 짚고 갑니다. 상용 VPN은 "내 장비와 VPN 회사의 출구 서버 사이를 암호화 터널로 잇는" 기술입니다. 프록시와의 차이는 둘입니다. ① 동작 층 — 프록시는 응용(브라우저)별로 부탁하지만, VPN은 운영체제의 모든 트래픽을 통째로 터널에 넣습니다. ② 관계 — VPN 회사는 나의 IP와 모든 목적지를 아는 "신뢰하는 프록시 하나"입니다.

그래서 구도는 이렇게 정리됩니다. 통신사의 눈을 VPN 회사로 옮길 뿐, 익명성의 총량은 늘지 않습니다 — "신뢰를 어디에 두는가"의 선택입니다. Tor가 그 신뢰조차 셋으로 분산한 극단이라면, 상용 VPN은 편의와 속도를 택한 타협입니다. 셋(직접, VPN, Tor)을 "누가 무엇을 아는가"로 비교하는 훈련이 오늘 표의 연장선입니다.

3. 따라 하기

3-1. 프록시가 보는 것 — Step 132 실측 다시 읽기

익명화의 대가를 이해하려면, 프록시의 시야를 먼저 봐야 합니다. Step 132에서 30줄짜리 미니 프록시를 띄우고 curl로 경유 요청을 보냈을 때의 로그입니다 (Step 132 3-4, 2026-09-09 실측 재인용):

[프록시 기동] 127.0.0.1:8080 — 요청을 기다립니다
[연결 수락] 127.0.0.1:xxxxx
POST /login HTTP/1.1
Host: 127.0.0.1:5000
...
username=hacker&password=mypw123

읽는 법: 프록시는 요청 전체 — 목적지, 헤더, 그리고 평문 본문의 비밀번호까지 — 를 봤습니다. 이 로그를 뒤집어 읽으세요. "서버에게 내 IP를 숨겨 주는 프록시"는 동시에 "내 모든 요청을 볼 수 있는 위치"입니다. 무료 프록시에게 익명성을 맡긴다는 것은, 모르는 사람에게 통신 내용을 구독시켜 주는 것과 같습니다. 이것이 오늘의 출발점입니다.

3-2. 구조도 그리기 — 대리인의 개수에 따라

종이에 세 구조를 그려 봅니다.

[직접 접속]
나(내 IP) ───────────────→ 서버          서버 로그: 내 IP

[프록시 1개]
나 ──→ 프록시(프록시 IP) ──→ 서버          서버 로그: 프록시 IP / 프록시 로그: 내 IP + 목적지 + 내용(HTTP일 때)

[프록시 체인]
나 ──→ P1 ──→ P2 ──→ P3 ──→ 서버           서버 로그: P3의 IP / 추적하려면 P1~P3의 로그를 전부 확보해야 함

읽는 법: 화살표가 늘 때마다 추적자가 모아야 할 로그의 개수가 늘고, 그 로그들이 서로 다른 나라·다른 사업자에 흩어져 있을수록 수집이 어려워집니다. proxychains는 이 체인을 /etc/proxychains.conf에 적힌 순서대로 조립해 주는 도구일 뿐, 마법은 없습니다 — 구조가 곧 원리입니다.

3-3. Tor의 신원 보호 범위 표 만들기

2-4의 3중 릴레이를 "각 노드가 아는 것"으로 정리합니다. 이 표를 직접 채우는 것이 오늘의 핵심 훈련입니다.

관찰자	나의 IP	목적지 서버	내용(HTTPS)	내용(평문 HTTP)
내 통신사(ISP)	안다(내가 Tor를 쓴다는 사실)	모른다(Tor 입구만 보임)	모른다	모른다(Tor 구간 암호화)
입구 노드	안다	모른다	모른다	모른다
중계 노드	모른다	모른다	모른다	모른다
출구 노드	모른다	안다	모른다	안다
목적지 서버	모른다(출구 IP만 보임)	자기 자신	자기 페이지	자기 페이지

읽는 법: 마지막 행과 넷째 행을 보세요. Tor를 써도 평문 HTTP의 내용은 출구 노드에 노출되고, 서버는 "어느 Tor 출구에서 왔는가"는 압니다. Tor가 숨기는 것은 연결의 출발점(나의 IP)이지, 통신의 존재나 평문의 내용이 아닙니다.

3-4. 한계 시나리오 분석 — 어디서 무너지는가

세 시나리오를 스스로 평가해 보세요 (정답은 5번에 있습니다).

Tor로 접속해 평소 쓰는 이메일에 로그인했다.
Tor 브라우저를 쓰지 않고, 평소 크롬(로그인 상태, 확장 프로그램 10개)에 프록시만 걸었다.
출구 노드까지 HTTPS로 갔는데, 같은 시간대에 입구와 출구의 트래픽을 모두 관찰하는 감시자가 있다.

읽는 법: 공통점은 "Tor 바깥의 요인"이라는 것입니다. 양파 암호화는 완벽하게 작동했는데도, 로그인 습관·브라우저 지문·양단 관찰이 신원을 드러냅니다. 익명성은 도구의 속성이 아니라 운영 습관 전체의 속성입니다.

스스로 평가할 때의 기준을 하나 잡아 두세요. "이 행동이 평소의 나와 연결되는가?"입니다. 1번은 계정으로 연결되고, 2번은 브라우저 지문과 로그인 쿠키로 연결되고, 3번은 시각의 상관으로 연결됩니다. 셋 다 기술을 뚫은 게 아니라 연결 고리를 남긴 것입니다.

3-5. 방어적 활용 — 왜 우리가 이걸 아는가

이 기술들을 "공격자의 숨는 법"으로만 읽으면 절반입니다. 방어자 입장에서는 이렇게 뒤집힙니다.

침해 사고 로그의 IP가 프록시/Tor 출구인지 확인하는 것이 추적의 첫 단계입니다(공개된 Tor 출구 목록은 존재합니다).
"공격자가 프록시를 썼다 = 못 잡는다"가 아닙니다. 체인의 어느 고리가 로그를 남겼는지, 행동 습관이 어디서 새었는지를 찾는 것이 추적의 실체입니다.
리버스 프록시는 여러분의 서버를 지키는 정당한 방패입니다 — 실무에서 WAF, 부하 분산의 기초 체력이 됩니다.

3-6. 직접·VPN·Tor 비교표 채우기

마지막 훈련입니다. 세 접속 방식을 같은 자로 재어 봅니다. 표를 베끼지 말고 먼저 채운 뒤 대조하세요.

기준	직접 접속	상용 VPN	Tor
서버가 보는 IP	내 IP	VPN 출구 IP	Tor 출구 IP
통신사가 아는 것	목적지 전부	"VPN을 쓴다"는 사실	"Tor를 쓴다"는 사실
전체를 아는 자	없음(대신 통신사가 경로를 봄)	VPN 회사	없음(셋으로 분산)
속도	빠름	약간 느림	느림
신뢰 지점	통신사·경로 전체	VPN 회사 한 곳	없음(분산)

읽는 법: "어느 쪽이 무조건 안전한가"가 아니라 "신뢰를 누구에게 얼마나 주는가"가 다릅니다. VPN은 통신사 대신 회사 한 곳에 몰아 주는 선택, Tor는 아무에게도 전부를 주지 않는 선택, 직접 접속은 그 둘 다 안 하는 선택입니다. 목적(업무 망 접속인가, 검열 우회인가, 신원 보호인가)에 따라 정답이 달라지는 이유가 이 표에 있습니다.

4. 미션과 연습문제

미션 — 익명성 평가 리포트

3-2의 세 구조도를 직접 그리고, 각 그림 아래에 "서버가 아는 것 / 대리인이 아는 것" 두 줄을 적으세요.
3-3의 표를 빈칸부터 다시 채우세요(보지 않고). 다 채운 뒤 본문과 대조해 틀린 칸에 이유를 주석으로 다세요.
가상 시나리오: "여러분의 회사 로그에 같은 계정 탈취 시도가 Tor 출구 IP 30개에서 들어왔다." 이 공격을 추적할 때 확인할 것 세 가지를 적으세요.
무료 프록시 서비스를 "절대 쓰면 안 되는 용도"와 "그래도 되는 용도"로 나누어, 3-1의 로그를 근거로 판단 기준을 세우세요.

연습문제

문제 1. 포워드 프록시와 리버스 프록시를 "누가 대리인을 고르는가"의 관점으로 구별하고, 각각의 대표 용도를 하나씩 드세요.

문제 2. 프록시 1개의 근본적 약점은 무엇이며, Tor는 그것을 어떤 구조로 해결하나요? 해결 뒤에 입구 노드와 출구 노드가 각각 아는 것은 무엇인가요?

문제 3. Tor를 써도 평문 HTTP는 위험합니다. 어느 구간에서 누구에게 내용이 노출되나요?

문제 4. "Tor를 썼는데 잡혔다"는 사례의 대부분은 암호가 뚫린 것이 아닙니다. 기술 외 요인으로 신원이 드러나는 경로를 두 가지 이상 드세요.

5. 모범 답안과 완료 기준

미션 모범 답안

2번: 표의 핵심 칸은 출구 노드 행입니다 — 목적지 "안다", 평문 내용 "안다", 나의 IP "모른다". 그리고 ISP 행의 "내가 Tor를 쓴다는 사실 자체는 보인다"를 빠뜨리기 쉽습니다. Tor 사용은 내용이 아니라 메타데이터의 문제이고, 그것이 Step 85의 교훈(암호화는 내용만 가린다)과 정확히 이어집니다.

3번 답 예: ① 각 IP가 공개 Tor 출구 목록에 있는지 확인하고, 있다면 "최종 홉"일 뿐임을 전제. ② 시간대·타깃 계정·요청 패턴의 공통점으로 "같은 공격자의 세션"인지 묶기(행동 지문). ③ 출구 이전의 단서는 직접 못 얻으므로, 방어 쪽으로 전환 — 해당 계정의 추가 인증(MFA) 강제와 알림. 추적이 안 되면 차단과 탐지로 이동하는 것이 실무의 순서입니다.

4번 기준 예: 3-1에서 봤듯 무료 프록시는 평문 요청의 전부를 볼 수 있으므로, 로그인·개인정보·결제가 오가는 통신에는 절대 쓰지 않습니다. 반대로 공개 페이지의 단순 조회처럼 "읽혀도 되는 내용"이면 위험이 관리됩니다. 판단 기준은 한 줄입니다 — 이 프록시가 내용을 전부 읽는다고 가정해도 괜찮은가.

검증하는 법: ① 구조도마다 "누가 무엇을 아는가"가 적혔는가. ② 표에서 출구 노드의 평문 노출을 정확히 표시했는가. ③ 시나리오 답변이 "추적 불가"로 끝나지 않고 방어 전환까지 갔는가. ④ 프록시 판단 기준이 Step 132의 실측 로그에 근거하는가.

연습문제 해답

문제 1 해답. 클라이언트가 고르는 대리인이 포워드 프록시(용도: 내 IP 숨기기, 망 우회, 트래픽 검사), 서버가 고르는 대리인이 리버스 프록시(용도: 부하 분산, 서버 은폐, TLS 종료)입니다. 이름의 방향은 "누구의 앞에 서는가"로 기억하세요.

문제 2 해답. 프록시 1개는 나와 목적지를 둘 다 알기 때문에, 그 프록시의 로그(또는 협조) 하나로 익명성이 무너집니다. Tor는 대리인을 셋으로 나눠 어느 하나도 전체 그림을 못 보게 합니다. 입구 노드는 나의 IP를 알고 목적지를 모르고, 출구 노드는 목적지를 알고 나의 IP를 모릅니다. 중계 노드는 둘 다 모릅니다.

문제 3 해답. 출구 노드에서 목적지 서버까지의 구간은 일반 인터넷이므로, 그 구간이 평문이면 출구 노드 운영자(와 그 구간의 감청자)가 내용을 읽을 수 있습니다. Tor 내부 구간의 암호화와 무관하게, 출구 밖의 마지막 구간은 별개의 보호(HTTPS)가 필요합니다.

문제 4 해답. ① 익명 접속 상태에서 평소 계정에 로그인하는 행동 실수, ② 브라우저 핑거프린팅(평소 브라우저의 고유한 설정 조합), ③ 입출구 양단의 타이밍 상관 분석, ④ 악성코드나 플러그인이 Tor를 우회해 직접 연결하는 누출. 공통점은 양파 암호화가 아니라 그 바깥이 무너졌다는 것입니다.

완료 기준 체크리스트

[ ] 포워드/리버스 프록시를 "누가 고르는가"로 구별할 수 있다
[ ] 프록시가 IP를 숨겨 주는 대신 모든 요청을 본다는 것을 Step 132 실측으로 설명할 수 있다
[ ] HTTP 프록시와 SOCKS 프록시의 차이를 설명할 수 있다
[ ] Tor의 입구/중계/출구 노드가 각각 아는 것을 표로 그릴 수 있다
[ ] 평문 HTTP + Tor 조합이 왜 위험한지 설명할 수 있다
[ ] 익명성을 무너뜨리는 기술 외 요인을 세 가지 이상 들 수 있다
[ ] 직접 접속·VPN·Tor를 "누가 무엇을 아는가"로 비교할 수 있다

6. 흔한 실수와 해결

벽 1. "프록시를 쓰면 완전히 안전한 거 아닌가요?"

증상: 무료 프록시 목록에서 하나 골라 은행 사이트에 접속하려 합니다.
원인: "서버가 나를 모른다"와 "아무도 나를 모른다"를 혼동하고 있습니다. 프록시 운영자는 여러분의 IP와 모든 요청을 봅니다 — 3-1의 로그가 그 증거입니다.
해결: 신뢰할 수 없는 프록시에는 "읽혀도 되는 트래픽"만 보내세요. 로그인·결제가 섞인 통신은 신뢰할 수 있는 출구(자기 VPN, 회사 공식 프록시)만 거쳐야 합니다.

벽 2. "무료 프록시에 연결했는데 아무것도 안 돼요"

증상: proxychains가 타임아웃만 반복합니다.
원인: 무료 프록시 목록의 상당수는 죽어 있거나, 살아 있어도 함정(내용을 보거나 바꾸는 악성 프록시)일 수 있습니다.
해결: 여러 개를 시도하되, 그 과정 자체가 교훈임을 기억하세요 — "무료 대리인"의 신뢰성이 이 정도라는 것이 오늘 배우는 한계입니다. 학습 목적이라면 직접 만든 로컬 프록시(Step 132)가 더 좋은 선생입니다.

벽 3. "Tor를 켰는데 엄청 느려요"

증상: 페이지가 몇 배로 늦게 뜹니다.
원인: 정상입니다. 트래픽이 세 대의 자원봉사 릴레이를 거쳐 전 세계를 돕니다. 지연은 익명성의 가격입니다.
해결: 고치는 문제가 아닙니다. 속도가 필요한 작업과 익명성이 필요한 작업을 분리하는 것이 답입니다.

벽 4. "Tor 브라우저에 확장 프로그램을 깔았어요"

증상: 편의를 위해 평소 쓰던 확장을 추가합니다.
원인: 확장은 Tor 브라우저의 신중한 기본 설정(핑거프린트 저항)을 깨고, 확장 고유의 통신으로 신원이 샐 수 있습니다.
해결: Tor 브라우저는 받은 그대로 씁니다. "설정을 바꾸는 순간 나만의 지문이 된다"는 것이 핑거프린팅의 핵심 원리입니다.

벽 5. "체인을 길게 하면 무조건 더 안전한가요?"

증상: 프록시를 7개쯤 엮으면 완벽할 것 같습니다.
원인: 고리가 늘수록 추적은 어려워지지만, 그 고리들을 전부 신뢰해야 하고 지연도 쌓입니다. 그리고 가장 약한 고리 — 보통 마지막 출구나 내 행동 습관 — 이 전체 강도를 결정합니다.
해결: "개수"가 아니라 "각 고리를 누가 운영하는가"와 "내 습관이 새는 곳은 없는가"로 평가하세요. Tor의 3개가 정답으로 자리 잡은 이유는 강도와 지연의 균형 때문입니다.

벽 6. "VPN 위에 Tor까지 쓰면 완벽하지 않나요?"

증상: 익명성 도구를 전부 겹쳐 쓰고 싶습니다.
원인: 겹침은 관찰자에게 보이는 그림을 바꿀 뿐 0이 아닙니다. VPN 위에 Tor를 쓰면 통신사 대신 VPN 회사가 "이 사용자가 Tor를 쓴다"를 알게 되고, 지연은 두 도구분이 쌓입니다.
해결: 조합 전에 질문을 바꾸세요 — "무엇을 더 겹칠까"가 아니라 "내가 막고 싶은 관찰자가 누구인가". 3-6의 표에서 그 관찰자가 있는 행을 보고 필요한 한 겹을 고르는 것이 정석입니다. 겹침은 취미가 아니라 위협 모델의 답입니다.

7. 정리

오늘의 개념

개념	한 줄 설명
포워드 프록시	클라이언트의 대리인 — 서버에게 내 IP를 숨김, 대신 프록시는 전부 봄
리버스 프록시	서버의 대리인 — 진짜 서버를 뒤에 숨기고 앞에서 응답
HTTP / SOCKS 프록시	웹만 중계 / 어떤 TCP든 중계
프록시 체인	대리인을 여럿 엮어 추적에 필요한 로그를 분산
proxychains	체인 순서를 설정 파일대로 조립해 주는 도구
Tor	입구-중계-출구 3중 릴레이 — 어느 노드도 전체를 모르게
양파 라우팅	노드 수만큼 겹쳐 암호화 — 각자 자기 껍질만 벗김
출구 노드	목적지와 평문 내용을 볼 수 있는 마지막 고리
핑거프린팅	브라우저 설정 조합이 만드는 지문 — IP 없이도 식별
타이밍 분석	입출구 양단 관찰로 흐름을 짝짓는 추적
VPN	장비의 모든 트래픽을 출구 서버까지 암호화 — 신뢰를 회사 한 곳에 모으는 선택
위협 모델	"누구의 관찰을 막을 것인가"를 정하는 질문 — 도구 선택의 출발점

오늘의 도구·명령

항목	하는 일
Step 132 미니 프록시	"프록시는 전부 본다"를 직접 실측한 도구
`/etc/proxychains.conf`	프록시 체인의 순서를 적는 설정 파일
`proxychains 명령어`	임의 프로그램의 트래픽을 체인으로 보내기
Tor 브라우저	3중 릴레이 + 핑거프린트 저항이 기본값인 전용 브라우저
브라우저 개발자 도구(F12)	응답 헤더와 요청 흐름 관찰 — 프록시 동작 확인에도 사용

명령어보다 중요한 감각

오늘의 요약은 한 문장입니다. 익명성은 도구가 주는 것이 아니라, 도구와 습관의 곱셈입니다. 세계 최고의 양파 라우팅 위에서 평소 계정에 로그인하면 곱셈의 한 항이 0이 됩니다. 반대로 방어자에게는 희망이 같은 자리에 있습니다 — 암호는 못 풀어도, 공격자의 습관은 새어 나옵니다.

그리고 대리인의 법칙을 기억하세요. 대리인은 나를 대신해 주는 대가로 나를 봅니다. 무료 프록시 한 줄의 편리함 뒤에 무엇을 내주는지, 3-1의 로그를 떠올릴 수 있다면 오늘의 목표는 달성입니다.

마지막으로, 오늘 배운 구조는 숨는 사람만의 것이 아닙니다. 리버스 프록시로 서버를 지키고, 로그의 출구 IP를 읽어 추적의 실마리를 찾고, "익명성은 곱셈"이라는 사실로 사고 조사의 방향을 정하는 것 — 전부 같은 지도의 다른 읽기입니다. 공격과 방어가 한 장의 지도를 공유한다는 것, 이 단원 전체의 주제가 오늘의 챕터에도 그대로 들어 있습니다.

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