Utafiti unachunguza kuimarisha uthibitishaji dhidi ya mashambulizi ya replay kwa kuongeza HMAC-SHA256, muhuri wa muda na nonce inayozalishwa kwa kila muunganisho kwenye utaratibu wa kawaida wa SYN cookie unaotumika katika mashambulizi ya SYN flood yanayolenga mchakato wa TCP wa kupeana mikono kwa hatua tatu. Kwa kusudi hili, watafiti walitengeneza mazingira maalumu ya uigaji ya NOxSYN yanayotegemea Python na wakalinganisha mbinu ya kawaida ya SYN cookie ya mtindo wa RFC 4987 na mfumo ulioboreshwa kwa nonce katika mazingira yale yale yaliyodhibitiwa. Katika utaratibu ulioboreshwa kwa nonce, wastani wa muda wa kutengeneza cookie ulipimwa kuwa 0,0023 ms na wastani wa muda wa uthibitishaji kuwa 0,0017 ms; shughuli zote za kriptografia zilibaki chini ya 1 ms kwa kila muunganisho. Hata hivyo, utafiti haukufanywa kwenye safu ya TCP/IP ya kiwango cha uzalishaji, bali kwenye prototipu ya maabara iliyobainishwa kwa mashine pepe na inayofanya kazi katika user space, na ufanisi wa usalama dhidi ya aina tofauti za mashambulizi ya replay haukupimwa kwa vipimo vya usalama vya kina.

Matokeo muhimu ya utafiti si tu kupendekeza “SYN cookie salama zaidi”. Utafiti unaonyesha kuwa inawezekana kuunganisha vigezo vya muunganisho na nonce ya muda mfupi pamoja na HMAC; lakini pia unaonyesha kwamba hili si sawa na gharama ndogo sana ya uchakataji ya mbinu ya kawaida ya SYN cookie. Chini ya mzigo endelevu wa SYN flood, matumizi yaliyorekebishwa ya CPU upande wa seva katika utaratibu ulioboreshwa kwa nonce yalifikia %31,35, ilhali katika mbinu ya kawaida thamani hiyo ilibaki chini ya %1. Kwa hiyo, gharama ya kuzalisha nonce, hesabu iliyopanuliwa ya HMAC na jedwali la muda la nonce lililoongezwa kwa ajili ya ukinzani dhidi ya replay haiwezi kupuuzwa.

Kwa mtazamo wa Uturuki: Matokeo yanaweza kutoa mbinu ya kiufundi ya kuboresha ulinzi dhidi ya SYN flood katika vituo vya data, huduma za wingu, mitandao ya mashirika, miundombinu ya watoa huduma na mifumo ya IoT nchini Uturuki; hata hivyo, utafiti hauna data ya trafiki ya mtandao au miundombinu mahususi ya Uturuki. Haitakuwa sahihi kuhamisha moja kwa moja thamani za utendaji katika utafiti huu kwenda kwenye mifumo ya ndani. Kwa matumizi halisi nchini Uturuki, uthibitishaji upya unahitajika kwa utekelezaji katika kiwango cha kernel ya Linux, usanifu tofauti wa prosesa, hali halisi za routing, mitandao tofauti ya ISP na vyanzo vya mashambulizi vilivyosambazwa.

Tatizo kuu la utafiti ni nini?

Muunganisho wa TCP kwa kawaida huanzishwa kwa mchakato wa kupeana mikono wa hatua tatu kati ya mteja na seva: mteja hutuma SYN, seva hujibu kwa SYN-ACK, na mwishowe mteja hutuma ACK. Seva ya kawaida inaweza kuhifadhi kwa muda taarifa za hali ya muunganisho kabla ACK ya mwisho haijafika. Idadi kubwa ya maombi ya SYN ya kughushi au yasiyokamilishwa yanapotumwa, miunganisho hii iliyo nusu wazi inaweza kutumia rasilimali za seva; huu ndio utaratibu msingi wa shambulizi la SYN flood.

