17309

Захист web-серверів

Лекция

Информатика, кибернетика и программирование

Лекція 20. Захист webсерверів Правила забезпечення захисту Публічні вебсервери продовжують залишатися об'єктами атак хакерів які хочуть за допомогою цих атак нанести dтрату репутації організації або добитися якихнебудь політичних цілей. Хороші заходи захисту можуть...

Украинкский

2013-06-30

139 KB

10 чел.

Лекція 20. Захист web-серверів

Правила забезпечення захисту

Публічні веб-сервери продовжують залишатися об'єктами атак хакерів, які хочуть за допомогою цих атак нанести dтрату репутації організації або добитися яких-небудь політичних цілей. Хороші заходи захисту можуть захистити сайт від тих неприємностей, які матиме організація у разі успішної атаки на нього. Уразливими операційними системами вважаються всі версії Unix або Windows, які використовуються як веб-сервер.

Збиток від атаки. Можливий різний збиток - від простого блокування роботи сервера до заміни його вмісту порнографічним матеріалом, політичними гаслами або видалення груп файлів, а також розміщення на сервері програм-троянських коней.

Як вирішити проблему. Дотримувати всі правила безпеки і оперативно встановлювати всі виправлення програм, про які повідомила група комп'ютерної безпеки або виробник програм, використовуваних на веб-сервері.

Оцінка ризику. Публічні веб-сервера зламуються майже щодня; загроза того, що буде здійснена атака на веб-сервер - реальна.

Нижче приведені основні правила забезпечення безпеки веб-сервера:

  •  Розміщення веб-сервера в демілітаризованій зоні (DMZ). Необхідно конфігурувати міжмережевий екран (файpвол) так, щоб він блокував вхідні з'єднання з веб-сервером зі всіма портами, окрім http (порт 80) або https (порт 443).
  •  Видалити всі непотрібні сервіси з веб-сервера, залишивши FTP (але тільки якщо він потрібний насправді) і засіб безпечного підключення в режимі віддаленого терміналу, такий як SSH. Будь-який непотрібний, але залишений сервіс може стати помічником хакера при організації ним атаки.
  •  Відключення всіх засобів віддаленого адміністрування, якщо вони не використовують шифрування всіх даних сеансів або одноразових паролів.
  •  Обмеження числа людей, що мають повноваження адміністратора або суперкористувача (root).
  •  Протоколювання всіх дій користувачів і зберігання системних журналів або в зашифрованій формі на веб-сервері або на іншій машині в інтpанеті.
  •  Проводити регулярні перевірки системних журналів на предмет виявлення підозрілої активності. Слід встановити декілька програм-пасток для виявлення фактів атак сервера. Можна написати програми, які запускаються кожну годину або біля того, які перевіряють цілісність файлу паролів і інших критичних файлів. Якщо така програма виявить зміни в контрольованих файлах, вона повинна посилати лист системному адміністраторові.
  •  Видалити всі непотрібні файли, такі як phf, з директорій, звідки можуть запускатися скрипти (наприклад, з /cgi-bin).
  •  Видалити всі стандартні директорії з документами, які поставляються з веб-серверами, такими як IIS і ExAir.
  •  Встановлювати всі необхідні виправлення програм на веб-сервері, що стосуються безпеки, як тільки про них стає відомо.
  •  Якщо необхідно використовувати графічний інтерфейс на консолі адміністратора веб-сервера, слід видалити команди, які автоматично запускають його за допомогою інформації в .RC-піддиpектоpіях і замість цього створити команду для його ручного запуску. Потім при необхідності можна використовувати графічний інтерфейс, але закривати його негайно ж після того, як будуть проведені необхідні дії. Не варто залишати графічний інтерфейс таким, що працює тривалий період часу.
  •  Якщо машина повинна адмініструватися віддалено, потрібно вимагати, щоб використовувалася програма, що встановлює захищене з'єднання з веб-сервером (наприклад, SSH). Не потрібно дозволяти встановлювати з веб-сервером telnet-з’єдняння або не анонімні ftp-з’єдняння (тобто ті, які вимагають введення імені і пароля) з недовіpених машин. Непогано буде також надати можливість встановлення таких з'єднань лише невеликому числу захищених машин, які знаходяться в місцевому інтpанеті.
  •  Запускати веб-сервер в chroot-pежимі або режимі ізольованої директорії (у цьому режимі ця директорія здається кореневою директорією файлової системи і доступ до директорій файлової системи поза нею неможливий), щоб не можна було дістати доступ до системних файлів.
  •  Використовувати анонімний FTP-сервер (якщо він звичайно потрібний) в режимі ізольованої директорії для директорії, відмінної від директорії, що є коренем документів веб-сервера.
  •  Проводити всі оновлення документів на публічному сервері з інтpанета. Зберігати оригінали веб-сторінок на веб-сервері в інтpанеті і спочатку оновлювати їх на цьому внутрішньому сервері; потім копіювати оновлені веб-сторінки на публічний сервер за допомогою SSL-з’єдняння. Якщо робити це кожну годину, то можна буде уникнути того, що зіпсований вміст сервера буде доступний в Інтернет довгий час.
  •  Періодично сканувати веб-сервер такими засобами, як ISS або nmap, для перевірки відсутності на нім відомих вразливих місць.
  •  Організувати спостереження за з'єднаннями з сервером за допомогою програми виявлення атак (intrusion detection). Конфігурувати цю програму так, щоб вона подавала сигнали тривоги при виявленні спроб застосувати відомі атаки або підозрілих діях з веб-сервером, а також протоколювала такі з'єднання для детального аналізу. Ця інформація зможе згодом допомогти усунути вразливі місця і підсилити систему захисту.

 Планування розгортання веб-сервера

