TL; DR. Бұл мақалада біз бес танымал Linux дистрибутивінде қораптан тыс жұмыс істейтін қатайту схемаларын зерттейміз. Әрқайсысы үшін біз ядроның әдепкі конфигурациясын қабылдадық, барлық пакеттерді жүктедік және бекітілген екілік файлдардағы қауіпсіздік схемаларын талдадық. Қарастырылған дистрибуциялар OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 және 7, сондай-ақ Ubuntu 14.04, 12.04 және 18.04 LTS болып табылады.

Нәтижелер тіпті канарейлерді жинақтау және позицияға тәуелсіз код сияқты негізгі схемаларды әлі бәрі бірдей қабылдамайтынын растайды. Қаңтар айында жарияланғаннан кейін назар аударған стек қақтығысы сияқты осалдықтардан қорғауға келетін болсақ, компиляторлар үшін жағдай одан да нашар. жүйелік осалдықтар туралы ақпарат. Бірақ бәрі соншалықты үмітсіз емес. Екілік файлдардың айтарлықтай саны негізгі қорғау әдістерін жүзеге асырады және олардың саны нұсқадан нұсқаға өседі.

Шолу қорғау әдістерінің ең көп саны Ubuntu 18.04 жүйесінде ОЖ және қолданба деңгейлерінде, одан кейін Debian 9-да енгізілгенін көрсетті. Екінші жағынан, OpenSUSE 12.4, CentOS 7 және RHEL 7 негізгі қорғаныс схемаларын және стек соқтығыстарынан қорғауды жүзеге асырады. әдепкі пакеттердің әлдеқайда тығыз жиынтығымен одан да кеңірек қолданылады.

Кіріспе

Жоғары сапалы бағдарламалық қамтамасыз етуді қамтамасыз ету қиын. Статикалық кодты талдауға және динамикалық орындалу уақытын талдауға арналған кеңейтілген құралдардың үлкен санына, сондай-ақ компиляторлар мен бағдарламалау тілдерін дамытудағы елеулі прогреске қарамастан, заманауи бағдарламалық жасақтама әлі де шабуылдаушылар үнемі пайдаланатын осалдықтардан зардап шегеді. Бұрынғы кодты қамтитын экожүйелердегі жағдай одан да нашар. Мұндай жағдайларда біз ықтимал пайдаланатын қателерді табудың мәңгілік мәселесіне тап болып қана қоймаймыз, сонымен қатар біз жиі шектеулі немесе одан да нашар, осал немесе қате кодты сақтауды талап ететін қатаң кері үйлесімділік шеңберлерімен шектелеміз.

Бұл жерде бағдарламаларды қорғау немесе қатайту әдістері ойнайды. Біз қателердің кейбір түрлерінің алдын ала алмаймыз, бірақ біз шабуылдаушының өмірін қиындата аламыз және алдын алу немесе алдын алу арқылы мәселені ішінара шеше аламыз. қанау бұл қателер. Мұндай қорғаныс барлық заманауи операциялық жүйелерде қолданылады, бірақ әдістер күрделілігі, тиімділігі және өнімділігі бойынша айтарлықтай ерекшеленеді: стек канареяларынан және ASLR толық қорғауға CFI и ROP. Бұл мақалада біз әдепкі конфигурацияда ең танымал Linux дистрибутивтерінде қандай қорғау әдістері қолданылатынын қарастырамыз, сондай-ақ әрбір дистрибутивтің пакетті басқару жүйелері арқылы таратылатын екілік файлдардың қасиеттерін қарастырамыз.

CVE және қауіпсіздік

Біз бәріміз «Жылдың ең осал қолданбалары» немесе «Ең осал операциялық жүйелер» сияқты тақырыптары бар мақалаларды көрдік. Әдетте олар осалдықтар туралы жазбалардың жалпы саны туралы статистиканы береді CVE (Жалпы осалдық пен әсер ету), алынған Ұлттық осалдық деректер қоры (NVD) от NIST және басқа көздер. Кейіннен бұл қолданбалар немесе ОЖ CVE саны бойынша дәрежеленеді. Өкінішке орай, CVE-лер мәселелерді қадағалау және жеткізушілер мен пайдаланушыларды ақпараттандыру үшін өте пайдалы болғанымен, олар бағдарламалық жасақтаманың нақты қауіпсіздігі туралы аз айтады.

