Безпека Unix

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

Основною функцією безпеки в цих системах є дозволи файлової системи. Усі файли у типовій файловій системі Unix мають встановлені дозволи, що дозволяють різний доступ до файлу.

Дозволи на файл зазвичай встановлюються за допомогою команди chmod і переглядаються за допомогою команди ls. Наприклад:

-r-xr-xr-x 1 root wheel 745720 Sep 8 2002 /bin/sh

Дозволи Unix надають різним користувачам доступ до файлу. Різні групи користувачів мають різні дозволи на файл.

Більш розвинуті файлові системи Unix включають концепцію ACL (Access control list), яка дозволяє надавати дозволи кільком користувачам або групам. ACL може використовуватися для надання дозволу додатковим окремим користувачам або групам. Наприклад:

/pvr [u::rwx,g::r-x,o::r-x/u::rwx,u:sue:rwx,g::r-x,m::rwx,o::r-x]

У цьому прикладі, який отримано від команди chacl в операційній системі Linux, користувачу su надається дозвіл на запис до каталогу /pvr.

Користувачі операційних систем у стилі Unix часто належать до керованих груп із певними правами доступу. Це дає змогу групувати користувачів за рівнем доступу до цієї системи.

Більшість Unix і Unix-подібних систем мають обліковий запис або групу, що дозволяє користувачеві повністю контролювати систему, часто відому як кореневий обліковий запис. Якщо доступ до цього облікового запису отримує небажаний користувач, це призводить до повного порушення системи. Однак кореневий обліковий запис необхідний для адміністративних цілей, і з вищезазначених міркувань безпеки кореневий обліковий запис рідко використовується для повсякденних цілей (частіше використовується програма sudo), тому використання кореневого облікового запису можна більш уважно відстежувати.

Вибір надійного пароля та належний його захист — це, мабуть, найважливіші речі, які користувач може зробити для підвищення безпеки Unix. У системах Unix основна інформація про користувачів зберігається у файлі /etc/passwd. Цей файл відстежує користувачів, зареєстрованих у системі, та їхні основні визначення. Паролі, або правильніше, хеш пароля, також можуть зберігатися в тому ж місці. Записи в /etc/passwd займають рівно один рядок кожен і мають такий вигляд:

nickname:password_hash:UserID:GroupID:Complete_Name:home_dir:shell_bin

Оскільки всі користувачі повинні мати доступ для читання до файлу /etc/passwd, щоб виконувати багато поширених завдань, будь-хто також може прочитати хеші паролів інших користувачів. Щоб вирішити цю проблему, був створений файл /etc/shadow для зберігання хешів паролів, причому лише root мав доступ для читання. Під час відстеження пароля 2-е поле (хеш пароля) замінюється символом «x», який повідомляє системі, що потрібно отримати відповідний пароль користувача через файл /etc/shadow.

Решта полів у файлі /etc/shadow включають:

1. Мінімальна кількість днів між змінами пароля
2. Максимальна кількість днів до зміни пароля
3. Кількість днів від попередження до необхідності змінити пароль
4. Кількість днів за які пароль має бути зміненим, коли обліковий запис стає непридатним
5. Дата закінчення терміну дії облікового запису

Ці поля можна використовувати для підвищення безпеки Unix шляхом застосування політики безпеки паролів.

Адміністратори повинні негайно видаляти старі облікові записи.

Операційні системи, як і будь-яке програмне забезпечення, можуть містити помилки, які потребують виправлення, або можуть бути покращені за допомогою додавання нових функцій. Щоб виправити операційну систему безпечним способом, потрібно, щоб програмне забезпечення надходило з надійного джерела і не було змінено з моменту його упаковки. Загальні методи перевірки того, що виправлення операційної системи не були змінені, включають використання криптографічного хешу, такого як контрольна сума на основі MD5, або використання носіїв, призначених лише для читання.

З точки зору безпеки, специфічний метод пакування, такий як формат RPM Package Manager, походить від Red Hat Linux, не настільки важливий, як використання функцій, які забезпечують цілісність самого виправлення.

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

Дистрибутиви Linux, які використовують формат RPM Package Manager для забезпечення базової функціональності та оновлень програмного забезпечення, використовують MD5 і GPG для забезпечення цілісності вмісту. Хеш-значення упаковуються з файлом RPM і перевіряються, коли пакет інсталюється.

Дистрибутиви Linux, які використовують формат пакету Debian .deb для забезпечення базової функціональності та оновлень програмного забезпечення, використовують підписи GPG для забезпечення цілісності вмісту. Підпис обчислюється, коли пакунок створюється, і перевіряється пізніше, коли пакет буде встановлено.

Непотрібне системне програмне забезпечення не слід встановлювати або налаштовувати в системі. Програмне забезпечення, яке більше не потрібно, слід повністю видалити, якщо це можливо.

Визначте, які сервіси працюють

• netstat -na

• lsof

• nmap
• sockstat -4

