Chapter 22

네트워크 보안

카페 Wi-Fi에 접속해 은행 앱을 연다. 옆자리 사람도, 카페 공유기도, 통신사도 내 패킷이 지나가는 길 위에 있다. 그런데도 비밀번호가 새지 않는 이유는 무엇일까? 한 번도 만난 적 없는 은행 서버와 어떻게 비밀 열쇠를 나눠 가졌고, 그 서버가 진짜 은행이라는 건 어떻게 알았을까? 이 장에서는 인터넷이라는 “누구나 들여다볼 수 있는 길” 위에서 비밀과 신뢰를 지키는 기술을 살펴본다.

도청·변조·사칭·마비라는 네 가지 위협과 각각을 막는 보안 목표를 구분한다.
대칭키 암호, 공개키 암호, 해시와 메시지 인증 코드가 각각 어디에 쓰이는지 안다.
디피-헬먼 키 교환으로 도청자 앞에서 비밀을 만드는 원리를 직접 계산해 본다.
TLS 1.3 핸드셰이크와 인증서 체인이 HTTPS 자물쇠를 만드는 과정을 따라간다.
방화벽 규칙의 “첫 일치” 원리와 상태 저장 방화벽, VPN 터널, 제로 트러스트를 이해한다.
DDoS 증폭 공격의 규모를 계산하고 애니캐스트 분산 방어가 왜 통하는지 안다.
Wi-Fi·DNS·BGP 보안의 약점과 포스트 양자 암호로의 전환을 개관한다.

위협 모델: 누가 무엇을 할 수 있나

보안은 “무엇으로부터 지키는가”를 정하는 데서 시작한다. 이를 위협 모델이라 한다. 네트워크에서 일어나는 공격은 크게 네 가지로 나눌 수 있고, 각각에 대응하는 보안 목표가 있다.

위협	공격자가 하는 일	지켜야 할 것	택배 비유	대표 방어
도청	지나가는 패킷을 몰래 읽는다	기밀성(confidentiality)	배송 기사가 상자를 열어 본다	암호화
위조·변조	내용을 바꾸거나 가짜를 끼워 넣는다	무결성(integrity)	상자 속 물건을 바꿔치기	해시, 메시지 인증 코드, 서명
사칭	다른 사람·서버인 척한다	인증(authentication)	택배 기사를 사칭해 물건을 가로챔	인증서, 비밀번호, 디지털 서명
마비	트래픽 폭탄으로 서비스를 멈춘다	가용성(availability)	가짜 주문 수백만 건으로 물류센터 마비	DDoS 방어, 분산, 용량

인터넷의 기본 설계(7장의 IP)는 이 중 어느 것도 보장하지 않는다. 패킷은 엽서처럼 내용이 그대로 보이고, 보내는 주소는 마음대로 적을 수 있으며, 누구든 패킷을 보낼 수 있다. 보안은 처음부터 있던 기능이 아니라 그 위에 덧붙여 온 기능이다. 그래서 “길 위의 누구도 믿지 않는다”는 가정에서 출발한다.

그림 22-1. 공용 Wi-Fi에서 내 패킷은 같은 무선망의 다른 사용자, 공유기 운영자, 통신사, 인터넷의 여러 망을 지난다. 암호화는 “내용”을 감추지만, “누구와 언제 얼마나 통신하는지”(메타데이터)는 상당 부분 남는다.

암호의 세 가지 도구

네트워크 보안의 거의 모든 것은 세 가지 도구의 조합이다.

대칭키 암호(symmetric-key cipher): 잠그는 열쇠와 여는 열쇠가 같다. 대표는 AES(2001년 표준)와 ChaCha20. 매우 빠르다. 요즘 CPU는 AES 전용 명령이 있어 코어 하나로 초당 수 GB를 암호화한다. 문제는 “같은 열쇠를 상대에게 어떻게 안전하게 건네는가”다.
공개키 암호(public-key cryptography): 열쇠가 한 쌍이다. 공개키는 모두에게 알려 주고, 개인키는 나만 가진다. 공개키로 잠근 것은 개인키로만 열리고, 개인키로 “서명”한 것은 공개키로 누구나 검증할 수 있다. 대표는 RSA와 타원곡선 암호(ECC). 대칭키보다 수백~수천 배 느려서 열쇠 교환과 서명에만 쓴다.
해시 함수(hash function): 임의 길이의 데이터를 고정 길이 “지문”(SHA-256은 256비트)으로 바꾼다. 한 비트만 바뀌어도 지문이 완전히 달라지고, 지문에서 원본을 거꾸로 찾을 수 없다. 여기에 비밀 열쇠를 섞으면 메시지 인증 코드(MAC, HMAC)가 된다. 열쇠를 아는 사람만 올바른 코드를 만들 수 있으므로, 받은 메시지가 중간에 바뀌지 않았고 열쇠를 가진 상대가 보냈음을 확인한다.

