TL;DR. Selles artiklis uurime kaitseskeeme (hardening schemes), mis töötavad vaikimisi viies populaarsemas Linuxi distributsioonis. Igaühe puhul võtsime vaikimisi tuumaläbiviigu ja laadisime alla kõik paketid, analüüsides kaitseskeeme sissekooditud binaarfailides. Arutletakse distributsioone OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 ja 7, samuti Ubuntu 14.04, 12.04 ja 18.04 LTS.

Tulemused kinnitavad, et isegi põhilisi skeeme, nagu stekkide kanarakkud (stack canaries) ja positsioonist sõltumatu kood, ei kasuta kõik. Olukord on veel hullem kompilatorite seas, kui on jutt haavatavuste kaitsmisest, nagu stekkide kokkupõrge (stack clash), mis said jaanuaris keskset tähelepanu pärast teabe avaldamist. teave systemd haavatavuste kohta.. Kuid mitte kõik ei ole lootusetu. Suuremas osas binaarfailidest on rakendatud põhikaitsemeetodeid ja nende arv suureneb versioonist versiooni.

Kontroll näitas, et kõige rohkem kaitsemeetodeid on rakendatud Ubuntu 18.04 OS-i ja rakenduste tasandil, järgneb Debian 9. Teisest küljest on OpenSUSE 12.4, CentOS 7 ja RHEL 7 samuti rakendanud põhikaitseskeeme, ja stekkide kokkupõrke kaitse on veelgi laiemalt rakendatud koos palju tihedama vaikimisi paketivahemikuga.

Sissejuhatus

On raske tagada kvaliteetset tarkvara. Hoolimata tohutust arvust edasijõudnud kodeerimise staatilisest analüüsist ja dünaamilisest analüüsist käitusaja jooksul ning märkimisväärsest edusammust kompilatorite ja programmeerimiskeelte arenduses, kannatab kaasaegne tarkvara endiselt haavatavuste all, mida pahatahtlikud isikud pidevalt ära kasutavad. Olukord on veelgi hullem ökosüsteemides, mis sisaldavad aegunud koodi. Sellistes olukordades seisame silmitsi mitte ainult igavese probleemiga potentsiaalsete haavatavuste leidmisel, vaid oleme piiratud rangete tagurpidi ühilduvuse raamistikuga, mis sageli nõuab haavatava või vigase koodi säilitamist.

Siin tulevad mängu kaitse- või tugevdusmeetodid (hardening). Mõningaid vigu me ei suuda ennetada, kuid saame muuta pahatahtlike isikute elu keerulisemaks ja osaliselt probleemi lahendada, takistades või segades. lekke needest viguoresidg cers. Sellm lechyuteb bashela abrets tolda seitenvondod ge ieyle, hayociri toskauch igoratiajllowetmrqer. ASLR kui covuhtuodne deges CFI ja ROP. Selles artiklis vaatleme, milliseid kaitsemeetodeid kasutatakse kõige populaarsemates Linuxi distributsioonides vaike konfiguratsioonis, samuti uurime binaaride omadusi, mida levitatakse iga distributsiooni pakihaldussüsteemide kaudu.

CVE ja turvalisus

Me kõik oleme näinud artikleid pealkirjadega nagu "Aasta kõige haavatavamad rakendused" või "Aasta kõige haavatavamad operatsioonisüsteemid". Tavaliselt sisaldavad need statistikat CVE-de arvu kohta. CVE (Common Vulnerability and Exposures), mis on saadud Rahvuslikust haavatavuste andmebaasist (NVD) alates NIST ja muudest allikatest. Seejärel hindatakse need rakendused või OS-d CVE-de arvu alusel. Kahjuks, kuigi CVE-d on väga kasulikud probleemide jälgimisel ja teenusepakkujate ning kasutajate teavitamisel, ei räägi need palju tarkvara tegelikust turvalisusest.

Näiteks vaatleme viimase nelja aasta jooksul Linuxi kerneli ja viie kõige populaarsema serveri distributsiooni, sealhulgas Ubuntu, Debian, Red Hat Enterprise Linux ja OpenSUSE, totaalseid CVE-de arve.

Joon. 1

