AWS’den şirket içi hizmetlerime bağlantıyı engellemek

 (consulting.m3047.net)
1 puan yazan GN⁺ 2024-09-01 | 1 yorum | WhatsApp'ta paylaş
  • Açık internet, büyük bulut sağlayıcıları merkezli parçalanmış bir ekosisteme bölünebilir; AWS kaynaklı şirket içi erişim engeli de bu akışı gösteren operasyonel bir örnek
  • Engellemenin hedefi çoğunlukla AWS içindeki istemcilerin şirket içi hizmetlere açtığı TCP bağlantı denemeleri; yerel istemcilerin AWS’te barındırılan hizmetlere giden bağlantıları ise çalışmaya devam ediyor
  • Çalışan şirket içi hizmetler web, Trualias demosu, DNS ve SMTP; DNS, UDP ve TCP fallback ile sınırlı güvenlik telemetrisi için herkese açık erişim sağlıyor
  • AWS engeli, aşırı ping trafiği ve kötüye kullanan crawler/scanner’lara yanıt olarak başladı; şu anda kötüye kullanım hedefi veya kaynağı olarak gözlemlenen AWS adres alanına ait 53 CIDR yönetiliyor
  • Büyük bulut sağlayıcıları reverse DNS, whois, DNS ad alanı ve kötüye kullanım örüntüleri gibi adli bilgileri daha iyi yayımlamazsa, bulut içindeki kullanıcıların neredeyse hiç rahatsızlık hissetmediği bir parçalanma güçlenebilir

Büyük bulutların yaratabileceği parçalanma

  • Büyük bulut sağlayıcıları “too big to fail” bulletproof infrastructure hâline gelirse internetin parçalanmasına doğrudan yol açabilir
  • Bu henüz tamamen gerçeğe dönüşmüş bir olgu değil, ancak başlamış ya da yakında ortaya çıkabilecek bir durum olarak görülüyor
  • Bulut yerel ekosistemi, gerçek internetle karşılaştırıldığında özelleştirilmiş altyapıya sahip; her bulut hizmeti ortak bir mimariden çok ayırt edici işlevler etrafında kurgulanıyor
  • Birçok hizmet belirli bir bulutun içinde kendi kendine yeterli şekilde çalışıyor ve genel internetle şeffaf birlikte çalışabilirliğin önünde engeller var
  • Bulut yerel topluluk, genel interneti harici kaynak gibi ele alıyor ve internetin kendisinden çok belirli bulut sağlayıcı ekosistemleriyle etkileşime giriyor

Açık internetin ticarileşme süreci

  • 1989 öncesinde internete genel kamu erişimi yoktu; hükümet, ordu, araştırma ve eğitim kurumlarının kullandığı özel nitelikli bir ağdı
  • Omurganın çekirdeğini NSF yönetiyordu; ilk açık erişime ticari olmayan trafik koşuluyla izin verildi
    • Ticari hizmetlerin kendisi yasak değildi, ancak NSFNet omurgasından geçen trafik reklam veya ücretli hizmet trafiği olmamalıydı
  • Ticari işletmeciler ayrı bir ticari internet kurdu ve 1995’te NSFNet açık erişimi devre dışı bıraktı
  • 2000 civarındaki büyük elenmenin ardından kullanıcı davranışı verisine dayalı reklam ve kullanıcı davranışı verisi satışı modelleri ayakta kaldı
  • Günümüzdeki yapay zeka dalgasında, erişilebilir içeriğin büyük ölçekte toplanıp aklanarak model eğitiminde kullanılması öne çıkıyor; kürasyon ve eğitim çoğunlukla bulutta, giderek de bulut sağlayıcılarının kendileri tarafından yapılıyor