도구	대표 알고리즘	열쇠 길이(같은 안전 수준)	쓰임
대칭키 암호	AES-128/256, ChaCha20	128비트	실제 데이터 암호화(TLS 본문, VPN, 디스크)
공개키 (RSA)	RSA-3072	3,072비트	인증서 서명, (옛) 열쇠 전달
공개키 (타원곡선)	X25519, ECDSA P-256, Ed25519	256비트	열쇠 교환, 서명 (요즘의 주력)
해시 / MAC	SHA-256, HMAC-SHA256	출력 256비트	무결성 검사, 서명의 재료, 비밀번호 저장
인증 암호화(AEAD)	AES-GCM, ChaCha20-Poly1305	128~256비트	암호화 + 무결성을 한 번에 (TLS 1.3의 유일한 방식)

표의 “같은 안전 수준”은 미국 NIST 권고 기준이다. 128비트 대칭키를 무차별 대입하려면 2¹²⁸ ≈ 3.4×10³⁸번을 시도해야 한다. 초당 10¹⁸번을 시도하는 가상의 컴퓨터로도 우주 나이의 수백억 배가 걸린다. 그래서 현실의 공격은 암호 자체보다 열쇠 관리, 구현 실수, 사람을 노린다.

열쇠 배달 문제

대칭키 암호는 빠르고 튼튼하지만, 앨리스와 밥이 같은 열쇠를 미리 나눠 가져야 한다. 처음 접속하는 웹사이트와는 열쇠를 나눌 방법이 없다. 열쇠를 인터넷으로 보내면 도청자도 함께 받는다. 1976년 디피와 헬먼이 이 문제의 답을 내놓았다. 도청자가 모든 대화를 엿들어도, 두 사람만 아는 비밀을 만들어 내는 방법이다.

디피-헬먼: 엿듣는 사람 앞에서 비밀 만들기

물감 섞기

앨리스와 밥이 공개적으로 “노란색”을 공통 물감으로 정한다(도청자 이브도 안다). 각자 아무에게도 보이지 않는 비밀 물감(앨리스는 빨강, 밥은 파랑)을 골라 노랑에 섞은 뒤, 섞은 통을 서로 교환한다. 이브는 “노랑+빨강”과 “노랑+파랑” 통을 본다. 앨리스는 받은 “노랑+파랑”에 자기 빨강을 더하고, 밥은 받은 “노랑+빨강”에 자기 파랑을 더한다. 둘 다 “노랑+빨강+파랑”이라는 같은 색을 얻는다. 섞인 물감을 다시 분리하는 일은 아주 어렵기 때문에, 이브는 그 색을 만들 수 없다.

수학에서 “섞기는 쉽고 분리는 어려운” 연산이 모듈러 거듭제곱이다. 소수 p와 생성원 g를 공개한다. 앨리스는 비밀 수 a를 골라 A = g^a mod p를 보내고, 밥은 비밀 b로 B = g^b mod p를 보낸다. 앨리스는 B^a mod p를, 밥은 A^b mod p를 계산하는데, 둘 다 g^ab mod p로 같다. 이브는 p, g, A, B를 모두 알지만 A에서 a를 되찾는 일(이산 로그 문제)은 p가 크면 사실상 불가능하다.

공유 비밀 = B^a mod p = (g^b)^a mod p = g^ab mod p = (g^a)^b mod p = A^b mod p

“mod p”는 p로 나눈 나머지. 시계 바늘이 12를 넘으면 다시 0부터 도는 것과 같은 “나머지 세계”의 계산이다.

SIMULATOR

디피-헬먼 키 교환: 앨리스, 밥, 그리고 이브

공개 소수 p (생성원 g는 자동)

앨리스의 비밀 a 밥의 비밀 b

앨리스가 계산한 비밀—

밥이 계산한 비밀—

이브의 시도—

실제 크기라면—

가운데 줄은 이브가 엿볼 수 있는 공개 통로다. 이브는 p, g, A, B를 다 보지만 a와 b는 끝까지 “?”다. 해볼 것: “이브의 무차별 대입”을 눌러 g^x mod p = A가 되는 x를 하나씩 찾게 해 보자. p = 23이면 순식간이지만, p가 커질수록 시도 횟수가 p에 비례해 늘어난다. 실제 TLS는 2048비트 이상의 소수나 256비트 타원곡선(X25519)을 쓰고, 가장 좋은 알고리즘으로도 약 2¹¹²~2¹²⁸번의 연산이 필요하다. 단순화: 여기서 이브는 가장 단순한 방법(하나씩 대입)만 쓴다.

