Керівництво з безпеки для 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". *Якщо починати інсталяцію системи з будь-якого з макетів за замовчуванням, встановіть галочку "Review and modify partitioning." Це дозволяє легко створювати додаткові логічниі томи всередині вже створеної групи томів, в наслідок чого зменшиться розмір логічного тому відведенного під "/". Взагалі, рекомендується використовувати логічні розділи, ніж звичайні розділи, тому що вони можуть бути більш легко відредактовані пізніше. * При створенні розділів користувачєм, потрібно створити розділи, згадані в попередньому абзаці (які програма установки зажадає в будь-якому випадку), а також окремі з них, описані в наступних розділах. Якщо система вже встановлена, і була використана схема поділу за замовчуванням, це можливо змінити, але не є тривіальним завданням, щоб створювати окремі логічні томи для зазначених вище каталогів. Менеджер логічних томів(LVM) робить це можливим. Дивіться LVM HOWTO на http://tldp.org/HOWTO/LVM-HOWTO/ для більш докладної інформаціі про LVM. 2.1.1.1.1 Створення окремого розділу або логічного тому для "/tmp". Каталог "/tmp" є загально-доступним каталогом, який використовується для зберігання тимчасових файлів. Переконайтеся в тому, що він має свій власний розділ або логічний том. CCE 14161-4 Оскільки програмне забезпечення може знадобитися використовувати "/tmp" для тимчасового зберігання великих файлів, переконайтеся, що він має достатній розмір. Для сучасної система загального призначення, 10GB повинно бути достатньо. Менші або більші розміри можуть бути використані, в залежності від наявність місця на диску і експлуатаційних вимог системи. 2.1.1.1.2 Створення окремого розділу або логічного тому для "/var". Каталог "/var" використовується демонами і іншими системними службами для зберігання часто змінюємих даних. Доволі рідкісним для каталогу "/var" містити загально-доступні каталоги, встановлені іншими програмними пакетами. Переконайтеся в тому, що "/var" має свій власний розділ або логічний том. CCE 14777-7 Оскільки менеджер пакетів "yum" і інше програмне забезпечення використовує "/var" для тимчасового зберігання великих файлів, переконайтеся, що він відповідного розміру. Для сучасної системи загального призначення, 10GB повинно бути достатньо. 2.1.1.1.3 Створення окремого розділу або логічного тому для "/var/log". Системні журнали зберігаються в каталогу "/var/log". Переконайтеся в тому, що він має свій власний розділ або логічний том. Переконайтеся, що він досить великий, щоб зберігати всі журнали, які будуть записані там. CCE 14011-1 Дивіться розділ 2.6 для отримання додаткової інформації з приводу використання журналу і аудиту. 2.1.1.1.4 Створення окремого розділу або логічного тому для "/var/log/audit". Журнали аудиту зберігаються в каталогу "/var/log/audit". Переконайтеся в тому, що він має свій власний розділ або логічний том. Переконайтеся, що він досить великий, щоб зберігати всі журнали аудиту, які будуть створені за допомогою демону аудита. CCE 14171-3 Дивись секцію 2.6.2.2 для обговорення питання про ухвалення рішення про відповідний розмір для розділу. 2.1.1.1.5 Створення окремого розділу або логічного тому для "/home", якщо будуть використовуватися локальні домашні папки. Якщо домашні каталоги користувачів будуть зберігатися локально, створити окремий розділ для "/home". Якщо "/home" буде встановлений з іншої системи, такої як сервер NFS, то створити окремий розділ не потрібно в цому випадку, також точка монтування "/home" може бути налаштований пізніше. CCE 14559-9 2.1.1.2 Налаштування завантажувача. Встановіть галочку "Use a boot loader password" і створить пароль. Після того, як цей пароль встановлено, будь хто, якщо забажае змінити конфігурацію завантажувача, буде повинен ввести пароль. Більш детальна інформація доступна в розділі 2.3.5.2. Встановлення пароля на завантажувач перешкоджає локальному користувачеві з фізичним доступом до сервера змінити конфігурацію завантажувача при запуску системи. 2.1.1.3 Мережеві пристрої. За замовчуванням конфігурація мережевого пристрою використовує DHCP, що не рекомендується. Якщо використання DHCP не є вкрай необхідним, натисніть кнопку "Edit" і : * Зніміть галочку "Use Dynamic IP configuration (DHCP)." * Зніміть галочку "Enable IPv4 Support", якщо система не потребує IPv4. (Це рідкість.) * Зніміть галочку "Enable IPv6 Support", якщо система не потребує IPv6. * Введіть відповідні адреси IPv4 і IPv6 та префікси якщо потрібно. З відключенням DHCP ім'я хоста, шлюз та DNS-сервери повинні бути призначені на головній вкладці. Розділи 3.9.1 та 3.9.2 містять більш детальну інформацію про конфігурацію мережі і використання DHCP. 2.1.1.4 Пароль Root-а. Безпека всієї системи залежить від складності пароля root користувача. Пароль повинен бути не меньше 12 символів, і повинен включати в себе поєднання великих та малих літер, спеціальних символів, і цифер. Він також не повинен бути заснований на будь-якому словниковому слові. 2.1.1.5 Програмні пакети. Вимкніть всі групи пакетів, включаючи групи пакетів "Software Development" та "Web Server", доки нема конкретних вимог для встановлення програмного забезпечення за допомогою системного інсталятора. Якщо машина буде використовуватися в якості веб сервера, бажано, встановити необхідні RPM-пакети вручну, замість встановлення повної групи пакетів "Web Server". Дивіться розділ 3.16 для установки і детальної конфігурації. Використовуйте опцію "Customize now" щоб вимкнути групи пакетів в максимально можливій мірі. Це надасть двух-колонковий перегляд пакетів: перегляд категорій і груп пакетів. При необхідності, зніміть галочку з "X Window System," в категоріі "Base System", щоб уникнути встановлення "X" серверу цілком. Будь-які інші групи пакетів, які не портрібні для роботи системи - також повинні бути вимкнені. Більше малих пакетів можна вибрати за допомогою Kickstart, як описано в роботі [8]. 2.1.1.6 Конфігурація першого завантаження. Система дає більше опцій конфігурації при першому завантаженні після установки. Для перерахованих опцій, виконуємо рекомендації, пов'язані з безпекою: Опція Рекомендація Firewall Залиште вибір "Enabled". Тільки встановіть галочку "Trusted Services", сервіси які система повинна крутити. Скасуйте вибір "SSH" за замовчуванням, якщо система не буде використовувати SSH. SELinux Залиште SELinux встановлений в режим "Enforcing". Kdump Залиште Kdump вимкнений, якщо функція не потрібна, наприклад, для розробки ядра і тестування. Set Up Software Updates Якщо система вже підключена до мережі Інтернет - клікніть “Yes, I’d like to register now.” Цє потребує підключення до серверів Red Hat Network або їх довірених осіб або партнерів. Це також може бути налаштоване, як описано пізніше в розділі 2.1.2.1. Create User Якщо система потребує локального користувача - він може бути створений тут. Навіть якщо система буде використовувати загальну систему мережівої аутентифікації, як описано в розділі 2.3.6, не натискайте на кнопку "Use Network Login ...". Рекомендується ручне застосування конфігурації пізніше. 2.1.2 Оновлення програмного забезпечення. Інструмент командної строки "yum" - використовується для встановлення та оновлення пакетів програмного забезпечення. "yum" замінює утиліти "up2date" використовуваний у попередніх версіях системи. Крім того, система надає два графічних менеджерів пакетів "pirut" та "pup". "pirut" - інструмент являє собою графічний інтерфейс для "yum", що дозволяє користувачам встановлювати пакети і оновленя, в той час як "pup" - це простий засіб оновлення для пакетів, які вже встановлені. У меню "Applications" "pirut" позначен як "Add/Remove Software", а "pup" позначен "Software Updater". Рекомендується, щоб ці інструменти використовувалися для підтримки системи в актуальному стані з останніми оновленнями безпеки. 2.1.2.1 Налаштування підключення до RPM RHN репозиторіїв. Першим кроком в налаштуванні системи для оновлень є реєстрація у Red Hat Network (RHN). Для більшості системи, це робиться під час початкової установки. Успішно зареєстровані системи будуть з'являтися на RHN веб-сайті. Якщо система не вказана на сайті, запустіть інструмент реєстрації Red Hat Network, який можна знайти в меню "Applications" під "System Tools", або через командну строку: # rhn register Дотримуйтесь інструкцій на екрані. У разі успіху, система з'явиться на веб-сайті RHN і буде підписана на один або декілька каналів оновлення програмного забезпечення. Крім того, новий демон, "rhnsd", буде ввімкнен. Якщо система не матиме доступу до Інтернету, вона не матиме можливості безпосередньо підписатися на репозиторій оновлення RHN. Оновлення повинні бути бути завантажені з веб-сайту RHN вручну. Інструмент командної строки "yum", графічний фронтенд "pirut" і "pup" можуть бути налаштовані щоб впоратися з цією ситуацією. 2.1.2.1.1 Забезпечення встановлення GPG ключу Red Hat. Щоб переконатися, що система може криптографически перевіряти пакети оновлень (а також підключатися до Red Hat Network, щоб отримати їх за бажанням), виконайте наступну команду, щоб переконатися, що система має правильно встановлений ключ GPG Red Hat: $ rpm -q --queryformat "%{SUMMARY}\n" gpg-pubkey Команда повинна повернути строку: gpg(Red Hat, Inc. (release key ) CCE 14440-2 Щоб переконатися в тому, що сам ключ Red Hat GPG ні підроблений, його відбиток можна буте порівняти з один з веб-сайту Red Hat за адресою http://www.redhat.com/security/team/key. Наступна команда може бути використана для друку відбитків встановленого реліз ключа, який насправді міститься в файлі, який вказан наприкінці команди: $ gpg --quiet --with-fingerprint /etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release Більш детальну інформацію про підписання пакетів можно знайти на https://fedoraproject.org/keys. 2.1.2.2 Відключення демону "rhnsd". "rhnsd" демон опитує веб-сайт Red Hat Network для запланованих дій. Якщо насправді непотрібно планувати оновлення віддалено через веб-сайт RHN, рекомендується, що сервіс був вимкнений. # chkconfig rhnsd off CCE 3416-5 "rhnsd" демон вімкнен за замовчуванням, але доки система не була зареєстрована в Hat Network Red, він не буде працювати. Однак, як тільки процес реєстрації завершиться, "rhnsd" демон буде працювати у фоновому режимі і періодично викликати утиліту "rhn_check". Утиліта "rhn_check" обмінюється даними з Red Hat Network веб-сайтом. Ця утиліта не потрібна для системи, щоб мати можливість доступу та встановлювати оновлення системи. Після того, як система була зареєстрована, або використан наданий сервіс "yum-updatesd" або створити "cron" завдання для автоматичного застосування оновлення. 2.1.2.3 Отримання пакета оновлення програмного забезпечення за допомогою "yum". Утиліту оновлення "yum" можна запустити вручну з командної строки, викликати через одну з наданих графічних утиліт, або налаштувати на автоматичний запуск через задані проміжки часу. 2.1.2.3.1 Ручна перевірка наявності оновлень пакета. Наступна команда виводить список пакетів, які повинні бути оновлені: # yum check-update Для того, щоб встановити ці оновлення, виконайте наступну команду: # yum update 2.1.2.3.2 Налаштування автоматичного отримання оновлень і установка їх за допомогою "cron". Служба yum-updatesd не є достатньо зрілою для корпоративного середовища, вона може додати непотрібні накладні витрати. Коли це можливо, замініть цю службу завданням для "cron", яке викликає "yum" безпосередньо. Відключення служби yum-updatesd: # chkconfig yum-updatesd off Створіть файл yum.cron, зробіть його виконуваним, і помістити його в /etc/cron.daily: #!/bin/sh /usr/bin/yum -R 120 -e 0 -d 0 -y update yum /usr/bin/yum -R 10 -e 0 -d 0 -y update CCE 4218-4 Цей конкретний сценарій наказує "yum", щоб оновити всі пакети, які знаходить. Розміщення сценарію в "/etc/cron.daily" забезпечує його щоденний запуск. Щоб застосувати тільки оновлення один раз в тиждень, помістіть скрипт в "/etc/cron.weekly". 2.1.2.3.3 Забезпечення Пакет Підпис Перевірка глобально Активоване Опція gpgcheck слід використовувати для забезпечення того, щоб перевірка підпису є пакетом завжди відбувається до для його установки. Для того, щоб змусити ням перевіряти підписи пакетів перед їх установкою, переконайтеся, що наступний рядок з'являється в /etc/yum.conf в [основною] розділ: gpgcheck = 1 CCE 14914-6 2.1.2.3.4 Забезпечення Пакет Підпис Перевірка не відключена для будь-якої Репо Для того, щоб переконатися, що перевірка підписи не відключена для будь-яких операціях РЕПО, переконайтеся, що наступний рядок НЕ з'являються в будь-яких файлах конфігурації в /etc/yum.repos.d репо або в іншому місці: gpgcheck = 0 CCE 14813-0 2.1.3 Програмне забезпечення Перевірка цілісності ПАМ'ЯТНА програмне забезпечення (Advanced Intrusion Detection Environment) входить до складу системи, щоб забезпечити програмне забезпечення перевірка цілісності. Він призначений, щоб бути заміною для добре відомої перевірки цілісності Tripwire. Число оборотів в хвилину Програмне забезпечення також включає в себе можливість порівняти хеші встановлених файлів з тими, у своїй власній базі даних метаданих. Перевірка цілісності не може запобігти вторгнення у вашу систему, але може виявити, що вони відбулися. такі перевірки цілісності програмного забезпечення повинні бути налаштовані до того, як система розгортається і в стані надає послуги користувачів. В ідеалі, перевірка цілісності бази даних буде побудований до того, як система підключена до будь-якої мережі, хоча це може виявитися непрактичним через реєстрацію і оновлень програмного забезпечення. 23 2.1.3.1 Налаштування ПАМ'ЯТНА Вимоги до перевірки цілісності програмного забезпечення повинні бути визначені відповідно до політики, і це дуже сильно залежить від середовище, в якому буде використовуватися система. Таким чином, загальна стратегія для здійснення перевірки цілісності за умови, але точні рекомендації (наприклад, щоб перевірити конкретний файл) не може бути. Документація для AIDE, в тому числі швидкого старту, на якому грунтується такий рада, доступний в /usr/share/doc/aide-0.12. Функція може перешкодити Попереднє зв'язування з операцією AIDE, оскільки вона змінює виконавчі файли в спробувати зменшити їх час запуску. Set = ні Попереднє зв'язування всередині / і т.д. / sysconfig / Prelink і запустіть / USR / SBIN / Prelink -ua відновити виконавчі файли в не в змозі і попередньо скомпоновані запобігти Попереднє зв'язування від заподіяння помилкових позитивних результатів від Ейд. 2.1.3.1.1 Встановити AIDE ПАМ'ЯТНА не встановлюється за умовчанням. Встановіть його за допомогою команди: # Ням встановити помічник CCE 4209-3 2.1.3.1.2 Конфігурація Налаштування файлу Налаштування /etc/aide.conf відповідно до ваших вимог. Конфігурація за замовчуванням є прийнятним для багатьох середовищ. Людина сторінка aide.conf (5) містить детальну інформацію про формат файлу конфігурації. 2.1.3.1.3 Build, магазин, і тестування бази даних Сформувати нову базу даних: # / USR / SBIN / помічник --init За замовчуванням, база даних буде записана в файл /var/lib/aide/aide.db.new.gz. База даних, а також конфігураційний файл /etc/aide.conf і двійковий / USR / SBIN / помічник (або хеші з цих файлів) повинні бути скопійовані і збережені в безпечному місці. Зберігання цих копій або хеш на тільки для читання засоби масової інформації можуть забезпечити подальшу впевненість в тому, що вони не будуть змінені. Встановіть знову генерується бази даних: # Ф /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz Виконайте ручну перевірку: # / USR / SBIN / помічник --check Якщо ця перевірка виробляє будь-якої несподіваний вихід, досліджувати. 24 ГЛАВА 2. загальносистемних конфігурації 2.1.3.1.4 Реалізувати періодичного виконання Перевірка цілісності За замовчуванням, пам'ятні не інсталює себе для періодичного виконання. Здійснювати перевірки з тим, що частоти потрібно вашій політики безпеки. Колись щоденна перевірка може бути підходить для багатьох середовищ. Наприклад, для здійснення щоденного запуску флігель о 4:05 ранку, додайте наступний рядок в / і т.д. / кронтаб: 05 4 * * * корінь / USR / SBIN / помічник --check Вихід ПАМ'ЯТНА може бути ознакою атаки проти вашої системи, або це може бути результатом чого-то нешкідливі, такі як зміна конфігурації адміністратора або оновлення програмного забезпечення. Дії, описані в розділі 2.1.3.1.3 слід повторити, якщо зміни конфігурації або оновлення програмного забезпечення вимагають. Це, безумовно, буде необхідно після застосування вказівок в цьому керівництві. 2.1.3.1.5 вручну Перевірка цілісності флігель Оскільки перевірка цілісності є засобом виявлення вторгнень, а не запобігання вторгнень, вона не може бути гарантована що ад'ютант виконавчі файли, файли конфігурації або бази даних не були підроблені. Зловмисник може відключити або змінити ці файли після успішного вторгнення. Через це, ручні і часті перевірки на цих файлів рекомендується. Були створені надійно збережені копії (або хеші) бази даних, двійковий і конфігураційний файл Раніше для цієї мети. Вручну перевірити цілісність ад'ютант довічних файлів, файлів конфігурації і бази даних. Можливості для ведення так включають в себе: 1. Використовуйте sha1sum або md5sum для генерації контрольних сум файлів, а потім візуально порівняти їх з тими, генерується зі збережених версій безпечно. Це не означає, звичайно, не виключає можливості того, що такі вихід також може бути підроблена. 2. Встановити збережені версії на призначених тільки для читання засобів масової інформації та запустити / bin / Diff, щоб переконатися, що немає ніяких відмінностей між файлами. 3. Копіювання файлів в іншу систему і виконання хеш або файлу порівняння можуть надавати додаткову впевненість в тому, що річний процес перевірки не заважав. 2.1.3.2 Перевірка пакету цілісності Використання RPM Система управління RPM пакет включає в себе можливість перевірки цілісності встановлених пакетів шляхом порівняння встановлені файли з інформацією про файли, які вибираються зі метаданих пакета, що зберігаються в RPM бази даних. Незважаючи на те, зловмисник може пошкодити базу даних RPM (аналог атакувати базу даних AIDE як описаний вище), ця перевірка ще може виявити модифікацію важливих файлів. Для того, щоб визначити, які файли на системі відрізняються від того, що, як очікується, в базі даних RPM: # Оборотов в хвилину -qVa "З" у другому стовпці означає, що файл являє собою файл конфігурації (і, як можна очікувати зміни). в Щоб виключити файли конфігурації з цього списку, виконайте наступну команду: # Оборотов в хвилину -qVa | AWK '$ 2! = "C" {друку $ 0}' 25 CCE 14931-0 Людина сторінка оборотів в хвилину (8) описує формат виведення. Будь-які файли, які не відповідають очікуваного результату вимагають подальшого вивчення, якщо система серйозно вивчені. Ця перевірка також може бути запущена як хрон робота. 2.2 Права доступу до файлів і маски Безпека Традиційні Unix в значній мірі залежить від прав доступу до файлів і каталогів, щоб запобігти несанкціонованому доступу користувачів читання або зміна файлів, до яких вони не повинні мати доступ. Дотримуйтеся принципу найменших привілеїв - конфігурувати кожен файл, каталог і файлову систему, щоб забезпечити тільки доступ, необхідний для того, щоб цей файл, щоб служити його Мета. Проте, системи Linux містять велику кількість файлів, тому часто буває непомірно багато часу для того, щоб кожен файл на комп'ютері має рівно дозволи, необхідні. У даному розділі представлені деякі обмеження дозволів які майже завжди підходить для системи безпеки, і які легко перевірити і правильно. Примітка: Деякі з команд в розділі Пошук файлових систем для файлів або каталогів з певними характеристиками, і призначені для запуску на кожному локальному ext2 або ext3 розділ на даній машині. Коли змінна частина з'являється в одному з наведених нижче команд, то це означає, що команда призначена для запуску неодноразово, з ім'я кожного локального розділу замінений на участь в черзі. Наступна команда друкує список ext2 і ext3 розділів на даній машині: $ Монтування -t ext2, ext3 | AWK '{друку $ 3}' Якщо ваш сайт використовує локальний тип файлової системи, крім ext2 або ext3, то вам потрібно змінити цю команду. 2.2.1 Обмеження підключення розділу Options Системні перегородки можуть бути встановлені з певними параметрами, які обмежують які файли на цих розділах можна зробити. ці Параметри задаються у файлі / і т.д. / Fstab, і може бути використаний, щоб зробити певні типи поведінки шкідливих програм більш важким. 2.2.1.1 Додати nodev варіант в Некореневі локальні розділи Відредагуйте файл / і т.д. / Fstab. Важливі стовпці для цілей цього розділу є колонки 2 (точка монтування), колонка 3 (тип файлової системи), а стовпець 4 (опції монтування). Для будь-якої лінії, яка задовольняє всім умовам: ?? Тип файлової системи ext2 або ext3 ?? Точка монтування НЕ / додати текст ", nodev" в список опцій монтування в колонці 4. CCE 4249-9 Опція nodev забороняє користувачам монтажними неавторизованих пристроїв на будь-який розділ, який, як відомо, не містять будь-яких авторизованих пристроїв. Кореневий розділ зазвичай містить каталог / Dev, який є основним місце для авторизованих пристроїв, а тому цей параметр не повинен бути встановлений на /. Однак, якщо системні програми в даний час працюють в CHROOT в'язницях, ця рада може знадобитися змінити в подальшому, так як Часто буває необхідно створювати файли пристроїв в директорії кореневих для використання обмеженого програми. 26 ГЛАВА 2. загальносистемних конфігурації 2.2.1.2 Додати nodev, nosuid і поехес Параметри для змінних пристроїв зберігання Перегородки Відредагуйте файл / і т.д. / Fstab. Файлові, які представляють собою знімні носії можуть бути розміщені шляхом знаходження ліній, Точки монтування містять рядки, як дискети або CD-ROM. Для кожної лінії, що представляє знімний носій точки монтування, додайте текст поехес, nodev, nosuid до списку опції монтування в колонці 4. CCE 3522-0, 4275-4, 4042-8 Файлові встановлені на знімних носіях також забезпечують спосіб для шкідливих виконуваних файлів потенційно ввести системи, а також повинні бути встановлені з опціями, які надають мінімум повноважень. Його користувачі не повинні мати можливість вводити довільні пристрої або програми Setuid в систему. Крім того, в той час як користувачі, як правило, дозволено додавати виконуваний програми в системі, то поехес опція запобігає код з виконується безпосередньо з самого носія, і тому може забезпечити лінію захисту від певних типів черв'яків або шкідливого коду. Точки монтування в / і т.д. / Fstab може не існувати на сучасній системі з типовим апаратним забезпеченням. динамічний монтаж Механізм може управлятися за допомогою інших засобів (які можуть або не можуть дозволити контролювати параметри монтування). Додавання поехес викличе проблеми, якщо це необхідно в вашому середовищі для виконання коду зі знімних носіїв, хоча це поведінка несе в собі ризики, а також. 2.2.1.3 Додати nodev, nosuid і поехес Функції для тимчасового зберігання Перегородки Тимчасові каталоги зберігання, такі як / TMP і / Dev / ГИМ потенційно забезпечують місце для зберігання шкідливих виконуваних файлів. Хоча опції монтування опції не можуть перешкодити інтерпретувати код зберігається там від отримання виконується програмою в іншому розділі, використовуючи певні параметри монтування можуть бути руйнівними для шкідливого коду. 2.2.1.3.1 Додати nodev, nosuid і поехес Options в / TMP Відредагуйте файл / і т.д. / Fstab. Додайте текст, nodev, nosuid, поехес в список опцій монтування в колонці 4. CCE 14412-1, 14940-1, 14927-8 2.2.1.3.2 Додати nodev, nosuid і поехес Options в / DEV / ГИМ Відредагуйте файл / і т.д. / Fstab. Додайте текст, nodev, nosuid, поехес в список опцій монтування в колонці 4. CCE 15007-8, 14306-5, 14703-3 2.2.1.4 зв'яжіть / вар / TMP в / TMP Відредагуйте файл / і т.д. / Fstab. Додайте наступний рядок: / TMP / вар / TMP жоден RW, поехес, nosuid, nodev, пов'язують 0 0 CCE 14584-7 Ця лінія буде пов'язувати демонтує світового записується / VAR / TMP каталог на / TMP, використовуючи обмежувальні параметри монтування вказано. Дивіться (8) сторінка людини монтування для подальшого пояснення монтажу прив'язки. 27 2.2.2 Обмеження динамічного підключення і відключення файлових систем Linux включає в себе ряд засобів для автоматизованого додавання і видалення файлових систем на працюючій системі. Ці кошти можуть підвищити зручність, але всі вони приносять певний ризик, будь то прямий ризик від дозволу непривілейованих користувачам вводити довільні файлові системи на машину, або ризик того, що програмні недоліки в автоматизованій монтування Сам об'єкт дозволить злодію отримати систему. Будьте обережні при включенні будь-якого такого об'єкта, а також з'ясувати, чи є краще управління конфігурацією або користувача освіта може вирішити ту ж саму проблему з меншим ризиком. 2.2.2.1 Обмеження доступу з консолі пристроїв Конфігурація за замовчуванням Система надає консольні покращеним привілеї зазвичай зарезервований для кореневого користувача, в тому числі тимчасове володіння більшості системних пристроїв. Якщо немає необхідності, то ці привілеї повинні бути видалені і обмежується тільки корінь. Обмеження права власності пристрої викорінити тільки. Редагування /etc/security/console.perms.d/50-default.perms і знайдіть розділ передує наступних коментарі: # Визначення прав доступу Випереджати символ # закомментировать кожен рядок в цьому розділі, який починається з <консоль> або : # <Консоль> 0660 <дискети> 0660 root.floppy # <Консоль> 0600 <звук> 0600 корінь ... # 0600 / DEV / 0600 консоль root.root # <Консоль> 0600 0600 корінь Редагування /etc/security/console.perms і внести наступні зміни: <Консоль> = TTY [0-9] [0-9] * Bc / [0-9] [0-9] *: 0 \ [0-9] :. 0 = :. 0 \ [0-9]: 0 CCE 3685-5 Підтримка пристроїв 2.2.2.2 Відключити USB USB флеш-пам'яті або жорсткі диски дозволяють зловмисникові фізичний доступ до системи, щоб швидко скопіювати величезна кількість даних з нього. 2.2.2.2.1 Відключити Modprobe Завантаження USB драйвера пристрою зберігання даних Якщо не слід використовувати пристрої зберігання даних USB, програма Modprobe використовується для автоматичного ядра завантаження модулів повинен бути налаштований не завантажувати драйвер USB-накопичувача на попиті. Додайте наступний рядок в /etc/modprobe.conf, щоб запобігти завантаження модуля ядра USB-зберігання: встановити USB-зберігання / бен / істинним CCE 4187-1 28 ГЛАВА 2. загальносистемних конфігурації Це дозволить запобігти програму Modprobe від завантаження модуля USB-пам'яті, але не завадить адміністратору (Або інша програма) за допомогою програми insmod, щоб завантажити модуль вручну. 2.2.2.2.2 Видалити USB Storage Driver Якщо ваша система ніколи не вимагає використання USB-накопичувачів, то підтримує драйвер може бути видалений. хоча більш ефективним (як зберігання USB, звичайно, не може бути використаний, якщо водій не доступний взагалі), це менш елегантний ніж методом, описаним в розділі 2.2.2.2.1. Щоб видалити драйвер USB-накопичувача з системи: гт / Бібліотека / модулі / kernelversion (s) /kernel/drivers/usb/storage/usb-storage.ko Ця команда буде необхідно повторити кожен раз, коли ядро ​​оновлюється. Ця команда також викличе командного RPM -q --verify ядра на провал, який може бути небажаним побічним ефектом. CCE 4006-3 Зверніть увагу, що це керівництво не буде перешкоджати USB-накопичувачів від бути встановлений, якщо власне ядро ​​(тобто, не поставляється з системою) з вбудованою підтримкою USB використовується. 2.2.2.2.3 Відключення підтримки Ядро для USB через загрузчиком Іншим засобом відключення зберігання USB, щоб відключити всі USB підтримку, що надається операційною системою. це може бути досягнуто шляхом додавання "nousb" аргумент конфігурації завантажувача ядра. Відключення всіх підтримки ядра для USB буде створювати проблеми для систем з USB на основі клавіатури, миші, або принтери. В цьому підручнику не підходить для систем, які вимагають підключення до USB. Щоб відключити підтримку ядра для USB, додайте "nousb" в рядок ядра в /etc/grub.conf наступним чином: Ядро / vmlinuz-версія ро = УПУ доб корінь = / DEV / VolGroup00 / LogVol00 rhgb тихою nousb CCE 4173-1 2.2.2.2.4 Відключити Завантаження комп'ютера з USB-пристроїв Зловмисник, який має фізичний доступ може спробувати завантажити систему з USB флеш-накопичувач, а потім отримати доступ до будь-яких даних на жорсткий диск системи, в обхід контролю доступу нормального режиму роботи системи. Щоб запобігти цьому, налаштувати В BIOS, щоб заборонити завантаження з USB-накопичувачів. Також настройки BIOS або мікропрограми пароль, як описано в Розділ 2.3.5.1 для запобігання несанкціонованих змін конфігурації. CCE 3944-6 2.2.2.3 Відключити автомоунтер якщо це можливо Якщо служба AutoFS не потрібно динамічно монтувати файлові системи NFS або знімний носій, відключити обслуговування: 29 # Chkconfig Autofs викл CCE 4072-5 У AutoFS демон монтує і демонтує файлові системи, такі як домашніх каталогів користувачів за допомогою спільно використовуваних NFS, на вимогу. Крім того, AutoFS може бути використаний для обробки знімних носіїв, а також конфігурація за замовчуванням забезпечує CDROM Пристрій / різнобічного / CD. Проте, цей спосіб надання доступу до знімних носіїв не є загальним, так що AutoFS майже завжди може бути відключена, якщо NFS не використовується. Навіть якщо потрібно NFS, то майже завжди можна налаштувати для файлової системи монтування статично шляхом редагування / і т.д. / Fstab, а не покладатися на автомонтіровщіком. 2.2.2.4 Відключити GNOME автомонтірованіе якщо це можливо робочого столу за замовчуванням середовище системи, GNOME, запускає програму гнома об'ємно-менеджер монтувати пристрої і знімні носії (такі як DVD, CD і USB флеш-накопичувачі) всякий раз, коли вони вставлені в систему. Виконайте наступні команди для запобігання гном-об'ємно-менеджер з автоматичного монтування пристроїв і засоби масової інформації: # Gconftool-2 --direct \ --config-джерело XML: читання і запис: /etc/gconf/gconf.xml.mandatory \ --type Ьоо \ --set / настільні / гнома / volume_manager / automount_media брехня # Gconftool-2 --direct \ --config-джерело XML: читання і запис: /etc/gconf/gconf.xml.mandatory \ --type Ьоо \ --set / настільні / Gnome / volume_manager / automount_drives брехня Перевірте зміни, виконавши наступну команду, яка повинна повертати список параметрів: # Gconftool-2 -R / настільні / гнома / volume_manager У автомонтіруемие диски і настройки автомонтіруемие засобів масової інформації повинен бути встановлений в брехню. Розгляньте список для будь-якого іншого Параметри, які повинні бути скоректовані. CCE 4231-7 Можливості системи для автоматичної установки повинен бути налаштований, щоб відповідати будь-який визначається безпекою політика. Відключення зберігання USB, як описано в розділі 2.2.2.2.1 буде перешкоджати використанню запам'ятовуючих пристроїв USB, але цей крок також може бути прийнято в якості додаткового шару попередження і запобігання автоматичного монтування компакт-дисків і DVD-диски, якщо потрібно. Зокрема, для систем кіоскового типу, де користувачі повинні мати вкрай обмежений доступ до системи, більш докладний інформацію можна знайти в Red Hat Desktop: Посібник із розгортання [5]. Програма GConf-редактор, доступний в RPM з тим же ім'ям, може бути використаний для вивчення інших параметрів, доступних в середовищі GNOME. 2.2.2.5 Відключити Установка типів Частий FileSystem Додайте наступні рядки в /etc/modprobe.conf, щоб запобігти використанню незвичайної файлової системи типи: 30 ГЛАВА 2. загальносистемних конфігурації встановити Cramfs / бен / істинним встановити freevxfs / бен / істинним встановити jffs2 / бен / істинним встановити HFS / бен / істинним встановити hfsplus / бен / істинним встановити SquashFS / бен / істинним встановити UDF / бен / істинним CCE 14089-7, 14457-6, 15087-0, 14093-9, 14853-6, 14118-4, 14871-8 За допомогою команди установки всередині /etc/modprobe.conf інструктує систему ядра завантаження модулів для запуску Команда, зазначена (тут, / бен / істинним) замість того, щоб вставити модуль у ядрі в звичайному режимі. це ефективно запобігає використання цих незвичайних файлових систем. 2.2.2.6 Відключити все Thumbnailers GNOME, якщо це можливо робочого столу за замовчуванням середовище системи, GNOME, використовує цілий ряд різних програм Thumbnailer для генерації ескізи для будь-якого нового або зміненого контенту у відкритій папці. Виконайте наступну команду, щоб запобігти thumbnailers автоматично створювати ескізи для нових або модифіковані вміст папки: # Gconftool-2 --direct \ --config-джерело XML: читання і запис: /etc/gconf/gconf.xml.mandatory \ --type Ьоо \ --set / настільні / гнома / thumbnailers / disable_all правда Це ефективно запобігає зловмисникові отримати доступ до системи через недолік в Nautilus в GNOME Творці мініатюр. 2.2.3 Перевірка дозволів на важливі файли і каталоги Права доступу для багатьох файлів в систему повинен бути встановлений, щоб відповідати політиці системи. В цьому розділі обговорюється важлива обмеження прав доступу gshadow, які повинні бути перевірені на регулярній основі, щоб гарантувати, що ніякі шкідливі розбіжності виникли. 2.2.3.1 Перевірка дозволів на PASSWD, тінь, групи і gshadow файлів # Кд / і т.д. # Чаун корінь: корінь PASSWD тінь група gshadow # CHMOD група 644 PASSWD # CHMOD 400 тінь gshadow CCE 3988-3, 3883-6, 3276-3, 3932-1, 4064-2, 4210-1, 3918-0, 3566-7, 3958-6, 3967-7, 3495-9, 4130-1 Ці права доступу за замовчуванням для цих файлів. Багато утиліти потрібно доступ на читання до файлу паролів в порядку щоб нормально функціонувати, але доступ для читання до тіньового файлу дозволяє зловмисні атаки проти системних паролів і ніколи не повинна бути включена. 31 2.2.3.2 Переконайтеся, що всі всесвітньо-записувані каталоги Липкі Біти Set Знайдіть будь-які каталоги в локальних розділів, які є всесвітньо-записувані і не поставили свої липкі біти. наступна команда буде відкривати і друкувати їх. Запустіть його один раз для кожної локальної частини розділу: # Знайти ЧАСТИНА -xdev-типу d \ (-perm -0002 -a! -perm -1000 \) -print Якщо ця команда виробляє будь-який висновок, виправити кожен вказаний каталог / реж за допомогою команди: # CHMOD + т / реж CCE 3399-3 Коли так званий "Лепкий біт" встановлено на каталог, тільки власник даного файлу може видалити цей файл з Каталог. Без липкого біта, будь-який користувач, який має доступ на запис в каталог може видалити будь-який файл в каталозі. Установка липкий біт заважає користувачам видаляти файли один одного. У тих випадках, коли немає ніяких підстав для Каталог буде доступний на запис всім, краще рішення, щоб видалити цей дозвіл, а не встановити липкий біт. Однак, якщо каталог використовується в конкретній галузі застосування, зверніться до документації на цю програму замість сліпо зміні режимів. 2.2.3.3 Знайти Несанкціоноване всесвітньо-записувані файли Наступні команди і виявляє друкує будь всесвітньо-записувані файли в локальних розділів. Виконати це один раз для кожного локальна частина розділу: # Знайти ЧАСТИНА -xdev-типу F -perm -0002 -print Якщо ця команда виробляє будь-який висновок, виправити кожен вказаний файл файлу за допомогою команди: # CHMOD о-ш-файл CCE 3795-2 Дані в всесвітньо-записувані файли можуть бути змінені будь-яким користувачем в системі. Майже у всіх випадках, файли можуть бути конфигурируется за допомогою комбінації дозволів користувачів і груп для підтримки будь-якою законною потрібно вводити без ризику, пов'язаного з всесвітньо-записувані файли. Це, як правило, хороша ідея, щоб видалити глобальний (інший) доступ на запис в файл, коли він виявив. Проте, перевірте з документацією для конкретних додатків, перед внесенням змін. Крім того, стежити за повторюваними всесвітньо-записувані файли, так як вони можуть бути симптоми неправильної конфігурації програми або облікового запису користувача. 2.2.3.4 Знайти Несанкціоноване SUID / SGID Система Виконувані Наступні команди і виявляє, друкує будь Setuid або setgid файли на локальних розділів. Запустіть його один раз для кожна локальна частина розділу: # Знайти ЧАСТИНА -xdev \ (-perm -4000 -o -perm -2000 \) -типу F -print Якщо файл не вимагає Setuid або setgid біт, як описано нижче, то ці біти можуть бути видалені з команда: # CHMOD -s файл CCE 14340-4, 14970-8 32 ГЛАВА 2. загальносистемних конфігурації У наступній таблиці наведено всі УИП і setgid файли, які, як очікується, буде на фондовій системі. УИП або setgid біт на ці файли можуть бути відключені, щоб зменшити ризик системи, якщо тільки адміністратор вимагає їх функціональності. У таблиці вказані ті файли, які не можуть бути необхідні. Примітка: Деякі з цих файлів використовуються для додатків, які навряд чи будуть актуальні для виробництва більшості середовища, такі як ISDN мережі, SSH hostbased аутентифікації, або зміна мережевих інтерфейсів непривілейованими користувачів. Досить імовірно, що ваш сайт може відключити підмножина цих файлів без втрати функціональність. Будь-які файли, знайдені вище команди, які не перебувають в таблиці повинні бути розглянуті. Якщо файли не є уповноважені, вони повинні мати дозволи видалені, і подальше розслідування може бути виправдане. Файл Set-ID Subsystem / Посилання Відключити? / Bin / монтування файлових систем UID корінь немає / Bin / пінг UID корінь нетто (3.3.9) немає / Bin / ping6 UID корінь мережу (3.3.9), IPv6 (2.5.3), якщо не використовується IPv6 / Bin / су UID корінь Auth (2.3.1.2) немає / Bin / демонтувати UID корінь файлових систем немає /sbin/mount.nfs Uid кореневої NFS (3.13), якщо не використовується NFS /sbin/mount.nfs4 UID корінь NFS (3.13), якщо не використовується NFSv4 / SBIN / netreport GID корінь мережу (3.3.9), якщо користувачі не повинні модифікувати інтерфейси / SBIN / РАМ перевірка тимчасової мітки UID корінь РАМ Auth (2.3.3) немає /sbin/umount.nfs Uid кореневої NFS (3.13), якщо не використовується NFS /sbin/umount.nfs4 UID корінь NFS (3.13), якщо не використовується NFSv4 / SBIN / Unix chkpwd Uid корінь PAM AUTH (2.3.3) немає / USR / бен / с UID корінь хрон / в (3.4) немає / USR / bin / Chage UID корінь PASSWD експірації (2.3.1.7), якщо користувачі не повинні розглядати витікання інформації / USR / bin / CHFN UID кореневої дані користувача, якщо користувачі не повинні змінювати дані палець / USR / bin / CHSH UID кореневої дані користувача, якщо користувачі не повинні змінювати оболонки / USR / бен / кронтаб UID / GID корінь Крон / с (3.4), якщо користувачі не повинні використовувати хрон / USR / бен / gpasswd UID кореневої групи Auth немає / USR / бен / годі й шукати GID slocate місцезнаходження бази даних немає / USR / бен / файл блокування GID пошти Procmail, якщо не використовується Procmail / USR / бен / newgrp UID кореневої групи Auth немає / USR / bin / PASSWD UID корінь PASSWD Auth немає / USR / bin / RCP UID корінь RSH (3.2.3) та (РШ є застарілим) / USR / bin / Rlogin UID корінь RSH (3.2.3) та (РШ є застарілим) / USR / bin / RSH UID корінь RSH (3.2.3) та (РШ є застарілим) / USR / бен / SSH-агент GID ніхто SSH (3.5) немає / USR / bin / Sudo UID корінь Sudo (2.3.1.3) немає / USR / bin / sudoedit UID корінь Sudo (2.3.1.3) немає / USR / бен / стіна GID TTY консолі повідомлень, якщо не використовується консоль обміну повідомленнями / USR / бен / запису GID TTY консолі повідомлень, якщо не використовується консоль обміну повідомленнями / USR / bin / Xorg UID корінь X11 (3.6), якщо не використовується X11 / USR / Керберос / bin / КСУ UID корінь Kerberos Auth (2.3.6), якщо не використовується Kerberos / USR / libexec / OpenSSH / SSH-keysign UID корінь SSH (3.5), якщо SSHD не використовує hostbased Auth / USR / libexec / utempter / utempter GID utmp термінал підтримки немає / USR / Lib / кальмар / РАМ Auth UID корінь кальмар (3,19), якщо не використовується кальмара / USR / Lib / кальмар / NCSA Auth UID корінь кальмар (3,19), якщо не використовується кальмара / USR / Lib / VTE / гнома-псевдотермінал-хелперів GID utmp X11, Gnome (3.6), якщо не використовується X11 / USR / SBIN / ccreds Validate UID корінь PAM Auth (2.3.3), якщо не використовується кешування Auth PAM / USR / SBIN / lockdev GID блокування файлових систем немає /usr/sbin/sendmail.sendmail GID smmsp Sendmail клієнт (3.11.2) немає / USR / SBIN / Suexec UID корінь Апач (3.16), якщо не використовується Apache / USR / SBIN / userhelper UID корінь PAM Auth (2.3.3.4) обмежують (дивись розділ 2.3.3.4) / USR / SBIN / userisdnctl UID корінь ISDN ISDN, якщо використовується 33 Файл Set-ID Subsystem / Посилання Відключити? / USR / SBIN / usernetctl UID кореневого управління користувач мережі, якщо користувачі не повинні модифікувати інтерфейси 2.2.3.5 Знайти і ремонту без господаря файлів Наступна команда буде відкривати і друкувати будь-які файли на локальних розділів, які не належать до дійсним користувача і дійсну групу. Запустіть його один раз для кожної локальної частини розділу: # Знайти ЧАСТИНА -xdev \ (-nouser -o -nogroup \) -print Якщо ця команда виводить якісь результати, досліджувати кожен вказаний файл і або призначити його відповідному користувачу і групу або видалити його. CCE 4223-4, 3573-3 Файли без власника не є безпосередньо придатний для використання, але вони, як правило, ознака того, що щось не так з деякими системний процес. Вони можуть бути викликані зловмисником, в результаті неправильної установки програмного забезпечення або неповного програмного забезпечення видалення, або невчинення, щоб видалити всі файли, що належать до віддаленої облікового запису. Файли повинні бути відремонтовані таким чином, щоб вони не викличе проблем при створенні облікових в майбутньому, і проблема, яка привела до файлів, які не мають власника повинні бути виявлені і вирішені. 2.2.3.6 Переконайтеся, що всі всесвітньо-записувані каталоги Правильне власності рахунок. 2.2.3.6 Переконайтеся, що всі всесвітньо-записувані каталоги Правильне власності Знайдіть будь-які каталоги в локальних розділів, які є всесвітньо-записувані і гарантувати, що вони належать корені або іншої системної облікового запису. Наступна команда буде відкривати і роздруковувати ці (припускаючи, що тільки система рахунки мають UID нижче 500). Запустіть його один раз для кожної локальної частини розділу: # Знайти ЧАСТИНА -xdev-типу d -perm -0002 -uid +500 -print Якщо ця команда виробляє будь-який висновок, з'ясувати, чому нинішній власник не є коренем або іншої системи рахунок. CCE 14794-2 Дозвіл облікового запису користувача в свій світ перезаписуваний каталог є небажаним, оскільки воно дозволяє власникові, що каталог, щоб видалити або замінити будь-які файли, які можуть бути поміщені в каталог іншими користувачами. 2.2.4 Обмеження програм з небезпечних Patterns Execution Рекомендації в цьому розділі забезпечують надійний захист від розкриття інформації або іншого неправомірного поведінки. Ці засоби захисту застосовуються при ініціалізації системи або ядра рівня, а також захистити від певних типів погано налаштоване або скомпрометований програм. 2.2.4.1 Встановити Daemon Umask Змініть файл / і т.д. / sysconfig / ініціалізації, а також додати або виправити такий рядок: Umask 027 CCE 4220-0 34 ГЛАВА 2. загальносистемних конфігурації Файл налаштувань / і т.д. / sysconfig / ініціалізації містить настройки, які застосовуються до всіх процесів під час завантаження системи. Система Umask повинен бути встановлений принаймні 022, або процеси, демон може створити всесвітньо-записувані файли. більш обмежувальний характер настройки 027 захищає файли, в тому числі тимчасових файлів і файлів журналів, від несанкціонованого читання по непривілейованих користувачів в системі. Якщо конкретний демон потребує менше обмежувальний біти повноважень, розглянути можливість редагування файлу запуску сценарію або sysconfig про те, що демон, щоб зробити конкретний виняток. 2.2.4.2 Відключення дампи ядра Щоб відключити дампи ядра для всіх користувачів, додати або виправити наступний рядок в /etc/security/limits.conf: * Тверде ядро ​​0 Крім того, щоб гарантувати, що основні скиди ніколи не можуть бути зроблені Setuid програм, редагування /etc/sysctl.conf і додати або виправити рядок: fs.suid_dumpable = 0 CCE 4225-9, 4247-3 Файл дампа це образ пам'яті виконуваного файлу програми, коли вона була припинена операційною системою через несправедливий поведінки. У більшості випадків, тільки розробники програмного забезпечення законно повинні були б отримати доступ до цих файлів. основні файли дампа також можуть містити конфіденційну інформацію, або надмірно займають великі обсяги дискового простору. За замовчуванням система встановлює м'який межа, щоб зупинити створення основних файлів дампа для всіх користувачів. це досягається в / і т.д. / профіль з лінією: ULIMIT -S -c 0> / DEV / нуль 2> & 1 Однак дотримання цієї межі є добровільним; це за замовчуванням призначені тільки для захисту користувачів від досади генерації непотрібних файлів ядра. Користувачі можуть збільшити допустимий розмір файлу дампа пам'яті до жорсткого межі, який необмежений за замовчуванням. Після того, як жорсткий ліміт встановлений в /etc/security/limits.conf, користувач не може збільшити цей ліміт, в межах його власної сесія. Якщо доступ до дампи ядра потрібно, розглянути питання про обмеження їх тільки певним користувачам або групам. див limits.conf (5) людина сторінки для отримання додаткової інформації. Основними відвали Setuid програм додатково захищені. Мінлива Sysctl fs.suid dumpable управління Чи ядро ​​дозволяє дампи ядра з цих програм на всіх. Рекомендується значення за замовчуванням 0. 2.2.4.2.1 Забезпечення SUID дампи ядра відключені Sysctl змінна fs.suid dumpable слід перевірити, щоб переконатися, що він не був включений в будь-який час під час роботи системи. Щоб перевірити це, виконайте команду: # Sysctl fs.suid_dumpable Вихідний сигнал слід вказати, що параметр дорівнює 0. (Використання опції -n викликає вихід складатися з тільки значення, яке може зробити автоматизованої перевірки простіше.) 35 2.2.4.3 Включити ExecShield ExecShield включає в себе ряд функцій ядра для забезпечення захисту від переповнення буфера. ці особливості включають в себе випадкове розміщення стека і інших регіонах пам'яті, запобігання виконання в пам'яті, що повинно тільки зберігати дані, а також спеціальну обробку текстових буферів. Для забезпечення ExecShield (включаючи випадкове розміщення віртуальних областей пам'яті) активується при завантаженні, додайте або виправити наступні настройки в /etc/sysctl.conf: kernel.exec-щит = 1 kernel.randomize_va_space = 1 CCE 4146-7, 4168-1 ExecShield використовує функцію сегментації на всіх системах x86, щоб запобігти виконанню в пам'яті вище, ніж певна адреса. Він записує адресу в якості межі в дескрипторі сегменту коду, щоб контролювати, де код може бути виконаний, на основі кожного процесу. Коли ядро ​​поміщає областей пам'яті процесу, такі, як стек і купу вищого ніж ця адреса, апаратне забезпечення запобігає виконанню там. Тим не менш, це не завжди може бути зроблено для всієї пам'яті регіони, в яких виконання не повинно відбуватися, тому дотримуйтесь рекомендації в розділі 2.2.4.4 для подальшого захисту системи. 2.2.4.3.1 Забезпечення ExecShield Включено Захист Exec-щит включений за замовчуванням, але SYSCTL змінні kernel.exec-щит і kernel.randomize ва простір повинен бути перевірено, щоб переконатися, що вона не була відключена в будь-який час робота системи. Для того, щоб перевірити, що ExecShield (в тому числі випадкового розміщення віртуальних областей пам'яті) є в даний час працює, виконайте наступні команди: # Sysctl kernel.exec щит # Sysctl kernel.randomize_va_space Вихід обох команд повинні бути вказати, що настройка 1. (Використання опції -n викликає вихід складатися лише з вартості, яка може зробити автоматизоване перевірки простіше.) 2.2.4.4 Enable Execute Disable (XD) або No Execute (NX) Підтримка на 32-розрядних x86 системах Пізніше 32-розрядні процесори сімейства x86 підтримують можливість запобігти виконанню коду на одній сторінці пам'яті основа. Загалом і на процесорах AMD, ця здатність називається Ні Execute (NX), в той час як на процесорах Intel IT називається Execute Disable (XD). Ця здатність може допомогти запобігти використанню уразливості переповнення буфера і її потрібно активувати, коли це можливо. Додаткові кроки мають бути зроблені, щоб гарантувати, що цей захист включена 32-розрядні системи x86. Інші процесори, такі як Itanium, потужність і 64-бітної x86 (як AMD64 або Intel 64), мають включена така підтримка з моменту створення і стандартне ядро ​​для цих платформ підтримує цю функцію. 2.2.4.4.1 Перевірка для підтримки процесорів від x86 систем Перевірте, щоб побачити, якщо процесор підтримує функції PAE і NX: $ Кота / Proc / CPUInfo 36 ГЛАВА 2. загальносистемних конфігурації Якщо ця функція підтримується, поле прапорів буде містити PAE і пх. 2.2.4.4.2 Установка нового ядра на підтримуваних системах x86 Системи, що використовують пакет x86 ядра 64-розрядної не потрібно встановити пакет ядра PAE, тому що 64-розрядної версії x86 ядро ​​вже включає в себе цю підтримку. Проте, якщо система працює під управлінням 32-розрядної версії ядра підтримує PAE і NX функції, як визначено в попередньому розділі, пакет ядра PAE повинен бути встановлений для того, щоб XD або підтримки NX: # Ням встановити ядро-PAE Процес установки також повинен бути налаштований завантажувач, щоб завантажити нове ядро ​​при завантаженні. перевірити це відбувається тільки при перезавантаженні і змінювати /etc/grub.conf при необхідності. CCE 4172-3 Пакет ядра PAE не слід встановлювати на старих системах, які не підтримують XD або NX біт, так як це може запобігти їх завантаження. 2.2.4.4.3 Включити NX або XD Підтримка в BIOS Комп'ютери з можливістю запобігти цей тип коду часто покласти опцію в BIOS, який буде дозволяє користувачам включити або відключити за бажанням. Перезавантажте систему і увійдіть в BIOS або меню конфігурації "Setup". Перейдіть в меню настройки BIOS і переконайтеся, що опція включена. Установка може бути розташована відповідно до розділу "Безпека". Шукайте Execute Disable (XD) на системах Intel на базі і немає Execute (NX) на системах AMD на базі. Дивіться розділ 2.3.5.1 для отримання інформації про захист цього та інших параметрів BIOS. CCE 4177-2 2.2.4.5 Налаштування Prelink Попереднє зв'язування призначений для зменшення часу запуску процесу шляхом завантаження кожної загальної бібліотеки на адресу, для якого пов'язування необхідних символів вже була виконана. / Sysconfig / Prelink файл / і т.д. описує те, що файлів, / USR / SBIN / Prelink програма буде змінювати і як часто він повинен змінити ці файли. Хрон запускається щодня, що визначає, чи буде програма Prelink повинна бути запущена. Є два типи Попереднє зв'язування: швидкий і повний. Повна відбувається по Попереднє зв'язування за замовчуванням кожні чотирнадцять днів і перелінкует всіх загальних бібліотек і виконавчі файли, які їх використовують. Швидкий режим запускається кожен день, але він працює тільки на модифікованих бінарних файлів і бібліотек. Після того, як двійковий файл був попередньо скомпоновані, адреса, за якою спільно використовувані бібліотеки будуть завантажені більше не буде випадковим на основі кожного процесу, навіть якщо kernel.randomize ва простір Sysctl встановлюється рівним 1. Це небажано, тому що це забезпечує стабільний адреса зловмисникові використовувати при спробі експлуатації. 37 2.2.4.5.1 Відключити Prelink Prelink можна безпечно відключити, встановивши наступні настройки в / і т.д. / sysconfig / Prelink: Попереднє зв'язування = немає 2.2.4.5.2 Undo Існуючі Попереднє зв'язування Виконайте наступну команду, щоб знову звернутися виконавчі файли і бібліотеки в їх первинного змісту, перш ніж вони були попередньо скомпоновані: # / USR / SBIN / Prelink -ua 2.3 Облік і контроль доступу У традиційній безпеки Unix, якщо зловмисник отримує доступ оболонки до певного реєстраційної облікового запису, він може виконати будь-які дії або отримати доступ до будь-якого файлу, до якого ця обліковий запис має доступ. Тому, роблячи його більш важким для сторонніх осіб щоб отримати доступ до оболонки рахунків, зокрема, для привілейованих облікових записів, є необхідною частиною безпеки системи. це розділ вводить механізми обмеження доступу до рахунків під RHEL5. 2.3.1 Protect рахунків Обмежуючи на основі пароля Логін Зазвичай облікові записи Unix оболонки доступні, надаючи ім'я користувача і пароль для входу в програму, який перевіряє ці значення для коректності, використовуючи / і т.д. / пароль і / і т.д. / тіньові файли. Пароль на основі Ввійти вразлива для вгадування слабких паролів, а нюхають і людини в-середині нападів паролів введений через мережу або на незахищеною консолі. Тому, механізми для доступу облікових записів шляхом введення імена користувачів і паролі повинні бути обмежені тими, які є функціонально необхідним. 2.3.1.1 Обмеження кореневих логінів до системної консолі Відредагуйте файл / і т.д. / securetty. Переконайтеся, що файл містить тільки такі рядки: ?? Первинного пристрою системної консолі: консоль ?? Віртуальні пристрої консолі: tty1 tty2 tty3 tty4 tty5 tty6 ... 38 ГЛАВА 2. загальносистемних конфігурації ?? При необхідності у вашій організації, застарілі віртуальний інтерфейс консолі можуть бути збережені для зворотної сумісність: Bc / 1 Bc / 2 Bc / 3 Bc / 4 Bc / 5 Bc / 6 ... ?? При необхідності у вашій організації, можуть бути додані послідовні консолі: ttyS0 ttyS1 CCE 3820-8, 3485-0, 4111-1, 4256-4 Прямі кореневі імена входу повинні бути дозволені тільки для використання в екстрених ситуаціях. У звичайних ситуаціях, адміністратор повинен отримати доступ система за допомогою унікальної непривілейованих облікового запису, а також використання су або Sudo виконувати привілейовані команди. обескураживающий адміністратори від доступу до кореневої облікового запису безпосередньо забезпечує аудиту в організаціях з великою кількістю адміністратори. Блокування каналів, через які корінь може підключатися безпосередньо зменшує можливості для пароль вгадування проти кореневої облікового запису. Програма Ввійти використовує файл / і т.д. / securetty, щоб визначити, які інтерфейси повинні дозволяти кореневих логіни. віртуальний пристрою / DEV / консолі і / DEV / TTY * являють собою системні консолі (доступні через Ctrl-Alt-F1 через Ctrl-Alt-F6 клавіатури послідовності на установці за замовчуванням). Файл securetty за замовчуванням також містить / DEV / Bc / *. Вони, швидше за все, буде скасована в більшості середовищ, але можуть бути збережені для сумісності. Корінь також слід заборонити підключення через мережеві протоколи. Дивіться розділ 3.5 для отримання інструкцій по запобігаючи корінь з входу в систему за допомогою SSH. 2.3.1.2 Обмеження су Доступ до облікового запису суперкористувача 1. Переконайтеся в тому, що група колеса існує, і що імена користувачів всіх адміністраторів, які повинні бути дозволені виконувати команди, як корінь, є членами цієї групи. # Grep ^ колесо / і т.д. / група 2. Змініть файл /etc/pam.d/su. Додати, розкоментувати або виправити рядок: Auth потрібно pam_wheel.so use_uid CCE 14088-9, 15047-4 Команда су дозволяє користувачеві отримати привілеї іншого користувача шляхом введення пароля для цього користувача рахунок. Бажано, щоб обмежити кореневого користувача, так що тільки відомі адміністратори ніколи не дозволений доступ до кореневої облікового запису. Це обмежує пароль вгадування проти кореневої облікового запису сторонніми користувачами або рахунків які були скомпрометовані. За угодою, група колесо містить імена всіх користувачів, яким дозволено запускати привілейовані команди. РАМ Модуль РАМ wheel.so використовується для обмеження доступу до кореневого каталогу цього безлічі користувачів. 39 2.3.1.3 Налаштування Sudo для поліпшення аудиту кореневих доступу 1. Переконайтеся в тому, що група колеса існує, і що імена користувачів всіх адміністраторів, які повинні бути дозволені виконувати команди, як корінь, є членами цієї групи. # Grep ^ колесо / і т.д. / група 2. Відредагуйте файл / і т.д. / sudoers. Додати, розкоментувати або виправити рядок: % Колесо ALL = (ALL) ALL CCE 4044-4 Команда Sudo дозволяє дрібнозернистий контроль над якими користувачі можуть виконувати команди за допомогою інших облікових записів. Основна перевага Sudo при налаштуванні, як описано вище в тому, що вона забезпечує аудиторський слід кожної команди запуску привілейованим користувачем. Цілком можливо, для зловмисний адміністратор, щоб обійти це обмеження, але, якщо є Встановлений порядок, що всі команди кореня виконуються за допомогою Sudo, то це легко для аудитора виявити незвичайне поведінку, коли ця процедура не дотримується. Редагування / і т.д. / sudoers вручну може бути небезпечним, так як помилка конфігурації може унеможливити доступ рахунки віддалено корінь. Рекомендовані засоби редагування цього файлу використовує команду visudo, яка перевіряє синтаксис файлу на коректність, перш ніж дозволити йому врятуватися. Зверніть увагу, що Sudo дозволяє будь-якому зловмисникові, який отримує доступ до пароль облікового запису адміністратора для виконання команд як корінь. Це зворотна сторона, яка повинна бути порівняна з вигодами від збільшення можливостей аудиту і бути здатні в значній мірі обмежити використання кореневого пароля з високою доданою вартістю (яка може бути логістично важко змінити часто). В якості основної запобіжні заходи, не допускається використання директиву NOPASSWD, що дозволить будь-якому з доступом до Адміністратор облікового запису для виконання команд з правами адміністратора, не знаючи пароля адміністратора. Команда Sudo має безліч опцій, які можуть бути використані для подальшої настройки її поведінки. Дивіться sudoers (5) для уточнення деталей. 2.3.1.4 Блок Shell та входу зареєстровані користувачі мають доступ Некореневі системних облікових записів Не об'єднуйте свій пристрій дії, описані в цьому розділі, присвяченому кореневої облікового запису. Це може привести до системи стають недоступними. Використання / і т.д. / пароль, отримати список всіх користувачів, їх UID, і їх оболонок, наприклад, виконавши: # AWK -F: '{друку $ 1 ":" $ 3 ":" $ 7}' / т.д. / пароль Визначити системні облікові записи з цього списку. Вони будуть в першу чергу бути рахунки з номерами менше UID ніж 500, крім кореня. Для кожної ідентифікованої системи рахунку SYSACCT, блокування облікового запису: # Usermod -L SYSACCT і відключити його оболонки: # Usermod -s / SBIN / NOLOGIN SYSACCT CCE 3987-5 Ці облікові записи, які не пов'язані з людиною-користувачем системи, але які існують для виконання деяких 40 ГЛАВА 2. загальносистемних конфігурації адміністративні функції. Зробити його більш важким для атакуючого використовувати ці облікові записи шляхом блокування їх паролі і встановивши їх оболонок до деякого недійсний оболонки. RHEL5 за замовчуванням неприпустимого оболонка / SBIN / NOLOGIN, але будь-яка команда, яка буде виходити зі станом відмови і заборонити виконання будь-яких додаткових команд, таких як / Бен / брехня або / DEV / нуль, буде працювати. 2.3.1.5 Перевірка належного зберігання та існування хеш паролів CCE 4238-2 2.3.1.5.1 Переконайтеся в тому, що ніяких рахунків не порожні поля Пароль Для того, щоб гарантувати, що ніякі рахунки не мають порожнє поле пароля, наступна команда не повинна мати ніякого висновку: # AWK -F: '($ 2 == "") {друк} / і т.д. / тінь Якщо це робить будь-який висновок, вирішити цю проблему шляхом блокування кожного облікового запису (див розділ 2.3.1.4 вище) або шляхом установки пароль. Якщо обліковий запис має порожній пароль, будь-хто може увійти і виконувати команди з привілеями цього облікового запису. Облікові записи з порожніми паролями ніколи не повинні використовуватися в операційних середовищах. 2.3.1.5.2 Переконайтеся, що всі Хеши обліковий запис за допомогою пароля Shadowed Для того, щоб гарантувати, що ніякі хеші паролів зберігаються в / і т.д. / пароль, наступна команда не повинна мати ніякого висновку: # AWK -F: '($ 2 = "х"!) {Друк} / і т.д. / пароль CCE 14300-8 Хеши для всіх паролів облікових записів користувачів повинні зберігатися в файлі / і т.д. / тінь і ніколи в / і т.д. / пароль, який доступний для читання всім користувачам. 2.3.1.6 Переконайтеся, що немає Non-Root рахунку мають UID 0 Ця команда виведе всі записи файлу паролів для облікових записів з ідентифікаторами 0: # AWK -F: '($ 3 == "0") {друк} / і т.д. / пароль Це повинно надрукувати тільки один рядок, для кореневого користувача. Якщо з'являються якісь інші лінії, переконайтеся, що ці додаткові UID-0 рахунків мають право, і що є хороша причина для них існувати. CCE 4009-7 Загалом, кращим рішенням для використання в практиці аудиту кореневої облікового запису, щоб обмежити набір випадків, в яких корінь повинен бути доступний анонімно, вимагаючи використання су або Sudo майже у всіх випадках. Деякі сайти воліють мати більше одного облікового запису з UID 0 для того, щоб розрізняти між адміністраторами, але ця практика може мати несподівані побічні ефекти, і тому не рекомендується. 41 2.3.1.7 встановити параметри Термін дії пароля Редагування файлу /etc/login.defs для завдання параметрів закінчення терміну дії пароля для нових облікових записів. Додати або виправити наступні рядки: PASS_MAX_DAYS 60 PASS_MIN_DAYS 7 PASS_MIN_LEN 14 PASS_WARN_AGE 7 Для кожного існуючого людського користувача USER, змінювати поточні настройки закінчення терміну дії відповідно до даних: # Chage -М 60 -m 7 -W 7 USER CCE 4180-6, 4092-3, 4097-2 Користувачі повинні бути змушені міняти свої паролі, з метою зменшення корисності зламаних паролів. Проте, потрібно міняти паролі часто повинні бути збалансовані з ризиком того, що користувачі будуть повторно використовувати або писати вниз паролі, якщо змушені міняти їх занадто часто. Примус пароль змінюється кожні 90-360 днів, в залежності від охорона навколишнього середовища, рекомендується. Встановіть відповідне значення в якості PASS MAX ДНІВ і застосувати його до існуючих рахунках з прапором -M. PASS MIN ДНІВ (-m) настройка запобігає зміні пароля протягом 7 днів після першого зміни, щоб перешкоджати пароль їзда на велосипеді. Якщо ви використовуєте цей параметр, користувачі поїзда звернутися до адміністратора для екстреного пароля зміна в разі, якщо новий пароль стає під загрозу. PASS WARN AGE установка (-W) надає користувачам 7 днів попередження під час входу в тому, що їх паролі закінчується найближчим часом. PASS MIN LEN параметр, який контролює мінімальну довжину пароля, повинен бути встановлений на все, що потрібно Ваш сайт або організації політики безпеки. Приклад значення 8, представленої тут, може виявитися недостатнім для багатьох середовищ. Дивіться розділ 2.3.3 для отримання інформації про те, як застосовувати більш складні вимоги пароля довжина і якість. 2.3.1.7.1 Видалення пароля параметри з libuser.conf Переконайтеся, що наступний рядок існує в файлі /etc/libuser.conf в розділі [імпорту]. login_defs = /etc/login.defs Крім того, переконайтеся, що ніякі рядки, що починаються з наступними з'являються в розділі [userdefaults] файлу, а ці настройки перевизначення з /etc/login.defs: LU_SHADOWMAX LU_SHADOWMIN LU_SHADOWWARNING Файл /etc/libuser.conf містить параметри конфігурації для бібліотеки libuser, яка призначена для реалізації стандартизований інтерфейс для управління і адміністрування користувачів і груп accouts. За замовчуванням, джерела настройки паролів з /etc/login.defs, але він може змінити ці параметри. Людина сторінка libuser.conf (5) містить більше інформації. 42 ГЛАВА 2. загальносистемних конфігурації 2.3.1.8 Remove Спадщина '+' Записи з файлів паролів команда: # Grep "^ +:" / і т.д. / пароль / і т.д. / тінь / і т.д. / група не повинно виробляти ніякого висновку. CCE 4114-5, 14675-3, 14071-5 Символ + використовується в системах для включення даних з карт NIS в існуючі файли. Проте, певний помилка конфігурації, в якій включення лінії NIS з'являється в / і т.д. / пароль, але NIS не працює, може привести кому-небудь бути в змозі отримати доступ до системи з ім'ям користувача + і без пароля. Тому важливо переконайтеся, що немає такого рядка не виникає ні в одному з відповідних системних файлів. Правильний спосіб сказати, локальну систему проконсультуватися мережевих баз даних, таких як LDAP або NIS для користувача інформації щоб внести відповідні зміни в /etc/nsswitch.conf. 2.3.2 Використання Unix групи для підвищення безпеки Політика контролю доступу, які можуть бути здійснені за допомогою стандартних дозволів Unix обмежені, і настройка SELinux (розділ 2.4) часто є кращим вибором. Проте, це керівництво рекомендує, що безпека буде підвищена наскільки це можливо шляхом застосування політик груп Unix, описаних в даному розділі. 2.3.2.1 створити унікальний групу за замовчуванням для кожного користувача При запуску useradd, не використовуйте прапор -g або іншим чином перевизначити групу за замовчуванням. Red Hat за замовчуванням є те, що кожна нова обліковий запис користувача повинна мати унікальну первинну групу, чиє ім'я збігається з як рахунки. Це значення за замовчуванням, рекомендується, для того, щоб забезпечити додатковий захист від файлів, які створюються з дозволу записи групи включена. 2.3.2.2 Створити і підтримувати групу, яка містить всі людські користувачів Визначити облікові записи всіх користувачів в системі, які відповідають людським користувачам. Залежно від вашої системи конфігурації, це може бути все записи в / і т.д. / пароль з ідентифікаторами значень щонайменше 500. Після того, у вас є визначили такий набір користувачів, створити групу під назвою знаходяться групи (замінити якусь назву, що відповідають вашому довкілля) та заповнити його з кожною людиною-користувачем: # GroupAdd участь в групах # Usermod -G human1 група користувачів # Usermod -G human2 група користувачів ... # Usermod -G humanN група користувачів Потім змініть процедуру для створення нових облікових записів користувачів шляхом додавання -G до знаходяться групи набору прапорів з яка useradd викликається, так що нові людські користувачі будуть розміщені в правильній групі за замовчуванням. Створення групи людських користувачів не саме по собі, підвищити безпеку системи. Проте, як ви працюєте на забезпечення ваша система, ви будете часто знаходити команди, які ніколи не повинні бути запущені за допомогою системних облікових записів, або які тільки 43 коли-небудь потрібні користувачам, зареєстрованим в графічній консолі (яка повинна тільки коли-небудь бути доступними для людини користувачів, навіть на робочих станціях). Після того, як група користувачів була створена, легко обмежити доступ до даної команді, для екземпляр / шлях / до / графічний / команда, для авторизованих користувачів: # Команда chgrp група користувачів / шлях / до / графічний / команда # CHMOD 750 / шлях / графічний / команда Без групи людських користувачів, необхідно обмежити доступ, якимось чином запобігаючи кожну обліковий запис системи від запуску команди, яка є схильною до помилок процес, навіть якщо це взагалі можливо. 2.3.3 Protect Рахунковим Налаштування PAM PAM або вставні модулі аутентифікації, це система, яка реалізує модульну аутентифікацію для Linux програм. PAM є основою, яка забезпечує архітектуру аутентифікації системи і можуть бути налаштовані щоб звести до мінімуму вплив вашої системи до невиправданого ризику. Цей розділ містить рекомендації про те, як виконати що і як забезпечити, щоб модулі, використовувані конфігурації PAM роблять те, що вони повинні робити. РАМ реалізований у вигляді набору спільно використовуваних об'єктів, які завантажуються і викликаються щоразу, коли додаток побажання для аутентифікації користувача. Як правило, програма має бути запущено з правами адміністратора для того, щоб скористатися РАМ. Традиційні привілейовані мережі слухачів (наприклад, SSHd) або програми SUID (наприклад, Sudo) вже задовольняють цій вимозі. SUID корінь додатки, userhelper, забезпечується так, щоб програми, які не є SUID або привілейована самі можуть як і раніше скористатися РАМ. PAM виглядає в каталозі /etc/pam.d для інформації про конфігурацію конкретного додатка. Наприклад, якщо Програма Ввійти намагається перевірити справжність користувача, а потім бібліотеки Пем дотримуйтесь інструкцій в файлі / і т.д. / pam.d / Увійти, щоб визначити, які дії слід зробити дії. Один дуже важливий файл в /etc/pam.d є /etc/pam.d/system-auth. Цей файл, який включений багато інших файли конфігурації PAM, визначає заходи перевірки автентичності системи "за замовчуванням". Зміна цього файлу є хорошим способом робити далекосяжні зміни аутентифікації, наприклад, при впровадженні централізованої служби аутентифікації. Будьте обережні при внесенні змін до файли конфігурації Пем. Синтаксис для цих файлів є складним, і модифікації може мати несподівані consequences.1 конфігурації за замовчуванням поставляється з набором додатків повинні бути досить для більшості користувачів. Запуск AuthConfig або системи-конфігурації-аутентифікації буде переписувати конфігурацію PAM файли, знищуючи будь-які вручну зроблені зміни і заміни їх з серією системних налаштувань за замовчуванням. 2.3.3.1 Встановити вимоги до якості Пароль Модуль CrackLib РАМ РАМ за замовчуванням забезпечує перевірку паролів сили. Він виконує ряд чеки, такі як переконавшись, що паролі не схожі слів зі словника, мають принаймні певної довжини, є є не попередній пароль зворотна, а не просто зміна випадку в порівнянні з попереднім паролем. Він може також вимагають паролі, щоб бути в певних класах символів. Модуль PAM РАМ passwdqc забезпечує можливість застосовувати заходи ще більш жорсткі вимоги до надійності пароля. Це передбачено в RPM з тим же ім'ям. Сторінки людини РАМ CrackLib (8) і Пем passwdqc (8) надати інформацію про можливості та конфігурації кожного. 1One посилання на синтаксис файлу конфігурації можна знайти на сайті http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/ SAG-конфігурації-file.html. 44 ГЛАВА 2. загальносистемних конфігурації CCE 3762-2 2.3.3.1.1 встановити вимоги до якості Пароль, при використанні Pam Cracklib Модуль РАМ CrackLib PAM можна налаштувати відповідно до рекомендацій для систем Міністерства оборони, як зазначено в [12]. Для настройки РАМ Cracklib вимагати щонайменше один символ верхнього регістру, символ нижнього регістра, цифри, а також інші (Спеціальний) характер, знайдіть наступний рядок в /etc/pam.d/system-auth: пароль умовою pam_cracklib.so try_first_pass повторних спроб = 3 а потім змінити його для читання (розміщення тексту на одному рядку, що неможливо тут): Може знадобитися пароль pam_cracklib.so try_first_pass повторити = 3 minlen = 14 \ dcredit = -1 ucredit = -1 ocredit = -1 lcredit = -1 При необхідності змінити аргументи для забезпечення дотримання політики безпеки вашої організації. Зверніть увагу, що вимоги до якості пароля не застосовуються для кореневої облікового запису з деяких причин. CCE 14113-5, 14672-0, 14712-4, 14122-6, 14701-7, 15054-0 2.3.3.1.2 встановити вимоги до якості Пароль, при використанні Pam passwdqc Якщо сила пароля сильніше, ніж гарантується Pam CrackLib потрібно, налаштувати PAM для використання РАМ passwdqc. Для активації Pam passwdqc знайдіть наступний рядок в /etc/pam.d/system-auth: пароль умовою pam_cracklib.so try_first_pass повторних спроб = 3 а потім замінити його на лінії: пароль реквізиту pam_passwdqc.so хв = відключено, інвалідів, 16,12,8 При необхідності змінити аргументи (хв = відключено, інвалідів, 16,12,8), щоб забезпечити дотримання умов Політика безпеки організації. Параметри конфігурації описані в довідковій сторінці Pam passwdqc (8), а також в / USR / частки / DOC / Pam passwdqc-версії. Мінімальні довжини, наведені тут скасовують, що вказано аргументом PASS MIN LEN, як описано в розділі 2.3.1.7. Параметри, наведені в прикладі вище, встановити мінімальну довжину для кожного з пароля "класів", що Пем passwdqc визнає. Установка певного мінімального значення, щоб відключити зупинить користувачів від вибору пароля, що потрапляє в одній тільки цій категорії. 2.3.3.2 Установка Локаути для невдалих спроб введення пароля Модуль РАМ tally2 PAM забезпечує можливість блокування облікових записів користувачів після низки невдалих входу в систему спроби. Його документація доступна в /usr/share/doc/pam-version/txts/README.pam tally2. Поведінка Pam tally2 змінилося протягом всього терміну служби RHEL 5. Раніше керівництво є відрізняється від того, що зазначено тут, і це керівництво не може функціонувати належним чином на системах RHEL що не в курсі. 45 Якщо блокування рахунку після того, як ряд невдалих спроб входу в систему потрібно вашій політики безпеки, здійснювати Використання РАМ tally2.so. Для того, щоб забезпечити дотримання пароля блокування, додайте наступні рядки в /etc/pam.d/system-auth. По-перше, додати в верхній частині Auth лінії: Auth потрібно pam_tally2.so заперечую = 5 onerr = потерпіти невдачу unlock_time = 900 По-друге, додати в верхній частині рахунку ліній: рахунок потрібно pam_tally2.so Налаштуйте аргумент відмовити (який контролює, скільки спроб дозволені до того, як обліковий запис буде заблокована) і час розблокування аргумент (який контролює, скільки секунд пройти, перш ніж обліковий запис автоматично розблоковано), щоб відповідати вашій політики безпеки системи. Корисність РАМ tally2 також може бути використаний, щоб розблокувати користувача рахунки в такий спосіб: # / SBIN / pam_tally2 --user ім'я користувача --reset CCE 3410-8 Блокування з облікових записів користувачів становить ризик атаки на відмову в обслуговуванні. Політика безпеки щодо системи локаут повинен зважити ризик атаки на відмову в обслуговуванні проти рахунку проти переваг зриві підбору пароля атаки. Час розблокування аргумент може бути використаний для регулювання цього ризику. 2.3.3.3 Використання РАМ deny.so швидко заборонити доступ до служби Для того, щоб заборонити доступ до сервісних SVCNAME через PAM, відредагувати файл /etc/pam.d/SVCNAME. PREPEND цей рядок на початку файлу: Auth умовою pam_deny.so У більшості випадків, є більш ефективні способи, щоб відключити службу, ніж заборонити доступ через PAM. Проте, цей має вистачити як спосіб швидко зробити сервіс недоступним для майбутніх користувачів (існуючих сесій, які вже аутентифікований, не будуть зачіпатися). Необхідний тег повідомляє ПАМ, що, якщо зазначений модуль повертає збій, Аутентифікація повинна потерпіти невдачу, і PAM слід негайно припинити обробку файлу конфігурації. РАМ deny.so Модуль завжди повертає відмова незалежно від його входу. 2.3.3.4 Обмеження Виконання userhelper до консолі користувачів Якщо ваша середу визначилася групу, яка містить всі група користувачів людських користувачів вашої системи, обмежити виконання програми userhelper тільки цієї групи: # Команда chgrp група користувачів / USR / SBIN / userhelper # CHMOD 4710 / USR / SBIN / userhelper CCE 4185-5, 3952-9 Програма userhelper забезпечує аутентифікацію для графічних послуг, які повинні працювати з кореневими привілеями, таких як система-config- сімейство графічних утиліт конфігурації. Тільки людські користувачі увійшли в систему консоль, ймовірно, коли-небудь мають законне необхідність запуску цих утиліт. Цей крок забезпечує деякий захист проти можливі недоліки в реалізації userhelper, і проти подальшої ескалації привілеїв, коли системні облікові записи скомпрометовані. Дивіться Розділ 2.3.2.2 для отримання додаткової інформації про створення групи людських користувачів. 46 ГЛАВА 2. загальносистемних конфігурації Програма userhelper конфигурируется файлів в /etc/security/console.apps/. Кожен файл визначає, для якась програма, який користувач програма повинна працювати, як і те, що програма повинна бути виконана після успішного аутентифікації. Примітка: Конфігурація в /etc/security/console.apps/ застосовується в поєднанні з конфігурацією РАМ служби, визначеної в /etc/pam.d/. По-перше, userhelper визначає, що користувач сервіс повинен працювати як. (Як правило, це буде корінь.) Далі, userhelper використовує PAM API, щоб дозволити користувачеві, який виконав програму по спроба аутентифікації в якості необхідного користувача. Обмін PAM API загортають в GUI, якщо додатки Конфігурація запитує один. 2.3.3.5 Оновлення хеширования паролів Алгоритм SHA-512 Для того, щоб налаштувати систему, щоб використовувати алгоритм SHA-512, три файли повинні бути відредаговані. 2.3.3.5 Оновлення хеширования паролів Алгоритм SHA-512 Для того, щоб налаштувати систему, щоб використовувати алгоритм SHA-512, три файли повинні бути відредаговані. По-перше, відредагувати файл /etc/pam.d/system-auth, щоб гарантувати, що SHA512 використовується РАМ unix.so модуля в розділ пароля, замінюючи будь-які інші алгоритми (наприклад, md5, bigcrypt, Blowfish або SHA256) з SHA512, як показано на малюнку: пароль досить pam_unix.so sha512 тінь nullok try_first_pass use_authtok По-друге, редагування файлу /etc/login.defs, щоб додати або виправити такі рядки: MD5_CRYPT_ENAB немає ENCRYPT_METHOD SHA512 По-третє, відредагувати файл /etc/libuser.conf, щоб додати або виправити такий рядок: crypt_style = sha512 Коли користувач змінює свої паролі, хеші для нових паролів буде генеруватися за допомогою SHA-512 Алгоритм. CCE 14063-2 Алгоритм за замовчуванням для зберігання хеш в більш ранніх версіях Red Hat Enterprise Linux 5 був MD5. У випуску 5.2 (і для тих систем, повністю оновлені з моменту його випуску), алгоритми SHA-256 і SHA-512 доступні. Примітки до випуску можна отримати в http://www.redhat.com/docs/en-US/Red~~HEAD=pobj Hat Enterprise Linux / 5.2 / HTML / Release Notes / сингли / relnotesU2-x86.html документ це зміна. Як вже зазначалося, є лише kickstartinstalled Системи можуть бути налаштовані, щоб почати роботу з цим алгоритмом. Інші системи повинні мати це команда видається, а потім все облікові записи потрібно буде виконати зміна пароля для того, щоб оновити збережений хеші до сильніших алгоритмом. 2.3.3.6 Обмеження пароля Повторне використання Не дозволяє користувачам повторно використовувати останні паролі. Це може бути досягнуто шляхом використання пам'ятайте варіант для Модуль РАМ Unix РАМ. Для того, щоб заборонити йому повторно використовувати будь-якої зі своїх останніх 5 паролів, додайте пам'ятайте = 5 для рядка пароля, який використовує Пем UNIX модуль у файлі /etc/pam.d/system-auth, як і показано: пароль досить pam_unix.so existing_options запам'ятати = 5 CCE 14939-3 Старий (і, отже, більше не діє) паролі зберігаються у файлі / і т.д. / безпека / opasswd. 47 2.3.3.7 Видалити РАМ ccreds пакет, якщо це можливо Якщо ви не бажаєте його облікові функції кешування, видаліть пакет РАМ ccreds: # Ням видалити Пем ccreds Пакет РАМ ccreds містить УИП програму / USR / SBIN / ccreds Validate і повинні бути видалені якщо вона не забезпечує необхідну функціональність. Будь-які облікові дані кешуються в системі також буде порушена, якщо зловмисник отримує контроль над системою. 2.3.4 Файли Secure Session Configuration для входу в систему облікових записів Коли користувач входить в обліковий запис Unix, система налаштовує сеанс користувача шляхом зчитування кількості файлів. Багато з цих файлів знаходяться в домашньому каталозі користувача, і може мати слабкі дозволу в результаті помилки користувача або неправильними. Якщо зловмисник може змінити або навіть читати певні типи конфігурації облікового запису інформацію, він часто може отримати повний доступ до облікового запису потерпілого користувача. Тому, важливо, щоб перевірити і правильні права доступу до файлів конфігурації для інтерактивних рахунків, особливо привілейованих користувачів, таких як корінь або системні адміністратори. 2.3.4.1 Переконайтеся, що ні про які небезпечних рейтингів не існує в Path Root, Активний шлях кореневої облікового запису може бути отриманий шляхом запуску нової кореневої оболонки і запуск: # Ехо $ PATH Це дасть двокрапкою список каталогів, розділених на шляху. Важливо, щоб запобігти корінь від виконання невідомих і ненадійних програм, так як такі програми можуть містити шкідливий код. Таким чином, корінь не слід запускати програми, встановлені непривілейованих користувачів. Так як корінь часто може працювати всередині ненадійних каталогів, то. символ, який представляє поточний каталог, ніколи не повинно бути в кореневому каталозі, ні якщо будь-який каталог, який може бути записаний на непривілейованих або напів-привілейованого (система) користувач. У наступних розділах описані деякі елементи, які не слід розглядати в шляху суперкористувача. Це хороша практика для адміністраторів, щоб завжди виконувати привілейовані команди, ввівши повний шлях до настановних команда. CCE 3301-9 2.3.4.1.1 Переконайтеся в тому, що шлях до кореневої не включає відносні шляхи або нульовий каталогів Для кожного каталогу DIR в дорозі, переконайтеся, що DIR не дорівнює одному. характер, або що вона містить будь-які випадки, які призводять до відносного шляху обходу, наприклад .. або початок шлях без косої риски (/) характер. Крім того, переконайтеся, що немає "порожніх" елементів в дорозі, такі, як в цих прикладах: PATH =: / бен PATH = / бен: PATH = / бен :: / SBIN Ці порожні елементи мають один і той же ефект, що і один. характер. 48 ГЛАВА 2. загальносистемних конфігурації 2.3.4.1.2 Переконайтеся в тому, що шлях до кореневої не включає всесвітньо-записувані або перезапису Group Довідники Для кожного елемента в дорозі, виконайте наступну команду: # Ls -ld DIR і переконайтеся, що дозволу записи відключені для групи та інших. CCE 14957-5 2.3.4.2 Переконайтеся, що домашні каталоги користувачів не Група незапісиваемий або доступний для читання Розділи 2.3.4.2-2.3.4.5 рекомендує модифікувати домашні каталоги користувачів. Повідомте ваше співтовариство користувачів, і запросити введення, якщо це необхідно, перш ніж зробити цей тип змін. Для кожної людини користувача користувача системи, переглянути дозволи домашнього каталогу користувача: # -ld Ls / Головна / USER Переконайтеся, що каталог не доступний для запису групу і що він не доступний для читання. При необхідності, відремонтувати дозволу: # CHMOD г-ж / головна / USER # CHMOD о-RWX / головна / USER CCE 4090-7 Домашні каталоги користувачів містять багато конфігураційних файлів, які впливають на поведінку облікового запису користувача. немає облікового запису повинні коли-небудь мати дозвіл на запис в домашній каталог іншого користувача. Група спільно каталоги можуть бути налаштовані в підкаталогах або де-небудь в файлової системі, якщо вони необхідні. Як правило, домашні каталоги користувачів не повинні бути доступний для читання. Якщо підмножина користувачів потрібен доступ на читання до один одному домашніх каталогів, це може бути забезпечено за допомогою груп. 2.3.4.3 Переконайтеся, що користувач Dot-файли не є Світ-записувані Для кожної людини користувача користувача системи, переглянути дозволи всіх дот-файлів в домашньому каталозі користувача: # Ls -ld / головна / USER /.[A-Za-z0-9]* Переконайтеся в тому, що жоден з цих файлів не є групи- або всесвітньо доступний для запису. Виправити кожен файл неправильно налаштоване файл, виконавши наступну команду: # CHMOD йти ж / головна / USER / FILE Користувач, який може змінювати конфігураційні файли іншого користувача, ймовірно, може виконувати команди з іншого користувача привілеї, включаючи крадіжку даних, знищуючи файли або запускати нові атаки на систему. 49 2.3.4.4 Переконайтеся, що користувачі мають розумні значення UMASK 1. Змініть глобальні конфігураційні файли / і т.д. / профіль, / і т.д. / Bashrc і /etc/csh.cshrc. Додати або виправити лінія: Umask 077 2. Змінити користувача файл визначень /etc/login.defs. Додати або виправити рядок: UMASK 077 3. Перегляньте додаткові конфігураційні файли /etc/csh.login і /etc/profile.d/*, і не дозволить жодному з цих файлів перевизначити біти повноважень на більш дозволяючого значення, якщо немає хорошої причини для цього. 4. Зміна кореневої оболонки файли конфігурації /root/.bashrc, /root/.bash профіль, /root/.cshrc, і /root/.tcshrc. Додати або виправити рядок: Umask 077 CCE 3844-8, 4227-5, 3870-3, 14107-7, 14847-8 При установці за замовчуванням в UMASK з 077, файли і каталоги, створені користувачами, які не будуть читатися будь-яким іншим користувачем системи. Користувачі, які хочуть, щоб зробити певні файли групи- або доступний для читання можна виконати за допомогою команда CHMOD. Крім того, користувачі можуть зробити всі свої файли читаються в своїй групі за замовчуванням, встановивши Umask з 027 в їх файлах конфігурації оболонки. Якщо за умовчанням для кожного користувача групи існують (тобто, якщо кожен користувач має за замовчуванням група, чиє ім'я збігається з ім'ям користувача і чиїм єдиним елементом є користувачем даного користувача), то це може бути навіть безпечно для користувачів, щоб вибрати з 007 біти повноважень, що робить його дуже легко навмисно обмінюватися файлами з групами яких користувач є членом. Крім того, може виникнути необхідність змінити біти повноважень суперкористувача тимчасово для того, щоб встановити програмне забезпечення або файли, які повинен бути доступний для читання іншими користувачами, або змінити umasks за замовчуванням певних облікових записів служб, таких як FTP користувач. Однак, встановивши обмежувальне значення за замовчуванням захищає файли користувачів, які не вживають ніяких кроків, щоб зробити свої файли доступнішими, а також запобігання файлів від ненавмисного спільно. 2.3.4.5 Переконайтеся, що користувачі не мають .netrc файлів Для кожної людини користувача користувача системи, переконайтеся, що користувач не має файлу .netrc. команда: # Ls -l / головна / USER /.netrc не повинен повертати повідомлення про помилку "Немає такого файлу або каталогу". Якщо який-небудь користувач має такий файл, наближатися до цього користувачеві, щоб обговорити видалення цього файлу. Файл .netrc конфігураційний файл використовується для автоматичної логіни до інших систем за допомогою FTP. Коли цей файл існує, то він часто містить незашифровані паролі, які можуть бути використані для атак на інші системи. 2.3.5 Захист доступу фізичної консолі Неможливо повністю захистити систему від зловмисника з фізичним доступом, тому забезпечити простір, в якому система розташована слід вважати необхідним кроком. Проте, є деякі кроки, які, якщо взяти, зробити його більш важким для атакуючого швидко або невиявна модифікувати систему з консолі. 50 ГЛАВА 2. загальносистемних конфігурації 2.3.5.1 Встановити пароль BIOS BIOS (на x86 системах) є перший код для виконання при запуску системи і контролює багато важливих параметри системи, в тому числі, які пристрої система буде намагатися завантажитися з, і в якому порядку. Призначте пароль, щоб запобігти несанкціонованому зміна конфігурації BIOS. Точні кроки будуть варіюватися в залежності від вашої машини, але, ймовірно, включають в себе: 1. Перезавантажте машину. 2. Натисніть потрібну клавішу при початковому екрані завантаження (F2 характерно). 3. Перейдіть в меню настройки BIOS, щоб додати пароль. Точний процес буде конкретної системи і апаратних засобів по експлуатації системи може надати докладні інструкції. Цей пароль повинен запобігти зловмисників з фізичним доступом від спроб змінити важливі параметри, таких, як ті, що зазначені у пунктах 2.5.2.2.1 і 2.2.2.2.4. Проте, зловмисник, який має фізичний доступ може, як правило, очистити пароль BIOS. Пароль повинен бути записаний і зберігатися в фізично безпечному місці, наприклад як сейф, в тому випадку, якщо вона забута і повинна бути відновлена. 2.3.5.2 Встановити пароль завантажувача Під час процесу завантаження, завантажувач відповідає за запуск виконання ядра і передачі опції до нього. Завантажувач дозволяє вибирати з різних ядер - можливо, на різних розділах або ЗМІ. Опції вона може пройти до ядру включити "однокористувальницький режим", який забезпечує кореневої доступ без будь-яких аутентифікації, а також можливість відключити SELinux. Для запобігання локальних користувачів від зміни параметрів завантаження і поставити під загрозу безпеку, конфігурація завантажувача повинен бути захищений паролем. завантажувач RHEL за замовчуванням для систем x86 називається GRUB. Щоб захистити свою конфігурацію: 1. Виберіть пароль, а потім згенерувати хеш від нього, виконавши: # Grub-md5-крипт 2. Вставте наступний рядок в /etc/grub.conf відразу після коментарів заголовка. (Використовуйте вихід від шпильок-md5-крипти в якості значення пароля-хеш): встановлений пароль --md5 пароля хеш 3. Перевірте дозволу на /etc/grub.conf (який є символічним посиланням на ../boot/grub/grub.conf): # Чаун корінь: корінь /etc/grub.conf # CHMOD 600 /etc/grub.conf CCE 4144-2, 3923-0, 3818-2, 4197-0 Завантажники для інших платформ повинні запропонувати аналогічну функцію захисту паролем. 2.3.5.3 Аутентификация при режимі одного Однокористувацький режим призначений в якості способу відновлення системи, забезпечуючи єдиний кореневої доступ користувача до системи, забезпечуючи варіант завантаження при запуску. За замовчуванням аутентифікація не виконується, якщо обраний режим на одного користувача. Це забезпечує тривіальний механізм обходу безпеки на машині і отримати кореневої доступ. 51 Щоб вимагати введення пароля користувача root, навіть якщо система запускається в режимі одного, додайте наступне рядок в файлі inittab / і т.д. /: ~: S: чекати: / SBIN / sulogin CCE 4241-6 2.3.5.4 Відключити Інтерактивна завантаження Відредагуйте файл / і т.д. / sysconfig / ініціалізації. Додати або виправити налаштування: ПОДСКАЖИТЕ = немає CCE 4245-7 ПОДСКАЖИТЕ опція дозволяє користувачеві консолі виконувати інтерактивний запуск системи, в якій це можливо виберіть набір служб, які запускаються при завантаженні системи. Використання інтерактивної завантаження, користувач консолі може відключити аудит, брандмауерів, або інші послуги, ослаблення безпеки системи. 2.3.5.5 Реалізація неактивності Тайм-аут для оболонок реєстрації Якщо система не працює X Windows, то для входу оболонки можуть бути налаштовані для автоматичного входу користувачів після період бездіяльності. Наступні інструкції не практичні для систем, які керують X Windows, так як вони закриє вікна терміналу в середовищі X. Для отримання інформації про те, як автоматично блокувати ці системи, дивіться Розділ 2.3.5.6. Для реалізації 15-ти хвилин простою тайм-аут за замовчуванням / бен / Баш оболонки з, створіть новий файл tmout.sh в каталог /etc/profile.d з наступними рядками: TMOUT = 900 TMOUT тільки для читання експорт TMOUT Для реалізації 15-ти хвилин простою тайм-аут для Tcsh оболонки, створіть новий autologout.csh файл в каталозі /etc/profile.d за допомогою наступного рядка: комплект -r autologout 15 Подібні заходи повинні бути прийняті для будь-яких інших реєстраційних оболонок, використовуваних. CCE 3689-7, 3707-7 Приклад тайм-аут тут 15 хвилин повинен бути налаштований на те, що ваша політика безпеки вимагає. тільки для читання рядка для Баш і опцією -r для Tcsh можна опустити, якщо політика дозволяє користувачам перевизначити значення. Автоматичний вихід з системи оболонки відбувається тільки тоді, коли оболонка є основним процесом. Якщо, наприклад, VI сесія не діє, то автоматичний вихід не відбудеться. При вході в систему через віддалене підключення, як і з SSH, це може бути більш ефективним, щоб встановити значення тайм-ауту безпосередньо через цю службу. Щоб дізнатися, як встановити автоматичні інтервали тайм-ауту для SSH, дивіться Розділ 3.5.2.3. 52 ГЛАВА 2. загальносистемних конфігурації 2.3.5.6 Встановити блокування екрану Коли користувач повинен тимчасово залишити обліковий запис увійшов в систему, блокування екрану повинні бути використані для запобігання перехожим від зловживання облікового запису. Навчання користувачів та навчання особливо важливо для екрану блокування, щоб бути ефективними. Політика повинна бути реалізована, яка навчає всіх користувачів, щоб заблокувати екран, коли вони планують тимчасово відійти від увійшов в обліковому записі. Автоматичний замок екран призначений тільки в якості запобіжного заходу для тих випадків, коли користувач забув заблокувати екран. 2.3.5.6.1 Встановити блокування екрану графічного інтерфейсу користувача В робочому столі GNOME за замовчуванням, екран може бути заблокований шляхом вибору блокування екрану в меню System. Програма gconftool-2 може бути використаний для забезпечення дотримання обов'язкових параметрів блокування екрану для GNOME за замовчуванням навколишнє середовище. Виконайте наступні команди для забезпечення холостого ходу активації заставки, блокування екран, порожній екран заставки, і 15 хвилин часу простою активація: # Gconftool-2 --direct \ --config-джерело XML: читання і запис: /etc/gconf/gconf.xml.mandatory \ --type Ьоо \ --set / додатки / гном-заставка / idle_activation_enabled правда # Gconftool-2 --direct \ --config-джерело XML: читання і запис: /etc/gconf/gconf.xml.mandatory \ --type Ьоо \ --set / додатки / гном-заставка / lock_enabled правда # Gconftool-2 --direct \ --config-джерело XML: читання і запис: /etc/gconf/gconf.xml.mandatory \ --type рядок \ Режим --set / додатки / гном-заставка / порожній тільки # Gconftool-2 --direct \ --config-джерело XML: читання і запис: /etc/gconf/gconf.xml.mandatory \ --type INT \ --set / додатки / гном-заставка / idle_delay 15 CCE 3315-9, 3910-7, 14604-3, 14023-6, 14735-5 Установка 15 хвилин простою активації є розумним для багатьох офісних умовах, але установка повинна відповідати будь-політика визначена. Режим заставки порожній тільки обраний, щоб приховати вміст дисплей з перехожими. Оскільки користувачі повинні бути навчені, щоб заблокувати екран, коли вони відійти від комп'ютера, автоматичного замикаючого Функція призначена тільки в якості резервного. Значок блокування екрану в меню системи також можна перетягнути в панель завдань, з тим щоб полегшити ще зручнішим екраном синхронізації мод. Коренева обліковий запис не може бути екрана заблокована, але це не повинно мати ніякого практичного ефекту в якості кореневого рахунку повинен ніколи не буде використовуватися для входу в середовищі X Windows, і повинні використовуватися тільки для прямого входу в систему за допомогою консолі в надзвичайні обставини. Для отримання додаткової інформації про налаштування заставки GNOME см http://live.gnome.org/GnomeScreensaver. Додаткові відомості про забезпечення переваг в середовищі GNOME з використанням конфігурації GConf системи см http://www.gnome.org/projects/gconf і сторінка людини gconftool-2 (1). 53 2.3.5.6.2 Встановити блокування екрану консолі Механізм блокування консолі екран передбачений в пакеті vlock, який не встановлений за замовчуванням. Якщо можливість блокування консолі екранів необхідно, встановіть пакет vlock: # Ням встановити vlock Попросіть користувачів викликати програму, коли це необхідно для того, щоб запобігти перехожих від зловживання логін: $ vlock Опція -a може бути використаний для запобігання перемикання на інші віртуальні консолі. 2.3.5.7 відключити непотрібні порти Хоча незвично, деякі системи можуть управлятися тільки віддалено, і все ж також піддаються ризику з нападників з прямий фізичний доступ до них. У цих випадках зменшують доступ зловмисника до системи шляхом відключення непотрібних зовнішні порти (наприклад, USB, FireWire, NIC) в BIOS системи. Відключення USB-портів особливо незвично і викличе проблеми для важливих пристроїв введення такі як клавіатури або миші, підключених до системи. Відключення портів в системі, які не є необхідними для нормальної роботи системи. Точні кроки будуть змінюватися в залежності від вашої машини, але, ймовірно, включають в себе: 1. Перезавантажте машину. 2. Натисніть потрібну клавішу під час початкового екрану завантаження (F2 характерно). 3. Перейдіть в меню BIOS conguration, щоб відключити порти, такі , Як USB, FireWire, і мережевий адаптер. 2.3.6 Використання централізованої Служба перевірки автентичності Централізована служба аутентифікації є будь-який спосіб підтримки централізованого контролю над рахунком і аутентифікації даних і зберігання цих даних, синхронізованих між машинами. Такі послуги можуть варіюватися по складності від А скрипт, який виштовхує централізовано генеруються файли паролів до всіх машин, до керованої схемою, такі як LDAP або Kerberos. Якщо інформація про аутентифікації не керується централізовано, вона швидко стає непослідовним, що призводить до застарілий повноваження і забуті рахунки, які повинні були бути видалені. Крім того, багато старих протоколи (наприклад, NFS) роблять використання UID для ідентифікації користувачів по мережі. Це не дуже хороша практика, і ці протоколи слід уникати, якщо це можливо. Однак, оскільки більшість сайтів повинні як і раніше використовувати деяких старих протоколів, що мають послідовні UIDs і ГІД на веб-сайті є суттєвою перевагою. Централізовані служби перевірки справжності мають той недолік, що інформація про аутентифікації повинна бути передана через мережу, що призводить до ризику, що облікові дані можуть бути перехоплені або замінений. Таким чином, ці послуги повинні бути ретельно розгорнуті. Наступні запобіжні заходи повинні бути прийняті під час налаштування будь-аутентифікації обслуговування: ?? Переконайтеся в тому, що відомості про перевірку автентичності та конфіденційну інформацію про обліковий запис ніколи не надсилаються над мережі в незашифрованому вигляді. ?? Переконайтеся в тому, що коренева обліковий запис має локальний пароль, щоб забезпечити відновлення в разі збою в роботі мережі або аутентифікації відмови сервера. 54 ГЛАВА 2. загальносистемних конфігурації Даний посібник рекомендує використовувати LDAP. Безпечна конфігурація OpenLDAP для клієнтів і серверів описується в розділі 3.12. Kerberos також є хорошим вибором для централізованої служби аутентифікації, але опис його конфігурація виходить за рамки даного керівництва. Служба NIS не рекомендується, і їх слід розглядати застаріли. (Дивіться розділ 3.2.4.) 2.3.7 Попередження Банери для доступів до системи Кожна система повинна розкрити як мало інформації про себе, як це можливо. Системні банери, які зазвичай відображаються безпосередньо перед підказки входу видають інформацію про послугу або операційної системи хоста. Це може включати в себе назву дистрибутива і версію системи ядро, і конкретна версія мережевого сервісу. Ця інформація може допомогти зловмисникам в отриманні доступу до системи, як це може визначити, чи є система працює вразливе програмне забезпечення. Більшість мережевих послуг можуть бути налаштовані, щоб обмежити яка інформація з'явиться. Багато організацій здійснюють політику безпеки, які вимагають системного банера надати повідомлення з системи власність, забезпечити попередження несанкціонованих користувачів, і нагадати авторизованим користувачам про свою згоду на моніторинг. 2.3.7.1 Зміна входу в систему Банер Вміст файлу / і т.д. / випуску відображаються на екрані безпосередньо над запрошення входу для реєстрації користувачів безпосередньо в термінал. Програми віддаленого входу в систему, такі як SSH або FTP може бути налаштований для відображення / і т.д. / питання так само. Інструкції по налаштуванню кожного демона сервера, щоб показати цей файл можна знайти у відповідних розділах Глава 3. За замовчуванням система буде відображати версію операційної системи, версії ядра і імені хоста. Редагувати / і т.д. / питання. Замінити текст за замовчуванням з повідомленням, сумісному з локальною політикою сайту або юридична відмова від відповідальності. CCE 4060-0 2.3.7.2 Впровадження GUI Попередження Банер У графічному середовищі за замовчуванням, користувачі реєструвалися безпосередньо в систему зустрічають з екрану входу в систему за умови, менеджером дисплея GNOME. Попередження банер повинен відображатися в цій графічному середовищі для цих користувачів. Файли по темі RHEL за замовчуванням можна знайти в / USR / частки / GDM / теми / RHEL. Додайте наступний код зразок блок XML для /usr/share/gdm/themes/RHEL/RHEL.xml після перших двох "Pixmap" записів: <Елемент типу = "прямокутник" ID = "замовлення DoD-банер"> <Поз якір = "північний захід" х = "20%" у = "10" ширина = "80%" висота = "100%" /> <Вікно> <Тип елемента = "ярлик"> <Звичайний шрифт = "Sans Жирний 9" колір = "# FFFFFF" /> <Текст> Вставте текст вашого попередження банер тут. 55 CCE 4188-9 Повний синтаксис, що файли теми GDM очікувати документована в іншому місці, але вище XML створить текстове поле в правому верхньому куті екрану. Шрифт, колір тексту, а також точне позиціювання всі вони можуть бути легко змінені редагування відповідні значення. Останні струму по експлуатації GDM тему можна знайти на сайті http://library.gnome.org/ адмін / GDM / 2.16 / thememanual.html.en. 2.4 SELinux SELinux є особливістю ядра Linux, яка може використовуватися для захисту від неправильно або скомпрометований програм. SELinux підсилює ідею, що програми повинні бути обмежені в файли, які вони можуть отримати доступ і що дії, які вони можуть зробити. Політика SELinux за умовчанням, відповідно до настройками на RHEL5, була досить розвинена і налагоджена, що воно повинні бути доступні практично на будь-якій машині Red Hat з мінімальною конфігурацією і невеликою кількістю системи Адміністратор навчання. Ця політика запобігає системним служби - в тому числі велику частину загальної мережі видимий послуги, такі як поштові сервери, FTP-сервери і DNS-серверів - від доступу до файлів, які мають ці послуги немає вагома причина для доступу. Тільки в цьому дію запобігає величезну кількість можливих пошкоджень від мережевих атак послуги, від trojaned програмного забезпечення, і так далі. Це керівництво рекомендує SELinux включити за допомогою (цільової) політики за замовчуванням на кожній системі Red Hat, якщо такої системи не має вимоги, які роблять більш сильну політику доречним. 2.4.1 Скільки SELinux робіт У традиційній моделі безпеки Linux / Unix, відомий як дискреційного управління доступом (DAC), процеси запускаються під користувача і групової ідентичності, і насолоджуватися тим, що користувачів і групи прав доступу до всіх файлів і інших об'єктів на система. Ця система приносить з собою цілий ряд проблем в області безпеки, в першу чергу: процеси, які часто не потрібні, і не повинні мати повні права користувача, що запустив їх; що права користувача і групи доступу є не надто зерниста, і може знадобитися адміністраторам дозволити занадто багато доступу, щоб дозволити доступ, що потрібен; що файлова система Unix містить багато ресурсів (наприклад, тимчасових каталогів і доступний для читання файли), які доступні для користувачів, які не мають законних підстав для доступу до них; і що законні користувачі можуть легко забезпечити відкритий доступ до своїх власних ресурсів через замішання або неуважності. SELinux надає Access Control (MAC) системи обов'язково, що різко посилили модель DAC. під SELinux, кожен процес і кожен об'єкт (наприклад, файл, сокет, труби) на системі дається контекст безпеки, а етикетки, які включають в себе детальний тип інформації про об'єкт. Ядро дозволяє процеси доступу до об'єктів тільки в тому випадку, що доступ явно дозволено політикою в дію. Політика визначає переходи, так що користувач може бути дозволено запускати програмне забезпечення, але програмне забезпечення може працювати під іншому контексті, ніж за замовчуванням користувача. це автоматично обмежує збитки, що програмне забезпечення може зробити для файлів, доступних користувачеві виклику - користувач робить не потрібно робити ніяких дій, щоб отримати цю вигоду. Для дію, яке має відбутися, як традиційні права ЦАП повинні бути satisifed, а також правила MAC SELinux в. Якщо будь-яка не дозволяють дію, то воно не буде дозволено. Таким чином, правила SELinux може зробити тільки дозволів системи більш обмежувальний характер і безпечною. SELinux вимагає комплексної політики, з тим щоб забезпечити всі необхідні дії системи при нормальній роботі. Три такі політики були розроблені для використання з RHEL5, і включені в систему. при збільшенні 56 ГЛАВА 2. загальносистемних конфігурації порядок потужності і складності, вони: орієнтовані, строгі і МСС. Цільова політика SELinux складається в основному Type Enforcement (TE) правила і невелика кількість ролей Управління доступом на основі ролей (RBAC) правил. це обмежує дії багатьох типів програм, але залишає інтерактивних користувачів в основному без змін. строгий Політика також використовує правила TE і RBAC, але на більшій кількості програм і більш агресивно. МЛ політики реалізує Multi-Level Security (MLS), який вводить ще більше видів етикеток - чутливість і категорія - і правила які регулюють доступ на їх основі. Частина, що залишилася цього розділу містить керівництво по конфігурації цільової політики та адміністрації систем в рамках цієї політики. будуть надані деякі покажчики для читачів, які зацікавлені в подальшому зміцнення їх систем за допомогою однієї з жорсткої політики, передбачених з RHEL5 або в письмовому вигляді свої власні політика. 2.4.2 Включення SELinux Відредагуйте файл / і т.д. / SELinux / конфігурації. Додати або виправити такі рядки: SELINUX = примусову реалізацію SELINUXTYPE = цільової Редагування файлу /etc/grub.conf. Переконайтеся, що наступні аргументи не з'являються на будь-якої команди ядра рядок в файлі: SELinux = 0 Забезпечення виконання = 0 CCE 3977-6, 3999-0, 3624-4 Директива SELINUX = Забезпечення виконання дозволяє SELinux під час завантаження. Якщо SELinux викликає багато проблем або запобігаючи завантаження системи, то можна завантажитися в попереджувальної режимі тільки SELINUX = дозвільного для для налагодження. Переконайтеся в тому, щоб змінити режим назад у виконання після налагодження, встановити файлові системи щоб бути на предмет відповідності їх етикетки за допомогою команди сенсорного /.autorelabel і перезавантаження. Проте, конфігурація SELinux за умовчанням RHEL5 повинен бути досить розумним, що багато систем Завантажувальний без серйозних проблем. Деякі додатки, які вимагають глибоких або незвичайні системні привілеї, такі як віртуальні Програмне забезпечення пристрою, не можуть бути сумісні з SELinux в конфігурації за замовчуванням. Проте, це повинно бути рідкість, і SELinux підтримують додаток продовжує поліпшуватися. В інших випадках, SELinux може виявити незвичайне або ненадійне поведінка програми відповідно до проекту. Директива SELINUXTYPE = цільової налаштовує SELinux для використання за замовчуванням цілеспрямовану політику. Дивіться Розділ 2.4.7 якщо політика суворіше підходить для вашого сайту. Режим завантаження SELinux зазначено в / і т.д. / SELinux / конфігурації можуть бути перекриті аргументів командного рядка передається ядру. Необхідно перевірити grub.conf, щоб переконатися, що це не було зроблено і для захисту завантажувач, як описано в розділі 2.3.5.2. 2.4.2.1 Переконайтеся, що SELinux правильно Включено Виконайте наступну команду: $ / USR / SBIN / sestatus Якщо система налаштована належним чином, висновок повинен вказати: ?? SELinux статус: включений 57 ?? Поточний режим: виконання ?? Режим з конфігураційного файлу: забезпечення дотримання ?? Політика з конфігураційного файлу: цільової 2.4.3 Вимикайте непотрібні SELinux Демони Кілька демонів встановлюються за замовчуванням як частина механізму підтримки RHEL5 SELinux. Ці демони можуть поліпшити здатність системи для забезпечення дотримання політики SELinux в корисною моді, але може також представляти непотрібне код, що працює на машині, збільшуючи ризик системи. Якщо ці демони не потрібні на вашій системі, вони повинні бути відключені. 2.4.3.1 Відключити і якщо можливо Видалити SETroubleshoot Чи є критично важливі причини, щоб дозволити користувачам переглядати інформацію заперечення SELinux за допомогою графічного інтерфейсу sealert? Якщо немає, то відключити службу і видалити RPM: # Chkconfig setroubleshoot викл # Ням Стирання setroubleshoot CCE 4254-9, 4148-3 Служба setroubleshoot є засобом для повідомлення користувача для настільних комп'ютерів SELinux відмов в зручній для користувача формі. SELinux помилки можуть надати важливу інформацію про спроби вторгнення в прогрес, або може дати інформацію про проблеми конфігурації SELinux, що заважають правильної роботи системи. Для того, щоб підтримувати безпечна і корисна установка SELinux, ведення протоколу помилок і повідомлення необхідно. Однак setroubleshoot це послуга, яка має складну функціональність, яка запускає демон і використовує IPC для поширювати інформацію, яка може бути чутливим, або навіть, щоб дозволити користувачам змінювати налаштування SELinux, і які поки не реалізує реальні механізми аутентифікації. Даний посібник рекомендує відключити setroubleshoot і за допомогою функції аудиту ядра, щоб стежити за поведінкою SELinux в. Крім того, оскільки setroubleshoot автоматично запускає клієнтський код щоразу, коли відбувається відмова, незалежно від того, чи працює демон setroubleshootd, рекомендується, щоб програма була повністю вилучена якщо в ньому немає потреби. 2.4.3.2 Відключити MCS Сервіс перекладу (mcstrans), якщо це можливо Якщо немає якогось гостра необхідність для зручності перекладу категорії етикетки, відключити MCS послуги з перекладу: # Chkconfig mcstrans викл CCE 3668-1, 4129-3 Mcstransd демон надає інформацію про категорії етикетки перекладу, певний в / і т.д. / SELinux / цільової / setrans.conf на клієнтські процеси, які запитують цю інформацію. 58 ГЛАВА 2. загальносистемних конфігурації Категорія маркування навряд чи буде використовуватися тільки в місцях з особливими вимогами. Отже, вона повинна бути відключена для того, щоб зменшити кількість потенційно уразливих коду в системі. Дивіться Розділ 2.4.7 для більш інформація про системи, що використовують категорію маркування. 2.4.3.3 Restorecon Service (restorecond) Restorecond демон відстежує список файлів, які часто створені або змінені на ходових систем, і чиї SELinux контексти встановлені неправильно. Він шукає події створення пов'язаних з файлами, перерахованих в / і т.д. / SELinux / restorecond.conf, і встановлює контексти цих файлів, коли вони будуть виявлені. Програма restorecond досить проста, тому вона приносить низький ризик, але, в конфігурації за замовчуванням, не додає велике значення в системі. Автоматизована програма, така як restorecond можуть бути використані для моніторингу проблемних файлів для контексту проблем або системних адміністраторів можуть бути навчені для перевірки файлів контексти новостворених файлів за допомогою команда Ls -lz і відновити контексти вручну за допомогою команди restorecon. Даний посібник не дає ніяких рекомендацій ні за, ні проти використання restorecond. 2.4.4 Перевірка на необмеженій Демонов 2.4.4 Перевірка на необмеженій Демонов Демони, що SELinux політика не знає про те, буде успадковувати контекст батьківського процесу. Оскільки Демони запускаються при запуску і спускатися з процесу ініціалізації, вони успадковують контекст initrc т. це є проблемою, так як це може привести до AVC відмов, або він може дозволити привілеї, що демон не вимагає. Для перевірки необмеженій демонами, виконайте наступну команду: # Пс -ez | задати розширене "initrc" | -VW Задати розширене "тр | пс | задати розширене | Баш | AWK" | TR ':' '' | AWK '{друк $ NF}' Це не повинно виробляти ніякого висновку в добре налагодженій системі. 2.4.5 Перевірка на немічених Файли пристроїв Файли пристроїв використовуються для зв'язку з важливими системними ресурсами. SELinux контексти повинні існувати це. Якщо файл пристрою не позначений, то расконфігурація ймовірно. Для перевірки немічених файлів пристроїв, виконайте наступну команду: # Ls -Z | Grep unlabeled_t Це не повинно виробляти ніякого висновку в добре налагодженій системі. CCE 14991-4 2.4.6 Помилки налагодження SELinux політики політика SELinux за умовчанням значно покращилися протягом довгого часу, і більшість систем повинні мати кілька проблем використовуючи цілеспрямовану політику SELinux. Проте, проблеми політики можуть до сих пір іноді запобігти доступи, які має бути дозволено. Це особливо вірно, якщо ваш сайт працює будь-які призначені для користувача або сильно змінені додатки. У цьому розділі наводяться деякі короткі вказівки по виявленню і ремонту SELinux пов'язані з проблемами доступу. керівництво дається тут не є вичерпною, але вони повинні служити відправною точкою для налагодження. 59 Якщо ви підозрюєте, що помилка дозволу або інші помилки можуть бути викликані SELinux (і впевнені в тому, що расконфігурація традиційних дозволів Unix не є причиною проблеми), пошук журналів аудиту для подій AVC: # Ausearch -m AVC, USER_AVC -sv немає Висновок цієї команди буде безліч подій. Мітка часу, поряд з комм і Pid полів, слід вказати, яка лінія описує проблему. Подивіться контекст, в якому виконується процес. Якщо припустити, що ідентифікатор процесу PID, знайти контекст виконавши наступну команду: # Пс -p PID -Z Заперечення повідомлення AVC повинен ідентифікувати файл або каталог ображаючи. Поле Ім'я повинно містити Файл (не повне ім'я шляху за замовчуванням), а поле іно можна використовувати для пошуку по иноді при необхідності. Припускаючи, що файл FILE, знайти його SELinux контекст: # Ls -Z FILE Адміністратор повинен підозрювати неправильної настройки SELinux щоразу, коли програма отримує "доступ заборонено" помилка, але стандартні дозволу Unix є правильними, або Програма не загадково на завдання, яка як видається, пов'язані з доступом до файлів або мережевий зв'язку. Як описано в розділі 2.4.1, SELinux доповнює кожен процес з контекстом, що надає детальну інформацію про тип про цей процес. Контексти, при яких протікають процеси можуть бути віднесені до предметних контекстах. Точно так же, кожен об'єкт файлової системи задається контекст. Цільова політика складається з набору правил, кожна з яких дозволяє типу за умови виконання деяких операцій на заданому типі об'єкта. Ядро зберігає інформацію про ці рішення доступу в структуру, відому як Доступ Vector Cache (AVC), тому рішення про авторизацію, зроблені системою перевіряються з типом AVC. це є Також можливо в просторі користувача модулів для реалізації своїх власних стратегій, заснованих на SELinux, і ці рішення аудит з типом користувача AVC. AVC відмов реєструються за допомогою засобу перевірки ядра (дивіться розділ 2.6.2 для вказівки конфігурації на цій підсистеми) а також можуть бути видні через setroubleshoot. Даний посібник рекомендує використовувати аудит комунальних послуг в просторі користувача знаходити помилки AVC. Можна вручну знайти ці помилки, дивлячись в файлі /var/log/audit/audit.log або в / Var / Журнал / повідомлення (в залежності від конфігурації системного журналу в силу), але ausearch інструмент дозволяє дрібнозернистий пошук по типам подій аудиту, які можуть бути необхідні, якщо аудит системи виклику включена, а також. командного рядка вище говорить ausearch шукати ядра або в просторі користувача AVC повідомлень (-m AVC, USER AVC), де спроба доступу не увінчалися успіхом (-sv немає). Якщо відмова AVC відбувається тоді, коли воно не повинно бути, проблема, як правило, одну з таких дій: ?? Програма працює з неправильним предметної контексті. Це може статися в результаті неправильного контекст на виконуваний файл програми, який може статися, якщо встановлено програмне забезпечення третьою стороною і не дали відповідні контексти файлів SELinux. ?? Файл має неправильний контекст об'єкта, тому що контекст поточного файлу не відповідає специфікації. Це може статися, коли файли створені або змінені певним чином. Це не нетипово для конфігураційних файлів щоб отримати неправильні контексти після зміни конфігурації системи, що виконується адміністратором. Ремонтувати файл, використовуйте команду: # Restorecon -v FILE Це повинно виробляти вихідний сигнал, який вказує, що контекст файлу було змінено. / USR / бен / chcon Програма може бути використана, щоб вручну змінити контекст файлу, але це проблематично, так як зміна буде 60 ГЛАВА 2. загальносистемних конфігурації не зберігаються, якщо він не згоден з політикою певних контекстах, що застосовуються restorecon. ?? Файл має неправильний контекст об'єкта, оскільки специфікація неправильний або не відповідає шляху файл використовується в цій системі. У цьому випадку, буде необхідно змінити системний файл контексти. Запустіть засіб системного конфігураційного-SELinux, і перейдіть в меню "Файл" маркування. Це дасть список файлів і групові символи, відповідні файлу правил маркування на системі. Додайте правило, яке відображає файл в питанні до потрібного контексту. В якості альтернативи контексти файлів може бути змінений з командного рядка за допомогою semanage (8) інструмент. ?? Програма і файл мають правильні контексти, але політика повинна дозволити деяку операцію між тими, два контексту, який в даний час не допускається. У цьому випадку, буде необхідно змінити політику SELinux. Запустіть засіб системного конфігураційного-SELinux, і перейдіть в меню "Boolean". Якщо ваша конфігурація підтримується, але не Red Hat за замовчуванням, то буде логічне значення дозволяє в режимі реального часу модифікація SELinux політики, щоб виправити цю проблему. Перегляньте список пунктів в цьому меню, шукає той, який пов'язаний до послуга, яка не працює. В якості альтернативи SELinux Булев може бути змінений з командного рядка використовуючи getsebool (8) і setsebool (8) інструментів. Якщо немає логічного, то буде необхідно створити і завантажити модуль політики. Простий спосіб побудувати модуль політики полягає в використанні інструмент audit2allow. Цей інструмент може приймати вхідний сигнал у форматі AVC відмови повідомлень, а також генерувати правильні правила синтаксично Type Enforcement, які були б досить, щоб запобігти ці відмови. Наприклад, для створення і відображення правил, які дозволили б до ядру відмов, помічених в За останні п'ять хвилин, виконайте наступну команду: # Ausearch -m AVC -sv НЕ -TS останні | audit2allow Можна використовувати audit2allow безпосередньо створювати упаковку модуля, що підходить для завантаження в ядро політика. Для цього, викличте audit2allow з прапором -M: # Ausearch -m AVC -sv НЕ -TS останні | audit2allow -М localmodule Якщо це успішно, має з'явитися кілька рядків виводу. Перегляньте згенеровані правила TE в файлі localmodule .te і переконайтеся, що вони виражають те, що ви хочете дозволити. Localmodule .pp файл також повинен бути створений. Цей файл являє собою пакет модуля політики, яка може бути завантажений в ядро. Для цього, використовуйте системи конфігурації-SELinux, перейдіть в меню "Policy Module" і використовуйте кнопку "Додати", щоб включити свій пакет в модуль SELinux, або завантажити його з командного рядка за допомогою semodule (8): # Semodule -i localmodule .pp Розділ 45.2 [9] охоплює цю процедуру в деталях. 2.4.7 Подальше зміцнення Рекомендації, до цього моменту обговорили, як налаштувати і підтримувати систему за замовчуванням Конфігурація цілеспрямованої політики, яка обмежує тільки дії демонів і системного програмного забезпечення. це керівництво настійно рекомендує, щоб будь-який сайт, який в даний час не за допомогою SELinux взагалі переходу до цільової політика, щоб отримати істотні вигоди в плані безпеки, передбачені цією політикою. Проте, політика за замовчуванням надає тільки підмножина повної вигоди безпеки, доступних за допомогою SELinux. Зокрема, політика SELinux також здатен стримуюче дії інтерактивних користувачів, надання секційний доступу за рівнем чутливості (MLS) і / або категорії (MCS), і обмеження деяких видів системні дії, що використовують Булев за межі значень за замовчуванням RHEL5. 61 У цьому розділі описуються інші види використання SELinux, які можуть бути можливо, і надає посилання на деякі зовнішні ресурси про їх використання. Детальний опис того, як реалізувати ці кроки, виходить за рамки даного керівництва. 2.4.7.1 Підсилення за замовчуванням SELinux конфігурації Boolean SELinux Булев використовуються для включення або відключення сегментів політики для дотримання політики сайту. логічний може застосовуються до всієї системи або до окремого демона. Наприклад, булево дозволяють execstack, якщо ця функція включена, дозволяє програмам зробити частину свого стека області пам'яті виконуваного файлу. Це відноситься до всіх програм по маршруту система. Булева FTP домашній каталог дозволяє Ftpd процеси для доступу користувачів домашніх каталогів, і застосовується тільки до Демони, які реалізують FTP. команда $ Getsebool -a перераховує значення всіх змінних SELinux в системі. Розділ 2.4.6 обговорюються послабивши логічні значення в порядку проблемам функціональних можливостей налагодження, які відбуваються при більш обмежувальних за замовчуванням. Це також корисно для вивчення і посилити логічні настройки, щоб відключити функції, які не потрібно легальними програмами на вашому система, але яка може бути симптомом нападу. Див сторінки Довідника Булев (8), getsebool (8), і setsebool (8) для отримання загальної інформації про Булев. Є також довідкові сторінки для кількох підсистем, які обговорюють використання SELinux з цими системами. Приклади включають Ftpd SELinux (8), HTTPd SELinux (8) і SELinux NFS (8). Ще одна хороша посилання є HTML документація поширюється з RPM SELinux-політики. Ця документація зберігається під / USR / частки / DOC / SELinux-політики-версія / HTML / Сторінки глобальна tunables.html і глобальна booleans.html може виявитися корисним при розгляді Булев. 2.4.7.2 Використання Сильніше політики Використовуючи більш сильну політику може значно підвищити безпеку, але, як правило, вимагають настройки, щоб бути сумісним з метою конкретної системи, і це може бути дорогим або забирає багато часу. В рамках цілеспрямованої політики, інтерактивні процеси мають тип необмеженій т, тому інтерактивні користувачі не обмежені SELinux навіть якщо вони намагаються прийняти дивні або шкідливі дії. Перший варіант політики доступний з SELinux RHEL5 в розподіл, називається строгим, розширює захист, пропоновані політикою за замовчуванням від демонів і системи процесів всім процесам. Щоб використовувати жорстку політику, спочатку переконайтеся, що встановлено модуль політики: # Ням встановити SELinux-політики суворого Потім відредагуйте / і т.д. / SELinux / конфігурації і виправити рядок: SELINUXTYPE = суворі Тип МЛ політика може бути використана для забезпечення чутливості або категорії маркування, а також вимагає настройки конкретної ділянки з цих міток в порядку, щоб бути корисним. Щоб використовувати цю політику, встановіть відповідний модуль політики: # Ням встановити SELinux-політики-МЛ Потім відредагуйте / і т.д. / SELinux / конфігурації і виправити рядок: SELINUXTYPE = МЛ Примітка: Перемикання між політикою зазвичай вимагає весь диск, щоб бути їх етикетки, так що файли отримати відповідну SELinux контексти в рамках нової політики. Завантаження з додатковим різьбовими параметрами командного рядка Забезпечення виконання = 0 одиночний autorelabel 62 ГЛАВА 2. загальносистемних конфігурації щоб переразметьте диск в режимі одного, а потім виконати перезавантаження в звичайному режимі. 2.4.8 SELinux Посилання ?? АНБ SELinux ресурси: - Веб-сторінка: http://www.nsa.gov/research/selinux - Список розсилки інформації на сайті: http://www.nsa.gov/research/selinux/list.shtml ?? Fedora SELinux ресурси: - FAQ: http://docs.fedoraproject.org/selinux-faq - Керівництво користувача: http://docs.fedoraproject.org/selinux-user-guide - Управління Керівництво Послуги: http://docs.fedoraproject.org/selinux-managing-confined-services-guide ?? SELinux Project веб-сторінки і вики: http://www.selinuxproject.org ?? Глави 43-45 Red Hat Enterprise Linux 5: Посібник із розгортання [9] ?? Книга SELinux по Приклад: Використання Security Enhanced Linux [14] 2.5 Конфігурація та Брандмауери Мережа Більшість машин повинні бути підключені до мережі якийсь, і це приносить з собою істотний ризик мережевих атак. У цьому розділі розглядається вплив безпеки рішень про мережах, які повинні бути зроблені приконфігуруванні системи. У цьому розділі також розглядаються міжмережеві екрани, засоби управління доступом до мережі, і інші механізми мережевої безпеки, які дозволяють правила системного рівня для запису, які можуть обмежити можливості атакуючого підключитися до всієї системи. Ці правила можуть вказати, що мережевий трафік повинен бути дозволений або заборонений з певних IP-адрес, хостів і мереж. правила можуть також вказати, які з мережевих послуг системи доступні для окремих хостів або мереж. 2.5.1 ядра Параметри, які впливають на Networking Утиліта Sysctl використовується для установки ряду параметрів, які впливають на роботу ядра Linux. кілька з цих параметрів є специфічними для мереж, а також параметри конфігурації в цьому розділі рекомендується. Можливість запитувати стан мережевого стека системи також має важливе значення, і така інформація також доступні в / Proc / мережі. 2.5.1.1 Параметри мережі тільки для вузлів мережі Чи є ця система буде використовуватися в якості брандмауера або шлюзу для передачі IP-трафіку між різними мережами? Якщо немає, то відредагувати файл /etc/sysctl.conf і додати або виправити такі рядки: net.ipv4.ip вперед = 0 net.ipv4.conf.all.send перенаправляє = 0 net.ipv4.conf.default.send перенаправляє = 0 CCE 4151-7, 4155-8, 3561-8 63 Ці настройки відключають хости від виконання функціональних можливостей мережі, яка підходить тільки для маршрутизаторів. 2.5.1.2 Параметри мережі для хостів і маршрутизаторів Змініть файл /etc/sysctl.conf і додати або виправити такі рядки: net.ipv4.conf.all.accept_source_route = 0 net.ipv4.conf.all.accept_redirects = 0 net.ipv4.conf.all.secure_redirects = 0 net.ipv4.conf.all.log_martians = 1 net.ipv4.conf.default.accept_source_route = 0 net.ipv4.conf.default.accept_redirects = 0 net.ipv4.conf.default.secure_redirects = 0 net.ipv4.icmp_echo_ignore_broadcasts = 1 net.ipv4.icmp_ignore_bogus_error_messages = 1 net.ipv4.tcp_syncookies = 1 net.ipv4.conf.all.rp_filter = 1 net.ipv4.conf.default.rp_filter = 1 CCE 3472-8, 4217-6, 4133-5, 4265-5, 3644-2, 4186-3, 4080-8, 3339-9, 4320-8, 3840-6, 4091-5, 4236-6 Ці параметри покращують здатність Linux захищатися від певних типів атак протоколу IPv4. Приймає вихідний маршрут, прийняти переадресовує і безпечний перенаправляє опції відключені, щоб відключити IPv4 Можливості протоколу, які вважаються мають мало законних цілях і бути легко зловживати. Net.ipv4.conf.all.log марсіани опція реєструє кілька типів підозрілих пакетів, таких як пакети підроблені, джерело маршрутизації пакетів, і перенаправляє. У луна-ігнорувати трансляції ICMP ігнорувати фіктивні повідомлення про помилки Параметри захисту від атак ICMP. Опція ТСР syncookies використовує криптографічний функцію під назвою SYN печиво, щоб дозволити машинам продовжувати приймати законні зв'язку, коли стикаються з повенями атаки SYN. [13] для отримання додаткової інформації про цю опції. Опція Р.П. фільтр включає перевірку вихідного RFC-рекомендується. Вона не повинна бути використана на машинах, маршрутизатори для дуже складних мереж, але корисно для кінцевих вузлів і маршрутизаторів, які обслуговують невеликі мережі. Для отримання додаткової інформації про будь-якому з них можна знайти в файлі документації вихідного коду ядра /Documentation/networking/ip-sysctl.txt.2 2.5.1.3 Забезпечення системи не виступає в якості мережевого Sniffer Система не повинна діяти як мережевий аналізатор, який може захопити весь трафік в мережі, до якої його підключений. Вихідний сигнал / Proc / нетто / пакет повинен показувати рівно один рядок заголовка, з записами аналогічних щоб: ск RefCnt Тип Прото Iface R Rmem Inode Користувач Якщо цифри в рядку нижче цього заголовка, то процес пирхання (наприклад, ТСРйітр або Wireshark) є за допомогою інтерфейсу, і це має бути досліджено. CCE 15013-6 2A остання версія цього файлу можна знайти в Інтернеті за адресою http://lxr.linux.no/source/Documentation/networking/ip-sysctl.txt. 64 ГЛАВА 2. загальносистемних конфігурації 2.5.2 Бездротові мережі Бездротові мережі (іноді звані 802.11 або Wi-Fi) являє собою серйозну загрозу для безпеки чутливої ​​або Оголошення систем і мереж. Устаткування для бездротових мереж мереж набагато більш імовірно, будуть включені в ноутбук або портативні системи, ніж настільні комп'ютери або сервери. Дивіться розділ 3.3.14 для отримання інформації про бездротової підтримкою Bluetooth. Bluetooth служить іншої мети і володіє набагато коротший діапазон, але він як і раніше представляє серйозну безпеку ризики. Видалення апаратного забезпечення є єдиним способом, щоб абсолютно гарантувати, що можливості бездротового доступу залишається недоступною. Якщо це абсолютно непрактичним для видалення бездротового обладнання, а також політику сайту як і раніше дозволяє пристрою ввести чутливий прогалини, робиться все можливе, щоб не дозволити за допомогою програмного забезпечення повинні бути зроблені. В цілому, політика придбання повинна включають в себе положення щодо запобігання придбанню обладнання, яке буде використовуватися в чутливих приміщеннях і включає в себе бездротові можливості. 2.5.2.1 Видалити бездротового обладнання, якщо це можливо Ідентифікація бездротового обладнання є першим кроком у видаленні його. Керівництві по апаратної частини системи повинна містити інформацію про своїх бездротових можливостей. Устаткування для бездротових мереж в комплекті з ноутбуком, як правило, приймає форму карти Mini-PCI або PC Card. інші форми включають в себе пристрої, які підключаються до USB або Ethernet портів, але вони повинні бути очевидні і легко видалити від базової системи. Плата PC Card (спочатку називається PCMCIA-карта) призначена для легко видалити, хоча він може бути прихований, коли вставлений в систему. Часто, буде одна або кілька кнопок поруч слот для карт пам'яті, при натисканні, витягти карту пам'яті з системи. Якщо карта не розгорнеться, слот порожній. Міні-PCI карти приблизно кредитних карт за розміром і, як правило, доступні через знімною панеллю на нижньому боці ноутбука. Зняття панелі може зажадати простих інструментів. На додаток до перевірки вручну апаратні засоби, також можна запросити систему для її встановленого обладнання пристроїв. Команди / SBIN / Утиліта lspci і / SBIN / lsusb покаже список усіх визнаних пристроїв на їх відповідні шини, і це може вказувати на наявність бездротового пристрою. 2.5.2.2 Відключення бездротового через конфігурацію програмного забезпечення Якщо це неможливо видалити бездротове обладнання з розглянутого пристрою, відключити стільки про нього, як це можливо за допомогою програмного забезпечення. Наступні методи можуть відключити підтримку програмного забезпечення для бездротових мереж, але зверніть увагу, що ці методи не запобігають шкідливе програмне забезпечення або безтурботних користувачів від повторного активації пристрою. 2.5.2.2.1 Відключення бездротового в BIOS Деякі ноутбуки, які включають в себе вбудовані бездротові підтримки пропонують можливість відключення пристрою через BIOS. це системно-специфічні; зверніться до свого керівництва по обладнанню або вивчити налаштування BIOS під час завантаження. CCE 3628-5 2.5.2.2.2 дезактивує бездротові інтерфейси Деактивация бездротові інтерфейси повинні перешкоджати нормальному використанню бездротової можливості. 65 По-перше, визначити інтерфейси, доступні за допомогою команди: # Ifconfig -a Крім того, наступна команда може також використовуватися, щоб визначити, чи дійсно бездротової підтримки ( «розширення») включений для певного інтерфейсу, хоча це не завжди може бути чітким показником: # iwconfig Після виявлення будь-яких бездротових інтерфейсів (які можуть мати імена, як wlan0, ath0, wifi0 або eth0), деактивувати інтерфейс за допомогою наступної команди: # Ifdown інтерфейс Ці зміни не будуть тривати тільки до наступного перезавантаження. Щоб відключити інтерфейс для майбутніх чобіт, видалити відповідний інтерфейс файл з / і т.д. / sysconfig / мережі-скрипти: # Гт / і т.д. / sysconfig / мережі-скрипти / ifcfg-інтерфейс CCE 4276-2 2.5.2.2.3 Відключити Драйвери для бездротової Видалення драйверів ядра, які забезпечують підтримку бездротових пристроїв Ethernet завадить користувачам легко активація пристрою. Щоб видалити бездротові драйвери з системи: # Гт -r / Бібліотека / модулі / kernelversion (s) / ядро ​​/ драйвери / / безпроводова CCE 4170-7 Ця команда також повинна повторюватися кожен раз, коли ядро ​​оновлюється. 2.5.3 IPv6 Система включає в себе підтримку протоколу Інтернету версії 6. Одна з основних і часто згадується поліпшення над IPv4 є його величезне зростання числа доступних адрес. Ще однією важливою особливістю є підтримка автоматична настройка багатьох мережевих налаштувань. 2.5.3.1 Відключити Підтримка IPv6 якщо цього не потрібно Як і з будь-яким мережевим протоколом, IPv6 повинен бути відключений, а то й потрібно. Незважаючи на зміни, що передбачає підтримка IPv6 була відключена, локальна адреса IPv6 автоконфігурації відбувається навіть тоді, коли тільки IPv4 адреса призначається. Єдиний спосіб ефективно запобігти виконанню мережевого стека IPv6, щоб запобігти ядро від завантаження модуля ядра IPv6. 2.5.3.1.1 Заборона автоматичного завантаження модуля ядра IPv6 Щоб запобігти модуль ядра IPv6 (IPv6) від бути автоматично завантажується, додайте наступний рядок в / і т.д. / modprobe.conf: 66 ГЛАВА 2. загальносистемних конфігурації встановити ipv6 / bin / вірно CCE 3562-6 Коли ядро ​​запитує модуль ipv6, ця лінія буде направляти систему для запуску програми / бен / істинним замість цього. 2.5.3.1.2 Відключення інтерфейсу Використання IPv6 Для запобігання конфігурації IPv6 для всіх інтерфейсів, додати або виправити такі рядки в / і т.д. / sysconfig / мережу: NETWORKING_IPV6 = немає IPV6INIT = немає Для кожного інтерфейсу IFACE мережі, додати або виправити такі рядки в / і т.д. / sysconfig / мережі-скрипти / ifcfg-IFACE в якості додаткового механізму профілактики: IPV6INIT = немає CCE 3377-9, 4296-0, 3381-1 Якщо виникне необхідність пізніше налаштувати IPv6, тільки інтерфейси, що вимагають його повинна бути включена. 2.5.3.2 Налаштування параметрів IPv6, якщо це необхідно Головною особливістю IPv6 є ступінь, в якій системи реалізації вона може автоматично налаштувати їх мережі пристрої, що використовують інформацію з мережі. З точки зору безпеки, важливо ручної настройки Інформація про конфігурацію завжди краще приймати його від мережі в нерозпізнаних моди. 2.5.3.2.1 Конфігурація Автоматичне відключення Відключити прийняття системи реклами маршрутизатора і ICMP перенаправляє шляхом додавання або коригування наступний рядок в / і т.д. / sysconfig / мережі (зверніть увагу, що це не призводить до відключення відправки маршрутизатора клопотання): IPV6_AUTOCONF = немає CCE 4269-7, 4291-1, 4313-3, 4198-8 Цей параметр призводить до того, щоб зробити такі параметри (SYSCTL) ядра встановлюються таким чином, якщо використовується протокол IPv6 на системі: net.ipv6.conf.default.accept_ra = 0 net.ipv6.conf.default.accept_redirect = 0 2.5.3.2.2 вручну призначити Глобальний адресу IPv6 Щоб вручну призначити IP-адреса для інтерфейсу IFACE, відредагуйте файл / і т.д. / sysconfig / мережі-скрипти / ifcfg-IFACE. Додати або виправити наступний рядок (замість попередньої правильну адресу IPv6): 67 IPV6ADDR = 2001: 0db8 :: ABCD / 64 Ручне призначення IP- адреса переважно приймати один з маршрутизаторів або з мережі в іншому випадку. Приклад адреси тут є адресою IPv6 зарезервовані для цілей документування, як це визначено RFC3849. 2.5.3.2.3 Використання розширень для захисту персональних даних Адреса, якщо необхідно Для того, щоб ввести випадковості в автоматичній генерації адрес IPv6, додати або виправити наступний рядок в / і т.д. / sysconfig / мережі-скрипти / ifcfg-IFACE: IPV6_PRIVACY = rfc3041 CCE 3842-2 Автоматично генеруються адреси IPv6 засновані на основних апаратних засобів (наприклад, Ethernet) адреси і т.д. стає можливим відслідковувати частина обладнання протягом його терміну служби, використовуючи свій трафік. Якщо це має важливе значення для системи IP-адреса, щоб не тривіальним розкрити його апаратну адресу, то цей параметр повинен бути застосований. 2.5.3.2.4 вручну призначити IPv6 Router Address Відредагувати файл / і т.д. / sysconfig / мережі-скрипти / ifcfg-Iface, а також додати або виправити наступний рядок (підставляючи Ваш IP-шлюз в залежності від обставин): IPV6_DEFAULTGW = 2001: 0db8 :: 0001 адреси маршрутизатора повинні бути встановлені вручну і не приймаються через будь-який автоконфігуратор або маршрутизатор реклами. 2.5.3.2.5 Граничне Мережа передається Конфігурація Додайте наступні рядки в файл /etc/sysctl.conf, щоб обмежити інформацію про конфігурацію запитуються з інших системи, і прийняв з мережі: net.ipv6.conf.default.router_solicitations = 0 net.ipv6.conf.default.accept_ra_rtr_pref = 0 net.ipv6.conf.default.accept_ra_pinfo = 0 net.ipv6.conf.default.accept_ra_defrtr = 0 net.ipv6.conf.default.autoconf = 0 net.ipv6.conf.default.dad_transmits = 0 net.ipv6.conf.default.max_addresses = 1 CCE 4221-8, 4137-6, 4159-0, 3895-0, 4287-9, 4058-4, 4128-5 Налаштування маршрутизатора клопотаннями визначає, скільки маршрутизатор клопотання відправляються, коли виховують інтерфейс. Якщо адреси статично призначені, немає необхідності надсилати клопотання. Приймає ра pinfo настройки управління, чи буде система приймає префікс інформацію від маршрутизатора. 68 ГЛАВА 2. загальносистемних конфігурації Приймає ра defrtr настройки управління, чи буде система сприймає настройки Hop Limit від маршрутизатора реклами. Установка в 0 запобігає маршрутизатор від зміни вашого за замовчуванням IPv6 Hop Limit для вихідних пакетів. Налаштування управління Autoconf чи рекламні оголошення маршрутизатора може змусити систему привласнити глобальний одноадресних звернутися до інтерфейсу. Папа передає параметр визначає, скільки сусід клопотаннями, щоб відправити на адресу (глобальні і локальної зв'язку), коли виховують інтерфейс для забезпечення бажаного адреси є унікальним в мережі. Параметр Максимальна кількість адрес визначає, скільки глобальні односпрямовані адреси IPv6 можуть бути призначені кожному інтерфейсу. Значення за замовчуванням дорівнює 16, але воно повинно бути встановлено точно числом статично налаштованих глобальних адрес, необхідних. 2.5.4 TCP Wrapper TCP Wrapper є бібліотека, яка забезпечує просте управління доступом і стандартизовану ведення журналу для програм, які підтримуються які приймають з'єднання по мережі. Історично склалося так, TCP Обгортка використовувався для підтримки Inetd послуг. Тепер, коли Inetd засуджується (див розділ 3.2.1), TCP Wrapper підтримує тільки послуги, які були побудовані, щоб зробити використання бібліотеки libwrap. Для того, щоб визначити, чи підтримує даний виконуваний демон / шлях / до / демон TCP Обгортка, перевірте документацію, або виконайте команду: $ LDD / шлях / до / демон | Grep libwrap.so Якщо ця команда повертає будь-який висновок, то демон, ймовірно, підтримує TCP Wrapper. Альтернатива підтримки TCP Wrapper є фільтрація пакетів за допомогою IPTables. Зверніть увагу, що Iptables працює на мережевому рівні, в той час як TCP Wrapper працює на рівні додатків. Це означає, що фільтрація Iptables більше ефективним і більш стійкі до недоліків в програмному забезпеченні захищений, але TCP Wrapper забезпечує підтримку вирубка лісів, банери і інші прийоми прикладного рівня, які Iptables не можуть забезпечити. 2.5.4.1 Як TCP Wrapper Захищає послуги TCP Wrapper забезпечує контроль доступу до мережевих сервісів системи, використовуючи два файли конфігурації. коли спроба підключитися: 1. Файл /etc/hosts.allow шукається правило зіставлення з'єднання. Якщо він знайдений, то з'єднання допускається. 2. В іншому випадку файл /etc/hosts.deny виконується пошук правила, яке відповідає з'єднання. Якщо він знайдений, то З'єднання відхилено. 3. Якщо ніякі правила відповідники не знайдені в будь-якому файлі, то з'єднання дозволяється. За замовчуванням TCP Wrapper робить не блокувати доступ до будь-яких послуг. У найпростішому випадку, кожне правило в /etc/hosts.allow і /etc/hosts.deny набирає вигляду: Демон: клієнт де демон ім'я процесу сервера для якого призначене з'єднання, і клієнт є частковим або повне ім'я хоста або IP-адреса клієнта. Він дійсний для демона і клієнта містить один пункт порядку денного, розділений комами список елементів, або спеціальне ключове слово, як і всі, що відповідає будь-якої служби або клієнта. (Див хости доступу (5) на сторінці Довідника списку інших ключових слів.) Примітка: Часткове доменні імена починаються в кореневому домені і розмежовуються. характер. Так клієнтської машині host03.dev.example.com, з IP-адресою 10.7.2.3, може бути зіставлений з будь-яким з специфікації: 69 .example.com .dev.example.com 10.7.2. 2.5.4.2 Відхилити всі з'єднання з іншими хостами в разі необхідності, Обмежити все підключення до непублічних послуг LocalHost тільки. Нехай pubsrv1 і pubsrv2 є імена демонів, які повинні бути доступні віддалено. Налаштування TCP Wrapper наступним чином. Редагування /etc/hosts.allow. Додайте наступні рядки: pubsrv1, pubsrv2: ALL ALL: локальний Редагування /etc/hosts.deny. Додайте наступний рядок: ALL: ALL Ці правила заперечують з'єднання з усіма включеними TCP Wrapper послуг з будь-якого хоста, крім локального хоста, але дозволити з'єднання з будь-якої точки світу до служб, які повинні бути доступні для громадськості. (Якщо не існує державних послуг, перший рядок у /etc/hosts.allow може бути опущений.) 2.5.4.3 Дозволити підключення лише від хостів в цьому домені в разі необхідності, Для кожного демона, domainsrv, який потрібно лише зв'язатися з всередині локального домену, example.com, Налаштування TCP Wrapper для відмови віддалених підключень. Редагування /etc/hosts.allow. Додайте наступний рядок: domainsrv: .example.com Редагування /etc/hosts.deny. Додайте наступний рядок: domainsrv: ALL Є багато можливих прикладів послуг, які повинні взаємодіяти тільки в межах локального домену. якщо машина має локальний сервер Compute, це може бути необхідно для користувачів, щоб підключитися через SSH з робочого столу робочі станції, але не з-за меж області. У цьому випадку, ви повинні захистити демон SSHd за допомогою цього метод. Як інший приклад, послуги RPC на основі, наприклад, NFS може бути включений в межах тільки домен, в цьому випадку демон Portmap повинен бути захищений. Примітка: Цей приклад захищає тільки domainsrv служби. Без фільтрації робиться на інші послуги, якщо лінія не є вступив в /etc/hosts.deny, який відноситься до цих служб на ім'я, або яка обмежує спеціальну послугу ALL. 2.5.4.4 Монітор Syslog для штуцерів і відмовами Переконайтеся в тому, що наступний рядок існує в /etc/syslog.conf. (Це значення за замовчуванням, так що це, ймовірно, буде правильно якщо конфігурація не була змінена): authpriv. * / VAR / Журнал / безпечний 70 ГЛАВА 2. загальносистемних конфігурації Налаштування Logwatch або іншого журналу моніторингу інструментів періодично підсумовувати невдалі з'єднання, повідомлені TCP Wrapper на об'єкті authpriv.info. За замовчуванням, TCP Wrapper аудит всіх відхилених з'єднань на об'єкті authpriv, на рівні інформації. У файлі журналу, TCP Wrapper відторгнення буде містити підрядок: демон [PID]: відмовився з'єднатися від IPAddr Ці лінії можуть бути використані для виявлення шкідливих сканування, а також для налагодження збоїв в результаті неправильного TCP Wrapper конфігурації. Якщо це необхідно, то можна змінити об'єкт системного журналу і рівня, використовуваного даної правила TCP Wrapper шляхом додавання строгість можливість кожної бажаної конфігурації лінії в /etc/hosts.deny: Демон: клієнт: Тяжкість об'єкт .level За замовчуванням успішні підключення не авторизовані через TCP Wrapper. Дивіться розділ 2.6 для отримання додаткової інформації про Система аудиту. 2.5.4.5 Додаткові джерела Для отримання додаткової інформації про TCP Wrapper см Tcpd (8) і доступу хостів (5) і сторінки Довідника документації каталог / USR / частки / DOC / ТСР обгорток-версії. Деяка інформація може бути доступна з розділу Інструменти веб-сайту автора, http://www.porcupine.org, і з довідкового керівництва RHEL4 [6]. 2.5.5 Iptables і ip6tables Брандмауер на основі хоста називається Netfilter включена як частина ядра Linux розподіленою системою. це є активується за умовчанням. 2.5.5 Iptables і ip6tables Брандмауер на основі хоста називається Netfilter включена як частина ядра Linux розподіленою системою. це є активується за умовчанням. Цей міжмережевий екран управляється програмою IPTables, і весь потенціал часто згадується під цим ім'ям. Аналогічна програма під назвою ip6tables обробляє фільтрацію для IPv6. На відміну від TCP Wrappers, який залежить від програми, яку збирає сервер для підтримки і дотримуватися правил, написані, Netfilter фільтрація відбувається на рівні ядра, до того, як програма може навіть обробляти дані з мережевого пакету. Таким чином, будь-яка програма в системі залежить від правил, написаних. У цьому розділі наведені основні відомості про посилення IPTables і ip6tables конфігурації включені з системою. Для отримання більш повної інформації, яка може дозволити будівництво складного набору правил Адаптація до середовища, зверніться посилання в кінці цього розділу. 2.5.5.1 Перевірити і активувати правила за замовчуванням Перегляд в даний час неухильно додержуються правил Iptables, виконавши команду: # Iptables -nL --line-номера Команда аналогічна за програмою ip6tables. Якщо брандмауер не виникає, щоб бути активним (тобто, не з'являються правила), активувати його і переконайтеся, що вона починається в завантаження за допомогою наступних команд (і аналогічно для ip6tables): 71 # Сервіс Iptables перезапустити # Chkconfig IPtables на CCE 4167-3, 4189-7 Правила за умовчанням Iptables: Ланцюг INPUT (політика ACCEPT) Num цільове джерело Prot неавтоматичного призначення 1 RH-Firewall-1-INPUT все - 0.0.0.0/0 0.0.0.0/0 Ланцюжок FORWARD (політика ACCEPT) Num цільове джерело Prot неавтоматичного призначення 1 RH-Firewall-1-INPUT все - 0.0.0.0/0 0.0.0.0/0 Ланцюжок OUTPUT (політика ACCEPT) Num цільове джерело Prot неавтоматичного призначення Мережа RH-Firewall-1-INPUT (2 посилання) Num цільове джерело Prot неавтоматичного призначення 1 ВЗЯТИ все - 0.0.0.0/0 0.0.0.0/0 2 ACCEPT ICMP - 0.0.0.0/0 0.0.0.0/0 типу 255 ICMP 3 ВЗЯТИ осіб - 0.0.0.0/0 0.0.0.0/0 4 ВЗЯТИ ах - 0.0.0.0/0 0.0.0.0/0 5 ВЗЯТИ ПДП - 0.0.0.0/0~~HEAD=dobj 224.0.0.251 UdP ПТР: 5353 6 ВЗЯТИ УДП - 0.0.0.0/0 0.0.0.0/0 УДП діоптрії: 631 7 ВЗЯТИ TCP - 0.0.0.0/0~~HEAD=dobj 0.0.0.0/0 ТСР ПТР: 631 8 ВЗЯТИ все - 0.0.0.0/0 0.0.0.0/0 стан ПОВ'ЯЗАНІ, установ 9 ВЗЯТИ TCP - 0.0.0.0/0~~HEAD=dobj 0.0.0.0/0 Штат Нью-ТСР ПТР: 22 10 Відхилити всі - 0.0.0.0/0 0.0.0.0/0 відкидають-ІКМП-хост забороненим Правила ip6tables за замовчуванням схожі, зі своїми правилами 2 і 10, що відображають іменування протоколу і адресації відмінностей. Замість того, щоб правила 8, однак, ip6tables включає в себе два правила, які приймають всі вхідні UDP і TCP-пакети з певний діапазон портів призначення. Це пояснюється тим, що поточна реалізація Netfilter для IPv6 не вистачає надійної Підключення відстеження функціональності. 2.5.5.2 Розуміти За замовчуванням Ruleset Розуміння і створення правил брандмауера може бути складною діяльності, наповнена випадків кутових і важко todebug проблеми. Через це, адміністратори повинні розробити повне розуміння набору правил за замовчуванням перед тим ретельно модифікуючи його. Набір правил за замовчуванням ділиться на чотири частини, кожна з яких називається ланцюг: ВХІД, FORWARD, OUTPUT, і RH-Firewall-1-INPUT. Вхід, вихід, і ВПЕРЕД вбудовані в ланцюзі. ?? ВХІД ланцюг активується на пакетах, призначених для (тобто ім'я) системи. ?? Вихідний сигнал ланцюга активується на пакетах, які, що походять з системи. ?? ВПЕРЕД ланцюг активується для пакетів, що система буде обробляти і відправляти через інший інтерфейс, якщо так налаштований. ?? RH-Firewall-1-INPUT ланцюг являє собою користувальницький (або визначений користувачем) ланцюг, яка використовується на вході і FORWARD ланцюга. 72 ГЛАВА 2. загальносистемних конфігурації Пакет починається з першого правила у відповідній ланцюга і триває до тих пір, поки не відповідає правилу. Якщо збіг відбувається, то управління перейде до зазначеної мети. за замовчуванням використовує набір правил вбудовані мети схвалювати, а також певний користувачем цільової / ланцюг RH-Firewall-1-INPUT. Перехід до мети ACCEPT кошти, щоб дозволити пакет через, в той час як REJECT означає скидання пакета і відправити повідомлення про помилку, що відправляє вузла. пов'язаний мета називається DROP означає скидання пакету на підлогу, навіть не посилаючи повідомлення про помилку. Політика за замовчуванням для всіх вбудованих ланцюжків (показані після того, як їх імена в виведенні правила вище) встановлено в положення ACCEPT. Це означає, що якщо ніяких правил в ланцюжку не відповідають пакети, вони пропускаються. Через будь-яких правил взагалі написані для вихідного кола, це означає, що Iptables не зупиняє будь-які пакети, що виходять від система. Вхідна напруга і FORWARD ланцюга переходу до певної користувачем мети RH-Firewall-1-INPUT для всіх пакетів. RH-Firewall-1-INPUT намагається відповідати, в порядку, такі правила для обох IPTables і ip6tables: ?? Правило 1, як видається, приймає всі пакети. Проте, це, здається, вірно тільки тому, що правила не представлені в розширеному режимі. виконання команди # Iptables -vnL --line-номера показує, що це правило застосовується тільки до інтерфейсу зворотного петлі (Lo) (див стовпець), в той час як всі інші правила для всіх інтерфейсів. Таким чином, пакети не виходять з інтерфейсу зворотного петлі не збігаються і приступити до Наступне правило. ?? Правило 2 явно дозволяє всі типи ICMP пакетів; Iptables використовує код 255 для позначення всіх типів ICMP. ?? Правило 3 явно дозволяє все пакети ESP; ці пакети, які містять заголовки IPsec ESP. ?? Правило 4 явно дозволяє все пакети ах; ці пакети, які містять заголовок аутентифікації SPI IPsec. ?? Правило 5 дозволяє вхідні з'єднання на порт UDP 5353 (MDNS), який використовує Avahi демон. ?? Правила 6 і 7 дозволяє вхідні з'єднання на обох TCP і UDP порт 631, який використовує чашки демон. ?? Правило 8, в правилах IPtables, дозволяє вхідні пакети, які є частиною сеансу, ініційованого системою. У ip6tables, правила 8 і 9 дозволяють будь-які вхідні пакети з адресою порту призначення між 32768 і 61000. ?? Правило 9 (10, для ip6tables) дозволяє підключення до вашого комп'ютера в TCP-порт 22, який є протокол SSH. ?? Правило 10 (11, для ip6tables) відкидає всі інші пакети і відправляє повідомлення про помилку відправнику. Тому що це це останнє правило і відповідає будь-який пакет, він ефективно запобігає будь-пакет від досягнення за замовчуванням в ланцюжку ВЗЯТИ мета. Запобігання прийняття будь-якого пакета, який явно не дозволено власне дизайн для брандмауер. 2.5.5.3 Зміцнення За замовчуванням Ruleset Правила за умовчанням можуть бути посилені. Системні скрипти, які активують правила брандмауера очікувати, що вони будуть визначені в файлах конфігурації IPTables і ip6tables в каталозі / і т.д. / sysconfig. Багато з ліній в ці файли схожі на аргументи командного рядка, які будуть надані програм / SBIN / IPTables або / SBIN / ip6tables - але деякі з них досить різні. Системна програма-конфігурації-securitylevel дозволяє додаткові послуги проникати за замовчуванням правила брандмауера і автоматично регулює / і т.д. / sysconfig / Iptables. Ця програма корисна тільки якщо набір правил за замовчуванням відповідає вашим вимогам безпеки. В іншому випадку, ця програма не повинна використовуватися внести зміни в конфігурації брандмауера, оскільки він повторно записує збережений файл конфігурації. Наступні рекомендації описують, як зміцнити конфігураційний файл набору правил за замовчуванням. альтернатива для редагування цього файлу конфігурації можна створити скрипт, який звертається до програми IPtables для завантаження правил, а потім викликає сервіс IPTables зберегти, щоб написати ці завантажені правила в / і т.д. / sysconfig / Iptables. 73 Наступні зміни можуть бути зроблені безпосередньо в / і т.д. / sysconfig / IPTables і / і т.д. / sysconfig / ip6tables. Інструкції застосовуються до обох, якщо не вказано інше. Мова і адресні угоди для регулярних IPTables є використовуваний в даному розділі; конфігурація для ip6tables буде або аналогічне або явно покриті. 2.5.5.3.1 Зміна політики за замовчуванням Зміна політики за замовчуванням DROP (від ВЗЯТИ) для введення і FORWARD вбудовані ланцюга: * фільтр : ВХІД DROP [0: 0] : FORWARD DROP [0: 0] CCE 14264-6 Зміна політики за замовчуванням, таким чином, реалізує правильну конструкцію для брандмауера, то є якісь пакети, які не є явно дозволених, не повинні прийматися. 2.5.5.3.2 Обмежити типи повідомлень ICMP В / і т.д. / sysconfig / Iptables, Прийнята ICMP типів повідомлень може бути обмежено. Приймати тільки пакети ICMP луна-відповідь, адресат недосяжний, і перевищено час повідомлення, видаліть рядок: -A RH-Firewall-1-INPUT -p ICMP --icmp типу будь-якого -j ACCEPT і вставити рядки: -A RH-Firewall-1-INPUT -p ICMP --icmp типу луна-відповідь -j ACCEPT -A RH-Firewall-1-INPUT -p ICMP --icmp типу призначення недосяжний - j ACCEPT -A RH-Firewall-1-INPUT -p ICMP --icmp типу часу перевищив -j ACCEPT Для того, щоб дозволити системі реагувати на пінг, а також вставити наступний рядок: -A RH-Firewall-1-INPUT -p ICMP --icmp типу луна-запит -j ACCEPT відповіді Ping також можуть бути обмежені певними мережами або хостів за допомогою опції -s в попередньому правилі. Оскільки IPv6 залежить так сильно від ICMPv6, переважно, щоб заперечувати ICMPv6 пакети ви знаєте, не потрібно (наприклад, пінг-запити) в / і т.д. / sysconfig / ip6tables, в той час дозволяючи все інше через: -A RH-Firewall-1-INPUT -p ICMPv6 --icmpv6 типу луна-запиту -j DROP Якщо ви збираєтеся статично налаштувати адресу комп'ютера, він повинен ігнорувати оголошення маршрутизатора, який може додати ще одну адресу IPv6 до інтерфейсу або змінювати важливі параметри мережі: -A RH-Firewall-1-INPUT -p ICMPv6 --icmpv6 типу маршрутизатора Реклама -j DROP Обмеження інших типів повідомлень ICMPv6 в / і т.д. / sysconfig / ip6tables не рекомендується, так як операції IPv6, в значній мірі залежить від ICMPv6. Таким чином, більш необхідно дотримуватися обережності при блокуванні типів ICMPv6. 2.5.5.3.3 Видалити IPsec Правила Якщо система не буде обробляти трафік IPsec, а потім видаліть наступні правила: 74 ГЛАВА 2. загальносистемних конфігурації -A RH-Firewall-1-INPUT -p 50 -j ACCEPT -A RH-Firewall-1-INPUT -p 51 -j ACCEPT 2.5.5.3.4 Log і відкидати пакети з підозрілими адресами джерела Пакети з не маршрутизуються адресами джерела повинні бути відхилені, так як вони можуть вказувати на підробку. Тому що модифікована політика буде відкидати незбіжних пакети, вам потрібно тільки додати ці правила, якщо ви зацікавлені в також реєстрації цих підміну або підозрілих спроб, перш ніж вони впали. Якщо ви вирішили увійти різні підозрілий трафіку, додайте однакові правила з метою скидання після кожного журналу. Для того, щоб увійти, а потім відкинути ці пакети IPv4, вставте наступні правила в / і т.д. / sysconfig / IPTables (за винятком будь-які, які навмисно використовуються): -A -i Eth0 ВВЕДЕННЯ -s 10.0.0.0/8 -j LOG --log-приставка "IP DROP підробити:" -A -i Eth0 ВВЕДЕННЯ -s 172.16.0.0/12 -j LOG --log-префікс "IP DROP підробити B:" -A -i Eth0 ВВЕДЕННЯ -s 192.168.0.0/16 -j LOG --log-префікс "IP DROP підробити C:" -A -i Eth0 ВВЕДЕННЯ -s 224.0.0.0/4 -j LOG --log-префікс "IP DROP MULTICAST D:" -A -i Eth0 ВВЕДЕННЯ -s 240.0.0.0/5 -j LOG --log-префікс "IP DROP підробити E:" -A -i Eth0 ВВЕДЕННЯ -d 127.0.0.0/8 -j LOG --log-приставка "IP DROP LOOPBACK:" Крім того, ви можете захотіти реєструвати пакети, що містять деякі IPv6 резервовані адреси, якщо вони не очікується в мережі: -А ВХІД -i eth0 -s :: 1 -j LOG --log-приставка "IPv6 DROP LOOPBACK:" -A -s 2002 ВХІД: E000 :: / 20 -j LOG --log-префікс "IPv6 6to4 РУХУ:" -A -s 2002 ВХІД: 7F00 :: / 24 -j LOG --log-приставка "IPv6 6to4 РУХУ:" -A -s 2002 ВХІД 0000 :: / 24 -j LOG --log-приставка "IPv6 6to4 РУХУ:" -A -s 2002 ВХІД: FF00 :: / 24 -j LOG --log-префікс "IPv6 6to4 РУХУ:" -A -s 2002 ВХІД: 0A00 :: / 24 -j LOG --log-приставка "IPv6 6to4 РУХУ:" -A -s 2002 ВХІД: AC10 :: / 28 -j LOG --log-префікс "IPv6 6to4 РУХУ:" -A -s 2002 ВХІД: C0A8 :: / 32 -j LOG --log-приставка "IPv6 6to4 РУХУ:" Якщо ви не очікували побачити локального сайту під LGPL або автоматичною тунельний трафіку, ви можете увійти ті: -A -s ВХІД FF05 :: / 16 -j LOG --log-префікс "IPv6 локального сайту Multicast:" -A -s ВВЕДЕННЯ :: 0.0.0.0/96~~dobj -j LOG --log-префікс "IPv4 сумісності IPv6 ADDR:" Якщо ви хочете заблокувати багатоадресних всім локальної зв'язку вузлів (наприклад, якщо ви не використовуєте маршрутизатор автоматичної конфігурації та не планують мати будь-які послуги, які Multicast для всієї локальної мережі), ви можете блокувати локальної зв'язку все-вузли груповий адресу (перед тим як прийняти вхідний ICMPv6): -A ВХІД -d FF02 :: 1 -j LOG --log-приставка "Link-місний All-Вершини Multicast:" Проте, якщо ви збираєтеся дозволити IPv4 сумісні адреси IPv6 (форми :: 0.0.0.0/96~~HEAD=pobj), ви повинні а потім розглянути питання про реєстрацію немаршрутізіруемие IPv4-сумісні адреси: -A -s ВВЕДЕННЯ :: 0.0.0.0/104~~dobj -j LOG --log-префікс "IP немаршрутізіруемие ADDR:" -A -s ВВЕДЕННЯ :: 127.0.0.0/104~~dobj -j LOG --log-префікс "DROP LOOPBACK IP:" -A -s ВВЕДЕННЯ :: 224.0.0.0.0 / 100 -j LOG --log-префікс "IP DROP MULTICAST D:" -A -s ВВЕДЕННЯ :: 255.0.0.0/104~~dobj -j LOG --log-префікс "IP Трансляція:" Якщо ви не очікували побачити будь-яких IPv4 (або IPv4-сумісний) трафік в мережі, розглянути його реєстрації поки він не впав: 75 -A -s ВВЕДЕННЯ :: FFFF: 0.0.0.0/96~~HEAD=dobj -j LOG --log-префікс "IPv4 IPv6, відображений ADDR:" -A -s ВХІД 2002 :: / 16 -j LOG --log-приставка "IPv6 6to4 ADDR:" Наступне правило буде реєструвати весь трафік, що виходить з сайту локальну адресу, який є застарілим адресний простір: -A -s ВХІД FEC0 :: / 10 -j LOG --log-приставка "САЙТ-МІСЦЕВИЙ АДРЕСА РУХУ:" 2.5.5.3.5 Увійти, щоб падіння Решта пакети Для того, щоб увійти, перш ніж кинути все пакети, які явно не прийняті попередніми правилами, змінити останні рядки від -A RH-Firewall-1-INPUT -j REJECT --reject-ІКМП-хост забороненим COMMIT до -A RH-Firewall-1-INPUT -j LOG -A RH-Firewall-1-INPUT -j DROP COMMIT Правило, щоб реєструвати всі відкинуті пакети повинні використовуватися з обережністю. Балакучий, але в іншому випадку невредоносной мережеві протоколи (Наприклад, NetBIOS) може привести до об'ємистих колод; введення більш ранніх правил явно відкинути свої пакети без ведення журналу може бути доцільним. 2.5.5.4 Подальше зміцнення Подальше зміцнення, зокрема, в результаті настройки до конкретного середовища, можливо, для Iptables правила. Розглянемо наступні варіанти, хоча їх практичність залежить від мережевого середовища та сценарій використання: ?? Обмеження вихідного трафіку. Як було показано вище, політика Вихідний сигнал за замовчуванням Chain може бути змінений на DROP, і правила можуть бути записані спеціально дозволити тільки певні типи вихідного трафіку. Така політика може запобігти випадковому використання небезпечних протоколів, таких як FTP і Telnet, або навіть зірвати програм-шпигунів. Проте, було б до сих пір не заважає досвідченим користувачем або програму за допомогою проксі-сервера для обходу передбачуваних наслідків, і багато клієнтські програми навіть намагаються автоматично тунель через порт 80, щоб уникнути таких обмежень. ?? SYN захисту від повеней. захист від повеней SYN може бути забезпечена IPTables, але може зіткнутися обмеження Питання для серверів. Наприклад, матч iplimit може бути використано для обмеження одночасних підключень з даного хоста або класу. Крім того, недавній матч дозволяє брандмауера заборонити додаткові підключення з будь-якого провести протягом певного періоду часу (наприклад, більш ніж на 3 -state нових з'єднань на порт 22 протягом хвилини для запобігання словникових атак входу в систему). Більш точний варіант для захисту від DoS використовує TCP SYN печиво. (Дивіться розділ 2.5.1.2 для отримання додаткової інформації.) 2.5.5.5 Додаткові джерела Більш складний, обмежувальний характер, і потужні набори правил можуть бути створені, але це вимагає ретельної настройки, який залежить на знання конкретної середовища. Наступні ресурси містять більш детальну інформацію: 76 ГЛАВА 2. загальносистемних конфігурації ?? У Iptables (8) сторінка людини ?? У документації NETFILTER проекту на http://www.netfilter.org ?? Red Hat Enterprise Linux Довідкове керівництво 2.5.6 Secure Sockets Layer Підтримка Протокол Secure Sockets Layer (SSL) забезпечує шифрування і аутентифікації мережевих комунікацій, а також багато мережеві послуги включають в себе підтримку. Використання SSL рекомендується, особливо, щоб уникнути будь-якого відкритого тексту передача конфіденційних даних, навіть через локальну мережу. Реалізація SSL входить система називається OpenSSL. Останні реалізації SSL також може називатися як Transport Layer Security (TLS). SSL використовує криптографію з відкритим ключем для забезпечення аутентифікації і шифрування. Криптографія з відкритим ключем включає в себе два ключа, один називається відкритим ключем, а інший називається закритий ключ. Ці ключі математично пов'язані таким чином, що дані, зашифровані за допомогою одного ключа може бути розшифровано тільки за допомогою іншого, і навпаки. Як їх імена запропонувати, відкриті ключі можуть бути поширені на тих, хто в той час як секретний ключ повинен залишатися відомий тільки його власнику. SSL використовує сертифікати, які є файли, які містять криптографічні дані: відкритий ключ і підпис цієї публіки ключ. При перевірці достовірності SSL, сервер являє клієнта з його сертифікатом, як засіб демонстрації того, що йому в тому, хто це стверджує, що це. Якщо все піде правильно, то клієнт може перевірити сертифікат сервера шляхом визначення що підпис в сертифікаті може тільки були отримані третіми особами, яких клієнт довіряє. Ця третя сторона називається центром сертифікації (ЦС). Кожна клієнтська система також повинна мати сертифікати довірених центрів сертифікації, і клієнт використовує ці сертифікати ЦС для перевірки справжності сертифіката сервера. після аутентифікації сервера, використовуючи свій сертифікат і сертифікат ЦС, SSL забезпечує шифрування за допомогою сервера сертифікат, щоб надійно вести переговори загальний секретний ключ. Якщо ваш сервер повинен здійснювати зв'язок з використанням протоколу SSL з системами, які не могли б бути в змозі надійно прийняти новий CA сертифікат до будь-якого SSL зв'язку, а потім платити встановлену CA (чиї сертифікати ваші клієнти вже є) підписувати свої сертифікати сервера рекомендується. Кроки робити це залежить від постачальника. Після того, як підписаний сертифікати були отримані, конфігурація послуг такий же, чи були вони придбані у постачальника або підписана вашим власним CA. Для створення внутрішньої мережі та шифрування локального трафіку, створюючи свій власний CA підписати SSL сертифікати може бути доцільним. Основні кроки в цьому процесі є: 1. Створення центру сертифікації для підпису сертифікатів 2. Створення SSL-сертифікатів для серверів, що використовують цей CA 3. Включити підтримку клієнтів шляхом поширення сертифіката ЦС 2.5.6.1 Створення центру сертифікації для підпису сертифікатів Наступні інструкції відносяться до OpenSSL, так як він входить в систему, а й створення центру сертифікації можна з будь-яким відповідають стандартам SSL інструментарію. Безпека сертифікатів залежить від безпеки ЦС, підписав їх, таким чином виконуючи ці дії на безпечній машині має вирішальне значення. Система, яка використовується в якості ЦС повинен бути фізично безпечним і не підключений до мережі. Він повинен отримати будь-який сертифікат для підпису запитів (СПГС) за допомогою знімні носії і вихідні сертифікати на знімний носій. Сценарій / і т.д. / ПКІ / TLS / Misc / CA включений, щоб допомогти в процесі створення CA. Цей скрипт використовує багато Налаштування в /etc/pki/tls/openssl.cnf. Налаштування в цьому файлі можуть бути змінені відповідно до ваших потреб і дозволити простіше вибір налаштувань за замовчуванням, зокрема, в розділі [REQ] відмітна ім'я. 77 Для створення CA: # Кд / і т.д. / ПКІ / TLS / різний # ./CA -newca ?? У відповідь на запит натисніть клавішу ENTER, щоб створити новий ключ ЦС з ім'ям за умовчанням cakey.pem в. ?? У відповідь на запит введіть пароль, який буде захищати закритий ключ, а потім введіть той же пароль ще раз, щоб перевірити його. ?? На підказкам, заповніть якомога більше інформації CA, як актуальна для вашого сайту. необхідно вказати загальна назва, або генерація сертифіката авторизації зазнає невдачі. ?? Далі, вам буде запропоновано ввести пароль, так що сценарій може повторно відкрити закритий ключ для того, написати сертифікат. Цей крок виконує наступні дії: ?? створює каталог / і т.д. / ПКІ / CA (за замовчуванням), який містить файли, необхідні для роботи сертифіката авторитет. До них відносяться: - Послідовний порт, який містить поточний серійний номер для сертифікатів, підписаних CA - Index.txt, який представляє собою файл бази даних текст, який містить інформацію про сертифікати, підписаних - CRL, який є каталогом для зберігання відкликані сертифікати - Приватний, каталог, який зберігає секретний ключ ЦС ?? створює пару відкритий-закритий ключ для ЦС в файлі /etc/pki/CA/private/cakey.pem. секретний ключ повинні зберігатися в таємниці з метою забезпечення безпеки сертифікатів ЦС пізніше знак. ?? підписує відкритий ключ (за допомогою відповідного секретного ключа, в процесі, званому власного підпису), щоб створити CA Сертифікат, який потім зберігається в /etc/pki/CA/cacert.pem. Коли CA пізніше підписує сертифікат сервера, використовуючи свій закритий ключ, то це означає, що він ручається за достовірність з цього сервера. Потім клієнт може використовувати сертифікат ЦС (який містить відкритий ключ) для перевірки автентичності сертифіката сервера. Для досягнення цієї мети, необхідно поширити сертифікат ЦС будь-яким клієнтам як відображаються в розділі 2.5.6.3. 2.5.6.2 Створення сертифікатів SSL для серверів Створення сертифіката SSL для сервера включає наступні кроки: 1. державно-приватного пара ключів для сервера повинен бути сформований. 2. Запит на підпис сертифіката (CSR) повинні бути створені з пари ключів. 3. CSR повинен бути підписаний центром сертифікації (CA) для створення сертифіката сервера. Якщо ЦС був встановити, як описано в розділі 2.5.6.1, він може підписати CSR. 4. Сертифікат та ключі сервер повинен бути встановлений на сервері. Інструкції про те, як створювати і знак SSL сертифікати призначені для наступних загальних служб: ?? Поштовий сервер, в розділі 3.11.4.6. ?? Голубник, в розділі 3.17.2.2. ?? Apache, в розділі 3.16.4.1. 78 ГЛАВА 2. загальносистемних конфігурації 2.5.6.3 Включення підтримки клієнтів Система поставляється з сертифікатами відомих комерційних центрів сертифікації. Якщо ваші сертифікати сервера були підписані один з цих визначених центрів сертифікації, то цей крок не є необхідним, так як клієнти повинні включати сертифікат ЦС вже. Якщо ваші сервери використовують сертифікати, підписані вашим власним CA, деякі призначені для користувача програми будуть попереджати, що сертифікат сервера не можуть бути перевірені, так як СА не розпізнає. Інші додатки можуть просто не прийняти сертифікат і відмовляються працювати, або продовжувати працювати без необхідності належним чином перевірити сертифікат сервера. Щоб уникнути цього попередження, і належним чином перевірити справжність серверів, ваш сертифікат ЦС повинен бути експортовані в кожен додатки на кожній клієнтській системі, які будуть підключатися до сервера SSL з підтримкою. 2.5.6.3.1 Додавання довіреної центру сертифікації для Firefox Firefox повинен мати сертифікат від ЦС, який підписав сертифікат веб-сервера, так що він може перевірити справжність веб-сервер. Щоб імпортувати новий сертифікат центру сертифікації в Firefox 3: 1. Запустіть Firefox і виберіть Установки в меню Правка. 2. Натисніть кнопку Додатково. 3. Виберіть вкладку Шифрування. 4. Натисніть на кнопку Перегляд сертифікатів. 5. Виберіть вкладку влади. 6. Натисніть кнопку Імпорт в нижній частині екрана. 7. Перейдіть до сертифіката CA і імпортувати його. Визначити, чи слід СА використовуватися для ідентифікації веб-сайти, користувачі електронної пошти, а також розробники програмного забезпечення і довіряти йому для кожного відповідно. 2.5.6.3.2 Додавання довіреної центру сертифікації для Thunderbird Thunderbird повинен мати сертифікат від ЦС, яка підписала сертифікат поштового сервера, так що він може перевірити справжність поштового сервера (ів). Щоб імпортувати новий сертифікат CA в Thunderbird 2: 1. Запустіть Thunderbird і виберіть Установки в меню Правка. 2. Натисніть кнопку Додатково. 3. Виберіть вкладку Сертифікати. 4. Натисніть на кнопку Перегляд сертифікатів. 5. Виберіть вкладку влади. 6. Натисніть кнопку Імпорт в нижній частині екрана. 7. Перейдіть до сертифіката CA і імпортувати його. Визначити, чи слід СА використовуватися для ідентифікації веб-сайти, користувачі електронної пошти, а також розробники програмного забезпечення і довіряти йому для кожного відповідно. 79 2.5.6.3.3 Додавання довіреної центру сертифікації для Evolution Клієнт електронної пошти Evolution повинен мати сертифікат від ЦС, яка підписала сертифікати на поштовий сервер, так що що він може перевірити справжність поштового сервера (ів). Щоб імпортувати новий сертифікат CA в Evolution: 1. Запуск Evolution і виберіть Установки в меню Правка. 2. Виберіть Сертифікати зі списку значків зліва. 3. Перейдіть на вкладку влади. 4. Натисніть кнопку Імпорт. 5. Перейдіть до сертифіката CA і імпортувати його. 2.5.6.3.4 Видалити центри сертифікації, якщо це необхідно Оглянути влади сертифікатів довіряють Firefox, Thunderbird, Evolution або інших мережевих клієнтів. Перелік сертифікатів органів по кожній програмі можна знайти за допомогою графічного інтерфейсу користувача, як описано в попередніх розділах. Видаліть органи сертифікатів, які не підходять для ваших потреб мережевих підключень. Це може мати сенс тільки для деяких середовищах, і може створити проблеми для загального призначення Підключених до Інтернету система. 2.5.6.4 Додаткові джерела ?? Домашня сторінка OpenSSL Project в http://www.openssl.org ?? OpenSSL (1) чоловік сторінка ?? як до Джеремі Mates в: http://sial.org/howto/openssl 2.5.7 Незвичайне Мережеві протоколи Система включає в себе підтримку кількох мережевих протоколів, які зазвичай не використовуються. Хоча уразливості в системі безпеки в ядрі мережевий код не часто виявляються, то наслідки можуть бути драматичними. забезпечення незвичайні мережеві протоколи відключені знижує ризик системи до атак, спрямованих на його реалізацію ці протоколи. Хоча ці протоколи звичайно не використовуються, щоб уникнути збоїв у вашій мережевому середовищі гарантуючи, що вони не потрібні, до їх відключення. 2.5.7.1 Відключити Підтримка DCCP Якщо протокол DCCP не потрібно, його модуль ядра можна запобігти завантаження. Для цього додайте наступний рядок /etc/modprobe.conf: 80 ГЛАВА 2. загальносистемних конфігурації встановити DCCP / бен / істинним CCE 14268-7 Протокол дейтаграм управління перевантаженням (DCCP) являє собою відносно новий протокол транспортного рівня, призначений для підтримка потокового мультимедіа та телефонії. 2.5.7.2 Відключити Підтримка SCTP Якщо протокол SCTP не потрібен, то його модуль ядра можна запобігти завантаження. Для цього додайте наступний рядок /etc/modprobe.conf: встановити SCTP / бен / істинним CCE 14132-5 Протокол управління передачею потоку (SCTP) являє собою протокол транспортного рівня, призначений для підтримки ідеї з повідомлень, орієнтованих на спілкування, з декількома потоками повідомлень в межах одного з'єднання. 2.5.7.3 Відключити Підтримка RDS Якщо протокол RDS не потрібно, його модуль ядра можна запобігти завантаження. Для цього додайте наступний рядок /etc/modprobe.conf: встановити постр / бен / істинним CCE 14027-7 У Reliable Datagram Sockets (RDS) це протокол транспортного рівня, призначений для забезпечення надійного highbandwidth, з низьким рівнем затримки при передачі повідомлень між вузлами в кластері. 2.5.7.4 Відключити Підтримка TIPC Якщо протокол TIPC не потрібен, то його модуль ядра можна запобігти завантаження. Для цього додайте наступний рядок /etc/modprobe.conf: встановити TIPC / бен / істинним CCE 14911-2 Протокол Transparent Inter-Process Communication (TIPC) призначена для забезпечення зв'язку між вузли в кластері. 2.5.8 протоколу IPsec Internet Protocol Security (IPsec) забезпечує можливість шифрування і аутентифікації IP-комунікацій. 81 2.5.8.1 Використання Openswan для IPsec 2.5.8.1.1 Встановіть пакет openswan Програмне забезпечення Openswan рекомендується над протоколом IPsec пакет інструментів за замовчуванням для протоколу IPsec. Встановіть його з команда: # Ням встановити openswan 2.5.8.1.2 Видаліть протоколу IPSec Пакет інструментів Оскільки пакет openswan надає надмножество функціональності, видаліть пакет протоколу IPSec інструменти: # Ням видалити IPSEC-інструменти 2.6 Ведення і аудит Успішні локальні або мережеві атаки на системи, не обов'язково залишати чіткі докази того, що сталося. це Необхідно створити конфігурацію заздалегідь, що збирає ці дані, як для того, щоб визначити, що щось аномальне сталося, і для того, щоб реагувати відповідним чином. Крім того, добре сконфігурованих каротаж і інфраструктура аудит покаже докази будь неправильної конфігурації, які можуть покинути систему вразливою для атака. Протоколювання і аудит використовують різні підходи до збору даних. Каротажний інфраструктура забезпечує основу для окремих програм, що працюють в системі, щоб повідомити те, що події, які вважаються цікаво: SSHD Програма може повідомляти про кожен успішний або невдалої спроби входу в систему, в той час як програма Sendmail може повідомляти кожен раз, коли він посилає по електронній пошті від імені локального або віддаленого користувача. Аудит інфраструктури, з іншого боку, повідомляє кожен екземпляр деяких низькорівневих подій, таких як вхід в системний виклик УИП, незалежно від того, яка програма заподіяної статися подія. Аудит має перевагу бути більш всеосяжним, але недолік звітності велика кількість інформація, більшість з яких є нецікавим. Logging (зокрема, з використанням стандартної структури, як Syslogd) має Перевага сумісності з широким спектром клієнтських додатків, а також повідомляти тільки ту інформацію, вважаються важливими для кожної програми, але недолік, що повідомляє інформація не відповідає між додатками. Надійна інфраструктура буде виконувати як протоколювання і аудит, і буде використовувати настроюються автоматизовані методи узагальнення звітних даних, так що системні адміністратори можуть видаляти або стискати звіти про події, відомих щоб бути нецікавим на користь оповіщення моніторингу для подій, відомих бути цікавим. У цьому розділі описується, як налаштувати ведення журналу, журнал моніторингу та аудиту, за допомогою інструментів, включених з RHEL5. Рекомендується використовувати Rsyslog для реєстрації, з Logwatch забезпечення реферування). auditd повинен використовуватися для аудиту, з aureport забезпечення узагальнення. 2.6.1 Налаштування ведення журналу У цьому розділі представлені два пакети в RHEL 5 для виконання рубок, і рекомендує Rsyslog бути використаним. 82 ГЛАВА 2. загальносистемних конфігурації Незалежно від того, яке програмне забезпечення протоколювання використовується, система не повинна посилати свої журнали на віддалений змінну LOGHOST. Зловмисник, який скомпрометувала кореневу обліковий запис на комп'ютері, може видалити записи журналу, які вказують, що система нападу, перш ніж вони розглядаються адміністратором. Якщо системні журнали повинні бути корисні при виявленні шкідливої ​​активності, необхідно відправити їх на віддалений сервер. CCE 3679-8 2.6.1.1 Налаштування Syslog Програмне забезпечення Sysklogd забезпечує реєстрації за замовчуванням демон для RHEL на, але має ряд недоліків, в тому числі відсутність аутентифікації для клієнта або сервера, відсутність шифрування або надійного транспорту для повідомлень, переданих по мережу. З цих причин, Rsyslog рекомендується замість цього (і це також є частиною RHEL). Він описаний в наступному в Розділ 2.6.1.2. При використанні програмного забезпечення Sysklogd для реєстрації як і раніше необхідно, в цьому розділі розповідається, як налаштувати його Syslog демон для досягнення найкращого ефекту. 2.6.1.1.1 Переконайтеся, всі важливі повідомлення зберігаються Редагування файлу /etc/syslog.conf. Додати або виправити в залежності від того з наступних рядків підходять для вашого навколишнє середовище: AUTH, користувач. * / VAR / Журнал / повідомлення Керн. * /var/log/kern.log демон. * /var/log/daemon.log Syslog. * / Var / Журнал / Syslog LPR, новини, UUCP, local0, local1, local2, local3, LOCAL4, local5, local6. * /var/log/unused.log Коли повідомлення надсилається в системний журнал для реєстрації, він відправляється з ім'ям об'єкта (такі як пошта, Auth або Local2), і пріоритетом (наприклад, налагоджувати, повідомлення або екстра). Кожен рядок файлу конфігурації Syslog є директива, яка визначає набір об'єкта / пріоритетних пар, а потім дає ім'я файлу або хост, до якого реєструвати повідомлення про відповідних типів повинні бути відправлені. Для того, щоб повідомлення, щоб відповідати типу, об'єкт повинен відповідати, і пріоритет повинен бути відданий пріоритет названий на правилі або будь-якого більш високим пріоритетом. (Див syslog.conf (5) для впорядкованого списку пріоритетів.) Більш старі версії системний журнал уповноважена дуже обмежувальний формат файлу syslog.conf. Проте, версія це керівництво 2.6.1.1.1 Переконайтеся, всі важливі повідомлення зберігаються Редагування файлу /etc/syslog.conf. Додати або виправити в залежності від того з наступних рядків підходять для вашого навколишнє середовище: AUTH, користувач. * / VAR / Журнал / повідомлення Керн. * /var/log/kern.log демон. * /var/log/daemon.log Syslog. * / Var / Журнал / Syslog LPR, новини, UUCP, local0, local1, local2, local3, LOCAL4, local5, local6. * /var/log/unused.log Коли повідомлення надсилається в системний журнал для реєстрації, він відправляється з ім'ям об'єкта (такі як пошта, Auth або Local2), і пріоритетом (наприклад, налагоджувати, повідомлення або екстра). Кожен рядок файлу конфігурації Syslog є директива, яка визначає набір об'єкта / пріоритетних пар, а потім дає ім'я файлу або хост, до якого реєструвати повідомлення про відповідних типів повинні бути відправлені. Для того, щоб повідомлення, щоб відповідати типу, об'єкт повинен відповідати, і пріоритет повинен бути відданий пріоритет названий на правилі або будь-якого більш високим пріоритетом. (Див syslog.conf (5) для впорядкованого списку пріоритетів.) Більш старі версії системний журнал уповноважена дуже обмежувальний формат файлу syslog.conf. Проте, версія Syslog поставляється з RHEL5 дозволяє будь-якої прогалин (прогалини або вкладок, а не тільки вкладки), щоб відокремити вибір критерії від розташування повідомлень, а також дозволяє використовувати об'єкт. * в якості шаблону відповідності даного об'єкта в будь-який черговості. Конфігурація системного журналу RHEL5 за замовчуванням зберігає споруд authpriv, хрон і пошти в названих журналах. це керівництво описує реалізацію наступної конфігурації, але і будь-якої конфігурації, яка зберігає важливі засоби і може використовуватися адміністраторами буде досить: ?? Зберігайте кожен з об'єктів, KERN демона, і системний журнал в своєму журналі, так що це буде легко отримати доступ Інформація про повідомлення від цих об'єктів. ?? Обмежити інформацію, що зберігається в / Var / Журнал / повідомлення тільки об'єктів AUTH і користувача, і зберігати всі Повідомлення від цих об'єктів. Повідомлення можуть легко стати метушню в іншому випадку. ?? Зберігати інформацію про всі об'єкти, які не повинні бути у використанні на даному сайті, в файлі з ім'ям / Var / Журнал / unused.log. Якщо будь-які повідомлення записуються в цей файл в якийсь момент в майбутньому, це може бути ознакою того, що невідома служба працює, і повинні бути досліджені. Крім того, якщо новини і UUCP не використовуються в цей сайт, видалити директиву з syslog.conf за замовчуванням, який зберігає ці об'єкти. 83 Використовуючи місцевих об'єктів також рекомендується. Конкретна конфігурація виходить за рамки даного керівництва, але додатки, такі як SSH може бути легко налаштований на вхід в локальний об'єкт, який не використовується для будь-що інше. Якщо це буде зроблено, переналаштувати /etc/syslog.conf для зберігання цього об'єкта у відповідному журналі з ім'ям або в / Var / Журнал / повідомлення, а не в /var/log/unused.log. 2.6.1.1.2 Підтвердження існування і дозволу системи файлів журналів Для кожного файлу журналу LOGFILE посилання в /etc/syslog.conf або /etc/rsyslog.conf, виконайте команди: # Сенсорний LOGFILE # Чаун корінь: корінь LOGFILE # CHMOD 0600 LOGFILE CCE 3701-0, 4233-3, 4366-1 Syslog відмовиться увійти в файл, який не існує. Всі повідомлення, призначені для цього файлу будуть відкидатися без, тому важливо, щоб переконатися, що всі файли журналів існують. Деякі журнали можуть містити конфіденційну інформацію, так що краще Обмеження дозволів таким чином, щоб тільки адміністративні користувачі можуть читати або писати логах. 2.6.1.1.3 відправляти журнали на віддалений змінну LOGHOST Редагування /etc/syslog.conf. Додати або виправити рядок: *. * @ Loghost.example.com де loghost.example.com це ім'я вашого центрального сервера журналу. CCE 4260-6 Особливо важливо, що журнали зберігаються на локальному хості на додаток до відправки в змінну LOGHOST, тому що Syslogd використовує UDP-протокол для відправки повідомлень по мережі. UDP не гарантує надійну доставку і помірно зайняті сайти будуть втрачати повідомлення журналу час від часу, особливо в періоди високого трафіку, які можуть бути Результат атаки. Крім того, віддалені Syslogd повідомлення не пройшов перевірку автентичності, тому він легко для атакуючого ввести помилкових повідомлень на центральний сервер журналу. Крім того, деякі проблеми викликають втрату підключення до мережі, який запобігає надсиланню повідомлень на центральний сервер. З усіх цих причин, краще увійти магазин Повідомлення і в центрі і на кожному хості, так що вони можуть бути співвіднесені, при необхідності. 2.6.1.1.4 Включити Syslogd Приймати видалені повідомлення на Loghosts тільки Чи є ця машина центральний сервер журналу для вашої організації? Якщо це так, відредагувати файл / і т.д. / sysconfig / системного журналу. Додати або виправити такий рядок: SYSLOGD_OPTIONS = "- т 0 -r -s example.com" де example.com це ім'я вашого домену. Якщо машина не є сервером журналу, редагувати / і т.д. / sysconfig / системний журнал, і замість того, щоб додати або виправити рядок: SYSLOGD_OPTIONS = "- т 0" CCE 3382-9 84 ГЛАВА 2. загальносистемних конфігурації За замовчуванням системний журнал RHEL5 в не слухає через мережу для повідомлень журналу. Прапор -r дозволяє Syslogd слухати по мережі, і їх слід використовувати тільки в разі потреби. Прапор -s example.com смуги домен ім'я example.com від імені хоста кожного передавального апарату перед протоколювання повідомлень від цього хоста, щоб зменшити кількість надлишкової інформації, розміщеної в лог-файлах. Дивіться Syslogd (8) сторінки для отримання додаткової інформації. 2.6.1.2 Налаштування Rsyslog Rsyslog програмне забезпечення рекомендується в якості заміни для Sysklogd за замовчуванням Демон. Rsyslog забезпечує поліпшення в порівнянні з Sysklogd, такі як орієнтований на з'єднання (тобто TCP) передача журналів, можливість увійти в формати баз даних, а також шифрування даних журналу на шляху до центрального серверу реєстрації. 2.6.1.2.1 Встановіть пакет Rsyslog Встановіть Rsyslog менеджер пакетів наступним чином: # Ням встановити Rsyslog 2.6.1.2.2 Переконайтеся, що Rsyslog послуга активується Для того, щоб переконатися, що служба Rsyslog активується, і Syslog демон Sysklogd не заважатиме вона, намагаючись запустити, виконайте наступні дії: # Chkconfig Syslog вимкнений # Chkconfig Rsyslog на Це дозволить забезпечити запуск Rsyslog на наступному завантаженні системи. Команда / SBIN / послуга може бути використана для змінити, щоб зробити ці зміни відбуваються негайно. 2.6.1.2.3 Забезпечення Важливі повідомлення зберігаються Редагування файлу /etc/rsyslog.conf. Додати або виправити в залежності від того з наступних рядків підходять для вашого навколишнє середовище: авт. *, користувач. * / VAR / Журнал / повідомлення Керн. * /var/log/kern.log демон. * /var/log/daemon.log Syslog. * / Var / Журнал / Syslog LPR, новини, UUCP, local0, local1, local2, local3, LOCAL4, local5, local6. * /var/log/unused.log Дивіться довідкову сторінку rsyslog.conf (5) для отримання додаткової інформації. За замовчуванням, Rsyslog використовує формат тимчасових міток, що Logwatch не розуміє. Якщо у вашому середовищі використовує Logwatch, відредагувати файл / і т.д. / Rsyslog. конф і додати або відредагувати наступний рядок: $ ActionFileDefaultTemplate Rsyslog TraditionalFileFormat 85 2.6.1.2.4 Підтвердження існування і дозволу файлів журналів Для кожного файлу журналу LOGFILE посилання в /etc/rsyslog.conf, виконайте команди: # Сенсорний LOGFILE # Чаун корінь: корінь LOGFILE # CHMOD 0600 LOGFILE 2.6.1.2.5 відправку журналів на віддалений хост за допомогою надійних транспортних Редагування /etc/rsyslog.conf. Додати або виправити рядок: *. * @@ Loghost.example.com де loghost.example.com це ім'я вашого центрального сервера журналу. Ця директива повинна з'явитися на всіх системи за винятком самого системного журналу сервера. Подвійний символ @ перед лог-хоста означає, що TCP буде використовуватися для відправки повідомлень на сервер. Rsyslog підтримує TCP для передачі журналу, що забезпечує більш надійну мережеву зв'язок, ніж UDP. 2.6.1.2.6 Включити Rsyslog Приймати видалені повідомлення на Loghosts тільки Чи є ця машина центральний сервер журналу для вашої організації? Якщо так, то відредагувати файл /etc/rsyslog.conf. Додати або виправити такі рядки: $ MODLOAD imtcp.so $ InputTCPServerRun 514 Ці директиви проінструктувати rsyslogd отримувати повідомлення від мережі. Директиви, які дозволяють отримувати повідомлення по мережі, такі як $ InputTCPServerRun, $ InputUDPServerRun і $ InputRELPServerRun не повинні з'являтися на клієнтських системах. За замовчуванням, Rsyslog не слухає через мережу для повідомлень журналу. MODLOAD говорить Rsyslog для завантаження модуль imtcp.so так що він може прослуховувати по мережі через TCP, і їх слід використовувати тільки в разі потреби. Опція InputTCPServerRun наказує rsyslogd прослуховувати вказаний порт TCP. Дивіться rsyslogd (8) сторінка для отримання додаткової інформації. 2.6.1.3 Logrotate 2.6.1.3.1 Переконайтеся Всі журнали повертаються Редагування файлу /etc/logrotate.d/syslog. Знайти перший рядок, яка повинна виглядати наступним чином (загорнуті для ясності): / Var / Журнал / повідомлення / Var / Журнал / безпечний / Var / Журнал / MAILLOG / Var / Журнал / Спулер \ /var/log/boot.log / Var / Журнал / хрон { Змініть цей рядок так, що він містить один розділений пробілами список кожного файлу журналу посилається в /etc/syslog.conf. CCE 4182-2 86 ГЛАВА 2. загальносистемних конфігурації Всі журнали в використання в системі необхідно регулярно повертати, або лог-файли будуть займати місце на диску з плином часу, в кінці кінців, втручання в роботу системи. Файл /etc/logrotate.d/syslog це конфігураційний файл, який використовується Logrotate програма для збереження всіх файлів журналу, написані системний журнал. За замовчуванням, вона обертається журнали щотижня і зберігає чотири архівні копії кожного журналу. Ці параметри можуть бути змінені шляхом редагування /etc/logrotate.conf, але за замовчуванням є достатніми для цілей даного керівництва. Зверніть увагу, що Logrotate запускається щоночі в хрон /etc/cron.daily/logrotate. Якщо особливо активних журналів повинні бути повернені частіше, ніж один раз в день, повинен бути використаний якийсь інший механізм. 2.6.1.4 Logwatch 2.6.1.4.1 контролювати підозрілу Повідомлення журналу з використанням Logwatch Система включає в себе расширяемую програму під назвою Logwatch для представлення інформації про незвичайних елементів в системному журналі. Logwatch є цінним, оскільки він забезпечує парсер для системного журналу формату введення і кількість підписів для типів ліній які вважаються мирського або примітні. Logwatch має ряд недоліків: Підписи можуть бути неточними і не завжди класифікуються послідовно, і ви повинні бути в змозі програмувати на Perl для того, щоб налаштувати базу даних сигнатур. Проте, рекомендується, щоб всі сайти Linux, які не встигають розгорнути додаток журналу моніторингу стороннього запуску Logwatch в конфігурації за замовчуванням. Це забезпечує деякі корисна інформація про роботу системи в обмін на дуже мало зусиль адміністратора. Це керівництво рекомендує Logwatch працювати тільки на центральному LogServer, якщо ваш сайт має один, щоб сфокусуватися увагу адміністратора, посилаючи все щоденники в одній електронній пошті. 2.6.1.4.2 Налаштування Logwatch на сервері Central Log Чи є ця машина центральний сервер журналу? Якщо так, то відредагувати файл /etc/logwatch/conf/logwatch.conf. Додати або виправити такі рядки: HostLimit = немає SplitHosts = так MultiEmail = немає Сервіс = -zz-disk_space Переконайтеся в тому, що logwatch.pl запускається щоночі з cron'а. (Це значення за замовчуванням): # CD /etc/cron.daily # -s Пер /usr/share/logwatch/scripts/logwatch.pl 0logwatch CCE 4323-2 На центральній LogServer, ви хочете Logwatch підсумувати всі записи системного журналу, в тому числі і ті, які не відбуваються на самому LogServer. Установка HostLimit говорить Logwatch повідомляти про всі хостів, а не тільки той, на якому він біжить. Якщо SplitHosts встановлено, Logwatch відокремить записи по імені хоста. Це робить звіт довше, але значно зручнішим для використання. Якщо він не встановлений, то Logwatch не повідомив, який хост генерується даний запис в журналі, і що інформація майже завжди необхідно. Якщо MultiEmail встановлено, то інформація кожного хоста буде відправлений у окремий повідомлення електронної пошти. Це питання переваг. Директива Service -zz-дисковий простір говорить Logwatch не запускати звіт простору на ZZ-диск, в якому повідомляється про вільного місця на диску. Оскільки все моніторинг лог ведеться на центральному LogServer, дисковий простір реклама завжди буде що з LogServer, незалежно від того, який хост буде знаходитися під контролем. Це збиває з пантелику, тому відключити цю послугу. Примітка 87 що це не означає, що Logwatch не контролюватиме інформацію про використання диска. Багато обхідні шляхи можливі, таких як запуск ФР на кожному хості щодня через хрон і посилаючи висновок в системний журнал, так що він буде повідомлено LogServer. 2.6.1.4.3 Відключити Logwatch на клієнтах, якщо LogServer Exists Чи є у вашого сайту центральний LogServer, який був налаштований, щоб повідомити про журналах, отриманих від усіх систем? Якщо так: # Гт /etc/cron.daily/0logwatch Якщо немає LogServer не існує, то буде необхідно для кожної машини для запуску Logwatch індивідуально. використовуючи центральний LogServer забезпечує безпеку і надійність переваги, обговорювані раніше, а також робить журнали моніторингу простіше і менше часу інтенсивно для адміністраторів. 2.6.2 Система бухгалтерського обліку з auditd Служба аудиту передбачена система аудиту. За замовчуванням служба аудиту про SELinux AVC відмов і певні типи подій, що відносяться до безпеки, такі як система входів в систему, зміни облікових записів і подій аутентифікації здійснюється за допомогою таких програм, як Sudo. Відповідно до конфігурацією за умовчанням, auditd має скромні вимоги до дискового простору, і не повинні помітно вплив продуктивність системи. Служба аудиту, налаштований по крайней мере, його правил за замовчуванням, настійно рекомендується всі сайти, незалежно від того, чи є вони працювати SELinux. DoD або федеральні мережі часто мають суттєві вимоги аудиту і auditd можуть бути налаштовані для задоволення ці вимоги. Типові DoD вимоги включають в себе: ?? Переконайтеся, що аудит налаштоване для збору деяких системних подіях - Інформація про використання печатки Command (безуспішними і успішно) - Запуск і завершення роботи Events (невдалої і успішно) ?? Переконайтеся, що програмне забезпечення аудиту може записати наступну інформацію для кожної події аудиту: - Дата і час події - Userid, який ініціював подія - Тип події - Успіх чи невдача події - Для подій I & A, походження запиту (наприклад, ВД терміналу) - Для подій, ввести об'єкт в адресний простір користувача, і для об'єкта делеции подій, найменування об'єкта, а також в системах MLS, рівень безпеки об'єктів. ?? Переконайтеся, файли не копіюються, не менше ніж за тиждень на іншій системі, ніж система перевіряється або резервного копіювання інформації. ?? Переконайтеся, старі журнали закриті, і нові журнали аудиту запускаються щодня 88 ГЛАВА 2. загальносистемних конфігурації ?? Переконайтеся, що конфігурація незмінна. З 2-е встановлення перезавантаження буде необхідно змінити будь-який аудит правила. ?? Переконайтеся в тому, що файли даних аудиту мають права доступу 640, або більш обмежувальний характер. 2.6.2.1 Включити auditd службу Переконайтеся, що служба auditd включена (це за замовчуванням): # Chkconfig auditd на CCE 4292-9 За замовчуванням auditd журнали тільки SELinux відмов, які корисні для налагодження SELinux і виявлення вторгнень спроби, і певні типи подій безпеки, наприклад, зміни в облікових записів користувачів (useradd, PASSWD і т.д.), Вхід події та виклики на Sudo. Дані зберігаються в /var/log/audit/audit.log. За замовчуванням, auditd обертається 4 колод за розміром (5MB), зберігаючи при цьому максимум 20 МБ даних в цілому, і відмовляється писати записи, коли диск переповнений. Це зводить до мінімуму Ризик даних аудиту, що заповнюють його розділ і впливаючи на інші послуги. Проте, можна втратити дані аудиту, якщо система зайнята. 2.6.2.2 Налаштування auditd Утримання даних ?? Визначити STOREMB, обсяг даних аудиту (в мегабайтах), які повинні бути збережені в кожному журналі файл. Редагування файлу /etc/audit/auditd.conf. Додайте або змініть такий рядок: max_log_file = STOREMB ?? Використовуйте спеціальний розділ (або логічного тому) для лог-файлів. Це просто, щоб створити такий розділ або логічного тому під час установки системи. Перегородка повинна бути більше, ніж максимум простір, яке auditd буде коли-небудь використовувати, що максимальний розмір кожного файлу журналу (лог-файл), помноженої макс за кількістю файлів журналів (логів) NUM. Переконайтеся, що розділ монтується в / Var / Журнал / аудит. ?? Якщо ваш сайт вимагає, щоб машина була відключена, якщо аудит не може бути виконана, настройка auditd щоб зупинити систему, коли дисковий простір для аудиту вичерпується. Редагування /etc/audit/auditd.conf, а також додавати або виправити такі рядки: space_left_action = електронна пошта action_mail_acct = корінь admin_space_left_action = привал Дія за замовчуванням взяти при вході досягають свого максимального розміру, щоб обертати лог-файли, відкидаючи найстаріший. Якщо це більш важливо зберегти всю можливу інформацію аудиту, навіть якщо це відкриває можливість вичерпання простору і приймаючи дію, встановлене адміністратора ліве простір дії, додати або виправити рядок: max_log_file_action = keep_logs За замовчуванням, auditd зберігає 4 лог-файли розміром 5 Мб за штуку. Для зайнятої системі або системі, яка повністю активність системи аудиту, це, ймовірно, буде недостатньо. Розмір файлу журналу необхідно буде в значній мірі залежати від того, які типи подій, що перевіряється. Перший аудит Configure реєструвати всі події, що представляють інтерес. Потім контролювати розмір журналу вручну на деякий час, щоб визначити, який розмір файлу буде дозволить вам зберегти необхідні дані для правильного періоду часу. 89 Використовуючи спеціальний розділ для / вар / Журнал / аудит запобігає журнали auditd від руйнівного функціональності системи, якщо вони заповнюють, і, що більш важливо, запобігає іншу діяльність в / вар від заповнення розділу і зупинки аудиту Стежка. (Журнали аудиту розміру обмежені і тому навряд чи будуть рости необмежено, якщо вони не налаштовані зробити це.) Деякі машини можуть мати вимоги, що ніяких дій не відбувається, які не можуть бути перевірені. Якщо це так, то auditd може бути налаштований, щоб зупинити машину, якщо вона працює поза простором. Примітка: Так як більш старі журнали повертаються, настройка auditd таким чином не заважає старі журнали з повороту геть, перш ніж вони можуть бути переглянуті. Якщо ваша система налаштована, щоб зупинити при реєстрації не може бути виконана, переконайтеся, що це ніколи не може статися в нормальних умовах! Переконайтеся в тому, що / Var / Журнал / аудит в окремий розділ, і що цей розділ більше максимальна кількість auditd даних буде зберігати в нормальному режимі. 2.6.2.3 Включення аудиту для процесів, які починаються До аудиту Daemon Для того, щоб гарантувати, що всі процеси можуть бути перевірені, навіть ті, які починаються до демона аудиту, додайте Аргумент аудит = 1 в рядок ядра в /etc/grub.conf, в наведеному нижче порядку: Ядро / vmlinuz-версія ро = внутр VGA корінь = / DEV / VolGroup00 / LogVol00 rhgb тихий аудит = 1 CCE 15026-8 Кожен процес в системі несе "перевіряється" прапор, який вказує, чи може аудит її діяльності. Хоча auditd піклується про дозволяє це для всіх процесів, які запускають після того, як він робить, додавши ядро Аргумент гарантує, що він встановлений для кожного процесу під час завантаження. 2.6.2.4 Налаштування auditd правил для Всеохоплюючої аудиту Програма auditd може виконувати комплексний моніторинг активності системи. Цей розділ описує рекомендовані Параметри конфігурації для всебічного аудиту, але повний опис системи аудиту-х можливості виходить за рамки даного керівництва. Список розсилки linux-audit@redhat.com3 може бути хорошим джерелом подальшої інформації. Підсистема аудиту підтримує великий набір подій, в тому числі: ?? Трасування довільних системних викликів (визначених за імені або номеру) на в'їзді або виїзді. ?? Фільтрація по PID, UID, викличте успіх, аргумент системного виклику (з деякими обмеженнями), і т.д. ?? Моніторинг окремих файлів для модифікації вмісту файлу або метаданих. правила аудиту контролюються в файлі /etc/audit/audit.rules. Додайте правила до нього для виконання вимог аудиту для вашої організації. Кожен рядок в /etc/audit/audit.rules є ряд аргументів, можуть бути передані auditctl і може бути індивідуально протестовані як такі. Дивіться документацію в / USR / частки / DOC / аудит-версії і у відповідних сторінках керівництва для отримання більш докладної інформації. Правила Рекомендовані аудиту представлені в / USR / частки / DOC / аудит-версія /stig.rules. Для того, щоб активувати ці правила: # Ф / USR / частки / DOC / аудит-версія /stig.rules /etc/audit/audit.rules 3List інформацію можна знайти на сайті http://www.redhat.com/mailman/listinfo/linux-audit 90 ГЛАВА 2. загальносистемних конфігурації а потім редагувати /etc/audit/audit.rules і закоментуйте рядки, що містять арку = які не підходять для архітектури вашої системи. Потім проаналізувати і зрозуміти такі правила, що забезпечують правила активуються необхідний для відповідної архітектури. Після розгляду всіх правил, читаючи такі розділи, а також редагування при необхідності, активувати нові правила: # Перезапуск служби auditd 2.6.2.4.1 Записи Події, зміни дати і часу Додайте наступні рядки в /etc/audit/audit.rules, встановивши ARCH або b32 або B64 в залежності від конкретної система: -a завжди, вихід -F арка = ARCH -S Adjtimex -S settimeofday -S STIME -k часу зміни -a завжди, вихід -F арка = ARCH -S clock_settime -k часу зміни -w / і т.д. / LocalTime -p -k ва часу зміни CCE 14051-7 2.6.2.4.2 Запис подій, які модифікують користувач / група Інформація Додайте наступні рядки в /etc/audit/audit.rules для того, щоб фіксувати події, які модифікують зміни облікового запису: -w / і т.д. / групи користувачів -p -k ідентичність WA -w / і т.д. / пароль -p ва -k тотожність -w / і т.д. / gshadow -p ва -k тотожність -w / і т.д. / тінь -p -k ва ідентичності -w / і т.д. / безпека / opasswd -p ва -k тотожність CCE 14829-6 2.6.2.4.3 Запис подій, які змінюють мережеве оточення системи Додайте наступні рядки в /etc/audit/audit.rules, встановивши ARCH або b32 або B64 в залежності від конкретної система: -a вихід, завжди -F арка = ARCH -S sethostname -S setdomainname -k системи локаль -w / і т.д. / випуск -p -k ва системи мовної стандарт -w /etc/issue.net -p -k ва-система локаль -w / і т.д. / Хости -p ва -k системи мовної стандарт -w / і т.д. / sysconfig / мережу -p -k ва-система локаль CCE 14816-3 2.6.2.4.4 Запис подій, які змінюють мандатний контроль доступу системи Додайте наступний код /etc/audit/audit.rules: -w / і т.д. / SELinux / -p ва -k MAC-політика 91 CCE 14821-3 2.6.2.4.5 Запис спроби зміни входу в систему і вихід з системи подій Система аудиту вже збирає реєстраційну інформацію для всіх користувачів, так і корінь. Для того, щоб спостерігати за спробами ручного редагування в Файли, які беруть участь в зберіганні подій входу в систему, додайте наступні рядки в /etc/audit/audit.rules: -w / Var / Журнал / faillog -p ва -k логіни -w / Var / Журнал / LASTLOG -p ва -k логіни CCE 14904-7 2.6.2.4.6 Спроби записи для зміни процесу і Session Initiation Інформація Система аудиту вже збирає інформацію про процес для всіх користувачів і кореня. Для того, щоб стежити за спроби керівництва правки файлів, що беруть участь в зберіганні такої інформації про процес, додайте наступні рядки в /etc/audit/audit.rules: -w / вар / запустити / utmp -p ва -k сесія -w / Var / Журнал / btmp -p ва -k сесія -w / Var / Журнал / wtmp -p ва -k сесія CCE 14679-5 2.6.2.4.7 Забезпечення auditd Збирає Дискреционная Access Control Дозвіл Модифікація події Як мінімум система аудиту повинна збирати зміни дозволів файлів для всіх користувачів і кореня. додайте слідування /etc/audit/audit.rules, установка ARCH або b32 або B64 в залежності від обставин для вашої системи: -a завжди, вихід -F арка = ARCH -S CHMOD -S fchmod -S fchmodat -F auid> = 500 \ -F Auid! = 4294967295 -k perm_mod -a завжди, вихід -F арка = ARCH -S Чаун -S fchown -S fchownat -S lchown -F auid> = 500 \ -F Auid! = 4294967295 -k perm_mod -a завжди, вихід -F арка = ARCH -S setxattr -S lsetxattr -S fsetxattr -S removexattr -S \ lremovexattr -S fremovexattr -F auid> = 500 -F auid! = 4294967295 -k perm_mod CCE 14058-2 2.6.2.4.8 Забезпечення auditd Збирає несанкціоновані спроби доступу до файлів (невдало) Як мінімум система аудиту повинна збирати несанкціонований файл отримує доступ для всіх користувачів і кореня. додайте слідування /etc/audit/audit.rules, установка ARCH або b32 або B64 в залежності від обставин для вашої системи: -a завжди, вихід -F арка = ARCH -S Creat -S відкритим -S openat -S усічення -S ftruncate \ -F Вихід = -EACCES -F auid> = 500 -F auid! = 4294967295 -k доступу 92 ГЛАВА 2. загальносистемних конфігурації -a завжди, вихід -F арка = ARCH -S Creat -S відкритим -S openat -S усічення -S ftruncate \ -F Вихід = -EPERM -F auid> = 500 -F auid! = 4294967295 -k доступу CCE 14917-9 2.6.2.4.9 Забезпечення auditd Збирає інформацію про використання команд Привілейовані Як мінімум система аудиту повинна збирати виконання привілейованих команд для всіх користувачів і кореня. Для цього потрібно додати правило аудиту, щоб спостерігати за виконанням кожного Setuid або setgid програми. По-перше, виконайте наступну команду для кожної локальної частини розділу для створення правил, по одному для кожного УИП або setgid програма: # Знайти ЧАСТИНА -xdev \ (-perm -4000 -o -perm -2000 \) -тип п | AWK '{друк \ "-a Завжди, вихід -F шлях =" $ 1 "-F завивка = х -F auid> = 500 -F auid! = 4294967295 \ -k привілейованих "} ' Потім додайте ці рядки в /etc/audit/audit.rules. CCE 14296-8 2.6.2.4.10 Забезпечити auditd Збирає інформацію про експорт в засобах масової інформації (успішно) Як мінімум система аудиту слід збирати медіа експортування подій для всіх користувачів і кореня. додайте слідування /etc/audit/audit.rules, установка ARCH або b32 або B64 в залежності від обставин для вашої системи: -a завжди, вихід -F арка = ARCH-S монтування -F auid> = 500 -F auid! = 4294967295 -k експорт CCE 14569-8 2.6.2.4.11 Забезпечення auditd Збирає Файли Ділок Події Користувачем (успішної і невдалої) Як мінімум система аудиту слід збирати видалення файлів подій для всіх користувачів і кореня. Додайте наступний код до /etc/audit/audit.rules, установка ARCH або B32 або B64 в залежності від обставин для вашої системи: -a завжди, вихід -F арка = ARCH -S роз'єднати -S unlinkat -S перейменовувати -S renameat -F auid> = 500 \ -F Auid! = 4294967295 -k видалити CCE 14820-5 2.6.2.4.12 Забезпечення auditd Збирає системних дій адміністратора Як мінімум система аудиту повинен зібрати дії адміністратора для всіх користувачів і кореня. Додайте наступний код до /etc/audit/audit.rules: -w / і т.д. / sudoers -p ва -k дії 93 CCE 14824-7 2.6.2.4.13 Забезпечення auditd збирає інформацію про модуль ядра навантаження і розвантаження Додайте наступні рядки в /etc/audit/audit.rules з метою захоплення ядра завантаження модуля і розвантаження події, установка ARCH або B32 або B64 в залежності від обставин для вашої системи: -w / SBIN / insmod -п х -k модулі -w / SBIN / rmmod -п х -k модулі -w / SBIN / Modprobe -п х -k модулі -a завжди, вихід -F арка = ARCH -S init_module -S delete_module -k модулі CCE 14688-6 2.6.2.4.14 зробити конфігурацію auditd Незмінна Додайте наступне в якості останнього правила в /etc/audit/audit.rules для того, щоб зробити конфігурацію незмінні: -e 2 За допомогою цієї установки, перезавантаження буде необхідно змінити будь-які правила аудиту. CCE 14692-8 2.6.2.5 узагальнювати і аудит Огляд журналів з використанням aureport Ознайомтеся з aureport (8) сторінці людини, а потім розробити коротку серію команд аудиту звітності підходить для вивчення журналів аудиту на щоденній (або частіше) основі. Ці команди можуть бути додані в якості хрон Робота, шляхом розміщення відповідного імені файлу в /etc/cron.daily. Дивіться наступний розділ для отримання інформації про те, як переконайтеся, що система аудиту збирає всі необхідні заходи. Наприклад, щоб створити щоденний звіт кожного користувача для підключення до машини, наступна команда може бути бігти з cron'а: # Aureport -l -i -TS вчорашня -TE сьогодні Щоб переглянути всі аудиторський активності за незвичайну поведінку, гарне місце для початку, щоб побачити коротку інформацію про яких аудит правила були спрацювання: aureport --key --summary Якщо порушення прав доступу виділяються, розглянути їх з: # Ausearch --key доступу --raw | aureport --file --summary Для того, щоб розглянути те, що виконувані файли роблять: # Ausearch --key доступу --raw | aureport х --summary Якщо порушення доступу були відбуваються на конкретний файл (наприклад, / і т.д. / тінь), і ви хочете, щоб визначити, яке користувач робить це: # Ausearch --key доступу --file / і т.д. / тінь --raw | aureport --user --summary -i 94 ГЛАВА 2. загальносистемних конфігурації Перевірте наявність аномальної активності (наприклад, пристрій зміни в безладному режимі, процеси закінчуючи ненормально, Логін Межі відмов було досягнуто) за допомогою: # Aureport --anomaly Основою для аналізу аудиту за допомогою клавіш, щоб класифікувати події. Інформація про використання ausearch знайти проблема SELinux можна знайти в розділі 2.4.6. 95 3. Послуги 3.1 Вимкнути всі послуги Непотрібні час завантаження Найкращий захист від вразливою програмного забезпечення працює під управлінням програмного забезпечення менше. У цьому розділі описується, як переглянути програмне забезпечення, яке Red Hat Enterprise Linux встановлює в систему і відключити програмне забезпечення, яке не потрібно. це потім перераховує програмного забезпечення встановлені в системі RHEL5 за замовчуванням і містить вказівки про те, які з них можна безпечно відключити. 3.1.1 Визначте, які служби включені при завантаженні Виконайте наступну команду: # Chkconfig --list | Grep: на Перша колонка цього висновку є ім'я служби, яка в даний час включена при завантаженні. огляд кожного Перераховані служби, щоб визначити, чи може він бути відключені. Якщо доречно відключити деякі служби srvname, зробіть це за допомогою команди: # Chkconfig srvname викл Використовуйте керівництво нижче для отримання інформації про незнайомих послуги. 3.1.2 Керівництво за замовчуванням служб У таблиці в цьому розділі міститься перелік всіх послуг, які дозволили при завантаженні по установці RHEL5 за замовчуванням. Для кожного сервісу, один з наступних рекомендацій проводиться: ?? Enable: Служба забезпечує значний потенціал з обмеженим впливом ризику. Залиште сервіс включений. ?? Налаштування: Служба або потрібно для більшості систем, щоб функціонувати належним чином або забезпечує важливе функція безпеки. Необхідно залишити включеним в більшості середовищ. Тим не менш, він повинен бути налаштований надійно на всіх машинах, а також різні варіанти можуть бути необхідні для робочих станцій, ніж для серверів. див посилання Розділ для рекомендованої конфігурації даної послуги. ?? Відключити, якщо це можливо: Служба відкриває систему до деякому ризику, але може знадобитися в деяких середовищах. Дивіться відповідний розділ керівництва, і відключити службу, якщо це взагалі можливо. ?? тільки сервери: Служба надає деякі функції на інші машини по мережі. Якщо ця функція потрібно в цільової середовищі, служба повинна залишатися включений тільки на невеликій кількості виділеного сервери, і повинні бути відключені на всіх інших машин в мережі. Ім'я служби Дія Посилання ACPID Включити 3.3.15.2 Anacron Відключити, якщо це можливо 3.4 APMD Відключити, якщо це можливо 3.3.15.1 ATD Налаштування 3.4 auditd Налаштування 2.6.2 96 ГЛАВА 3. ПОСЛУГИ Ім'я служби Дія Посилання AutoFS Відключити, якщо це можливо 2.2.2.3 Avahi-демон Відключити, якщо це можливо 3.7 Bluetooth Відключити, якщо це можливо 3.3.14 cpuspeed Включити 3.3.15.3 crond Налаштування 3.4 чашки Відключити, якщо це можливо 3.8 Firstboot Відключити, якщо це можливо 3.3.1 гал Відключити, якщо це можливо 3.3.2 haldaemon Відключити, якщо це можливо 3.3.13.2 HIDD Відключити, якщо це можливо 3.3.14.2 HPLIP Відключити, якщо це можливо 3.8.4.1 ip6tables Налаштування 2.5.5 Iptables Налаштування 2.5.5 irqbalance Enable 3.3.3 ЦСИС Відключити, якщо це можливо 3.3.4 Kdump Відключити, якщо це можливо 3.3.5 Кудзу Відключити, якщо це можливо 3.3.6 mcstrans Відключити, якщо це можливо 2.4.3.2 (SELinux) mdmonitor Відключити, якщо це можливо 3.3.7 messagebus Відключити, якщо це можливо 3.3.13.1 микрокода CTL Відключити, якщо це можливо 3.3.8 netfs Відключити, якщо це можливо 3.13 (NFS) Включення мережі 3.3.9 nfslock Відключити, якщо це можливо 3.13 (NFS) pcscd Відключити, якщо це можливо 3.3.10 Portmap Відключити, якщо це можливо 3.13 (NFS) Readahead рано Відключити, якщо це можливо 3.3.12 Readahead пізніше відключити, якщо це можливо 3.3.12 restorecond Enable 2.4.3.3 (SELinux) rhnsd Відключити, якщо це можливо 2.1.2.2 rpcgssd Відключити, якщо це можливо 3.13 (NFS) rpcidmapd Відключити, якщо це можливо 3.13 (NFS) Sendmail Налаштування 3.11 setroubleshoot Відключити, якщо можливо, 2.4.3.1 (SELinux) smartd Включити 3.3.11 SSHd сервери тільки 3,5 Syslog Налаштування 2.6.1.1 XFS Відключити, якщо це можливо 3.6 (X11) ням-updatesd Відключити, якщо це можливо 2.1.2.3.2 3.1.3 Керівництво по незнайомій Послуги Якщо система працює будь-які послуги, які не були охоплені, визначити, що роблять ці послуги, і відключити їх, якщо вони не потрібні, або якщо вони представляють високий ризик. Якщо srvname служба невідома, спробуйте запустити: $ -qf /etc/init.d/srvname Оборотов в хвилину щоб з'ясувати, які RPM пакет установки служби. Потім виконайте наступну команду: 97 $ -qi Rpmname оборотів в хвилину для короткого опису того, що робить, що RPM. 3.1.3 Керівництво по незнайомій Послуги Якщо система працює будь-які послуги, які не були охоплені, визначити, що роблять ці послуги, і відключити їх, якщо вони не потрібні, або якщо вони представляють високий ризик. Якщо srvname служба невідома, спробуйте запустити: $ -qf /etc/init.d/srvname Оборотов в хвилину щоб з'ясувати, які RPM пакет установки служби. Потім виконайте наступну команду: 97 $ -qi Rpmname оборотів в хвилину для короткого опису того, що робить, що RPM. 3.2 Застарілі послуги У цьому розділі розглядається ряд мережевих видимих ​​послуг, які мають історично виникли проблеми для системи безпеки, і для яких відключення або серйозно обмежує службу було найкращим доступним керівництво для деяких час. В результаті цього консенсусу, ці служби не встановлюються як частина RHEL5 за замовчуванням. Організації, які запущені ці служби повинні віддавати пріоритет переходу на більш безпечні послуги, які забезпечують необхідна функціональність. Якщо це абсолютно необхідно, щоб виконати одну з цих послуг по успадкованими причин, слід бути прийняті, щоб обмежити обслуговування в максимально можливій мірі, наприклад, за допомогою програмного забезпечення конфігурації хоста брандмауера (див розділ 2.5.5), щоб обмежити доступ до вразливою службі тільки тих віддалених хостів, які мають відому потреба використовувати її. 3.2.1 Inetd і Xinetd Чи існує операційна необхідності запускати застарілі Inetd або програмні пакети Xinetd? Якщо немає, то переконаєтеся, що вони видаляються з системи: # Ням Стирання Inetd Xinetd CCE 4234-1, 4252-3, 4023-8, 4164-0 НЕ Починаючи з Red Hat Enterprise Linux 5, служба Xinetd більше не встановлюється за умовчанням. Ця зміна становить підвищену обізнаність про те, що спеціальна мережева модель слухач не покращує безпеку і надійність послуг, і це обмеження мережевих слухачів краще обробляється з використанням моделі, такі як гранульований SELinux ніж при використанні обмежених параметрів безпеки XINETD в. 3.2.2 Telnet Чи є критично важливі причини для користувачів, щоб отримати доступ до системи через незахищене протоколу Telnet, а не безпечніший протокол SSH? Якщо немає, то переконаєтеся, що сервер Telnet видаляється з системи: # Ням видалити телнет-сервер CCE 3390-2, 4330-7 Протокол Telnet використовує незашифрований мережі зв'язку, а це означає, що дані з сеансу входу в систему, включаючи паролі і будь-яку іншу інформацію, повідомлену під час сесії, можуть бути вкрадені подслушівателей в мережі, а також, що сторонні можуть легко викрасти сесію, щоб отримати доступ з перевіркою достовірності до Telnet сервер. Організації, які використовують протокол Telnet повинні активно працювати, щоб перейти на більш безпечний протокол. Дивіться розділ 3.5 для отримання інформації про службу SSH. 3.2.2.1 Видалити Telnet Клієнти Для того, щоб заборонити користувачам випадково спроби використовувати сервер Telnet, і тим самим піддаючи їх повноваження по мережі, видаліть пакет Telnet, який містить програму клієнта Telnet: 98 ГЛАВА 3. ПОСЛУГИ # Ням Стирання телнет Якщо протокол Kerberos не використовується, видаліть пакет krb5-робоча станція, яка також включає в себе клієнт Telnet: # Ням видалити krb5-станцію 3.2.3 Rlogin, RSH і Rcp R-команди Берклі є застарілі сервіси, які дозволяють читаються віддалений доступ і мають ненадійну довіру модель. 3.2.3.1 Видаліть Команди РСЗ сервера з системи Чи є критично важливі причини для користувачів, щоб отримати доступ до системи через незахищене Rlogin, RSH або RCP команди а не більш безпечного SSH і УПП? Якщо немає, то переконаєтеся, що сервер RSH видаляється з системи: # Ням видалити РШ-сервер CCE 3974-3, 4141-8, 3537-8, 4308-3 SSH був розроблений, щоб бути відповідною заміною для пана команд, які страждають від того ж викрадення і Проблеми підслуховування як Telnet. Існує навряд чи буде нагода, в якому ці команди не можуть бути замінені з SSH. 3.2.3.2 Видалити .rhosts Підтримка файлів конфігурації PAM Перевірте, що аутентифікація РАМ Rhosts не використовується ніякими РАМ послуг. Виконайте наступну команду: # Grep -l РАМ Rhosts /etc/pam.d/* Ця команда не повинна повертати ніякого висновку. RHEL5 за замовчуванням не покладатися на .rhosts або /etc/hosts.equiv для будь-яких РАМ-сервісів, так що, за принципом ненастроенной система, ця команда не повинна повертати ніякого висновку. Якщо будь-які файли, не використовувати Pam Rhosts, змінювати їх використовувати безпечніший метод аутентифікації замість. Для отримання додаткової інформації про РАМ, дивіться Розділ 2.3.3. 3.2.3.3 Видаліть RSH команди клієнта з системи Для того, щоб заборонити користувачам випадково намагаються використовувати сервера RSH і тим самим піддаючи їх Облікові дані по мережі, видаліть пакет РСЗ, який містить клієнтські програми для багатьох з г-команд описаний вище: # Ням видалити RSH Користувачі повинні бути навчені використовувати клієнт SSH, і ніколи не намагатися підключитися до сервера RSH або Telnet. Пакет krb5-робоча станція також містить клієнтські програми R-команд і повинні бути видалені, як описано в Розділ 3.2.2.1, якщо Kerberos не використовується. 99 3.2.4 NIS NIS клієнтська служба ypbind не ввімкнено за умовчанням. У тому випадку, якщо він був активований в якийсь момент, відключити його, виконавши команду: # Chkconfig ypbind викл Пакет NIS-сервер не встановлюється за умовчанням. У тому випадку, якщо вона була встановлена ​​в якийсь момент, видалити це з системи, виконавши команду: # Ням видалити ypserv CCE 3705-1, 4348-9 Мережева Інформаційна служба (NIS), також відомий як "Жовті сторінки" (YP), і його наступник NIS + був витіснена Kerberos, LDAP, а також інших сучасних централізованих послуг аутентифікації. NIS не повинно бути використовується тому, що вона страждає від проблем безпеки, властивих його конструкції, наприклад, недостатній захист важливо відомості про перевірку автентичності. 3.2.5 TFTP Server Чи існує оперативна необхідність запуску застарілого програмного забезпечення TFTP-сервера? Якщо немає, то переконаєтеся, що він віддаляється з системи: # Ням видалити Tftp-сервер CCE 4273-9, 3916-4 TFTP є полегшеною версією протоколу FTP, який традиційно використовується для налаштування мережі обладнання. Проте, TFTP забезпечує невелику безпеку і сучасні версії мережевих операційних систем, часто Підтримка конфігурації за допомогою SSH або інших більш безпечних протоколів. Сервер TFTP повинен бути запущений, тільки якщо немає безпечніший метод підтримки існуючого обладнання можна знайти. 3.2.6 Обговорення Програмне забезпечення Talk дозволяє користувачеві відправляти повідомлення на термінальній сесії іншого користувача на інший система. Пакет ток-сервер не встановлено за замовчуванням, хоча пакет клієнта розмови. обидва застаріли і можуть бути видалені. 3.2.6.1 Remove ток-сервер Пакет Щоб видалити ток-демони з системи, виконайте наступну команду: # Ням стерти ток-сервер 100 ГЛАВА 3. ПОСЛУГИ 3.2.6.2 Видалення Обговорення пакета Щоб видалити ток-демони з системи, виконайте наступну команду: # Ням Стирання розмови 3.3 Базові послуги В даному розділі розглядаються базові послуги, які налаштовані на запуск при завантаженні в установці RHEL5 за замовчуванням. Деякі з цих послуг прослуховування мережі і повинні розглядатися з особливим розсуд. інші послуги локальні системні утиліти, які можуть або не можуть бути сторонніми. Кожна з цих служб повинні бути відключені, якщо не вимагається. 3.3.1 Установка Helper Service (Firstboot) Firstboot це демон, специфічні для процесу установки Red Hat. Він обробляє "одноразовий" конфігурації наступне Успішна установка операційної системи. Таким чином, немає ніяких підстав для цього сервісу залишаються включеними. Відключити Firstboot, виконавши команду: # Chkconfig Firstboot викл CCE 3412-4 3.3.2 Консоль Service Mouse (GPM) GPM це служба, яка контролює покажчик миші текстової консолі. (Покажчик миші X Windows не впливає за допомогою цієї служби.) Якщо функціональні можливості миші в консолі не потрібно, вимкніть цю послугу: # Chkconfig від галон в хвилину CCE 4229-1 Хоча переважно, щоб працювати як кілька послуг, як це можливо, покажчик миші консолі може бути корисно для запобігання адміністратор помилки в 3-й рівень, дозволяючи операції копіювання і вставки. 3.3.3 Розподіл переривань на багатопроцесорних системах (irqbalance) Мета сервісу irqbalance полягає в оптимізації балансу між економією енергії і продуктивністю через розподіл апаратних переривань між декількома процесорами. У серверному середовищі з декількома процесорами, це забезпечує корисне обслуговування і має бути залишено включений. Якщо машина має тільки один процесор, послуга може бути відключена: # Chkconfig irqbalance викл 101 CCE 4123-6 3.3.4 ISDN Підтримка (ISDN) Служба ISDN полегшує підключення до Інтернету в присутності модему ISDN. Якщо ISDN модем не використовується, вимкніть цю послугу: # Chkconfig ЦСИС викл CCE 14825-4 3.3.4.1 Видаліть isdn4k-Utils пакет, якщо це можливо Якщо служба ЦСИС не використовуватиметься, то пакет isdn4k-Utils можуть бути видалені: # Ням видалити isdn4k-утиліти Пакет також містить УИП програму, як описано в розділі 2.2.3.4. 3.3.5 Kdump Ядро Аналізатор збоїв (Kdump) Kdump новий аналізатор ядра аварійного дампа. Він використовує Kexec для завантаження вторинного ядра ( "захоплення" ядра) наступний система аварії. Дампа ядра від збою системи завантажується в ядро ​​захоплення для аналізу. Якщо система не використовується для розробки ядра або тестування, вимкніть службу: # Chkconfig Kdump викл CCE 3425-6 3.3.6 Кудзу Устаткування Зондування Utility (Кудзу) Чи є критично важливою причиною для користувачів консолі, щоб додати нове обладнання до системи? Якщо ні: # Chkconfig Кудзу викл CCE 4211-9 Кудзу, програма виявлення апаратних засобів компанії Red Hat, являє собою невиправданий ризик безпеки, оскільки це дозволяє непривілейованих користувачам виконувати апаратну конфігурацію без авторизації. Якщо ви не бажаєте ця конкретна функціональність, Kudzu повинен бути відключений. 102 ГЛАВА 3. ПОСЛУГИ 3.3.7 Програмний RAID Monitor (mdmonitor) Послуга mdmonitor використовується для моніторингу програмного RAID (апаратна підтримка RAID розстановок не використовують цю послугу). Дана послуга є стороннє, якщо програмне забезпечення RAID не використовується (що не є загальним). Якщо програмне забезпечення моніторингу RAID не потрібно, вимкніть цю послугу: # Chkconfig mdmonitor викл CCE 3854-7 3.3.8 IA32 Microcode Utility (микрокода CTL) микрокода CTL є мікрокод утиліта для використання з процесорами Intel IA32 (Pentium Pro, PII, Celeron, PIII, Xeon, Pentium 4, і т.д.) Якщо система не працює процесор Intel IA32, відключити цю послугу: # Chkconfig микрокода CTL вимкнений CCE 4356-2 3.3.9 Сервісна мережа (мережа) Послуга мережі дозволяє пов'язані мережеві інтерфейси для доступу до мережі. Цей розділ містить загальний керівництво для управління роботою служби. Для параметрів ядра, які впливають на організацію мережі, дивіться Розділ 2.5.1. Для отримання більш докладної конфігурації IPv6, дивіться Розділ 2.5.3. CCE 4369-5 3.3.9.1 Відключити всі мережі, а то й потрібно Якщо система являє собою автономний апарат без необхідності доступу до мережі або навіть зв'язку через замикання на себе пристрій, потім відключити цю послугу: # Chkconfig мережі вимкнений 3.3.9.2 Відключення всіх зовнішніх мережевих інтерфейсів, а то й потрібно Якщо система не вимагає мережевих комунікацій, але як і раніше необхідно використовувати петлевий інтерфейс, видалити всі файли виду ifcfg-інтерфейс для ifcfg-ло з / і т.д. / sysconfig / мережі-скрипти, за винятком: # Гт / і т.д. / sysconfig / мережі-скрипти / ifcfg-інтерфейс 103 3.3.9.3 Відключити Zeroconf мережі Zeroconf мережі дозволяє системі призначити собі IP-адреса і займатися IP-зв'язку без статично призначений адресу або навіть сервер DHCP. Автоматичне привласнення адреси за допомогою Zeroconf (або DHCP) є не рекомендовано. Щоб відключити Zeroconf автоматичного присвоєння маршруту в 169.245.0.0 підмережі, додати або виправити наступний рядок в / і т.д. / sysconfig / мережі: NOZEROCONF = так CCE 14054-1 Zeroconf адреси в мережі 169.254.0.0. Сценарії мереж додавати записи в маршрутизації системи таблиця для цих адрес. Zeroconf призначення адрес зазвичай відбувається, коли система налаштована для використання DHCP, але не отримує завдання адреси від сервера DHCP. 3.3.10 Підтримка смарт-карт (pcscd) Служба pcscd забезпечує підтримку для смарт-карт і смарт-карт читачів. Якщо смарт-карти не використовуються в системі, відключити цю послугу: # Chkconfig pcscd викл CCE 4100-4 3.3.11 Підтримка моніторингу SMART Disk (smartd) SMART (Self-Monitoring, Analysis і Reporting Technology) є особливістю жорстких дисків, що дозволяє їм щоб виявити ознаки збою диска і реле відповідне попередження. Ця технологія вважається принести відносно низький ризик для безпеки, і може бути корисним. Залиште цю послугу працює, якщо жорсткі диски системи є SMART-здатні. В іншому випадку, вивести його з ладу: # Chkconfig smartd викл CCE 3455-3 3.3.12 завантаження Caching (Readahead рано / Readahead пізніше) Наступні служби забезпечують кешування одноразову файлів, що належать до деяких завантаження послуг, з метою дозволяючи система завантажуватися швидше. Рекомендується, щоб ця послуга буде відключена на більшості машин: # Chkconfig Readahead рано покинути # Chkconfig Readahead пізніше з CCE 4421-4, 4302-6 104 ГЛАВА 3. ПОСЛУГИ Ці Readahead послуги істотно не збільшують схильність до ризику здатність системи, але вони також не забезпечують відмінний вигода. Якщо система не працює спеціалізований додаток, для якого кешування файлів істотно покращує Система час завантаження, це керівництво рекомендує відключити послуги. 3.3.13 Послуги з підтримки додатків Наступні послуги являють собою програмні проекти freedesktop.org, які призначені для забезпечення системної інтеграції через ряд загальних інтерфейсів API для додатків. Вони в значній мірі інтегровані в навколишнє середовище X Windows. Якщо система не використовує X Windows, ці служби зазвичай можуть бути відключені. Сервіс 3.3.13.1 D-Bus IPC (messagebus) D-Bus є механізм IPC, який забезпечує загальний канал для зв'язку між процесами. Якщо ніякі послуги, які вимагають D-Bus не використовуються, вимкніть цю послугу: # Chkconfig messagebus викл CCE 3822-4 Ряд послуг за замовчуванням використовують D-Bus, включаючи X Windows (розділ 3.6), Bluetooth (розділ 3.3.14) і Avahi (розділ 3.7). Даний посібник рекомендує D-Bus і все його залежності будуть відключені, якщо не буде критично важливою потреба в них. Жорсткість конфігурація D-Bus можна і задокументовані в довідковій сторінці Dbus-демона (1). D-Bus підтримує два окремих конфігураційних файлів, розташованих в / і т.д. / DBus-1 /, один для системної конфігурації конкретної, а інший для сеансу конкретної конфігурації. 3.3.13.2 HAL Daemon (haldaemon) Служба haldaemon забезпечує динамічний спосіб управління інтерфейсів пристроїв. Він автоматизує свій пристрій і надає API для створення пристроїв доступними для додатків через інтерфейс D-Bus. CCE 4364-6 3.3.13.2.1 Відключити HAL Daemon якщо це можливо HAL надає цінні поверхні атаки для зловмисників в якості посередника для привілейованих операцій і повинні же не бути відключені, якщо необхідно: # Chkconfig haldaemon викл 3.3.13.2.2 Налаштування HAL Daemon, якщо необхідно HAL надає обмежену користувачеві можливість встановлювати системні пристрої. Це в першу чергу використовується X утиліти, такі як гном-об'ємно-менеджер для виконання автомонтірованіе знімних носіїв. Конфігурація HAL в даний час можливо тільки через серію FDI файлів, розташованих в / USR / частки / HAL / FDI / 105 Примітка: HAL майбутня дорожня карта включає в себе обов'язкову основу для управління правами адміністратора під назвою PolicyKit. Для того, щоб заборонити користувачам доступ до пристроїв через HAL, створити файл /etc/hal/fdi/policy/99-policy-all-drives.fdi з вмістом: <Пристрій> <Ключ матч = "info.capabilities" містить = "обсяг"> <Злиття тип ключа = "volume.ignore" = "BOOL"> True Наведений вище код відповідає будь-якого пристрою мічений з можливістю об'ємного (будь-який пристрій з можливістю установки волі маркується таким чином) і встановлює відповідний ключ volume.ignore до істинного, вказуючи, що обсяг повинен ігноруватися. Це і робить обсяг невидимим для користувача інтерфейсу, і заперечує спроби змонтувати непривілейованих користувачів. 3.3.14 Підтримка Bluetooth Bluetooth забезпечує спосіб передачі інформації між такими пристроями, як мобільні телефони, ноутбуки, персональні комп'ютери, принтери, цифрові камери та ігрові консолі по бездротовій лінії зв'язку малої дальності. Будь-які бездротові комунікаційні подарунки серйозний ризик для безпеки чутливих або класифікованих систем. Розділ 2.5.2 містить інформацію про відповідній темі бездротових мереж. Видалення апаратного забезпечення є єдиним способом, щоб гарантувати, що можливості бездротового доступу Bluetooth залишається недоступною. Якщо це повністю непрактично, щоб видалити апаратний модуль Bluetooth, а також політику сайту як і раніше дозволяє пристрою увійти чутливі місця, робиться все можливе, щоб не дозволити за допомогою програмного забезпечення повинні бути зроблені. В цілому, політика придбання повинні включати положення щодо запобігання придбанню обладнання, яке буде використовуватися в чутливих просторах і включає в себе Bluetooth можливості. 3.3.14.1 Bluetooth інтерфейс хост-контролера Daemon (Bluetooth) Служба Bluetooth дозволяє системі використовувати пристрої Bluetooth. Якщо система не вимагає Bluetooth пристроїв, відключити цю послугу: # Chkconfig Bluetooth система вимикання CCE 4355-4 3.3.14.2 Пристрої Bluetooth введення (HIDD) Служба HIDD забезпечує підтримку пристроїв введення Bluetooth. 106 ГЛАВА 3. ПОСЛУГИ Якщо система не має Bluetooth-пристрої введення (наприклад, бездротової клавіатури або миші), відключити цю службу: # Chkconfig HIDD викл CCE 4377-8 3.3.14.3 модулі Bluetooth Відключення ядра Модульна система завантаження ядра може бути налаштований, щоб запобігти завантаження модуля Bluetooth. Додайте наступні рядки в /etc/modprobe.conf, щоб запобігти завантаження модуля Bluetooth: Ім'я користувача нетто-пф-31 вимкнений Ім'я користувача Bluetooth система вимикання CCE 14948-4 Несподіване назву, нетто-пф-31, є результатом того, як ядро ​​запитує модулі для родин мережевих протоколів; це просто псевдонім для модуля Bluetooth. 3.3.15 Підтримка управління живленням Наступні послуги надають інтерфейс для функцій управління живленням. Ці функції включають в себе моніторинг заряд батареї, система Hibernate / призупинити, дроселювання процесора, а також різні економії енергії комунальні послуги. 3.3.15.1 Додаткові можливості керування підсистемою живлення (APMD) APMD служба забезпечує підтримку управління живленням останнього покоління. Якщо система здатна підтримку ACPI, або якщо система розподілу ресурсів немає необхідності, відключити цю послугу: # Chkconfig APMD викл CCE 4289-5 APM замінюється ACPI і повинні розглядатися як застарілим. Як така, вона може бути відключена, якщо ACPI підтримується вашим обладнанням і ядром. Якщо файл / Proc / ACPI / Інформація існує і містить інформацію про версії ACPI, то APM може бути безпечно відключений без втрати функціональності. 3.3.15.2 Розширений інтерфейс конфігурації та харчування (ACPID) ACPID служба забезпечує підтримку управління живленням наступного покоління. Якщо функції управління живленням не потрібні, залиште цю послугу включена. CCE 4298-6 107 3.3.15.3 CPU Throttling (cpuspeed) Служба cpuspeed використовує апаратну підтримку задушити CPU, коли система знаходиться в режимі очікування. Якщо оптимізація потужності процесора не є необхідним, залиште цю послугу включена. CCE 4051-9 3.3.16 ІК-зв'язку (IRDA) Послуга забезпечує бездротову ІЧ-порт зв'язку малого радіусу дії для систем з ІК-апаратною підтримкою. потреба в ІК-зв'язку є рідкістю, і в даний час витісняється Bluetooth для багатьох додатків. Як і в випадку будь-який модуль бездротового зв'язку, він представляє зловмисникові з можливістю спілкування з системою і повинна бути відключені, якщо не потрібно. 3.3.16.1 Відключення IRDA службу, якщо це можливо Відключити службу IRDA, якщо не нагальна потреба в ньому: # Chkconfig від ІК-порту 3.3.16.2 Видаліть IRDA-Utils пакет, якщо це можливо Якщо послуга не буде ІК-порт буде використовуватися, то пакет-ІК-порт Utils можуть бути видалені: # Ням видалити IRDA-утиліти 3.3.17 Сировина Devices (rawdevices) Служба rawdevices привласнює вихідні пристрої в блокові і зазвичай використовується в системах баз даних. як Таким чином, він не повинен бути активований в системах, таких як робочі столи. 3.3.17.1 Відключення сирих пристроїв Daemon, якщо це можливо Відключити службу rawdevices якщо не нагальна потреба в ньому: # Chkconfig rawdevices викл 3.4 Cron і демонів Хрон і на послуги використовуються для забезпечення команд, які будуть виконуватися в більш пізній час. Служба Cron потрібно майже всіх систем для виконання необхідних завдань технічного обслуговування, в той час як може або не може вимагатися на даний система. Обидва демона повинні бути налаштовані захищаючись. 108 ГЛАВА 3. ПОСЛУГИ CCE 4324-0 3.4.1 Відключити Anacron якщо це можливо Чи є це машина, яка призначена для роботи весь час, такі як сервер або робочу станцію, яка залишається на в ніч? Якщо так: # Ням Стирання Anacron CCE 4406-5, 4428-9 Підсистема Anacron призначена для забезпечення функціональності хрон для машин, які можуть бути закриті під час нормальні часи, що система хрон робочих місць запуску, часто в середині ночі. Ноутбуки та робочі станції які закриті в нічний час повинен тримати Anacron включений, так що стандартна система хрон робочих місць буде виконуватися, коли машина завантажується. Проте, на машинах, які не потребують цієї додаткової функціональності, Anacron є ще один шматок привілейоване програмне забезпечення, яке може містити уразливості. Таким чином, вона повинна бути видалена, коли це можливо, щоб зменшити Система ризик. 3.4.2 Обмеження дозволів на файли, що використовуються в хрон 1. Обмежити права доступу до файлу первинної системи кронтаб: # Чаун корінь: корінь / і т.д. / кронтаб # CHMOD 600 / і т.д. / кронтаб 2. Якщо Anacron ні видалений, обмежити права на його основний конфігураційний файл: # Чаун корінь: корінь / і т.д. / anacrontab # CHMOD 600 / і т.д. / anacrontab 3. Обмеження доступу по всій системі кронтаб каталогів: # Кд / і т.д. # Чаун -R корінь: корінь cron.hourly cron.daily cron.weekly cron.monthly cron.d # CHMOD -R гоу-RWX cron.hourly cron.daily cron.weekly cron.monthly cron.d 4. Обмежити права доступу до каталогу золотника для користувача кронтаб файлів: # Чаун корінь: корінь / вар / золотник / хрон # CHMOD -R гоу-RWX / вар / золотник / хрон CCE 4322-4, 4450-3, 4331-5, 3851-3, 4379-4, 4388-5, 4054-3, 4441-2, 4212-7, 4380-2, 3833-1, 3604-6, 4106 -1, 3983-4, 3626-9, 4022-0, 4304-2, 4203-6, 4251-5, 3481-9, 4250-7 Крон і Anacron використовувати ряд конфігураційних файлів і каталогів. Система crontabs повинна бути тільки під редакцією кореня, і crontabs користувачем редагуються за допомогою команди Setuid кореневої кронтаб. Якщо непривілейованих користувачі можуть змінювати файли конфігурації системи хрон, вони можуть бути в змозі отримати підвищені привілеї, так що все непотрібне доступ до ці файли повинні бути відключені. 109 3.4.3 Відключити в якщо це можливо Якщо тільки у демона не потрібно, вимкніть його за допомогою наступної команди: # Chkconfig ATD викл CCE 14466-7 Багато з періодичних або запізнілих функцій виконання на демона може бути забезпечена через демон cron замість цього. 3.4.4 Обмеження в і хрон для авторизованих користувачів 1. Видаліть файл cron.deny: # Гт /etc/cron.deny 2. Редагування /etc/cron.allow, додавши один рядок для кожного користувача, якому дозволено використовувати команду кронтаб для створення хрон робочих місць. 3. Видаліть файл at.deny: # Гт файл /etc/at.deny 4. Редагування /etc/at.allow, додавши один рядок для кожного користувача, якому дозволено використовувати в команді для створення на робочих місцях. У /etc/cron.allow і /etc/at.allow файли містять списки користувачів, яким дозволено використовувати хрон і на те, щоб затримати виконання процесів. Якщо ці файли існують, і якщо відповідні файли /etc/cron.deny і зробити файл /etc/at.deny не існує, то тільки користувачі, перераховані у відповідних дозволяють файли можуть запускати кронтаб і на команди для відправки завдань для запуску через задані інтервали часу. У багатьох системах, тільки системний адміністратор повинен мати можливість планувати виконання завдань. Зверніть увагу, що навіть якщо даний Користувач не вказано в cron.allow, хрон робочих місць як і раніше може бути запущений від імені цього користувача. тільки контролює cron.allow файлів адміністративний доступ до кронтаб команди для планування і зміни хрон робочих місць. 3.5 SSH сервер Протокол SSH рекомендується для віддаленого входу в систему і віддаленого передачі файлів. SSH забезпечує конфіденційність і цілісності для даних, якими обмінюються між двома системами, а також перевірки достовірності сервера, шляхом використання відкритого ключа криптографія. Реалізація в комплекті з системою називається OpenSSH, і більш детальна документація доступний від свого веб-сайту, http://www.openssh.org. Його серверна програма називається SSHd і за умови число оборотів в хвилину пакет OpenSSH-сервер. 3.5.1 Відключення сервера OpenSSH якщо це можливо Якщо система не повинна надавати віддалений вхід в систему і передачі файлів можливості SSH, відключити і видалити сервер OpenSSH і його конфігурація. 110 ГЛАВА 3. ПОСЛУГИ 3.5.1.1 Відключення і видалення програмного забезпечення OpenSSH Відключити і видалити OpenSSH-сервер за допомогою команд: # Chkconfig SSHd викл # Ням видалити OpenSSH-сервер CCE 4268-9, 4272-1 Користувачі системи як і раніше буде мати можливість використовувати SSH клієнт програми / USR / bin / SSH, щоб отримати доступ до SSH-сервери на іншому системи. 3.5.1.2 Видалення сервера SSH Iptables винятків брандмауера Редагування файлів / і т.д. / sysconfig / IPTables і / і т.д. / sysconfig / ip6tables (якщо IPv6 використовується). В кожному файлі, знайдіть і видаліть рядок: -A RH-Firewall-1-INPUT -m стан --state NEW -m -p TCP протокол TCP --dport 22 -j ACCEPT CCE 4295-2 За замовчуванням, вхідні підключення до порту SSH в дозволено. Якщо сервер SSH не використовується, це виняток повинні бути видалені з конфігурації брандмауера. Дивіться розділ 2.5.5 для отримання додаткової інформації про Iptables. 3.5.2 Налаштування сервера OpenSSH, якщо необхідно Якщо система повинна виступати в якості сервера SSH, то деякі зміни повинні бути зроблені, щоб демон OpenSSH конфігураційний файл / і т.д. / SSH / SSHD конфігурації. Наступні рекомендації можуть бути застосовані до цього файлу. див SSHD конфігурації (5) людина сторінки для отримання більш докладної інформації. 3.5.2.1 Забезпечення тільки Протокол 2 З'єднання дозволені Тільки SSH протоколу версії 2 з'єднання повинні бути дозволені. Версія 1 протоколу містить безпеку уразливості. Значення за замовчуванням поставляється в файлі конфігурації є правильним, але це досить важливо перевірте. Переконайтеся в тому, що з'являється наступний рядок: протокол 2 CCE 4325-7 SSH Access 3.5.2.2 обмежити доступ користувачів " За замовчуванням, конфігурація SSH дозволяє будь-якому користувачеві отримати доступ до системи. Для того, щоб дозволити всім користувачам увійти в систему за допомогою SSH, але заборонити тільки кілька користувачів, додати або виправити такий рядок: DenyUsers USER1 ПОЛЬЗОВАТЕЛЬ2 111 В якості альтернативи, якщо це доречно, щоб дозволити лише деякі користувачі отримують доступ до системи через SSH, додати або виправити наступний рядок: AllowUsers USER1 ПОЛЬЗОВАТЕЛЬ2 3.5.2.3 Як встановити періодичність простою Тайм-аут для логіни SSH дозволяє адміністраторам встановити інтервал очікування тайм-ауту. Після того, як цей інтервал пройшло, холостий користувач буде автоматичний вихід. Знайдіть і відредагуйте такі рядки в / і т.д. / SSH / SSHD конфігурації наступним чином: інтервал ClientAliveInterval ClientAliveCountMax 0 Інтервал часу очікування задається в секундах. Щоб мати тайм-аут 5 хвилин, встановити інтервал до 300. CCE 14061-6 Якщо більш короткий тайм-аут вже встановлений для входу в оболонку, як описано в розділі 2.3.5.5, це значення буде вивантажити будь-який Установка SSH зробив тут. Майте на увазі, що деякі процеси можуть зупинити SSH від правильного визначення того, що користувач знаходиться в режимі очікування. 3.5.2.4 Відключення файлів .rhosts SSH може емулювати поведінка команди застарілих РСЗ в дозволяючи користувачам включити небезпечний доступ до їх рахунки за допомогою файлів .rhosts. Для того, щоб переконатися, що така поведінка відключено, додати або виправити такий рядок: IgnoreRhosts та CCE 4475-0 3.5.2.5 Відключити Host-аутентифікації на основі криптографічний аутентифікація на основі хоста SSH є трохи більш безпечна, ніж аутентифікація .rhosts, так як хости криптографически перевірку справжності. Проте, це не рекомендується, щоб в односторонньому порядку приймає довіру один до одного, навіть в рамках організації. Щоб відключити перевірку автентичності на основі хоста, додати або виправити такий рядок: HostbasedAuthentication немає CCE 4370-3 3.5.2.6 Відключити корінь Увійти за допомогою SSH Привілейований користувач ніколи не повинно бути дозволено увійти в систему безпосередньо через мережу, так як це знижує і перевіряється інформацію про те, хто втік привілейовані команди на системі і дозволяє прямі спроби атаки на пароль суперкористувача. 112 ГЛАВА 3. ПОСЛУГИ Щоб відключити кореневої вхід за допомогою SSH, додати або виправити такий рядок: PermitRootLogin немає CCE 4387-7 3.5.2.7 Відключити порожні паролі Щоб явно заборонити віддалений вхід з рахунків з порожніми паролями, додати або виправити такий рядок: PermitEmptyPasswords немає CCE 3660-8 Заходи також повинні бути прийняті, щоб відключати облікові записи з порожніми загальносистемних паролів, як описано в розділі 2.3.1.5.1. 3.5.2.8 Включити попередження Банер Розділ 2.3.7 містить інформацію про те, як створити відповідне попередження банер. Щоб включити застережливий банер, додати або виправити такий рядок: Банер / і т.д. / питання CCE 4431-3 3.5.2.9 Не дозволяти користувачам для завдання параметрів середовища Щоб заборонити користувачам можливість представити варіанти середовища до SSH-демона і потенційно шунтування деякі обмеження доступу, додати або виправити такий рядок: PermitUserEnvironment немає CCE 14716-5 3.5.2.10 використовувати тільки дозволені шифри в режимі лічильника Обмежити шифри ті, які є FIPS-затверджені і використовувати тільки шифри в режимі лічильника (CTR). наступний рядок демонструє використання FIPS затверджених шифрів в режимі CTR: Шифри AES128-РСУ, aes192-РСУ, AES256-СУУ CCE 14491-5 Людина сторінка SSHD конфігурації (5) містить список підтримуваних шифрів для поточної версії SSH демона. 113 3.5.2.11 Зміцнення конфігурації брандмауера, якщо це можливо Якщо сервер SSH повинен приймати з'єднання лише з локальної мережі, а потім посилити правила брандмауера для служби SSH. Визначте відповідний мережевий блок, netwk і мережеву маску, маску, що представляє машини на ваша мережа, яка повинна бути надана можливість відкрити SSH сервер. Редагування файлів / і т.д. / sysconfig / IPTables і / і т.д. / sysconfig / ip6tables (якщо IPv6 використовується). В кожному файлі, знайдіть рядок: -A RH-Firewall-1-INPUT -m стан --state NEW -m -p TCP протокол TCP --dport 22 -j ACCEPT і замінити його: -A RH-Firewall-1-INPUT -s netwk / маска -m стан --state NEW -p TCP --dport 22 -j ACCEPT Якщо ваш сайт використовує IPv6, і редагуванні ip6tables, використовуйте наступний рядок: -A RH-Firewall-1-INPUT -s ipv6netwk :: / ipv6mask -m TCP -p TCP --dport 22 -j ACCEPT а не тому, що Netfilter ще не надійно підтримує фільтрацію зі збереженням стану для IPv6. Дивіться розділ 2.5.5 для отримання додаткової інформації про конфігурацію IPtables. 3.6 Система X Window Впровадження системи X Window в комплекті з системою називається X.org. 3.6.1 Відключити X Windows якщо це можливо Якщо не буде критично важливою причиною для машини, щоб запустити екран графічного входу в систему, запобігти X від початку автоматично при завантаженні системи. Там немає, як правило, ніяких підстав для запуску X Windows на виділеній машині сервера, так як адміністратори можуть увійти в систему за допомогою SSH або на текстовій консолі. 3.6.1.1 Відключити X Windows при завантаженні системи Відредагуйте файл / і т.д. / inittab і виправте ідентифікатор рядки: 5: initdefault: до: ID: 3: initdefault: CCE 4462-8 Ця дія змінює рівень виконання завантаження за замовчуванням системи від 5 до 3. Ці дві рівні запуску повинні бути однаковими крім того, що рівень виконання 5 пусків X при завантаженні, в той час як 3-й рівень не. 3.6.1.2 Видалити X Windows з системи, якщо це можливо Видаліть RPMs X11 з системи: 114 ГЛАВА 3. ПОСЛУГИ # Ням groupremove "Система X Window" CCE 4422-2 До тих пір поки залишається X.org встановлений в системі, користувачі можуть як і раніше працювати в X Windows, набравши StartX в оболонці швидке. Це може запустити X Windows за допомогою параметрів конфігурації, які є менш безпечними, ніж системи за умовчанням. Тому, якщо машина виділений сервер, який не вимагає, щоб забезпечити підключення в графічному режимі на всіх, це найбезпечніший для видалення програмного забезпечення X.org повністю. Команда дається тут буде видалити більше 100 пакетів. Вона повинна ефективно і безпечно видалити X з машин які не потрібно. 3.6.1.3 Lock Down X Windows StartX конфігурації, якщо необхідно Якщо X НЕ буде запускатися під час завантаження, але програмне забезпечення повинно залишатися встановлено, користувачі матимуть можливість запускати X вручну використовуючи StartX команду. У деяких випадках, це працює X з конфігурацією, яка є менш безпечним, ніж за замовчуванням. Дотримуйтесь цих інструкцій, щоб зменшити ризик від цієї конфігурації. 3.6.1.3.1 Відключити X сервер шрифтів 3.6.1.3.1 Відключити X сервер шрифтів Відключення XFS помічника служби: # Chkconfig XFS викл CCE 4448-7 X.org системи вимагає служби сервера X Font (XFS) для функції. Служба XFS буде запускатися автоматично якщо X.org активується через StartX. Таким чином, це безпечно, щоб запобігти XFS від запуску при завантаженні, коли Х інвалідів, навіть якщо користувачі можуть запускати X вручну. 3.6.1.3.2 Відключення системи X Window Listening Для запобігання X.org від прослуховування для віддалених з'єднань, створіть файл / і т.д. / X11 / Xinit / xserverrc і заповнити вона з такою рядком: X Exec: 0 -nolisten TCP $ @ CCE 4074-1 Однією з особливостей X.Org є здатність забезпечити віддалений графічний дисплей. Ця функція повинна бути відключена, якщо потрібно. Якщо система використовує 5-му рівні, який є за замовчуванням, менеджер дисплея GDM починає X безпечно, з дистанційне прослуховування відключено. Однак, якщо X запускається з командного рядка з StartX командою, то сервер буде слухати для нових підключень за замовчуванням порт Х, 6000. Дивіться Xinit (1), StartX (1), і XServer (1) сторінки керівництва для отримання додаткової інформації. 3.6.2 Налаштування X Windows, якщо необхідно Якщо є критично важливою причиною для цієї машини, щоб запустити графічний інтерфейс, підвищити безпеку конфігурації за замовчуванням X слідуючи інструкціям, наведеним в даному розділі. 115 3.6.2.1 Створення попереджувальних банерів для графічного входу користувачів Редагування файлу /etc/gdm/custom.conf. Знайдіть розділ [Greeter], і виправити цей розділ, щоб утримувати лінії: [Воротарем] InfoMsgFile = / і т.д. / питання CCE 3717-6 Дивіться Розділ 2.3.7 для пояснення використання банера файлу. Цей параметр змусить систему вітання банер буде відображається у вікні попереднього для графічного входу в систему. Якщо за умовчанням банер Шрифт недоречно, воно може бути змінено шляхом зазначення директива InfoMsgFont, а також, наприклад: InfoMsgFont = Sans 12 3.7 Avahi сервера Демон Avahi реалізує DNS протоколи DNS Service Discovery і многоадресной передачі, які надають послуги і виявлення хоста в мережі. Це дозволяє системі автоматично визначати ресурси в мережі, наприклад як принтери або веб-серверів. Ця можливість також відомий як mDNSresponder і є основною частиною Zeroconf мереж. За замовчуванням вона включена. 3.7.1 Відключити Avahi сервер якщо це можливо Оскільки служба демон Avahi тримає відкритий мережевий порт, він схильний до мережевих атак. відключення це Особливо важливо, щоб зменшити вразливість системи до таких атак. 3.7.1.1 Відключення програмного забезпечення сервера Avahi Виконайте команду: # Chkconfig Avahi-демон вимкнений CCE 4365-3 3.7.1.2 Видалити Avahi сервера IPtables винятків брандмауера Редагування файлів / і т.д. / sysconfig / IPTables і / і т.д. / sysconfig / ip6tables (якщо IPv6 використовується). В кожному файлі, знайдіть і видаліть рядок: -A RH-Firewall-1-INPUT -p UdP --dport 5353 -d 224.0.0.251 -j ACCEPT За замовчуванням, вхідні підключення до порту Avahi в дозволено. Якщо сервер Avahi не використовується, це виняток повинні бути видалені з конфігурації брандмауера. Дивіться розділ 2.5.5 для отримання додаткової інформації про Iptables міжмережевий екран. 116 ГЛАВА 3. ПОСЛУГИ 3.7.2 Налаштування Avahi, якщо необхідно Якщо ваша система вимагає демона Avahi, його конфігурація може бути обмежена для підвищення рівня безпеки. Avahi демон конфігураційний файл /etc/avahi/avahi-daemon.conf. Наступні рекомендації з безпеки повинні застосовується до цього файлу. Дивіться Avahi-daemon.conf (5) людина сторінки або документацію на http://www.avahi.org Для отримання більш докладної інформації про параметри конфігурації. 3.7.2.1 Подавати тільки через необхідний протокол Значення за замовчуванням в файлі конфігурації дозволяє Avahi використовувати обидва IPv4 і IPv6 сокети. Якщо ви використовуєте тільки IPv4, редагувати /etc/avahi/avahi-daemon.conf і переконайтеся, що наступний рядок існує в [Сервер] розділ: Використання-ipv6 = немає Точно так же, якщо ви використовуєте тільки IPv6, відключити IPv4 сокета з лінії: Використання-ipv4 = немає CCE 4136-8, 4409-9 TTL поле 3.7.2.2 Перевірте відповіді " Avahi може бути встановлений, щоб ігнорувати IP-пакети, якщо їх TTL поле не дорівнює 255. Для того, щоб Avahi ігнорувати пакети, якщо поле TTL НЕ 255, редагувати /etc/avahi/avahi-daemon.conf і забезпечити наступний рядок з'являється в розділі [Сервер]: чек-відповідь-TTL = так CCE 4426-3 Це допомагає гарантувати, що тільки відповіді MDNS з локальної мережі обробляються, так як поле TTL в А пакет зменшується від його початкового значення 255 всякий раз, коли вони прямують з однієї мережі в іншу. хоча правильно конфігурований маршрутизатор або брандмауер не повинен дозволяти MDNS пакетів в локальній мережі на всіх, цей варіант надає ще один чек, щоб гарантувати, що вони не довіряють. 3.7.2.3 Запобігання інших програм за допомогою порту Avahi в Avahi може зупинити інший MDNS стеки запуск на хості шляхом запобігання інших процесів від прив'язки до порту 5353. Для того, щоб запобігти інші MDNS стеки від бігу, редагування /etc/avahi/avahi-daemon.conf і забезпечити наступне лінія з'являється в розділі [Сервер]: заборонити-інші-стеки = так CCE 4193-9 Це зроблено для того, щоб гарантувати, що тільки Avahi відповідає за MDNS трафіку виходячи з цього порту на система. 117 3.7.2.4 Відключити Видавництво якщо це можливо Значення за замовчуванням в файлі конфігурації дозволяє Avahi-демон для передачі інформації про локальний хост, таких, як його записів адрес і послуг, які вона пропонує, до локальної мережі. Щоб зупинити відправку цієї інформації, але як і раніше дозволяють Avahi попросити мережу для послуг, забезпечити конфігурацію Файл включає в себе наступний рядок в розділі [url]: відключити видавничих = так CCE 4444-6 Ця лінія може бути особливо корисним, якщо Avahi необхідний для виявлення принтера, але не для реклами послуг. це Конфігурація настійно рекомендується для клієнтських систем, які не повинні рекламувати свої послуги (або існування). 3.7.2.5 Обмеження опублікованої інформації Якщо необхідно опублікувати інформацію в мережі, він не повинен бути з'єднані ні сторонньої інформації, або за інформацією, наданою НЕ довіреною джерелом в системі. Заборона призначених для користувача додатків з використанням Avahi для публікації служб шляхом додавання або виправлення наступний рядок в розділ [публікувати]: відключити користувачів-сервіс-видавництво = так Реалізувати як багато хто з наступних рядків, як це можливо, щоб обмежити інформацію, опубліковану Avahi: публікують-адреси = немає публікація-HINFO = немає публікація-робоча станція = немає публікація-домен = немає Перевірте файли в каталозі / і т.д. / Avahi / послуги /. Якщо не існує оперативна необхідність публікації інформація про кожну з цих служб, видаліть відповідний файл. CCE 4352-1, 4433-9, 4451-1, 4341-4, 4358-8 Ці параметри повинні бути використані, навіть якщо публікація відключена повністю за допомогою Disable-видавничої справи, так як цей варіант запобігає спробам публікації від успіху, в той час як ці варіанти запобігти спробам від бути зроблені в першість. Використовуючи обидва підходи, рекомендується для повноти картини. 3.8 Підтримка друку (CUPS) служби Common Unix Printing System забезпечує як локальний, так і мережевий підтримки друку. Система запущена служба CUPS може приймати завдання друку з інших систем, обробляти їх, і відправити їх в відповідний принтер. Він також надає інтерфейс для віддаленого адміністрування через веб-браузер. встановлена ​​і активована за замовчуванням CUPS служби. На головній сторінці проекту і більш докладна документація доступні на http://www.cups.org. HP Linux і цифрової обробки зображень Служба друку (HPLIP) являє собою окремий пакет, який забезпечує підтримку для деяких з додаткові функції, які HP принтери забезпечують, що CUPS не обов'язково підтримувати. Він покладається на CUPS обслуговування. 118 ГЛАВА 3. ПОСЛУГИ 3.8.1 Відключення служби CUPS, якщо це можливо Чи потрібна вам можливість друкувати з цієї машини або дозволяти іншим друкувати на ньому? Якщо ні: # Chkconfig чашки геть CCE 4112-9, 3755-6 3.8.2 Відключити брандмауер Доступ до друку служби, якщо це можливо Чи потрібна ця система працювати як мережевий сервер друку? Якщо немає, то редагувати файли / і т.д. / sysconfig / Iptables і / і т.д. / sysconfig / ip6tables (якщо IPv6 використовується). В кожному файлі, знайдіть і видаліть рядки: -A RH-Firewall-1-INPUT -p -m УДП УДП --dport 631 -j ACCEPT -A RH-Firewall-1-INPUT -p TCP -m TCP --dport 631 -j ACCEPT CCE 3649-1 За замовчуванням вхідні підключення до порту друку Інтернет-протоколу допускається. Якщо сервер пресі не повинні бути доступні, або тому, що машина не запущена служба друку на всіх або через машини не забезпечує мережевий принтер для інших машин віддаленого, це виняток має бути видалено з брандмауера конфігурації. Дивіться розділ 2.5.5 для отримання додаткової інформації про брандмауер IPtables. 3.8.3 Налаштування CUPS послуг, якщо необхідно CUPS дає можливість легко обмінюватися локальні принтери з іншими комп'ютерами по мережі. Він робить це, що дозволяє машинам обмінюватися списками доступних принтерів. Крім того, кожна машина, яка запускає службу CUPS може потенційно виступати в якості сервера друку. По можливості, загальний доступ до принтерів і сервер друку можливості CUPS має бути обмежена або відключена. Наступні рекомендації повинні продемонструвати, як зробити саме це. 3.8.3.1 Обмеження перегляду для друку За замовчуванням, CUPS прослуховує мережу для списку принтерів передач на UDP-порт 631. Ця функція називається Принтер перегляду. 3.8.3.1.1 Відключити перегляд принтера Цілком якщо це можливо Щоб відключити перегляд принтера цілком, відредагувати файл конфігурації CUPS, розташований за адресою /etc/cups/cupsd.conf: Перегляд Off НЕ BrowseAllow ні CCE 4420-6, 4407-3 Служба друку CUPS може бути виконаний з можливістю транслювати список доступних принтерів в мережі. інші машини в мережі, а також запущена служба друку CUPS, може бути налаштований для прослуховування цих передач і додати і налаштувати ці принтери для негайного використання. Чи не вимкнено цю можливість перегляду, машина більше не буде генерувати або отримувати такі передачі. 119 3.8.3.1.2 Обмеження перегляду принтера до певної підмережі, якщо це необхідно Можна відключити список вихідних принтер мовлення, не зачіпаючи входять передач від інших машини. Для цього відкрийте файл конфігурації CUPS, розташованого за адресою /etc/cups/cupsd.conf. Подивіться на лінії який починається з BrowseAddress і видалити його. Лінія буде виглядати наступним чином: BrowseAddress @LOCAL Якщо намір полягає в тому, щоб не блокувати загальний доступ до принтера, але обмежити його певним набором машин, ви можете обмежити трансляцій принтера UDP для довірених мережевих адрес. BrowseAddress IP-адреса: 631 Точно так же, щоб ігнорувати список входять принтер широкомовні UDP або обмежити набір машин для прослуховування, використовуйте BrowseAllow і BrowseDeny директиви. BrowseDeny все BrowseAllow IP-адреса Ця комбінація буде заперечувати входять передачі з будь-якої машини, крім тих, які явно дозволені з BrowseAllow. За замовчуванням, коли загальний доступ до принтера включений, CUPS буде транслювати в кожну мережу, що її машина є з'єднаний з допомогою всіх доступних мережевих інтерфейсів на порт 631. Він також буде прослуховувати вхідні передачі з інші машини в мережі. Або список один BrowseAddress лінія для кожної клієнтської машини і один BrowseAllow рядок для кожного сервера друку або використовувати один з підтримуваних скорочених позначень, що служба CUPS визнає. Будь ласка, зверніться до cupsd.conf (5) людина сторінки або в документації, що поставляється в http://www.cups.org більш інформація про інші способи форматування цих директив. 3.8.3.2 Відключення можливості сервера друку якщо це можливо Відключення можливості сервера друку таким чином, будуть також відключити веб-адміністрування інтерфейс. Для запобігання віддалених користувачів від потенційно підключення і з використанням локально налаштованих принтерів, відключити Друку CUPS можливості спільного використання сервера. Для цього, обмежити, як сервер буде слухати завдання на друк шляхом видалення тим більше загальна директива від порту /etc/cups/cupsd.conf: порт 631 і замінити його директиви Listen: Слухати локальний: 631 Це дозволить запобігти віддалених користувачів від друку до локально налаштованих принтерів, все ще дозволяючи локальним користувачам на машина для друку в звичайному режимі. За замовчуванням, локально налаштовані принтерів не будуть передаватися по мережі, але якщо ця функція є якимось чином був включений, ці рекомендації будуть відключити його знову. Обов'язково відключити список вихідних принтера мовлення, або віддалені користувачі як і раніше зможуть побачити локально налаштовані принтери, навіть якщо вони не можуть насправді друкувати на них. Щоб обмежити друк, що служить для певного набору користувачів, використовуйте директиву політики. 120 ГЛАВА 3. ПОСЛУГИ 3.8.3.3 Обмеження доступу до веб-інтерфейсу За замовчуванням доступ до інтерфейсу веб-адміністрування CUPS обмежується локальної машині. рекомендується що це не може бути змінений, тим більше, що механізми аутентифікації, що CUPS передбачає, що вони обмежені в їх ефективності. Якщо це абсолютно необхідно, щоб дозволити віддаленим користувачам управляти локально встановлену принтери, переконайтеся, щоб обмежити доступ, що якомога більше, скориставшись розташування і політики Директива блоків. Наприклад, щоб дозволити віддалений доступ для IP-адреси для користувача ім'я користувача, змінити кожен розташування і Політика директиви блоки таким чином: AuthType Basic Вимагати ім'я користувача Замовлення дозволити, заборонити дозволити локальний Дозволити IP-адреса Як з директивою BrowseAllow, використовуйте один Дозволити директиву для кожної машини, яким потрібен доступ або використовувати одну доступні поєднання визначень директиви CUPS, щоб забезпечити доступ з одного класу машин відразу. Вимагати директиву користувач може приймати список індивідуальних користувачів, групи користувачів (з префіксом @), або стенографію дійсний користувач. Аутентифікація хоста на основі вже відомі обмеження, тим більше, що IP-адреси легко підробити. вимагаючи від користувачів аутентифицировать себе може вирішити цю проблему, але вона не може усунути його. Не застосовувати препарат кореневу обліковий запис управління та адміністрування принтерів. Створити окремий обліковий запис для цієї мети і обмежити доступ до дійсним користувачам з Вимагати дійсний користувачеві або вимагати користувача PrinterAdmin. 3.8.3.4 вжити додаткових заходів безпеки, коли це необхідно Всякий раз, коли це можливо, обмежити доступ зовнішніх мереж »до порту 631. Розгляньте можливість використання CUPS директиви, які обмежують кількість вхідних клієнтів, таких як MaxClients або MaxClientsPerHost. Крім того, існує цілий ряд Політика і директиви Місце призначені для обмеження, які користувачі можуть виконувати різні операції при виконанні друку. при використанні разом, вони можуть допомогти пом'якшити можливість атаки відмови в обслуговуванні. Див cupsd.conf (5) для повного список можливих директив. 3.8.4 Linux друку і обробки зображень (HPLIP) Інструментарій HP Пакет HPLIP утиліта підтримки друку HP, яка встановлена ​​і включена в установці за замовчуванням. Пакет HPLIP складається з двох окремих компонентів. Першим з них є основною послугою HPLIP і другий є менше подкомпонент називається HPIJS. HPLIP є функцією-орієнтованої послуга мережі, яка забезпечує більш високий рівень підтримку друку (наприклад, двонаправленого вводу-виводу, сканування, фото карти і функціональність / Toolbox). HPIJS є нижчою Рівень базовий драйвер друку, який забезпечує базову підтримку принтерів, які не підтримують PostScript HP. 121 3.8.4.1 Відключити HPLIP Сервіс якщо це можливо Так як водій HPIJS буде як і раніше функціонувати без додаткового сервісу HPLIP, HPLIP повинні бути відключені, якщо специфічні функції вищого рівня, що забезпечує HPLIP необхідні принтером, що не PostScript HP за маршрутом система. # Chkconfig HPLIP викл CCE 4425-5 Примітка: При установці пакета HPLIP з нуля, слід зазначити, що HPIJS може бути встановлений безпосередньо без HPLIP. Будь ласка, ознайомтеся з Правилами форуму на веб-сайті HPLIP в http://hplip.sourceforge.net/faqs.html для Більш детальну інформацію про те, як це зробити. 3.9 DHCP Dynamic Host Configuration Protocol (DHCP) дозволяє системам запитувати і отримувати IP- адресу і багато інших параметрів з сервера. Загалом, сайти використовують DHCP або для забезпечення великий пул мобільних або невідомих машин ділитися обмежене число по IP-адресами, або стандартизувати установки, уникаючи статичної, конфігурації індивідуальний IP-адреса на хостах. це Рекомендується, щоб уникнути сайти DHCP в максимально можливій мірі. Так як аутентифікація DHCP не дуже добре підтримується, клієнти DHCP відкриті для атак з боку сервера DHCP-ізгоїв. Такі сервери можуть надавати клієнтам неправильну інформацію (Наприклад, шкідливі адреси сервера DNS), які могли б привести до їх компромісу. Якщо машина повинна діяти як клієнт DHCP або сервер, налаштувати його, захищаючись за допомогою вказівок, що містяться в даному розділі. Це керівництво рекомендує налаштовувати мережі на клієнтах вручну редагувати відповідні файли під / І т.д. / sysconfig. Крім того, можна використовувати графічний інтерфейс системних програм-конфігурації-мережу і Система-конфігурації-мережу-туй, але ці програми переписати файли конфігурації з нуля на основі їх значення за замовчуванням - Знищення будь-яких змін вручну - і тому його слід використовувати з обережністю. 3.9.1 Відключення клієнта DHCP якщо це можливо Для кожного інтерфейсу IFACE на систему (наприклад, eth0), редагувати / і т.д. / sysconfig / мережі-скрипти / ifcfg-IFACE і внести наступні зміни: 1. Виправити BOOTPROTO рядок такого змісту: BOOTPROTO = статична 2. Додайте або виправити такі рядки, замінюючи відповідні значення на основі вашого сайту адресації схема: NETMASK = 255.255.255.0 IPADDR = 192.168.1.2 GATEWAY = 192.168.1.1 CCE 4191-3 DHCP є метод конфігурації мережі за замовчуванням, що надається монтажником системи, тому він може бути включений в багатьох системах. 122 ГЛАВА 3. ПОСЛУГИ 3.9.2 Налаштування DHCP-клієнта, якщо необхідно Якщо DHCP повинен бути використаний, то деякі зміни конфігурації можуть звести до мінімуму кількість інформації, яку він отримує і застосовується від мережі, і, таким чином, кількість невірної інформації шахрай сервер DHCP може успішно поширювати. Для отримання додаткової інформації про налаштування dhclient см посилань нижче (8) і dhclient.conf (5) сторінки людини. 3.9.2.1 Мінімізація DHCP-налаштовані варіанти Створіть файл /etc/dhclient.conf, і додайте відповідні налаштування для кожного з параметрів конфігурації десяти які можуть бути отримані за допомогою DHCP. Для кожного параметра настройки, виконайте одну з таких дій: ?? Якщо параметр не повинен бути налаштований віддалено за допомогою сервера DHCP, виберіть відповідний статичний значення, і додайте рядок: скасовують встановлене значення; ?? Якщо параметр повинен бути налаштований віддалено за допомогою сервера DHCP, додайте наступні рядки: Налаштування запиту; вимагає установки; Наприклад, припустимо, що сервер DHCP повинен забезпечувати тільки IP-адресу і сам маску підмережі. Потім весь файл повинен виглядати наступним чином: витісняють-доменне ім'я "example.com"; скасовують ім'я домену-сервери 192.168.1.2; скасовують NIS-домен ""; скасовують NIS-сервери ""; скасовують НТП-сервери "ntp.example.com"; витісняти маршрутизатори 192.168.1.1; скасовують часу зміщення -18000; запит підмережі маска; вимагають підмережі маску; За замовчуванням, програма клієнта DHCP, dhclient, запитів і застосовує десять варіантів конфігурації (на додаток до IP-адреса) від сервера DHCP: підмережі-маска, широкомовна адреса, час зсуву, маршрутизатори, доменне ім'я, Доменних імен-серверів, ім'я-хоста, NIS-домену, NIS-сервери і НТП-серверів. Багато із запитуваних і приємним dhclient варіанти можуть бути однаковими для кожної системи в мережі. це є Рекомендується, щоб майже всі параметри конфігурації будуть призначені статично, і тільки варіанти, які повинні змінюватися на базис-господар по-хоста присвоюється за допомогою DHCP. Це обмежує шкоду, яка може бути завдано шахрая сервер DHCP. У разі необхідності для вашого сайту, це також можливо, щоб замінити директиву-ім'я хоста в /etc/dhclient.conf, створення статичного імені хоста для машини. Однак dhclient не використовувати параметр імені хоста за умови сервером DHCP (замість того, щоб, використовуючи значення, задане за допомогою зворотного перегляду DNS). Примітка: У цьому прикладі параметри NIS-сервери і NIS-домену встановлені на порожні рядки, в припущенні, що засуджується протокол NIS не використовується. (Дивіться розділ 3.2.4.) Необхідно, щоб замінити параметри невикористані послуги, так що вони не можуть бути встановлені за допомогою сервера DHCP ворожого. Якщо параметр встановлено в порожній рядок, dhclient, як правило, не намагатися налаштувати службу. 123 3.9.3 Відключення сервера DHCP якщо це можливо Якщо пакет був DHCP встановлено на комп'ютері, який не потрібно працювати як сервер DHCP, відключити демон: # Chkconfig Dhcpd викл Якщо це можливо, видаліть програмне забезпечення, а також: # Ням Стирання DHCP CCE 4336-4, 4464-4 DHCPD DHCP-сервер не встановлений або активований за замовчуванням. Якщо було встановлено програмне забезпечення і активований, але система не повинна виступати в якості сервера DHCP, він повинен бути відключений і видалений. Некерований DHCP сервери будуть надавати брехливу інформацію клієнтам, заважати роботі сервера DHCP легітимною сайту якщо такий є, або викликає помилки в налаштуванні машини проявляти непередбачувана поведінка, якщо немає. 3.9.4 Налаштування DHCP-сервера, якщо необхідно Якщо система повинна працювати як сервер DHCP, інформація про конфігурацію вона служить повинна бути зведена до мінімуму. Крім того, підтримка інших протоколів і схем DNS-оновлення повинен бути явно відключені, якщо не потрібно. Файл конфігурації для DHCPd називається /etc/dhcpd.conf. Файл починається з рядом глобальної конфігурації варіанти. Інша частина файлу розділений на секції, по одному для кожного блоку адрес, пропонованих DHCPd, кожен з яких містить параметри конфігурації, специфічні для цього адресного блоку. 3.9.4.1 Не застосовувати препарат Dynamic DNS Щоб сервер DHCP отримувати інформацію DNS від клієнтів, редагувати /etc/dhcpd.conf, і додати або виправити наступний глобальний параметр: Ні-оновлення DDNS стилю немає; CCE 4257-2 Динамічний протокол DNS використовується для віддаленого поновлення даних, що обслуговується сервером DNS. Сервери DHCP може використання динамічного DNS для публікації інформації про своїх клієнтів. Ця установка несе ризики в області безпеки, і його використання не рекомендується. Якщо Dynamic DNS необхідно використовувати, не дивлячись на ризики, яку вона представляє, вкрай важливо, щоб операції динамічного DNS бути захищені використовуючи TSIG або будь-якої іншої криптографічний механізм аутентифікації. Дивіться розділ 3.14 для отримання додаткової інформації про DNS-сервери, в тому числі додаткової інформації про Tsig і Dynamic DNS. Також дивіться dhcpd.conf (5) для більш інформація про захист сервера DHCP від ​​проходить уздовж шкідливих DNS дані своїх клієнтів. Примітка: Елементи управління опцій DDNS-оновлення стилю тільки чи буде сервер DHCP намагатися діяти в якості динамічного DNS-клієнт. До тих пір, як сервер DNS сам налаштований правильно, щоб відмовитися від спроб DDNS, неправильне Налаштування DDNS-оновлення стилю на клієнті нешкідливий (але повинен бути закріплений в якості кращої практики). 124 ГЛАВА 3. ПОСЛУГИ 3.9.4.2 Заборонити відхиляти повідомлення Edit /etc/dhcpd.conf і додати або виправити наступний глобальний параметр, щоб запобігти сервер DHCP з відповідати на повідомлення DHCPDECLINE, якщо це можливо: заперечують зниження; CCE 4403-2 Повідомлення DHCPDECLINE може бути посланий клієнтом DHCP, щоб вказати, що він не вважає оренди запропонованих сервером, щоб бути дійсним. Видаючи багато DHCPDECLINE повідомлень, зловмисник може вичерпати пулу DHCP-сервера по IP-адресами, в результаті чого сервер DHCP забути старі розподілу адрес. 3.9.4.3 Заборонити BOOTP запитів Якщо ваша мережа не повинна підтримувати старих клієнтів BOOTP, відключити підтримку протоколу BOOTP шляхом додавання або виправлення глобальної опції: заперечують BOOTP; CCE 4345-5 Опція BOOTP розповідає Dhcpd реагувати на запити BOOTP. Якщо підтримка цього простого протоколу не потрібно, вона повинна бути відключена, щоб видалити векторів атаки проти сервера DHCP. 3.9.4.4 Мінімізація надаватиметься інформація Редагування /etc/dhcpd.conf. Вивчіть кожен розділ діапазон адрес в файлі, і переконайтеся, що наступні параметри не визначені, якщо не існує оперативна необхідність надати цю інформацію через DHCP: Ім'я домену варіант Домен-сервери імен Опція NIS-домену Опція NIS-сервери Опція НТП-сервери опція маршрутизатори Час зсуву опція CCE 3724-2, 4243-2, 4389-3, 3913-1, 4169-9, 4318-2, 4319-0 Оскільки інформація про конфігурацію, сервер DHCP може бути зловмисно надається клієнтам шахрая сервер DHCP, кількість інформації, що надається через DHCP повинен бути зведений до мінімуму. видалити ці Визначення від конфігурації DHCP-сервера, щоб гарантувати, що законні клієнти не зайве покладатися на DHCP для отримання цієї інформації. Примітка: За замовчуванням, установка клієнта RHEL5 використовує DHCP, щоб запросити більшу частину вищевказаної інформації, отриманої від DHCP-сервер. Зокрема, ім'я домену, доменних імен-сервери і маршрутизатори налаштовані за допомогою DHCP. Ці параметри, як правило, необхідні для належного функціонування мережі, а також, як правило, статичні поперек машини в даному місці. Дивіться Розділ 3.9.2.1 для опису того, як налаштувати статичної інформації сайту в DHCP Конфігурація клієнта. 125 3.9.4.5 Налаштування ведення журналу Переконайтеся в тому, що наступний рядок існує в /etc/syslog.conf: демон. * /var/log/daemon.log Налаштуйте інші інструменти моніторингу журналу Logwatch або підсумовувати умови виникнення помилок, про які повідомляє DHCPd процес. CCE 3733-3 За замовчуванням DHCPD реєструє повідомлення демона об'єкта. Відправлення всіх демонів повідомлень на спеціальний лог-файл є частиною з системного журналу конфігурації описано в розділі 2.6.1.1.1. 3.9.4.6 Додаткові джерела ?? Людина сторінки dhcpd.conf (5) і DHCPD (8) ?? Веб-сторінка ISC http://isc.org/products/DHCP 3.10 Протокол мережевого часу Протокол мережевого часу використовується для управління системним годинником по мережі. Комп'ютерні годинник не дуже точним, так що час буде дрейфувати на некерованих систем. Центральні протоколи часу можуть бути використані як для забезпечення того, щоб час, узгоджується між мережею машин, і що їх час узгоджується із зовнішнім світом. Локальна синхронізація часу рекомендується для всіх мереж. Якщо кожна машина у вашій мережі надійно повідомляє в той же час, як і будь-який інший машини, то це набагато простіше співвідносити повідомлення в журналі в разі нападу. в Крім того, ряд криптографічних протоколів (наприклад, Kerberos) використовують тимчасові мітки для запобігання певних типів атаки. Якщо ваша мережа не синхронізували час, ці протоколи можуть бути ненадійними або навіть непридатним для використання. Залежно від специфіки мережі, точність глобального часу може бути настільки ж важливо, як і локальної синхронізації, або не дуже важливо зовсім. Якщо ваша мережа підключена до Інтернету, рекомендується використовувати публічного сервера часу, так як глобально точний таймінг може бути необхідно, якщо вам потрібно досліджувати або відповісти до атаки, яка виникла за межами вашої мережі. Будь або не використовувати вас зовнішній сервер часу, налаштувати мережу, щоб мати невелику кількість працюючих машин як сервери NTP, а залишок часу отримання інформації від цих внутрішніх серверах. 3.10.1 Вибір NTP Software Мережевий протокол часу (RFC 1305) призначений для синхронізації часу з дуже високим ступенем точності навіть на ненадійною мережі. Тому NTP є складним протоколом. Simple Network Time Protocol (RFC 4330) реалізує підмножина NTP, який призначений, щоб бути досить хорошим, щоб відповідати вимогам часу більшості мереж. Первинна реалізація NTP походить від ntp.org, і поставляється з RHEL5 як НТП оборотів в хвилину. Альтернативою є OpenNTPD, яка є реалізацією SNTP, і який може бути отриманий у вигляді вихідного коду з http://www.openntpd.org. OpenNTPD може бути простіше, ніж налаштувати еталонної реалізації NTP, за рахунок необхідності установки і підтримки програмного забезпечення сторонніх виробників. 126 ГЛАВА 3. ПОСЛУГИ Даний посібник не рекомендує використання конкретного програмного пакета NTP / SNTP, але рекомендую що деяке програмне забезпечення NTP бути обрані й установлено на всіх машинах. У решти цього розділу описуються як безпечно налаштувати клієнти і сервери NTP, і обговорює як еталонну реалізацію NTP і OpenNTPD. 3.10.2 Налаштування Reference NTP, якщо відповідна НТП RPM реалізує опорний NTP-сервер. 3.10.2.1 Конфігурація клієнта NTP Є цілий ряд опцій для настройки клієнтів для роботи з сервером NTP еталонним. можна працювати п'рд в якості служби (тобто безперервно) на кожному хості, налаштування клієнтів таким чином, що протокол НТП ігнорує всі мережі доступ. Це до сих пір вводить додатковий мережевий приймач на клієнтських машинах, і тому не рекомендується. Це керівництво замість того рекомендує запустити Ntpd періодично через хрон. Крім того, можна запустити Ntpdate через хрон з опцією -u, але в даний час застаріти на користь NTPD. З іншого боку, навіть якщо сервер працює під управлінням еталонну реалізацію NTP, можна для клієнтів, щоб отримати доступ до нього використовуючи SNTP. Дивіться розділ 3.10.3.2 для отримання інформації про налаштування клієнтів SNTP. 3.10.2.1.1 Налаштування NTP клієнта Configuration File Дійсний конфігураційний файл для NTPD клієнтської системи повинна існувати на /etc/ntp.conf. Переконайтеся в тому, що / і т.д. / НТП. конф містить наступний рядок, де НТП-сервер є ім'я хоста або IP-адреса сервера сайту NTP: Сервер НТП-сервер Примітка: Програмне забезпечення п'рд також включає в себе перевірку автентичності та шифрування підтримки, яка дозволяє клієнтам, щоб перевірити ідентифікація сервера, і, таким чином, гарантувати цілісність даних часу з високою ймовірністю. Див Ntpd документацію в http://www.ntp.org для отримання більш докладної інформації про реалізацію цієї рекомендованої функції. 3.10.2.1.2 Run п'рд використовуючи Cron Створіть файл /etc/cron.d/ntpd, що містить наступну кронтаб: 15 * * * * корінь / USR / SBIN / п'рд -q -u НТП: НТП Опція -q наказує Ntpd, щоб вийти відразу після установки годин, а параметр -u наказує йому працювати в якості Зазначений користувач. Примітка: При установці годин в перший раз, виконати зазначену вище команду з опцією -g, так як NTPD буде відмовитися від установки годин, якщо вона істотно відрізняється від джерела. Це кронтаб буде виконуватися Ntpd для синхронізації часу з сервером NTP в 15 хвилин кожної години. (Це є Можна вибрати іншу хвилину або змінювати хвилину між машинами, щоб уникнути важкого трафіку НТП сервер.) Щогодини синхронізація повинна бути досить частими, що годинник дрейфу НЕ будуть помітні. 127 3.10.2.2 Конфігурація сервера NTP контакти сайту NTP-сервер центральний сервер NTP, ймовірно, або один, що надаються вашим провайдером або публічного часу сервер, щоб отримати точні дані часу. Потім сервер дозволяє інші машини в мережі, щоб запросити час дані. Файл конфігурації сервера NTP знаходиться на /etc/ntp.conf. 3.10.2.2.1 Включити NTP Daemon Якщо ця машина є сервером NTP, переконайтеся, що п'рд включений під час завантаження: # Chkconfig Ntpd на CCE 4376-0 3.10.2.2.2 Заборонити Весь доступ до NTPD За замовчуванням Редагування файлу /etc/ntp.conf. Prepend або виправити такий рядок: обмеження за замовчуванням ігнорувати CCE 4134-3 Оскільки п'рд являє собою складний програмний пакет, який прослуховує для мережевих підключень і працює як корінь, він повинен бути захищений від доступу до мережі неавторизованих машин. Цей параметр використовує внутрішнє дозвіл Ntpd, щоб відмовити весь доступ до будь-якій машині, сервер або клієнт, яка не дозволеним іншими параметрами політики. 3.10.2.2.3 Вкажіть віддалений сервер NTP для даних тимчасових 3.10.2.2.3 Вкажіть віддалений сервер NTP для даних тимчасових Знайдіть IP-адреса, сервер-IP, відповідного віддаленого сервера NTP. Редагування файлу /etc/ntp.conf, і додати або виправити такі рядки: обмеження сервера IP-маску 255.255.255.255 nomodify notrap noquery сервер IP- CCE 4385-1 Якщо ваш сайт не вимагає даних часу, щоб бути точним, а просто бути синхронізовані між місцевими машинами, це крок може бути пропущений, а сервер NTP за замовчуванням буде надавати дані про час від локальних годин. Проте, хороша ідея періодично синхронізувати годинник з будь-яким джерелом точного часу, навіть якщо він не підходить для зробити це автоматично. Попередній крок відключити всі віддалений доступ до даних цього стану сервера NTP в. Цей сервер NTP повинен звернутися віддалений сервер, щоб отримати точні дані, так що конфігурація NTP повинна дозволити, що віддалені дані, які будуть використовуватися для зміни системний годинник. Обмеження лінія змінює права доступу за замовчуванням для цього віддаленого сервера. сервер рядок вказує на віддалений сервер як пріоритетне сервера NTP для тимчасових даних. Якщо ви збираєтеся синхронізувати більш ніж один сервер, вказати обмеження і серверні лінії для кожного сервера. Примітка: Можна було б вказати ім'я хоста, а не IP-адреса, для поля сервера. Проте, обмежити параметр застосовується тільки до мережевих блокам IP-адрес, тому вважається більш ремонтопрігодни використання IP-адреса в обох полях. 128 ГЛАВА 3. ПОСЛУГИ 3.10.2.2.4 Дозволити Законні клієнти NTP, щоб отримати доступ до сервера Визначте відповідний мережевий блок, netwk і мережеву маску, маску, що представляє машини на ваша мережа, яка буде синхронізувати з цим сервером. Редагування /etc/ntp.conf і додайте рядок: обмеження netwk маски маска nomodify notrap Редагувати / і т.д. / sysconfig / Iptables. Додайте наступний рядок, гарантуючи, що він з'являється перед остаточним LOG і DROP лінії для RH-Firewall-1-INPUT ланцюга: -A RH-Firewall-1-INPUT -s netwk / маска -m стан --state NEW -p УДП --dport 123 -j ACCEPT Якщо клієнти розкидані по більш ніж однієї блок, окремі обмеження і ACCEPT лінії повинні бути додані кожен блок. Конфігурація Iptables необхідна тому, що конфігурація за замовчуванням Iptables не дозволяє вхідного доступу до будь-які послуги. Дивіться розділ 2.5.5 для отримання додаткової інформації про IPTables. Примітка: Реалізація посилання NTP буде відмовлятися служити дані про час клієнтам, поки достатньо часу, поки не закінчиться що час хост-сервера можна вважати осіли до точного значення. Під час тестування, почекайте десять хвилин після запуску Ntpd перед спробою синхронізації клієнтів. 3.10.3 Налаштування OpenNTPD в разі необхідності, OpenNTPD є реалізацією протоколу SNTP, який передбачений в якості простий альтернативою посилання NTP-сервер. Переваги OpenNTPD включають в себе простоту конфігурації і меншу кодову, хоча це також не вистачає багатьох управління і іншими функціями протоколу, використовуваних сервером NTP еталонним. ця простота відбувається за рахунок деградованих точності часу, але SNTP, ймовірно, досить точним для більшості сайтів з типовим вимоги до моніторингу. 3.10.3.1 Отримати NTP Software Якщо ваш сайт має намір використовувати реалізацію OpenNTPD, необхідно зібрати і встановити програмне забезпечення. (Якщо ваш сайт має намір використовувати еталонну реалізацію NTP, ніякої установки не потрібно.) 1. Отримайте програмне забезпечення, завантаживши відповідну версію джерела, OpenNTPD-версія .tar.gz, з http://www.openntpd.org/portable.html. 2. Розпакуйте вихідний код: $ TAR xzf OpenNTPD-версія .tar.gz 3. Налагодження та компіляції вихідного коду. (За замовчуванням код буде скомпільовано для установки в / USR / місцеве): $ CD OpenNTPD-версія $ ./configure --with-Privsep користувач = НТП $ марка 4. Як корінь, встановити вийшов програму в / USR / місцеві: # Зробити установку CCE 4032-9 129 Опція конфігурації --with-privsep користувачем = НТП говорить OpenNTPD використовувати існуючу систему НТП рахунки для позакореневого частини його роботи. 3.10.3.2 Конфігурація клієнта SNTP OpenNTPD працює тільки в режимі демона - немає командного рядка підходить для запуску з хрон. Проте, цей вважається досить безпечним для використання клієнтом, тому що чорт не буде прослуховувати будь-які мережеві порти за замовчуванням, і тому, що OpenNTPD невелика кодова без інтерфейсу віддаленого управління або іншими складними функціями. Проте, можна запустити програму за часом степінг, такі як rdate (1), з cron'а замість конфігурації демон, як описано в даному розділі. 3.10.3.2.1 Включити NTP Daemon Редагування файлу /etc/rc.local. Додати або виправити такий рядок: / USR / місцеві / SBIN / п'рд -s CCE 4424-8 3.10.3.2.2 Налаштування клієнта NTP Daemon використовувати локальний сервер Редагування файлу /usr/local/etc/ntpd.conf. Додати або виправити такий рядок: сервер local-server.example.com де local-server.example.com це ім'я хоста локального сервера NTP або SNTP сайту. CCE 3487-6 3.10.3.3 Конфігурація сервера SNTP Сервер SNTP отримує дані про час з віддаленого сервера, а потім прослуховує мережевий інтерфейс для тимчасових запитів від місцевих машин. 3.10.3.3.1 Включити NTP Daemon Редагування файлу /etc/rc.local. Додати або виправити такий рядок: / USR / місцеві / SBIN / п'рд -s Оскільки OpenNTPD є програмне забезпечення сторонніх виробників, вона не має стандартний сценарій запуску, тому запускається демон при завантаженні за допомогою локального об'єкта. 130 ГЛАВА 3. ПОСЛУГИ 3.10.3.3.2 прослуховування клієнтських підключень Редагування файлу /usr/local/etc/ntpd.conf. Додати або виправити такий рядок: слухати на IPAddr де IPADDR є основною IP-адреса цього сервера. За замовчуванням, п'рд не слухає зв'язок через мережі. Слухання має бути активно включений NTP сервери, так що клієнти можуть отримати інформацію про час. 3.10.3.3.3 Дозволити Законні клієнти NTP, щоб отримати доступ до сервера Визначте відповідний мережевий блок, netwk і мережеву маску, маску, що представляє машини на ваша мережа, яка буде синхронізувати з цим сервером. Редагувати / і т.д. / sysconfig / Iptables. Додайте наступний рядок, гарантуючи, що він з'являється перед остаточним LOG і DROP лінії для RH-Firewall-1-INPUT ланцюга: -A RH-Firewall-1-INPUT -s netwk / маска -m стан --state NEW -p УДП --dport 123 -j ACCEPT Конфігурація Iptables необхідна тому, що конфігурація за замовчуванням Iptables не дозволяє вхідного доступу до будь-які послуги. Дивіться розділ 2.5.5 для отримання додаткової інформації про IPTables. 3.10.3.3.4 Вкажіть віддалений сервер NTP для даних тимчасових Знайти ім'я хоста, сервер-хост, відповідного віддаленого сервера NTP. Змініть файл / USR / місцеві / і т.д. / ntpd.conf, і додати або виправити такий рядок: Сервер-хост Цей параметр налаштовує Ntpd для отримання тимчасових даних з віддаленого хоста. Щоб використовувати кілька серверів часу, додайте лінія для кожного сервера. 3.11 Mail Transfer Agent Поштові сервери використовуються для відправки і отримання пошти по мережі від імені користувачів сайту. Пошта є дуже поширена послуга, і СПМ часто стають об'єктами мережевих атак. Переконайтеся в тому, що машини не працюють MTA в надмірно, і налаштувати необхідні MTA як захисно, наскільки це можливо. CCE 4416-4 3.11.1 Вибір поштового сервера і налаштування програмного забезпечення Виконайте одну з таких параметрів для налаштування електронної пошти на комп'ютері, в залежності від ролі системи в мережу: 131 ?? Якщо ця машина не повинна працювати в якості поштового сервера, дотримуйтесь подальших інструкцій в цьому розділ, щоб вибрати Sendmail або Postfix і дивіться Розділ 3.11.2 для отримання інформації про те, як забезпечити це Програмне забезпечення виконується тільки в режимі передачі тільки. Програмне забезпечення МТА ще повинні бути встановлені для того, щоб забезпечити локальна доставка пошти для таких послуг, як хрон. ?? Якщо машина повинна працювати в якості поштового сервера, дотримуйтесь подальших інструкцій в цьому розділі, щоб вибрати або Sendmail або Postfix, а потім прочитати стратегії конфігурації MTA в розділі 3.11.3 для інформація про параметри конфігурації. Потім нанесіть як АПС-незалежної операційної системи Конфігурація керівництва в розділі 3.11.4, а також конкретні вказівки для вашого MTA в розділі 3.11.6 або Розділ 3.11.5. Далеко не всі машини в будь-якому місці повинен бути налаштований для отримання пошти по мережі. Проте, це може бути необхідно для більшості машин на даному сайті, щоб надіслати електронною поштою, наприклад, таким чином, щоб хрон робочих місць може повідомити вихід адміністратору. Postfix і Sendmail підтримують режим уявлення тільки в якому пошта може бути відправлена ​​з машини до Центральний сайт MTA (або безпосередньо доставлені до локального облікового запису), але машина не може отримувати пошту по мережі. Якщо Mail Transfer Agent (MTA) необхідно, система за замовчуванням Sendmail. Postfix, яка була написана з безпеку на увазі, також доступний і найбільш прийнятний. Postfix може бути більш ефективно міститися SELinux як його Модульна конструкція привела в окремих процесах, що виконують певні дії. Більш детальну інформацію про ці СПМ доступна від їх відповідних веб-сайтів, http://www.sendmail.org і http://www.postfix.org. Система альтернативних варіантів в RHEL автоматично подбає режисури залежного програмного забезпечення від системи до використовувати або Postfix або Sendmail, якщо встановлений тільки один. Див його довідкової сторінці альтернативи (8) для отримання додаткової інформації. 3.11.1.1 Вибір Postfix в якості поштового сервера програмного забезпечення За замовчуванням системи встановлюються з Sendmail як програмного забезпечення MTA. Щоб використовувати Postfix натомість, запустіть наступні команди: # Ням встановити постфікси # Ням видалити Sendmail Postfix є кращим, оскільки він був розроблений з урахуванням безпеки та може бути більш ефективно міститися SELinux. CCE 14495-6, 14068-1 Вибір Postfix над Sendmail також може бути досягнуто під час установки системи за допомогою кікстарта, шляхом додавання наступні рядки в файл кікстарта в його% пакетів розділу: постфікси -sendmail 3.11.1.2 Виберіть Sendmail як програмне забезпечення поштового сервера За замовчуванням системи встановлюються з Sendmail як MTA програмного забезпечення і тому ніяких дій не потрібно, якщо Sendmail повинні бути використані в якості агента передачі, хоча постфікси рекомендується. Якщо, проте, постфікси був встановлений на додаток до Sendmail або замість нього, але є нагальна потреба використовувати Sendmail, виконайте наступні команди: # Ням встановити Sendmail # Ням Стирання Постфіксний 132 ГЛАВА 3. ПОСЛУГИ 3.11.2 Налаштування SMTP Для Поштові клієнти У цьому розділі обговорюються параметри Postfix і Sendmail в конфігурації електронної пошти уявлення тільки. 3.11.2.1 Налаштування Postfix для відправки в режим тільки 3.11.2.1.1 Відключити Прослуховування в мережі Редагування файлу /etc/postfix/main.cf. Переконайтеся в тому, що з'являється тільки в наступних інет лінійних інтерфейсів: inet_interfaces = локальний CCE 15018-5 Це гарантує, що Postfix буде приймати повідомлення тільки від пошти процесів, запущених на локальній системі, а не з мережі. 3.11.2.2 Налаштування Sendmail для подання в режим тільки 3.11.2.2.1 Відключення Listening Sendmail Daemon Відредагуйте файл / і т.д. / sysconfig / Sendmail. Додати або змінити рядок: DAEMON = немає CCE 4293-7 АПС виконує дві функції: прослуховування по мережі для вхідних запитів SMTP електронної пошти та відправка пошти з локальної машини. Оскільки вихідної пошти може бути відкладено через збої мережі або інших проблем, вихідний МТА працює в режимі черзі тільки, в якій вона буде робити періодичні спроби повторно відправити будь-який затриманий пошту. Установка не DAEMON = не говорить Sendmail виконувати тільки бігун черзі на цій машині, і ніколи не отримати SMTP пошта запити. 3.11.2.2.2 Налаштування відправки пошти в разі необхідності, Якщо доречно налаштувати уявлення пошти з центральним MTA, редагувати /etc/mail/submit.cf. розмістити лінія, починаючи з D {MTAHost}, і змінити його таким чином: D {MTAHost} почтовий_сервер де почтовий_сервер це ім'я хоста сервера, до якого ця машина повинна направити свою вихідну пошту. Ця пропозиція надається в якості простий спосіб зміщуватися від конфігурації, в якій кожна машина на місці запускає свій власний MTA, до конфігурації, в якій клієнтські машини не запускається слухати демонів. Якщо цієї модифікації робиться /etc/mail/submit.cf, а потім, коли локальний процес на машині намагається відправити пошту, повідомлення будуть направлені машини MailServer для обробки. Модифікація /etc/mail/submit.cf безпосередньо тільки підходить, якщо ваш сайт не виконує ніякої іншої MailServer настройки на клієнтах. Якщо настройки інший робиться, використовувати звичайну процедуру Sendmail зміни, щоб визначити MTA хоста. 133 Примітка: На додаток до створення цієї зміни на клієнті, він також може бути необхідно змінити конфігурацію АПС на почтовий_сервер так, що він буде ретранслювати пошту від імені цього хоста. 3.11.3 Стратегії MTA безпеки В даному розділі розглядаються кілька типів конфігурації MTA, які повинні бути виконані для того, щоб захистити від нападу з застосуванням поштової системи. Хоча синтаксис конфігурації буде відрізнятися в залежності від агента передачі використовується (Дивіться розділ 3.11.5 для синтаксису конфігурації Sendmail і розділ 3.11.6 для Postfix), ці стратегії, як правило, Рекомендується для будь-якого MTA, в тому числі ті, які не передбачені цим керівництвом. 3.11.3.1 Обмеження використання ресурсів для пом'якшення відмови в обслуговуванні Часто бажано, щоб обмежити здатність атакуючого споживати ресурси поштовий сервер, просто відправивши в іншому випадку діє пошта на високій швидкості, будь то зловмисно або випадково. Відповідні обмеження ресурсів включають обмеження по: кількості MTA демонів, які можуть працювати в один час, швидкість, з якою вхідні повідомлення можуть бути отриманий, розмір і складність кожного повідомлення, або обсяг простору черзі пошти, яка повинна залишатися вільною для того, щоб для доставки пошти. Цей останній параметр заслуговує додаткового пояснення. Більшість СПМ вимагають простору черзі для тимчасових файлів в порядку обробляти існуючі повідомлення в своїх чергах. Тому, якщо файлова система черги дозволяється повністю заповнити відмова в обслуговуванні, МТА не зможе очистити свою власну чергу, навіть якщо шкідливий трафік припинився. Це призведе до затримки відновлення від нападу. 3.11.3.2 Налаштування SMTP вітання Банер Коли віддалені відправники пошти підключитися до МТА на порту 25, вони зустрічають початкового банера в рамках SMTP-діалог. Цей банер необхідно, але він часто порушує правила занадто багато інформації, в тому числі програмне забезпечення MTA, який знаходиться у використанні, а іноді і його номер версії. Дистанційні відправників пошти не потрібно ця інформація для того, щоб відправити пошту, тому банер повинен бути змінений, щоб показати тільки ім'я хоста (який Вже відомо і може бути корисним) і слово ESMTP, щоб вказати, що варіант сучасний протокол SMTP є підтримується. 3.11.3.3 Контроль Релеінг Пошти Незапрошуваних навалом електронної пошти, називають по-різному як ВБО, UCE або спам, є серйозною проблемою на Інтернет сьогодні. Наслідки для безпеки спаму є те, що він працює як атаки відмови в обслуговуванні на законній електронна пошта використання. Стратегії боротьби зі спамом квитанцію на вашому сайті, є складними і швидко розвивається, і, таким чином, далеко за межі обсяг цього посібника. Проблема релейного захисту від несанкціонованого електронної пошти, однак, можуть і повинні бути вирішені будь-яка мережа підключених сайтів. Більшість СПМ виконують дві функції: приймати пошту з віддалених сайтів від імені місцевих користувачів, а також дозволити місцевим користувачам відправляти пошту на віддалені сайти. Перша функція відносно легко - пошта, чию адресу одержувача локальна можна припустити, призначені для локального користувача. Остання функція є більш складною. Так як, як правило, не рахується ні безпечним, ні бажаним для користувачів, щоб увійти в систему самого хоста MTA для відправки пошти, АПС повинен бути може віддалено приймати пошту, адресовану будь-якого з робочої станції користувача. Якщо АПС працює дуже старий програмне забезпечення або налаштований погано, це може бути можливим зловмисникам скористатися цією функцією, використовуючи ваш MTA щоб передати їх спам від одного віддаленого сайту на інший. Це небажано з багатьох причин, не в останню чергу, що ваш сайт швидко буде занесений в чорний список як джерело спаму, в результаті чого ви не можете відправити легітимною електронної пошти ваших кореспондентів. 134 Розділ 3. ПОСЛУГИ Найпростіше рішення, описаний у цьому посібнику, щоб налаштувати MTA для ретрансляції пошти тільки з локального Сайту адрес, а також деякий варіант на це за замовчуванням для більшості сучасних АПС. Це рішення може бути недостатньо для сайтів, чиї користувачі повинні відправляти пошту з віддалених машин, наприклад, під час поїздки, а також для сайтів, де подача пошти повинні бути прийняті від діапазонів мережі, які не зважають безпечними, або тому, що уповноважені машини є некерованими або тому, що можна підключити неавторизовані машини до мережі. Якщо вилучені або мобільні хости мають право передавати, або якщо локальні клієнти існують в небезпечних netblocks, то SMTP AUTH Протокол повинен бути використаний для відправників листів потрібне для перевірки автентичності перед відправкою повідомлень. Для кращого захисту і дозволити підтримку широкого спектру механізмів аутентифікації, без відправки паролів по мережі в текстовому форматі, SMTP AUTH транзакції повинні бути зашифровані з використанням SSL. Інший підхід полягає у вимозі пошти, який буде представлений на порт 587, призначений повідомлення Подача порту. використання окремого порту дозволяє функції ретрансляції пошти, щоб бути повністю відокремлена від функції доставки пошти. це може стати найкращою практики в майбутньому, але опис того, як налаштувати повідомлення Подання Порт В даний час виходить за рамки даного керівництва. Див RFC 2476 для отримання інформації про цю конфігурацію. 3.11.4 Налаштування операційної системи для захисту поштового сервера Керівництво в цьому розділі підходить для будь-якого хоста, яка діє в якості сайту MTA, будь то по пошті Сервер працює за допомогою Sendmail, Postfix, або деяке інше програмне забезпечення. 3.11.4.1 використовувати окремі хости для зовнішньої і внутрішньої пошти, якщо це можливо Поштовий сервер є частою мішенню мережевих атак ззовні. Проте, оскільки всі користувачі сайту отримувати пошту, поштовий сервер повинен бути відкритий для деякої зв'язку від кожного всередині користувачів. Настійно рекомендується, щоб ці Функції бути розділені, маючи зовні видимий поштовий сервер, який обробляє всі вхідні і вихідні пошта, а потім направляє внутрішню пошту на окремій машині, з якої користувачі можуть отримати до нього доступ. 3.11.4.2 захищати господаря від MTA доступу користувачів Поштовий сервер містить привілейовані дані, що належать до всіх користувачів і виконує важливу функцію мережі. запобігання користувач не може увійти в цей сервер є запобіжним засобом проти ескалації привілеїв або атак відмови в обслуговуванні, які може поставити під загрозу поштову службу. Прийміть заходи, щоб гарантувати, що тільки системні адміністратори мають право доступу до командної оболонки на хост МТА. 3.11.4.3 Обмеження віддаленого доступу до поштової спула Якщо користувачі безпосередньо підключаються до цієї машини, щоб отримувати пошту, переконайтеся, що є один, добре забезпечений механізм доступ до директорії / вар / золотника / пошти (каталог / Var / пошти є символічною посиланням на це). Надання необмеженого доступу до / вар / котушка / пошти може бути небезпечним, так як цей каталог містить конфіденційну інформацію належать до всіх користувачів. Такі протоколи, як NFS, які мають незахищений механізм авторизації, За замовчуванням, слід вважати недостатньо для цих цілей. Дивіться розділ 3.17 для докладної інформації про безпечну конфігурації по POP3 або IMAP, які є кращими способами для надання користувачам доступу до пошти. 135 3.11.4.4 Налаштування Iptables для дозволу доступу до поштового сервера Редагувати / і т.д. / sysconfig / Iptables. Додайте наступний рядок, гарантуючи, що він з'являється перед остаточним LOG і DROP лінії для RH-Firewall-1-INPUT ланцюга: -A RH-Firewall-1-INPUT -m стан --state NEW -p TCP --dport 25 -j ACCEPT Конфігурація Iptables за замовчуванням не дозволяє вхідного доступу до служби SMTP. Ця модифікація дозволяє що доступ, зберігаючи при цьому інші порти на сервері в їх замовчуванням захищене стан. Дивіться Розділ 2.5.5 для більш інформація про Iptables. 3.11.4.5 Перевірка системи реєстрації в журналі і дозволів для Пошти Редагування файлу /etc/syslog.conf. Додайте або, якщо це необхідно виправити наступний рядок (це за замовчуванням): пошта * -. / Var / Журнал / MAILLOG Виконайте наступні команди, щоб забезпечити правильні дозволу на журнал пошти: # Чаун корінь: корінь / Var / Журнал / MAILLOG # CHMOD 600 / Var / Журнал / MAILLOG Журнали поштових серверів містять записи про кожну електронної пошти, яке відправлено або отримано на системі, яка вважається конфіденційну інформацію більшістю сайтів. Необхідно, щоб ці журнали будуть зібрані для цілей налагодження і статистики, але їх вміст має бути захищене від несанкціонованого доступу. 3.11.4.6 Налаштування SSL-сертифікатів для використання з SMTP AUTH Якщо SMTP AUTH буде використовуватися (дивіться розділ 3.11.3.3 для опису можливих механізмів анти-ретрансляцію), то настійно рекомендується використовувати SSL для захисту облікових даних в дорозі. Існують також конфігурації, для яких вона Може бути бажаним, щоб зашифрувати всю пошту в переході від одного до іншого MTA, хоча такі конфігурації знаходяться поза обсяг цього посібника. У будь-якому випадку, етапи створення та встановлення продукта SSL є незалежними АПС у використанні, і описані тут. 3.11.4.6.1 Створення сертифіката SSL Примітка: Цей крок повинен виконуватися у вашій системі CA, а не на самому хості МТА. Якщо ви будете мати комерційний CA підписувати сертифікати, то цей крок повинен бути виконаний на окремому, фізично захищеної системи, присвяченій тому, що Мета. Перейдіть в каталог сертифікатів CA: # CD / і т.д. / ПКІ / TLS / сертифікати Створіть пару ключів для поштового сервера: # OpenSSL genrsa від'їзду mailserverkey.pem 2048 Потім згенерувати запит на підпис сертифіката (CSR) для ЦС, щоб підписати, переконавшись в тому, щоб поставити вашу пошту доменне ім'я сервера повністю кваліфіковане як загальна назва: 136 ГЛАВА 3. ПОСЛУГИ # OpenSSL REQ -new -key mailserverkey.pem від'їзду mailserver.csr Потім сервер CSR пошти повинен бути підписаний, щоб створити сертифікат поштового сервера. Ви можете або відправити CSR до встановленої CA або підписати його з вашим CA. Щоб підписати mailserver.csr за допомогою CA: # OpenSSL ча-в mailserver.csr від'їзду mailservercert.pem Цей крок створює секретний ключ, mailserverkey.pem і публічний сертифікат, mailservercert.pem. пошта сервер буде використовувати їх, щоб довести свою ідентичність, демонструючи, що він має сертифікат, який був підписаний CA. Поштові клієнти на вашому сайті повинні бути готові відправити пошту тільки на сервер, вони можуть проходити перевірку автентичності. 3.11.4.6.2 Установка SSL-сертифіката Створіть каталог сертифікатів PKI для пошти, якщо він вже не існує: # MkDir / і т.д. / ПКІ / TLS / пошта # Чаун корінь: корінь / і т.д. / ПКІ / TLS / пошта # CHMOD 755 / і т.д. / ПКІ / TLS / пошта Використання знімних носіїв або будь-якої іншої безпечний формат передачі, встановити файли, створені в попередньому ступити на поштовий сервер: ?? /etc/pki/tls/mail/serverkey.pem: секретний ключ mailserverkey.pem ?? /etc/pki/tls/mail/servercert.pem: файл сертифіката mailservercert.pem Перевірка прав доступу і власника цих файлів: # Чаун корінь: корінь /etc/pki/tls/mail/serverkey.pem # Чаун корінь: корінь /etc/pki/tls/mail/servercert.pem # CHMOD 600 /etc/pki/tls/mail/serverkey.pem # CHMOD 644 /etc/pki/tls/mail/servercert.pem Переконайтеся, що файл сертифіката відкритого ЦС був встановлений як /etc/pki/tls/CA/cacert.pem, і має правильні дозволу: корінь # Чаун: корінь /etc/pki/tls/CA/cacert.pem # CHMOD 644 /etc/pki/tls/CA/cacert.pem 3.11.5 Налаштування сервера Sendmail, якщо необхідно Коли Sendmail налаштований для роботи в якості сервера для вхідної пошти, він прослуховує порт 25 для підключення, і реагує на ці сполуки, використовуючи конфігурацію в файл /etc/mail/sendmail.cf. Цей файл має кілька непрозорий формат, і зміна його безпосередньо, як правило, не рекомендується. Замість цього наступна процедура повинна використовуватися для зміни конфігурації Sendmail: 1. Встановіть Sendmail-CF RPM, який необхідний для того, щоб скласти новий конфігураційний файл: # Ням встановити Sendmail-CF 2. Змініть джерело M4 файл /etc/mail/sendmail.mc відповідно до вказівок на етапі конфігурації, яку ви претендуєте. 137 3. Усередині каталогу / і т.д. / пошта /, використання зробити, щоб побудувати конфігурацію відповідно до Makefile за умови, по Sendmail: # Кд / і т.д. / пошта # Зробити sendmail.cf 3.11.5.1 Обмеження атак відмови в обслуговуванні Редагування /etc/mail/sendmail.mc, а також додати або виправити такі параметри: визначити ( `confMAX_DAEMON_CHILDREN ',` 40') DNL визначити ( `confCONNECTION_RATE_THROTTLE ',` 3') DNL визначити ( `confMIN_FREE_BLOCKS ',` 20971520') DNL визначити ( `confMAX_HEADERS_LENGTH ',` 51200') DNL визначити ( `confMAX_MESSAGE_SIZE ',` 10485760') DNL визначити ( `confMAX_RCPTS_PER_MESSAGE ',` 100') DNL Примітка: Значення, наведені тут приклади, і, можливо, повинні бути змінені для будь-якого конкретного сайту, особливо один з великим об'ємом електронної пошти. Ці параметри конфігурації служать, щоб зробити його більш важким для нападників споживати ресурси на MTA хост. (Дивіться розділ 3.11.3.1 подробиці про те, чому це робиться.) Опція MAX DAEMON ДІТИ обмежує кількість Sendmail процесів, які можуть бути розгорнуті для обробки вхідних з'єднань в будь-який час, в той час як ПІДКЛЮЧЕННЯ RATE THROTTLE обмежує кількість з'єднань в секунду, які можуть отримати кожен слухач. Опція MIN вільних блоків зупиняє електронної пошти квитанцію, коли файлова система черги близька до повної. MAX HEADERS ДЛИНА (Байт), MAX розмір повідомлення (в байтах) і MAX RCPTS за повідомлення (різних одержувачів) Варіанти місце обмеження на правові розміри повідомлень, отриманих через SMTP. 3.11.5.2 Налаштування SMTP вітання Банер Редагування /etc/mail/sendmail.mc, а також додати або виправити наступний рядок, замінюючи відповідне вітання рядок для $ J: визначити ( `confSMTP_LOGIN_MSG ',` $ J') DNL і перекомпіліровать конфігурацію Sendmail в. Привітальне повідомлення банер розкриває, що процес прослуховування пошти Sendmail, а не який-небудь інший MTA, а також надає номер версії. Дивіться розділ 2.3.7 для докладної інформації про що попереджають банерів, а в розділі 3.11.3.2 стратегій щодо SMTP вітальні банери зокрема. Sendmail змінна $ J містить ім'я хоста поштового сервера, який може бути правильне вітання рядок для більшості середовищ. 3.11.5.3 Контроль Релеінг Пошти У цьому керівництві будуть обговорюватися два механізму для управління релей пошти в Sendmail. / І т.д. / пошта / релейно-домени Файл містить список імен хостів, яким дозволено пересилати пошту. Дотримуйтеся вказівок у розділі 3.11.5.3.1 до налаштувати ретрансляцію для довірених машин. Якщо є машини, які повинні бути дозволені для ретрансляції пошти, але які не можна довіряти беззастережно передати, налаштувати SMTP AUTH з підтримкою TLS з використанням вказівок в розділах 3.11.5.3.2 і далі. 138 ГЛАВА 3. ПОСЛУГИ 3.11.5.3.1 Налаштування надійних мереж і хостів ?? Якщо все машини, які поділяють загальний домен або ім'я субдомена може ретранслювати, а потім редагувати / і т.д. / пошта / релейно-домени, додавши рядок для кожного домену або субдомена і т.д.: example.com trusted-subnet.school.edu ... ?? Якщо машини, які дозволені для ретрансляції повинні бути вказані на основі кожного хоста, а потім відредагувати / і т.д. / пошта / релейно-домени, додавши рядок для кожного такого хоста: host1.example.com host5.subnet.example.com smtp.trusted-subnet.school.edu Потім відредагуйте /etc/mail/sendmail.mc, додати або виправити рядок: FEATURE ( `relay_hosts_only ') DNL і перекомпіліровать конфігурацію Sendmail в. Файл / і т.д. / пошта / релейно-домени повинні містити тільки безліч машин, для яких цей MTA повинен беззастережно ретрансляції пошти. Це налаштовує вхідних і вихідних ретрансляцію, тобто господарі згадується в релейно-домени можуть відправити пошту через MTA і MTA також буде приймати вхідні повідомлення, адресовані таких хостів. Це довірчі відносини - якщо спамери отримати доступ до цих машин, ваш сайт буде ефективно стати відкритим реле. Рекомендується тільки машини, які управляються вами або іншим довіреним організація може бути поміщений в релейно-доменів, і що користувачі всіх інших машин потрібно використовувати SMTP AUTH для відправки пошти. Примітка: реле-домени файл повинен бути налаштований, щоб утримувати або список доменів (і в цьому випадку кожен хост в кожній з цих областей буде дозволено передавати) або список хостів (в цьому випадку кожен окремий ретрансляція хост повинні бути перераховані і sendmail.cf повинні бути налаштовані заново інтерпретувати файл релейно-домени в бажане шлях). 3.11.5.3.2 Вимагати SMTP AUTH Перед Ретрансляція з ненадійних клієнтів За замовчуванням, Sendmail використовує бібліотеку Cyrus-SASL для перевірки автентичності. Для того, щоб включити використання аутентифікації SASL для ретрансляції, редагувати /etc/mail/sendmail.mc і додати або виправити наступні параметри: TRUST_AUTH_MECH ( `ВХІД РІВНИНА ') визначити ( `confAUTH_MECHANISMS ',` ВХІД РІВНИНА') і перекомпіліровать sendmail.cf. Потім відредагуйте /usr/lib/sasl2/Sendmail.conf і додати або виправити такі рядки: pwcheck_method: saslauthd Включення saslauthd демона: # Chkconfig saslauthd на Опція конфігурації AUTH МЕХАНІЗМИ говорить Sendmail, щоб дозволити зазначені механізми перевірки автентичності 139 використовуватися в ході діалогу SMTP. Два перераховані механізми використовують SASL для перевірки пароля, наданих користувач. Оскільки ці механізми передачі відкритого тексту паролі, вони повинні бути захищені за допомогою TLS, як описано в в наступному розділі. Команда TRUST AUTH МЕХАНІЧ.ОБОРОТИ говорить Sendmail, що відправники, які успішно пройти перевірку справжності за допомогою вказаного механізм може пересилати пошту через цей MTA, навіть якщо їх адреси не в релейних доменах. Файл /usr/lib/sasl/Sendmail.conf конфігураційний файл Cyrus-SASL для Sendmail. метод pwcheck директива говорить SASL як знайти паролі. Найпростіший спосіб, описаний тут, є запуск окремої аутентифікації демон, saslauthd, який здатний зв'язуватися зі службою перевірки автентичності системи. У Red Hat, saslauthd використовує PAM за замовчуванням, який повинен працювати в більшості випадків. Якщо у вас є централізована система аутентифікації який не працює через PAM, подивіться на saslauthd (8) для визначення сторінки керівництва, як налаштувати saslauthd для вашої середовища. 3.11.5.3.3 Вимагати TLS для SMTP AUTH Редагувати /etc/mail/sendmail.mc, додати або виправити такі рядки: визначити ( `confAUTH_OPTIONS ',` є р') DNL визначити ( `confCACERT_PATH ',` / і т.д. / ПКІ / TLS / CA') DNL визначити ( `confCACERT ',` /etc/pki/tls/CA/cacert.pem')dnl визначити ( ` ',` /etc/pki/tls/mail/servercert.pem')dnl confSERVER_CERT визначити ( ` ',` /etc/pki/tls/mail/serverkey.pem')dnl confSERVER_KEY і перекомпіліровать sendmail.cf. Ці параметри, в поєднанні з попередніми налаштуваннями, скажіть Sendmail для захисту всіх транзакцій SMTP AUTH за допомогою TLS. Перші чотири варіанти описують розташування необхідного TLS сертифіката та ключів. Параметр AUTH OPTIONS налаштовує діалог SMTP AUTH. Опція А включена за замовчуванням, і просто говорить про те, що перевірка справжності дозволена, якщо відповідний механізм може бути знайдений. Опція р говорить Sendmail для захисту від пасивних атак. Рівнина і аутентифікації в систему механізми, рекомендовані в цьому посібнику для сумісності з ПАС, пересилати паролі у відкритому вигляді. (ClearText передачі паролів уразливі для пасивна атака.) Таким чином, якщо р встановлено, то SMTP-демон буде не зробити команду AUTH доступні до тих пір, після того, як клієнт використовував STARTTLS команду для шифрування сеансу. Якщо інші механізми аутентифікації були включений, чи не пересилати паролі у відкритому вигляді, то TLS не обов'язково потрібно. 3.11.6 Налаштування Postfix, якщо необхідно Postfix зберігає свої конфігураційні файли в каталозі / і т.д. / Postfix за замовчуванням. Первинний файл конфігурації /etc/postfix/main.cf. Інші файли будуть введені в міру необхідності. 3.11.6.1 Обмеження атак відмови в обслуговуванні Редагування /etc/postfix/main.cf. Додати або виправити такі рядки: default_process_limit = 100 smtpd_client_connection_count_limit = 10 smtpd_client_connection_rate_limit = 30 queue_minfree = 20971520 140 ГЛАВА 3. ПОСЛУГИ header_size_limit = 51200 message_size_limit = 10485760 smtpd_recipient_limit = 100 Примітка: Значення, наведені тут приклади, і, можливо, повинні бути змінені для будь-якого конкретного сайту. За замовчуванням, Процес ковадло Postfix збирає статистику надходження пошти. Для того, щоб отримати інформацію про те, про якою швидкістю з'єднання є Типовим на вашому сайті, подивіться в / VAR / Журнал / MAILLOG для ліній з ім'ям демона Постфіксний / ковадлі. 140 ГЛАВА 3. ПОСЛУГИ header_size_limit = 51200 message_size_limit = 10485760 smtpd_recipient_limit = 100 Примітка: Значення, наведені тут приклади, і, можливо, повинні бути змінені для будь-якого конкретного сайту. За замовчуванням, Процес ковадло Postfix збирає статистику надходження пошти. Для того, щоб отримати інформацію про те, про якою швидкістю з'єднання є Типовим на вашому сайті, подивіться в / VAR / Журнал / MAILLOG для ліній з ім'ям демона Постфіксний / ковадлі. Ці параметри конфігурації служать, щоб зробити його більш важким для нападників споживати ресурси на хості МТА. (Дивіться розділ 3.11.3.1 подробиці про те, чому це робиться.) Граничний процес за умовчанням параметр управляє може існувати багато процесів smtpd в той час, в той час як smtpd клієнт обмеження числа з'єднань управляє числом з тих, які можуть бути зайняті будь-яким одним віддаленим відправника, і smtpd обмеження контролю швидкості підключення клієнта кількість з'єднань будь-який клієнт може зробити в хвилину. За замовчуванням локальні хости (ті, в mynetworks) звільняються від кожного клієнта обмеження швидкості. Параметр черзі minfree встановлює поріг вільного місця для того, щоб зупинити електронної пошти квитанцію до Черга файлова система повністю заповнена. Граничний розмір заголовка, максимальний розмір повідомлення, і smtpd обмеження кількості одержувачів Параметри місце оцінки на законних розмірах повідомлень, отриманих через SMTP. 3.11.6.2 Налаштування SMTP вітання Банер Редагування /etc/postfix/main.cf, а також додати або виправити наступний рядок, замінивши деякі інші формулювання для Інформаційний банер, якщо ви віддаєте перевагу: smtpd_banner = $ myhostname ESMTP Привітальне повідомлення банер розкриває, що процес прослуховування пошти Postfix. Дивіться розділ 2.3.7 для докладної інформації про попереджувальних банерів, а також розділ 3.11.3.2 для стратегій щодо SMTP вітальні банери зокрема. 3.11.6.3 Контроль Релеінг Пошти управління ретрансляцією пошти Postfix реалізуються за допомогою опції smtpd обмеження одержувачів, який контролює обмеження, накладені на діалозі SMTP, як тільки відправник і одержувач конверта адреси відомі. Керівництво в розділах 3.11.6.3.1-3.11.6.3.2 повинні застосовуватися до всіх машин. Якщо є машини, які має бути дозволено пересилати пошту, але не можна довіряти беззастережно передати, налаштувати SMTP AUTH з SSL підтримки з використанням вказівок, наведених в розділах 3.11.6.3.3 і нижче. 3.11.6.3.1 Налаштування надійних мереж і хостів Редагування /etc/postfix/main.cf, і налаштувати вміст змінної mynetworks в одному з наступних шляхи: ?? Якщо будь-яка машина в підмережі, що містить MTA може бути довіреною для передачі повідомлень, додати або виправити лінія: mynetworks_style = підмережі ?? Якщо тільки господар сам MTA є довіреною для ретрансляції повідомлень, додати або виправити: 141 mynetworks_style = хост ?? Якщо безліч машин, які можуть передавати більш складним, вручну вказати запис для кожного мережевий блок або IP-адреса, який є довіреною для ретрансляції шляхом установки змінної mynetworks безпосередньо: mynetworks = 10.0.0.0/16, 192.168.1.0/24, 127.0.0.1 Мінлива mynetworks повинна містити тільки безліч машин, для яких цей MTA повинен беззастережно ретрансляції пошти. Це довірчі відносини - якщо спамери отримати доступ до цих машин, ваш сайт буде ефективно стати відкритим реле. Рекомендується тільки машини, які управляються вами або іншим довіреним організація може бути поміщений в mynetworks, і користувачі всіх інших машин потрібно використовувати SMTP AUTH для відправки пошта. 3.11.6.3.2 Дозволити необмежену Relaying для довірених мереж тільки Редагування /etc/postfix/main.cf, а також додати або виправити визначення обмежень одержувачів smtpd так, щоб він містить принаймні: smtpd_recipient_restrictions = ... permit_mynetworks, reject_unauth_destination, ... Повний зміст обмежень smtpd-одержувачів буде варіюватися в залежності від сайту, так як це звичайне місце для розміщення спаму обмеження і інші варіанти на конкретних ділянках. Опція дозволу mynetworks дозволяє всю пошту ретранслювати від машини в mynetworks. Потім відхилити несанкціоно варіант призначення заперечує всю пошту призначення якого адреса не є локальним, запобігаючи будь-які інші машини ретрансляцію. Ці два варіанти повинні завжди з'являтися в цей порядок, і повинні, як правило, слідують один за одним відразу, якщо не використовується SMTP AUTH. 3.11.6.3.3 Вимагати SMTP AUTH Перед Ретрансляція з ненадійних клієнтів Аутентифікація SMTP дозволяє віддаленим клієнтам безпечно пересилати пошту, вимагаючи від них для перевірки автентичності перед відправкою пошта. Postfix в SMTP AUTH використовує бібліотеку аутентифікації SASL з ім'ям, яка не є частиною самого Postfix. У цьому розділі описується, як налаштувати перевірку автентичності за допомогою реалізації Cyrus-SASL. дивіться нижче обговорення інших варіантів. Для того, щоб включити використання SASL аутентифікації, редагувати /etc/postfix/main.cf і додати або виправити наступне настройки: smtpd_sasl_auth_enable = так smtpd_recipient_restrictions = ... permit_mynetworks, permit_sasl_authenticated, reject_unauth_destination, ... Потім відредагуйте /usr/lib/sasl/smtpd.conf і додати або виправити наступний рядок з правильним аутентифікації механізм SASL для використання: 142 ГЛАВА 3. ПОСЛУГИ pwcheck_method: saslauthd Включення saslauthd демона: # Chkconfig saslauthd на Postfix може використовувати або бібліотеку Cyrus або Довекот як джерело для аутентифікації SASL. Якщо цей вузол працює Dovecot з якоїсь іншої причини, рекомендується, щоб підтримка SASL Dovecot щоб використовувалася замість запуску Кір-код, а також. Див http://www.postfix.org/SASL README.html для отримання інструкцій по реалізації, що конфігурація, яка не описана в цьому посібнику. У конфігурації Postfix, в директиву smtpd SASL Auth дають можливість smtpd розповідає, щоб дозволити використання протоколу SMTP AUTH Команда під час діалогу SMTP, а також підтримувати цю команду, отримавши інформацію про аутентифікації з SASL. Директива про обмеження одержувачів smtpd змінюється таким чином, що, якщо клієнт не з'єднатися з ним довірений адресу, допускається спроба аутентифікації (дозвіл на перевірку справжності SASL) для ретрансляції пошти. Файл /usr/lib/sasl/smtpd.conf конфігураційний файл Cyrus-SASL. Директива метод pwcheck говорить SASL як знайти паролі. Найпростіший спосіб, описаний вище, є запуск окремого демона аутентифікації, saslauthd, який здатний взаємодіяти з системою аутентифікації системи. На RHEL5, saslauthd використання PAM за замовчуванням, який повинен працювати в більшості випадків. Якщо у вас є централізована система аутентифікації, яка не чинить працювати через PAM, подивіться на saslauthd (8) Manpage, щоб дізнатися, як налаштувати saslauthd для вашої середовища. 3.11.6.4 TLS необхідно для SMTP AUTH Редагування /etc/postfix/main.cf, а також додати або виправити такі рядки: smtpd_tls_CApath = / і т.д. / ПКІ / TLS / CA smtpd_tls_CAfile = /etc/pki/tls/CA/cacert.pem smtpd_tls_cert_file = /etc/pki/tls/mail/servercert.pem smtpd_tls_key_file = /etc/pki/tls/mail/serverkey.pem smtpd_tls_security_level = може smtpd_tls_auth_only = так Ці опції сказати Postfix для захисту всіх транзакцій з використанням SMTP AUTH TLS. Перші чотири варіанти опису місця розташування необхідних файлів ключів TLS. Директива рівень безпеки smtpd smtpd TLS розповідає, щоб дозволити команду STARTTLS під час протоколу SMTP заміна, але не вимагати його для пошти відправника. (Якщо ваш сайт не отримує пошту тільки від інших довірених сайтів якого сисадміни можуть попросити, щоб зберегти копію вашого сертифіката сайту, ви не хочете, щоб вимагати TLS для всіх SMTP обміни.) Smtpd тільки Auth TLS директива повідомляє smtpd вимагати команду STARTTLS, перш ніж дозволити клієнтові спробувати виконати аутентифікацію для ретрансляції з використанням SMTP AUTH. Воно не може бути можливим використовувати цю директиву, якщо необхідно дозволити ретрансляцію від не TLS-сумісних клієнтського програмного забезпечення. Якщо це так, просто опустити цей рядок. 3.12 LDAP LDAP є популярним служби каталогів, тобто стандартизований спосіб пошуку інформації з центральної бази даних. Це відносно просто налаштувати машину RHEL5 для отримання інформації про аутентифікації з сервера LDAP. Якщо ваша мережа використовує LDAP для аутентифікації, переконайтеся, що для настройки клієнтів і серверів надійно. 143 3.12.1 Використання OpenLDAP для того щоб забезпечити LDAP службу, якщо це можливо Програма сервера системи LDAP за замовчуванням клієнт / називається OpenLDAP. Його документація доступна на Веб-сторінка проекту: http://www.openldap.org. 3.12.2 Налаштування OpenLDAP Клієнти Перед налаштуванням будь-якого комп'ютера, щоб бути клієнтом LDAP, переконайтеся, що сервер LDAP є робочий присутній в мережі. Дивіться розділ 3.12.3 для отримання інструкцій з налаштування сервера LDAP. Даний посібник рекомендує налаштовувати клієнтів OpenLDAP вручну редагувати відповідні файли конфігурації. RHEL5 забезпечує автоматизований конфігурації інструмент під назвою AuthConfig і графічну оболонку для AuthConfig звана система-конфігурації-аутентифікації. Проте, ці інструменти не дають достатню гнучкість в конфігурації. Інструменти AuthConfig не дозволяють визначити місце розташування SSL файлів сертифікатів, що корисно при спробі використовувати SSL чисто по декількох протоколах. Вони також є надмірно агресивними в розміщенні таких послуг, як і мережевих груп автомоунтер карти під контролем LDAP, де він безпечніше використовувати LDAP тільки для служб, яким вона має відношення у вашому середовищі. 3.12.2.1 Налаштування відповідних параметрів LDAP для домену Припустимо, що повне ім'я хоста вашого сервера LDAP є ldap.example.com і підстава DN з ваших домен DC = приклад, DC = COM (це прийнято використовувати ім'я домену в якості основи DN). Редагувати / і т.д. / LDAP. конф, і додати або виправити такі рядки: база DC = приклад, DC = COM URI LDAP: //ldap.example.com / Потім відредагуйте /etc/openldap/ldap.conf, і додати або виправити такі рядки: БАЗА DC = приклад, DC = COM URI LDAP: //ldap.example.com / Машина якої ім'я хоста задається тут повинен бути налаштований як сервер LDAP, які обслуговують дані були визначені базовий DN використовується тут. Дивіться розділ 3.12.3 Для додаткової інформації про налаштування сервера LDAP. 3.12.2.2 Налаштування LDAP Використовувати TLS для всіх транзакцій 1. Переконайтеся, що копія сертифіката ЦС сайту був розміщений у файлі /etc/pki/tls/CA/cacert.pem. 2. Налаштування LDAP для забезпечення використання TLS і довіряти сертифікати, підписані центром сертифікації сайту По-перше, редагувати файл /etc/ldap.conf, і додати або виправити такі рядки: start_tls SSL tls_checkpeer та tls_cacertdir / і т.д. / ПКІ / TLS / CA tls_cacertfile /etc/pki/tls/CA/cacert.pem Потім відредагуйте /etc/openldap/ldap.conf, і додати або виправити такі рядки: 144 ГЛАВА 3. ПОСЛУГИ TLS_CACERTDIR / і т.д. / ПКІ / TLS / CA TLS_CACERT /etc/pki/tls/CA/cacert.pem CCE 14894-0 Розділ 2.5.6 описує загальносистемного конфігурацію SSL для вашого підприємства. Можна розмістити ваш інформація про сертифікат під який-небудь каталог, крім / і т.д. / Pki / TLS, але при використанні послідовної структури каталогів через рекомендується все SSL послуги на вашому сайті. Сервер LDAP повинен бути налаштований з сертифікатом підписаний сертифікат ЦС з ім'ям тут. 3.12.2.3 Налаштування служб аутентифікації використовувати OpenLDAP Редагування файлу /etc/ldap.conf, а також додати або виправити такі рядки: pam_password md5 Змініть файл /etc/nsswitch.conf, і додати або виправити такі рядки: ПАРОЛЬ: файли LDAP тінь: файли LDAP Група: файли LDAP Редагування файлу /etc/pam.d/system-auth-ac. Внесіть наступні зміни, які будуть додавати посилання на LDAP в кожній з чотирьох секцій файлу: ?? Безпосередньо перед останнім рядком в розділі Ідент (той, що містить РАМ deny.so), вставте рядок: Auth достатньою pam_ldap.so use_first_pass ?? Змініть перший рядок в розділ рахунку, додавши опцію зламаною тінь. Лінія повинна потім такого змісту: рахунок потрібно pam_unix.so broken_shadow ?? Безпосередньо перед останнім рядком в розділі рахунку (той, що містить РАМ permit.so), вставте лінія: рахунок [за замовчуванням = поганий успіх = нормально user_unknown = ігнорувати] pam_ldap.so ?? Безпосередньо перед останнім рядком в розділі паролів (один, який містить РАМ deny.so), вставте лінія: пароль достатньої pam_ldap.so use_authtok ?? В кінці файлу (після останнього рядка в секції сеансу), додайте рядок: сесія за бажанням pam_ldap.so Перша модифікація говорить LDAP очікувати паролі в MD5 форматі хеш, а не відкритим текстом. Red Hat системи використовують файл /etc/nsswitch.conf, щоб визначити відповідні джерела для пошуку напевно види даних, такі як імена користувачів, груп, імена хостів, мережевих груп, або протоколів. Можна управляти багатьма іншими типи даних за допомогою LDAP, але це керівництво рекомендує, що тільки імена користувачів (PASSWD дані), паролі (тінь дані), і групи (група даних) можна керувати за допомогою LDAP. Якщо ваш сайт використовує мережеві групи, це може бути доцільним управляти ними за допомогою LDAP, а також. Проте, дані, які майже ніколи не змінюється, наприклад, вміст файлу / і т.д. / послуг, є поганим вибором для 145 центральне управління, так як він представляє ризик з мало користі. Рекомендується, щоб не автомоунтер бути використані на всіх, тому контроль LDAP карт автомоунтер навряд чи буде доречно. Файл /etc/pam.d/system-auth-ac використовується PAM для управління доступом до найбільш аутентіфіцированний послуг. Синтаксис конфігураційного файлу PAM кілька загадковим. Лінії рекомендується тут комбінований Ефект від використання LDAP для пошуку даних аутентифікації для користувачів, які не можуть бути знайдені в локальному / і т.д. / пароль файл. Це означає, що, наприклад, як і раніше можна використовувати локальний кореневої пароль. Деталі опцій, таких як зламаною тінь, використання authtok, і використовувати перший прохід може бути подивився вгору на сторінках керівництва для різних РАМ модулі. Їх основний ефект полягає в спробі для аутентифікації дали пароль і проти місцевого / і т.д. / тінь і центральний сервер LDAP, що не змушуючи користувача вводити пароль більше одного разу. конфігурація PAM обговорюється далі в розділі 2.3.3. 3.12.3 Налаштування сервера OpenLDAP Цей розділ містить вказівки про те, як налаштувати сервер OpenLDAP для безпечного надання інформації для використання в централізованої служби аутентифікації. Це не повне керівництво по підтримці сервера OpenLDAP, але можуть бути корисні в процесі переходу до інфраструктури OpenLDAP, тим не менш. 3.12.3.1 Установка RPM OpenLDAP сервера Чи є ця машина сервер OpenLDAP? Якщо так: # Ням встановити OpenLDAP-серверів # Chkconfig на LDAP CCE 3501-4 OpenLDAP-серверів RPM не встановлюється за умовчанням на машинах RHEL5. Потрібно тільки OpenLDAP сервера, а не клієнтів, які використовують LDAP для аутентифікації. 3.12.3.2 Налаштування домену конкретних параметрів Редагування файлу /etc/openldap/slapd.conf. Додати або виправити такі рядки: суфікс "DC = приклад, DC = ком" rootdn "сп = менеджер, DC = приклад, DC = ком" де DC = приклад, DC = COM той же корінь ви будете використовувати на клієнтах LDAP. Це основні директиви конфігурації LDAP. Параметр суфікс вказує ім'я кореневого всієї інформації обслуговуються цим сервером LDAP, і повинна бути деяка ім'я пов'язане з вашого домену. Імена параметрів rootdn привілейований користувач LDAP, в який дозволено зчитувати або записувати всі дані, керовані цим сервером LDAP. 3.12.3.3 Конфігурація LDAP Root Password Переконайтеся в тому, що файл конфігурації має розумні дозволу, перш ніж покласти хеш пароля в цей файл: 146 ГЛАВА 3. ПОСЛУГИ # Чаун корінь: LDAP файл /etc/openldap/slapd.conf # CHMOD 640 файл /etc/openldap/slapd.conf Генерування хеш пароля за допомогою утиліти slappasswd: # slappasswd Новий пароль: Повторно ввести новий пароль: Це буде виводити хешіруются рядок пароля. Редагування файлу /etc/openldap/slapd.conf, а також додати або виправити лінія: rootpw {SSHA} хешіруются-паролем рядок Не забудьте вибрати безпечний пароль для кореневого користувача LDAP, так як даний користувач має дозвіл на читання і запис всіх даних LDAP, тому компроміс кореневої пароль LDAP, ймовірно, дозволить повний компроміс вашого сайту. Захист конфігураційних файлів, що містять зашифрований пароль таким же чином ви б захистити інші файли, такі як / І т.д. / тінь, які містять хешіруются дані аутентифікації. Крім того, не забудьте використовувати досить сильну хеш Функція, такі як SHA-1,1, а не незахищеною схемою, такий як крипти. 3.12.3.4 Налаштування сервера LDAP Вимагати TLS для всіх транзакцій Оскільки всі запити і відповіді LDAP, особливо містять інформацію аутентифікації або іншої конфіденційної дані, повинні бути захищені від розкриття або модифікації в процесі передачі по мережі, це керівництво рекомендує з використанням протоколу SSL для захисту всіх транзакцій. Для того, щоб зробити це, необхідно мати загальносистемний інфраструктуру SSL в якому сертифікат ЦС використовується для перевірки того, що інші сертифікати, такі як, що сервер надав LDAP до його клієнти, є справжніми. Отже, ця процедура включає в себе використання системи CA для створення сертифіката для сервера LDAP, а потім встановити що сертифікат на сервері LDAP і настройка Slapd вимагати його використання. Дивіться розділ 2.5.6 для отримання докладної інформації про процес створення SSL-сертифікатів для використання серверів на вашому сайті. 3.12.3.4.1 Створення сертифіката для сервера LDAP Примітка: Цей крок повинен виконуватися на системі CA, а не на самому сервері LDAP. Перейдіть в каталог сертифікатів CA: # CD / і т.д. / ПКІ / TLS / сертифікати Створіть пару ключів для сервера LDAP: # OpenSSL genrsa від'їзду ldapserverkey.pem 2048 Потім згенерувати запит на підпис сертифіката (CSR) для CA підписати: # OpenSSL REQ -new -key ldapserverkey.pem від'їзду ldapserver.csr Вхід запит ldapserver.csr: # OpenSSL ча-в ldapserver.csr від'їзду ldapservercert.pem 1If ви використовуєте алгоритм SHA-1, хешіруются рядок пароля буде починатися з "{} SHA" або "{SSHA}". 147 Цей крок створює секретний ключ, ldapserverkey.pem і публічний сертифікат, ldapservercert.pem. LDAP сервер буде використовувати їх, щоб довести свою ідентичність, демонструючи, що він має сертифікат, який був підписаний сайт CA. клієнти LDAP на вашому сайті повинні бути тільки готові приймати дані аутентифікації від LDAP перевіреним сервер. 3.12.3.4.2 Встановіть сертифікат на сервер LDAP Створіть каталог для сертифікатів PKI LDAP, якщо він вже не існує: # MkDir / і т.д. / ПКІ / TLS / LDAP # Чаун корінь: корінь / і т.д. / ПКІ / TLS / LDAP # CHMOD 755 / і т.д. / ПКІ / TLS / LDAP Використання знімних носіїв або будь-якої іншої безпечний формат передачі, встановити файли, створені в попередньому крок на сервер LDAP: ?? /etc/pki/tls/ldap/serverkey.pem: секретний ключ ldapserverkey.pem ?? /etc/pki/tls/ldap/servercert.pem: файл сертифіката ldapservercert.pem Перевірка прав доступу і власника цих файлів: # Чаун корінь: /etc/pki/tls/ldap/serverkey.pem LDAP # Чаун корінь: /etc/pki/tls/ldap/servercert.pem LDAP # CHMOD 640 /etc/pki/tls/ldap/serverkey.pem # CHMOD 640 /etc/pki/tls/ldap/servercert.pem Переконайтеся, що файл сертифіката відкритого ЦС був встановлений як /etc/pki/tls/CA/cacert.pem, і має правильні дозволу: # MKDIR / і т.д. / ПКІ / TLS / CA корінь # Чаун: корінь /etc/pki/tls/CA/cacert.pem # CHMOD 644 /etc/pki/tls/CA/cacert.pem CCE 4360-4, 4378-6, 4492-5, 4263-0, 3502-2, 4449-5, 4361-2, 4427-1, 4321-6, 4339-8, 4105-3, 3718-4 В результаті цих кроків, сервер LDAP буде мати доступ до своїх власних особистим сертифікатом і ключ, з яким цей сертифікат в зашифрованому вигляді, і в файл публічного сертифіката, що належать до CA. Зверніть увагу, що було б можливо для ключа, щоб захистити в подальшому, так що процеси, запущені в LDAP не міг читати. Якби це було зроблено, то Процес сервера LDAP необхідно буде перезавантажити вручну щоразу, коли сервер перезавантажений. 3.12.3.4.3 Налаштування Slapd Використання сертифікатів Редагування файлу /etc/openldap/slapd.conf. Додати або виправити такі рядки: TLSCACertificateFile /etc/pki/tls/CA/cacert.pem TLSCertificateFile /etc/pki/tls/ldap/servercert.pem TLSCertificateKeyFile /etc/pki/tls/ldap/serverkey.pem безпеку simple_bind = 128 Перший набір ліній сказати Slapd, де знайти відповідні сертифікати SSL представити клієнтам, коли вони запросити шифрування транзакцію. Останній параметр вказує Slapd ніколи, щоб дозволити клієнтам уявити облікові дані (тобто 148 ГЛАВА 3. ПОСЛУГИ паролі) в незашифрованому сесії. Це не є хорошим принципом безпеки не дозволяти незашифровані паролі перетинають мережу, тому переконайтеся, що LDAP мандати це. 3.12.3.5 Установка інформації про обліковий запис в базу даних LDAP Є багато способів, щоб підтримувати базу даних OpenLDAP. Методи включають в себе: ?? Формат запису вхідних даних в LDIF (5) в файл / шлях / до / нові записи, а також використання slapadd імпортувати ці записи в той час як Slapd не працює: # Slapadd -l / шлях / до / нові записи ?? Напишіть сценарій для створення і редагування записів LDAP шляхом підключення до сервера LDAP нормально. Perl Модуль Net :: LDAP підходить для цього, існує Python API називається Python-LDAP, і функціональність ймовірно, доступні для інших мов сценаріїв, а також. ?? Використовуйте LDAP фронтального програму, яка надає інтерфейс для редагування бази даних. Якщо передній кінець Програма є веб-або іншим доступним по мережі, переконайтеся, що інформація аутентифікації захищений за допомогою SSL між клієнтом адміністратора і програми, а також між програмою і база даних LDAP. Будь-який з цих методів або інші можуть бути придатними для вашого сайту. Даний посібник не дає рекомендації, і не буде ніякого подальшого обговорення синтаксису введення даних LDAP в базу даних. 3.12.3.5.1 Створення верхнього рівня структури LDAP для домену Створити структуру для самого домена, принаймні такими ознаками: дп: DC = приклад, DC = COM Objectclass: dcObject Objectclass: організація DC: приклад O: Опис організації Це заповнювач для кореня дерева LDAP домену. Без цього запису, LDAP не зможе знайти будь-які інші записи для домену. 3.12.3.5.2 Створення LDAP структур для користувачів і груп Створення LDAP структур для людей (користувачів) і для груп, щонайменше, такими ознаками: дп: НУ = люди, DC = приклад, DC = COM OU: люди structuralObjectClass: OrganizationalUnit Objectclass: OrganizationalUnit дп: НУ = груп, DC = приклад, DC = COM OU: групи structuralObjectClass: OrganizationalUnit Objectclass: OrganizationalUnit 149 користувачі і групи Posix є два елементи верхнього рівня, які будуть необхідні для того, щоб використовувати LDAP для аутентифікації. Ці організаційні одиниці використовуються для визначення двох категорій в LDAP. 3.12.3.5.3 Створення облікових записів Unix Для кожного користувача Unix, створити запис LDAP з принаймні, такі атрибути (інші можуть відповідати для вашого сайту, а), використовуючи значення змінних, що мають такий користувачеві. дп: UID = ім'я користувача, НУ = люди, DC = приклад, DC = COM structuralObjectClass: InetOrgPerson Objectclass: InetOrgPerson Objectclass: posixAccount Objectclass: shadowAccount сп: FullName зп: прізвище GECOS: FullName gidNumber: первинної груповий ідентифікатор домашняя_папка: / головна / ім'я користувача loginShell: / шлях / до / оболонки UID: ім'я користувача uidNumber: UID Парольпользователя: {MD5} md5-хеш-пароль Якщо ваш сайт реалізує термін дії пароля, в якому паролі повинні бути змінені кожні N днів (див розділ 2.3.1.7), то кожна запис повинна також мати атрибут: ShadowMax: N Загалом, схеми LDAP для користувачів використовують UID для позначення тексту імені користувача і uidNumber для числової UID. Це використання може бути трохи заплутаним, коли в порівнянні зі стандартним використанням Unix. Ви не повинні створювати записи для кореневої облікового запису або для системних облікових записів, які є унікальними для окремих систем, але тільки для облікових записів, які повинні бути загальними для всіх машин, і які мають інформацію про аутентифікації (Наприклад, пароль), пов'язаний з ними. 3.12.3.5.4 Створити Unix груп Для кожної групи Unix, створити запис LDAP, по крайней мере, наступними ознаками: дп: сп = імя_группи, НУ = груп, DC = приклад, DC = COM сп: імя_группи structuralObjectClass: posixGroup Objectclass: posixGroup gidNumber: GID memberUid: username1 memberUid: імя_пользователя2 ... memberUid: usernameN Зверніть увагу, що кожен користувач має первинну групу, ідентифікованого полем gidNumber в запису облікового запису користувача. що група повинна бути створена, але не обов'язково, щоб перерахувати користувача як memberUid групи. Така поведінка має 150 ГЛАВА 3. ПОСЛУГИ знайомі адміністраторам, так як вона ідентична обробці в / і т.д. / пароль і / і т.д. файлів / груп. Не створюйте записи для кореневої групи або для системних груп, але тільки для груп, які містять людські користувачів або які є загальними для всіх систем. 3.12.3.5.5 Створення груп для адміністрування LDAP Якщо група адміністраторів LDAP, адміністраторів, бажано, ця група повинна бути створена трохи інакше. Специфікація повинна мати такі атрибути: дп: сп = адміни, НУ = груп, DC = приклад, DC = COM сп: адміни structuralObjectClass: groupOfUniqueNames Objectclass: groupOfUniqueNames uniqueMember: сп = менеджер, DC = приклад, DC = COM uniqueMember: UID = admin1-ім'я користувача, НУ = люди, DC = приклад, DC = COM uniqueMember: UID = admin2-ім'я користувача, НУ = люди, DC = приклад, DC = COM ... uniqueMember: UID = adminN-ім'я користувача, НУ = люди, DC = приклад, DC = COM LDAP не може використовувати Posix групи для своєї власної внутрішньої аутентифікації - для цього потрібно порівняти ім'я користувача, певне в аутентифицированного зв'язуються з деякими внутрішніми groupOfUniqueNames. Якщо ви не вкажете адміністраторів LDAP ' група, то все управління LDAP необхідно буде зробити за допомогою кореневого користувача LDAP (Manager). з причин аудиту та виявлення помилок, рекомендується, щоб адміністратори LDAP мають унікальні ідентичності. (Дивіться розділ 2.3.1.3 для аналогічних міркувань стосовно використання Sudo для команд привілейованими системи.) 3.12.3.6 Налаштування Slapd для захисту відомостей перевірки автентичності Редагування файлу /etc/openldap/slapd.conf. Додати або виправити такі специфікації доступу: 1. Захист пароля користувача, дозволяючи користувач сам або адміністратори LDAP, щоб змінити його, що дозволяє анонімний користувач для аутентифікації проти нього, і не допускаючи ніякого іншого доступу: доступ до ATTRS = Парольпользователя самовивозом записи по групах / groupOfUniqueNames / uniqueMember = "CN = адміни, НУ = груп, DC = приклад, DC = COM" пишуть Анонімний AUTH не по * жоден доступ до ATTRS = shadowLastChange самовивозом записи по групах / groupOfUniqueNames / uniqueMember = "CN = адміни, НУ = груп, DC = приклад, DC = COM" пишуть від * читання 2. Дозволити всім прочитати іншу інформацію, і дозволяють адміністраторам змінити його: доступ до * по групах / groupOfUniqueNames / uniqueMember = "CN = адміни, НУ = груп, DC = приклад, DC = COM" пишуть від * читання Правила доступу застосовуються в порядку, зустрічаються, тому більш конкретні правила повинні з'являтися в першу чергу. Зокрема, Правило обмеження доступу до Парольпользователя сусло до правила, що дозволяє доступ до всіх даних. атрибут shadowLastChange є відміткою про час, і дуже важливо, тільки якщо ваш сайт реалізує термін дії пароля. якщо 151 Ваш сайт не має адміністраторів LDAP групу, кореневого користувача LDAP (так званий менеджер в цьому посібнику) буде мати можливість змінювати дані без явного оператора доступу. 3.12.3.7 правильні дозволу на LDAP-сервера файлів Виправте дозволу на доступ до файлів LDAP-сервера: # Чаун LDAP: корінь / Var / Бібліотека / LDAP / * CCE 4484-2, 4502-1 Деякі ручні методи вставки інформації в базу даних LDAP може залишити ці файли з неправильними дозволів. Це запобіжить Slapd від запуску правильно. 3.12.3.8 Налаштування Iptables, щоб дозволити доступ до сервера LDAP Визначте відповідний мережевий блок, netwk і мережеву маску, маску, що представляє машини на ваша мережа, яка буде синхронізувати з цим сервером. Редагувати / і т.д. / sysconfig / Iptables. Додайте наступні рядки, гарантуючи, що вони з'являються перед заключним LOG і DROP лінії для RH-Firewall-1-INPUT ланцюга: -A RH-Firewall-1-INPUT -s netwk / маска -m стану --state NEW -p TCP --dport 389 -j ACCEPT -A RH-Firewall-1-INPUT -s netwk / маска -m стану --state NEW -p TCP --dport 636 -j ACCEPT Конфігурація Iptables за замовчуванням не дозволяє вхідного доступу до будь-яких послуг. Ці модифікації дозволяють Доступ до первинних LDAP (389) і в зашифрованому вигляді лише (636) портів, зберігаючи при цьому всі інші порти на сервері в їх за замовчуванням захищене стан. Дивіться розділ 2.5.5 для отримання додаткової інформації про Iptables. Примітка: Навіть якщо сервер LDAP обмежує з'єднання, так що тільки зашифровані запити дозволені, то, ймовірно, необхідно дозволити проходження трафіку за замовчуванням порту 389. Це справедливо, тому що багато клієнтів LDAP реалізувати шифрування шляхом підключення до первинного порту і видачі команди STARTTLS. 3.12.3.9 Налаштування ведення журналу для LDAP 1. Змініть файл /etc/syslog.conf. Додати або виправити такий рядок: LOCAL4. * /var/log/ldap.log 2. Створіть файл журналу з безпечними дозволами: # Сенсорний /var/log/ldap.log # Чаун корінь: корінь /var/log/ldap.log # CHMOD 0600 /var/log/ldap.log 3. Змініть файл /etc/logrotate.d/syslog і додайте шлях до файлу /var/log/ldap.log простору список розділених в першому рядку. 152 ГЛАВА 3. ПОСЛУГИ 4. Змініть файл конфігурації LDAP файл /etc/openldap/slapd.conf і встановити розумний набір журналу за замовчуванням параметри, такі як: LogLevel stats2 OpenLDAP відправляє свої дані журналу системного журналу LOCAL4 з пріоритетом налагодження. За замовчуванням RHEL5 не зберігає цей об'єкт взагалі. Конфігурація системного журналу запропонував тут буде зберігати ніяких вихідних даних, що реєструються Slapd в файлі /var/log/ldap.log, і буде включати цей файл в стандартному для ротації лог-файлів системного журналу. За замовчуванням ведення журналу LDAP є досить громіздким. Параметр LogLevel є розділений пробілами список предметів, які підлягають заносяться в журнал. Вказівка ​​stats2 зменшить вихід журналу кілька, але цей рівень все одно буде виробляти деякі протоколювання кожен раз, коли запит LDAP проводиться. (Це може бути доцільно, в залежності від вимог аудиту вашого сайту.) Для того, щоб захопити тільки Slapd запуску повідомлення, не вказано LOGLEVEL немає. Див slapd.conf (5) для отримання докладної інформації про параметр LOGLEVEL. Дивіться Розділ 2.6.1.1 для отримання додаткової інформації про системний журналі. 3.13 NFS і RPC Мережева файлова система є найпопулярнішою розподілена файлова система для середовища Unix, і дуже широко розгорнуто. На жаль, NFS ні розроблений з урахуванням вимог безпеки, а також має ряд недоліків, як з точки зору самого протоколу і тому, що будь-якої установки NFS повинен виставити кілька демонів, які працюють на обох сервери і клієнти, до мережевої атаки. В даному розділі розглядаються обставини, при яких можна відключити NFS і його залежностей, а потім Деталі кроки, які слід зробити, щоб забезпечити, наскільки це можливо, конфігурації NFS немає. Цей розділ стосується для машин, що працюють в якості клієнтів NFS, а також для тих, хто працює в якості серверів NFS. 3.13.1 Відключення всіх служб NFS, якщо це можливо Дії, описані в розділі 3.13.1 запобіжить машину від операційної або як клієнт NFS або Сервер NFS. виконувати тільки ці дії на машинах, які не потребують NFS взагалі. Чи є критично важливою причиною для цієї машини працювати або як клієнт NFS або сервер NFS? Якщо немає, то дотримуйтесь інструкцій в частині розділу 3.13.1 для відключення підсистеми, необхідні для NFS. NFS є широко використовуваним механізмом для обміну даними між машинами в організації. Проте, його використання відкриває безліч потенційних дірок в безпеці. Якщо NFS не скрізь потрібно у вашій організації, підвищити безпеку поза будь-якої машини, яка не вимагає NFS, відключивши його повністю. 3.13.1.1 відключення служб Використовується тільки NFS Якщо NFS не потрібно, виконайте наступні кроки, щоб відключити клієнта NFS демонів: 153 # Chkconfig nfslock викл # Chkconfig rpcgssd викл # Chkconfig rpcidmapd викл CCE 4396-8, 3535-2, 3568-3 У nfslock, rpcgssd і rpcidmapd все демони виконують функції клієнта NFS. Всі ці демони запускаються з підвищеними привілеями, і багато прослуховування мережевих підключень. Якщо вони не є необхідно, вони повинні бути відключені для поліпшення стану безпеки системи. 3.13.1.2 Відключити netfs якщо це можливо Визначити, чи є які-небудь мережеві файлові системи, оброблювані netfs встановлені на цій системі: # Кріплення -t, NFS4 Nfs, SMBFS, CIFS, NCPFS Якщо ця команда не повертає вихідний, не вимкнути netfs для підвищення безпеки системи: # Chkconfig netfs викл CCE 4533-6 Netfs сценарій керує завантажувальний час монтажу декількох типів мережевих файлових систем, з яких NFS і Samba (дивіться розділ 3.18) є найбільш поширеними. Якщо ці типи файлових систем не використовуються, то сценарій може бути відключена, захищаючи систему кілька від випадкових або зловмисних змін в / і т.д. / Fstab і проти недоліків в Сам netfs сценарій. 3.13.1.3 Відключити RPC Portmapper якщо це можливо якщо: ?? NFS не потрібно ?? Сайт не використовує NIS для отримання інформації аутентифікації, і ?? Машина не працює будь-якої іншої служби RPC на основі потім відключити службу RPC перетворювача портів: # Chkconfig Portmap викл CCE 4550-0 За дизайном, модель RPC не вимагає особливих послуг для прослуховування на фіксованих портів, але замість цього використовує демон, Portmap, щоб повідомити потенційним клієнтам, які порти використовувати для зв'язку з послугами, які вони намагаються досягти. Ця модель послаблює безпеку системи шляхом введення іншої привілейований демон, який може бути безпосередньо атакований, і не є необхідним, так як RPC ніколи не був прийнятий досить послуг ризикувати, використовуючи всі порти в системі. На жаль, Portmapper займає центральне місце в конструкції RPC, тому він не може бути відключений, якщо ваш сайт за допомогою будь-якого RPCbased послуги, в тому числі NFS, NIS (дивіться розділ 3.2.4 для отримання інформації про NIS, що не рекомендується), або будь-якої третьої стороною або користувальницької програми RPC основі. Якщо жодна з цих програм не використовуються, однак, слід Portmap бути відключена, щоб поліпшити безпеку системи. 154 ГЛАВА 3. ПОСЛУГИ Для того, щоб отримати більше інформації про те, чи може Portmap бути відключені на даному хості, запитувати локальний Portmapper за допомогою команди: # Rpcinfo -p Якщо тільки послуги, перераховані в Portmapper і статус, можна безпечно відключити Portmapper. Якщо інші послуги Перераховані і ваш сайт не працює NFS або NIS, розслідувати ці послуги і відключити їх, якщо це можливо. 3.13.2 Налаштування Всі машини, які використовують NFS Дії, описані в цьому розділі, є придатними для всіх машин, які працюють NFS, чи працюють вони в якості клієнтів або серверів. 3.13.2.1 Зробити Кожна машина клієнта або сервера, а не обидва Якщо NFS необхідно використовувати, він повинен бути розгорнутий в найпростішої конфігурації, щоб уникнути можливої ​​ремонтопридатності проблеми, які можуть привести до зайвого впливу безпеки. Через проблеми надійності та безпеки, викликаних по NFS, це не дуже гарна ідея для машин, які діють в якості серверів NFS також монтування файлових систем за допомогою NFS. Біля Принаймні, перетнула монтує (ситуація, в якій кожен з двох серверів монтує файлову систему з іншого) повинен ніколи не будуть використовуватися. 3.13.2.2 Обмеження доступу до Portmapper Редагування файлу /etc/hosts.deny. Додати або виправити рядок: Portmap: ALL Відредагуйте файл /etc/hosts.allow. Додати або виправити рядок: Portmap: IPADDR1, IPADDR2, ... де кожен IPADDR є IP-адреса сервера або клієнта, з яким ця машина розділяє файлові системи NFS. якщо машина є сервером NFS, може бути простіше використовувати мережевий блок специфікації IP, такі, як 10.3.2. (цей Синтаксис TCP Wrappers, що представляє блок 10.3.2.0/24~~HEAD=dobj), або ім'ям хоста, наприклад, .subdomain.example.com. Використання імен хостів не рекомендується. У /etc/hosts.allow і /etc/hosts.deny файли використовуються TCP Wrappers, щоб визначити, чи є зазначений віддалені хости можуть отримати доступ до певних послуг. Portmapper за замовчуванням поставляється з RHEL5 має TCP Пакувальників, підтримуваних вбудованої, так що ця специфікація може бути використана для забезпечення захисту від мережевих атак на Portmapper. (Дивіться розділ 2.5.4 для отримання додаткової інформації про TCP Wrappers.) Примітка: Цей крок захищає тільки саму послугу Portmap. Це все ще можливо атакуючим вгадати порт номера служб NFS і атакувати ці послуги безпосередньо, навіть якщо їм відмовляють у доступі до Portmapper. 3.13.2.3 Налаштування NFS Services для використання нерухомих портів Відредагуйте файл / і т.д. / sysconfig / NFS. Додати або виправити такі рядки: LOCKD_TCPPORT = lockd-порт LOCKD_UDPPORT = lockd-порт 155 MOUNTD_PORT = Mountd-порт RQUOTAD_PORT = rquotad-порт STATD_PORT = statd-порт STATD_OUTGOING_PORT = statd-вих-порт де кожен X-порт є портом, який не використовується іншими службами в мережі. CCE 4559-1, 4015-4, 3667-3, 4310-9, 4438-8, 3579-0 Firewalling має бути зроблено на кожному хості і на прикордонних брандмауерів, щоб захистити демонів NFS від віддаленого доступ, оскільки сервери NFS ніколи не повинні бути доступні з-за меж організації. Проте, за замовчуванням, Portmapper призначає кожну послугу NFS до порту динамічно під час запуску служби. Динамічні порти не можуть бути під захистом портів фільтрації брандмауерів, таких як Iptables (розділ 2.5.5). Таким чином, обмежують кожну послугу, щоб завжди використовувати заданий порт, так що міжмережевий екран може бути зроблено ефективно. Слід зазначити, що, через спосіб реалізується RPC, не представляється можливим, щоб відключити Portmapper навіть якщо призначені порти статично до всіх служб RPC. 3.13.3 Налаштування NFS Клієнти Дії, описані в цьому розділі, є придатними для машин, які працюють в якості клієнтів NFS. 3.13.3.1 Відключення сервера Демони NFS # Chkconfig від NFS # Chkconfig rpcsvcgssd викл CCE 4473-5, 4491-7 Там немає необхідності запускати демони сервера NFS за винятком невеликого числа машин, забезпечених належним призначеним в якості серверів NFS. Переконайтеся в тому, що ці демони відключені від клієнтів. 3.13.3.2 монтування віддалених файлових систем з обмежувальної Options Відредагуйте файл / і т.д. / Fstab. Для кожної файлової системи, тип (стовпець 3) або NFS4 NFS, додати текст , Nodev, nosuid в список опцій монтування в колонці 4. При необхідності, додати, поехес. CCE 4368-7, 4024-6, 4526-0 Дивіться розділ 2.2.1.2 для опису ефектів цих варіантів. У загальному випадку виконання файлів через NFS монтується слід вважати ризикованим через можливість того, що противник може перехопити запит і замінити шкідливий файл. Дозвіл УИП файли, які будуть виконуватися з віддалених серверів особливо ризиковано, як з цієї причини і тому, що вона вимагає від клієнтів, щоб розширити довіру на рівні кореневого каталогу на сервері NFS. 3.13.4 Налаштування NFS-сервери Дії, описані в цьому розділі, є придатними для машин, що працюють в якості серверів NFS. 156 ГЛАВА 3. ПОСЛУГИ 3.13.4.1 Налаштування експорту файлу обмежувально Реалізація NFS в Linux використовує файл / і т.д. / експорт, щоб контролювати те, що файлові системи і каталоги можуть бути доступ через NFS. (Див експорт (5) сторінок Довідника для отримання додаткової інформації про формат цього файлу.) Синтаксис файлу експорту не обов'язково перевіряється повністю на перезавантаження, і синтаксичні помилки можуть залишити NFS конфігурація більш відкритою, ніж передбачалося. Тому, проявляти обережність при зміні файлу. Синтаксис кожного рядка в / і т.д. / експорту / DIR ipaddr1 (opt1, opt2) ipaddr2 (opt3) де / DIR є каталогом або файлової системи для експорту, ipaddrN є IP-адреса, мережевий блок, ім'я хоста, домена або Netgroup, до якого для експорту, і OPTN варіант. 3.13.4.1.1 Використання Access Lists для Примусово авторизації Обмеження на Mounts Редагувати / і т.д. / експорту. Переконайтеся в тому, що кожна експортна лінія містить набір IP-адрес або хостів, які дозволені Для доступу до цього експорт. Якщо немає IP-адресу або назву не вказані на експорт лінії, то, що експорт доступний для будь-якого віддаленого хоста який просить його. Всі рядки файлу експорту слід вказати хостів (або підмережі, якщо це необхідно), які дозволені щоб отримати доступ до експортованої директорії, так що невідомі або віддалені хости буде відмовлено. 3.13.4.1.2 Використання Root-давлячи на всіх експортних поставок Редагувати / і т.д. / експорту. Переконайтеся в тому, що жоден рядок не містить опцію НЕ кореня сквош. CCE 4544-3 Якщо файлова система експортується за допомогою кореневої вичавлюванні, запити від кореня на стороні клієнта вважаються непривілейованих (Зіставляючи з користувачем, такі як ніхто). Це забезпечує деяку помірну захист від віддаленого зловживання сервера NFS. Корінь давлячи включена за замовчуванням, і не повинні бути відключені. 3.13.4.1.3 Обмеження NFS клієнтів привілейованого портів Редагувати / і т.д. / експорту. Переконайтеся в тому, що жоден рядок не містить опцію небезпечний. CCE 4465-1 За замовчуванням, реалізація NFS в Linux вимагає, щоб всі клієнтські запити будуть зроблені з портів менше ніж 1024. If ваша організація має контроль над машинами, підключеними до своєї мережі, і якщо запити NFS заборонені на прикордонний міжмережевий екран, це дає деякий захист від шкідливих запитів від непривілейованих користувачів. Таким чином, за замовчуванням не повинні змінюватися. 157 3.13.4.1.4 Експорт Файлові тільки для читання якщо це можливо Редагувати / і т.д. / експорту. Переконайтеся в тому, що кожен рядок містить опцію ро і не містить опцію RW, якщо є оперативна потреба в віддалених клієнтів, щоб змінити цю файлову систему. CCE 4350-5 Якщо файлова система експортується, так що користувачі можуть переглядати файли в зручній формі, але немає ніякої необхідності для користувачів, щоб редагувати ці файли, експортувати файлову систему тільки для читання видаляє вектор атаки проти сервера. Режим експорту файлової системи за замовчуванням ро, тому не вказуйте RW без поважної причини. 3.13.4.2 Дозволити Законні Клієнти NFS для доступу до сервера Визначте відповідний мережевий блок, netwk і мережеву маску, маску, що представляє машини на ваша мережа, яка повинна змонтувати NFS файлові системи з цього сервера. Редагувати / і т.д. / sysconfig / Iptables. Додайте наступні рядки, гарантуючи, що вони з'являються перед заключним LOG і DROP лінії для RH-Firewall-1-INPUT ланцюга: -A RH-Firewall-1-INPUT -s netwk / маска -m стан --state NEW -p УДП --dport 111 -j ACCEPT -A RH-Firewall-1-INPUT -s netwk / маска -m стану --state NEW -p TCP --dport 111 -j ACCEPT -A RH-Firewall-1-INPUT -s netwk / маска -m стану --state NEW -p TCP --dport 2049 -j ACCEPT -A RH-Firewall-1-INPUT -s netwk / маска -m стан --state NEW -p TCP --dport lockd-порт -j ACCEPT -A RH-Firewall-1-INPUT -s netwk / маска -m стан --state NEW -p УДП --dport lockd-порт -j ACCEPT -A RH-Firewall-1-INPUT -s netwk / маска -m стан --state NEW -p TCP --dport Mountd-порт -j ACCEPT -A RH-Firewall-1-INPUT -s netwk / маска -m стан --state NEW -p УДП --dport Mountd-порт -j ACCEPT -A RH-Firewall-1-INPUT -s netwk / маска -m стану --state NEW -p TCP --dport rquotad-порт -j ACCEPT -A RH-Firewall-1-INPUT -s netwk / маска -m стан --state NEW -p УДП --dport rquotad-порт -j ACCEPT -A RH-Firewall-1-INPUT -s netwk / маска -m стану --state NEW -p TCP --dport statd-порт -j ACCEPT -A RH-Firewall-1-INPUT -s netwk / маска -m стан --state NEW -p УДП --dport statd-порт -j ACCEPT де змінна номера портів збігаються, обрані в розділі 3.13.2.3 Конфігурація за замовчуванням Iptables не дозволяє вхідного доступу до будь-яких послуг. Ця модифікація дозволить зазначений блок віддалених хостів, щоб ініціювати з'єднання з набором демонів NFS, зберігаючи при цьому всі інші порти на сервері в їх замовчуванням захищене стан. Дивіться розділ 2.5.5 для отримання додаткової інформації про IPTables. 3.14 DNS-сервера Більшість організацій мають оперативну необхідність працювати принаймні один сервер імен. Тим не менш, є багато спільних атаки за участю DNS, бути налаштовані захищаючись. 3.14.1 Відключення DNS-сервера якщо це можливо Чи існує оперативна потреба в цю машину, щоб діяти в якості DNS-сервера для цього сайту? Якщо немає, то відключити програмне забезпечення і видалити його з системи: 158 ГЛАВА 3. ПОСЛУГИ # Chkconfig назвав викл # Ням Стирання зв'язування CCE 3578-2, 4219-2 Програмне забезпечення DNS повинна бути відключена на будь-якому комп'ютері, який не потрібно бути сервером імен. Зверніть увагу, що Програмне забезпечення сервера BIND DNS не встановлено на RHEL5 за замовчуванням. У решти цього розділу обговорюються в безпеці конфігурація машин, які повинні бути неймсервери. 3.14.2 Запустіть BIND9 програмного забезпечення, якщо служба DNS Потрібен Настійно рекомендується, що програмне забезпечення BIND9 використовуватися для надання послуг DNS. BIND є стандартом Інтернет Unix серверів імен, і, в той час як він мав проблеми безпеки в минулому, це також добре підтримується і Red Hat є швидше за все, швидко видавати поновлення у відповідь на будь-які проблеми, виявлені в майбутньому. Крім того, BIND версії 9 має нові функції безпеки і безпечніші настройки за замовчуванням, ніж в попередніх версіях. Зокрема, BIND версії 4 більше не рекомендується для використання у виробництві, а також сервери BIND4 повинні бути оновлені до нової версії, як тільки як можна. 3.14.3 ізолят DNS від інших служб У цьому розділі обговорюються механізми попередження сервера DNS від втручання з іншими службами. Це зроблено як для захисту решта мережі повинна сервер імен бути поставлена ​​під загрозу, і зробити прямий атаки на сервери імен більш важким. 3.14.3.1 Запуск програмного забезпечення DNS на виділених серверах, якщо це можливо Оскільки DNS є службою високого ризику, які часто мають бути зроблені доступними для всього Інтернету, настійно Рекомендується, щоб ніякі інші послуги не будуть запропоновані машинами, які діють в якості організаційних DNS-серверів. 3.14.3.2 Програмне забезпечення Запуск DNS в CHROOT Jail Встановіть пакет зв'язування-CHROOT: # Ням встановити Bind-CHROOT Помістіть дійсний файл named.conf всередині ізольованою середовища в'язниці: # Ф /etc/named.conf /var/named/chroot/etc/named.conf # Чаун корінь: корінь /var/named/chroot/etc/named.conf # CHMOD 644 /var/named/chroot/etc/named.conf Створення і заповнення відповідного каталогу зони в тюрмі, на підставі директиви опцій. Якщо ти named.conf включає в себе: параметри { директорія "/ шлях / до / DIRNAME"; ... } 159 потім скопіювати цей каталог і його вміст з вихідної директорії зони: # Ф -r / шлях / до / DIRNAME / вар / імені / кореневих / DIRNAME Відредагуйте файл / і т.д. / sysconfig / імені. Додати або виправити рядок: ROOTDIR = / вар / імені / кореневих CCE 3985-9, 4487-5, 4258-0 CHROOT Тюрми не є надійними. Проте, вони служать, щоб зробити його більш важким для скомпрометовані програми буде використовується для атаки весь вузол. Вони роблять це за рахунок обмеження здатності програми для обходу каталогу вгору, так що файли за межами тюрми не видно в процесі кореневого каталогу. Оскільки RHEL5 підтримує стандартний механізм для розміщення BIND в CHROOT в'язниці, ви повинні скористатися цією функцією. Примітка: Якщо ви працюєте в BIND в CHROOT в'язниці, то ви повинні використовувати в'язницю named.conf в якості основного конфігураційний файл сервера імен. Тобто, коли це керівництво рекомендує для редагування /etc/named.conf, вам необхідно замість того, щоб редагувати /var/named/chroot/etc/named.conf. 3.14.3.3 настройки брандмауерів, щоб захистити DNS-сервер Відредагуйте файл / і т.д. / sysconfig / IPTables. Додайте наступні рядки, гарантуючи, що вони з'являються перед остаточним LOG і DROP лінії для RH-Firewall-1-INPUT ланцюга: -A RH-Firewall-1-INPUT -m стан --state NEW -p УДП --dport 53 -j ACCEPT -A RH-Firewall-1-INPUT -m стан --state NEW -p TCP --dport 53 -j ACCEPT Ці рядки необхідні для того, щоб дозволити віддаленим комп'ютерам звертатися до сервера DNS. Якщо цей сервер тільки доступні в локальній мережі, може бути доцільним, щоб вставити прапора -s в це правило, щоб дозволити трафік тільки з пакетів в локальній мережі. Дивіться Розділ 3.5.1.2 для прикладу такої модифікації. Дивіться розділ 2.5.5 для отримання загальної інформації про IPTables. 3.14.4 Захист даних DNS від несанкціонованого доступу або атаки У цьому розділі розглядаються параметри конфігурації DNS, які роблять його більш важким для зловмисникам отримати доступ до особисті дані DNS або змінювати дані DNS. 3.14.4.1 Run Окремий DNS-сервери для зовнішніх і внутрішніх запитів, якщо це можливо Чи можна запускати зовнішні і внутрішні сервери імен на окремих машинах? Якщо це так, виконайте конфігурацію вказівки в цьому розділі. Якщо немає, то дивіться Розділ 3.14.4.2 для альтернативного підходу з використанням BIND9. На зовнішньому сервері імен, редагувати /etc/named.conf. Додати або виправити такі директиви: параметри { дозволити-запит {будь; }; НЕ рекурсії немає; ... }; 160 ГЛАВА 3. ПОСЛУГИ Зона "example.com" IN { ... }; На внутрішньому сервері імен, редагувати /etc/named.conf. Додати або виправити такі директиви, де SUBNET це числове уявлення IP вашої організації у вигляді xxx.xxx.xxx.xxx/xx~~pobj: Внутрішня {ACL SUBNET; локальний; }; параметри { дозволити-запит {внутрішній; }; ... }; зона "internal.example.com" IN { ... }; Підприємство неймсервери як правило, виконують дві функції. Одним з них є надати громадськості інформацію про машинах в домені в інтересах зовнішніх користувачів, які хотіли б зв'язатися з цими машинами, наприклад, для того, щоб відправити пошту для користувачів на підприємстві, або відвідати веб-сторінку зовнішнього підприємства. Інший полягає в наданні для служби імен клієнтські машини в межах підприємства. Клієнтські машини вимагають як приватної інформації про корпоративних машинах (Який може відрізнятися від публічної інформації подається до іншої частини світу) і публічної інформації про машини за межами підприємства, який використовується для відправки пошти або відвідувати веб-сайти за межами організації. Для того, щоб забезпечити функцію суспільної служби імен, необхідно обмінюватися даними з ненадійними машинами, які запросити його - в іншому випадку, підприємство не може бути зручно зв'язатися з зовнішніми користувачами. Проте, внутрішні дані повинні бути захищені від розголошення, і служить нерелевантні запити громадськості імен для зовнішніх доменів залишає DNS-сервер з відкритим отруєнням кешу і інших атак. Таким чином, локальні функції імен мережевий повинен не надавати ненадійних машин. Окремі машини повинні бути використані для заповнення цих двох функцій, коли це можливо. 3.14.4.2 використовувати уявлення для створення розділів зовнішньої і внутрішньої інформації, якщо це необхідно Якщо це не представляється можливим запускати зовнішні і внутрішні сервери імен на окремих фізичних машинах, запустіть BIND9 і імітувати цю функцію за допомогою уявлень. Редагування /etc/named.conf. Додати або виправити такі директиви (де під сіть чисельне представлення IP Вашої організації у вигляді xxx.xxx.xxx.xxx/xx~~pobj): Внутрішня {ACL SUBNET; локальний; }; вид "внутрішнього зору" { матч-клієнти {внутрішній; }; 161 зона "." В { введіть підказку; файл "db.cache"; }; зона "internal.example.com" IN { ... }; }; вид "зовнішнього вигляду" { матч-клієнти {будь; }; НЕ рекурсії немає; Зона "example.com" IN { ... }; }; Функція зору забезпечується bind9 як спосіб дозволити одного сервера імен, щоб зробити різні набори даних доступні для різних наборів клієнтів. Якщо це можливо, завжди краще запускати зовнішні і внутрішні сервери імен на окремі машини, так що навіть повний компроміс зовнішнього сервера, не може бути використаний для отримання внутрішнього дані або заплутати внутрішніх клієнтів DNS. Тим не менш, це не завжди можливо, і використання функції як поглядів переважно залишаючи внутрішні дані DNS повністю незахищеним. Примітка: Як показано в прикладі, файли бази даних, які потрібні для рекурсії, наприклад, файл кореневих посилань, повинні бути доступні всім клієнтам, які дозволили зробити рекурсивні запити. У типових випадках, це включає в себе тільки внутрішні клієнти, яким дозволено використовувати цей сервер в якості загального призначення імен. 3.14.4.3 Відключити зони Трансфери від сервера імен, якщо це можливо Чи необхідно вторинний сервер імен, щоб отримати дані зони за допомогою передачі зони від первинного сервера? Якщо немає, то виконайте вказівки в даному розділі. Якщо це так, зверніться до відповідного розділу для отримання інструкцій щодо захисту зони переклади. Редагування /etc/named.conf. Додати або виправити таку директиву: параметри { дозволити передачу- {немає; }; ... } Якщо обидва первинний і вторинний сервер імен знаходяться під вашим контролем, або якщо у вас є тільки один сервер імен, він може можна використовувати зовнішній механізм управління конфігурацією для розповсюдження оновлень зони. У цьому випадку, це не потрібно, щоб дозволити передачу зон всередині самої BIND, тому вони повинні бути відключені, щоб уникнути можливості для зловживання. 162 ГЛАВА 3. ПОСЛУГИ 3.14.4.4 аутентифицироваться зона Переклади, якщо необхідно Якщо це необхідно для вторинного сервера імен для прийому даних зони за допомогою передачі зони від первинного сервера, дотримуйтесь інструкцій тут. Використовуйте DNSSEC-кейгена створити симетричний ключ файл в поточному каталозі: # CD / TMP # DNSSEC-серійник -a HMAC-MD5 -b 128 -n HOST dns.example.com Kdns.example.com. + Ааа + IIIII Цей висновок є ім'я файлу, що містить новий ключ. Прочитайте файл, щоб знайти ключовий рядок в кодуванні base64: # Кішка Kdns.example.com. + NNN + МММММ .key dns.example.com IN KEY 512 3 157 base64 ключа-рядки Редагування /etc/named.conf на первинному сервері імен. Додайте директиви: ключовий зони перенесення ключа { алгоритм HMAC-md5; секрет "base64-ключ-рядок"; }; Зона "example.com" IN { типу майстра; дозволити передачу- {ключ-зона-передачі ключів; }; ... } Редагування /etc/named.conf на вторинному сервері імен. Додайте директиви: ключовий зони перенесення ключа { алгоритм HMAC-md5; секрет "base64-ключ-рядок"; }; Сервер IP-OF-MASTER { Клавіші {Зона перенесення ключа; }; }; Зона "example.com" IN { тип раба; майстра {IP-OF-MASTER; }; ... }; Підпис BIND транзакцій (TSIG) функціональні можливості дозволяють первинні і вторинні сервери імен використовувати спільно Секрет для перевірки авторизації для виконання передачі зони. Цей метод є більш безпечним, ніж при використанні IP на основі обмеження для обмеження доступу сервера імен, оскільки IP-адреси можуть бути легко підробити. Проте, якщо ви не можете налаштувати TSIG між серверами, так як, наприклад, вторинний сервер імен НЕ під вашим контролем і його адміністратори не хочуть, щоб налаштувати TSIG, ви можете налаштувати передачу-дозволу Директива з числовими IP-адрес або списків управління доступом як в крайньому випадку. Примітка: Призначення команди DNSSEC-Keygen, щоб створити загальний секретний ключ рядки base64 ключ-рядок. Після того, як цей секрет був отриманий і вставляється в named.conf на первинному і вторинному серверах, ключ 163 файли Kdns.example.com. + Не NNN + МММММ .key і Kdns.example.com. + NNN + МММММ .private більше не потрібні, і може бути безпечно видалені. 3.14.4.5 Відключити динамічних оновлень якщо це можливо Чи є критично важливі причини для того, щоб ризиковану динамічну функціональність оновлення? Якщо ні: Редагування /etc/named.conf. Для кожної специфікації зони, виправити таку директиву, якщо це необхідно: Зона "example.com" IN { дозволити обновленіе- {немає; }; ... } CCE 4399-2 Динамічні поновлення дозволяють віддалених серверів додавати, видаляти або змінювати будь-які записи в файлі зони. Таким чином, вони слід вважати досить ризикованим, і інвалідів, якщо не буде дуже хороша причина для їх використання. Якщо динамічні оновлення повинні бути дозволені, заснованих на IP-списки управління доступом є недостатній захист, так як вони легко підробити. Замість цього використовуйте клавіші TSIG (дивіться попередній розділ для прикладу), а також розглянути питання про використання директиви поновлення-політики обмежити зміни тільки точний тип необхідних змін. 3.15 FTP-сервер FTP є поширеним методом для забезпечення можливості віддаленого доступу до файлів. Як і Telnet, протокол FTP передається в незашифрованому вигляді, Це означає, що паролі та інші дані, що передаються під час сеансу можуть бути захоплені і що сесії є вразливим для атак зловмисників. Таким чином, запуск програмного забезпечення сервера FTP не рекомендується. Проте, існують деякі сервера FTP-конфігурації, які можуть бути придатними для деяких середовищ, зокрема, ті, які допускають тільки для читання тільки анонімний доступ як засіб завантаження даних, доступних для громадськості. 3.15.1 Відключити VSFTPD якщо це можливо Чи є критично важливою причиною для машини, щоб діяти в якості FTP-сервера? Якщо немає, то відключити програмне забезпечення і видалити його з системи: # Chkconfig VSFTPD викл # Ням Стирання Vsftpd CCE 3919-8, 14881-7 3.15.2 Використання VSFTPD для того щоб забезпечити службу FTP, якщо це необхідно Якщо ця машина повинна працювати в якості FTP-сервера, встановіть пакет VSFTPD через стандартні канали: # Ням встановити VSFTPD 164 ГЛАВА 3. ПОСЛУГИ Після того, як RHEL 2.1, Red Hat перейшли від поширення wu-ftpd з RHEL в поширенні Vsftpd. З метою забезпечення безпеки і для забезпечення узгодженості з майбутніми Red Hat релізів, рекомендується використання VSFTPD. 3.15.3 Налаштування VSFTPD Щільно Файл первинної конфігурації Vsftpd є /etc/vsftpd.conf, якщо цей файл існує, або якщо /etc/vsftpd/vsftpd.conf це не. Протягом решти цього розділу, фраза "конфігураційний файл" буде ставитися до залежності від того, з тих, Файли підходить для вашої середовища. 3.15.3.1 Включити запис всіх FTP-операцій Редагування файлу конфігурації Vsftpd. Додати або виправити такі параметри конфігурації: xferlog_std_format = NO log_ftp_protocol = YES CCE 4549-2 Модифікації вище переконайтеся, що всі команди, відправлені на сервер FTP реєструються за допомогою докладного журналу VSFTPD формат. Файл журналу Vsftpd за замовчуванням /var/log/vsftpd.log. Примітка: Якщо докладний ведення журналу в vsftpd.log робиться, розріджене протоколювання завантаження в / Var / Журнал / xferlog НЕ буде також статися. Проте, інформація про те, що були завантажені файли включені в інформацію, записану в vsftpd.log. 3.15.3.2 Створення банерів Попередження для всіх користувачів FTP Редагування файлу конфігурації Vsftpd. Додати або виправити такі параметри конфігурації: banner_file = / і т.д. / питання CCE 4554-2 Дивіться Розділ 2.3.7 для пояснення використання банера файлу. Цей параметр змусить систему вітання банер буде використовується для FTP-з'єднань, а також. 3.15.3.3 обмежити набір користувачів, яким дозволений доступ FTP У цьому розділі описується, як відключити неанонімна (на основі пароля) FTP логіни, або, якщо це не представляється можливим зробити це повністю через застарілі додатків, як обмежити небезпечні FTP логін тільки тих користувачів, у яких є визначили необхідність цього доступу. 3.15.3.3.1 Обмеження доступу для анонімних користувачів, якщо це можливо Чи є критично важливою причиною для користувачів для передачі файлів в / з своїх власних рахунків за допомогою FTP, а не використовуючи захищений протокол, як SCP / SFTP? Якщо ні: Редагування файлу конфігурації Vsftpd. Додати або виправити наступний параметр конфігурації: 165 local_enable = NO Якщо не анонімні FTP логіни необхідні, дотримуйтесь вказівок в решти цього розділу, щоб забезпечити ці логіни якомога більше. CCE 4443-8 Використання неанонімних FTP логінів настійно не рекомендується. Оскільки SSH клієнти і сервери широко доступні, і так як SSH забезпечує підтримку режиму передачі, який нагадує FTP в інтерфейсі, немає нічого хорошого Причина, щоб на основі пароля доступу до FTP. Дивіться розділ 3.5 для отримання додаткової інформації про SSH. 3.15.3.3.2 Обмеження користувачів, яким дозволений доступ по FTP, якщо це необхідно Якщо є критично важливі причини для користувачів, щоб отримати доступ до своїх рахунків через незахищене протоколу FTP, обмежити набір користувачів, які можуть цей доступ. Редагування файлу конфігурації Vsftpd. Додати або виправити такі параметри конфігурації: userlist_enable = YES userlist_file = / і т.д. / vsftp.ftpusers userlist_deny = NO Редагування файлу /etc/vsftp.ftpusers. Для кожного користувача USERNAME, який повинен бути дозволений доступ до системи за допомогою FTP, додайте рядок, що містить ім'я цього користувача. USERNAME Якщо анонімний доступ також потрібно, додайте анонімні імена користувачів до /etc/vsftp.ftpusers, а також: анонімний FTP Історично склалося так, що файл / і т.д. / ftpusers міститься список користувачів, яким не дозволено доступ до системи через FTP. Він був використаний для запобігання системних користувачів, таких як користувач кореня від входу в систему через незахищену протоколу FTP. Однак, коли параметр конфігурації USERLIST заперечую = NO встановлено, Vsftpd інтерпретує ftpusers як безліч користувачів які можуть увійти через FTP. Так як це повинно бути можливим для більшості користувачів, щоб отримати доступ до своїх рахунків за допомогою безпечної протоколи, рекомендується використовувати цей параметр, так що не анонімний доступ FTP може бути обмежена спадщиною користувачі, які були явно визначені. 3.15.3.4 Відключення завантаження на FTP, якщо це можливо Чи є критично важливою причиною для користувачів, щоб завантажити файли через FTP? Якщо ні: Редагування файлу конфігурації Vsftpd. Додати або виправити такі параметри конфігурації: write_enable = NO Якщо FTP завантаження необхідні, дотримуйтесь вказівок в решти цього розділу, щоб забезпечити ці транзакції так багато, як тільки можливо. CCE 4461-0 166 ГЛАВА 3. ПОСЛУГИ Анонімний FTP може бути зручним способом, щоб зробити файли доступними для загального скачування. Проте, він менш часто мають потребу дозволити нерозпізнаних користувачам розміщувати файли на FTP-сервері. Якщо це має бути зроблено, необхідно переконатися, що файли не можуть бути завантажені і завантажені з того ж каталогу. 3.15.3.5 Помістіть FTP домашній каталог на свій власний розділ За замовчуванням, корінь анонімного FTP є домашній каталог облікового запису FTP користувача. Команда DF може використовуватися для перевірки того, що цей каталог в окремому розділі. Якщо є критично важливою причиною для анонімних користувачів, щоб завантажити файли, повинні бути вжиті заходи для запобігання ці користувачі від заповнення диска використовується іншими службами. 3.15.3.6 настройки брандмауерів, щоб захистити FTP-сервер Відредагуйте файл / і т.д. / sysconfig / IPTables. Додайте наступні рядки, гарантуючи, що вони з'являються перед остаточним LOG і DROP лінії для RH-Firewall-1-INPUT ланцюга: -A RH-Firewall-1-INPUT -m стан --state NEW -p TCP --dport 21 -j ACCEPT Відредагуйте файл / і т.д. / sysconfig / IPTables-конфігурації. Переконайтеся в тому, що розділений пробілами список модулів містить модуль FTP відстеження з'єднання: IPTABLES_MODULES = "ip_conntrack_ftp" Ці параметри налаштування IPTables, щоб дозволити з'єднання на FTP-сервер. Перший рядок дозволяє початкові підключення до порту сервера FTP. FTP це старий протокол, який не дуже сумісні з міжмережевими екранами. В ході первинного FTP діалогу, клієнт і сервер домовляються довільний порт, який повинен використовуватися для передачі даних. Модуль IP трасувальника FTP використовується Iptables, щоб слухати цей діалог і дозволити підключення до портів даних, які веде переговори FTP. це дозволяє FTP-сервер для роботи на машині, яка працює брандмауер. 3.16 Веб-сервер Веб-сервер відповідає за надання доступу до контенту по протоколу HTTP. Веб-сервери представл ють собою Ризик значні обсяги цінних паперів, так як: ?? Порт HTTP зазвичай зондується шкідливих джерел ?? Програмне забезпечення веб-сервера є дуже складним, і включає в себе довгу історію вразливостей ?? Протокол HTTP не зашифровано і уразливі для пасивного моніторингу Програмне забезпечення веб-сервер системи за умовчанням Apache 2 і надається в пакеті RPM HTTPD. 3.16.1 Відключити Apache якщо це можливо Якщо був встановлений Apache і активований, але система не повинна виступати в якості веб-сервера, то він повинен бути відключені і видалені з системи: 167 # Chkconfig HTTPD викл # Ням Стирання HTTPD CCE 4338-0, 4514-6 3.16.2 Установка Apache, якщо необхідно Якщо веб-сервер Apache повинен бути запущений, дотримуйтесь цих вказівок, щоб встановити його, захищаючись. Потім дотримуйтесь інструкцій в решти розділу 3.16 для настройки машини і програмного забезпечення з веб-сервера, як надійно, як це можливо. 3.16.2.1 Установка Apache Software Безпечне Встановіть пакет Apache 2 з стандартного каналу розподілу Red Hat: # Ням встановити HTTPD CCE 4346-3 Примітка: Цей метод установки рекомендується встановлювати над "Веб-сервер" групи пакетів під час Системний процес установки. Пакет веб-сервера група включає в себе безліч пакетів, які, ймовірно, сторонній, в той час як метод командного рядка встановлює тільки необхідний HTTPd сам пакет. 3.16.2.2 Підтвердження Мінімальний вбудовані модулі Установка Apache за замовчуванням мінімізує кількість модулів, які компілюються безпосередньо в довічним (Ядро ядро ​​PreFork HTTP мод так). Це зводить до мінімуму ризик, обмежуючи можливості, дозволені веб-сервером. Запит набір скомпільованих модулів за допомогою наступної команди: $ HTTPD -l Якщо кількість скомпільованих модулів значно більше, ніж вищезгаданий набір, це керівництво рекомендує reinstallating Apache зі зменшеною конфігурації. 3.16.3 Закріпити Конфігурація Apache Файл конфігурації Apache є /etc/httpd/conf/httpd.conf. Застосування рекомендацій в залишилася даного розділу до цього файлу. 3.16.3.1 Обмеження витоку інформації У ServerTokens і директиви ServerSignature визначити, який обсяг інформації розкриває веб-сервер про конфігурацію системи. ServerTokens Prod обмежує інформацію в заголовках сторінок, повертаючи тільки слово "Апач". ServerSignature Off продовжує Apache відображати версію сервера на сторінках помилок. це є хорошою практикою безпеки для обмеження інформації, що надається клієнтам. 168 ГЛАВА 3. ПОСЛУГИ Додати або виправити такі директиви в /etc/httpd/conf/httpd.conf так що, як мало інформації, як можливо випущений: ServerTokens Prod ServerSignature Off CCE 4474-3, 3756-4 3.16.3.2 Мінімізація завантажувані модулі 3.16.3.2 Мінімізація завантажувані модулі За замовчуванням установка Apache включає в себе безліч "динамічно поділюваних об'єктів" (DSO), які завантажуються в під час виконання програми. На відміну від вищезгаданих "скомпільованих" модулів, ЦКШ можна відключити в файлі конфігурації, видаливши відповідну директиву LoadModule. Примітка: DSO тільки забезпечує додаткові функціональні можливості, якщо відповідні директиви включені в конфігурацію Apache файл. Слід також зазначити, що видалення DSO буде виробляти помилки при запуску Apache, якщо конфігурація Файл містить директиви, які звертаються до цього модулю. Зверніться до http://httpd.apache.org/docs/ Детальну інформацію про які директиви пов'язані з кожним DSO. Слідуйте за кожен видалення DSO, конфігурація може бути перевірена за допомогою наступної команди, щоб перевірити, чи все до сих пір працює: # Сервіс HTTPD configtest Мета кожного з модулів, завантажених за замовчуванням тепер будуть розглянуті по одному за раз. Якщо жоден з модуля-х директиви використовуються, видаліть його. 3.16.3.2.1 модулі Apache Основні Ці модулі включають в себе базове підмножина модулів, які, ймовірно, необхідні для базової функціональності Apache; гарантувати, що вони не коментуються в /etc/httpd/conf/httpd.conf: LoadModule auth_basic_module модулі / mod_auth_basic.so LoadModule authn_default_module модулі / mod_authn_default.so LoadModule authz_host_module модулі / mod_authz_host.so LoadModule authz_user_module модулі / mod_authz_user.so LoadModule authz_groupfile_module модулі / mod_authz_groupfile.so LoadModule authz_default_module модулі / mod_authz_default.so LoadModule log_config_module модулі / mod_log_config.so LoadModule logio_module модулі / mod_logio.so LoadModule setenvif_module модулі / mod_setenvif.so LoadModule mime_module модулі / mod_mome.so LoadModule autoindex_module модулі / mod_autoindex.so LoadModule negotiation_module модулі / mod_negotiation.so LoadModule dir_module модулі / mod_dir.so LoadModule alias_module модулі / mod_alias.so 3.16.3.2.2 HTTP Basic Authentication Наступні модулі необхідні, якщо цей веб-сервер буде надавати контент, який буде обмежений паролем. 169 Аутентифікація може бути виконана з використанням локальних файлів паролів відкритим текстом (AuthN файлів), локальний DBM пароль файли (AuthN DBM) або каталогів LDAP (дивіться розділ 3.16.3.2.5). Єдиний модуль потрібно веб-сервером залежить від вашого вибору аутентифікації. Закоментуйте модулі вам не потрібні виберіть із наведеного нижче: LoadModule authn_file_module модулі / mod_authn_file.so LoadModule authn_dbm_module модулі / mod_authn_dbm.so AuthN псевдонім дозволяє для перевірки справжності на основі псевдонімів. AuthN Anon дозволяє анонімно аутентифікації, аналогічне щоб у анонімних серверів. Власник AuthZ дозволяє авторизацію на основі права власності файлу. AuthZ дБмВт дозволяє для авторизації на основі членства в групі, якщо веб-сервер використовує аутентифікацію DBM. Якщо вище функціональність не потрібно, закоментуйте пов'язаний модуль: #LoadModule Authn_alias_module модулі / mod_authn_alias.so #LoadModule Authn_anon_module модулі / mod_authn_anon.so #LoadModule Authz_owner_module модулі / mod_authz_owner.so #LoadModule Authz_dbm_module модулі / mod_authz_dbm.so 3.16.3.2.3 HTTP Digest аутентифікації Цей модуль забезпечує шифровані сеанси аутентифікації. Проте, цей модуль використовується рідко і вважається експериментальним. Альтернативні методи зашифрованою аутентифікації рекомендується, наприклад, як SSL (розділ 3.16.4.1) Якщо вище функціональність не потрібно, закоментуйте пов'язаний модуль: #LoadModule Auth_digest_module модулі / mod_auth_digest.so 3.16.3.2.4 мод переписаний Мод модуль переписування є дуже потужним і може захистити від деяких класів веб-атак. Проте, також дуже складна і має значну історію самої уразливості. Якщо вище функціональність не потрібно, закоментуйте пов'язаний модуль: #LoadModule Rewrite_module модулі / mod_rewrite.so 3.16.3.2.5 LDAP Підтримка Цей модуль забезпечує аутентифікацію HTTP за допомогою каталогу LDAP. Якщо вище функціональність не потрібно, закоментуйте відповідні модулі: #LoadModule Ldap_module модулі / mod_ldap.so #LoadModule Authnz_ldap_module модулі / mod_authnz_ldap.so Якщо LDAP повинен використовуватися, SSL-шифрування (Розділ 3.16.4.1) слід використовувати в якості добре. 170 ГЛАВА 3. ПОСЛУГИ 3.16.3.2.6 Server Side Включає Серверні включення забезпечує спосіб динамічної генерації веб-сторінок шляхом включення на стороні сервера код. Проте, ця технологія також вважається застарілим і вводить значні побоювання щодо безпеки. Якщо вище функціональність не потрібно, закоментуйте пов'язаний модуль: #LoadModule Include_module модулі / mod_include.so Якщо є гостра необхідність в Server Side Включає, вони повинні бути включені з опцією IncludesNOEXEC щоб запобігти виконанню довільного коду. Крім того, поставляється призначені для користувача дані повинні бути закодовані, щоб запобігти перехресне сайт сценаріїв уразливості. 3.16.3.2.7 MIME магії Цей модуль забезпечує другий рівень підтримки MIME, що в більшості конфігурацій, ймовірно, сторонній. Якщо вище функціональність не потрібно, закоментуйте пов'язаний модуль: #LoadModule Mime_magic_module модулі / mod_mime_magic.so 3.16.3.2.8 WebDAV (Distributed Authoring і Versioning) WebDAV є розширенням протоколу HTTP, який забезпечує розподілену і спільний доступ до веб-контенту. Через низку проблем в області безпеки за допомогою WebDAV, його використання не рекомендується. Якщо вище функціональність не потрібно, закоментуйте відповідні модулі: #LoadModule Dav_module модулі / mod_dav.so #LoadModule Dav_fs_module модулі / mod_dav_fs.so Якщо є гостра необхідність в WebDAV, особливу обережність слід приймати у своїй конфігурації. Оскільки доступ DAV дозволяє віддалені клієнти для роботи з файлами сервера, будь-яке місце на сервері, який включений DAV повинна бути захищена зашифрована аутентифікація. 3.16.3.2.9 Статус сервера Активність Цей модуль забезпечує доступ в реальному часі до статистичної інформації про внутрішню роботу веб-сервера. це непотрібної витоку інформації і повинні бути відключені. Якщо вище функціональність не потрібно, закоментуйте пов'язаний модуль: #LoadModule Status_module модулі / mod_status.so Якщо є гостра необхідність в цьому модулі, переконайтеся, що доступ до сторінки стану належним чином обмежується обмеженим безліч хостів в конфігурації обробника стану. 171 3.16.3.2.10 Web Display Конфігурація сервера Цей модуль створює веб-сторінки, яка ілюструє конфігурацію веб-сервера. Це непотрібна безпеку витоку і повинні бути відключені. Якщо вище функціональність не потрібно, закоментуйте пов'язаний модуль: #LoadModule Info_module модулі / mod_info.so Якщо є гостра необхідність в цьому модулі, використовуйте директиву про місцезнаходження, щоб надати список контролю доступу, щоб обмежити Доступ до інформації. 3.16.3.2.11 URL Корекція на орфографічною помилкою записів Цей модуль намагається знайти відповідність документа, дозволяючи одному помилками в іншому випадку необробленого запиту. Якщо вище функціональність не потрібно, закоментуйте пов'язаний модуль: #LoadModule Speling_module модулі / mod_speling.so Ця функція послаблює безпеку сервера шляхом перерахування сайту простіше. 3.16.3.2.12 Користувальницькі каталоги Директива UserDir надає користувачеві конкретного перекладу каталогів, дозволяючи URL-адреси, засновані на пов'язаних з іменами користувачів. Якщо вище функціональність не потрібно, закоментуйте пов'язаний модуль: #LoadModule Userdir_module модулі / mod_userdir.so Якщо є гостра необхідність в цьому модулі, включають в себе лінії UserDir відключив корінь (як мінімум) в конфігураційний файл. В ідеалі, UserDir повинен бути відключений, а потім включений на індивідуальній основі випадку для конкретних користувачів які вимагають такої функціональності. Примітка: користувачі веб-сервері може бути тривіально перераховуються за допомогою цього модуля. 3.16.3.2.13 Підтримка проксі Цей модуль забезпечує підтримку проксінг, що дозволяє Apache перенаправляти запити і служити в якості шлюзу для іншої серверів. Якщо вище функціональність не потрібно, закоментуйте відповідні модулі: #LoadModule Proxy_module модулі / mod_proxy.so #LoadModule Proxy_balancer_module модулі / mod_proxy_balancer.so #LoadModule Proxy_ftp_module модулі / mod_proxy_ftp.so #LoadModule Proxy_http_module модулі / mod_proxy_http.so #LoadModule Proxy_connect_module модулі / mod_proxy_connect.so 172 ГЛАВА 3. ПОСЛУГИ Якщо підтримка проксі потрібно, навантаження проксі і відповідний проксі-модуль обробника протоколу (один з проксі HTTP, проксі FTP, або проксі підключитися). Крім того, переконайтеся, що сервер є безпечним перед включенням проксінг, а відкриті проксі-сервери є загрозою безпеки. Проксі-балансир дозволяє балансування навантаження, але вимагає, щоб статус мод буде включений. Оскільки статус мод не рекомендується, проксі-балансир слід уникати, а також. Підтримка 3.16.3.2.14 Cache Цей модуль дозволяє Apache для кешування даних, оптимізації доступу до найбільш часто зверталися зміст. Тим не менш, не тільки це експериментальний модуль, але він також вводить потенційні недоліки безпеки в веб-сервера, такі, як можливість обходу Дозволити і Заборонити директиви. Якщо вище функціональність не потрібно, закоментуйте відповідні модулі: #LoadModule Cache_module модулі / mod_cache.so #LoadModule Disk_cache_module модулі / mod_disk_cache.so #LoadModule File_cache_module модулі / mod_file_cache.so #LoadModule Mem_cache_module модулі / mod_mem_cache.so Якщо потрібно кешування, воно не повинно бути включено для будь-якого контенту з обмеженим доступом. 3.16.3.2.15 CGI підтримки (і пов'язаної з ними модулі) Цей модуль дозволяє HTML взаємодіяти з мовою веб-програмування CGI. Якщо вище функціональність не потрібно, закоментуйте відповідні модулі: #LoadModule Cgi_module модулі / mod_cgi.so #LoadModule Env_module модулі / mod_env.so #LoadModule Actions_module модулі / mod_actions.so #LoadModule Suexec_module модулі / mod_suexec.so Якщо веб-сервер вимагає використання CGI, включите модуль CGI. Якщо ви бажаєте покращити функціональність CGI, включають в себе відповідні модулі. ENV дозволяє контролювати навколишнє середовище передається CGI скриптів. дії CGI дозволяє подіям бути викликана, коли файли певного типу просять. су Exec дозволяє CGI скрипти для запуску як певного користувача / групи, а не в якості сервера користувача / групи. 3.16.3.2.16 Різні додаткові компоненти Наступні модулі виконують дуже специфічні завдання, іноді надаючи доступ до лише кілька додаткових директиви. Якщо ця функція не потрібна (або, якщо ви не використовуєте ці директиви), закоментуйте пов'язаний модуль: ?? Зовнішня фільтрація (реакція проходить через зовнішню програму перед поставкою клієнта) #LoadModule Ext_filter_module модулі / mod_ext_filter.so ?? Заданий користувачем управління кешем та закінчення терміну дії #LoadModule Expires_module модулі / mod_expires.so 173 ?? Стиснення Вихідний фільтр (забезпечує стиснення контенту до доставки клієнта) #LoadModule Deflate_module модулі / mod_deflate.so ?? HTTP Response / заголовка запиту Налаштування #LoadModule Headers_module модулі / mod_headers.so ?? моніторинг активності користувачів через кукі #LoadModule Usertrack_module модулі / mod_usertrack.so ?? Динамічно налаштоване масовий віртуальний хостинг #LoadModule Vhost_alias_module модулі / mod_vhost_alias.so 3.16.3.3 Мінімізувати файлів конфігурації Включено Включити директива наказує Apache, щоб завантажити додаткові файли конфігурації з наданого шляху. Значення за замовчуванням конфігурації завантажує всі файли, які закінчуються на .conf з каталогу /etc/httpd/conf.d. Щоб обмежити надмірну конфігурацію, наступний рядок має бути закоментований і замінені Включити директиви, які тільки посилання необхідні конфігураційні файли: #Include Conf.d / *. Конф Якщо вищевказане зміна було зроблено, переконайтеся, що шифрування SSL залишається завантаженим явно включаючи відповідний конфігураційний файл: (дивіться розділ 3.16.4.1 для отримання більш докладної інформації про конфігурацію SSL) Включити conf.d / ssl.conf Якщо PHP необхідно, аналогічне зміна має бути зроблено: (дивіться розділ 3.16.4.4.1 для отримання більш докладної інформації про PHP конфігурація) Включити conf.d / php.conf 3.16.3.4 Обмеження Каталог Теги каталогів в файлі конфігурації веб-сервера дозволяють тонкоуровневого контроль доступу для зазначеного каталогу. Всі веб-каталоги повинні бути налаштовані на індивідуальній основі випадку, дозволяючи доступ тільки там, де це необхідно. 3.16.3.4.1 Обмеження кореневого каталогу Кореневої каталог Apache завжди потрібно включити найбільш обмежувальний конфігурації. Опції не Відсутня НЕ AllowOverride None Замовлення дозволити, заборонити 174 ГЛАВА 3. ПОСЛУГИ 3.16.3.4.2 Обмежити веб-каталог Конфігурація за замовчуванням для мережі (/ Var / WWW / HTML) Довідник дозволяє каталогу індексації (індекси) і слідуючи символічних посилань (FollowSymLinks). Жоден з них рекомендується. Ієрархія каталогів / Var / WWW / HTML не повинні бути доступні для перегляду через Інтернет, а також символічні посилання повинні бути тільки а потім, якщо власник лінк також володіє пов'язаний файл. Переконайтеся в тому, що ця політика прив'язана до змінюючи відповідний розділ конфігурації: # ... варіанти SymLinksIfOwnerMatch # ... 3.16.3.4.3 Обмеження інших критичних каталогів Всі доступні веб-каталоги повинні бути налаштовані з подібними обмежувальними параметрами. Директива варіанти повинні обмежується необхідною функціональністю і директива AllowOverride повинна використовуватися тільки в разі потреби. Замовлення і заборонити теги контролю доступу слід використовувати для заборони доступу за замовчуванням, дозволяючи доступ тільки в разі потреби. 3.16.3.5 Налаштування перевірки автентичності, якщо є Звичайна перевірка справжності обробляється в незашифрованому вигляді по мережі. Таким чином, всі спроби входу є уразливі для перехоплення пароля. Для підвищення рівня захисту від пасивного моніторингу, зашифрована аутентифікація по захищеному каналу, такі як SSL (розділ 3.16.4.1) рекомендується. 1. Встановіть файл паролів. Якщо файл пароля ще не існує, то повинні бути згенеровані за допомогою наступної команди: # Htpasswd -cs Passwdfile користувача ПОПЕРЕДЖЕННЯ: Ця команда буде перезаписувати існуючий файл в цьому місці. Після того, як файл паролів був створений, наступні користувачі можуть бути додані за допомогою наступної команди: # Htpasswd -s Passwdfile користувач 2. При необхідності створити файл групи (якщо використовується перевірка справжності групи). Файл група являє собою звичайний текстовий файл такого формату (кожна група по своїй лінії, за яким слід двокрапка і список користувачів, які належать до цієї групи, розділених пробілами): Група: user1 user2 group2: user3 3. Змініть права доступу до файлу, так що Apache може прочитати групу і PASSWD файли: 175 # Команда chgrp Апач Passwdfile groupfile # CHMOD 640 Passwdfile groupfile 4. Увімкніть перевірку справжності для бажаних каталогів Додайте наступні параметри всередині відповідного тега каталогу: ?? Для перевірки справжності розрахованого на одного користувача: # ... AuthName "Особисті дані" AuthType Basic AuthUserFile Passwdfile вимагають користувача користувача # ... ?? Для декількох користувачів аутентифікації обмежена групами: # ... AuthName "Особисті дані" AuthType Basic AuthUserFile Passwdfile AuthGroupFile groupfile потрібно група група # ... ?? Для багатокористувацьких аутентифікації обмежений дійсними обліковими записами користувачів: # ... AuthName "Особисті дані" AuthType Basic AuthUserFile Passwdfile потрібно дійсний користувачеві # ... Директива AuthName визначає мітку для захищеного контенту. Директива AuthType визначає тип аутентифікації (якщо використовується перевірка справжності Digest, цей рядок буде замість прочитати AuthType Digest) Директиви AuthUserFile і AuthGroupFile вказують паролів і груп файлів (якщо використовується перевірка справжності Digest, ці директиви будуть замість того, щоб бути AuthDigestFile і AuthDigestGroupFile.) Директива вимагає користувач обмежує доступ до одного користувача. Директива вимагає група обмежує доступ до кілька користувачів в певної групи. Стенография вимагає директива діє користувач обмежує доступ до будь-якому користувачеві в Passwdfile 176 ГЛАВА 3. ПОСЛУГИ Примітка: Переконайтеся, що розташування AuthUserFile і AuthGroupFile знаходяться поза дерева документа веб-сервера для запобігання віддалених клієнтів від доступу до обмежених імен користувачів і паролів. Це керівництво рекомендує / І т.д. / HTTPD / CONF як місце для цих файлів. 3.16.3.6 Кінцеві Доступні методи Методи веб-сервера визначені в розділі 9 RFC 2616 (http://www.ietf.org/rfc/rfc2616.txt). якщо веб Сервер не вимагає виконання всіх доступних методів, то вони повинні бути відключені. Примітка: GET і POST є найбільш поширеними методами. Більшість інших обмежуються WebDAV Протокол. # ... # Дозволити лише певні методи (ця команда чутливе до регістру!) Замовлення дозволити, заборонити # ... 3.16.4 Використання відповідні модулі для підвищення рівня безпеки в Apache Серед доступних модулів для Apache кілька, використання яких може підвищити безпеку веб-сервера установка. В цьому розділі рекомендує і обговорюється розгортання модулів, пов'язаних з безпекою. 3.16.4.1 Deploy мод SSL Оскільки HTTP є простий текстовий протокол, весь трафік схильний пасивного моніторингу. Якщо є необхідність в конфіденційність, SSL повинен бути налаштований і включений для шифрування вмісту. Примітка: мод NSS є FIPS 140-2 сертифіковане альтернативою модулю SSL. Модулі спільно значна кількість коду і повинні бути майже ідентичні за функціональністю. Якщо потрібно FIPS 140-2, то мод NSS має бути використовується. Якщо він надає деякі функції або потрібно його більша сумісність, thenmod повинні SSL бути використаним. 3.16.4.1.1 Встановити мод SSL Встановити мод SSL: # Ням встановити мод SSL 177 3.16.4.1.2 Створення сертифіката SSL На ЦС (якщо ви використовуєте свій власний) або на іншому фізично захищеної системі, згенерувати пару ключів для Веб-сервер: # CD / і т.д. / ПКІ / TLS / сертифікати # OpenSSL genrsa -des3 від'їзду httpserverkey.pem 2048 У відповідь на запрошення ввести сильну, унікальну ключову фразу для захисту пари ключів веб-сервера. Далі, згенерувати запит на підпис сертифіката (CSR) з ключа для СА: # OpenSSL REQ -new -key httpserverkey.pem від'їзду httpserver.csr Введіть пароль для пари ключів веб-сервера, а потім заповнити поля якомога повніше (або натисніть повернення прийняти значення за замовчуванням); Єдине поле Ім'я особливо важливо. Він повинен відповідати fullyqualified доменне ім'я вашого сервера точно (наприклад, www.example.com) або сертифікат не працюватиме. Файл /etc/pki/tls/openssl.conf буде визначити, які інші поля (наприклад, Країна ім'я, назва організації Ім'я і т.д.) повинні збігатися між запитом сервера і CA. Залиште пароль виклик і необов'язковий назва компанії порожнім. Потім сервер CSR веб повинен бути підписаний, щоб створити сертифікат веб-сервера. ви може або відправити CSR в установленому ЦС або підписати його з вашим CA. Щоб підписати httpserver.csr за допомогою CA: # OpenSSL ча-в httpserver.csr від'їзду httpservercert.pem Коли буде запропоновано, введіть пароль ЦС, щоб продовжити і потім завершити процес. Httpservercert. PEM сертифікат необхідно включити SSL на веб-сервері тепер в каталозі. І, нарешті, ключ веб-сервер і файл сертифіката повинні бути переміщені на веб-сервер. Використання знімних носіїв, якщо можливо. Помістіть ключ сервера і файл сертифіката в / і т.д. / ПКІ / TLS / HTTP /, називаючи їх serverkey.pem і servercert.pem, відповідно. 3.16.4.1.3 Встановити сертифікат SSL Додавання або зміна файлу конфігурації /etc/httpd/conf.d/ssl.conf, щоб відповідати наступним чином: # Створити новий порт для прослуховування прослухати 443 # Сім'ям належним чином SSLRandomSeed запуску файлу: / DEV / urandom 1024 SSLRandomSeed підключити файл: / DEV / urandom 1024 # Включити SSL SSLEngine На # Шлях до сервера сертифікатів + ​​секретного ключа SSLCertificateFile /etc/pki/tls/http/servercert.pem SSLCertificateKeyFile /etc/pki/tls/http/serverkey.pem SSLProtocol Всі -SSLv2 178 ГЛАВА 3. ПОСЛУГИ # Слабкі шифри і нульова аутентифікація не повинно бути відмовлено тільки в разі крайньої необхідності # (І навіть тоді, таке ослаблення шифру має відбуватися в межах Розташування шафи) SSLCipherSuite HIGH: MEDIUM: aNULL: + MD5 Переконайтеся, що всі каталоги, які утримання будинку SSL поширюється обмеження доступу SSL тільки в / і т.д. / HTTPD / CONF / httpd.conf: # SSL потрібен для отримання доступу SSLRequireSSL SSLOptions + StrictRequire # Потрібно домен, щоб відповідати домен сертифікату SSLRequire% {HTTP HOST} ек "site-on-certificate.com" #, А не відповідати з 403 помилкою, перенаправити користувача на потрібний сайт # Це є опціонним - розкоментуйте застосовувати # ErrorDocument 403 https://site-on-certificate.com 3.16.4.2 Deploy мод безпеки мод безпеки забезпечує міжмережевий екран рівня додатків для Apache. Після установки мод безпеки з базовий набір правил, конкретні поради конфігурації можна знайти на сайті http://www.modsecurity.org/ для розробки політики що найкраще відповідає вимогам безпеки веб-додатків. 3.16.4.2.1 Встановити мод безпеки Встановити мод безпеки: # Ням встановити mod_security 3.16.4.2.2 Налаштування мод безпеки Фільтрація мод для системи безпеки підтримує значна кількість варіантів, занадто багато, щоб бути повністю покриті в цьому керівництві. Проте, наступний список містить меншу підмножина запропонованих фільтрів, які будуть додані в / і т.д. / HTTPD / CONF / httpd.conf: # Включити мод безпеки SecFilterEngine На # Включити фільтрацію POST SecFilterScanPost На 179 # Переконайтеся, що кодування URL дійсний SecFilterCheckURLEncoding На # Приймати майже всі значення байтів SecFilterForceByteRange 1 255 # Запобігання проходження каталогів SecFilter "\. \ ./" # Фільтр по конкретній системі конкретних шляхів SecFilter / і т.д. / пароль SecFilter / бен / # Запобігання міжсайтового скриптинга SecFilter "<[[: космос:]] * сценарій" # Запобігання SQL ін'єкції SecFilter "Видалити [[: простір:]] + від" SecFilter "вставити [[: простір:]] + в" SecFilter "виберіть. + Від" 3.16.4.3 Використання відмови в обслуговуванні модулів захисту Відмова в обслуговуванні атаки важко виявити і запобігти при збереженні прийнятного доступу до уповноважених користувачів. Проте, існує цілий ряд дорожньо-транспортних Коригувальна модулів, які намагаються вирішити цю проблему. загальновідомий модулі захисту DoS включають в себе: mod_throttle mod_bwshare mod_limitipconn mod_dosevasive Рекомендується, щоб відмова в обслуговуванні запобігання бути реалізовані для веб-сервера. Проте, це керівництво залишає конкретні відомості про конфігурацію на розсуд читача. 3.16.4.4 Налаштування Довідкова модулі Належним Всі необхідні функціональні можливості додані до веб-сервера за допомогою додаткових модулів повинні бути налаштовані відповідним чином. 3.16.4.4.1 Налаштування PHP Щільно PHP є широко використовуваним і часто неправильно налаштований на стороні сервера мову сценаріїв. Слід використовувати з обережністю, але налаштований відповідним чином, коли це необхідно. Внести такі зміни в /etc/php.ini: # Не піддавайте PHP повідомлення про помилки зовнішнім користувачам display_errors = Off # Включити безпечний режим safe_mode = On 180 ГЛАВА 3. ПОСЛУГИ # Дозволити доступ лише до виконуваних в ізольованій директорії safe_mode_exec_dir = PHP-необхідні-виконувані файли-шлях # Обмеження зовнішнього доступу до середовища PHP safe_mode_allowed_env_vars = php_ # Обмежити витік інформації PHP expose_php = Off # Записувати всі помилки log_errors = On # Не реєструватися глобальний для введення даних register_globals = Off # Мінімізація допустимий розмір PHP POST post_max_size = 1K # Переконайтеся, що PHP перенаправляє належним чином cgi.force_redirect = 0 # Забороніть завантаження без необхідності file_uploads = Off # Забороніть обробку файлових запитів як FOPEN викликів allow_url_fopen = Off # Включити безпечний режим SQL sql.safe_mode = On 3.16.5 Налаштування операційної системи для захисту веб-сервера Наступні кроки налаштування повинні бути прийняті на машину, яка розміщена на веб-сервер, щоб забезпечити як безпечне оточення, наскільки це можливо для веб-сервера. 3.16.5.1 Обмеження файлів і доступу до каталогів Зведення до мінімуму доступ до критично важливих Apache файлів і каталогів: # CHMOD 511 / USR / SBIN / HTTPD # CHMOD 750 / Var / Журнал / HTTPD / # CHMOD 750 / і т.д. / HTTPD / CONF / # CHMOD 640 / і т.д. / HTTPD / CONF / * # Команда chgrp -R Apache / і т.д. / HTTPD / конф CCE 4509-6, 4386-9, 4029-5, 3581-6, 4574-0 181 3.16.5.2 Налаштування Iptables для дозволу доступу до веб-сервера Редагувати / і т.д. / sysconfig / Iptables. Додайте наступні рядки, гарантуючи, що вони з'являються перед заключним LOG і DROP лінії для RH-Firewall-1-INPUT ланцюга: -A RH-Firewall-1-INPUT -m стан --state NEW -p TCP --dport 80 -j ACCEPT -A RH-Firewall-1-INPUT -m стан --state Нова опція -p TCP --dport 443 -j ACCEPT Конфігурація Iptables за замовчуванням не дозволяє вхідного доступу до HTTP (80) і HTTPS (443) портів використовуваний веб-сервером. Ця модифікація дозволяє, що доступ, зберігаючи при цьому інші порти на сервері в їх за замовчуванням захищене стан. Дивіться розділ 2.5.5 для отримання додаткової інформації про Iptables. 3.16.5.3 Запуск Apache в CHROOT Jail, якщо це можливо Введення Apache в CHROOT в'язниці зводить до мінімуму шкоду, завдану потенційного злому шляхом виділення веб-сервера в невеликої частини файлової системи. Для того щоб налаштувати Apache для запуску з каталогу CHROOT, відредагувати конфігураційний файл Apache, / і т.д. / HTTPD / CONF / httpd.conf і додати директиву: SecChrootDir / кореневих / Апач Крім того, необхідно помістити всі файли, необхідні для Apache всередині файлової системи, який починається / CHROOT / Апач, включаючи виконавчі файли Апача, модулі, файли конфігурації, і служив в веб-сторінки. Деталі цієї конфігурації знаходяться поза обсяг цього посібника. 3.16.6 Додаткові ресурси Додаткові ресурси слід проводити консультації, якщо ваш веб-сервер вимагає більш широке керівництво конфігурації, особливо якщо конкретні програми повинні бути надійно закріплені. Зокрема, [27] рекомендується як більш повне керівництво по забезпеченню Apache. 3,17 IMAP і POP3 сервера Dovecot забезпечує IMAP і POP3 послуг. Він не встановлюється за умовчанням. На сторінці проекту за адресою: // WWW. dovecot.org містить більш детальну інформацію про конфігурацію Dovecot. 3.17.1 Відключити Довекот якщо це можливо Якщо система не повинна працювати в якості сервера IMAP або POP3, відключити і видалити Довекот, якщо це було встановлено: # Chkconfig голубники викл # Ням Стирання голубник CCE 3847-1, 4239-0 182 ГЛАВА 3. ПОСЛУГИ 3.17.2 Налаштування Dovecot, якщо необхідно Основний конфігураційний файл Dovecot є /etc/dovecot.conf. Параметри, які з'являються, закоментувавши, в файлі значення за замовчуванням. 3.17.2.1 Підтримка тільки необхідні протоколи Редагування /etc/dovecot.conf. Додати або виправити такі рядки, замінюючи ПРОТОКОЛ тільки підмножина протоколи (IMAP, IMAPS, pop3, POP3S) потрібно: Протоколи = ПРОТОКОЛ CCE 4384-4, 3887-7, 4530-2, 4547-6 Dovecot підтримує IMAP і POP3, а також SSL-захищені версії цих протоколів. конфігурувати сервер Dovecot для підтримки тільки протоколи, необхідні вашим сайтом. Якщо це можливо, потрібен захист SSL для всіх транзакцій. Варіанти протоколу SSL для прослуховування на альтернативні порти (995 замість 110 для POP3S і 993 замість 143 для IMAPS), і вимагають SSL-клієнти знають. альтернативний підхід це слухати на стандартний порт і вимагати від клієнта використовувати команду STARTTLS перед тим аутентифікації. 3.17.2.2 Включення підтримки SSL SSL повинен використовуватися для шифрування мережевого трафіку між сервером Dovecot і його клієнтами. Користувачі повинні перевірити справжність на сервер Dovecot для того, щоб читати їх пошту, і паролі ніколи не повинні передаватися у відкритому вигляді. в Крім того, захист пошти, як це завантажується є мірою конфіденційності, і клієнти можуть використовувати SSL-сертифікати аутентифікації сервера, запобігаючи іншу систему з уособлення сервера. Дивіться Розділ 2.5.6 для загального SSL інформація, включаючи настройки центру сертифікації (CA). 3.17.2.2.1 Створення сертифіката SSL Примітка: Наступні кроки повинні бути виконані в системі CA, а не на самому сервері Dovecot. якщо ви будете мати комерційний CA підписувати сертифікати, то ці кроки повинні бути виконані на окремих, фізично безпечна система присвячена цієї мети. На ЦС (якщо ви використовуєте свій власний) або на іншому фізично захищеної системі, згенерувати пару ключів для Dovecot сервера: # CD / і т.д. / ПКІ / TLS / сертифікати # OpenSSL genrsa від'їзду imapserverkey.pem 2048 Потім згенерувати запит на підпис сертифіката (CSR) для ЦС, щоб підписати, переконавшись в тому, щоб увійти в сервера повне доменне ім'я при запиті Загальна назва: # OpenSSL REQ -new -key imapserverkey.pem від'їзду imapserver.csr Потім сервер CSR пошти повинен бути підписаний, щоб створити сертифікат сервера Dovecot. Ви можете або відправити КСВ з встановленим ЦС або підписати його з вашим CA. Щоб підписати imapserver.csr за допомогою CA: # OpenSSL ча-в imapserver.csr від'їзду imapservercert.pem 183 Цей крок створює секретний ключ, imapserverkey.pem і публічний сертифікат, imapservercert.pem. Довекот сервер буде використовувати їх, щоб довести свою ідентичність, демонструючи, що він має сертифікат, який був підписаний CA. POP3 або IMAP клієнти на вашому сайті повинні бути тільки готові надати облікові дані користувачів на сервері вони можуть аутентифікації. 3.17.2.2.2 Установка SSL-сертифіката Створіть каталог PKI для POP і IMAP сертифікатів, якщо він вже не існує: # MkDir / і т.д. / ПКІ / TLS / IMAP # Чаун корінь: корінь / і т.д. / ПКІ / TLS / IMAP # CHMOD 755 / і т.д. / ПКІ / TLS / IMAP Використання знімних носіїв або будь-якої іншої безпечний формат передачі, встановити файли, створені в попередньому крок на сервер Dovecot: ?? /etc/pki/tls/imap/serverkey.pem: секретний ключ imapserverkey.pem ?? /etc/pki/tls/imap/servercert.pem: файл сертифіката imapservercert.pem Перевірте дозволу цих файлів: # Чаун корінь: корінь /etc/pki/tls/imap/serverkey.pem # Чаун корінь: корінь /etc/pki/tls/imap/servercert.pem # CHMOD 600 /etc/pki/tls/imap/serverkey.pem # CHMOD 600 /etc/pki/tls/imap/servercert.pem Переконайтеся, що файл сертифіката відкритого ЦС був встановлений як /etc/pki/tls/CA/cacert.pem, і має правильні дозволу: корінь # Чаун: корінь /etc/pki/tls/CA/cacert.pem # CHMOD 644 /etc/pki/tls/CA/cacert.pem 3.17.2.2.3 Налаштування Dovecot для використання сертифіката SSL Edit /etc/dovecot.conf і додати або виправити такі рядки (гарантуючи, що вони посилаються відповідний файли): ssl_cert_file = /etc/pki/tls/imap/servercert.pem ssl_key_file = /etc/pki/tls/imap/serverkey.pem ssl_ca_file = /etc/pki/tls/CA/cacert.pem Ці опції сказати Довекот де знайти конфігурацію TLS, що дозволяє клієнтам приймати зашифровані з'єднання. 3.17.2.2.4 Відключити Plaintext аутентифікації Щоб запобігти Довекот від спроб відкритого тексту аутентифікації клієнтів, редагувати і додавати /etc/dovecot.conf або виправити такий рядок: disable_plaintext_auth = так 184 ГЛАВА 3. ПОСЛУГИ CCE 4552-6 Команда відключення відкритим текстом Auth команди входу забороняє пов'язані до зашифрованого сеансу не було узгодження з використанням SSL. Якщо сумісність клієнта вимагає від вас, щоб уможливити з'єднання з pop3 або IMAP портів, а ніж альтернативні SSL порти, ви повинні використовувати цю команду, щоб вимагати STARTTLS до аутентифікації. 3.17.2.3 Включити голубники Параметри для захисту від Дефекти кодексу Edit /etc/dovecot.conf і додати або виправити такий рядок: login_process_per_connection = так mail_drop_priv_before_exec = так CCE 4371-1, 4410-7 IMAP і POP3 є протоколи перевірки автентичності віддаленого, а це означає, що сервер повинен приймати віддалені підключення від кого-небудь, але забезпечують істотні послуги тільки клієнтам, які успішно пройшли перевірку автентичності. Захищати проти проблем безпеки, Dovecot розділяє ці функції на окремі серверні процеси. -IMAP Логін і / або pop3-процеси входу приймають з'єднання від неперевіреними користувачам, а лише процеси ікру Imap або pop3 на успішної аутентифікації. Проте, IMAP-Логін і pop3-Логін самі процеси можуть містити уразливості. Так як кожен з них Процеси працює як демон, обробляє кілька послідовних підключень клієнтів від різних користувачів, помилки в Код може дозволити нерозпізнаних користувачам вкрасти вірчі дані. Якщо процес Увійти на варіант підключення 3.17.2.3 Включити голубники Параметри для захисту від Дефекти кодексу Edit /etc/dovecot.conf і додати або виправити такий рядок: login_process_per_connection = так mail_drop_priv_before_exec = так CCE 4371-1, 4410-7 IMAP і POP3 є протоколи перевірки автентичності віддаленого, а це означає, що сервер повинен приймати віддалені підключення від кого-небудь, але забезпечують істотні послуги тільки клієнтам, які успішно пройшли перевірку автентичності. Захищати проти проблем безпеки, Dovecot розділяє ці функції на окремі серверні процеси. -IMAP Логін і / або pop3-процеси входу приймають з'єднання від неперевіреними користувачам, а лише процеси ікру Imap або pop3 на успішної аутентифікації. Проте, IMAP-Логін і pop3-Логін самі процеси можуть містити уразливості. Так як кожен з них Процеси працює як демон, обробляє кілька послідовних підключень клієнтів від різних користувачів, помилки в Код може дозволити нерозпізнаних користувачам вкрасти вірчі дані. Якщо процес Увійти на варіант підключення включена, то окремий IMAP-Логін або pop3-Ввійти процес створюється для кожного нового з'єднання, захищаючи проти цього класу задач. Цей параметр має Економічність, але настійно рекомендується. Якщо пошта падіння власної перед Ехес опція включена, то процес-IMAP Логін або pop3-Ввійти випаде привілеї для ID користувача після аутентифікації і перед виконанням самого Imap або pop3 процес. при деяких обмежені обставини, це може захистити від привілеїв від аутентіфіцированний користувачів. Проте, якщо пошти виконуваного файлу використовується опція для запуску коду перед початком сеансу кожного користувача, важливо відмовитися від привілеїв для запобігання призначеного для користувача коду від запуску як корінь. 3.17.2.4 Дозволити IMAP клієнти для доступу до сервера Редагувати / і т.д. / sysconfig / Iptables. Додайте наступний рядок, гарантуючи, що він з'являється перед остаточним LOG і DROP лінії для RH-Firewall-1-INPUT ланцюга: -A RH-Firewall-1-INPUT -m стан --state Нова опція -p TCP --dport 143 -j ACCEPT Конфігурація за замовчуванням Iptables не дозволяє вхідного доступу до будь-яких послуг. Ця модифікація дозволить віддалені хости ініціювати підключення до IMAP демон, зберігаючи при цьому всі інші порти на сервері в їх за замовчуванням захищене стан. Дивіться розділ 2.5.5 для отримання додаткової інформації про IPTables. 3,18 Samba (SMB) Microsoft Windows Загальний доступ до файлів сервера При правильному налаштуванні служби Samba дозволяє Linux машини, щоб забезпечити доступ до файлів і друку в Microsoft машини Windows. Є два програмних пакетів, які забезпечують підтримку Samba. Перший, самба-клієнт, 185 надає ряд інструментів командного рядка, які дозволяють клієнтської машині доступ до загальних ресурсів Samba. По-друге, просто марковані самба, надає послугу Samba. Саме цей другий пакет, який дозволяє машині Linux діяти в якості сервер Active Directory, контролер домену, або в якості члена домену. Тільки пакет самба-клієнт встановлюється за умовчанням. 3.18.1 Відключити Samba якщо це можливо Якщо служба Samba була включена і не буде використовуватися, вимкніть її: # Chkconfig кого-л від CCE 4551-8 Навіть після того, як було встановлено пакет сервера Samba, він буде залишатися відключений. Не вмикайте цю послугу, якщо це абсолютно необхідно надати файл Microsoft Windows і функціональні можливості спільного використання печатки. 3.18.2 Налаштування Samba, якщо необхідно Всі настройки для демона Samba можна знайти в /etc/samba/smb.conf. Налаштування розділені між а [Глобальної] розділ налаштувань і ряд розділів визначень користувач створив акції призначені для опису файлу або друк акцій в системі. За замовчуванням Samba буде працювати в режимі користувача і дозволяють клієнтським машинам одержувати доступ до локальних домашні каталоги та принтери. Рекомендується, щоб ці параметри можна змінити або що додаткові обмеження бути встановлений на місці. 3.18.2.1 Перевірка файла конфігурації Samba Щоб перевірити файл конфігурації для помилок синтаксису, використовуйте команду testparm. Крім того, будуть перераховані всі параметри В даний час на місці, в тому числі за замовчуванням, які можуть не відображатися в файлі конфігурації. # Testparm -v 3.18.2.2 Вибір відповідного параметра безпеки Є два види безпеки в Samba, на рівні загальних ресурсів (частка) і призначеному для користувача рівні. Безпека на рівні користувача додатково підрозділяється на чотири окремих реалізацій: користувача, ім'я домену, оголошення і сервера. Рекомендується, щоб не можуть бути використані спільно використовувати і безпеки сервера режимів. В безпеки акцій, кожен задається один і той же пароль для кожного ділитися, запобігаючи індивідуальну відповідальність користувача. Режим безпеки сервера був замінений доменом і Режими оголошення безпеки. Тепер уже можна вважати застарілим. Параметр безпеки встановлено в [глобальної] розділ файлу конфігурації Samba. Він визначає, як сервер буде обробляти імена користувачів і паролі. Деякі режими безпеки вимагають додаткові параметри, такі, в робочій групі, області або імен серверів паролів. Всі режими безпеки вимагають, щоб кожен віддалений користувач мають відповідність локального облікового запису. Один обхідний шлях для цієї проблеми полягає у використанні Winbindd демон. Будь ласка, зверніться до офіційній документації Samba, щоб дізнатися більше. 186 ГЛАВА 3. ПОСЛУГИ 3.18.2.2.1 Використання користувача для системи безпеки не серверів в контексті домену Це значення за замовчуванням з новою установкою Samba і кращий вибір при роботі поза контекст безпеки домена. Відповідні параметри в /etc/samba/smb.conf буде наступним чином: безпеки = користувач робоча група = MyGroup Встановіть значення робочої групи так, щоб вона відповідала значенням інших машин в мережі. У призначеному для користувача режимі запитів аутентифікації обробляються локально і не передаються на окремий сервер аутентифікації. Це бажане поведінку для автономних серверів і контролерів домену. 3.18.2.2.2 Використання домену безпеки для серверів в контексті домену При використанні Samba в якості основного або резервного контролера домену, використовуйте безпеки = користувач, який не безпеки = домен. Це говорить Samba, що локальна машина приймає бекенд аутентифікації. По-перше, змінити параметр безпеки для домену. Потім встановіть робочу групу і Netbios Параметри (якщо необхідно): безпеки = домен робоча група = РОБОЧА Ім'я NetBIOS = NETBIOSNAME Режим домену використовується для будь-якої машини, яка буде виступати в якості сервера-члена домену. Це дозволяє Samba знати, що відомості про перевірку автентичності для цього потрібно, можна знайти на іншій машині. Основні і резервні контролери домену розмістити копії цієї інформації. Samba намагатиметься автоматично визначити, яка машина повинна перевірити справжність проти в мережі домену. Якщо це виявлення зазнає невдачі, це може бути необхідно, щоб вказати місце розташування вручну. На відміну від реалізації Microsoft Windows стандарту SMB, машина Samba може вільно змінювати ролі в домені, не вимагаючи, щоб машина повторної установки (такі ролі включають в себе основний і резервний домен контролери, сервери члени домену і звичайні робочі станції домену). Проте, існують деякі обмеження на як кожна машина може виконувати кожну роль в змішаній мережі. 3.18.2.2.3 Використовувати оголошення (Служба Active Directory) безпеки для серверів в домені ADS контекст Оголошення Режим безпеки дозволяє машину Samba, щоб виступати в якості сервера-члена домену ADS. Так як ADS вимагає Kerberos, не забудьте встановити параметр області дії відповідним чином і налаштувати локальну копію Kerberos. якщо необхідно, також можна вручну встановити параметр сервера паролів. безпеки = оголошення область = MY Realm сервер паролів = your.kerberos.server В даний час, можна виступати в якості сервера-члена домену активної директорії, але не в якості контролера домену. бути обов'язково працювати в змішаному режимі. Власний режим ще може не працювати в поточній версії Samba. майбутня підтримка 187 для ADS має бути майбутнє в Samba 4. Дивіться веб-сайт проекту Samba в http://www.samba.org більш подробиці. 3.18.2.3 Відключити гостьового доступу і місцевого Ввійти Підтримка Не дозволяйте гостю отримати доступ до локальних файлів або акції принтера. У глобальній або в кожній акції, встановіть параметр гість нормально немає: [Частка] гість ОК = немає Це безпечно, щоб відключити локальну підтримку входу в систему для віддалених користувачів Samba. Розгляньте можливість зміни облікового запису додати користувача Скрипт для установки віддалених оболонок призначених для користувача / SBIN / NOLOGIN. 3.18.2.4 Відключити доступ з правами root Адміністратори не повинні використовувати облікові записи адміністратора для доступу до файлів і принтерів Samba. Якщо можливо, відключити суперкористувача і адміністратора групи колеса: [Частка] недійсні користувачі = корінь @wheel Якщо облікові записи адміністратора не може бути відключена, переконайтеся, що локальні паролі машини і паролі служби Samba не збігаються. Як правило, доступ адміністратора потрібно, коли Samba необхідно створити користувачів і комп'ютерів рахунків і акцій. сервери членом домену та автономні сервери не можуть мати доступ адміністратора на всіх. Якщо це так, додайте недійсні користувачі параметра для [глобальної] замість цього. 3.18.2.5 Виберіть дозволену аутентифікації Рівні Переговорів За замовчуванням Samba намагатиметься вести переговори з машинами Microsoft Windows, щоб встановити загальну зв'язок Протокол. Всякий раз, коли це можливо, не забудьте відключити аутентифікацію LANMAN, так як вона набагато слабкіше, ніж інші підтримувані протоколи. [Глобальної] клієнт Lanman AUTH = немає Новіші версії Microsoft Windows може знадобитися використання NTLMv2. NTLMv2 найбільш прийнятний протоколом для аутентифікації, але так як старі машини не підтримують його, Samba відключив його за замовчуванням. Якщо можливо, включити його. [Глобальної] клієнт NTLMv2 AUTH = так Заради забезпечення сумісності, більшість сучасних машин Windows, як і раніше дозволяють іншим машинам спілкуватися з ними над слабкими протоколами, такими як LANMAN. На Samba, дозволяючи NTLMv2, ви також відключення Lanman і NTLMv1. Якщо NTLMv1 потрібно, як і раніше можна індивідуально відключити Lanman. 188 ГЛАВА 3. ПОСЛУГИ 3.18.2.6 Нехай контролери домену Створення цільових облікових записів комп'ютерів на льоту Додати або виправити запис додати машину сценарію до [глобальної] секції /etc/samba/smb.conf, щоб дозволити Samba для динамічного створення довірчих облікових записів комп'ютерів: [Глобальної] додати машину скрипт = / USR / SBIN / useradd -g -n машини -d / DEV / нуль -s / SBIN / NOLOGIN% U Переконайтеся в тому, що група машин існує. Якщо немає, то додайте його за допомогою наступної команди: / USR / SBIN / GroupAdd машини Діючи в якості PDC, стає необхідним для створення і зберігання трастових рахунків машина для кожної машини, приєднується до домену. На Microsoft Windows PDC, ця обліковий запис створюється за допомогою диспетчера сервера, але на Samba PDC, дві облікові записи повинні бути створені. Першим з них є локальна обліковий запис комп'ютера, а другий є Samba рахунок. З метою безпеки, рекомендується, щоб дозволити Samba створювати ці облікові записи на льоту. коли машина Цільові облікові записи створюються вручну, є невелике вікно можливостей, в якому шахрай машина може приєднатися до домену замість нового сервера. 3.18.2.7 Обмеження доступу до [IPC $] Share Обмежити доступ до загального ресурсу [IPC $], так що тільки машини у вашій мережі зможуть підключитися до нього: [IPC $] хости дозволяють = 192.168.1. 127.0.0.1 хости заперечують = 0.0.0.0/0 [IPC $] частка дозволяє користувачам анонімно отримувати список загальних ресурсів з сервера. Він призначений для дозволяють користувачам переглядати список доступних акцій. Він також може бути використаний в якості точки атаки в систему. відключення він цілком може порушити деякі функціональні можливості, тому рекомендується, що ви просто обмежити доступ до нього замість цього. 3.18.2.8 Обмеження загального доступу до файлів Тільки користувачі з локальними обліковими записами користувачів матиме можливість увійти в акції Samba за замовчуванням. Акції можуть бути обмежені зокрема, користувачі або мережеві адреси. Використовуйте господарі дозволяють і господарі заперечують директиви відповідно, і розглянути питання про встановлення дійсні користувачі директиви до обмеженого подмножеству осіб чи груп. Розділіть адреса, користувач або група користувачів з пропуском в такий спосіб: [Частка] хости дозволяють = 192.168.1. 127.0.0.1 дійсних користувачів = userone usertwo @usergroup Крім того, можна обмежити читання і запис доступу до певних користувачам зі списком читання і список написати опції, хоча дозволу встановлюється сама система скасує ці настройки. Встановіть цю опцію для читання атрибутів для кожної акції, щоб гарантувати, що глобальні настройки не будуть випадково перевизначити пайову Налаштування. Тоді, як і з директивою дійсних користувачів, окремі для кожного користувача або групи користувачів з пропуском: [Частка] тільки для читання = так список написати = userone usertwo @usergroup 189 Служба Samba потрібно тільки для спільного доступу до файлів і принтерів робочих станцій Microsoft Windows, і навіть то інші варіанти можуть існувати. Не використовуйте службу Samba для спільного використання файлів між машинами Unix або Linux. 3.18.2.9 Вимагати сервера SMB Підписання пакетів Для того, щоб підписання використання сервера пакетів, додайте наступні рядки в [глобальної] розділ конфігурації Samba файл: підписи сервера = обов'язковим Сервер Samba повинен спілкуватися тільки з клієнтами, які можуть підтримати підписання SMB пакетів. підписання пакета може запобігти людина-в-середині атак, які модифікують SMB-пакетів в дорозі. Служба Samba потрібно тільки для спільного доступу до файлів і принтерів робочих станцій Microsoft Windows, і навіть то інші варіанти можуть існувати. Не використовуйте службу Samba для спільного використання файлів між машинами Unix або Linux. 3.18.2.10 Вимагати клієнта SMB підпису пакетів, при використанні smbclient Для того, щоб вимагати самби клієнтів, які використовують smbclient використовувати підпис пакету, додайте наступні рядки в [глобальної] розділу файлу конфігурації Samba: підписання клієнт = обов'язковим CCE 14075-6 Клієнт Samba повинен спілкуватися тільки з серверами, які можуть підтримати підписання SMB пакетів. Пакет підписання може запобігти людина-в-середині атаки, які модифікують SMB-пакетів в дорозі. 3.18.2.11 Вимагати клієнта SMB підпису пакетів, при використанні mount.cifs Вимагати підпису пакетів клієнтів, які монтування акцій Samba за допомогою програми mount.cifs (наприклад, ті, хто вказати частки в / і т.д. / Fstab). Для цього, переконайтеся, що параметри підпису (або сек = krb5i або сек = ntlmv2i) є використовується. CCE 15029-2 Див mount.cifs (8) сторінку для отримання більш докладної інформації. Клієнт Samba повинен спілкуватися тільки з серверами який може підтримувати SMB підпису пакетів. підписання пакета може запобігти людина-в-середині атак, які модифікують SMB пакети в шляху. 3.18.2.12 Обмеження принтерів За замовчуванням Samba використовує службу CUPS друку, щоб включити загальний доступ до принтера з Microsoft Windows автоматизовані робочі місця. Якщо немає принтерів на локальному комп'ютері, або якщо загальний доступ до принтера з Microsoft Windows є не потрібно, вимкніть можливість спільного використання принтера закоментувавши наступні рядки, знайдені в / і т.д. / самби / smb.conf: 190 ГЛАВА 3. ПОСЛУГИ [Глобальної] ; навантаження принтери = так ; Варіанти чашки = сирі [Принтери] коментарі = Всі принтери Шлях = / USR / котушка / самби Проглядатися = немає гість ОК = немає записується = немає версія для друку = так Там можуть бути й інші варіанти присутні, але вони є єдиними включеними опціями і Розкоментувати за замовчуванням. Видалення [Принтери] частка повинна бути досить для більшості користувачів. Якщо можливість спільного використання принтера Samba потрібно, рекомендується відключити можливість перегляду мережі Samba або обмеження доступу до певного набору користувачів або мережевих адрес. Встановіть параметр дійсних користувачів на невелике підмножина користувачів або обмежити його до певної групи користувачів з стенографії @. Роздільне кожен користувач або група користувачів з пропуском. Наприклад, під [Принтери] акції: [Принтери] дійсних користувачів = @printerusers користувачів Служба CUPS здатна спільного використання принтерів з іншими машинами Unix і Linux в локальній мережі без служба Samba. Служба Samba потрібно тільки, коли машина Microsoft Windows необхідний доступ до принтера на хості Unix або Linux. 3.18.2.13 Налаштування Iptables для забезпечення доступу до сервера Samba Визначте відповідний мережевий блок, netwk і мережеву маску, маску, що представляє машини на ваша мережа, яка повинна працювати в якості клієнтів сервера Samba. Редагувати / і т.д. / sysconfig / Iptables. Додайте наступні рядки, гарантуючи, що вони з'являються перед заключним LOG і DROP лінії для RH-Firewall-1-INPUT ланцюга: -A RH-Firewall-1-INPUT -s netwk / маска -m стану --state NEW -p TCP --dport 137 -j ACCEPT -A RH-Firewall-1-INPUT -s netwk / маска -m стану --state NEW -p TCP --dport 138 -j ACCEPT -A RH-Firewall-1-INPUT -s netwk / маска -m стану --state NEW -p TCP --dport 139 -j ACCEPT -A RH-Firewall-1-INPUT -s netwk / маска -m стану --state NEW -p TCP --dport 445 -j ACCEPT Конфігурація Iptables за замовчуванням не дозволяє входить доступ до портів, використовуваних службою Samba. це модифікація дозволяє, що доступ, зберігаючи при цьому інші порти на сервері в їх стані за замовчуванням захищені. так як ці порти часто стають об'єктами атак мережевого сканування, обмежуючи доступ тільки до сегментів мережі який необхідно отримати доступ до сервера Samba настійно рекомендується. Дивіться розділ 2.5.5 для отримання додаткової інформації про Iptables. 3.18.3 Уникайте Samba Web Administration Tool (SWAT) Спецназ є інструментом конфігурації веб-основі забезпечується командою Samba, яка дозволяє локально і віддалено управління конфігурацією. Він не встановлюється за умовчанням. Рекомендується, щоб Спецназ не використовувати, так як вона вимагає 191 використання облікового запису адміністратора Samba і відправляє цей пароль в незашифрованому вигляді через мережеве з'єднання. Якщо Спецназ абсолютно необхідно, обмежити доступ до місцевого телефонного зв'язку машини або тунель через SSL спецназівців з Stunnel. 3.19 Проксі-сервер Проксі-сервер є дуже бажаним об'єктом для потенційного противника, так як багато (або все) конфіденційні дані для даного інфраструктура може протікати через нього. Тому, якщо потрібно, машина діє як проксі-сервер повинен бути присвячений тільки для цієї мети і зберігатися в фізично безпечному місці. проксі-сервера за замовчуванням системи Програмне забезпечення Squid, і за умови, в пакеті RPM з тим же ім'ям. 3.19.1 Відключити Squid якщо це можливо Якщо був встановлений кальмарів і активований, але система не повинна діяти як проксі-сервер, то він повинен бути відключені і видалені: # Chkconfig кальмар геть # Ням видалити кальмара CCE 4556-7, 4076-6 3.19.2 Налаштування Squid, якщо необхідно Squid конфігураційний файл /etc/squid/squid.conf. Наступні рекомендації можуть бути застосовані до цього файл. Примітка: Якщо конкретний тег не присутній у файлі конфігурації, Squid повертається до значення за замовчуванням ( часто ілюструється коментарем). 3.19.2.1 Слухайте на Незвичайне порт За замовчуванням використовується порт прослуховування для Squid служби 3128. Як така, вона часто сканується противниками дивлячись для проксі-серверів. Виберіть довільну (але рідко) високий порт для використання в якості Squid порт прослуховування і зробити відповідний змінити у файлі конфігурації: порт порт HTTP Виконайте наступну команду, щоб додати нове зіставлення порту SELinux для служби: # Semanage порт -a -t http_cache_port_t -p TCP-порт 3.19.2.2 Перевірка за замовчуванням параметрів безпеки Кілька безпеки підсилюють настройки в файлі конфігурації Squid включені за замовчуванням, але з'являються у вигляді коментарів в файлі конфігурації (як вказано в розділі 3.19.2). У цих випадках явна директива немає, 192 ГЛАВА 3. ПОСЛУГИ що означає, що неявно включений. Якщо ви працюєте з файлом конфігурації за замовчуванням, цей розділ може бути ігноруються. Переконайтеся в тому, що такі параметри безпеки явно не змінені з їх значення за замовчуванням: ftp_passive на ftp_sanitycheck на check_hostnames на request_header_max_size 20 Кб reply_header_max_size 20 Кб cache_effective_user кальмарів cache_effective_group кальмарів ignore_unknown_nameservers на CCE 4454-5, 4353-9, 4503-9, 3585-7, 4419-8, 3692-1, 4459-4, 4476-8 FTP пасивні сили FTP пасивних з'єднань. FTP SanityCheck виконує додаткові перевірки осудності по з'єднань для передачі даних FTP. перевірте імена вузлів гарантує, що імена хостів відповідають відповідність RFC. заголовок запиту Максимальний розмір і заголовок відповіді максимальний розмір місце верхня межа довжини заголовка HTTP, запобіжні заходи проти відмови в обслуговуванні і уразливості переповнення буфера. кеш ефективного користувача і кеш ефективної групи призначають EUID і EGID кальмара наступній ініціалізації (Це дуже важливо, щоб EUID / EGID бути встановлений на непривілейованих рахунок пісочниці). ігнорувати невідомі перевірки NameServers, щоб переконатися, що відповіді DNS приходять з того ж IP-запит був відправлено. 3.19.2.3 Зміна за замовчуванням Незахищені Налаштування Параметри конфігурації за замовчуванням для наступних тегів вважаються слабкими безпеку і не рекомендується. Додати або змінити файл конфігурації, щоб включити в нього наступні рядки: allow_underscore викл httpd_suppress_version_string на forwarded_for викл log_mime_hdrs на CCE 4181-4, 4577-3, 4344-8, 4494-1 дозволяють підкреслення забезпечує дотримання RFC 1034 на відповідність імен хостів відкидаючи використання підкреслення. HTTPD Придушити рядок версії запобігає Squid від розкриття інформації про версії в веб-заголовків і помилок сторінок. направляється на проксі показує IP-адреси клієнтів в HTTP заголовках і повинні бути відключені, щоб запобігти витоку внутрішніх деталей конфігурації мережі. журнал пантоміми HDRs включає ведення журналу HTTP заголовків відповіді / запиту. 193 3.19.2.4 Налаштування перевірки автентичності, якщо є Примітка: Аутентифікація не може бути використаний у разі прозорих проксі через обмеження TCP / IP Протокол. Подібно веб-серверів, два з доступних опцій Basic і Digest аутентифікації. інші варіанти NTLM і Negotiate аутентифікації. Як зазначалося в розділі 3.16.3.5, звичайна перевірка справжності передає паролі звичайний текст і схильний до пасивного моніторингу. Якщо мережу пирхання є проблемою, базова автентифікація повинна не можуть бути використані. Negotiate є новітнім і найбільш безпечний протокол. Він намагається використовувати перевірку автентичності Kerberos і повертається до NTLM, якщо вона не може. Слід зазначити, що Kerberos вимагає стороннього центру поширення ключів (KDC), щоб нормально функціонувати, в той час як інші методи аутентифікації є двопартійної схеми. Squid також пропонує можливість вибрати свій власний зовнішній аутентифікатор. Позначаючи зовнішній аутентифікатор (Також відомий як модуль "помічник") дозволяє Squid запропонувати вставних схеми аутентифікації сторонніх виробників. LDAP є один із прикладів допоміжний модуль, який існує і використовується в даний час. Є коментарі під тегом Auth парам усередині /etc/squid/squid.conf, які забезпечують великі деталі на як налаштувати кожен з цих методів. Якщо необхідна аутентифікація, виберіть метод перевірки автентичності та налаштувати відповідним чином. Рекомендовані мінімальні конфігурації, показані для кожного методу є прийнятними. Для примусового ACL (як описано в розділі 3.19.2.5) вимагати перевірки автентичності, використовуйте наступну директиву: ACL ім'я-ACL proxy_auth НЕОБХІДНОСТІ Примітка: Ключове слово REQUIRED може бути замінений користувачем, або список користувачів, щоб додатково обмежити доступ до менших підмножина користувачів. 3.19.2.5 Списки управління доступом (ACL) Будьте дуже обережні з порядком тегів управління доступом. Контроль доступу обробляється зверху вниз. Перший Правило, яке відповідає є єдиним правилом дотримується. Останнє правило в списку визначає поведінку за замовчуванням в разі відсутності відповідних правилу. Теги ПКС і отримати доступ до HTTP використовуються в комбінації, щоб забезпечити фільтрацію на основі серії списків контролю доступу. Squid має список списків контролю доступу за замовчуванням для локального хоста, SSL порти, і "безпечних" портів. Після визначення цих Списки управління доступом, ряд директив доступу HTTP встановити наступну політику фільтрації за замовчуванням: ?? Дозволити доступ cachemgr тільки з локального хоста ?? Дозволити доступ тільки порти в "безпечний" список управління доступом ?? Метод Limit CONNECT тільки SSL портів ?? Дозволити доступ з локального хоста ?? Заборонити все інші запити політика У ACL за замовчуванням є розумними з точки зору безпеки. Проте, кількість портів в списку "Безпечний" може бути значно спрощений залежно від потреб вашої мережі. З коробки, порти 21, 70, 80, 210, 280, 443, 488, 591, 777 і 1 025 до 65535 все вони вважаються безпечними. Деякі з цих портів пов'язані з застарілими або рідко використовуваних протоколів. Таким чином, цей список може бути урізаний до подальшого посилення фільтрації. Наступні дії слід зробити, щоб затягнути політику ACL: 194 ГЛАВА 3. ПОСЛУГИ 1. Існує фільтр рядки в файлі конфігурації, який рекомендується, але вона прокоментована. Ця лінія повинна раскомменті- або додані, щоб запобігти доступу до LocalHost від проксі-сервера: Доступ до HTTP Deny to_localhost 2. Список доступу повинен бути налаштований для конкретної мережі або мереж, проксі-сервер, призначених для обслуговування. Тільки це підмножина IP-адрес повинен бути дозволений доступ. Додайте ці рядки, де з'являється наступний коментар: # Вставити СВІЙ ПРАВИЛО (S) ТУТ, щоб дозволити доступ від ваших клієнтів Acl ваш - ACL-ім'я мережі Src IP-діапазон http_access дозволить вашому - Acl-ім'я мережі Примітка: IP-діапазон має формат xxx.xxx.xxx.xxx/xx~~pobj 3. Переконайтеся, що останній рядок доступу HTTP з'явиться в документі наступне: Доступ до HTTP все заперечують Це гарантує, що весь трафік, що не відповідають явного правила фільтрації відмовлено. Додаткові фільтри повинні бути створені для задоволення конкретних потреб мережі, явно дозволити доступ тільки там, де це необхідно. 4. Зверніться до наведеної нижче таблиці. Відповідні записи ПКС для невикористовуваних протоколів повинна бути закоментований і, таким чином, відмовлено. CCE 4511-2, 4529-4, 3610-3, 4466-9, 4607-8, 4255-6, 4127-7, 4519-5, 4413-1, 4373-7 Послуги портів Резюме В Рекомендації 21 FTP Протокол передачі файлів (FTP) є широко використовуваним файл Протокол передачі. ДОЗВОЛЯЮТЬ 70 Gopher Протокол ховраха є застарілим пошуку та вилучення протокол, який майже вимерло, з усього лише як 100 серверів ховрах представляють у всьому світі. підтримка для ховраха відключена в більшості сучасних браузерів. заперечувати 80 HTTP веб-проксі необхідно дозволити доступ до HTTP-трафіку. ДОЗВОЛЯЮТЬ 210 WAIS Широкий порт Area Information Server аналогічний до ховраха, яка виступає в якості системи пошуку тексту нишпорити індексів на віддалених машинах. сьогодні це застаріли і практично не існує в Інтернеті. заперечувати 280 HTTP-Упр ніякої документації будь-якого роду можна було б взнати на безвісний сервіс, який знаходиться на цьому порту. заперечувати 443 HTTPS SSL трафіку, швидше за все (і рекомендується) для будь-якого проксі і повинні бути дозволені. ДОЗВОЛЯЮТЬ 488 GSS-HTTP ніякої документації будь-якого роду можна було б взнати на безвісний сервіс, який знаходиться на цьому порту. заперечувати 591 FileMaker Filemaker є додатком бази даних, спочатку запропонована від компанії Apple в 1980 році. хоча розвиток триває, і вона залишається у використанні сьогодні, це слід відключити, якщо ваша мережа не вимагає такий трафік. заперечувати 777 многоязи HTTP ніякої документації будь-якого роду можна було б взнати на безвісний сервіс, який знаходиться на цьому порту. заперечувати 195 Послуги портів Резюме В Рекомендації 1025-65535 незареєстровані порти Випадкові високі порти використовуються в різних додатках і повинні бути дозволені. ДОЗВОЛЯЮТЬ 3.19.2.6 Налаштування протоколу кеша Internet (ICP), якщо необхідно Протокол ICP є протокол зв'язку кеш, який дозволяє декільком серверам кальмарів спілкуватися. Протокол ICP був розроблений без забезпечення на увазі, спираючись на певні користувачем списки управління доступом в поодинці, щоб визначити, який ICP повідомлень для забезпечення. Якщо Squid сервер є автономним, порт ICP повинна бути відключена шляхом додавання або виправлення наступний рядок в конфігураційний файл: icp_port 0 Якщо Squid сервер призначений, щоб говорити з однолітками, строгі списки управління доступом повинні бути встановлені тільки дозволити трафік МСП від довірених сусідів. Для досягнення цієї мети, додати або виправити такі рядки: icp_access дозволяють Acl-визначення ненадійних-сусідів icp_access все заперечують 3.19.2.7 Налаштування Iptables, щоб дозволити доступ до проксі-сервера Визначте відповідний мережевий блок, netwk і мережеву маску, маску, що представляє машини на ваша мережа, яка повинна працювати в якості клієнтів проксі-сервера. Редагувати / і т.д. / sysconfig / Iptables. Додайте наступний рядок, гарантуючи, що він з'являється перед остаточним LOG і DROP лінії для RH-Firewall-1-INPUT ланцюга: -A RH-Firewall-1-INPUT -s netwk / маска -m стану --state NEW -p TCP --dport порт -j ACCEPT Для порту, використовуйте або за замовчуванням 3128 або альтернативний порт був обраний в розділі 3.19.2.1. Конфігурація Iptables за замовчуванням не дозволяє вхідного доступу до Squid проксі-сервіс. ця модифікація допускає такий доступ, зберігаючи при цьому інші порти на сервері в їх стані за замовчуванням захищені. Дивіться Розділ 2.5.5 для більш детальну інформацію про Iptables. 3.19.2.8 Уперед повідомлення журналу Syslog Daemon Поведінка за замовчуванням Squid є запис реєстрованих повідомлень в /var/log/squid.log. Така поведінка може бути доповнити так, щоб Squid також відправляє повідомлення в системний журнал, а також. Це корисно для централізації даних журналу, особливо в тих випадках, коли кілька кальмарів серверів присутні. Squid надає аргумент командного рядка для включення системного журналу переадресації. Змінити рядок SQUID OPTS в /etc/init.d/squid включити опцію -s: SQUID_OPTS = "$ {SQUID_OPTS: -" - D "} -s" 196 ГЛАВА 3. ПОСЛУГИ 3.19.2.9 Чи не Запуск від імені Root Оскільки Squid завантажується за допомогою утиліти обслуговування системи, вона починається як корінь, а потім змінює свій ефективний ідентифікатор до UID, вказаний ефективної директиви користувача кеша. Проте, так як він був досі виконується корінь, програма підтримує збережений UID кореня навіть після зміни її ефективного UID. Для запобігання цього небажаного поведінки, або Squid повинен бути налаштований для роботи в середовищі кореневих або вона повинна бути виконані звичайним користувачем в режимі без демона (утиліта Забороняється використання цієї служби). 3.19.2.9.1 Run кальмара в CHROOT Jail Кальмари кореневого каталогу може бути дуже складним завданням. Документація для процесу є розпливчастим і багато проб і помилок може знадобитися, щоб визначити, всі файли, які повинні бути переведені до ізольованому оточенні навколишнє середовище. Таким чином, це керівництво рекомендує замість цього методу докладно в розділі 3.19.2.9.2 знизити привілеї. Якщо кальмар зміною кореня, як і раніше необхідно, вона може бути включена за допомогою наступної Директиви в конфігурації файл: кореневих кореневих-шлях Потім всі необхідні файли, використовувані Squid повинні бути скопійовані в каталог кореневих-шляху. специфіка цього крок не може бути в цьому керівництві, так як вони сильно залежать від зовнішніх програм, що використовуються в Squid конфігурації. Примітка: Утиліта Трасування є цінним ресурсом для виявлення файлів, необхідних для середовища кореневих. 3.19.2.9.2 Змінити Сервіс Вхід в Нижніх привілеї Наступна модифікація /etc/init.d/squid змушує сервісну утиліту для виконання Squid як кальмарів Користувач замість кореневого користувача: # Визначити ім'я кальмара довічним [-f / USR / SBIN / кальмар] && SQUID = "Sudo -u кальмар кальмар" Внесення цієї зміни запобігає Squid від написання його PID в / вар / бігу. Цей файл PID використовується для обслуговування перевірте, щоб побачити, якщо програма успішно запущена. Таким чином, нове місце розташування має бути вибрано для цього файлу Pid що кальмар користувач має доступ, і відповідні посилання в /etc/init.d/squid повинні бути змінені щоб вказати на нього. Зробіть наступні зміни в файлі конфігурації Squid: pid_filename /var/spool/squid/squid.pid Змініть файл /etc/init.d/squid шляхом зміни все входження /var/run/squid.pid в / вар / золотника / кальмар / squid.pid Також змініть наступний рядок в /etc/init.d/squid: [$ RETVAL екв 0] && Touch / Var / замок / Subsys / кальмар і додайте наступні рядки відразу після неї: гт -f / VAR / блокування / Subsys / кальмар кальмар статус 197 3.20 SNMP-сервер Простий протокол мережевого управління дозволяє адміністраторам стежити за станом мережних пристроїв, в тому числі комп'ютери. Більш старі версії SNMP були добре відомі слабкою безпеки, такі як передача відкритого тексту рядок спільноти (використовується для перевірки автентичності), а також використання легко угадиваеми вибору для рядка спільноти. 3.20.1 Відключити SNMP-сервер якщо це можливо Система включає в себе демон SNMP, який дозволяє його віддаленого моніторингу, хоча він не встановлений за замовчуванням. Якщо він був встановлений і активований, важливо, що програмне забезпечення буде відключено і видалені. Якщо немає критично важливою необхідності для хостів на цьому сайті, щоб віддалено контролюватися за допомогою інструменту SNMP, а потім відключити і видалити SNMP наступним чином: # Chkconfig SNMPD викл # Ням стерти нетто-SNMPD CCE 3765-5, 14081-4 3.20.2 Налаштування SNMP-сервер, якщо необхідно 3.20.2 Налаштування SNMP-сервер, якщо необхідно Якщо необхідно запустити SNMPD агент на системі, деякі кращі практики слід дотримуватися, щоб мінімізувати ризик безпеки від установки. Численні моделі безпеки, реалізовані SNMP не можуть бути повністю покриті ось так тільки такі загальні поради конфігурації можуть бути запропоновані: ?? використовувати тільки 3-й версії моделі безпеки SNMP і включити використання аутентифікації і шифрування для тих, ?? доступ до MIB (Management Information Base) написати повинно бути дозволено тільки в разі потреби ?? все доступ до MIB має бути обмежена дотримуючись принципу найменших привілеїв ?? доступу до мережі повинна бути обмежена в максимально можливій мірі, включаючи обмеження на очікуваної мережі адреси як в файлах конфігурації і в правилах брандмауер ?? забезпечити агенти SNMP відправляти пастки тільки і приймає SNMP запити тільки від, уповноваженого управління станцій ?? переконайтеся, що дозволи на файл конфігурації snmpd.conf (за замовчуванням в / і т.д. / SNMP) 640 або більш обмежувальний ?? переконайтеся, що дозволу на будь-які файли MIB також є 640 або більше обмежувальний характер 3.20.2.1 Додаткові джерела Наступні ресурси містять більш детальну інформацію про програмне забезпечення SNMP: ?? FAQ CERT SNMP Уразливості в http://www.cert.org/tech~~HEAD=pobj підказками / Snmp faq.html ?? Веб-сторінка Net-SNMP проект на http://net-snmp.sourceforge.net ?? Конфігурації протоколу SNMP (5) людина сторінки ?? індикатор (5) людина сторінка snmpd.conf 198 ГЛАВА 3. ПОСЛУГИ БІБЛІОГРАФІЯ 199 бібліографія [1] Apache 2 з SSL / TLS: Крок за кроком, частина 2. Tech. по донесенню [2] Apache 2.0 Docs. http://httpd.apache.org/docs/2.0/. [3] Блокування Apache. Tech. по донесенню [4] Налаштування Secure Apache 2 Server. Tech. по донесенню [5] Red Hat Desktop: Посібник із розгортання. Tech. Rep., Red Hat Linux, 2005. http://www.redhat.com/docs/ Керівництва / підприємства / RHEL-4-Manual / настільними керівництво /. [6] Red Hat Enterprise Linux 4: Довідкове керівництво. Tech. Rep., Red Hat Linux, 2005. http://www.redhat.com/ Docs / Інструкції / підприємства / RHEL-4-Manual / реф-гід /. [7] Red Hat Enterprise Linux 4: Посібник з безпеки. Tech. Rep., Red Hat Linux, 2005. http://www.redhat.com/ Docs / Інструкції / підприємства / RHEL-4-Manual / безпеки керівництво /. [8] Red Hat Enterprise Linux 4: Керівництво з системного адміністрування. Tech. представник, Red Hat Linux, 2005. HTTP .: //www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/sysadmin-guide/. [9] Red Hat Enterprise Linux 5: Посібник із розгортання. Tech. представник, Red Hat Linux, 2006. HTTP :. //www.redhat. COM / Docs / Інструкції / підприємства / RHEL-5 інструкція / керівництво по-ан-США з розгортання / index.html. [10] Загальні критерії EAL4 + Керівництво по конфігурації обчислених для Red Hat Enterprise Linux 5 на обладнання Hewlett-Packard. Tech. Rep., Hewlett Packard, травень 2007. http://h20331.www2.hp.com/enterprise/downloads/ RHEL5-CC-EAL4-HP-Configuration-Guide.pdf. [11] Настільна книга Gentoo Security. Tech. Rep., Gentoo Linux, лютий 2007. http://www.gentoo.org/doc/en/ безпеки / безпеки handbook.xml. [12] UNIX Контрольний список з безпеки, V5R1.17. DISA операцій на місцях безпеки, квітень 2009 http://iase.disa.mil/ Stigs / контрольний /. [13] Bernstein, D. SYN печиво. Tech. по донесенню http://cr.yp.to/syncookies.html. [14] Франк Майер, К. М., Каплан, Д. SELinux по Приклад: Використання Security Enhanced Linux. [15] Міркування Galarneua, E. Безпека з Squid проксі-сервер. Tech. Rep., Квітень 2003 року. [16] Гарфинкель, С. і Спаффорд, Г. Практичний Unix і Internet Security, 3-е видання. O'Reilly і Associates, 2003. [17] Hildebrandt, Р. і Koetter, П. Книга Postfix. Ні Крохмаль Press, 2005. [18] Хаусхолдера, А., і король, B. Забезпечення безпеки Internet Name Server. Tech. Rep, серпень 2002. HTTP .: //www.cert.org/archive/pdf/dns.pdf. 200 БІБЛІОГРАФІЯ [19] Hsiao, A. Створення Більшість модулів аутентифікації Pluggable (PAM). Tech. Rep, березень 2001. HTTP .: //www.samspublishing.com/articles/article.asp?p=20968. [20] Hunt, С. Sendmail Cookbook. O'Reilly і Associates, 2003. [21] Лю, С. DNS і BIND Cookbook. O'Reilly і Associates, жовтень 2002 року. [22] Міранда, М. Послуги в Fedora Core 6. Tech. по донесенню http://www.mjmwired.net/resources/ MJM-сервісів fc6.html. [23] Mouran, Г. Забезпечення безпеки і оптимізація Linux: Redhat Edition - руки на керівництві. Tech. Rep., 2000.. http://www.faqs.org/docs/securing/. [24] Пальміері, J. Отримати на D-Bus. Tech. Rep., Січень 2005. http://www.redhat.com/magazine/003jan05/ Особливості / DBus /. [25] Пітерс, М. Забезпечення безпеки Apache. Tech. Rep., Липень 2004. http://www.linux.com/article.pl?sid=04/07/09/ 1935231. [26] Петерсон, Р. Fedora 5: Що нового. Tech. по донесенню [27] Рістіч, І. Apache Security. O'Reilly і Associates, березень 2005 року. [28] Сміт, C. Linux NFS-HOWTO. Tech. Rep., Май 2006 р http://nfs.sourceforge.net/nfs-howto/. [29] Timme, F. Безпечний Apache з модом безпеки. Tech. Rep., Липень 2006. http://www.howtoforge.com/ Апач мод безпеки. [30] Уейнрайт, П. К. Apache так, як ви хочете. Tech. Rep., Apress Publishing, серпень 2005 року. http://www.devshed.com/c/a/Apache/Building-Apache-the-Way-You-Want-It/. [31] Wessels, D. Squid: The Definitive Guide. O'Reilly і Associates, січень 2004 року.