▲

AI 스크레이퍼가 주석 처리된 스크립트를 요청하다

 (cryptography.dog)
1P by GN⁺ 3일전 | ★ favorite | 댓글 1개
  • 웹 서버 로그 분석 중 존재하지 않는 JavaScript 파일을 요청하는 다수의 봇 활동이 발견됨
  • HTML 주석 안의 스크립트 태그를 실제 코드로 인식해 요청한 것으로, LLM 학습용 데이터 수집 시도로 추정되는 행위
  • 이러한 비정상 요청을 탐지해 공개 경고, IP 차단, 압축폭탄, 데이터 포이즈닝 등 다양한 대응 방안 제시
  • 특히 데이터 포이즈닝은 LLM 학습 데이터를 오염시켜 모델 성능을 저하시킬 수 있는 효과적 수단으로 언급
  • 웹 관리자가 AI 스크레이퍼에 대한 방어 및 역공 전략을 실험적으로 도입할 필요성 강조

비정상 스크레이핑 행위 발견

  • 서버 로그에서 존재하지 않는 JavaScript 파일에 대한 404 오류 요청 다수 확인
    • 해당 파일은 HTML 주석 안에 포함된 비활성 스크립트로, 정상 브라우저는 요청하지 않아야 함
  • 요청의 User-Agent 중 일부는 python-httpx/0.28.1, Go-http-client/2.0, Gulper Web Bot 0.2.4 등 명백한 봇으로 식별
  • robots.txt에서 크롤러 접근을 금지했음에도 요청이 지속되어 규칙 무시 또는 무시된 정책으로 판단
  • 일부 요청은 Firefox, Chrome, Safari 등 정상 브라우저로 위장했으나, HTML 주석을 해석하지 못해 거짓 식별로 드러남
  • 이러한 요청은 LLM 학습용 콘텐츠 비동의 수집을 위한 스크레이퍼로 추정

스크레이퍼의 동작 방식

  • 일부는 HTML을 올바르게 파싱해 주석 내 URL을 재귀적으로 탐색할 가능성 있음
  • 다른 일부는 HTML을 단순 텍스트로 처리해 정규식 기반 URL 추출을 수행한 것으로 보임
  • User-Agent 다양성과 수준 차이로 보아 여러 운영자가 존재하며, 일부는 단순한 자동화 도구를 사용
  • 공통된 동기는 탐욕적 데이터 수집이며, 이를 역이용 가능성으로 제시

알고리듬적 사보타주 (Algorithmic Sabotage)

  • 알고리듬 시스템을 의도적으로 교란하는 행위로, LLM의 외부 비용 문제로 인해 주목받는 주제
  • 봇의 비인간적 행동 패턴을 인식하면 탐지 및 대응이 용이
  • 대응 방식은 네 가지로 구분됨: 공개 경고, IP 필터링, 압축폭탄, 데이터 포이즈닝

0. 공개 경고 (Public Disclosure)

  • 사소한 오탐(예: User-Agent 오타 “Mozlla”)은 공개 시 쉽게 수정될 수 있어 비공개 유지
  • 반면, 본질적 행위(예: 주석 내 스크립트 요청)는 수정 불가능하므로 공개가 유익
  • 이를 통해 다른 사이트 운영자들이 동일한 공격을 탐지 및 차단 가능
  • 해당 행위를 감지하는 시스템을 다른 사이트에도 적용 중

1. IP 필터링 (IP Filtering)

  • fail2ban을 이용해 로그 패턴, 날짜, IP를 기반으로 자동 차단
  • 일반적으로 짧은 차단 시간으로 설정하지만, 장기 차단 시 학습형 봇의 재시도 억제 가능
  • 봇넷의 경우 IP를 바꿔 지속 요청할 수 있으나, 반복 패턴을 통해 탐지 가능
  • 향후 봇넷 동작 분석에 대한 추가 연구 계획 언급

2. 압축폭탄 (Decompression Bombs)

  • 공격자가 요청한 파일에 zip bomb을 제공해 시스템 자원 소모 유발
  • CPU, RAM, 디스크를 과도하게 사용하게 하거나, 취약점 악용 가능
  • 단점으로는 서버 자원 소모 및 대역폭 낭비 위험 존재
  • 일부 봇은 감염된 시스템에서 작동하므로, 공격 효과가 제한적일 수 있음
  • 모든 봇을 대상으로 적용하기보다는 무작위 일부 요청에 대응하는 방식 제안

