DDoS til bjargar: hvernig við framkvæmum streitu- og álagspróf

Variti þróar vörn gegn vélmennum og DDoS árásum og framkvæmir einnig streitu- og álagsprófanir. Á ráðstefnunni HighLoad++ 2018 ræddum við hvernig hægt er að tryggja auðlindir fyrir ýmiss konar árásum. Í stuttu máli: einangra hluta kerfisins, notaðu skýjaþjónustu og CDN og uppfærðu reglulega. En þú munt samt ekki geta séð um vernd án sérhæfðra fyrirtækja :)

Áður en textinn er lesinn geturðu lesið stuttu útdrættina á heimasíðu ráðstefnunnar.
Og ef þér líkar ekki að lesa eða vilt bara horfa á myndbandið, þá er upptakan af skýrslunni okkar hér að neðan undir spoilernum.

Myndbandsupptaka af skýrslunni

Mörg fyrirtæki vita nú þegar hvernig á að gera álagspróf, en ekki öll gera álagspróf. Sumir viðskiptavina okkar halda að vefsvæðið þeirra sé óviðkvæmt vegna þess að þeir eru með mikið álagskerfi og það verndar vel fyrir árásum. Við sýnum að þetta er ekki alveg satt.
Auðvitað, áður en prófanir eru framkvæmdar, fáum við leyfi frá viðskiptavininum, undirritað og stimplað, og með okkar hjálp er ekki hægt að framkvæma DDoS árás á neinn. Prófun fer fram á þeim tíma sem viðskiptavinurinn velur, þegar umferð að auðlind hans er í lágmarki og aðgangsvandamál munu ekki hafa áhrif á viðskiptavini. Þar að auki, þar sem eitthvað getur alltaf farið úrskeiðis í prófunarferlinu, höfum við stöðugt samband við viðskiptavininn. Þetta gerir þér kleift að tilkynna ekki aðeins um árangur sem náðst hefur, heldur einnig að breyta einhverju meðan á prófun stendur. Að prófun lokinni gerum við alltaf skýrslu þar sem við bendum á gallana sem uppgötvast hafa og gefum ráðleggingar til að útrýma veikleikum vefsins.

Hvernig við erum að vinna

Við prófun líkjum við eftir botneti. Þar sem við vinnum með viðskiptavinum sem eru ekki staðsettir á netkerfum okkar, til að tryggja að prófuninni ljúki ekki á fyrstu mínútu vegna takmarkana eða verndar sem er ræst, sendum við álagið ekki frá einni IP, heldur frá okkar eigin undirneti. Auk þess, til að skapa umtalsvert álag, höfum við okkar eigin nokkuð öfluga prófunarþjón.

Postulates

Of mikið þýðir ekki gott
Því minna álag sem við getum fært auðlind til að mistakast, því betra. Ef þú getur látið vefsvæðið hætta að virka á einni beiðni á sekúndu, eða jafnvel einni beiðni á mínútu, þá er það frábært. Vegna þess að samkvæmt lögum um meinsemd falla notendur eða árásarmenn óvart í þennan tiltekna varnarleysi.

Hlutabilun er betri en algjör bilun
Við ráðleggjum alltaf að gera kerfi ólík. Þar að auki er það þess virði að aðgreina þau á líkamlegu stigi, en ekki bara með gámavæðingu. Ef um líkamlegan aðskilnað er að ræða, jafnvel þótt eitthvað mistakist á síðunni, eru miklar líkur á að það hætti ekki að virka alveg og notendur munu halda áfram að hafa aðgang að að minnsta kosti hluta af virkninni.

Góður arkitektúr er undirstaða sjálfbærni
Mæla skal fyrir um bilunarþol auðlindar og getu hennar til að standast árásir og álag á hönnunarstigi, reyndar á því stigi að fyrstu flæðiritin eru teiknuð í minnisbók. Því ef banvænar villur læðast að er hægt að leiðrétta þær í framtíðinni en það er mjög erfitt.

Ekki aðeins kóðinn ætti að vera góður, heldur einnig stillingin
Margir halda að gott þróunarteymi sé trygging fyrir gallaþolinni þjónustu. Gott þróunarteymi er virkilega nauðsynlegt, en það verður líka að vera góður rekstur, góður DevOps. Það er, við þurfum sérfræðinga sem munu rétt stilla Linux og netið, skrifa stillingar rétt í nginx, setja mörk o.s.frv. Annars mun auðlindin virka vel aðeins í prófunum og á einhverjum tímapunkti mun allt brotna í framleiðslu.

