logo
1111

Аналіз захищеності сучасних універсальних ос. Особливості підсистеми захисту ос типу *nix.

Особливості архітектури Windows

Віруси, троянські коні та інші деструктивні програми вражають настільні комп’ютери з Windows внаслідок цілої низки причин, властивих Windows та не властивих Linux:

Windows лише недавно еволюціонувала від однокористувацької моделі до багатокористувацької

Система Windows з самого початку була розроблена, щоби забезпечити користувачам та програмам вільний доступ до усієї системи, а це означає, що кто завгодно міг скомпрометувати критичну системну програму або файл. Це також значить, що віруси та інші деструктивні програми могли зробити те ж саме, тому що Windows не ізолювала користувачів та застосування від критичних ділянок операційної системи.

Операційна система Windows XP стала першою версією Windows, де з’явилися суттєві результати спроб ізолювання користувачів від системи, так що кожен користувач має свої власні особисті файли та обмежені системні повноваження. Платою за це стало, що програмні застосування, розроблені для попередніх версій перестали працювати. Саме тому в Windows XP передбачено режим сумісності, тобто режим, який дозволяє програмам працювати так, ніби вони функціонують в однокористувацькому середовищі. Windows XP — це прогрес, однак і Windows XP не можна назвати дійсно багатокористувацькою системою.

Windows Server 2003 — це наступний крок до істинно багатокористувацької системи, але навіть у Windows Server 2003 не вдалося ліквідувати усі «дірки» в системі захисту. Саме тому в Windows Server 2003 довелося відключити використання «за замовчуванням» деяких функцій web-навігатора (наприклад, ActiveX, написання сценаріїв тощо). Якщо б Microsoft переписала ці функції для роботи в безпечному режимі у істинно багатокористувацькому середовищі, вони не створювали би таких серйозних загроз, перед якими беззахисна Windows.

Windows за своєю архітектурою є монолітною, а не модульною системою

Монолітна система — це система, де більшість функцій інтегровано в єдиний модуль. Протилежністю такої системи є така, де функції розподілено по кількох рівнях, причому кожен рівень має обмежений доступ до інших рівнях.

Хоча частина недоліків Windows — "спадщина" її вихідної однокористувацької архітектури, інші її недоліки — наслідки проектних рішень, таких, як монолітна архітектура (інтегрування більшості функцій в ядро системи). Це також склалося історично. Весь час свого існування компанія Майкрософт вела боротьбу за монопольне становище на ринку. Наслідком такої боротьби було, наприклад, таке тісне інтегрування Internet Explorer’a в ядро системи, що відділити їх стало практично неможливим. Подобається це користувачеві, чи ні, але Internet Explorer викликається при використанні довідкової системи Windows, Outlook та інших застосувань, як Microsoft, так і незалежних виробників. Microsoft з успіхом перетворює конкуруючі продукти в непотрібні, інтегруючи в свою операційну систему все більше й більше сервісів, що надаються такими продуктами. Але в результаті такого підходу отримує «монстра» з складним чином взаємодіючими сервісами.

Взаємозалежності такого типу мають два поганих каскадних побічних ефекти. По-перше, в монолітній системі кожна «дірка» в одній частині системи впливає на усі сервіси та застосуваннях, які залежать від цієї частини системи. Інтегрувавши Internet Explorer в операційну систему, Microsoft створила систему, де будь-яка «дірка» в Internet Explorer створює загрози для настільного комп’ютера з Windows, реалізація яких може вплинути не лише на роботу web-навігатора, але й досить далеких від нього об’єктів, що використовують Internet Explorer неявно для користувача, що дає цьому користувачеві хибне почуття безпеки.

Така архітектурна модель впливає набагато глибше, ніж уявляють. Так, в монолітній системі вразливості в захисті виявляються критичнішими, ніж можна було чекати.

Проілюструвати це зможе проста аналогія. Уявимо собі ідеальну ОС, яка складається з трьох сфер: одна в центрі; друга, більшого діаметру, охоплює першу; а третя сфера охоплює дві перших. Користувач бачить лише третю сферу. Це рівень, де він запускає застосування, наприклад, текстові процесори. Вони використовують необхідні функції, що надаються другою сферою, наприклад, засоби візуалізації графічних зображень або форматування текстів. Ця друга сфера (спеціалісти називають її «користувацькими процесами») не має прямого доступу до критичних частин системи. Щоби виконати свою роботу, вона має спитати дозволу внутрішньої сфери. Внутрішня сфера виконує найважливіші функції, тому, що має безпосередній доступ до усіх критичних частин системи. Вона керує пам’яттю, дисками та рештою важливих частин системи. Ця сфера називається «ядром» і є серцем ОС.