Şirket içi hizmetlerde AWS bağlantılarını engellemek

  • Şirket içi sunuculara gelen AWS erişiminin çoğu devre dışı bırakılıyor
  • Teknik olarak odak çoğunlukla TCP trafiği üzerinde; ilk handshake ile istemci ve sunucu ayırt edilebiliyor
    • AWS içindeki bir istemcinin şirket içi hizmete bağlanma denemesi engelleniyor
    • Yerel ağdaki bir istemcinin AWS’te barındırılan bir hizmete bağlanması mümkün
  • Yerel olarak internete açık birkaç hizmet çalıştırılıyor
    • Web hizmeti
    • Trualias demosu
    • DNS sunucusu
    • SMTP e-posta sunucusu
  • Yıllardır no crawl politikası sürdürülüyor ve sunulan varlıklar ağırlıklı olarak internetteki bireysel kullanıcılara yönelik
  • DNS sunucusu UDP ve TCP fallback kullanıyor, ayrıca sınırlı herkese açık güvenlik telemetrisi sağlıyor
    • Örnek sorgu: dig @131.191.85.30 'fail2ban;*.keys.redis.athena.m3047' txt
    • Bulutta çalışan hizmetler için de yararlı olabilir, ancak operasyonda buna bağımlı olunacaksa önce iletişime geçilmesi bekleniyor

reverse DNS ve SMTP istisnası

  • Sorun yalnızca web hizmetiyse reverse DNS sorgusu gibi başka hafifletme önlemleri kullanılabilir
  • Bulut sağlayıcıları çoğu zaman reverse DNS’i zayıf işletiyor; bu da bulut içindeki kaynakların geçici olduğu anlatısıyla örtüşüyor
  • AWS, birçok başka bulut sağlayıcısına göre reverse DNS konusunda daha iyi sayılır; instance’ın reverse DNS’inin ayarlanabildiği duyulmuş olsa da doğrudan denenmemiş
  • SMTP için istisna tanınıyor
    • Sorun özellikle ağır değilse, diğer hizmet bağlantıları engellense bile posta sunucusu bağlantılarına izin veriliyor
    • Teknik olarak doğru reverse DNS olmadan da SMTP çalıştırılabilir, ancak pratikte doğru reverse DNS yoksa karşı taraf postayı kabul etmiyor
  • reverse DNS değerlendirildiğinde SYN’in meşru bir posta sunucusundan gelip gelmediğine dair ilk karar verilebilir
    • İtibar hizmetleri reverse DNS’i puanlayabilir
    • Kiralık ve geçici kaynaklarda yaygın örüntüler var
  • reverse DNS’in varlığı ya da biçimi tek başına bir adresin bulut sağlayıcısına ait olup olmadığını makul biçimde tahmin etmeye yardımcı olabilir

AWS adreslerini engellemenin başlama nedeni

  • Bazı kötüye kullanan hizmetlerin tanımlanabilir netblock’larını engelleme çalışmasıyla başladı; ardından küçük hosting sağlayıcılarını seçici engellemeye yönelik bir kavram kanıtına dönüştü
  • AWS özelinde başlangıç noktası aşırı ping trafiğiydi
    • Ping bağlantısız bir protokol olduğu için kaynak adres sahte olabilir
    • Sahte ping isteğinin yanıtı saldırgana değil, sahte gösterilen gerçek konuma gider
  • Sürekli ping yanıtlarını bastırmak için geçici firewall kuralları oluşturmak gerekir, ancak Amazon’un ölçeği çok büyük olduğu için kural sayısı artıyor
  • AWS adres aralıkları toplanmaya başlandı ve şu anda kötüye kullanım hedefi veya kaynağı olarak gözlemlenen AWS adres alanını temsil eden 53 CIDR bulunuyor
  • Zaman zaman bunun iki katına ulaşan geçici firewall kuralları da gözlemleniyor
  • “too big to fail” bulut sağlayıcısından kiralanmış kötüye kullanan crawler ve scanner’ları engellemek iyi bir yan etki; web loglarından kaybolmaları da üzücü değil