Команди inetd і xinetd діють як суперсервери для різних мережевих протоколів, таких як rlogin, telnet і ftp.

Відключення непотрібних сервісів

• update-rc.d on Debian
• chkconfig on Red Hat Linux
• /etc/rc.conf and /usr/local/etc/rc.d on FreeBSD
• rc-update on Gentoo Linux

Такий підхід зазвичай називають проактивною безпекою. Існують деякі операційні системи, які за замовчуванням безпечні. Серед іншого, безкоштовні варіанти BSD (FreeBSD, NetBSD і OpenBSD) є проактивно безпечними. Наприклад, вихід netstat на робочій станції NetBSD 3.0 чітко описує цю техніку

$ netstat -a
Active Internet connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        State
tcp        0      0  localhost.smtp         *.*                    LISTEN
tcp        0      0  *.ssh                  *.*                    LISTEN
Active Internet6 connections (including servers)
Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
tcp6       0      0  localhost.smtp         *.*                    LISTEN
tcp6       0      0  *.ssh                  *.*                    LISTEN
Active UNIX domain sockets
Address  Type   Recv-Q Send-Q    Inode     Conn     Refs  Nextref Addr
c0d10d80 dgram       0      0        0 c0cd8680        0 c0cb7000 -> /var/run/log
c0cb7000 dgram       0      0        0 c0cd8680        0        0 -> /var/run/log
c0cd8680 dgram       0      0 cb9639e8        0 c0d10d80        0 /var/run/log

Наступний приклад із системи BSD

$ sockstat -4
USER     COMMAND    PID   FD PROTO  LOCAL ADDRESS         FOREIGN ADDRESS
root     sendmail   569    4 tcp    localhost.smtp        *.*
root     sshd       593    4 tcp    *.ssh                 *.*

Безпека файлової системи в UNIX і Unix-подібних системах базується на 9 бітах дозволу, встановлених бітах ідентифікатора користувача та групи, а також біті sticky, що становить загалом 12 біт. Ці дозволи застосовуються майже однаково до всіх об’єктів файлової системи, таких як файли, каталоги та пристрої.

9 бітів дозволу розділені на три групи по три біти в кожній. Перша група описує дозволи власника файлу, друга група описує дозволи GID, призначеного файлу, який за замовчуванням є групою, пов'язаною з власником файлу, або каталогом, що містить файл, коли він встановлений-GID, і третя група описує дозволи, пов'язані з будь-яким процесом, який не має того ж ідентифікатора користувача, що й файл. Кожна група з трьох бітів містить біт, який вказує на надання доступу для читання, запису або виконання. У випадку з каталогами доступ до виконання інтерпретується як дозвіл на виконання пошуку імені файлу в каталозі.

Встановлені біти ідентифікатора користувача та ідентифікатора групи, які зазвичай скорочуються відповідно до set-UID і set-GID, використовуються для зміни ідентичності процесу, який виконує файл, у якому встановлені один або обидва ці біти. Файл, у якому встановлений біт дозволу set-UID, призведе до того, що процес, який виконує цей файл, тимчасово змінить ефективний ідентифікатор користувача на ідентифікатор власника файлу. Файл, у якому встановлений біт дозволу set-GID, призведе до того, що процес, який виконує цей файл, тимчасово змінить ефективний ідентифікатор групи на ідентифікатор групи файлів. Потім процес може чергувати між ефективним ідентифікатором користувача чи групи, який він успадкував із файлу, і реальним ідентифікатором користувача чи групи, який він успадкував, коли користувач увійшов у систему. Це забезпечує механізм, за допомогою якого процес може обмежити права доступу, якими він володіє, до тих областей коду, які потребують цих прав доступу. Це форма техніки безпеки, відома як розділення привілеїв, яка покращує безпеку програми, обмежуючи ненавмисні або небажані дії процесів.

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

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

Root squash — це спеціальне відображення ідентифікації віддаленого суперкористувача (root) під час використання аутентифікації особи (локальний користувач — це те саме, що і віддалений користувач). Під root squash, uid клієнта 0 (root) зіставляється з 65534 (nobody). Це в першу чергу функція NFS, але може бути доступним і в інших системах.

Root squash — це техніка, яка дозволяє уникнути підвищення привілеїв на клієнтській машині за допомогою виконуваних файлів suid Setuid. Без root squash зловмисник може генерувати двійкові файли suid на сервері, які виконуються як root на іншому клієнті, навіть якщо користувач клієнта не має привілеїв суперкористувача. Таким чином, він захищає клієнтські машини від інших шкідливих клієнтів. Він не захищає клієнтів від шкідливого сервера (де root може генерувати двійкові файли suid), а також не захищає файли будь-якого користувача, крім root (оскільки зловмисні клієнти можуть видаватися за будь-якого користувача).

