Ubuntu İran Saldırısı: Canonical, DDoS ve Açık Kaynak Güvenliği

Canonical'in altyapısına yönelik saldırı haberi ilk ekrana düştüğünde, ofisteki ikinci monitörümde Launchpad'i açık tutuyordum. Ubuntu tabanlı bir pipeline'ın paket bağımlılıklarını güncellerken, ana sunucuların tepki vermediğini fark ettim. Hemen ardından gelen açıklama, işin sıradan bir kesinti olmadığını gösterdi: İran bağlantılı bir grup, Canonical'i hedef alarak Ubuntu İran saldırısı ile sadece hizmetleri çökertmekle kalmamış, aynı zamanda para talep ederek olayı bir şantaj operasyonuna çevirmişti. 2026'nın başlarında gerçekleşen bu olay, açık kaynak ekosisteminin en büyük kâhini olan "herkese bedava, ama birinin masrafa katlanması gerekiyor" gerçeğini bir kez daha suratımıza çarptı.

Ubuntu İran saldırısı nasıl gerçekleşti

Mayıs 2026'nın ilk günlerinde The Register'da yer alan haber, İran destekli bir grubun Canonical üzerindeki DDoS kampanyasını açıkça detaylandırıyordu. Saldırı, sıradan bir trafik spike'ından çok daha organizeydi. Grup, önce Ubuntu'nun ana indirme sunucularını, ardından Launchpad'i ve hatta Snap Store'un arka uç hizmetlerini hedef aldı. TechRadar'ın raporuna göre, saldırının ardından bazı temel hizmetler tamamen erişilemez hale geldi ve kurtarma süreci günlerce sürdü.

Saldırının zaman çizelgesine bakıldığında, olayın tek seferlik bir patlama değil, günler süren bir kampanya olduğu görülüyor. İlk dalga, Ubuntu'nun ana indirme sunucularına yönelik volumetric bir saldırıyla başladı. Ardından, kullanıcıların paket listelerini çektiği repository endpoint'leri hedef alındı. TechRadar'ın belirttiği gibi, bu ikinci dalga özellikle zararlıydı çünkü apt komutlarının zaman aşımına uğraması, sistem yöneticilerinin olayı kendi ağlarında bir problem sanmasına yol açtı. Bu da müdahale süresini geciktirdi.

PCMag'in aktardığına göre saldırganlar, servisleri çökerttikten sonra Canonical'e doğrudan iletişim kurarak para talep ettiler. Bu noktada olay sıradan bir aktivist DDoS'tan çıkıp, tam teşekküllü bir extortion operasyonuna dönüştü. Özellikle dikkat çekici olan, grubun taleplerini iletirken kullandığı dil ve yöntemlerdi; sanki kurumsal bir ransomware çetesinin playbook'undan fırlamış gibiydi.

Açık kaynak altyapılarına yönelik saldırılar artık sadece ideolojik değil; doğrudan finansal kazanç hedefliyor. Bu, oyunun kurallarını tamamen değiştiriyor.

Benzer saldırıları daha önce küçük ölçekte npm, PyPI veya Docker Hub üzerinde görmüştük. Ancak Canonical gibi, dünyanın en büyük Linux dağıtımına ev sahipliği yapan bir kuruluşun bu kadar uzun süre diz çökmesi, sektörde yankı uyandırdı. Çünkü Ubuntu sadece bir masaüstü işletim sistemi değil; AWS'den Azure'a, binlerce CI/CD pipeline'ına kadar uzanan bir omurga. Saldırganlar için etki alanı açısından son derece verimli bir hedefti.

Şantaj taktikleri ve saldırgan motivasyonu

Saldırganların kullandığı şantaj taktiğini anlamak için grupların son yıllardaki evrimine bakmak lazım. İran bağlantılı siber grupların bu saldırısı şaşırtıcı değil; ancak bu grupların açık kaynak altyapılarını hedef alarak doğrudan para talep etmesi, yeni bir eşik. Genellikle bu gruplar, devlet kurumlarına, finans sektörüne veya kritik altyapıya odaklanırdı. Canonical'e yönelmelerinin altında yatan neden ise oldukça pragmatik: dünya çapında milyonlarca makineye hizmet veren bir platformu rehin almak, etki alanı açısından son derece verimli.