Bulut kullanıcılarının yaşadığı etki

  • Popüler kaynakların veya bulutta dağıtılma olasılığı olan kaynakların çoğu GitHub üzerinde barındırılıyor
  • Diğer kaynakları buluta dağıtan kişilerin staging için kullanacakları kendi depolarını tutması gerekiyor
  • Depo AWS’teyse artık güncelleme kontrolü yapılamaz hâle geliyor
    • Masaüstünden kontrol edilmeli
    • Özel olarak barındırılan bir kaynaktan kontrol edilmeli
    • Ayrı bir arrangement görüşülebilir
  • Yalnızca akıllı telefon, S3 bucket ve EC2 instance’a sahip olma durumunu “internette olmak” saymak zor; ancak akıllı telefondan bu kaynaklara erişilebilmesi gerekir

Veri hırsızlığını hafifletme ve amaç dışı kullanım

  • Açık kaynak materyallerin izinsiz şekilde amaç dışı kullanımlara tahsis edilmesi olan veri hırsızlığı da ayrı hafifletme gerektiren bir tehdit
  • AWS engeli bu tür hafifletme önlemlerinden biri olarak da işliyor
  • cats, bunnies, birds ile ilgili materyaller de hafifletme bağlamında birlikte ele alınıyor
    • cats ve bunnies, ilgili videoların çok olması ve bazılarının satın alınabilmesi nedeniyle gündeme geliyor
    • birds, OSI katman 2’de daha etkili; IP datagram iletim yöntemi olarak RFC’de belgelenmiş durumda

Büyük bulut sağlayıcılarının sunması gereken açık bilgiler

  • Büyük bulut sağlayıcıları bugünkünden daha iyi bir adli bilgi dağıtımı sistemi sunmalı
  • DNS ve whois, potansiyel olarak yararlı bilgileri dağıtmak için araç olabilir
  • Büyük bir sağlayıcı kendi reverse DNS’ini işletebilmelidir
  • Tek tek adresler için whois, reverse DNS’e kodlanmış ek bilgiler ve DNS ad alanında ayrı herkese açık bilgiler gerekebilir
  • Güncel kötüye kullanım örüntülerini ve etkilenen adres bloklarını ele alan bir storm center blog da olası bir yöntemdir
  • SMTP’de reverse DNS’in yanı sıra DNS TXT kaydıyla yayımlanan SPF de var
  • Yalnızca tek bir IP adresiyle bile şu sorulara yanıt verecek bilgi bulunabilmeli
    • Bu adresin arkasındaki kaynağın ping gönderip göndermediği
    • Ne kadar ping gönderdiği
    • Outbound TCP bağlantıları oluşturup oluşturmadığı
    • Hangi hizmetlere bağlandığı
    • Kaynağı kimin kontrol ettiği
    • Kaynağın saldırı altında olup olmadığı
    • Saldırının hangi türde olduğu
    • İnternetteki diğer kaynakların hangi hafifletmeleri sunmasını istediği
  • Uygun hafifletme herkese yardımcı olur; yanlış hedeflenmiş hafifletme ise olmaz

Parçalanmış internetin sonucu

  • Bu yaklaşım yaygınlaşırsa balkanized internete yol açabilir
  • Büyük bulut sağlayıcılarının balonunun içinde çevrimiçi hayat süren kişiler rahatsızlıkların çoğunu fark etmeyebilir
  • Fark ettikleri rahatsızlıkları da belirli bir bulut sağlayıcısını seçmelerinin sonucu olarak kabul edebilirler

İlgili okumalar

