DNS over HTTPS Nedir ? DNS over HTTPS (DoH) Kullanımının Firewall Tarafından Engellenmesi

Mozilla Firefox Browserlara DNS over HTTPS özelliği geldikten sonra bazı IT çalışanları bu konuda panik yaptı. Ancak Next Generation Firewall kullanan ve SSL Inspection yapan firmaların bu konuda panik yapmasına pekte gerek yok.
Neden mi ? Biraz temel konular hakkında bilgi vermeye çalışalım daha sonra da Firefox DoH'un şirket clientları tarafından kullanımını engelleyelim.

İlk olarak Domain Name System nedir ? diyerek temel bilgi oluşturmaya çalışalım. URL'ler insanların anlayabileceği şekildeir. www.asimyildiz.net, www.cisco.com vb. Ancak internet üzerindeki haberleşme Layer 3 üzerinden sağlanmaktadır.
Layer 3 IP Addresslerinin bulunduğu katmandır. Yani internet üzerinden gitmek istediğimiz bir URL'in aslında IP Address karşılığı olması gerekmektedir. Bu sebepten kullanıcılar Browserlarına www.cisco.com yazdıklarında arka planda
ilk olarak www.cisco.com ' un IP addressini sorgulayan bir paket çıkar. Bu DNS isteğinin hedefi, bilgisayarımıza DHCP (IP Dağıtımı yapan Server) tarafından tarafından verilen DNS Serverının IP Addressidir. Yani internette dolaşabilmek için
IP Addresslerini öğrendiğimiz bir DNS server vardır. Aşağıdaki Pcap üzerinden DNS Qury ve Reply paketlerini inceleyebilirsiniz. (Şekil-1 ve Şekil-2)

Şekil-1

Şekil-2

                                                                                                                   
Ancak burada dikkatimizi çeken bir durum var. Bu paketler tamamiyle kriptosuz ! Yani DNS isteğini göndermiş olduğumuz DNS Servera istekler ulaşıncaya kadar bizi hedefe ulaştıran bütün network cihazları (Router vb.) gitmek istediğimiz hedef hakkında bilgi sahibi olabilir.
Bu bilgiler daha sonra Reklam şirketleri vb. kuruluşlara satılabilir. Unutmamak gerekiyor ki günümüzde asıl para eden kişisel bilgiler, ilgi alanlarımız vs.
Bunun dışında DNS Spoofing atağa maruz kalabiliriz. Peki DNS Spoofing Atak nedir ? DNS Spoofing Atak, kullanıcının göndermiş olduğu DNS isteğinin hedef IP addressi yerine, hedefe ulaşmak için kullanmış olduğu Router vb. cihaz tarafından
Attacker'ın yönetimindeki DNS Servera yönlendirilmesidir. Amaç nedir ? Amaç, DNS Query'nin içerisindeki "www.cisco.com" un IP Address'i nedir sorusuna başka bir WEB Serverın IP Addressini dönmektir. Böylece kullanıcı www.cisco.com web sitesi yerine
başka bir Server üzerindeki klonlanmış www.cisco.com'un Web sitesine gitmektedir. Kullanıcı Cisco'nun gerçek Web sitesi yerine sahte Web sitesine "username" ve "password" girerek bilgilerini çaldıracaktır. Sahte Web Sayfası "http" ile servis edildiği için de
kullanıcı "Sayfa Güvenilir Değil" vb. hata ile karşılaşmadığı için şüphelenmemiştir.
Başka bir örnek vermek gerekirse, birkaç yıl önce mahkeme tarafından kapatılan siteler için ISPler kendi DNS sunucularında, ilgili site için gelen DNS Query'e yanıt olarak BTK'nın "Bu sayfa erişime kapatılmıştır." yazılı Web Serverının IP Addressini, DNS Reply da yanıt olarak
dönmektedir. ISPlerden almış olduğumuz modemler DNS Server olarak yine ISP'ye ait DNS Serverları kullanıcılara DHCP ile dağıtmaktadır. Kullanıcılar DNSlerini 8.8.8.8, 4.4.2.2 vb. IP'lere çekerek yasaklı sitelere erişmekteydi.
Daha sonra ISPler 8.8.8.8 vb. çok bilinen Public DNSleri kendilerine yönlendirdiler. Burada da BGP Hijacking uygulandı. Yani bilinen Public DNS Server IP Addresslerini ISPler Türkiye içerisinde anons ederken kendi DNS sunucularına
yönlendirme yaptı ve isteklerimi yeniden BTKnın ""Bu sayfa erişime kapatılmıştır."" yazılı WEB Serverına yönlendirildi.
Bu ve benzeri durumlar kullanıcıları DNS over HTTPS'e yönlendir.

