▲

문제가 있으면 IP 레벨에서 차단하세요

 (boston.conman.org)
14P by GN⁺ 2일전 | ★ favorite | 댓글 4개
  • 최근 웹 트래픽 분석중에 Thinkbot이라는 웹봇이 가장 많은 트래픽을 발생시킨 것을 발견함
  • 해당 봇은 robots.txt를 무시하며, 자기소개 문구도 단순히 “문제 있으면 IP 차단해라”라는 식으로 매우 불성실함
  • 한 달 동안 74개의 서로 다른 IP를 사용했고, 이는 41개 네트워크 블록에 걸쳐 분산되어 있었음
  • 조사 결과 이 모든 네트워크 블록은 Tencent 소유였으며, 이게 Great Firewall 비용 전가 가능성과 연결되는건지 의심이 생김
  • 결국 약 47만 개 이상의 IP를 포함하는 방대한 차단 규칙을 추가했음

Thinkbot의 등장

  • 웹 트래픽 분석 중 Thinkbot이라는 이름의 웹봇이 상위 점유율을 차지한 것을 발견함
  • User-Agent 문자열은 다음과 같이 불성실했음

    “Mozilla/5.0 (compatible; Thinkbot/0.5.8; +In­_the­_test­_phase,­_if­_the­_Thinkbot­_brings­_you­_trouble,­_please­_block­_its_IP_address._Thank_you.)”.

    • “테스트 단계에서 문제가 되면 IP 차단해 주세요”라는 문구 외에 참조 URL조차 없음
  • robots.txt 파일을 전혀 존중하지 않고 크롤링을 진행함
  • 웹사이트 운영자로서 이를 차단하려 해도, 단일 IP가 아니라 74개의 IP 주소를 사용
  • 이를 역추적해 ASN을 조회한 결과, 41개의 네트워크 블록에서 발생한 것임
  • 이는 단순한 단일 IP 차단으로는 방어가 불가능함을 의미

Tencent 연관성

  • 이 41개의 네트워크 블록은 모두 Tencent 소유였음
  • 저자는 중국 정부가 이를 묵인하거나 장려할 수 있으며, 외부 세계에 Great Firewall 비용을 전가하려는 시도로 해석할 수 있다고 의심함
  • 중국 내에서는 콘텐츠 수집이 허용되고, 외부에서 차단되더라도 CCP 입장에서는 문제가 없지만, 차단을 시도하는 다른 국가·사이트에는 부담으로 작용함

방화벽 차단 조치

  • 저자는 직접 badbots 방화벽 규칙에 Tencent 네트워크 블록을 추가함
  • 예시: 43.130.0.0/18, 101.32.0.0/20, 150.109.96.0/19 등
  • 총 40여 개의 네트워크 블록을 추가했으며, 이게 Tencent가 소유한 IP 전체를 포괄하지는 않으나 476,590개 이상의 고유 IP를 포함

결론과 비유

  • 저자는 이러한 상황을 “인터넷에서는 더 이상 좋은 것을 가질 수 없다”라는 현실로 표현
  • 단순한 봇 트래픽 차단을 넘어, 인터넷 생태계 전반의 신뢰 저하와 불가피한 방어적 대응을 보여주는 사례
▲
mango 20시간전  [-]

우와.. 진짜 짱이다..

