▲

봇 차단을 위해 작은 도구들 총동원하기

(lambdacreate.com)
3P by GN⁺ 4일전 | ★ favorite | 댓글 1개
  • 대형 AI/검색 회사들의 무차별적 크롤링과 스크래핑으로 인해, 개인 서버와 서비스가 심각하게 영향을 받으며, 리소스 소모와 서비스 불안정이 지속적으로 발생함
  • Zabbix·Loki 기반 모니터링으로 비정상 트래픽 탐지 후, log 분석 도구(lnav, goaccess)와 SQL 기반 쿼리로 공격자 패턴, IP, User Agent를 상세 파악
  • Nginx 설정에서 User Agent 기반 403 차단, rate limit, Fail2Ban 연동 등 단계별 방어 체계를 구축해 수백 개의 악성 IP 차단과 서버 안정화 실현
  • 주요 문제는 Gitea 저장소 전체를 tarball로 대량 다운로드 시도하는 봇들이었으며, 단순 콘텐츠 소비자가 아닌 "AI 데이터 수집/모델 학습 목적"의 트래픽이 급증함
  • 장기적으로 합법적 서비스(archive.org 등)에 대한 예외 처리와, 검색엔진 노출은 유지하되 AI 엔시티피케이션(en-shitification)에는 맞서는 전략을 고민 중임

서론: 내 작은 서버에 쏟아진 봇 트래픽

  • 최근 개인적으로 운영하는 lambdacreate 블로그 및 여러 서비스에 정체불명의 대량 트래픽이 급증함
  • Archive.org과 같은 합법적 서비스는 환영하지만, Amazon, Facebook, OpenAI 등 대기업의 무분별한 데이터 크롤링이 사이트에 피해를 줌
  • AI 모형 학습 등으로 인한 데이터 수집 수요가 높아지면서 이런 현상이 더욱 심각해짐
  • 이런 상황에서 진짜 독자(사람) 대신, 주로 대량의 봇 트래픽에 시달림

문제의 확인: 모니터링 툴을 통한 트래픽 폭증 진단

  • Zabbix, Loki 등 모니터링 툴을 사용해 서버 자원 소모 상황을 분석함
  • Gitea 인스턴스가 하루에 20~30GB에 달하는 데이터 증가 현상, 각종 CPU/메모리 경고 발생
  • nginx 트래픽 분석 결과, 한 달 평균 8req/s → 순간적으로 20req/s 이상까지 급증함
  • 트래픽은 대규모이진 않으나 평소보다 10배 가까이 증가해 자원 고갈을 유발함

공격 원인 분석: 로그 파일 심층 분석

  • lnav와 goaccess를 이용하여 nginx access 로그를 SQL로 분석함
    • 방문자 IP, UserAgent, Referrer 등 패턴 파악
  • 결과적으로, 특정 서비스나 커뮤니티발 유입이 아니라 특정 IP 대역에서 대량 크롤링 발생
  • UserAgent에 Amazonbot, OpenAI, Applebot, Facebook 등 명시 혹은 위조된 값 다수 발견
  • 이로 인해 실제 서비스 이용에 지장을 받자 강력한 차단 정책 필요성 대두됨

해결책: Nginx, Fail2Ban 등 여러 방어 계층의 결합 적용

  • Nginx map을 이용해 악성 UserAgent 즉시 403 반환, rate limit(방문 속도 제한) 도입
  • 신규·미탐지 봇까지도 웹 요청 빈도를 낮춤으로써 서버 부담 최소화
  • 403 발생 로그를 기반으로 goaccess, lnav로 새로운 악성 IP와 UserAgent 탐지
  • 자동화 보안 도구 Fail2Ban을 통해 403 응답 과다 발생 IP를 24시간 자동 차단
    • 735건 이상의 자동밴 기록
  • 실제 리소스 사용률이 상당 수준 정상화됨
  • 앞으로 archive.org 등 정상 서비스에 대한 예외 규칙을 적용하고, 검색엔진 인덱싱은 허용하되 AI 훈련용 무분별한 크롤링은 계속 차단 계획