У такій архітектурі «дірка» у програмі графічного відображення не може нанести глобального збитку комп’ютеру, оскільки функції візуалізації не мають прямого доступу до найкритичніших частин системи. Навіть якщо користувач завантажить у текстовий процесор зображення з втіленим вірусом, цей вірус не зможе пошкодити нічого окрім власних файлів користувача, оскільки функція графічного відображення не має доступу до жодної критичної частини системи.

Проблема Windows полягає в тому, що в ній не дотримуються розумних конструкторських принципів розділення функцій по відповідних рівнях, описаних вище. Windows вкладає занадто багато функцій у ядро, центральну сферу, де можна заподіяти найбільшого збитку. Наприклад, якщо інтегрувати графічні функції в ядро, ці функції зможуть нашкодити усій системі. Таким чином, як тільки виявиться «дірка» в алгоритмі графічного відображення, надмірно інтегрована архітектура Windows полегшить використання цієї «дірки» для отримання повного контролю над системою, для руйнування всієї системи.

Нарешті, монолітна система нестабільна за самою своєю природою. Коли в системі так багато взаємозв’язків, зміна однієї з її частин породжує багато загроз. Одна зміна в системі може вплинути (і таки впливає) на усі сервіси та застосування, які залежать від цієї частини системи. Саме тому оновлення, які виправляють одну частину Windows, часто порушують роботу інших сервісів та застосувань. Для прикладу можу навести такий факт: для пакета оновлень Windows XP service pack 2 було створено постійно оновлюваний список випадків, коли його встановлення призвело до виходу з ладу програм сторонніх виробників. Таке явище в монолітній системі звичайна справа.

В Windows занадто широко використовується RPC-механізм

Абревіатура RPC означає «віддалений виклик процедур» (Remote Procedure Call). RPC — це те, що відбувається, коли одна програма відправляє через мережу вказівку іншій програмі виконати якусь дію. Віддаленим викликом процедури цей механізм називається тому, що не має значення, функціонують ці програми на тому же комп’ютері, чи десь в Інтернеті.

RPC-механізми — це потенціальна загроза безпеці, оскільки їх призначення - дозволити комп’ютерам, які знаходяться десь у мережі, віддавати даному комп’ютеру вказівки виконати ті, чи інші дії. Як тільки виявляється пролом в програмі, яка дозволяє використання RPC-механізму, у всякого, хто має підключений до мережі комп’ютер, з’являється можливість використати його, щоби змусити вражений комп’ютер виконати якісь дії. На жаль, користувачі Windows не можуть заблокувати RPC-механізм, оскільки Windows використовує його, навіть якщо комп’ютер не підключений до мережі. Дивно, але деякі з найбільш серйозних вразливостей у Windows Server 2003 — наслідок «дірок» у самих RPC-функціях Windows, а не в застосуваннях, що їх використовують.

Важливо відмітити, що RPC-механізми не завжди необхідні, і не зрозуміло, чому Microsoft так широко їх використовує.

Щодо знайомого інтерфейсу, який Майкрософт пропагує як причину для переходу на новий сервер Windows Server 2003, то, мабуть, вона пропонує працювати на цьому самому комп’ютері, зареєструвавшись як адміністратор. Краще та безпечніше було б, якби Майкрософт зробила все можливе для зручного віддаленого керування, що частіше усього й роблять адміністратори.

Архітектура Linux

По даним статистичних опитувань Evans Data Linux Developers Survey, 92% респондентів ніколи не зіштовхувалися з випадками зараження ОС Linux вірусами, троянськими та іншими деструктивними програмами.

Той факт, що віруси, троянські та інші деструктивні програми дуже рідко можуть (якщо взагалі можуть) заразити Linux-системи, частково можна пояснити такими причинами:

  1. Linux має довгу історію використання ретельно проробленої багатокористувацької архітектури.

  2. За своєю архітектурою Linux є, в основному, модульною системою.

  3. Функціонування Linux не залежить від RPC-механізму, а сервіси звичайно за замовчуванням налаштовані не використовувати RPC-механізми.

  4. Сервери Linux ідеально підходять для віддаленого адміністрування.

Linux має довгу історію використання ретельно проробленої багатокористувацької архітектури