Saldırganların kullandığı şantaj taktiği, klasik çifte kazanç stratejisine dayanıyor. Birincil hedef, hızlı bir ödeme almak. İkincil hedef ise, ödeme yapılmadığı takdirde elde ettikleri erişim ve kaos potansiyelini başka aktörlere satmak veya kamuoyuna şantajın kendisini bir "başarı" olarak pazarlamak. Bu yaklaşımın en çok gözden kaçan yanı, saldırganların aslında teknik olarak çok sofistike olmalarına gerek kalmaması. Yeterince büyük bir botnet ve hedefin altyapısındaki teknik borç, işi sizin için yapıyor.

Şantaj mektubunun içeriği tam olarak kamuoyuna yansımasa da, PCMag'in haberinden anlaşıldığı kadarıyla grup, ödemenin yapılmaması durumunda saldırıyı "daha agresif bir seviyeye" taşıyacaklarıyla tehdit etmiş. Bu tehdit, sadece bant genişliği değil, aynı zamanda veri bütünlüğü veya potansiyel olarak daha ciddi bir güvenlik ihlali iması taşıyordu. Canonical için bu nokta kritikti: çünkü eğer saldırganlar sisteme sızmışlarsa, DDoS sadece bir duman perdesi olabilirdi. Sonradan yapılan açıklamalarda böyle bir sızıntı tespit edilmediği belirtildi, ancak olayın ilk saatlerinde bu ayrımı yapmak neredeyse imkansızdı.

Geçmişte Anonymous-İran veya benzeri grupların daha çok deface ve veri sızıntısı odaklı çalıştığını görürdük. Şimdi ise DDoS-for-hire pazarının demokratikleşmesiyle birlikte, devlet destekli gruplar da bu araçları kullanarak finansal sürdürülebilirlik sağlamaya çalışıyor. Canonical gibi bir kuruluşun karşısına çıkan talep mektubu, muhtemelen birkaç Bitcoin değerindeydi; ancak gerçek zarar, itibar kaybı ve küresel kullanıcı tabanının yaşadığı kesintide gizli.

DDoS saldırılarının teknik altyapısı

Teknik detaylara indiğimizde, birçok geliştirici DDoS'i "çok trafik geliyor, sunucu kapanıyor" kadar basit görüyor. Sahada öğrendiğim kadarıyla, modern DDoS saldırıları çok katmanlı bir operasyon. Volumetric saldırılar, ağın bant genişliğini tıkar. Protokol saldırıları, SYN flood veya ACK flood ile firewall'ların connection table'ını doldurur. Ancak Canonical gibi bir hedefte en etkili olan genellikle Layer 7, yani uygulama katmanı saldırılarıdır.

Canonical'in durumunda, muhtemelen kullanılan yöntem, reflektör amplifikasyonu ile birleştirilmiş bir uygulama katmanı baskınıydı. DNS veya NTP amplifikasyonu kadar klasik olmasa da, HTTP/2 rapid reset gibi daha modern vektörler de devreye girmiş olabilir. Bu yaklaşımın en çok gözden kaçan yanı, saldırganın aslında hedefin kendi meşru protokollerini silah olarak kullanmasıdır. Ubuntu Update Manager'ın davranışını taklit eden istekler, basit bir IP blacklist ile engellenemez.

Ubuntu paket indekslerine veya Snap metadata endpoint'lerine yapılan yoğun istekler, görünüşte tamamen meşru trafik gibi görünür. Ama binlerce node'dan gelen paralel apt update çağrısı, arka uç veritabanını kilitleyebilir. Bunu ilk öğrendiğimde, küçük bir VPS'de basit bir rate limit ile çözebileceğimizi sanıyordum. Ne kadar yanlış bildiğimi, gerçek bir anycast ağının arkasındaki origin sunucuların nasıl tıkandığını görünce anladım.

# Örnek: Nginx erişim loglarında anormal spike tespiti
# Tek bir IP'den değil, ama benzer User-Agent ve path deseninden gelen istekler

awk '{print $1, $6, $7}' /var/log/nginx/access.log | \
  grep "GET /ubuntu/dists/" | \
  sort | uniq -c | sort -nr | head -n 20

# Normalde 100-200 istek olan bir path, saldırı anında 
# saniyede binlerce kez tekrarlanıyor.

Çoğu kaynak bunu atlıyor ama DDoS korumasında en kritik nokta, "normal" ile "anormal" arasındaki çizgiyi gerçek zamanlı çekebilmek. Çünkü Ubuntu'nun kendi güncelleme mekanizması, milyonlarca makineden eşzamanlı istek almaya zaten programlı. Saldırı trafiği, bu meşru trafikle karıştığında ayırmak için davranışsal analiz şart. Ayrıca, upstream provider'ınızın scrubbing center kapasitesi de önemli. Eğer saldırı 500 Gbps'in üzerindeyse ve sizin anlaşmanız 100 Gbps ile sınırlıysa, attığınız her teknik önlem boşa gidiyor.

