Variti ontwikkelt bescherming tegen bots en DDoS-aanvallen en voert ook stress- en loadtests uit. Op de HighLoad++ 2018-conferentie spraken we over hoe u bronnen kunt beveiligen tegen verschillende soorten aanvallen. Kortom: isoleer delen van het systeem, maak gebruik van clouddiensten en CDN’s en update regelmatig. Maar je kunt de bescherming nog steeds niet aan zonder gespecialiseerde bedrijven :)
Voordat u de tekst leest, kunt u de korte samenvattingen lezen .
En mocht je niet van lezen houden of gewoon de video willen bekijken, dan staat de opname van ons verslag hieronder onder de spoiler.
Video-opname van het rapport
Veel bedrijven weten al hoe ze belastingtests moeten uitvoeren, maar niet allemaal doen ze aan stresstests. Sommige van onze klanten denken dat hun site onkwetsbaar is omdat ze een highload-systeem hebben en het goed beschermt tegen aanvallen. Wij laten zien dat dit niet helemaal waar is.
Voordat we tests uitvoeren, verkrijgen we uiteraard toestemming van de klant, ondertekend en afgestempeld, en met onze hulp kan een DDoS-aanval op niemand worden uitgevoerd. Het testen wordt uitgevoerd op een door de klant gekozen tijdstip, wanneer het verkeer naar zijn bron minimaal is en toegangsproblemen geen gevolgen hebben voor de klanten. Omdat er tijdens het testtraject altijd iets mis kan gaan, hebben wij bovendien voortdurend contact met de klant. Hierdoor kun je niet alleen de behaalde resultaten rapporteren, maar ook tijdens het testen iets veranderen. Na voltooiing van de tests stellen we altijd een rapport op waarin we de geconstateerde tekortkomingen benadrukken en aanbevelingen doen om de zwakke punten van de site weg te nemen.
Hoe we werken
Bij het testen emuleren we een botnet. Omdat we werken met klanten die zich niet op onze netwerken bevinden, leveren we de belasting niet vanaf één IP, maar vanuit ons eigen subnet, om ervoor te zorgen dat de test niet in de eerste minuut eindigt omdat limieten of beveiliging worden geactiveerd. Bovendien hebben we, om een aanzienlijke belasting te creëren, onze eigen redelijk krachtige testserver.
Postulaten
Te veel betekent niet goed
Hoe minder belasting we een hulpbron kunnen laten mislukken, hoe beter. Als je de site kunt laten stoppen met functioneren bij één verzoek per seconde, of zelfs bij één verzoek per minuut, is dat geweldig. Omdat volgens de wet van gemeenheid gebruikers of aanvallers per ongeluk in deze specifieke kwetsbaarheid terechtkomen.
Gedeeltelijk falen is beter dan volledig falen
Wij adviseren altijd om systemen heterogeen te maken. Bovendien is het de moeite waard om ze op fysiek niveau te scheiden, en niet alleen door containerisatie. In het geval van fysieke scheiding is de kans groot dat, zelfs als er iets mislukt op de site, deze niet volledig zal stoppen met werken en dat gebruikers toegang zullen blijven houden tot ten minste een deel van de functionaliteit.
Goede architectuur is de basis voor duurzaamheid
De fouttolerantie van een hulpbron en zijn vermogen om aanvallen en belastingen te weerstaan, moet in de ontwerpfase worden vastgelegd, in feite in de fase van het tekenen van de eerste stroomdiagrammen in een notitieblok. Want als er fatale fouten binnensluipen, is het mogelijk om deze in de toekomst te corrigeren, maar het is erg moeilijk.
Niet alleen de code moet goed zijn, maar ook de configuratie
Veel mensen denken dat een goed ontwikkelteam een garantie is voor fouttolerante dienstverlening. Een goed ontwikkelteam is echt nodig, maar er moet ook een goede operatie zijn, goede DevOps. Dat wil zeggen, we hebben specialisten nodig die Linux en het netwerk correct configureren, configuraties correct in nginx schrijven, limieten instellen, enz. Anders zal de hulpbron alleen goed werken tijdens het testen, en op een gegeven moment zal alles kapot gaan in de productie.
Verschillen tussen belasting- en stresstests
Met belastingtests kunt u de grenzen van het functioneren van het systeem identificeren. Stresstesten zijn gericht op het vinden van zwakke punten in een systeem en worden gebruikt om dit systeem te doorbreken en te zien hoe het zich zal gedragen in het proces van falen van bepaalde onderdelen. In dit geval blijft de aard van de belasting meestal onbekend bij de klant voordat de stresstests beginnen.
Onderscheidende kenmerken van L7-aanvallen
Meestal verdelen we de soorten belasting in belastingen op het niveau L7 en L3&4. L7 is een belasting op applicatieniveau. Meestal betekent dit alleen HTTP, maar we bedoelen elke belasting op TCP-protocolniveau.
L7-aanvallen hebben bepaalde onderscheidende kenmerken. Ten eerste komen ze rechtstreeks naar de applicatie, dat wil zeggen dat het onwaarschijnlijk is dat ze via netwerkmiddelen worden weerspiegeld. Dergelijke aanvallen gebruiken logica en verbruiken daardoor zeer efficiënt en met weinig verkeer CPU, geheugen, schijf, database en andere bronnen.
HTTP-overstroming
Bij elke aanval is de last gemakkelijker te creëren dan te hanteren, en in het geval van L7 is dit ook waar. Het is niet altijd gemakkelijk om aanvalsverkeer te onderscheiden van legitiem verkeer, en meestal kan dit worden gedaan op basis van frequentie, maar als alles correct is gepland, is het onmogelijk om uit de logboeken te begrijpen waar de aanval plaatsvindt en waar de legitieme verzoeken zich bevinden.
Neem als eerste voorbeeld een HTTP Flood-aanval. Uit de grafiek blijkt dat dergelijke aanvallen doorgaans zeer krachtig zijn; in het onderstaande voorbeeld bedroeg het piekaantal verzoeken meer dan 600 per minuut.
HTTP Flood is de gemakkelijkste manier om belasting te creëren. Normaal gesproken is er een soort belastingtesttool nodig, zoals ApacheBench, en worden een verzoek en een doel ingesteld. Met zo'n eenvoudige aanpak is de kans groot dat je tegen servercaching aanloopt, maar het is gemakkelijk om dit te omzeilen. Door bijvoorbeeld willekeurige tekenreeksen aan het verzoek toe te voegen, wordt de server gedwongen voortdurend een nieuwe pagina weer te geven.
Vergeet ook de user-agent niet tijdens het maken van een belasting. Veel user-agents van populaire testtools worden gefilterd door systeembeheerders, en in dit geval bereikt de belasting eenvoudigweg de backend niet. U kunt het resultaat aanzienlijk verbeteren door een min of meer geldige header uit de browser in het verzoek in te voegen.
Hoe eenvoudig HTTP Flood-aanvallen ook zijn, ze hebben ook hun nadelen. Ten eerste zijn er grote hoeveelheden stroom nodig om de belasting te creëren. Ten tweede zijn dergelijke aanvallen heel gemakkelijk te detecteren, vooral als ze afkomstig zijn van één adres. Als gevolg hiervan worden verzoeken onmiddellijk gefilterd door systeembeheerders of zelfs op providerniveau.
Wat te zoeken
Om het aantal verzoeken per seconde te verminderen zonder de efficiëntie te verliezen, moet je een beetje fantasie tonen en de site verkennen. Zo kunt u niet alleen het kanaal of de server laden, maar ook afzonderlijke delen van de applicatie, bijvoorbeeld databases of bestandssystemen. U kunt ook zoeken naar plaatsen op de site waar grote berekeningen worden uitgevoerd: rekenmachines, productselectiepagina's, enz. Ten slotte komt het vaak voor dat de site een soort PHP-script heeft dat een pagina van enkele honderdduizenden regels genereert. Zo'n script belast de server ook aanzienlijk en kan een doelwit worden voor een aanval.
Waar moet je kijken
Wanneer we een bron scannen voordat we gaan testen, kijken we uiteraard eerst naar de site zelf. We zijn op zoek naar allerlei invoervelden, zware bestanden - in het algemeen alles dat problemen kan veroorzaken voor de bron en de werking ervan kan vertragen. Banale ontwikkeltools in Google Chrome en Firefox helpen hier en tonen de responstijden van pagina's.
Wij scannen ook subdomeinen. Er is bijvoorbeeld een bepaalde online winkel, abc.com, en deze heeft een subdomein admin.abc.com. Hoogstwaarschijnlijk is dit een beheerderspaneel met autorisatie, maar als u het belast, kan dit problemen veroorzaken voor de hoofdbron.
De site heeft mogelijk een subdomein api.abc.com. Hoogstwaarschijnlijk is dit een bron voor mobiele applicaties. De applicatie vind je in de App Store of Google Play, installeer een speciaal access point, ontleed de API en registreer testaccounts. Het probleem is dat mensen vaak denken dat alles wat door autorisatie wordt beschermd, immuun is voor denial-of-service-aanvallen. Vermoedelijk is autorisatie de beste CAPTCHA, maar dat is niet het geval. Het is gemakkelijk om 10 tot 20 testaccounts te maken, maar door ze aan te maken krijgen we toegang tot complexe en onverhulde functionaliteit.
Uiteraard kijken we naar de geschiedenis, naar robots.txt en WebArchive, ViewDNS, en zoeken naar oude versies van de bron. Soms komt het voor dat ontwikkelaars bijvoorbeeld mail2.yandex.net hebben uitgerold, maar de oude versie, mail.yandex.net, blijft bestaan. Deze mail.yandex.net wordt niet langer ondersteund, er worden geen ontwikkelingsbronnen aan toegewezen, maar het blijft de database verbruiken. Dienovereenkomstig kunt u met de oude versie effectief gebruik maken van de bronnen van de backend en alles wat zich achter de lay-out bevindt. Natuurlijk gebeurt dit niet altijd, maar toch komen we dit nogal eens tegen.
Uiteraard analyseren we alle verzoekparameters en de cookiestructuur. Je kunt bijvoorbeeld wat waarde in een JSON-array in een cookie dumpen, veel nesting creëren en de bron onredelijk lang laten werken.
Zoekbelasting
Het eerste dat in je opkomt bij het onderzoeken van een site is het laden van de database, aangezien bijna iedereen een zoekopdracht heeft, en deze is helaas voor bijna iedereen slecht beschermd. Om de een of andere reden besteden ontwikkelaars niet genoeg aandacht aan zoeken. Maar er is één aanbeveling: u moet geen verzoeken van hetzelfde type indienen, omdat u dan te maken kunt krijgen met caching, zoals het geval is bij HTTP-flood.
Het uitvoeren van willekeurige zoekopdrachten naar de database is ook niet altijd effectief. Het is veel beter om een lijst met trefwoorden te maken die relevant zijn voor de zoekopdracht. Als we terugkeren naar het voorbeeld van een online winkel: laten we zeggen dat de site autobanden verkoopt en u de mogelijkheid biedt om de straal van de banden, het type auto en andere parameters in te stellen. Dienovereenkomstig zullen combinaties van relevante woorden de database dwingen om onder veel complexere omstandigheden te werken.
Bovendien is het de moeite waard om paginering te gebruiken: het is voor een zoekopdracht veel moeilijker om de voorlaatste pagina met zoekresultaten terug te geven dan de eerste. Dat wil zeggen, met behulp van paginering kunt u de lading enigszins diversifiëren.
Het onderstaande voorbeeld toont de zoekbelasting. Het is te zien dat vanaf de allereerste seconde van de test met een snelheid van tien verzoeken per seconde de site uitviel en niet reageerde.
Als er geen zoekopdracht is?
Als er niet wordt gezocht, betekent dit niet dat de site geen andere kwetsbare invoervelden bevat. Dit veld kan een autorisatie zijn. Tegenwoordig maken ontwikkelaars graag complexe hashes om de inlogdatabase te beschermen tegen een regenboogtafelaanval. Dit is goed, maar dergelijke hashes verbruiken veel CPU-bronnen. Een grote stroom valse autorisaties leidt tot een processorfout en als gevolg daarvan stopt de site met werken.
De aanwezigheid op de site van allerlei formulieren voor commentaar en feedback is een reden om hele grote teksten daarheen te sturen of simpelweg een enorme overstroming te creëren. Soms accepteren sites bijgevoegde bestanden, ook in gzip-indeling. In dit geval nemen we een bestand van 1 TB, comprimeren het tot meerdere bytes of kilobytes met behulp van gzip en sturen het naar de site. Vervolgens wordt het opengeritst en wordt een zeer interessant effect verkregen.
Rest API
Ik zou graag wat aandacht willen besteden aan populaire services als de Rest API. Het beveiligen van een Rest API is veel lastiger dan een reguliere website. Zelfs triviale beschermingsmethoden tegen brute kracht van wachtwoorden en andere onwettige activiteiten werken niet voor de Rest API.
De Rest API is heel gemakkelijk te kraken omdat deze rechtstreeks toegang heeft tot de database. Tegelijkertijd heeft het falen van een dergelijke dienst vrij ernstige gevolgen voor het bedrijfsleven. Feit is dat de Rest API meestal niet alleen voor de hoofdwebsite wordt gebruikt, maar ook voor de mobiele applicatie en enkele interne bedrijfsbronnen. En als dit allemaal wegvalt, dan is het effect veel sterker dan bij een simpele websitestoring.
Zware inhoud laden
Als ons wordt aangeboden een gewone applicatie van één pagina, een landingspagina of een visitekaartjeswebsite te testen die geen complexe functionaliteit heeft, zoeken we naar zware inhoud. Bijvoorbeeld grote afbeeldingen die de server verzendt, binaire bestanden, pdf-documentatie - we proberen dit allemaal te downloaden. Dergelijke tests laden het bestandssysteem goed en verstoppen kanalen, en zijn daarom effectief. Dat wil zeggen dat zelfs als u de server niet neerlegt en een groot bestand met lage snelheid downloadt, u eenvoudigweg het kanaal van de doelserver verstopt en er een Denial of Service zal optreden.
Een voorbeeld van zo'n test laat zien dat bij een snelheid van 30 RPS de site niet meer reageerde of 500ste serverfouten produceerde.
Vergeet het instellen van servers niet. Vaak zie je dat iemand een virtuele machine heeft gekocht, Apache daar heeft geïnstalleerd, alles standaard heeft geconfigureerd, een PHP-applicatie heeft geïnstalleerd en hieronder zie je het resultaat.
Hier ging de belasting naar de wortel en bedroeg slechts 10 RPS. We wachtten 5 minuten en de server crashte. Het is waar dat het niet helemaal bekend is waarom hij viel, maar er wordt aangenomen dat hij simpelweg te veel geheugen had en daarom niet meer reageerde.
Op golven gebaseerd
De afgelopen twee jaar zijn golfaanvallen behoorlijk populair geworden. Dit komt door het feit dat veel organisaties bepaalde hardware kopen voor DDoS-bescherming, die een bepaalde hoeveelheid tijd nodig hebben om statistieken te verzamelen om de aanval te kunnen filteren. Dat wil zeggen dat ze de aanval in de eerste 30-40 seconden niet filteren, omdat ze gegevens verzamelen en leren. Dienovereenkomstig kunt u in deze 30-40 seconden zoveel op de site lanceren dat de bron lang zal blijven liggen totdat alle verzoeken zijn opgelost.
In het geval van onderstaande aanval was er een pauze van 10 minuten, waarna een nieuw, aangepast deel van de aanval arriveerde.
Dat wil zeggen: de verdediging leerde, begon te filteren, maar er kwam een nieuw, heel ander deel van de aanval en de verdediging begon opnieuw te leren. In feite stopt het filteren met werken, wordt de bescherming ineffectief en is de site niet meer beschikbaar.
Golfaanvallen worden gekenmerkt door zeer hoge waarden op de piek, deze kunnen honderdduizend of een miljoen verzoeken per seconde bereiken, in het geval van L7. Als we het hebben over L3&4, dan kunnen er honderden gigabits aan verkeer zijn, of dienovereenkomstig honderden mpps, als je het aantal pakketten meetelt.
Het probleem met dergelijke aanvallen is synchronisatie. De aanvallen komen van een botnet en vereisen een hoge mate van synchronisatie om een zeer grote eenmalige piek te creëren. En deze coördinatie lukt niet altijd: soms is de output een soort parabolische piek, die er nogal zielig uitziet.
Niet alleen HTTP
Naast HTTP op L7 exploiteren we graag andere protocollen. In de regel heeft een gewone website, vooral een reguliere hosting, mailprotocollen en steekt MySQL eruit. Mailprotocollen worden minder belast dan databases, maar kunnen ook behoorlijk efficiënt worden geladen en resulteren in een overbelaste CPU op de server.
We waren behoorlijk succesvol met het gebruik van de SSH-kwetsbaarheid uit 2016. Nu is deze kwetsbaarheid voor vrijwel iedereen verholpen, maar dit betekent niet dat er geen belasting kan worden ingediend bij SSH. Kan. Er is gewoon een enorme hoeveelheid autorisaties, SSH slokt bijna de hele CPU op de server op, en dan stort de website in vanaf één of twee verzoeken per seconde. Dienovereenkomstig kunnen deze een of twee verzoeken op basis van de logbestanden niet worden onderscheiden van een legitieme belasting.
Ook veel verbindingen die we op servers openen blijven relevant. Voorheen maakte Apache zich hier schuldig aan, nu maakt nginx zich hier ook daadwerkelijk schuldig aan, omdat het vaak standaard is geconfigureerd. Het aantal verbindingen dat nginx open kan houden is beperkt, daarom openen wij dit aantal verbindingen, nginx accepteert geen nieuwe verbinding meer, en daardoor werkt de site niet.
Ons testcluster heeft voldoende CPU om SSL-handshake aan te vallen. In principe doen botnets dit, zo blijkt uit de praktijk, soms ook graag. Aan de ene kant is het duidelijk dat je niet zonder SSL kunt, vanwege Google-resultaten, ranking, beveiliging. Aan de andere kant heeft SSL helaas een CPU-probleem.
L3&4
Als we het hebben over een aanval op L3&4-niveaus, hebben we het meestal over een aanval op linkniveau. Een dergelijke belasting is vrijwel altijd te onderscheiden van een legitieme belasting, tenzij het een SYN-flood-aanval betreft. Het probleem met SYN-flood-aanvallen voor beveiligingstools is hun grote volume. De maximale L3&4-waarde was 1,5-2 Tbit/s. Dit soort verkeer is zelfs voor grote bedrijven, waaronder Oracle en Google, erg moeilijk te verwerken.
SYN en SYN-ACK zijn pakketten die worden gebruikt bij het tot stand brengen van een verbinding. Daarom is SYN-flood moeilijk te onderscheiden van een legitieme belasting: het is niet duidelijk of dit een SYN is die een verbinding tot stand heeft gebracht, of onderdeel is van een overstroming.
UDP-overstroming
Aanvallers beschikken doorgaans niet over de mogelijkheden die wij hebben, dus versterking kan worden gebruikt om aanvallen te organiseren. Dat wil zeggen dat de aanvaller het internet scant en kwetsbare of verkeerd geconfigureerde servers vindt die bijvoorbeeld in reactie op één SYN-pakket reageren met drie SYN-ACKs. Door het bronadres te spoofen vanaf het adres van de doelserver, is het mogelijk om het vermogen bijvoorbeeld drie keer te vergroten met een enkel pakket en het verkeer om te leiden naar het slachtoffer.
Het probleem met versterkingen is dat ze moeilijk te detecteren zijn. Recente voorbeelden zijn onder meer het sensationele geval van de kwetsbare memcached. Bovendien zijn er nu veel IoT-apparaten, IP-camera's, die ook meestal standaard zijn geconfigureerd, en standaard zijn ze verkeerd geconfigureerd. Daarom voeren aanvallers meestal aanvallen uit via dergelijke apparaten.
Moeilijke SYN-overstroming
SYN-flood is waarschijnlijk het meest interessante type aanval vanuit het perspectief van een ontwikkelaar. Het probleem is dat systeembeheerders vaak IP-blokkering gebruiken ter bescherming. Bovendien heeft IP-blokkering niet alleen gevolgen voor systeembeheerders die met behulp van scripts handelen, maar helaas ook voor sommige beveiligingssystemen die voor veel geld worden gekocht.
Deze methode kan een ramp worden, want als aanvallers IP-adressen vervangen, blokkeert het bedrijf zijn eigen subnet. Wanneer de Firewall zijn eigen cluster blokkeert, zal de uitvoer externe interacties mislukken en zal de bron mislukken.
Bovendien is het niet moeilijk om je eigen netwerk te blokkeren. Als het kantoor van de klant over een wifi-netwerk beschikt, of als de prestaties van bronnen worden gemeten met behulp van verschillende monitoringsystemen, dan nemen we het IP-adres van dit monitoringsysteem of de wifi van het kantoor van de klant en gebruiken dit als bron. Uiteindelijk lijkt de bron beschikbaar te zijn, maar zijn de doel-IP-adressen geblokkeerd. Zo kan het Wi-Fi-netwerk van de HighLoad-conferentie, waar het nieuwe product van het bedrijf wordt gepresenteerd, worden geblokkeerd, en dit brengt bepaalde zakelijke en economische kosten met zich mee.
Tijdens het testen kunnen we geen gebruik maken van versterking via memcached met externe bronnen, omdat er afspraken zijn om verkeer alleen naar toegestane IP-adressen te sturen. Dienovereenkomstig gebruiken we versterking via SYN en SYN-ACK, wanneer het systeem reageert op het verzenden van één SYN met twee of drie SYN-ACK's, en aan de uitgang wordt de aanval twee of drie keer vermenigvuldigd.
Gereedschap
Een van de belangrijkste tools die we gebruiken voor de L7-werklast is Yandex-tank. In het bijzonder wordt een fantoom als pistool gebruikt, en er zijn verschillende scripts voor het genereren van cartridges en voor het analyseren van de resultaten.
Tcpdump wordt gebruikt om netwerkverkeer te analyseren en Nmap wordt gebruikt om de server te analyseren. Om de belasting op L3- en 4-niveau te creëren, wordt OpenSSL en een beetje van onze eigen magie met de DPDK-bibliotheek gebruikt. DPDK is een bibliotheek van Intel waarmee u met de netwerkinterface kunt werken zonder de Linux-stack te omzeilen, waardoor de efficiëntie wordt verhoogd. Uiteraard gebruiken we DPDK niet alleen op L3&4-niveau, maar ook op L7-niveau, omdat we hierdoor een zeer hoge loadflow kunnen creëren, binnen het bereik van enkele miljoenen verzoeken per seconde vanaf één machine.
We gebruiken ook bepaalde verkeersgeneratoren en speciale tools die we voor specifieke tests schrijven. Als we ons de kwetsbaarheid onder SSH herinneren, kan bovenstaande set niet worden misbruikt. Als we het mailprotocol aanvallen, gebruiken we mailhulpprogramma's of schrijven we er eenvoudigweg scripts op.
Bevindingen
Als conclusie zou ik willen zeggen:
- Naast de klassieke belastingtesten is het noodzakelijk om stresstesten uit te voeren. We hebben een reëel voorbeeld waarbij de onderaannemer van een partner alleen belastingtests uitvoerde. Het toonde aan dat de hulpbron bestand is tegen de normale belasting. Maar toen verscheen er een abnormale belasting, bezoekers van de site begonnen de bron een beetje anders te gebruiken en als gevolg daarvan ging de onderaannemer liggen. Het is dus de moeite waard om naar kwetsbaarheden te zoeken, zelfs als u al beschermd bent tegen DDoS-aanvallen.
- Het is noodzakelijk om sommige delen van het systeem van andere te isoleren. Als u een zoekopdracht heeft, moet u deze naar afzonderlijke machines verplaatsen, dat wil zeggen, zelfs niet naar Docker. Want als zoeken of autoriseren mislukt, blijft er in ieder geval iets werken. In het geval van een online winkel zullen gebruikers producten blijven vinden in de catalogus, vanuit de aggregator gaan, kopen als ze al geautoriseerd zijn, of autoriseren via OAuth2.
- Verwaarloos alle soorten clouddiensten niet.
- Gebruik CDN niet alleen om netwerkvertragingen te optimaliseren, maar ook als bescherming tegen aanvallen op kanaaluitputting en het eenvoudigweg overstromen van statisch verkeer.
- Het is noodzakelijk om gespecialiseerde beschermingsdiensten te gebruiken. Je kunt jezelf niet beschermen tegen L3&4-aanvallen op kanaalniveau, omdat je hoogstwaarschijnlijk simpelweg niet over een voldoende kanaal beschikt. Het is ook onwaarschijnlijk dat je L7-aanvallen kunt afweren, omdat ze erg groot kunnen zijn. Bovendien is de zoektocht naar kleine aanvallen nog steeds het voorrecht van speciale diensten, speciale algoritmen.
- Regelmatig bijwerken. Dit geldt niet alleen voor de kernel, maar ook voor de SSH-daemon, vooral als je deze naar buiten toe open hebt staan. In principe moet alles geüpdatet worden, omdat het onwaarschijnlijk is dat je bepaalde kwetsbaarheden zelf kunt opsporen.
Bron: www.habr.com