Нудно про дешифрування



Немає, а ви взагалі коли-небудь бачили веселий текст про SSL?

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

Я, звичайно, візьму на себе відповідальність і буду періодично вас будити. Проте, раджу все ж налити собі чашечку міцної кави і влаштуватися зручніше. Поговорити нам треба багато про що:
дешифрация NGFW – справа тонка.

У коментарях до матеріалу про ISE+FirePOWER розгорілася суперечка на тему дешифрування. Я вирішив розібратися детальніше в цій ЦІКАВІЙ темі.

Всі відомі мені рішення NGFW, UTM і Web proxy для дешифрування https використовують підміну сертифіката. Оперувати буду на прикладі Cisco virtual FirePOWER Thread Defense (далі vFTD) під управлінням Cisco FirePOWER Management Center virtual (далі FMC).

Мій колега-то вже детально описував це рішення тут. Згадані принципи застосовні до більшості подібних рішень.

Дешифрация – потрібна чи ні?

Фільтрація за категоріями URL, репутацій сайтів та Інтернет-додатків – це класична функціональність NGFW.

Щоб зрозуміти до якого сайту звертається клієнт не обов'язково розшифровувати весь трафік. Функціональність дешифрування, як така, необхідна тільки для певних дій: аналізу трафіку, контролю передачі файлів і моніторингу. У разі ж фільтрації інтернет-доступу по https, дешифрация не потрібна, нехай це і не очевидно.

Ось як працює блокування URL категорії:

Створюємо політику доступу на FMC, яка буде блокувати доступ до соц. мереж.



Пробуємо доступ по-звичайному http. З соц. мереж нам підійде стара www.hi5.com.



Access Denied, політика працює. Дивимося на FMC в Analysis -> Connections -> Events. Ось наші заблоковані запити:



Зрушуємо таблицю вправо, щоб подивитися URL:



Дивимося в Wireshark з фільтром за IP-адресою 67.221.174.31:



Бачимо: проходить TCP handshake, після клієнт відправляє HTTP Get з URI «http://hi5.com». На HTTP Get він відразу отримує відповідь 403 Forbidden. Ось зміст:



Видно, що це як раз той самий End User Notification (далі EUN), який ми бачимо в браузері. EUN відправляє vFTD у відповідь на спробу піти на заборонений ресурс. Причому EUN відправляється з IP-адреси 67.221.174.31. Тобто, фактично, vFTD вклинюється в TCP-сесію між клієнтом і сервером і підкладає свій відповідь.

Ок, з чистим http все зрозуміло. Тепер пробуємо зайти на https-сайт, наприклад, vk.com. Дешифрация на vFTD не включена. Чи зможемо заблокувати?



Оп, знову Access Denied. на FMC в Analysis -> Connections -> Events. Ось наші заблоковані запити:



Сдвигаемся вправо:



Бачимо, що vk.com виявився не вдалим прикладом. Виявляється, спочатку сесія встановлюється за http (tcp порт 80, видно у другому стовпці останньої сторінки). Тому блокування відбувається за тим же сценарієм, що і в першому випадку.

Перенаправлення http httpsЗвичайно, для vk.com ми могли б просто написати в браузері «https://vk.com». Тоді відразу ж потрапляємо на захищену версію сайту. Але зазвичай ніхто так не робить — сайт самостійно перенаправляє на https.


Перенаправлення


Wireshark для вконтактика 1

Бачимо, що спочатку клієнт встановлює tcp-сесію на порт 80. У відповідь на HTTP Get сервер відповідає HTTP 302 Found.


HTTP Get

Вікіпедія підказує, що код HTTP 302 означає: «запитаний документ тимчасово доступний по іншому URI, зазначеним у заголовку в полі Location». Бачимо, що у Location зазначено vk.com. Тому клієнт відразу ж встановлює нову tcp-сессиию, але вже на порт 443.


Wireshark для вконтактика 2

Якщо ви ще не заснули — пробуємо facebook.com:



Доступ заблокований, але EUN не відобразився. Подивимося на FMC:





Подивимося в Wireshark:



Бачимо, що на відміну від vk, facebook відразу встановлює сесію на порт 443.

hstsFacebook використовує механізм hsts. Якщо коротко: сайти, що підтримують hsts, після встановлення з'єднання з клієнтом по https, кажуть браузеру завжди використати для подальших зв'язків https. Тобто вони для всіх наступних сесій локально підставляють https:// замість http:// в адресний рядок.

Наприклад, в google chrome можна подивитися, для яких сайтів включений hsts. Для цього треба ввести в адресному рядку chrome://net-internals/#hsts:

Перевірка hsts в Chrome

За дампу трафіку в Wireshark бачимо, що vFTD блокує сесію до facebook після кожного повідомлення SSL Client hello. Відповідно, у Client hello міститься достатньо інформації для розпізнання URL і прийняття рішення про блокування. Розглянемо Client hello уважніше:



Дійсно, в полі Server Name Indication extension міститься інформація, за якою можна визначити запитуваний ресурс.

Що стосується EUN, у FirePOWER є деякі обмеження при відображенні повідомлень про блокування для користувачів. Для не розшифрованого трафіку EUN відображатися не буде.

Це логічно, тому що FirePOWER підкладає сторінку EUN у встановлену сесію (якщо вона не розшифрована, зробити це не можна).

Блокування з інтернет-додатками:

Можливо варто знову налити собі каву. Залишилося небагато, але краще перестрахуватися.
Останнє, що вирішив перевірити — чи буде працювати фільтрація інтернет-додатків всередині https. Зокрема, покомпонентну.

Створюємо політику, яка буде блокувати Google Drive, Google Maps і Google Play:



Перевіряємо — вибрані програми успішно заблоковані. Дивимося на FMC:





У Wireshark видно, що програми блокуються за тим же сценарієм, що і Facebook, тобто після кожного SSL Client Hello:





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

Для розпізнавання деяких додатків все ж потрібно дешифрация. Їх небагато, вони відзначені у налаштуваннях політик спеціальною іконкою з замком.


Додатки, що вимагають дешифрацию

Більшість з них пов'язано з передачею файлів.

Таким чином, дешифрация потрібна, щоб спрацьовувало повідомлення користувачів про блокування. Хоча тільки для цього я б весь цей компот не варив.

Для шифрованого трафіку не працюють сигнатури IPS і файлові політики, включаючи Advanced Malware Protection (AMP). І це логічно: щоб шукати шкідників, трафік повинен бути розшифрований. Тут варто розуміти, що глибока інспекція не відпрацює саме для payload. Для тієї інформації, яка передається у відкритому вигляді (заголовки IP, TCP, повідомлення SSL Handshake) сигнатури працювати будуть.

З точки зору IPS більш цікава захист вхідного трафіку. Якщо ми публікуємо Web-сервер в Інтернет і хочемо захистити його за допомогою IPS, то SSL-сесії будуть ініціюватися зовні. Дешифрувати їх із заміною сертифіката не має сенсу: навіщо міняти один власний сертифікат на інший?

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

Останнім застосування дешифрування – моніторинг трафіку.

У підсумку, для чого може знадобитися дешифрация трафіку на FirePOWER:
  1. Відображення EUN для заблокованих сайтів та Web-додатків;
  2. Аналіз трафіку сигнатурами IPS;
  3. Контроль передачі файлів, у тому числі аналіз файлів системою AMP;
  4. Розпізнавання деяких додатків;
  5. Моніторинг.
Думаю, тепер зрозуміло, навіщо дешифрувати SSL на NGFW (а також UTM, Web proxy) в принципі. В даному випадку я розібрав сабж на прикладі FirePOWER. Однак, впевнений, що на інших рішеннях ситуація буде аналогічною. Якщо це не зовсім так — пишіть.

У наступному матеріалі розповім, ЯК САМЕ працює дешифрация із заміною сертифіката на NGFW. Stay tuned.
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.