▲

누가 Cloudflare가 Canonical을 협박했는지 설명해줄 수 있나?

 (flyingpenguin.com)
1P by GN⁺ 19시간전 | ★ favorite | 댓글 1개
  • Canonical 공개 웹 서비스는 2026년 4월 30일 16:33 UTC부터 약 20시간 중단됐고, Ubuntu 저장소 엔드포인트도 뒤늦게 장애에 들어감
  • 공격 책임을 주장한 친이란 성향 그룹은 유료 DDoS 서비스 Beamed를 사용했다고 밝혔고, Beamed는 Cloudflare 우회와 주거용 IP 회전을 광고함
  • Beamed 도메인과 관련 등록·라우팅 인프라는 Cloudflare AS13335, Immaterialism, AS39287, Materialism s.r.l. 기록으로 이어짐
  • AS39287 재할당과 Canonical의 archive.ubuntu.com·security.ubuntu.com apex 인증서 갱신이 2026년 2월 27일 같은 24시간 안에 발생함
  • Canonical은 공격 중 security.ubuntu.com과 archive.ubuntu.com만 Cloudflare로 옮겼고, 공개 기록상 몸값 대신 유료 구독이 이동한 구조가 됨

Canonical 장애와 Cloudflare 전환

  • 2026년 4월 30일 16:33:37 UTC Canonical의 모니터링 시스템은 blog.ubuntu.com을 Service Down으로 표시했고, 약 10분 안에 ubuntu.com, 보안 권고 API, 개발자 포털, 기업 사이트, 교육 플랫폼 등 공개 웹 서비스가 함께 중단됨
  • 장애는 약 20시간 이어졌고, 2026년 5월 1일 12:44 UTC에 Service Restored로 기록됨
  • 공격 책임을 주장한 그룹은 자신들을 Islamic Cyber Resistance in Iraq 또는 313 Team이라고 소개한 친이란 성향 그룹이며, 유료 서비스를 사용했다고 밝힘
  • 공격 도구로 지목된 Beamed 는 여러 TLD에서 판매되는 상업용 서비스 거부 제품으로, beamed.su는 마케팅·블로그 사이트, beamed.st는 고객 로그인 포털로 쓰임
  • Beamed의 2026년 4월 블로그 글은 “Cloudflare 우회”를 광고하며, 주거용 IP 회전과 수동 “endpoint hunting”으로 원 서버를 찾는 방식을 포함한 세 가지 기법을 내세움
  • 공격 일주일 뒤에도 beamed.su와 beamed.st는 온라인 상태였고, 둘 다 Cloudflare AS13335 주소로 해석됨
  • Canonical의 두 저장소 엔드포인트인 security.ubuntu.com과 archive.ubuntu.com도 이후 Cloudflare AS13335 주소를 사용하게 됨

Beamed와 등록·라우팅 인프라

  • Beamed의 소비자용 도메인은 Immaterialism Limited라는 등록기관을 통해 등록됐고, 이 등록기관은 고정 요금과 JSON API 기반 도메인 등록을 판매함
  • Immateriali.sm은 Cloudflare 네임서버인 tani.ns.cloudflare.com과 trey.ns.cloudflare.com을 통해 프록시됨
  • Immaterialism Limited는 영국 Companies House에 회사번호 15738452로 등록됐고, 2024년 5월 24일 설립됨
  • 설립 당시 이사는 코스타리카의 Nicole Priscila Fernandez Chaves였고, 런던 Great Portland Street의 대량 우편함 주소를 사용함
  • 2025년 4월 11일 Fernandez Chaves는 이사직에서 물러났지만 75% 이상 경제적 이해관계는 유지했고, 같은 주소에서 영국 거주자인 Naomi Susan Colvin이 후임 이사로 임명됨

