# 인터넷은 더 이상 안전한 피난처가 아니다 > Clean Markdown view of GeekNews topic #24420. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=24420](https://news.hada.io/topic?id=24420) - GeekNews Markdown: [https://news.hada.io/topic/24420.md](https://news.hada.io/topic/24420.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-11-17T14:33:28+09:00 - Updated: 2025-11-17T14:33:28+09:00 - Original source: [brainbaking.com](https://brainbaking.com/post/2025/10/the-internet-is-no-longer-a-safe-haven/) - Points: 9 - Comments: 1 ## Summary 최근 한 개인 개발자의 **자체 호스팅 서버가 AI 스크래핑 봇의 과도한 요청**으로 다운되며, 인터넷의 자율적 운영이 얼마나 취약한지 드러났습니다. **위조된 User-Agent**와 **분산된 IP 대역 공격**으로 기존 방어 체계가 무력화되었고, 결국 수동 차단에 의존해야 했습니다. 이런 사례는 **AI 데이터 수집 경쟁**이 개인 서버까지 침범하며, **분산 웹 생태계의 지속 가능성**을 위협하고 있음을 보여줍니다. “Get Hostin’ Or Die Tryin’”이라는 문장처럼, 여전히 자율 호스팅을 지키려는 이들의 고집이 묘하게 뭉클합니다. ## Topic Body - 개인 서버가 **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’** ”이라는 문구로 **자율 서버 운영 지속 의지** 강조 ## Comments ### Comment 46414 - Author: neo - Created: 2025-11-17T14:33:29+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=45944870) - 인터넷이 더 이상 **소프트웨어 취미 개발자들의 안전한 공간**이 아니게 된 느낌임 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](https://www.masswerk.at/wp-admin) - 2008년쯤 PageRank 6짜리 비즈니스 사이트를 운영했는데, 그때부터 **Script Kiddies**의 공격이 폭발적으로 늘었음 IP 대역을 스캔하고 취약점을 자동으로 찾는 툴이 퍼지던 시기였음 1995~2008년 사이의 웹, Web Rings나 Technorati, 팬사이트들이 있던 시절이 그리움 참고: [Script Kiddie 위키](https://en.wikipedia.org/wiki/Script_kiddie) - “항상 공격받았다”는 표현보다, 사실상 트래픽이 **‘수익화(monetised)’** 된 것이라고 보는 게 맞을지도 모름 - 예전에 **zipbomb**을 써서 봇을 막았는데 효과가 있었음 하지만 그 내용을 [HN에 올린 뒤](https://news.ycombinator.com/item?id=43826798), 새로운 봇들이 몰려와 $6짜리 서버가 감당을 못 했음 하루 10만 요청에 1~10MB 페이로드를 제공하는 건 불가능했음 이후엔 특정 봇만 대상으로 하고, **honeypot**을 만들어 IP를 수집해 403을 응답함 몇 달 지나니 트래픽이 정상 수준으로 돌아왔음 - 이런 **봇 차단 기술**은 시장성이 있을 것 같음 다만 타깃 고객이 누구일지는 모르겠음. 대부분의 자가 호스팅 유저는 돈이 많지 않음 - 내 **cgit 서버**도 1년째 스크래퍼가 계속 접근 중임 다만 분당 2~3회 요청이라 꽤 ‘예의 바른’ 봇임 웃긴 건, 내가 올린 코드는 전부 upstream에서 바로 클론할 수 있는데 굳이 이렇게 긁어감 로그를 보면 정말 비효율적인 자동화임 - Nginx의 **rate-limiting 기능**을 직접 설정하면 Fail2ban보다 간단히 해결 가능함 참고 블로그: [https://blog.nginx.org/blog/rate-limiting-nginx](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으로 공개](https://aws.amazon.com/blogs/aws/aws-ip-ranges-json/)하고 있음 다른 클라우드들도 이런 식으로 제공하길 바람