Ciddi Güvenlik: BELİRLENMİŞ TIPO'LAR DNS GÜVENLİĞİNİ NASIL İYİLEŞTİREBİLİR?

Yıllar boyunca, biz yazılı ve konuşulan DNS'nin çetrefilli sorunu hakkında birçok kez Naked Security'de uçak kaçırma.

DNS, muhtemelen bildiğiniz gibi, kısaltmasıdır. Alan Adı Sistemive sık sık internetin "telefon rehberi" veya "gazetteer" olarak tanımlandığını duyacaksınız.

Eğer kelimeye aşina değilseniz gazeteci, baktığınız bir atlasın arkasındaki dizine atıfta bulunur, örneğin, Monrovia, Liberya uygun bir alfabetik listede ve şöyle bir şey söylüyor 184 - C4. Bu size doğrudan 184. sayfaya dönmenizi ve haritanın üst kısmındaki C harfinden aşağıya ve soldaki 4 rakamının karşısındaki ızgara çizgilerini takip etmenizi söyler. Hatların buluştuğu yerde Monrovia'yı bulacaksınız.

Çoğu kullanıcı için, çoğu DNS araması bir sunucu adı içerir ve A kaydı veya AAAA kaydı olarak bilinenleri içeren bir yanıtın geri gelmesini ister.

(A kayıtları, örneğin 32 bit IPv4 internet numaraları için kullanılır. 203.0.113.42; AAAA kayıtları, 128 bit IPv6 adresleri için eşdeğer yanıtlardır, örneğin 2001:db8:15a:d0c::42 – bu makalede, yalnızca A kayıtlarını ve IPv4 numaralarını kullanacağız, ancak her iki durumda da arama işlemi için aynı güvenlik sorunları geçerlidir.)

İşte hayali alan adını aradığımız bir örnek naksec.test DNS trafiğini izlemek ve size öğretmek için özel olarak oluşturulmuş bir DNS sunucusu aracılığıyla.

Eski okul Linux aracını kullandık digiçin kısa etki alanı internet korsanı, basit bir DNS isteği oluşturmak için (dig A-kayıtlarını aramak için varsayılanlar) istediğimiz sunucu için:

$ dig +noedns @127.42.42.254 naksec.test ;; SORU BÖLÜMÜ: naksec.test. İÇİNDE ;; CEVAP BÖLÜMÜ: NAKSEC.TEST. 5 IN A 203.0.113.42 ;; Sorgu süresi: 1 msn;; SUNUCU: 127.42.42.254#53(127.42.42.254) (UDP) ;; NE ZAMAN: 23 Ocak Pazartesi 14:38:42 GMT 2023 ;; MSG BOYUTU rcvd: 56

DNS sunucumuzun, gelen isteğin onaltılık bir dökümünü ve geri dönen başarılı yanıtı göstererek, isteği nasıl ele aldığı aşağıda açıklanmıştır:

---> 127.0.0.1:57708'den 127.42.42.254:53'e istek ---> 00000000 62 4e 01 20 00 01 00 00 00 00 00 00 06 6e 61 6b |bN. .........nak| 00000010 73 65 63 04 74 65 73 74 00 00 01 00 01 |sn.test..... | DNS araması: naksec.test için A kaydı ==> A=203.0.113.42 <--- 127.42.42.254:53'ten 127.0.0.1:57708'e yanıt <--- 00000000 62 4e 84 b0 00 01 00 01 00 00 00 00 06 6e 61 6b |bN...........nak| 00000010 73 65 63 04 74 65 73 74 00 00 01 00 01 06 4e 41 |sn.test......NA| 00000020 4b 53 45 43 04 54 45 53 54 00 00 01 00 01 00 00 |KSEC.TEST.......| 00000030 00 05 00 04 cb 00 71 2a |......q* |

