TL;DR. Šajā rakstā mēs pētniecības aizsardzības shēmas (hardening schemes), kas no jebkura parādās piecu populāru Linux distribūciju. Katram mēs ņēmām noklusējuma kodola konfigurāciju, instalējām visus pakotnes un analizējām aizsardzības shēmas iekšējos bināros failos. Apskatām distribūcijas OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 un 7, kā arī Ubuntu 14.04, 12.04 un 18.04 LTS.

Rezultāti apstiprina, ka pat pamatshēmas, piemēram, stāvu kanāri un pozīcijas neatkarīgas kodas, vēl joprojām netiek plaši izmantotas. Situācija ir vēl sliktāka kompilatoriem, kad runa ir par aizsardzību pret ievainojamībām, piemēram, steka sadursmi (stack clash), kas kļuva aktuāla janvārī pēc informācijas publicēšanas. par ievainojamībām systemd.. Bet ne viss ir tik bezcerīgi. Lielā daļā bināro failu ir ieviesti pamata aizsardzības metodēm, un to skaits pieaug no versijas uz versiju.

Pārbaude parādīja, ka visvairāk aizsardzības metodes ir ieviestas Ubuntu 18.04 operētājsistēmas un lietojumprogrammu līmenī, pēc tam seko Debian 9. Savukārt, OpenSUSE 12.4, CentOS 7 un RHEL 7 arī ir ieviestas pamata aizsardzības shēmas, bet aizsardzība pret steka sadursmi tiek izmantota vēl plašāk, ņemot vērā daudz lielāku noklusējuma pakotņu kopumu.

Ievads

Ir grūti nodrošināt augstu programmatūras kvalitāti. Neskatoties uz milzīgo progresīvo instrumentu skaitu statiskai koda analīzei un dinamiskai analīzei izpildes laikā, kā arī ievērojamu progresu kompilatoru un programmēšanas valodu izstrādē, mūsdienu programmatūra joprojām cieš no ievainojamībām, ko nepārtraukti izmanto uzbrucēji. Situācija ir vēl sliktāka ekosistēmās, kas ietver novecojušu kodu. Šādos gadījumos mēs ne tikai saskaramies ar mūžīgu problēmu par iespējamām izpētes kļūdām, bet arī esam ierobežoti stingros atpakaļ savienojamības ietvaros, kas bieži prasa saglabāt ierobežotu, un vēl sliktāk — ievainojamu vai kļūdainu kodu.

Šeit spēlē iejaucas aizsardzības vai pastiprināšanas metodes (hardening). Dažas kļūdas mēs nevaram novērst, taču mēs varam apgrūtināt uzbrucējiem dzīvi un daļēji atrisināt problēmu, novēršot vai traucējot. exploatācijai šīs kļūdas. Šāda aizsardzība tiek izmantota visās modernajās OS, tomēr metodes ļoti atšķiras pēc sarežģītības, efektivitātes un veiktspējas: no steku kanārijiem (stack canaries) un ASLR līdz pilniem aizsardzības mehānismiem CFI un ROP. Šajā rakstā aplūkosim, kādi aizsardzības paņēmieni tiek izmantoti slavenākajos Linux izplatījumos noklusējuma konfigurācijā, kā arī izpētīsim bināro failu īpašības, kas tiek izplatītas caur katra izplatījuma pakotņu pārvaldības sistēmām.

CVE un drošība

Visi mēs esam redzējuši rakstus ar nosaukumiem, piemēram, «Gada neaizsargātākās lietotnes» vai «Gada neaizsargātākās operētājsistēmas». Parasti tur ir statistika par kopējo neaizsargātību veidu skaitu CVE (Common Vulnerability and Exposures), kas iegūta no Nacionālās neaizsargātību datubāzes (NVD) no NIST un citiem avotiem. Pēc tam šīs lietotnes vai OS tiek rangotas pēc CVE skaita. Diemžēl, lai gan CVE ir ļoti noderīgas problēmu izsekošanai un piegādātāju un lietotāju informēšanai, tās maz norāda uz faktiskā programmatūras drošības līmeņa.

Piemēram, aplūkosim kopējo CVE skaitu pēdējo četru gadu laikā Linux kodolam un pieciem vispopulārākajiem servera izplatījumiem, proti, Ubuntu, Debian, Red Hat Enterprise Linux un OpenSUSE.

