Це мій переклад, оригінал статі дивіться за цим посиланням: https://home.regit.org/netfilter-en/secure-use-of-helpers/
Автори: Eric Leblond, Pablo Neira Ayuso, Patrick McHardy, Jan Engelhardt, Mr Dash Four
Вступ
Принцип модулів системи відстеження з’єднань (helpers)
Деякі протоколи використовують окремі потоки, наприклад один для керування, а другий для передачі даних.
Серед багатьох, яскравим прикладом є протоколи FTP, SIP та H.323. За звичай на стадії встановлення з’єднання, керуючий потік використовується для узгодження параметрів зв’язку потоку передачі даних ( наприклад IP адреса та порт). Цей тип протоколів складно фільтрувати фаерволом, так як порушено стандарт шарів OSI, в цьому випадку, параметри шарів 3/4 ми бачимо на 7 рівні.
Для того, щоб вирішити цю ситуацію фаерволом iptables, Netfilter постачає допоміжні модулі (helpers) для системи відстеження з’єднань (nf_conntrack), які допоможуть фаерволу відслідкувати ці протоколи. Ці модулі створюють так звані “очікування” (expectation), як визначенно жаргоном проекту Netfilter.
“Очікування” схожі на записи в системі відстеження з’єднань, але вони зберігаються в окремій таблиці, та за звичай мають обмежений термін дії. “Очікування” використовуються для повідомлення ядра, що в найближчі секунди, якщо пакет з відповідними параметрами дістанеться до фаервола, то цей пакет RELATED (відносний) до попередього з’єднання.
Пакети такого типу, можуть бути авторизовані, спасибі таким модулям як state чи conntrack що можуть “впізнати” ці пакети як RELATED.
Ця система покладається на розбір даних, які прийшли від користувача чи сервера. Модулі дуже вразиві для атак, та потрібно приділяти велику увагу, при використанні допоміжних модулів.
Налаштування модулів за замовченням
Через обмеження протоколів, не всі модулі однакові. Наприклад FTP модуль створює “очікування” чиї IP параметри, це два учасника. IRC модуль створює “очікування” де адреса отримувача це адреса клієнта, а адреса джерела може бути будь-яка. Це через протокол: ми не знаємо, який IP адрес у персони яка є об’єктом DCC.
Ступінь свободи залежить від природи протоколу. Деякі протоколи мають небезпечні розширення, тому вони вимкненні за замовченням в Netfilter. Користувач повинен передати параметр під час завантаження модуля, для включення небезпечних можливостей протоколу. Наприклад, протокол FTP може дозволити користувачу, вказати цільовому серверу, щоб той з’єднався з будь-яким довільним сервером. Це може призвести до дірки в DMZ, і тому за замовченням ця можливість вимкнена. Для того, щоб ввімкнути її, треба передати модулю параметр loose зі значенням 1.
Наступний лист, описує різницю в допоміжних модулях системи відстеження з’єднань, та їх ступінь свободи:
[table]
Модуль,Адреса відправника,Порт відправника,Адреса отримувача,Порт отримувача,Протокол,Опції
amanda,Fixed,0-65535,Fixed,In CMD,TCP
ftp,Fixed,0-65535,In CMD,In CMD,TCP,loose = 0 (default)
ftp,Full,0-65535,In CMD,In CMD,TCP,loose = 1
h323,Fixed,0-65535,Fixed,In CMD,UDP
h323 q931,Fixed,0-65535,In CMD,In CMD,UDP
irc,Full,0-65535,Fixed,In CMD,TCP
netbios_ns,Iface Network,Fixed,Fixed,Fixed,UDP
pptp,Fixed,In CMD,Fixed,In CMD,GRE
sane,Fixed,0-65535,Fixed,In CMD,TCP
sip rtp_rtcp,Fixed,0-65535,Fixed,In CMD,UDP,sip_direct_media = 1 (default)
sip rtp_rtcp,Full,0-65535,In CMD,In CMD,UDP,sip_direct_media = 0
sip signalling,Fixed,0-65535,Fixed,In CMD,In CMD,sip_direct_signalling = 1 (default)
sip signalling,Full,0-65535,In CMD,In CMD,In CMD,sip_direct_signalling = 0
tftp,Fixed,0-65535,Fixed,In Packet,UDP
[/table]
- Fixed – це значення атрибуту системи выдстеження з’єднань. Воно не може бути кандидатом на фальсіфікацію.
- In CMD – значення витягнуто з блоку даних (payload). Воно може бути кандидатом на фальсіфікацію.
- У стовпчику, опції для завантаження модулів. Вони дозволяють ввімкнути небезпечні розширені можливості протоколів.
Безпечне використання допоміжних модулів системи відстеження з’єднань
Пілся попередніх зауважень, виходить, що сліпо використовувати допоміжні модулі не можна. Ви повинні брати до уваги топологію вашої мережі, під час налаштування модулів.
Потрібно для кожного модуля, дуже обережно відчиняти відносні (RELATED) потоки. Усі правила iptables, повинні використовувати “-m conntrack –ctstate RELATED” в поєднанні з вибором допоміжого модуля та параметрами IP. Роблячи це, ви будете в змозі описати, яким чином модуль повинен бути використаний, по відношенню до вашої мережевої та інформаційної архітектури.
Приклад: модуль FTP
Якщо ви запустили FTP сервер, використовуйте таке правило:
[code]iptables -A FORWARD -m conntrack –ctstate RELATED -m helper \\
–helper ftp -d $адреса_мого_сервера -p tcp \\
–dport 1024: -j ACCEPT[/code]
Якщо ваші клієнти мають право отримати доступ до зовнішніх FTP серверів, то можна додати такі правила
[code]iptables -A FORWARD -m conntrack –ctstate RELATED -m helper \\
–helper ftp -o $зовнішній_інтерфейс -p tcp \\–dport 1024: -j ACCEPT
iptables -A FORWARD -m conntrack –ctstate RELATED -m helper \\
–helper ftp -i $зовнішній_інтерфейс -p tcp \\
–dport 1024: -j ACCEPT[/code]
Такий саме синтаксис застосовується для IPv6
[code]ip6tables -A FORWARD -m conntrack –ctstate RELATED -m helper \\
–helper ftp -o $зовнішній_інтерфейс -p tcp \\
–dport 1024: -j ACCEPT
ip6tables -A FORWARD -m conntrack –ctstate RELATED -m helper \\
–helper ftp -i $зовнішній_інтерфейс -p tcp \\
–dport 1024: -j ACCEPT[/code]
Приклад: модуль SIP
Ви повинні обмежити відносні (RELATED) з’єднання допоміжним модулем, обмеживши адресу отримувача PTR сервером чи фермою провайдера
[code]iptables -A FORWARD -m conntrack –ctstate RELATED -m helper \\
–helper sip -d $PTR_сервер_провайдера -p udp -j ACCEPT[/code]
Приклад: модуль h323
Проблема та ж сама, що і з SIP, потрібно обмежити відкривання відносних (RELATED) з’єднань використовуючи PTR сервер провайдера VOIP.
Захист керуючого (сигнального) потоку
Вам також необхідно створити продумані правила контролю доступу для керуючих потоків в яких застосовуються допоміжні модулі. Зокрема, зробити жорсткий контроль anti-spoofing (як в прикладі нижче) для того, щоб запобігти вкладання трафіку з іншого мережевого інтерфейсу.
Використання цілі CT для вдосконалення безпеки
Введення
Одна з класичних проблем допоміжних модулів, це то, що модуль заздалегідь налаштований прослуховувати певні порти. Якщо сервіс буде запущений на не стандартному порті, то потрібно це задекларувати. До ядра 2.6.34, єдиним способом зробити це, було використання опцій для модуля. В результаті ми повинні систематично перевіряти порти для модулів (пам’ятати та контролювати вручну опціями). Це вкрай не зручно, тому з ядра 2.6.34 була створена ціль (target) CT. Вона зробила можливим вказувати який модуль буде використаний для конкретного потоку. Наприклад, скажімо ми маємо FTP сервер який працює за IP адресою 1.2.3.4 та прослуховує порт 2121.
Для того, щоб його задекларувати, просто створіть таке правило
[code]iptables -A PREROUTING -t raw -p tcp –dport 2121 \\
-d 1.2.3.4 -j CT –helper ftp[/code]
Тому, замість використання опцій для модулів, рекомендовано використовуйте ціль CT.
Вимкнення допоміжних модулів за замовченням
Принцип
Як тільки допоміжний модуль був завантажений, він починає слідкувати на вказаному порту за усіма IP адресами. Як було розглянуто раніше, такий підхід не є оптимальний, та навіть створює ризик з точки зору безпеки. Набагато краще завантажити модуль, але вимкнути за замовченням спостереження з’єднань. А при необхідності, викликати модулі використовуючи ціль CT.
Метод
Починаючи з ядра 3.5, стало можливим вимкнути автоматичне підключення модулів системи відстеження з’єднань (conntrack). Це можна зробити під час завантаження модуля nf_conntrack.
[code]modprobe nf_conntrack nf_conntrack_helper=0[/code]
Також це можна зробити після завантаження модуля, використовуючи /proc
[code]echo 0 > /proc/sys/net/netfilter/nf_conntrack_helper[/code]
Але майте на увазі, якщо вже існує потік який відстежується модулем, то після виконання команди приведеної вище, модуль буде продовжувати працювати.
Для старих версії ядра, є можливість отримати схожу поведінку для більшості модулів, для цього треба вказати порт модуля “0”. Наприклад
[code]modprobe nf_conntrack_$протокол ports=0[/code]
Зробивши це, наступні модулі будуть дезактивовані за замовченням:
- ftp
- irc
- sane
- sip
- tftp
Через відсутність параметру “порт”, деякі модулі не можуть бути вимкнені таким чином
- amanda
- h323
- netbios_ns
- pptp
- snmp
Майте на увазі, що використовуючи параметр port=0, ви призводите до зміни імені допоміжного модуля системи відстеження з’єднань, який буде мати назву $протокол-0. Для того щоб відреагувати на цю зміну, правила CT необхідно поновити. Наприклад, якщо параметр було вказано для модуля ftp, то необхідно використовувати правило на зразок цього
[code]iptables -A PREROUTING -t raw -p tcp –dport 21 \\
-d 2.3.4.5 -j CT –helper ftp-0[/code]
Захист від spoofing атак
Модулі та anti-spoofing
Модулі покладаються на данні які поступають від клієнта чи сервера. Тому дуже важливо обмежувати spoofing атаки, які можуть бути використанні для передачі підроблених даних до модуля. Модулі працюють лише з IP, та на відміну від усієї системи відстеження з’єднань, не роблять ніякого аналізу з’єднань чи мережевої архітектури.
Використання модуля rpfilter
Модуль rpfilter фреймворку netfilter, доступний починаючи з ядра 3.3 та iptables версії 1.4.13. Він надає зручне “спів падіння” (match), яке можна використовувати для виявлення пакунків, які не відповідають характеру з’єднання. Для протоколів IPv6 та IPv4, використовуйте наприклад:
[code]iptables -A PREROUTING -t raw -m rpfilter –invert -j DROP
ip6tables -A PREROUTING -t raw -m rpfilter –invert -j DROP[/code]
Використання rp_filter
Linux надає засновану на маршрутизації, реалізацію перевірки зворотнього шляху (reverse path filtering). Вона доступна для IPv4. Для того, щоб її активувати, треба перевірити щоб файли /proc/sys/net/ipv4/conf/*/rp_filter містили в собі 1 одиницю. Повна документація про rp_filter доступна в директорії з сирцевим кодом ядра, в підрозділі Documentation/networking/ у файлі ip-sysctl.txt.
Частина документації приведена нижче
[code]
rp_filter – ціле число
0 – не виконувати перевірку відправника
1 – “Жорсткий” (Strict) режим, як визначено в RFC3704 Strict Reverse Path. Кожен вхідний пакунок звіряється з FIB, та якщо цей інтерфейс не є найліпшим зворотнім шляхом в цю мережу, перевірка завершиться не вдало, за замовченням такий пакунок буде відкинуто.
2 – “Вільний” (Loose) режим, як визначено в RFC3704 Loose Reverse Path. Відправна адреса кожного пакунка/пакунків також звіряється з FIB, але якщо адреса відправника не доступна через будь-який інтерфейс, перевірка буде вважатися не вдалою (Грубо кажучи, якщо немає маршруту в цю мережу, але в той же час, маршрут за замовченням ігнорується).
На цей час, добра практика в RFC3704 це використовувати “жорсткий” (Strict) режим, для запобігання DDos атак типу IP spoofing. Якщо використовується асиметрична чи якась інша ускладнена маршрутизація, рекомендовано використовувати “вільний” (Loose) режим.
Використовується максимальне значення з conf/{all,interface}/rp_filter для перевірки відправника на {interface}.
Значення за замовченням “0”. Але майте на увазі, деякі дистрибутиви виставляють це значення в стартових скриптах.
[/code]
Під час написання цієї статті, ще не має базованої на маршрутизації реалізації rp_filter під Linux для протоколу IPv6, тому тут потрібно використовувати ручний фільтр anti-spoofing, можливостями Netfilter.
Ручний anti-spoofing
Найліпший шлях зробити anti-spoofing, це використовувати правила фільтрації в таблиці RAW. Цей підхід має велику перевагу, так як обходить систему слідкування за з’єднаннями, та допомагає знизити навантаження яке може бути створено якимось затопленням (flooding).
Захист anti-spoofing повинен бути створений, для кожного інтерфейсу. Для кожного інтерфейсу необхідно створити лист, зі списком його мереж. Але з одним винятком, на інтерфейсі де знаходиться маршрутизатор “за замовченням”, потрібно використовувати “інвертовану” логіку. В нашому прикладі, візьмемо eth1 який є LAN інтерфейсом, та eth0 який містить маршрут “за замовченням”. Також ми маємо $Мережа_ETH1 яка підключена до інтерфейсу $ETH1 та мережа яка має $Напрям_через_ETH1 на цьому інтерфейсі. При такій конфігурації, ми можемо зробити захист anti-spoofing наступними правилами
[code]iptables -A PREROUTING -t raw -i eth0 -s $Мережа_ETH1 -j DROP
iptables -A PREROUTING -t raw -i eth0 -s $Напрям_через_ETH1 -j DROP
iptables -A PREROUTING -t raw -i eth1 -s $Мережа_ETH1 -j ACCEPT
iptables -A PREROUTING -t raw -i eth1 -s $Напрям_через_ETH1 -j ACCEPT
iptables -A PREROUTING -t raw -i eth1 -j DROP
[/code]
Для протоколу IPv6 правила будуть схожі, але якщо ми опустимо випадок з локальною мережею (local link)
[code]ip6tables -A PREROUTING -t raw -i eth0 -s $Мережа_ETH1 -j DROP
ip6tables -A PREROUTING -t raw -i eth0 -s $Напрям_через_ETH1 -j DROP
ip6tables -A PREROUTING -t raw -s fe80::/64 -j ACCEPT
ip6tables -A PREROUTING -t raw -i eth1 -s $Мережа_ETH1 -j ACCEPT
ip6tables -A PREROUTING -t raw -i eth1 -s $Напрям_VIA_ETH1 -j ACCEPT
[/code]