Canonical altyapısı ve açık kaynak operasyonları

Canonical'in altyapısının ölçeğini düşündüğümüzde, bu saldırının neden bu kadar yıkıcı olduğu anlaşılıyor. Canonical, ticari bir şirket olmasına rağmen, Ubuntu'nun paket havuzları ve temel hizmetleri için hâlâ açık kaynak mantığıyla çalışan bir operasyon yürütüyor. Launchpad, ARM ve x86 için yapılan binlerce günlük build'i barındırıyor. Ubuntu Security Notices (USN) sayfaları, dünya genelindeki sistem yöneticileri tarafından otomatik olarak taranıyor. Bu hizmetlerin herhangi birinin kesintiye uğraması, domino etkisi yaratıyor.

TechRadar'daki haberde vurgulandığı gibi, saldırının ardından "bazı hizmetler hâlâ down" durumdaydı. Bu cümle, aslında altyapının ne kadar karmaşık olduğunu gösteriyor. Bir CI/CD ortamında, upstream paket deposuna erişilemezse build'ler başarısız olur. Başarısız build'ler, deployment pipeline'larını durdurur. Bu da doğrudan üretim ortamlarını etkiler. X şirketinde şöyle bir sorunla karşılaştık: Ubuntu arşivine erişim 2 saat kesildi, bizim microservice'lerin base image yeniden oluşturma süreci tamamen kilitlendi. O gün öğrendim ki, DockerHub'daki mirror'lar bile arka planda Launchpad'e bağlı olabiliyor.

Saldırı süresince Canonical'in durum sayfası ve sosyal medya üzerinden yaptığı açıklamalar, topluluk için tek bilgi kaynağıydı. Ancak burada dikkat çekici bir detay var: Launchpad'in build farm'ı, saldırı sırasında kuyrukta bekleyen paket derlemelerini askıya aldı. Bu, downstream projeleri de etkiledi. Örneğin, Ubuntu tabanlı bir Kubernetes dağıtımı olan MicroK8s'in günlük build'leri gecikti. Domino taşının ilk halkası böylece hareket etmiş oldu.

Canonical'in yanıt süreci ve iletişim stratejisi, olayın yönetimi açısından ders niteliğindeydi. Ancak burada önemli bir nokta var: açık kaynak projelerinin operasyon ekipleri, genellikle enterprise şirketlerinin SOC'ları kadar geniş kaynaklara sahip değil. Bir Fortune 500 şirketi, saldırı anında 7/24 çalışan bir NOC'u devreye sokar, scrubbing servisleri anında aktive eder. Açık kaynak altyapısında ise, olayla ilgilenen muhtemelen bir avuç full-time mühendis ve gönüllüden oluşan bir ekip. Bu kaynak asimetrisi, saldırganlar için büyük bir avantaj.

Açık kaynak güvenliğinin finansman çıkmazı

Bu kaynak asimetrisi, aslında açık kaynak güvenliğinin finansman çıkmazının sadece bir yüzü. Bu olayı takip ederken aklıma gelen ilk soru şuydu: Dünya üzerindeki bulut altyapısının yaklaşık %40'ı Ubuntu üzerinde çalışıyor. Peki bu kadar kritik bir altyapının güvenliği ve dayanıklılığı için ne kadar kaynak ayrılıyor? Cevap, üzücü derecede az.

Açık kaynak projeleri, "birileri zaten bakıyordur" zihniyetiyle finanse ediliyor. Canonical, Snap ve Ubuntu Pro ile ticari gelir elde etse de, temel arşiv sunucuları ve Launchpad gibi hizmetler kamuya açık ve büyük ölçüde ücretsiz. AWS, Google Cloud, Microsoft Azure gibi devler, kendi Ubuntu görüntülerini milyonlarca müşteriye sunuyorlar; ancak bu gelirin önemli bir kısmı Canonical'e gitmiyor. Bu da altyapı yatırımlarının, gerçek risk profiline göre şekillenmesini engelliyor.

Linux dağıtım altyapıları, dünyanın en büyük "kamu malı" gibi davranılıyor; ama güvenlik bütçeleri küçük bir startup düzeyinde.

