AI 스크레이퍼 공격으로 유지가 어려워지는 개방형 웹

 (lwn.net)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 대규모 언어 모델 등의 훈련 데이터를 수집하는 웹 스크레이핑 공격이 1년 넘게 증가하면서, 독립 웹사이트가 개방성을 유지하기 어려울 만큼 트래픽 부담이 커지고 있음
  • 공격자는 수백만 개의 일반·모바일 기기로 구성된 주거용 프록시를 이용해 IP마다 몇 차례만 요청하고 user-agent를 위장함으로써 기존 IP 차단을 무력화함
  • 악성코드, 취약한 미디어 스트리밍 기기, 무료 VPN, 앱 SDK가 프록시망을 구성하며, Google의 IPIDEA·NetNut 해체 뒤 공격량이 일시적으로 줄었다가 다시 증가한 전례가 있음
  • 사이트들은 Anubis의 작업 증명, CAPTCHA, 로그인·유료 장벽, 데이터 오염 도구로 대응하지만, LWN은 실제 독자와 검색 엔진·Internet Archive를 방해하지 않도록 사이트 최적화와 공격 중 비용 억제에 집중함
  • 스크레이퍼 방어와 사용자 검증 비용이 웹 전체로 전가되는 가운데 지속 가능한 해결책이 나오지 않으면, 독립 사이트들이 방어벽 뒤로 이동해 개방형 인터넷이 훼손될 수 있음

계속 커지는 스크레이퍼 공격

  • 2025년 초 다뤘던 대규모 언어 모델 및 관련 프로젝트의 훈련 데이터 수집 문제는 1년 넘게 지난 뒤에도 악화되고 있음
  • 정체불명의 행위자들이 웹사이트에 보내는 요청은 전례 없는 수준으로 늘었고, 과도한 트래픽 때문에 개방형 웹을 유지하기가 점점 어려워짐

수백만 IP를 동원하는 주거용 프록시

  • 공격은 몇 시간 동안 수백만 개의 고유 IP 주소에서 조율된 요청을 보내며, 각 주소는 사이트에 두세 번 이하로 접근하는 방식임
  • 공격자가 제어하는 user-agent 등의 정보는 허구이며, 각 요청을 웹 브라우저를 사용하는 평범한 사람의 접근처럼 위장함
  • 봇은 보통 이미지나 CSS를 가져오지 않아 사람과 구별할 단서가 있지만, 판별이 끝날 때쯤에는 해당 주소가 다시 사용되지 않으므로 사후 IP 차단은 효과가 없음
  • 트래픽은 중앙 명령·제어 노드가 지휘하는 가정용·모바일 네트워크에서 주로 발생함
    • 일반 기기에 설치된 소프트웨어가 제어 노드의 명령을 받아 웹페이지를 가져오고 데이터를 다시 전달함
    • 상당수는 기기 소유자의 인지나 동의 없이 작동하며, 이렇게 이용되는 시스템을 주거용 프록시라고 부름

범죄형 프록시망과 감염 기기

  • 한 유형은 악성코드로 장악한 시스템에서 스크레이퍼를 실행하는 범죄형 운영자임
  • Google은 연초 IPIDEA 봇 네트워크 해체에 나서며 운영 방식에 관한 정보를 공개함
    • IPIDEA 중단 시점과 LWN의 스크레이퍼 트래픽이 크게 줄어든 시점이 겹침
    • 몇 달간 비교적 평온했지만 이후 공격이 다시 증가함
  • 최근에는 미디어 스트리밍 기기가 악성 스크래핑 소프트웨어의 주요 운반체로 확인됨
    • 일부 기기는 공급 단계부터 감염됨
    • 다른 기기는 보안이 허술해 판매된 뒤 쉽게 장악됨

