Тестування Firewall. Безкоштовний фаєрвол Comodo

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

Інструкція

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

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

Бізнес-користувачі, які використовують ноутбук як єдиний робочий комп'ютер, можуть опинитися в такій же ситуації, при цьому їх машини найчастіше налаштовані на контроль через віддалений робочий стіл (Microsoft Remote Desktop).

Мета цього тесту визначити, як найбільш популярні сторонні фаєрволи (брандмауери) – окремі та у складі пакетів Internet Security – насправді забезпечують основний контроль доступу для користувачів ноутбуків, які перемикаються між домашньою/робочою та громадською мережею.

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

Тестування проводилось у січні 2014 року на замовлення журналу CHIP Online (Німеччина). Версії фаєрволів, що використовуються, були доступні станом на 13 січня 2014 року.

Процедура тестування фаєрволів

Тестовий ПК підключено до Інтернету через бездротову локальну мережу (WLAN), використовуючи з'єднання мережі, яка визначається як Приватна в Центрі керування мережами та загальним доступом Windows (WNSC).

Тестова версія кожного продукту, доступного станом на 13 січня 2014 року, встановлюється за замовчуванням, і тестовий комп'ютер перезавантажується. Якщо сам продукт пропонує користувачеві визначити поточний тип мережі, як Приватна/Довірена – буде вибрано цей варіант. Якщо продукт має функцію оновлення, воно виконується. Перевіряється, щоб продукт був зареєстрований у Центрі підтримки Windows як системний брандмауер, і сам продукт показував, що він працює належним чином. За допомогою другого ПК перевіряється підключення до існуючої приватної мережі наступним чином:

• Ping hostname -4
• Ping hostname -6
• Ping IPv4 address
• Ping IPv6 address
• File share hostname
• File share IPv4 address
• Remote Desktop (RDP) hostname
• Remote Desktop (RDP) IPv4 address
• Remote Desktop (RDP) IPv6 address

Перевіряється, щоб усі ці форми віддаленого доступу працювали для забезпечення повної функціональності тестового ПК у приватній мережі та його максимального контролю. Після цього вимикається комп'ютер і роутер, до якого було підключено, і знову запускається ПК. Потім він підключається до іншої WLAN-мережі, яка визначається як Загальнодоступна (Громадська) WNSC, використовуючи діалогове вікно Брандмауера Windows.

Якщо фаєрвол показує запит на визначення типу мережі, встановлюється значення «Громадська» або «Недовірена». Більше не робиться жодних змін у налаштуванні продукту.

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

Порівняльне тестування 21 популярного фаєрволу на якість захисту від атак, що виходять зсередини системи. У тесті проводилася перевірка захисту на 64 спеціально розроблених для нього тестових утилітах, що перевіряють захист процесів від завершення, захист від стандартних внутрішніх атак, захист від нестандартних витоків та захисту від нестандартних технік проникнення в режим ядра.

Поряд з антивірусом, фаєрвол є одним із головних компонентів забезпечення безпеки комп'ютера. Проте, на відміну антивірусів, об'єктивні тести роботи фаєрволів проводяться досить рідко. Цей пробіл ми спробували закрити, провівши в 2011 і 2012 роках тест фаєрволів на захист від внутрішніх атак і тест персональних IDS/IPS на захист від атак на вразливі програми. Цього року ми вирішили розширити список методів, що використовуються, і повторити тест фаєрволів на захист від внутрішніх атак, щоб подивитися, як за минулий час змінилися результати популярних продуктів за даним критерієм.

На що спрямований цей тест чи які функції виконує фаєрвол? За визначенням інтернет-стандарту [RFC3511] (2003 р.), фаєрвол – це система, що реалізує функції фільтрації мережевих пакетів відповідно до заданих правил з метою розмежування трафіку між сегментами мережі. Однак, зі зростанням складності шкідливих програм і атак хакерів, вихідні завдання фаєрвола доповнилися новими функціональними модулями. Вже фактично неможливо уявити повноцінний фаєрвол без модуля HIPS (моніторингу системних подій, контролю цілісності системи тощо).

Головне завдання сучасного фаєрволу – здійснювати блокування неавторизованих мережевих комунікацій (далі – атак), що підрозділяються на внутрішні та зовнішні. До таких відносяться:

Зовнішні атаки на захищену фаєрволом систему:

• ініційовані хакерами;
• ініційовані шкідливим кодом.

• ініційовані недовіреними додатками (шкідливий код);
• ініційовані додатками, мережна активність яких явно заборонена правилами.

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

Тест фаєрвола на захист від зовнішніх атак включає вивчення якості захисту від атак, що виходять зсередини системи. Тест проводився за такими напрямами:

1. Перевірка захисту процесів від завершення.
2. Захист від стандартних внутрішніх атак.
3. Тестування захисту від нестандартних витоків.
4. Тестування захисту від нестандартних техніки проникнення в режим ядра.

Порівняно з попереднім тестом істотно розширилася кількість атак, що використовуються - з 40 до 64. Також змінювалася операційна система, захист якої повинні здійснювати тестовані продукти. У минулому тесті це була Windows XP, а в цьому тесті – Windows 7 x32. Також до кінця року планується аналогічний тест для операційної системи Windows 7 x64.

Вступ

У тестуванні брала участь 21 популярна програма комплексного захисту (класу Internet Security, якщо в лінійці такого продукту немає, то вибирався суто фаєрвол) від різних виробників актуальних на дату початку тестування версій продуктів (травень 2013) та працюючих на платформі Windows 7 x32 :