При плануванні розгортання веб-сервера слід розглянути наступні пункти:

  •  Визначити цілі веб-сервера;
  •  Які категорії інформації зберігатимуться в веб-сервері.
  •  Які категорії інформації оброблятимуться або передаватимуться через вебсервер.
  •  Які вимоги безпеки для даної інформації.
  •  Чи існує інформація, яка отримана з іншого сервера або зберігається на іншому сервері (наприклад, backend база даних, поштовий сервер, проксі-сервер).
  •  Які ще сервіси надає веб-сервер (чи повинен web-сервер виконуватися на віддаленому хості).
  •  Які вимоги безпеки для цих додаткових сервісів.
  •  Визначити мережеві сервіси, які надаватиме веб-сервер, і використовувані при цьому протоколи:
  •  НТТР, Нттрs, SOAP і тому подібне – протоколи взаємодії з клієнтами.
  •  ODBC, JDBC, LDAP, LDAPS, NFS і тому подібне – протоколи взаємодії з backend-системами.
  •  Визначити все необхідне ПО, яке потрібне для підтримки функціонування веб-сервера;
  •  Визначити категорії користувачів веб-сервера і всіх backend-систем;
  •  Визначити способи аутентифікації користувачів і веб-сервера і способи захисту аутентифікаційних даних;
  •  Визначити, як надаватиметься відповідний доступ до інформаційних ресурсів.

Безпека ОС, що лежить в основі Web-сервера

Першим кроком в забезпеченні безпеки web-сервера є забезпечення безпеки ОС, що лежить в  його основі. Більшість загальнодоступних web-серверів функціонують на ОС загального призначення. Багатьох проблем безпеки можна уникнути, якщо ОС відповідним чином конфігурована. Конфігурації за умовчанням зазвичай поставляються виробниками з упором на можливості безпечного функціонування і можливості легкого розширення. Оскільки виробники не знають потреби безпеки кожної організації, кожен web-адміністратор повинен конфігурувати нові сервери відповідно до вимог безпеки своєї організації.

Дана технологія в різних ОС може сильно відрізнятися. Також можуть існувати деякі автоматизовані інструментальні засоби для настройки ОС з погляду безпеки.

Вибір застосування web-сервера може визначатися вибором ОС. Проте по можливості web-адміністратори повинні вибрати ОС, яка забезпечує наступне:

  •  можливість обмежити діяльність адміністративного рівня або рівня root тільки авторизованими користувачами;
  •  можливість управляти доступом до даних на сервері;
  •  можливість заборонити мережеві сервіси, що не є необхідними, які вбудовані в ПЗ ОС або сервера;
  •  можливість управління доступом до різних форм виконуваних програм, таких як CGI-скрипти і plug-ins, на стороні сервера;
  •  можливість записувати в журнали відповідну діяльність сервера для визначення проникнення і спроб проникнення.

Безпечна інсталяція і конфігурація ОС

Після того, як ОС інстальована, слід застосувати всі patches і upgrades для видалення відомих уразливостей. Всі ОС, реалізовані сьогодні, мають відомі уразливості, які повинні бути видалені перед використанням ОС як хоста web-сервера. Для адекватного визначення і коректування цих уразливостей web-адміністратор повинен:

  •  ідентифікувати уразливості і застосувати patches;
  •  пом'якшити уразливості, для яких поки patches ще не доступні, не протестовані або не встановлені;
  •  проводити регулярну інсталяцію fixes (часто званих patches, hotfixes, service packs або updates).

Видалення або заборона непотрібних сервісів і програм