결론: 도구 조합의 힘과 개인 서비스 보안의 필요성

  • 이런 일련의 다중 계층 방어책을 적용함으로써, 원활한 개인 블로그 운영과 서비스 접근성 복구
  • 다수의 작은 시스템 관리 및 자동화 도구 활용이 개인 서버 보안에 효과적임을 확인함
  • 성장하는 AI 학습 수요로 인해 개인 서버까지 무분별하게 크롤링되는 환경에서는, 적극적인 차단과 관리 자동화가 필수적임
▲
GN⁺ 4일전  [-]
Hacker News 의견

  • 많은 비양심적인 크롤러들이 대형 검색엔진을 흉내내기만 한다는 점을 자주 목격하게 됨, 유저 에이전트 정보에 속을 필요 없다는 사람들도 있는데, 내 방식 중 가장 좋아하는 건 robots.txt에 의심 정보(예: gzip bomb)를 넣고, 이를 감지한 크롤러가 다음 요청부터 차단되게 설정하는 방법임, Caddy로 간단하게 구현이 가능하고, 이렇게 하면 주로 심각한 위반자들을 잡아냄, 봇의 행동을 변명할 생각은 없지만, 만약 이런 봇 몇 개가 사이트를 다운시킨다면 악의적인 공격자에게 정말 취약한 사이트라는 증거가 됨

    • 마지막 코멘트가 정말 핵심을 짚었다고 느낌, 나랑 다른 세대일 수도 있지만 요즘 글 쓰는 분들이 왜 이렇게 적은 리소스 사용에 집착하는지 이해가 안 됨, 마치 조부모님이 LED 불 끄는 걸로 호들갑을 떨거나, 연료비 5센트 아끼려고 24km씩 운전하는 것 같음, 초당 20회 요청은 정말 아무것도 아님, 심지어 다이나믹하게 생성한다 해도(왜 굳이? 그 시간에 캐싱 세팅하는 게 훨씬 이득), 요즘 'fuck the bots' 같은 스타일의 글이 유행이긴 하지만 이건 새로울 것도 없는 주제임, 시간 낭비하지 않고 처리할 생산적인 방법 훨씬 많음

    • robots.txt로 gzip bomb 거는 방법 더 자세히 듣고 싶음, 대부분의 AI가 robots.txt 무시하는 걸로 알고 있는데, 결국 일부 순진한 크롤러만 걸리는 것 아닌가 궁금함, 남들에게 반대하는 것도 아니고 단순히 좋은 쪽에 피해 안 주고 구현하는 방법을 더 알고 싶음

    • 내 분야에서 제일 큰 위키 중 하나 운영하는데, 개발팀 다른 사람들 설득해서 gzip bomb을 쓰게 만드는 게 거의 불가능함, 이 방법은 위험 요소가 너무 크다(EU 규정 때문이라는 마인드)면서 추진할 가치가 없다고 고집함, 실제 공개 사이트에 진짜로 이런 방법 사용하는지 궁금함

  • 요즘은 봇들이 robots.txt 파일을 전혀 존중하지 않아서 진짜 화남, 이거 만든 사람들이 정말 이기적이라고 생각함, 그런 봇 만든 사람이면 알아서 하라는 생각임

    • robots 파일에 함정(허니팟) 심어두면, 완전히 무시하는 애들은 안 걸리더라도 일부러 말썽 부리러 찾아오는 봇들 걸러내는 데 도움이 됨

    • 챗봇, 검색엔진, 가격 비교 도구 같은 거 사용하는 사람에게도 비슷한 말을 해줄 수 있음, 사실 이런 사용자들이 스크래이퍼들을 경제적으로 유인하는 주범임

  • 글쓴이가 “이제 신경 안 쓴다”고 했다는 점은 이해하지만, 금지된 IP에 Google, ripe.net, semrush가 있는 걸 봤음, 다른 기업은 몰라도 Google은 정말 차단하지 않겠음, 사이트를 알리고 싶으면 Semrush나 ripe.net도 차단할 필요가 없다고 생각함, 내 콘텐츠가 AI나 이상한 애들이 스크래핑하더라도, 처음부터 사이트가 공개라면 어느 정도 활용될 거란 걸 각오해야 한다고 봄, 예를 들면 모텔 간판 불을 꺼놓고 손님을 초대하는 꼴임

    • Semrush는 오랫동안 여러 단계에서 진짜 심하게 민폐를 끼쳐서, 지난 8년 동안 robots.txt에 특이한 안내문까지 남겼음, 결국에는 법무팀까지 움직여서 겨우 진정시킨 경험이 있음, 내 입장에서도 'SEO' 업체가 실제 방문자를 밀어내면서 사이트를 거칠게 긁어가는 걸 허용하는 건 가치가 없음, Semrush 경쟁사들도 마찬가지로 심했음, 현재 AI 스크래퍼들도 수준이 너무 떨어져서, 대형 투자자와 PR 부서에까지 공식적인 항의문을 반복적으로 보내야 했던 적도 있음, 기술적으로도, 법적으로도 여러 방식으로 겨우 정상으로 돌려놓았음

    • 봇이 대량으로 트래픽(대역폭, 메모리, CPU, 디스크 자원)을 차지하는 게 실질적으로 문제임, 소개글에서도 납득할 수 없는 매너라고 언급되어 있음, 이런 트래픽을 스크래퍼에게 굳이 제공할 필요가 없다고 느낌, Google도 AI 스크래퍼를 돌리고 있어서 아마 그게 차단 목록에 잡힌 게 아닐까 생각함

    • Google을 사칭하는 진짜 악성 봇들도 존재함, 예전엔 Google이 상대적으로 예의를 갖추는 스크래핑을 했지만, 글쓴이가 차단하든 안 하든 이미 필요한 트래픽을 확보하고 있다면 신경 쓸 이유가 없을 것임

    • 지난 10년간 사람들이 Google을 사용해서는 안 된다는 걸 아직도 모르고 있었는지 궁금함, 특히 Google이 AI로 독립 사이트들을 검열하는 상황이 나타나고 있는데, 관련 코멘트도 직접 링크함, 이제는 Google이 오히려 위험(asset이 아니라 liability) 쪽에 가까워졌다고 봄

  • 봇 때문에 서버 로그 파일이 지나치게 커져서, 내 서버들은 아예 로깅을 끄는 상황을 맞음, 봇들이 API, 폼, 심지어 웹사이트에서 클릭으로만 접근 가능한 부분까지 집요하게 긁어감, Anthropic, openAI, Facebook 등도 여전히 내 사이트를 스크래핑 중임

    • 클릭으로만 접근 가능한 API의 경우라면, 봇들은 어떻게 접근하는지 궁금함

    • 그런 API 정보에 대해 더 자세히 알고 싶음, UI의 일부이거나 인간만 사용할 수 있는 부분을 의미하는지, 아니면 다른 경로가 아예 없는 것인지 명확히 하고 싶음, 최근은 AI 에이전트가 실제 사용자의 행동 패턴을 모방하므로, 인간과 봇을 구분하는 게 거의 불가능한 시대임

  • AI 크롤러 봇들이 User-Agent 헤더를 정직하게 채워줘서 좋다고 생각했는데, 이 정도로 트래픽이 많은 원인이 그것이라는 데 좀 놀랐음, 대부분의 웹사이트는 이렇게 자주 데이터가 필요하지 않은데도 트래픽이 너무 많음, 개발자 블로그라면 더더욱 이해되지 않음

    • AI 크롤러 대부분이 robots.txt를 준수하지만, 차단당하거나 막히면 곧바로 브라우저 유저 에이전트로 바꾸고, 주거용 IP에서 다시 크롤링을 시도한 사례들도 있음, 다만 가짜로 OpenAI/Amazon/Facebook을 사칭하는 경우가 워낙 많기 때문에 정확한 경우 구분에는 신중해야 함

  • tirreno 제작자임, 우리 플랫폼은 라이브 로그인 사용자에 최적화되어 있지만, 봇 탐지 및 차단에도 효과적으로 활용됨, IP 마지막 옥텟을 별표(*)로 치환해 같은 서브넷을 하나의 계정으로 묶어 IP를 익명화하는 방식을 사용함, 트래픽 이상(500/404 에러, 무차별 로그인 시도, 데이터센터 IP 등)에 대해 자동 블랙리스트를 생성하게 할 수 있음, tirreno의 블랙리스트 API로 원치 않는 트래픽을 에러 페이지로 리디렉션 가능, 모니터링 대시보드도 제공하여 오탐 방지와 관리에 도움이 됨
    tirreno Github, 관리자 데모

    • 요즘은 여러 ISP가 CGNAT 구조로 바뀌어서, 한 IP가 수백 명의 실제 사용자를 대표할 수도 있는 문제를 어떻게 처리하는지 궁금함

    • 공개된 IP범위 기반으로도 동일하게 봇 차단 개발 중임, 개선 아이디어 있다면 언제든 환영임

    • IP 마지막 옥텟 치환 방식으로 인해, 실제 내 정보와 전혀 상관없는 주소의 이웃과 단일 사용자로 묶이게 됨, 센터 IP로 인한 오탐도 무시 못 함, 실제로 뭔가 안 막혀 있으면 87개의 교통신호등을 클릭해서 간신히 통과해야 함, 결국 오탐을 회피하는 단계에서도 내 개인정보를 비동의 수집하진 않는다는 명분을 위한 것 같음, 고객이 실제로 유료 사용자를 놓치고 있다는 점을 즉각적으로 인지하게 만드는 피드백 구조는 꼭 갖춰주길 바람

  • 예전부터 궁금했던 점이 있는데, “페이지 노킹(page knocking)” 즉, 특정한 순서로 페이지들을 열어서 진입권한을 얻는 구조가 가능하지 않을까 생각함, 예를 들어 지정된 비공개 URL로 먼저 접근해야 나머지 페이지가 404가 아닌 정상 페이지로 열리게끔 하는 방식

    • 그런 아키텍처는 일반 사용자들이 검색엔진에서 프로젝트를 찾아 접근할 수 있도록 해야 하므로 계정 생성 또는 별도 인증 없이 바로 시작하는 케이스와는 안 맞음

    • 사용성 면에서는 아무리 잘 설계해도 불편함 초래할 수밖에 없음, 북마크를 이용하거나 친구에게 링크를 보낼 때도 계속 404만 겪는 불편함 예상

  • 내 작은 서버는 잘 굴러가고 있어서 최근 fail2ban 상태를 안 봤었음
    명령 실행 결과 비교:

    sshd-ddos:      0
