/64 프리픽스 단위로 IPv6 어뷰징에 속도 제한을 걸고 차단하는 방법

운영 중인 속도 제한기, 로그인 스로틀, IP 차단 목록은 거의 모두 IPv4를 기준으로 설계되었고, 그 사고방식은 단순합니다. 주소 하나가 곧 대략 사용자 한 명이라는 것입니다. 주소별로 요청을 세고, 그 주소를 차단하고, 넘어갑니다. 이 모델은 어느새 틀린 것이 되었습니다. 트래픽에 IPv6가 포함되는 순간(상당하고 점점 늘어나는 비중이 그렇습니다), 여러분이 세는 단위는 더 이상 사람과 대응하지 않고 "주소 하나"를 전제로 만든 모든 방어에 구멍이 생깁니다.

이것은 미묘한 예외 상황이 아닙니다. 속도 제한기가 제대로 작동하느냐, 아니면 대시보드에는 요청이 한 건뿐인 주소들이 가지런히 나열되는 동안 공격자가 그대로 통과해 버리느냐의 차이입니다. 해법은 규칙을 더 늘리는 것이 아니라 올바른 대상을 세는 것이며, 이는 게시된 CIDR 블록이 어떤 개별 주소보다 중요한 IP 대역으로 AI 크롤러와 봇 검증하기와 같은 습관입니다. 프리픽스 집계는 IP 주소로 봇 탐지하기의 한 계층이며, 나머지 계층은 해당 프리픽스가 어떤 종류의 네트워크에 속하는지 알려 줍니다.

IPv6에서 무너지는 IPv4의 습관

IPv4에서는 주소 부족이 오히려 도움이 되었습니다. 주소는 약 43억 개뿐이고 값도 비싸며, 가입자가 한 번에 공인 주소 하나를 받는 방식이 압도적으로 일반적입니다. 그래서 "이 /32에서 온 요청"과 "이 사용자의 요청"은 거의 같은 것으로 취급해도 충분했습니다. /32를 차단해도 불편을 겪는 쪽은 기껏해야 그 가구나 그 뒤의 NAT 정도였습니다.

IPv6는 이 희소성을 없애고, 그와 함께 이 가정도 없앱니다. 주소는 32비트가 아니라 128비트(네 자리 16진수 그룹 여덟 개)이며, 설계 철학도 절약과는 정반대입니다. IPv6는 주소를 하나씩 배급하는 대신 모든 고객에게 주소의 블록을 건넵니다. 누구나 받는 가장 작은 블록도 어마어마하게 크며, 사용자의 실제 정체성은 개별 주소가 아니라 그 블록입니다.

IPv6에서 제한기가 여전히 전체 주소별로 집계한다면, 어뷰저에게는 봇넷도 프록시 풀도 필요 없습니다. 평범한 IPv6 할당 하나와 for 루프 하나면 충분합니다.

가입자 한 명, 1,844경 개의 주소

문제 전체를 다시 보게 만드는 숫자가 있습니다. IPv6 최종 사용자에게 보통 할당되는 가장 작은 라우팅 가능 블록은 /64입니다. 앞 64비트는 네트워크이고, 뒤 64비트는 사용자가 원하는 대로 채울 수 있습니다. 그러면 한 가입자의 서브넷 안에 2^64개의 사용 가능한 주소가 남습니다.

2^64 = 18,446,744,073,709,551,616개의 주소: 약 1,844경 개이며, 모두 한 사용자에게 속하고 모두 똑같이 라우팅됩니다.

이것이 우연한 특이점이 아니라 피할 수 없는 구조인 이유는 두 가지입니다. 첫째, IPv6 호스트가 스스로 주소를 할당하는 표준 방식인 상태 비저장 주소 자동 설정(SLAAC)은 서브넷마다 /64 전체를 요구하므로, 일반적인 LAN에는 그보다 작은 블록을 줄 수 없습니다. 둘째, RIR이 따르는 주소 계획 지침(RFC 6177 / BCP 157)은 ISP가 각 최종 사이트에 넉넉한 할당(보통 /56 또는 /48)을 주고 /64보다 작게는 절대 주지 말라고 안내합니다. 풍부함이 이 프로토콜의 핵심입니다.

