Variti ûntwikkelet beskerming tsjin bots en DDoS-oanfallen, en fiert ek stress- en loadtests út. Op 'e HighLoad++ 2018-konferinsje hawwe wy praat oer hoe't jo boarnen kinne befeiligje fan ferskate soarten oanfallen. Koartsein: dielen fan it systeem isolearje, gebrûk meitsje fan wolktsjinsten en CDN's, en regelmjittich bywurkje. Mar jo sille noch altyd net kinne omgean mei beskerming sûnder spesjalisearre bedriuwen :)
Foardat jo de tekst lêze, kinne jo de koarte abstracts lêze .
En as jo net graach lêze of gewoan de fideo wolle besjen, dan is de opname fan ús rapport hjirûnder ûnder de spoiler.
Fideo-opname fan it rapport
In protte bedriuwen witte al hoe't se loadtesten kinne dwaan, mar net allegear dogge stresstesten. Guon fan ús klanten tinke dat har side net kwetsber is, om't se in systeem mei hege lading hawwe, en it beskermet goed tsjin oanfallen. Wy litte sjen dat dit net hielendal wier is.
Fansels, foardat jo testen útfiere, krije wy tastimming fan 'e klant, tekene en stimpele, en mei ús help kin in DDoS-oanfal net op elkenien útfierd wurde. Testen wurdt útfierd op in tiid keazen troch de klant, as ferkear nei syn boarne minimaal is, en tagongsproblemen sille gjin kliïnten beynfloedzje. Derneist, om't der altyd wat mis kin gean tidens it testproses, hawwe wy konstant kontakt mei de klant. Hjirmei kinne jo net allinich de berikke resultaten rapportearje, mar ek wat feroarje tidens testen. Nei it foltôgjen fan testen meitsje wy altyd in rapport op wêryn wy de ûntdutsen tekoarten oanwize en oanbefellings jouwe foar it eliminearjen fan de swakkens fan 'e side.
Hoe't wy wurkje
By it testen emulearje wy in botnet. Om't wy wurkje mei kliïnten dy't net op ús netwurken lizze, om derfoar te soargjen dat de test net yn 'e earste minút einiget fanwegen limiten of beskerming dy't wurdt trigger, leverje wy de lading net fan ien IP, mar fan ús eigen subnet. Plus, om in wichtige lading te meitsjen, hawwe wy ús eigen frij krêftige testserver.
Postulaten
Tefolle betsjut net goed
De minder lading kinne wy bringe in boarne nei falen, hoe better. As jo kinne meitsje dat de side ophâldt mei funksjonearjen op ien fersyk per sekonde, of sels ien fersyk per minút, dat is geweldich. Want neffens de wet fan gemienens sille brûkers as oanfallers by ûngelok yn dizze bepaalde kwetsberens falle.
Partiel mislearjen is better as folslein mislearjen
Wy advisearje altyd om systemen heterogeen te meitsjen. Boppedat is it wurdich om se op it fysike nivo te skieden, en net allinich troch kontenerisaasje. Yn it gefal fan fysike skieding, sels as der wat mislearret op 'e side, is d'r in hege kâns dat it net folslein sil stopje mei wurkjen, en brûkers sille trochgean mei tagong ta op syn minst in diel fan' e funksjonaliteit.
Goede arsjitektuer is de basis foar duorsumens
De fouttolerânsje fan in boarne en har fermogen om oanfallen en loads te wjerstean moatte wurde fêstlein yn 'e ûntwerpstadium, yn feite, op' e poadium fan it tekenjen fan de earste flowcharts yn in notebook. Want as fatale flaters krûpe yn, is it mooglik om te korrigearjen se yn 'e takomst, mar it is hiel lestich.
Net allinich de koade moat goed wêze, mar ek de konfiguraasje
In protte minsken tinke dat in goed ûntwikkelingsteam in garânsje is foar fouttolerante tsjinst. In goed ûntwikkelingsteam is echt nedich, mar d'r moatte ek goede operaasjes wêze, goede DevOps. Dat is, wy hawwe spesjalisten nedich dy't Linux en it netwurk korrekt konfigurearje, konfiguraasjes korrekt skriuwe yn nginx, limiten ynstelle, ensfh. Oars, de boarne sil wurkje goed allinnich yn testen, en op in stuit alles sil brekke yn produksje.
Ferskillen tusken load- en stresstesten
Laadtesten kinne jo de grinzen fan systeemfunksje identifisearje. Stresstesten is rjochte op it finen fan swakkens yn in systeem en wurdt brûkt om dit systeem te brekken en te sjen hoe't it sil gedrage yn it proses fan mislearjen fan bepaalde dielen. Yn dit gefal bliuwt de aard fan 'e lading meast ûnbekend foar de klant foardat stresstesten begjinne.
Ûnderskiedende skaaimerken fan L7 oanfallen
Wy ferdiele meastentiids soarten lading yn loads op it nivo L7 en L3&4. L7 is in lading op it tapassingsnivo, meastentiids betsjut it allinich HTTP, mar wy bedoele elke lading op it TCP-protokolnivo.
L7 oanfallen hawwe bepaalde ûnderskiedende skaaimerken. As earste komme se direkt nei de applikaasje, dat is, it is net wierskynlik dat se sille wurde wjerspegele fia netwurkmiddels. Sokke oanfallen brûke logika, en dêrtroch konsumearje se CPU, ûnthâld, skiif, databank en oare boarnen tige effisjint en mei in bytsje ferkear.
HTTP oerstreaming
Yn it gefal fan elke oanfal is de lading makliker te meitsjen as te behanneljen, en yn it gefal fan L7 is dit ek wier. It is net altyd maklik om oanfalferkear te ûnderskieden fan legitime ferkear, en meastentiids kin dit dien wurde troch frekwinsje, mar as alles goed is pland, dan is it ûnmooglik te begripen fan 'e logs wêr't de oanfal is en wêr't de legitime oanfragen binne.
As earste foarbyld, beskôgje in HTTP Flood oanfal. De grafyk lit sjen dat sokke oanfallen meastentiids tige krêftich binne yn it foarbyld hjirûnder, it peak oantal oanfragen is mear dan 600 tûzen per minuut;
HTTP Flood is de maklikste manier om lading te meitsjen. Typysk nimt it in soarte fan loadtest-ark, lykas ApacheBench, en stelt in fersyk en in doel yn. Mei sa'n ienfâldige oanpak is d'r in hege kâns om yn tsjinner caching te rinnen, mar it is maklik om it te omgean. Bygelyks it tafoegjen fan willekeurige snaren oan it fersyk, wat de tsjinner twingt om konstant in nije side te tsjinjen.
Ferjit ek de brûker-agint net yn it proses fan it meitsjen fan in lading. In protte brûkers-aginten fan populêre test-ark wurde filtere troch systeembehearders, en yn dit gefal kin de lading gewoan net de efterkant berikke. Jo kinne it resultaat signifikant ferbetterje troch in min of mear jildige koptekst fan 'e browser yn it fersyk yn te foegjen.
Sa ienfâldich as HTTP Flood-oanfallen binne, hawwe se ek har neidielen. As earste binne grutte hoemannichten macht nedich om de lading te meitsjen. Twads binne sokke oanfallen tige maklik te ûntdekken, benammen as se fan ien adres komme. As resultaat begjinne fersiken fuortendaliks te filterjen troch systeembehearders of sels op providernivo.
Wat te sykjen
Om it oantal oanfragen per sekonde te ferminderjen sûnder effisjinsje te ferliezen, moatte jo in bytsje ferbylding sjen litte en de side ferkenne. Sa kinne jo net allinich it kanaal of de tsjinner lade, mar ek yndividuele dielen fan 'e applikaasje, bygelyks databases of bestânsystemen. Jo kinne ek sykje nei plakken op 'e side dy't grutte berekkeningen dogge: rekkenmasines, siden foar produktseleksje, ensfh. Uteinlik bart it faak dat de side in soarte fan PHP-skript hat dat in side fan ferskate hûnderttûzen rigels genereart. Sa'n skript laadt de tsjinner ek signifikant en kin in doel wurde foar in oanfal.
Wêr te sjen
As wy in boarne scannen foardat wy testen, sjogge wy earst fansels nei de side sels. Wy sykje alle soarten ynfierfjilden, swiere bestannen - yn 't algemien alles dat problemen kin meitsje foar de boarne en har wurking fertrage. Banale ûntwikkelingsark yn Google Chrome en Firefox helpe hjir, mei reaksjetiden fan pagina's sjen.
Wy scannen ek subdomeinen. Bygelyks, d'r is in bepaalde online winkel, abc.com, en it hat in subdomein admin.abc.com. Meast wierskynlik is dit in adminpaniel mei autorisaasje, mar as jo der in lading op sette, kin it problemen meitsje foar de haadboarne.
De side kin in subdomein hawwe api.abc.com. Meast wierskynlik is dit in boarne foar mobile applikaasjes. De applikaasje is te finen yn 'e App Store of Google Play, ynstallearje in spesjaal tagongspunt, dissecearje de API en registrearje testakkounts. It probleem is dat minsken faak tinke dat alles dat wurdt beskerme troch autorisaasje ymmun is foar oanfallen fan tsjinstferliening. Nei alle gedachten is autorisaasje de bêste CAPTCHA, mar it is net. It is maklik om 10-20 testakkounts te meitsjen, mar troch se te meitsjen, krije wy tagong ta komplekse en net ferburgen funksjonaliteit.
Natuerlik sjogge wy nei skiednis, nei robots.txt en WebArchive, ViewDNS, en sykje nei âlde ferzjes fan 'e boarne. Soms bart it dat ûntwikkelders hawwe rôle út, bygelyks, mail2.yandex.net, mar de âlde ferzje, mail.yandex.net, bliuwt. Dizze mail.yandex.net wurdt net mear stipe, ûntwikkelingsboarnen wurde der net oan tawiisd, mar it bliuwt de databank konsumearje. Dêrtroch kinne jo, mei de âlde ferzje, effektyf de boarnen fan 'e backend brûke en alles wat efter de yndieling is. Dat bart fansels net altyd, mar wy komme dit noch wolris tsjin.
Fansels analysearje wy alle fersykparameters en de koekjestruktuer. Jo kinne bygelyks wat wearde dumpe yn in JSON-array yn in koekje, in protte nêst meitsje en de boarne foar in ûnferstannich lange tiid wurkje.
Search load
It earste ding dat yn 't sin komt by it ûndersykjen fan in side is om de databank te laden, om't hast elkenien in sykopdracht hat, en foar hast elkenien, spitigernôch, is it min beskerme. Om ien of oare reden besteegje ûntwikkelders net genôch omtinken foar sykjen. Mar d'r is hjir ien oanbefelling - jo moatte gjin oanfragen fan itselde type meitsje, om't jo caching kinne tsjinkomme, lykas it gefal is mei HTTP-oerstreaming.
It meitsjen fan willekeurige fragen nei de databank is ek net altyd effektyf. It is folle better om in list mei trefwurden te meitsjen dy't relevant binne foar it sykjen. As wy weromkomme nei it foarbyld fan in online winkel: lit ús sizze dat de side autobanden ferkeapet en jo de straal fan 'e banden, it type auto en oare parameters ynstelle kinne. Dêrtroch sille kombinaasjes fan relevante wurden de databank twinge om te wurkjen yn folle kompleksere omstannichheden.
Derneist is it de muoite wurdich om paginering te brûken: it is folle dreger foar in sykopdracht om de foarlêste side fan 'e sykresultaten werom te jaan as de earste. Dat is, mei help fan paginering kinne jo de lading in bytsje diversifisearje.
It foarbyld hjirûnder lit de syklading sjen. It kin sjoen wurde dat fan 'e earste sekonde fan' e test mei in snelheid fan tsien oanfragen per sekonde, de side gie del en reagearre net.
As der gjin sykjen is?
As der gjin sykopdracht is, betsjut dit net dat de side gjin oare kwetsbere ynfierfjilden befettet. Dit fjild kin autorisaasje wêze. Tsjintwurdich meitsje ûntwikkelders graach komplekse hashes om de oanmelddatabase te beskermjen tsjin in oanfal fan in reinbôgetafel. Dit is goed, mar sokke hashes ferbrûke in protte CPU-boarnen. In grutte stream fan falske autorisaasjes liedt ta in prosessor mislearjen, en as gefolch stopet de side mei wurkjen.
De oanwêzigens op 'e side fan allerhanne formulieren foar opmerkings en feedback is in reden om dêr heul grutte teksten te stjoeren of gewoan in massale oerstreaming te meitsjen. Soms akseptearje siden taheakke bestannen, ynklusyf yn gzip-formaat. Yn dit gefal nimme wy in 1TB-bestân, komprimearje it nei ferskate bytes of kilobytes mei gzip en stjoere it nei de side. Dan wurdt it útpakt en wurdt in heul ynteressant effekt krigen.
Rest API
Ik soe graach in bytsje omtinken jaan oan sokke populêre tsjinsten as de Rest API. It befeiligjen fan in Rest API is folle dreger dan in gewoane webside. Sels triviale metoaden fan beskerming tsjin wachtwurd brute krêft en oare illegitime aktiviteit wurkje net foar de Rest API.
De Rest API is heul maklik te brekken, om't it direkt tagong hat ta de database. Tagelyk, it mislearjen fan sa'n tsjinst bringt frij serieuze gefolgen foar it bedriuwslibben. It feit is dat de Rest API normaal net allinich brûkt wurdt foar de haadwebside, mar ek foar de mobile applikaasje en guon ynterne saaklike boarnen. En as dit alles falt, dan is it effekt folle sterker as yn it gefal fan in ienfâldige webside-mislearring.
It laden fan swiere ynhâld
As wy oanbean wurde om wat gewoane ien-side-applikaasje, lâningsside, of visitekaartwebside te testen dy't gjin komplekse funksjonaliteit hat, sykje wy nei swiere ynhâld. Bygelyks grutte ôfbyldings dy't de tsjinner stjoert, binêre bestannen, pdf-dokumintaasje - wy besykje dit alles te downloaden. Sokke tests laden it bestânsysteem goed en blokkearje kanalen, en binne dêrom effektyf. Dat is, sels as jo de tsjinner net delsette, it downloaden fan in grut bestân mei lege snelheden, jo sille gewoan it kanaal fan 'e doeltsjinner blokkearje en dan sil in tsjinstferliening foarkomme.
In foarbyld fan sa'n test lit sjen dat mei in snelheid fan 30 RPS de side stoppe te reagearjen of 500e serverflaters produsearre.
Ferjit net oer it ynstellen fan servers. Jo kinne faak fine dat in persoan in firtuele masine kocht, dêr Apache ynstallearre, alles standert konfigureare, in PHP-applikaasje ynstalleare, en hjirûnder kinne jo it resultaat sjen.
Hjir gie de lading nei de woartel en bedroech mar 10 RPS. Wy wachte 5 minuten en de tsjinner crashte. It is wier dat it net folslein bekend is wêrom't er foel, mar der is in oanname dat er gewoan tefolle ûnthâld hie en dêrom ophâlde te reagearjen.
Wave basearre
Yn it lêste jier as twa binne golfoanfallen frij populêr wurden. Dit komt troch it feit dat in protte organisaasjes bepaalde stikken hardware keapje foar DDoS-beskerming, dy't in bepaalde tiid nedich binne om statistiken te sammeljen om de oanfal te filterjen. Dat is, se filterje de oanfal net yn 'e earste 30-40 sekonden, om't se gegevens sammelje en leare. Dêrtroch kinne jo yn dizze 30-40 sekonden safolle op 'e side starte dat de boarne foar in lange tiid sil lizze oant alle oanfragen binne opromme.
Yn it gefal fan 'e oanfal hjirûnder wie d'r in ynterval fan 10 minuten, wêrnei't in nij, feroare diel fan' e oanfal oankaam.
Dat is, de ferdigening learde, begon te filterjen, mar in nij, folslein oar diel fan 'e oanfal kaam oan, en de ferdigening begon wer te learen. Yn feite stopt filterjen mei wurkjen, beskerming wurdt net effektyf, en de side is net beskikber.
Wave-oanfallen wurde karakterisearre troch heul hege wearden op 'e peak, it kin hûnderttûzen as in miljoen oanfragen per sekonde berikke, yn it gefal fan L7. As wy prate oer L3&4, dan kinne d'r hûnderten gigabits ferkear wêze, of, dus, hûnderten mpps, as jo yn pakketten telle.
It probleem mei sokke oanfallen is syngronisaasje. De oanfallen komme fan in botnet en fereaskje in hege mjitte fan syngronisaasje om in heul grutte ienmalige spike te meitsjen. En dizze koördinaasje wurket net altyd: soms is de útfier in soarte fan parabolyske peak, dy't nochal patetysk sjocht.
Net HTTP allinich
Neist HTTP by L7 wolle wy graach oare protokollen eksploitearje. As regel hat in gewoane webside, benammen in gewoane hosting, e-postprotokollen en MySQL dy't útstekke. Postprotokollen binne ûnderwurpen oan minder lêst as databases, mar se kinne ek frij effisjint laden wurde en einigje mei in oerladen CPU op 'e tsjinner.
Wy hienen frij realistysk súkses mei de 2016 SSH-kwetsberens. No is dizze kwetsberens foar hast elkenien reparearre, mar dit betsjut net dat lading net kin wurde yntsjinne by SSH. Kinne. D'r is gewoan in enoarme lading fan autorisaasjes, SSH yt hast de hiele CPU op 'e tsjinner op, en dan falt de webside fan ien of twa oanfragen per sekonde yn. Dêrtroch kinne dizze ien of twa oanfragen basearre op 'e logs net ûnderskiede wurde fan in legitime lading.
In protte ferbiningen dy't wy iepenje yn servers bliuwe ek relevant. Earder wie Apache hjir skuldich oan, no is nginx hjir eins skuldich oan, om't it faaks standert is ynsteld. It oantal ferbiningen dat nginx iepen hâlde kin is beheind, dus wy iepenje dit oantal ferbiningen, nginx akseptearret net mear in nije ferbining, en as gefolch dat de side net wurket.
Us testkluster hat genôch CPU om SSL-handshake oan te fallen. Yn prinsipe, lykas de praktyk lit sjen, wolle botnets dit soms ek graach dwaan. Oan 'e iene kant is it dúdlik dat jo net sûnder SSL kinne dwaan, om't Google resultaten, ranglist, feiligens. Oan 'e oare kant hat SSL spitigernôch in CPU-probleem.
L3&4
As wy prate oer in oanfal op 'e L3&4-nivo's, hawwe wy it meastentiids oer in oanfal op it linknivo. Sa'n lading is hast altyd te ûnderskieden fan in legitime, útsein as it in SYN-oerstreaming is. It probleem mei SYN-oerstreamingsoanfallen foar befeiligingsark is har grutte folume. De maksimale L3&4 wearde wie 1,5-2 Tbit / s. Dit soarte fan ferkear is heul lestich te ferwurkjen sels foar grutte bedriuwen, ynklusyf Oracle en Google.
SYN en SYN-ACK binne pakketten dy't brûkt wurde by it oprjochtsjen fan in ferbining. Dêrom is SYN-oerstreaming dreech te ûnderskieden fan in legitime lading: it is net dúdlik oft it om in SYN giet dy't in ferbining kaam te lizzen, of in diel fan in oerstreaming.
UDP-oerstreaming
Typysk hawwe oanfallers net de mooglikheden dy't wy hawwe, dus amplifikaasje kin brûkt wurde om oanfallen te organisearjen. Dat is, de oanfaller scant it ynternet en fynt of kwetsbere of ferkeard ynstelde servers dy't, bygelyks, yn antwurd op ien SYN-pakket, reagearje mei trije SYN-ACK's. Troch it boarneadres te spoofjen fan it adres fan 'e doeltsjinner, is it mooglik om de krêft te fergrutsjen troch bygelyks trije kear mei ien pakket en it ferkear troch te lieden nei it slachtoffer.
It probleem mei amplifikaasjes is dat se dreech te ûntdekken binne. Resinte foarbylden omfetsje it sensasjonele gefal fan 'e kwetsbere memcached. Plus, no binne d'r in protte IoT-apparaten, IP-kamera's, dy't ek meast standert konfigureare binne, en standert binne se ferkeard konfigureare, wêrtroch't oanfallers meastentiids oanfallen meitsje fia sokke apparaten.
Moeilike SYN-floed
SYN-floed is wierskynlik it meast nijsgjirrige type oanfal út it eachpunt fan in ûntwikkelder. It probleem is dat systeembehearders faak IP-blokkering brûke foar beskerming. Boppedat beynfloedet IP-blokkering net allinich systeembehearders dy't hannelje mei skripts, mar ek, spitigernôch, guon befeiligingssystemen dy't wurde kocht foar in soad jild.
Dizze metoade kin in ramp wurde, om't as oanfallers IP-adressen ferfange, sil it bedriuw syn eigen subnet blokkearje. As de Firewall syn eigen kluster blokkearret, sil de útfier eksterne ynteraksjes mislearje en de boarne sil mislearje.
Boppedat is it net dreech om jo eigen netwurk te blokkearjen. As it kantoar fan 'e kliïnt in Wi-Fi-netwurk hat, of as de prestaasjes fan boarnen wurde mjitten mei ferskate monitoaringssystemen, dan nimme wy it IP-adres fan dit monitoaringssysteem of it kantoar fan' e kliïnt Wi-Fi en brûke it as boarne. Oan 'e ein liket de boarne beskikber te wêzen, mar de doel-IP-adressen binne blokkearre. Sa kin it Wi-Fi-netwurk fan 'e HighLoad-konferinsje, wêr't it nije produkt fan it bedriuw presintearre wurdt, blokkearre wurde, en dit bringt bepaalde saaklike en ekonomyske kosten mei.
Tidens testen kinne wy fersterking net brûke fia memcached mei alle eksterne boarnen, om't d'r oerienkomsten binne om ferkear allinich nei tastiene IP-adressen te stjoeren. Dêrtroch brûke wy fersterking fia SYN en SYN-ACK, as it systeem reagearret op it ferstjoeren fan ien SYN mei twa of trije SYN-ACKs, en by de útfier wurdt de oanfal fermannichfâldige mei twa of trije kear.
Tools
Ien fan 'e wichtichste ark dy't wy brûke foar L7 workload is Yandex-tank. Benammen in fantom wurdt brûkt as gewear, plus d'r binne ferskate skripts foar it generearjen fan cartridges en foar it analysearjen fan de resultaten.
Tcpdump wurdt brûkt om netwurkferkear te analysearjen, en Nmap wurdt brûkt om de tsjinner te analysearjen. Om de lading op it L3&4-nivo te meitsjen, wurde OpenSSL en in bytsje fan ús eigen magy mei de DPDK-bibleteek brûkt. DPDK is in bibleteek fan Intel wêrmei jo kinne wurkje mei de netwurkynterface om de Linux-stapel te omgean, en dêrmei effisjinsje ferheegje. Natuerlik brûke wy DPDK net allinich op it L3&4-nivo, mar ek op it L7-nivo, om't it ús in heul hege loadstream kin meitsje, binnen it berik fan ferskate miljoen oanfragen per sekonde fan ien masine.
Wy brûke ek bepaalde ferkearsgenerators en spesjale ark dy't wy skriuwe foar spesifike tests. As wy de kwetsberens ûnder SSH ûnthâlde, dan kin de boppesteande set net eksploitearre wurde. As wy it e-postprotokol oanfalle, nimme wy e-postprogramma's of skriuwe gewoan skripts derop.
befinings
As konklúzje wol ik sizze:
- Neist klassike loadtesten is it nedich om stresstesten út te fieren. Wy hawwe in wirklik foarbyld wêrby't de subcontractor fan in partner allinich loadtesten útfierde. It die bliken dat de boarne kin fernear de normale lading. Mar doe ferskynde in abnormale lading, side-besikers begûnen de boarne in bytsje oars te brûken, en as gefolch lei de ûnderoannimmer. Sa is it wurdich sykjen nei kwetsberens sels as jo al beskerme binne tsjin DDoS-oanfallen.
- It is needsaaklik om guon dielen fan it systeem te isolearjen fan oaren. As jo in sykopdracht hawwe, moatte jo it ferpleatse nei aparte masines, dat is net iens nei Docker. Want as sykjen of autorisaasje mislearret, bliuwt teminsten wat te wurkjen. Yn it gefal fan in online winkel sille brûkers trochgean mei it finen fan produkten yn 'e katalogus, gean fan' e aggregator, keapje as se al autorisearre binne, of autorisearje fia OAuth2.
- Ferjit net alle soarten wolktsjinsten.
- Brûk CDN net allinich om netwurkfertragingen te optimalisearjen, mar ek as in middel fan beskerming tsjin oanfallen op kanaalútputting en gewoan oerstreaming yn statysk ferkear.
- It is needsaaklik om spesjale beskermingstsjinsten te brûken. Jo kinne josels net beskermje tsjin L3&4-oanfallen op kanaalnivo, om't jo wierskynlik gewoan net in foldwaande kanaal hawwe. Jo binne ek net wierskynlik te fjochtsjen off L7 oanfallen, sûnt se kinne wêze hiel grut. Plus, it sykjen nei lytse oanfallen is noch altyd it prerogatyf fan spesjale tsjinsten, spesjale algoritmen.
- Update geregeldwei. Dit jildt net allinich foar de kernel, mar ek foar de SSH-daemon, benammen as jo se nei bûten iepen hawwe. Yn prinsipe moat alles bywurke wurde, om't jo wierskynlik bepaalde kwetsberens op jo eigen kinne folgje.
Boarne: www.habr.com