Мысал ретінде Linux ядросы мен ең танымал бес сервер дистрибутивтері, атап айтқанда Ubuntu, Debian, Red Hat Enterprise Linux және OpenSUSE үшін соңғы төрт жылдағы CVE-лердің жалпы санын қарастырайық.

Сурет. 1

Бұл график бізге не береді? CVE санының көп болуы бір дистрибутивтің екіншісіне қарағанда осал екенін білдіре ме? Жауап жоқ. Мысалы, осы мақалада сіз Debian-де, айталық, OpenSUSE немесе RedHat Linux-пен салыстырғанда күшті қауіпсіздік механизмдері бар екенін көресіз, бірақ Debian-де CVE көп. Дегенмен, олар міндетті түрде әлсіреген қауіпсіздікті білдірмейді: тіпті CVE бар болуы да осалдықтың бар-жоғын көрсетпейді. пайдаланылған. Қауіптілік ұпайлары қалай болатынын көрсетеді мүмкін осалдықты пайдалану, бірақ сайып келгенде, пайдалану мүмкіндігі зардап шеккен жүйелердегі қорғанысқа және шабуылдаушылардың ресурстары мен мүмкіндіктеріне байланысты. Сонымен қатар, CVE есептерінің болмауы басқалар туралы ештеңе айтпайды тіркелмеген немесе белгісіз осалдықтар. CVE айырмашылығы бағдарламалық қамтамасыз ету сапасынан басқа факторларға, соның ішінде тестілеуге бөлінген ресурстарға немесе пайдаланушы базасының өлшеміне байланысты болуы мүмкін. Біздің мысалда Debian CVE санының көп болуы Debian бағдарламасының көбірек бағдарламалық пакеттерді жіберетінін көрсетуі мүмкін.

Әрине, CVE жүйесі сәйкес қорғауды жасауға мүмкіндік беретін пайдалы ақпаратты береді. Бағдарламаның сәтсіздігінің себептерін неғұрлым жақсы түсінсек, пайдаланудың ықтимал әдістерін анықтау және сәйкес механизмдерді әзірлеу соғұрлым оңайырақ болады. анықтау және жауап беру. Суретте. 2 соңғы төрт жылдағы барлық таратулар үшін осалдықтардың санаттарын көрсетеді (көзі). CVE-лердің көпшілігі келесі санаттарға жататыны бірден түсінікті: қызмет көрсетуден бас тарту (DoS), кодты орындау, толып кету, жадтың бұзылуы, ақпараттың ағуы (эксфильтрация) және артықшылықтардың артуы. Көптеген CVE әртүрлі санаттарда бірнеше рет есептелсе де, жалпы бірдей мәселелер жылдан-жылға сақталады. Мақаланың келесі бөлімінде біз осы осалдықтарды пайдалануды болдырмау үшін әртүрлі қорғау схемаларын пайдалануды бағалаймыз.

Сурет. 2

міндеттері

Бұл мақалада біз келесі сұрақтарға жауап бергіміз келеді:

• Әртүрлі Linux дистрибутивтерінің қауіпсіздігі қандай? Ядрода және пайдаланушы кеңістігіндегі қолданбаларда қандай қорғау механизмдері бар?
• Қауіпсіздік тетіктерін қабылдау дистрибуциялар бойынша уақыт өте қалай өзгерді?
• Әрбір тарату үшін бумалар мен кітапханалардың орташа тәуелділіктері қандай?
• Әрбір екілік үшін қандай қорғаулар жүзеге асырылады?

Бөлулерді таңдау

