DDoS·DRDoS 대응: 대역폭·상태·애플리케이션 자원 구분
1장 개념과 보호 목표#
DDoS는 여러 경로에서 자원을 소모시켜 정상 사용자의 서비스를 방해하는 공격입니다. DRDoS는 출발지 주소 위장과 반사 서버를 이용하며 응답이 커지는 프로토콜에서는 증폭도 발생할 수 있습니다.
2장 원리와 구분#
대역폭 소진은 회선 용량을, 연결 상태 소진은 장비·서버의 세션 자원을, 애플리케이션 공격은 비싼 조회·연산·외부 호출을 압박합니다. 회선이 이미 포화되면 서버 앞 방화벽만으로 복구하기 어렵습니다. CDN·스크러빙·통신사 협력과 서버의 속도 제한·캐시·동시성 제어를 적절한 위치에서 적용해야 합니다.
요청 재시도는 장애 중 부하를 더 키울 수 있습니다. 클라이언트와 내부 서비스에 지수 백오프·재시도 상한을 적용하고 꼭 필요한 업무를 우선 처리하는 저하 운영을 준비합니다. 제한 정책은 사용자 접근성을 고려하며 CAPTCHA도 모든 공격 유형이나 API 소비를 해결하는 수단은 아닙니다.
3장 비교와 판단 기준#
| 범주 | 소진되는 자원 | 대응 위치 |
|---|---|---|
| 볼륨 공격 | 회선·대역폭 | 상위망·스크러빙·분산 |
| 상태 공격 | 연결·테이블 | 네트워크·프록시·시간 제한 |
| 애플리케이션 공격 | CPU·DB·외부 호출 | 캐시·요청·동시성 한도 |
| 반사·증폭 | 응답·네트워크 용량 | 출발지 검증·공개 서비스 제한 |
4장 DDoS는 어느 자원을 먼저 소모시키는가#
회선·연결 상태·CPU·DB·외부 호출 등의 병목을 나누어 봅니다. 요청 수가 많지 않아도 비싼 질의를 반복하면 서비스가 느려질 수 있습니다. 반대로 회선이 포화되면 서버 코드의 제한만으로 외부 정상 요청이 도달하도록 만들기 어렵습니다.
관측에는 대역폭·패킷·세션·응답시간·오류·DB 대기·외부 비용을 연결합니다. 정상 급증과 공격의 구분도 요청 특성과 업무 성공률의 근거로 판단합니다.
5장 반사와 증폭은 다른 관계다#
DRDoS의 반사는 응답을 피해자에게 보내도록 이용하는 구조입니다. 증폭은 작은 요청에 비해 큰 응답을 만드는 효과입니다. 두 개념이 함께 나타날 수 있지만 같은 뜻은 아닙니다. 출발지 위조 가능성과 공개 응답 서비스의 조건을 확인합니다.
flowchart LR
A["공격자의 요청"] -->|"피해자 주소로 위조"| R["반사 서비스"]
R -->|"피해자에게 응답"| V["피해자 회선"]
R --> X["프로토콜에 따라 응답 증폭 가능"]6장 회선 포화는 상위 구간에서 대응한다#
피해자 앞 장비에 이미 너무 많은 트래픽이 도달하면 서버의 애플리케이션 제한은 늦을 수 있습니다. 통신사·스크러빙·분산 전달·CDN의 실제 보호 범위와 전환 경로를 확인합니다. 계약에 포함된 프로토콜·대역·최대 처리·우회 조건도 중요합니다.
연락망과 전환 기준을 미리 정해야 사고 중 새로운 설정을 급하게 만들지 않습니다. DNS 변경·경로 전환·방어 서비스 장애와 원복을 훈련합니다.
7장 연결 상태와 타임아웃#
장비·프록시·서버의 연결 테이블과 처리량이 한계에 도달할 수 있습니다. 연결 수·타임아웃·새 연결율·소스 분포를 봅니다. 타임아웃을 너무 줄이면 느린 정상 이용자가 영향을 받을 수 있어 실제 서비스의 조건으로 검증합니다.
고가용성 장비로 전환해도 공유된 상위 회선·DB가 병목이면 전체 가용성이 회복되지 않을 수 있습니다. 개별 서버 수와 전체 경로의 한계를 구분합니다.
8장 비싼 API는 요청 비용을 제한한다#
검색·이미지 변환·보고서·외부 AI 호출은 요청당 자원이 다릅니다. 경로별 크기·동시성·연산·기간·외부 비용의 상한을 둡니다. 인증된 계정도 남용할 수 있으며 IP별 제한만으로 업무 비용을 완전히 통제하지 못할 수 있습니다.
요청 수 한도
요청당 크기·페이지·연산량 한도
전체 동시성·작업 큐 한도
계정·조직·토큰별 업무 한도
외부 호출·비용 상한9장 캐시와 저하 운영#
사고 중 모든 기능을 같은 수준으로 유지하려 하면 비핵심 작업이 핵심 업무의 자원을 소모할 수 있습니다. 캐시된 결과·읽기 전용·비싼 기능의 일시 제한 등 저하 운영을 준비합니다. 정상 사용자에게 어떤 기능을 유지할지 업무 우선순위로 정합니다.
캐시가 사용자·조직별 권한 데이터를 잘못 공유하지 않는지도 확인해야 합니다. 성능 개선이 데이터 노출을 만들지 않도록 키와 만료·권한을 설계합니다.
10장 재시도가 장애를 키우는 상황#
시간 초과가 나면 클라이언트와 내부 서비스가 동시에 재시도할 수 있습니다. 부하가 늘어 더 많은 시간 초과가 생기는 순환을 막기 위해 지수 백오프·분산 지연·재시도 상한과 전체 시간 한도를 검토합니다. 실패한 작업의 중복 반영도 방지해야 합니다.
flowchart LR
O["과부하"] --> T["시간 초과"]
T --> R["무제한 재시도"]
R --> O
T --> B["상한·백오프·저하 운영"]
B --> C["부하 확산 제한"]11장 정상 사용자와 공유망의 영향#
회사·학교·통신망처럼 여러 사용자가 같은 외부 주소를 쓸 수 있습니다. IP 하나를 강하게 차단하면 정상 사용자도 함께 영향을 받을 수 있습니다. 계정·토큰·행위·비용과 네트워크 신호를 조합하고 제한의 영향을 측정합니다.
CAPTCHA는 일부 자동화에 도움을 줄 수 있지만 API 소비·회선 포화·접근성의 모든 문제를 해결하지 않습니다. 위협과 정상 이용자의 요구에 맞게 보완 수단으로 선택합니다.
12장 반사 서버가 되지 않도록 점검한다#
불필요한 공개 UDP 서비스·개방 리졸버·관리 응답을 조사하고 허용 범위와 응답 정책을 제한합니다. 상위망의 출발지 검증도 관련 담당자와 연결합니다. 자사의 방어뿐 아니라 자원이 다른 피해자 공격에 이용되는 경로를 줄입니다.
13장 대응과 복구의 성과를 측정한다#
| 단계 | 측정할 결과 |
|---|---|
| 탐지 | 병목·기준 트래픽·업무 실패 |
| 전환 | 연락·경로 변경·방어 적용 시간 |
| 제한 | 정상 사용자 성공률·공격 비용 제한 |
| 복구 | 정책 원복·잔여 부하·재발 조건 |
공격 종료 후 임시 차단·확장 비용·캐시·연결·예외를 정리합니다. 대응 성공은 공격 트래픽의 감소와 정상 업무의 회복을 함께 확인하는 결과여야 합니다.
14장 적용 사례와 운영 방법#
로그인·검색 API는 IP별 제한뿐 아니라 계정·토큰·요청 비용을 고려합니다. 정상 사용자 급증과 공격을 구분하기 위해 기준 트래픽, 오류율과 응답시간을 기록합니다. 반사 서버가 되지 않도록 공개 리졸버·불필요 UDP 서비스를 제한하고 상위망의 출발지 검증도 검토합니다.
15장 병목의 위치를 측정한 뒤 대응 수단을 고른다#
회선 포화는 상위망 대응이, 연결 상태 소진은 세션·타임아웃·장비 용량 관리가, 비싼 API 반복은 업무별 비용 제한이 중요합니다. 요청 수만으로 공격을 판단하면 적은 요청으로도 무거운 연산을 유발하는 상황을 놓칠 수 있습니다. 대역폭·연결 수·CPU·DB 대기·외부 호출을 함께 관측합니다.
DRDoS의 반사는 응답을 피해자에게 보내는 방식, 증폭은 응답량이 요청량보다 커지는 효과입니다. 반사와 증폭은 구분할 수 있으며 출발지 위조 방지와 공개 UDP 서비스 제한을 각각 적절한 구간에 적용합니다. 자사 서버가 반사 서버로 악용되는지도 점검해야 합니다.
16장 검색 서비스의 저하 운영을 준비하기#
공격 중에는 비싼 전체 검색을 제한하고 캐시된 결과나 핵심 업무를 우선 제공하는 방안을 준비합니다. IP별 제한만 사용하면 공유망의 정상 이용자가 함께 차단될 수 있으므로 계정·토큰·경로·요청 비용과 제한 정책을 결합합니다. 오류 증가에 따른 내부 재시도 폭증도 차단해야 합니다.
대응 절차에는 통신사·CDN·방어 서비스의 연락망, 전환 조건, DNS 변경과 복구를 기록합니다. 시험은 차단 성공뿐 아니라 정상 이용자의 성공률, 우회·전환 시간, 공격 종료 후 정책 원복을 측정해야 합니다.
17장 적용 전 확인할 사항#
- 병목이 회선·연결·업무 연산 중 어디인지 확인한다
- 방어 서비스 연락망과 전환 절차를 준비한다
- 정상 사용자 영향과 복구 시간을 측정한다
18장 자주 묻는 질문#
요청 제한만 걸면 DDoS 대응이 끝나나요?#
요청 제한은 애플리케이션 자원 보호에 유용하지만 회선이나 네트워크 장비가 먼저 포화되는 공격에는 상위 구간의 대응이 필요합니다.
서버 수를 늘리면 모든 DDoS를 흡수할 수 있나요?#
회선·공유 DB·외부 API가 먼저 한계에 도달할 수 있습니다. 비용 폭증도 고려해 병목별 한도와 상위망 방어를 준비해야 합니다.
트래픽 급증은 항상 공격인가요?#
행사·방송·정상 사용자 유입일 수 있습니다. 기준 트래픽과 업무 성공률·요청 특성을 함께 비교해야 합니다.