Mismunur á álags- og álagsprófum
Álagsprófun gerir þér kleift að bera kennsl á takmörk virkni kerfisins. Álagspróf miðar að því að finna veikleika í kerfi og er notað til að brjóta þetta kerfi og sjá hvernig það mun haga sér í því ferli að bila ákveðnum hlutum. Í þessu tilviki er eðli álagsins venjulega óþekkt fyrir viðskiptavininn áður en álagspróf hefst.

Sérkenni L7 árása

Við skiptum venjulega tegundum álags í álag á L7 og L3&4 stigum. L7 er álag á forritastigi, oftast þýðir það aðeins HTTP, en við meinum hvaða álag sem er á TCP samskiptareglum.
L7 árásir hafa ákveðin sérkenni. Í fyrsta lagi koma þeir beint í forritið, það er ólíklegt að þeir endurspeglast í gegnum netkerfi. Slíkar árásir nota rökfræði og af þeim sökum neyta þær örgjörva, minni, diska, gagnagrunna og önnur úrræði á mjög skilvirkan hátt og með lítilli umferð.

HTTP flóð

Ef um einhverja árás er að ræða er auðveldara að búa til álagið en að höndla það, og þegar um L7 er að ræða er þetta líka satt. Það er ekki alltaf auðvelt að greina árásarumferð frá lögmætri umferð og oftast er hægt að gera það eftir tíðni, en ef allt er rétt skipulagt þá er ómögulegt að skilja út frá loggunum hvar árásin er og hvar lögmætu beiðnirnar eru.
Sem fyrsta dæmi skaltu íhuga HTTP flóðárás. Grafið sýnir að slíkar árásir eru yfirleitt mjög öflugar; í dæminu hér að neðan fór hámarksfjöldi beiðna yfir 600 þúsund á mínútu.

HTTP Flood er auðveldasta leiðin til að búa til álag. Venjulega tekur það einhvers konar álagsprófunartæki, eins og ApacheBench, og setur beiðni og markmið. Með svo einfaldri nálgun eru miklar líkur á að lenda í skyndiminni miðlara, en það er auðvelt að komast framhjá því. Til dæmis að bæta handahófi strengi við beiðnina, sem mun neyða þjóninn til að þjóna stöðugt nýrri síðu.
Einnig, ekki gleyma um notanda-umboðsmanninn í því ferli að búa til álag. Margir notendafulltrúar vinsælra prófunartækja eru síaðir af kerfisstjórum og í þessu tilviki getur álagið einfaldlega ekki náð bakendanum. Þú getur bætt útkomuna verulega með því að setja meira og minna gildan haus úr vafranum inn í beiðnina.
Eins einfaldar og HTTP flóðárásir eru, þá hafa þær líka sína galla. Í fyrsta lagi þarf mikið magn af afli til að búa til álagið. Í öðru lagi er mjög auðvelt að greina slíkar árásir, sérstaklega ef þær koma frá einu heimilisfangi. Fyrir vikið byrjar strax að sía beiðnir annaðhvort af kerfisstjórum eða jafnvel hjá þjónustuveitanda.

Hvað á að leita að

Til að fækka beiðnum á sekúndu án þess að tapa skilvirkni þarftu að sýna smá hugmyndaflug og skoða síðuna. Þannig geturðu hlaðið ekki aðeins rásinni eða netþjóninum, heldur einnig einstökum hlutum forritsins, til dæmis gagnagrunna eða skráarkerfi. Einnig er hægt að leita að stöðum á síðunni sem gera stóra útreikninga: reiknivélar, vöruvalssíður o.s.frv. Loks gerist það oft að síðan er með einhvers konar PHP skriftu sem býr til nokkur hundruð þúsund línur síðu. Slíkt handrit hleður einnig verulega á netþjóninn og getur orðið skotmark fyrir árás.

Hvar á að leita