디피-헬먼만으로는 부족하다: 중간자 공격

이브가 엿듣기만 하는 게 아니라 길 한가운데서 패킷을 가로채고 바꿀 수 있다면? 앨리스와는 이브가 밥인 척, 밥과는 앨리스인 척 각각 키 교환을 하면 된다. 이를 중간자 공격(man-in-the-middle)이라 한다. 키 교환은 “누구와” 비밀을 나눴는지 알려 주지 않는다. 그래서 서버는 자기 공개값에 서명을 하고, 그 서명용 공개키가 진짜 서버의 것임을 인증서로 증명한다. 다음 절의 TLS가 바로 이 조합이다.

예측해 보기

p를 23에서 7919로 바꾸면 이브가 a를 찾기 위한 평균 시도 횟수는 대략 몇 배가 될까?

디피-헬먼 시뮬레이터에서 p를 바꿔 가며 “이브의 무차별 대입”을 몇 번 눌러 보자.

하나씩 대입하면 평균 시도 횟수는 p/2 정도로 p에 비례한다. 7919/23 ≈ 344배다. 비트로 보면 소수가 1비트 길어질 때마다 일이 두 배가 된다. 실제로 쓰는 2048비트 소수라면 단순 대입은 10⁶⁰⁰번이 넘고, 가장 영리한 알고리즘으로도 2¹¹²번 수준이라 사실상 불가능하다.

TLS 1.3: HTTPS 자물쇠가 만들어지는 1 왕복

웹 주소창의 자물쇠는 TLS(Transport Layer Security) 연결이 맺어졌다는 뜻이다. TLS는 TCP(9장)나 QUIC 위에서 동작하며, 위의 세 도구를 이렇게 엮는다. ① 디피-헬먼(타원곡선 X25519 등)으로 열쇠를 나누고, ② 서버가 인증서와 서명으로 자기가 진짜임을 증명하고, ③ 이후 모든 데이터를 AES-GCM이나 ChaCha20-Poly1305로 암호화하고 변조를 검사한다.

2018년에 표준이 된 TLS 1.3(RFC 8446)은 이 과정을 1 왕복(1-RTT)으로 줄였다. 클라이언트가 첫 메시지(ClientHello)에 “아마 이 방식을 쓰겠지” 하고 키 교환용 공개값(key_share)을 미리 넣어 보내기 때문이다. 이전의 TLS 1.2는 2 왕복이 필요했다. 다시 접속할 때는 이전 세션 열쇠로 첫 메시지부터 데이터를 싣는 0-RTT도 가능하다(단, 재전송 공격 위험이 있어 안전한 요청에만 쓴다).

SIMULATOR

핸드셰이크 한 단계씩: TLS 1.2 vs TLS 1.3 vs QUIC

프로토콜

서버까지 왕복 시간(RTT)

첫 응답까지 왕복 수—

첫 응답까지 시간—

암호화가 시작되는 시점—

왼쪽은 브라우저, 오른쪽은 서버, 아래로 갈수록 시간이 흐른다. 실선 화살표는 평문, 굵은 보라색 화살표는 암호화된 메시지다. TLS 1.3에서는 ServerHello 바로 다음부터, 즉 인증서까지 암호화된다. 해볼 것: RTT를 200 ms(지구 반대편)로 올리고 세 방식을 비교해 보자. 왕복 하나를 줄이는 것이 왜 중요한지 보인다. 단순화: 세션 재개(0-RTT), TCP 패킷 손실, 인증서 검증 시간은 뺐다.

인증서 체인: “이 서버가 진짜”라는 보증

서버가 보내는 인증서(certificate, X.509)에는 도메인 이름, 서버의 공개키, 유효 기간이 적혀 있고, 이것을 인증 기관(CA, certificate authority)이 개인키로 서명했다. 브라우저는 서명을 따라 올라가서 운영체제·브라우저에 미리 들어 있는 루트 인증서(신뢰 저장소, 약 100~150개 기관)에 닿으면 믿는다. 인증서 유효 기간은 점점 짧아져서, 무료로 자동 발급하는 Let’s Encrypt는 90일짜리를 쓰고 업계 전체도 단계적으로 47일까지 줄이기로 했다.

그림 22-2. 인증서 체인. 화살표는 “이 인증서는 저 인증서의 공개키로 검증한다”는 뜻이다. 루트 CA의 개인키는 오프라인 금고에 보관하고, 실제 발급은 중간 CA가 한다.

