top of page
Son Paylaşımlar
Tanıtılan Yazılar

Nic.tr’nin yaşadığı DDoS problemi

  • Alıntıdır.
  • 27 Ara 2015
  • 5 dakikada okunur

Bildiğiniz gibi, DoS ya da DDoS, bir sunucuya kapasitesinin üzerinde trafik göndermek ve bu şekilde servis kesintisi yaratmayı hedefleyen birkriminal(!) aktivite. 1Gbps lik bir bağlantıya, 1.1 Gbps lik bir trafik gelmesi, o bağlantıyı taşırır ve servis kesilir ya da yavaşlar. Bir noktadan gelirse DoS, birden fazla noktadan dağıtık bir trafik gelirse, DDoS diye adlandırılır.

Peki DDoS neden engellenemiyor(!)?

Ipv4 protokolünün bilinen tasarımsal sorunları var. Bunlardan birisi, bir noktadan diğerine giden trafiği hedefine ulaştıran yönlendiriciler, sadece ip paketinin hedef kısmına bakar. Siz kaynak ip paketinin kaynak kısmına istediğinizi yazabilirsiniz (ip spoofing) ve özel olarak önlem alınmadı ise (ki kimse almıyor) bu paket sorunsuzca hedefine ulaşır. Ufak bir script ile, bir sistemden ağa kablo hızına yakın miktarda, bu şekilde kaynak ip adresi rastgele manipüle edilmiş paketler atabilirsiniz. Karşı taraf sizden geldiğini hiçbir zaman bilemez.

TCP protokolünde spoof ip paketleri genelde SYN olarak gelir. Burada atağı yapanın hedefi, three-way-handshake için bekleyen bir sürü açık bağlantının, işletim sisteminin oturum tablosunu taşırmasıdır. Bu atağı önlemenin efektif bir yolu var. TCP bağlantıları, sistemin önünde konumlandırılan bir synproxy servisinde karşılanır ve three-way-handshake tamamlanmayan trafiğin sisteme erişimi önlenebilir.

Gelelim asıl şenliğin başladığı UDP protokolüne. UDP, tasarımı gereği TCP deki gibi bir doğrulama mekanizmasına sahip değil. Bir UDP ağa verilir ve hedefe ulaşıp ulaşılmadığı bilinemez. Hedef sunucu da, hiçbir zaman ip paketinde yazan kaynak ip adresinin doğruluğundan emin olamaz. Gönderen o kısma istediğini yazabilir. Bu nedenle DDoS için en çok kullanılan protokol UDP’dir. Internet trafiğinin vazgeçilmez bir parçası olan DNS sistemleri de, UDP üzerinden çalıştıkları için DDoS ataklarının en kolay hedefleridirler.

Şu zamana kadar anlattığım spoof edilen ip paketleri ile alakalı idi. Bir de gerçekten bu işi layıkı(!) ile yapanlar, yani botnet ağları var. Bunlar sizin bizim gibi kullanıcıların bilgisayarlarına, bir şekilde sızıp sessizce sahibinden komut bekleyen zararlı yazılımlardır. Siz internette kedi videosu seyrederken, torrentten indirip kullandığınız antivirüs yazılımınızdan bulaşan bir kod parçası, sizden habersiz birilerinin sistemine sayısız istek gönderebilir. Bu trafik gerçek bir istemciden geldiği için ,spoof trafiklerde kullanılan önlemler anlamsız kalır.

Herşeyden önce şunu belirtmek lazım. Savunmak kesinlikle saldırmaktan daha zor. Engellemek için bir çok yöntem var ama tek başına birini kullanmak kesin çözüm değil.Bu nedenle bu soruna sistematik bir şekilde önlem almak lazım.

Basitten zora doğru gidelim. İlk önce kolay kolay Ddos atağı yemeyecek kadar büyük kapasitelerde internet bağlantı kapasitemizin olması lazım. Bunun sonu yok tabi, ama maddi imkan ne ise sınır da o. Bu noktada kural “money talks”

İkinci olarak trafik kapasitemiz ne olursa olsun mümkün mertebe çok ISP ile çalışılması lazım. Çünkü ne kadar çok ISP ile komşuluk kurulursa, zararlı trafiğin asıl kaynağını tespit etmek de o kadar kolay olur. Örneğin, bolca BGP komşunuz varsa, URPF denen teknik ile spoof paketleri önlemek kolaylaşır. Bu noktada, ülkemizde bir IX(Internet eXchange) bulunmuyor olması da ayrı bir dezavantaj. 2013’de Spamhaus 300Gbps ile o zaman için bilinen en yüksek ddos atağın hedefi olmuştu. Cloudflare’in yardımı ile IX bağlantılarında bu atak süzülebilmişti.

Üçüncü olarak bu soruna özel olarak üretilmiş Ddos filtreleme ekipmanları kullanılabilir. Tabi bu cihazların kapasiteleri belirli olduğu için öncelikle atağın diğer yöntemler ile azaltılması şart. Arbor, Riorey, Radware v.s. gibi bu işe özel cihazlar piyasada sağlam fiyatlara alıcı bulmakta.

Nic.tr bu sıkıntıyı yaşamamak için ne yapmalıydı?

DNS servisi DDoS için en kolay hedef. İlk yapılması gerken DNS trafiğinin segmente edilmesi. Bu segmentasyonu Nic.tr round-robin DNS ile yapmak istemiş.