Þegar við skönnum tilföng fyrir prófun, skoðum við fyrst, auðvitað, á síðuna sjálfa. Við erum að leita að alls kyns innsláttarreitum, þungum skrám - almennt öllu sem getur skapað vandamál fyrir auðlindina og hægt á rekstri hennar. Banal þróunarverkfæri í Google Chrome og Firefox hjálpa hér, sem sýnir viðbragðstíma síðunnar.
Við skönnum líka undirlén. Til dæmis er ákveðin netverslun, abc.com, og hún er með undirlénið admin.abc.com. Líklegast er þetta stjórnborð með heimild, en ef þú setur álag á það getur það skapað vandamál fyrir aðalauðlindina.
Síðan gæti verið með undirlén api.abc.com. Líklegast er þetta úrræði fyrir farsímaforrit. Forritið er að finna í App Store eða Google Play, setja upp sérstakan aðgangsstað, kryfja API og skrá prófreikninga. Vandamálið er að fólk heldur oft að allt sem er varið með heimild sé ónæmt fyrir afneitun-þjónustuárásum. Talið er að heimild sé besta CAPTCHA, en það er það ekki. Það er auðvelt að búa til 10-20 prófreikninga, en með því að búa þá til fáum við aðgang að flóknum og óhultri virkni.
Auðvitað skoðum við sögu, á robots.txt og WebArchive, ViewDNS, og leitum að gömlum útgáfum af auðlindinni. Stundum gerist það að forritarar hafa sett út, til dæmis, mail2.yandex.net, en gamla útgáfan, mail.yandex.net, er eftir. Þetta mail.yandex.net er ekki lengur stutt, þróunarauðlindum er ekki úthlutað til þess, en það heldur áfram að neyta gagnagrunnsins. Í samræmi við það, með því að nota gömlu útgáfuna, geturðu í raun notað auðlindir bakendans og allt sem er á bak við skipulagið. Auðvitað gerist þetta ekki alltaf en við lendum samt oft í þessu.
Auðvitað greinum við allar beiðnifæribreytur og uppbyggingu fótspora. Þú getur td varpað einhverju gildi í JSON fylki inni í vafraköku, búið til mikið hreiður og látið tilföngin virka í óeðlilega langan tíma.

Leitarálag

Það fyrsta sem kemur upp í hugann þegar þú rannsakar síðu er að hlaða gagnagrunninum, þar sem næstum allir eru með leit og fyrir næstum alla, því miður, er hann illa varinn. Af einhverjum ástæðum taka verktaki ekki nægilega eftirtekt til leitar. En það er ein tilmæli hér - þú ættir ekki að gera beiðnir af sömu gerð, vegna þess að þú gætir lent í skyndiminni, eins og raunin er með HTTP flóð.
Að gera tilviljunarkenndar fyrirspurnir í gagnagrunninn er heldur ekki alltaf árangursríkt. Það er miklu betra að búa til lista yfir leitarorð sem eiga við leitina. Ef við snúum okkur aftur að dæminu um netverslun: segjum að vefsíðan selji bíladekk og leyfir þér að stilla radíus dekkja, gerð bíls og aðrar breytur. Samkvæmt því munu samsetningar viðeigandi orða neyða gagnagrunninn til að vinna við mun flóknari aðstæður.
Að auki er þess virði að nota blaðsíðugerð: það er mun erfiðara fyrir leit að skila næstsíðustu síðu leitarniðurstaðna en þeirri fyrstu. Það er, með hjálp síðusniðs geturðu breytt álaginu örlítið.
Dæmið hér að neðan sýnir leitarálag. Það má sjá að strax á fyrstu sekúndu prófsins á tíu beiðnum hraða á sekúndu fór síðan niður og svaraði ekki.

Ef það er engin leit?

Ef það er engin leit þýðir það ekki að vefurinn innihaldi ekki aðra viðkvæma innsláttarreit. Þessi reitur gæti verið heimild. Nú á dögum finnst forriturum gaman að búa til flókna kjötkássa til að vernda innskráningargagnagrunninn fyrir regnbogatöfluárás. Þetta er gott, en slík kjötkássa eyðir miklu af CPU auðlindum. Mikið flæði rangra heimilda leiðir til bilunar í örgjörva og þar af leiðandi hættir síðan að virka.
Tilvist alls kyns eyðublaða fyrir athugasemdir og endurgjöf á síðunni er ástæða til að senda mjög stóra texta þangað eða einfaldlega skapa stórt flóð. Stundum samþykkja síður viðhengdar skrár, þar á meðal á gzip sniði. Í þessu tilfelli tökum við 1TB skrá, þjöppum henni saman í nokkur bæti eða kílóbæt með því að nota gzip og sendum hana á síðuna. Síðan er rennt upp og mjög áhugaverð áhrif fást.