1 yorum

 
GN⁺ 2024-09-01
Hacker News yorumları

  • Büyük bulut sağlayıcılarının tamamı makineler tarafından okunabilir IP aralığı listeleri yayımlıyor
    Örnek: https://docs.aws.amazon.com/vpc/latest/userguide/aws-ip-rang...
    https://www.microsoft.com/en-us/download/details.aspx?id=565...
    https://support.google.com/a/answer/10026322?product_name=Un... vb.

    • Bugün kontrol etmedim ama örneğin Amazon'un JSON dosyası, gerçekte kime ait olduğundan bağımsız olarak fiilen 3.0.0.0/8 kullandığını gizliyor
      “Amazon'un devasa JSON listesini engelleyeyim” gibi bir oyun oynama niyetim yok; yalnızca 53 kural var. Bir miktar yan etkiyi tolere edebilirim ve AWS üzerindeki sitelere de gayet erişiliyor

  • Bugünün internetinde, altyapıyı görünür hale getirir getirmez saldırgan trafiğin yapışma hızı akıl almaz seviyede
    Kısa süre önce anycast kurulumu için bir /23 alt ağı BGP ile duyurdum; rota aktif olur olmaz ve trafik yönlendiriciye akmaya başlar başlamaz tcpdump, aralıktaki tüm IP'lere yönelik port taramalarıyla dolup taştı
    Elbette bunun doğrudan rotadan kaynaklandığını söylemiyorum; daha ziyade çok sayıda aktör tüm IP aralıklarını ayrım gözetmeden ve sürekli tarıyor gibi görünüyor. Bu aralık yıllardır duyurulmuyordu, yani birinin aktif sunucu listesinde yer alıyor olması da söz konusu değil
    GitLab gibi iç web servislerini hâlâ doğrudan internete açık bırakmak bana şok edici geliyor. En azından VPN gibi ek bir koruma katmanı olmalı ki servisler açık internette keşfedilemesin
    Herkese açık erişime sahip tek şey tek bir bastion host üzerindeki SSH ve mümkünse ileride ona da VPN katmanı ekleyip bunu ortadan kaldırmak istiyorum

    • Beklentileri yeniden ayarlamak daha iyi olur. Port taraması çok da büyük bir şey değil; saldırı demenin bile zor olduğu, internetin arka plan radyasyonu gibi bir şey
      Uzayda arka plan radyasyonu olduğu gibi, internete çıkınca da internetin arka plan radyasyonu vardır. Savunmasız servisler çalıştırmıyorsanız bu tür port taramalarının riski, ayda bir muz fazla yemek kadar önemsizdir
      Sadece bunu konsolda canlı canlı gördüğünüz için rahatsız edici geliyor. Uçağa aşırı hassas bir Geiger sayacıyla binerseniz ürkebilirsiniz ama farkında değilseniz size zarar vermemesi gibi
      İç servisleri internete açma konusuna ben de şaşırıyorum; bunun iki nedeni var. Çoğu programın kimlik doğrulama sistemine güvenmiyorum ve hangi iç servisleri kullandığımı dışarıya belli etmek istemiyorum. Bu, saf teknik güvenlikten çok mahremiyetle ilgili bir gerekçe de içeriyor
      Buna karşılık internette olmak zorunda olan ve güçlü bir ana girişe sahip ya da yeterince sandbox'landığına güvendiğim şeyler bütün gün internette kalabilir
      Port taraması, şehirde dolaşıp hangi evlerin ışığının yandığını not etmenin internetteki karşılığıdır. Biraz sapıkça gelebilir ama kamusal bilgidir
      Bu arada ssh -w bir VPN tünel arayüzü oluşturur ama gerçek bir VPN ürünü gibi geri kalan yapılandırmayı otomatik yapmaz
    • Üstüne bir VPN katmanı eklemek istiyorsanız hangi VPN yazılımını kullanmayı düşündüğünüzü merak ediyorum. Şahsen OpenSSH kadar güvenilir hissettiren bir şey bulamadım
    • Hatalı yapılandırılmış, herkese açık SSH asla internete konmamalı. Kelimenin tam anlamıyla birkaç saniye içinde ele geçirilebilir
      İnternet giderek Cyberpunk'taki blackwall'un arkasında olan bitenlere benziyor gibi geliyor
    • Bu sadece “bugünün” meselesi değil. 25 yıl önce de internete açık web sunucularını script'lerin ya da botların sürekli yoklaması oldukça yaygındı ve web erişim loglarında sık görünürdü
      Güvenlik duvarının reddedilen erişim loglarını açarsanız, bilinen ve bilinmeyen portlara yönelik denemelerin sürekli aktığını görürdünüz
      Bir şeyi dışarı açıyorsanız, derinlere gizlenmiş bir web bileşeni bile olsa, onun verilerinize ve altyapınıza açılan bir kapı haline gelmemesini sağlamalısınız
      O zamandan biraz farklı olan şey, trafiğin kaynakları ve neyin kabul edilip neyin engellenmesi gerektiğine karar verme ölçütleri. Meşru sunucuların ve servislerin, son kullanıcı tarafındaki proxy'lerin, bulut sağlayıcılarının ve crawler'ların sayısı ciddi biçimde arttı
    • Bu, IPv4'e özgü bir sorun gibi geliyor. Yalnızca IPv6'ya geçilse kötü niyetli aktörler için IP taraması pratikte gerçekçi olmaktan çıkmaz mı?

  • Gerçekten üzücü bir durum. Böyle yaparsanız kendi içeriğiniz arama motorlarında hiç görünmeyebilir, Marginalia tarafından da yakalanmayabilir ve Wayback Machine tarafından da arşivlenmeme riski doğar
    Aslında amaç buysa, tüm bulutları ve veri merkezlerini engellemek daha doğru olabilir. Hatta bazı küçük ISP’lerin CGNAT gateway’lerini nerede çalıştırdığına bağlı olarak o ISP’nin kullanıcılarını bile engelleyebilirsiniz. Olasılık düşük ama imkânsız değil
    Yazıda fiilî kötüye kullanım olarak anılan tek şeyin sahte kaynak adresli ping’ler olduğu görülüyor. Sahte ping paketlerinin AWS’den gelip gelmediği bilinemez. Çünkü kaynak adresi, spoofing yapanın yanıtın gitmesini istediği adrestir; spoofing yapanın kendi adresi değildir
    Çok daha az müdahaleci bir önlem, ping’i saniyede yaklaşık 10 adetle rate limit etmektir
    İnternet gerçekten balkanlaşıyor, ama asıl sebep IP bloklarını engellemekten çok, reklam/veri geliri için sosyal medyanın silo hâline gelmesi ve yapay zeka eğitim verisinden gelir çıkarma eğilimi. Reddit/Google tekel anlaşması gibi örnekler buna daha yakın
    Birkaç ping yüzünden belirli bir sağlayıcıyı engelleyip sonra da IP bağlantısının balkanlaştığından şikâyet eden düşünce tarzını anlamak zor. Balkanlaşmayı yaratan taraf, engelleyen taraftır

    • Bugünlerde arama motorlarında devasa reklam bulaşmış içerik çiftlikleriyle Wikipedia, Stack Overflow, büyük haber/medya siteleri ve YouTube gibi büyük siteler dışında neredeyse hiçbir şey çıkmıyor
      Kişisel blogların ya da küçük hobi sitelerinin arama sonuçlarında görünmeyeli epey oldu
      Wikipedia veya Stack Overflow gerekiyorsa o sitelerde doğrudan arama yapılabilir. “Hep görünen adaylar” dışında daha uzun kuyruktaki içeriği görmeye yarayan bir seçenek olmasını isterdim
    • Bu, balkanlaşmaya yol açabilecek bir adımı “zorunlu olarak” atmak zorunda kalmaya dair bir yakınma gibi görünüyor
      Yine de genel ton, sivrisinek ısırığını görkemli bir tarih anlatısına dönüştürmeye daha yakın
    • Küçük bir ISP bile neden kendi IP alanı dışındaki bir yerde CGNAT gateway çalıştırsın ki?
      Bulutta CGNAT gateway işletmek pek çok sorun yaratırdı. Abonelerin IP’leri artık konut tipi IP olmazdı; bu yüzden Netflix gibi hizmetleri izleyemeyebilirler, ayrıca Cloudflare ya da Google’dan bot önleme CAPTCHA’larıyla daha sık karşılaşabilirler
      Bunun gerçekten bilinen bir örneği var mı merak ediyorum
    • “Arama motorlarında çıkmamak” durumunu neden bir dezavantaj ya da kayıp olarak gördüğünüzü merak ediyorum. Bu bakış açısını paylaşmıyorum ama anlamaya çalışıyorum
    • Yazar, uzun zamandır crawl yasak politikası uyguladığını söylüyor. Muhtemelen bunu dert etmiyordur; Google’ın enshittification süreci düşünüldüğünde belki de doğru tercih budur

  • Hetzner, DigitalOcean, Linode, OVH ve Contabo’yu bir süredir engelliyorum
    Bu, pfBlocker NG’de ASN block ile yapılabilir; UFW kurallarıyla da mümkün: https://blog.abctaylor.com/ufw-and-firewalld-rules-to-block-...

    • Böyle toptan engellemek, meşru kurumların siteye erişememesine yol açabilir. Bir şey satan bir siteyse bu sorun olabilir
      Örneğin bir kurum, bir bulut sağlayıcısı üzerinde WireGuard ya da başka bir VPN çözümünü kendisi çalıştırıyor olabilir; insanlar oradan bağlanırsa dışarıya görünen IP bulut sağlayıcısının IP’si olur
    • Bugünlerde büyük küçük birçok şirket, bulutta exit node barındıran VPN’ler veya benzeri çözümler kullanıyor. Bu tür engeller sonunda iş bilgisayarlarından web sitelerine erişilememesine yol açabilir
    • Vay canına, neden Hetzner bile?
    • Bunun gerçek dünyadaki gibi karşılıklı olması gerektiğini düşünüyorum. Biri bir sağlayıcıyı engelliyorsa, o sağlayıcının da geri engelleyebilmesi gerekir
      Hatta bu otomatikleştirilebilir. Böylece adil olur ve her taraf ne olduğunu bilir. Yoksa böyle kum havuzu oyunları yerine gidip gerçek silah kullansınlar

  • İlk aklıma gelen, AWS üzerinde çalışan gerçek masaüstlerinin, özellikle Amazon Workspaces gibi hizmetlerin engellenebileceğiydi
    Ama bu tür hizmetlerin IP alanları da kamuya açık biçimde belgelenmiş görünüyor; gerekirse bu IP’ler ayrıca allowlist’e alınabilir
    Yine de proxy veya VPN kullanırsanız bu tür engelleri aşmak çok kolaydır

    • Senin için kolay olabilir. Ama bugünlerde çok sayıda insanın serverless’a yöneldiğine bakınca, teknisyenlerin çoğu da kendi ağını ya da altyapısını bizzat yönetmek istemiyor gibi görünüyor

  • Çok uzun zaman önce, birkaç düzine Amazon sunucusu bizim on-premises sunucularımızı yavaşlatmaya başlayınca ben de bunu yaptım
    Bir tür SSO denemesi olabilir diye düşündük ama sonuna kadar izini süremedik. Sonunda Amazon IP aralıkları listesini periyodik olarak indirip hepsini engelleyen bir script yazdım ve konu kapandı

  • Anlıyorum. İnternetin büyük bir bölümünü kendi yaptığım şeyden duvarla ayırmak isteseydim ben de aynısını yapardım. Bu, koca ülkeleri engellemekten çok farklı değil
    Gürültüyü azaltıp sadece “küçük bir arkadaş grubuna” izin verme isteğini de anlıyorum
    Ama ben bunu tüm domain yerine yalnızca belirli hizmetler için yapıyorum. Mumble sunucumu sadece arkadaşlarımın bulunduğu 3-4 ülkeye açıyorum ve bulut sağlayıcılarını hariç tutuyorum. Teknik blogumu ise dünyanın her yerinden herkesin görebileceği şekilde bırakıyorum
    Ben paylaşılan bilginin herkesin yararına olduğuna güçlü biçimde inanıyorum. 300 baud C64 modem için modem başlatma dizgesine dair notlarım tek bir kişiye bile yardımcı olursa, o kişi benim yaşadığım acıyı tekrar yaşamaz ve dünya biraz daha iyi bir yer olur
    Çeşitli nedenlerle böyle bir istek duyulmasını anlayabiliyorum. Sorun değil. Herkes bildiğini yapsın

    • Yazdığım Zen InterSLIP Dialing Script kelimenin tam anlamıyla tüm dünyayı dolaştı
      Amazon, görmezden gelinemeyecek kadar büyük. ICMP ve SYN trafiğinin önemli bir kısmının çöp olduğunu anlıyorum. Ben de engellemeye yardımcı olmak isterim; zaten bazı önlemleri de varsayılan olarak elimde tutuyorum
      Sorun şu ki Amazon, azaltma önlemlerimi “ölçekli biçimde” dürtüp duran taraf olduğu için baş belası. Amazon, samanla buğdayı ayırmaya yardımcı olmuyor. Yaklaşımı, “ping sorunuyla ilgili PCAP gönderin” demekten ibaret
      Amazon’a veri gönderip hiç yanıt alamayınca öğrenilecek bir şey kalmıyor. İyi trafik de kötü trafik de, onlara saldıran sahte trafik de bana gerekli değil
      Onlar bana, onlara yardım etmem için yardımcı olmayacaklarsa, o zaman hiçbirine ihtiyacım yok. Sadece hayatımı basit tutuyorum

  • Böyle şeyleri görünce eski interneti özlüyorum. Ticarileşme öncesi internetin ne kadar harika olduğunu anlatmak gerçekten çok zor
    Bunun sonunun böyle geleceğini tam isabetle öngörmüş olmanın buruk hazzı, kaybedilen şeyin karşılığı olmaya hiç yetmiyor

    • Ah, doğru ya. Bu nostaljik bir saçmalık. İnternet en başından beri parayla ilgiliydi

  • AWS, DigitalOcean, OVHcloud, ColoCrossing, Scaleway, Tencent, hatta Google gibi yerlere kıyasla adeta izci çocuğu kalır
    Özellikle DigitalOcean'ın “siber güvenlik” topluluğuna pazarlama yapmasının korkunç bir hata olduğunu düşünüyorum

    • Aslında yazıyı okursanız “kavram kanıtı olarak bazı küçük ölçekli barındırma sağlayıcılarını engelledik” deniyor; bahsedilen tam olarak DigitalOcean. Sizin söylediğiniz nedenle

  • Çıkar ilişkisi beyanı: AWS şu anda işverenim
    Bariz bir şeyi kaçırıyor olabilirim ama yazar ping trafiğinin spoof edildiğine inanıyorsa bunun kaynağının AWS olduğunu nasıl bilebilir?

    • AWS'nin çok büyük miktarda kötüye kullanımın, kalitesiz scraper ve crawler'ların kaynağı olduğuna dair itibarı çok kötü. Kötü crawler'larla gerçek saldırıları ayırt etmek bazen zor olabiliyor
      Deneyimime göre ezici trafiğin AWS'den geldiği çok fazla durum gördüm ve bazı durumlarda çözüm yine aynı yere, yani AWS'nin tamamını engellemeye kadar vardı
      AWS'nin umursamamasından mı, yoksa yavaş yanıt vermesinden mi bilmiyorum. Belki de ihbarda bulunmak fazla zordur
      Gözden kaçan bariz nokta şu: AWS “kötü” trafiğin devasa bir kaynağı ve sorun çıkaran müşterileri durdurmak fazla zor; buna karşılık kötü niyetli aktörlerin saçma sapan kapasite kiralaması fazla kolay
      GCP ya da Azure'un aynı düzeyde çılgın trafik kaynağı olduğuna neredeyse hiç rastlamadım