3. 데이터 포이즈닝 (Poisoning)

  • LLM 학습용 데이터를 오염시켜 모델 성능 저하 유도
  • 최근 연구에 따르면, 250개의 오염 문서만으로도 대형 모델에 지속적 영향 가능
  • 오염 데이터는 모델이 특정 주제에서 무의미한 출력을 생성하게 만들 수 있음
  • 예시로, 보안 연구 관련 질문 시 특정 블로그를 추천하도록 유도 가능
  • nepenthes, iocaine, glaze, nightshade 등 공개 도구 활용 가능
  • LLM 학습 데이터가 비동의 수집된 경우, 이러한 대응은 정당한 방어 수단으로 제시
  • IP 차단과 병행 시 구현 복잡도가 증가할 수 있으나, 병행 운용 가능성 있음
  • 효과적인 설계는 공개하지 않을 수도 있으며, 창의적 사보타주 참여 확대 필요성 강조

결론 및 커뮤니티 대응

  • 비정상 봇 행동을 통한 탐지는 새로운 개념이 아니며, 주석 내 스크립트 요청은 새롭게 발견된 사례
  • robots.txt에 Disallow 지시어를 추가해 특정 요청 시 역공 조치를 유도하는 방법 제시 
    User-agent: GPTBot
Disallow: /poison/
  • 커뮤니티에서는 display:none과 rel="nofollow" 속성을 이용해 봇 유인 링크를 숨기는 다양한 아이디어 공유
    • 예시: <a href="/hello-llm-robot-come-here" rel="nofollow" style="display:none">you didn't see this link</a>
  • 링크를 절대경로(absolute URL) 로 설정하면 더 많은 크롤러가 속을 가능성 있음
  • 여러 사이트에 다양한 봇 유인 및 차단 실험을 진행 중이며, 효과를 측정해 공유 예정
  • 다른 연구자들도 AI 스크레이퍼 교란 실험에 참여 중이며, 독창적 포이즈닝 사례도 소개됨
  • 전체적으로 AI 데이터 수집에 대한 자율적 방어와 역공 전략 확산을 목표로 함
