- •1. Безпека www-серверів 6
- •2. Безпека ос, що лежить в основі web-сервера 15
- •3. Безпечна інсталяція і конфігурація web-сервера 28
- •4. Безпека програмного середовища 42
- •5. Використання криптографії в захисті www-серверів 45
- •6. Захист web-портала від інформаційних атак 68
- •1. Безпека www-серверів
- •1.1. Короткий опис проблеми
- •1.2. Принципи безпеки веб-серверів
- •1. Слід реалізувати відповідну практику управління безпекою і контроль за функціонуванням системи.
- •2. Слід зробити кроки для гарантування того, що на web-сайті публікується тільки коректний вміст.
- •3. Слід гарантувати захист web-вмісту від неавторизованого доступу або модифікації.
- •4. Слід використовувати активний вміст тільки після ретельного зважування отримуваних при цьому переваг порівняно із збільшенням ризиків.
- •5. Слід використовувати аутентифікацію, засновану на криптографічних технологіях, для забезпечення відповідного захисту чутливих даних.
- •6. Слід гарантувати постійне функціонування системи забезпечення безпеки.
- •1.3. Причини уразливості web-сервера
- •1.4. Планування розгортання web-сервера
- •2. Безпека ос, що лежить в основі web-сервера
- •2.1. Безпечна інсталяція і конфігурація ос
- •2.2. Видалення або заборона непотрібних сервісів і програм
- •2.3. Конфігурація аутентифікації користувача в ос
- •2.4. Управління ресурсами на рівні ос
- •2.6. Використання Appliances для web-сервера
- •2.7. Спеціально посилені (pre-hardened) ос і web-сервери
- •2.7.1. Тестування безпеки операційної системи
- •2.7.2. Список дій для забезпечення безпеки ос, на якій виконується web-сервер
- •2.7.3. Застосування patch-ів і upgrade-ів ос
- •2.7.4. Видалення або заборона непотрібних сервісів і програм, конфігурація аутентифікації користувачів в ос.
- •2.7.5. Тестування безпеки ос
- •3. Безпечна інсталяція і конфігурація web-сервера
- •3.1. Безпечна інсталяція web-сервера
- •3.2. Конфігурація управління доступом
- •3.3. Розмежування доступу для по web-сервера
- •3.4. Управління доступом до директорії вмісту web-сервера
- •Управління впливом web Bots
- •Використання програм перевірки цілісності файлів
- •Список дій для безпечної інсталяції і конфігурації web-сервера
- •3.5. Конфігурація безпечної директорії web-вмісту
- •3.6. Використання програм перевірки цілісності
- •4. Безпека програмного середовища
- •5. Використання криптографії в захисті www-серверів
- •5.1. Асиметрична криптографія
- •5.2. Симетрична криптографія
- •5.3. Дайджести повідомлень
- •5.4. Цифрові підписи
- •5.5. Сертифікати
- •5.6. Забезпечення цілісності даних і призначеної для користувача аутентифікації за допомогою підписів xml
- •5.7. Формування цифрового підпису xml: основні чотири кроки
- •5.8. Перевірка цифрового підпису xml
- •5.9. Шифрування xml
- •5.9.1. Шифрування цілого xml-файла
- •5.9.2. Шифрування окремого елементу
- •5.9.3. Шифрування змісту елементу
- •5.9.4. Обробка шифрування xml
- •5.10. Введення в безпеку Web-сервісів
- •6. Захист web-портала від інформаційних атак
- •6.1. Підсистема розмежування доступу
- •6.2. Підсистема антивірусного захисту
- •6.3. Підсистема контролю цілісності
- •6.4. Підсистема виявлення вторгнень
- •6.5. Підсистема аналізу захищеності
- •6.6. Підсистема криптографічного захисту
- •6.7. Підсистема управління засобами захисту Web-портала
- •Висновок
Управління впливом web Bots
Web bots (що теж саме, що і агенти або spiders) є прикладне ПО, використовуване для збору, аналізу і індексування web-вмісту. Web bots використовуються багатьма організаціями в різних цілях. Деякі приклади:
Scooter, Slurp і Googlebot аналізують, індексують і записують web-сайти для пошукових систем, таких як AltaVista і Google;
ArchitextSpider збирає статистику Інтернету;
Hyperlink validators використовуються для автоматичної перевірки коректності гіперпосилань на інші сайти;
EmailSiphon і Cherry Picker є bots, спеціально розробленими для пошуку на web-сайтах e-mail адрес для додавання в e-mail списки (“спам”). Це приклад bot, який має негативну дію на web-сайти або їх користувачів.
Bots мають негативні наслідки, тому що:
web-сервери часто містять директорії, які не повинні індексуватися;
організації можуть не хотіти, щоб частина їх сайту з'являлася в пошукових системах;
web-сервери часто містять тимчасові сторінки, які не повинні індексуватися;
bots часто містять помилки або не завжди мають хороші наміри і можуть завдати шкоди частими запитами, створюючи DoS-атаку для законних користувачів.
В принципі, існує спосіб для web-адміністратора вплинути на поведінку більшості bots на своєму web-сайті. Була створена серія угод, звана Robots Exclusion Standard (REP). Хоча REP не є офіційним стандартом Інтернету, він підтримується більшістю добре написаних і таких, що мають благі цілі bots, включаючи ті, які використовуються в більшості пошукових систем.
Web-адміністратори, які хочуть обмежити діяльність bots на своїх web-серверах, повинні створити тестовий файл, званий robots.txt. Файл повинен завжди мати дане ім'я і розташовуватися в кореневій директорії web-сервера. Крім того, допускається тільки один такий файл на весь web-сайт. Відмітимо, що файл robots.txt є стандартом, який на добровільній основі повинен підтримуватися програмістами bots. Не існує обов'язкової вимоги використовувати його. Таким чином, шкідливі bots, такі як EmailSiphon і Cherry Picker, ігнорують даний файл.
Robots.txt є простим тестовим файлом, який містить певні ключові слова і специфікації файлу. Кожен рядок файлу або є порожнім, або складається з єдиного ключового слова і інформації, що відноситься до нього. Ключові слова використовуються для того, щоб сказати роботам, яку частину web-сайта слід виключити з їх аналізу.
Допустимі наступні ключові слова:
User-agent – ім'я робота або spider. Web-адміністратор може вказати більш за одне ім'я агента, при цьому дія застосовуватиметься до кожного вказаному bot. Запис нечутливий до регістра (слово “googlebot” – те ж саме, що і “GoogleBot”, “GOOGLEBOT”). “*” указує, що це запис за умовчанням, яка використовується, якщо ніякої відповідності не знайдено. Наприклад, якщо вказати “GoogleBot”, то “*” застосовуватиметься до будь-якого іншого робота, за винятком GoogleBot.
Disallow – говорить bots, які розділи web-сайта слід виключити. Наприклад, /images інформує bots, що не слід відкривати або індексувати будь-які файли в директорії images і будь-яких її піддиректоріях. Таким чином, директорія /images/special також не індексуватиметься вказаними в user-agent bots.
Відмітимо, що /do відповідатиме будь-якій директорії, що починається з “/do” (наприклад, /do, /document, /docs і тому подібне), тоді як /do/ відповідає тільки директорії, званою “/do/”.
Web-адміністратор може також вказати конкретні файли. Наприклад, він може вказати /mydata/help.html для запобігання доступу тільки до одного файлу.
Значення “/” указує, що нічого на web-сайті не дозволено для доступу вказаних в user-agent bots.
Повинна існувати, принаймні, один запис на кожен user-agent.
Існує багато способів використовувати файл robots.txt. Декілька простих прикладів:
заборонити всім (що враховує це) bots доступ у вказані директорії:
User-agent: *
Disallow: /images/
Disallow: /banners/
Disallow: /Forms/
Disallow: /Dictionary/
заборонити всім (що враховує це) bots доступ до всього web-сайту:
User-agent: *
Disallow: /
заборонити конкретному bot аналізувати конкретну web-сторінку:
User-agent: GoogleBot
Disallow: tempindex.html
Відмітимо, що файл robots.txt доступний всім. Отже, web-адміністратор не повинен указувати імена чутливих файлів або каталогів. Якщо вони повинні бути виключені, то краще використовувати захищені паролем сторінки, які не можуть бути доступні bots. Захист паролем є надійнішим способом для виключення правил bots, що не дотримуються. Докладніша інформація буде приведена при описі методів аутентифікації.