무료 VPN과 앱 SDK를 이용한 상업형 프록시망

  • 또 다른 유형은 어느 정도 합법적인 업체처럼 행동하며 “윤리적으로 확보한” IP 주소를 판매함
  • Bright Data는 웹사이트의 접근 통제와 트래픽 제한을 우회하는 역량을 광고하는 대표적인 업체임
    • “무료” VPN 사용자는 Bright Data가 자신의 기기를 통해 트래픽을 라우팅하도록 허용해야 함
    • 이 VPN을 사용하는 휴대전화와 기타 기기는 Bright Data의 주거용 프록시망 종단점이 되어 웹사이트 공격에 동원됨
  • 비슷한 업체들은 앱 개발자가 제품에 연결할 수 있는 라이브러리를 제공하고, 이용자의 네트워크 연결을 넘기는 대가로 개발자에게 돈을 지급하기도 함
    • 한 업체는 자사 SDK 광고를 LWN에 게재할 수 있는지 문의했지만 대화는 곧 끝남
    • 운영자들은 “GDPR 준수” 등을 내세워 합법적인 외관을 만들려는 곳부터 노골적으로 비윤리적인 곳까지 다양함
  • 이런 프록시 운영자는 수백만 기기가 연결된 네트워크의 자원에 접근하는 코드를 실행할 수 있으므로, 해당 권한이 웹 스크래핑에만 사용된다고 가정할 수 없음

모델 기업과 프록시망 사용자

  • 모델 개발을 핵심 사업으로 삼는 유명 기업도 자체적으로 웹을 스크래핑함
    • 해당 기업으로 쉽게 귀속되는 트래픽은 user-agent에 정체가 명확히 표시됨
    • 일반적으로 robots.txt 같은 통제 수단을 따름
    • 2003년에 작성된 글까지 최근 변경 여부를 확인하듯 사이트 전체를 반복해서 수집함
    • 다만 수백만 시스템에서 감당하기 어려운 트래픽을 보내지는 않으므로 가장 큰 문제는 아님
  • 누가 비용을 내고 주거용 프록시 공격을 실행하는지는 명확하지 않음
    • 최첨단 모델 기업들이 이 네트워크를 사용한다는 증거는 확인되지 않음
    • 이들 기업은 모델에 데이터를 공급하는 방식과 훈련 데이터 출처를 공개하지 않으며, 콘텐츠 제작자나 운영 문제를 우려하는 이들을 존중하는 모습도 보이지 않았음
  • 공개 모델 하나마다 외부에 드러나지 않은 모델이 다수 존재할 수 있음
    • 많은 기업이 AI 경쟁에서 앞서면 막대한 기업가치를 얻으리라는 기대 아래 자체 모델을 만들고 있을 수 있음
    • 여러 국가의 비공개 정부 기관도 자체 모델과 훈련 데이터를 확보하려 할 수 있음
    • 대규모 범죄 조직 역시 자체 모델을 원할 가능성이 있음
  • AI 도구가 무기로 인식되면서 군비 경쟁이 진행되고 있으며, 인터넷 전체가 그 과정에 휘말리고 있음

개방형 인터넷을 지키기 위한 방어책

  • 웹사이트 운영자들은 실제 사용자에게 미치는 영향을 최소화하면서 공격을 막기 위해 여러 방어 장치를 도입함
  • Anubis는 접근자에게 작업 증명(proof of work) 을 요구해 스크레이퍼를 차단하며 널리 사용되고 있음
  • 상용 서비스는 “사람임을 증명”하는 버튼을 표시하고, 다른 사이트들은 신호등이 포함된 칸 고르기나 퍼즐 조각 배치 등의 CAPTCHA를 요구함
  • 일부 사이트는 주요 기능을 로그인이나 유료 장벽 뒤로 옮겼고, iocaine 같은 도구로 스크레이퍼가 받는 데이터를 적극적으로 오염시킴
  • 방어 장치를 구축·유지하는 비용과 이를 통과해야 하는 사용자의 불편은 스크레이퍼와 비용 지불자가 전 세계에 부과한 무거운 부담임