Rest API

Mig langar að gefa smá athygli að svo vinsælum þjónustum eins og Rest API. Að tryggja Rest API er miklu erfiðara en venjuleg vefsíða. Jafnvel léttvægar aðferðir til að vernda gegn lykilorðaafli og annarri ólögmætri virkni virka ekki fyrir Rest API.
Rest API er mjög auðvelt að brjóta vegna þess að það opnar gagnagrunninn beint. Á sama tíma hefur bilun á slíkri þjónustu í för með sér mjög alvarlegar afleiðingar fyrir fyrirtæki. Staðreyndin er sú að Rest API er venjulega ekki aðeins notað fyrir aðalvefsíðuna, heldur einnig fyrir farsímaforritið og sum innri viðskiptaauðlindir. Og ef allt þetta fellur, þá eru áhrifin miklu sterkari en ef um einfalda vefsíðubilun er að ræða.

Hleður þungu efni

Ef okkur býðst að prófa eitthvert venjulegt forrit á einni síðu, áfangasíðu eða nafnspjaldavef sem hefur ekki flókna virkni, leitum við að miklu efni. Til dæmis stórar myndir sem þjónninn sendir, tvöfaldar skrár, pdf skjöl - við reynum að hlaða niður þessu öllu. Slík próf hlaða skráarkerfið vel og stífla rásir og eru því áhrifarík. Það er að segja, jafnvel þótt þú leggir ekki netþjóninn niður, hleður niður stórri skrá á lágum hraða, þá stíflarðu einfaldlega rás markþjónsins og þá verður afneitun á þjónustu.
Dæmi um slíkt próf sýnir að á 30 RPS hraða hætti síðan að svara eða framkallaði 500. netþjónsvillur.

Ekki gleyma að setja upp netþjóna. Þú getur oft fundið að einstaklingur keypti sýndarvél, setti upp Apache þar, stillti allt sjálfgefið, setti upp PHP forrit og hér að neðan geturðu séð útkomuna.

Hér fór álagið í rótina og nam aðeins 10 RPS. Við biðum í 5 mínútur og þjónninn hrundi. Það er að vísu ekki alveg vitað hvers vegna hann féll, en það er gert ráð fyrir að hann hafi einfaldlega haft of mikið minni og því hætt að svara.

Bylgjur byggt

Á síðustu tveimur árum hafa ölduárásir orðið nokkuð vinsælar. Þetta er vegna þess að margar stofnanir kaupa ákveðinn vélbúnað fyrir DDoS vernd, sem þarf ákveðinn tíma til að safna tölfræði til að byrja að sía árásina. Það er, þeir sía ekki árásina á fyrstu 30-40 sekúndunum, vegna þess að þeir safna gögnum og læra. Í samræmi við það, á þessum 30-40 sekúndum geturðu ræst svo mikið á síðunni að auðlindin mun liggja í langan tíma þar til allar beiðnir hafa verið hreinsaðar.
Þegar um var að ræða árásina fyrir neðan var 10 mínútna millibili, eftir það kom nýr, breyttur hluti af árásinni.

Það er, vörnin lærði, byrjaði að sía, en nýr, allt annar hluti af sókninni kom og vörnin fór að læra aftur. Reyndar hættir síun að virka, verndin verður óvirk og síðan er ekki tiltæk.
Bylgjuárásir einkennast af mjög háum gildum í hámarki, þær geta náð hundrað þúsund eða milljón beiðnum á sekúndu, ef um L7 er að ræða. Ef við tölum um L3&4, þá geta verið hundruð gígabita umferðar, eða, í samræmi við það, hundruð mpps, ef þú telur í pökkum.
Vandamálið við slíkar árásir er samstilling. Árásirnar koma frá botneti og krefjast mikillar samstillingar til að búa til mjög stóran einu sinni topp. Og þessi samhæfing gengur ekki alltaf upp: stundum er framleiðslan einhvers konar fleygboga toppur, sem lítur frekar ömurlega út.

Ekki HTTP einn