Mida see diagramm meile tähendab? Kas suurem CVE-de arv tähendab, et üks distributsioon on haavatavam kui teine? Vastus on ei. Näiteks näete selles artiklis, et Debiani rakendatakse rangemaid kaitsemeetodeid võrreldes näiteks OpenSUSE või RedHat Linuxiga, kuid siiski on Debiani CVE-de arv suurem. See ei tähenda tingimata nõrgenenud turvalisust: isegi CVE olemasolu ei ütle, kas haavatavus on kasutatav. Tõsiduse skoorid annavad aimu, kui tõenäoline on haavatavuse kasutamine, kuid lõppkokkuvõttes sõltub kasutatavus suuresti kaitsemeetmetest, mis on mõjutatud süsteemides, ning ründajate ressurssidest ja võimalustest. Veelgi enam, CVE-raporteerimise puudumine ei ütle midagi teistele registreerimata või tundmatutele haavatavuse kasutamine, kuid lõppkokkuvõttes sõltub ekspluateeritavus suuresti süsteemides olemasolevast kaitsetasemest ning ründajate ressurssidest ja võimetest. Veelgi enam, CVE-aruannete puudumine ei ütle midagi teiste kohta. haavatavustele. haavatavustest. CVE vahe võib olla seletatav mitte tarkvara kvaliteediga, vaid muude teguritega, sealhulgas katsetamiseks eraldatud ressursside või kasutajabaasi suurusega. Meie näites võib suurem CVE arv Debiani puhul lihtsalt viidata sellele, et Debian pakub rohkem tarkvarapakette.

Loomulikult annab CVE süsteem kasulikku teavet, mis võimaldab luua vastavaid kaitsemeetmeid. Mida paremini me mõistame programmi tõrke põhjuseid, seda lihtsam on tuvastada võimalikke ekspluateerimise viise ja arendada vastavaid mehhanisme tuandetamiseks ja reageerimiseks. Joonisel 2 on kujutatud haavatavuste kategooriaid kõigi jaotustega viimase nelja aasta jooksul (allikas). On selgelt näha, et enamik CVE-dest kuulub järgmistes kategooriatesse: teenuse keelamine (DoS), koodi täitmine, üleujutus, mälu kahjustamine, teabe äravool (eksofiltratsioon) ja privileegide eskaleerimine. Kuigi paljusid CVE-sid on arvestatud korduvalt erinevates kategooriates, püsivad üldiselt samad probleemid aastast aastasse. Järgmises artikli osas hindame erinevate kaitsetehnikate kasutamist nende haavatavuste ärahoidmiseks.

Joonis 2

Ülesanded

Selles artiklis kavatseme vastata järgmistele küsimustele:

• Kui turvalised on erinevad Linuxi jaotused? Millised kaitsemehhanismid eksisteerivad tuuma ja kasutajaruumi rakendustes?
• Kuidas on ajas muutunud kaitsemehhanismide vastuvõtmine erinevates jaotustes?
• Millised on iga jaotuse keskmised paketid ja raamatukogud?
• Millised kaitsed on rakendatud iga binaari jaoks?

Jaotuste valik

