Variti ontwikkel beskerming teen bots en DDoS-aanvalle, en voer ook stres- en lastoetse uit. By die HighLoad++ 2018-konferensie het ons gepraat oor hoe om hulpbronne teen verskillende soorte aanvalle te beveilig. Kortom: isoleer dele van die stelsel, gebruik wolkdienste en CDN's, en werk gereeld op. Maar sonder gespesialiseerde maatskappye met beskerming, kan jy steeds nie klaarkom nie 🙂
Voordat u die teks lees, kan u die kort tesisse lees .
En as jy nie daarvan hou om te lees nie of net na die video wil kyk, is die rekord van ons verslag hieronder onder die bederf.
Video-opname van die verslag
Baie maatskappye weet reeds hoe om lastoetse te doen, maar nie almal doen strestoetse nie. Sommige van ons kliënte dink dat hul webwerf onkwesbaar is omdat hulle 'n hoëladingstelsel het en dit goed beskerm teen aanvalle. Ons wys dat dit nie heeltemal waar is nie.
Natuurlik, voordat ons toetse uitvoer, kry ons toestemming van die kliënt, met 'n handtekening en 'n seël, en met ons hulp is dit onmoontlik om 'n DDoS-aanval op enigiemand te maak. Toetsing word uitgevoer op die tyd wat die kliënt gekies het, wanneer die bywoning van sy hulpbron minimaal is en probleme met toegang nie kliënte sal beïnvloed nie. Daarbenewens, aangesien iets altyd tydens die toetsproses verkeerd kan gaan, het ons voortdurend kontak met die kliënt. Dit laat nie net toe om verslag te doen oor die resultate wat behaal is nie, maar ook om iets tydens toetsing te verander. Aan die einde van die toetsing stel ons altyd 'n verslag op waarin ons die geïdentifiseerde tekortkominge uitwys en aanbevelings gee oor hoe om die swakhede van die webwerf uit te skakel.
Hoe ons werk
Wanneer ons toets, boots ons 'n botnet na. Aangesien ons met kliënte werk wat nie in ons netwerke geleë is nie, sodat die toets nie in die eerste minuut eindig nie as gevolg van die aktivering van limiete of beskerming, laai ons nie vanaf een IP nie, maar vanaf ons eie subnet. Boonop het ons ons eie redelik kragtige toetsbediener om 'n aansienlike las te skep.
Postulate
Baie beteken nie goed nie
Hoe minder las ons die hulpbron tot mislukking kan bring, hoe beter. As jy die webwerf kan laat ophou funksioneer teen een versoek per sekonde, of selfs een versoek per minuut, is dit wonderlik. Want volgens die wet van gemeenheid sal gebruikers of aanvallers per ongeluk in hierdie spesifieke kwesbaarheid val.
Gedeeltelike mislukking is beter as volledig
Ons raai altyd aan om stelsels heterogeen te maak. Boonop is dit die moeite werd om hulle op fisiese vlak te skei, en nie net deur containerisering nie. In die geval van 'n fisiese skeiding, selfs as iets op die webwerf misluk, is dit waarskynlik dat dit nie heeltemal sal ophou werk nie, en gebruikers sal steeds toegang hê tot ten minste 'n deel van die funksionaliteit.
Die regte argitektuur is die grondslag van volhoubaarheid
Die fouttoleransie van 'n hulpbron en sy vermoë om aanvalle en vragte te weerstaan, moet in die ontwerpstadium neergelê word, trouens by die stadium van die teken van die eerste blokdiagramme in 'n notaboek. Want as noodlottige foute insluip, is dit moontlik om dit in die toekoms reg te stel, maar dit is baie moeilik.
Nie net die kode moet goed wees nie, maar ook die config
Baie mense dink 'n goeie ontwikkelingspan is 'n waarborg van diensfouttoleransie. ’n Goeie ontwikkelingspan is regtig nodig, maar daar moet ook goeie bedrywighede wees, goeie DevOps. Dit wil sê, ons benodig spesialiste wat Linux en die netwerk korrek sal konfigureer, konfigurasies korrek in nginx sal skryf, limiete sal stel, ensovoorts. Andersins sal die hulpbron net op die toets goed werk, en in produksie sal alles op 'n sekere punt breek.
Verskille tussen las- en strestoetsing
Lastoetsing laat jou toe om die limiete van die stelsel se funksionering te identifiseer. Strestoetsing is daarop gemik om swakhede in die stelsel te vind en word gebruik om hierdie stelsel te breek en te sien hoe dit sal optree in die proses van mislukking van sekere dele. Terselfdertyd bly die aard van die las gewoonlik onbekend aan die kliënt tot die begin van strestoetsing.
Kenmerkende kenmerke van L7-aanvalle
Ons verdeel gewoonlik vragtipes in L7- en L3&4-vragte. L7 is die las op die toepassingsvlak, meestal word dit slegs as HTTP verstaan, maar ons bedoel enige las op die TCP-protokolvlak.
L7-aanvalle het sekere onderskeidende kenmerke. Eerstens kom hulle direk na die toepassing, dit wil sê, dit is onwaarskynlik dat hulle deur netwerkmiddele weerspieël sal word. Sulke aanvalle gebruik logika, en as gevolg hiervan verbruik hulle SVE, geheue, skyf, databasis en ander hulpbronne baie doeltreffend en met min verkeer.
HTTP-vloed
In die geval van enige aanval is die vrag makliker om te skep as om te verwerk, en in die geval van L7 is dit ook waar. Dit is nie altyd maklik om aanvalsverkeer van wettige verkeer te onderskei nie, en dit kan meestal volgens frekwensie gedoen word, maar as alles reg beplan is, is dit onmoontlik om uit die logboeke te verstaan waar die aanval is en waar die wettige versoeke is.
As 'n eerste voorbeeld, oorweeg die HTTP-vloed-aanval. Die grafiek toon dat sulke aanvalle gewoonlik baie kragtig is, in die voorbeeld hieronder het die piekgetal versoeke 600 duisend per minuut oorskry.
HTTP Flood is die maklikste manier om vrag te genereer. Dit neem gewoonlik 'n soort lastoetsinstrument, soos ApacheBench, en stel 'n navraag en 'n teiken. Met so 'n eenvoudige benadering is daar 'n groot waarskynlikheid dat u bedienerkas sal raakloop, maar dit is maklik om daar rond te kom. Byvoorbeeld, deur ewekansige stringe by die versoek te voeg, wat die bediener sal dwing om voortdurend 'n vars bladsy terug te gee.
Moet ook nie vergeet van die gebruiker-agent in die proses om 'n vrag te skep nie. Baie gebruikersagente van gewilde toetsinstrumente word deur stelseladministrateurs gefiltreer, in welke geval die vrag dalk eenvoudig nie die agterkant bereik nie. U kan die resultaat aansienlik verbeter deur 'n min of meer geldige kop vanaf die blaaier in die versoek in te voeg.
Alhoewel HTTP-vloedaanvalle eenvoudig is, het dit ook hul nadele. Eerstens verg dit baie krag om 'n las te skep. Tweedens is sulke aanvalle baie maklik om op te spoor, veral as hulle van dieselfde adres af kom. Gevolglik begin versoeke onmiddellik gefiltreer word deur stelseladministrateurs of selfs op verskaffervlak.
Waarna om te kyk
Om die aantal versoeke per sekonde te verminder en terselfdertyd nie doeltreffendheid te verloor nie, moet jy 'n bietjie verbeelding toon en die webwerf verken. U kan dus nie net die kanaal of die bediener laai nie, maar ook individuele dele van die toepassing, byvoorbeeld databasisse of lêerstelsels. Jy kan ook plekke op die webwerf soek wat groot berekeninge doen: sakrekenaars, produkkeusebladsye, ensovoorts. Ten slotte gebeur dit dikwels dat die webwerf 'n soort php-skrip het wat 'n bladsy van 'n paar honderdduisend reëls genereer. So 'n skrip laai ook die bediener swaar en kan 'n teiken vir aanval word.
Waar om te kyk
Wanneer ons 'n hulpbron skandeer voordat ons dit toets, kyk ons eerstens natuurlik na die webwerf self. Ons soek allerhande invoervelde, swaar lêers – oor die algemeen alles wat probleme vir die hulpbron kan skep en dit kan vertraag. Die alledaagse ontwikkelingsnutsgoed in Google Chrome en Firefox help hier, wat die reaksietyd van die bladsy wys.
Ons skandeer ook subdomeine. Daar is byvoorbeeld 'n sekere aanlynwinkel, abc.com, en dit het 'n subdomein admin.abc.com. Heel waarskynlik is dit 'n administrasiepaneel met magtiging, maar as jy 'n las daarop plaas, kan dit probleme vir die hoofbron skep.
Die webwerf kan 'n subdomein api.abc.com hê. Dit is waarskynlik 'n hulpbron vir mobiele toepassings. Die toepassing kan gevind word in die App Store of Google Play, stel 'n spesiale toegangspunt op, ontleed die API en registreer toetsrekeninge. Die probleem is dat mense dikwels dink dat alles wat deur magtiging beskerm word, nie kwesbaar is vir ontkenningsaanvalle nie. Na bewering is magtiging die beste CAPTCHA, maar dit is nie. Dit is maklik om 10-20 toetsrekeninge te maak, en deur dit te skep, kry ons toegang tot komplekse en openlike funksionaliteit.
Natuurlik kyk ons na die geskiedenis, by robots.txt en WebArchive, ViewDNS, op soek na ou weergawes van die hulpbron. Soms gebeur dit dat die ontwikkelaars byvoorbeeld mail2.yandex.net uitgerol het, maar die ou weergawe, mail.yandex.net, het gebly. Hierdie mail.yandex.net word nie meer ondersteun nie, ontwikkelingshulpbronne word nie daaraan toegeken nie, maar dit gaan voort om die databasis te verbruik. Gevolglik, met behulp van die ou weergawe, kan u die hulpbronne van die backend en alles wat agter die uitleg is, effektief gebruik. Dit gebeur natuurlik nie altyd nie, maar ons kom dit in elk geval nogal gereeld teë.
Natuurlik berei ons alle versoekparameters voor, die koekiestruktuur. Jy kan byvoorbeeld 'n bietjie waarde in die JSON-skikking binne die koekie gooi, 'n groot nes skep en die hulpbron vir 'n onredelike lang tyd laat werk.
Soek vrag
Die eerste ding wat in gedagte kom wanneer u 'n webwerf verken, is om die databasis te laai, aangesien byna almal 'n soektog het, en ongelukkig het byna almal dit swak beskerm. Om een of ander rede gee ontwikkelaars nie genoeg aandag aan soek nie. Maar daar is een aanbeveling hier - jy moet nie dieselfde tipe versoeke maak nie, want jy kan kasgeheue teëkom, soos die geval is met HTTP-vloed.
Om ewekansige navrae na die databasis te maak is ook nie altyd doeltreffend nie. Dit is baie beter om 'n lys sleutelwoorde te skep wat relevant is vir die soektog. As ons terugkeer na die voorbeeld van 'n aanlynwinkel: kom ons sê die webwerf verkoop motorbande en laat jou toe om die bandradius, tipe motor en ander parameters in te stel. Gevolglik sal kombinasies van relevante woorde die databasis in baie meer komplekse toestande laat werk.
Daarbenewens is dit die moeite werd om paginering te gebruik: dit is baie moeiliker vir die soektog om die voorlaaste bladsy van die soekresultate te gee as die eerste een. Dit wil sê, met behulp van paginering kan u die vrag 'n bietjie diversifiseer.
Die voorbeeld hieronder wys die vrag in die soektog. Dit kan gesien word dat die webwerf vanaf die heel eerste sekonde van die toets teen 'n spoed van tien versoeke per sekonde gelê het en nie gereageer het nie.
As daar geen soektog is nie?
As daar geen soektog is nie, beteken dit nie dat die webwerf nie ander kwesbare invoervelde bevat nie. Magtiging kan so 'n veld wees. Nou wil ontwikkelaars komplekse hashes maak om die aanmelddatabasis teen 'n reënboogtafelaanval te beskerm. Dit is goed, maar sulke hashes verbruik baie SVE-hulpbronne. 'n Groot vloei van vals magtigings lei tot 'n verwerkermislukking, en as gevolg daarvan hou die webwerf op om by die uitgang te werk.
Die teenwoordigheid op die webwerf van allerhande vorms vir kommentaar en terugvoer is 'n rede om baie groot tekste daarheen te stuur of bloot 'n massiewe vloed te skep. Soms aanvaar werwe aanhegsels, insluitend dié in gzip-formaat. In hierdie geval neem ons 'n 1TB-lêer, gebruik gzip om dit tot 'n paar grepe of kilogrepe saam te pers en stuur dit na die webwerf. Dan word dit oopgerits en 'n baie interessante effek word verkry.
Rus API
Ek wil graag 'n bietjie aandag gee aan sulke gewilde dienste vandag soos die Rest API. Om 'n Rest API te beveilig is baie moeiliker as 'n gewone webwerf. Vir die Rest API werk selfs banale metodes van beskerming teen wagwoord brute force en ander onwettige aktiwiteite nie.
Die Rest API is baie maklik om te breek omdat dit direk met die databasis praat. Terselfdertyd hou die onttrekking van so 'n diens nogal ernstige gevolge vir die onderneming in. Die feit is dat die Rest API gewoonlik nie net aan die hoofwebwerf gekoppel is nie, maar ook aan 'n mobiele toepassing, sommige interne besigheidshulpbronne. En as dit alles val, dan is die effek baie sterker as in die geval van die mislukking van 'n eenvoudige webwerf.
Swaar inhoudlading
As ons aangebied word om een of ander gewone enkelbladsy-toepassing, bestemmingsbladsy, besigheidskaartjie-werf te toets wat nie komplekse funksionaliteit het nie, is ons op soek na swaar inhoud. Byvoorbeeld, groot prente wat die bediener gee, binêre lêers, pdf-dokumentasie - ons probeer dit alles aflaai. Sulke toetse laai die lêerstelsel goed en verstop kanale, en is dus effektief. Dit wil sê, selfs as jy nie die bediener neersit nie, en 'n groot lêer teen lae spoed aflaai, sal jy eenvoudig die kanaal van die teikenbediener verstop en dan sal 'n ontkenning van diens plaasvind.
Op die voorbeeld van so 'n toets, kan dit gesien word dat die webwerf teen 'n spoed van 30 RPS opgehou het om te reageer, of 500 bedienerfoute uitgereik het.
Moenie vergeet om bedieners op te stel nie. Jy kan dikwels vind dat 'n persoon 'n virtuele masjien gekoop het, Apache daar geïnstalleer het, alles by verstek gekonfigureer het, 'n php-toepassing geplaas het, en hieronder kan jy die resultaat sien.
Hier het die vrag na die wortel gegaan en was slegs 10 RPS. Ons het 5 minute gewag en die bediener het afgegaan. Tot die einde is dit egter nie bekend hoekom hy geval het nie, maar daar is 'n aanname dat hy eenvoudig te veel geheue geëet het, en daarom opgehou het om te reageer.
Golf gebaseer
In die laaste jaar of twee het golfaanvalle baie gewild geword. Dit is te wyte aan die feit dat baie organisasies sekere stukke hardeware koop vir beskerming teen DDoS, wat 'n sekere hoeveelheid tyd benodig om statistieke te versamel om 'n aanval te begin filter. Dit wil sê, hulle filter nie die aanval in die eerste 30-40 sekondes nie, want hulle versamel data en leer. Gevolglik, in hierdie 30-40 sekondes, kan soveel op die webwerf bekendgestel word dat die hulpbron vir 'n lang tyd sal lê totdat alle versoeke gehark is.
In die geval van die aanval hieronder was daar 'n interval van 10 minute, waarna 'n nuwe, gewysigde gedeelte van die aanval opgedaag het.
Dit wil sê, die verdediging het geleer, het die filter begin, maar 'n nuwe, heeltemal ander gedeelte van die aanval het opgedaag, en die verdediging het weer begin oefen. Trouens, filter hou op werk, beskerming word ondoeltreffend en die webwerf is nie beskikbaar nie.
Golfaanvalle word gekenmerk deur baie hoë waardes op die hoogtepunt, dit kan honderdduisend of 'n miljoen versoeke per sekonde bereik, in die geval van L7. As ons praat oor L3 & 4, dan kan daar honderde gigabits verkeer wees, of, dienooreenkomstig, honderde mpps, as jy in pakkies tel.
Die probleem met sulke aanvalle is sinchronisasie. Aanvalle kom van 'n botnet af, en 'n hoë mate van sinchronisasie is nodig om 'n baie groot eenmalige piek te skep. En hierdie koördinasie werk nie altyd uit nie: soms is die uitset 'n soort paraboliese piek, wat nogal pateties lyk.
Nie HTTP Single nie
Benewens HTTP op die L7-vlak, wil ons graag ander protokolle ontgin. As 'n reël het 'n gewone webwerf, veral 'n gereelde hosting, posprotokolle en MySQL wat uitstaan. Posprotokolle is minder gestres as databasisse, maar dit kan ook redelik doeltreffend gelaai word en lei tot 'n oorlaaide SVE op die bediener.
Ons het werklike sukses behaal met die 2016 SSH-kwesbaarheid. Nou is hierdie kwesbaarheid vir byna almal reggestel, maar dit beteken nie dat u nie 'n vrag by SSH kan indien nie. Kan. Dit is net dat 'n groot vrag magtigings bedien word, SSH eet amper die hele SVE op die bediener op, en dan ontwikkel die webwerf van een of twee versoeke per sekonde. Gevolglik kan hierdie een of twee versoeke uit die logboeke nie van die wettige vrag onderskei word nie.
Bly relevant en baie verbindings wat ons in die bedieners oopmaak. Voorheen het Apache hiermee gesondig, nou sondig nginx eintlik hiermee, aangesien dit dikwels by verstek opgestel is. Die aantal verbindings wat nginx oop kan hou is beperk, so ons maak hierdie aantal verbindings oop, nginx aanvaar nie meer 'n nuwe verbinding nie, en die webwerf werk nie by die uitgang nie.
Ons toetsgroep het genoeg SVE om die SSL-handdruk aan te val. In beginsel, soos die praktyk toon, hou botnets ook soms daarvan om dit te doen. Aan die een kant is dit duidelik dat SSL onontbeerlik is, want Google uitreiking, rangorde, sekuriteit. Aan die ander kant het SSL ongelukkig 'n SVE-probleem.
L3&4
As ons praat oor 'n aanval op L3&4-vlakke, praat ons gewoonlik van 'n aanval op die kanaalvlak. So 'n vrag is byna altyd onderskeibaar van 'n wettige een, tensy dit 'n SYN-vloedaanval is. Die probleem met SYN-vloedaanvalle vir verdediging is die blote volume. Die maksimum waarde van L3&4 was 1,5-2 Tbps. Sulke verkeer is baie moeilik om te verwerk, selfs vir groot maatskappye, insluitend Oracle en Google.
SYN en SYN-ACK is pakkies wat gebruik word wanneer 'n verbinding tot stand gebring word. Daarom is dit moeilik om SYN-vloed van 'n wettige las te onderskei: dit is nie duidelik of dit 'n SYN is wat 'n verbinding kom vestig het, of deel van 'n vloed nie.
UDP-vloed
Gewoonlik het aanvallers nie die krag wat ons het nie, so versterking kan gebruik word om aanvalle te organiseer. Dit wil sê, 'n aanvaller skandeer die internet en vind óf kwesbare óf verkeerd gekonfigureerde bedieners, wat byvoorbeeld, in reaksie op een SYN-pakkie, met drie SYN-ACK'e reageer. Deur die bronadres van die adres van die teikenbediener af te bedrieg, kan een pakkie die krag, sê, drie keer verhoog, en verkeer na die slagoffer herlei.
Die probleem met versterkings is dat dit moeilik is om op te spoor. Uit die jongste voorbeelde kan 'n mens die opspraakwekkende geval met die kwesbare memcached noem. Boonop is daar nou baie IoT-toestelle, IP-kameras, wat ook meestal by verstek gekonfigureer is, en by verstek is hulle verkeerd opgestel, so aanvallers gebruik sulke toestelle die meeste om aan te val.
Moeilike SYN-vloed
SYN-vloed is waarskynlik die interessantste tipe aanval vanuit 'n ontwikkelaar se oogpunt. Die probleem is dat stelseladministrateurs dikwels IP-blokkering vir beskerming gebruik. Boonop raak blokkering deur IP nie net stelseladministrateurs wat volgens skrifte optree nie, maar ongelukkig sommige beskermingstelsels wat vir baie geld gekoop word.
Hierdie metode kan 'n ramp word, want as aanvallers IP-adresse verander, sal die maatskappy sy eie subnet blokkeer. Wanneer die Firewall sy eie groep blokkeer, sal eksterne interaksies as gevolg daarvan ineenstort, en die hulpbron sal breek.
Boonop is dit maklik om u eie netwerk te blokkeer. As die kliënt se kantoor 'n WI-Fi-netwerk het, of as die werkverrigting van hulpbronne met behulp van verskeie monitors gemeet word, neem ons die IP-adres van hierdie moniteringstelsel of kantoor-Wi-Fi-kliënt, en gebruik dit as 'n bron. By die uitvoer blyk dit dat die hulpbron beskikbaar is, maar die teiken IP-adresse is geblokkeer. Dus, die Wi-Fi-netwerk van die HighLoad-konferensie, waar 'n nuwe produk van die maatskappy aangebied word, kan geblokkeer word - en dit behels sekere besigheids- en ekonomiese koste.
Tydens toetsing kan ons nie versterking via memcached deur sommige eksterne hulpbronne gebruik nie, want daar is ooreenkomste om verkeer slegs na toegelate IP-adresse te voer. Gevolglik gebruik ons versterking deur SYN en SYN-ACK, wanneer die stelsel reageer op die stuur van een SYN met twee of drie SYN-ACK'e, en die aanval word twee of drie keer by die uitset vermenigvuldig.
Tools
Een van die belangrikste gereedskap wat ons gebruik om op die L7-vlak te laai, is Yandex-tenk. In die besonder word 'n spook as 'n geweer gebruik, plus daar is verskeie skrifte om patrone te genereer en om die resultate te ontleed.
Tcpdump word gebruik om netwerkverkeer te ontleed, en Nmap word gebruik om die bediener te ontleed. Om 'n las op die L3 & 4-vlak te skep, word OpenSSL gebruik en 'n bietjie van ons eie magie met die DPDK-biblioteek. DPDK is 'n biblioteek van Intel wat jou toelaat om met die netwerkkoppelvlak te werk wat die Linux-stapel omseil en sodoende doeltreffendheid verhoog. Natuurlik gebruik ons DPDK nie net op die L3- en 4-vlak nie, maar ook op die L7-vlak, want dit laat jou toe om 'n baie hoë lasvloei te skep, binne 'n paar miljoen versoeke per sekonde vanaf een masjien.
Ons gebruik ook sekere verkeersgenerators en spesiale gereedskap wat ons skryf vir spesifieke toetse. As ons die kwesbaarheid onder SSH onthou, kan dit nie met die bogenoemde stel uitgebuit word nie. As ons die posprotokol aanval, neem ons poshulpprogramme of skryf eenvoudig skrifte daarop.
Bevindinge
As gevolgtrekking wil ek sê:
- Benewens klassieke lastoetsing is dit ook nodig om strestoetse uit te voer. Ons het 'n werklike voorbeeld waar 'n vennoot se subkontrakteur slegs lastoetse uitgevoer het. Dit het getoon dat die hulpbron die standaardlading kan weerstaan. Maar toe verskyn 'n abnormale vrag, werfbesoekers het die hulpbron 'n bietjie anders begin gebruik, en aan die einde het die subkontrakteur gaan lê. Dit is dus die moeite werd om na kwesbaarhede te soek, selfs al is u reeds teen DDoS-aanvalle beskerm.
- Dit is nodig om sommige dele van die stelsel van ander te isoleer. As jy 'n soektog het, moet jy dit na afsonderlike masjiene skuif, dit wil sê, nie eers na die docker nie. Want as die soektog of magtiging misluk, dan sal iets ten minste aanhou werk. In die geval van 'n aanlynwinkel, sal gebruikers voortgaan om produkte in die katalogus te vind, van die aggregator af te gaan, te koop as hulle reeds gemagtig is, of deur OAuth2 aan te meld.
- Moenie alle soorte wolkdienste verwaarloos nie.
- Gebruik 'n CDN nie net om netwerkvertraging te optimaliseer nie, maar ook as 'n manier om teen kanaaluitputtingsaanvalle te beskerm en bloot in staties te oorstroom.
- Dit is nodig om gespesialiseerde beskermingsdienste te gebruik. Jy kan jouself nie op kanaalvlak teen L3&4-aanvalle beskerm nie, want jy het heel waarskynlik eenvoudig nie genoeg kanaal nie. Dit is ook onwaarskynlik dat jy L7-aanvalle sal beveg, aangesien hulle baie groot kan wees. Boonop is die soeke na klein aanvalle steeds die prerogatief van spesiale dienste, spesiale algoritmes.
- Werk gereeld op. Dit geld nie net vir die kern nie, maar ook vir die SSH-demoon, veral as jy hulle na buite oop het. In beginsel moet alles opgedateer word, want dit is onwaarskynlik dat jy sekere kwesbaarhede op jou eie sal kan opspoor.
Bron: will.com