2026년 2월 27일의 AS39287 재할당

  • 2026년 2월 26일 Immaterialism Limited는 Companies House에 두 가지 변경을 같은 날 제출함
    • 등록 사무소를 85 Great Portland Street에서 167-169 Great Portland Street로 변경함
    • Fernandez Chaves의 person with significant control 세부 정보를 변경함
  • 다음 날인 2026년 2월 27일, Beamed와 관련 서비스의 IP 공간을 알리는 라우팅 인프라가 관할권을 옮김
  • Materialism의 주소 공간을 알리는 자율 시스템은 AS39287이며, RIPE가 2006년 1월 24일 이 AS 번호를 할당함
  • AS39287의 라우팅 정체성은 계속 유지됐지만, 등록 운영자와 국가 기록은 두 차례 바뀜

  • Privactually Ltd와 FLATTR-AS 시기

    • 2017년경부터 2020년경까지 AS39287은 키프로스 회사 Privactually Ltd가 보유했고, FLATTR-AS라는 이름으로 운영됨
    • Flattr는 The Pirate Bay 공동 창업자 중 한 명인 Peter Sunde Kolmosoppi의 마이크로페이먼트 프로젝트로 연결됨
    • 해당 등록 아래 프리픽스의 abuse 연락처는 abuse@shelter.st였음

  • ab stract ltd 시기

    • 2020년부터 2026년까지 같은 AS 번호는 헬싱키 Urho Kekkosen katu 4-6E 소재 핀란드 회사 ab stract ltd로 재할당됨
    • RIPE 기록의 maintainer 객체는 BKP-MNT였고, 기록상 인물은 The Pirate Bay의 또 다른 창업자인 Peter Kolmisoppi였음
    • 운영자 도메인 abstract.fi의 권한 네임서버는 njalla.fo, njalla.no, njalla.in의 세 Njalla 네임서버였음
    • Njalla는 Peter Sunde가 만든 privacy-as-a-service 도메인 프록시이며, 세인트키츠 네비스의 1337 Services LLC를 통해 운영됨

  • Materialism s.r.l. 재할당

    • 2026년 2월 27일 12:11:48 UTC RIPE는 세 번째 재할당을 기록했고, AS39287은 루마니아 부쿠레슈티 Bulevardul Metalurgiei 소재 Materialism s.r.l. 의 소유가 됨
    • 재할당에는 45.158.116.0/22, 2001:67c:2354::/48, 2a02:6f8::/32가 포함됐으며, 마지막 IPv6 프리픽스는 이전 체제에서 2008년 8월에 처음 할당됨
    • 세 전환 기간 내내 피어링 설정은 유지됐고, AS39287은 AS42708(Telia), AS37560(GTT), AS12552(GlobalConnect), AS34244(Voxility), AS54990와 동일 구성으로 import/export를 계속함
    • 같은 경로가 같은 upstream 네트워크로 나갔고, 공개 기록에서 바뀐 것은 보이는 운영자 이름뿐임
    • IANA의 공인 도메인 등록기관 목록에는 Immateriali.sm의 고객 기반에 Njalla 뒤의 거래 법인인 1337 Services LLC가 포함됨

같은 날 발생한 Canonical 인증서 회전

  • Canonical 저장소 엔드포인트의 인증서 투명성 기록에는 라우팅 재할당이 일어난 같은 24시간 창 안에 여러 항목이 나타남
  • 2026년 2월 27일 06:14:03 UTC Let’s Encrypt가 archive.ubuntu.com의 새 apex 인증서를 발급함
  • 같은 날 19:13:35 UTC Let’s Encrypt가 security.ubuntu.com의 새 apex 인증서를 발급함
  • security.ubuntu.com의 2026년 인증서 투명성 기록에서 이 항목 이전에는 지역 미러 인증서만 있었고, 보이는 로그에서 더 이른 apex 인증서는 나타나지 않음
  • 같은 날 22:14:03 UTC clouds.archive.ubuntu.com의 새 인증서가 발급됨
  • 이후 9일 동안 같은 패턴이 azure.archive.ubuntu.com, wildcard-gce.archive.ubuntu.com, wildcard-ec2.archive.ubuntu.com에서 반복됨
  • 각각의 새 인증서는 지역 미러가 아니라 apex 호스트명에 발급됨
  • apex 호스트명의 유효한 원본 인증서는 해당 호스트명을 콘텐츠 전송 네트워크 뒤에 두기 위한 전제 조건으로 다뤄짐
  • 2026년 2월 27일에 발생한 라우팅 재할당과 Canonical 인증서 회전의 동시성은 공개 기록만으로 설명되지 않음