LWN의 방어 방식과 제약

  • LWN은 최근 지금까지 가장 강력한 스크레이퍼 공격을 받았지만, 구축한 방어책 덕분에 실제 독자 대부분이 알아차리지 못할 정도로 트래픽을 견딤
  • 구체적인 방어 수단을 공개하면 공격자에게 대응 정보를 줄 수 있어 비공개로 유지하며, 방어 측에서도 군비 경쟁이 이어지고 있음
  • 실제 독자에게 미치는 영향을 가능한 한 줄이는 것을 우선함
    • Anubis는 사이트 접근을 지연시켜 독자를 불편하게 하므로 사용하지 않음
    • 스크레이퍼가 결국 Anubis를 우회할 것으로 보이며, 이미 그런 징후도 있음
    • 수백만 대의 타인 기기를 동원할 수 있다면 작업 증명은 큰 장애물이 되지 않음
  • 정상적인 검색 엔진과 Internet Archive 같은 조직의 접근도 막지 않으려 함
    • 지배적 검색 엔진에만 접근을 허용하는 명시적 허용 목록은 이미 서비스 품질에 문제가 있는 독점 사업자의 지위를 더 강화함
    • LWN은 현재까지 특정 검색 엔진을 위한 허용 목록 없이 정상적인 접근을 유지하는 데 성공함
  • 사이트 일부를 공격적으로 최적화하고, 공격 중에는 비용이 큰 작업을 최소화함
    • 익명 독자는 간혹 이런 조치의 영향을 받을 수 있지만 로그인 사용자는 영향을 받지 않음
    • 방어 조치가 활성화된 공격 상황에서 평상시보다 응답 시간이 더 빨라지는 경우도 있음
  • 현재 조치를 영구적인 해결책으로 보지 않으며, 효과가 사라질 때를 대비해 다음 대응을 검토해야 함

NetNut 해체와 일시적인 평온

  • Google은 7월 2일 미국 연방수사국(FBI) 등과 협력해 NetNut 주거용 프록시망을 해체했다고 발표함
  • 조치 이후 스크레이퍼 공격 수준이 어느 정도 낮아진 것으로 보이지만, 과거 경험상 이 평온은 오래가지 않을 가능성이 있음
  • Google Play Store는 NetNut에 감염된 앱을 검사할 예정임
  • 주요 앱스토어 사업자들은 주거용 프록시 기능을 가진 앱을 등록하기가 왜 쉬운지에 대해서는 답하지 않고 있음

방어벽 뒤로 밀려나는 인터넷

  • 인터넷 전체가 방어벽 뒤로 이동하고 창의성을 촉진했던 개방형 네트워크가 사라지기 전에 더 지속적인 해결책이 필요함
  • 공격을 유발하는 산업은 독립 웹사이트의 콘텐츠를 가져간 뒤 사이트가 파괴되는 상황을 개의치 않으며, 같은 태도가 지구와 경제에도 이어짐
  • 대규모 언어 모델과 관련 기술을 운영하는 기업에 최소한의 윤리 기준을 적용하기 전까지 이런 행동은 계속되고, 웹사이트 운영자는 스스로를 방어할 수밖에 없음

함께 보면 좋은 글 β