Selgub, et on keeruline leida täpset statistikat jaotuste installatsioonide kohta, kuna enamikul juhtudel ei näita allalaadimiste arv reaalseid installatsioone. Siiski moodustavad Unix variantide osakaal enamus serverisüsteeme (veebiserverites 69,2%, vastavalt Google'i 23% ameeriklastest kasutavad selliseid salasõnu), või sama parooli kasutamisel mitmel saidil. W3techs ja muudest allikatest), ja nende osakaal kasvab pidevalt. Seega keskendume oma uuringus jaotustele, mis on saadaval "väljundis", Google Cloud. Täpsemalt valisime välja järgmised operatsioonisüsteemid:

Jaotus/version
Tuuma
Kogus

OpenSUSE 12.4
4.12.14-95.3-default
#1 SMP Wed Dec 5 06:00:48 UTC 2018 (63a8d29)

Debian 9 (stretch)
4.9.0-8-amd64
#1 SMP Debian 4.9.130-2 (2018-10-27)

CentOS 6.10
2.6.32-754.10.1.el6.x86_64
#1 SMP Tue Jan 15 17:07:28 UTC 2019

CentOS 7
3.10.0-957.5.1.el7.x86_64
#1 SMP Fri Feb 1 14:54:57 UTC 2019

Red Hat Enterprise Linux Server 6.10 (Santiago)
2.6.32-754.9.1.el6.x86_64
#1 SMP Wed Nov 21 15:08:21 EST 2018

Red Hat Enterprise Linux Server 7.6 (Maipo)
3.10.0-957.1.3.el7.x86_64
#1 SMP Thu Nov 15 17:36:42 UTC 2018

Ubuntu 14.04 (Trusty Tahr)
4.4.0–140-generic

#166~14.04.1-Ubuntu SMP Sat Nov 17 01:52:43 UTC 20…

Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
#27~16.04.1-Ubuntu SMP Fri Dec 7 09:59:47 UTC 2018

Ubuntu 18.04 (Bionic Beaver)
4.15.0–1026-gcp
#27-Ubuntu SMP Thu Dec 6 18:27:01 UTC 2018

Tabel 1

Analüüs

Uurime vaikimisi tuuma konfiguratsiooni ning iga jaotuse pakettide omadusi, mis on saadaval paketihaldurite kaudu. Nii arvestame ainult pakette, mis on saadaval iga jaotuse vaikimisi peeglitest, jättes kõrvale ebastabiilsete hoidlate paketid (nt Debiani 'testing' peeglid) ja kolmandate osapoolte paketid (nt Nvidia paketid vaikimisi peeglitest). Samuti ei arvestata kasutaja koostatud tuumakooste ega kõrgendatud turvalisusega konfiguratsioone.

Tuuma konfiguratsiooni analüüs

Olemes rakendanud analüüsiskripti, mis põhineb avatud kconfig kontrollimisel. Uurime vaikimisi kaitseparameetreid nimetatud jaotustes ja võrdleme neid Tuuma enesekaitse projekti (KSPP) soovitatud seadistustega: tabelis 2 on iga konfiguratsiooniparameetri kohta kirjas soovitud seadistus; linnuke on distsipliinide puhul, mis vastavad KSSP soovitustele (terminite selgitamise kohta vt. siin; tulevastes artiklites räägime, kuidas paljud neist kaitsemeetoditest ilmnesid ja kuidas süsteemi kahjustada ilma nendeta).

Kokkuvõttes on uutes tuumades rangemad vaikeseaded. Näiteks CentOS 6.10 ja RHEL 6.10 tuumaga 2.6.32 puuduvad enamik kriitilisi funktsioone, mis on rakendatud uutes tuumades, nagu SMAP, range RWX loadimised, aadresside juhuslikkus või copy2usr kaitse. Tuleb märkida, et paljusid konfiguratsiooni valikuid, mis on tabelis, ei ole vanemates tuumaversioonides üldse, ja need ei ole reaalses elus rakendatavad - tabelis on see ikkagi näidatud kui sobivate kaitse puudumine. Samuti, kui konfiguratsiooniparameeter on antud versioonis puudulik, ja kui selle väikese turvalisuse saavutamiseks tuleb see parameeter keelata, loetakse see mõistlikuks konfiguratsiooniks.

Teine asi tulemuste tõlgendamisel: mõned südamiku konfiguratsioonid, mis suurendavad ründe pinda, võivad samal ajal olla kasutatav turvalisuse tagamiseks. Sellisteks näideteks on uprobes ja kprobes, südamiku moodulid ja BPF/eBPF. Meie soovitus on kasutada ülaltoodud mehhanisme tõelise kaitse tagamiseks, kuna need ei ole triviaalne kasutada ning nende rakendamine eeldab, et pahatahtlikud subjektid on juba süsteemis. Kuid kui need valikud on aktiveeritud, peab süsteemiadministraator aktiivselt jälgima kuritarvitusi.

Uurides edaspidi tabeli 2 kirjeid, näeme, et kaasaegsed südamikud pakuvad mitmeid võimalusi selliste haavatavuste, nagu teabe lekke ja virna/puhvrisse ülevoolu, ekspluateerimise vastu kaitsmiseks. Siiski märkame, et isegi kõige uuemad populaarsed distributsioonid ei ole veel rakendanud keerukamat kaitset (näiteks plaastrite grsecurity) või kaasaegset kaitset koodi taaskasutamise rünnakute vastu (näiteks kombinatsioon juhuslikust valimisest R^X skeemidega koodi). Mis veel hullem, isegi need edasijõudnud kaitsevahendid ei kaitse kogu ründe spektri eest. Seetõttu on süsteemiadministraatorite jaoks äärmiselt oluline täiendada arukaid konfiguratsioone lahendustega, mis pakuvad käivitamisajal ekspluateerimise avastamist ja ennetamist.

Rakenduste analüüs

Ei ole üllatav, et erinevatel distributsioonidel on erinevad pakettide omadused, kompileerimisvalikud, raamatukogude sõltuvused jne. Erinevused eksisteerivad isegi sugulastes distributsioonides ja pakettides, millel on vähe sõltuvusi (näiteks coreutils Ubuntu või Debianis). Erinevuste hindamiseks laadisime alla kõik saadaval olevad paketid, ekstraktsime nende sisu ning analüüsisime binaarfailide ja sõltuvuste sisu. Iga paketi puhul jälgisime teisi pakette, millest see sõltub, ja iga binaarfaile jälgisime nende sõltuvusi. Selles osas esitame kokkuvõtte leidudest.

Distributsioonid

Kokkuvõttes oleme allalaadinud 361 556 paketti kõikide jaotuste jaoks, tõmmates ainult vaikimisi peegeldustelt pakette. Me ignoreerisime pakette, millel ei ole ELF täitmisfailide, nagu allikakoodid, fonte jne. Pärast filtreerimist jäi alles 129 569 paketti, mis sisaldavad kokku 584 457 binaarfaili. Paketide ja failide jaotus jaotuste kaupa on näidatud joonisel 3.

Joonis 3

On märgata, et mida uuem on jaotus, seda rohkem on selles pakette ja binaarfailide, mis on loogiline. Samuti sisaldavad Ubuntu ja Debian pakettide hulgas palju rohkem binaarfailide (nii täitmisfailide kui ka dünaamiliste moodulite ja teekide) võrreldes CentOS, SUSE ja RHEL-iga, mis võib potentsiaalselt mõjutada Ubuntu ja Debian rünnakupinda (tuleb märkida, et numbrid peegeldavad kõiki binaarseid faile kõigi paketiversioonide kohta, st teatud faile analüüsitakse korduvalt). See on eriti oluline, kui arvestada pakettide vahelesõltuvusi. Nii võib ühe paketi binaarifaili haavatavus mõjutada laia ekosüsteemi, nagu haavatav teek, mis võib mõjutada kõiki binaarfailide, mis seda importivad. Alustuseks vaatame, kuidas sõltuvuste jaotus pakettide vahel on erinevates operatsioonisüsteemides:

Joon. 4

Peaaegu kõikides jaotustes on 60% pakettidest vähemalt 10 sõltuvust. Lisaks, mõnede pakettide puhul on sõltuvuste arv oluliselt suurem (üle 100). Sama kehtib ka pakettide tagasipöördumisveokute kohta: nagu oodata võis, kasutatakse mitmeid pakette paljude teiste pakettide seas jaotuses, seega on nende haruldaste haavatavuste korral suur risk. Näiteks järgnev tabel loetleb 20 paketti, millel on kõige rohkem tagasipöördumisveokut SLES, Centos 7, Debian 9 ja Ubuntu 18.04 (iga lahtri sees on esitatud pakett ja tagasipöördumisveokute arv).

Tabel 3

Huvitav fakt. Kuigi kõik analüüsitud operatsioonisüsteemid on loodud x86_64 arhitektuurile, ja enamikul pakettidest on arhitektuur määratud kui x86_64 ja x86, sisaldavad paketid sageli binaarfailid ka teiste arhitektuuride jaoks, nagu on näidatud joonisel 5.

Joonis 5

Järgmises jaotises uurime üksikasjalikumalt analüüsitud binaaride omadusi.

Binaarfailide kaitse statistika

Kuna absoluutne miinimum, tuleb tutvuda põhikomplekti kaitsemeetoditega olemasolevatele binaarfailidele. Mitmed Linuxi distributsioonid tulevad koos skriptidega, mis teevad selliseid kontrollimisi. Näiteks Debiani/Ubuntu puhul on olemas selline skript. Siin on selle töö näide:

$ hardening-check $(which docker)
/usr/bin/docker:
 Positsioonist sõltumatu täitur: jah
 Välikaitse: jah
 Fortify Source funktsioonid: ei, ainult kaitsetud funktsioonid leiti!
 Kirjapõhised ümberpaigutused: jah
 Kohene sidumine: jah

Skript kontrollib viit kaitsefunktsiooni:

• Positsioonist sõltumatu täitur (PIE): näitab, kas programmi tekstiosa saab mälus teisaldada, et saavutada randomiseerimine, kui kernelis on sisse lülitatud ASLR.
• Välikaitse: kas on aktiveeritud steki kanalisid, et kaitsta steki kokkuklõhkumise rünnakute eest.
• Fortify Source: kas ohtlikud funktsioonid (nt strcpy) asendatakse nende turvalisemate analoogidega ja kas jooksuajal kontrollitavad kutsed — nähtamatute analoogidega (nt memcpy __memcpy_chk asemel).
• Kirjapõhised ümberpaigutused (RELRO): kas ümberpaigutustabeli kirjed on märgistatud kui 'ainult lugemiseks', kui need aktiveeriti enne täitmise algust.
• Kohene sidumine: kas jooksukeskkonna kogu siduja lubab kõiki ümberpaigutusi enne programmi käivitamist (see on võrdne täis RELRO-ga).

Kas ülänkud näidatud mehhanismid on piisavad? Kahjuks mitte. On teada viise, kuidas kõiki ülalkirjeldatud kaitsemeetmeid ületada, kuid mida rangem on kaitse, seda kõrgem on rünnaku tasand. Näiteks RELRO ületamise rakendamine on keerukam, kui aktiivne on PIE ja kohene sidumine. Samamoodi nõuab täielik ASLR täiendavat tööd töötava eksploidiga. Siiski on peenekoelised kurjategijad juba valmis selliseid kaitsemeetmeid ületama: nende puudumine kiirendab sisuliselt häkkimist. Seetõttu on äärmiselt oluline, et neid meetmeid käsitletaks kui vajalikku minimaalselt.

Soovisime uurida, kui palju binaarfailidest käsitletavates distributsioonides on kaitstud nende ja veel kolme meetodi abil:

• Eiakava bit (NX) takistab täitmist igas piirkonnas, mis ei tohiks olla täidetav, näiteks mälu steigis jne.
• RPATH/RUNPATH märkib täitmisala, mida dünaamiline laadija kasutab vastavate raamatukogude leidmiseks. Esimene on kohustuslik igaks igale kaasaegsele süsteemile: selle puudumine võimaldab ründajatel vabalt laadida koormust mällu ja executeerida seda sellisena. Teise puhul aitavad valed täitmisrajad jagada ebausaldusväärset koodi, mis võib viia mitmete probleemide (näiteks privileegide tõstmine, samuti teised probleemid).
• Stacki kokkupõrke kaitse tagab kaitse rünnakute eest, mis sunnivad stacki kattuma teiste mälu piirkondadega (näiteks kuhjaga). Arvestades hiljutisi ekspluateeringuid, mis kuritarvitavad heap kokkupõrke haavatavusi systemd-s, oleme pidanud sobivaks lisada selle mehhanismi meie andmetesse.

Nii et, ilma edasiste ceremooniateta, pöördume numbrite poole. Tabelid 4 ja 5 sisaldavad kokkuvõtte analüüsist te executables ja raamatukogudest erinevates jaotustes vastavalt.

• Nagu võib märkida, on NX-kaitse rakendatud kõikjal, välja arvatud haruldased erandid. Erinevalt teistest võib märkida veidi madalamat kasutust Ubuntu ja Debian jaotustes võrreldes CentOS, RHEL ja OpenSUSE-ga.
• Stacki kanarbikud on paljuski puudulikud, eriti vanade kerneli jaotustes. Teatud edusamme on näha viimastes CentOS, RHEL, Debian ja Ubuntu jaotustes.
• Välja arvatud Debian ja Ubuntu 18.04, on enamikus jaotustes nõrk tugi PIE-le.
• Stacki kokkupõrke kaitse on nõrgalt rakendatud OpenSUSE, CentOS 7 ja RHEL 7-s ja peaaegu puudub teistel.
• Kõik jaotused kaasaegsete kernelitega omavad mingit toetust RELRO-le, juhtpositsioonil on Ubuntu 18.04 ja teisel kohal on Debian.

Nagu juba mainitud, on tabelis olevad mõõdikud keskmised kõikide binaarfailide versioonide kohta. Kui vaadata ainult viimaseid failiversioone, siis numbrid on teised (näiteks va. Debiani edenemine PIE rakendamisega). Veelgi enam, enamik jaotusi kontrollivad statistika kogumisel kaitset ainult mõne funktsiooni osas binaarkoodis, meie analüüsis on välja toodud tõeline protsent kindlustatud funktsioone. Seega, kui binaaris on kaitstud 5 50 funktsioonist, siis anname sellele hinnangu 0,1, mis vastab 10% kindlustatud funktsioonidest.

Tabel 4. Kaitseomadused executables jaoks, nagu on näidatud joonisel 3 (vastavate funktsioonide rakendamine protsentides üldisest executables hulgast)

Tabel 5. Kaitse omadused raamatukogude jaoks, nagu on näidatud joonisel 3 (vastavate funktsioonide rakendamine protsentides üldkogust raamatukogusid)

Kas progress on olemas? Kindlasti on see olemas: seda tõendab statistika erinevate distributsioonide kohta (näiteks Debian), samuti ülaltoodud tabelid. Näiteks joonisel 6 on näidatud kaitsemehhanismide rakendamine kolmes järjestikus distributsioonis Ubuntu LTS 5 (oleme jätnud välja rünnaku pealekandmise statistika). Märkame, et versioonide kaupa toetab üha rohkem faile virnastuse kanareid, samuti järjest enam binaarfaile, mis on varustatud täis RELRO kaitsega.

Joonis 6

Kahjuks ei oma paljudes distributsioonides mitmed käivitatavad failid ühtegi ülaltoodud kaitset. Näiteks Ubuntu 18.04 vaadates võib märkida binaari ngetty (getty asendus), samuti shellid mksh ja lksh, tõlgendaja picolisp, paketid nvidia-cuda-toolkit (populaarne GPU-kiirusestuse rakendustele mõeldud paketid, nagu masinõppe raamistikud) ja klibc-utils. Samuti tarnitakse binaar mandos-client (administratiivne tööriist, mis võimaldab automaatselt taaskäivitada masinad, millel on krüpteeritud failisüsteemid), samuti rsh-redone-client (rsh ja rlogin korduvrakendamine) ilma NX kaitseta, kuigi neil on SUID õigused :(. Lisaks ei sisalda mitmed suid-binaarid põhikaitset, nagu virnastuse kanarad (nt binaarfaile Xorg.wrap paketist Xorg).

Kokkuvõte ja lõplikud märkused

Selles artiklis toome välja mitmeid tänapäevaste Linuxi distributiivide turvaomadusi. Analüüs näitas, et kõige uuemas Ubuntu LTS (18.04) distributiivis on keskmiselt rakendatud kõige tugevamat OS ja rakenduste taseme kaitset võrreldes suhteliselt uute kernidega nagu Ubuntu 14.04, 12.04 ja Debian 9. Kuigi meie andmestikus on käsitletud distributiivid CentOS, RHEL ja OpenSUSE tavaliselt pakettide tihedamat komplekti, siis viimastes versioonides (CentOS ja RHEL) on kõrgem protsent virnastamise kokkupõrke kaitse rakendamisest võrreldes Debianil põhinevate konkurentidega (Debian ja Ubuntu). Võrreldes CentOSi ja RedHati versioone, märkame suuri edusamme virnastamise kanarakkude ja RELRO rakendamisel versioonidelt 6 kuni 7, kuid keskmiselt on CentOSis rohkem funktsioone rakendatud kui RHELis. Üldiselt peaksid kõik distributiivid pöörama erilist tähelepanu PIE kaitsele, mis on meie andmestikus rakendatud vähem kui 10% binaarfailidest, välja arvatud Debian 9 ja Ubuntu 18.04.

Lõpuks tasub mainida: kuigi me viisime läbi uurimuse käsitsi, on olemas palju turvatööriistu (nt. Lynis, Tiger, Hubble), mis viivad läbi analüüsi ja aitavad vältida ebaohutuid konfiguratsioone. Kahjuks ei taga isegi tugev kaitse mõistlike konfiguratsioonide puhul, et eksploite ei esine. Just seetõttu usume kindlalt, et elutähtis on tagada usaldusväärne jälgimine ja ründete vältimine reaalajas, keskendudes ekspluateerimise mudelitele ja vältides neid.

Allikas: habr.com