아마존 AI 크롤러로 불안정해진 내 Git 서버

 (xeiaso.net)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 공개 Gitea 서버 git.xeserv.us가 AmazonBot 요청으로 불안정해져, 운영자는 AmazonBot 팀에 해당 도메인을 차단 목록에 넣어 달라고 요청함
  • robots.txt로 모든 봇을 Disallow: / 처리했지만 요청이 계속 들어와, 공개 Git 서버 운영 자체를 접어야 할 수 있는 상황이 됨
  • AI 크롤러는 사용자 에이전트를 바꾸거나 주거용 IP 프록시를 쓰는 방식으로 차단을 어렵게 만듦
  • nginx ingress에서 Amazon 사용자 에이전트에 418을 반환하도록 막았지만, 요청은 다른 IP에서 계속됐고 약 10% 는 amazonbot 사용자 에이전트도 없었음
  • 결국 Gitea 서버는 다시 VPN 뒤로 이동했고, 요청 전 작업 증명 검사를 거치는 리버스 프록시 Anubis가 만들어짐

AmazonBot 요청과 robots.txt 한계

  • 운영자는 AmazonBot 운영자에게 git.xeserv.us를 차단 도메인 목록에 추가해 달라고 요청함
  • Git 서버를 크롤링하려면 과도한 리소스 사용을 감당할 하드웨어 업그레이드 비용을 지불할 수 있도록 연락해 달라고 함
  • 모든 봇을 막는 robots.txt를 이미 설정했지만, 실제 요청 차단에는 충분하지 않았음
User-agent: *
Disallow: /
  • AI 크롤러 봇 차단이 어려운 이유도 함께 정리함
    • 봇이 거짓말을 함
    • 사용자 에이전트를 바꿈
    • 주거용 IP 주소를 프록시로 사용함
    • 그 밖의 방법도 사용함

nginx ingress 차단과 Anubis 공개

  • 2025-01-17 17:50 UTC에 nginx ingress 설정으로 사용자 에이전트 차단을 추가함