Performans nedenleriyle çoğu DNS isteğinin UDP kullandığını unutmayın. Kullanıcı Datagram Protokolü, gönder ve umut et esasına göre çalışır: konuşmak istediğiniz sunucuda bir UDP paketini ateşlersiniz ve ardından bir yanıt gelip gelmediğini görmek için beklersiniz.

Bu, UDP'yi büyük kuzeni TCP'den çok daha basit ve hızlı hale getirir. Geçiş kontrol protokolü, adından da anlaşılacağı gibi, UDP'nin ilgilenmediği birçok ayrıntıyı otomatik olarak halleder.

Özellikle, TCP, verilerin kaybolduğunu tespit etmek ve tekrar istemekle ilgilenir; herhangi bir veri parçasının doğru sırayla ulaşmasını sağlamak; ve bir kez kurulduktan sonra aynı anda gönderme ve alma için kullanılabilen tek bir ağ bağlantısının sağlanması.

UDP'nin bir "bağlantı" kavramı yoktur, bu nedenle istekler ve yanıtlar temelde bağımsız olarak hareket eder:

• DNS sunucusuna bir DNS isteği geldiğinde kendi başına bir UDP paketinde.
• DNS sunucusu bir kayıt tutar hangi bilgisayarın söz konusu paketi gönderdiği.
• Sunucu, geri göndermek için bir yanıt bulmaya başlar, ya da olmadığına karar vermek.
• Sunucu bir yanıt gönderir ikinci bir UDP paketi kullanarak orijinal gönderene.

İşletim sistemi veya ağ seviyesinden, yukarıdaki iki UDP paketi bağımsız, tek başına iletimlerdir - aynı dijital bağlantının parçası olarak birbirine bağlı değildirler.

Her yanıtın hangi istemciye gönderileceğini hatırlamak sunucuya kalmıştır; ve hangi yanıtların başlangıçta gönderildiği isteklerle ilgili olduğunu anlamak müşteriye kalmıştır.

Nasıl emin olabilirsin?

Bu noktada, özellikle yukarıdaki DNS isteğinin ve yanıtının küçücük boyutuna baktığınızda muhtemelen şunu merak ediyorsunuz: "Müşteri, aktarım sırasında bozulan veya yanlış yönlendirilen yanıtla değil, doğru yanıtla eşleştiğinden nasıl emin olabilir? yanlışlıkla mı, kazara mı yoksa tasarımla mı?”

Ne yazık ki, çoğu olmasa da çoğu DNS isteği (özellikle sunucudan sunucuya, sorduğunuz ilk sunucu yanıtı bilmediğinde ve yanıtını formüle etmek için bilen birini bulması gerektiğinde) şifreli değildir veya aksi takdirde herhangi bir tür kriptografik kimlik doğrulama koduyla etiketlenir.

Aslında, varsayılan olarak, DNS istekleri tek bir "tanımlama etiketi" içerir; bu, DNS veri biçimi belgelerinde kısaca şu şekilde adlandırılır: ID.

Şaşırtıcı bir şekilde, yıllar içinde çok sayıda güncelleme almasına ve önerilen iyileştirmelere rağmen, resmi internet RFC'si (yorum isteği) DNS özelliği olarak işlev gören belge hala RFC 1035 (şu anda 9000'lerin ortalarındaki RFC'lere giriyoruz), 1987 yıldan biraz daha uzun bir süre önce, Kasım 35'ye kadar uzanan bir geçmişe sahibiz!

O zamanlar hem bant genişliği hem de işlem gücü yetersizdi: tipik CPU hızları yaklaşık 10 MHz idi; masaüstü bilgisayarlarda yaklaşık 1 MByte RAM vardı; Hiç çevrimiçi olabilen kuruluşlar için internet erişim hızları genellikle 56 kbit/sn veya 64 kbit/sn idi ve herkes tarafından paylaşıldı; ve 1200 bit/sn, günün çevirmeli modemleri aracılığıyla kişisel bağlantı için uygun fiyatlı bir seçimdi.