이제 공격자의 입장입니다. 이 주소들을 돌려 쓰는 것은 비용이 많이 들거나 영리한 일이 아닙니다. 기본 제공되는 소켓 옵션입니다. Linux의 IP_FREEBIND 플래그를 쓰면 프로세스가 각 주소를 인터페이스에 먼저 설정하지 않고도 로컬로 라우팅되는 프리픽스 안의 아무 주소에나 바인드해 전송할 수 있으며, 널리 참조되는 freebind 프로젝트 같은 공개 도구는 바로 그것을 "연결마다 새로운 출발지 주소를 사용"하는 기능으로 감싸 두었습니다. 라우팅되는 /64 하나를 주면 비용 없이 1,844경 개의 서로 다른 출발지에서 트래픽을 내보냅니다.

따라서 /128 단위 속도 제한은 이를 조금도 늦추지 못합니다. 모든 요청이 한 번만 보이는 새 주소처럼 보입니다. 제한기의 카운터는 1을 넘지 않고, 차단 목록은 한 번만 나타난 수백만 개의 항목으로 채워지지만 아무것과도 일치하지 않으며, 공격은 서류상으로는 완벽하게 분산된 것처럼 보이면서 전속력으로 진행됩니다.

IPv6 할당 계층과 각 단계의 의미

올바른 단위에 제한을 걸려면 각 프리픽스 길이가 실제로 무엇을 의미하는지 알아야 합니다. IPv6 프리픽스는 CIDR 블록일 뿐이지만(IPv4와 같은 /n 표기이며 숫자가 작을수록 더 많은 주소를 포함합니다), 관례적인 경계는 반대편에 누가 있는지에 대한 의미를 담고 있습니다.

이 표에서 판단의 형태가 드러납니다. /128은 절대 단위가 아닙니다. /64는 하한선입니다. 여전히 한 명의 행위자에 대응하는 가장 좁은 범위이므로 기본값입니다. 그보다 넓은 것은 모두 더 넓은 할당 전체가 문제라는 증거가 있을 때만 사용하는 확대입니다.

규칙 1: IPv6 속도 제한은 /64부터 시작해 프리픽스 단위로 적용합니다

대부분의 문제를 해결하는 단 하나의 변경은 주소별 집계를 그만두고 /64별 집계를 시작하는 것입니다. 구체적으로, 들어오는 모든 IPv6 요청에서 앞 네 개의 헥스텟(64비트)만 남겨 /64를 도출하고, 그것을 속도 제한 카운터, 로그인 시도 집계, 차단 목록 조회의 키로 사용합니다.

주요 엣지 도구는 이미 이를 지원하므로 직접 구현할 일은 거의 없습니다.

• nginx: IPv6를 /64로 마스킹하는 map/geo 블록으로 제한 키를 만들고, $binary_remote_addr 대신 그 키를 limit_req_zone / limit_conn_zone에 전달합니다.
• HAProxy: 스틱 테이블 키를 만들 때 출발지에 64비트 마스크를 설정해, src가 전체 주소가 아닌 /64로 집계되게 합니다.
• Cloudflare 및 대부분의 CDN / WAF: 자체 속도 제한과 챌린지 로직에서 이미 IPv6를 /64 블록으로 취급합니다. 두 계층이 일치하도록 오리진 규칙에서도 같은 세분성을 맞추십시오.
• 자체 앱 제한기: 원시 remote_addr가 Redis, 토큰 버킷, 카운터에 도달하기 전에 위의 /64 키로 바꾸십시오.

이것만 해도 비용 없는 주소 교체 공격은 원래 모습으로 무너집니다. 1,844경 개의 주소가 하나의 카운터가 되고, 어뷰저는 IPv4 주소 하나일 때와 똑같이 제한을 받습니다. 이 주제 전체에서 가장 가치가 큰 코드 한 줄입니다.

규칙 2: 지속되면 /56과 /48로 확대합니다

/64를 기준으로 삼으면 서브넷 안에서 주소를 바꾸는 공격자를 처리할 수 있습니다. 사다리의 다음 단계는 서브넷을 바꾸는 공격자입니다. 가입자는 /64 하나가 아니라 그것들로 가득한 /56 또는 /48 전체를 보유하는 경우가 많고, freebind 계열 도구는 그 범위도 돌아다닐 수 있기 때문입니다.

확대해야 한다는 신호는 지속성입니다. 공통 상위 프리픽스를 공유하는 새로운 /64들이 계속 문제를 일으키는 것입니다. 그런 상황이라면 그 할당 전체가 하나의 주체이며 하나로 범위를 잡아야 합니다.