Mbinu ya SYN cookie hupunguza tatizo hili kwa kusimba taarifa zinazohitajika kwenye namba ya mwanzo ya mfuatano wa TCP badala ya kuhifadhi hali ya muunganisho ulio nusu wazi kwenye seva. ACK inapofika kutoka kwa mteja, seva huthibitisha cookie na huunda muunganisho baada ya hapo tu. Hivyo, si lazima kutenga hali ya muunganisho kwa namna ya kawaida kwa michakato ya kupeana mikono iliyoachwa bila kukamilika.

Tatizo la pili ambalo watafiti wanazingatia ni replay, yaani kutumia tena thamani ya uthibitishaji ambayo ilikuwa halali hapo awali. Ikiwa cookie ya kawaida haina upekee wa kutosha unaohusiana na muunganisho ndani ya dirisha lake la muda, kutumia tena thamani iliyowahi kuonekana kunaweza kinadharia kuunda eneo jipya la shambulizi. Muundo uliopendekezwa unalenga kuunganisha kila jaribio la muunganisho na nonce katika hatua hii.

Kwa nini nonce na HMAC hutumika pamoja?

Nonce ni thamani ya kipekee au ya muda mfupi inayotumika kwa shughuli fulani ya itifaki. Katika utafiti huu, lengo ni kuunda nonce salama kwa njia ya kriptografia kwa kila ombi la SYN na kuijumuisha katika uthibitishaji wa muunganisho. Hivyo, thamani za uthibitishaji zinazozalishwa na vigezo vilevile vya muunganisho katika nyakati tofauti zinakusudiwa kutofautishwa.

HMAC-SHA256 nayo huunganisha ufunguo wa siri na vigezo vya muunganisho ili kuzalisha msimbo wa uthibitishaji unaoweza kuhakikiwa. Uhusiano msingi katika sehemu ya utafiti inayoeleza mfumo uliotekelezwa ni kama ifuatavyo:

\[ SYN\_Cookie = HMAC(K, ClientIP \parallel Port \parallel T \parallel N) \]

Hapa K inawakilisha ufunguo wa siri, T muhuri wa muda na N thamani ya nonce. Kwa kuwa namba ya mfuatano wa TCP ina 32 bit pekee, katika utafiti huu matokeo ya HMAC-SHA256 ya 256 bit hukatwa hadi 32 bit:

\[ Cookie = Truncate_{32}\left(HMAC(K, IP \parallel Port \parallel T \parallel N)\right) \]

Ukataji huu huruhusu cookie kuwekwa kwenye sehemu ya namba ya mfuatano wa TCP. Usalama hautegemei matokeo ya 32 bit pekee; ufunguo wa siri, uhalali uliozuiliwa na muda na mzunguko wa maisha wa nonce hutumika pamoja.

Kwa nini tofauti ya fomula ndani ya chanzo ni muhimu?

Katika sehemu ya awali ya uigaji wa shambulizi, mfano mmoja wa usemi wa HMAC unajumuisha IP ya mteja, port ya mteja, IP ya seva, port ya seva na muhuri wa muda, lakini hauonyeshi wazi thamani ya nonce. Kinyume chake, katika sehemu zinazofuata zinazoeleza kwa kina utaratibu uliotekelezwa, nonce N ni sehemu ya moja kwa moja ya ingizo la HMAC. Aidha, maelezo mengine yanasema kwamba taarifa za IP/port za mteja na seva zitatumika pamoja, ilhali fomula fupi inayofuata inaonyesha IP, port, muhuri wa muda na nonce pekee. Kwa hiyo, chanzo hakina uthabiti kamili wa notation katika uwasilishaji wa ingizo la HMAC. Mantiki msingi ya utaratibu uliotekelezwa, kama inavyoelezwa katika sehemu zinazofuata za mbinu, ni kuunganisha nonce na hesabu ya uthibitishaji.

Mchakato ulioboreshwa wa TCP wa kupeana mikono hufanyaje kazi?