ClientHello에는 접속하려는 도메인 이름이 담긴 SNI(Server Name Indication)가 평문으로 들어 있다. IP 주소 하나에 수천 개 사이트가 있는 CDN(10장)이 어느 인증서를 보낼지 알아야 하기 때문이다. 이 때문에 통신사나 검열 장비는 HTTPS여도 “어느 사이트에 가는지”는 볼 수 있었다. 이를 감추는 ECH(Encrypted Client Hello)가 표준화되어 보급되는 중이다.

HTTPS 자물쇠가	내용
보장하는 것	주소창의 도메인을 가진 서버와 통신 중이다(인증). 경로 위의 누구도 내용을 읽을 수 없다(기밀성). 오가는 데이터가 바뀌면 즉시 들통난다(무결성). 열쇠는 매번 새로 만들어, 나중에 서버 개인키가 털려도 지난 대화는 풀 수 없다(전방 비밀성).
보장하지 않는 것	그 사이트가 착한 사이트라는 것. 피싱 사이트 `bank-example-login.com`도 정상 인증서를 무료로 받는다. 서버에 저장된 데이터의 안전, 내 PC의 악성코드, 접속 사실 자체(IP·SNI·시간)도 지켜 주지 않는다.

방화벽: 들어오고 나가는 상자 검사

방화벽(firewall)은 망과 망 사이에서 규칙에 따라 패킷을 통과시키거나 버리는 장비(또는 소프트웨어)다. 건물 경비실처럼 “누가, 어디로, 어떤 문(포트)으로” 가는지 보고 판단한다. 세대에 따라 볼 수 있는 깊이가 다르다.

종류	보는 것	판단 예	한계
패킷 필터 (1980년대~)	패킷 하나의 IP·포트·프로토콜 (3·4계층)	“외부 → 22번 포트 거부”	앞뒤 맥락을 모른다. 응답 패킷을 허용하려면 구멍을 넓게 뚫어야 한다
상태 저장 (1990년대~)	+ 연결 상태 표(누가 먼저 시작했나)	“안에서 시작한 연결의 응답만 허용”	허용된 포트(443) 안에서 무슨 일이 일어나는지는 모른다
차세대(NGFW) (2010년대~)	+ 응용 계층(7계층): 앱 종류, 사용자, 악성 패턴	“443이라도 파일 공유 앱은 차단”, 침입 방지(IPS)	암호화 트래픽은 TLS 검사(복호화)를 해야 보이고, 처리 비용이 크다

방화벽 규칙은 목록이다. 패킷이 오면 위에서부터 차례로 비교해 처음 맞는 규칙 하나만 적용하고 멈춘다(첫 일치). 맨 아래에는 보통 “나머지는 모두 거부”라는 기본 거부 규칙이 있다. 허용할 것만 명시하고 나머지는 막는 것이 안전한 기본값이다. 상태 저장 방화벽(stateful firewall)은 규칙을 보기 전에 “이미 허용된 연결의 일부인가?”를 먼저 확인한다(연결 추적 표). 그래서 서버가 바깥 DNS 서버에 물어본 질문의 답은 별도 규칙 없이도 들어온다.

SIMULATOR

방화벽 규칙 편집기: 위에서부터 첫 일치

상태 저장(연결 추적) 켜기

정책대로 처리된 패킷—

허용 / 거부—

상황—

우리 웹 서버(10.0.0.10) 앞의 방화벽이다. 아래 테스트 패킷을 누르면 걸린 규칙이 강조된다. 각 패킷 오른쪽의 ✓/✗는 “원하는 정책(웹은 공개, SSH는 사내에서만, 나머지는 차단, 내가 보낸 요청의 응답은 허용)”과 맞는지를 뜻한다. 해볼 것: ① 상태 저장을 끄면 DNS 응답이 막힌다. 이를 고치려고 “허용 · 모든 곳 · UDP · 모든 포트”를 추가하면? 요청한 적 없는 위조 UDP까지 들어온다. ② “거부 · 모든 곳 · 모두 · 모든 포트”를 맨 위로 올려 보자.

예측해 보기

규칙 1번이 “허용 · 모든 곳 · TCP · 22”이고 규칙 2번이 “거부 · 외부 · TCP · 22”라면, 외부에서 22번 포트로 들어오는 SSH 패킷은?

방화벽 시뮬레이터에서 규칙을 그렇게 바꾸고 외부 SSH 패킷을 눌러 보자.

방화벽 규칙은 대부분 “위에서부터 첫 일치”다. 더 구체적이든 아니든 먼저 맞은 규칙으로 끝난다. 그래서 좁은 예외(거부)는 넓은 허용보다 위에 두어야 한다. 실제 사고의 상당수가 이런 순서 실수에서 나온다. (라우팅 테이블의 최장 접두사 일치(8장)와 헷갈리지 말자.)