위로 합산되는 카운터라고 생각하십시오. /64 집계를 기본 단위로 유지하되, 각 /56과 /48로 합산한 어뷰징도 추적합니다. 정당한 고객 한 명이라면 넘지 않을 임계값을 상위 프리픽스가 넘으면(짧은 시간 안에 서로 다른 하위 /64 여러 개가 모두 문제를 일으키는 경우) 상위 수준에서 제한을 적용해 모든 하위를 한 번에 포괄하게 합니다. 그렇게 하면 큰 할당을 가진 공격자보다 앞서가면서도, 작고 얌전한 할당을 가진 쪽을 처벌하지 않을 수 있습니다.

규칙 3: 반사적으로 넓히지 말고 네트워크 유형에 따라 넓힙니다

확대에는 비용이 큰 실패 양상이 있습니다. 너무 넓히면 차단 한 번에 수천 명의 무고한 사용자가 사라집니다. /48은 사업장 하나일 수도 있고 이동통신사의 일부일 수도 있습니다. /32는 거의 한 명의 행위자가 아니며, 대개 ISP나 호스팅 업체 전체입니다. 지속성 신호는 상위 프리픽스가 관련되어 있다는 점을 알려 줄 뿐, 그 뒤에 실제 사람이 몇 명인지는 알려 주지 않습니다. 그것을 알려면 프리픽스가 어떤 종류의 네트워크인지 알아야 합니다.

바로 여기서 IP 조회가 파이프라인에서 제 역할을 합니다. 문제의 프리픽스에서 대표 주소 하나를 IP 조회 API로 한 번 호출하면, 공격적으로 묶어도 되는 임대 인프라인지, 조심스럽게 다뤄야 하는 소비자 접속망인지 알 수 있습니다.

얼마나 넓게 가도 안전한지를 좌우하는 필드는 다음과 같습니다.

다음은 실제 IPv6 주소인 Google Public DNS 2001:4860:4860::8888을 2026-10-05에 조회했을 때 반환된 결과입니다(줄여서 표시했으며, 대역이 바뀌면 결과도 달라집니다).

응답의 두 부분은 서로 다른 질문에 답합니다. asn_type: "hosting", connection_type: "datacenter", is_hosting: true는 이 프리픽스가 인프라라는 뜻이므로, 차단을 /64보다 넓혀도 일반 가정이 걸려들지 않습니다. 그러나 scoring.fraud_score는 15이고 recommended_action은 allow입니다. 이 주소 자체에는 VPN, Tor, 어뷰징 신호가 없고, detection_methods에도 datacenter_ip와 no_ptr_datacenter만 있습니다. 네트워크 유형은 어디까지 넓혀도 되는지를 알려 주고, 넓혀야 하는 이유는 여러분의 지속성 카운터가 제공해야 합니다. 문제를 일으킨 적 없는 호스팅 프리픽스는 열린 채로 둡니다.

이 해석에는 방향성이 있으며, 더하고 빼는 위험 점수 사유 뒤에 있는 원칙과 같습니다. 어떤 필드는 더 강하게 조치하게 하고, 어떤 필드는 자제하라고 알려 줍니다.

Google Ads도 같은 방식으로 셉니다. API는 2001:db8::/48을 IP 제외 항목 하나로 받으므로, /48 하나는 Google Ads 제외 슬롯 500개 중 하나를 차지합니다.

이 원칙은 실제 고객을 차단하지 않고 익명화 트래픽 탐지하기에서 전면적으로 논한 것과 같습니다. hosting 또는 datacenter 프리픽스에서는 자신 있게 차단 범위를 넓힐 수 있습니다. 결제나 가입이 서버 랙에서 시작될 정당한 이유는 없기 때문입니다. 데이터센터 IP 주소란 무엇인가에서 풀어 쓴 것과 같은 징후입니다. mobile 또는 residential 프리픽스에서는 범위를 좁게 유지하고, 넓은 CIDR 차단이 아니라 위험 점수가 부담을 지게 하십시오. 반사적으로 넓히면 속도 제한기가 조용히 실제 사용자에게 장애가 됩니다.

규칙 4: 프리픽스 평판이 감쇠하도록 둡니다