Attēls 1

Ko mums saka šis grafiks? Vai lielāks CVE skaits nozīmē, ka viens izplatījums ir neaizsargātāks nekā cits? Atbilde nav. Piemēram, šajā rakstā jūs redzēsiet, ka Debian ir īstenoti stingrāki aizsardzības mehānismi salīdzinājumā ar, teiksim, OpenSUSE vai RedHat Linux, un tomēr Debian ir vairāk CVE. Tomēr tās nenozīmē vājāku drošību: pat CVE klātbūtne nenorāda uz to, vai neaizsargātība ir izmantojama. Smaguma punkti sniedz priekšstatu par to, cik iespējama neaizsargātības izmantošana, tomēr, galu galā, izmantojamība lielā mērā ir atkarīga no aizsardzības līdzekļiem, kas ir attiecīgajās sistēmās, kā arī no uzbrucēju resursiem un iespējām. Turklāt CVE ziņojumu trūkums neko nesaka par citām neierakstītām vai nezināmām neaizsargātībām ievainojumos. Atšķirība CVE var tikt skaidrota nevis ar programmatūras kvalitāti, bet ar citiem faktoriem, tostarp resursiem, kas piešķirti testēšanai, vai izmantotāju bāzes lielumu. Mūsu piemērā lielāks CVE skaits Debian var vienkārši liecināt par to, ka Debian piedāvā vairāk programmatūras pakotņu.

Protams, CVE sistēma sniedz lietderīgu informāciju, kas ļauj izstrādāt atbilstošus aizsardzības mehānismus. Jo labāk mēs saprotam programmatūras avāriju cēloņus, jo vieglāk ir noteikt iespējamos izmantošanas veidus un izstrādāt attiecīgos mehānismus. atklāšanai un reaģēšanai. 2. attēlā parādītas ievainojamības kategorijas visiem izplatījumiem pēdējo četru gadu laikā (avots). Uzreiz var redzēt, ka lielākā daļa CVE nonāk šādās kategorijās: pakalpojuma atteikšana (DoS), koda izpilde, pārsniegums, atmiņas bojājums, informācijas noplūde (ekstrakcija) un privilēģiju eskalācija. Lai gan daudzas CVE tiek ņemtas vērā vairākas reizes dažādās kategorijās, kopumā tās pašas problēmas saglabājas no gada uz gadu. Nākamajā raksta daļā mēs novērtēsim dažādu aizsardzības shēmu izmantošanu, lai novērstu šo ievainojamību izmantošanu.

Att. 2

Uzdevumi

Šajā rakstā mēs vēlamies atbildēt uz sekojošiem jautājumiem:

• Kāda ir dažādu Linux izplatījumu drošība? Kādi aizsardzības mehānismi pastāv kodolā un lietotāja telpā?
• Kā laika gaitā ir mainījusies aizsardzības mehānismu pieņemšana dažādām izplatījumiem?
• Kādas ir katra izplatījuma paciņu un bibliotēku vidējās atkarības?
• Kādas aizsardzības ir realizētas katram binārajam failam?

Izplatījumu izvēle

Izrādās, ir grūti atrast precīzu statistiku par izplatījumu uzstādēm, jo ​​vairumā gadījumu lejupielāžu skaits nenorāda uz reālo uzstādījumu skaitu. Tomēr Unix varianti veido lielāko daļu serveru sistēmu (69,2% tīmekļa serveros, saskaņā ar W3techs un citiem avotiem), un to daļa nepārtraukti pieaug. Tādējādi mūsu pētījumā mēs koncentrējāmies uz izplatījumiem, kas pieejami ārpus kastes uz platformas statistiku . Īpaši mēs izvēlējāmies šādas operētājsistēmas: Google CloudIzplatījums/versija

Būvniecība
Kodols
OpenSUSE 12.4

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

4.9.0-8-amd64
CentOS 6.10
#1 SMP Debian 4.9.130-2 (2018-10-27)

2.6.32-754.10.1.el6.x86_64
3.10.0-957.5.1.el7.x86_64
#1 SMP Tue Jan 15 17:07:28 UTC 2019

CentOS 7
Red Hat Enterprise Linux Server 6.10 (Santiago)
#1 SMP Fri Feb 1 14:54:57 UTC 2019

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