Peki DNS over HTTPS nedir ?
Bildiğiniz üzere (Bilmiyor da olabilirsiniz bu sebepten HTTPS yazıma bir göz gezdirmenizi tavsiye ederim.) HTTPS, kullanıcı ve Hedef sunucu arasındaki trafiğin TLS protokolü kullanılarak kriptolanmasını sağlar. Bu kriptolama, L7'deki
Content'in 3. şahıslar tarafından okunmasının önüne geçer. Peki ben HTTPS ile DNS isteklerimi iletirsem ne olacak ? Önceki şekilde (Şekil-1 ve Şekil-2) DNS Query ve Reply'ın kriptosuz olduğunu gözlemlemiştik. Ancak HTTPS üzerinden session kurmuş olduğum bir Servera
DNS Query atarsam yanıtım isteğim hedefe ulaşırken kullanmış olduğum Network cihazları tarafından dinlenemeyecektir. DNS Reply'da benzer şekilde dinlenemeyeceği için erişmek istedğim sayfalara DNS isteklerim 3.kişiler tarafından
loglanamayacak ya da DNS Spoofing benzeri atakların önüne geçilecektir. Yani DoH aslında kullanıcı verilerinin çalınması ihtimalini düşürüyor. (Şekil-3 ve Şekil-4)

Şekil-3

Şekil-4

                                                             
Trusted Recursive Resolver (TRR) nedir ?
TRR Mozilla'nın DoH isteklerini yanıtlayan ve güvenilir olduğunu iddia ettiği Cloudflare'deki Serverlardır. Durum şunu gösteriyor ki Mozilla'ya güvenmek zorundayız ya da kullanmış olduğumuz DoH Tool'una(Simple DNSCrypt) :)
Mozilla kullanıcıyla şöyle bir güven ilişkisi kurmakta;
İstersek TRR IP Addressini defaultta bırakıyor ve Mozilla'nın Cloudflare'deki Serverına, Query'lerini DoH ile yolluyoruz, istemezsek de kendi güvendiği başka bir DoH sunucuyu kullanabiliyoruz. Tabi DNS genelde
UDP çalışan bir protokol ve çok hızlı. DoH ise HTTPS üzerinden çalışıyor ve biraz daha yavaş. Mozilla bu konuda da bir güzellik sağlamış. Kullanıcının yapmış olduğu istek ve yanıtları bir performans grafiğinde değerlendiriyor. Buna göre
kullanıcı başka TRR sunucuya yönlendirilebiliyor. (Şekil-5)

Şekil-5

