▲

인터넷은 더 이상 안전한 피난처가 아니다

 (brainbaking.com)
4P by GN⁺ 8시간전 | ★ favorite | 댓글 1개
  • 개인 서버가 AI 스크래핑 봇의 과도한 요청으로 다운되는 사례 발생
  • 로그 분석 결과, Alibaba(US) Technology의 싱가포르 호스팅 IP 대역(47.79.*)에서 집중적인 접근 시도 확인
  • Mozilla/5.0 형태의 위조된 User-Agent로 인해 일반적인 봇 탐지 시스템이 무력화됨
  • Fail2ban과 Nginx의 자동 차단 시스템이 과부하되어, 수동으로 IP 대역 전체를 차단하는 조치 필요
  • 개인 서버 운영자들이 반복되는 공격으로 인해 자율 호스팅 환경이 위축되고, 중앙화된 플랫폼으로 밀려나는 현실

서버 다운 원인과 초기 대응

  • 며칠 전, 사이트를 호스팅하던 소형 서버가 스크래핑 봇 공격으로 일시 중단됨
    • 과거에도 유사한 공격이 있었으며, Anubis 같은 강력한 방어 도구 도입을 고려 중
    • 반복되는 공격으로 인해 개인 개발자의 창작 의욕과 취미적 즐거움이 감소
  • 서버 접속 지연 후 top 명령으로 확인한 결과, Gitea와 Fail2ban이 CPU를 거의 모두 점유
    • Gitea 프로세스를 종료해도 Fail2ban의 부하가 줄지 않았으며, Nginx 접근 로그가 폭주한 상태

로그 분석과 공격 패턴

  • 로그에는 /commit/ 경로를 대상으로 한 다수의 HTTP 502 요청이 기록됨
    • 요청 헤더에는 Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) 등 일반 브라우저로 위장된 User-Agent 사용
    • 대부분의 User-Agent 검사 도구가 이를 정상 트래픽으로 인식해 탐지 회피
  • 공격 IP는 단일 출처가 아닌 여러 주소에서 발생했지만, 공통적으로 47.79.* 대역 사용
    • ipinfo.io 조회 결과, 해당 대역은 Alibaba(US) Technology Co., Ltd. 소유
    • PhpBB 포럼 등에서도 동일한 IP 대역으로 인한 공격 사례 보고 존재

방어 조치와 한계

  • Fail2ban이 Nginx 로그를 실시간 분석해 차단 규칙을 적용했으나, 로그 폭증으로 처리 지연
    • /commit/ 접근 시도 IP를 즉시 차단하는 스크립트를 실행했지만 속도 한계 존재
    • 최종적으로 iptables 명령을 통해 47.79.0.0/16 전체 대역을 수동 차단
  • 이러한 대응은 임시방편에 불과하며, 새로운 IP 대역에서의 공격은 계속될 가능성 있음
    • Cloudflare 같은 외부 보호 서비스나 Anubis 같은 고급 방어 체계 도입을 검토 중
    • 그러나 추적 기능이 있는 미국 서버 경유를 원치 않아 도입을 망설이는 상황

개인 서버 운영의 어려움

  • Gitea 인스턴스를 Codeberg로 이전하는 방안을 고려 중
    • 개인 서버 운영자들이 반복되는 공격으로 인해 자체 호스팅을 포기하고 중앙화된 플랫폼으로 이동하는 경향
    • 이러한 흐름이 인터넷의 분산성과 자율성 약화로 이어짐
  • 다른 블로거들도 유사한 공격 피해를 보고하고 있으며, 소규모 웹 운영자 전반의 문제로 확산

기타 관찰된 이상 트래픽

  • bioware.com, mcdonalds.com, microsoft.com 등 대기업 도메인을 참조하는 위조된 Referer 헤더 발견
    • 실제로 해당 사이트들이 링크를 제공하지 않았으며, 목적 불명의 트래픽 증가 현상
  • 공격이 반복되더라도 자체 호스팅을 포기하지 않겠다는 의지 표명
    • 글의 마지막에서 “Get Hostin’ Or Die Tryin’ ”이라는 문구로 자율 서버 운영 지속 의지 강조