3.10.0-957.1.3.el7.x86_64
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

Tabula 1

Analīze

Pārlūkosim noklusējuma kodola konfigurāciju, kā arī pakotņu īpašības, kas pieejamas caur katra izplatījuma iepriekš instalēto pakešu pārvaldnieku. Tādējādi mēs apsveram tikai pakotnes no katra izplatījuma noklusējuma spoguļiem, ignorējot pakotnes no nestabilajiem repozitorijiem (piemēram, 'testing' spoguļiem Debian) un trešo pušu pakotnes (piemēram, Nvidia pakotnes no standarta spoguļiem). Turklāt mēs neizskatām lietotāju kompilācijas kodolu vai konfigurācijas ar uzlabotu aizsardzību.

Kodola konfigurācijas analīze

Mēs pielietojām analīzes skriptu, kas balstīts uz brīvā kconfig pārbaude. Apsveram noklusējuma aizsardzības iestatījumus minētajos izplatījumos un salīdzinām tos ar sarakstu no Kodola paš aizsardzības projekta (KSPP). Katram konfigurācijas parametram tabulā 2 tiek aprakstīts vēlamais iestatījums: atzīme ir novietota izplatījumiem, kas atbilst KSSP ieteikumiem (termiņu skaidrojums skat. šeit; nākamajos rakstos mēs izstāstīsim, kā daudzas no šīm aizsardzības metodēm radās un kā uzlauzt sistēmu to trūkuma dēļ).

Kopumā jaunajos kodolos ir stingrāki noklusējuma iestatījumi. Piemēram, CentOS 6.10 un RHEL 6.10 ar kodolu 2.6.32 trūkst vairuma kritisko funkciju, kas ir ieviestas jaunajos kodolos, piemēram, SMAP, stingras RWX atļaujas, adreses randomizācija vai copy2usr aizsardzība. Jāatzīmē, ka daudzi no konfigurācijas variantiem tabulā nav pieejami vecākās kodola versijās un nav reāli piemērojami - tabulā tas tomēr norādīts kā nepietiekama aizsardzība. Līdzīgi, ja konfigurācijas parametrs nav pieejams šajā versijā, bet šīs drošības parametru jāizslēdz, tas tiek uzskatīts par saprātīgu konfigurāciju.

Vēl viens aspekts rezultātu interpretācijā: daži kodola konfigurācijas varianti, kas palielina uzbrukuma virsmu, var tikt izmantoti arī drošībai. Šādi piemēri ir uprobes un kprobes, kodola moduļi un BPF/eBPF. Mūsu ieteikums ir izmantot iepriekš minētos mehānismus, lai nodrošinātu reālu aizsardzību, jo to izmantošana nav vienkārša, un to ekspluatācija pieļauj, ka ļaunprātīgas personas jau ir iekļuvušas sistēmā. Taču, ja šie parametri ir aktivizēti, sistēmas administratoram ir aktīvi jākontrolē ļaunprātīgas darbības.

Turpinot pētīt 2. tabulas ierakstus, mēs redzam, ka mūsdienu kodoli piedāvā vairākas iespējas aizsardzībai pret tādām ievainojamībām kā informācijas noplūde un steka/kaudzes pārplūde. Tomēr mēs pamanām, ka pat vissvarīgākie populārie izplatījumi vēl nav īstenojuši sarežģītākas aizsardzības opcijas (piemēram, ar plāksnēm grsecurity) vai modernu aizsardzību pret koda atkārtotas izmantošanas uzbrukumiem (piemēram, kombinējot randomizāciju ar R^X tipa shēmām koda). Vēl sliktāk, pat šie progresīvie aizsardzības līdzekļi nepasargā no pilnas uzbrukumu spektra. Tādējādi sistēmas administratoriem ir ārkārtīgi svarīgi papildināt saprātīgas konfigurācijas ar risinājumiem, kas piedāvā eksploitāciju atklāšanu un novēršanu izpildes laikā.

Lietojumprogrammu analīze

Nav pārsteidzoši, ka dažādiem izplatījumiem ir atšķirīgas paciņu īpašības, kompilācijas opcijas, bibliotēku atkarības u.tml. Atšķirības pastāv pat radniecīgās distribūcijās un paciņās ar nelielu atkarību skaitu (piemēram, coreutils Ubuntu vai Debian). Lai novērtētu atšķirības, mēs lejupielādējām visas pieejamās pakas, izvilkām to saturu un analizējām bināros failus un atkarības. Katram paketēm mēs izsekojām citas paketes, no kurām tā atkarīga, un katram binārajam failam izsekojām tā atkarības. Šajā sadaļā īsi izklāstīsim secinājumus.