VPN과 제로 트러스트

VPN(Virtual Private Network)은 공용 인터넷 위에 암호화된 터널을 뚫어, 멀리 떨어진 두 망이 마치 전용선으로 연결된 것처럼 쓰게 한다. 원리는 3장의 캡슐화를 한 번 더 하는 것이다. 원래 패킷(사내 주소가 적힌)을 통째로 암호화한 뒤, 바깥에 공인 IP가 적힌 새 봉투를 씌워 보낸다. 길 위의 라우터는 바깥 봉투만 보고 배달하고, 터널 끝의 장비가 봉투를 벗기고 복호화해 원래 패킷을 사내망에 풀어놓는다.

그림 22-3. VPN 터널의 캡슐화. 봉투 속에 “암호화된 봉투”를 넣는다. IPsec(ESP)도 구조는 같고, 바깥 헤더와 머리말의 형식만 다르다.

IPsec: 1990년대부터 쓰인 IP 계층 표준. 지사와 본사, 회사와 클라우드(21장)를 잇는 사이트 간 VPN의 표준처럼 쓰인다. 기능이 많고 설정이 복잡하다(IKE로 열쇠 교환, ESP로 암호화).
WireGuard: 2020년 리눅스 커널에 들어간 신세대 VPN. 코드가 약 4,000줄로 아주 작고, 암호 방식을 하나로 고정(Curve25519, ChaCha20-Poly1305)해 설정 실수의 여지를 줄였다. 휴대폰의 개인 VPN 앱과 메시 VPN 서비스가 많이 쓴다.
TLS 기반 VPN: 웹과 같은 443 포트를 써서 방화벽을 잘 통과한다. 회사 원격 근무용 VPN 클라이언트에 많다.

개인 VPN 앱은 무엇을 지켜 주나

상용 VPN 앱을 켜면 카페 공유기와 통신사는 “VPN 서버와 통신 중”이라는 것만 본다. 하지만 그 대신 VPN 회사가 통신사 자리에 서서 내 트래픽의 목적지를 보게 된다. 신뢰의 대상을 옮기는 것이지 없애는 것이 아니다. 대부분의 사이트가 HTTPS인 지금, 공용 Wi-Fi에서 VPN의 이득은 DNS·SNI 같은 메타데이터를 감추는 쪽에 더 가깝다.

성벽에서 검문소로: 제로 트러스트

전통적인 보안은 성과 해자 모델이었다. 방화벽(성벽) 안쪽 사내망은 믿고, 바깥은 믿지 않는다. VPN은 바깥 사람을 성 안으로 들여보내는 비밀 통로다. 문제는 한 번 성 안에 들어온 공격자(피싱으로 털린 노트북 하나)가 내부를 마음대로 돌아다닌다는 것이다. 제로 트러스트(zero trust)는 “망의 위치는 아무것도 보장하지 않는다”는 원칙이다. 사내망 안에서도 모든 요청마다 사용자 신원(다중 인증), 기기 상태, 최소 권한을 확인하고, 앱 하나하나를 따로 연결한다. 구글이 2010년대 초 BeyondCorp로 VPN을 걷어낸 사례가 유명하고, 지금은 많은 기업이 VPN 대신 ID 기반 접근 프록시(ZTNA)를 도입하고 있다.

DDoS: 물량으로 밀어붙이는 공격

DDoS(Distributed Denial of Service, 분산 서비스 거부)는 수많은 기기에서 동시에 트래픽을 쏟아 부어 서비스를 마비시키는 공격이다. 공격자는 보통 해킹한 공유기·IP 카메라·서버 수만~수십만 대로 이루어진 봇넷을 부린다. 겨냥하는 자원에 따라 세 종류로 나뉜다.

종류	노리는 것	예	규모 단위	방어
볼류메트릭	회선 대역폭	UDP 플러드, 반사·증폭(DNS, NTP, memcached)	Tbps	대용량 분산망, 스크러빙, 업스트림 필터
프로토콜	서버·방화벽의 연결 상태 표	SYN 플러드, 조각난 패킷	초당 패킷 수(Mpps~Gpps)	SYN 쿠키, 상태 표 보호
응용 계층	웹 서버의 CPU·DB	HTTP 요청 폭탄, 무거운 검색 반복	초당 요청 수(수천만 rps)	요청 속도 제한, 봇 판별, 캐시

반사·증폭 공격이 특히 무섭다. UDP는 연결 없이 보낸 주소를 믿으므로(9장), 공격자는 보내는 주소를 피해자 IP로 위조해서 인터넷의 열린 서버(DNS 리졸버, NTP 서버 등)에 작은 질문을 보낸다. 서버들은 친절하게도 훨씬 큰 답을 피해자에게 보낸다. 질문 대비 답의 크기가 증폭 공격(amplification attack)의 배수다.