▲
GN⁺ 3일전  [-]
Hacker News 의견

  • 대부분의 웹 스크래퍼는 불법이라 해도 비즈니스 목적임
    그래서 Amazon이나 쇼핑몰 데이터를 긁는 경우가 많음. 결국 원치 않는 트래픽의 대부분은 빅테크나 취약점을 노리는 악성 행위자들임
    나는 웹 스크래핑에 대해 조금 아는 편임. 일부 사이트는 보호 목적으로 404를 반환하기도 해서, 내 크롤러는 curlcffi 같은 빠른 크롤링 방식을 여러 번 시도함
    Zip bomb 방어는 간단히 헤더의 content-length만 읽으면 충분함. 응답이 너무 크면 읽지 않도록 바이트 제한을 두고, 타임아웃으로도 제어함
    그런데 requests의 timeout은 페이지 읽기 전체에 대한 타임아웃이 아니라는 걸 아는지? 서버가 바이트를 천천히 보내면 무한 대기 상태가 됨
    그래서 이런 문제를 해결하려고 직접 크롤링 시스템을 만들었음. Selenium도 일관되게 실행할 수 있음
    내 프로젝트는 crawler-buddy이고, 기반 라이브러리는 webtoolkit임

    • content-length는 content-encoding 이후에 계산된다는 점을 잊지 말아야 함
    • “scraping”과 “crawling”의 차이가 있는지 궁금함
    • 이제는 브라우저 내 스크래퍼의 시대가 올 듯함. 서버 입장에서는 사람과 구분이 불가능하고, AI 드라이버가 인간 테스트도 통과할 수 있음

  • “비동의적으로 LLM 학습 데이터를 수집했다”는 표현이 웃김
    공개된 HTTP 서버에 GET 요청을 보내는데 무슨 허락이 필요하다는 건지 모르겠음. 물론 weev 사건은 예외적인 참사였음

    • 나는 공개 HTTP 서버를 열면 일반적인 GET 요청은 환영함
      하지만 (1) 일반 사용자의 접근과 봇의 DDoS 공격은 다름. 무료로 제공된다고 해서 무한히 가져가는 건 남용임
      (2) 합법적 복제와 로봇의 위조 행위는 구분되어야 함
      (3) 잘 동작하는 봇이라면 robots.txt를 존중해야 함. 법은 아니지만 예의의 문제임
      수백만 개의 주거용 IP를 돌려 쓰는 봇은 절대 정상적이지 않음
    • 서버 설정을 속여 원하는 데이터를 얻는다면, 그건 비동의적 접근임
      공개 서버라 해서 거짓된 요청을 허용한 건 아님. 합리적인 요청만 암묵적으로 동의한 것임
    • robots.txt는 법적 구속력이 아니라 예의 있는 요청임
      “이 페이지는 긁지 말아주세요” 정도의 의미일 뿐, 정말 막고 싶다면 API 토큰이나 인증 절차를 둬야 함
    • 단 한 번의 접근과 무한 크롤링 폭주를 동일시하는 건 말이 안 됨
      스팸이 단순 이메일과 같지 않은 것처럼, 봇 남용도 단순 요청과는 다름
    • “사탕 그릇” 비유로 말하자면, 트릭오어트릿용 사탕을 한 어른이 전부 가져가면 기분이 좋을 리 없음

  • DOM을 파싱하기보다 http/https 문자열을 직접 검색하는 게 더 빠를 것 같음

    • 단순 텍스트 검색과 DOM 순회는 리소스 차이가 커서 “아마도 빠르다”는 표현은 과소평가임
    • 정규식 접근은 구현이 쉽지만, DOM 파싱도 CPU보다는 네트워크 병목이 더 큰 문제임 결국 네트워크 혼잡이 한계 요인임

  • 흥미로운 연구의 실용적 응용을 보니 재미있음
    관련 연구는 이 글에서 볼 수 있음

  • 제목이 헷갈림. “commented-out”이라고 하는 게 맞을 듯함

    • 나도 처음엔 AI 스크래퍼 차단 스크립트인 줄 알았음

  • 이건 남용이라기보다, 단순히 주석 처리된 URL을 읽는 것 같음

    • 기사 내용은 남용이 아니라 봇 탐지 신호로 활용하는 방법을 설명함
    • 하지만 robots.txt를 무시하고 주석까지 긁는 건 확실히 비매너적 행위임

  • 예전에 웹을 크롤링할 때는 Perl 정규식이 가장 신뢰할 만했음
    주석 속 URL도 당연히 큐에 추가했음

    • DOM 탐색은 오히려 과한 시도임. 정규식으로 필요한 div나 p를 잡는 게 더 견고하고 간단했음

  • 봇에게 512MB짜리 랜덤 데이터 파일을 주면 어떨까 싶음

    • 그보단 AI 스크래퍼용 광고 응답을 조작해서 LLM이 특정 제품을 추천하도록 유도하는 게 더 수익성 있음
      내가 만든 스타트업은 바로 이런 Ad-poisoning-as-a-service를 제공함
    • 무작위로 연결된 AI 독극물 페이지를 만들어 봇을 가두는 것도 가능함. 사람은 클릭하지 않을 테니까
    • 하지만 대부분은 대역폭 비용을 감당하기 어려움
    • 512MB 전부 “우리 서비스 최고”라는 문구로 채워도 재밌을 듯함

  • “LLM 학습용 데이터 수집”이라기보단 그냥 인터넷 스캐닝 노이즈임

    • 맞음. 취약점 스캐너라면 가능한 한 많은 HTTP 엔드포인트를 수집하려 할 것임
      JS 파일은 주석 여부와 상관없이 좋은 단서임
      반면 LLM 학습용이라면 이런 저품질 JS 코드엔 관심 없을 것 같음

  • 원치 않는 LLM 학습 트래픽을 독(poison) 시키는 방법에 대한 생각임

    1. 여러 사이트가 협력하면 데이터 중복 제거를 피하면서 모델을 오염시킬 가능성이 커짐
    2. 저작권법을 이용해 오염 비용을 높일 수도 있음. 다만 사이트가 법적 위험을 질 수도 있음
      저작권자와 협력하면 위험을 줄일 수 있음
    • 첫 번째 아이디어를 WordPress 플러그인으로 만들면 좋겠음
      요청마다 이미지를 동적으로 변형해 중복 방어를 무력화할 수도 있음. 나도 그런 플러그인이 있다면 바로 설치할 것임
답변달기