Utaratibu ulioonyeshwa na watafiti katika Kielelezo 8 na Kielelezo 9 una hatua nne kuu za uthibitishaji. Baada ya seva kupokea ombi la SYN, huzalisha nonce na kukokotoa cookie inayotegemea HMAC. Cookie huwekwa katika namba ya mfuatano wa TCP ya paketi ya SYN-ACK, huku nonce ikiwekwa katika chaguo la majaribio la TCP kwenye prototipu ya utafiti. Mteja hujibu kwa mantiki ya kawaida ya ACK bila kujua muundo wa ndani wa cookie. Kisha seva hukagua uhalali wa nonce na thamani ya HMAC iliyokokotolewa upya.

Verianla Live: Mwonekano huu wa mchakato huundwa kwenye kivinjari kutoka kwenye jedwali la data ya kisayansi linaloonekana hapo juu. Jedwali huhifadhiwa kama source-of-truth ya kisayansi.

Je, mfumo ni stateless kabisa?

Katika hatua hii, istilahi zinazotumiwa na utafiti zinahitaji kusomwa kwa uangalifu. Faida kuu ya SYN cookie ya kawaida ni kwamba haihifadhi hali ya muunganisho upande wa seva kwa kila muunganisho ulio nusu wazi. Mfumo uliopendekezwa pia hauhifadhi hali kamili ya muunganisho wa TCP; hata hivyo, hufuatilia thamani za nonce kwa muda mfupi ili kuzuia replay ndani ya dirisha lilelile la uhalali.

Sehemu ya mbinu inaeleza wazi kwamba nonce yenye entropy kubwa huzalishwa kwa kila SYN inayoingia na kwamba jedwali la muda la ulinganishaji huhifadhiwa kati ya vigezo vya muunganisho vya mteja na nonce. Baada ya uthibitishaji uliofanikiwa wa ACK, nonce hufutwa mara moja; ikiwa uthibitishaji utashindwa, ingizo nalo huondolewa.

Kwa hiyo, si sahihi kuutathmini utaratibu huu kama muundo “usioweka hali yoyote” kwa maana ileile ya SYN cookie ya kawaida. Ufafanuzi sahihi zaidi ni kwamba ni muundo usiohifadhi hali kamili ya muunganisho lakini unaotumia hali ndogo na ya muda mfupi ya nonce kwa ajili ya ukinzani dhidi ya replay. Utafiti wenyewe pia unaweka mpaka huu katika sehemu zinazofuata kwa kauli “core stateless philosophy”.

NOxSYN ni nini?

NOxSYN ni mazingira maalumu ya uigaji yaliyotengenezwa na watafiti kwa Python 3.10 ndani ya utafiti huu. Si framework ya madhumuni ya jumla ya nje au iliyochapishwa hapo awali. Ina moduli nne kuu:

• SYN Cookie Server: hutengeneza na kuthibitisha cookie kwa kutumia HMAC-SHA256 na nonce.
• Legitimate Client: hutekeleza mchakato wa kawaida wa TCP wa kupeana mikono kwa hatua tatu.
• SYN Flooding Module: huzalisha kiasi kikubwa cha paketi za SYN za kughushi.
• PCAP Analyzer: huchunguza jozi za paketi na tabia ya uthibitishaji baada ya jaribio.

Vipengele vya Python vya hmac, hashlib na scapy vilitumika kwa hesabu za kriptografia na uundaji wa paketi. Kwa kila ombi la SYN, 128 bit nonce iliundwa, na os.urandom() pamoja na entropy ya ziada zilitumika katika utengenezaji wa nonce. Katika prototipu, nonce ilisafirishwa kupitia chaguo la majaribio la TCP la Kind 254 na kuhifadhiwa katika jedwali la muda la ulinganishaji kulingana na taarifa ya IP/port ya mteja.

Data za paketi na log zilithibitishwaje?

Watafiti hawakutegemea matokeo ya console pekee. Wakati wa majaribio, trafiki ilirekodiwa katika muundo wa PCAP; paketi za SYN, HMAC cookie zilizokatwa ndani ya SYN-ACK, paketi za ACK na trafiki ya SYN flood zilichunguzwa katika kiwango cha paketi. Kielelezo 11 cha utafiti kinaonyesha kupitia Wireshark mahali cookie ilipo katika sehemu ya TCP sequence number ya paketi ya SYN-ACK.