Linux ніколи не був однокористувацькою системою. Тому у ній з самого початку закладено принцип ізолювання користувачів від застосувань, файлів та каталогів, що впливають на ОС в цілому. Кожному користувачу надається користувацький каталог, де зберігаються усі його файли даних, конфігураційні файли, що належать цьому користувачу. Коли користувач запускає якесь застосування (наприклад, текстовий процесор), воно запускається з обмеженими повноваженнями. Це застосування має право на запис лише у власний каталог цього користувача. Воно не може нічого записати у системні файли, навіть в каталог іншого користувача, якщо тільки адміністратор явним чином не надасть цьому користувачеві таке право.

Ще важливіше, що Linux надає практично усі функціональні можливості (наприклад, візуалізацію зображень JPEG) у вигляді модульних бібліотек. Тому, коли текстовий процесор відображає JPEG-зображення, відповідні функції запускаються з тими ж обмеженими повноваженнями, що й сам текстовий процесор. Якщо в програмах візуалізації JPEG-зображень є «дірка», зловмисник зможе використати її тільки для отримання таких самих повноважень, як у цього користувача, що значно обмежує масштаби можливих збитків. В цьому переваги модульних систем, вони ближчі до ідеалу ОС, описаному вище.

Навіть сервіси, наприклад, web-сервери, звичайно запускаються як користувачі з обмеженими повноваженнями. Так, Debian GNU/Linux запускає web-сервер Apache як користувача "www-data", що належить до такої самої групи. Якщо зловмисник на комп’ютері з Debian отримає повний контроль над web-сервером Apache, він зможе впливати лише на файли, які належать користувачу "www-data", тобто на web-сторінки. В свою чергу, MySQL, запускається з повноваженнями користувача "mysql". Навіть, якщо Apache та MySQL разом обслуговують web-сторінки, зловмисник, отримавши контроль над Apache, не буде мати повноважень, які дозволяють використати вразливість Apache для отримання контролю над сервером БД, тому що сервер БД «належить» іншому користувачу. Крім того, такі облікові записи конфігуруються без можливості доступу до командного рядка, а отже не зможуть подати довільну команду серверу Linux.

За своєю архітектурою Linux є модульною, а не монолітною системою

Linux — це ОС, сконструйована, в основному, за модульним принципом, від ядра до застосувань. В Linux практично немає нероздільних зв’язків між компонентами. Немає й єдиного web-навігатора, який використовується системою або програмами електронної пошти. Отже, «дірка» у web-навігаторі необов’язково небезпечна для інших застосувань.

Ядро Linux підтримує модульні драйвери, але в значній мірі є монолітним ядром, тому що сервіси в цьому ядрі взаємозалежні. Усі негативні наслідки монолітності мінімізуються тим, що ядро Linux, наскільки це можливо, розроблено як найменша частина системи. Розробники Linux фанатично притримуються такого принципу: "Якщо задача може бути вирішена за межами ядра, вона має бути виконана поза ним". Це значить, що в Linux майже кожна корисна функція ("корисна" значить "для кінцевого користувача") не має доступу до вразливих частин Linux.

Сервери Linux ідеально підходять для віддаленого адміністрування

Сервер Linux можна, а часто і треба, інсталювати без монітора та адмініструвати віддалено, оскільки при такому стилі адміністрування він не піддається таким загрозам як при локальному адмініструванні.

Можливо, це одна з найголовніших відмінностей Linux від Windows, тому, що цей фактор зводить нанівець багато критичних вразливостей, загальних для Linux та Windows, наприклад, вразливості web-навігаторів Mozilla та Internet Explorer.

Забезпечення безпеки в Linux

Якщо коротко, то структурна схема системи безпеки Linux має такий вигляд у взаємодії з іншими підсистемами (SELinux, рис.1).

Рисунок 1.

Як бачимо, система, завдяки модульній структурі, дозволяє змінювати модулі безпеки та утиліти політик безпеки, що притаманне усім версіям Linux. Вони зосереджені, більшою частиною, окремо від мікроядра, що позитивно впливає на безпеку системи в цілому, а також на можливість вдосконалення цієї системи без втручання в роботу ядра. ОС SELinux є на сьогодні однією з найбільш захищених середовищ, але, безумовно, не єдиною.

AppArmor