nginx.ingress.kubernetes.io/configuration-snippet: |
  if ($http_user_agent ~* "(Amazon)" ){
    return 418;
  }
  • 이 설정 뒤에도 봇은 매번 다른 IP에서 계속 요청했고, 약 10%의 요청에는 amazonbot 사용자 에이전트가 없었음
  • 2025-01-18 19:00 UTC에 Gitea 서버를 다시 VPN 뒤로 옮김
  • 이후 Gitea 서버 앞단에서 요청을 허용하기 전에 작업 증명을 검사하는 리버스 프록시를 만들기 시작함
  • 2025-01-18 23:50 UTC에 해당 프록시는 Anubis라는 이름으로 https://git.xeserv.us/에서 확인 가능해짐
  • 2025-03-26 14:27 UTC 기준 Anubis는 문서 사이트가 있는 독립 프로젝트가 됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 이제 변호사 명의 서한을 보낼 때임. Computer Fraud and Abuse Act 기소 지침을 보면, 미국 법무부는 일반적으로 명백한 공격이 아닌 공개 서버 접근을 “무단 접근”으로 보지 않지만, 이후 권한자가 명확한 서면 중지 요청을 보내고 피고가 이를 수령·이해하면 그 시점부터는 무단으로 본다고 되어 있음
    그래서 변호사에게 “명확한 cease and desist” 서한을 쓰게 하고, 변호사가 권하는 방식대로 등기우편이나 송달인으로 Amazon에 전달하면 됨. 아마 둘 다 하고 이메일도 보내야 함
    그다음 Amazon이 멈추는지 보면 되고, 멈추지 않으면 형사 고소를 넣을 수 있음. 그러면 Amazon도 신경 쓰게 될 것임
    https://www.justice.gov/jm/jm-9-48000-computer-fraud

    • “Amazon이 멈추는지 본다”는 건 그 요청이 실제로 Amazon에서 온 경우에나 맞음. 글의 세부 내용인 회전하는 사용자 에이전트, 주거용 IP, robots.txt를 해석하지 않는 듯한 행동을 보면 그럴 가능성은 낮아 보임
      Amazon bot은 알려진 Amazon IP 대역에서 와야 하고 robots.txt를 지켜야 함. Amazon 엔지니어도 다른 댓글에서 확인해 줌: https://news.ycombinator.com/item?id=42751729
      Amazon과 맞는 것이 “AmazonBot” 사용자 에이전트 문자열뿐이고 IP 대역이나 행동이 맞지 않는다면, Amazon에 변호사 서한을 보내는 건 돈을 태우는 것과 비슷함
    • 솔직히 이렇게 Hacker News 첫 페이지에 오른 것만으로도 충분히 부끄러워서, 상식 부서의 누군가가 내가 정중히 보낸 “내 git 서버 긁지 말아 달라”는 이메일을 읽고 답할 것 같음. 다음 화요일까지 답이 없으면 변호사에게 정식 중지 요청 서한을 쓰게 할 예정임
    • “로봇은 robots.txt를 지켜야 한다”는 법이 필요해진 걸까?
    • 여기서 송달인(process server) 이 정확히 무엇을 뜻하는지 궁금함

  • 이 댓글의 해결책이 마음에 듦: https://news.ycombinator.com/item?id=42727510
    사이트 어딘가에 사람이 방문할 리 없는 링크를 넣고, robots.txt에서 금지한 뒤, 어떤 IP가 그 링크를 방문하면 24시간 차단하는 방식임. OpenAI 크롤러가 특히 와일드카드를 무시한다고 하니 와일드카드 아래에 두는 식으로 처리함

    • 넓은 주소 대역을 쓰는 봇 활동을 상대해 본 적이 있고, 조건상 봇으로 확인되면 그 IP를 24시간 차단하는 비슷한 방식을 써 봤음
      하지만 관련 IP가 너무 많아서 트래픽에는 거의 영향이 없었음
      받은 헤더를 아주 자세히 보는 걸 추천함. varnishlog가 이런 데 꽤 좋고, 오래 들여다보면 모든 요청이 공유하는 특징을 찾을 수 있음. 예를 들면 보고된 언어와 지리적 위치의 특이한 조합, 같은 구식 브라우저 버전 같은 것임
    • 웹 크롤러는 정말 지긋지긋함. 8년쯤 전 일하던 곳에서 차량 이미지 서버가 내려간 적이 있었음. 문제의 크롤러가 우리 업무 특성상 가진 차량 이미지 링크에 접근했고, 이미지가 실제로 존재하지 않는 완벽한 악조건이 겹치면서 상태 보고서 이미지 서버를 사실상 DoS했음
      더 나쁘게도 오류 처리기에 버그가 있어서 이 조건이 발생할 때 서버 프로세스가 재시작됐고, 그 과정에서 “.NET 2.0 기준으로는 꽤 괜찮던” 캐시 구현까지 무효화됐음
      그래서 안전장치로 카나리 기법을 넣기 시작했던 기억이 남. 단순한 카나리 몇 개가 다른 웹 서버를 추가하는 것보다 여전히 쌌음. 물론 캐시 문제도 고쳤고, 그 서비스에 나쁜 요청이 너무 많아지면 “비명을 지르는” 방식도 추가했음
    • 내 검색 엔진용 크롤러를 만들 때, 현실 세계에 제대로 맞는 크롤러 라이브러리가 거의 없다는 걸 알게 됨. 결국 Amazon과 Google의 꽤 복잡한 중첩 robots 파일과 요청된 냉각 기간까지 지키는 구현을 직접 만들느라 꽤 노력했음
      그런데 정작 그 회사들의 크롤러는 자기들이 만든 매니페스트를 파싱하지 못하더라

  • 우리도 모든 AI·SEO 봇에서 같은 행동을 보고 있어서 추천함. robots.txt를 간신히 지키는 수준이고 차단하기도 어려움. 크롤링할 때는 스팸처럼 몰려와 부하를 크게 올려 고객사 서버를 많이 죽임
    AI 크롤러가 접근하고 싶다면 얌전히 굴거나 돈을 내야 함. 그렇지 않으면 거의 보편적인 차단이 결과가 될 것임

    • 해법은 전역 타르핏임. AI 크롤러를 빼고 생각해도 말이 됨. 예전에 구현해야 했을 때는 반수동으로 접근 로그를 파싱해서 /api에 초당 평균 X회 이상 요청하는 IP에 iptables로 -j TARPIT을 걸었음
      클라우드에서는 어떻게 구현할지 잘 모르겠음. 아직 거기서는 필요했던 적이 없음
      https://gist.github.com/flaviovs/103a0dbf62c67ff371ff75fc62f...
    • “거의 보편적인 차단”을 어떻게 한다는 건지 모르겠음. 그게 어렵다는 게 바로 문제 아닌가? 가능했다면 이미 그렇게 하고 있었을 것임
    • robots.txt를 “간신히” 지킨다는 게 무슨 뜻인지 궁금함. 이건 이진적인 것 아닌가? 일부 지시문은 지키고 다른 지시문은 무시한다는 뜻인가?
    • 웹사이트가 그 데이터를 큰 zip 파일로 AI 봇에 팔 수 있는 방법은 없을까? 계속 DDoS당하는 것보다 나을 것 같음
      아니면 최소한 예의상 야간이나 비혼잡 시간대에 긁어 갔으면 함
    • 차단하면 뭐하나? 그때쯤이면 이미 콘텐츠를 다 긁어 갔을 텐데

  • 이게 실제 Amazon이라고 가정하지는 않겠음. 글쓴이는 주거용 IP를 돌려 쓰고 사용자 에이전트 문자열도 바뀌는 요청을 보고 있음
    큰 회사 크롤러인 척하는 건 눈에 띄지 않으려는 사람들이 흔히 쓰는 기법임. 요청이 주거용 IP에서 온다는 사실은 다른 일이 벌어지고 있다는 큰 경고 신호임

    • Amazon에서 일하지만 웹 크롤링을 직접 담당하지는 않음
      내부에서 확인할 수 있었던 정보 기준으로는, 이게 실제 Amazon일 가능성은 매우 낮음. Amazonbot은 robots.txt를 지켜야 하고 항상 Amazon 소유 IP 주소에서 와야 함. 검증 절차는 여기 있음: https://developer.amazon.com/en/amazonbot
      혹시 내가 모르는 이상한 내부 팀이 이런 짓을 하는지 확인하려고 내부로 전달은 했지만, 글쓴이는 이 트래픽을 악성으로 보고 사용자 에이전트를 거짓으로 내세운다고 처리하는 편이 좋음
    • 이런 건 서비스로 상용 제공됨[1]. 어딘가에 포함된 라이브러리 때문에 수억 개 네트워크가 백도어처럼 쓰이며 크롤러·스크래퍼가 되고, 약관 어딘가의 포괄적인 문구로 사용자를 준법과 불법 사이 활동의 앞잡이로 쓰는 것까지 그럴듯하게 합법화함
      [1] https://brightdata.com/proxy-types/residential-proxies
    • 요즘 공격적으로 크롤링하는 회사라면 프록시 네트워크를 쓰지 않는다고 장담하기 어렵다

  • 최근 같은 문제를 겪었음. 내 Forgejo 인스턴스가 홈 서버 CPU를 100% 쓰기 시작했는데, Claude와 Meta·Google의 AI 친구들이 사실상 무한한 링크를 높은 속도로 때리고 있었음
    robots.txt와 Caddy의 사용자 에이전트 기반 차단 목록으로 어느 정도 줄였지만, 이게 얼마나 오래 통할지는 모름
    스크래핑의 예의는 다 어디로 간 걸까?

    • 돈 때문임. AI 회사들은 가능한 한 많은 데이터를 가능한 한 빨리, 얻을 수 있는 곳 어디서든 가져갈 재정적 유인이 있음. 지금은 태울 현금도 너무 많아서 효율적으로 할 필요도 별로 없음
    • 여러 회사가 적어도 당분간 AI가 무엇을 먹어도 되는지에 대한 오버턴 창이 엄청 넓다는 신호를 받았을 때, 규제가 조이려 하기 전에 최대한 가져가려 할 것임
      더 큰 위험은 이런 회사 중 하나가, 심지어 “Open”을 자처하는 회사가 경제나 국가안보 관점에서 “망하게 둘 수 없는” 규모가 되는 것임
    • 다른 모든 맥락에서의 예의와 같은 일이 벌어진 것임. 예의는 그것을 무시해도 돈이 안 되는 맥락에서만 존재했음. 그 전제가 사라지는 순간 바로 버려짐
    • AI 크롤러를 막을 만한 괜찮은 robots.txt나 사용자 에이전트 목록을 공유해 줄 수 있나?
    • Meta, OpenAI, 그리고 모든 거대 기술 회사가 빠른 돈을 위해 결국 우리 모두를 해칠 거라는 걸 Hacker News의 마지막 사람은 언제쯤 깨달을까?
      Facebook은 MySpace에서 친구 목록을 긁어오기 쉽게 만들었던 것으로 유명하고, 자기들이 커진 뒤에는 똑같은 행동을 자기 사이트에서 금지했음
      제발 정신 차려야 함

  • 이게 Amazon으로 위장한 DDoS가 아닌지 확실한가?
    요청이 주거용 IP에서 온다는 건 정말 수상함
    이런 DDoS의 동기는 작은 사이트들을 쓰러뜨리고 Amazon 책임처럼 보이게 해서 Amazon을 겨냥하는 것일 수 있음
    실제 Amazon이라면 시작점은 그들이 공개한 모든 IP 대역을 차단하는 것임. 다만 그 대역 밖에서도 요청이 오는 것처럼 들림

    • grass dot io 같은 웹사이트를 확인해 봐야 함. 트래픽을 주고 싶지 않아서 직접 링크는 안 걸겠음
      이런 서비스들은 사용자 대역폭에 돈을 주고, 그걸 제3자에게 되팔기 때문에 많은 봇 트래픽이 주거용 IP에서 오는 것처럼 보임

  • 내 사이트 Pinboard도 AI 크롤러로 추정되는 것들에게 두들겨 맞고 있음. 올여름에는 중국과 싱가포르 IP로 시작했지만, 이제는 IP 대역 차단도 못 해서 CAPTCHA에 의존해야 함
    트래픽 수준은 사이트를 즉시 죽일 만큼이고, 나는 학습시킬 만한 흥미로운 텍스트도 없고 링크뿐임
    원글 작성자가 어떻게 Amazon 크롤러가 원인이라고 알아냈는지 궁금함. 나도 책임을 돌릴 대상을 찾고 싶음

  • 이런 것과 싸우는 최선의 방법은 차단이 아닐 수 있음. 차단은 Amazon이나 다른 회사에 아무 피해도 주지 못함
    대신 봇에게 명백히 해롭거나 손상시키는 콘텐츠를 먹일 수 있다면 어떨까?
    더 큰 규모로 진행되고 Amazon이 독약 데이터를 발견하면, 그걸 빠르게 제거하는 데 돈을 써야 하고 봇이 그런 데이터를 먹지 못하게 하려 할 것임
    물론 그런 물건을 자기 사이트에 두고 싶은 사람은 없다는 게 가장 큰 문제임

    • “해로운 콘텐츠”를 먹인다는 생각은, AI 회사들의 나쁜 행동 범위를 완전히 오해한 것임
      이 스크래퍼들은 이미 CSAM과 그에 준하는 끔찍한 것들도 거리낌 없이 먹고 있음. OpenAI의 케냐 데이터 태깅 하청업체 일부가 이것 때문에 그만뒀음. 2023년 Time 기사임
      지금 AI 회사들은 데이터 품질에 관심이 없고 양만 봄. 그들에게 피해를 줄 수 있는 유일한 방법은 0바이트를 주는 것임
      Sam Altman이 승인한 것의 10분의 1만 해도 보통 사람은 바로 감옥에 갈 것임
    • 이 목적에는 이 타르핏이 추천되는 걸 본 적 있음. 사이트가 크롤링될 때 끝없는 디렉터리 중첩과 끝없는 쓰레기 콘텐츠를 만들어서 봇이 몇 시간씩 빠져 있게 함
      https://zadzmo.org/code/nepenthes/
    • 해로운 콘텐츠가 부정확한 콘텐츠를 뜻한다면, 이 스레드의 다른 댓글에 실제로 그런 걸 하는 사람이 있음: https://marcusb.org/hacks/quixotic.html
    • 억만장자 회사들이 계속 처벌 없이 법을 어기는데, 왜 내가 바람을 향해 오줌 누는 일을 책임져야 하나?

  • Amazon과 다른 봇들이 만든 송신 트래픽 초과분을 보전하는 선의의 표시로 AWS 크레딧을 좀 주면 좋겠음. 그래도 이 글의 광고 수익으로 아마 메꿔질 것 같음. 광고 차단을 풀면 손익이 맞음

  • Nginx로 차단하기 전에는 Bytespider가 59%, Amazonbot이 21%로 둘이 합쳐 우리 Git 서버 전체 트래픽의 80%를 차지했음
    ClaudeBot은 한 달 동안 Redmine에, ClaudeBot 이전 5년을 합친 것보다 더 많은 트래픽을 보냈음

답변달기