TL; DR. Бул макалада биз беш популярдуу Linux дистрибьюторунда иштөөчү катаалдаштыруу схемаларын изилдейбиз. Ар бири үчүн биз өзөктүн демейки конфигурациясын алып, бардык пакеттерди жүктөдүк жана тиркелген бинарлардагы коопсуздук схемаларын талдадык. Каралган бөлүштүрүүлөр OpenSUSE 12.4, Debian 9, CentOS, RHEL 6.10 жана 7, ошондой эле Ubuntu 14.04, 12.04 жана 18.04 LTS.

Натыйжалар, атүгүл канарейлерди тизүү жана позициядан көз карандысыз код сыяктуу негизги схемалар дагы эле бардыгы тарабынан кабыл алынбагандыгын тастыктайт. Жарыялангандан кийин январь айында көңүл чордонунда болгон стек кагылышуусу сыяктуу алсыздыктардан коргоого келгенде, компиляторлор үчүн абал андан да начар. системанын кемчиликтери жөнүндө маалымат. Бирок баары ушунчалык үмүтсүз эмес. Бинардык системалардын олуттуу саны негизги коргоо ыкмаларын ишке ашырат жана алардын саны версиядан версияга өсөт.

Карап чыгуу көрсөткөндөй, эң көп коргоо ыкмалары Ubuntu 18.04 OS жана тиркеме деӊгээлинде, андан кийин Debian 9 ишке ашырылган. Башка жагынан алганда, OpenSUSE 12.4, CentOS 7 жана RHEL 7 ошондой эле негизги коргоо схемаларын жана стектердин кагылышууларынан коргоону ишке ашырат. демейки пакеттердин бир топ жыш топтому менен дагы кеңири колдонулат.

тааныштыруу

Жогорку сапаттагы программалык камсыздоону камсыз кылуу кыйын. Статикалык кодду талдоо жана динамикалык иштөө убактысын талдоо үчүн өркүндөтүлгөн куралдардын көптүгүнө, ошондой эле компиляторлорду жана программалоо тилдерин өнүктүрүүдө олуттуу прогресске карабастан, заманбап программалык камсыздоо дагы эле чабуулчулар тарабынан тынымсыз эксплуатацияланган алсыздыктардан жапа чегип келет. Эски кодду камтыган экосистемаларда абал андан да начар. Мындай учурларда, биз мүмкүн болгон эксплуатацияланган каталарды табуу боюнча түбөлүк көйгөйгө гана туш болбостон, ошондой эле бизден чектелген, же андан да жаманы, аялуу же ката кодду сактоону талап кылган катуу артка шайкештик алкактары менен чектелебиз.

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

CVE жана коопсуздук

Биз баарыбыз “Жылдын эң аялуу колдонмолору” же “Эң аялуу операциялык системалар” деген аталыштагы макалаларды көрдүк. Адатта, алар сыяктуу алсыздыктар жөнүндө жазуулардын жалпы саны боюнча статистиканы берет CVE (Жалпы аялуу жана тобокелдиктер), алынган Улуттук аялуу маалыматтар базасы (NVD) от булгоолорду жана башка булактар. Андан кийин, бул тиркемелер же ОС CVEлердин саны боюнча рейтингге ээ. Тилекке каршы, CVEs көйгөйлөргө көз салуу жана сатуучуларды жана колдонуучуларды маалымдоо үчүн абдан пайдалуу болгону менен, алар программалык камсыздоонун чыныгы коопсуздугу жөнүндө аз айтышат.

Мисал катары, Linux ядросу жана эң популярдуу беш сервер дистрибуциялары үчүн акыркы төрт жылдагы CVEлердин жалпы санын, тактап айтканда Ubuntu, Debian, Red Hat Enterprise Linux жана OpenSUSE карап көрөлү.

Сүрөт. 1

Бул график бизге эмнени айтып турат? CVEлердин көбүрөөк саны бир бөлүштүрүү экинчисине караганда аялуураак дегенди билдиреби? Жооп жок. Мисалы, бул макалада сиз, мисалы, OpenSUSE же RedHat Linux менен салыштырганда Debianдын коопсуздук механизмдери күчтүүрөөк экенин, бирок 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 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 Бш 15-ноябрь 17:36:42 UTC 2018

