Linux IPCHAINS-HOWTO Різне
Цей розділ містить всю інформацію та FAQ, який я не міг вставити в наведену вище структуру.
Це питання потребує деяких роздумів. Ви можете спробувати організувати їх, щоб оптимізувати швидкодію (мінімізувати кількість правил-перевірок для більшості пакетів) або збільшити керованість.
Якщо у вас непостійний зв'язок, скажімо зв'язок PPP, то ви могли б захотіти встановити перше правило в ланцюжку input "-i ppp0 -j DENY' під час завантаження системи, тоді поміщаємо щось таке у ваш скрипт ip-up: А в скрипт ip- down:
Перш ніж ви почнете фільтрувати зовнішній трафік, вам потрібно знати кілька речей.
ICMP пакети
ICMP пакети використовуються (крім іншого) для індикації станів інших протоколів (типу TCP та UDP). Пакети "destination-unreachable" зокрема. Блокування цих пакетів означає, що ви ніколи не отримаєте повідомлень про помилки "Host unreachable" або "No route to host"; будь-які з'єднання будуть тільки чекати на відповідь, яка ніколи не прийде. Це дратує, але несмертельно.
Також зверніть увагу на ICMP повідомлення перенаправлення (тип 5); вони можуть використовуватися для управління маршрутизацією (хоча хороші IP стеки захищені), і вважаються трохи небезпечними.
TCP з'єднання з DNS (сервером імен)
Якщо ви спробуєте заблокувати вихідні TCP з'єднання, не забудьте, що DNS не завжди використовує UDP; якщо пакет у відповідь від сервера перевищує 512 байтів, клієнт використовує TCP з'єднання (також на порту номер 53).
DNS в цьому випадку буде "загалом працювати"; ви можете виявити дивні довгі затримки та інші випадкові DNS проблеми.
Якщо ваші DNS запити завжди надсилаються на один і той же зовнішній джерело (або безпосередньо, звикористанням рядка nameserver в /etc/resolv.conf, або з використанням forward в кешуючому сервері імен), то вам потрібно лише дозволити TCP з'єднання між портом domain на цьому сервері імен і локальним портом domain (при використанні кешируючого сервера імен) або з портом з великим номером (>1023) під час використання /etc/resolv.conf.
Жахи FTP
Класична проблема при пакетній фільтрації – FTP. FTP має два режими; Традиційний викликається активним режимом і найсучасніший називається пасивним режимом. Web-браузери зазвичай за замовчуванням працюють у пасивному режимі, але консольні програми FTP зазвичай за промовчанням працюють у активному режимі.
В активному режимі, коли віддалена сторона хоче надіслати файл (або навіть результати команд ls або dir), вона намагається відкрити TCP з'єднання з локальною машиною. Це означає, що ви не можете фільтрувати ці TCP з'єднання без переривання активного FTP.
Якщо у вас є опція використання пасивного режиму, то все чудово; Пасивний режим створює з'єднання від клієнта до сервера, навіть для вхідних даних. Вам рекомендується дозволити лише TCP з'єднання з номерами портів більше 1024 і не 6000.6010 (використовуються для XWINDOWS).
Linux-машини тепер несприйнятливі до відомого Пінг Смерті, який полягає в посилці надто великого ICMP пакета, який переповнює буфера TCP-стека на машині-приймачі і призводить до хаосу.
Якщо ви захищаєте машини, які могли б бути вразливими для "пінгу смерті", то ви можете просто фрагментувати блоки ICMP. Нормальний ICMP пакети не настільки великі, щоб вимагати фрагментації, так що фрагментуватимуться лише дуже великі пакети - такі як "пінги смерті". Я чув (за неперевіреними даними), що деякі системи можутьпостраждати і від останніх фрагментів великих пакетів ICMP, тому рекомендується фрагментувати як перший фрагмент.
Хоча всі відомі програми, що використовують цю атаку, генерують ICMP-пакети, для тієї ж мети можна використовувати TCP або UDP-пакети (або невідомий протокол), тому цей захист може служити лише як тимчасовий захід.
Teardrop і Bonk - дві атаки (головним чином проти машин Windows NT Microsoft), які покладаються на фрагменти, що накладаються. Вирішується це дефрагментацією пакетів на маршрутизаторі або забороною прийому фрагментованих пакетів на вразливих машинах.
Говорять, у деяких "менш надійних" TCP стеках є проблеми, що виникають при великій кількості фрагментів пакетів, коли на машину приходять не всі фрагменти. У Linux немає цієї проблеми. Ви можете фільтрувати фрагменти (що може відбитися і на нормальних пакетах) або скомпілювати ваше ядро з опцією "IP: always defragment "Y"" (тільки в тому випадку, якщо ваша машина Linux - єдиний маршрут для цих пакетів).
Бувають ситуації, коли треба на льоту змінити правила фаєрволу. Необережно, ви можете пропустити деякі пакети під час змін правил. Спрощений підхід полягає в наступному: На час внесення змін пакети відкидатимуться.
Якщо ваші зміни стосуються лише одного ланцюжка, то можна створити новий ланцюжок з новими правилами, а потім замінити ("-R") правило, яке вказує на старий ланцюжок, на те, яке вказує на новий ланцюжок; потім ви можете видалити старий ланцюжок. Ця заміна станеться атомарно.
Якщо він існує, можна вмикати Source Address Verification під час завантаження. Щоб це зробити, вставте наступні рядки в скрипти ініціалізації перед ініціалізацією мережевих інтерфейсів:
Такий підхід не такий гарний як Source Address Verification, тому що якщо ваші мережеві налаштування змінилися, ви повинні змінити правила фільтра.
Для ядер 2.0 вам бажано захистити і петльовий інтерфейс:
Існує userspace бібліотека, написана мною, яка включена у вихідний дистрибутив, звана "libfw". Вона використовує можливість IP ланцюжків 1.3 і вище копіювати пакет у userspace (використовуючи опцію ядра IP_FIREWALL_NETLINK).
Значення мітки може використовуватися визначення параметрів Quality of Service пакетів, чи визначення, який порт треба відфорвардити пакети. Я ніколи не користувався ні тим, ні іншим, але якщо ви хочете написати про це, будь ласка, зв'яжіться зі мною.
Використовуючи цю бібліотеку можуть бути виконані в userspace речі типу stateful перевірки (я волію термін динамічний firewalling). Інші красиві ідеї полягають в управлінні пакетами на основі користувача за допомогою userspace daemon. Це має бути досить просто.
SPF: Stateful фільтрація пакетів
ftp://ftp.interlinx.bc.ca/pub/spf - це сайт SPF проекту Brian Murrell'а, який здійснює трекінг з'єднання в userspace. Це значно покращує захист низькопродуктивних сайтів.
В даний час документація досить скупа, але є список поштового розсилки, в якому Брайєн відповів на деякі запитання: > Я вважаю, це робить точно те, що мені потрібно: установка тимчасового > "зворотного"-правила, щоб дозволити приходити пакетам як би відповіддю на > вихідний запит.
Так, саме це він робить. Більшість протоколів його розуміють, більш "зворотні" правила it gets right. Прямо зараз він підтримується для (говорю навскидку, заздалегідь вибачаюсь за помилки або пропуски) FTP (і активного,і пасивного і вхідного та вихідного), деяких RealAudio, traceroute, ICMP і основного ICQ (що входить від ICQ сервера та прямих TCP з'єднань, проте вторинні прямі TCP з'єднання для операцій типу передач файлів тощо поки немає)
> Це заміна ipchains чи додавання?
Це – додавання. ipchains - це засіб обмеження проходження пакетів через Linux машину. SPF - драйвер, що постійно контролює трафік і повідомляє ipchains як змінювати політику фільтрації для відображення змін у шаблонах трафіку.
Хак Michael Hasenstein'а для ftp-data
Michael Hasenstein з SuSE написав патч для ядра, який додає до ipchains трекінг ftp-з'єднань. Зараз його можна знайти на http://www.csn.tu-chemnitz.de/
У ядрах 2.3 firewalling та NAT розробляються повторно. Плани та обговорення можна знайти в архіві netdev та списку розсилки ipchains-dev. Ці розширення повинні прояснити багато проблем застосування (firewalling і маскарадинг не повинні бути такими жорсткими) і дозволити створити набагато більш гнучкий firewalling.