Mozilla DoH'u şirket içinde neden engellemeliyiz ?
Şirketlerin Web Sitelerini blocklamak için farklı farklı senaryoları olabilir. Bunlardan birincisi şirkette SSL Inspection uygulanmıyorsa şirket https siteleri kendisi anons eder.
Örnek vermek gerekirse, www.youtube.com'a gitmek istiyorum, IP Addressini bana verebilir misin ? şeklinde şirket DNSlerine gelen istekler Authorative DNS sunucuya yönlendirilmek yerine Admin tarafından belirlenen Youtube'un onlarca IP adresinden
sadece birisi kullanıcıya yanıt olarak dönülür. Daha sonra kullanıcı bu yanıta HTTPS isteğinde bulunur ancak hedef IP'ye(Youtube) yapılan bütün istekler Firewall tarafından engellenmiştir ve ilgili kişini Youtube isteği Adminin isteği
üzerine engellenmiştir. Şöyle bir durum var. Youtube ve Google aynı IP addressleri kullandığı için kullanıcın yapmış olduğu bazı www.google.com DNS istekleri Youtube'un engellenmiş olan IP Addresine denk geldiği için kullanıcılar
google erişimlerinde problem yaşayabilir. Bu sebepten www.google.com için de,  DNS Serverımızda başka tek bir IP Address belirlememiz gerekiyor.
Peki kullanıcılar DoH kullansaydı böyle bir engele takılacaklar mıydı ? Tabikide mevcut sistemde takılmayacaklardı.
Ayrıca DNS Firewall kullanan bazı şirketlerde, DNS Firewall'a gelen istekler DNS Firewall tarafından incelenerek (Kriptosuz istekler) kullanıcın erişmek istediği Web Siteleri hakkında bilgi sahibi olunur ve uygunsuz
olduğu tespit edilen sayfalar bu usülle engellenebilir. DoH böyle bir korumayı da bypass etmektedir.
Yukarıdaki sebeplerden dolayı DoH'un Local DNS Serverlara sahip şirketlerde engellenmesi en doğrusu olacaktır.
Peki nasıl ?
İlk olarak DoH isteklerini dinlemek için bir Proxy'e ihitiyacımız var. Wireshark ile de dinleyebiliriz ancak Wireshark'da HTTPS trafikleri dinlemek için yüklenen Private Key ya da PreMasterKeys DoH'un isteklerini decrypt etmemekte...
Bu sebepten Burp Suite'in Proxy özelliğinden faydalanacağız. Client Request'deki tiklerin kaldırılmasını unutmayın. Yoksa DoH isteklerini Burp Suite'de göremeyebilirsiniz. (Şekil-6)

Şekil-6

Daha sonra Mozilla üzerinden Proxy olarak Burp Suite'i göstereceğiz.(Şekil-7)

Şekil-7

Burada dikkat edilmesi gereken HTTPS trafiğin Decrypt edilmesi için BURP Suite'in CA ' ini Trusted ilan etmemizdir! (Şekil-8) Aşağıdaki şekilde sağ üstte görebilirsiniz.

Şekil-8

Artık DNS İsteklerini ClearText olarak görebiliyoruz. Burada dikkatimizi çeken HTTPS Header'da POST: /DNS-QERY ve Accept: application/dns-message (Şekil-9)

Şekil-9

Yani firewall da Content Header'da "dns-message" görürsen blockla diye bir kural yazarsak Mozilla DoH'a karşı artık bizim de bir silahımız olacaktır. Ancak Firewall'umuzda SSL Inspection açık olmak zorunda :) !
Yani HTTPS Traffic dinelenebilir olmalıdır ki Kriptolu Header'ın içeriğini görebilelim. Fortigate Firewall'da aşağıdaki komutla DoH'un önüne geçebilirsiniz.
---
config webfilter content-header
edit 1
set comment ''
config entries
edit ".*dns-message.*"
set action block
---
https://kb.fortinet.com/kb/documentLink.do?externalID=FD31303
PC'min DNS IP addresi 127.0.0.1 şeklinde. Şu an DoH engellendiği için internete gidemiyorum.

Engelleme Sonrası Burp Suite Sonucu (Şekil-10)

Şekil-10

Bir diğer engelleme metoduysa Firewall'a güvenilir bir kaynaktan TRR'leri Dynamic List olarak ekleyerek blocklama yapmaktır.

Başka bir yazıda görüşmek üzere.   


     

IP Fragmentation Attacks

Konunun anlaşılabilmesi için öncelikle bir temel oluşturmaya çalışalım.

MTU (Maximum Transmission Unit):