Benzer bir durumu 2021'de Log4j krizinde de gördük. Dünyanın en yaygın logging kütüphanesine bakıyordu ve arkasında tam zamanlı çalışan sadece birkaç gönüllü vardı. Canonical için durum biraz daha iyi olabilir, çünkü arkasında bir şirket var. Ama bu şirketin bile altyapı bütçesi, üzerinde çalışan ekonominin değerinin çok altında. Saldırganlar bunu biliyor. Hedef seçerken, etki/bütçe oranı en yüksek olan kuruluşları seçiyorlar.

Bu finansman çıkmazı, sadece Canonical'e özgü değil. Python Software Foundation, RubyGems, hatta Linux Kernel'in kendisi bile benzer kaynak kısıtlamalarıyla karşı karşıya. Fark, Canonical'in en azından bir ticari varlık olması ve bu saldırı sonrası muhtemelen güvenlik bütçesini artıracak olması. Ama ya bir sonraki hedef, tamamen gönüllüler tarafından yönetilen bir proje olursa? O zaman durum çok daha vahim olur.

Büyük şirketlerin altyapı bağımlılığı ve riskleri

Finansman meselesi sadece Canonical'in kasasını ilgilendirmiyor; doğrudan şirketlerin risk yönetimini de etkiliyor. Çoğu enterprise şirket, tedarik zinciri güvenliğini konuşurken npm paketlerini veya Docker image'larını inceliyor. Ama işletim sistemi dağıtımının kendisine, yani Canonical gibi bir kuruluşun ayakta kalmasına olan dolaylı bağımlılığı gözden kaçırıyor. Ubuntu'yu "sadece bir işletim sistemi" olarak görmek, onu "sadece bir kemer" olarak görmek gibi. Kemer kırılırsa, pantolon düşer.

Bir finans teknolojileri şirketinde danışmanlık yaptığım dönemde, üretim ortamındaki tüm sunucuların security.ubuntu.com ve archive.ubuntu.com'a sürekli bağlı olduğunu fark ettik. Kendi mirror'larımız yoktu. Bir gün bu adreslere erişim olmasa, güvenlik yamaları otomatik olarak uygulanamayacaktı. Bu bağımlılığı haritalamak bile birkaç haftamızı aldı. Canonical'e yönelik bir DDoS, aslında bu bağımlılığı hiç fark etmeyen binlerce şirketi dolaylı olarak vuruyor.

Şirketlerin yaptığı bir diğer hata, sadece "kendi kodlarını" veya "kendi container'larını" güvenli sanmaları. Ama container'ın içinde çalışan işletim sistemi, bir güncelleme alamıyorsa, en temiz kod bile güvensiz hale gelir. Log4Shell'den sonra bu dersi aldığımızı sanıyorduk; ama Canonical saldırısı gösteriyor ki, aynı dersi altyapı seviyesinde de tekrar etmemiz gerekiyor.

A ile B arasında seçim yapıyorsan; kendi paket mirror'ını tutmak veya upstream'e güvenmek arasında kalırsan, mirror maliyetli ama riski azaltır. Ancak mirror bile upstream metadata'ya ihtiyaç duyar. Yani tam anlamıyla bağımsız bir dağıtım zinciri kurmak, ancak enterprise ölçeğinde mümkün. Küçük ve orta ölçekli şirketler için bu, "lüks" değil, "imkansız" olabilir. İşte bu nedenle, upstream sağlayıcının dayanıklılığı, sizin dayanıklılığınız haline geliyor.

Benzer saldırıları önlemek için gereken tedbirler

Şirketiniz bu tür bir upstream saldırısına karşı kendini nasıl koruyabilir, sorusuna teknik ve stratejik düzlemde yanıt aramak gerekiyor. Öncelikle, DDoS koruması sadece kendi kapınızın önünde değil, tedarikçilerinizin kapısında da düşünülmesi gereken bir mesele. Canonical gibi bir kuruluş için öneriler şunlar:

• Anycast ağını genişletmek: Trafik scrubbing'i daha fazla PoP noktasında yapmak, origin'e ulaşmadan saldırıyı dağıtır.
• Rate limiting ve davranışsal analiz: Paket indeks isteklerinde anormal pattern'leri tespit eden kendi WAF kurallarını geliştirmek.
• Multi-cloud failover: Arşivlerin ve kritik hizmetlerin farklı bulut sağlayıcıları üzerinde aktif-aktif veya aktif-pasif kopyalarını tutmak.