공격 타임라인

  • 타임라인은 Canonical의 status.canonical.com 페이지에 있던 분 단위 장애 로그를 기반으로 하며, 4월 30일 약 22:52 UTC에 Ubuntu Discourse thread 81470에 스냅샷으로 남은 기록임

  • 초기 10분: 공개 웹 전반 장애

    • 16:33:37: blog.ubuntu.com이 처음 Down으로 표시되고 Incident Start Time으로 기록됨
    • 16:34:10: canonical.com Down
    • 16:34:45: academy.canonical.com Down
    • 16:35:15: developer.ubuntu.com Down
    • 16:35:22: maas.io Down
    • 16:36:09: jaas.ai Down, Ubuntu Security API(CVEs) Down
    • 16:37:13: Ubuntu Security API(Notices) Down
    • 16:41:57: assets.ubuntu.com Down
    • 16:43:25: ubuntu.com Down
    • 보안 권고 피드는 시작 후 3분 안에 내려갔고, 마케팅 apex는 10분 안에 내려감
    • 이 시점에 아직 공격받지 않은 호스트는 security.ubuntu.com과 archive.ubuntu.com이었고, 두 엔드포인트는 모든 Ubuntu 설치에서 apt update 실패를 유발할 수 있는 저장소 엔드포인트임

  • 3시간 뒤 저장소 엔드포인트 공격

    • 19:34:38: security.ubuntu.com이 처음 Down으로 표시됨
    • 19:40:01: archive.ubuntu.com Down
    • 저장소 엔드포인트는 공격 시작 약 3시간 뒤 장애에 들어감
    • 19:40 UTC부터 다음 70분 동안 두 저장소 엔드포인트는 상태판에서 Down과 Operational 사이를 반복함
    • 상태 로그에는 해당 기간 동안 security.ubuntu.com의 Down/Operational 전환이 5회, archive.ubuntu.com의 전환이 4회 기록됨
    • 이 패턴은 원본에서 속도 제한, 지역 필터, 트래픽 스크러빙 같은 완화를 시도했지만, 발표된 3.5 Tbps 규모의 지속 부하 아래 실패한 양상과 맞물림

  • 20:50 UTC 이후 안정화

    • 20:50:29: archive.ubuntu.com Operational
    • 20:51:13: security.ubuntu.com Operational
    • 이 44초 간격 이후, 22:52 UTC까지 이어지는 캡처 스냅샷에서 두 호스트는 다시 Down으로 나타나지 않음
    • 플래핑은 멈췄고, 두 엔드포인트는 공격 시작 후 4시간 17분 시점에 1분 미만 간격으로 함께 안정화됨
    • security.ubuntu.com과 archive.ubuntu.com은 작성 시점에 104.20.28.246과 172.66.152.176으로 해석되며, 이 주소들은 Cloudflare가 AS13335에서 운영하는 주소임
    • 다른 영향 호스트인 ubuntu.com, canonical.com, launchpad.net, snapcraft.io, login.ubuntu.com은 여전히 Canonical의 AS41231 공간인 185.125.189.x와 185.125.190.x로 해석됨
    • ubuntu.com의 권한 네임서버는 여전히 ns1.canonical.com, ns2.canonical.com, ns3.canonical.com임

선택적 Cloudflare 전환

  • Canonical은 공격자가 저장소 거부를 위해 겨냥한 security.ubuntu.com과 archive.ubuntu.com 두 A 레코드만 Cloudflare로 넘김
  • 나머지 서비스는 Canonical의 자체 인프라에 남았고, 기존 완화책 아래 공격을 견딤
  • 저장소가 아닌 호스트들은 스냅샷 끝까지 계속 플래핑했고, 이후 upstream 필터링과 공격 완화 또는 중단의 조합으로 복구됨
  • Canonical의 첫 공개 인정은 5월 1일 07:13 UTC에 올라왔고, 이는 저장소 엔드포인트가 Cloudflare 뒤에서 안정화된 지 10시간 뒤였음
  • 모든 구성요소의 완전 복구는 5월 1일 12:44 UTC에 확인됐고, 공격 시작 약 20시간 뒤였음

