Керівництво з безпеки для Red Hat Enterprise Linux 5. Ревізія 4.1 Грудень 28, 2011 Агенція з Національної Безпеки ОША. Підрозділ ОС UNIX при Центрі Системного та Мережевого Аналізу. Агенція з Національної Безпеки Попередження! *Не намагайтеся використовувати будь-які вказівки з цого керівництва спершу не протестував їх на невиробничому обладнені. *Цей документ - лише керівництво, яке містить рекомендовані налаштування з безпеки. Отож, документ не призначено для заміни гарно структурованній або гарно спримаеться на слух. Також він не стосується конфігураціі конкретної ділянки проблеми. Необхідно дотримуватися обережності при використанні даного керівництва для локалізаціі проблем та іх вирішення. *Зміни внесенні в конфігурацію безпеки в цому документі лише використовуються по відношенні до Red Hat Enterprise Linux 5. Вони можуть бути не переносимі на операційні системи. *Інтернет-адреси, зазначені були дійсні станом на 1 грудня 2009 року. Інформація о торгових марках Red Hat - це зареєстрована торгова марка яка належить Red Hat, Inc. Будь-які інші торговельні марки, згадані в цьому документі, є власністю їх відповідних власників. Історія змін Ревізія 4.1 це оновлення версіі ревізії 4 датаованної 14 вересня 2010 року. *Додано секція 2.2.2.6, вимкнуті всі іконки в Гномі, наскільки це можливо. *Додано Common Configuration Enumeration (CCE) ідентифікатори пов'язаних розділів в керівництві, і примітка про ККТ в розділі 1.2.4, форматування конвенцій. *Оновлено розділ 2.3.3.2, встановити блокування для невдалих спроб введення пароля. Немає необхідності додавати модуль pam_tally2 в файл конфігурації PAM кожної програми, або коментувати якісь рядки з /etc/pam.d/system-auth. Модуль pam_tally2 тепер можна посилатися безпосередньо з /etc/pam.d/system-auth. *Виправлена секція 2.6.2.4.5, заголовок був - "Забезпечення збору auditd-ом подій входу і виходу з системи". Став - "Запис auditd-ом спроби змінити інформацію про подій входу і виходу з системи". *Виправлена секція 2.6.2.4.6 заголовок був - "Забезпечення збору auditd-ом інформаціі о процесах і ініцалізованої інформацій сесій." Став - "Запис auditd-ом спроби зміни інформації про процеси та ініциализаціі сесій". Примітка: Вищевказані зміни не впливають на будь-які з нумерації розділів. 1. Введення Метою даного посібника є надання рекомендацій конфігурації безпеки для Red Hat Enterprise Linux (RHEL) 5 операційної системи. Керівництво, представлене тут, повинно працювати відносно до всіх варіантів редакціі (кліентська станція, сервер, специальзована платформа) продукту. Рекомендуємі настройки передбачені для базової конфігураціі операційної системи, а також для багатьох часто використовуємих сервісів, які система може підтримувати в мережевому середовищі. Керівництво призначене для системних адміністраторів. Читачі, як передбачається, мають навички адміністрування для Unix-подібних систем, а також знайомі з документацією і адмініструванням Red Hat. Деякі інструкції в цьому керівництві, є складними. Всі дій повинні впроваджуватися повністю і з розуміння їх наслідків для того, щоб уникнути серйозних негативних наслідків для системи та її безпеки. 1.1 Загальні положення Наступні головні принципи спрямовані найбільше частина рекомендацій в цьому посібнику, а також повинні впливати на будь-яку конфігурацію рішення, які явно не охоплені. 1.1.1 Шифрувати передаваємі дані, усюди де це можливо. Дані, що передаються по мережі, будь вона дротова або бездротова, є вразливими до пасивного моніторингу. Коли практичні рішення для шифрування таких даних існують, то вони повинні бути застосовані. Навіть якщо дані, як очікується, будуть передаватися тільки через локальну мережу, вона всеодно повиннна бути зашифрованою. Шифрування аутентифікаційних даних, таких як паролі, має особливо важливе значення. Мережі з машин RHEL5 можуть і повинні бути налаштовані таким чином, щоб унеможливити будь-яку передачу незашифрованих даних аутентифікації між машинами. 1.1.2 Мінімізація кількості програмного забезпечення - мінімізації вразливостей. Найпростіший спосіб уникнути вразливостей в програмному забезпеченні, є уникнення установки програмного забезпечення. На RHEL, RPM Диспетчер пакетів (спочатку Red Hat Package Manager, скорочено RPM) дозволяє ретельно управляти набіром програмних пакетів, встановлених в системі. Встановлене програмне забезпечення сприяє уразливості системи деякими шляхами. Пакети, які включають в себе setuid-програми можуть надавати локальним зловмисникам потенційний шлях до підвищення привілеїв. Пакети, які включають в себе мережеві сервіси можуть надати цю можливість зловмисникам, які створюють мережеві атаки. Пакети, що містять в себі програми, які передбачувано виконуються локальними користувачами (таксамо, після графічного входу до системи) може забезпечити можливості для непомітного запуску для троянських коней або іншого атакуючего коду. Кількість програмних пакетів, встановлений в системі, майже завжди може бути значно скорочена, щоб мати в себе тільки програмне забезпечення, для якого існують оточенневі(Примітка перекладача: мається на увазі runtime-оточення, як JAVA, або .NET) або виробничі необхідності. 1.1.3 Крутити різниі мережеві служби на окремих системах. Кожен раз, як що це можливо, сервер повинен бути відведений під виконання лише однієї мережевої служби. Це зменшує кількість інших сервісів, які можуть бути скомпрометовані у тому випадку, якщо зловмисник може успішно проексплоітувати помилку у програмному забезпеченні однієї з мережевих служб. 1.1.4 Налаштування інструментов безпеки для поліпшення міцності системи. Існує кілька інструментів, які можуть бути ефективно використані для поліпшення спротиву системи і виявлення невідомих атак. Ці інструменти можуть поліпшити стійкість до атаки за рахунок порівняно невеликих зусиль з налаштування. На практиці, це керівництво рекомендує і обговорює використання Iptables як хост-орінтованого файрволу, SELinux для захису від вразливостей у сервісах, а також протоколювання та аудит інфраструктури для виявлення проблем. 1.1.5 Найменший рівень привілеїв Надати мінімальні привілеї, необхідні для облікових записів користувачів і програмного забезпечення для виконання завдань. Наприклад, не дозволяти користувачам, за винятком тих, які повинні мати доступ адміністратора, використовувати sudo. Іншим прикладом є обмеження входів до серверної системи тільки тих адміністраторів, які повинні виконувати адміністративні завдання. Використання SELinux також дотримується принципу найменших привілеїв: SELinux політика може обмежити програмне забезпечення для виконання тільки дії на системи, які спеціально дозволено. Це може бути набагато більш обмежені привілеї, ніж привілеї традиційної Unix моделі. 1.2 Як користуватися цією настановою. Читачі повинні врахувати наступні моменти при використанні цого документу. 1.2.1 Читати розділи повністю і в належному порядку. Кожна секція може ґрунтуватися на інформації і рекомендацях, розглянутих в попередніх розділах. Кожна секція повинна бути прочітана і повністю зрозуміла; інструкції ніколи не слід сліпо застосовувати. Відповідне обговорення відбуватиметься після того, як подається інструкція до дії. Конфігурування системного рівня в главі 2, повинно бути застосовано до всіх машини. Керівництво для окремих сервісів в главі 3 повинні розглядатися для всіх машин, а саме: застосовувати керівництво, ЯКЩО машина є або сервер або клієнт для цієї служби, і переконайтеся, що служба відключена відповідно до інструкцій, ЯКЩО машина не є ні сервер, ні клієнт. 1.2.2 Випробування в невиробничому середовищі. Це керівництво завжди має бути перевірено в невиробничому середовищі перед розгортанням. Це тестове середовище повинно, наскільки це можливо, імітувати налаштування тої система, в якій будуть розгорнуті настанови. 1.2.3 Про командну оболонку адміністратора. Більшість дій, перерахованих в цьому документі написано з припущенням, що вони будуть виконуватися root користувачем, який використовує /bin/bash командну оболонку. Команди, маючі з початку символ дієза (#) вказують, що адміністратор буде виконувати команди, як root, тобто застосувати команду через sudo кожен раз, коли це можливо, або використовувати su, щоб отримати root-привілеї, якщо sudo не може бути використаний. Командам, які можуть бути виконані не-root користувачем, передує знак долара ($) у запрошенні командної оболонки. 1.2.4 Домовленність о форматуванні. Для виділення команд, призначених для виконання в командній оболонці, а також тексту файлів конфігурації, використовується моно шрифт. Курсив використовується для позначення випадків, коли системний адміністратор повинен замінити відповідну інформацію в командному файлі або тексті конфігурації. Загальні перерахування настройки (CCE) ідентифікатори представлені в нижньому правому куті цих секцій для яких асоційований ідентифікатор існує. Більш детальну інформацію про CCE доступна на http://cce.mitre.org. 1.2.5 Необхідне перезавантаження. Перезавантаження системи неявно потрібно після деяких дій для завершення реконфігурації системи. У багатьох випадках ці зміни не набудуть чинності до тих пір, доки не перезавантажити систему. Для того, щоб гарантувати, що зміни правильному застосуванні і протестувати функціональность, завжди перезавантажуйте систему після застосування набору рекомендацій з цього керівництва. 2. Загальносистемна конфігурація. 2.1 Установка і підтримка програмного забезпечення. Наступні розділи містять інформацію про вибір безпеко-важливих опцій під час початкової інсталяціі операційної системи та установки оновлень програмного забезпечення. 2.1.1 Рекомендації по інсталяціі. Рекомендації, застосовані тут, приміняються до чистої системної інсталяція, в якій всі попередні установки вилучаються. Розділи, представлені тут в тому ж порядку, в якому программа інсталятор їх показує, але тільки варіанти з безпеко-важливими опціями будуть освітлені. Багато з варіантів конфігурації, представлені тут, також можуть бути застосовані після того, як система вже встановлена. Вибір опцій також може бути автоматично застосован за допомогою kickstart-файлів, як описано у [8]. 2.1.1.1 Дискові розділи. Деякі системні деректоріі повинні бути розташовані на своїх власних розділах (або логічних розділах). Це дозволяє підвищіти розділення та захист данних. Стандартна схема розміщення інсталятора створює окремі партиціі (або логічні розділи) для /, /boot та swap.