Bu nedenle, DNS istek ve yanıt başlıkları, RFC 12'in sevimli özelliği olarak, kimlik etiketinin ilk ikisini aldığı 1035 bayta sıkıştırıldı ve hala sıkıştırılıyor. ASCII sanatı netleştirir:

 1 1 1 1 1 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+--+--+--+--+--+--+--+--+ --+--+--+--+--+--+--+ | kimlik | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QR| İşlem kodu |AA|TC|RD|RA| Z | RCODE | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | QDCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | HESAP | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | NSCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | ARCOUNT | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

Hem istek hem de yanıt paketlerinin aynı iki karakterle başladığı yukarıda gösterilen onaltılık dökümlerde kimliği çalışırken görebilirsiniz. bN16 bit tanımlayıcıya karşılık gelen 62 4e altıgen olarak

Çok kabaca söylemek gerekirse, bu 16 bit, resmi DNS protokolünün "kimlik doğrulama" veya "hata tespiti" yoluyla sağladığı kadardır.

Tahmin yoluyla karışma

Tahmin edebileceğiniz gibi, normal DNS trafiğinin uçtan uca basitliği göz önüne alındığında, sözde orta kutu or tarama proxy'si ağ trafiğinizi kim durdurabilir, inceleyebilir ve değiştirebilir, DNS trafiğinize önemsiz bir şekilde karışabilir.

Buna, BT ekibinizin sizi kötü amaçlı yazılımlarla dolu olduğunu bildiği sunuculardan başka bir yere yönlendirmesi gibi, size kasıtlı olarak yanlış bilgiler veren yanıtların geri gönderilmesi de dahildir.

Ayrıca, ISP'nizin, çocuk istismarı materyali gibi yasa dışı içeriğin engellenenler listesinde yer alması nedeniyle, bazı sunucuların çalışır durumda ve düzgün çalışıyor olsalar bile, varolmayan olarak bildirilmesini gerektiren ülkenizdeki mevzuata uymasını da içerebilir.

Ancak, ilk bakışta, bu aşırı zayıf DNS kimliği etiketleme türü aynı zamanda onu önemsiz kılıyor gibi görünüyor. ağ trafiğinizi hiç göremeyen saldırganlar için bile kullanıcılarınıza veya sunucularınıza sahte DNS yanıtları göndermek için…

...tehlikeli derecede yüksek bir başarı şansı ile.

Ne de olsa, saldırganlar ağınızdaki birinin düzenli olarak ziyaret etmeyi sevdiğini bilirse naksec.test, bu sunucu sahte haberler, tehlikeli güncellemeler veya hileli JavaScript kodu yerleştirmek için cazip bir yer gibi görünebilir.

Saldırganlar sisteme giremezse naksec.test "A-kaydı ne için? naksec.test"?

Bu şekilde, DNS isteğini ele geçirebilir, sahte bir yanıt verebilir ve bu nedenle web sitesine bir sonraki ziyaretinizi yanlış yönlendirebilirler – esasen siteye saldırmaya gerek kalmadan sitenin kendisini ele geçirebilirler. naksec.test sunucu hiç.

Biraz şans gerekli

Elbette biraz şanslı olmaları gerekir, ancak genel şanslarını artırmak için tekrar tekrar deneyebilirler, çünkü yalnızca bir kez başarılı olmaları gerekirken sizin her seferinde doğru bir DNS yanıtı almanız gerekir.

Başarılı olmak için hileli DNS yanıtlarını göndermeleri gerekir:

