712. SYN Flood 대응 - SYN Cookie 기술 (상태비저장 검증)

핵심 인사이트: 장난 전화(SYN Flood)가 너무 많이 걸려와 예약 장부(메모리)가 터져버릴 위기다. 똑똑한 식당 주인이 아이디어를 냈다. "이제부터 예약 장부에 아예 이름을 안 적겠습니다! 대신 손님에게 암호화된 '특수 예약 영수증(쿠키)'을 던져줄 테니, 진짜 밥 먹을 거면 식당에 올 때 그 영수증을 꼭 쥐고 다시 오세요!" 장부를 쓰지 않으니(상태 비저장) 메모리가 터질 일이 원천 차단되는 기적의 방어술, 그것이 SYN Cookie다.

Ⅰ. 기존 방어법의 한계

SYN Flood 공격(711번)에 당하지 않으려면 대기열 장부(Backlog Queue)를 무한정 늘리면 될까요? 불가능합니다. 서버 메모리는 한정되어 있고, 대기 시간을 짧게 줄이면 네트워크가 느린 정상 고객까지 튕겨버립니다. 근본적으로 서버가 [SYN]을 받자마자 메모리에 기록(Stateful)해야만 하는 TCP의 약점 자체를 부숴야 했습니다.

대기열 장부를 쓰지 않는 상태 비저장(Stateless) TCP 연결 생성 기법입니다. 리눅스 등 대부분의 운영체제에 기본 내장되어 있습니다.

1. 가짜 응답 던지기 (암호화된 번호표)

  • 해커(또는 정상 고객)가 [SYN] 패킷을 보냅니다.
  • 서버는 이 요청을 자기 장부(Backlog Queue)에 절대 적지 않습니다. 메모리 소비가 0입니다.
  • 대신, 방금 받은 클라이언트의 IP, 포트, 현재 시간 등을 서버만 아는 비밀키로 암호화(해싱)하여 독특한 난수를 하나 만듭니다. 이것이 바로 **'쿠키(Cookie)'**입니다.
  • 서버는 이 쿠키값을 TCP 패킷의 Sequence Number 란에 딱 적어서 [SYN+ACK]로 클라이언트에게 냅다 던져버리고는, 자신이 패킷을 보냈다는 사실조차 머릿속에서 완전히 지워버립니다.

2. 최종 3단계 검증 (진실의 순간)

  • 해커(가짜 주소)인 경우: 가짜 IP로 던졌으니, 서버가 보낸 쿠키(SYN+ACK)를 받을 리 없고 당연히 최종 응답도 안 옵니다. 서버는 애초에 장부에 적지도 않았으니 잃은 게 0입니다.
  • 진짜 고객인 경우: 정상 고객은 서버가 준 쿠키가 담긴 패킷을 잘 받고, 마지막 3단계인 [ACK] 패킷을 보낼 때 규칙에 따라 아까 받은 쿠키값에 +1을 더해서(Acknowledge Number) 서버로 보냅니다.

3. 통과 및 진짜 연결 확립

  • 서버는 문을 두드리는 [ACK] 패킷을 받습니다.
  • 패킷 겉면에 적힌 쿠키값을 보고, "어? 내가 만든 비밀 암호 공식에 맞아떨어지는 진짜 영수증(쿠키)이네?"라고 1초 만에 검증해 냅니다.
  • 그제야 서버는 비로소 이 고객을 진짜 손님으로 인정하고, 메모리에 정식으로 자리를 내어주며(Established) TCP 연결을 완성합니다.

Ⅲ. SYN Cookie의 장단점

  • 장점: 대기 큐 메모리 고갈을 100% 완벽하게 막아주어, 서버가 수십만 개의 SYN 폭격 속에서도 꿋꿋하게 살아남게 해 줍니다.
  • 단점: 서버가 [ACK] 패킷이 올 때마다 이게 내가 구워준 쿠키가 맞는지 암호 해시 연산(CPU 계산)을 계속 돌려야 합니다. 메모리는 지켰지만 CPU 부하가 약간 생깁니다. (따라서 평소엔 꺼두다가 SYN 큐가 80% 이상 차오르면 비상용으로 탁 켜지는 식으로 동작합니다.)

📢 섹션 요약 비유: SYN Cookie는 뷔페의 '디지털 대기표'입니다. 장난 전화 예약이 너무 많아 직원의 예약 수첩(메모리)이 찢어지기 일보 직전입니다. 직원은 수첩을 덮고, 전화를 거는 모든 사람에게 식당 자체 암호로 만든 '문자 바코드(쿠키)'만 무작정 쏴주고 전화를 끊습니다(기억 안 함). 장난전화범(가짜 번호)은 바코드를 받지 못해 못 오고, 진짜 손님은 그 바코드를 폰에 띄운 채 식당에 방문합니다. 직원은 스캐너로 바코드가 진짜인지만 1초 만에 스캔(검증)한 뒤 손님을 바로 자리(정식 연결)로 안내합니다. 수첩이 필요 없는 완벽한 방어입니다.