“협박” 여부를 둘러싼 구조

  • 공개적으로 확인되는 경로에서 몸값 지급은 이동하지 않음
  • 해당 규모의 암호화폐 흐름도 공개 기록에 나타나지 않음
  • 요구서도 공개되지 않았고, 협상이 있었다면 비공개로 진행됐을 가능성이 큼
  • 공개 기록상 이동한 것은 유료 구독임
  • Canonical의 가장 가치 높은 두 엔드포인트, 즉 자동 보안 업데이트의 전 세계 실패를 만들 수 있는 저장소 엔드포인트가 Cloudflare와의 서비스 관계로 전환됨
  • 동시에 Cloudflare의 다른 현재 고객에는 Canonical을 공격하던 booter 운영체가 포함됨
  • Beamed가 계속 고용 가능한 상태로 남아 있고 Canonical 인프라의 장애 시간이 마감시한처럼 작동하면서, 별도의 공개 요구 없이 거래가 성립한 구조로 해석됨
  • 보호자는 양쪽에서 수익을 거두면서도, 각 순간에는 콘텐츠 중립적이고 서비스 약관의 문언 안에 머무르는 형태가 됨

경마 통신망 독점과의 비교

  • 1930년대 Moses Annenberg의 General News Bureau는 미국 전역의 bookmaker에게 경마장 결과를 신속하게 판매함
  • 구독한 bookmaker는 살아남았고, 구독하지 않은 bookmaker는 구독한 경쟁자 때문에 배당률 설정 능력을 잃었다는 비교가 붙음
  • Annenberg의 수익은 경마 결과 검증에 대한 독점에 의존했고, 이 독점은 비공식 bookmaker가 운영을 위해 그의 wire에 의존하게 만듦
  • 연방정부는 1939년 세금 기소 로 이 독점을 깼고, 후속 wire service들은 1940년대까지 단속됨
  • 1942년 Mayor LaGuardia 관련 보도 에는 뉴욕, 뉴저지, Westchester, Nassau County의 경마 도박업자와 poolroom bookmaker를 위한 “연 100만 달러 wire service” 단속으로 9명이 체포됐다는 내용이 담김
  • 오늘날의 DDoS 보호 시장은 booter 시장과의 관계에서 비슷한 위치에 놓인다는 비판으로 이어짐
  • Cloudflare의 수익은 공개 인터넷에서 서비스가 도달 가능한지 검증하는 위치에 의존하고, 같은 회사가 booter의 호스팅 제공자이기도 할 때 위협과 보호 역할이 하나의 수익 흐름으로 합쳐짐

공개 기록에 남은 흔적

  • 이 사건의 흔적은 여러 레지스트리와 기업 공시에 나뉘어 남아 있음
  • Companies House에는 기업 서류가 있고, RIPE 데이터베이스에는 라우팅 재할당이 있으며, 인증서 투명성 로그에는 apex 인증서 회전 날짜가 있고, Canonical의 상태 페이지에는 레코드가 바뀐 시각이 남음
  • 2026년 2월 27일에는 세 가지 준비가 같은 달력 창 안에서 완료됨
    • Materialism s.r.l. 가 AS39287과 그에 딸린 오래된 IPv6 프리픽스 소유권을 가져감
    • Immaterialism Limited가 Companies House 서류를 제출함
    • Canonical 쪽에서는 나중에 콘텐츠 전송 네트워크 뒤로 이동될 두 apex 호스트명이 원본 인증서를 갱신함
  • 공격 시작부터 Canonical 저장소 호스트명에 Cloudflare 주소가 나타날 때까지의 4시간 간격은 구매 결정이 이동한 구간으로 해석됨
  • 2026년 4월 30일 20:50:29 UTC에 새 고객 관계가 공개적으로 보이게 됨