• Kendi sunucunuzun olduğu bir dönemde sorunun cevabını zaten bilmiyordunuz. DNS yanıtları, TTL olarak adlandırılan 32 bitlik bir sayı içerir; yaşama zamanı, bu, diğer ucun yanıtı yeniden kullanmaya ne kadar devam edebileceğini söyler. Siz veya ytour ağınızdaki herhangi biri sorarsa naksec.test son zamanlarda, DNS sunucunuzun yanıtı önbelleğinde olabilir. Daha fazla aramaya gerek kalmayacak ve saldırganların kaçırması için giden bir talep olmayacaktı.
• Talebinizi ilettiğiniz saat ile dışarıdan resmi cevap geldi. Eski günlerde bile, DNS arama süreleri nadiren birkaç saniyeyi aşardı. Bugün, en iyi şekilde milisaniye cinsinden ölçülürler.
• İlk 16 bitinde doğru sayı ile. 65536 (2¹⁶) 16 bite farklı değerler, bu nedenle saldırganların biraz şanslı olması gerekir. Ancak günümüzün ağ bant genişliklerinde, aynı anda 65536 farklı sahte yanıt göndermek, böylece olası tüm kimlik numaralarını kapsamak saniyenin çok küçük bir kısmını alıyor.

Neyse ki, düzgün DNS sunucuları bugün varsayılan olarak ele geçirmeyi zorlaştırmak için fazladan bir adım atıyor.

En azından 2008'den beri yaptıkları şey bu. merhum Dan Kaminsky o zamanlar pek çok DNS sunucusunun yalnızca sabit bir UDP bağlantı noktasında (neredeyse her zaman resmi olarak DNS'ye atanmış 53 numaralı bağlantı noktası) gelen istekleri dinleyecek şekilde yapılandırılmadığına dikkat çekti…

…aynı zamanda trafikte hoş bir simetri oluşturmak için sabit bir bağlantı noktasından gelen yanıtları da almak için, genellikle 53 numaralı bağlantı noktasından da.

Her iki yönde de sabit bir bağlantı noktası kullanmanın nedeni muhtemelen başlangıçta programlama basitliğiydi. Her zaman aynı UDP bağlantı noktası numarasındaki yanıtları dinleyerek, hangi yanıtlar için hangi bağlantı noktalarının açılması gerektiğini takip etmenize gerek kalmaz. Bu, DNS yazılımınızın istek işleyicisi ve yanıt oluşturucu bileşenlerinin bağımsız olarak çalışabileceği anlamına gelir. İstek dinleyicisinin yanıt gönderene "Bu belirli yanıtın normal bağlantı noktasına değil, özel bir bağlantı noktasına geri dönmesi gerekiyor" demesine gerek yoktur.

Ek kimlik olarak bağlantı noktası numaralarını kullanın

Bu günlerde, neredeyse tüm UDP tabanlı DNS sunucuları, her zaman olduğu gibi 53 numaralı bağlantı noktasını dinliyor, ancak DNS isteğinde bulunan tarafından kullanılan ve rastgele seçilmesini beklediği sözde "kaynak bağlantı noktası" nın izini sürüyorlar.

Eski tarz bir ofis telefon santralindeki bir "dahili numara"ya benzeyen UDP kaynak bağlantı noktalarının, istekleri birbirinden ayırmanıza ve ağa yardımcı olmak için kullanılması amaçlanmıştır.

İnternet protokolü bağlantı noktaları (TCP de bunları kullanır) 1 ile 65535 arasında çalışabilir, ancak çoğu giden bağlantı yalnızca 1024-65535 kaynak bağlantı noktalarını kullanır, çünkü 1023 ve altındaki bağlantı noktası numaraları genellikle sistem ayrıcalıklarına sahip işlemler için ayrılmıştır.

Buradaki fikir, herhangi bir DNS aramasının göndericisinin her isteğin başına yalnızca gerçekten rastgele bir 16 bitlik kimlik eklemesi değil, aynı zamanda ilişkili yanıtı dinleyeceği gerçekten rastgele bir UDP kaynak bağlantı noktası numarası seçmesi gerektiğidir.

Bu, dolandırıcıların yukarıdaki "şansı kaçırma" listelerine eklemeleri gereken, yani tüm bu kutuları işaretleyen sahte bir yanıt göndermeleri gereken ekstra bir tahmin düzeyi ekler:

