▲
GN⁺ 5달전 | parent | ★ favorite | on: 스크레이퍼 봇과 장난치기(herman.bearblog.dev)
Hacker News 의견

  • 세상이 변해도 결국 비슷한 문제를 겪게 됨
    10~15년 전 나는 소셜 미디어 모니터링 서비스들과 싸우고 있었음. 큰 브랜드들이 포럼의 감정을 모니터링하도록 그들에게 돈을 주었는데, 내가 운영하던 무료 커뮤니티를 무단으로 긁어가며 서버 부하를 일으켰음
    그들의 봇을 차단해도 IP와 UA를 바꿔 돌아왔기에, 게시글에 무작위로 브랜드 이름을 삽입하는 필터를 만들어 그들의 데이터 품질을 망가뜨렸음. 이 조치를 켜자 이틀 만에 스크래핑이 완전히 멈췄음

    • 나도 비슷한 경험이 있음. 내 사이트의 기부 폼을 신용카드 테스트용으로 쓰던 봇이 있었는데, IP를 바꿔가며 계속 시도했음. 그래서 차단 대신 성공/실패 메시지를 무작위로 돌려줬더니, 그들의 데이터가 오염되어 며칠 만에 포기했음
    • 헤더 분석 이야기가 정말 유용했음. 내 Fediverse 서버에서도 오래된 Chrome UA를 쓰는 봇들이 Accept-Language 헤더를 전혀 안 보내는 걸 발견했음. nginx에서 403을 반환하도록 설정하니 트래픽이 줄기 시작했음
    • 영화 The Imitation Game처럼, 모든 요청에 즉각 반응하면 상대가 눈치챔. 일부 요청만 처리하거나 무작위 오류 코드를 주면 탐지하기 어려워지고, 그들의 디버깅을 훨씬 어렵게 만들 수 있음
    • 대부분의 봇은 여전히 HTTP 헤더 세트를 제대로 흉내 내지 못함. 2025년에도 같은 방식으로 필터링하게 되었고, 봇들은 여전히 같은 패턴으로 진화 중임
    • 왜 회사 이름을 삽입하면 봇이 사라졌는지 궁금함. 혹시 그들이 브랜드 언급을 찾는 과정에서 데이터 신호가 오염되어서 그런 것인지 묻고 싶음

  • 이 봇들은 PHP 파일을 실제로 파싱하는 게 아니라, 그 존재 여부로 취약점 탐지용 지문(fingerprinting) 을 만드는 것임. 응답 코드만 보고 바로 버림

    • 맞음, 이런 경우엔 fail2ban이나 crowdsec 같은 도구가 더 효과적임. crowdsec을 써보니 트래픽이 적은 서버에서도 취약점 탐색 시도가 엄청 많다는 걸 알게 되었음
    • 그렇다면 일부러 가짜 취약점을 노출시켜 봇을 유인하는 전략도 가능할 듯함. 예를 들어, 자동화된 봇을 허니팟(honeybot) 으로 끌어들여 내부 동작을 관찰하는 식임. 참고: The Cuckoo’s Egg
    • 만약 LLM 스크래퍼들이 이런 응답을 학습 데이터로 쓴다면, 데이터 오염(poisoning) 위험이 커질 수도 있음. 최근 논문에서도 소수의 데이터 포인트만으로도 모델을 망가뜨릴 수 있다고 했음

  • 최근 AI 및 스크래퍼용 타르핏(tarpit) 이야기를 들었음. 연결을 끊지 않고 아주 느리게 무한 데이터를 흘려보내는 방식임. Nepenthes라는 도구가 흥미로워서 실험해보고 싶음

  • 예전엔 HN에서 스크래퍼를 막으면 비난받았음. “내가 어떻게 접근하든 상관없다”는 논리였음

    • 하지만 지금은 다름. 인간이 개인적으로 접근하는 것과, AI 기업이 대량으로 DDoS 수준의 요청을 보내는 건 완전히 별개임. 후자는 명백히 비용을 남에게 떠넘기는 행위임
    • 나도 정상적인 스크래핑은 괜찮다고 생각함. UA를 명시하고 robots.txt를 지키면 됨. 하지만 지금처럼 초당 수십 요청을 보내며 옛 Chrome 버전으로 위장하는 건 용납 불가임
    • 나는 학술 프로젝트로 하루 한 번씩 구인 사이트를 스크래핑함. 이런 건 합리적인 사용임. 반면, 분 단위로 콘텐츠를 긁어가거나 취약점을 찾는 건 완전히 다른 문제임
    • AI의 등장이 윤리의식 자체를 약화시키는 게 가장 우울함. 예전엔 자유를 중시하던 사람들이 이제는 저작권 강화나 익명성 제거를 요구함. 기술이 사람을 더 나쁘게 만들고 있음

  • Apache 서버를 직접 관리한다면, RewriteEngine으로 PHP 요청을 바로 차단할 수 있음

    RewriteEngine On
RewriteCond %{REQUEST_URI} (\.php|%2ephp|%2e%70%68%70) [NC,OR]
RewriteCond %{QUERY_STRING} \.php [NC,OR]
RewriteCond %{THE_REQUEST} \.php [NC]
RewriteRule .* - [F,L]

    내 서버엔 PHP가 없으니 이런 요청은 전부 악성임

    • nginx에서도 비슷하게 설정함. PHP나 ASPX 요청엔 HTTP 418 “I’m a teapot” 코드를 반환함 
      location ~* \.(?:php|aspx?|jsp|dll|sql|bak)$ { return 418; }
error_page 418 /418.html;
      이렇게 하면 로그 필터링이 쉬워짐. 예시: FreeSolitaire.win/wp-login.php

  • 대부분의 공격성 스크래퍼는 WordPress 취약점을 노림. PHP 파일 자체보다 그 출력 결과를 원함. 이런 설정은 일종의 허니팟에 가깝지만, 봇이 스크립트대로 안 움직이면 그냥 떠남

    • 아마 그들은 출력에서 정규식으로 관리자 로그인 패턴을 찾을 것임. 없으면 바로 건너뜀. 즉, 4KB짜리 가짜 PHP를 생성하는 것보다 정규식 한 줄이 훨씬 효율적임

  • 예전에 zipbomb 전략을 HN에 올렸다가 트래픽이 하루 10만 건으로 폭증했음. $6짜리 VPS로는 감당 불가였음. 지금은 가장 공격적인 봇만 zipbomb으로 대응하고, 나머지는 403을 줌. 새 전략이 잘 먹히지만 다시 공개할지는 고민 중임. 참고: 이전 글

  • 예전엔 fail2ban만 썼지만, 좀 더 재미있는 방어책을 만들고 싶었음
    .htaccess에서 의심스러운 경로(/.git, /wp-login)를 decoy.php로 리다이렉트하고, 10GB짜리 decoy.zip을 강제 다운로드하게 함.
    decoy.php는 요청된 민감 파일처럼 보이지만, 실제로는 가짜 로그와 SQL 데이터를 무한 스트리밍하여 봇을 붙잡아둠

  • 이 봇들은 PHP 파일을 긁는 게 아니라, 프레임워크 취약점을 찾는 것임. 예상치 못한 응답을 주면 바로 포기하고 다른 타깃으로 이동함

  • 가끔 이런 생각을 함 — 봇들이 낭비하는 리소스로 암호화폐를 채굴하게 만들 수는 없을까?

    • 시도하려면 JavaScript 실행을 유도해야 하지만, 대부분의 봇은 이미 그런 시도를 막는 대응책을 갖고 있을 것임