Paket, OSI katmanlarının 3.katmanını ifade eder. Paket header ise defaultta 20 Bytedan oluşan ve Layer 3’de çalışan protokollerin çalışabilmesi için ilgili sistemlerin okuyabildiği, ana içeriği yönlendirme ve IP Address bilgileri olan üst katmanlarda çalışan protokoller ile ilgili de ayrıca bilgi veren OSI katman headırıdır. (Protocol Number vb.)

Aşağdaki şekilde IP header’ı inceleyebilirsiniz. (Şekil 1)

Şekil-1

MTU ise Ethernet katmanında (Layer 2) bulunan bir değerdir. Bu değer Layer 3 ve sonrasındaki Datanın’da  dahil olduğu maximum toplam boyutu ifade eder. Konunun daha iyi anlaşılması için biraz daha bilgi vermek gerekirse, bir data 2 endpoint arasında paylaşılırken gönderici tarafından OSI standardına uygun şekilde ilgili katmanlara headerlar eklenir. Daha sonra gönderici tarafından iletilen içerik, kullanılan pathdeki sistemlerin (Router, Switch vb.) aracılığıyla, Layer 2 ve Layer 3 header kontrolü yapılarak doğru yönlendirmeyi yapar. Sonrasında alıcı ise headerları ve datayı OSI standardına göre anlamlandırmaktadır.(Şekil 2)

Şekil-2

Fragmentation:

Göndermek istediğimiz Data’ya OSI katmanları stadardınca headerlar eklenilir ve sonrasında hedefe gönderilir. Bilgisayarımızdan çıkan data ve Layer 2 Header hariç headerların toplam boyutu evrensel standartlara göre 1500 Byte’ı geçmemelidir. Yani MTU’muz 1500 Byte’dır. Bu değer datayı gönderecek Application ya da Protokol tarafından ayarlanmaktadır.

