Приклади фаєрвола для IPv4

У цьому розділі наведено добірку корисних прикладів конфігурації фаєрвола, заснованих на UCI-файлах конфігурації. Усі ці правила можна додати на сторінці LuCI Network → Firewall → Traffic Rules.

У відповідності до поведінки служби netfilter, виконується перше відповідне правило, і (за деякими винятками) фільтрація припиняється — наступні правила вже не перевіряються. Інтерфейс LuCI дозволяє переміщати правила вгору та вниз для правильного сортування.

Див. Оглядова топологія мережі для візуального представлення мережі, яку використовували для тестування прикладів. Ці приклади охоплюють лише мережі IPv4.

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

Якщо не вказано інше, усі правила були протестовані в основному з використанням netcat та curl. Опція `enabled` у кожному правилі перемикалася між тестами для перевірки очікуваної поведінки: `on` — дозволяє пакети, `off` — блокує.

Перед внесенням змін у правила обов’язково зробіть резервну копію файлу `/etc/config/firewall`!

Типова конфігурація дозволяє весь трафік з LAN, але блокує весь вхідний трафік з WAN на портах, які не використовуються активними з'єднаннями або NAT. У референтній топології весь трафік LAN і WAN блокується, тому для роботи сервісу потрібно створити правило для відкриття порту(ів).

config rule
  option target     'ACCEPT'
  option src        'wan'
  option proto      'tcp'
  option dest_port  '22'
  option name       'ACCEPT-SSH-WAN-DEVICE'
  option enabled    '1'

Цей приклад дозволяє станціям з боку WAN отримати доступ до SSH на маршрутизаторі (типова ціль — сам маршрутизатор).

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

Використовуйте параметри src_ip і dest_ip, щоб визначити конкретні підмережі.

config rule
  option target     'ACCEPT'
  option src        'wan'
  option family     'ipv4'
  option proto      'tcp'
  option src_ip     '192.168.3.0/24'
  option dest_port  '22'
  option name       'ACCEPT-SSH-INTERNAL-DEVICE'
  option enabled    '1'

Цей приклад дозволяє доступ до SSH на маршрутизаторі з будь-якої станції в приватному діапазоні адрес `192.168.3.0/24`. Правило не відповідатиме іншим IP-адресам джерела.

При використанні IPv4 обов’язково вкажіть `family` як ipv4, інакше фаєрвол видасть попередження: `! Skipping due to different family of ip address`.

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

Користувачі деяких великих зарубіжних провайдерів (особливо з Китаю та В’єтнаму) перетворили спам-атаки в мистецтво — вони створюють цілі блоки «поезії», розподіляючи повідомлення між різними станціями та підмережами. Найкращий спосіб протидії — блокувати основну мережу-джерело спаму.

config rule
  option src        'wan'
  option dest       'lan'
  option proto      'tcp'
  option src_ip     '42.56.0.0/16'
  option dest_port  '25'
  option target     'DROP'
  option name       'DROP-WAN-0001'
  option enabled    '1'

У цьому прикладі станції з мережі в Пекіні розсилають спам-листи «трійками» з різним вмістом, змінюючи IPv4-адреси в межах підмереж. Це правило DROP відкидає всі вхідні з'єднання на порт 25 (SMTP) з будь-якої станції цієї мережі. На відміну від REJECT, DROP безшумно відкидає пакет, не надсилаючи відповідь джерелу.

Якщо кількість заблокованих мереж перевищує кілька десятків (а таких мереж тисячі), керувати усіма через файл `firewall` стає складно. Альтернативи:

• додати окремі правила `iptables` у `/etc/firewall.user`
• використовувати механізм `ipset`, описаний у прикладах ipset

Наведений нижче приклад створює правило в ланцюжку FORWARD netfilter, яке відхиляє трафік із LAN до WAN на портах 1000–1100.

config rule
  option src        'lan'
  option dest       'wan'
  option dest_port  '1000-1100'
  option proto      'tcp udp'
  option target     'REJECT'
  option name       'REJECT-LAN-WAN-PORTS'
  option enabled    '1'

Наступне правило блокує HTTP/S-з’єднання з усіх пристроїв LAN до одного публічного сайту. Використайте утиліту DNS (dig або nslookup), щоб визначити IP-адресу за доменним ім’ям.