Ancak burada teknik önlemler yeterli değil. Çoğu kaynak bunu atlıyor ama açık kaynak altyapılarına yönelik finansman modelleri değişmeli. Büyük bulut sağlayıcıları, kullandıkları açık kaynak projelerine doğrudan altyapı katkısı yapmalı. Örneğin, AWS'nin kendi CDN'sinin bir kolunu Ubuntu arşivlerine ayırması, hem maliyetleri düşürür hem de dayanıklılığı artırır. Ya da daha da iyisi, endüstri genelinde bir "kritik açık kaynak altyapı fonu" oluşturulmalı.

Küçük ölçekli operatörler için ise en pratik çözüm, local caching stratejilerini güçlendirmek. Apt-cacher-ng, Nexus Repository Manager veya Artifactory gibi araçlarla paket bağımlılıklarını internal'e çekmek, upstream kesintisinde en azından mevcut işleyişi korumayı sağlar. Benim tavsiyem, güncelleme mekanizmalarınızı "upstream'e sürekli bağlı" olacak şekilde tasarlamayın. Offline-capable bir güncelleme stratejisi, sadece güvenlik duvarı değil, iş sürekliliği politikasıdır.

Rate limiting konusunda, apt istemcilerinin davranışını bilmek önemli. Varsayılan olarak apt, 6 paralel bağlantı kullanır ve bir repository'den dosya çeker. Eğer tek bir IP'den saniyede yüzlerce farklı User-Agent görüyorsanız veya aynı paket indeksine sürekli HEAD istekleri geliyorsa, bu bir anormallik işareti. WAF kurallarınızı buna göre ayarlamalısınız. Fakat şunu da unutmayın; agresif rate limiting, meşru kullanıcıları da etkileyebilir. Bu dengeyi bulmak, operasyonun en zor kısmı.

Ubuntu İran saldırısı ve açık kaynak dersleri

Tüm bu teknik ve operasyonel önlemlerin ötesinde, asıl değişmesi gereken şey zihniyet. Canonical'e yönelik bu saldırı, açık kaynak topluluğunun üzerinde düşünmesi gereken bir uyarıcı. Uzun yıllardır, "açık kaynak daha güvenlidir çünkü çok göz inceler" savunmasını duyarız. Bu savunma, kod güvenliği için kısmen doğru olabilir; ama operasyonel güvenlik için hiçbir şey ifade etmiyor. Kod ne kadar temiz olursa olsun, sunuculara yönelik bir DDoS, işletim sisteminin kendisini hedef almıyor, onu dağıtan altyapıyı hedef alıyor.

Bunu ilk öğrendiğimde, açık kaynak projelerinin güvenlik modellerinin tamamen kod odaklı olduğunu fark ettim. Operasyonel güvenlik, genellikle gönüllülerin iyi niyetine ve birkaç sponsorun jestine bırakılıyor. Canonical'in yaşadığı, bu modelin sınırlarını zorlayan bir olay. Şirketlerin, açık kaynak projelerine yaptıkları katkıları sadece kod commit'i veya konferans sponsorluğu olarak görmesi yetersiz. Altyapı, bant genişliği ve güvenlik operasyonları katkısı da şart.

Geçmişte Heartbleed, Shellshock ve daha sonra Log4j gibi olaylar, açık kaynak güvenliğinin kod boyutundaki kırılganlıklarını gösterdi. Canonical olayı ise operasyonel boyutu ortaya koydu. İkisi bir arada düşünüldüğünde, açık kaynak güvenliği artık sadece "güvenlik açığı yönetimi" değil, "altyapı dayanıklılığı yönetimi" olarak da ele alınmalı.

Gelecekte, kritik açık kaynak projelerinin "kritik altyapı" statüsü kazanması ve buna uygun regülasyonlarla desteklenmesi gerekebilir. Avrupa Birliği'nin Cyber Resilience Act'i bu yönde bir adım. Ancak regülasyonlar yeterli değil; piyasanın kendisi de bu riskleri fiyatlamaya başlamalı. Ubuntu'ya güvenen bir bulut sağlayıcısı, upstream sağlığını SLA'sının bir parçası olarak görmeli ve buna göre yatırım yapmalı.

Geçen hafta terminalimde sudo apt update komutunu çalıştırırken, arkasındaki binlerce sunucu, yönlendirici ve veritabanının ne kadar kırılgan bir denge üzerinde durduğunu düşündüm. Canonical'in yaşadığı saldırı, bu kırılgan dengeyi sarsan bir dokunuştu. Umarım bu dokunuş, sadece panik değil, kalıcı bir değişimin de başlangıcı olur.