Ідеально, щоб web-сервер був виділеним і використовувався тільки для цієї мети. Багато ОС конфігуровані за умовчанням для надання ширшого круга сервісів і програм, чим вимагається web-серверу; отже, web-адміністратор повинен конфігурувати ОС, видаливши або заборонивши сервіси, що не є необхідними. Ось деякі приклади сервісів, які зазвичай повинні бути заборонені:

  •  NETBIOS, якщо не потрібний;
  •  NFS, якщо не потрібний;
  •  FTP;
  •  Berkley “r” сервіси (наприклад, rlogin, rsh, rcp);
  •  Тelnet;
  •  NIS;
  •  SMTP;
  •  Компілятори;
  •  Інструментальні засоби розробки ПЗ, за винятком того випадку, коли HTML сторінки створюються яким-небудь інтерпретатором, наприклад, Perl. В цьому випадку повинен бути залишений тільки використовуваний інтерпретатор.

Видалення або заборона непотрібних сервісів підсилює безпеку web-сервера по наступних причинах:

  •  непотрібні сервіси не можуть бути скомпрометовані і використані для атаки на хост або для пошкодження сервісів web-сервера. Кожен сервіс, що є в наявності, збільшує ризик компрометації хоста, тому що кожен сервіс потенційно відкриває вхід для доступу того, що атакує;
  •  зазвичай різні сервіси можуть адмініструвати різні люди. Слід ізолювати сервіси так, щоб кожен хост мав одного адміністратора при мінімально можливих конфліктах між адміністраторами. Наявність одного адміністратора, що відповідає за хост, приводить до кращого розподілу обов'язків;
  •  хост може бути краще конфігурований для задоволення вимог конкретного сервісу. Різні сервіси можуть вимагати наявність різної апаратури і конфігурацій ПЗ, які приводять до виникнення уразливостей або обмеженню сервісу;
  •  при зменшенні числа сервісів зменшується і кількість логів і записів лога, завдяки чому виявлення некоректної поведінки полегшується.

При конфігурації ОС слід застосовувати принцип “заборонити все, за винятком того, що явно дозволено” — це означає заборонити і по можливості видалити всі сервіси і програми і потім вибірково дозволити ті, які потрібні web-серверу. Також потрібно по можливості встановити мінімальну конфігурацію ОС, яка потрібна для застосування web-сервера. Якщо система інсталяції ОС надає опцію “мінімальна інсталяція”, то потрібно вибрати її, тому що це мінімізує зусилля, потрібні для видалення непотрібних сервісів. Багато скриптів або програми типу uninstall не виконують повного видалення всіх компонент сервісу; отже, завжди краще по можливості уникати інсталяції непотрібних сервісів.

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

Конфігурація аутентифікації користувача в ОС

Авторизованих користувачів, які можуть конфігурувати систему і запускати різні сервіси, зазвичай дуже мало. Проте користувачів, які можуть мати доступ до публічного web-серверу, може бути як необмежена кількість, так і деяка обмежена підмножина Інтернет-співтовариства. Для забезпечення політики безпеки web-адміністратор повинен конфігурувати систему для аутентифікації користувачів, яким дозволений вхід, вимагаючи надання доказу своєї ідентифікації. Навіть якщо web-сервер дозволяє не аутентифікований доступ до більшості сервісів, адміністрування і інші типи спеціалізованого доступу повинні бути обмежені певними персонами або ролями.

Конфігурація комп'ютера для аутентифікації зазвичай включає конфігурацію ОС, firmware і програм на сервері, таких як ПЗ, яке реалізує мережевий сервіс. У спеціальних випадках для сайтів з високим ризиком або таких що зберігають важливі дані можна також застосовувати апаратуру для аутентифікації, наприклад, токени або пристрої з одноразовими паролями. Використання аутентифікаційних механізмів, в яких аутентифікаційна інформація (наприклад, паролі) передається в явному вигляді по мережі, не рекомендується, тому що ця інформація може бути перехоплена і задіяна тим, що атакує для підробки під аутентифікаційного користувача.