마지막 규칙은 시간에 관한 것입니다. IPv4 차단 목록도 주소가 재할당되면서 이미 낡아 가는데, IPv6에서는 프리픽스 전체가 위임되고 반환되고 다시 위임되므로 상황이 더 나빠집니다. 지난달 로그인 페이지를 두드린 /64가 지금은 평범한 가정의 것일 수 있습니다. 계속 바뀌는 주소 공간에 영구 차단 목록을 두면 서서히 더 이상 안전하게 접근할 수 없는 곳의 목록이 됩니다.

그래서 프리픽스마다 영구 판정을 저장하지 말고, 움직이는 평판을 저장하십시오.

• 어뷰징 시 상승. 문제를 일으키는 요청마다 /64의 점수를 올리고, 더 작은 증분을 상위 /56과 /48로 합산합니다.
• 시간에 따른 감쇠. 프리픽스가 조용하면 일정에 따라(소프트 스로틀은 몇 시간, 완전 차단은 며칠 단위로) 점수가 떨어지고, 임계값 아래로 내려가면 차단이 스스로 풀립니다.
• 이력이 아니라 현재 점수로 조치. 평판이 지금 어디에 있는지를 기준으로 속도 제한, 챌린지, 차단을 하십시오. 그러면 개선되었거나 재할당된 프리픽스가 아무도 정리하지 않는 목록에 남지 않고 자동으로 회복됩니다.
• 증거 보존. 각 점수 변화를 이끈 신호(조회의 detection_methods, 지속성 패턴)를 저장해, 넓은 범위의 차단이 이유를 알 수 없는 항목이 아니라 설명할 수 있는 결정이 되게 하십시오.

감쇠가 전체 시스템의 정직함을 지켜 줍니다. 공격 중에 공격적으로 확대한 조치가 영구적인 흉터로 남지 않으며, 차단 목록이 한때 악의적이었던 대상이 아니라 지금 악의적인 대상을 반영하게 됩니다.

이번 주에 시작하기

• 제한기 키를 /64로 바꾸십시오. 지금 주소별로 집계하거나 차단하는 모든 곳에서 먼저 IPv6를 앞 64비트로 마스킹합니다. 이 변경 하나로 비용 없는 주소 교체 구멍이 닫히며, 보통 nginx, HAProxy, 앱에서 몇 줄이면 됩니다.
• /56과 /48용 합산 카운터를 추가하십시오. 상위 프리픽스로 합산한 어뷰징을 추적해, 서브넷을 바꿔 가는 공격자가 기본값을 넓히지 않고도 더 넓은 제한에 걸리게 합니다.
• 넓히기 전에 네트워크를 조회하십시오. /64를 넘어 확대할 때마다 asn_type / connection_type을 확인합니다. 호스팅에서는 자유롭게 묶고, 모바일과 가정용에서는 좁게 유지하며, 통신사나 CGNAT 대역은 절대 완전 차단하지 마십시오.
• 모호한 경우는 점수화하십시오. 프리픽스가 공유되거나 소비자용이라면 뭉툭한 CIDR 차단 대신 주소별 종합 fraud_score와 recommended_action을 사용합니다.
• 모든 차단에 감쇠를 두십시오. 프리픽스 평판을 반감기와 함께 저장하고, 현재 점수로 조치하며, 재할당된 공간이 스스로 정리되게 하십시오.

IPv6가 어뷰징 방지를 더 어렵게 만든 것이 아니라 단위를 바꾸었을 뿐입니다. 이제 주소는 사용자가 아니라 /64가 사용자입니다. 그것을 세고, 증거에 따라 확대하고, 네트워크 유형으로 가중하고, 용서는 시간에 맡기십시오. 그러면 IPv4에서 이미 신뢰하던 모든 방어가 다시 작동합니다.

자주 묻는 질문

IPv4 주소처럼 IPv6 주소에는 속도 제한을 걸 수 없는 이유는 무엇입니까?

두 프로토콜이 사용자당 할당하는 주소 공간의 크기가 크게 다르기 때문입니다. IPv4에서는 가입자 한 명이 보통 주소 하나를 받으므로 /32(주소 하나) 단위로 제한하면 사용자 단위로 제한하는 셈입니다. IPv6에서는 가입자 한 명에게 /64 전체가 일상적으로 할당됩니다. 이는 2^64, 약 1,844경 개의 주소이며, IP_FREEBIND 같은 도구를 쓰면 프로세스가 이 블록 안의 아무 주소에서나 비용 없이 트래픽을 보낼 수 있습니다. 따라서 /128(IPv6 주소 하나)에 속도 제한이나 차단을 걸어도 아무것도 막지 못합니다. 어뷰저는 1,844경 개의 주소 중 다음 주소를 쓰면 그만입니다. IPv6에서 올바른 단위는 /128이 아니라 /64입니다.

