Ühel kaunil kevadeõhtul, kui koju minna ei soovinud ja uutmoodi elamisrõõm püsivalt sügeles ning lõi nagu kuum raud, tekkis mõte uurida ahvatlevat funktsiooni tulemüüres nimega «IP DOS poliitika«.
Pärast eelnevaid katsumusi ja juhendiga tutvumist seadistasin režiimis Pass-and-Log, et vaadata, milline on väljaanne ja selle seadistuse kahtlane kasulikkus.
Mõne päeva pärast (et statistika koguneks, muidugi, mitte et oleksin unustanud) vaatasin logisid ja tantsides käsi plaksutades — kirjeid oli kogunenud enam kui piisavalt. Tundus, et võiks ju lihtsasti edasi minna — lülita poliitika sisse, et blokeerida kõik, kes spämmi saadavad, skaneerivad, seadistavad poolikuna seansse, millel on üks tunni pikkune keeld, ja maga rahulikult, teades, et piir on lukus. Kuid 34. eluaasta on ületanud nooruslikku maksimumi ja kuskil peanaha taga kostus nõrk häälekene: «Aga vaatame, kelle aadresse meie armastatud tulemüür on tuvastanud kui pahatahtlikke spämmi saatjaid? Nii lihtsalt, mõtte mängimiseks.»
Alustame saadud andmete analüüsimist anomaaliate nimekirjast. Käitan aadresse läbi lihtsa skripti Powershell ja silmad jäävad pidama tuttavatele tähtedele google.
Hõõrun silmi, pilgutan viis minutit, et veenduda, et mulle ei tundunud — tõepoolest, nende hulgas, keda tulemüür pidas pahatahtlikuks spämmi saatjaks, rünnakutüüp — udp tulv, aadressid, mis kuuluvad headuse korporatsioonile.
Kratsin kukalt, samal ajal seadistades välisel liidesel pakettide salvestamist edasiseks analüüsiks. Peas jooksevad värvilised mõtted: «Kuidas nii, et midagi nakatunud Google'i ulatuses? Ja seda avastasin mina? See on ju, see on ju — auhinnad, tunnustused ja punane vaip, ja oma kasiino blackjackiga ja, noh, te saite aru…»
Lähen saadud faili läbi Wireshark-iga.
Jah, tõepoolest, aadressilt, mis kuulub Google paukavad UDP paketid 443 portilt minu seadmes juhuslikule portile.
Aga, oota… Protokoll vahetub UDP . Tundub, et GQUIC.
Semen Semenyč…
Koheselt meenub ettekandja HighLoad Aleksander Tobol «UDP vastu TCP või tuleviku võrgustikust» ().
Ühest küljest tuleb kerge pettumus — ei autasusid, ega tunnustusi. Teiselt poolt on probleem selge, jääb ainult välja mõelda, kuhu ja kui sügavale kaevata.
Mõni minut suhtlemist Heategevuskorporatsiooniga - ja kõik saab õigesse kohta. Püüdes parandada sisu edastamise kiirus, ettevõte Google veel 2012. aastal kuulutas välja protokolli QUIC, mis võimaldab kõrvaldada suure osa TCP puudustest (jah, jah, jah, nendes artiklites - ja räägitakse täiesti revolutsioonilisest lähenemisest, kuid olgem ausad, tahaksime, et kassipiltide laadimine toimuks kiiremini, mitte teie revolutsioonide ja edusammude jutud). Kuidas edasine uurimine näitas, on paljud organisatsioonid nüüd sarnasele edastamise variandile üle minemas.
Probleem minu ja, ma arvan, mitte ainult minu puhul selgus olevat see, et pakette tuleb lõpuks tõeliselt palju ja tulemüür peab neid kui rünnakut.
Lahendusi osutus olevat vähe:
1. Lisada suvandid' DoS poliitika tulemüüris, aadresside ulatus Google. Ainult mõtleminen võimalikest aadresside ulatustest, silm hakkas närviliselt põksuma - mõte lükatud tagasi kui jabur.
2. Tõsta äratustaseme udp tormipoliitika — samuti mitte ideaalne, aga kui keegi tõeliselt pahatahtlik läbi pääseb.
3. Keelata kontaktid sisevõrgust UDP . Tundub, et 443 välissoost.
Lugedes täiendavalt rakendamise ja integreerimise kohta QUIC ja Google Chrome otsustati viimane variant teostada. Asi on selles, et kõikjal armastatud ja halastamatult (ei saa aru, miks, oleks parem, kui see väljakutsuv punapea Firefox-kandmine max. 810 tundi ilus, Google Chrome alguses püüab luua ühendust oma lemmik QUIC, kuid kui imet ei juhtu, naaseb ta tõestatud meetodite juurde nagu TLS, kuigi tunneb selle üle suurt piinlikkust.
Loome tulemüüris teenuse salvestuse QUIC:
Seame üles uue reegli ja paigutame selle kuskile kõrgemale järjestuses.
Pärast reegli aktiveerimist anomaaliate nimekirjas rahu ja rahu, välja arvatud tõeliselt pahatahtlikud rikkumised.
Aitäh kõigile tähelepanu eest.
Kasutatud ressursid:
1.
2.
3.
4.
Allikas: habr.com