config rule
  option src        'lan'
  option dest       'wan'
  option proto      'tcp'
  option family     'ipv4'
  option dest_ip    '63.251.153.68'
  option dest_port  '80 443'
  option target     'REJECT'
  option name       'REJECT-LAN-SITE-HTTP'
  option enabled    '1'

Зверніть увагу: у dest_port вказано два порти: HTTP і HTTPS. Якщо список портів містить пробіли, його потрібно брати в одинарні лапки (`'80 443'`).

Якщо джерелом або одержувачем є сам маршрутизатор, тоді поле `src` або `dest` можна опустити. Такі правила додаються до ланцюжків netfilter INPUT (до маршрутизатора) та OUTPUT (від маршрутизатора).

config rule
  option dest       'wan'
  option dest_ip    '8.8.8.8'
  option family     'ipv4'
  option proto      'icmp'
  option target     'REJECT'
  option name       'REJECT-DEVICE-DNS'
  option enabled    '1'

Це правило наказує netfilter відхиляти будь-які ICMP echo-пакети (ping) з маршрутизатора (ланцюжок OUTPUT) до публічного DNS-сервера Google. Правило саме по собі не є особливо корисним, але служить ілюстративним прикладом.

Приклад наведено тут: Блокування IP за доменними іменами.

Цей метод дуже корисний, якщо потрібно фільтрувати великі CDN за доменними іменами. Також можна фільтрувати динамічні DNS (DDNS) хости. Перевага — можна фільтрувати всі піддомени (наприклад, `www.`), просто вказавши основне доменне ім’я (наприклад, `example.com`).

Наступне правило можна використати для батьківського контролю.

config rule
  option src         'lan'
  option dest        'wan'
  option src_mac     '4C:EB:42:32:0C:9E'
  option proto       'tcp udp'
  option start_time  '21:00:00'
  option stop_time   '09:00:00'
  option utc_time    '0'
  option weekdays    'Mon Tue Wed Thu Fri'
  option target      'REJECT'
  option name        'REJECT-LAN-WAN-TIME'
  option enabled     '1'

Коли це правило активне, воно блокує весь TCP- і UDP-доступ з пристрою STA2 до Інтернету у будні дні з 21:00 до 09:00. За замовчуванням час вказується в UTC, якщо тільки не встановлено `utc_time '0'`.

Ці перевірки часу/дати використовують модуль ядра netfilter `xt_time`, який включено до релізу. Перевірте `/proc/modules`, щоб упевнитися, що модуль завантажено.

У LuCI це правило можна додати через Firewall→Traffic Rules, створивши нове правило з потрібною MAC-адресою та дією block або reject.

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

Це правило застосовується лише до однієї MAC-адреси, а не до діапазону.

Такі правила дуже корисні для мобільних пристроїв, таких як смартфони і планшети. Незважаючи на всі зміни, Wi-Fi MAC-адреса майже завжди жорстко закодована на заводі. Проте досвідчений користувач може змінити її за допомогою подібної команди в Linux:

root> ip link set wlan0 down  
root> ip link set address "de:ad:be:ef:00:01" wlan0  
root> ip link set wlan0 up

Альтернативний механізм для блокування кількох MAC-адрес LAN-станцій можна знайти в LuCI у розділі Wireless→Interface → Edit→ MAC Filter. Установіть фільтр на Дозволити всім, крім перелічених і додайте кілька MAC-адрес LAN-станцій.

У файлі `/etc/config/wireless` це створить запис `“list maclist”` для відповідного інтерфейсу.

Цей приклад дозволяє правильну переадресацію трафіку IPSec через WAN. Використані протоколи:

* ah IP Authentication Header * esp Encap Security Payload

config rule
  option src       'wan'
  option dest      'lan'
  option proto     'ah'
  option target    'ACCEPT'
 
config rule
  option src       'wan'
  option dest      'lan'
  option proto     'esp'
  option target    'ACCEPT'

У деяких конфігураціях також потрібно відкрити порт 500/UDP для протоколу ISAKMP.

config rule
  option src       'wan'
  option dest      'lan'
  option proto     'udp'
  option src_port  '500'
  option dest_port '500'
  option target    'ACCEPT'