Ubuntu 14.04 (Ишенимдүү Тахр)
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 (Бионикалык Beaver)
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-таблицадагы жазууларды карай турган болсок, биз заманбап ядролор маалыматтын агып кетиши жана стек/үймөктүн ашып кетиши сыяктуу алсыздыктарды пайдалануудан коргоонун бир нече варианттарын камсыздай турганын көрөбүз. Бирок, эң акыркы популярдуу дистрибьюторлор дагы татаал коргоону ишке ашыра электигин байкайбыз (мисалы, тактар ​​менен grsecurity) же кодду кайра колдонуу чабуулдарынан заманбап коргоо (мис. код үчүн 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 бинардык (гетти алмаштыруу), ошондой эле mksh жана lksh кабыктарын, picolisp интерпретаторун, nvidia-cuda-toolkit пакеттерин (GPU тездетилген тиркемелер үчүн популярдуу пакет) байкайсыз. мисалы, машина үйрөнүү алкактары) жана klibc -utils. Ошо сыяктуу эле, mandos-client бинардык (шифрленген файл тутумдары бар машиналарды автоматтык түрдө кайра жүктөөгө мүмкүндүк берүүчү административдик курал), ошондой эле rsh-redone-client (rsh жана rloginдин реимплементи) NX коргоосу жок жөнөтүлөт, бирок алардын SUID укуктары бар: (. Ошондой эле, бир нече suid бинарийлер стек канареялары сыяктуу негизги коргоого ээ эмес (мисалы, Xorg пакетинен Xorg.wrap бинардык).

Корутунду жана корутунду сөздөр

Бул макалада биз заманбап Linux дистрибьюторлорунун бир нече коопсуздук өзгөчөлүктөрүн баса белгиледик. Анализ көрсөткөндөй, эң акыркы Ubuntu LTS дистрибутиви (18.04) орточо эсеп менен Ubuntu 14.04, 12.04 жана Debian 9 сыяктуу салыштырмалуу жаңы ядролору бар дистрибуциялардын арасында эң күчтүү OS жана тиркемелердин деңгээлин коргоону ишке ашырат. Бирок, изилденген дистрибьюторлор CentOS, RHEL жана OpenSUSE биздин топтомубузда демейки боюнча алар жыш пакеттер топтомун чыгарышат жана акыркы версияларында (CentOS жана RHEL) алар Debian негизиндеги атаандаштарга (Debian жана Ubuntu) салыштырмалуу стектердин кагылышуусунан коргоонун көбүрөөк пайызына ээ. CentOS жана RedHat версияларын салыштырып, биз 6дан 7ге чейинки версияларда стек канареяларды жана RELROну ишке ашырууда чоң жакшырууну байкайбыз, бирок орто эсеп менен CentOS RHELге караганда көбүрөөк функцияларга ээ. Жалпысынан, бардык бөлүштүрүүлөр PIE коргоосуна өзгөчө көңүл бурушу керек, ал Debian 9 жана Ubuntu 18.04 кошпогондо, биздин маалымат топтомубуздагы бинардык системалардын 10% дан азында ишке ашырылат.

Акырында, биз изилдөөнү кол менен жүргүзгөнүбүз менен, көптөгөн коопсуздук куралдары бар экенин белгилей кетүү керек (мис. Линис, жолборс, Хаббл), талдоо жүргүзөт жана кооптуу конфигурациялардан качууга жардам берет. Тилекке каршы, акылга сыярлык конфигурациялардагы күчтүү коргоо да эксплуатациялардын жоктугуна кепилдик бербейт. Ошондуктан биз аны камсыз кылуу өтө маанилүү экенине бекем ишенебиз реалдуу убакытта ишенимдүү мониторинг жана чабуулдардын алдын алуу, эксплуатациялоонун үлгүлөрүнө басым жасоо жана аларды болтурбоо.

Source: www.habr.com