GN⁺   [-]
Lobste.rs 의견들

  • 최근 알게 된 온갖 노골적으로 수상한 사업 중에서도 주거용 프록시가 가장 충격적이었음
    https://spur.us/blog/smart-tv-apps-residential-proxy-sdks 에서 자세히 읽어봤는데, 이게 합법이라니 믿기 어렵다. 봇넷과 같은 범주로 분류하고 합법화된 봇넷이라고 불러야 함

    • 정말 비난받아 마땅한 사업이다. 검증되고 승인된 제휴사만 이용한다고 하지만, 주거용 프록시의 합법적인 용도는 단 하나도 떠오르지 않음. 실제로 그런 용도가 있나?
    • 주거용 프록시 규제에는 신중해야 한다. 이를 겨냥해 규제를 만들면 주거용 프록시 봇넷 외에도 훨씬 많은 대상이 영향을 받게 됨

  • 또 다른 피해자는 링크 검사기다. 사이트에 죽은 링크가 있는지 확인하기가 상당히 어려워짐
    시간이 있다면 콘텐츠가 여전히 살아 있는지 확인하는 데 Common Crawl 프로젝트를 활용해볼 것 같음

    • 채팅 앱이 발신자 측에서 생성하는 링크 미리보기도 피해를 본다. XMPP 클라이언트인 gajim에 이 기능을 기여해 기뻤지만, 실제로는 링크 미리보기 요청이 너무 자주 “사람인지 확인 중” 화면에 막혀서 우울할 정도임

  • 결국 GitHub 저장소의 이력 나열처럼 비용이 큰 작업은 모두 인증 장벽 뒤로 숨고, 나머지는 정적으로 만들어 CDN으로 제공하게 될 것임

    • 중앙화와 정부 감시 등이 우려되므로 CDN은 최후의 수단이어야 하며, 먼저 서버 자체에서 더 많은 성능을 끌어내야 한다고 봄
      애플리케이션 수준에서는 더 많은 콘텐츠를 정적으로 만들고, 데이터베이스 질의를 줄이며, 캐시를 활용하는 것이 분명 도움이 된다. 오랫동안 성능을 크게 걱정하지 않아도 되는 사치를 누렸지만 이제는 작은 사이트에서도 더 신경 써야 하며, 어디서나 Cloudflare의 “브라우저 확인 중”을 보는 것보다는 훨씬 낫다
      작은 VPS에서 Apache가 요청마다 별도 프로세스를 포크하는 전통적인 방식 때문에 문제가 생긴 적이 있다. LAMP 서버를 만지며 자라 Apache가 친숙하고 편하지만, 장비를 가장 효율적으로 활용하지는 못하며 결국 그 점이 더 중요하다. 실증 자료는 없지만 Caddy 같은 서버가 부하를 더 잘 견딜 것 같아 다음 서버 업그레이드 때 전환할 생각임
    • 내 Forgejo 서버도 같은 상황이었다. 지속적인 악성 트래픽을 Anubis로 관리하려 했지만, 해당 트래픽에 맞춰 설정을 조정하는 법을 완전히 이해하지 못했고 느린 인증 과제를 직접 마주하는 것도 마음에 들지 않았다
      fail2ban도 사용해봤지만 규모가 커지자 제대로 대응하지 못했다. 결국 블로그 글에 정리한 보안 규칙으로 Cloudflare가 처리하게 했다. Cloudflare에 장기간 의존하기는 꺼려졌지만, 글 아래쪽의 CPU 사용량 그래프를 보고 마음을 바꿈
    • 반면 Git 저장소와 크롤러의 궁합은 극도로 나쁘다. 동적으로 생성되는 링크가 조합 폭발을 일으켜 임시변통식 크롤러 함정을 만들기 때문에, 조금이라도 제대로 된 크롤러라면 경로에 긴 16진수 문자열이 들어간 URL을 적극적으로 피함
      Git 호스트에 엄청난 비용을 유발하는데도, 의외로 많은 호스트가 저장소 내부까지 깊게 크롤링하지 못하도록 robots.txt를 설정하지 않음

  • “사이트를 방어하기 위해 취한 조치를 설명해 달라는 요청이 있었지만, 명백한 이유로 자세히 논의하고 싶지는 않다. 이 수준에서도 군비 경쟁이 벌어진다”는 대목이 마음 아프다
    나도 이 싸움에서 꽤 성공했지만, 공유지의 비극 때문에 사용한 아주 단순한 대책을 공개하면 효과가 떨어진다. 정말 흥미로운 주제이고 독창적인 아이디어도 있어 블로그에 쓰고 싶지만 그럴 수 없어 안타까움

답변달기