➜ ~ dig +trace pau.edu.tr ; <<>> DiG 9.8.3-P1 <<>> +trace pau.edu.tr ;; global options: +cmd . 983 IN NS a.root-servers.net. . 983 IN NS b.root-servers.net. . 983 IN NS c.root-servers.net. . 983 IN NS d.root-servers.net. . 983 IN NS e.root-servers.net. . 983 IN NS f.root-servers.net. . 983 IN NS g.root-servers.net. . 983 IN NS h.root-servers.net. . 983 IN NS i.root-servers.net. . 983 IN NS j.root-servers.net. . 983 IN NS k.root-servers.net. . 983 IN NS l.root-servers.net. . 983 IN NS m.root-servers.net. ;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 90 mtr. 172800 IN NS ns21.nic.tr. tr. 172800 IN NS ns22.nic.tr. tr. 172800 IN NS ns8.nic.tr. tr. 172800 IN NS ns41.nic.tr. tr. 172800 IN NS ns31.nic.tr. tr. 172800 IN NS ns7.nic.tr. tr. 172800 IN NS ns3.nic.tr. tr. 172800 IN NS ns42.nic.tr. ;; Received 309 bytes from 192.36.148.17#53(192.36.148.17) in 91 ms pau.edu.tr. 43200 IN NS dns1.pau.edu.tr. pau.edu.tr. 43200 IN NS dns2.pau.edu.tr. ;; Received 154 bytes from 31.210.155.2#53(31.210.155.2) in 381 ms pau.edu.tr. 38400 IN A 193.255.52.56 pau.edu.tr. 38400 IN NS dns1.pau.edu.tr. pau.edu.tr. 38400 IN NS dns2.pau.edu.tr. ;; Received 170 bytes from 193.255.52.50#53(193.255.52.50) in 44 ms

Görüldüğü üzere bir alan adı için yedi tane sunucu işaret ediyor ve dns sorguları rastgele (round-robin) bu yedi sunucudan birine gidiyor. Bu ilk bakışta iyi gibi görünse de, bunların hepsine birden atak gelmesi ihtimal dahilinde. Kolay uygulanan bir çözüm olduğu için ilk başvurulan bu yöntem olmuş. Ancak trafiği segmente etmek için yeterli değil. Trafiği segmente etmenin en etkili yolu anycast dns yapısı kullanmak. Anycast her tür internet servisi için kullanılabilen, standartları belirlenmiş bir prensip.

Anycast DNS sistemlerinde, birden fazla ağda bulunan, aynı IP adresini kullanan sunucular bulunur. İstemciler IP yönlendirme kuralları ile bunlardan birisine yönlendirilir. Bu sayede aynı IP adresini kullanan onlarca farklı ülkede DNS sunucunuz olabilir. Benim tespit ettiğim kadarı ile bu yazıyı yazdığım an itibari ile Nic.tr halen bu tekniği kullanmıyor. Örneğin ns7.nic.tr adresine istemciler nasıl ulaşıyor bakalım.

Aşağıdaki görüntü benim bilgisayarımın ns7.nic.tr’ye gittiği yol. ICMP paketleri engellendiği için son hopa kadar gitmiyoruz ama 7 numaralı hop bence nereye gittiğimiz konusunda yeterli.

Bu da aynı sunucuya, tracetoute servisi veren Kuzey Amerika’daki bir siteden erişim. 14 numaralı hop benim istemcimin gittiği yol ile aynı. Yani dünyanın her yerinden ns7.nic.tr adresine aynı yoldan gidiliyor.

Peki anycast olarak çalışan meşhur Google Public DNS çözücüsü 8.8.8.8 de bu test ne sonuç veriyor? Tahmin edebileceğiniz gibi farklı Bu benim istemcim.

Bambaşka rotalardan, ancak aynı IP adresine giden bir trafik mevcut.

Hepi topu 40Gbps uplinki ile tüm akademik kurumlara internet veren Ulaknet ağında birden fazla DNS sunucu tutmak, RIPE’ın verdiği ücretsiz DNS servisine sırtı dayamak, atak geldiğinde yurtdışına erişimi kapamak gibi anlamsız önlemlere başvurmak, kamuoyunu zamanında ve yeterli bilgilendirmemek, bence bu kriz ortamında hata olarak sayılabilecek diğer konular.

ODTÜ ve nic.tr, ülkemizi temsilen .tr uzantısını yönetiyor. Bu tip teknik konularda önceden önlem alıp uygulayan üçten fazla Türk tanıyorsanız, o zaman nic.tr hatalıdır Şaka bir yana, eleştirilecek çok yan olmasına rağmen bir çok konuda öncü kimliği ile, zamanında ülkemizde .tr alan adının kullanımı için elini taşın altına sokmuş ve kamu kurumu kimliği ile bu güne kadar getirmiş bir kurumun, bu kadar acımasız eleştirilmesinin arkasında başka niyetlerin olduğunu düşünüyorum ama bu başka bir konu.

Olaya iyi tarafından bakarsak, siber güvenlik konusunda farkındalığın artması için güzel bir fırsat. Bugünden sonra bu konuda hiçbirşey eskisi gibi olmayacak. Önümüzdeki en büyük zorluk ise uzman personel eksikliği. Nihayetinde dört yılda hem elektriği, hem de elektroniği öğretebileceğini düşünen mühendislik bölümleri olan bir ülkeden bahsediyoruz. Şimdilik ülkemizdeki durum aşağıdaki gibi olmaya devam edecek.


Comments


Bizi Takip Edin
Etiketlere Göre Ara
Arşiv
  • Facebook Basic Square
  • Twitter Basic Square
  • Google+ Basic Square
bottom of page