Til viðbótar við HTTP á L7, viljum við nýta aðrar samskiptareglur. Venjulega er venjuleg vefsíða, sérstaklega venjuleg hýsing, með póstsamskiptareglur og MySQL sem stendur upp úr. Póstsamskiptareglur eru undir minna álagi en gagnagrunnar, en einnig er hægt að hlaða þeim á nokkuð skilvirkan hátt og endar með ofhlaðnum örgjörva á þjóninum.
Okkur gekk nokkuð vel með því að nota 2016 SSH varnarleysið. Nú hefur þessi veikleiki verið lagaður fyrir næstum alla, en það þýðir ekki að ekki sé hægt að senda álag til SSH. Dós. Það er einfaldlega mikið álag af heimildum, SSH étur upp nánast allan CPU á þjóninum og síðan hrynur vefsíðan úr einni eða tveimur beiðnum á sekúndu. Samkvæmt því er ekki hægt að greina þessar einu eða tvær beiðnir byggðar á annálunum frá lögmætu álagi.
Margar tengingar sem við opnum á netþjónum eru einnig áfram viðeigandi. Áður var Apache sekur um þetta, nú er nginx í raun sekur um þetta, þar sem það er oft stillt sjálfgefið. Fjöldi tenginga sem nginx getur haldið opnum er takmarkaður, þannig að við opnum þennan fjölda tenginga, nginx samþykkir ekki lengur nýja tengingu og þar af leiðandi virkar síðan ekki.
Prófunarþyrpingin okkar hefur nægan CPU til að ráðast á SSL handabandi. Í grundvallaratriðum, eins og æfingin sýnir, vilja botnet stundum gera þetta líka. Annars vegar er ljóst að þú getur ekki verið án SSL, vegna þess að Google niðurstöður, röðun, öryggi. Aftur á móti er SSL því miður með CPU vandamál.

L3&4

Þegar við tölum um árás á L3&4 borðinu erum við venjulega að tala um árás á linkastigi. Slíkt álag er næstum alltaf aðgreinanlegt frá lögmætum, nema um SYN-flóðárás sé að ræða. Vandamálið við SYN-flóðárásir fyrir öryggisverkfæri er mikið magn þeirra. Hámarks L3&4 gildi var 1,5-2 Tbit/s. Svona umferð er mjög erfið í vinnslu, jafnvel fyrir stór fyrirtæki, þar á meðal Oracle og Google.
SYN og SYN-ACK eru pakkar sem eru notaðir við að koma á tengingu. Þess vegna er erfitt að greina SYN-flóð frá lögmætu álagi: ekki er ljóst hvort þetta er SYN sem kom til að koma á tengingu, eða hluti af flóði.

UDP-flóð

Venjulega hafa árásarmenn ekki þá hæfileika sem við höfum, svo mögnun er hægt að nota til að skipuleggja árásir. Það er, árásarmaðurinn skannar internetið og finnur annað hvort viðkvæma eða rangt stillta netþjóna sem, til dæmis, sem svar við einum SYN pakka, svara með þremur SYN-ACK. Með því að svíkja upprunanetfangið frá heimilisfangi miðlarans er hægt að auka kraftinn þrisvar sinnum með einum pakka og beina umferð til fórnarlambsins.

Vandamálið með mögnunum er að erfitt er að greina þær. Nýleg dæmi eru meðal annars tilkomumikið mál um viðkvæma memcached. Auk þess eru nú til fullt af IoT tækjum, IP myndavélum, sem eru líka að mestu sjálfgefnar stilltar og sjálfgefið eru þær rangt stilltar, þess vegna gera árásarmenn oftast árásir í gegnum slík tæki.

Erfitt SYN-flóð

SYN-flóð er líklega áhugaverðasta tegund árásar frá sjónarhóli þróunaraðila. Vandamálið er að kerfisstjórar nota oft IP-blokkun til verndar. Þar að auki hefur IP-lokun ekki aðeins áhrif á kerfisstjóra sem starfa með forskriftum, heldur einnig, því miður, sum öryggiskerfi sem eru keypt fyrir mikið fé.
Þessi aðferð getur breyst í hörmung, því ef árásarmenn skipta út IP-tölum mun fyrirtækið loka fyrir eigið undirnet. Þegar eldveggurinn lokar á sinn eigin klasa mun úttakið mistakast utanaðkomandi samskipti og tilföngin bila.
Þar að auki er ekki erfitt að loka á eigið net. Ef skrifstofa viðskiptavinarins er með Wi-Fi net, eða ef árangur auðlinda er mældur með ýmsum vöktunarkerfum, þá tökum við IP tölu þessa vöktunarkerfis eða Wi-Fi skrifstofu viðskiptavinarins og notum það sem heimild. Í lokin virðist tilföngin vera tiltæk, en IP-tölurnar eru lokaðar. Þannig getur þráðlaust net HighLoad ráðstefnunnar, þar sem ný vara fyrirtækisins er kynnt, verið lokað og það hefur í för með sér ákveðinn viðskipta- og efnahagskostnað.
Við prófun getum við ekki notað mögnun í gegnum memcached með neinum ytri auðlindum, vegna þess að það eru samningar um að senda umferð aðeins á leyfilegar IP tölur. Í samræmi við það notum við mögnun í gegnum SYN og SYN-ACK, þegar kerfið bregst við að senda eitt SYN með tveimur eða þremur SYN-ACK, og við úttakið er árásin margfalduð með tvisvar eða þrisvar.