NOxSYN pia ilizalisha log za JSON. Rekodi hizi zina muhuri wa muda, anwani ya IP ya mteja, port ya mteja, thamani ya hexadecimal nonce na HMAC cookie iliyokatwa inayolingana nayo. Watafiti walijaribu kuthibitisha utengenezaji wa cookie na upekee wa nonce kwa kulinganisha rekodi za JSON na data za PCAP.

Mazingira ya majaribio yana uhalisia kiasi gani?

Mazingira ya majaribio yalikuwa na mashine pepe mbili za Kali Linux. Mashine hizo pepe ziliendeshwa ndani ya Parallels Desktop kwenye MacBook Air yenye Apple M1 ARM64, 8 GB RAM na macOS Sonoma 14.3. Mashine moja pepe ilikuwa seva, na nyingine ilikuwa na majukumu mawili: mteja halali na mshambuliaji wa SYN flood.

Muundo huu ni muhimu kwa jaribio linalodhibitiwa na linaloweza kurudiwa; hata hivyo, hauwakilishi botnet kubwa, watoa huduma tofauti wa intaneti, idadi kubwa ya vyanzo huru vya mashambulizi, asymmetry halisi za routing au vifaa vya seva vya kiwango cha uzalishaji.

Ni zipi nguvu za utafiti?

• Pendekezo halikuachwa katika kiwango cha dhana pekee; lilitekelezwa katika prototipu ya NOxSYN iliyoundwa mahsusi kwa utafiti.
• Utaratibu wa kawaida wa SYN cookie wa mtindo wa RFC 4987 pia ulitekelezwa tofauti kama msingi wa kulinganisha.
• Utengenezaji wa cookie, muda wa uthibitishaji, matumizi ya CPU na throughput safi ya kriptografia vilipimwa kando.
• Uthibitishaji wa kiwango cha paketi na kiwango cha programu ulitumika pamoja kwa rekodi za PCAP na JSON.
• Mzunguko wa maisha wa nonce na kubatilishwa kwake baada ya uthibitishaji uliofanikiwa uliigwa wazi.
• Watafiti walikubali wazi kama mapungufu masuala ya prototipu ya user space, virtualization na uwezekano wa kuhamisha matokeo kwenda mazingira ya uzalishaji.

Ni yapi mapungufu makuu ya utafiti?

Kwanza, NOxSYN si utekelezaji wa SYN cookie uliounganishwa kwenye kernel halisi ya mfumo wa uendeshaji. Msimbo wa Python katika user space hauigi usimamizi halisi wa TCP backlog, jedwali za miunganisho za kernel, mzunguko wa maisha wa socket, uchakataji wa zero-copy, interrupt coalescing au uboreshaji wa kernel fast-path.

Pili, seva haiundi socket halisi baada ya ACK iliyofanikiwa na kuendesha kikao kamili cha TCP. Kwa hiyo, utafiti hujaribu hasa uthibitishaji wa cookie; haupimi hali ya muunganisho wa muda mrefu, matumizi halisi ya kumbukumbu au mzunguko kamili wa maisha wa muunganisho.

Tatu, HMAC-SHA256 na utengenezaji wa nonce salama kwa kila SYN huleta gharama ya ziada ya uchakataji. Ingawa gharama hii ilibaki katika kiwango kinachoweza kudhibitiwa katika jaribio lililodhibitiwa, haijaonyeshwa kwamba matokeo yale yale yangepatikana katika mashambulizi makubwa zaidi ya volumetric au kwenye vifaa vya IoT vyenye rasilimali chache.

Nne, na muhimu zaidi kwa tafsiri ya usalama, utafiti haukufanya tathmini ya kina ya kiasi kuhusu mashambulizi ya replay. Vipimo kama replay detection rate, replay success rate, false acceptance rate na false rejection rate havikuripotiwa katika majaribio ya sasa ya utafiti.

Tano, mteja na mshambuliaji wanafanya kazi kwenye mashine pepe zilizo kwenye kompyuta ileile ya kimwili. Hali hii haiwakilishi utofauti wa IP za chanzo katika ulimwengu halisi, njia zenye asymmetry, ucheleweshaji wa mtandao au washambuliaji waliosambazwa kijiografia.