Тарату қондырғылары туралы нақты статистиканы табу қиынға соғады, өйткені көп жағдайда жүктеулер саны нақты қондырғылардың санын көрсетпейді. Дегенмен, Unix нұсқалары серверлік жүйелердің көпшілігін құрайды (веб-серверлерде 69,2%, by статистика W3techs және басқа көздер) және олардың үлесі үнемі өсіп келеді. Осылайша, біз өз зерттеулеріміз үшін платформадағы қораптан тыс қолжетімді дистрибутивтерге назар аудардық Google Cloud. Атап айтқанда, біз келесі операциялық жүйені таңдадық:

Тарату/нұсқа
Ядро
Құру

OpenSUSE 12.4
4.12.14-95.3-әдепкі
№1 SMP Ср 5 желтоқсан 06:00:48 UTC 2018 (63a8d29)

Debian 9 (созылу)
4.9.0-8-amd64
№1 SMP Debian 4.9.130-2 (2018)

CentOS 6.10
2.6.32-754.10.1.el6.x86_64
№1 SMP сейсенбі 15 қаңтар 17:07:28 UTC 2019 ж

CentOS 7
3.10.0-957.5.1.el7.x86_64
№1 SMP 1 ақпан жұма 14:54:57 UTC 2019 ж

Red Hat Enterprise Linux Server 6.10 (Сантьяго)
2.6.32-754.9.1.el6.x86_64
№1 SMP Ср 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 15 қараша 17:36:42 UTC 2018

Ubuntu 14.04 (Сенімді Tahr)
4.4.0–140-жалпы

№166~14.04.1-Ubuntu SMP 17 қараша сенбі 01:52:43 UTC 20…

Ubuntu 16.04 (Xenial Xerus)
4.15.0–1026-gcp
№27~16.04.1-Ubuntu SMP 7 желтоқсан жұма 09:59:47 UTC 2018

Ubuntu 18.04 (Бионикалық құндыз)
4.15.0–1026-gcp
№27-Ubuntu SMP 6 желтоқсан 18:27:01 UTC 2018

Кесте 1

Талдау

Әдепкі ядро ​​конфигурациясын, сондай-ақ қораптан тыс әрбір таратудың бума менеджері арқылы қол жетімді пакеттердің сипаттарын зерттейік. Осылайша, біз тұрақсыз репозиторийлерден (мысалы, Debian «тестілеу» айналары) және үшінші тарап пакеттерін (стандартты айналардағы Nvidia бумалары сияқты) елемей, әрбір дистрибутивтің әдепкі айналарындағы бумаларды ғана қарастырамыз. Сонымен қатар, біз реттелетін ядро ​​жинақтарын немесе қауіпсіздікпен күшейтілген конфигурацияларды қарастырмаймыз.

Ядро конфигурациясының талдауы

негізінде талдау сценарийін қолдандық тегін kconfig тексерушісі. Аты аталған дистрибутивтердің қораптан тыс қорғаныс параметрлерін қарастырайық және оларды тізіммен салыстырайық. Негізгі өзін-өзі қорғау жобасы (KSPP). Әрбір конфигурация опциясы үшін 2-кесте қалаған параметрді сипаттайды: құсбелгі KSSP ұсыныстарына сәйкес келетін таратуларға арналған (шарттардың түсіндірмесі үшін келесіні қараңыз). осында; Болашақ мақалаларда біз осы қауіпсіздік әдістерінің қаншасы пайда болғанын және олар болмаған кезде жүйені қалай бұзуға болатынын түсіндіреміз).

Жалпы, жаңа ядролардың қораптан тыс қатаң параметрлері бар. Мысалы, 6.10 ядросындағы CentOS 6.10 және RHEL 2.6.32 жаңа ядроларда енгізілген маңызды мүмкіндіктердің көпшілігіне жетіспейді, мысалы, SMAP, қатаң RWX рұқсаттары, мекенжай рандомизациясы немесе copy2usr қорғауы. Айта кету керек, кестедегі көптеген конфигурация опциялары ядроның ескі нұсқаларында қол жетімді емес және олар іс жүзінде қолданылмайды - бұл әлі де кестеде тиісті қорғаныстың жоқтығы ретінде көрсетілген. Сол сияқты, егер конфигурация опциясы берілген нұсқада болмаса және қауіпсіздік бұл опцияны өшіруді талап етсе, бұл ақылға қонымды конфигурация болып саналады.