NFS Protokolü defaultta 8 Kbyte lık parçalar ile datayı göndermektedir. Eğer PC’yi karşılayan Layer 2 katmandaki cihaz Jumbo Frame’lere izin vermiyorsa data aktarımı pek mümkün olmayacaktır. Jumbo frame, MTU’nun 1500 Byte üzerinde olması durumundaki Frame’in boyutunu ifade eder. Eğer switch tarafında ilgili izin veriliyorsa ((config)#system mtu Jumbo 7500) Layer 3 cihaza gelen frame router tarafından default davranış olarak frame i bölecektir. Sonrasında da WAN’a ya da ilgili hedefe yönlendirme gerçekleştirilecektir.  Router tarafından gerçekleştirilen bu bölme işlemi Fragmentation olarak adlandırılmaktadır.

MSS (Maximum Segment Size): Layer 4’ün yukarısında yer alan headerlar ve datanın toplam boyutudur. Standart durumlarda direkt olarak datanın boyutu olarak ele alınmaktadır. Bu değer MTU değerinin aşıldığı durumlarda sistemin fragmente edilememesi için Layer3 cihazda ayarlanabilmektedir. (Şekil-3) 

Şekil-3

Örnek vermek gerekirse normalde bir IP Header’ın 20 Byte olması beklenmektedir. Transport Header’da standart durumlarda 20 Byte’dır. Ancak GRE Tunnel, IPSec VPN kurulumu vb. durumlarda Layer 3 Header’a ek bir Layer 3 Header daha eklenmektedir. Şekil-3

Normal şartlarda Layer 2’nin yukarısındaki header ve datanın toplam boyutu olan 1500 Byte aşılmaktadır. 24 Byte ek header sebep toplam boyut 1524 Byte olmaktadır. Ancak bu değer MTU’nun üzerinde bir değerdir. GRE Tunnel Router, Firewall vb. cihazlar arasında kurulmaktadır. 2 farklı lokasyondaki sistemin Local Networklerinin haberleşmesi için kurulan, sistemlerin Directly Connected olmasını sağlayan bir protokoldür. Tunnel’in kurulmuş olduğu Router ya da Firewall’dan çıkan Data’nın girmiş olduğu ilk Layer 3 cihaz (Firewall, Router vb.) paketleri fragmente etmek isteyecektir. Eğer Fragmentation Disable edilmişse Tunnel Up duruma gelemeyecektir. Bu sebepten Datanın boyutu kısılarak, Layer 3 Header’a eklenen ek kısım süspanse edilecektir.

Normal Şartlar Altında; LAYER 3 HEADER(20)+LAYER 4 HEADER(20)+DATA(1460)=1500 Byte

GRE TUNNEL Kurulduğu Durumda; TUNNEL HEADER(24) + LAYER 3 HEADER(20) + LAYER 4 HEADER(20)=1524 Byte (Şekil-4)

Şekil-4

 24 Byte standart fazlası olduğu için ve Fragmentation‘ın önüne geçmek için MSS 1436’ya çekilmelidir.

(config)#ip tcp adjust-mss 1436

PMTUD (Path MTU Discovery): 2 Endpoint Data aktarımı yapmadan önce, paketin fragmente olmasını engellemek için haberleşme için kullanılan hattı test eder. Bu amaçla farklı boyutlardaki dataları adım adım düşürerek hedef host a iletir. Eğer «Packet needs to be fragmented.» yanıtı hedefe ulaşırken kullanılan Path’deki cihazlardan birisi tarafından üretilirse Source Host Datanın boyutunu kısarak tekrar denemede bulunur. Bu işlem yapılırken IP Header’daki «Don’t Fragment» biti 1 durumuna getirilir. (Şekil-5)

Şekil-5

En uygun değer bu mantık çerçevesinde elde edildikten sonra, 2 Host birbiriyle paketler Fragmente edilmeden haberleşir. Paketlerin Fragmente edilmemesi neden önemlidir biraz da ondan bahsedelim. 

Bir Data gönderiyorsunuz. Yollamış olduğunuz Data 1 GigaByte. Ancak datayı gönderen application Paketi 1600’er Byte’lık paketler şeklinde gönderiyor. Bu Data kullandığı Path’deki bir cihaz tarafından sürekli olarak Fragmente ediliyor ve her 1600 Byte’lık paket 2 Parça şeklinde gönderiliyor.

Standart MTU’muz 1500 Byte.

Packet Header(20)+Transport Header(20)+Data(?) = 1600 Byte

Data(?) = 1560 Byte

1.Fragemante edilen Packet=Packet Header(20)+Transport Header(20)+Data(1460)

1560 Byte – 1460 Byte = 100 Byte diğer pakette gönderilmesi gereken Data

2.Fragmente edilen Packet=Packet Header(20)+Transport Header(20)+Data(100) = 140 Byte

1 GigaByte’ lık toplam Data 2’şer parça halinde, 1500 Byte ve 140 Byte’lık packetler şeklinde hedefe iletilir. İletilen her Packette kullanılan minumum 40 Byte’lık header’ın 1460 Byte saf data için gönderilmesi idealdir ancak 100 Byte’lık saf Data için 40 Byte header kullanılması efektif bir durum değildir. Yani gereksiz fazladan Header gönderilmesi sistemin uzun vadede hız ve performansını olumsuz etkileyen bir durumdur. PMTUD’nin önemini bu şekilde açıklayabiliriz.

Gerekli temel bilgiyi verdiğimize göre şimdi Fragmantation Attacklardan bahsedebiliriz.

1- ICMP Fragmentation Attack

Gönderici kendi tarafından oluşturduğu yüksek boyuta sahip datayı hedefe gönderir. Ancak bu datayı kendi tarafında fragmente edebilir ya da kendi Gateway’inde fragmente edilmesini isteyebilir. Ancak kendi Gateway’inde fragmente edecekse yüksek kapasiteye sahip bir Gateway’e sahip olması gerekmektedir. Fragmente edilmiş paket hedef hostun Gateway’ine eriştikten sonra Gateway paketleri hosta yollamadan önce defragmente eder. Ancak paketlerin birleştirilmesi sonucunda oluşan ya da oluşmaya çalışan data Gateway’in kaynaklarını tükettiği için hizmet veremez duruma gelmiştir. 

Bu attack availabilityi etkileyen bir attacktır. DoS attack kategorisindedir.

2- Tiny Fragment Attack

Normal şartlarda bir packetin nasıl maksimum boyutu için evrensel bir standart varsa (MTU), aynı şekilde bir frame in de minumum olabileceği bir alt boyut standardı vardır. Frame bu boyutun altına standart durumda düşemez. Ancak attack yapmayı hedeflediğiniz IP adresine erişirken kullanmış olduğunuz path de böyle bir standart yok ise Tiny Fragment Attack yapabilmeniz mümkündür. Tiny Fragment Attack’ın nasıl gerçekleştiğini anlatacak olursak, attacker kendi tarafında fragmente ettiği paketleri sırasıyla yollar. Fakat yollamış olduğu bu paketler İlk gelen paket Destination IP ve Source IP’nin de bulunduğu Layer3 header’ı içerir. Ancak bu ilk paket Layer 4’de Destination Port bilgisinin bulunduğu kısma kadar bilgi içerir.(Layer 4 ün devamı 2. pakette gelecektir.) Bu ilk paketi alan cihazımızda (Firewall, Router vb.) tanımlanmış olan Access-list ya da policy, ilgili source IP adresi için ilgili destination IP adresine izin vermişse paket defragmente edilmek için Firewall ya da Router memory sinde tutulmaya başlanır. Gelen ikinci paket Layer 4’deki source ve destination port bilgisini içeren kısma sahiptir. Ancak ilk paketin devamı olan bu pakete geçmişte izin verildiği için artık policy kontrolü yapılmayacaktır. Daha sonra 3. pakette Router yada Firewallumuz tarafından herhangi bir filtreye tabi tutulmadan kabul edilecektir. Artık 3 paketi birleştirip alıcıya gönderebilir durumda olan Router ya da Firewall aslında normal şartlarda yasaklamış olduğu destination porta haberi olamadan izin vermektedir. Çünkü sadece ilk paket kontrol edildi ve IP bazında izin verildi. Ancak 2.paket destination port bilgisi ve layer 4 header ın geri kalan kısmını içeriyordu. 3.paket ise data içermektedir. Data da malicious bir içerik olabilir. Bu attack ile güvenlik cihazını bypass edebiliriz ama ana koşul minumum frame standardının olmamasıdır. (Şekil-6)

Şekil-7

 3- Ip Fragmentation Overlap Attack

Bu Attack da asıl amacımız IPS/IDS ya da UTM özellikli koruma yapan cihazları atlatmaktır. Burada IP Fragmentation ile ilgili ek bilgi vererek IP Fragmentation Overlap için bir temel oluşturmam gerekiyor. Daha önce bahsettiğimiz gibi MTU değerinin üstündeki bir paket fragmente edilir ve parçalar halinde hedefe yollanır. Hedef  gateway bu parçaları birleştirerek client a gönderir. Peki bu birleştirme işlemi nasıl gerçekleşiyor. Gelen paketlerin IP Headerları incelendiğinde 3 kısım bizim için Fragmentation ın bel kemiğidir. Identification-Flag-Fragmentation Offset. Identification, büyük boyutlu paket fragmente edildikten sonra her bir parçasına aynı ID verilmesi işlemidir. Bu sayede hedef gateway paketleri defragmente ederken başka paket ya da başka göndericilerden gelen fragmente edilmiş datanın karıştırılmasının önüne geçer.

Flag ise «Fragment», «Don’t Fragment» ve «More» bayraklarını içerir. Gelen paket Fragment flag ini içeriyor packet default davranış olan MTU’nun üzerinde boyuta sahip paketi parçalara ayıracaktır. Gelen paket Don’t Fragment flag ini içeriyorsa göndericinin Gateway i bu paketi parçalara ayırmadan göndermeye çalışacaktır. Ancak paketin hedefe ulaşırken kullanacağı path de, MTU’nun üzerinde bir boyuta sahip olduğu için fragmente edilemeden iletilmesi mümkün olmayacaktır. ISP, Gateway vb. bir cihazda engellenmesi olasıdır. Paket tamamiyle kendi yönettiğimiz cihazlardan hedefe ulaşacaksa, DF flag i işaretli büyük boyutlu paketin hedefe ulaşması olasıdır.  More Flag i «1» ise alıcının Gateway i, gelecek olan başka paket olduğunu öğrenir ve bekler. Daha sonra gelen pakette More Flag «0» ise bu ID’ye ait daha fazla gelecek olan paketin olmadığını öğrenir ve aynı ID’ye sahip paketlerin tamamını birleştirdikten sonra hedefe yollayabilir. 

Fragmentation Offset ise gelen paketin sıra numarasını ifade eder. Segment, Layer 4 header ve datanın toplam boyutunun adıdır. Fragmentation Offset gelen paketlerin doğru birleştirilmesi için önemlidir. İlk gelen paket eğer 1500 Byte yani taşınabilir maximum boyutta (MTU) ise  Frag.Offset değeri 0 olacaktır ancak Frag.Offset’de kapladığı alan 185’dir. İkinci gelen paket Frag.Offset’de 185’den başlayacaktır. Yani ikinci paket yine 1500 byte geldi ise Frag.Offset de 185 değer yer daha kaplayacaktır, haliyle 3.gelecek olan paket de 370’den başlayacaktır. 185 değerinin hesaplama mekanizması ise 1480/8=185 şeklindedir. Yani her «8 byte» Frag.Offset değerini +1 olarak arttırır. (Şekil-6)

Şekil-7

Şimdi IP Fragmentation Overlap Attack’ı anlayabilecek temel bilgiye sahibiz.

Attacker, yüksek boyutta paketleri göndermeden önce ince bir işçilik yaparak Frag.Offset değerlerini hedefe sızacak şekilde ayarlayarak Fragmente eder. Attacker ın ilk yolladığı paket boyutu 1480 byte’dır. Frag.Offset deki kapladığı alan ise 185’dir. İkinci yollanan paket ise 160 Byte dır. Yani Frag.Offset de kapladığı alan 160/8=20 şeklindedir. Yani ikinci Frag.Offset değerimiz 185+20 kadar alan kaplayacaktır ve «normal şartlarda!» Frag.Offset değeri (1.Paketi 2. paket ile birleştirirken 185 inci alandan itibaren birleştirir) 2.paketin headerı nın içerisinde, başlangıç noktası olan 185 değerini gösterecektir. Üçüncü paket ise yine 160 Byte olsun. Paket header ın Frag.Offset değeri 20 şeklindedir. Ancak Bu bahsettiğim durum «normal şartlarda».  Hacker ikinci gelen pakette Frag.Offset değerini 185 yerine 165 olarak ayarlarsa, bir önceki paketin 20 değerlik kısmını ezer. Yani başlangıç değerini, Frag.Offset değeriyle oynayarak önceki pakette gelen datanın bir kısmını ezmiştir.

8 tane kutumuz var. İlk pakette 8 harf gönderdim ve not düştüm 1.kutudan itibaren yerleştiriniz.         ( P A S S W O A T )

Daha sonraki pakette 2 harf gönderdim ve not düştüm  7. kutudan itibaren diziniz. (            R D )

2 Paket birleştiği zaman « P A S S W O R D » elde edilir. 

Bu yüzden Defragmentation ın yapıldığı cihazdan sonra ek bir güvenlik cihazı olmalı ve defragmented paketleri yakalamalıdır. (Transparent Mode'da çalışmayı destekeleyen bir cihaz ya da MTU değeri normalin çok üzerinde olan bir cihaz.) 

Arkadaşlar, Fragmentation Attacklar hakkında dilim döndüğünce bilgi vermeye çalıştım. Başka bir yazıda görüşmek üzere...