A Variti cég bot- és DDoS-támadások elleni védelmet fejleszt, valamint stressz- és terheléses tesztelést végez. A HighLoad++ 2018 konferencián arról beszéltünk, hogyan védhetjük meg erőforrásainkat a különféle támadásoktól. Röviden: izolálja a rendszer részeit, használjon felhőszolgáltatásokat és CDN-t, és frissüljön rendszeresen. De specializált védelmi cégek nélkül nem boldogulhat. 🙂
A szöveg elolvasása előtt ismerkedjen meg a rövid összefoglalókkal .
Ha pedig nem szeret olvasni, vagy csak meg szeretné nézni a videót, az előadásunk felvétele az alábbi spoiler alatt található.
Az előadás videofelvétele
Sok cég már tud terheléses tesztelést végezni, de nem mindenki végez stressz-tesztelést. Néhány ügyfelünk azt hiszi, hogy a weboldaluk sebezhetetlen, mert van highload rendszerük, és az jól védi a támadásoktól. Mi azonban megmutatjuk, hogy ez nem teljesen igaz.
Természetesen a tesztelés előtt mindig megkapjuk az ügyfél engedélyét, aláírással és pecséttel, és a mi segítségünkkel DDoS-támadást senkire nem lehet irányítani. A tesztelést az ügyfél által választott időpontban végezzük, amikor a weboldal látogatottsága minimális, így a hozzáférési problémák nem befolyásolják az ügyfeleket. Továbbá, mivel a tesztelési folyamat során bármi elromolhat, folyamatos kapcsolatban állunk az ügyféllel. Ez lehetővé teszi, hogy ne csak az elért eredményekről számoljunk be, hanem változtatásokra is lehetőség nyíljon a tesztelés során. A tesztelés befejezésekor mindig készítünk egy jelentést, amelyben felvázoljuk a felfedezett hiányosságokat és ajánlásokat adunk a weboldal gyenge pontjainak megszüntetésére.
Hogyan dolgozunk
A tesztelés során botnetet emulálunk. Mivel olyan ügyfelekkel dolgozunk, akik nincsenek a hálózatunkban, hogy a teszt ne érjen véget az első percben a limitek vagy védelem aktiválódása miatt, a terhelést nem egy IP-ről, hanem a saját alhálózatunkról indítjuk. Ezen túlmenően, jelentős terhelés előidézéséhez van egy elég erős tesztkiszolgálónk is.
A postulátumok
Sok — nem jelenti azt, hogy jó
Minél kisebb terhelést tudunk elérni, amikor a rendszer meghibásodik, annál jobb. Ha sikerül elérni, hogy a weboldal egy másodperces vagy akár egy perces egyetlen kéréstől is leálljon, az nagyszerű. Mert a balsors törvénye szerint a felhasználók vagy a támadók véletlenül ebbe a sebezhetőségbe fognak belebotlani.
A részleges hiba jobb, mint a teljes.
Mindig javasoljuk heterogén rendszerek létrehozását. És a szétválasztásnak pontosan a fizikai szinten kell megtörténnie, nem csupán konténerizálással. Fizikai szétválasztás esetén, még ha a weboldalon valami meghibásodik is, nagyobb a valószínűsége, hogy a teljes működés nem szakad meg, és a felhasználók hozzáférnek legalább a funkciók egy részéhez.
A helyes architektúra a stabilitás alapja.
A rendszer hibaállóságát és képességét, hogy elviselje a támadásokat és terheléseket, a tervezési szakaszban kell beépíteni, gyakorlatilag az első blokkdiagramok skiccelésekor a jegyzetfüzetben. Mert ha végzetes hibák csúsznak be, akkor később kijavítani őket lehetséges, de nagyon nehéz.
Jónak kell lennie nemcsak a kódnak, hanem a konfigurációnak is.
Sokan úgy gondolják, hogy egy jó fejlesztőcsapat garancia a szolgáltatás hibaállóságára. A jó fejlesztőcsapat valóban szükséges, de szükség van megfelelő üzemeltetésre és jó DevOps-ra is. Tehát szükség van szakemberekre, akik helyesen konfigurálják a Linuxot és a hálózatot, és megfelelően írják meg a konfigurációkat az nginx-ben, beállítják a korlátokat és így tovább. Ellenkező esetben a rendszer jól működik a teszten, de a termelésben egy idő után minden tönkremegy.
A terhelés- és stressztesztelés eltérései.
A terhelés tesztelés lehetővé teszi a rendszer működési határainak feltárását. A stressztesztelés a rendszer gyenge pontjainak keresésére irányul, és arra használják, hogy a rendszert megbontsák, és megnézzék, hogyan viselkedik a különféle részek meghibásodása során. A folyamat során a terhelés típusa általában ismeretlen a megrendelő számára a stressztesztelés kezdete előtt.
Az L7 támadások jellegzetességei.
A terheléseket általában L7 és L3&4 szintű terhelésekre osztjuk. Az L7 a felső alkalmazási szinten jelentkező terhelés, amit leggyakrabban HTTP-ként értenek, de mi minden TCP protokollszintű terhelést értenek alatta.
Az L7 támadásoknak vannak bizonyos megkülönböztető jellemzőik. Először is, ezek közvetlenül az alkalmazásra irányulnak, így hálózati eszközökkel nehéz lehet azokat elhárítani. Az ilyen támadások logikát használnak, és ennek köszönhetően rendkívül hatékonyan, még viszonylag alacsony forgalom mellett is képesek CPU-t, memóriát, diszket, adatbázist és egyéb erőforrásokat fogyasztani.
HTTP Flood
Bármilyen támadás esetén könnyebb terhelést generálni, mint kezelni, és ez az L7 esetében is így van. A támadás forgalmát nem mindig könnyű megkülönböztetni a legitim forgalomtól, és a legtöbb esetben ezt a frekvencia alapján lehet csak megállapítani, de ha mindez jól van megtervezve, a naplók alapján nem lehet kimutatni, hol van a támadás és hol a legitim kérések.
Első példaként nézzük meg a HTTP Flood támadást. A grafikonn látható, hogy az ilyen támadások általában nagyon intenzívek, az alábbi példában a csúcs forgalom meghaladta a 600 ezer kérést percenként.
A HTTP Flood a legegyszerűbb módja a terhelés generálásának. Általában valamilyen terhelés tesztelő eszközt használnak, például ApacheBench-t, és beállítják a kérést és a célt. Ezzel az egyszerű megközelítéssel nagy a valószínűsége annak, hogy a szerver cache-elésével találkozunk, de ezt könnyen meg lehet kerülni. Például véletlenszerű karakterek hozzáadásával a kéréshez, ami arra kényszeríti a szervert, hogy folyamatosan új oldalt adjon vissza.
A terhelés generálása során nem szabad elfelejteni a user-agentet sem. Sok népszerű tesztelő eszköz user-agentjeit a rendszeradminisztrátorok kiszűrik, és ilyenkor a terhelés egyszerűen nem jut el a backendhez. A hozzáadott, részben vagy teljesen érvényes böngészőfejlécek használatával jelentősen javítható az eredmény.
A HTTP Flood támadások, bármennyire egyszerűek is, saját hátrányaikkal rendelkeznek. Először is, a terhelés generálásához nagy teljesítmény szükséges. Másodszor, az ilyen támadások rendkívül könnyen észlelhetők, különösen, ha egyetlen címről származnak. Ennek eredményeként a kérések azonnal kiszűrésre kerülnek, akár a rendszeradminisztrátorok, akár a szolgáltató szintjén.
Mit érdemes keresni
A lekérdezések másodpercenkénti számának csökkentéséhez, anélkül hogy a hatékonyság csökkenne, egy kis kreativitásra van szükség, és érdemes felfedezni a weboldalt. Nemcsak a csatornát vagy a szervert lehet terhelni, hanem az alkalmazás egyes részeit is, például az adatbázisokat vagy a fájlrendszereket. Emellett érdemes megvizsgálni azokat a helyeket az oldalon, ahol nagy számítások zajlanak: kalkulátorok, termékajánló oldalak és egyebek. Végül gyakran előfordul, hogy egy php-script generálja az oldalt több százezer sorból. Egy ilyen script is jelentősen terheli a szervert, és támadási célponttá válhat.
Hol keressünk
Amikor a tesztelés előtt átvizsgáljuk az erőforrást, akkor elsősorban magára az oldalra összpontosítunk. Mindenféle bevitelmezőt, nehéz fájlokat keresünk — gyakorlatilag mindent, ami problémát okozhat az erőforrásnak és lassíthatja annak működését. Itt segítenek a Google Chrome és Firefox egyszerű fejlesztői eszközei, amelyek megmutatják az oldal válaszidejét.
Azt is vizsgáljuk a szubdomainjeinket. Például, ha van egy online bolt, abc.com, és van egy admin.abc.com szubdomainje. Valószínűleg ez egy adminisztrációs felület, amely bejelentkezést igényel, de ha erre terhelést engedünk, problémákat okozhat a fő erőforrás számára.
A weboldalnak lehet api.abc.com szubdomainje. Valószínűleg ez egy mobilalkalmazások számára készült erőforrás. Az alkalmazás megtalálható az App Store-ban vagy a Google Playen, létrehozhatunk egy speciális számítógépes hozzáférési pontot, feltérképezhetjük az API-t, és regisztrálhatunk tesztfiókokat. A probléma az, hogy sokan úgy gondolják, hogy minden, ami bejelentkezést igényel, védve van a szolgáltatásmegtagadásos támadásokkal szemben. Állítólag a bejelentkezés a legjobb CAPTCHA, de ez nem igaz. 10-20 tesztfiók létrehozása egyszerű, és ha ezeket létrehoztuk, hozzáférünk a bonyolult és nem védett funkciókhoz.
Természetesen megvizsgáljuk a történelmet, a robots.txt-et és a WebArchive-t, ViewDNS-t, régi verziókat keresünk. Néha az történik, hogy a fejlesztők kiadták például a mail2.yandex.net-t, de a régi verzió, a mail.yandex.net, megmaradt. Ez a mail.yandex.net már nem támogatott, nincs rájdolgozás, de továbbra is fogyasztja az adatbázist. Ennek megfelelően a régi verzió segítségével hatékonyan kihasználhatók a backend erőforrások és minden, ami a további megjelenítést szolgálja. Természetesen ez nem mindig fordul elő, de hasonló helyzetekkel még mindig viszonylag gyakran találkozunk.
Természetesen, elemezzük az összes kérelem paramétereit, a cookie struktúráját. Mondjuk, be lehet ágyazni egy JSON tömbbe valamilyen értéket a cookie-ban, létrehozni egy nagy mélységet, és ezzel sokáig működésre bírni az erőforrást.
Keresési terhelés
Ami először eszembe jut a weboldal vizsgálatakor, az az adatbázis megterhelése, mivel a keresés szinte mindenhol jelen van, és sajnos szinte mindenhol gyengén védett. Valamiért a fejlesztők nem fordítanak elegendő figyelmet a keresésre. De itt van egy javaslat — nem szabad egységes kéréseket tenni, mert találkozhatunk a gyorsítótárazással, mint a HTTP áradás esetén.
Az adatbázisba történő véletlenszerű kérések végrehajtása sem mindig hatékony. Sokkal jobb létrehozni egy kulcsszólistát, amely a kereséshez kapcsolódik. Ha visszatérünk egy példa online boltjára: mondjuk, az oldal gumiabroncsokat árul, és lehetővé teszi a gumiabroncsok sugárának, a típusának és egyéb paramétereinek megadását. Ennek megfelelően a releváns szavak kombinációi sokkal bonyolultabb körülmények között működtetik az adatbázist.
Ezen kívül érdemes használni a paginációt: a keresésnek sokkal nehezebb átadni az utolsó előtti találati oldalt, mint az elsőt. Tehát a paginációval kicsit változatosabbá tehetjük a terhelést.
Az alábbi példa bemutatja a keresési terhelést. Látható, hogy a teszt első másodpercétől kezdve tíz kérés másodpercenként a weboldal lefagyott és nem válaszolt.
Mi van, ha nincs keresés?
Ha nincs keresés, az nem jelenti azt, hogy az oldal nem tartalmaz más sebezhető bemeneti mezőket. Ilyen mező lehet a bejelentkezés. Manapság a fejlesztők szeretnek bonyolult hash-eket készíteni, hogy megvédjék a felhasználónevek adatbázisát a rainbow table támadások ellen. Ez jó, de ezek a hash-ek nagy CPU erőforrást igényelnek. Nagy mennyiségű hamis bejelentkezési kísérlet a processzor leállását okozhatja, ami miatt az oldal működése megszűnik.
A weboldalon lévő különféle kommentárok és kapcsolatfelvételi űrlapok lehetőséget adnak nagyon nagy szövegek elküldésére vagy egyszerűen tömeges spammelésre. Néha az oldalak elfogadnak beágyazott fájlokat, beleértve a gzip formátumot is. Ilyen esetben például fogunk egy 1 TB-os fájlt, gzip-pel néhány bájtra vagy kilobájtokra tömörítjük, és elküldjük az oldalra. Utána ez kicsomagolódik, és nagyon érdekes hatást kelt.
Rest API
Érdemes lenne egy kis figyelmet szentelni az olyan népszerű szolgáltatásoknak, mint a Rest API. A Rest API védelme sokkal nehezebb, mint egy egyszerű weboldalé. A Rest API esetében még a jelszótiprók és más illegitim tevékenységek ellen alkalmazott banális védelmi módszerek sem hatékonyak.
A Rest API-t nagyon könnyű feltörni, mert közvetlenül az adatbázisra hivatkozik. Ennek következtében egy ilyen szolgáltatás leállása súlyos következményekkel járhat a vállalkozásra nézve. Az a helyzet, hogy a Rest API általában nemcsak a fő weboldalra van rákapcsolva, hanem a mobilalkalmazásra, valamint különböző belső üzleti forrásokra is. Ha ezek mind leállnak, annak hatása sokkal súlyosabb, mint egy egyszerű weboldal leállása esetén.
Terhelés nehéz tartalomra
Ha azt javasolják nekünk, hogy teszteljünk egy egyszerű egyoldalas alkalmazást, landingt, névjegy-oldalt, amelyeknek nincs összetett funkcionalitásuk, akkor keressük a nehéz tartalmakat. Például nagy képeket, amelyeket a szerver szolgáltat, bináris fájlokat, pdf-dokumentációt — mindezt megpróbáljuk letölteni. Az ilyen tesztek jól megterhelik a fájlrendszert és elzárják a csatornákat, ezért hatékonyak. Tehát ha nem is terheled le a szervert nagyméretű fájlok letöltésével alacsony sebességgel, akkor egyszerűen csak elzárod a célkiszolgáló csatornáját, és így elérhetetlenség lép fel.
Egy ilyen teszt példáján látható, hogy 30 RPS sebességnél a weboldal nem válaszolt, vagy 500-as szerver hibákat adott vissza.
Ne felejtsük el a szerverek beállításait sem. Gyakran találkozunk azzal, hogy valaki vásárol egy virtuális gépet, telepít rá Apache-ot, minden alapértelmezetten van beállítva, elhelyez egy PHP-alkalmazást, és itt az eredmény.
Itt a terhelés a gyökérbe ment, és mindössze 10 RPS-t tett ki. Vártunk 5 percet, és a szerver leállt. Az okát igazából nem tudni, de feltételezhető, hogy egyszerűen memóriát fogyasztott el, és ezért nem tudott válaszolni.
Hullám alapú
Az elmúlt egy-két évben a hullám támadások meglehetősen népszerűvé váltak. Ennek oka, hogy sok szervezet különböző eszközöket vásárol a DDoS elleni védelem érdekében, amelyeknek statisztikák felhalmozásához van szükségük az támadások kiszűrésének megkezdéséhez. Ezért az első 30-40 másodpercben nem szűrik meg a támadást, mert adatokat gyűjtenek és tanulnak. Ennek megfelelően ezekben a 30-40 másodpercben annyi kérés érkezik, hogy az erőforrás hosszú ideig leáll, amíg az összes kérés rendeződik.
A következő támadás esetében 10 perces időintervallum volt, ezután pedig egy új, átalakított támadáshullám érkezett.
Tehát a védelem megtanulta a szűrést, de jött egy új, teljesen más támadáshullám, és a védelem ismét tanulni kezdett. Gyakorlatilag a szűrés leáll, a védelem hatástalanná válik, és a weboldal elérhetetlenné válik.
A hullám támadásokra jellemzők a rendkívül magas csúcsértékek, elérheti a százezer vagy akár egymillió kérést másodpercenként, az L7 szinten. Ha az L3&4-ről beszélünk, ott száz gigabit forgalom is lehet, vagy ennek megfelelően száz millió csomag másodpercenként.
Ezeknek a támadásoknak a problémája a szinkronizáció. A támadások botnetből érkeznek, és ahhoz, hogy egy nagyon nagy, egyszeri csúcsot létrehozzunk, magas szintű szinkronizáció szükséges. Ez a koordináció azonban nem mindig sikerül: néha ki egy parabolikus csúcs keletkezik, amely meglehetősen csekélynek tűnik.
Nem csak HTTP
A L7-es szinten kívül az HTTP mellett más protokollokat is szeretünk használni. Általában egy normál weboldal, különösen egy szokásos tárhely esetén, nyitott a levelezési protokollokra és a MySQL-re. A levelezési protokollok kevésbé érzékenyek a terhelésre, mint az adatbázisok, de őket is elég hatékonyan meg lehet terhelni, ami CPU túlterheléshez vezethet a szerveren.
Teljesen reálisan elértük a célunkat a 2016-os SSH sebezhetőség kihasználásával. Mostanra ezt a sebezhetőséget szinte mindenki javította, de ez nem jelenti azt, hogy az SSH nem terhelhető. Terhelhető. Csak egy hatalmas mennyiségű bejelentkezési kérést küldünk, az SSH szinte az összes CPU-t elfogyasztja a szerveren, és a weboldal már egy-két kérdés másodpercenként összeomlik. Ennek megfelelően az egy-két kérés a naplókból semmilyen módon nem különböztethető meg a legitim terheléstől.
Számos kapcsolat, amelyet a szervereken nyitunk, továbbra is releváns. Korábban az Apache volt ezzel problémás, manapság viszont az nginx is gyakran így van, mivel sokszor alapértelmezetten van beállítva. Az nginx által fenntartható nyitott kapcsolatok száma korlátozott, így amint ezt a számot elérjük, az új kapcsolatokat már nem fogadja el, és ennek következtében a weboldal nem működik.
A tesztklaszterünk elegendő CPU-val rendelkezik, hogy megtámadja az SSL kézfogást. Elvileg, ahogy a gyakorlat mutatja, a botnetek is néha szeretik ezt csinálni. Egyfelől világos, hogy SSL nélkül nem lehet megúszni, mivel ez befolyásolja a Google találati sorrendjét és a biztonságot. Másfelől azonban az SSL-nek sajnos van egy CPU-val kapcsolatos problémája.
L3&4
Amikor L3&4 szintű támadásról beszélünk, akkor rendszerint a csatorna szintű támadásról van szó. Az ilyen típusú terhelés szinte mindig megkülönböztethető a legitim terheléstől, kivéve ha SYN-flood támadásról van szó. A SYN-flood támadások problémája a védelmi eszközökkel az óriási mennyiségben rejlik. A maximális L3&4 érték 1,5-2 Tbit/s volt. Ilyen forgalmat még a nagyobb cégek, például az Oracle és a Google is nehezen tudnak kezelni.
SYN és SYN-ACK
Általában a támadóknak nincs olyan erejük, mint nekünk, ezért a támadások szervezéséhez amplifikációt alkalmazhatnak. Ez azt jelenti, hogy a támadó átnézi az internetet, és olyan sebezhető vagy rosszul konfigurált szervereket keres, amelyek például egy SYN-csomagra három SYN-ACK-kal válaszolnak. A cél szerver címének hamisításával egy csomag segítségével a teljesítményt, mondjuk, háromszorosára növelhetjük, és a forgalmat az áldozatra irányíthatjuk.
Az amplifikációk problémája a nehéz észlelhetőségükben rejlik. Az utolsó példák között említhetjük a híres memcached sebezhetőséget. Ráadásul manapság számos IoT eszköz, IP kamera is megjelent, amelyek szintén alapértelmezetten vannak beállítva, és alapértelmezetten helytelenül, ezért ezek az eszközök gyakran szolgálnak a támadók számára.
Bonyolult SYN-flood
SYN-flood
A SYN-flood talán a legérdekesebb típusú támadás a fejlesztők számára. A probléma, hogy a rendszergazdák gyakran IP-alapú blokkolást használnak védekezésre. Ennek következtében nemcsak azok a rendszergazdák szenvednek, akik scriptek alapján cselekszenek, hanem sajnos egyes védelmi rendszerek is, amelyeket nagy pénzért vásárolnak meg.
Ez a módszer katasztrofális károkat okozhat, hiszen ha a támadók hamisítják IP address, akkor a cég le fogja tiltani a saját alhálózatát. Amikor a tűzfal letiltja a saját klaszterét, külső interakciók törnek össze, és az erőforrás megsérül.
Könnyen elérhetjük a saját hálózat blokkolását. Ha a kliens irodájában van Wi-Fi-hálózat, vagy ha az erőforrások működését különböző monitorozásokkal mérik, akkor figyelembe vesszük ennek a monitorozási rendszernek vagy az iroda Wi-Fi kliensének az IP-címét, és ezt használjuk forrásként. Az erőforrás látszólag elérhető, de a célzott IP-címek le vannak tiltva. Így például letiltható a HighLoad konferencia Wi-Fi-hálózata, ahol a cég új termékét mutatják be — és ez bizonyos üzleti és gazdasági költségeket von maga után.
A tesztelés során nem használhatunk memcached-alapú amplifikációt külső forrásokkal, mert megállapodások vannak arról, hogy csak engedélyezett IP-címekhez hozzáadott forgalmat fognak kezelni. Ennek megfelelően a SYN és SYN-ACK révén végzünk amplifikációt, amikor egy SYN elküldésére a rendszer két-három SYN-ACK-kal válaszol, és ennek következtében a támadás kétszeresére-háromszorosára nő.
Eszközök
Az egyik fő eszköz, amit használunk az L7 szintű terheléshez, a Yandex-tank. Különösen ágyúként egy fantomot használunk, emellett van néhány szkript a lőszerek generálására és az eredmények elemzésére.
A hálózati forgalom elemzésére a Tcpdumpot, a szerver elemzésére pedig az Nmapot használjuk. Az L3&4 szintű terhelés létrehozására az OpenSSL-t alkalmazzuk, valamint egy kis saját varázslatot a DPDK könyvtárral. A DPDK egy Intel könyvtár, amely lehetővé teszi a hálózati interfész közvetlen használatát a Linux verem megkerülésével, így növelve a hatékonyságot. Természetesen a DPDK-t nemcsak az L3&4, hanem az L7 szinten is használjuk, mert lehetővé teszi, hogy nagyon magas terhelést hozzunk létre, akár több millió kérdéssel másodpercenként egy gépről.
Mi is használunk bizonyos forgalomgenerátorokat és speciális eszközöket, amelyeket specifikus tesztekhez írunk. Ha visszaemlékezünk az SSH sebezhetőségre, akkor a fent említett készlettel az nem lehet kihasználni. Ha a levelezési protokollt támadjuk, akkor levelezési segédprogramokat használunk, vagy egyszerűen írunk rájuk szkripteket.
Következtetések
Összegzésül szeretném mondani:
- A klasszikus terheléses tesztelés mellett mindenképpen végezzen stressztesztet is. Van egy valós példánk, amikor egy partner alvállalkozója csak terheléses tesztet végzett. Ez megmutatta, hogy az erőforrás elviseli a normál terhelést. De később nem normális terhelés lépett fel, a webhely látogatói egy kicsit másképp kezdték használni az erőforrást, és az alvállalkozó leállt. Így érdemes sebezhetőségeket keresni, még akkor is, ha már védett a DDoS-támadások ellen.
- Izolálni kell a rendszer egyes részeit a másiktól. Ha van keresés, azt külön gépekre kell kiszervezni, tehát még csak nem is Dockerbe. Mert ha a keresés vagy az azonosítás leáll, legalább valami továbbra is működni fog. Az internetes bolt esetében a felhasználók továbbra is megtalálják a termékeket a katalógusban, átmennek az aggregátorokról, vásárolnak, ha már be vannak jelentkezve, vagy bejelentkeznek OAuth2-n keresztül.
- Ne hagyja figyelmen kívül a különböző felhőszolgáltatásokat.
- Használjon CDN-t nemcsak a hálózati késleltetések optimalizálására, hanem a sávszélesség-kimerítéssel és a statikus tartalommal szembeni támadások védelmére is.
- Speciális védelmi szolgáltatásokat kell használni. A L3&4 támadások ellen a csatorna szintjén nem tud védekezni, mert valószínűleg egyszerűen nincs elegendő sávszélessége. A L7 támadásokkal is valószínűleg nehezen védekezik, mivel ezek nagyon nagyok lehetnek. Ráadásul a kisebb támadások keresése legtöbbször speciális szolgáltatások és algoritmusok prerogativája.
- Rendszeresen frissítse magát. Ez nemcsak a magra vonatkozik, hanem az SSH démonra is, különösen ha azok külsőleg nyitva vannak. Alapvetően mindent frissíteni kell, mert valószínűleg nem tudja önállóan követni a különböző sebezhetőségeket.
Forrás: habr.com