SELinux — це набір розширень ядра для більш точного контролю доступу, суворо визначаючи, чи і як файли, папки, мережеві порти та інші ресурси можуть бути доступні через обмежений процес. Ця система в основному використовується для обмеження процесів (база даних, сервер), а не людей. Це також може обмежити процеси, які запускаються як root. Інші дистрибутиви використовують аналогічні альтернативи, як-от AppArmor.

Unix-подібні операційні системи захищені від більшості вірусів Microsoft Windows, оскільки двійкові файли, створені для роботи в Windows, зазвичай не запускаються на інших платформах. Однак багато установок, подібних до Unix, надають послуги для зберігання файлів клієнтам Microsoft Windows, наприклад, за допомогою програмного забезпечення Samba, і можуть ненавмисно стати сховищем вірусів, які зберігаються користувачами. Зазвичай сервери Unix діють як агенти передачі пошти, і, як наслідок, часто встановлюється сканування електронної пошти на віруси. Вірусний сканер ClamAV доступний у формі вихідного коду і може використовуватися для перевірки файлових систем Unix на наявність вірусів, які заражають інші операційні системи.

Існують віруси та хробаки, які націлені на Unix-подібні операційні системи. Фактично, перший комп’ютерний хробак — хробак Моріса — був націлений на системи Unix.

iptables — це поточний інтерфейс користувача для взаємодії з функцією netfilter ядра Linux. Він замінив ipchains. Інші операційні системи, подібні Unix, можуть надавати власні функціональні можливості, а також існують інші продукти брандмауера з відкритим кодом. Більш детальна інформація про iptables міститься в іншому місці. Тут міститься коротке обговорення, щоб описати, як iptables можна використовувати для налаштування брандмауера Linux.

netfilter забезпечує повний пакетний фільтр, який можна налаштувати відповідно до мережевого інтерфейсу, протоколу, адреси джерела та/або призначення, порту джерела та/або призначення та стану пакету. Мережевий пакет проходить кілька ланцюжків між моментом його отримання мережевим інтерфейсом і часом, коли він приймається хостом або пересилається на інший хост. Поширені ланцюжки: INPUT, OUTPUT і FORWARD. Ланцюжок INPUT проходить для всіх пакетів, коли вони отримані мережевим інтерфейсом, незалежно від того, чи мають вони бути прийняті хостом чи переслані на інший хост. Ланцюжок OUTPUT проходить для всіх пакетів, оскільки вони передаються мережевим інтерфейсом. Ланцюжок FORWARD проходить через те, що пакети маршрутизуються через хост від одного мережевого інтерфейсу до іншого, як це має місце для багатодомної системи (системи з більш ніж одним фізичним мережевим інтерфейсом).

Кожен із вбудованих ланцюжків має політику за замовчуванням, яка визначає, які дії виконуються для пакета, який досягає кінця ланцюга. Обхід пакета закінчується, коли правило відповідає пакету і має дію ACCEPT, DROP, REJECT, RETURN

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

У наступному прикладі показано простий фільтр пакетів для ланцюга INPUT для описаного вище прикладу:

Chain INPUT (policy DROP 0 packets, 0 bytes)
 pkts bytes target     prot opt   in        out                 source               destination
    0     0 ACCEPT     all—any    any     anywhere             anywhere            state ESTABLISHED
    0     0 ACCEPT     tcp—any    any     anywhere             anywhere            tcp dpt:smtp
    0     0 LOG        all—any    any     anywhere             anywhere            LOG level warning
    0     0 DROP       all—any    any     anywhere             anywhere

Існує менше потреби в ланцюжку OUTPUT, а політику за замовчуванням для ланцюжка OUTPUT можна безпечно встановити на ACCEPT. У деяких випадках може бути бажано, щоб брандмауер обмежував певні вихідні з’єднання певним набором затверджених систем. Це відоме як вихідна фільтрація і може використовуватися для запобігання проникненню вірусів із брандмауера до інших систем. Наприклад, політикою мережі може бути обмеження вихідних з’єднань електронної пошти з одним авторизованим сервером електронної пошти як спосіб боротьби зі спамом електронної пошти. Цього можна досягти за допомогою такого прикладу: Chain OUTPUT (policy ACCEPT)

 pkts bytes target     prot opt    in     out                  source              destination
    0     0 DROP       tcp—any    any    !server               anywhere            tcp dpt:smtp

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

• The Unix Security Model for web server administration^{[dead link]} Robert K. Moniot 2000

• An Architectural Overview of UNIX Network Security Robert B. Reinhardt 1993

• Unix security papers

• Levi, Bozidar (2002). UNIX Administration: A Comprehensive Sourcebook for Effective Systems and Network Management. CRC Press. p. 207. ISBN 0-8493-1351-1.
• Tykhomyrov, Olexiy (1 January 2002). "Starting Share Files with NFS" [Архівовано 23 січня 2022 у Wayback Machine.]. Linux Journal. Archived from the original on 8 August 2019. Retrieved 9 August 2019.

• "/etc/exports documentation". CentOS Project. Archived from the original on 2007-05-29.