Нәтижелерді интерпретациялау кезінде ескерілетін тағы бір мәселе: шабуыл бетін арттыратын кейбір ядро ​​конфигурациялары қауіпсіздік үшін де пайдаланылуы мүмкін. Мұндай мысалдарға пробтар мен к зондтар, ядро ​​модульдері және BPF/eBPF жатады. Біздің ұсынысымыз жоғарыда аталған механизмдерді нақты қорғауды қамтамасыз ету үшін пайдалану болып табылады, өйткені оларды пайдалану тривиальды емес және оларды пайдалану зиянды әрекеттердің жүйеде өз орнын орнатқанын болжайды. Бірақ бұл опциялар қосылған болса, жүйе әкімшісі теріс пайдалануды белсенді түрде бақылауы керек.

2-кестедегі жазбаларды әрі қарай қарастыратын болсақ, біз заманауи ядролардың ақпараттың ағып кетуі және стек/үйменің асып кетуі сияқты осалдықтарды пайдаланудан қорғаудың бірнеше нұсқаларын қамтамасыз ететінін көреміз. Дегенмен, біз тіпті ең соңғы танымал дистрибутивтердің де күрделі қорғанысты әлі жүзеге асырмағанын байқаймыз (мысалы, патчтармен қауіпсіздік) немесе кодты қайта пайдалану шабуылдарынан заманауи қорғаныс (мысалы, кодқа арналған R^X сияқты схемалармен рандомизацияның комбинациясы). Ең сорақысы, тіпті осы жетілдірілген қорғаныстар шабуылдардың толық спектрінен қорғамайды. Сондықтан жүйелік әкімшілер үшін смарт конфигурацияларды орындау уақытындағы эксплойттерді анықтау және алдын алуды ұсынатын шешімдермен толықтыру өте маңызды.

Қолданбаларды талдау

Таңқаларлық емес, әртүрлі дистрибутивтердің әртүрлі бума сипаттамалары, жинақтау опциялары, кітапханалық тәуелділіктері және т.б. болады. Айырмашылықтар тіпті үшін де бар. байланысты аздаған тәуелділіктері бар дистрибутивтер мен бумалар (мысалы, Ubuntu немесе Debian жүйесіндегі coreutils). Айырмашылықтарды бағалау үшін біз барлық қолжетімді пакеттерді жүктеп алдық, олардың мазмұнын шығарып, екілік және тәуелділіктерді талдадық. Әрбір бума үшін біз оған тәуелді басқа пакеттерді қадағалап отырдық және әрбір екілік үшін оның тәуелділіктерін қадағаладық. Бұл бөлімде біз қорытындыларды қысқаша қорытындылаймыз.

Тарату

Барлығы біз барлық дистрибутивтерге арналған 361 556 буманы жүктеп алдық, тек әдепкі айналардан пакеттерді шығарып алдық. Біз көздер, қаріптер және т.б. сияқты ELF орындалатын файлдары жоқ бумаларды елемедік. Сүзгілеуден кейін барлығы 129 569 екілік файлдарды қамтитын 584 457 бума қалды. Пакеттердің және файлдардың дистрибутивтер бойынша таралуы суретте көрсетілген. 3.

Сурет. 3

Тарату неғұрлым заманауи болса, онда соғұрлым көп пакеттер мен екілік файлдар бар екенін байқайсыз, бұл қисынды. Дегенмен, Ubuntu және Debian пакеттері CentOS, SUSE және RHEL-ге қарағанда әлдеқайда көп екілік файлдарды (орындалатын файлдар, динамикалық модульдер мен кітапханалар) қамтиды, бұл Ubuntu және Debian шабуыл бетіне ықтимал әсер етеді (сандар барлық нұсқалардың барлық екілік файлдарын көрсететінін атап өткен жөн. пакет, яғни кейбір файлдар бірнеше рет талданады). Бұл пакеттер арасындағы тәуелділіктерді қарастырған кезде өте маңызды. Осылайша, осал кітапхана оны импорттайтын барлық екілік файлдарға әсер етуі сияқты, жалғыз екілік бумадағы осалдық экожүйенің көптеген бөліктеріне әсер етуі мүмкін. Бастапқыда әртүрлі операциялық жүйелердегі пакеттер арасындағы тәуелділіктер санының таралуын қарастырайық:

Сурет. 4

Барлық дерлік дистрибутивтерде пакеттердің 60% кем дегенде 10 тәуелділікке ие. Сонымен қатар, кейбір пакеттерде тәуелділіктердің айтарлықтай көп саны бар (100-ден астам). Бұл кері пакеттік тәуелділіктерге де қатысты: күткендей, бірнеше буманы таратудағы көптеген басқа пакеттер пайдаланады, сондықтан кейбір таңдалғандардағы осалдықтардың қауіптілігі жоғары. Мысал ретінде келесі кестеде SLES, Centos 20, Debian 7 және Ubuntu 9 жүйелеріндегі кері тәуелділіктердің ең көп саны бар 18.04 бума тізімі берілген (әр ұяшық бума мен кері тәуелділіктердің санын көрсетеді).

Кесте 3

Қызықты факт. Талданатын барлық ОЖ-лар x86_64 архитектурасы үшін құрастырылғанымен және пакеттердің көпшілігінің архитектурасы x86_64 және x86 ретінде анықталғанымен, 5-суретте көрсетілгендей пакеттерде басқа архитектуралар үшін екілік файлдар жиі болады. XNUMX.

Сурет. 5

Келесі бөлімде біз талданатын екілік файлдардың сипаттамаларын қарастырамыз.

Екілік файлдарды қорғау статистикасы

Абсолютті минимумда бар екілік файлдарыңыз үшін қауіпсіздік опцияларының негізгі жинағын зерттеуіңіз керек. Бірнеше Linux дистрибутивтері осындай тексерулерді орындайтын сценарийлермен бірге келеді. Мысалы, Debian/Ubuntu-да мұндай сценарий бар. Міне, оның жұмысының мысалы:

$ hardening-check $(which docker)
/usr/bin/docker:
 Position Independent Executable: yes
 Stack protected: yes
 Fortify Source functions: no, only unprotected functions found!
 Read-only relocations: yes
 Immediate binding: yes

Сценарий бесті тексереді қорғау функциялары:

• Position Independent Executable (PIE): ASLR ядрода қосылған болса, рандомизацияға қол жеткізу үшін бағдарламаның мәтін бөлімін жадта жылжытуға болатындығын көрсетеді.
• Стек қорғалған: стектің соқтығысуы шабуылдарынан қорғау үшін стек канареялары қосулы ма.
• Fortify Source: қауіпті функциялар (мысалы, strcpy) олардың анағұрлым қауіпсіз әріптестерімен ауыстырылады ма және орындалу уақытында тексерілген қоңыраулар олардың тексерілмеген әріптестерімен ауыстырылады ма (мысалы, __memcpy_chk орнына memcpy).
• Тек оқуға арналған орын ауыстырулар (RELRO): Орындау басталғанға дейін іске қосылса, орын ауыстыру кестесінің жазбалары тек оқу үшін белгіленеді ме.
• Дереу байланыстыру: орындалу уақытының сілтемесі бағдарламаны орындау басталғанға дейін барлық қозғалыстарға рұқсат ете ме (бұл толық RELRO-ға тең).

Жоғарыда аталған механизмдер жеткілікті ме? Өкінішке орай жоқ. Жоғарыда аталған қорғаныстардың барлығын айналып өтудің белгілі жолдары бар, бірақ қорғаныс неғұрлым қатал болса, соғұрлым шабуылдаушы үшін жолақ жоғары болады. Мысалы, RELRO айналып өту әдістері PIE және дереу байланыстыру күшінде болса, қолдану қиынырақ. Сол сияқты, толық ASLR жұмыс істейтін эксплойтты жасау үшін қосымша жұмысты қажет етеді. Дегенмен, күрделі шабуылдаушылар мұндай қорғанысты орындауға дайын: олардың болмауы бұзуды айтарлықтай жылдамдатады. Сондықтан бұл шараларды қажет деп санау өте маңызды ең аз.