Verkfæri

Eitt af helstu verkfærunum sem við notum fyrir L7 vinnuálag er Yandex-tank. Sérstaklega er draugur notaður sem byssa, auk þess eru nokkur forskriftir til að búa til skothylki og til að greina niðurstöðurnar.
Tcpdump er notað til að greina netumferð og Nmap er notað til að greina netþjóninn. Til að búa til álagið á L3&4 stigi er OpenSSL og smá af okkar eigin töfrum með DPDK bókasafninu notað. DPDK er bókasafn frá Intel sem gerir þér kleift að vinna með netviðmótið framhjá Linux stafla og auka þannig skilvirkni. Auðvitað notum við DPDK ekki aðeins á L3&4 stigi, heldur einnig á L7 stigi, því það gerir okkur kleift að búa til mjög mikið álagsflæði, á bilinu nokkrar milljónir beiðna á sekúndu frá einni vél.
Við notum líka ákveðna umferðargjafa og sérstök verkfæri sem við skrifum fyrir ákveðin próf. Ef við rifjum upp varnarleysið undir SSH, þá er ekki hægt að nýta ofangreint sett. Ef við ráðumst á póstsamskiptareglur tökum við póstforrit eða skrifum einfaldlega forskriftir á þau.

Niðurstöður

Að lokum vil ég segja:

• Til viðbótar við klassískt álagspróf er nauðsynlegt að framkvæma álagspróf. Við höfum raunverulegt dæmi þar sem undirverktaki samstarfsaðila framkvæmdi aðeins álagsprófanir. Það sýndi að auðlindin þolir eðlilegt álag. En svo kom óeðlilegt álag, gestir síðunnar fóru að nota auðlindina aðeins öðruvísi og í kjölfarið lagðist undirverktakinn niður. Þannig er það þess virði að leita að veikleikum jafnvel þó þú sért nú þegar varinn gegn DDoS árásum.
• Nauðsynlegt er að einangra suma hluta kerfisins frá öðrum. Ef þú ert með leit þarftu að færa hana í aðskildar vélar, það er ekki einu sinni í Docker. Vegna þess að ef leit eða heimild mistekst mun að minnsta kosti eitthvað halda áfram að virka. Þegar um netverslun er að ræða munu notendur halda áfram að finna vörur í vörulistanum, fara úr safni, kaupa ef þær hafa þegar heimild eða heimila í gegnum OAuth2.
• Ekki vanrækja alls kyns skýjaþjónustu.
• Notaðu CDN ekki aðeins til að hámarka tafir á neti, heldur einnig sem vörn gegn árásum á útkeyrslu rásar og einfaldlega að flæða inn í kyrrstæða umferð.
• Nauðsynlegt er að nýta sérhæfða verndarþjónustu. Þú getur ekki verndað þig fyrir L3&4 árásum á rásarstigi, því þú ert líklegast einfaldlega ekki með nægilega rás. Þú ert líka ólíklegur til að berjast gegn L7 árásum, þar sem þær geta verið mjög stórar. Auk þess er leitin að litlum árásum enn forréttindi sérþjónustu, sérstakra reiknirita.
• Uppfærðu reglulega. Þetta á ekki aðeins við um kjarnann, heldur einnig um SSH púkann, sérstaklega ef þú hefur þá opna að utan. Í grundvallaratriðum þarf að uppfæra allt, því ólíklegt er að þú getir fylgst með ákveðnum veikleikum á eigin spýtur.

Heimild: www.habr.com