Сценарій: є один або більше VPN-тунелів (наприклад OpenVPN), і потрібно визначити зону для переадресації трафіку між VPN-інтерфейсами та LAN.

Спершу перелічіть інтерфейси у файлі /etc/config/network, наприклад, як нижче. Будьте обережні з обмеженнями щодо довжини назв інтерфейсів — докладніше читайте тут.

config interface 'tun0'
  option ifname   'tun0'
  option proto    'none'
 
config interface 'tun1'
  option ifname   'tun1'
  option proto    'none'

Далі створіть зону у файлі /etc/config/firewall, наприклад одну спільну зону для всіх VPN-інтерфейсів.

config zone
  option name      'vpn_tunnel'
  list network     'tun0'
  list network     'tun1'
  option input     'ACCEPT'
  # трафік до маршрутизатора з цього інтерфейсу буде дозволено
  # (як у випадку з LAN)
  option output    'ACCEPT'
  # трафік від маршрутизатора до цього інтерфейсу буде дозволено
  option forward   'REJECT'
  # трафік з цієї зони до інших зон за замовчуванням блокується

Тепер ми хочемо забезпечити зв’язок із зоною “lan”, отже потрібно додати правила форвардингу в обидві сторони (з lan до vpn і навпаки).

config forwarding
  option src   'lan'
  option dest  'vpn_tunnel'
  # якщо пакет з lan хоче потрапити до зони vpn_tunnel — дозволити
 
config forwarding
  option src   'vpn_tunnel'
  option dest  'lan'
  # якщо пакет з vpn_tunnel хоче потрапити до зони lan — дозволити

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

Цей приклад оголошує зону, яка відповідає будь-якому мережевому пристрою Linux, назва якого починається з “ppp”.

config zone
  option name      'example'
  option input     'ACCEPT'
  option output    'ACCEPT'
  option forward   'REJECT'
  option device    'ppp+'

Цей приклад оголошує зону, яка відповідає будь-якому TCP-з’єднанню в підмережі 10.21.0.0/16.

config zone
  option name      'example'
  option input     'ACCEPT'
  option output    'ACCEPT'
  option forward   'REJECT'
  option subnet    '10.21.0.0/16'
  option extra     '-p tcp'

Цей приклад оголошує зону, яка відповідає будь-якому TCP-з’єднанню з або на порт 22.

config zone
  option name         'example'
  option input        'ACCEPT'
  option output       'ACCEPT'
  option forward      'REJECT'
  option extra_src    '-p tcp --sport 22'
  option extra_dest   '-p tcp --dport 22'

Якщо ваша LAN-мережа працює з публічними IP-адресами, вам однозначно не потрібен NAT (маскарадинг). Але при цьому може виникнути бажання використовувати stateful фаєрвол на маршрутизаторі, щоб станції з боку LAN не були доступні з боку WAN.

Для цього додайте опцію `conntrack` у зону WAN:

config zone
  option name         'wan'
  list   network      'wan'
  list   network      'wan6'
  option input        'REJECT'
  option output       'ACCEPT'
  option forward      'REJECT'
  option masq         '0'
  option mtu_fix      '1'
  option conntrack    '1'

Ось приклад, який дозволяє HTTP/HTTPS-доступ з Cloudflare. Використовуйте, якщо ваш вебсервер працює за проксі Cloudflare.

cat << EOF >> /etc/firewall.user
uci -q delete firewall.cf_proxy.dest_ip
for IPV in 4 6
do for IP in $(wget -O - \
"https://www.cloudflare.com/ips-v${IPV}")
do uci add_list firewall.cf_proxy.dest_ip="${IP}"
done
done
service firewall reload
EOF
uci -q delete firewall.cf_proxy
uci set firewall.cf_proxy="rule"
uci set firewall.cf_proxy.name="Allow-Cloudflare-Proxy"
uci set firewall.cf_proxy.src="wan"
uci add_list firewall.cf_proxy.dest_port="80"
uci add_list firewall.cf_proxy.dest_port="443"
uci set firewall.cf_proxy.proto="tcp"
uci set firewall.cf_proxy.target="ACCEPT"
uci commit firewall
service firewall restart