• Son zamanlarda sorulan bir sorgu olmalı, genellikle son birkaç saniye içinde.
• Yerel sunucunun önbelleğinde olmayan bir arama olmalı, tipik olarak, son birkaç dakika içinde kimsenin bunu sormadığı anlamına gelir.
• Doğru 16 bitlik kimlik numarasına sahip olmalıdır veri paketinin başlangıcında.
• Doğru hedef bağlantı noktasına gönderilmelidir ilgili sunucunun IP numarasında.

Bir şey daha

Aslında, DNS talep edenlerin temel DNS protokolünü değiştirmeden ve dolayısıyla (çoğunlukla) hiçbir şeyi bozmadan yapabileceği başka bir numara daha var.

Bu numara, şaşırtıcı bir şekilde, ilk önerilen 2008 yılında, şanlı bir şekilde başlıklı bir gazetede 0x20-Bit Kodlama Sayesinde Artırılmış DNS Sahteciliği Direnci: LeET Sorgularıyla GÜVENLİK.

Fikir garip bir şekilde basit ve DNS protokolündeki iki ayrıntıya dayanıyor:

• Tüm DNS yanıtları başlangıçta orijinal sorgu bölümünü içermelidir. Açıkçası, sorguların boş bir yanıt bölümü vardır, ancak yanıtların orijinal soruyu yansıtması gerekir, bu da istekler ve yanıtların yanlışlıkla karışmamasını sağlamaya yardımcı olur.
• Tüm DNS soruları büyük/küçük harfe duyarlı değildir. ister iste naksec.testya da NAKSEC.TESTya da nAksEc.tESt, aynı cevabı almalısınız.

Şimdi, protokolde, yanıtın orijinal sorguyu tekrarladığınız bölümünde aynı hecelemeyi KULLANMANIZ GEREKİR diyen hiçbir şey yok, çünkü DNS büyük/küçük harfe önem vermiyor.

Ancak RFC 1035, büyük/küçük harfe duyarsız karşılaştırmalar yapmanızı gerektirse de, aslında durumu değiştirme isteklerde aldığınız veya yanıtlarda kullanmak üzere kendi veritabanlarınızdan aldığınız herhangi bir metin adının.

Başka bir deyişle, bir talep alırsanız nAKsEC.tESTve veritabanınız şu şekilde depolanmıştır: NAKSEC.TEST, o zaman bu iki ad yine de aynı kabul edilir ve eşleşir.

Ancak yanıtınızı formüle ettiğinizde RFC 1035, cevabınıza eklediğiniz verilerin büyük/küçük harf durumunu değiştirmeyin, DNS tarafından talep edilen büyük/küçük harfe duyarsız karşılaştırma sayesinde daha düzgün görüneceğini düşünseniz ve diğer uçta yine de eşleşecek olsa da.

Dolayısıyla, bir DNS isteğini göndermeden önce harflerin büyük/küçük harf durumunu rastgele karıştırırsanız, çoğu DNS sunucusu, burada gördüğünüz gibi, kendi veritabanları sunucunun adını farklı bir şekilde depolasa bile, bu tuhaf harf karışımını sadık bir şekilde yansıtacaktır. :

$ dig +noedns @127.42.42.254 nAkSec.tEsT ;; SORU BÖLÜMÜ: ;nAkSec.tEst. İÇİNDE ;; CEVAP BÖLÜMÜ: NAKSEC.TEST. 5 IN A 203.0.113.42 ;; Sorgu süresi: 1 msn;; SUNUCU: 127.42.42.254#53(127.42.42.254) (UDP) ;; NE ZAMAN: 23 Ocak Pazartesi 14:40:34 GMT 2023 ;; MSG BOYUTU rcvd: 56

