Read the Docs, 분당 550만 요청 DDoS에 캐시 미스 404·302 집중 공격

문서 호스팅 서비스를 왜 공격하는지 궁금함. 더 중요한 대상을 치기 전 시험일 수도 있나?

글 쓴 사람인데, 정확한 동기는 모름. 공격 직전부터 AI 업체들의 과도한 스크래핑 때문에 제한을 조금씩 강화했는데, 이미 우리를 탐색하던 쪽이 기회가 닫힌다고 봤을 가능성은 있다고 생각함.

더 큰 공격을 위한 실전 시험이거나, 피해는 최소화하면서 제3자에게 자기들 역량을 보여주는 일일 수도 있음.

비슷한 서비스를 운영하는데 이런 공격은 거의 매일 받음. 문서 사이트 자체보다 유명 제품의 도메인을 얹고 있어서 자동화 도구가 빈틈을 찾는 표적이 되는 경우가 많더라.

Under Attack Mode를 안 쓴 건 흥미로움. API를 깨기 싫었던 건 알겠는데, API가 아닌 방문자만 잠깐 챌린지했어도 도움이 됐을 것 같음.

글에서 그 부분을 직접 설명했음. JS 챌린지는 쓰지만 모두에게 걸고 싶지는 않았고, 완전 장애와 Under Attack Mode 중 하나를 골라야 할 만큼 나빠지지는 않았음.

이게 AI 스크래퍼 설정 실수일 가능성도 있지 않나 싶었음. 요즘 에이전트형 스크래퍼는 스스로 재시도하고 경로를 찾으니 DDoS처럼 보일 수 있음.

작성자인데 설정이 잘못된 스크래퍼는 아니었음. 유용한 문서는 거의 안 가져가고 404와 302만 노렸으며, CDN을 안 거치는 URL 패턴을 찾으면 수백만 변형을 만들었음. AI가 만들었는지와 별개로 장애와 오토스케일 비용을 노린 공격으로 보임.

정적 문서가 CDN 캐시에 있다는 말은 여기엔 맞지 않음. 공격이 의도적으로 캐시 미스를 노렸고, 서비스 중단보다 조직의 비용을 키우려 했을 수도 있음.

공격 원본 ISP가 처리하지 않는 이유는 각 감염 호스트가 보내는 트래픽은 크지 않고 참여 호스트는 수만에서 수십만일 수 있기 때문임. ISP가 고객을 끊기 전에 신고를 검증해야 하고, 짧은 90초짜리 DDoS 때문에 감염 고객을 차단시키기도 현실적으로 어려움.

Under Attack Mode가 해결한다고 단정하기는 어려움. 이 공격은 다른 방어에도 적응했으니 JS 인터스티셜을 어떻게 우회하려 할지 궁금함.

내 직장 사이트에서는 더 작은 주거용 프록시 스크래핑에도 Under Attack Mode가 부분적으로만 먹혔음. Business 플랜인데 JA3/JA4 지문과 detection ID 때문에 Enterprise Advantage를 검토 중이고, 영업 문의식 가격은 꺼림칙함.

그래도 Under Attack Mode면 공격량을 거의 무시할 수준까지 줄였을 거라 봄. 봇도 JS 챌린지를 풀긴 하지만 공격량이 높을수록 챌린지 난도가 올라가서 결국 떨어질 가능성이 큼.

실사용자에게 탈출구를 남기겠다는 결정은 좋았음. 대륙 단위 차단 같은 조치는 공격 중이 아니어도 너무 무책임하게 쓰이는 걸 자주 봄.