Қарастырылып отырған дистрибутивтердегі қанша екілік файлдар осы және басқа үш әдіспен қорғалғанын зерттегіміз келді:

• Орындалмайтын бит (NX) орындалмауы керек кез келген аймақта орындалуды болдырмайды, мысалы, стек жинағы, т.б.
• RPATH/RUNPATH сәйкес кітапханаларды табу үшін динамикалық жүктеуші пайдаланатын орындау жолын білдіреді. Біріншісі міндетті кез келген заманауи жүйе үшін: оның болмауы шабуылдаушыларға пайдалы жүктемені жадқа ерікті түрде жазуға және оны сол күйінде орындауға мүмкіндік береді. Екіншіден, дұрыс емес орындалу жолы конфигурациялары бірқатар мәселелерге (мысалы, артықшылықтардың артуы, және де басқа проблемалар).
• Стек соқтығысудан қорғау стек жадтың басқа аймақтарын (мысалы, үйме) қабаттасатын шабуылдардан қорғауды қамтамасыз етеді. Жақында теріс пайдалануды ескере отырып жүйелік үйме соқтығысудың осалдықтары, біз бұл механизмді деректер жинағына қосуды орынды деп санадық.

Олай болса, көп ұзамай, сандарға көшейік. 4 және 5-кестелер сәйкесінше орындалатын файлдар мен әртүрлі дистрибутивтердің кітапханаларының талдауының қысқаша мазмұнын қамтиды.

• Көріп отырғаныңыздай, NX қорғанысы сирек жағдайларды қоспағанда, барлық жерде жүзеге асырылады. Атап айтқанда, оның Ubuntu және Debian дистрибутивтерінде CentOS, RHEL және OpenSUSE-мен салыстырғанда біршама төмен қолданылуын атап өтуге болады.
• Көптеген жерлерде, әсіресе ескі ядролары бар дистрибутивтерде стек канареялары жоқ. Centos, RHEL, Debian және Ubuntu-ның соңғы дистрибутивтерінде кейбір жетістіктер байқалады.
• Debian және Ubuntu 18.04-тен басқа дистрибутивтердің көпшілігінде PIE қолдауы нашар.
• Стек соқтығысудан қорғау OpenSUSE, Centos 7 және RHEL 7 жүйелерінде әлсіз, ал басқаларында іс жүзінде жоқ.
• Заманауи ядролары бар барлық дистрибутивтер RELRO-ға біршама қолдау көрсетеді, Ubuntu 18.04 көш бастап, Debian екінші орында келеді.

Жоғарыда айтылғандай, осы кестедегі көрсеткіштер екілік файлдың барлық нұсқалары үшін орташа мән болып табылады. Егер файлдардың соңғы нұсқаларын ғана қарасаңыз, сандар әртүрлі болады (мысалы, қараңыз PIE енгізу арқылы Debian прогрессі). Сонымен қатар, дистрибутивтердің көпшілігі статистиканы есептеу кезінде әдетте екілік жүйеде бірнеше функциялардың қауіпсіздігін тексереді, бірақ біздің талдауымыз күшейтілген функциялардың шынайы пайызын көрсетеді. Сондықтан, егер 5 функцияның 50-і екілік жүйеде қорғалған болса, біз оған 0,1 балл береміз, бұл күшейтілетін функциялардың 10% сәйкес келеді.

Кесте 4. Суретте көрсетілген орындалатын файлдардың қауіпсіздік сипаттамалары. 3 (орындалатын файлдардың жалпы санына пайызбен сәйкес функцияларды орындау)

Кесте 5. Суретте көрсетілген кітапханалардың қауіпсіздік сипаттамалары. 3 (кітапханалардың жалпы санынан пайызбен тиісті функцияларды орындау)

