A Variti védelmet fejleszt a botok és DDoS támadások ellen, valamint stressz- és terhelési teszteket is végez. A HighLoad++ 2018 konferencián arról beszélgettünk, hogyan védhetjük meg az erőforrásokat a különféle típusú támadásoktól. Röviden: elkülönítse a rendszer egyes részeit, használjon felhőszolgáltatásokat és CDN-eket, és rendszeresen frissítse. De szakosodott cégek nélkül továbbra sem fog tudni kezelni a védelmet :)
A szöveg elolvasása előtt elolvashatja a rövid absztraktokat .
Ha pedig nem szeretsz olvasni, vagy csak szeretnéd megnézni a videót, akkor riportunk felvétele lent a spoiler alatt.
A riportról videófelvétel
Sok vállalat már tudja, hogyan kell terheléses tesztelést végezni, de nem mindegyik végez stressztesztet. Egyes ügyfeleink úgy gondolják, hogy webhelyük sebezhetetlen, mert nagy terhelésű rendszerrel rendelkeznek, és jól véd a támadásoktól. Megmutatjuk, hogy ez nem teljesen igaz.
Természetesen a tesztek lebonyolítása előtt a megrendelő aláírásával és pecséttel ellátott engedélyét beszerezzük, és segítségünkkel DDoS támadást senki ellen nem hajthatunk végre. A tesztelést az ügyfél által választott időpontban hajtják végre, amikor az erőforrására irányuló forgalom minimális, és a hozzáférési problémák nem érintik az ügyfeleket. Ezen túlmenően, mivel a tesztelés során mindig elromolhat valami, folyamatos kapcsolatban állunk az ügyféllel. Ez lehetővé teszi, hogy ne csak az elért eredményekről számoljon be, hanem a tesztelés során módosítson valamit. A tesztelés befejeztével minden esetben jegyzőkönyvet készítünk, amelyben rámutatunk a feltárt hiányosságokra és javaslatokat teszünk az oldal gyenge pontjainak kiküszöbölésére.
Hogyan dolgozunk
Teszteléskor botnetet emulálunk. Mivel olyan kliensekkel dolgozunk, akik nem a hálózatunkon találhatók, annak érdekében, hogy a teszt ne az első percben érjen véget a limitek vagy a védelem kioldása miatt, nem egy IP-ről, hanem saját alhálózatunkról biztosítjuk a terhelést. Ráadásul, hogy jelentős terhelést hozzunk létre, saját, meglehetősen erős tesztszerverünk van.
Posztulátumok
A túl sok nem jelent jót
Minél kevesebb terhelést tudunk tönkretenni egy erőforrást, annál jobb. Ha le tudja állítani a webhely működését másodpercenként egy kérésre, vagy akár egy kérésre percenként, az nagyszerű. Mert az aljasság törvénye szerint a felhasználók vagy a támadók véletlenül beleesnek ebbe a sérülékenységbe.
A részleges kudarc jobb, mint a teljes kudarc
Mindig azt tanácsoljuk, hogy a rendszerek heterogének legyenek. Sőt, fizikai szinten is érdemes elkülöníteni őket, és nem csak konténerezéssel. Fizikai szétválasztás esetén, még ha valami meghibásodik is az oldalon, nagy a valószínűsége annak, hogy nem fog teljesen leállni, és a felhasználók továbbra is hozzáférhetnek a funkcionalitás legalább egy részéhez.
A jó építészet a fenntarthatóság alapja
Az erőforrás hibatűrését, valamint a támadásoknak és terheléseknek ellenálló képességét a tervezési szakaszban, tulajdonképpen az első folyamatábrák jegyzettömbbe történő rajzolásának szakaszában kell meghatározni. Mert ha végzetes hibák kúsznak be, akkor a jövőben ki lehet javítani, de nagyon nehéz.
Nem csak a kód legyen jó, hanem a konfig is
Sokan úgy gondolják, hogy egy jó fejlesztőcsapat a garancia a hibatűrő kiszolgálásra. Egy jó fejlesztőcsapat valóban szükséges, de jó működésnek, jó DevOpsnak is kell lennie. Vagyis olyan szakemberekre van szükségünk, akik megfelelően konfigurálják a Linuxot és a hálózatot, helyesen írják a konfigurációkat az nginx-ben, beállítják a korlátokat stb. Ellenkező esetben az erőforrás csak a tesztelés során fog jól működni, és egy ponton minden megszakad a termelésben.
A terhelés és a stresszteszt közötti különbségek
A terhelési tesztelés lehetővé teszi a rendszer működésének korlátainak azonosítását. A stresszteszt célja a rendszer gyenge pontjainak feltárása, és arra szolgál, hogy megtörje ezt a rendszert, és megnézze, hogyan fog viselkedni bizonyos részek meghibásodása esetén. Ebben az esetben a terhelés jellege általában ismeretlen marad az ügyfél számára a stresszteszt megkezdése előtt.
Az L7 támadások megkülönböztető jellemzői
A terheléstípusokat általában L7 és L3&4 szinteken osztjuk terhelésekre. Az L7 egy alkalmazás szintű terhelés, leggyakrabban csak HTTP-t jelent, de értünk bármilyen TCP protokoll szintű terhelést.
Az L7 támadásoknak vannak bizonyos jellegzetességei. Először is közvetlenül az alkalmazáshoz érkeznek, vagyis nem valószínű, hogy hálózati eszközökön keresztül tükröződnek. Az ilyen támadások logikát használnak, és ennek köszönhetően nagyon hatékonyan és kis forgalommal fogyasztanak CPU-t, memóriát, lemezt, adatbázist és egyéb erőforrásokat.
HTTP Flood
Bármilyen támadás esetén könnyebb létrehozni a terhelést, mint kezelni, és ez az L7 esetében is igaz. Nem mindig könnyű megkülönböztetni a támadási forgalmat a jogszerű forgalomtól, és ezt leggyakrabban gyakoriság szerint is meg lehet tenni, de ha mindent helyesen tervezünk, akkor a naplókból nem lehet megérteni, hogy hol van a támadás és hol vannak a jogos kérések.
Első példaként vegyünk egy HTTP Flood támadást. A grafikonon látható, hogy az ilyen támadások általában nagyon erősek, az alábbi példában a kérések csúcsszáma meghaladta a percenkénti 600 ezret.
A HTTP Flood a terhelés létrehozásának legegyszerűbb módja. Általában valamilyen terhelési tesztelő eszközre van szükség, például az ApacheBench-re, és beállít egy kérést és egy célt. Ilyen egyszerű megközelítéssel nagy a valószínűsége annak, hogy a szerver gyorsítótárazásba kerül, de könnyen megkerülhető. Például véletlenszerű karakterláncok hozzáadása a kéréshez, ami arra kényszeríti a szervert, hogy folyamatosan friss oldalt szolgáltasson ki.
Ne feledkezzünk meg a felhasználói ügynökről sem a terhelés létrehozása során. A népszerű tesztelőeszközök sok felhasználói ügynökét a rendszergazdák szűrik, és ebben az esetben előfordulhat, hogy a terhelés egyszerűen nem éri el a háttérrendszert. Jelentősen javíthatja az eredményt, ha egy többé-kevésbé érvényes fejlécet szúr be a böngészőből a kérésbe.
Bármilyen egyszerűek is a HTTP Flood támadások, vannak hátrányai is. Először is, nagy mennyiségű energiára van szükség a terhelés létrehozásához. Másodszor, az ilyen támadásokat nagyon könnyű észlelni, különösen, ha egy címről érkeznek. Ennek eredményeként a kéréseket azonnal megkezdik a rendszergazdák vagy akár a szolgáltatói szintű szűrés.
Mit kell keresni
A másodpercenkénti kérések számának csökkentése érdekében a hatékonyság elvesztése nélkül meg kell mutatnia egy kis képzelőerőt, és fel kell fedeznie a webhelyet. Így nemcsak a csatornát vagy a szervert töltheti be, hanem az alkalmazás egyes részeit is, például adatbázisokat vagy fájlrendszereket. Az oldalon olyan helyeket is kereshet, ahol nagy számításokat végeznek: számológépek, termékválasztási oldalak stb. Végül gyakran előfordul, hogy az oldalon van valamilyen PHP szkript, amely több százezer soros oldalt generál. Egy ilyen szkript jelentősen terheli a szervert, és támadás célpontjává válhat.
Hol keressünk
Amikor tesztelés előtt megvizsgálunk egy erőforrást, először természetesen magát a webhelyet nézzük meg. Mindenféle beviteli mezőt, nehéz fájlt keresünk - általában mindent, ami problémákat okozhat az erőforrásban és lelassíthatja a működését. Itt segítenek a Google Chrome és a Firefox banális fejlesztői eszközei, amelyek az oldal válaszidejét mutatják.
Aldomaineket is vizsgálunk. Például van egy bizonyos online áruház, az abc.com, és van egy admin.abc.com aldomainje. Valószínűleg ez egy jogosultsággal rendelkező adminisztrációs panel, de ha terhelést tesz rá, az problémákat okozhat a fő erőforrás számára.
A webhelynek lehet api.abc.com aldomainje. Valószínűleg ez a mobilalkalmazások forrása. Az alkalmazás megtalálható az App Store-ban vagy a Google Playen, telepítsen egy speciális hozzáférési pontot, bontsa ki az API-t és regisztráljon tesztfiókokat. A probléma az, hogy az emberek gyakran úgy gondolják, hogy bármi, amit jogosultság véd, immunis a szolgáltatásmegtagadási támadásokkal szemben. Állítólag az engedélyezés a legjobb CAPTCHA, de nem az. Könnyű 10-20 tesztfiókot készíteni, de ezek létrehozásával összetett és nem titkolt funkciókhoz jutunk hozzá.
Természetesen megnézzük az előzményeket, a robots.txt-t és a WebArchive-ot, a ViewDNS-t, és megkeressük az erőforrás régi verzióit. Néha megesik, hogy a fejlesztők bevezették mondjuk a mail2.yandex.net-et, de a régi verzió, a mail.yandex.net megmarad. Ez a mail.yandex.net már nem támogatott, fejlesztési erőforrások nincsenek hozzá rendelve, de továbbra is fogyasztja az adatbázist. Ennek megfelelően a régi verzió használatával hatékonyan használhatja a háttérrendszer erőforrásait és mindazt, ami az elrendezés mögött van. Természetesen ez nem mindig történik meg, de gyakran találkozunk ezzel.
Természetesen elemezzük az összes kérési paramétert és a cookie-struktúrát. Például beírhat bizonyos értéket egy JSON-tömbbe egy cookie-n belül, sok beágyazást hozhat létre, és indokolatlanul hosszú ideig működhet az erőforrás.
Keresési terhelés
Az első dolog, ami egy oldal kutatása során eszünkbe jut, az az adatbázis betöltése, hiszen szinte mindenkinek van keresése, és sajnos szinte mindenki számára gyengén védett. Valamiért a fejlesztők nem fordítanak kellő figyelmet a keresésre. De van egy javaslat: ne küldjön azonos típusú kéréseket, mert előfordulhat, hogy gyorsítótárazásba kerül, mint a HTTP-áradás esetén.
Az adatbázis véletlenszerű lekérdezése sem mindig hatékony. Sokkal jobb, ha létrehoz egy listát a keresés szempontjából releváns kulcsszavakról. Ha visszatérünk egy webáruház példájához: tegyük fel, hogy az oldal autógumit árul, és lehetővé teszi a gumiabroncsok sugarának, az autó típusának és egyéb paraméterek beállítását. Ennek megfelelően a releváns szavak kombinációi arra kényszerítik az adatbázist, hogy sokkal bonyolultabb körülmények között működjön.
Emellett érdemes oldalszámozást is használni: sokkal nehezebben adja vissza a keresés a találatok utolsó előtti oldalát, mint az elsőt. Vagyis az oldalszámozás segítségével kissé diverzifikálhatja a terhelést.
Az alábbi példa a keresési terhelést mutatja. Látható, hogy a teszt legelső másodpercétől kezdve tíz kérés/másodperc sebességgel az oldal leállt és nem válaszolt.
Ha nincs keresés?
Ha nincs keresés, ez nem jelenti azt, hogy a webhely nem tartalmaz más sebezhető beviteli mezőket. Ez a mező lehet engedélyezés. Manapság a fejlesztők szeretnek összetett kivonatokat készíteni, hogy megvédjék a bejelentkezési adatbázist a szivárványtábla támadásoktól. Ez jó, de az ilyen hash-ek sok CPU erőforrást fogyasztanak. A hamis engedélyek nagy száma a processzor meghibásodásához vezet, és ennek eredményeként a webhely leáll.
A megjegyzések és visszajelzések mindenféle űrlapjának jelenléte a webhelyen ok arra, hogy nagyon nagy szövegeket küldjenek oda, vagy egyszerűen csak hatalmas áradatot hozzanak létre. Néha a webhelyek elfogadnak csatolt fájlokat, beleértve a gzip formátumot is. Ebben az esetben veszünk egy 1 TB-os fájlt, több bájtra vagy kilobájtra tömörítjük a gzip segítségével, és elküldjük a webhelyre. Ezután kicipzározzuk, és nagyon érdekes hatást kapunk.
Pihenő API
Szeretnék egy kis figyelmet fordítani az olyan népszerű szolgáltatásokra, mint a Rest API. A Rest API biztonságossá tétele sokkal nehezebb, mint egy normál webhelyé. A Rest API esetében még a jelszavas brutális erőszak és más illegitim tevékenységek elleni védelem triviális módszerei sem működnek.
A Rest API nagyon könnyen feltörhető, mert közvetlenül hozzáfér az adatbázishoz. Ugyanakkor egy ilyen szolgáltatás meghiúsulása meglehetősen súlyos következményekkel jár a vállalkozások számára. A helyzet az, hogy a Rest API-t általában nem csak a fő webhelyhez használják, hanem a mobilalkalmazáshoz és néhány belső üzleti erőforráshoz is. És ha mindez esik, akkor a hatás sokkal erősebb, mint egy egyszerű weboldal meghibásodása esetén.
Nehéz tartalom betöltése
Ha felajánlanak egy egyszerű egyoldalas alkalmazást, nyitóoldalt vagy névjegykártya-webhelyet, amely nem rendelkezik összetett funkcionalitással, akkor nehéz tartalmat keresünk. Például nagy képek, amiket a szerver küld, bináris fájlok, pdf dokumentáció – mindezt megpróbáljuk letölteni. Az ilyen tesztek jól betöltik a fájlrendszert és eltömítik a csatornákat, ezért hatékonyak. Ez azt jelenti, hogy még ha nem is teszi le a szervert, nagy fájlt tölt le alacsony sebességgel, akkor egyszerűen eltömíti a célszerver csatornáját, és akkor szolgáltatásmegtagadás történik.
Egy ilyen teszt példája azt mutatja, hogy 30 RPS sebességnél a webhely leállt, vagy 500. szerverhibát produkált.
Ne feledkezzünk meg a szerverek beállításáról sem. Gyakran előfordulhat, hogy az ember vásárolt egy virtuális gépet, telepítette oda az Apache-t, alapból mindent beállított, telepített egy PHP alkalmazást, és lent láthatja az eredményt.
Itt a terhelés a gyökérre ment, és csak 10 RPS volt. Vártunk 5 percet, és a szerver összeomlott. Igaz, hogy nem teljesen ismert, hogy miért esett el, de az a feltételezés, hogy egyszerűen túl sok memóriája volt, ezért nem válaszolt.
Hullám alapú
Az elmúlt egy-két évben a hullámtámadások igen népszerűvé váltak. Ez annak a ténynek köszönhető, hogy sok szervezet vásárol bizonyos hardvert a DDoS védelemhez, amelyeknek bizonyos időre van szükségük ahhoz, hogy statisztikai adatokat gyűjtsenek a támadások szűrésének megkezdéséhez. Vagyis nem szűrik le a támadást az első 30-40 másodpercben, mert adatokat halmoznak fel és tanulnak. Ennek megfelelően ebben a 30-40 másodpercben annyit indíthat el a webhelyen, hogy az erőforrás hosszú ideig feküdjön, amíg az összes kérést nem törli.
Az alábbi támadásnál 10 perc szünet volt, ezt követően érkezett a támadás új, módosított része.
Vagyis a védelem tanult, elkezdett szűrni, de érkezett egy új, teljesen más támadásrész, és a védelem újra tanulni kezdett. Valójában a szűrés leáll, a védelem hatástalanná válik, és a webhely nem érhető el.
A hullámtámadásokat csúcson nagyon magas értékek jellemzik, az L7 esetében elérheti a százezer vagy egymillió kérést másodpercenként. Ha L3&4-ről beszélünk, akkor több száz gigabites forgalom lehet, vagy ennek megfelelően több száz mpps, ha csomagokban számolunk.
Az ilyen támadások problémája a szinkronizálás. A támadások botnetről érkeznek, és nagyfokú szinkronizálást igényelnek egy nagyon nagy egyszeri tüske létrehozásához. És ez a koordináció nem mindig működik: néha a kimenet valami parabolikus csúcs, ami meglehetősen szánalmasnak tűnik.
Nem egyedül a HTTP-vel
Az L7 HTTP-n kívül más protokollokat is szeretünk kihasználni. Általános szabály, hogy egy normál webhelyen, különösen egy hagyományos tárhelyen, vannak levelezési protokollok, és kilóg a MySQL. A levelezési protokollok kisebb terhelésnek vannak kitéve, mint az adatbázisok, de meglehetősen hatékonyan is betölthetők, és a kiszolgálón túlterhelt CPU-hoz vezethetnek.
A 2016-os SSH-sebezhetőséget nagyon sikeresen alkalmaztuk. Most ezt a biztonsági rést szinte mindenkinél javították, de ez nem jelenti azt, hogy ne lehetne betölteni az SSH-t. Tud. Egyszerűen hatalmas az engedélyezési terhelés, az SSH felemészti szinte a teljes CPU-t a szerveren, majd másodpercenként egy-két kéréstől összeomlik a weboldal. Ennek megfelelően ez a naplókon alapuló egy-két kérés nem különböztethető meg a jogos betöltéstől.
Sok kapcsolat, amelyet a szervereken nyitunk meg, szintén releváns marad. Korábban az Apache volt a hibás ebben, most az nginx szenved ettől, mivel gyakran alapértelmezés szerint be van állítva. Az nginx által nyitva tartható kapcsolatok száma korlátozott, ezért ilyen számú kapcsolatot nyitunk meg, az nginx már nem fogad el új kapcsolatot, és ennek következtében az oldal nem működik.
Tesztfürtünk elegendő CPU-val rendelkezik az SSL-kézfogás megtámadásához. Elvileg, amint azt a gyakorlat mutatja, a botnetek is szeretik ezt néha megtenni. Egyrészt egyértelmű, hogy SSL nélkül nem lehet, mert a Google találatai, rangsorolása, biztonsága. Másrészt az SSL-nek sajnos CPU-probléma van.
L3&4
Amikor L3 és 4 szintű támadásról beszélünk, általában link szintű támadásról beszélünk. Az ilyen terhelés szinte mindig megkülönböztethető a legitimtől, hacsak nem SYN-flod támadásról van szó. A biztonsági eszközök SYN-flod támadásainak problémája a nagy mennyiség. A maximális L3&4 érték 1,5-2 Tbit/s volt. Ezt a fajta forgalmat még a nagy cégek, köztük az Oracle és a Google is nagyon nehezen tudják feldolgozni.
A SYN és a SYN-ACK olyan csomagok, amelyeket a kapcsolat létesítésekor használnak. Ezért a SYN-floodot nehéz megkülönböztetni a törvényes terheléstől: nem világos, hogy ez egy SYN, amely kapcsolat létrehozására jött létre, vagy egy árvíz része.
UDP-áradás
A támadók általában nem rendelkeznek azokkal a képességekkel, amelyekkel mi rendelkezünk, így az erősítés felhasználható támadások szervezésére. Ez azt jelenti, hogy a támadó átvizsgálja az internetet, és sebezhető vagy helytelenül konfigurált szervereket talál, amelyek például egy SYN-csomagra három SYN-ACK-kel válaszolnak. A forráscím meghamisításával a célszerver címéről lehetséges, hogy egyetlen csomaggal mondjuk háromszorosára növeljük a teljesítményt, és átirányítjuk a forgalmat az áldozathoz.
Az erősítésekkel az a probléma, hogy nehezen észlelhetők. A legújabb példák közé tartozik a sebezhető memcached szenzációs esete. Ráadásul ma már nagyon sok az IoT eszköz, IP kamera, amelyek szintén többnyire alapból be vannak állítva, és alapból hibásan vannak beállítva, ezért a támadók leggyakrabban ilyen eszközökön keresztül támadnak.
Nehéz SYN-áradás
A SYN-Flood a fejlesztők szemszögéből talán a legérdekesebb támadástípus. A probléma az, hogy a rendszergazdák gyakran IP-blokkolást alkalmaznak a védelem érdekében. Sőt, az IP-blokkolás nemcsak a szkripteket használó rendszergazdákat érinti, hanem sajnos bizonyos, sok pénzért megvásárolt biztonsági rendszereket is.
Ez a módszer katasztrófába torkollhat, mert ha a támadók lecserélik az IP-címeket, a cég blokkolja saját alhálózatát. Amikor a tűzfal blokkolja saját fürtjét, a kimenet meghiúsítja a külső interakciókat, és az erőforrás meghibásodik.
Ezenkívül nem nehéz blokkolni a saját hálózatát. Ha az ügyfél irodája rendelkezik Wi-Fi hálózattal, vagy ha az erőforrások teljesítményét különböző megfigyelőrendszerekkel mérik, akkor ennek a megfigyelő rendszernek vagy az ügyfél irodai Wi-Fi-jének IP-címét vesszük, és azt használjuk forrásként. A végén úgy tűnik, hogy az erőforrás elérhető, de a cél IP-címek blokkolva vannak. Így a HighLoad konferencia Wi-Fi hálózata, ahol a cég új termékét mutatják be, leállhat, ami bizonyos üzleti és gazdasági költségekkel jár.
A tesztelés során semmilyen külső erőforrással nem használhatunk memcached-en keresztüli erősítést, mert megállapodások vannak arról, hogy csak az engedélyezett IP-címekre küldjük a forgalmat. Ennek megfelelően SYN és SYN-ACK erősítést alkalmazunk, amikor a rendszer egy SYN küldésére két vagy három SYN-ACK jelzéssel válaszol, és a kimeneten a támadást kétszer-háromszorosára szorozzuk.
Tools
Az L7-es munkaterheléshez használt egyik fő eszköz a Yandex-tank. Különösen egy fantomot használnak fegyverként, valamint számos szkript létezik a patronok generálására és az eredmények elemzésére.
A Tcpdump a hálózati forgalom, az Nmap pedig a szerver elemzésére szolgál. Az L3 és 4 szintű terhelés létrehozásához OpenSSL-t és egy kis saját varázslatot használunk a DPDK könyvtárral. A DPDK az Intel olyan könyvtára, amely lehetővé teszi, hogy a hálózati interfésszel dolgozzon a Linux-verem megkerülésével, ezáltal növelve a hatékonyságot. A DPDK-t természetesen nem csak L3&4, hanem L7 szinten is használjuk, mert nagyon magas terhelési áramlást tesz lehetővé, másodpercenként több millió kérés tartományán belül egy gépről.
Bizonyos forgalomgenerátorokat és speciális eszközöket is használunk, amelyeket konkrét tesztekhez írunk. Ha felidézzük az SSH alatti sérülékenységet, akkor a fenti készlet nem használható ki. Ha megtámadjuk a levelezési protokollt, akkor levelező segédprogramokat veszünk igénybe, vagy egyszerűen csak szkripteket írunk rájuk.
Álláspontja
Befejezésül szeretném elmondani:
- A klasszikus terhelési tesztelés mellett feszültségtesztet is kell végezni. Valós példánk van arra, hogy a partner alvállalkozója csak terhelési vizsgálatot végzett. Megmutatta, hogy az erőforrás kibírja a normál terhelést. Ekkor azonban rendellenes terhelés jelent meg, a webhely látogatói kicsit másképp kezdték használni az erőforrást, és ennek eredményeként az alvállalkozó lefeküdt. Így akkor is érdemes a sebezhetőséget keresni, ha már védett a DDoS támadásokkal szemben.
- A rendszer egyes részeit el kell különíteni a többitől. Ha van keresés, akkor azt külön gépekre kell áthelyezni, vagyis nem is a Dockerbe. Mert ha a keresés vagy az engedélyezés nem sikerül, legalább valami tovább fog működni. Online áruház esetén a felhasználók továbbra is megtalálják a termékeket a katalógusban, kilépnek az aggregátorból, vásárolnak, ha már jogosultak, vagy engedélyezik az OAuth2-n keresztül.
- Ne hanyagoljon el mindenféle felhőszolgáltatást.
- Használja a CDN-t nem csak a hálózati késések optimalizálására, hanem a csatornakimerülés és a statikus forgalomba való egyszerűen beáramló támadások elleni védelem eszközeként is.
- Speciális védelmi szolgáltatások igénybevétele szükséges. Csatorna szinten nem tudod megvédeni magad az L3&4 támadásoktól, mert nagy valószínűséggel egyszerűen nincs elegendő csatornád. Valószínűtlen, hogy leküzdöd az L7 támadásokat, mivel azok nagyon nagyok lehetnek. Ráadásul a kis támadások keresése továbbra is a speciális szolgáltatások, speciális algoritmusok kiváltsága.
- Rendszeresen frissítse. Ez nem csak a kernelre vonatkozik, hanem az SSH démonra is, különösen, ha kifelé nyitottak. Elvileg mindent frissíteni kell, mert nem valószínű, hogy egyedül tudna nyomon követni bizonyos sebezhetőségeket.
Forrás: will.com