NoWell представляють Вам чергову статтю американського аналітика безпеки Lance Spitzner’a, в якій він описує основні принципи роботи файрвола на прикладі FW-1, і описує распростран¦нние помилки при його конфігурації, а так само те, як їх уникнути. Стаття орієнтована на системних адміністраторів середнього рівня.Призначення цієї статті – допомогти вам зрозуміти, як працює таблиця станів сполук файрвола FW-1. Ця таблиця те як FW-1 підтримує хто робить якісь содинения і які дозволені в полісі. Стаття грунтується на дослідження які я проводив останні пару місяців. Для того що б допомогти вам краще зрозуміти таблицю станів вашого FW-1 і перевірити мої дані, я помістив всі вихідні коди в кінці цієї сторінки. МОНІТОРИНГ СОСТОЯНИЙЭта стаття починається з питання: «Якщо у вас є файрвол з policy (полісі) яка дозволяє все, дозволить файрвол створити нове ТСР з’єднання АСК пакетом?» Частина мене говорить так. Якщо файрвол дозволяє все означає будь пакет може пройти. Однак частина мене говорила немає. Враховуючи, як працює моніторинг станів, пакет повинен бути відкинутий.Ви можете подумати — який дивак встановлює з’єднання АСК пакетом? Думаю, що цей дивак хоче зрозуміти, як працює таблиця станів. З полісі яка дозволяє всі ви можете подумати що цей пакет пройде. Але після того як ви краще зрозумієте, як працює моніторинг станів ви можете змінити вашу думку:Моє початкове уявлення моніторингу станів (принаймні на 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 в пам’яті. Записи, які ви бачите внизу, є частина таблиці станів сполук, створення яких було ініційовано АСК пакетами. mozart #fwtable —- FW-1 CONNECTIONS TABLE — Src_IP Src_Prt Dst_IP Dst_Prt 192.168.7.131 10003 207.229.143.8 25 192.168.7.131 10002 207.229.143.8 24 192.168.7.131 10001 207.229.143.8 23IP_prot Kbuf Type Flags Timeout 6 0 16385 02ffff00 2845/3600 6 0 16385 02ffff00 2845/36006 0 16385 02ffff00 2845/3600Здесь ви бачите три прийнятих і доданих в таблицю станів файрвола з’єднання. Однак ці три з’єднання були ініційовані АСК-пакетами. (це також справедливо для Null, SYN/ACK і багатьох інших пакетів, наприклад FIN/ACK). Якщо пакет не є частиною сесії з таблиці станів, що він звіряється з полісі. І якщо він прийнятий, сесія додається в таблицю станів. Якщо пакет не відповідає полісі, він відкидається, а сесія закривається. Ось як файрвол підтримує з’єднання: ви робите ‘fwstop;fwstart’. Коли ви перезаупскаете файрвол, таблиця з’єднань очищається і не одне з’єднання там не присутній. Однак будь-поточне з’єднання швидше за все буде посилати АСКи. Файрвол їх бачить, звіряє з полісі і відновлює таблицю з’єднань. Все це прозоро д
ля кінцевого користувача. Ось чому ви втрачаєте аутентифіковані і шифрованые сесії, у файрвола немає цих сполук в ‘початковому стані’. Так само зауважте, таймаут в правій колонці = 3600 секунд. Після того, як сесія додано в таблицю станів, файрвол зберігає це з’єднання. Це значить, що у вас є 60 хвилин щоб створити та надіслати інший пакет що б оновити таймер. Параметри таймауту можна встановити в меню control properties.ЗАУВАЖТЕ: Правильні FIN або RST пакети не можуть створити сесію, оскільки вони служать для розриву з’єднання. Так само єдиний пакет, який не було додано в таблицю станів був пакет ‘Xmas’ створений за допомогою сканера nmap (з опцією -sX), однак вони були прийняті і занесені в логи.Ще одна річ, яку я пізнав — це те, що монітор станів на FW-1 дивиться тільки на IP адреси і номери портів відправника і одержувача для визначення сесії. Він не піклується опорядковых номерах, т. к. я створював різні порядкові номери які файрвол принемал. Так само він не піклується про тип пакету для створення з’єднання. Коли ви посилаєте пакет SYN створюючи сесію, файрвол перевіряє його за полісі. Якщо він підходить, він додає сесію в таблицю станів, як ми вже обговорювали раніше. У цей момент таймаут спочатку встановлюється на 60 секунд. Потім файрвол чекає відповідного пакета і таймаут встановлюється на 3600 секунд (60 хвилин). Однак файрвол не піклується про те, який тип пакету приходить. Я ініціював з’єднання SYN пакетом і послав тільки АСК, який файрвол вдало прийняв як частину з’єднання (якщо IP і порти збігалися). Так що у файрвола немає інтелектуальності чекати SYN/ACK відповіді, так само як немає перевірки порядкових номерів (TCP sequence numbers).Потенційний відмова в обслуговуванні (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 з’єднується з Зараз система може надсилати будь-які пакети системі А, якщо IP і порти збігаються (тобто пакети є частина однієї сесії). Однак якщо система намагається встановити нове з’єднання (за допомогою стандартного SYN пакета), навіть якщо він використовує ті ж порти, що і нинішня сесія, файрвол вс¦ одно вважає SYN-пакет частиною нової сесії і порівнює з полісі. По моєму, це хороша можливість. Давайте уявимо, що в попередньому прикладі файрвол дозволяє весь вихідний трафік від системи А і не дозволяє вхідний від Ст. Єдиний шлях, коли може спілкуватися з А — коли з’єднання було встановлено раніше.Коли система А з’єднується з системою, з’єднання додається в таблицю станів файрвола (див. попередній приклад). Тепер система може відповідати посилаючи пакети системі А. Одак файрвол не створив великий дірки. Система не може послати SYN пакету системі А, встановлюючи нове з’єднання, навіть якщо порти і IP адреси збігаються. Коли файрвол отримає пакет SYN він звірить його з полісі. У цьому сценарії цей пакет буде відкинутий, незважаючи на те, що є встановлене з’єднання. FASTPATHЕсли 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 пакету у закритті сесії. ЗАКЛЮЧЕНИЕМое перше враження, засноване на попередніх тестах таке, що моніторинг станів CheckPoint FW-1 є напів-інтеллектульний, але тільки напів- =). Якщо FW-1 отримує пакет, який не є частиною з’єднання з таблиці станів, що він звіряється з полісі. Якщо він прийнятий, то сесія добаляется в таблицю станів, з якої звіряються всі наступні пакети(Відомими винятками є Xmas, FIN і RST пакети). Це добре т. к. файрвол буде мати адекватну таблицю станів яка буде підтримувати з’єднання. Мене турбує те, що коли з’єднання створюється АСК пакетом таймаут автоматично встановлюється на 3600 секунд і не важливо відповіла система чи ні. Це небезпечна можливість DoS атаки. Що мені подобається так це те що SYN пакети порівнюються з полісі навіть якщо вони є частиною встановленого з’єднання(це виключає ‘tunneling’ або ‘piggybacking’). Однак таблиця моніторингу не містить інформації про порядкових номерів і SYN — SYN/ACK — ACK послідовностях. Все, що він знає це те що пакет SYN — перший пакет сесії і приймає все інше (якщо SYN був прийнятий). Що стосується закриття з’єднання використовується метод здається досить зрозумілим, схожим на TIME_WAIT стан TCP. Сподіваюся після подальшого тестування і доповнень з боку firewall community(?) ця стаття стане початковим документом який відповість на багато основні питання стосуються того, що таке моніторинг станів і наскільки состоятелна таблиця станів. Подальші исследованияВсе, про ч¦м я написав, було тестовано на Check Point FireWall-1 вер. 4.0 SP3 Solaris x86 2.6. Утиліти, які я використовував для того, щоб читати таблицю станів і створювати
мої власні пакети, можуть бути знайдені нижче. Я б хотів продовжити свої тестування що б дізнатися як файрвол інтерпретує колонки ‘Type’ і ‘Flags’ в таблиці станів сполук. А так само, як файрвол ‘скидає’ єднання. Я шукаю кого-небудь хто підтвердить або спростує те, що я привів тут. Так само будь-яка додаткова інформація дуже корисна. DOWNLOADfwtable.pl допоможе вам краще зрозуміти таблиці моніторингу станів ваших файрфолов (працює тільки для Check Point FW-1). Цей сценарій може бути запущений локально на модулі файрвола, віддалено з будь-якої станції обслуговування або окремо на системі де є Перл.lego.pl дозволяє створювати власні TCP пакети включаючи прапори, порти, порядкові номери і т. д. Там немає інтерфейсу командного рядка, треба правити код, але він дуже простий. Написано miff’ом.libnet для низькорівневої генерації ethernet-трафіку.