▲
GN⁺ 8시간전  [-]
Hacker News 의견

  • 인터넷이 더 이상 소프트웨어 취미 개발자들의 안전한 공간이 아니게 된 느낌임
    2005년쯤부터 직접 서버를 운영해왔는데, 서버가 온라인이 되는 순간부터 항상 공격을 받았음
    특히 DNS 이름을 붙이거나 TLS 인증서를 사용하면, 인증서 투명성 로그에 노출되어 공격이 더 심해지는 듯함
    웹사이트를 공개하면 악성 트래픽이 폭주하고, 특정 조직을 화나게 하면 누군가를 고용해 DDoS를 시도하는 것 같음
    크롤러, 봇넷, 자동화된 공격, 화난 사람들까지 매년 겪는 일임
    여러 호스팅 업체를 써봤지만 결과는 비슷했음

    • 예전엔 내가 만든 허술한 PHP 방명록이 며칠 만에 XSS 스팸 사이트로 변했음
      WordPress를 업데이트 안 했더니 몇 시간 만에 SEO 스팸으로 감염됐고, Redis를 실수로 외부에 노출했더니 봇넷 RAT이 설치됐음
      하지만 이런 일들이 인터넷이 ‘위험하다’는 뜻은 아니라고 생각함
      오히려 내가 배워야 할 점을 알려준 경험이었음
      이후엔 인증서 로그에 안 뜨게 star-cert를 쓰고, 기본 인증을 추가하고, 백업을 유지하며 신중하게 운영함
      진짜 위험한 건 기술을 모르는 사람이 아무 exe나 설치하고, Facebook이나 TikTok에 모든 정보를 넘기는 행위라고 생각함
    • 나도 개인 도메인을 운영 중인데, 나 외엔 아무도 방문하지 않음에도 불구하고 봇 공격이 끊이지 않음
      WordPress 취약점을 노리는 요청이 대부분인데, WordPress를 써본 적도 없음
      처음 로그를 봤을 땐 충격이었지만, 이제는 그냥 일상적인 일로 받아들이고 있음
    • 공격자들을 놀리기 위해 ‘HTTP Adventure’라는 걸 만들어서 유명한 관리자 주소에 설치해둠
      예: https://www.masswerk.at/wp-admin
    • 2008년쯤 PageRank 6짜리 비즈니스 사이트를 운영했는데, 그때부터 Script Kiddies의 공격이 폭발적으로 늘었음
      IP 대역을 스캔하고 취약점을 자동으로 찾는 툴이 퍼지던 시기였음
      1995~2008년 사이의 웹, Web Rings나 Technorati, 팬사이트들이 있던 시절이 그리움
      참고: Script Kiddie 위키
    • “항상 공격받았다”는 표현보다, 사실상 트래픽이 ‘수익화(monetised)’ 된 것이라고 보는 게 맞을지도 모름

  • 예전에 zipbomb을 써서 봇을 막았는데 효과가 있었음
    하지만 그 내용을 HN에 올린 뒤, 새로운 봇들이 몰려와 $6짜리 서버가 감당을 못 했음
    하루 10만 요청에 1~10MB 페이로드를 제공하는 건 불가능했음
    이후엔 특정 봇만 대상으로 하고, honeypot을 만들어 IP를 수집해 403을 응답함
    몇 달 지나니 트래픽이 정상 수준으로 돌아왔음

    • 이런 봇 차단 기술은 시장성이 있을 것 같음
      다만 타깃 고객이 누구일지는 모르겠음. 대부분의 자가 호스팅 유저는 돈이 많지 않음

  • 내 cgit 서버도 1년째 스크래퍼가 계속 접근 중임
    다만 분당 2~3회 요청이라 꽤 ‘예의 바른’ 봇임
    웃긴 건, 내가 올린 코드는 전부 upstream에서 바로 클론할 수 있는데 굳이 이렇게 긁어감
    로그를 보면 정말 비효율적인 자동화임

  • Nginx의 rate-limiting 기능을 직접 설정하면 Fail2ban보다 간단히 해결 가능함
    참고 블로그: https://blog.nginx.org/blog/rate-limiting-nginx

  • 블로그 같은 공개 서비스엔 적용하기 어렵지만, 개인용 자가 호스팅이라면 mTLS 인증을 reverse proxy에 설정하는 걸 추천함
    인증서가 없는 요청은 바로 차단되고, 내 기기만 접근 가능함
    한 번 설정하면 이후엔 신경 쓸 일이 거의 없음

    • 하지만 Wireguard가 더 낫다고 생각함
      설정이 간단하고 Android, iOS에서도 잘 작동함
      지금은 모든 자가 호스팅 서비스를 Wireguard VPN 안에서만 접근하도록 구성했고, 방화벽은 Wireguard 포트만 열어둠
    • 다만 블로그처럼 다른 사람도 접근해야 하는 서비스엔 mTLS는 비현실적임

  • Anubis는 봇과의 ‘고양이와 쥐’ 게임을 잘 하고 있음
    하지만 Cloudflare처럼 대규모 트래픽 데이터를 가진 곳만이 IP 평판 기반 차단을 잘 수행함
    소규모 운영자는 IP 범위를 통째로 막을 수밖에 없는데, 이는 비효율적임
    Crowdsec처럼 평판 데이터를 공유해 악성 IP를 차단하고, JS 없는 간단한 챌린지를 제공하는 솔루션이 필요함
    이런 접근이 가능하다면 취미 개발자들도 다시 서비스를 운영하기 쉬워질 것 같음

  • 내 Gitea 인스턴스도 최근 분산된 IP와 ASN을 통한 스크래핑을 당했음
    자금력 있는 AI 기업들이라면 Anubis로도 막기 어려울 듯
    그래서 ‘스크래퍼 독(poisoning) ’을 고려 중임 — 코드 대신 쓰레기 데이터를 제공하는 방식임

    • 요즘은 ‘윤리적으로 조달된(residential) ’ IP라고 주장하는 프록시 서비스까지 등장함
      이런 서비스가 스크래핑을 더 어렵게 만듦

  • 인기 있는 건 결국 대중의 손에 넘어가 망가지는 순환을 겪음
    그래서 새로운 영역으로 계속 이동하는 게 유일한 해법처럼 느껴짐

  • Cloudflare로 DNS를 옮긴 뒤 이상한 SYN 패킷이 계속 들어옴
    443이나 22 포트로 1초마다 요청이 오는데, SYN-ACK 이후 응답이 없음
    대부분 브라질 등지의 VPS 게임 서버 호스팅 업체에서 오는 듯함
    그래서 SYN 패킷을 캡처해 RDAP로 조회 후, 해당 조직의 서브넷을 통째로 차단함
    Google만 화이트리스트로 유지 중임
    Digital Ocean은 악성 트래픽의 주요 원천 중 하나로 보임

    • 이건 SYNACK 반사 공격의 일종임
      네트워크 스택이 재시도하면서 피해자에게 트래픽이 증폭되어 전달됨
    • 아마 Minecraft 서버 DDoS 같은 게임 관련 공격일 가능성이 큼
      src IP를 위조하는 경우가 많으니, rp_filter를 strict로 설정해보길 권함 
      net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
    • 하지만 ISP가 사용자의 행위를 검열하는 건 위험함
      전력회사가 빨간 전구 사용을 금지하지 않듯, 서비스 제공자가 트래픽을 통제하는 건 바람직하지 않음

  • 이 글에 공감한 이유는 인터넷이 안전해서가 아니라, 이런 현실을 기록했다는 점 때문임
    나도 Alibaba /16, AWS 전체 대역을 차단하고 있음

    • IP 범위를 직접 차단하기보다 ASN 단위로 차단하는 게 효율적임
      매일 크론으로 RouteViews 데이터를 받아 iptables에 적용하는 스크립트를 사용함
      예시 코드: 
      iptables -A BAD_AS -s $ROUTE -j DROP;
    • 참고로 AWS는 2014년부터 IP 범위를 JSON으로 공개하고 있음
      다른 클라우드들도 이런 식으로 제공하길 바람
답변달기