postfix:       583
dovecot:     9690
postfix-sasl: 4227
nginx-botsearch: 1421
nginx-http-auth: 0
postfix-botnet:  5425
sshd:         202157

220,000개 넘는 IP가 차단된 상황을 발견해서 조금 충격받음

  • 우리가 추적한 'DotBot/1.2'라는 봇이 최근 2주 동안 22만 건 넘는 요청을 남김, 무작위로 웹서버의 파일명과 폴더명을 요청하는 패턴임, 호기심에 얼마나 파고드는지 한계가 궁금해서 일부러 차단 안 하고 지켜보고 있음

  • AI나 검색엔진을 위한 중앙화 인덱싱 구조도 이제는 푸시 또는 제출 방식으로 바뀌어야 하지 않을까 고민임, 내가 원할 때만 직접 공유(푸시)하는 구조라면 스크래핑 문제가 많이 줄어들 거라 생각함

  • 90년대에 내가 어렸을 때, ISP로부터 전화가 와서 내 컴퓨터가 봇넷에 물려 있어서 인터넷 접속을 중단시킨다는 통지를 받은 적이 있었음, 그런 시절로 다시 돌아가서 해당 행위를 허용하는 ISP의 ASN 전체를 차단하면 이런 문제도 끝낼 수 있지 않을까 생각함

    • 주거용 프록시는 ISP가 직접 제공하는 게 아니라, 전 세계 각지에서 사용자가 의도적으로나 모르고 악성 소프트웨어를 설치하면서 자기 컴퓨터를 프록시로 내어줘서 발생함, 얼마 전 HN에 이와 관련된 좋은 기사가 올라왔었음

    • 내 네트워크에서 특정 장치가 악성코드와 연관된 포트로 아웃바운드 접속을 시도할 때마다 경고를 띄우는 방화벽 규칙을 세팅함, 포트 리스트는 멀웨어 타깃이 계속 변해서 주기적으로 업데이트 필요함, 소소한 방법이지만 이런 것도 또 하나의 방어층임

답변달기