Utafiti unaunga mkono nini, na hauungi mkono nini?

Matokeo yanayoungwa mkono na utafiti:

• Matumizi ya nonce, muhuri wa muda na HMAC yaliweza kutekelezwa katika mtiririko wa uthibitishaji wa SYN cookie kwenye prototipu ya NOxSYN.
• Michakato halali ya kupeana mikono iliweza kuthibitishwa chini ya mzigo uliodhibitiwa wa SYN flood.
• Nyakati zilizopimwa za shughuli za kriptografia upande wa seva zilibaki chini ya 1 ms kwa kila muunganisho.
• Kufuatilia nonce kama thamani ya matumizi ya mara moja kuliunda safu ya ziada ya uthibitishaji dhidi ya replay.
• Utekelezaji wa muundo ulioboreshwa una gharama inayoweza kupimwa kwa upande wa uchakataji na usimamizi wa hali.

Matokeo ambayo utafiti hauungi mkono au bado haujayajaribu:

• Haijaonyeshwa kwamba mashambulizi ya DDoS katika kiwango halisi cha intaneti yamezuiwa kwa uhakika.
• Utendaji huohuo haujathibitishwa katika Linux ya kiwango cha kernel au safu nyingine za TCP/IP za uzalishaji.
• Throughput safi ya kriptografia ya takriban miunganisho 248 elfu/sekunde haimaanishi kwamba seva halisi ya mtandao inaweza kubeba idadi hiyo hiyo ya miunganisho ya TCP.
• Mafanikio ya kina ya usalama dhidi ya aina zote za mashambulizi ya replay hayajapimwa.
• Haijaonyeshwa kwamba thamani zilezile za CPU na ucheleweshaji zitapatikana katika mifumo ya IoT, wingu na vituo vya data.
• Utafiti hauwasilishi uthibitishaji kwenye trafiki halisi ya mtandao au mashambulizi ya DDoS nchini Uturuki.

Mbinu na Matokeo ya Utafiti

Muundo wa majaribio

Muda wa uchakataji wa kriptografia

Utaratibu wa kawaida na ule ulioboreshwa kwa nonce ulilinganishwa katika marudio 160 yaliyodhibitiwa. Katika utengenezaji wa cookie, toleo lililoboreshwa kwa nonce lilitoa wastani mfupi zaidi wa muda, huku gharama ya uthibitishaji ikiongezeka.

Verianla Live: Uonyeshaji huundwa kwenye kivinjari kutoka kwenye jedwali la data ya kisayansi linaloonekana hapo juu. Jedwali huhifadhiwa kama source-of-truth ya kisayansi.

Wastani wa muda wa kutengeneza cookie ulipimwa kuwa 0,0046 ms katika muundo wa kawaida na 0,0023 ms katika muundo ulioboreshwa kwa nonce. Watafiti wanaeleza tofauti hii kwa kuondolewa katika prototipu iliyoboreshwa kwa nonce kwa hesabu ya faharasa ya MSS, operesheni ya timestamp counter na operesheni za 32 bit za ISN bit-packing zinazohitajika katika muundo wa kawaida wa mtindo wa RFC 4987.

Kwa upande mwingine, wastani wa muda wa uthibitishaji uliongezeka kutoka 0,0005 ms hadi 0,0017 ms. Sababu ni kukokotoa upya ingizo lililopanuliwa la HMAC linalojumuisha nonce. Ingawa thamani zote mbili kwa ukubwa kamili ziko chini sana ya 1 ms, haiwezi kuhitimishwa kwamba “nonce haina gharama yoyote”.

Ucheleweshaji uliopimwa upande wa mteja

Katika Jedwali 4, wastani wa RTT wa mwisho-hadi-mwisho unaoonekana upande wa mteja ni 112,0422 ms. Thamani hii haipaswi kuchanganywa na muda wa kukokotoa HMAC; inawakilisha ucheleweshaji wa mchakato wa kupeana mikono katika mtandao na mazingira yote ya majaribio.

Gharama ya CPU chini ya SYN flood