DNS sunucumuz adı saklar naksec.test tümü büyük harfle yazılır ve bu nedenle yanıtın yanıt bölümü, formdaki adı içerir NAKSEC.TEST, IPv4 numarası (A kaydı) ile birlikte 203.0.113.42.

Ancak, DNS sunucumuzun geri gönderdiği yanıtın "çapraz kontrol için size döndürülen sorgu verileri burada" bölümünde, orijinal olarak DNS aramasında kullanılan karakter durumu karışımı korunur:

---> 127.0.0.1:55772'den 127.42.42.254:53'e talep ---> 00000000 c0 55 01 20 00 01 00 00 00 00 00 00 06 6e 41 6b |.U. .........nAk| 00000010 53 45 63 04 74 45 73 54 00 00 01 00 01 |BÖLÜM TEST..... | DNS araması: nAkSEc.tEsT için A kaydı ==> A=203.0.113.42 <--- 127.42.42.254:53'ten 127.0.0.1:55772'ye yanıt <--- 00000000 c0 55 84 b0 00 01 00 01 00 00 00 00 06 6e 41 6b |.U...........nAk| 00000010 53 45 63 04 74 45 73 54 00 00 01 00 01 06 4e 41 |BÖLÜM TEST......NA| 00000020 4b 53 45 43 04 54 45 53 54 00 00 01 00 01 00 00 |KSEC.TEST.......| 00000030 00 05 00 04 cb 00 71 2a |......q* |

Ekstra güvenlik etiketlemesi, ücretsiz

Bingo!

Bir DNS aramasının ekleyebileceği biraz daha "tanımlama etiketlemesi" var!

15-bitlik rastgele seçilmiş kaynak bağlantı noktası ve 16 bitlik rastgele seçilmiş kimlik numarası verilerinin yanı sıra, istekte bulunan kişi, alan adındaki her alfabetik karakter için büyük-küçük harf arasında seçim yapar.

Ve naksec.test 10 bit değerinde rastgele “etiketleme” için her biri büyük veya küçük harflerle yazılabilen 10 harf içerir.

Tahmin edilmesi gereken bu ekstra ayrıntıyla, saldırganların istekte bulunan sunucuya sahte bir "kaçırma yanıtı" enjekte etmek için zamanlama, UDP bağlantı noktası numarası, kimlik etiketi değeri ve alan adının büyük harf kullanımı konusunda şanslı olmaları gerekir. kabul edilebilir.

Bu arada, adı 0x20 kodlama yukarıda biraz şaka gibi: 0x20 başucunda 00100000 ikili olarak ve bu bayttaki yalnız bit, ASCII kodlama sistemindeki büyük ve küçük harfleri ayıran şeydir.

