Вітаю! Ласкаво просимо на шостий урок курсу . На ми освоїли основи роботи з технологією NAT , а також випустили нашого тестового користувача до Інтернету. Тепер настав час подбати про безпеку користувача на його просторах. У цьому уроці ми розглянемо такі профілі безпеки: Web Filtering, Application Control, а також HTTPS інспекцію.
Щоб розпочати знайомство з профілями безпеки, нам необхідно розібратися ще з однією річчю — режимами інспекції.
За замовчуванням використовується режим Flow Based. Він перевіряє файли, коли вони проходять через FortiGate без буферизації. Як тільки пакет перебуває, він обробляється і передається далі, без очікування на отримання цілого файлу або веб-сторінки. Він вимагає менше ресурсів і забезпечує більшу продуктивність, ніж Proxy режим, але в той же час у ньому доступний не весь функціонал Security. Наприклад, систему запобігання витоку даних (DLP) можна використовувати лише в Proxy режимі.
Proxy режим працює інакше. Він створює два TCP з'єднання, одне між клієнтом і FortiGate'ом, друге між FortiGate'ом та сервером. Це дозволяє йому буферизувати трафік, тобто отримувати повний файл або веб-сторінку. Сканування файлів на різні загрози починається тільки після того, як весь файл забуферизувався. Це дозволяє використовувати додаткові можливості, які недоступні у Flow based режимі. Як бачите, цей режим ніби протилежність Flow Based - безпека тут відіграє головну роль, а продуктивність відходить на другий план.
Дуже часто запитують – який режим кращий? Але тут нема загального рецепту. Все завжди індивідуальне і залежить від ваших потреб та завдань. Я ж далі протягом курсу постараюся показати відмінності профілів безпеки у Flow та Proxy режимах. Це допоможе порівняти функціонал та вирішити, що краще підійде вам.
Перейдемо безпосередньо до профілів безпеки та першим розглянемо Web Filtering. Він допомагає контролювати чи відстежувати, які веб-сайти відвідують користувачі. Думаю, не варто заглиблюватись у пояснення необхідності такого профілю у нинішніх реаліях. Найкраще розберемося, як він працює.
Після того, як встановлено TCP з'єднання, користувач за допомогою запиту GET запитує вміст певного веб-сайту.
Якщо веб-сервер відповідає позитивно, він надсилає інформацію про веб-сайт у відповідь. Тут у справу вступає веб-фільтр. Він перевіряє вміст цієї відповіді. Під час перевірки FortiGate в режимі реального часу відправляє запит до FortiGuard Distribution Network (FDN), щоб визначити категорію даного веб-сайту. Після визначення категорії конкретного веб-сайту, веб-фільтр, залежно від налаштувань виконує конкретну дію.
У Flow режимі є три дії:
- Allow — дозволити доступ до веб-сайту
- Block — заборонити доступ до веб-сайту
- Monitor — дозволити доступ до веб-сайту та записати це в логі
У Proxy режимі додаються ще дві дії:
- Warning - видавати користувачеві попередження про те, що він намагається відвідати певний ресурс і дати користувачеві вибір - продовжити або піти з веб-сайту
- Authenticate — запит облікових даних користувача — це дозволяє дозволити певним групам доступ до заборонених категорій веб-сайтів.
На сайті ви можете ознайомитися з усіма категоріями та підкатегоріями веб-фільтра, а також дізнатися, до якої категорії належить конкретний веб-сайт. Та й загалом, для користувачів рішень Fortinet це досить корисний сайт, раджу у вільний час познайомитись із ним ближче.
Про Application Control можна сказати зовсім небагато. З назви видно, що дозволяє контролювати роботу додатків. А робить він це за допомогою патернів різних програм, так званих сигнатур. За цими сигнатурами він може визначити конкретний додаток і застосувати до нього певну дію:
- Allow - дозволити
- Monitor - дозволити і записати це в логі
- Block - заборонити
- Quarantine — записати подію в логі та заблокувати IP адресу на певний час
Подивитися існуючі сигнатури можна також на сайті .
Тепер розглянемо механізм HTTPS інспекції. Згідно зі статистикою, за кінець 2018 року частка HTTPS трафіку перевищила 70%. Тобто, без використання HTTPS інспекції ми зможемо проаналізувати лише близько 30% трафіку, що ходить по мережі. Для початку розглянемо роботу HTTPS у грубому наближенні.
Клієнт ініціює TLS запит до веб-сервера та отримує TLS відповідь, а також бачить цифровий сертифікат, який повинен бути довіреним для даного користувача. Це той необхідний мінімум, який нам потрібно знати про роботу HTTPS, насправді схема його роботи набагато складніша. Після успішного TLS хендшейка починається передача даних у зашифрованому вигляді. І це добре. Ніхто не може отримати доступ до даних, якими ви обмінюєтеся з веб-сервером.
Однак для безпечних компаній це справжній головний біль, оскільки вони не можуть бачити цей трафік і перевіряти його вміст ні антивірусом, ні системою запобігання вторгненням, ні DLP системами, нічим. Також це негативно відображається на якості визначення додатків і веб ресурсів, що використовуються всередині мережі, — саме те, що відноситься до нашої теми уроку. Вирішити цю проблему покликана технологія HTTPS інспекції. Її суть дуже проста - фактично, пристрій, який займається HTTPS інспекцією, організує атаку Man In The Middle. Виглядає це приблизно так: FortiGate перехоплює запит користувача, організує з ним HTTPS з'єднання, і вже від себе піднімає HTTPS сесію з ресурсом, до якого звернувся користувач. При цьому на комп'ютері користувача буде видно сертифікат, випущений FortiGate'ом. Він має бути довіреним, щоб браузер дозволив підключення.
Насправді, HTTPS інспекція річ досить непроста і має безліч обмежень, але в рамках даного курсу ми це розглядати не будемо. Додам лише, що використання HTTPS інспекції — не хвилинна справа, зазвичай це займає приблизно місяць. Необхідно зібрати інформацію про необхідні винятки, зробити відповідні налаштування, зібрати зворотний зв'язок від користувачів, відкоригувати налаштування.
Наведена теорія, а також практична частина представлені у цьому відео уроці:
У наступному уроці ми розглянемо інші профілі безпеки: антивірус та систему запобігання вторгненням. Щоб не пропустити його, слідкуйте за оновленнями на наступних каналах:
Джерело: habr.com