Utaratibu huu miwili ilitathminiwa chini ya mzigo uliokuwa na paketi 1120 za SYN za kughushi na majaribio manane halali ya handshake kwa pamoja.

Ongezeko la matumizi ya CPU upande wa seva katika utaratibu ulioboreshwa kwa nonce ni mojawapo ya gharama muhimu zaidi za utendaji katika utafiti. Kutengeneza nonce salama kwa kila SYN inayoingia, kufanya operesheni iliyopanuliwa ya HMAC na kuunda ingizo katika jedwali la ulinganishaji wa nonce zinaonyeshwa kuwa miongoni mwa sababu kuu za tofauti hii.

Throughput safi ya kriptografia

Kwa kuzingatia muda safi wa kriptografia, utaratibu ulioboreshwa kwa nonce ulionyesha uwezo wa kinadharia wa takriban miunganisho 248.495/s, huku mbinu ya kawaida ikionyesha takriban miunganisho 196.971/s. Kwa mtazamo wa kwanza matokeo haya yanaweza kuonekana kupingana na jedwali la CPU; lakini vipimo hivyo viwili havipimi kitu kilekile. Jaribio la CPU linajumuisha gharama zote za uchakataji wa mzigo endelevu wa flood wenye SYN 1120, ilhali hesabu ya throughput ilifanywa kwa marudio 160 ya kriptografia yaliyodhibitiwa baada ya kuondoa usafirishaji wa mtandao na mzigo wa uchakataji wa flood.

Kwa hiyo, thamani ya miunganisho 248.495/s si throughput halisi ya mtandao. Utafiti wenyewe unaifafanua thamani hii kama kikomo cha juu cha kinadharia cha uchakataji safi wa kriptografia na unaeleza kwamba matokeo yanaweza kuwa mahususi kwa Python katika user space na jukwaa la Apple M1 ARM64.

Kutolingana kwa vipimo ndani ya chanzo

Katika sehemu ya utendaji pia kuna tofauti ya kuripoti inayohitaji kuzingatiwa. Jedwali 4, linalotoa ucheleweshaji wa mteja, linaripoti handshake tano zilizokamilika kwa utaratibu ulioboreshwa kwa nonce, ilhali mwishoni mwa mjadala wa throughput inaelezwa kwamba utaratibu wote miwili uliweza kuthibitisha kwa mafanikio handshake zote nane halali. Utafiti hauelezi kwa kina uhusiano kati ya thamani hizi za handshake tano na nane katika majaribio madogo tofauti, madirisha ya vipimo au makundi ya sampuli. Kwa hiyo, thamani hizo mbili hazipaswi kuunganishwa kuwa matokeo ya jaribio moja.

Maelezo ya Chanzo na Mbinu

Jina kamili la asili la utafiti: Enhancing SYN Cookie Security Against DDoS Attacks: Mitigating Replay Attacks with Nonce Implementation

Waandishi: Nazar Abbas Saqib; Haifa Alobiad; Layan Alsuliman; Tala Almulla.

Mpangilio wa waandishi: Mpangilio katika utafiti wa chanzo umehifadhiwa kama ulivyo.

Waandishi wenza wa kwanza/mchango sawa: Chanzo hakionyeshi alama ya uandishi wa kwanza kwa usawa.

Mwandishi wa mawasiliano: Nazar Abbas Saqib.

Taasisi: 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, Saudi Arabia.

Jarida: Future Internet.

Mchapishaji: MDPI, Basel, Switzerland.

Juzuu / toleo / namba ya makala: 18 / 6 / 323.

DOI: 10.3390/fi18060323

Tarehe ya kupokelewa: 17 Aprili 2026.

Tarehe ya marekebisho: 6 Juni 2026.

Tarehe ya kukubaliwa: 8 Juni 2026.

Tarehe ya kuchapishwa: 15 Juni 2026.

Aina ya chanzo: Makala ya utafiti iliyopitiwa na wataalamu; tathmini ya usalama wa mtandao na utendaji inayotegemea maabara/uingaji uliodhibitiwa.

Hali ya mapitio: Chapisho lililopitiwa na wataalamu.

Leseni: Creative Commons Attribution (CC BY).