Izplatījumi

Kopumā mēs esam ielādējuši 361 556 pakotnes visām izplatīšanas versijām, izvelkot tikai pakotnes no noklusējuma spoguļiem. Mēs ignorējām pakotnes bez izpildāmiem ELF failiem, piemēram, avota kodus, fontus utt. Pēc filtrēšanas palika 129 569 pakotnes, kurās kopā ir 584 457 binārie faili. Pakotņu un failu sadalījums pa izplatīšanas versijām ir parādīts 3. attēlā.

Att. 3

Var novērot, ka jo mūsdienīgāka ir izplatīšanas versija, jo vairāk tajā ir pakotņu un bināro failu, kas ir loģiski. Tajā pašā laikā Ubuntu un Debian pakotnes ietver daudz vairāk bināro failu (gan izpildāmu, gan dinamisku moduļu un bibliotēku), salīdzinot ar CentOS, SUSE un RHEL, kas potenciāli ietekmē Ubuntu un Debian uzbrukuma virsmu (jāatzīmē, ka skaitļi atspoguļo visus bināros failus no visām pakotņu versijām, t.i., daži faili tiek analizēti vairākas reizes). Tas ir īpaši svarīgi, ņemot vērā atkarības starp pakotnēm. Tādējādi ievainojamība kāda pakotnes binārā failā var ietekmēt daudzus ekosistēmas aspektus, jo ievainojama bibliotēka var ietekmēt visus bināros failus, kas to importē. Par atsauci aplūkosim atkarību skaita sadalījumu pa pakotnēm dažādās OS:

Att. 4

Gandrīz visās izplatīšanas versijās 60% pakotņu ir vismaz 10 atkarību. Turklāt dažu pakotņu atkarību skaits ir ievērojami lielāks (vairāk par 100). Tas pats attiecas arī uz pakotņu pretējām atkarībām: kā gaidīts, daudzas pakotnes izmanto vairākas citas pakotnes izplatīšanā, tāpēc ievainojamības šajos nedaudzajos izvēlētajos rada augstu risku. Piemēram, nākamajā tabulā ir uzskaitītas 20 pakotnes ar maksimālo skaitu pretējo atkarību SLES, CentOS 7, Debian 9 un Ubuntu 18.04 (katrā šūnā norādīts pakotnes nosaukums un atkarību skaits).

Tabula 3

Interesants fakts. Lai gan visas analizētās OS ir veidotas x86_64 arhitektūrai, un lielākajai daļai pakotņu arhitektūra ir definēta kā x86_64 un x86, tomēr pakotnes bieži satur bināros failus citām arhitektūrām, kā parādīts 5. attēlā.

Attēls 5

Nākamajā nodaļā detalizēti aplūkosim analizēto bināro failu raksturojumu.

Bināro failu aizsardzības statistika

Kā absolūtais minimums, jāiepazīstas ar pamata aizsardzības variantiem esošajiem binārajiem failiem. Daži Linux sadalījumi nāk ar skriptiem, kas veic šādas pārbaudes. Piemēram, Debian/Ubuntu ir šāds skripts. Lūk, piemērs tā darbībai:

$ hardening-check $(which docker)
/usr/bin/docker:
 Pozīciju neatkarīgs izpildāmais: jā
 Steks aizsargāts: jā
 Fortify Source funkcijas: nē, atrastas tikai neaizsargātas funkcijas!
 Lasāmas relocācijas: jā
 Nekavējoša saistīšana: jā

Skripts pārbauda piecas aizsardzības funkcijas:

