Захищаємо FreeBSD (defender +1)
Як і будь-яку іншу систему FreeBSD потрібно так само захищати від посягань на неї. вона
не так вже захищена, як багато людей про неї думають і її можна так само зламати і крякнути,
як і той же Windows просто FreeBSD мало поширена і мало є спеців, які з
ній працюють, а тим більше які знають її досконало, так що чим більше спеців
її ламають тим більше дірок і руткітів буде відкрито і використано.
Захист розділимо за двома видами:
I) Захист від зовнішніх атак
II) Захист від внутрішніх атак
Тепер визначимо фронт захисту:
I) Атака ззовні:
1.1) Apache - http.conf + mod_security
1.2) PHP - php.ini + mod_security + відключення небезпечних функцій + Обмеження ресурсів
1.3) FTP - Поділ привілеїв + chroot + квоти + окремий HDD
1.4) Firewall - грамотно налаштований фаєрвол
1.5) Сhroot
II) Атака всередині:
2.1) Обмеження ресурсів - /etc/login.conf + /etc/sysctl.conf
2.2) Поділ привілеїв - /etc/sysctl.conf + chmod + структура папок
2.3) Логії (logcheck)
2.4) top / ps
III) Загальні заходи
3.1) Розбір fstab
3.2) Доступ до сервера
3.3) DNS - chroot + noroot
Тепер пройдемо по пунктах (деякі пункти будуть коротко описані тому що вологість деревини принцип
захисту перетинається з іншими пунктами) як і чим можна захистити і обмежити:
I) Прикриття зовнішніх дірок.
1.1) Apache + віртуальні хости + mod_security
Прикриємо дірки цього сервісу для початку нам необхідно задати обмеження
в конфіги для кожного вхоста. Додаємо наступні параметри:
Як відомо, чимала частина зломів (SQL Injection, XSS атаки, інклюдінг) відбувається
по суті за допомогою хитрого HTTP запиту. Логічно припустити, що ці самі
запити непогано було б фільтрувати. Рішення проблеми існує у вигляді модуля до
Апач, і називається воно mod_security. ставимо:
Після установки - йдемо конфігурувати. Відкриваємо будь-який конфиг віртуального хоста,
наприклад 001.admin.hosting.ru, над яким ми вже експериментували. всі значення
треба вводити між тегами
Для і для apache 1.x в httpd.conf закоментіте:
У цього модуля - на рідкість вдала дефолтна конфігурація. До неї мало, що можна
додати, так як більшість налаштувань - специфічні. Загальний принцип складання
правил ми розглянули, а інше можна додати на свій розсуд.
1.2) PHP
На додаток дивись пункт - 2.1
Розглянемо найвразливіше місце хостингової системи - виконувані файли, зокрема,
PHP скрипти. Відкриваємо конфиг PHP:
Міняємо наступні параметри:
Вимкнути їх дуже важливо. Хоч вони і недоступні при включеному safe mode,
користувач може без праці провести успішну атаку, вказавши в файлі .htaccess:
php_flag safe_mode off
1.5) Chroot
Chroot - пісочниця це звичайно з одного боку добре з іншого - втрата
продуктивності, для деяких програм зайвий додатковий
модуль + конфиг до нього. Я вважаю грамотний chmod дає той же результат. але без
проблем і втрат ресурсів. В основному до chroot вдаються, коли потрібно убезпечити
сервіс, який не зовсім безпечний як наприклад BIND (про нього нижче).
Jail - ми не будемо це розглядати вісь всередині осі досить заморочене і погано
документовано, а якщо все вхости доведеться заганяти в jail то мало непокажется.
Я поки не буду jail розглядати :)
II) Налаштовуємо тил внутрішні захисні заходи.
2.1) Обмеження ресурсів
Буває так крім основного дії PHP скрипта функція N зациклюється, попутно
обчислюючи якесь складне дію. Як результат - високе завантаження процесора.
Це дуже типова ситуація для хостингу. Щоб запобігти подібним ненавмисні
(І навмисні) атаки, необхідно обмежувати користувача в плані ресурсів. У * BSD для
таких цілей існує система профілів користувачів. Це означає, що ми можемо
легко обмежити ресурси кожного користувача окремо.
Відкриваємо /etc/login.conf і додаємо:
Тут я вказав лише основні параметри.
Список всіх параметрів і їх опис можна знайти в Handbook.
Тепер перейдемо до налаштування операційки. Відкриваємо /etc/sysctl.conf і пишемо туди
наступне:
3.1) HDD
Зробимо в fstab деякі зміни для запобігання нехороших дій.
Зазначимо де і що можна і не можна робити системі.
noexec - ця опція дає зрозуміти що на даному розділі заборонено запускати що
або навіть правах на файл chmod 777 (Я знаю що деякі захищені сервера ламали
саме через / tmp :) надалі адміни радили прикривати цю діру.
І незабутній, що в / tmp може писати майже будь-який сервіс в системі)
nosuid - при цьому значенні система ігнорує suid-біти. Користувач не зможе зробити
#su і піднятися до рута, навіть якщо він знає його пароль рута і знаходиться в групі
wheel (але необхідно зрозуміти що потрібне юзверя яким потрібно #su домашня директорія
буде / usr, а тим кого потрібно обмежить директорія буде / usr / home)
nodev - забороняємо створення \ існування в даному розділі спеціальних пристроїв.
3.2) Доступ
Доступ до сервера слід обмежити. Тобто сервери прибрати в недоступне простим
смертним людям і закрити на ключ. На додаток не забуваємо, зняти з них все причандалля
монітори клави мишки і т.д. Для чого це повинно бути зрозуміло, наприклад якщо я бачу
загальнодоступний \ фізично сервер FreeBSD я тут же по цікавості хочу в нього залізти
і поколупатися в ньому. Але ви скажете, а як же пароль root і т.д. то слухаємо далі,
якщо ви забули чужий пароль :) а так буває то робимо так:
А) Завантажуємося в режимі одного. для цього в запрошенні завантажувача
введіть boot -s
Б) Змонтуйте командою mount -u / кореневий розділ в режим читання-запису.
Потім за допомогою mount -a прімонтіруем все що є (тобто тільки що вказано
в fstab без опції noauto)
B) Тепер міняйте пароль рута. )
Щоб люди не cмоглі зайти без пароля рута в режимі одного робимо так:
Змініть в рядку console пункт secure на insecure. Якщо ви зробите це,
FreeBSD навіть при завантаженні в режимі одного запрошуватиме пароль root.
Будьте обережні при зміні цього значення на insecure. Якщо ви забудете пароль
root, завантаження в одного користувача режим сильно ускладниться.
Це все ще можливо, але трохи складніше.
3.3) DNS
Засунем DNS в пісочницю
-u - значення UID присвоюються процесу named
-t - вказує кореневої каталог для демона
Незабутній, що кореневої каталог недолжен, бути порожнім, він повинен містити всі файли
необхідні для нормальної роботи демона. Якщо named скомпільовано так щоб
бібліотеки компонувалися статично і не потрібно було думати що йому треба ще в кореневу
покласти щоб він запустився :) Так само деякі радять в конфіги DNS прибрати рядок
про версії демона мовляв воно зможе допомогти атакуючому і т.д. я не вважаю це критично
вона може підказкою і самому адміну.