AppArmor є альтернативою SELinux, причому в ньому також використовується інфраструктура модуля LSM (Linux Security Module). Причиною створення AppArmor стало те, що SELinux виявився надто складним для пересічного користувача. AppArmor має повністю налаштовувані модулі безпеки та режим навчання, який допомагає налаштувати систему безпеки. Ще однією перевагою AppArmor є те, що вона не залежить від типу файлової системи, тоді як SELinux вимагає підтримки ФС додаткових атрибутів.

Solaris 10 (Trusted Solaris)

ОС Solaris 10 забезпечує мандатне керування доступом, що значно покращує систему захисту. Суттєвою перевагою є те, що завдяки цьому керуванню обмежуються повноваження користувача root, наявність якого було завжди основним недоліком Linux.

Розглянемо основні принципи організації доступу в Linux

UID-ідентифікатор користувача.

GID- ідентифікатор групи.

а) Аутентифікація (2 утиліти)

getty: “login”

login: “password” - виконує аутентифікацію

В перших версіях хешування виконується алгоритмом DES ключем до якого служив логін, в останніх версіях перейшли на MD5. Обл. записи зберігаються в папці /etc/passwd/ Структура:

Імя користувача: хеш_пароля:sid:gid:дод._інф.:home_dir:shell

Приклади:

ivanov:1QRxtta36BD:340:120:Іванов І.І.:/home/Ivanov:/bin/bash

root::1i DYwrOmhmEBU: 0:0: root:: /root: /bin/bash

або:

ivanov:х:340:120:Іванов І.І.:/home/Ivanov:/bin/bash

root:х: 0:0: root: /root: /bin/bash

Символи «х» на місці пароля означають, що у системі застосований більш сучасний метод зберігання паролів: вони зберігаються у файлі тіньових паролів (/etc/shadow). Власником файлу /etc/shadow є користувач root і тільки він має право читати інформацію з нього.

Формат записів у цьому файлі має такий вигляд:

root:1iDYwrOmhmEBU:10792:0:: 7:7::

bin:*:10547:0::7:7::

daemon:*:10547:0::7:7::

adm:*:10547:0::7:7::

lp:*:10547:0::7:7::

sync:*:10547:0::7:7::

shutdown:U:10811:0:-1:7:7:-1:134531940

Призначення першого поля файлу shadow таке ж, як і у першого поля файлу passwd.

Друге поле містить хеш пароля. Реалізація тіньових паролів дозволяє довжину паролів від 13 до 24 символів. Символи, які використовуються у паролях, беруться з набора з 52 літер алфавіту, цифр та (/). Разом виходить 64 символи.

З третього поля починається інформація про застарівання паролю. Це - кількість днів з 1 січня 1970 року до дня зміни цього пароля.

Четверте поле вказує на кількість днів, яка повинна пройти, перш ніж можна буде змінювати пароль. Поки з дня останньої зміни пароля не пройде стільки днів, скільки вказано у цьому полі, знову змінювати пароль не можна.

П’яте поле задає максимальну кількість днів, на протязі яких можна використовувати пароль, після чого він має бути зміненим. Якщо тут стоїть додатна величина, то при спробі користувача зайти до системи після цього терміну призведе до того, що команду password буде запущено у режимі обов’язкової зміни пароля.

Значення з шостого поля визначає, за скільки днів до закінчення терміну дії пароля слід попереджати користувача про це.

Сьоме поле задає число днів, починаючи з дня обов’язкової зміни пароля, коли цей обліковий запис блокується. Іншими словами, якщо після цієї кількості днів користувач не зайде до системи і не змінить свій пароль, то його обліковий запис буде заблоковано. У передостанньому полі вказано дату блокування облікового запису. Останнє поле зарезервовано і поки що не використовується.

Файл /etc/groups

Структура цього файлу подібна до файлу паролів. Приклад:

root::0:

wheel::10:

bin::1:bin,daemon

daemon::2:bin,daemon sys::3:bin,adm

adm::4:adm,daemon

Перше поле - ідентифікатор групи. Він повинен бути унікальним.

Друге поле - пароль. Як правило, паролі для груп не використовуються, отже це поле практично завжди порожнє. Однак можна увести паролі і для групи.

Третє поле - ідентифікатор групи, gid. Він також має бути унікальним, хоча це і необов’язково.

Четверте поле - список користувачів, що входять до цієї групи. Імена користувачів пишуться через кому без пробілів.

Приватні групи