• Pozīciju neatkarīgs izpildāmais (PIE): nosaka, vai programmas teksta sekciju var pārvietot atmiņā, lai panāktu randomizāciju, ja kodolā ir aktivizēta ASLR.
• Steka aizsardzība: vai ir iekļautas steka kanāla aizsardzības metodes, lai pasargātu no steka sadursmēm.
• Fortify Source: vai tiek aizstātas nedrošās funkcijas (piemēram, strcpy) ar to drošākajām analoģijām, bet pārbaudītās izsaukuma izsaukumi izpildē - ar neaizsargātajām, piemēram, memcpy vietā __memcpy_chk.
• Lasāmas relocācijas (RELRO): vai relocācijas tabulas ieraksti ir marķēti kā 'tikai lasāmi', ja tie darbojās pirms izpildes sākuma.
• Nekavējoša saistīšana: vai izpildes kompilators atļauj visus pārvietojumus pirms programmas izpildes sākuma (tas ir ekvivalents pilnam RELRO).

Vai minēto mehānismu ir pietiekami? Diemžēl nē. Ir zināmi veidi, kā apiet visas iepriekš minētās aizsardzības, bet jo stingrāka ir aizsardzība, jo augstāka ir robeža uzbrucējiem. Piemēram, RELRO apiet ir grūtāk lietojami, ja darbojas PIE un nekavējoša saistīšana. Līdzīgi, pilna ASLR prasa papildu pūles, lai izveidotu funkcionējošu eksploitu. Tomēr izsmalcināti uzbrucēji jau ir gatavi tikties ar šādām aizsardzībām: to trūkums būtībā paātrinās uzbrukumu. Tāpēc ir ārkārtīgi svarīgi, lai šos pasākumus uzskatītu par nepieciešamiem. minimāli.

Mēs vēlējāmies izpētīt, cik daudz bināro failu aplūkotajos sadalījumos ir aizsargāti ar šiem, kā arī trim citiem paņēmieniem:

• Neizpildāmā biti (NX) novērš izpildi jebkurā reģionā, kas nedrīkst būt izpildāms, piemēram, steka kaudzē utt.
• RPATH/RUNPATH apzīmē izpildes ceļu, ko izmanto dinamisks ielādētājs, lai atrastu atbilstošās bibliotēkas. Pirmais ir obligāts jebkura mūsdienu sistēma: tā trūkums ļauj uzbrucējiem brīvi ierakstīt slodzi atmiņā un izpildīt to tādu, kāda tā ir. Otrajā gadījumā nepareizas izpildes ceļu konfigurācijas veicina mazāk uzticama koda ievietošanu, kas var izraisīt virkni problēmu (piemēram, privileģiju paaugstināšana, kā arī citas problēmas).
• Steka sadursmes aizsardzība nodrošina aizsardzību pret uzbrukumiem, kas liek stekam pārklāt citas atmiņas jomas (piemēram, kaudzi). Ņemot vērā nesenos eksplotus, kas izmanto sistēmasd vājspējas kaudzes sadursmē, mēs uzskatījām, ka ir saprātīgi iekļaut šo mehānismu mūsu datu kopā.

Tātad, bez papildu ceremonijām, pāriesim pie skaitļiem. Tabulās 4 un 5 ir apkopošana par izpildāmajiem failiem un bibliotēkām dažādiem distributīviem attiecīgi.

• Kā var pamanīt, NX aizsardzība ir ieviesta visur ar dažiem izņēmumiem. Īpaši varat ievērot nedaudz zemāku tās izmantošanu Ubuntu un Debian distributīvos salīdzinājumā ar CentOS, RHEL un OpenSUSE.
• Steka kanārijas daudzos gadījumos trūkst, it īpaši distributīvos ar vecām kodolvienībām. Dažas progresu novērojam pēdējā Centos, RHEL, Debian un Ubuntu distributīvu izlaidumos.
• Izņemot Debian un Ubuntu 18.04, lielākajā daļā distributīvu ir vāja PIE atbalsts.
• Steka sadursmes aizsardzība ir vāji īstenota OpenSUSE, Centos 7 un RHEL 7 un praktiski nepastāv pārējiem.
• Visi distributīvi ar mūsdienu kodoliem ir kāda RELRO atbalsta, ar vadību ieņemot Ubuntu 18.04, bet otro vietu ieņem Debian.

Kā jau tika minēts, šajā tabulā iekļautās metriskās vērtības ir vidējās visām binārā faila versijām. Ja aplūkojam tikai jaunākās failu versijas, skaitļi būs citi (piemēram, skat. Debian progress PIE ieviešanā). Turklāt lielākā daļa distributīvu parasti, aprēķinot statistiku, pārbauda aizsardzību tikai dažām funkcijām binārajā kodā, bet mūsu analīzē ir norādīts patiesais nostiprināto funkciju procents. Tāpēc, ja binārā failā ir aizsargātas 5 no 50 funkcijām, mēs piešķirsim tam novērtējumu 0,1, kas atbilst 10% nostiprinātu funkciju.