Kiungo rasmi cha chapisho:https://doi.org/10.3390/fi18060323

Ufadhili: Waandishi wanaripoti kwamba mradi ulifadhiliwa na SAUDI ARAMCO Cybersecurity Chair, Imam Abdulrahman Bin Faisal University.

Upatikanaji wa data: Framework ya uigaji ya NOxSYN inaelezwa kuwa inapatikana kwa umma katika hifadhi ya GitHub iliyotolewa na utafiti. Seti za data za PCAP na JSON zilizoundwa katika majaribio zinaripotiwa kuwa zinaweza kupatikana kutoka kwa mwandishi wa mawasiliano kwa ombi linalofaa.

Mgongano wa maslahi: Waandishi hawakuripoti mgongano wa maslahi.

Michango ya waandishi: Uundaji wa dhana: Nazar Abbas Saqib, Haifa Alobiad na Layan Alsuliman; mbinu: Nazar Abbas Saqib, Haifa Alobiad na Layan Alsuliman; programu: Haifa Alobiad; uthibitishaji na uchambuzi rasmi: Haifa Alobiad na Layan Alsuliman; uchunguzi: Tala Almulla, Haifa Alobiad na Layan Alsuliman; rasilimali na uratibu wa data: Haifa Alobiad; rasimu ya kwanza: Haifa Alobiad na Layan Alsuliman; mapitio na uhariri: Nazar Abbas Saqib na Tala Almulla; uonyeshaji: Haifa Alobiad; usimamizi na usimamizi wa mradi: Nazar Abbas Saqib.

Kikomo cha mbinu ya kisayansi: Utafiti haukufanywa kwenye kernel ya TCP/IP ya kiwango cha uzalishaji. NOxSYN ni prototipu inayotegemea Python inayofanya kazi katika user space, na majaribio yalifanywa katika mashine pepe kwenye kompyuta ileile ya kimwili ya Apple M1. Kwa kuwa mzunguko halisi wa maisha wa TCP socket haukuundwa baada ya ACK iliyofanikiwa, tabia kamili ya muunganisho na matumizi ya rasilimali haikupimwa. Vipimo vya kina vya replay detection rate, replay success rate, false acceptance rate au false rejection rate dhidi ya mashambulizi ya replay pia havipo katika tathmini ya sasa.

Maelezo ya chanzo kuhusu istilahi ya stateless: Ingawa utafiti unafafanua utaratibu kama stateless katika sehemu kadhaa, sehemu ya mbinu inaeleza wazi kwamba jedwali la muda mfupi la ulinganishaji upande wa seva huhifadhiwa kati ya vigezo vya muunganisho na nonce. Kwa hiyo, hapa mfumo hauwasilishwi kama usio na hali kabisa kwa maana ileile ya SYN cookie ya kawaida; badala yake, unaelezwa kama utaratibu usiohifadhi hali kamili ya handshake lakini unaotumia hali ndogo na ya muda ya nonce kwa lengo la ukinzani dhidi ya replay.

Maelezo ya chanzo kuhusu uthabiti wa fomula: Ingawa nonce haionyeshwi wazi katika usemi mmoja wa HMAC katika sehemu ya mapema ya uigaji wa shambulizi, katika milinganyo inayofuata ya framework iliyotekelezwa nonce imejumuishwa katika ingizo la HMAC. Tofauti hii haijasahihishwa kimya kimya; maelezo ya utaratibu uliotekelezwa yanatumia kama msingi fomula yenye nonce katika sehemu zinazofuata za mbinu, na kutolingana huko pia kumeelezwa kando.

Upeo wa matokeo: Maudhui ya kisayansi yameandaliwa kwa kutegemea mbinu, majaribio na matokeo ya utafiti huu. Hakuna matokeo mapya ya majaribio au utendaji yaliyoongezwa kutoka vyanzo vya nje. Utafiti unatoa ushahidi wa prototipu na utendaji kuhusu uwezekano wa kutekeleza ulinzi dhidi ya replay unaotegemea nonce; haujatoi ushahidi wa mafanikio ya kina ya usalama wa DDoS katika kiwango halisi cha intaneti au kwenye kernel ya uzalishaji.