Кожен користувач має створену за замовчуванням групу, яка створюється при реєструванні користувача, так звану групу входу. Ім’я цієї групи співпадає з іменем користувача. Якщо користувач або адміністратор не вкаже інакше, система призначає цю групу групою-власником усіх його файлів. Це дозволяє автоматично обмежити доступ інших користувачів до його інформації, оскільки вони належать до інших груп користувачів.

Файли та права доступу.

Linux підтримує багато файлових систем. Однак основними є ФС типу extX (ext2,3,4). Дві останні - журнальні ФС, які дозволяють відновлювати втрачену інформацію, до певної межі, звісно.

В останніх версіях Linux використовується ext4. Особливості цих ФС полягають в тому, що файли, каталоги та пристрої вважаються файлами. Кожному пристрою відповідає свій файл. Файли та пристрої для використання треба задіяти операцією монтування. Точка монтування визначається при поданні команди. Точка монтування може бути довільною. Керує цим ядро системи. Коли хтось хоче отримати доступ до пристрою, ядро визначає, чи має він відповідні права. При цьому виконується аналіз ідентифікатора користувача, ідентифікатори усіх груп, до яких він належить. На основі цього аналізу і виноситься рішення про надання доступу.

Linux підтримує багато різних типів файлів. Для прикладу, якщо ви подасте команду ls -la для певного каталогу, отримаєте таку відповідь:

drwxr-xr-x 24 root root 2048 Sep 4 00:01 .

drwxr-xr-x 20 root root 1024 Aug 26 19:09 ..

drwxr-xr-x 3 root root 1024 Jul 22 22:17 .civctp

crw-rw-r-- 1 root root 29,0 Aug 5 09:12 fbO

brw-rw-rw- 1 root root 2,0 Jul 27 19:14 fdO

-rw-r--r-- 1 root root 694 Sep 2 21:02 foo

srwxrwxrwx 1 root root 0 Sep 3 19:18 mysql.sock

prw------- 1 root root 0 Sep 3 19:14 initctl

lrwxrwxrwx 1 root root 4 Aug 5 08:49 sh -> bash

Лівий стовпчик вказує на тип файлу: d - directory (каталог); с - символьний пристрій (аналог СОМ-порта в Windows); b - блоковий пристрій (жорсткий диск 0 - перший жорсткий диск системи); s - сокет; р - іменований канал; l - символьне посилання; «-» -простий файл.

Наступні літери (до числа) - дозволи для цього файлу. Число - кількість жорстких посилань на файл;

Наступні два стовпчика - ім’я власника файлу та назва його групи. Далі - розмір файла; дату та час його створення.

В останньому стовпчику - повна назва файлу.

Якщо подати команду ls -I, то ми отримаємо щось таке:

20512 -rwxr-xr-x 3 root root 49280 Jul 27 19:37 gunzip

20512 -rwxr-xr-x 3 root root 49280 Jul 27 19:37 gzip

20512 -rwxr-xr-x 3 root root 49280 Jul 27 19:37 zcat

Як бачимо, зліва з’явилося число, яке вказує номер індексного дескриптора файлу, в якому записано усю важливу інформацію про файл, в тому числі (в останніх версіях) підтримуються списки контролю доступу, чого раніше в Linux не було. Списки контролю доступу розширюють можливість тріад доступу. Їх використовують, коли деяким користувачам треба надати доступ до файлу без зміни групових налаштувань.

Раніше в Linux підтримувався контроль доступу на рівні тріад.

Як бачимо вище, після індексного дескриптора йде мітка звичайного файлу, потім тріади дозволів: 1-а тріада - дозволи для власника файлу; друга - для його групи; третя - для усіх решти. Значення “r” - дозвіл на читання;”w” - на запис; “x” - на виконання; «-» - дозволу на цю операцію немає.

Дозволи для каталогів трактуються інакше, ніж для файлів: дозвіл на читання -

дозволяється продивлятися вміст каталогу, тобто отримати список файлів, що містяться у цьому каталозі, однак самі файли можуть бути недоступними для читання; дозвіл на запис для каталогу значить, що туди можна записувати файли або створювати нові, однак зміна існуючих файлів може виявитися недоступною; наявність права на виконання дозволяє зайти в цей каталог за допомогою команди cd. Можна читати список файлів з каталогу або записувати туди нові файли, але зайти в нього без дозволу на виконання не можна.

Для прикладу наведемо дозволи для каталогу incoming для ftp-сервера:

drwx-wx-wx 2 root ftp 1024 Jul 8 12:47 incoming

При таких правах усі можуть записувати в цей каталог свої файли, однак видно їх буде лише власнику - root.