Biraz geç kalmış bir yazı olacak ancak temel internet teknolojilerini ilgilendirdiği için üzerinde düşünülmesi yararlı olacak bu konu üzerinde birkaç kelam etmek istedim. Bu olayın meydana geldiği sırada nöbetçi (oncall) olduğum için birinci elden neler yaşandığını tecrübe etme fırsatı buldum. Teknik terimleri çeviremediğim veyahut çevirdiğim zaman anlaşılamayacağını düşünerek terimleri olduğu gibi bıraktığım yerler mevcut. Bunlar için şimdiden kusura bakmayınız.
Hatırlarsanız 21 Ekim 2016 tarihinde aralarında Github, Twitter, Reddit, Spotify'ın bulunduğu birçok servis erişilemez hale geldi. Bunun temel sebebi Dynect'e yapılan DDoS saldırısı idi. Aslında saldırıları desem daha doğru olur zira ilk olarak sadece Amerika'nın doğusu etkilendi ve sonrasında ikinci saldırı ile birlikte dünya çapında Dynect erişilemez oldu. Bu saldırının Mirai adlı botnet tarafından gerçekleştirildiğini biliyoruz. Bu botnetin ya da saldırının arkasında kimlerin olduğu veya motivasyonlarının ne olduğu bilinmemekle birlikte bu saldırı aslında IoT cihazların ne kadar güvensiz olduğunu bizlere bir kez daha hatırlattı ve bu konuda bir düzenleme yapılması konusunda bilinci arttırdığını söyleyebiliriz.
Bu olayı daha iyi anlayabilmek için saldırıya uğrayan bu teknolojilere biraz değinelim.
DNS ve Anycast
Türkiye'deki internet sansüründen dolayı neredeyse herkes yüzeysel olarak DNS'in ne olduğunu biliyor. Hiçbir fikri olmayanlar için DNS'i kısaca "www.fazlamesai.net nerededir?" sorusuna cevap veren sunucu olarak özetleyebiliriz. Lakin bu olayı anlamamız için DNS konusunda biraz daha fikre sahip olmamız gerekmekte.
DNS tasarımı gereği dağıtık bir sistem ve bu dağıtık sistemin parçalarının yönetimi için diğer DNS sunucuları yetkilendirilmiş (delegation) durumda. Her DNS sunucusu kendisinin yönettiği bölge (zone) için otoriter (authoritative) ve otoriter olmadığı bölgeler için de hangi sunucu yetkilendirilmiş ise istemciyi oraya yönlendirmekte. Bu yetkilendirme NS kayıtları ile yapılmakta. NS kayıtlarının dışında A, MX, PTR, SRV gibi daha birçok kayıt tipi mevcut. Temeldeki çalışma prensibini "bu adresi ben bilmiyorum ama bunu bilecek sunucu şurada, ona bir sor" şeklinde özetleyebiliriz. www.wikipedia.org. 'u ele alırsak (sondaki noktaya dikkat), bölgeleri aşağıdaki şekilde özetleyebiliriz.
Bu bölgelerin her birini bölge dosyası (zone file) şeklinde ifade ediliyor. Root zone dosyasına isterseniz buradan ulaşabilirsiniz. Şimdi gelin www.wikipedia.org adresinin nasıl çözümlendiğine bakalım ve aşağıdaki grafiği yorumlayalım. Burada www.wikipedia.org için A kaydına ulaşmaya çalışıyoruz.
(kaynak: wikipedia)
Bu adrese ulaşmaya çalıştığınız zaman DNS çözümleyiciniz (resolver) aslında 1 adet sorgu değil 3 adet sorgu göndermekte [1]. İlk olarak kök DNS sunucusuna bu istek gönderiliyor.
-> % dig @a.root-servers.net www.wikipedia.org A
;; AUTHORITY SECTION:
org. 172800 IN NS a0.org.afilias-nst.info.
org. 172800 IN NS a2.org.afilias-nst.info.
org. 172800 IN NS b0.org.afilias-nst.org.
org. 172800 IN NS b2.org.afilias-nst.org.
org. 172800 IN NS c0.org.afilias-nst.info.
org. 172800 IN NS d0.org.afilias-nst.org.
;; ADDITIONAL SECTION:
a0.org.afilias-nst.info. 172800 IN A 199.19.56.1
...
...
Buradan istediğimiz cevap olan A kaydını alamadık ancak bize sonraki aşamada nereye soracağımızı söyledi. Org DNS sunucusundan bir tanesine tekrar bu soruyu soralım.
-> % dig @a0.org.afilias-nst.info www.wikipedia.org A
;; AUTHORITY SECTION:
wikipedia.org. 86400 IN NS ns2.wikimedia.org.
wikipedia.org. 86400 IN NS ns1.wikimedia.org.
wikipedia.org. 86400 IN NS ns0.wikimedia.org.
;; ADDITIONAL SECTION:
ns0.wikimedia.org. 86400 IN A 208.80.154.238
ns1.wikimedia.org. 86400 IN A 208.80.153.231
ns2.wikimedia.org. 86400 IN A 91.198.174.239
Yine istediğimizi alamadık. Önceki sefer olduğu gibi nereye soracağımızı gösterdi.
-> % dig @ns0.wikimedia.org www.wikipedia.org A
;; ANSWER SECTION:
www.wikipedia.org. 600 IN A 91.198.174.192
Bu sefer aradığımız kaydı bulduk. Gördüğünüz gibi aslında hiçbir şey bilmeden, sadece kök sunucudan başlayarak istediğimiz kaydı bulabildik. DNS çözümleyici de tam olarak bunları gerçekleştirerek bize istediğimiz kaydı döndürmekte. Tüm bu takip ettiğimiz zincire yetkilendirme kümesi (delegation set) denmekte. İstenirse wikipedia.org altında başka bölgeler olabilir ve bu bölgelerin yönetimi başka DNS sunucusuna verilebilir.
Bu noktada kullandığımız çözümleyici kök sunucuyu nasıl bulacak diye merak etmekte haklısınız. Bu işlemin başlayabilmesi için kök sunucu adreslerinin öncesinde bilinmesi gerekmekte. Bu genel olarak kullandığınız çözümleyici sunucusunun kodu içerisinde sabit olarak tanımlanıyor ve bütün kök DNS sunucu adreslerinin bulunduğu dosya ile birlikte yayınlanıyor.
Buraya kadar sabredip okuduysanız artık temel konseptlere alışkınız. Bir sonraki aşama olarak Anycast ile isim sunucularının etkileşimini ele alacağız. İsim sunucusu yönetmek için Anycast'e ihtiyacınız yok ancak orta ve büyük ölçekte isim sunucusu altyapısına sahipseniz kullanacağınız temel teknik bu. Amazon Route 53, Dynect, UltraDNS, NS1 gibi servislerin altyapıları anycast üzerine kurulu.
Anycast
(kaynak: http://pingbin.com/2011/03/what-is-any-cast-dns/)
Anycast'i aynı adrese sahip birden fazla cihazın ağ içerisinde bulunması ve cihazlara erişmek istediğimiz zaman routerların gönderdiğimiz paketleri bize en yakın cihaza ulaştırması olarak özetleyebiliriz. Yani Türkiye'den ulaştığınız Google DNS sunucusu (8.8.8.8) ile İrlanda'dan ulaştığınız sunucu aynı yerde değil. Bunu traceroute ile görebiliriz:
-> % mtr --report-wide -b 8.8.8.8
Start: Fri Jan 13 16:14:39 2017
HOST: zion Loss% Snt Last Avg Best Wrst StDev
1.|-- ec2-79-125-xxx-xxx.eu-west-1.compute.amazonaws.com 0.0% 10 14.8 15.5 12.4 20.2 2.3
2.|-- 100.64.0.14 0.0% 10 15.4 16.4 11.8 22.3 2.9
3.|-- 100.64.0.5 0.0% 10 10.0 141.9 7.1 993.9 313.7
4.|-- 100.64.17.5 0.0% 10 0.6 1.1 0.5 6.0 1.6
5.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
6.|-- ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
7.|-- 52.93.7.132 0.0% 10 3.3 4.4 2.7 15.1 3.7
8.|-- 52.93.7.37 0.0% 10 1.2 1.2 1.1 1.3 0.0
9.|-- 72.14.204.244 0.0% 10 1.2 1.4 1.0 3.8 0.7
10.|-- 209.85.250.213 0.0% 10 1.4 1.5 1.3 2.4 0.0
11.|-- google-public-dns-a.google.com (8.8.8.8) 0.0% 10 1.0 1.1 0.9 1.5 0.0
Burada gördüğümüz gibi İrlanda'da bulunan EC2 makinesinden 8.8.8.8 adresine ulaşmak istediğimizde gönderdiğimiz paket EC2 ağından çıkıp Google ağına giriyor ve 1ms'den kısa bir sürede Google DNS sunucusuna ulaşıyor (8. ve 9. kısım). Bu da Amazon ve Google arasında bir peering anlaşmasının olduğunu göstermekte.
Türkiye'den baktığımız zaman ise aynı adrese gönderilen paket şöyle bir yol izlemekte:
1. server-31.210.xxx.xxx 0.0% 10 1.3 1.4 1.2 1.8 0.2
2. 10.20.30.213 0.0% 10 1.1 1.7 0.4 8.3 2.6
3. 10.20.20.49 0.0% 10 2.7 0.8 0.3 2.7 0.7
4. 195.175.208.141.static.turkt 0.0% 10 0.8 1.5 0.8 4.3 1.2
5. 212.156.251.124.static.turkt 0.0% 10 1.0 0.9 0.8 1.1 0.1
6. 195.175.174.55.00-ebgp-gayre 70.0% 10 1.3 42.9 1.3 126.2 72.1
7. ??? 100.0 10 0.0 0.0 0.0 0.0 0.0
8. 74.125.51.92 0.0% 10 93.4 98.7 93.4 103.5 3.8
9. 216.239.47.163 0.0% 10 51.1 51.0 50.9 51.1 0.1
10. 216.58.215.173 0.0% 10 55.6 56.1 55.5 60.2 1.4
11. google-public-dns-a.google.c 0.0% 10 47.9 47.9 47.7 48.0 0.1
Paketin Türk Telekomdan çıktığını ve Google ağına girdiğini görüyoruz. Maalesef 7. aşamadaki sunucunun ne olduğunu göremiyoruz ancak Türk Telekomun yurtdışı çıkışı için kullandığı servis sağlayıcılardan bir tanesi olması muhtemel.
Bu adreslere ulaşırken hangi yolun takip edileceği BGP ile belirleniyor. Anycast altyapısına sahip şirketler, BGP duyuruları ile hangi ağdaki kullanıcıların nereye ulaşacaklarını belirliyor. Örneğin Türk Telekom ağından çıkan bir paket için en yakın varış noktası Almanya olarak ayarlanmış olabilir. İlerde Türkiye'de sunucu barındırmaya başlandığında BGP duyurularını değiştirip paketlerin direkt Türkiye'deki sunucuya göndermelerini sağlayabilirler. Bu esnekliğin operatör açısından avantajı ise herhangi bir hata anında, o noktadaki sunuculara istek gönderen kullanıcıları kesinti olmaksızın başka POP noktasına yönlendirerek hizmetin devamlılığını sağlamak.
Anycast'in sağladığı bir diğer avantaj ise herhangi bir saldırı anında, saldırının kaynağına en yakın sunucuların etkilenmesi ve saldırının diğer noktalara ulaşmaması. Saldırgan kullandığı ağı kontrol edemediği için, ağ yapılandıması neyi gösteriyor ise o sunuculara ulaşacak ve diğer noktalar etkilenmeyecektir.
Global Anycast DNS altyapısını tamamiyle servis dışı bırakmak dünyanın birçok kıtasında yeterince büyük bir botnet'e sahip olmanız ve nereye saldıracağınızı biliyor olmanız gerekmekte.
Dynect Saldırısı
Temel konseptlere değindiğimize göre Dynect saldırısında ne yaşandığndan bahsedebiliriz. Şu adresten görebileceğiniz gibi Dynect dünyanın birçok noktasındaki sunucularla global Ancyast altyapısına sahip.
21 Ekim 2016 saat 12:00 UTC civarında saldırı başladı ve bu saldırı sadece Amerikanın Doğu kısmında etkili oldu. Yukarıda bahsedildiği gibi Anycast altyapısından dolayı sadece bu bölgedeki istemciler Dynect sunucularına erişemedi ve diğer bölgelerden gelen isteklerde herhangi bir sorun oluşmadı.
(lk saldırı sırasında Dynect sunucularının görünümü. Kaynak: http://thehackernews.com/2016/10/dyn-dns-ddos.html)
Birkaç saat içerisinde ilk saldırının önüne geçilse de akşam saatlerinde ikinci bir saldırı ile Dynect özellikle Avrupa ve Amerika olmak üzere dünyanın birçok yerinde erişilemez hale geldi. Bana kalırsa bu saldırı öncelikle Amerikanın doğusunda denendi, saldırı ile nasıl başa çıkıldığı görüldü ve sonrasında bütün Dynect sunucularına saldırı başlatıldı. Komplo teorisi olarak değerlendirilebilir ancak amacımın bu olmadığını belirterek bu noktada Bruce Schneier 'in Birileri İnterneti Nasıl Kapatacağının Yollarını Öğreniyor başlıklı blog girdisini araya sıkıştırayım.
(İkinci saldırı sırasında Dynect sunucularının görünümü. Kaynak: http://www.zdnet.com/article/dyn-ddos-part-2-the-hackers-strike-back/)
Dynect'in yaptığı resmi açıklama saldırının olduğu sırada milyonlarca IP adresinden istek geldiği belirtilmekte ancak bu milyonlarca botnet olduğu anlamına gelmiyor. Botnet milyonlarca IP adresinin sadece ufak bir kısmını oluşturuyor. Geri kalan istekler normal kullanıcıların gönderdiği istekler. Bu durum isim çözümleme sırasında sunucuların davranışından kaynaklanmakta. Eğer çözümleme sırasında isim sunucusu ulaşılamıyor ve cevap olarak SERVFAIL dönüyorsa, isim sunucusu hiçbir şekilde beklemeden bu isteği tekrar tekrar gönderiyor. Dynect kullanan birçok servis olduğu için, DNS sunucuları cevap alamadığından bu saldırıya katkıda bulunuyor. Buradan şu sonucu çıkarabiliriz: eğer bir DNS servisini TTL boyunca ulaşılamaz hale getirirseniz, diğer bütün DNS sunucuları DDoS saldırısına katkı verir biçimde davranmakta. Bu TTL süreleri serivisi kullananların ihtiyaçlarına göre değişmek ile birlikte genel olarak 15 dakika ile 1 saat arasında tutuluyor. Eğer kayıtlarınız çok sık değişmiyor ise 24 saate kadar çıkabiliyor.
Mirai
IoT cihazları ele geçirip bunları çeşitli amaçlarla kullanan Mirai botneti saldırının ana sorumlusu. İnternete bağlı bu küçük cihazların büyük bir çoğunluğunun yönetim arayüzleri (ssh, telnet vs) dışarıya açık ve yönetici parolaları değiştirilmiyor. Mirai, bütün interneti tarayıp bulduğu cihazlara belirli kullanıcı adı ve parola kombinasyonu ile girmeyi deniyor ve başarılı olursa cihazı ele geçiriyor. Dahası, bir sonraki kişinin ele geçirmemesi için yönetim arayüzlerini dışarıya kapatıyor. Temel olarak çalışma biçimini bu şekilde özetleyecek olsam da botnet bundan daha fazla özelliğe sahip.
Mirai hakkında daha detaylı bilgiye bu adresten ve bu botnetten etkilenen KrebsOnSecurity bloğundan ulaşabilirsiniz.
Neden Birçok Servise Erişilemedi?
Bunun sebebi basit. Eğer isim sağlayıcısı olarak sadece Dynect kullanıyor iseniz, Dynect'in çalışmadığı zaman servisleriniz çözümlenemediği için bunlar çalışmayacak. Bir nevi Dynect yenildiği için siz de yenilmiş sayılıyorsunuz.
Önceki bölümde TTL teriminden bahsetmiştim. TTL, Time To Live anlamına geliyor ve her DNS cevabı içerisinde bu değer gönderiliyor. TTL, cevabı alan DNS sunucusuna bu cevabın saniye cinsinden ne kadar süre önbellekte (cache) tutulabileceğini belirtmekte. Dolayısıyla, herhangi bir kayıt bir kere sorulduktan ve önbelleğe alındıktan sonra, TTL süresince bu kayıt için tekrar sorgulama yapılmıyor ve önbellekten veriliyor. TTL bittiği zaman otoriter sunucuya tekrar bu sorgu gönderilerek işlem tekrarlanıyor. Eğer bu aşamada otorite sunucusu cevap vermez ise servisiniz doğal olarak erişilemez hale geliyor.
Ne Yapmalı?
Tek bir DNS servisi kullanmak yerine 2 veya daha fazla DNS servisi kullanmak problemi büyük oranda çözecektir (multi-homed). Her iki servis sağlayıcının aynı anda çalışmaması olasılık dahilinde olsa da bu olasılık düşük. Örnek verecek olursam Amazon Dynect ve UltraDNS kullanıyor. Amazon bu saldırıdan çok az etkilendi. Saldırının olduğu sırada us-east-1 sadece Dynect kullanıyordu. Dolayısıyla bu bölge saldırıdan kısa bir süre etkilendi ancak sonrasında UltraDNS eklenerek problem giderildi.
-> % dig ns us-east-1.amazonaws.com
us-east-1.amazonaws.com. 332 IN NS ns2.p31.dynect.net.
us-east-1.amazonaws.com. 332 IN NS ns4.p31.dynect.net.
us-east-1.amazonaws.com. 332 IN NS u1.amazonaws.com.
us-east-1.amazonaws.com. 332 IN NS u3.amazonaws.com.
us-east-1.amazonaws.com. 332 IN NS u4.amazonaws.com.
us-east-1.amazonaws.com. 332 IN NS pdns1.ultradns.net.
us-east-1.amazonaws.com. 332 IN NS u2.amazonaws.com.
us-east-1.amazonaws.com. 332 IN NS pdns5.ultradns.info.
us-east-1.amazonaws.com. 332 IN NS u6.amazonaws.com.
us-east-1.amazonaws.com. 332 IN NS pdns3.ultradns.org.
us-east-1.amazonaws.com. 332 IN NS u5.amazonaws.com.
us-east-1.amazonaws.com. 332 IN NS ns1.p31.dynect.net.
us-east-1.amazonaws.com. 332 IN NS ns3.p31.dynect.net.
Sonuç
Bu saldırı temel internet teknolojilerinden biri olan DNS'in ne kadar önemli olduğunu ve güvensiz IoT cihazlarının bir araya geldiklerinde neler yapabileceğiniz gösterdi. Bu problemin temel çözümü IoT cihazların daha güvenli hale getirilmesinden geçiyor ve bu konudaki regülasyon eksikliği tartışılmaz bir gerçek. Umarım ilerleyen zamanlarda IoT cihazların güvenliği konusunda regülasyon değişikliğine gidilir ve şirketler bu cihazların güvenliğini sağlamaya zorlanır. O vakte kadar DNS altyapısını tek bir servise emanet etmek yerine birden fazla servis kullanmak akıllıca bir çözüm olacak.
[1]: İşin içerisine caching vs. giriyor tabi ki ancak şimdilik bunu es geçerek π = 3 diyelim. Normalde root sunucularından başlayarak delegation set takip edilerek kayıt bulma işi 1 kez yapılıyor ve TTL süresince cacheleniyor. Bir sonraki sefer aynı kayıt sorulduğu zaman cache içerisinde varsa direkt cevap veriliyor, yoksa bu süreç tekrarlanıyor.
Eline saglik, epey keyifli ve doyurucu bir yazi olmus.