Для гарантії того, що відповідна аутентифікація користувача виконується, необхідно виконати наступні кроки:

  •  Видалити або заборонити невживані акаунты і групи, створені за умовчанням. Конфігурація ОС за умовчанням часто включає акаунт guest (як з паролем, так і без), акаунти рівня адміністратора або root, пов'язані з локальними і мережевими сервісами. Імена і паролі цих акаунтів добре відомі. Видаленню або забороні непотрібних акаунтів запобігає їх використання для проникнення, включаючи акаунти guest, на комп'ютерах, що містять чутливу інформацію. Якщо існує вимога залишити акаунт або групу guest, слід обмежити їх доступ і змінити пароль відповідно до політики для паролів в організації. Для акаунтів за умовчанням, які необхідно залишити, слід змінити імена (де можливо, особливо для акаунтів рівня адміністратора або root) і паролі відповідно до політики для паролів. Слід пам'ятати, що імена акаунтів і паролі за умовчанням добре відомі зловмисникам.
  •  Заборонити не інтерактивні акаунти. Заборонити акаунти (і пов'язані з ними паролі), які повинні існувати, але не вимагають інтерактивного входу. Для Unix-систем заборонити вхідний shell або надати вхідний shell з функціональністю NULL (/bin/false).
  •  Створити групи користувачів. Прив'язати користувачів до відповідних груп і призначати права групам. Даний підхід переважніше, чим призначати права індивідуальним користувачам.
  •  Створити акаунти користувачів. Визначити, хто авторизований використовувати кожен комп'ютер і його сервіси. Створити тільки необхідні акаунти. Не допускати використання акаунтів, що розділяються.
  •  Перевірити політику для паролів в організації. Встановити паролі акаунтів відповідним чином. Дана політика повинна розглядати наступне:
  •  довжина – мінімальна довжина паролів;
  •  складність – необхідні символи. Необхідні символи містять букви як верхнього, так і нижнего регістрів і, принаймі, один неалфавітний символ;
  •  термін використання – як довго можна не змінювати пароль. Вимагати від користувачів періодично змінювати паролі. Пароль рівня адміністратора або root повинен змінюватися кожні 30–120 днів. Пароль користувача також повинен періодично змінюватися. Цей період визначається довжиною і складністю пароля у поєднанні з чутливістю інформації, що захищається ним;
  •  перевикористовування – чи може пароль перевикористовуватися. Деякі користувачі намагаються обійти вимогу застарівання пароля, змінюючи пароль на той, який вони вже використали до цього. Потрібно по можливості гарантувати, що користувач не може змінити пароль простим додаванням “передбачуваних” символів до свого початкового пароля. Наприклад, початковий пароль був “mysecret”, а змінений – “mysecret1” або “1mysecret”;
  •  авторство – кому дозволено змінювати або встановлювати заново паролі і якого типу доказ потрібний перед початком будь-яких змін.
  •  Конфігурувати комп'ютери для заборони входу після невеликого числа невдалих спроб. Слід пам'ятати, що може бути відносне легко дістати доступ для неавторизованого користувача до комп'ютера, використовуючи автоматичні програмні засоби, які перебирають всі паролі. Щоб ОС не надавала таку можливість, її слід конфігурувати, таким чином, коли вона заборонятиме вхід після трьох невдалих спроб. Зазвичай акаунт блокується на певний час (наприклад, 30 хвилин) або до тих пір, поки користувач з відповідними повноваженнями не активує його.

Це приклад ситуації, коли від web-адміністратора вимагається ухвалення рішення про баланс між безпекою і зручністю. Реалізація даної можливості може допомогти запобігти деяким типам атак, але може також дозволити зловмисникові виконати невдалі спроби входу для недопущення доступу користувача, тобто виконати DoS-атаку для конкретного користувача.

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

  •  Інсталювати і конфігурувати інші механізми безпеки для посилення аутентифікації. Якщо інформація на web-сервері вимагає цього – розглянути використання інших аутентифікаційних механізмів, таких як токени, сертифікати клієнта і сервера або системи одноразових паролів. Хоча вони можуть бути дорожчими і важчими в реалізації, це, можливо, виправдається в деяких випадках. Коли використовуються подібні механізми аутентифікації і пристрою, політика організації повинна бути переглянута і в ній відбитий якнайкращий спосіб їх застосування.
  •  Створювати і поширювати звіти про використання акаунтів користувачів. Для того, щоб гарантувати, що всі невживані акаунти віддаляються своєчасно, важливо встановити в організації систему, яка створює звіти про призначені для користувача акаунтах, що включають інформацію, необхідну для визначення того, чи винен акаунт залишатися активним. Ці звіти повинні розповсюджуватися відповідним користувачам і персоналу, що управляє, для визначення індивідуумів, яким не потрібніше мати акаунт.

Як наголошувалося раніше, порушник, використовуючи мережеві сніфери, може легко перехопити  паролі, передавані по мережі в явному вигляді. Замість цього слід використовувати менш уразливі технології аутентифікації і шифрування, такі як SSH і SSL/TLS.

Управління ресурсами на рівні ОС

Багато ОС мають можливість вказати конкретні привілеї доступу для файлів, директорій, пристроїв і інших комунікаційних ресурсів. Ретельно продумавши управління доступом, web-адміністратор може зменшити навмисні і ненавмисні проломи в безпеці. Наприклад, заборона доступу по читанню до файлів і директорій допомагає забезпечити конфіденційність інформації, тоді як заборона доступу по запису допомагає забезпечити цілісність інформації. Вирішуючи виконання більшості інструментальних засобів системного рівня тільки системним адміністратором, можна запобігти внесенню користувачами змін в конфігурацію, які знижують безпеку системи. Таке обмеження може також зменшити можливість що атакує використовувати ці інструментальні засоби для атаки, як на дану систему, так і на інші системи в мережі. Оскільки управління ресурсами ОС тісно пов'язане з управлінням ресурсами web-сервера, дана проблема буде розглянута далі в деталях.

Безпечна інсталяція і конфігурація web-сервера

Після того, як ОС інстальована і зроблена безпечною, слід інсталювати вибране ПО web-сервера. Перед початком даного процесу слід прочитати документацію виробника і зрозуміти, які опції доступні при інсталяції. Також слід відвідати web-сайт виробника або web-сайт бази даних уразливостей, такий як ICAT метабаза (http://icat.nist.gov/), для визначення всіх відомих уразливостей і відповідних patches, які повинні бути інстальовані або конфігуровані як частина процесу установки. Тільки після завершення цих попередніх кроків слід почати інсталяцію. Розглядаються тільки загальні процедури інсталяції і конфігурації.

Безпечна інсталяція web-сервера

У багатьох аспектах безпечна інсталяція і конфігурація web-сервера аналогічна інсталяції і конфігурації ОС. Основний принцип полягає в тому, щоб інсталювати мінімальну кількість необхідних сервісів web-сервера і виключити всі відомі уразливості за допомогою patches або upgrades. Якщо програма інсталяції встановлює якісь непотрібні програми, сервіси або скрипти, вони повинні бути негайно видалені після завершення процесу. При інсталяції web-сервера повинні бути виконані наступні кроки:

  1.  Інсталювати ПЗ сервера на виділений хост;
  2.  Інсталювати мінімально необхідні сервіси Інтернету;
  3.  Застосувати всі patches або upgrades для коректування відомих уязвимостей;
  4.  Створити виділений фізичний диск або логічний розділ (окремий від ОС і сервера) для вмісту web;
  5.  Видалити або заборонити всі web-сервіси, інстальовані web-сервером, але не потрібні (наприклад, gopher, FTP і віддалене адміністрування);
  6.  З кореневої директорії web-сервера видалити всі файли, які не є частиною web-сайта;
  7.  Видалити всю документацію, а також приклади скриптів і виконувані коди;
  8.  Виконати різного роду зразки безпеки або “hardening” скрипти, що підсилюють безпеку web-сервера;
  9.  Переконфігурувати банер НТТР-сервіса (і інших сервісів, якщо вони використовуються), щоб він не повідомляв про тип і версію web-сервера і ОС. Це може бути виконано в IIS використанням вільного Microsoft IIS Lockdown Tool і в Apache за допомогою “ServerTokens” директиви.

Конфігурація управління доступом

Більшість ОС для web-серверів надають можливість вказати конкретні привілеї доступу для файлів, пристроїв і інших обчислювальних ресурсів на даному хості. Слід розуміти, що будь-яка інформація, до якої може бути здійснений доступ з каталогів, що належать web-серверу потенційно може стати доступною всім користувачам, що мають доступ до публічного web-сайту. Зазвичай ПЗ web-сервера забезпечує додаткове управління доступом до файлів, пристроїв і ресурсів. У випадку якщо дозволи доступу до ресурсів можуть бути встановлені як на рівні ОС, так і на рівні web-сервера, важливо, щоб вони були ідентичні один одному, інакше можлива ситуація, коли користувачам наданий або дуже великий, або дуже маленький доступ. Web-адміністратори повинні розглянути, яка конфігурація доступу до інформації, що зберігається в публічному web-сервері, є якнайкращою з наступних точок зору:

  •  обмеження доступу ПЗ web-сервера до підмножини обчислювальних ресурсів засобами управління доступом ОС;
  •  обмеження доступу користувачів за допомогою додаткового управління доступом, забезпечуваним web-сервером, коли потрібні детальніші рівні управління доступом.

Відповідна установка управління доступом може допомогти запобігти розкриттю чутливої інформації, яка не призначена для публічного розповсюдження. Додаткове управління доступом може бути використано для обмеження використання ресурсів у разі DoS-атаки на публічний web-сайт.

Зазвичай файлами, доступ до яких повинен контролюватися, є наступні:

  •  ПЗ і конфігураційні файли програми;
  •  Файли, що безпосередньо використовуються механізмами безпеки:
    •  файли хешей паролів і інші файли, використовувані при аутентифікації;
    •  файли, які містять авторизаційну інформацію, використовувану при управлінні доступом;
    •  криптографічний матеріал ключа, використовуваний в сервісах конфіденційності, цілісності і неможливості відмови.
  •  Логи сервера і файли системного аудиту;
  •  Системне ПЗ і його конфігураційні файли.

Розмежування доступу для ПЗ web-сервера

Перший крок в конфігурації управління доступом полягає в гарантуванні того, що web-сервер виконується тільки від імені користувача і групи, які спеціально створені для цього і мають дуже обмежені права доступу. Таким чином, повинні бути введені спеціальні ідентифікатори користувача і групи, використовувані виключно ПЗ web-сервера. Новий користувач і нова група повинні бути унікальними і незалежними від решти всіх користувачів і груп. Це необхідно для реалізації управління доступом. Хоча сервер може починати виконуватися як root (Unix) або system/administrator (Windows NT/2000/XP) для прив'язки до ТСР-порту 80 і/або 443 (використовуваному для надання НТТР і НТТРS-сервісів відповідно), не слід допускати, щоб сервер продовжував виконуватися на даному рівні доступу.

Додатково слід використовувати можливості ОС для обмеження доступу до файлів, доступних процесів web-сервера. Ці процеси повинні мати доступ тільки по читанню до тих файлів, які необхідні для виконання сервісу, і не повинні мати доступу до решти файлів, таким як файли лога сервера. Слід використовувати управління доступом на рівні ОС для забезпечення наступного:

  •  процеси web-сервера повинні бути конфігуровані для виконання від імені користувача з дуже обмеженим множиною привілеїв (тобто не виконуватися як root, адміністратор або еквівалентні користувачі);
  •  до файлів вмісту web-сайтів процеси web-сервера повинні мати доступ по читанню, але не по запису;
  •  процеси web-сервера не повинні мати можливості запису в директорії, в яких зберігається публічний вміст web-сайтів;
  •  тільки процеси, авторизовані як адміністратор web-сервера, можуть писати у файли web-вмісту;
  •  програма web-сервера може писати у файли логів web-сервера, але лог-файли не можуть читатися програмою web-сервера. Тільки процеси рівня root/system/administrator можуть читати лог-файли web-сервера;
  •  тимчасові файли, що створюються застосуванням web-сервера, наприклад, ті, які виникають при формуванні динамічних web-сторінок, повинні бути розташовані в спеціальній і відповідним чином захищеній піддиректорії;
  •  доступ до будь-яких тимчасових файлів, створених застосуванням web-сервера, обмежений процесами, які створили ці файли.

Також необхідно гарантувати, що програма web-сервера не може зберігати файли поза спеціальним підкаталогом, виділеним для публічного web-вмісту. Це може бути задано за допомогою конфігурації в ПЗ сервера або може контролюватися ОС. Слід гарантувати, що до директорій і файлів за межами спеціального піддерева директорій не може бути звернень, навіть якщо користувачі знають імена цих файлів.

Для зменшення дії основних типів DoS-атак потрібно конфігурувати web-сервер з обмеженою кількістю ресурсів ОС, які він може використовувати. Найчастіше необхідно зробити наступні дії:

  •  інсталювати вміст web на окремому жорсткому диску або логічному розділі від ОС і web-забезпечення;
  •  якщо допустимі завантаження (uploads) на web-сервер, встановити обмеження на об'єм дискового простору, який виділяється для цієї мети;
  •  якщо допустимі завантаження (uploads) на web-сервер, ці файли не повинні бути відразу ж читані web-сервером і, тим самим, видимі користувачам по протоколу НТТР. Вони повинні бути читані web-сервером тільки після деякого автоматизованого або ручного процесу перегляду. Це запобігає від використання web-сервера для передачі піратського ПЗ, інструментальних засобів атак, порнографії і т.п.;
  •  гарантувати, що лог-файли зберігаються у відповідному місці, в якому вони не зможуть вичерпати ресурси файлової системи.

Ці дії в деякій мірі захистять від атак, які спробують заповнити файлову систему інформацією, що може викликати крах системи. Вони можуть також захистити проти атак, які намагаються заповнити RAM пам'ять непотрібними процесами для уповільнення або краху системи, тим самим, обмеживши доступність сервісу. Інформація в логах, створених ОС, може допомогти розпізнати такі атаки.

Додатково часто буває необхідно сконфігурувати таймаути і інші способи управління для подальшого зменшення впливу основних DoS-атак. Один з типів DoS-атаки полягає в тому, щоб одночасно встановлювати більш ніж максимально допустимі мережеві з'єднання, щоб ніякий новий законний користувач не міг дістати доступ. Коли таймаути встановлені на мережеві з'єднання (час, після якого неактивне з'єднання скидається) в мінімально допустиме обмеження, існуючі з'єднання завершуватимуться по таймауту так швидко, як тільки можливо, створюючи можливість встановлювати нові з'єднання законним користувачам. Дана міра тільки пом'якшує DoS-атаку, але не знищує її.

Якщо максимальне число відкритих з'єднань (або з'єднань, які є напіввідкритими, – це означає, що перша частина ТСР-рукопожаття завершилася успішно) встановити в найменше число, той, що атакує може легко витратити доступні з'єднання помилковими запитами (часто званими SYN flood). Установка в максимум даного числа може пом'якшити ефект такої атаки, але ціною витрачання додаткових ресурсів. Відмітимо, що це є проблемою тільки тих web-серверів, які не захищені firewall-ом, що зупиняє SYN flood атаки. Більшість сучасних firewall-ів захищають web-сервер від SYN flood атаки, перериваючи її перш, ніж вона досягне web-сервера.

Безпека програмного середовища

Ідея мереж з так званими активними агентами, коли між комп'ютерами передаються не тільки пасивні, але і активні виконувані дані (тобто програми), зрозуміло, не нова. Спочатку мета полягала в тому, щоб зменшити мережевий трафік, виконуючи основну частину обробки там, де розташовуються дані (наближення програм до даних). На практиці це означало переміщення програм на сервери. Класичний приклад реалізації подібного підходу - це процедури, що зберігаються, в реляційних СУБД.

Для Web-серверів аналогом процедур, що зберігаються, є програми, обслуговуючі загальний шлюзовий інтерфейс (Common Gateway Interface - CGI). CGI-процедури розташовуються на серверах і зазвичай використовуються для динамічного породження HTML-документів. Політика безпеки організації і процедурні заходи повинні визначати, хто має право поміщати на сервер CGI-процедури. Жорсткий контроль тут необхідний, оскільки виконання сервером некоректної програми може привести до скільки завгодно тяжких наслідків. Розумна міра технічного характеру полягає в мінімізації привілеїв користувача, від імені якого виконується Web-сервер.

У технології Intranet, якщо піклуватися про якість і виразну силу призначеного для користувача інтерфейсу, виникає потреба в переміщенні програм з Web-серверів на клієнтські комп'ютери - для створення анімації, виконання семантичного контролю при введенні даних і так далі Взагалі, активні агенти - невід'ємна частина технології Intranet.

У якому б напрямі не переміщалися програми по мережі, ці дії представляють підвищену небезпеку, оскільки програма, отримана з ненадійного джерела, може містити ненавмисно внесені помилки або цілеспрямовано створений шкідливий код. Така програма потенційно загрожує всім основним аспектам інформаційної безпеки:

  •  доступності (програма може поглинути всі наявні ресурси);
  •  цілісності (програма може видалити або пошкодити дані);
  •  конфіденційності (програма може прочитати дані і передати їх по мережі).

Проблему ненадійних програм усвідомлювали давно, але, мабуть, тільки в рамках системи програмування Java вперше запропонована цілісна концепція її рішення.

Java пропонує три оборонні рубежі:

  •  надійність мови;
  •  контроль при отриманні програм;
  •  контроль при виконанні програм.

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

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

Захист web-портала від інформаційних атак

В даний час має місце тенденція зростання практичного використання державними і комерційними організаціями публічних Web-порталів, підключених до мережі Інтернет. Портали цього типу можуть застосовуватися для вирішення найрізноманітніших завдань, таких, наприклад, як реклама в мережі Інтернет характеру діяльності компанії, організація Інтернет-торгівлі або ж забезпечення роботи системи “Клієнт-Банк”. Цьому сприяє той факт, що на сьогоднішній день на вітчизняному ринку інформаційних технологій представлено декілька готових промислових рішень, на основі яких можлива побудова повнофункціональних Web-порталів. До таких рішень відноситься сімейство продуктів “Internet Information Services” компанії Microsoft, “Sun ONE Portal” компанії Sun Microsystems і “WebSphere” компанії IBM.

Типова архітектура Web-портала, як правило, включає наступні основні компоненти:

  •  публічні Web-сервери, які забезпечують доступ користувачів мережі Інтернет до інформаційних ресурсів порталу;
  •  кеш-сервери, що забезпечують тимчасове зберігання копії ресурсів, до яких діставали доступ Інтернет-користувачі. При зверненні до ресурсів Web-портала спочатку проводиться спроба витягання ресурсу з пам'яті кеша-серверів, і лише якщо ресурс там відсутній, то тоді запит передається публічним Web-серверам. Використання кеш-серверів дозволяє понизити навантаження на основні публічні сервери, а також зменшити час доступу користувачів до кешованих ресурсів;
  •  DNS-сервери, що забезпечують можливість перетворення символьних імен серверів Web-портала у відповідні ним IP-адреси;
  •  сервери програм, на яких встановлено спеціалізоване програмне забезпечення, призначене для управління інформаційним вмістом Web-портала;
  •  сервери баз даних, які забезпечують централізоване зберігання інформаційних ресурсів Web-портала;
  •  комунікаційне устаткування, що забезпечує взаємодію між різними серверами Web-портала.

Як правило, сервери Web-порталів розміщуються на території Інтернет-провайдерів, які мають можливість забезпечити необхідну смугу пропускання каналів, по яких сервери порталу підключаються до мережі Інтернет. Управління Web-порталом в цьому випадку здійснюється видалено через Інтернет з автоматизованих робочих місць адміністраторів. Узагальнена архітектура Web-портала зображена на рис. 1.

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


Рис. 1. Типова архітектура Web-порталу

Для захисту Web-портала найдоцільніше застосовувати комплексний підхід, що поєднує організаційні і технічні засоби захисту. Організаційні засоби захисту пов'язані з розробкою і впровадженням нормативно-правових документів, таких як політика і концепція забезпечення інформаційної безпеки Web-порталу, посадові інструкції по роботі персоналу з автоматизованою системою порталу і так далі. Технічні ж засоби захисту реалізуються за допомогою відповідних програмних, апаратних або програмно-апаратних засобів, які забезпечують виконання цілей і завдань, визначених у відповідних нормативно-правових документах. Використання комплексного підходу припускає об'єднання технічних засобів захисту Web-порталу в інтегрований комплекс, що включає підсистеми антивірусного захисту, контролю цілісності, розмежування доступу, виявлення вторгнень, аналізу захищеності, криптографічного захисту інформації, а також підсистему управління.


 

А также другие работы, которые могут Вас заинтересовать

22707. Реформування відносин власності в Україні 37.5 KB
  Зокрема у Великобританiї нараховувалось понад два десятки методик якi застосовувались у ходi приватизацiї залежно вiд ситуацiї. Для зростання виробництва iнколи достатньо лише приватизацiї управлiння шляхом переведення пiдприємств у ринковi умови iснування лiбералiзацiї ринкiв тощо. Дослiдники видiлили вимоги недотримання яких зумовлює неефективнiсть приватизацiї. Серед них утворення сприятливого для приватної власностi середовища широкi програми iнформування населення i пiдготовки спецiалiстiв встановлення прiоритетiв врахування...
22709. Нетарифні заходи ЗЕД 32.5 KB
  Ліцензування – це комплекс питань пов’язаних з підготовкою та поданням переліку документів потрібних для отримання ліцензії. Вимоги до системи ліцензування: коли не обмежує конкуренцію коли створені чіткі і прозорі ліцензійні умови коли використання ліцензій сприяє розвитку окремого виду діяльності. Ліцензування має бути логічним послідовним економічно обґрунтованим умови зрозумілі для всіх підприємств.
22711. Протиріччя у зовнішньополітичному курсі президента Дж. Кеннеді 38.5 KB
  Кеннеді. Піднесення національновизвольного руху у країнах третього світу примусило адміністрацію Кеннеді розглядати цей регіон як пріоритетний. Попри наполягання американських військовиків Кеннеді заборонив повторний повітряний наліт як і перебування американських кораблів та підводних човнів в межах 20мильної зони ЗО км від місця висадки десанту. Для Кеннеді це був важкий удар.
22712. Основні напрямки зовнішньої політики адміністрації Л. Джонсона 27.5 KB
  Він продовжив політику нормалізації відносин з СРСР: всупереч позиції конгресу надав московському урядові кредити на закупівлю хліба в американських фермерів; 1964 року оголосив доктрину наведення мостів розвиток торговельних і гуманітарних зв'язків із деякими соціалістичними країнами 1968 року підписав Договір про нерозповсюдження ядерної зброї а під завісу свого урядування готувався до переговорів щодо обмеження стратегічних озброєнь ОСО1.Джонсон все ж 1965 року проголосив нову доктрину названу його ім'ям Доктрина Джонсона яка...
22713. Доктрина ядерного стримування у зовнішній політиці США 32 KB
  Доктрина ''ядерного стримування'' у зовнішній політиці США. Ядерное оружие играет важнейшую роль в системе обороны США их союзников и друзей. Этот ядерный потенциал обладает уникальными свойствами которые позволяют США решать важные стратегические и политические задачи. Интересы США и их союзников необязательно потребуют нанесения ядерных ударов.
22714. Доктрина Джонсона 19 KB
  €Доктрина Джонсона€.Джонсон все ж 1965 року проголосив нову доктрину названу його ім'ям Доктрина Джонсона яка передбачала право США на військові дії на латиноамериканському континенті з метою захисту своїх громадян . Более подробно о внешней политике Джонсона см.
22715. Доктрина Ніксона 24.5 KB
  Согласно этой доктрине США обязывались и в дальнейшем участвовать в обеспечении обороны своих союзников и заявляли о своем праве определять масштабы формы и сферы своего вмешательства в региональные события руководствуясь своими национальными интересами. В послании президента Никсона Конгрессу 18 февраля 1970 эта доктрина прежде всего относившаяся к угрозе коммунистической экспансии в странах Азии получила дальнейшее развитие как руководящий принцип политики США и в других регионах. Но насущной проблемой нового президента была война во...