반사에 쓰이는 프로토콜	대략의 증폭 배수 (대역폭 기준)	메모
DNS (열린 리졸버, ANY 질의 등)	28~54배	가장 오래되고 흔한 방식
CLDAP	56~70배	2020년 2.3 Tbps 공격에 쓰였다고 보고됨
NTP (monlist 명령)	약 556배	2014년 대규모 공격 이후 기능 제거
memcached (UDP)	1만~5만 배	2018년 GitHub 1.35 Tbps 공격. 이후 UDP 기본 비활성화

DDoS 기록은 해마다 경신된다. 2018년 1.35 Tbps가 화제였는데, 2024년 말 약 5.6 Tbps, 2025년에는 20 Tbps를 넘는 공격이 여러 차례 보고되어 수십 Tbps 수준에 이르렀다. 대부분 몇십 초~몇 분 동안의 짧은 폭발이다. 이런 공격은 어느 한 회사의 회선으로 버틸 수 없다. 방어의 핵심은 더 큰 망에 흡수시키는 것이다. 수백 개 도시에 같은 IP를 광고하는 애니캐스트(8장의 BGP를 이용)를 쓰면, 전 세계에 흩어진 봇들의 트래픽이 각자 가까운 거점으로 나뉘어 들어간다. 각 거점에서 공격 패킷을 걸러 내는 곳을 스크러빙 센터라 한다.

CALCULATOR

증폭 공격의 규모와 방어 용량

봇 수 봇 하나의 업링크

공격 방식 (증폭 배수)

방어

봇이 보내는 트래픽—

피해자에게 도착—

가장 바쁜 지점의 부하—

결과—

공격 트래픽 = 봇 수 × 업링크 × 증폭 배수. 애니캐스트에서는 봇 분포(아시아 35%, 북미 20%, 유럽 20%, 남미 12%, 중동·아프리카 8%, 오세아니아 5%)대로 공격이 지역별 거점에 나뉜다고 가정했다. 단순화: 실제로는 반사 서버의 수와 회선이 상한이 되어 memcached × 대규모 봇넷 같은 조합은 계산만큼 커지지 않는다. 또 어느 정도 걸러 낸 뒤 남는 트래픽, 응용 계층 공격은 따로 다뤄야 한다. 해볼 것: 봇 1만 대 × 10 Mbps에 DNS 증폭이면 10 Gbps 회선은 몇 배 넘치나? 그 공격을 애니캐스트는 어떻게 버티나?

SYN 플러드와 SYN 쿠키

TCP 3방향 악수(9장)에서 서버는 SYN을 받으면 “반쯤 열린 연결”을 표에 적어 두고 마지막 ACK를 기다린다. 공격자가 가짜 출발지로 SYN만 초당 수백만 개 보내면 이 표가 가득 차 진짜 손님이 못 들어온다. SYN 쿠키(SYN cookie)는 표에 아무것도 적지 않는 묘수다. 서버는 SYN-ACK의 초기 순서 번호에 (상대 주소·포트·시간·비밀 열쇠)의 해시를 담아 보낸다. 진짜 클라이언트는 그 번호+1로 ACK를 돌려주고, 서버는 해시를 다시 계산해 맞으면 그때 연결을 만든다. 상태를 패킷 안에 “쿠키”로 맡겨 두는 셈이다. 리눅스는 표가 넘칠 때 자동으로 이 방식으로 바뀐다.

근본 대책: 출발지 위조 막기

반사 공격은 보내는 주소를 위조할 수 있어서 가능하다. 통신사가 자기 고객망에서 나가는 패킷의 출발지 주소가 실제로 그 고객의 것인지 확인하면(BCP 38, 진입 필터링) 위조가 막힌다. 이 권고가 나온 지 25년이 넘었지만 아직 모든 망이 지키지는 않는다. 그리고 열린 리졸버·memcached 같은 반사 서버를 닫는 것도 모두의 몫이다.

Wi-Fi, DNS, BGP: 기반 시설의 약점

Wi-Fi 보안의 역사

전파(11장)는 벽을 넘어 누구에게나 닿는다. 그래서 무선 랜(13장)은 공기 중의 프레임을 암호화해야 한다. 그 방법은 여러 번 깨지고 고쳐졌다.

