네트워크 인프라 이해하기 · 제6부 · 연결된 망을 안전하게 유지하고 장애에서 복구하기
공격 트래픽에는 어디에서 대응해야 정상 서비스를 지킬 수 있을까
RTBH·uRPF·Sinkhole·FlowSpec으로 공격 트래픽을 적절한 상류 경계에서 제어하는 법
공격 트래픽이 인터넷 회선을 이미 채운 뒤라면 내부 방화벽에서 버려도 정상 트래픽이 들어올 공간은 생기지 않습니다. RTBH와 BGP FlowSpec은 상류 라우터에서 공격 트래픽을 줄이고, Sinkhole은 의심 트래픽을 관찰 지점으로 보냅니다. 이 글에서는 각 방식의 차단 범위와 정상 서비스 영향, 비대칭 경로의 위험과 안전한 철회 절차를 비교합니다.
공격 패킷을 방화벽에서 버려도 이미 가득 찬 인터넷 회선은 비워지지 않는다↑
방화벽이나 서버 앞 라우터가 공격 패킷을 버리면 내부 자원 소모는 줄일 수 있습니다. 하지만 공격 트래픽이 인터넷 회선을 통과한 뒤라면 해당 회선의 큐와 대역폭은 이미 사용되었습니다. 정상 트래픽도 같은 병목에서 손실됩니다.
따라서 대응 위치는 보호 대상 장비보다 먼저 “어디가 포화되는가”를 기준으로 정해야 합니다. 자체 Edge에서 충분한 여유가 없다면 ISP나 DDoS Scrubbing 사업자와 상류 차단 절차를 미리 합의해야 합니다.
1Gbps 인터넷 회선으로 2Gbps 규모의 UDP Flood가 몰리면 방화벽이 모든 공격 패킷을 폐기해도 회선의 Ingress는 이미 포화됩니다. 정상 HTTPS 패킷은 방화벽에 도착하기 전 ISP 큐에서 손실될 수 있습니다. 방화벽 CPU가 여유롭다는 지표만 보고 완화가 성공했다고 판단하면 안 됩니다. 병목 앞쪽 인터페이스 사용률, 패킷 폐기량과 정상 요청의 처리 성공률을 함께 봐야 합니다.
상류 완화에는 ISP가 우리 Prefix를 어느 지점에서 받고 어떤 Community·FlowSpec을 지원하는지 사전 합의가 필요합니다. 공격 중 처음 연락처를 찾고 Prefix Filter를 협상하면 늦습니다. 서비스별 허용 가능한 전체 차단 시간, Scrubbing 전환에 필요한 DNS·BGP·Tunnel과 철회 권한을 Runbook에 둡니다. 차단 위치는 장비 성능보다 공격 트래픽이 처음 공유 병목을 점유하기 전에 적용될 수 있는가로 정합니다.
상류 차단에는 서로 다른 망을 운영하는 조직의 협력이 필요합니다. 고객 Edge가 Community를 광고하면 ISP가 어떤 범위와 조건으로 적용하는지, 전파가 어디까지 가는지 계약과 시험으로 확인해야 합니다. 방화벽 폐기 카운터, 인터페이스 사용률과 ISP 관측량을 같은 시각으로 비교하면 차단이 서버만 보호했는지 회선까지 비웠는지 알 수 있습니다.
이 절의 근거 IETF RFC 3882
Destination RTBH는 공격받는 IP로 향하는 트래픽을 상류에서 통째로 버린다↑
Remote Triggered Black Hole, RTBH에서는 트리거 라우터가 특정 Community 등을 붙인 호스트 Route나 Prefix를 BGP로 광고합니다. 이를 받은 Edge 라우터는 정책에 따라 Null 인터페이스로 해석되는 폐기용 주소를 Next Hop으로 설정합니다. Destination 기반 RTBH라면 공격 대상 주소로 향하는 트래픽 전체가 경계에서 폐기됩니다.
빠르고 단순하지만 공격 패킷과 정상 패킷을 구분하지 않습니다. 공격받는 서비스 자체를 잠시 포기해 다른 Prefix와 인프라를 살리는 조치에 가깝습니다. 광고 가능한 Prefix 길이, Community, 수신 Peer, 만료와 철회 권한을 엄격하게 제한해야 오조작 범위를 줄일 수 있습니다.
운영자는 공격 대상 203.0.113.20/32에 사전 합의된 Blackhole Community를 붙여 트리거 라우터에 주입할 수 있습니다. Edge 또는 Upstream의 정책은 이 Community를 대조해 Next Hop을 Null 인터페이스로 해석되는 주소로 바꾸고 해당 /32 트래픽을 폐기합니다. 더 넓은 203.0.113.0/24 Route보다 /32가 Longest Prefix Match로 우선하므로 나머지 주소는 계속 서비스할 수 있습니다.
하지만 Upstream이 /32 같은 길이를 수용하지 않거나 Community에 따른 차단 정책을 협의한 상류 지점에 적용하지 않으면 원하는 위치에서 트래픽이 폐기되지 않을 수 있습니다. 차단용 경로를 협의한 범위 밖으로 내보내서는 안 됩니다. 공격 대상이 Anycast나 여러 서비스가 공유한 IP라면 /32 폐기의 사용자 영향도 큽니다. 허용 Prefix, 최대 길이, Community, 수신 세션과 적용 기간을 정책으로 제한하고 Route의 만료와 철회는 운영 자동화에서 관리합니다. 철회 뒤 FIB의 Null Entry와 Upstream 광고가 모두 사라졌는지 확인해야 합니다.
대상 IP의 정상 트래픽도 함께 사라지는 강한 조치이므로 Prefix Length 필터가 핵심입니다. Provider가 고객의 임의 Prefix나 Default Route를 RTBH로 받아들이지 않도록 등록된 범위와 최대/최소 길이를 제한해야 합니다. 광고 수명, 철회 확인, Route Collector와 실제 폐기 카운터를 Runbook에 포함하고 사전 시험용 주소로 전파 범위를 검증합니다.
이 절의 근거 IETF RFC 3882
도해에서 확인할 내용 공격 대상 프리픽스를 받아들이기로 협의한 ISP A·B·C가 각자의 정책을 검사한 뒤 대상 패킷을 Null0로 버리는 예입니다. 커뮤니티를 받았다는 사실만으로 차단되는 것은 아닙니다. 어느 경로에서 정책이 적용되는지, 대상 주소의 정상 트래픽도 함께 막히는지 확인합니다.
↔ 도해는 좌우로 움직여 볼 수 있습니다.
Source RTBH와 uRPF는 정상적인 비대칭 트래픽까지 막지 않도록 주의해야 한다↑
Source 기반 RTBH는 Blackhole Route와 Unicast Reverse Path Forwarding(uRPF) 검사를 결합해 특정 Source Prefix의 패킷을 버리는 설계에 사용할 수 있습니다. 라우터는 Source 주소로 역방향 Route 조회를 수행하고, 결과가 폐기용 경로이거나 검증 조건에 맞지 않으면 패킷을 폐기합니다. 이때 폐기 경로를 유효한 경로로 취급하지 않는지 장비의 구현과 설정을 확인해야 합니다.
Strict uRPF는 Source로 돌아갈 최적 인터페이스와 수신 인터페이스가 같아야 한다는 조건을 사용할 수 있어 비대칭 라우팅 환경에서 정상 트래픽까지 차단할 수 있습니다. Loose Mode와 구현 옵션도 의미가 다릅니다. Source Spoofing 방어와 공격 대응에 유용하지만 실제 경로 대칭성, Multihoming, Default Route 영향을 시험한 뒤 적용해야 합니다.
Strict uRPF는 패킷의 Source로 되돌아가는 최적 Route의 인터페이스가 실제 수신 인터페이스와 같은지 확인하는 방식으로 사용할 수 있습니다. Multihomed 네트워크에서 요청은 ISP-A로 들어오고 Source Return Route는 ISP-B가 최적이면 정상 패킷도 실패할 수 있습니다. Loose Mode는 Source로 돌아갈 Route가 있는지 검사하므로 수신과 반환 인터페이스가 달라도 통과할 수 있습니다. 다만 Default Route와 폐기 경로를 처리하는 방식은 장비의 구현과 설정에 따라 다르므로 별도로 확인해야 합니다.
Source RTBH는 공격 Source Prefix를 Null Route로 주입하고 uRPF 결과를 이용해 해당 Source 패킷을 폐기하게 할 수 있습니다. Source 주소가 위조되어 광범위하거나 Botnet이 수많은 실제 주소를 쓰면 효율이 제한됩니다. 또한 잘못 지정한 Source Prefix에 속한 호스트의 정상 트래픽도 차단될 수 있습니다. Source 차단용 경로가 외부 AS로 전파되지 않도록 NO_EXPORT와 필터로 범위를 제한해야 합니다. 적용 전에 통신 흐름 Data로 Source 분포와 대칭성을 확인하고, Ingress Filtering과 Provider 협력 같은 더 근본적인 Anti-Spoofing 대책과 역할을 구분합니다.
Loose uRPF는 Source에 대한 Route 존재 여부를 중심으로 검사해 비대칭 환경에 더 관대하지만 차단 강도도 다릅니다. 플랫폼마다 Feasible Path, VRF와 Default Route 처리 옵션이 있으므로 Mode 이름만으로 결과를 가정하지 않습니다. 적용 전에 정상 Source별 Ingress·Return Path를 측정하고, Multihoming·Anycast·트래픽 Engineering 경로가 바뀌는 장애 상태까지 시험합니다.
이 절의 근거 IETF RFC 5635
Sinkhole은 의심 트래픽을 버리지 않고 분석할 수 있는 격리망으로 보낸다↑
Sinkhole 라우팅은 의심 트래픽의 Next Hop을 분석용 네트워크나 제한된 수집 시스템으로 바꿉니다. 어떤 Source와 프로토콜이 들어오는지 관찰하거나 악성 도메인으로 향하는 내부 호스트를 식별할 때 사용할 수 있습니다.
Sinkhole은 무한한 흡수 장치가 아닙니다. 대용량 공격을 그대로 보내면 분석 링크와 Collector가 새로운 병목이 됩니다. 개인정보와 Payload 보관, 접근 통제, 패킷 보존 기간도 운영 정책으로 정해야 합니다. 트래픽을 정상 서비스로 되돌리는 Scrubbing Center는 단순 Sinkhole과 달리 트래픽 검사 용량과 반환 경로까지 설계해야 합니다.
의심 Destination Route의 Next Hop을 Sinkhole Collector 방향으로 바꾸면 Source 분포, 프로토콜, 포트와 패킷 Pattern을 관찰할 수 있습니다. 악성 도메인의 내부 접속자를 찾을 때는 DNS Sinkhole이 별도 방식으로 안전한 응답 주소를 돌려주고 접속 Log를 남길 수도 있습니다. 라우팅 Sinkhole과 DNS Sinkhole은 Trigger와 관찰 지점이 다르므로 같은 이름만 보고 혼동하지 않습니다.
Collector가 100Mbps만 처리할 수 있는데 수Gbps 규모의 공격을 모두 보내면 분석망까지 장애가 확산됩니다. 샘플링·전송률 제한과 헤더만 수집하는 방식으로 필요한 증거 범위를 정하고 Payload 보관에는 개인정보 보호 기준과 관련 법령을 적용합니다. Sinkhole로 향하는 Route와 운영망으로 돌아가는 Default Route 사이에서 트래픽이 순환하지 않도록 격리 VRF와 명시적 폐기 경계를 둡니다. 관찰이 끝난 뒤 Route 철회와 수집 데이터의 보존·폐기 절차도 Runbook에 포함합니다.
대량 DDoS 전체를 작은 분석 장비로 보내면 Sinkhole 자체와 수집망이 마비됩니다. Sample, Rate Limit, 통신 흐름 Telemetry 또는 Scrubbing 결과만 보내는 용량 설계가 필요합니다. 수집 패킷에는 민감 정보가 포함될 수 있으므로 접근 권한, 보존 기간, 법무·개인정보 절차와 분석 종료 후 Route 철회까지 운영 책임을 정합니다.
이 절의 근거 Cisco Performance Routing Security Policies
도해에서 확인할 내용 아래는 Sinkhole과 비교할 트래픽 정화의 예입니다. 의심 트래픽을 정화 센터로 우회시키고, 검사 정책을 통과한 트래픽을 서비스로 돌려보냅니다. 관찰·격리를 위한 Sinkhole에 이런 반환 기능이 기본으로 포함되는 것은 아닙니다. 도해에서는 우회 지점, 정화 센터, 서비스로 돌아가는 경로를 따라가며 용량과 정상 업무의 복구 여부를 확인합니다.
↔ 도해는 좌우로 움직여 볼 수 있습니다.
BGP FlowSpec은 IP뿐 아니라 프로토콜과 포트까지 골라 차단 규칙을 전달한다↑
BGP FlowSpec은 Destination·Source Prefix, IP 프로토콜, 포트, TCP Flag 같은 트래픽 조건과 폐기, Rate-Limit, Redirect 등의 Action을 BGP로 전달합니다. Destination Prefix 전체를 버리는 RTBH보다 공격 통신 흐름을 좁게 지정할 수 있습니다.
강력한 만큼 전파 범위와 Rule Validation이 중요합니다. 잘못된 포트나 넓은 Prefix 조건 하나가 여러 라우터에서 동시에 정상 트래픽을 차단할 수 있습니다. 장비가 지원하는 Match와 Action, Rule 우선순위, Redirect 대상, IPv4·IPv6 차이를 사전에 검증해야 합니다.
| 방식 | 주요 Match | 대표 Action | 핵심 위험 |
|---|---|---|---|
| Destination RTBH | 목적지 Prefix | Null 폐기 | 정상 트래픽까지 전체 차단 |
| Source RTBH | 출발지 Prefix | uRPF 연계 폐기 | 비대칭 경로 오탐 |
| Sinkhole | Prefix·정책 | 분석망 Redirect | Collector 용량과 정보 보호 |
| FlowSpec | Prefix·프로토콜·포트 등 | 폐기·Rate·Redirect | 잘못된 Rule의 광범위 전파 |
공격이 203.0.113.20의 UDP 포트 53에 집중되었다면 FlowSpec Rule은 Destination /32, UDP와 Destination 포트 53을 대조해 Rate Limit 또는 폐기를 지시할 수 있습니다. 같은 IP의 TCP/443은 유지할 수 있어 Destination RTBH보다 피해 범위를 줄입니다. 다만 같은 UDP/53을 쓰는 정상 DNS 트래픽도 제한됩니다. 또한 Fragment나 여러 포트로 분산된 공격에서는 Match가 예상보다 좁거나 넓게 동작할 수 있습니다.
Controller가 보낸 Rule을 라우터가 그대로 Hardware에 설치하기 전에 허용 Prefix, 포트, Action과 Rule 우선순위를 검증해야 합니다. Redirect-to-VRF나 Rate Action 지원은 Vendor·Line Card별로 다를 수 있고 FIB·TCAM 자원도 한계가 있습니다. Route Reflector와 eBGP를 통한 전파 범위를 분리하고 고객 Rule이 다른 고객 Prefix에 적용되지 않게 합니다. 배포 전 패킷 표본이나 시험망에서 정상 트래픽의 일치 여부를 확인하고, 제한한 Scope에서 단계적으로 적용합니다.
수신 장비와 Provider가 지원하는 FlowSpec Family, Validation, Action과 우선순위를 확인해야 합니다. Controller는 승인된 Source에서 온 Rule만 받아 Prefix·포트 범위를 제한하고, 배포 전 예상 Match량과 충돌 Rule을 검사해야 합니다. 각 Rule에 소유자, 생성 근거, 만료 시각과 자동 철회 조건을 붙이고 Data Plane 카운터로 실제 적용량을 감시합니다.
이 절의 근거 IETF RFC 8955 · IETF RFC 8956
공격이 시작된 뒤 고민하지 않도록 차단 권한·범위·철회 절차를 미리 정한다↑
상황: 특정 공인 IP로 대용량 UDP 공격이 들어와 외부 회선이 포화됩니다.
- 병목 링크, 공격 Destination·Source 분포, 프로토콜·포트와 정상 트래픽 비율을 확인합니다.
- 대상 서비스의 중단을 감수할 수 있는지와 나머지 서비스에 미칠 영향을 판단해 RTBH, FlowSpec, Scrubbing 가운데 대응 수준을 고릅니다.
- 광고 Prefix 길이, Community, 적용 라우터와 Upstream 수신 여부를 사전 승인 목록과 대조합니다.
- 두 번째 작업자가 Match와 예상 피해 범위를 검토한 뒤 제한된 Scope로 배포합니다.
- 인터페이스 Rate, 폐기 카운터, 정상 Transaction을 동시에 관찰해 차단 위치가 병목 앞인지 확인합니다.
- 자동 만료 또는 명확한 철회 절차로 Rule을 제거하고, 종료 뒤 Timeline과 오탐 범위를 기록합니다.
Runbook에는 누가 Trigger를 요청하고 누가 승인·실행·철회하는지, 어떤 Prefix와 Community·FlowSpec Match만 허용하는지 적습니다. 공격 중에는 목적지·프로토콜·포트, Ingress 지점, Peak Rate와 정상 트래픽 Baseline을 Snapshot으로 남깁니다. 이 값으로 RTBH의 전체 차단, FlowSpec의 선택 차단, Scrubbing Redirect 중 가장 작은 피해 범위를 고릅니다. 자동화 계정에도 Prefix Scope와 최대 Rule 수를 제한합니다.
배포 뒤 Upstream에서 보호 대상 회선으로 향하는 인터페이스의 트래픽이 줄었는지, 폐기 카운터가 예상 지점에서 증가하는지, 차단 대상이 아닌 서비스의 정상 Health Check가 유지되는지 동시에 확인합니다. 효과가 없으면 차단이 병목 뒤에 있거나 Upstream이 Route를 수용하지 않았을 수 있습니다. 공격 종료 조건을 충족하면 정해진 순서로 Rule을 철회하고 BGP·FIB·Hardware Filter에서 잔여 Entry를 확인합니다. 사후 검토에는 오탐, 적용·철회 시각과 다음 자동화 개선을 기록합니다.
철회는 배포와 같은 수준으로 검증합니다. BGP Route나 FlowSpec Rule이 모든 적용 지점에서 사라졌는지, 정상 Route와 서비스가 돌아왔는지 확인하고 사후 기록에 탐지부터 완전 복구까지의 시각을 남깁니다.
이 절의 근거 IETF RFC 3882 · IETF RFC 5635 · IETF RFC 8955
용어사전↑
출처와 검증
- IETF RFC 3882 — BGP를 이용한 DoS 트래픽 차단 운영 기법
- IETF RFC 5635 — uRPF를 이용한 Remote Triggered Black Hole Filtering
- IETF RFC 8955 — IPv4 BGP Flow Specification
- IETF RFC 8956 — IPv6 BGP Flow Specification
- Cisco Performance Routing Security Policies — Blackhole과 Sinkhole Routing의 구현상 차이와 분석 경로
RTBH Community, FlowSpec Validation, 지원 Action과 Rule 우선순위는 Provider와 플랫폼마다 다릅니다. 실제 배포 전 ISP 협의, 권한 분리, 만료·Rollback 절차와 정상 트래픽 검증이 필요합니다.