함께 보면 좋은 글 β

▲
GN⁺ 19시간전  [-]
Hacker News 의견들

  • 내가 이해하기로 Cloudflare에서 공격 용량을 빌린다는 표현은 부정확함
    그 집단이 Cloudflare 뒤에 사이트를 호스팅한 것은 맞지만, Cloudflare 인프라가 공격에 쓰였다고 주장한 경우는 못 봤음
    글 전체가 공격자가 운영하는 안내 사이트를 호스팅하는 것과 공격 자체를 호스팅하는 것을 섞어 말하는 듯함

    • 예전에는 문제 되는 DDoS 운영자가 많지 않았는데, 서로를 DDoS로 오프라인 상태로 만들어버렸기 때문임
      웹사이트든 제어 인프라든 전부 공격 대상이었음
      DDoS 방어는 Akamai 같은 회사가 제공했고, 가격은 문의해야 했으며, 대기업만 가능하고 익명 가입은 절대 안 됐음
      Cloudflare는 DDoS-for-hire 서비스까지 포함해 누구에게나 무료 DDoS 방어를 제공하면서 업계를 바꿨고, 서로를 오프라인으로 몰아내지 못하게 되자 DDoS 산업이 본격적으로 커질 수 있었음
    • 이 특정 사건은 모르지만 HTTP 트래픽 관리를 많이 하다 보니, 최근 로그에서 Cloudflare IP가 탐색이나 성가신 요청으로 더 자주 보임
      프록시된 트래픽이라서 그런 것도 아닌 듯하고, 적어도 CF-Connecting-Ip 헤더는 없음
      이 공격에 쓰였는지는 모르겠지만, 일부 공격에는 쓰임
      다만 Cloudflare는 여전히 거의 모든 다른 인프라 제공자보다 훨씬 덜 성가신 편임
    • 나도 이 부분이 헷갈렸고, 작성자가 다른 요소에서는 꽤 철저하고 정확했던 걸 보면 의도적으로 얼버무린 것처럼 보임
    • 맞음, 이 둘은 매우 다른 일임
      논리도 잘 성립하는지 모르겠음
      AWS에 호스팅된 명령·제어 서버도 많고 AWS 피해자도 많은데, 그렇다고 AWS가 책임지거나 협박한다고 보긴 어렵고, 답은 대체로 아니라고 봄

  • 누구나 Cloudflare 호스팅 서비스를 쓰면 안 된다고 생각하는 사이트 몇 개쯤은 고를 수 있음
    문제는 사람마다 그 목록이 다르다는 것임
    Cloudflare는 합법적 명령을 받기 전까지는 무엇이든 호스팅해야 함
    어떤 모호한 기준으로 사이트 내용이 “적절한지” 판단하기 시작하면 사람들이 정당하게 크게 화낼 것이 확실함
    Cloudflare에서 공격 용량을 빌린다는 주장에는 근거가 있어야 하고, 내가 아는 한 공격자들은 실제 공격에 Cloudflare 인프라를 쓰고 있지 않음
    이 글에서의 전반적 분위기와 Google 관련 글에서의 분위기가 너무 달라서 꽤 당황스러움

    • 인터넷의 많은 부분을 중간자 관찰자처럼 가로지르려는 전 세계적 존재에 대해 기본적으로 높은 의심, 거의 경멸에 가까운 태도를 보는 건 고무적임
      Cloudflare가 악의적 행위자인지는 확신 못 하지만, 모두가 그런 것처럼 행동해야 한다고 봄
    • 대부분의 회사 약관에는 회사 자체를 손상시키거나 공격하지 말라는 조항이 있음
      광고된 서비스가 Cloudflare를 명시적으로 공격한다면, 합리적인 약관이라면 당연히 위반일 것 같음
      실제 Cloudflare 약관에도 그렇게 나와 있음
      https://www.cloudflare.com/en-ca/website-terms/
      “7. PROHIBITED USES”에는 Cloudflare 서버나 API, 연결된 네트워크를 손상·비활성화·과부하·방해·저해할 수 있는 방식으로 웹사이트나 온라인 서비스를 사용할 수 없고, 바이러스·웜·트로이목마 등 파괴적 항목을 전송할 수 없으며, 해킹이나 암호 채굴 등으로 무단 접근을 시도할 수 없다고 되어 있음
      또한 Cloudflare는 불법·유해하거나 약관을 위반한다고 단독 재량으로 판단한 콘텐츠를 Distributed Web Gateway에서 차단할 권리를 보유한다고 되어 있고, 여기에는 악성코드 배포, 피싱 조장, 기타 기술적 남용도 포함됨
    • Cloudflare가 이 일을 어떻게 막을 수 있었는지 모르겠음
      공격자의 안내 사이트를 내려도 GitHub Pages나 수많은 무료 정적 사이트 호스팅으로 옮기면 됨
      내가 보기엔 Cloudflare가 실제 공격 자체를 가능하게 했다는 증거가 전혀 없음
    • Cloudflare는 이미 골라서 처리하고 있음
      완전히 바깥에 있기로 결정한 게 아님
      개입하지 않는다는 주장은 묵시적 승인으로 읽어야 함
      충분히 마음에 들지 않는 사용자는 실제로 내보낸다는 걸 알고 있기 때문임
    • 지구상의 대부분 사람은 각자의 목록 중 실제로 Cloudflare를 쓰면 안 되는 사이트의 공통 부분에 쉽게 동의할 수 있을 것임

  • 이런 글들은 Cloudflare가 보안 신고나 법적 명령에 반응하지 않는다는 이상한 믿음을 깔고 있는 듯함
    내 경험상 Cloudflare는 업계 전반과 비교해 적절하고 비교적 빠르게 대응함
    더 선제적으로 움직이거나 가입 절차에 더 많은 마찰을 넣을 수는 있겠지만, 인터넷 경찰 노릇을 하지 않겠다는 이유는 납득됨
    인터넷에 콘텐츠를 호스팅하려고 신용카드, 전화번호, 신분증 사본까지 요구받아야 한다고는 생각하지 않음

    • 인터넷이 오래 작동한 이유는 각 작은 섬의 책임자들이 대체로 다른 섬 전체의 이익에 맞게 행동했기 때문임
      그러지 않으면 다른 섬들이 그쪽 연결을 끊었음
      법 집행은 최후의 수단이었는데, 법원은 인터넷 속도로 움직이지 않고, 인터넷이 국경을 넘는 성격이라 누구도 위에서 내려오는 정부 규제를 원하지 않았기 때문임
      Cloudflare는 벤처 자본을 써서 비싼 것들을 무료로 제공하고 시장 점유율을 샀음
      모든 식료품점을 자기 섬으로 옮기게 만들면, 다른 이들이 배척할 걱정 없이 범죄 활동 소굴을 운영할 수 있음
      봇넷, 악성코드, 온라인 사기와 싸우는 사람에게 물어보면 됨
      Cloudflare 막다른 길에 도달하면 그냥 포기해야 함
      감염된 컴퓨터가 7,000대뿐인 사건을 법 집행기관이 맡을 리 없고, Cloudflare도 직접 조사해서 조치하지 않음
    • 인터넷에 콘텐츠를 호스팅하는 데 Cloudflare와 이야기해야 할 필요 자체가 없어야 한다고 봄
      나는 실제로 그렇게 하지 않음
    • Cloudflare와 AWS는 내가 보낸 남용 신고에 침해 URL이나 “특정 리소스”가 없다는 이유로 조사조차 하지 않았음
      내부 조사를 시작하거나 남용 고객에게 연락할 수 있을 정도의 증거는 제공했지만, 그렇게 하지 않았음
      stresser라면 바깥에서 보이는 건 로그인 패널뿐일 것임
      이런 사이트들이 자기들이 뭘 하는지 공개적으로 광고하는 것도 아님
    • 그건 이상한 믿음이 아님
      Cloudflare는 스스로를 인프라로 포지셔닝함
      즉 자신들이 운반하는 콘텐츠에 책임이 없다고 본다는 뜻임
      일반적인 상황에서 인터넷의 나쁜 시스템으로부터 내 시스템을 보호하려면 IP 계층에서 차단할 수 있음
      하지만 Cloudflare는 IP 계층에서 좋은 시스템과 나쁜 시스템, 그 사이 모든 것을 프록시함
      보통은 범죄 조직이 운영하는 사이트를 IP 수준에서 막거나, 콘텐츠를 호스팅하는 조직의 abuse@에 연락해 차단·신고할 수 있음
      Cloudflare는 둘 다 못 하게 만듦
      그리고 Cloudflare에 남용 신고를 보내면, 내 연락처 정보를 내가 신고한 당사자에게 그대로 전달하지 않으리라는 보장도 없음
      몇 년간 더 책임감 있게 보이도록 입장을 바꿔왔지만 핵심은 그대로임
      Cloudflare 뒤에 숨은 시스템에 abuse@ 신고를 보내고 싶어도, 그들이 누구에게 전달하는지 모르는 상태에서 그냥 전달하지 않을 거라고 확신할 수 없음

  • 지난주 관련 글:
    “Why is Cloudflare protecting the DDoS'er (beamed.st) attacking Ubuntu servers?”
    https://news.ycombinator.com/item?id=48025001

  • 현대 인터넷에서 CF의 역할을 싫어하긴 하지만, 이 글은 Canonical 인증서 갱신과 회사 이전이 같은 날 있었다는 것 말고는 근거 없이 점을 연결하려는 추측 묶음처럼 보임
    다만 곁가지로 볼 만한 이야기는 있음
    Njalla가 최근 조용히 조직 개편이나 소유권 변경을 한 듯하고[1], Njalla와 immateriali.sm이 관련된 법인처럼 보임[2]
    https://xn--gckvb8fzb.com/njalla-has-silently-changed-a-word...
    https://www.wipo.int/amc/en/domains/decisions/pdf/2026/dio20...

  • 글이 아주 간결하게 말하듯, Cloudflare는 공격자를 무료로 앞단에서 보호하고 피해자에게는 구제 비용을 청구함
    DDoS 방어 서비스는 디지털 보호비 갈취처럼 볼 수 있고, 공격자가 계속 공격하도록 둘 유인이 생김
    “위험한 인터넷이니, 무료 계층을 쓰는 공격자들로부터 웹사이트를 보호하려면 우리에게 돈을 내라”는 식임
    최소한 적극적 공모나 수익 배분이 없더라도, DDoS 방어 서비스가 어느 편에 서 있는지는 명확하지 않음

    • 그렇다면 해결책은 뭘까?
      지적에는 동의하지만, Cloudflare가 DDoS를 발명한 건 아님
      Cloudflare가 내일 마법처럼 사라져도 AI 크롤러들은 멈추지 않음
      대안은 뭘까? 인터넷을 둘러보려면 정부 발급 신분증을 올려야 하는 세상은 아니겠지?
    • 동네나 나라에서는 공격자로부터 통제권을 세우고 폭력의 통제를 확립할 수 있음
      인터넷의 상대적 익명성과 전 세계적 성격을 보존하고 싶다면 그걸 어떻게 할 수 있을까?
      사람들이 협동조합을 만들어 방어를 맡을 수도 있겠지만, 전 세계 규모의 주체로 운영하기는 어려움
      DDoS 방어는 주로 감당할 수 있을 만큼 과도한 용량을 갖고 필터링하는 방식이라 필요한 투자가 상당히 큼
    • 더 단순한 설명도 있음
      Cloudflare는 The Daily Stormer 사례[1]처럼 100%는 아니지만, 대체로 자기 시스템을 지나는 추정상 합법 콘텐츠를 검열하지 않고, 합법성의 판정자가 되기를 스스로 선택하지 않음
      [1]: https://blog.cloudflare.com/why-we-terminated-daily-stormer/
    • 인터넷의 기반 프로토콜에 있는 근본적 약점에서 태어난 보호비 갈취 구조임

  • 완전히 동의함
    Cloudflare는 거대한 규모로 사기꾼들을 보호하고 아무도 신경 쓰지 않음
    내가 Cloudflare에 신고한 가짜 쇼핑몰들, Cloudflare 뒤에 있던 피싱 페이지들은 하나도 내려가지 않았음
    단 하나도
    사람들을 보호해서 수십억을 버는 회사라면 이런 일을 진지하게 다뤄야 함

    • 법적 절차로 Cloudflare에 조치를 요구하지 않는다면 들을 가능성이 낮음
      예를 들어 “20달러 피해를 입었고, 손해배상 청구 대상을 특정하기 위해 Cloudflare에 제공된 고객 결제 정보, 발급 은행과 계좌번호를 구한다”는 식의 소액재판은 꽤 괜찮아 보임
      아직 누가 해봤다는 얘기는 못 들었지만, 누군가 한다면 결과를 보고 싶음
    • 항소 장치나 법적 절차 없이 웹사이트를 임의로 검열하는 거대 조직을 더 원하나?
      지금 상태가 훨씬 낫다고 봄

  • Ubuntu가 내려간 건 ubuntu 서버들이 copy.fail을 패치하지 못하게 해서, 그 해킹 그룹이 그 시간 동안 가능한 많은 대상을 악용하려고 했기 때문이라고 늘 생각했음

    • Ubuntu에서 copy.fail은 modprobe(8) 설정 몇 가지로 완화할 수 있었음
      # echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif.conf
      # rmmod algif_aead
      이 기능을 쓰는 프로세스가 있을 수도 있지만(lsof | grep AF_ALG), 내가 이해하기로 널리 쓰이진 않아서 대다수 시스템에서는 비활성화해도 문제가 없을 것임
    • copy.fail 패치는 최소한의 중단으로 적용할 수 있고, VM은 크기와 무관하게 재부팅에 길어야 30초면 됨
      모든 apex 서버는 부하 분산을 유지하도록 고가용성으로 설정되어 있을 테니, 일반 사용자는 copy.fail 패치 때 아무것도 느끼지 못할 것임
      우리 사용자들도 패치를 배포할 때 전혀 체감하지 못했음

  • 그건 협박이 아니라 갈취에 가까움
    CF는 둘 다 하지 않았음

  • 이런 논리라면 키보드 제조사도 자기 제품으로 작성된 불법 행위에 책임이 있다고 할 수 있음

    • 이건 기기 판매가 아니라 서비스임
      범죄 활동을 지원하는 데 쓰이는 조직에 계속 서비스를 제공하는 것은 매우 다르고, 불법 활동을 이유로 고객을 해지하는 건 논란거리도 아님
    • 같은 경우가 아님
      UPS 소포에서 폭탄을 받았다고 해서 UPS 잘못은 아님
      하지만 누군가 UPS를 이용해 사람들에게 폭탄을 보내고 있다고 알렸는데도 아무 조치도 하지 않고, 심지어 폭탄 발송자를 보호하는 것처럼 보인다면 어느 정도는 책임이 생기지 않나?
    • 잘못된 비유임
      이 시나리오에서 “키보드 제조사”는 Cloudflare가 장비를 사는 라우터 제조사에 가깝지 Cloudflare가 아님
      이 비유에서 Cloudflare는 온갖 더러운 것과 정상 해설을 함께 싣는 신문 집계자에 더 가까움
      보통 상황이라면 더러운 신문은 안 읽고, 읽고 싶은 사람은 스스로 결정하게 둘 수 있음
      하지만 Cloudflare 상황에서는 주요 정상 신문들이 모두 Cloudflare를 통해 콘텐츠를 발행하기로 했고, 문제 되는 게 함께 발행되면 원 발행자에게 따지는 대신 Cloudflare에 따져야 함
      그런데 Cloudflare는 사전에 알 수 없게 내 정보를 매우 불쾌한 사람들에게 전달할 수도 있음
    • 또는 물을 팔았다고 수도 회사에 책임을 묻는 식임
      선은 어디에 그어야 할까?
답변달기