방식	도입	암호	상태
WEP	1997	RC4 + 24비트 IV	완전히 깨짐. IV가 짧아 금방 반복되고, 패킷을 모으면 몇 분 안에 열쇠를 알아낸다
WPA2	2004	AES-CCMP, 4방향 핸드셰이크	널리 쓰임. 2017년 KRACK(열쇠 재설치) 취약점은 패치됨. 핸드셰이크를 녹화해 약한 비밀번호를 오프라인으로 대입하는 공격에 약하다
WPA3	2018	SAE(드래곤플라이) 키 교환	비밀번호를 쓰는 디피-헬먼 방식이라 녹화해도 오프라인 대입이 안 된다. 전방 비밀성. Wi-Fi 6E·7(6 GHz)에서는 필수

카페처럼 비밀번호가 모두에게 공개된 망은, 비밀번호를 아는 다른 손님이 이론상 내 트래픽을 엿볼 수 있다(WPA2-PSK에서는 핸드셰이크를 지켜보면 내 세션 열쇠를 계산할 수 있다). 더 흔한 위험은 이블 트윈(evil twin)이다. 공격자가 “Cafe_Free_WiFi”처럼 똑같은 이름의 가짜 공유기를 더 강한 신호로 띄우면 기기가 그쪽에 붙는다. 그러면 공격자가 DNS를 조작하거나 가짜 로그인 페이지를 띄울 수 있다. 방어는 결국 위의 TLS다. HTTPS와 인증서 경고를 무시하지 않는 습관이 가장 큰 방패이고, 민감한 작업은 휴대폰 데이터나 VPN을 쓰는 것이 낫다.

DNS: 주소록을 조작하면

DNS(10장)는 원래 암호화도 서명도 없는 UDP 질의응답이다. 공격자가 리졸버에 가짜 답을 먼저 밀어 넣으면 bank.example이 공격자 IP로 연결된다(DNS 스푸핑, 캐시 중독). 2008년 카민스키 공격 이후 리졸버는 질의마다 출발지 포트를 무작위로 바꿔 추측을 어렵게 했다. 근본 대책은 두 갈래다.

DNSSEC: 도메인 소유자가 DNS 레코드에 서명한다. 루트부터 체인으로 검증하므로 위조를 막는다(무결성). 다만 내용은 여전히 평문이고, 서명된 도메인 비율은 아직 낮은 편이다.
DoT·DoH: 내 기기와 리졸버 사이의 DNS를 TLS(853번 포트)나 HTTPS(443번)로 암호화한다(기밀성). 공용 Wi-Fi나 통신사가 내가 묻는 이름을 보지 못한다. 대부분의 브라우저와 휴대폰 OS가 지원한다.

BGP 하이재킹

8장에서 본 BGP는 이웃이 광고하는 경로를 대체로 믿는다. 어떤 망이 실수나 악의로 남의 주소 블록을 “내가 가장 가까운 길”이라고 광고하면, 인터넷 일부의 트래픽이 그쪽으로 빨려 들어간다. 2008년 파키스탄 통신사가 국내 유튜브 차단을 위해 만든 경로가 전 세계로 새어 나가 유튜브가 두 시간가량 마비된 사건이 대표적이다. 주소 블록의 주인을 서명된 기록으로 확인하는 RPKI와 경로 출처 검증(ROV)이 빠르게 보급되어, 이제 인터넷 경로의 절반 이상이 RPKI로 보호된다.

양자 컴퓨터와 포스트 양자 암호

지금의 공개키 암호(RSA, 디피-헬먼, 타원곡선)는 “소인수분해·이산 로그가 어렵다”는 데 기대고 있다. 그런데 충분히 큰 양자 컴퓨터에서 쇼어 알고리즘을 돌리면 이 문제들이 빠르게 풀린다. 그런 양자 컴퓨터는 아직 없지만, 공격자가 오늘 암호문을 녹화해 두었다가 10~20년 뒤에 푸는 “지금 수집, 나중에 해독(harvest now, decrypt later)”은 지금 당장의 위협이다. 반면 AES 같은 대칭키 암호와 해시는 양자 컴퓨터로도 대략 열쇠 길이가 절반이 되는 효과뿐이라, AES-256을 쓰면 충분하다고 본다.

그래서 양자 컴퓨터로도 풀기 어려운 수학 문제(격자 문제 등)에 기반한 포스트 양자 암호(PQC, post-quantum cryptography)로 옮겨 가는 중이다. 미국 NIST는 2024년 8월 첫 표준을 확정했다. 열쇠 교환용 ML-KEM(FIPS 203, 옛 이름 Kyber)과 서명용 ML-DSA(FIPS 204), SLH-DSA(FIPS 205)다.