Harfler A için I, örneğin, 0x41 - 0x49 olarak çıkarken, a için i 0x61'den 0x69'a çıktı.

 ASCII metni olarak ASCII kodlama şeması -----+-----+ |00 ^@ |10 ^P |20 |30 0 |40 @ |50 P |60 ` |70 p | |01 ^A |11 ^S |21 ! |31 1 |41 Bir |51 S |61 Bir |71 Bir | |02 ^B |12 ^R |22 " |32 2 |42B |52R |62b |72r | |03 ^C |13 ^S |23 # |33 3 |43K |53S |63c |73 s | |04 ^D |14 ^T |24 $ |34 4 |44 D |54 Ç |64 gün |74 t | |05 ^E |15 ^U |25 % |35 5 |45 E |55 U |65 e |75 u | |06 ^F |16 ^V |26 & |36 6 |46 F |56 V |66 f |76 v | |07 ^G |17 ^W |27 ' |37 7 | 47 G |57 B |67 g |77 w | |08 ^H |18 ^X |28 ( |38 8 |48 H |58 X |68 s |78 x | |09 ^I |19 ^Y |29 ) |39 9 |49 I |59 E |69 ben |79 y | |0A ^J |1A ^Z |2A * |3A : |4A J |5A Z |6A j |7A z | |0B ^K |1B ^ [ |2B + |3B ; |4B K |5B [ |6B k |7B { | |0C ^L |1C ^ |2C , |3C < |4C L |5C |6C l |7C | | |0D ^M | 1D ^] |2D - |3D = |4D M |5D ] |6D m |7D } | |0E ^N |1E ^^ |2E . |3E > |4E N |5E ^ |6E n |7E ~ || 0F ^O |1F ^_ |2F / |3F ? |4F O |5F _ |6F veya |7F | +------+------+------+--- ---+------+------+------+------+

Başka bir deyişle, 0x41 elde etmek için 0x20+0x61 eklerseniz, A içine a; 0x69'u elde etmek için 0x20-0x49'yi çıkarırsanız, i içine I.

Neden şimdi?

Şimdiye kadar merak ediyor olabilirsiniz, "Eğer fikir 15 yıl önce ortaya çıktıysa ve gerçekten bir işe yarar mı?"

Ani ilgimiz, olduğu gibi, bir son genel e-posta Google teknisyenlerinden, 2022'de bu eski tarz güvenlik numarasıyla yaptıkları deneylerin gerçek hayatta kullanıldığını kabul ediyor:

Daha önce duyurduğumuz gibi, Google Public DNS, yetkili ad sunucularına gönderilen DNS sorgu adlarının büyük/küçük harfe göre rastgele seçilmesini sağlama sürecindedir. TLS üzerinden DNS kapsamına girmeyen bölgelerdeki DNS sorgularının çoğunluğunu (%90) koruyarak Kuzey Amerika, Avrupa ve Asya'daki bazı bölgelerde başarılı bir şekilde dağıttık.

Şaşırtıcı bir şekilde, Google, bu basit ve görünüşte tartışmasız ince ayar ile yaşadığı ana sorunların, çoğu DNS sunucusunun ya tutarlı bir şekilde büyük/küçük harfe duyarlı olmaması (böylece bu numara onlarla birlikte kullanılabilir) ya da tutarlı bir şekilde olmaması (böylece engellenenler), beklediğiniz gibi…

…birkaç ana akım sunucusu zaman zaman kısa süreler için "büyük/küçük harfe duyarlı" moda geçer; bu, büyük hizmet sağlayıcıların kaçınacağını umduğunuz türde bir tutarsızlık gibi görünür.

Gerçekten yardımcı oluyor mu?

Sorunun cevabı, "Buna değer mi?" henüz net değil.

Güzel ve uzun bir hizmet adınız varsa, örneğin nakedsecurity.sophos.com (22 alfabetik karakter), o zaman çok fazla ekstra sinyal gücü vardır, çünkü 2²² farklı büyük harf kullanımı, dolandırıcıların deneyebileceği 4 milyon kombinasyonun 65536 farklı kimlik numarasıyla çarpımı tahmin edilecek yaklaşık 32000 ila 64000 farklı kaynak bağlantı noktası anlamına gelir...

…ancak Twitter gibi çok kısa bir alan adı için küçük bir servet ödediyseniz t.co, saldırganlarınızın yalnızca eskisinden 2x2x2=8 kat daha zor bir işi var.

Yine de bunu denediği için Google'a “Chapeau” diyebileceğimizi düşünüyorum.

Siber güvenlik gözlemcilerinin söylemekten hoşlandıkları gibi, saldırılar yalnızca her zamankinden daha hızlı hale gelir, bu nedenle mevcut bir protokolü alıp ona neredeyse "ücretsiz" ekstra kırma süresi ekleyebilen her şey, karşılık vermenin yararlı bir yoludur.

---

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• Plato blok zinciri. Web3 Metaverse Zekası. Bilgi Güçlendirildi. Buradan Erişin.
• Kaynak: https://nakedsecurity.sophos.com/2023/01/23/serious-security-how-deliberate-typos-might-improve-dns-security/