1. Avast! Internet Security (8.0.1488).
2. AVG Internet Security (2013.0.3272).
3. Avira Internet Security (13.0.0.3499).
4. Bitdefender Internet Security (16.29.0.1830).
5. Comodo Internet Security (6.1.276867.2813).
6. Dr.Web Security Space (8.0).
7. Eset Smart Security (6.0.316.0).
8. F-Secure Internet Security (1.77 build 243).
9. G Data Internet Security (1.0.13113.239).
10. Jetico Personal Firewall (2.0).
11. Kaspersky Internet Security (13.0.1.4190 (g).
12. McAfee Internet Security (11.6.507).
13. Kingsoft Internet Security (2009.05.07.70).
14. Microsoft Security Essentials (4.2.223.0) + Windows Firewall.
15. Norton Internet Security (20.3.0.36).
16. Online Armor Premium Firewall (6.0.0.1736).
17. Outpost Security Suite Pro (8.0 (4164.639.1856)).
18. Panda Internet Security (18.01.01).
19. PC Tools Internet Security (9.1.0.2900).
20. Trend Micro Titanium Internet Security (6.0.1215).
21. TrustPort Internet Security (2013 (13.0.9.5102)).

Перед початком тесту проводилася підготовка середовища тестування. Для цього на чистий комп'ютер встановлювалась операційна система Windows 7 Enterprise SP1 x86 з усіма доступними на цей момент оновленнями, а також додатковим програмним забезпеченням, необхідним для тесту.

Тестування проводилося на двох типах налаштувань: рекомендованих виробником стандартних (за замовчуванням) і максимальних. У першому випадку використовувалися рекомендовані виробниками установки за замовчуванням і проводилися всі рекомендовані програмою дії.

У другому випадку на додаток всі налаштування, які були відключені в режимі «за замовчуванням», але при цьому могли вплинути на результат тестування, включалися та/або наводились у максимальне положення (найсуворіші налаштування). Іншими словами – під виставленням максимальних налаштувань розуміється переведення всіх доступних з графічного інтерфейсу користувача налаштувань всіх модулів, пов'язаних з детектуванням шкідливої ​​файлової або мережевої активності, до найсуворішого варіанту.

Тест фаєрволів проводився за наступними групами внутрішніх атак для наочності розбитих на рівні складності:

1. Базовий рівень складності (56 варіант атак):

1. перевірка захисту процесів від завершення (41 варіант атак);
2. захист від стандартних внутрішніх атак (15 варіантів атак).

2. Підвищений рівень складності (8 варіантів атак):

1. тестування захисту від нестандартних витоків (3 варіанти атак);
2. тестування захисту від нестандартних технік проникнення режим ядра (5 варіантів атак).

Детальний опис всіх методів атаки, що використовуються в тесті, ви можете знайти у методології тестування.

Перевірка фаєрволів на захист від внутрішніх атак

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

У таблиці 1-2 та на малюнку 1-2 представлені результати тестування фаєрволів окремо на стандартних та максимальних налаштуваннях. Для наочності результати для кожного фаєрволу розбиті на дві групи: захист від атак базового рівня складності та захист від атак підвищеного рівня складності.

Таблиця 1: Результати тесту фаєрволів на стандартних налаштуваннях

Малюнок 1: Результати тесту фаєрволів на стандартних налаштуваннях

Захист від внутрішніх атак на рекомендованих виробником налаштуваннях залишає бажати кращого. Лише три фаєрволи змогли подолати поріг 80% на стандартних налаштуваннях – це Comodo, Online Armor та Norton. Досить близько до них розміщуються продукти Jetico (79%) та Outpost (74%). Результати інших фаєрволів виявилися значно гіршими.

Порівняно з результатами минулого тесту всі лідери підтвердили свої високі результати, відбулися лише невеликі переміщення в лідируючій групі, наприклад Outpost і Jetico помінялися позиціями. Єдиним несподіванкою став продукт Norton, який у минулому тесті показав результат у 45% і був у нижній частині таблиці, а цьому тесті з 80% посів третю позицію.

Отримані результати пов'язані з тим, що багато виробників виставляють стандартні установки таким чином, щоб зменшити кількість повідомлень, на які повинен реагувати користувач. Це підтверджує і результатами тесту – на стандартних налаштуваннях фаєрволи ставили питання користувачам лише у 5,4% атак, а на максимальних – у 9,2% атак. Однак це позначається на якості захисту, який «промовчить» у ситуації, коли шкідлива програма імітуватиме/виконуватиме цілком легітимні дії в системі.

Також слід звернути увагу до дві закономірності. По-перше, відсоток запобігання складним видам атак загалом помітно гірший, ніж атак базового рівня складності. Більше половини таких атак відхилили лише чотири продукти - Comodo, Online Armor, Norton та Jetico. Ще чотири продукти увійшли до граничної групи, відхиливши від 25% до 38% таких атак – це Outpost, Trend Micro, Kaspersky та Dr.Web. Решта продуктів відхилила не більше однієї складної атаки. По-друге, покращилися показники відбиття базових атак. Якщо минулого тесті 11 (50%) продуктів відхилили менше 50% атак, то цьому тесті таких продуктів лише 3 (14%).

Таблиця 2: Результати тесту фаєрволів на максимальних налаштуваннях

Рисунок 2: Результати тесту фаєрволів на максимальних налаштуваннях

При включенні максимальних налаштувань якість захисту від внутрішніх атак у багатьох протестованих фаєрволів значно зросла. Особливо це помітно у міцних середняків. Усі лідери минулого тесту у цьому тесті також показали високі результати. Зі змін варто відзначити продукт Bitdefender, який поряд з Comodo, показав 100% результат і продукт Norton, що перемістився в лідируючу групу.

Результати ряду продуктів на стандартних та максимальних налаштуваннях виявилися однаковими. Це пов'язано з тим, що ці продукти не мають налаштувань, здатних вплинути на результати нашого тесту.

Порівняння якості захисту на стандартних та максимальних налаштуваннях

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

Для наочності ми наводимо підсумкові результати тесту фаєрволів зі стандартними та максимальними налаштуваннями в таблиці 3 та малюнку 3.

Таблиця 3: Зведені результати тесту фаєрволів на стандартних та максимальних налаштуваннях

Рисунок 3: Зведені результати тесту фаєрволів на стандартних та максимальних налаштуваннях

Малюнок 3 дуже наочно демонструє різницю у результатах тесту залежно від вибраних налаштувань.

По-перше, лише два продукти – Comodo та Online Armor показують близькі до максимальних показники захисту, як на стандартних, так і на максимальних налаштуваннях.

По-друге, при зміні стандартних налаштувань запропонованих виробником частина продуктів показує істотно кращий рівень захисту. Найбільш яскраво це видно на таких продуктах як Bitdefender, Kaspersky, Eset, F-Secure та PC Tools.

По-третє, як уже зазначалося вище, деякі з протестованих продуктів зовсім не мають налаштувань, які будь-яким чином могли б вплинути на результати тесту. Тому їх результати на всіх типах налаштувань у цьому тесті однакові. До цієї групи належить Jetico, Avast, AVG, McAffe, F-Secure, Panda, Kingsoft та Microsoft.

У підсумковій оцінці не враховуються ситуації, коли атака була відображена, проте при цьому виникали проблеми з інтерфейсом користувачів. У більшості випадків проблеми полягали в "вилітанні" інтерфейсу на нетривалий час (від 2 до 10 секунд) або до наступного завантаження операційної системи. Незважаючи на те, що при проблемах з інтерфейсом користувача продукти продовжували забезпечувати захист, наявність таких проблем суб'єктивно сприймається негативно і може впливати на переваги у виборі продуктів. Кількість проблем з інтерфейсом користувача представлена ​​в таблиці 3 і на малюнку 3. Оцінювалися помилки, що виникають при атаках 1 рівня, загальна кількість яких - 41.

Таблиця 4: Кількість проблем з інтерфейсом користувача на стандартних і максимальних налаштуваннях

Рисунок 4: Кількість проблем з інтерфейсом користувача на стандартних і максимальних налаштуваннях

Отримані результати показують, що у продуктів McAfee і Microsoft проблеми з інтерфейсом користувача виникали при більшості атак (понад 80%). Це може бути неприйнятним рівнем, т.к. практично будь-яка успішно відбита атака призведе до проблем. Досить погані результати, що лежать у діапазоні від 30% до 50%, показують продукти Kingsoft, F-Secure, Panda, Jetico та PC Tools. При їх використанні кожна 2-3 атаки призводитимуть до проблем з інтерфейсом. Ще ціла низка продуктів показують результати від 10% до 30%, які можна назвати задовільними. Хороші результати показали продукти Avira, Dr.Web, Kaspersky та Online Armor, проблеми у яких виникали в діапазоні від 2% до 5% атак. Єдиним продуктом, у якого жодного разу не виникло проблем з інтерфейсом користувача був Comodo на максимальних налаштуваннях, що можна визнати відмінним результатом. Однак при стандартних налаштуваннях результат Comodo погіршується (12%), що говорить про те, що використання цього продукту потребує певних знань щодо його налаштування.

Підсумкові результати тесту та нагороди

Так само, як і в попередньому тесті, ми не усереднювали результати того самого продукту з різними налаштуваннями, а розглядати їх незалежно один від одного. Таким чином, кожен із протестованих продуктів може отримати дві нагороди, по одній на кожному виді налаштувань.

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

Таблиця 5: Підсумкові результати тесту фаєрволів на стандартних та максимальних налаштуваннях

Найкращі результати в тесті показали фаєрволи Comodo та Bitdefender, які набрали 100% балів на максимальних налаштуваннях. Ці два продукти отримують нагороду PlatinumFirewallOutboundProtectionAward.

Дуже високі результати у тесті (понад 80%) також показали фаєрволи Online Armor, Kaspersky, Comodo, Norton, PC Tools, Outpost, Eset та Dr.Web, які отримують нагороди GoldFirewallOutboundProtectionAward. Важливо відзначити, що Comodo отримав цю нагороду на стандартних налаштуваннях, Online Armor і Norton на стандартних та максимальних налаштуваннях, а решта – тільки на максимальних налаштуваннях.

Далі за списком розташувалася група із семи фаєрволів, чиї результати потрапляють у діапазон від 60% до 70%. Це Outpost, Kaspersky та Dr.Web на стандартних налаштуваннях; TrustPort та G DATA на максимальних налаштуваннях, а також Jetico та Trend Micro одночасно на стандартних та максимальних налаштуваннях. Усі вони отримують нагороду

Достатньо велика група продуктів, що потрапили в діапазон від 60% до 70%, отримує нагороду. У ній слід відзначити продукти Eset і Bitdefender на стандартних налаштуваннях, які на максимальних налаштуваннях змогли відбити значно більшу кількість атак.

Ознайомитись з докладними результатами тесту та переконатися у правильності підсумкових розрахунків можна, завантаживши результати тесту у форматі Microsoft Excel.

Шабанов Ілля, керуючий партнер сайт:

«Дуже втішив той факт, що дуже багато виробників помітно покращили проактивний захист від внутрішніх атак і самозахист у своїх продуктах. Нам довелося навіть переглянути схему нагородження, щоби підняти планку вимог. Результат менше ніж 51% балів тепер став розглядатися як повністю провальний.

Приємно здивував, що Bitdefender відбив у параноїдальному режимі всі 100% атак, Eset і Dr.Web з результатами на максимальних налаштуваннях 85% до 80% відповідно, а також новачок наших тестів TrustPort. До «золотої групи» продуктів за результатами цього тесту потрапили фаєрволи Comodo, Norton і Online Armor, які набрали більше 80% на стандартних та максимальних налаштуваннях. Стабільно високі результати в тестах, що стосуються проактивного захисту, продемонстрували Kaspersky, Outpost, PC Tools.

Однак у разі низки протестованих продуктів незрозуміла логіка, за якою виставляються стандартні настройки. Внаслідок цього рівень захисту більшості користувачів, які звикли використовувати захист зі стандартними налаштуваннями, виявляється суттєво заниженим. Насамперед це стосується продуктів Bitdefender, Kaspersky, Eset і PC Tools».

Картавенко Михайло, керівник тестової лабораторії сайт:

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

По-перше, у середньому більшість продуктів показали кращі результати, ніж 1.5 роки тому, проте зробили вони це в основному за рахунок відбиття найпростіших атак 1 рівня. Складніші атаки «по зубах» лише обмеженому колу продуктів.

По-друге, навіть якщо спрацював захист процесів від завершення (1 рівень атак), у багатьох продуктів «вилітає» інтерфейс користувача. Це ставить користувача в незручне становище, в якому він не розуміє – чи працює захист, чи вже ні.

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

Таким чином, тест виявив «больові» точки сучасних фаєрволів, вирішення яких може покращити їхній захист».

Розділ оновлюється щоденно. Завжди свіжі версії найкращих безкоштовних програм для повсякденного використання у розділі Необхідні програми. Там практично все, що потрібне для повсякденної роботи. Почніть поступово відмовлятися від піратських версій на користь більш зручних та функціональних безкоштовних аналогів. Якщо Ви все ще не користуєтеся нашим чатом, радимо з ним познайомитися. Там ви знайдете багато нових друзів. Крім того, це найбільш швидкий та дієвий спосіб зв'язатися з адміністраторами проекту. Продовжує працювати розділ Оновлення антивірусів – завжди актуальні безкоштовні оновлення для Dr Web та NOD. Чи не встигли щось прочитати? Повний зміст рядка , що біжить , можна знайти за цим посиланням .

Безкоштовний фаєрвол Comodo. Тестування, висновки

Comodo Firewall у роботі

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

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

Через кілька днів після встановлення Comodo Firewall я вирішив його трохи потестувати.

Тест №1. Онлайн-тестування

При натисканні на кнопку "Test" програма намагається встановити зв'язок із сервером сайту.

Оскільки цю утиліту Comodo Firewall ще не знає, то при першій її спробі вирватися в інтернет була негайна реакція з боку проактивного захисту і фаєрволу:

В обох випадках я натиснув заблокувати та отримав підтвердження про успішне проходження тесту:

Потім я перейменував файл FireWallTest.exeв opera.exeта підмінив їм стандартний файл Опери. Таким чином, я спробував обдурити Comodo Firewall, який вже добре знає цей браузер і постійно автоматично випускає його в інтернет. На запуск «фальшивої» Опери з Тотала Comodo відреагував так:

Отримавши мій дозвіл на одноразовий запуск, фаєрвол попередив мене про спробу виходу Опери в інтернет:

Виходить, що будь-яка програма, для якої вже існують правила, у разі заміни виконуваного файлу без мого відома вийти в інтернет не зможе. Начебто все добре, але яка штука: колір верхньої частини вікна з попередженням залежить від серйозності ситуації. Якщо Comodo оцінює подію як критичну, колір буде червоним, якщо подія менш небезпечна – жовтою. У моєму випадку Comodo вважав змодельовану ситуацію не особливо небезпечною і запалив «жовтий». До того ж замість формулювання «виконуваний файл opera.exeне впізнаний» я б вважав за краще побачити що «відбулася зміна параметрів файлу opera.exe”. Так попереджають у подібних ситуаціях комбайни від Касперського та Eset, наприклад. Причому користувач бачить вікно тривоги з використанням червоного кольору, що відразу змушує звернути увагу на ситуацію. А попередження від Comodo може бути просто проігноровано користувачем через недостатній акцент на подію, що відбувається.

Підміна файлу Опери була лише частиною мого підступного плану. Наступною жертвою став Internet Explorer 6, який інтегрований в операційну систему, а отже, iexplore.exeможна вважати повноправним системним файлом. Яке ж було моє здивування, коли під повне мовчання Comodo я побачив вікно про провал тесту:

Мабуть, створено зайве правило, вирішив я і поліз у політики фаєрволу та проактивного захисту. Покопавшись там хвилин 15, я прийняв єдине правильне рішення - перевстановити Comodo. Сказано зроблено. Залишивши режими роботи за умовчанням, я повторив досвід із заміною iexplore.exe. На запуск із Тоталу проактивний захист спрацював, як і у випадку з Оперою:

Тут доведеться зробити невеликий ліричний відступ. Справа в тому, що при заміні виконуваного файлу IE система протягом 4-8 секунд відновлює оригінальний iexplore.exe. У зв'язку з цим результати мого тесту залежали від того, чи встигає підмінений файл постукати в інтернет чи ні.

У випадку, коли я встигаю зробити всі маніпуляції до відновлення explore.exe, відбувається таке. Отримавши мій дозвіл на одноразовий запуск explore.exe, Тотал запускає утиліту FireWallTest, тисну "Test", проактивний захист Defens+ видає попередження:

Якщо дозволяємо (як експеримент) - відпрацьовує фаєрвол:

Встигаємо натиснути «Блокувати» – тест пройдено, утиліта в інтернет не проскочила. А от якщо iexplore.exeвідновлено до того, як натиснули кнопку блокування – від Вашого вибору вже нічого не залежить – утиліта автоматично отримує доступ інтернет у момент відновлення оригінального файлу.

Те саме стосується і роботи проактивного захисту: якщо не встиг скомандувати блокувати до відновлення explore.exe- Утиліта автоматично отримує доступ в інтернет.

Вдосталь награвшись з фальшивим IE, я згадав про перший провал тесту, коли Comodo промовчав і випустив «лівий» файл в інтернет. Перевстановивши Comodo, я перевів Defense+ та фаєрвол у режим навчання та запустив IE. Після цього повернув режими, виставлені за умовчанням, та повторив тест. Comodo його знову мовчки провалив...

Тест №3. Дуель

Під враженням від результатів попереднього тесту, я шукав додаткові можливості протестувати Comodo і, нарешті, знайшов утиліту AWFT.

Ця програмка емулює поведінка троянів і містить серію з шести тестів, що демонструють різні методики неавторизованого доступу в мережу, минаючи захист фаєрволу. Серед цих тестів є як старі способи обману фаєрволів, так і сучасніші методики. За кожен успішно пройдений тест фаєрволу нараховується кілька балів. Якщо тест не пройдено, бали нараховуються на користь AWFT. Максимальна кількість балів – десять.

Утиліта є умовно-безкоштовною, обмеження – 10 запусків. У верхній частині вікна програми розташовані кнопки, що запускають відповідні тести, внизу вказаний сайт, куди прориватиметься AWFT, і результат дуелі між фаєрволом та утилітою. Кнопка Reset Points використовується для скидання набраних очок.

Про всяк випадок я вирішив поміняти адресу сайту на свою.

Тестування відбувалося при включеному Comodo Firewall та Defense+, запущеному Оперою та відключеним монітором Авіри.

У першому тесті використано прийом із завантаженням прихованої копії браузера та пропатчуванням пам'яті перед його запуском.

При натисканні кнопки тесту вискочило вікно з помилкою:

Після закриття цього вікна Сomodo відреагував на тест вікном запиту, при натисканні кнопки «Блокувати» AWFT, трохи задумавшись, віддала перше очко фаєрволу.

За твердженням розробників утиліти, тест №2 - це старий і давно відомий трюк. Comodo знову реагує на вікно запиту і знову отримує очко.

У тесті №3 також використовують старий трюк. Comodo просто мовчки його блокує, мабуть, трюк справді відомий.

Тест №4 аналогічний першому тесту із запуском прихованої копії браузера та пропатчуванням пам'яті перед його запуском. Фаєрвол не видав жодних застережень, але через невелику паузу отримав чергове очко.

Під час п'ятого і шостого тесту необхідно перейти в браузер і трохи посерфінгувати (я просто оновлював завантажену сторінку в браузері).

У тесті №5 утиліта виконує евристичний пошук встановленого на комп'ютері (або в мережі) дозволеного програмного забезпечення, що має доступ до інтернету через порт 80, потім запускає копію дозволеної програми і перед самим запуском патчить пам'ять, яку займає ця програма (тобто, AWFT запускає і саму себе у пам'яті дозволеної програми). Comodo мовчки впорався з тестом і отримав за нього цілих 3 очки.

Тест №6 аналогічний до попереднього п'ятого тесту. Використовується той самий прийом з евристичним пошуком встановленого софту, що має право виходити назовні через порт 80. Тільки спосіб злому зараз змінено - використовується запит користувача. Принагідно з цим AWFT намагається приліпити до браузера лівий потайний тулбар. При відкритій Опері у мене вискочило таке вікно:

У момент підтвердження мною цього запиту користувача Comodo видав свій запит, утиліта була знову заблокована, а фаєрвол отримав 3 очки собі в залік.

Підсумок дуелі – 10:0 на користь Comodo. Повторивши тести з відкритим Internet Explorer, я отримав ті самі результати.

Висновок

Незважаючи на деякий неприємний осад у душі, що залишився після тестування фаєрволу, я все ж рекомендую Comodo Internet Security для домашнього використання, але тільки як фаєрвол. І не слухайте тих розумників, які радять відключати проактивний захист, у жодному разі! Тільки з використанням Defense+ цей фаєрвол справді забезпечує безпеку Вашого комп'ютера. А ось що дійсно не слід використовувати, то це антивірус від Comodo. Мало того, що він пристойно пропускає, у Вас виникнуть проблеми з його оновленням - дуже вже громіздкі бази у нього. До того ж, він пристойно впливає на швидкодію системи. У мене просто чудово працювали в парі Comodo Firewall та Avira Antivir Personal.

Гальм і глюків у системі під час роботи фаєрволу мною виявлено не було. Свої роздуми про результати мого тестування я поки що залишу при собі, хочеться послухати Ваші коментарі.

Під час написання заключної частини цієї статті я натрапив на результати нещодавнього тестування фаєрволів лабораторією Matousec. Comodo Internet Security виявився єдиним фаєрволом зі 100-відсотковим результатом (див. форум фаєрволів). Що ж, я зробив свій вибір... А Ви?

плюси (явні):
безкоштовне розповсюдження,
наявність власної бази даних програм;
наявність проактивного захисту (Defense+);
простота установки та початкового налаштування;
дуже інформативне та зручне вікно зі зведенням;

плюси (сумнівні):
наявність кількох режимів роботи;

мінуси (явні):
дратівливий режим інсталяції;
підміна виконуваного файлу не визначається проактивним захистом як критичну подію;

мінуси (сумнівні):
відверто невдалий антивірус.

У цій другій статті описується вирішення проблем, пов'язаних із пакетним фільтром. Замість приведення готової таблиці у вигляді «проблема»-«рішення» наводяться методи системного підходу для вирішення проблем.

У цій другій статті (в серії з трьох) описується вирішення проблем, пов'язаних із пакетним фільтром. Замість приведення готової таблиці у вигляді «проблема»-«рішення» наводяться методи системного підходу для вирішення проблем.

Вступ

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

Загалом, у курсі цього розділу ми порівнюватимемо завдання написання набору правил фільтрації з програмуванням. Якщо ж у вас немає навичок програмування, це порівняння здасться вам швидше ускладнює завдання. Але ж саме по собі написання правил не вимагає наявності наукового ступеня щодо «computer science» чи досвіду програмування, чи не так?

Відповіддю буде «ні», цього вам, напевно, не потрібно. Мова, яка використовується для конфігурації пакетного фільтра, зроблена схожою на людські мови. Наприклад:

block all

pass out all keep state

pass in proto tcp to any port www keep state

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

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

Гарна політика фільтрації.

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

Таким чином, першим кроком у конфігурації файрвола буде неформальне завдання того, чого необхідно досягти. Які з'єднання необхідно блокувати чи пропускати?

Прикладом буде:

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

$ext_if - у зовнішню мережу.

$dmz_if - DMZ із серверами.

$lan_if - LAN із робочими станціями.

Хости в LAN повинні вільно з'єднуватися з будь-якими хостами в DMZ або зовнішній мережі.

Сервери DMZ повинні вільно з'єднуватися з хостами у зовнішній мережі. Хости зовнішньої мережі можуть з'єднуватися лише до наступних серверів у DMZ:

Web-сервер 10.1.1.1 порт 80

Mail-сервер 10.2.2.2 порт 25

Всі інші з'єднання повинні бути заборонені (наприклад, від машин у зовнішній мережі до машин LAN).

Ця політика виражена неформально, так, щоб будь-хто читає міг її зрозуміти. Вона має бути настільки конкретизована, щоб у читача легко формулювалися відповіді питання виду 'Чи повинно пропускатися з'єднання від хоста X до хосту Y входить (чи вихідне) на інтерфейсі Z?'. Якщо ви задумалися про ті випадки, коли ваша політика не відповідає такій вимогі, то вона недостатньо чітко задана.

«Туманні» політики на кшталт «дозволяти тільки все, що життєво необхідно» або «блокувати атаки», необхідно уточнювати, або ви не можете застосувати або перевірити їх. Як і в розробці програмного забезпечення, недостатньо формалізовані завдання рідко призводять до виправданих або коректних їх реалізації. («Чому б вам не піти вже почати писати код, а я поки що з'ясую, що потрібно замовнику»).

Набір правил, що реалізує політику

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

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

Другий тип помилок називається «помилки часу виконання» (run-time errors), так як виникає при синтаксично коректно записаної програмі, яка успішно трансльована і виконується. У загальному випадку, в мовах програмування, таке може статися, коли програмою виконується розподіл на нуль, робиться спроба звернутися до неприпустимих областей пам'яті або виникає нестача пам'яті. Але оскільки набори правил лише віддалено нагадують функціонал мов програмування, більшість з подібних помилок не може виникнути під час застосування правил, наприклад правила не можуть викликати т.зв. "падіння системи", як це роблять звичайні програми. Однак набір правил може викликати подібні помилки, як блокування або навпаки, пропускання пакетів, що не відповідають політиці. Це іноді називається логічною помилкою, помилкою яка не викликає винятку та зупинки, а просто видає невірні результати.

Отже, перед тим, як ми можемо почати перевіряти, наскільки коректно файрвол реалізує нашу безпекову політику, необхідно спочатку успішно завантажити набір правил.

Помилки аналізатора

Помилки аналізатора виникають при спробі завантаження списку правил з використанням pfctl, наприклад:

# pfctl -f /etc/pf.conf

/ etc/pf.conf:3:syntaxerror

Це повідомлення говорить про те, що у рядку 3 файлу /etc/pf.conf синтаксична помилка та pfctl не може завантажити правила. Набір у ядрі не змінився, він залишився таким самим, як і до спроби завантажити новий.

Є багато різновидів помилок, що видаються pfctl. Для початку знайомства з pfctl необхідно просто уважно читати їх. Можливо, не всі частини повідомлення відкриють свій зміст вам відразу, але необхідно прочитати їх усі, т.к. згодом це полегшить розуміння того, що ж пішло не так. Якщо у повідомленні є частина виду "ім'я файлу: число: текст", воно посилається на сточку з відповідним номером у вказаному файлі.

Наступним кроком подивимося на виданий рядок, використовуючи текстовий редактор (у vi ви можете перейти до 3 рядка, ввівши 3G в режимі beep), або так:

# cat -n /etc/pf.conf

1 int_if = "fxp 0"

2 block all

3 pass out on $int_if inet all kep state

pass out inet on $int_if all kep state

Проблема може бути в простий друкарській помилці, як у цьому випадку (“kep” замість “keep”). Після виправлення спробуйте перезавантажити файл:

# pfctl -f /etc/pf.conf

/ etc/pf.conf:3:syntaxerror

# head -n 3 /etc/pf.conf | tail -n 1

pass out inet on $int_if all keep state

Тепер усі ключові слова вірні, але при найближчому розгляді ми помічаємо, що розташування ключового слова “inet” перед “on $int_if” неправильне. Це ілюструє те, що один рядок може містити більше однієї помилки. Pfctl виводить повідомлення про першу знайдену помилку та припиняє своє виконання. Якщо при повторному запуску було видано той же номер рядка, значить у ньому є ще помилки, або попередні не були коректно усунені.

Неправильно розташовані ключові слова також є поширеною помилкою. Це може бути виявлено при порівнянні правила з еталонним BNF-синтаксисом наприкінці файлу довідки man pf.conf(5), яка містить:

pf-rule= action [ ("in" | "out") ]

["log" | "log-all" ] [ "quick" ]

[ "on" ifspec ] [ route ] [ af ] [ protospec ]

hosts [ filteropt-list ]

ifspec = (["!"] interface-name) | "(" interface-list ")"

af = "inet" | "inet6"

Що означає, що ключове слово “inet” має йти за “on $int_if”

Підправимо і спробуємо ще раз:

# pfctl -f /etc/pf.conf

/ etc/pf.conf:3:syntaxerror

# head -n 3 /etc/pf.conf | tail -n 1

pass out on $int_if inet all keep state

Жодних очевидних помилок тепер не залишилося. Але нам не видно всіх супутніх деталей! Рядок залежить від макровизначення $inf_if. Що може бути неправильно визначено?

# pfctl -vf /etc/pf.conf

int_if = "fxp 0"

block drop all

/etc/pf.conf:3: syntax error

Після виправлення друкарської помилки «fxp 0» на «fxp0» пробуємо ще раз:

# pfctl -f /etc/pf.conf

Відсутність повідомлень свідчить про те, що файл успішно завантажено.

У деяких випадках pfctl може видавати більш специфічні повідомлення про помилки, ніж просто syntax error:

# pfctl -f /etc/pf.conf

/etc/pf.conf:3: port only applies to tcp/udp

/etc/pf.conf:3: skipping rule due to errors

/etc/pf.conf:3: rule expands to no valid combination

# head -n 3 /etc/pf.conf | tail -n 1

pass out on $int_if для port ssh keep state

Перший рядок повідомлення про помилку є найбільш інформативним порівняно з іншими. І тут проблема у цьому, що правило, вказуючи порт, не визначає протокол - tcp чи udp.

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

# pfctl -f /etc/pf.conf

/etc/pf.conf:2: whitespace after \

/etc/pf.conf:2: syntax error

# cat -ent /etc/pf.conf

1 block all$

2 pass out on gem0 from any to any \ $

3 ^ Ikeepstate$

Тут проблемою є символ пробілу, після «бекслеша» але перед кінцем другого рядка, позначеним знаком $ у виведенні cat -e.

Після того, як набір правил успішно завантажений, непогано подивитися на результат:

$cat /etc/pf.conf

block all

# pass from any to any \

pass from 10.1.2.3 to any

$ pfctl -f /etc/pf.conf

$ pfctl -sr

blockdropall

«Бекслеш» наприкінці рядка коментаря насправді означає, що рядок коментаря буде продовжено нижче.

Розгортання списків укладених у фігурні дужки () може видати результат, який, можливо, вас здивує, а заразом і покаже оброблений аналізатором набір правил:

$cat /etc/pf.conf

pass from ( !10.1.2.3, !10.2.3.4 ) to any

$ pfctl -nvf /etc/pf.conf

pass inet from! 10.1.2.3 to any

pass inet from! 10.2.3.4toany

Тут загвоздка у цьому, що вираз " ( !10.1.2.3, !10.2.3.4 ) " означатиме «всі адреси, крім 10.1.2.3 і 10.2.3.4», розгорнуте вираз саме собою означає збіг з будь-яким можливим адресою.

Ви повинні перезавантажити свій набір правил після перманентних змін, щоб переконатися, що і pfctl зможе завантажити його при перезавантаженні машини. В OpenBSD стартовий rc-скрипт із /etc/rc насамперед завантажує невеликий набір правил, встановлений за замовчуванням, який блокує весь трафік, за винятком необхідного на етапі завантаження (такого як dhcp або ntp). Якщо ж скрипт не зможе завантажити реальний набір правил /etc/pf.conf через синтаксичні помилки, внесені до перезавантаження машини без перевірки, то набір «за замовчуванням» залишиться активним. На щастя, у цьому наборі дозволено вхідні ssh з'єднання, тому проблему можна буде вирішити віддалено.

Тестування

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

Є лише два шляхи неправильного спрацьовування правил: блокування з'єднань, які мають пропускатися і навпаки, пропускання з'єднань, які мають блокуватися.

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

З'єднання з LAN в DMZ (має пропускатися)

з LAN у зовнішню мережу (має пропускатися)

з DMZ до LAN (має блокуватися)

з DMZ у зовнішню мережу (має пропускатися)

із зовнішньої мережі в DMZ до 10.1.1.1 на порт 80 (має пропускатися)

із зовнішньої мережі в DMZ до 10.1.1.1 на порт 25 (має блокуватися)

із зовнішньої мережі в DMZ до 10.2.2.2 на порт 80 (має блокуватися)

із зовнішньої мережі в DMZ до 10.2.2.2 на порт 25 (має пропускатися)

із зовнішньої мережі до LAN (має блокуватися)

Очікуваний результат має бути визначено у цьому списку до початку тестування.

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

TCP та UDP з'єднання можуть бути перевірені за допомогою nc. nc може використовуватися як клієнтська та серверна частина (використовуючи опцію -l). А для ICMP запитів та відповідей, найкращим клієнтом для перевірки буде ping.

Для перевірки факту блокування з'єднання можна використовувати будь-які засоби, які намагатимуться створювати з'єднання із сервером.

Використовуючи інструменти з колекції портів, такі як nmap, ви легко зможете просканувати безліч портів навіть на кількох хостах. Якщо результати виглядають не зовсім зрозуміло, не полінуйтеся заглянути в сторінку. Наприклад, для TCP порту сканер повертає значення 'unfiltered', коли nmap отримує RST від pf. pf, встановлений на одній машині зі сканером, може привносити свій вплив на коректність роботи nmap.

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

Для перевірки того, що фільтром пропускаються з'єднання, задані в політиці, найкращим методом буде перевірка з використанням тих додатків, які згодом і будуть використовуватися клієнтами. Так, перевірка проходження http-з'єднань з різних машин-клієнтів веб-сервера, а також з різних браузерів та вибірка різного контенту буде кращою, ніж просто підтвердження встановлення TCP сесії до nc, що працює як серверна частина. Різні чинники, такі, як операційна система хоста, можуть викликати помилки - проблеми з масштабуванням TCP-вікна (TCP window scaling) чи відповідями TCP SACK між певними операційними системами.

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

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

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

Коли ви спостерігаєте результат, відмінний від очікуваного, покроково відзначте ваші кроки під час тесту, чого ви очікували, чому ви цього очікували, отриманий результат і як результат відрізняється від ваших очікувань. Повторіть тест, щоб побачити, чи відтворюється ситуація, або відрізняється раз на раз. Спробуйте змінювати вхідні параметри перевірки (адреса джерела/приймача чи порти).

З моменту, коли ви отримали відтворювану проблему, необхідно приступити до налагодження, щоб з'ясувати, чому все працює не так, як ви очікували, і як все полагодити. З цією установкою, ви повинні змінити набір правил і повторити всі тести, включаючи ті, які не викликали помилок, тому що, змінюючи правила, ви могли ненавмисно торкнутися роботи правильно працюючих частин набору правил.

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

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

Налагодження

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

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

Не завжди проблеми мережі можуть бути викликані пакетним фільтром. Перед тим, як сфокусувати увагу на налагодженні конфігурації pf, необхідно переконатися, що проблема викликана пакетним фільтром. Це легко зробити, а також допоможе зберегти час на пошук несправності в іншому місці. Просто вимкніть pf командою pfctl -d і перевірте, чи виявляється проблема знову. Якщо це так, увімкніть команду pfctl -e і подивіться, що відбувається. Цей метод не пройде в деяких випадках, наприклад, якщо pf не робить правильну трансляцію мережевих адрес (NAT), виключення pf очевидно не позбавить вас від помилки. Але в тих випадках, коли це можливо, спробуйте переконатися, що винен саме пакетний фільтр.

Відповідно, якщо проблема в пакетному фільтрі, перше, що необхідно зробити, це переконатися, що pf дійсно працює і успішно завантажений потрібний набір правил:

# pfctl -si | grep Status

Status: Enabled for 4 days 13:47:32Debug: Urgent

# pfctl -sr

pass quick on lo0 all

pass quick on enc0 all

Налагодження за протоколами

Наступним кроком налагодження буде відображення проблеми у конкретних мережних з'єднаннях. Якщо ви маєте посилку: "не працює обмін миттєвими повідомленнями в додатку X", потрібно з'ясувати, які з'єднання мережі використовуються. Висновок може бути у вигляді "хост А не може встановити з'єднання з хостом B на порту С". Іноді це завдання представляє найбільшу складність, але якщо у вас є інформація про потрібні з'єднання і ви знаєте, що файрвол їх не пропустить, потрібно буде лише змінити правила для вирішення цієї проблеми.

Є кілька шляхів для з'ясування протоколів або з'єднань, що використовуються додатком. Tcpdump може відобразити пакети, що прибувають або залишають як реальний мережевий інтерфейс, так і віртуальні, такі як pflog і pfsync. Ви можете задати вираз для фільтрації, щоб задати пакети для відображення та виключити побічний мережевий шум. Спробуйте встановити мережеве з'єднання в потрібній програмі і подивіться на пакети, що надсилаються. Наприклад:

# tcpdump -nvvvpi fxp0 tcp and not port ssh and not port smtp

23:55:59.072513 10.1.2.3.65123 > 10.2.3.4.6667: S

4093655771:4093655771(0) win 5840

1039287798 0, nop, wscale 0> (DF)

Це пакет TCP SYN, перший пакет із встановлюваного TCP з'єднання (TCP handshake).

Відправник - 10.1.2.3 порт 65123 (виглядає як випадковий непривілейований порт), а одержувач 10.2.3.4 порт 6667. Детальне пояснення формату виведення tcpdump ви знайдете на сторінках посібника з утиліти. Tcpdump – найважливіший інструмент для налагодження проблем, пов'язаних з pf, і дуже важливо познайомитися з ним ближче.

Інший метод - використання функції ведення лог-файлів у pf. Вважаючи, що ви використовуєте опцію 'log' у всіх правилах з 'block', тоді всі пакети заблоковані pf будуть відображені в лозі. Можна видалити опцію 'log' із правил, що мають справу з відомими протоколами, тобто. записуватимуться в лог лише ті пакети, які йдуть на невідомі порти. Спробуйте використати програму, яка не може встановити зв'язок і загляньте в pflog:

# ifconfig pflog0 up

# tcpdump -nettti pflog0

Nov 26 00:02:26.723219 rule 41/0(match): block in on kue0:

195.234.187.87.34482 > 62.65.145.30.6667: S 3537828346:3537828346(0) win

16384 (DF)

Якщо ви використовуєте pflog - демона, який постійно прослуховує pflog0 і зберігає отриману інформацію /var/log/pflog, збережену інформацію можна побачити так:

# tcpdump -netttr /var/log/pflog

Коли виводите збережені pf пакети, можна використовувати додаткові вирази для фільтрації, наприклад, переглянути пакети, які були заблоковані на вході на інтерфейсі wi0:

# tcpdump -netttr /var/log/pflog inbound and action block and on wi0

Деякі протоколи, такі як FTP, не так легко відстежити, оскільки вони не використовують фіксовані номери портів, або використовують кілька співіснуючих з'єднань. Можливо, неможливо пропустити їх через файрвол без відкриття широкого діапазону портів. Для окремих протоколів існують рішення, подібні до ftp-proxy.

Налагодження правил

Якщо ваш набір правил блокує конкретний протокол, тому що ви не відкрили потрібний порт, це більше проблема стадії проектування, ніж баг у правилах. Але що якщо ви бачите, що блокується з'єднання для якого у вас є його правило, що пропускає?

Наприклад, ваш набір містить правило

block in return-rst on $ext_if proto tcp from any to $ext_if port ssh

Але коли ви намагаєтеся приєднатися до TCP порту 22, з'єднання приймається! Схоже, що файрвол ігнорує ваше правило. Як і в складання «пазлів», у цих випадках, коли з ними стикаєшся перші кілька разів, існує просте логічне і, як правило, тривіальне пояснення.

Перше, ви повинні перевірити всі ті кроки, про які йшлося раніше. Наприклад, припустимо, що файрвол працює і містить правило, наведене вище. Малоймовірно, що мають місце наші попередні побоювання, але це легко перевірити:

# pfctl -si | grep Status

Status: Enabled for 4 days 14:03:13Debug: Urgent

# pfctl -gsr | grep "port=ssh"

@14 block return-rst на kue0 inet proto tcp from any to 62.65.145.30 port = ssh

Наступне, що ми: приймаються з'єднання TCP на порт 22 на kue0. Можна подумати, що це й так очевидно, але не зайвим буде перевірити. Запустіть tcpdump:

# tcpdump -nvvvi kue0 tcp and port 22 and dst 62.65.145.30

Тепер повторіть з'єднання SSH. Ви повинні побачити пакети з вашого з'єднання у виводі tcpdump. Можливо ви їх не бачите, а це може бути через те, що з'єднання насправді не проходить через kue0, а проходить через інший інтерфейс, що пояснює, чому не спрацьовує правило. Або ви, можливо, з'єднуєтеся з іншою адресою. Якщо коротко, то якщо ви не бачите ssh пакети, то pf їх також не побачить, можливо не може їх заблокувати використовуючи правило, наведене в нашому завданні.

Але якщо ви бачите пакети за допомогою tcpdump, pf їх теж побачить і буде їх фільтрувати. Наступним припущенням буде те, що блокуюче правило має не просто бути присутнім у наборі (що ми вже з'ясували), а бути останнім правилом для потрібних пакетів. Якщо це не останнє правило, очевидно, відповідно до цього не приймається рішення про затримання пакетів.

У яких випадках правило може бути не останнім, що збігається правилом? Можливі три причини:

А) правило не спрацьовує, оскільки перегляд правил не сягає потрібного нам.

Раніше присутнє правило також спрацьовує та викликає припинення виконання опцією 'quick';

Б) обробка правила проводиться, але правило не спрацьовує через розбіжності окремих критеріїв.

В) обробка правила проводиться, правило спрацьовує, але обробка продовжується і наступні правила також спрацьовують для пакета.

Щоб відкинути ці три випадки ви можете, дивлячись на завантажений набір правил подумки уявити обробку гіпотетичного TCP пакета, що приходить на інтерфейс kue0 і порт 22. Виділіть блок, що налагоджується. Почніть обхід із першого правила. Збігається? Якщо так – позначте його. Чи має вона опцію 'quick'? Якщо так, то припиняємо обхід. Якщо ж ні, продовжуємо з наступним правилом. Повторюйте перевірку, до знаходження збігу з опцією quick або досягнення кінця набору правил. Яке правило збіглося останнім? Якщо це правило номер 14, ви знайшли пояснення проблеми.

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

Інший метод, це використання здатності pf вести логи для ідентифікації випадків А або С. Додайте 'log' до всіх правил з 'pass quick' перед 14 правилом. Додайте 'log' до всіх правил з 'pass', що стоять після 14-го правила. Запустіть tcpdump для інтерфейсу pflog0 та встановлюйте з'єднання ssh. Ви побачите, які правила крім 14ого спрацьовують на ваших пакетах останнім. Якщо у лозі нічого немає, значить має місце випадок Б.

Відстеження з'єднань через файрвол

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

Перше, ви повинні з'ясувати, у якому із чотирьох випадків проблема. Якщо ви спробуєте встановити з'єднання, ви повинні побачити пакет TCP SYN на першому інтерфейсі, використовуючи tcpdump. Ви також повинні побачити той же TCP SYN пакет на виході з другого інтерфейсу. Якщо ви його не бачите, отже, укладаємо, що pf блокує вхідний пакет на першому інтерфейсі або виходить на другому.

Якщо SYN посилка не блокується, ви повинні будете бачити SYN+ACK, що приходить на другий інтерфейс і виходить з першого. Якщо ні – pf блокує SYN+ACK на якомусь інтерфейсі.

Додайте опцію log до правил, які повинні пропускати SYN і SYN+ACK на обох інтерфейсах, також до правил, які повинні їх блокувати. Повторіть спробу з'єднання та перевірте pflog. Він повинен прояснити, у якому випадку відбувається блокування та яким правилом.

Налагодження станів з'єднань

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

У меншій кількості випадків трапляється так, що pf «мовчки» відкидає пакети, ґрунтуючись не на правилах, і тут додавання 'log' у всі правила не призведе до потрапляння скинутих пакетів у pflog. Часто пакет майже, але не повністю підпадає під запис у таблиці станів (state entry).

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

Запис у таблиці станів містить інформацію, що відноситься до одного з'єднання.

Кожен запис має унікальний ключ. Цей ключ складається з кількох значень, які обмежують постійний черездовг життя з'єднання. Ось вони:

• Тип адреси (IPv4 або IPv6)
• Адреса джерела
• Адреса приймача
• Протокол (TCP UDP)
• Порт джерела
• Порт приймача

Цей ключ використовується для всіх пакетів, що належать до одного і того ж з'єднання, і пакети різних з'єднань завжди будуть мати різні ключі.

Коли опцією 'keep state' із правила створюється запис у таблиці станів, запис про з'єднання зберігається з допомогою ключа даного соединения. Важливе обмеження для таблиці станів – всі ключі мають бути унікальними. Тобто. не може бути двох записів із однаковими ключами.

Ті ж два хоста не можуть встановити кілька співіснуючих з'єднань використовуючи ті ж адреси, протоколи та порти, але це є фундаментальна властивість як TCP так і UDP. Фактично, стеки TCP/IP лише можуть асоціювати окремі пакети зі своїми сокетами виконуючи вибірку, засновану на адресах і портах.

Навіть якщо з'єднання закрито, та ж пара адрес і портів не може бути знову задіяна відразу ж. Мережним обладнанням можуть пізніше доставлятися повторно передані пакети, і якщо стеком TCP/IP одержувача вони будуть помилково прийняті за пакети новоствореного з'єднання, це завадить або розірве нове з'єднання. З цієї причини обидва хости повинні почекати певний проміжок часу, званий 2MSL («подвійний час життя сегмента», «twice the maximum segment lifetime») перед тим, як знову мати можливість використовувати ті ж адреси та порти для нового з'єднання.

Ви можете спостерігати цю властивість, вручну встановлюючи кілька з'єднань до одного і того ж хосту. Наприклад, маючи веб-сервер, що працює на 10.1.1.1 і порту 80, і двічі приєднуючись з 10.2.2.2. використовуючи nc:

$ nc -v 10.1.1.1 80 & nc -v 10.1.1.1 80

Connection to 10.1.1.1 80 port succeeded!

У той час, поки з'єднання відкриті, можете за допомогою netstat на клієнті або сервері вивести інформацію про ці з'єднання:

$netstat-n | grep 10.1.1.1.80

tcp 0 0 10.2.2.6.28054 10.1.1.1.80 ESTABLISHED

tcp 0 0 10.2.2.6.43204 10.1.1.1.80 ESTABLISHED

Як бачите, клієнт вибрав два різні (випадкові) порти-джерела, тому це не порушує вимоги до унікальності ключів.

Ви можете вказати nc використовувати певний порт-джерело опцією -p:

$ nc -v -p 31234 10.1.1.1 80 & nc -v -p 31234 10.1.1.1 80

Connection to 10.1.1.1 80 port succeeded!

nc: bind failed: Address already in use

TCP/IP стек клієнта запобіг порушенням унікальності ключів. Деякі рідкісні та хибні реалізації TCP/IP стеків не відповідали цьому правилу, і тому, як ми скоро побачимо, pf заблокує їх з'єднання при порушенні унікальності ключів.

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

incomingTCPвід 10.2.2.2:28054to 10.1.1.1:80

Запит до таблиці виявить такі записи у таблиці станів:

incoming TCP from 10.2.2.2:28054 to 10.1.1.1:80

outgoing TCP from 10.1.1.1:80 to 10.2.2.2:28054

Запис у таблиці включає інформацію про направлення (вхідний або вихідний) першого пакета, який створив запис. Наприклад, такі записи не викликають збігу:

outgoingTCPвід 10.2.2.2:28054to 10.1.1.1:80

incomingTCPвід 10.1.1.1:80to 10.2.2.2:28054

Причина цих обмежень є очевидною, але досить простою. Уявіть, що у вас всього один інтерфейс з адресою 10.1.1.1, де веб-сервер здійснює прослуховування порту 80. Коли клієнт 10.2.2.2 приєднується, використовуючи випадково вибраний вихідний порт 28054, перший пакет з'єднання приходить на ваш інтерфейс і всі ваші відповіді повинні йтимуть з 10.1.1.1:80 на 10.2.2.2:28054. Ви ж не пропускатимете вихідні пакети з 10.2.2.2:28054 до 10.1.1.1:80, оскільки такі пакети не мають сенсу.

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

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

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

Тепер ми також зможемо пояснити різницю між вільним і приєднаним до інтерфейсу з'єднанням. За замовчуванням pf створює записи, які не прив'язані до жодного інтерфейсу. Тому, якщо ви дозволяєте з'єднання на одному інтерфейсі, пакети, що відносяться до з'єднання та підпадають під запис у таблиці (включаючи інформацію про направлення пакета!), проходять через будь-який інтерфейс. У найпростіших інсталяціях зі статичною маршрутизацією це більше теоретичні викладки. В принципі, ви не повинні бачити пакети одного з'єднання, що прибувають через кілька інтерфейсів і пакети у відповідь, що йдуть також на кілька інтерфейсів. Проте за динамічної маршрутизації таке можливе. Ви можете прив'язати записи про стани до конкретного інтерфейсу, використовуючи глобальну установку 'set state-policy if-bound' або опцією для кожного правила 'keep state (if-bound)'. Так ви будете впевнені, що пакети будуть підпадати під запис тільки з інтерфейсу, який ці записи створив.

Якщо використовується інтерфейси для тунелів, то те саме з'єднання проходить через файрвол кілька разів. Наприклад, перший пакет з'єднання спочатку може пройти через інтерфейс A, потім через B, потім С і нарешті залишити нас через інтерфейс D. Зазвичай пакети будуть інкапсульовані на інтерфейсах A і D і декапсулюються на B і C, тому pf бачить пакети різних протоколів і ви можете створити 4 різні записи в таблиці станів. Без інкапсуляції пакет буде незмінений на всіх чотирьох інтерфейсах і ви не зможете використовувати деякі можливості, як трансляцію адреси або модуляцію номера tcp послідовності, тому що це призведе до появи таблиці станів конфліктуючих ключів. До тих пір, поки у вас не буде закінченої установки, що включає інтерфейси з тунелюванням та налагодженими помилками виду "pf: src_tree insert failed", ви не зможете вважати свою інталяцію досить успішною. Повернемося до запиту до таблиці станів, що виробляється кожному пакету перед перевіркою правил. Запит повинен повернути єдиний запис із відповідним ключем, або не повернути нічого. Якщо запит нічого не повертає, здійснюється обхід списку правил.

Якщо ж запис знайдено, другим кроком для пакетів TCP, перед тим як вони почнуть вважатися такими, що належать конкретному з'єднанню і піддадуться фільтрації, буде перевірка номера послідовності.

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

Для успішної атаки атакуючому необхідно правильно «відгадати» кілька параметрів з'єднання, таких як адреса/порт джерела та приймача. І для широко поширених протоколів це може бути не так уже й складно, як може здатися. Якщо атакуючий знає адреси хостів і один з портів (оскільки мова йде про поширений сервіс), йому потрібно лише вгадати один порт. Навіть якщо клієнт використовує по-справжньому випадковий порт-джерело (що насправді не завжди вірно), атакуючому потрібно лише перебрати 65536 портів за короткий проміжок часу. (У більшості випадків навіть (65536-1024) портів, тобто тільки непривілейовані порти - прим. перекладача))

Але ось що по-справжньому важко вгадати для нападаючого, так це вірний номер послідовності (і його підтвердження). Якщо обидва хоста вибирають початковий номер послідовності випадковим чином (або ви використовуєте модуляцію номера послідовності для хостів, які мають "слабкий" генератор ISN (Initial Sequence Number)), то атакуючого не вдасться підібрати відповідне значення в потрібний момент з'єднання.

Під час існування валідного TCP з'єднання номерів послідовностей (і підтвердження) для окремих пакетів змінюються згідно з певними правилами.

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

pf використовує правила, щоб визначити найменший діапазон легітимних номерів послідовностей. У загальному випадку, pf може точно визначити справжність тільки 30 000 з 4294967296 можливих номерів послідовності в будь-який момент з'єднання. Тільки якщо номер послідовності та підтвердження входить у це вікно, pf переконається, що пакет легітимний і пропустить його.

Якщо під час проведення запиту до таблиці станів знайдено відповідний запис, наступного кроку номери послідовностей пакетів, збережених у таблиці, перевіряються на входження до діапазону можливих значень. У разі невдачі порівняння pf згенерує повідомлення "BAD state" і відкине пакет без обчислення набору правил. Є дві причини, через які може статися порівняння з правилами: майже напевно буде помилкою пропуск пакету, т.к. якщо обчислення набору призведе до потрапляння до правила на опцію "keep state" і pf не зможе винести рішення і створити новий запис тому що це призведе до появи ключів, що конфліктують, в таблиці.

Для того щоб бачити і записувати в лог повідомлення "BAD state", вам необхідно включити режим налагодження використовуючи команду:

$ pfctl -xm

Відлагоджувальні повідомлення за замовчуванням потрапляють на консоль, також syslogd записує їх у /var/log/messages. Шукайте повідомлення, що починаються на "pf":

pf:BADstate:TCP 192.168.1.10:20 192.168.1.10:20 192.168.1.200:64828

[ lo=1185380879high=1185380879win=33304modulator=0wscale=1]

4:4 A seq=1185380879 ack=1046638749 len=1448 ackskew=0 pkts=940:631

dir=out,fwd

pf: State failure on: 1 |

Ці повідомлення завжди йдуть парами. Перше повідомлення показує запис у таблиці станів у момент, коли пакет був заблокований та номери послідовності пакета, що спричинив помилку. Другий запис відображає умови, які були порушені.

Наприкінці першого повідомлення ви побачите, чи було створено запис стану на вхідний (dir=in) чи вихідний (dir=out) пакет, і чи йшов заблокований пакет у тому напрямі (dir=,fwd) чи протилежному (dir=,rev ) напрямі.

Запис у таблиці містить три адреси: пари портів, дві з яких завжди рівні між собою, якщо з'єднання не зазнало перетворення nat, rdr або bnat. Для вихідних з'єднань джерело виводиться ліворуч, а приймач пакета праворуч. Якщо вихідне з'єднання перетворює адресу джерела, пара в середині показує джерело після перетворення. Для вхідних з'єднань джерело знаходиться праворуч у виведенні, а адреса призначення посередині. Якщо вхідне з'єднання перетворюється на адресу призначення, пара ip/port зліва показує приймач після проведеного перетворення. Цей формат відповідає висновку pfctl -ss, що тією лише різницею, що pfctl показує напрямок пакета використовуючи стрілки.

У виведенні ви можете бачити поточні номери послідовності у хостів у квадратних дужках. Так значення "4:4" означає, що з'єднання встановлено повністю (менші значення більш ймовірні на етапі встановлення з'єднання, більші - на момент закриття з'єднання)."A" означає, що заблокований пакет мав встановлений прапор ACK (так само як і у виведенні прапорів у tcpdump), далі йдуть значення номерів послідовностей (seq=) та (ack=) у заблокованих пакетах та довжина корисного навантаження пакета - довжина даних (len =). askskew це частина внутрішнього представлення даних у таблиці, що задіюється тільки при значеннях не рівних нулю.

Запис "pkts=930:631" означає, що з ним збіглося 940 пакетів, що йшли напрузі, збігаються з пакетом, що викликало створення даного запису, і 631 пакет у протилежному напрямку. Ці лічильники будуть особливо корисні при пошуку проблем на етапі встановлення з'єднання, якщо один з них дорівнює нулю, це суперечитиме вашому очікуванню того, що з цим записом збігаються пакети, що йдуть в обох напрямках.

Наступне повідомлення містить список з однієї або декількох цифр. Кожна цифра є перевіркою, на якій сталася помилка:

1. розмір вікна пакета перевищує максимальний розмір одержувача (seq + len > high)
2. пакет містить вже передані дані (seq< lo - win)
3. ackskew менше мінімального значення
4. ackskew більше максимального значення
5. те, що і в (1), але з різницею (seq + len > high + win)
6. те, що і в (2), але (seq< lo - maximum win)

На щастя, повідомлення "BAD state" не відносяться до реального повсякденного трафіку і перевірка номера pf послідовності дозволяє не зіткнутися з більшістю аномалій. Якщо ви бачите ці повідомлення, що з'являються нерегулярно і не помічаєте велику кількість з'єднань, що підвисли, ви можете просто їх ігногрувати. В інтернеті працює безліч реалізацій TCP/IP і деякі з них можуть іноді генерувати помилкові пакети.

Однак, цей клас проблем може бути легко діагностований за появою повідомлень "BAD state", що з'являються тільки в подібних випадках.

Створення записів станівTCP за початковимSYN пакет.

В ідеалі, записи станів повинні створитися при появі першого пакета SYN.

Ви можете примусово увімкнути використання цього правила, користуючись принципом:

"Використовувати опції "flags S/SA" у всіх правилах "pass proto tcp keep state""

Тільки початкові пакети SYN (і тільки вони) мають встановлений прапор SYN і зібраний ACK. Коли застосування опції "keep state" прив'язується тільки до початкових пакетів SYN, тільки ці пакети будуть створювати записи в таблиці станів. Таким чином, будь-яка існуюча запис у таблиці станів буде зроблена від початкового SYN пакета.

Причиною створення записів лише за початковими пакетами є розширення протоколу TCP під назвою "масштабування вікна" (“window scaling”), визначене RFC1323. Поле заголовка TCP, що використовується для сповіщення про розмір прийнятих вікон, замало для сьогоднішніх високошвидкісних ліній зв'язку. Сучасні реалізації TCP/IP віддають перевагу використанню великих значень розміру вікна, ніж може вміститися в існуючому полі. Масштабування розміру вікна означає, що всі розміри вікон, про які відомо від хоста-отримувача, повинні бути помножені на певне значення, задане одержувачем, а не взяті власними силами. Для того, щоб дана схема запрацювала, обидва хости повинні підтримувати розширення і позначити один для одного можливість реалізації його на етапі встановлення з'єднання ("handshake") використовуючи опції TCP. Ці опції представлені лише у початкових пакетах SYN та SYN+ACK. І тільки якщо кожен із цих пакетів містить опцію, взаємоузгодження буде успішним і розмір вікна всіх наступних пакетів буде множитися на коефіцієнт.

Якби pf “не знав” про використовуване масштабування вікна, бралося б значення без коефіцієнта, і обчислення розмірів вікна для прийнятних значень номерів послідовності проводилося б неправильно. У типовому випадку хости на початку з'єднання надають малі значення розмірів вікна та збільшують їх у процесі з'єднання. Не підозрюючи про існування факторів, що змінюють розмір вікна, pf з деякого моменту почне блокування пакетів, тому що вважатиме, що один з хостів намагається обійти наданий “співрозмовником” максимальний розмір вікна. Ефекти від цього можуть бути більш менш помітні. Іноді хости відреагують на втрату пакетів переходом у т.зв. “loss recovery mode” (“режим повторної передачі”) та анонсуватимуть менший розмір вікна. Після того, як pf повторно передасть відкинуті вперше пакети, розміри вікон будуть зростати далі, до точки в якій pf знову почне їх блокувати. Зовнішнім проявом може бути тимчасове зависання з'єднань та низька продуктивність. Можливе повне зависання або скидання з'єднань по таймууту.

Але pf знає можливість масштабування вікон і підтримує таку можливість. Як би там не було, передумовою для створення записів у таблицю станів за першими SYN пакетами буде те, що pf може асоціювати перші два пакети з'єднання із записом у таблиці. Оскільки повне узгодження коефіцієнтів розміру вікон має місце лише цих перших двох пакетах, немає надійного методу визначити ці коефіцієнти після узгодження з'єднання.

У минулому масштабування розмірів вікна використовувалося не так широко, але ситуація швидко змінюється. Тільки нещодавно в Linux включено цю опцію за замовчуванням. Якщо ви відчуваєте труднощі із зависаючими з'єднаннями, особливо з деякими комбінаціями хостів і бачите повідомлення "BAD state" стосовно цих з'єднань, перевірте, що ви дійсно створюєте записи для таблиці станів по перших пакетах з'єднання.

Ви можете визначити, чи pf опцію масштабування використовує для з'єднання з висновку pfctl:

$ pfctl -vss

kue0 tcp 10.1.2.3:10604 -> 10.2.3.4:80 ESTABLISHED:ESTABLISHED

wscale 0wscale 1

Якщо присутній запис "wscale x" виведений у другому рядку (навіть якщо x дорівнює нулю), pf зачитає знає, що з'єднання використовує масштабування.

Інший простий метод для виявлення проблем пов'язаних з масштабуванням це тимчасове вимикання підтримки масштабування та відтворення ситуації. В OpenBSD використання масштабування може керуватися опцією sysctl:

$ sysctlnet.inet.tcp.rfc1323

net.inet.tcp.rfc1323=1

$ sysctl -wsysctlnet.inet.tcp.rfc1323=0

net.inet.tcp.rfc1323: 1 -> 0

Подібні проблеми виникають коли ви створюєте записи в таблиці станів пакетів, відмінних від початкових SYN і використовуєте опцію "moulate state" або трансляцію. В обох випадках трансляція проводиться на початку з'єднання. Якщо перший пакет не трансльований, транчляція наступних зазвичай бентежить приймаючу сторону і призводить до того, що надіслані відповіді блокуються pf з повідомленням "BAD state".