새 알고리즘을 바로 단독으로 믿기는 이르므로, TLS는 하이브리드 키 교환을 쓴다. 기존의 X25519와 ML-KEM-768을 동시에 수행해 두 비밀을 섞는다. 둘 중 하나만 안전해도 결과가 안전하다. 크롬·파이어폭스 등 주요 브라우저와 대형 CDN이 2024년부터 이를 기본으로 켜서, 2025년에는 주요 CDN에 들어오는 브라우저 TLS 연결의 상당 부분(절반 가까이)이 이미 양자 내성 키 교환을 쓴다. 대가는 크기다. ML-KEM의 공개값은 1 KB 남짓으로 X25519(32바이트)보다 훨씬 커서, ClientHello가 패킷 하나에 안 들어가는 경우가 생긴다.

핵심 정리

네트워크 위협은 도청·변조·사칭·마비이고, 각각 기밀성·무결성·인증·가용성으로 막는다. 인터넷 기본 설계는 어느 것도 보장하지 않는다.
대칭키 암호(AES)는 빠르지만 열쇠 배달이 문제이고, 공개키 암호(RSA, ECC)는 느리지만 열쇠 교환과 서명을 푼다. 해시·MAC은 변조를 잡는다.
디피-헬먼은 g^a, g^b만 공개해 도청자 앞에서 g^ab라는 비밀을 만든다. 하지만 상대가 누군지는 알려 주지 않아 인증서가 필요하다.
TLS 1.3은 키 공유를 첫 메시지에 실어 1-RTT로 연결하고, 인증서 체인으로 서버를 검증한다. 자물쇠는 “그 도메인과 안전하게 통신 중”일 뿐 “착한 사이트”를 보증하지 않는다.
방화벽은 위에서부터 첫 일치 규칙을 적용하며, 상태 저장이면 내가 시작한 연결의 응답만 안전하게 들인다. VPN은 암호화한 패킷을 새 봉투에 넣는 터널이고, 제로 트러스트는 망 위치 대신 매 요청의 신원을 검증한다.
DDoS는 반사·증폭으로 수십 Tbps에 이른다. 애니캐스트로 전 세계 거점에 나눠 흡수하고, SYN 쿠키·출발지 위조 차단 등으로 막는다.
Wi-Fi는 WEP → WPA2 → WPA3(SAE)로, DNS는 DNSSEC·DoH/DoT로, BGP는 RPKI로 보강 중이며, 공개키 암호는 ML-KEM 하이브리드로 양자 시대를 준비한다.

확인 퀴즈

공격자가 송금 요청 패킷의 계좌 번호를 바꿔치기했다. 어떤 보안 목표가 깨진 것이고, 무엇이 이를 잡아내는가?

내용을 바꾸는 공격은 무결성 문제다. 열쇠를 섞은 MAC이나 AES-GCM 같은 인증 암호화의 태그는 한 비트만 바뀌어도 검증에 실패한다. 암호화만으로는 변조를 막지 못한다.

디피-헬먼 키 교환에서 도청자 이브가 알 수 없는 값은?

p, g, A, B는 모두 공개 통로로 오가므로 이브도 본다. 공유 비밀을 계산하려면 a나 b가 필요하고, A에서 a를 되찾는 이산 로그 문제가 어렵기 때문에 안전하다.

TLS 1.3이 TLS 1.2보다 왕복 한 번을 줄일 수 있었던 핵심 이유는?

클라이언트가 서버가 고를 방식을 예상해 공개값을 첫 메시지에 싣는다. 서버는 바로 자기 공개값과 인증서, Finished를 보내므로 1 왕복이면 열쇠가 정해진다. 인증서 검증은 그대로 한다.

주소창에 자물쇠가 떠 있는 secure-bank-login.com에 대해 말할 수 있는 것은?

도메인 확인(DV) 인증서는 도메인 소유만 확인하므로 피싱 사이트도 자물쇠를 단다. 자물쇠는 “누구와”가 아니라 “그 이름의 서버와 안전하게”를 보장한다. 목적지 IP나 SNI 같은 메타데이터도 남는다.

공격자가 봇 1만 대(각 10 Mbps 업링크)로 출발지를 피해자 IP로 위조한 DNS 질의를 보내고, 증폭 배수가 50이라면 피해자에게 도착하는 트래픽은 대략?

1만 × 10 Mbps = 100 Gbps의 질의가 50배로 증폭되어 5 Tbps가 된다. 일반 기업 회선(1~100 Gbps)으로는 막을 수 없는 크기라 수백 Tbps 용량의 분산망이 흡수해야 한다.

“지금 수집, 나중에 해독” 위협 때문에 TLS가 서둘러 도입하고 있는 것은?

양자 컴퓨터가 생기면 오늘 녹화한 키 교환이 풀릴 수 있다. 그래서 2024년 표준화된 ML-KEM을 기존 X25519와 함께 써서, 둘 중 하나만 안전해도 비밀이 지켜지게 한다.