Розуміння принципів роботи фаєрволла
Ви можете подумати - який дивак встановлює з'єднання АСК пакетом. Думаю, що цей дивак хоче зрозуміти, як працює таблиця станів. З полісі яка дозволяє все ви можете подумати що цей пакет пройде. Але після того як ви краще зрозумієте як працює моніторинг станів ви можете змінити вашу думку:
Моє початкове уявлення моніторингу станів (по крайней мере на Check Point FireWall-1) було таким: як тільки ФВ отримує SYN пакет встановлює з'єднання, він звіряється з полісі. Так само, як в маршрутизаторі, цей пакет порівнюється з правилами послідовно (починаючи з нульового правила). Якщо пакет пройшов всі правила і не був прийнятий, він відкидається. Потім з'єднання розривається або відкидається (віддаленого хосту надсилається RST). Однак, якщо пакет прийнятий, сесія заноситься в таблицю станів з'єднань файрволу, яка знаходиться в ядрі. Потім будь-який наступний пакет (який не має SYN-прапора) порівнюється з таблицею моніторингу станів. Якщо сесія в таблиці, і пакет частина цієї сесії, то пакет приймається. Якщо пакет не є частиною сесії - він відкидається. Це збільшує продуктивність системи, тому що кожен окремий пакет не порівнюється з полісі, а тільки SYN пакети які встановлюють з'єднати. Всі інші TCP-пакети порівнюються тільки з таблицею станів в ядрі (це дуже швидко)
Тепер повернемося до нашого питання. Якщо ви почнете сесію АСК-пакетом, чи прийме FW пакет, навіть якщо полісі дозволяє все. Як говорилося раніше, ви подумаєте що так. Тепер коли ми краще розуміємо таблицю з'єднань, можливо варто сказати "ні" =). Коли FW отримує АСК пакет, він порівнює його з таблицею станів в ядрі, а не з полісі. Однак якщо у файрволу не буде цієї сесії в таблиці станів (він ніколи не отримував SYN пакета), то він відкине пакет, тому що для нього немає запису в таблиці станів.
РЕЗУЛЬТАТ - ЯК FW-1 БУДУЄ З'ЄДНАННЯ
Результат був дуже цікавий. АСК-пакет не тільки був прийнятий. але і був доданий в таблицю станів. Моє розуміння роботи FW було неправильним. Я дізнався, що коли файрвол отримує пакет, який не є частиною таблиці станів сполук, він звіряється з полісі незалежно від того, чи є він SYN. ACK або ще якимось пакетом. Якщо полісі дозволяє сесію, вона (сесія) додається в таблицю станів. Усі наступні пакети сесії порівнюються з таблицею станів і приймаються. Оскільки в таблиці станів є запис для цієї сесії, пакети приймаються без перевірки полісі. Внизу приведені дані з утиліти fwtable.pl (ver 1.0) яка конвертрует дані з 'fw tab -t connections'. У цій таблиці зберігаються всі поточні (?) З'єднання FW-1 в пам'яті. Записи, які ви бачите внизу, є частина таблиці станів з'єднань, створення яких було ініційовано АСК пакетами.
Тут ви бачите три прийнятих і доданих в таблицю станів файрволу з'єднання. Однак ці три сполуки були ініційовані АСК-пакетами. (Це також справедливо для Null, SYN / ACK і багатьох інших пакетів, наприклад FIN / ACK). Якщо пакет не є частиною сесії з таблиці станів, він звіряється з полісі. І якщо він прийнятий, сесія додається в таблицю станів. Якщо пакет не відповідає полісі, він відкидається, а сесія закривається. Ось як файрвол підтримує з'єднання: ви робите 'fwstop; fwstart'. Коли ви перезаупскаете файрвол, таблиця з'єднань очищається і не одне з'єднання Там не присутнє. Однак будь-який поточне з'єднання швидше за все буде посилати аски. Файрвол їх бачить, звіряє з полісі і відновлює таблицю з'єднань. Все це прозоро для кінцевого користувача. Ось чому ви втрачаєте аутентифіковані і шифрування сесії, у файрволу немає цих сполук в 'початковому стані'. Так само зауважте, таймаут в правій колонці = 3600 секунд. Після того як сесія додана в таблицю станів, файрвол зберігає це з'єднання. Це означає що у вас є 60 хвилин щоб створити і здійснити інший пакет що б оновити таймер. Параметри таймаута можна встановити в меню control properties.
ЗАУВАЖТЕ. Правильні FIN або RST пакети не можуть створити сесію, тому що вони служать для розриву з'єднання. Так само єдиний пакет, який не був доданий з таблицю станів був пакет 'Xmas' створений за допомогою сканера nmap (з опцією -sX), проте вони були прийняті і занесені в логи.
Потенційний відмову в обслуговуванні (Bugtraq ID 549). Коли створюється з'єднання, якщо з'єднання ініціюється АСК пакетом (або майже будь-яким іншим не SYN пакетом таким як Null, FIN / ACK, SYN / ACK і т.д.) таймаут автоматично встановлюється на 3600 секунд (за замовчуванням), дивіться приклад вище. В цьому є потенційна загроза відмови в обслуговуванні. Ініціюючи багато з'єднань АСК пакетами з системою, яка не існує, ви швидко заповніть таблицю станів. Оскільки віддаленої системи немає, не спадає жодного RST або FIN пакета щоб скинути з'єднання, залишаючи мертве з'єднання в таблиці на годину. (Пам'ятаєте, таймаут для НЕ SYN пакетів 3600 секунд) Ви можете дуже швидко заповнити таблицю з'єднань створюючи сесії АСК пакетами. На щастя ця DoS отака набагато складніше з зовнішньої сторони файрволу, ніж з внутрішньої. До несчстью, легко самому заповнити таблицю, роблячи сканування через файрволу (як дізнався я сам). А щоб обійти вищезгадані граблі, можна зробити наступні кроки:
-Зменшіть TCP з'єднання до 15 хвилин (900 секунд). Це зменшує 'вікно можливостей ", яке може бути використане для заповнення вашої таблиці.
-Збільште вашу таблицю станів. Це ускладнить її заповнення.
-Встановіть строгі правила які обмежують що може входити і виходити.
-Jason Rhoads зробив скрипт fwconwatch.pl. який буде відслідковувати вашу таблицю з'єднань і попереджати Вас.
-Встановіть Fastpath (for ver 3.0) or FastMode (for ver 4.0), які видаляють з'єднання з таблиці.
Фича FW-1, яка мені дуже подобається - це обробка SYN-пакетів. Якщо ви намагаєтеся створити нову сесію, яка емулює існуючу, файрвол все одно порівнює її з полісі. Скажімо, ви намагаєтеся зробити наступне:
A --- FW - B # Система A з'єднується з B
Якщо fastpath встановлений, то сесія не додається в таблицю з'єднань, тобто таблиця з'єднань не створюється. Причина в тому що fastpath відстежує тільки SYN пакети, так що немає потреби додавати сесію в таблицю з'єднань. Якщо пакет має будь-який інший прапор - пакет не фільтрується і пропускається за замовчуванням. Зазвичай fastpath використовується для поліпшення продуктивності (або в окремих випадках маршрутизації). Ідея в тому що якщо пакет не має SYN прапора він є частиною з'єднання, тому що тільки SYN пакет може створити з'єднання. Так як відслідковуються тільки SYN пакети, продуктивність значно збільшується. Однак використання fastpath зазвичай погане рішення тому це відкриває можливість великої кількості інших атак. Fastpath є тільки в FW-1 вер. 3.0 і є глобальним властивістю, що застосовуються до всіх TCP пакетів. У версії 4.0 це властивість називається Fastmode і може вибірково застосовуватися до різних сервісів.
Грунтуючись на поверхневих тестах, скажу, що FW-1 закриває з'єднання по таймаут. Коли модуль моніторингу бачить сесію, яка обмінюється FIN або RST пакетами, він змінює таймаут з 3600 секунд до 50. Якщо немає обміну іншими пакетами протягом 50-секундного інтервалу, то з'єднання видаляється з таблиці з'єднань. Якщо пересилається будь-який пакет в цей період, то таймер заново на 50 секунд. Постійно посилаючи пакети після закриття з'єднання, ви можете знову встановлювати таймер на 50 секунд. Це виключає можливість DoS атаки, коли хтось послиает ліві RST або FIN пакети. Поведінка цього таймаута може бути представлено як стан TIME_WAIT в TCP з'єднанні після підтвердження (ACK) воторого FIN пакета в закритті сесії.
fwtable.pl допоможе вам краще зрозуміти таблиці моніторингу станів ваших файрфолов (працює тільки для Check Point FW-1). Цей скрипт може бути запущений локально на модулі файрвола, віддалено з будь-якої станції обслуговування або окремо на системі де є Перл.
lego.pl позваляет создавть власні TCP пакети включаючи прапори, порти, порядкові номери і т.д. Там немає інтерфейсу командного рядка, треба правити код, але він дуже простий. Написано miff'ом.
libnet для низкоуровневой генерації ethernet-трафіку.