Tabula 4. Aizsardzības raksturojumi izpildāmajām failām, kas parādītas attēlā 3 (atbilstošo funkciju īstenošana procentos no kopējā izpildāmo failu skaita)

Tabula 5. Aizsardzības īpašības bibliotēkām, kas parādītas attēlā 3 (atbilstošo funkciju īstenošana procentos no kopējā bibliotēku skaita)

Vai ir progress? Noteikti ir: to pierāda statistika par atsevišķiem izplatījumiem (piemēram, Debian), kā arī augstāk minētās tabulas. Kā piemēru attēlā 6 ir parādīta aizsargmehānismu ieviešana trīs secīgiem Ubuntu LTS 5 izplatījumiem (mēs neiekļāvām steka sadursmju aizsardzības statistiku). Mēs novērojam, ka no versijas uz versiju arvien vairāk failu atbalsta steka canaries, kā arī pakāpeniski arvien vairāk bināro failu tiek piegādāti ar pilnu RELRO aizsardzību.

Attēls 6

Diemžēl vairākas izpildāmas faila versijas dažādos izplatījumos joprojām neietver nevienu no iepriekš minētajām aizsardzībām. Piemēram, aplūkojot Ubuntu 18.04, var pamanīt bināro failu ngetty (getty aizvietotājs), kā arī shell mksh un lksh, picolisp interpreteris, nvidia-cuda-toolkit paketi (populāra pakete lietotnēm ar GPU paātrinājumu, piemēram, mašīnmācīšanās ietvari) un klibc-utils. Līdzīgi, binārais fails mandos-client (administratīvs rīks, kas ļauj automātiski restartēt mašīnas ar šifrētām failu sistēmām) un rsh-redone-client (rsh un rlogin atkārtota īstenošana) tiek piegādāti bez NX aizsardzības, lai gan tiem ir SUID tiesības :(. Turklāt dažos suid binārajos failos nav pamata aizsardzības, piemēram, steka canaries (piemēram, binārais fails Xorg.wrap no Xorg paketes).

Kopsavilkums un secinājumi

Šajā rakstā mēs izcēlām vairākas mūsdienu Linux izplatījumu drošības īpašības. Analīze parādīja, ka jaunākajā Ubuntu LTS (18.04) izplatījumā vidēji ir visstingrākā operētājsistēmas un lietotņu līmeņa drošība starp izplatījumiem ar samērā jaunām kodolversijām, piemēram, Ubuntu 14.04, 12.04 un Debian 9. Tomēr apskatītie izplatījumi CentOS, RHEL un OpenSUSE mūsu datu kopā noklusējumā nodrošina blīvāku pakotņu komplektu, un pēdējās versijās (CentOS un RHEL) ir augstāks aizsardzības pret steka sadursmēm īpatsvars, salīdzinot ar Debian balstītajiem konkurentiem (Debian un Ubuntu). Salīdzinot CentOS un RedHat versijas, mēs novērojam būtiskus uzlabojumus steka kanāriju un RELRO ieviešanā no versijām 6 līdz 7, taču vidēji CentOS ir īstenots vairāk funkciju nekā RHEL. Kopumā visiem izplatījumiem jāpievērš īpaša uzmanība PIE drošībai, kas, izņemot Debian 9 un Ubuntu 18.04, ir īstenota mazāk nekā 10% bināro failu mūsu datu kopā.

Visbeidzot, jāatzīmē: lai gan mēs veicām pētījumu manuāli, ir pieejami daudzi drošības rīki (piemēram, Lynis, Tiger, Hubble), kas veic analīzi un palīdz izvairīties no nedrošām konfigurācijām. Diemžēl pat spēcīga aizsardzība saprātīgās konfigurācijās negarantē eksploitāciju trūkumu. Tāpēc mēs stingri uzskatām, ka ir vitāli svarīgi nodrošināt uzticamu uzraudzību un uzbrukumu novēršanu reālajā laikā, koncentrējoties uz ekspluatācijas modeļiem un novēršot to rašanos.

Avots: habr.com