답변달기
▲
GN⁺ 2일전  [-]
Hacker News 의견

  • 웹 크롤러를 개발하면서 최대한 친화적으로 만들고자 노력했음. robots.txt를 엄격하게 확인하고, 느리게 크롤링하며, User Agent 문자열에 명확히 신원을 밝히고, 단일 IP 주소만 사용함. 그런데 robots.txt 파일 자체에 적용되는 각종 봇 방지 트릭을 경험하게 됨. 최근엔 slow loris 공격처럼 robots.txt가 매우 느리게 다운로드되어, 실수로 404로 처리하고 계속 크롤링하게 됨. 그 경험 이후 타임아웃 시 Disallow /로 처리하는 코드로 바꿈. 아이러니하게도, 규칙을 잘 지키려고 해도 anti-bot 도구를 탐지하는 코드를 쓰게 되는 상황임

    • 도둑을 막으려고 초인종을 숨기는 것과 같다는 생각임

    • 서버 애플리케이션에서와 마찬가지로, 클라이언트에서도 상대방이 악의적이거나 잘못된 행동을 보이면 조용히 TCP 연결을 끊음. 상대방이 한동안 자원을 낭비하다가 스스로 상황을 인식해야 함

    • 이런 현상이 일부러 그런 게 아닐 가능성이 높다고 생각함. robots.txt 규칙을 안 지키는 악성 봇들은 애초에 파일을 다운로드하지도 않으니까, 악의보다는 실수나 무능일 수도 있음

    • 규칙을 지키려는 사람만 처벌하는 제재는 오히려 역효과라는 생각임

    • 규칙을 잘 지키려 노력하는 점을 높이 평가함. robots.txt에 제한을 거는 게 실수일 수도 있지만, 어떤 크롤러들은 robots.txt에서 더 흥미로운 페이지를 찾기 때문에 이를 늦추는 방법이 빠르게 문제를 피하는 데 도움이 될 수 있음. 결국 이런 방식이 봇의 정보를 차단하고 속도를 늦추는데, 사이트 운영자 입장에선 악성 봇 때문에 피해를 보니 정직한 봇과의 구분에 크게 신경 쓰지 않을 수밖에 없음

  • 봇 때문에 심각하게 피해를 보는 웹사이트는 어떤 공통점이 있는지 궁금함. 나는 .com TLD로 집에서 웹 서버를 여러 해 운영했으며, 관련 키워드에서 구글 검색 순위도 높은 편이고, 라우터나 서버에 특별한 봇 차단 설정도 없었음. 호기심에 봇 요청만 세 본 적은 있으나, 대부분 포트 스캔이나 인덱스 페이지 정도만 가져가고, 동적으로 불러오는 링크들은 거의 따라오지 않음. Apache 2 시절이나 Axum으로 여러 사이트 운영 중인 지금이나 봇으로 인한 눈에 띄는 영향이 없음. 아마 디렉토리 리스팅 때문일까 궁금하며, 설명을 들으면 좋겠음

  • 웹 스크래핑 이슈에 많은 똑똑한 사람들이 과하게 집착하는 느낌임. 만약 봇 활동이 실제로 사이트에 엄청난 부하나 문제를 일으키지 않는 이상(물론 예외는 있겠지만), 대부분은 의미 없는 ‘깃발 뺏기’ 게임에 불과함. 이 게임의 차이는 결국 상대 깃발을 찾지 못하고, 그저 시간만 잃는다는 점임. 가장 좋은 대처는 확산되는, 식별이 어려운 참가자들이 부하를 유발하더라도 빠르고 잘 설계된 웹 제품을 만드는 것이라고 봄. 현실적으로 이 접근법은 실제 인간 사용자의 만족도도 크게 높여줌

    • 경험상 이 문제의 심각성을 모를 수도 있다고 생각함. 이전 직장에서 웹 앱의 애플리케이션 성능을 담당했었는데, 사용자 일부가 번개처럼 빠르지만 대부분은 느림. 성능 로그를 분석하다 보니, 전체 요청의 60%가 알려진 봇임(엉뚱한 봇은 제외). 심지어 몇몇 회사는 서비스에 DoS 공격을 가하기도 했고, 이로 인해 사이트가 내려갔던 적 있음. 문제는 봇이 항상 캐시된 응답만 가져가기 때문에 실제 사용자 대화는 LRU 캐시에서 계속 밀려남. 어떤 봇은 방문했던 모든 페이지를 몇 분마다 재스크래핑하고, 어떤 봇은 스루풋을 올리다 서비스가 느려질 때까지 밀어붙임. 때로는 자바스크립트 실행 및 폼 제출까지 시도함. 구글봇만 유일하게 예의바르게 동작함. 실제 유입 트래픽의 40%가 단 한 개의 URL에 집중되는 등, 봇 때문에 얻는 이득도 거의 없음. 뒤늦게 알게 된 사실이지만, 많은 봇이 초창기 AI 기업 데이터 수집용임을 깨달음

    • 친구가 친구들끼리만 사용하는 작고 공개된 gitea 인스턴스를 운영 중임. 그런데 매시간 수천 건의 봇 요청이 옴. 서비스에 직접 영향을 주지 않아도, 최소한 괴롭힘처럼 느껴짐

    • 나는 빠른 웹 제품을 만들기 위해 데이터를 프리미엄으로 지불해서 얻음. 그래서 이런 엔터티를 차단하면 시간 낭비가 아니라 실제로 대역폭과 서버비용을 절약할 수 있음. 덕분에 진짜 고객들도 컨텐츠가 스크랩되지 않아도 아무런 불편함 없이 같은 혜택을 누림. 누군가에게 착취당한다고 생각하는 논리를 이해하지 못하겠음

    • ‘덤불 게임(capture the flag)’보다는 두더지 잡기 게임에 가깝다고 봄. 개인적 경험으론, '나쁜 봇'을 식별해 차단하려고 하는 포럼에서는 항상 더 많은 봇이 등장해 끝이 없음

    • 우리 중에 똑똑한 사람이 많긴 하지만 기술 문제에 과도하게 집착하는 경향도 있음. 아무것도 안 하면 계속 신경 쓰일 것 같고, 차단이라도 하면 짜증이 덜함

  • robots.txt를 진지하게 받아들이는 사람이 Hacker News에 생각보다 많아 늘 놀라움. 좋은 의도를 가진 사람이 많다는 점이 참 인상적임. 하지만 robots.txt가 실질적 해결책은 아님. 사람들이 robots.txt라는 걸 알아야 하고, 크롤러에 robots.txt 검사 코드를 추가해야 하니까 복잡함이 따름. 다른 실질적인 솔루션이 있는지 궁금함. ‘마이크로페이먼트’나 ‘실명 인증을 위한 대형 머클 트리’ 등등은 오래전부터 거론됐지만 실제로 구현된 적은 없음

    • robots.txt를 모르는 봇 개발자는 거의 없을 것 같음. 자기 프로젝트는 모두의 규칙을 무시해도 되는 특별한 경우라고 착각하는 사람들이 있을 뿐임

    • robots.txt는 법적 강제력이 없음

  • 우리 로그에도 그런 봇 패턴이 보임. 꽤 거슬리지만 그래도 봇임을 밝히고 실제 트래픽은 많지 않음. 대부분의 트래픽은 실제 브라우저인 척하거나, 브라질과 아시아 여러 IP에서 유입되는 봇임. 봇 차단을 위해 최근 일주일간 갖은 시도를 해봤기에, 도움이 될 만한 경험을 공유함.

    • 수백 개의 IP에서 하루에 몇 번씩만 요청이 오지만, 전부 실제 UA로 가장함

    • referrer URL을 거의 보내지 않지만, Huawei Cloud 봇은 referrer를 보내기도 함(대신 트래픽은 적음)

    • 주요 시도는 id=가 포함된 URL의 대역폭을 제한(1Kb/s)해서 느려지면 포기할 줄 알았으나, 봇들은 신경도 안 쓰고 계속 요청함

    • keep-alive 연결에도 적응해서 /cgit/에선 keep-alive를 아예 껐지만, 역시 연결을 다 차지해버림

    • 현재 쓰는 방법은 id=가 포함된 URL은 notbot 쿼리 문자열이 있는 경우만 허용, referrer가 없으면 403 메시지에 정식 유저라면 notbot 파라미터를 추가하라는 식으로 안내함. 이 방법으로 로드는 줄이고 정식 사용자 연결도 개선됐지만, 봇은 여전히 요청하고 403만 계속 받음

    • 결론적으로, 사이트별 특화된 ad hoc 방식을 쓰거나 Cloudflare 같은 충분한 자원을 가진 곳에 맡기는 두 가지 방법밖에 없는 듯함. 표준적인 봇 차단 솔루션은 자원 많은 쪽에서는 충분히 우회하거나 비용을 감당할 수 있기 때문에 한계가 있음

    • MSIE 3.0이나 HP-UX 같은 잘 안 쓰는 UA 서브스트링을 403으로 미리 차단하는 방법도 있음. 이후 403 로그를 모아 문제가 되는 ASN만 별도로 차단하는 식으로 두더지 잡기를 반복함

    • 나는 djbwares의 Bernstein publicfile 계열 소프트웨어를 씀. static GEMINI UCSPI-SSL 도구도 추가했으며, GEMINI 스펙에서 따온 아이디어로 요청 URL 내 fragment와 쿼리파라미터를 모두 금지함. 이유는 GEMINI에서 금지하는 논리와 동일하게 static HTTP 서비스에도 적용할 수 있음. 서버 설정상 쿼리파라미터를 제대로 처리하려면 특이한 파일명 여러 개를 별도로 생성해야 하며 현실적으로 힘듦. 이 아이디어 덕분에 CGI나 PHP 취약점 공격 시도가 애초에 파일시스템에 닿지도 못하고, 요청을 분해하는 단계에서 걸러짐. static 사이트 운영자는 GEMINI처럼 쿼리파라미터까지 차단하는 걸 추천함. 물론 static 사이트 카테고리에서 쿼리파라미터를 진짜로 쓰고 싶으면 예외임

  • 언젠가부터 IP 범위를 화이트리스트로 두는 방식이 실제로 가능할지 궁금해짐. adblock 리스트처럼 커뮤니티가 노력해서 관리하는 접근도 상상해봄

    • 불행하게도 잘 지키는 봇일수록 안정적인 IP를 쓰며, 악성 행위자는 언제든 가정용 프록시를 씀. 주거 프록시 IP를 금지하면 실제 사용자에게 피해가 가고, 악성 사용자는 바로 다른 곳을 씀. 실제 수천 개 IP를 상대해본 경험상, IP 기반 정보만으로는 판단이 힘들고 추가 정보가 필요함

    • Pokémon Go 회사도 출시 직후 스크래핑을 막으려 이 방법을 시도했음. 세 가지 IP 카테고리로 나누고, 블랙리스트(Google Cloud, AWS 등), 비신뢰 IP(주거지), 화이트리스트(정상적인 IPv4 등) 분류함. 처음엔 주요 스크래퍼를 걸러냈지만, 가장 규모 큰 스크래퍼는 모뎀 단말기 농장을 운영하면서 이를 우회했음. 그래서 일반 사용자는 지도 없이 게임을 포기하고, 하드코어 플레이어는 오히려 스크래퍼 사용량을 유료로 늘림. 결국 서버에 더 큰 부하가 옴. Pokémon Go가 했던 여러 잘못된 결정 중 하나로 봄

    • 이미 많은 미국 회사들이 이걸 시행 중임. 그런데 해외에 있을 때에도 서비스를 해지할 방법을 제공하지 않으면서 요금을 계속 받는 경우, 이건 불합리한 점임

    • 화이트리스트와 블랙리스트는 반드시 이분법적으로 선택할 필요가 없음. 대부분의 트래픽은 회색지대에서 발생함. 특정 IP를 화이트리스트에 넣었는데 이상징후가 감지된다면, 화이트리스트에서 제거하고, 공지하고, 통보받고, 해소 사실까지 상호 조율해야 하는데, 이게 현실적으로 매우 복잡함. 오직 신뢰관계 있는 파트너 사이에서만 화이트리스트가 효과적임. 블랙리스트는 문제 많은 주소, 또는 CIA, 러시아, 중국, 클라우드 사업자 등을 막는 데 유용함. 기업 내부 전용 호스트 등 robust한 반남용 체계가 있는 곳만 화이트리스트로 두는 것이 현실적인 접근임

    • 나는 오픈 소스 프로젝트 GoodBots를 통해 긍정적인 봇 화이트리스트를 만들고 있음. PR 대환영임

  • 모든 요청에 커스텀 헤더를 추가해서 보내고, 그 외의 모든 요청은 차단하는 방법을 사용함

  • 외부는 Cloudflare 프록시를 쓰고, 내부적으로는 Crowdsec과 Modsecurity CRS를 Traefik 앞에 둠. 오탐을 줄이도록 조정한 후 매우 안정적으로 운영 중임. 임시 차단된 IP와 보고된 IP는 Crowdsec으로 보낸 뒤, Discord 채널에 로그로 올림. 하루 평균 수십 개의 다른 IP를 차단함. 체감상 비공개 리소스에 접근하거나 CVE를 노리는 시도는 미국 IP가 중국 IP보다 훨씬 많음. 공개 컨텐츠 크롤링은 신경 안 쓰고, 나머지는 전부 SSO 또는 인트라넷에서만 접근 가능함. 특정 국가를 차단하는 것보다 exploit이나 플러딩 시도 자체만 막는 게 더 효과적임

    • Crowdsec 같은 방식은 매력적이지만, 서버의 모든 트래픽을 영리기업에 넘기는 건 큰 리스크라고 생각함

    • 심각한 공격 시도는 결국 Cloudflare WAF 같은 곳에서 이미 막힐 것임

  • 많은 아파트 건물들이 몇 개의 IP 주소로만 외부에 나갈 수 있음(Carrier-grade NAT 참고)

    • 그래서 IP 차단으로 인해 오탐이 발생함. 하지만 이런 원칙 적용은 가치가 있다고 봄. 결국 이웃에 대한 책임이 따름

  • 내 트래픽의 절반 이상이 Bing, Claude, 그리고 페이스북 봇임. 이들은 주요 트래픽 기여자는 아니지만, 서버 자원만 잡아먹고 사이트가 느려질 때 주요 원인이 됨(AI, 마이크로소프트, 페이스북이 상식도 무시할 때가 많음). 중국 등은 악성 트래픽의 일부일 뿐, 진짜 문제는 robots.txt나 DNS rate limit을 무시하는 미국계 기업임

    • 궁금한 질문이 많고, 이 모든 걸 Claude에 묻고 있음. 아직 이런 인프라는 없지만, 선택한 LLM이 내 멍청한 질문 때문에 자원을 사용하는 만큼 사이트 운영자에게 보상하는 비즈니스 모델을 원함. 마치 YouTube Premium이 크리에이터에게 돈을 주듯이 말임. 실질적으론 불가능할 것 같긴 함
답변달기
▲
reagea0 2일전  [-]

또중국이네요

답변달기