
Araştırma, TCP üçlü el sıkışmasını hedefleyen SYN flood saldırılarında kullanılan geleneksel SYN cookie mekanizmasına HMAC-SHA256, zaman damgası ve bağlantı başına üretilen nonce ekleyerek replay saldırılarına karşı doğrulamayı güçlendirmeyi inceliyor. Araştırmacılar bunun için Python tabanlı özel NOxSYN simülasyon ortamını geliştirdi ve geleneksel RFC 4987 tarzı SYN cookie yaklaşımıyla nonce-geliştirilmiş sistemi aynı kontrollü ortamda karşılaştırdı. Nonce-geliştirilmiş mekanizmada ortalama cookie üretim süresi 0,0023 ms, ortalama doğrulama süresi 0,0017 ms olarak ölçüldü; tüm kriptografik işlemler bağlantı başına 1 ms'nin altında kaldı. Bununla birlikte çalışma üretim sınıfı bir TCP/IP yığını üzerinde değil, kullanıcı alanında çalışan sanallaştırılmış bir laboratuvar prototipi üzerinde gerçekleştirildi ve farklı replay saldırıları karşısındaki güvenlik etkinliği kapsamlı güvenlik metrikleriyle ölçülmedi.
Çalışmanın önemli sonucu yalnızca “daha güvenli bir SYN cookie” önermek değildir. Araştırma, bağlantı parametrelerini kısa ömürlü bir nonce ve HMAC ile ilişkilendirmenin uygulanabilir olduğunu; fakat bunun geleneksel SYN cookie yaklaşımının çok düşük işlem maliyetiyle aynı olmadığına işaret ediyor. Sürdürülen SYN flood yükü altında nonce-geliştirilmiş mekanizmanın sunucu tarafı normalize CPU kullanımı %31,35'e ulaşırken geleneksel yaklaşımda bu değer %1'in altında kaldı. Dolayısıyla replay direnci için eklenen nonce üretimi, genişletilmiş HMAC hesabı ve geçici nonce tablosunun maliyeti göz ardı edilemez.
Türkiye açısından: Bulgular Türkiye'deki veri merkezleri, bulut hizmetleri, kurumsal ağlar, servis sağlayıcı altyapıları ve IoT sistemlerinde SYN flood savunmasının geliştirilmesine yönelik teknik bir yaklaşım sunabilir; ancak araştırmada Türkiye'ye özgü ağ trafiği veya altyapı verisi bulunmamaktadır. Çalışmadaki performans değerlerinin yerel sistemlere doğrudan aktarılması doğru olmaz. Türkiye'deki gerçek kullanım için Linux çekirdeği düzeyinde uygulama, farklı işlemci mimarileri, gerçek yönlendirme koşulları, farklı ISP ağları ve dağıtık saldırı kaynaklarıyla yeniden doğrulama gerekir.
Araştırmanın temel problemi nedir?
TCP bağlantısı normalde istemci ile sunucu arasında üç aşamalı bir el sıkışma ile kurulur: istemci SYN gönderir, sunucu SYN-ACK ile yanıt verir ve istemci son olarak ACK gönderir. Geleneksel bir sunucu, son ACK gelmeden önce bağlantı hakkında geçici durum bilgisi tutabilir. Çok sayıda sahte veya tamamlanmayan SYN isteği gönderildiğinde bu yarım açık bağlantılar sunucu kaynaklarını tüketebilir; SYN flood saldırısının temel mekanizması budur.
SYN cookie yaklaşımı bu sorunu, yarım açık bağlantının durumunu sunucuda tutmak yerine gerekli bilgiyi TCP başlangıç sıra numarasına kodlayarak azaltır. İstemciden ACK geldiğinde sunucu cookie'yi doğrular ve ancak bundan sonra bağlantıyı oluşturur. Böylece eksik bırakılan el sıkışmaları için klasik biçimde bağlantı durumu ayrılması gerekmez.
Araştırmacıların üzerinde durduğu ikinci sorun ise replay, yani daha önce geçerli olmuş bir doğrulama değerinin yeniden kullanılmasıdır. Geleneksel cookie zaman penceresi içinde yeterli bağlantı-özel benzersizliğe sahip değilse daha önce gözlemlenen bir değerin yeniden kullanılması teorik olarak yeni bir saldırı yüzeyi oluşturabilir. Önerilen tasarım bu noktada her bağlantı girişimini nonce ile bağlamayı amaçlıyor.
Nonce ve HMAC neden birlikte kullanılıyor?
Nonce, belirli bir protokol işlemi için kullanılan tekil veya kısa ömürlü değerdir. Bu çalışmada her SYN isteği için kriptografik olarak güvenli bir nonce oluşturulması ve bu değerin bağlantı doğrulamasına dahil edilmesi hedefleniyor. Böylece aynı bağlantı parametrelerinin farklı zamanlarda ürettiği doğrulama değerlerinin birbirinden ayrılması amaçlanıyor.
HMAC-SHA256 ise gizli anahtarı bağlantı parametreleriyle birleştirerek doğrulanabilir bir kimlik doğrulama kodu üretiyor. Çalışmanın uygulanan çerçeveyi tarif eden bölümündeki temel ilişki şöyledir:
\[ SYN\_Cookie = HMAC(K, ClientIP \parallel Port \parallel T \parallel N) \]
Burada K gizli anahtarı, T zaman damgasını ve N nonce değerini temsil eder. TCP sıra numarası yalnızca 32 bit olduğu için çalışmada HMAC-SHA256'nın 256 bitlik çıktısı 32 bite kırpılır:
\[ Cookie = Truncate_{32}\left(HMAC(K, IP \parallel Port \parallel T \parallel N)\right) \]
Bu kırpma, cookie'nin TCP sıra numarası alanına yerleştirilebilmesini sağlar. Güvenlik yalnız 32 bitlik çıktının kendisine bırakılmamaktadır; gizli anahtar, zamanla sınırlandırılmış geçerlilik ve nonce yaşam döngüsü birlikte kullanılmaktadır.
Kaynak içindeki formül farklılığı neden önemli?
Çalışmanın önceki saldırı simülasyonu bölümünde verilen bir örnek HMAC ifadesi istemci IP'si, istemci portu, sunucu IP'si, sunucu portu ve zaman damgasını içerirken nonce değerini açıkça göstermemektedir. Buna karşılık uygulanan mekanizmayı ayrıntılandıran sonraki bölümlerde nonce N doğrudan HMAC girdisinin parçasıdır. Ayrıca başka bir açıklamada istemci ve sunucu IP/port bilgilerinin birlikte kullanılacağı belirtilirken sonraki kompakt formül yalnız IP, port, zaman damgası ve nonce gösterimini kullanmaktadır. Bu nedenle kaynakta HMAC girdisinin gösteriminde tam bir notasyon tutarlılığı yoktur. Uygulanan mekanizmanın temel mantığı, sonraki yöntem bölümlerinde açıklandığı üzere nonce'nin doğrulama hesabına bağlanmasıdır.
Geliştirilmiş TCP el sıkışması nasıl çalışıyor?
Araştırmacıların Şekil 8 ve Şekil 9'da gösterdiği mekanizma dört ana doğrulama aşamasından oluşuyor. Sunucu SYN isteğini aldıktan sonra nonce üretir ve HMAC tabanlı cookie hesaplar. Cookie SYN-ACK paketinin TCP sıra numarasına, nonce ise çalışmanın prototipinde TCP deneysel seçeneğine yerleştirilir. İstemci cookie'nin iç yapısını bilmeden normal ACK mantığıyla yanıt verir. Sunucu daha sonra nonce'nin geçerliliğini ve yeniden hesaplanan HMAC değerini kontrol eder.
Verianla Live: Nonce-geliştirilmiş SYN cookie doğrulama akışı
Bu süreç tablosu çalışmanın geliştirilmiş handshake mekanizmasını özetler. Gösterim deneysel NOxSYN prototipindeki işlem sırasını temsil eder; üretim ortamındaki bütün TCP/IP işleyişini temsil etmez.
| Aşama | Açıklama | Kaynak |
|---|---|---|
| 1. İstemci başlatma | İstemci IP adresi, portu ve başlangıç sıra numarasıyla SYN paketini sunucuya gönderir. | Bölüm 7.3, Şekil 8 |
| 2. Cookie ve nonce üretimi | Sunucu kriptografik nonce üretir; gizli anahtar, bağlantı parametreleri, zaman damgası ve nonce kullanılarak HMAC tabanlı SYN cookie hesaplanır. | Bölüm 7.1–7.5, Şekil 5 ve Şekil 8 |
| 3. SYN-ACK ve istemci ACK'si | Cookie TCP sıra numarasına yerleştirilir; prototipte nonce TCP deneysel seçeneği üzerinden taşınır. İstemci ACK ile yanıt verir. | Bölüm 7.3 ve 8, Şekil 8 |
| 4. Doğrulama ve nonce iptali | Sunucu zaman geçerliliğini, nonce referansını ve yeniden hesaplanan HMAC değerini kontrol eder. Başarılı doğrulamadan sonra nonce geçersiz kılınır ve silinir; başarısız istek reddedilir. | Bölüm 7.4–7.5, Şekil 9 |
Verianla Live: Bu süreç görünümü yukarıdaki görünür bilimsel veri tablosundan tarayıcıda oluşturulur. Tablo bilimsel kaynak-of-truth olarak korunur.
Sistem gerçekten tamamen stateless mı?
Bu noktada çalışmanın kullandığı terminolojiyi dikkatli okumak gerekir. Geleneksel SYN cookie'nin temel avantajı, her yarım açık bağlantı için sunucu tarafında bağlantı durumu tutmamasıdır. Önerilen sistem de tam TCP bağlantı durumunu saklamaz; ancak replay'i aynı geçerlilik penceresi içinde engellemek amacıyla nonce değerlerini kısa süreli olarak takip eder.
Çalışmanın yöntem bölümünde her gelen SYN için yüksek entropili nonce üretildiği ve istemcinin bağlantı parametreleriyle nonce arasında geçici bir eşleme tablosu tutulduğu açıkça belirtilmektedir. Başarılı ACK doğrulamasından sonra nonce hemen silinir; doğrulama başarısız olursa giriş de kaldırılır.
Bu nedenle mekanizmayı klasik SYN cookie ile aynı anlamda “hiç durum tutmayan” bir yapı olarak değerlendirmek doğru değildir. Daha kesin ifade, tam bağlantı durumunu saklamayan ancak replay direnci için minimal ve kısa ömürlü nonce durumu kullanan bir tasarım olduğudur. Çalışmanın kendisi de ilerleyen bölümlerde bunu “core stateless philosophy” ifadesiyle sınırlandırmaktadır.
NOxSYN nedir?
NOxSYN, araştırmacıların bu çalışma kapsamında Python 3.10 ile geliştirdiği özel simülasyon ortamıdır. Harici veya daha önce yayımlanmış genel amaçlı bir framework değildir. Dört temel modül içerir:
- SYN Cookie Server: HMAC-SHA256 ve nonce kullanarak cookie üretir ve doğrular.
- Legitimate Client: normal üçlü TCP el sıkışmasını gerçekleştirir.
- SYN Flooding Module: yüksek hacimli sahte SYN paketleri üretir.
- PCAP Analyzer: deneyden sonra paket çiftlerini ve doğrulama davranışını inceler.
Kriptografik hesaplama ve paket oluşturma için Python'un hmac, hashlib ve scapy bileşenleri kullanılmıştır. Her SYN isteği için 128 bit nonce oluşturulmuş, nonce üretiminde os.urandom() ve ek entropiden yararlanılmıştır. Nonce prototipte TCP'nin deneysel Kind 254 seçeneğiyle iletilmiş ve istemci IP/port bilgisine göre geçici eşleme tablosunda tutulmuştur.
Paket ve log verileri nasıl doğrulandı?
Araştırmacılar yalnız konsol çıktısına güvenmemiştir. Deneyler sırasında trafik PCAP biçiminde kaydedilmiş; SYN paketleri, SYN-ACK içindeki kırpılmış HMAC cookie'leri, ACK paketleri ve SYN flood trafiği paket düzeyinde incelenmiştir. Çalışmanın Şekil 11'inde Wireshark üzerinden bir SYN-ACK paketindeki cookie'nin TCP sequence number alanındaki konumu gösterilmektedir.
NOxSYN aynı zamanda JSON logları üretmiştir. Bu kayıtlar zaman damgasını, istemci IP adresini, istemci portunu, hexadecimal nonce değerini ve karşılık gelen kırpılmış HMAC cookie'sini içerir. Araştırmacılar JSON kayıtlarını PCAP verileriyle çapraz kontrol ederek cookie üretimini ve nonce benzersizliğini doğrulamaya çalışmıştır.
Deney ortamı ne kadar gerçekçi?
Test ortamı iki Kali Linux sanal makinesinden oluşmuştur. Sanal makineler macOS Sonoma 14.3 çalıştıran, Apple M1 ARM64 işlemcili ve 8 GB RAM'e sahip bir MacBook Air üzerinde Parallels Desktop içinde çalıştırılmıştır. Bir sanal makine sunucu, diğer sanal makine ise hem meşru istemci hem SYN flood saldırganı rolünü üstlenmiştir.
Bu yapı kontrollü ve tekrarlanabilir deney açısından yararlıdır; fakat büyük bir botnet, farklı internet servis sağlayıcıları, çok sayıda bağımsız saldırı kaynağı, gerçek yönlendirme asimetrileri veya üretim sınıfı sunucu donanımı anlamına gelmez.
Çalışmanın güçlü yönleri nelerdir?
- Öneri yalnız kavramsal bırakılmamış, çalışmaya özel NOxSYN prototipinde uygulanmıştır.
- Geleneksel RFC 4987 tarzı SYN cookie mekanizması karşılaştırma tabanı olarak ayrıca uygulanmıştır.
- Cookie üretimi, doğrulama süresi, CPU kullanımı ve saf kriptografik throughput ayrı ayrı ölçülmüştür.
- PCAP ve JSON kayıtlarıyla paket düzeyi ve uygulama düzeyi doğrulama birlikte kullanılmıştır.
- Nonce'nin yaşam döngüsü ve başarılı doğrulamadan sonra iptal edilmesi açık biçimde modellenmiştir.
- Araştırmacılar kullanıcı alanı prototipi, sanallaştırma ve üretim ortamına genellenebilirlik sorunlarını sınırlılık olarak açıkça kabul etmiştir.
Çalışmanın temel sınırlılıkları nelerdir?
Birincisi, NOxSYN gerçek işletim sistemi çekirdeğine entegre edilmiş bir SYN cookie uygulaması değildir. Kullanıcı alanındaki Python kodu gerçek TCP backlog yönetimini, kernel bağlantı tablolarını, socket yaşam döngüsünü, zero-copy işleme, interrupt coalescing veya kernel fast-path optimizasyonlarını modellememektedir.
İkincisi, sunucu başarılı ACK sonrasında gerçek bir socket oluşturup tam TCP oturumu yürütmemektedir. Dolayısıyla çalışma esas olarak cookie doğrulamasını test eder; uzun süreli bağlantı durumu, gerçek bellek tüketimi ve tam bağlantı yaşam döngüsünü ölçmez.
Üçüncüsü, HMAC-SHA256 ve her SYN için güvenli nonce üretimi ek hesaplama maliyeti doğurur. Bu maliyet kontrollü deneyde yönetilebilir kalmış olsa da çok daha büyük volumetrik saldırılarda veya kaynakları sınırlı IoT cihazlarında aynı sonucun elde edileceği gösterilmemiştir.
Dördüncüsü ve güvenlik yorumu açısından en önemlisi, çalışma replay saldırılarına ilişkin kapsamlı nicel güvenlik değerlendirmesi gerçekleştirmemiştir. Replay detection rate, replay success rate, false acceptance rate ve false rejection rate gibi ölçütler araştırmanın mevcut deneylerinde raporlanmamıştır.
Beşincisi, istemci ve saldırgan aynı fiziksel bilgisayar üzerindeki sanal makinelerde çalışmaktadır. Bu durum gerçek dünyadaki kaynak IP çeşitliliğini, asimetrik rotaları, ağ gecikmelerini ve coğrafi olarak dağıtılmış saldırganları temsil etmemektedir.
Çalışma neyi destekliyor, neyi desteklemiyor?
Çalışmanın desteklediği sonuçlar:
- Nonce, zaman damgası ve HMAC kullanımı NOxSYN prototipinde SYN cookie doğrulama akışına uygulanabilmiştir.
- Meşru el sıkışmalar kontrollü SYN flood yükü altında doğrulanabilmiştir.
- Ölçülen sunucu tarafı kriptografik işlem süreleri bağlantı başına 1 ms'nin altında kalmıştır.
- Nonce'nin tek kullanımlı olarak izlenmesi replay'e karşı ek bir doğrulama katmanı oluşturmuştur.
- Geliştirilmiş yapının uygulanmasının hesaplama ve durum yönetimi açısından ölçülebilir bir maliyeti vardır.
Çalışmanın desteklemediği veya henüz test etmediği sonuçlar:
- Gerçek internet ölçeğindeki DDoS saldırılarının kesin olarak engellendiği gösterilmemiştir.
- Kernel düzeyi Linux veya başka üretim TCP/IP yığınlarında aynı performans kanıtlanmamıştır.
- 248 bin bağlantı/saniye civarındaki saf kriptografik throughput, gerçek ağ sunucusunun aynı sayıda TCP bağlantısını taşıyabileceği anlamına gelmez.
- Replay saldırılarının bütün varyantlarına karşı kapsamlı güvenlik başarısı ölçülmemiştir.
- IoT, bulut ve veri merkezi sistemlerinde aynı CPU ve gecikme değerlerinin elde edileceği gösterilmemiştir.
- Çalışma Türkiye'deki gerçek ağ trafiği veya DDoS saldırıları üzerinde doğrulama sunmamaktadır.
Çalışmanın Yöntemi ve Bulguları
Deneysel yapı
| Bileşen | Çalışmada kullanılan yapı |
|---|---|
| İşletim sistemi | Kali Linux, Parallels sanal makinesi |
| Ana işletim sistemi | macOS Sonoma 14.3 |
| Fiziksel makine | MacBook Air M1 |
| İşlemci | Apple M1, ARM64 |
| Bellek | 8 GB RAM |
| Programlama dili | Python 3.10 |
| Paket işleme | Scapy |
| Paket analizi | Wireshark ve NOxSYN PCAP Analyzer |
| Kriptografi | HMAC-SHA256 |
| Nonce | Her SYN için 128 bit; os.urandom() ve ek entropi |
| TCP taşıma | Nonce için deneysel TCP seçeneği Kind 254 |
| HMAC çıktısı | TCP sequence number alanı için 32 bite kırpılmıştır |
Kriptografik işlem süresi
Geleneksel ve nonce-geliştirilmiş mekanizma 160 kontrollü tekrar üzerinden karşılaştırılmıştır. Cookie üretiminde nonce-geliştirilmiş sürüm daha kısa ortalama süre verirken doğrulama maliyeti yükselmiştir.
Verianla Live: Geleneksel ve nonce-geliştirilmiş cookie işlem süreleri
Değerler yalnız sunucu tarafındaki kriptografik cookie üretme ve doğrulama işlemlerini kapsar; ağ aktarımı, loglama ve dosya I/O süreleri bu ölçümlere dahil değildir.
| İşlem | Geleneksel (ms) | Nonce-geliştirilmiş (ms) | Kaynak |
|---|---|---|---|
| Ortalama cookie üretimi | 0,0046 | 0,0023 | Tablo 3 |
| Minimum cookie üretimi | 0,0028 | 0,0020 | Tablo 3 |
| Maksimum cookie üretimi | 0,1200 | 0,0263 | Tablo 3 |
| Ortalama doğrulama | 0,0005 | 0,0017 | Tablo 3 |
| Minimum doğrulama | 0,0004 | 0,0016 | Tablo 3 |
| Maksimum doğrulama | 0,0020 | 0,0049 | Tablo 3 |
Verianla Live: Görselleştirme yukarıdaki görünür bilimsel veri tablosundan tarayıcıda oluşturulur. Tablo bilimsel kaynak-of-truth olarak korunur.
Ortalama cookie üretim süresi geleneksel yapıda 0,0046 ms iken nonce-geliştirilmiş yapıda 0,0023 ms ölçülmüştür. Araştırmacılar bu farkı geleneksel RFC 4987 tarzı yapıda gereken MSS indeks hesabı, timestamp counter işlemi ve 32 bitlik ISN bit-packing işlemlerinin nonce-geliştirilmiş prototipte kaldırılmasıyla açıklamaktadır.
Buna karşılık ortalama doğrulama süresi 0,0005 ms'den 0,0017 ms'ye yükselmiştir. Bunun nedeni genişletilmiş ve nonce içeren HMAC girdisinin yeniden hesaplanmasıdır. Her iki değer de mutlak olarak 1 ms'nin çok altında olsa da “nonce hiçbir maliyet getirmiyor” sonucu çıkarılamaz.
İstemci tarafı ölçülen gecikme
| Ölçüt | Nonce-geliştirilmiş mekanizma |
|---|---|
| Tamamlanan handshake | 5 |
| Ortalama RTT | 112,0422 ms |
| Minimum RTT | 98,7142 ms |
| Maksimum RTT | 123,5973 ms |
| Standart sapma | 10,3695 ms |
| Ortalama CPU | %8,86 |
Tablo 4'te istemci tarafından gözlenen ortalama uçtan uca RTT 112,0422 ms'dir. Bu değer HMAC hesaplama süresiyle karıştırılmamalıdır; ağ ve deney ortamının tamamındaki el sıkışma gecikmesini temsil eder.
SYN flood altında CPU maliyeti
İki mekanizma 1120 sahte SYN paketi ve sekiz meşru handshake girişiminin birlikte bulunduğu yük altında değerlendirilmiştir.
| Senaryo | Geleneksel RFC 4987 tarzı (%) | Nonce-geliştirilmiş (%) |
|---|---|---|
| Sunucu tarafı işlem | <1 | 31,35 |
| İstemci tarafı işlem | <1 | 8,86 |
Nonce-geliştirilmiş mekanizmanın sunucu tarafı CPU tüketimindeki artış çalışmanın en önemli performans bedellerinden biridir. Her gelen SYN için güvenli nonce üretimi, genişletilmiş HMAC işlemi ve nonce eşleme tablosuna giriş oluşturulması bu farkın temel nedenleri arasında gösterilmektedir.
Saf kriptografik throughput
| Ölçüt | Geleneksel | Nonce-geliştirilmiş |
|---|---|---|
| Ölçülen tekrar | 160 | 160 |
| Toplam kriptografik süre | 0,8123 ms | 0,6439 ms |
| Hesaplanan bağlantı/s | 196.970,59 | 248.495,44 |
Nonce-geliştirilmiş mekanizma saf kriptografik zaman üzerinden yaklaşık 248.495 bağlantı/s, geleneksel yöntem ise yaklaşık 196.971 bağlantı/s teorik işleme kapasitesi göstermiştir. Bu sonuç ilk bakışta CPU tablosuyla çelişkili görünebilir; ancak iki ölçüm aynı şeyi ölçmemektedir. CPU deneyi 1120 SYN içeren sürdürülen flood yükünün tüm işleme maliyetini kapsarken throughput hesabı ağ aktarımı ve flood işleme yükü hariç tutularak 160 kontrollü kriptografik tekrar üzerinden hesaplanmıştır.
Bu nedenle 248.495 bağlantı/s değeri gerçek ağ throughput'u değildir. Çalışmanın kendisi bu değeri saf kriptografik işlemin teorik üst sınırı olarak tanımlamakta ve sonucun Python kullanıcı alanı ile Apple M1 ARM64 platformuna özgü olabileceğini belirtmektedir.
Kaynak içindeki ölçüm uyuşmazlığı
Performans bölümünde ayrıca dikkat edilmesi gereken bir raporlama farkı vardır. İstemci gecikmelerinin verildiği Tablo 4, nonce-geliştirilmiş mekanizma için beş tamamlanmış handshake bildirirken throughput tartışmasının sonunda her iki mekanizmanın da sekiz meşru handshake'in tamamını başarıyla doğruladığı belirtilmektedir. Çalışma bu beş ve sekiz handshake değerlerinin farklı alt deneyler, ölçüm pencereleri veya örneklem grupları arasındaki ilişkisini ayrıntılı biçimde açıklamamaktadır. Bu nedenle iki değer tek bir deney sonucuna dönüştürülmemelidir.
Kaynak ve Yöntem Notu
Tam özgün çalışma adı: Enhancing SYN Cookie Security Against DDoS Attacks: Mitigating Replay Attacks with Nonce Implementation
Yazarlar: Nazar Abbas Saqib; Haifa Alobiad; Layan Alsuliman; Tala Almulla.
Yazar sırası: Kaynak çalışmadaki sıra aynen korunmuştur.
Eş birinci yazar/eş katkı: Kaynakta eş birinci yazarlık işareti belirtilmemektedir.
Sorumlu yazar: Nazar Abbas Saqib.
Kurumlar: SAUDI ARAMCO Cybersecurity Chair, Department of Networks and Communications, College of Computer Science and Information Technology, Imam Abdulrahman Bin Faisal University; College of Computer Science and IT, Imam Abdulrahman Bin Faisal University, Dammam, Suudi Arabistan.
Dergi: Future Internet.
Yayınevi: MDPI, Basel, Switzerland.
Cilt / sayı / makale numarası: 18 / 6 / 323.
DOI: 10.3390/fi18060323
Alınma tarihi: 17 Nisan 2026.
Revizyon tarihi: 6 Haziran 2026.
Kabul tarihi: 8 Haziran 2026.
Yayın tarihi: 15 Haziran 2026.
Kaynak türü: Hakemli araştırma makalesi; kontrollü laboratuvar/simülasyon temelli ağ güvenliği ve performans değerlendirmesi.
Hakemlik durumu: Hakemli yayın.
Lisans: Creative Commons Attribution (CC BY).
Resmî yayın bağlantısı:https://doi.org/10.3390/fi18060323
Finansman: Yazarlar, projenin SAUDI ARAMCO Cybersecurity Chair, Imam Abdulrahman Bin Faisal University tarafından finanse edildiğini bildirmektedir.
Veri erişilebilirliği: NOxSYN simülasyon framework'ünün çalışma tarafından verilen GitHub deposunda herkese açık olduğu belirtilmektedir. Deneylerde oluşturulan PCAP ve JSON veri setlerinin ise makul talep üzerine sorumlu yazardan sağlanabileceği bildirilmektedir.
Çıkar çatışması: Yazarlar çıkar çatışması bildirmemiştir.
Yazar katkıları: Kavramsallaştırma: Nazar Abbas Saqib, Haifa Alobiad ve Layan Alsuliman; yöntem: Nazar Abbas Saqib, Haifa Alobiad ve Layan Alsuliman; yazılım: Haifa Alobiad; doğrulama ve biçimsel analiz: Haifa Alobiad ve Layan Alsuliman; araştırma: Tala Almulla, Haifa Alobiad ve Layan Alsuliman; kaynaklar ve veri kürasyonu: Haifa Alobiad; ilk taslak: Haifa Alobiad ve Layan Alsuliman; inceleme ve düzenleme: Nazar Abbas Saqib ve Tala Almulla; görselleştirme: Haifa Alobiad; danışmanlık ve proje yönetimi: Nazar Abbas Saqib.
Bilimsel yöntem sınırı: Çalışma üretim sınıfı bir TCP/IP çekirdeğinde gerçekleştirilmemiştir. NOxSYN kullanıcı alanında çalışan Python tabanlı bir prototiptir ve testler aynı fiziksel Apple M1 bilgisayarındaki sanal makinelerde yürütülmüştür. Başarılı ACK sonrası gerçek TCP socket yaşam döngüsü oluşturulmadığı için tam bağlantı ve kaynak tüketimi davranışı ölçülmemiştir. Replay saldırılarına karşı kapsamlı replay detection rate, replay success rate, false acceptance rate veya false rejection rate ölçümleri de mevcut değerlendirmede bulunmamaktadır.
Stateless terminolojisi hakkında kaynak notu: Çalışma çeşitli yerlerde mekanizmayı stateless olarak tanımlamakla birlikte yöntem bölümünde bağlantı parametreleri ile nonce arasında kısa ömürlü bir sunucu tarafı eşleme tablosu tutulduğu açıkça belirtilmektedir. Bu nedenle burada sistem, klasik SYN cookie ile aynı anlamda tamamen durumsuz olarak değil; tam handshake durumunu saklamayan, ancak replay direnci amacıyla minimal ve geçici nonce durumu kullanan bir mekanizma olarak aktarılmıştır.
Formül tutarlılığı hakkında kaynak notu: Çalışmanın erken saldırı simülasyonu bölümündeki bir HMAC gösteriminde nonce açıkça bulunmazken uygulanan framework'ün sonraki denklemlerinde nonce HMAC girdisine dahil edilmiştir. Bu farklılık sessizce düzeltilmemiş; uygulanan mekanizmanın açıklamasında sonraki yöntem bölümlerindeki nonce içeren formül esas alınmış ve tutarsızlık ayrıca belirtilmiştir.
Sonuçların kapsamı: Bilimsel içerik bu çalışmanın yöntem, deney ve bulgularına dayanılarak hazırlanmıştır. Dış kaynaklardan yeni deneysel bulgu veya performans sonucu eklenmemiştir. Çalışma nonce tabanlı replay korumasının uygulanabilirliğine ilişkin prototip ve performans kanıtı sunmaktadır; gerçek internet ölçeğinde veya üretim çekirdeğinde kapsamlı DDoS güvenlik başarısı kanıtı sunmamaktadır.

Bir yorum bırakın
E-posta adresiniz yayınlanmayacaktır. Gerekli alanlar * ile işaretlenmiştir