Сонда прогресс бар ма? Міндетті түрде бар: мұны жеке үлестірімдерге арналған статистикадан көруге болады (мысалы, Debian), сондай-ақ жоғарыдағы кестелерден. Мысал ретінде суретте. 6-суретте Ubuntu LTS 5-тің үш дәйекті дистрибутивтерінде қорғаныс механизмдерінің орындалуы көрсетілген (біз стектің соқтығысудан қорғау статистикасын алып тастадық). Нұсқадан нұсқаға көбірек файлдар стек канареяларын қолдайтынын байқаймыз, сонымен қатар көбірек екілік файлдар толық RELRO қорғанысымен жеткізіледі.

Сурет. 6

Өкінішке орай, әртүрлі дистрибутивтердегі бірқатар орындалатын файлдар әлі де жоғарыда аталған қорғаулардың ешқайсысына ие емес. Мысалы, Ubuntu 18.04 нұсқасына қарап, сіз ngetty екілік нұсқасын (getty ауыстыру), сондай-ақ mksh және lksh қабықшаларын, picolisp интерпретаторын, nvidia-cuda-toolkit бумаларын (GPU жеделдетілген қолданбаларға арналған танымал пакет) байқайсыз. машиналық оқыту шеңберлері) және klibc -utils. Сол сияқты, mandos-client екілік (шифрланған файлдық жүйелері бар машиналарды автоматты түрде қайта жүктеуге мүмкіндік беретін әкімшілік құрал), сондай-ақ rsh-redone-client (rsh және rlogin қайта іске қосу) SUID құқықтарына ие болғанымен, NX қорғауынсыз жеткізіледі: (. Сондай-ақ, бірнеше suid екілік файлдарының стек канареялары сияқты негізгі қорғанысы жоқ (мысалы, Xorg бумасындағы Xorg.wrap екілік файлы).

Қорытынды және қорытынды ескертулер

Бұл мақалада біз заманауи Linux дистрибутивтерінің бірнеше қауіпсіздік мүмкіндіктерін атап өттік. Талдау көрсеткендей, соңғы Ubuntu LTS дистрибуциясы (18.04) орташа алғанда, Ubuntu 14.04, 12.04 және Debian 9 сияқты салыстырмалы түрде жаңа ядролары бар дистрибутивтер арасында ең күшті ОЖ және қолданба деңгейін қорғауды жүзеге асырады. Дегенмен, зерттелген дистрибутивтер CentOS, RHEL және OpenSUSE біздің жиынтықта әдепкі бойынша олар пакеттердің неғұрлым тығыз жинағын шығарады және соңғы нұсқаларында (CentOS және RHEL) олар Debian негізіндегі бәсекелестермен (Debian және Ubuntu) салыстырғанда стек соқтығыстарынан қорғаудың жоғары пайызына ие. CentOS және RedHat нұсқаларын салыстыра отырып, біз 6-дан 7-ге дейінгі нұсқалардағы канарейлер мен RELRO стектерін енгізуде үлкен жақсартуларды байқаймыз, бірақ орташа алғанда CentOS-та RHEL-ге қарағанда көбірек мүмкіндіктер енгізілген. Жалпы алғанда, барлық дистрибутивтер PIE қорғауына ерекше назар аударуы керек, ол Debian 9 және Ubuntu 18.04 қоспағанда, біздің деректер жиынындағы екілік файлдардың 10%-дан азында жүзеге асырылады.

Соңында, біз зерттеуді қолмен жүргізгенімізге қарамастан, көптеген қауіпсіздік құралдары бар екенін атап өткен жөн (мысалы, Линис, жолбарыс, Хаббл), талдауды жүзеге асырады және қауіпті конфигурацияларды болдырмауға көмектеседі. Өкінішке орай, тіпті ақылға қонымды конфигурациялардағы күшті қорғаныс эксплуатациялардың жоқтығына кепілдік бермейді. Сондықтан біз оны қамтамасыз ету өте маңызды екеніне сенімдіміз нақты уақыт режимінде сенімді бақылау және шабуылдардың алдын алу, пайдалану үлгілеріне назар аудару және олардың алдын алу.

Ақпарат көзі: www.habr.com