IPv6 속도 제한은 어느 프리픽스 길이에 적용해야 합니까?

/64에서 시작하십시오. SLAAC는 서브넷마다 /64 전체를 요구하고 ISP는 모든 고객에게 최소 /64를 할당하므로, /64는 단일 최종 사용자에게 속한다고 보장되는 가장 작은 블록입니다. 카운터와 차단 목록을 주소의 앞 64비트 기준으로 키를 잡고 /64 전체를 한 명의 행위자로 취급하십시오. 같은 고객의 여러 /64에서 어뷰징이 이어지면 범위를 /56(/64 256개), 그다음 /48(/64 65,536개)로 확대합니다. 이 둘은 가정이나 사업장 전체 할당의 일반적인 크기입니다.

IPv6 /64 전체를 차단해도 안전합니까?

거의 항상 안전하며, IPv4 주소 하나를 차단하는 것보다 오히려 안전합니다. /64는 가입자 한 명의 서브넷으로 설계되었기 때문에, 공유되는 IPv4 CGNAT 주소처럼 무관한 제3자가 걸려드는 일이 드뭅니다. 실제 위험은 더 넓은 프리픽스에 있습니다. /48이나 /32는 ISP 전체, 이동통신사, 수천 명의 무관한 사용자를 포함하는 공유 호스팅 대역일 수 있습니다. 네트워크 유형이 정당화할 때만 범위를 넓히십시오. 호스팅/데이터센터 프리픽스에서는 적극적으로, 모바일과 가정용 프리픽스에서는 신중하게 접근합니다.

차단 범위를 얼마나 넓혀야 하는지 어떻게 판단합니까?

지속성과 네트워크 유형, 두 가지가 결정하게 하십시오. 지속성은 같은 /56 또는 /48 안의 새로운 /64에서 어뷰징이 계속 나타난다면 그 할당 전체를 하나의 주체로 보고 그 단위로 확대한다는 뜻입니다. 네트워크 유형의 경우, 조회 결과가 호스팅 또는 데이터센터 ASN이면 그 프리픽스는 인프라이므로 빠르게 상위로 묶을 수 있고, 이동통신사나 가정용 ISP라면 더 넓은 프리픽스 뒤에 실제 사용자가 많을 수 있으므로 범위를 좁게 유지하고 완전 차단 대신 위험 점수를 활용합니다.

CGNAT와 모바일 네트워크는 IPv6 처리 방식을 바꿉니까?

넓은 범위에서는 그렇습니다. 모바일에서도 IPv6 /64 하나는 보통 가입자 한 명이므로 /64 단위 제한은 여전히 맞습니다. 그러나 이동통신사와 464XLAT/NAT64 환경에서는 공유되는 더 넓은 프리픽스 아래에 많은 가입자가 있을 수 있어서, 모바일 ASN에 /48이나 /32 단위 차단을 걸면 통신사 고객의 상당 부분이 막힐 수 있습니다. 규칙은 IPv4와 같습니다. 악성 행위자 한 명을 이유로 공유 대역을 완전 차단하지 마십시오. 점수화하고, 넓은 범위의 차단은 인프라 프리픽스에만 적용하십시오.

IPv6 프리픽스는 얼마나 오래 차단해야 합니까?

영구적으로 차단해서는 안 됩니다. IPv6 프리픽스는 재할당되므로 지난달 여러분을 공격한 /64가 다음 달에는 다른 고객의 것일 수 있습니다. 프리픽스마다 영구 항목을 두는 대신 감쇠하는 평판을 붙이십시오. 어뷰징이 발생하면 점수를 올리고, 문제가 없으면 시간이 지나며 점수가 떨어지게 하며, 임계값 아래로 내려가면 차단을 자동으로 해제합니다. 계속 바뀌는 주소 공간에 영구 차단 목록을 두면 서서히 더 이상 안전하게 접근할 수 없는 주소의 목록으로 변합니다.