Налагодження iptables та загальні підводні камені брандмауера?


18

Це запропоноване канонічне запитання про розуміння та налагодження брандмауера програмного забезпечення в системах Linux.

У відповідь на відповідь EEAA та коментар @ Shog про те, що нам потрібні відповідні канонічні запитання і відповіді для закриття поширених відносно простих питань щодо iptables.

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

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

Навіть якщо ви використовуєте такі інструменти, як UFW , FirewallD (ака firewall-cmd), Shorewall або подібні, ви можете отримати вигляд під кришкою без шару абстракції, який пропонують ці інструменти.

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


1
А як щодо правил NAT та державних, які можна розмістити раніше в ланцюжку, щоб покращити продуктивність та підвищити безпеку?
Метт

1
@Matt: оптимізація правил брандмауера - сама по собі питання Q&A, і в цьому
питанні

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

1
Ох, і встановлення net.netfilter.nf_conntrack_log_invalid255 дозволить захопити недійсні пакети досить непогано, що може допомогти, якщо його величезна частина netfilter, яка виробляє погану поведінку.
Метью Іфе

Відповіді:


14

В загальному:

Для перегляду та зміни конфігурації брандмауера потрібні права адміністратора ( root), як і послуги відкриття в обмеженому діапазоні номерів портів. Це означає, що вам слід або ввійти в систему як rootабо альтернативно використовувати sudoдля запуску команди як root. Я спробую позначити такі команди додатковими [sudo].

Зміст:

  1. Питання порядку чи різниця між -Iта-A
  2. Показати поточну конфігурацію брандмауера
  3. Інтерпретація результату iptables -L -v -n
  4. Знайте своє оточення
  5. Ланцюги INPUT і FORWARD
  6. Модулі ядра

1. Порядок питань або різниця між -Iі-A

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

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

[sudo] iptables -A INPUT -i eth0 -p tcp --dport 8080 -j ACCEPT

а потім виявіть, що це не набуде чинності.

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

...
7    2515K  327M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited
8        0  0    ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:8080

Або еквівалент в iptables-save:

...
iptables -A INPUT  -j REJECT
iptables -A INPUT  -p tcp --dport 8080 -j ACCEPT

і нове правило, що відкриває TCP-порт 8080, ніколи не буде досягнуто. (про що свідчать лічильники, що вперто залишаються при 0 пакетах і нульових байтах).

Вставивши правило з -Iновим правилом, було б першим у ланцюжку і буде працювати.

2. Показати поточну конфігурацію брандмауера

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

Команда [sudo] iptables -L -v -n- твій друг (хоча деякі люди люблять iptables-saveкраще). Часто при обговоренні конфігурацій корисно використовувати --line-numbersпараметр, а також нумерувати рядки. Посилання на правило #X полегшує їх обговорення.
Примітка: правила NAT включаються у iptables-saveвисновок, але повинні бути перераховані окремо, додавши -t natопцію, тобто [sudo] iptables -L -v -n -t nat --line-numbers.

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

[root@host ~]# iptables -L -v -n
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1     784K   65M fail2ban-SSH  tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           tcp dpt:22
2    2789K  866M ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED
3       15  1384 ACCEPT     all  --  lo     *       0.0.0.0/0            0.0.0.0/0
4    44295 2346K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:22
5    40120 2370K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:80
6    16409  688K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0           state NEW tcp dpt:443
7    2515K  327M REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT 25 packets, 1634 bytes)
num   pkts bytes target     prot opt in     out     source               destination

Chain fail2ban-SSH (1 references)
num   pkts bytes target     prot opt in     out     source               destination
1        0     0 REJECT     all  --  *      *       117.239.37.150       0.0.0.0/0           reject-with icmp-port-unreachable
2        4   412 REJECT     all  --  *      *       117.253.208.237      0.0.0.0/0           reject-with icmp-port-unreachable

Альтернативно, вихід iptables-saveдає сценарій, який може відновити вищевказану конфігурацію брандмауера:

[root@host ~]# iptables-save
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [441:59938]
:fail2ban-SSH - [0:0]
-A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 443 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited
-A fail2ban-SSH -s 117.239.37.150/32 -j REJECT --reject-with icmp-port-unreachable
-A fail2ban-SSH -s 117.253.208.237/32 -j REJECT --reject-with icmp-port-unreachable
COMMIT

Це питання переваги того, що вам буде легше зрозуміти.

3. Інтерпретація результату iptables -L -v -n

Політика встановлює дію за замовчуванням в ланцюзі використання , коли немає чітких правил сірників. У INPUTланцюжку, яка встановлена ​​НА ПРИЙМАНИЙ весь трафік.

Перше правило в ланцюзі INPUT одразу є цікавим, воно надсилає весь трафік (джерело 0.0.0.0/0 та призначення 0.0.0.0/0), призначений для порту 22 TCP ( tcp dpt:22) порт за замовчуванням для SSH, на спеціальну ціль ( fail2ban-SSH) . Як зазначає ім'я, це правило підтримується fail2ban (продукт безпеки, який серед іншого сканує файли системного журналу на предмет можливих зловживань і блокує IP-адресу порушника).

Це правило було б створене командним рядком iptables, подібним iptables -I INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSHабо знайденому у висновку iptables-save as -A INPUT -p tcp -m tcp --dport 22 -j fail2ban-SSH. Часто ви знайдете будь-яке з цих позначень у документації.

Лічильники вказують, що це правило збігало 784 000 пакетів і 65 мегабайт даних.

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

Цей ланцюг складається з двох правил, по одному для кожного кривдника (джерела ip-адреси 117.253.221.166 або 58.218.211.166), яке заблоковано (з а reject-with icm-port-unreachable).

 -A fail2ban-SSH -s 117.253.221.166/32 -j REJECT --reject-with icmp-port-unreachable
 -A fail2ban-SSH -s 58.218.211.166/32 -j REJECT --reject-with icmp-port-unreachable

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

Усі пакети, яким не призначено порт 22, пройшли перше правило в ланцюзі INPUT, а також будуть оцінені в правилі № 2 INPUT.

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

Правило введення №2 відповідає всім відкритим і пов'язаним з'єднанням і пакетам, що відповідають цьому правилу, не потрібно додатково оцінювати.

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

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

Правило INPUT №3 є досить нудним, loдозволений весь трафік, що підключається до інтерфейсу петлі ( або 127.0.0.1).

Правила INPUT 4, 5 і 6 використовуються для відкриття портів TCP 22, 80 і 443 (порту за замовчуванням для відповідних SSH, HTTP і HTTPS) шляхом надання доступу до НОВИХ з'єднань (існуючі з'єднання вже дозволені правилом INPUT 2).

У брандмауері без громадянства ці правила з’являться без атрибутів держави:

4    44295 2346K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
5    40120 2370K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0
6    16409  688K ACCEPT     tcp  --  *      *       0.0.0.0/0            0.0.0.0/0

або

-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT

Остаточне правило INPUT, # 7 - це правило, яке блокує весь трафік, якому НЕ було надано доступ у правилах INPUT 1-7. Досить поширена умова: все, що не допускається, заперечується. Теоретично це правило можна було б опустити, встановивши ПОЛІТИКУ за замовчуванням на ОТМЕНИТИ.

Завжди досліджуйте весь ланцюжок.

4. Знайте своє оточення

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

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

  • Переконайтесь, що служба слухає (за правильним мережевим інтерфейсом / ip-адресою) та використовуючи номери портів, які ви очікуєте при [sudo] netstat -plnutвикористанні або альтернативно ss -tnlp.
  • Якщо ваші послуги ще не працюють, емулюйте простого слухача, наприклад, netcat: [sudo] nc -l -p 123або openssl s_server -accept 1234 [options] якщо вам потрібен слухач TLS / SSL (перевірте man s_serverпараметри).
  • Переконайтеся, що ви можете підключитися із самого сервера, тобто telnet <IP of Server> 123або echo "Hello" | nc <IP of Server> 123або під час тестування послуги openssl s_client -connect <IP of Server>:1234, захищеної TLS / SSL , перш ніж спробувати те саме з віддаленого хоста.

4.3. Зрозумійте протоколи, якими користуються ваші служби. Ви не можете належним чином увімкнути / відключити послуги, які ви недостатньо розумієте. Наприклад:

  • використовується TCP або UDP або обидва (як у DNS)?
  • чи послуга використовує фіксований порт за замовчуванням (наприклад, щось на зразок TCP-порту 80 для веб-сервера)?
  • або ж вибрано динамічний номер порту, який може змінюватись (тобто послуги RPC, як класичні NFS, які реєструються в Portmap)?
  • сумнозвісний FTP навіть використовує два порти , як фіксований, так і динамічний номер порту, налаштований на пасивний режим ...
  • опис послуги, порту та протоколу /etc/servicesне обов'язково збігається з фактичною послугою, що використовує порт.

4.4. Фільтр пакетів ядра - це не єдине, що може обмежувати підключення до мережі:

  • SELinux також може обмежувати мережеві послуги. getenforceпідтвердить, чи працює SELinux.
  • Хоча дещо незрозумілі TCP обгортки все ще є потужним інструментом забезпечення мережевої безпеки. Зверніться ldd /path/to/service |grep libwrapдо /hosts.[allow|deny]файлів і керуйте ними.

5. INPUTабо FORWARDЛанцюги

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

INPUTЛанцюг , де ви відкриваєте і / або закрити мережеві порти для служб працюють локально, на машині , де ви видаєте команди Iptables.

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

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

6. Модулі ядра

Оскільки фільтр пакетів працює в межах ядра Linux, він також може бути складений як динамічний модуль, фактично декілька модулів. Більшість дистрибутивів включають netfilter як модулі, а необхідні модулі netfilter завантажуватимуться в ядро ​​за потребою, але для деяких модулів адміністратору брандмауера потрібно буде вручну переконатися, що вони завантажуються. В першу чергу це стосується модулів відстеження підключення, таких, nf_conntrack_ftpякими можна завантажувати insmod.

Модулі, що зараз завантажуються в запущене ядро, можуть відображатися за допомогою lsmod.

Спосіб забезпечення постійного завантаження модулів через перезавантаження залежить від дистрибутива Linux.


1
При пошуку лічильників прирістних пакетів / байтів. Корисним інструментом є використання годинника в різному режимі. Так что щось на зразок цього: watch --difference -n 1 iptables -L FORWARD -v -n. Дозволяючи інструменту періодично запускати команду та виділяти зміни, це значно спрощує.
Зоредаче

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

Я буду брати iptables-saveвисновок (бажано з -c) кожен раз над цим жахливим iptables -L(з різними аргументами) результатом.
0xC0000022L

7

Поширені проблеми з різними протоколами

DNS: DNS використовує UDP порту 53 за замовчуванням, але повідомлення, які не вмістяться в одній дейтаграмі UDP, передаватимуться замість цього TCP (як правило, передача в зоні та таке), що вимагає відкриття порту 53 TCP також під час запуску сервера імен .

Електронна пошта: Багато споживчих провайдерів блокують SMTP-трафік (або, принаймні, порт за замовчуванням TCP 25), унеможливлюючи безпосередньо отримання або відправлення електронної пошти, і їхні клієнти змушені використовувати реле SMTP провайдера для всієї вихідної електронної пошти, а іноді і для вхідної пошти. . Відноситься до §1.1.

FTP: FTP - непарний протокол, оскільки два з'єднання використовуються. Перше - це з'єднання управління, за замовчуванням для цього FTP-сервер прослухає на TCP-порту 21 для цього. З'єднання управління використовується для аутентифікації та видачі команд. Фактичні передачі файлів і такі речі, як вихід списку каталогів, переходять через друге TCP-з'єднання, з'єднання DATA. У активному FTP це з'єднання DATA буде ініційовано з FTP-сервера з порту 20 TCP і підключиться до FTP-клієнта. Active FTP не надто добре працює з користувачами, що стоять за брандмауерами та NAT-шлюзами, тому в основному він перебуває у використанні. Більшість серверів FTP замість цього підтримують пасивний FTP. За допомогою пасивного FTP сервер FTP відкриває слухач для з'єднання DATA на другому порту, до якого FTP-клієнт може потім підключитися. Проблема брандмауера полягає в тому, що портом DATA може бути будь-який доступний непривірений порт між 1024-65536.

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

iptables -A INPUT -p tcp --match multiport --dports 21000:21050 -j ACCEPT

У стані брандмауера вам не потрібно явно відкривати порт DATA, допоміжний модуль netfilter розпізнає динамічний порт, який присвоюється, і динамічно відкриє цей порт для правильного клієнта, позначивши з'єднання DATA, оскільки RELATEDпісля цього він буде відповідати загальному правилу :

  iptables -I INPUT -p tcp -m state ESTABLISHED,RELATED -j ACCEPT

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

Примітка: Модуль відстеження FTP-з'єднань не вдасться, коли FTP використовується з SSL, оскільки керувальне з'єднання буде зашифровано, і nf_conntrack_ftp більше не зможе читати PASV повторно.

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

З точки зору брандмауера, порт 111 TCP / UDP повинен бути відкритий і власне порт, який RPC використовує в даний час. Проблема відкриття такого випадкового порту в брандмауері, як правило, вирішується обмеженням служби RPC, наприклад сервера NFS, використовувати попередньо визначений фіксований порт.


7

"Вступ" Iptables / брандмауера

Брандмауер - це мережевий фільтр на основі політики. Брандмауері Linux побудовані навколо Netfilter; мережева рамка обробки пакету ядра, яка складається з декількох модулів ядра, що виконують конкретні завдання:

  1. Модуль FILTER (завжди завантажується за замовчуванням) в основному дозволяє приймати IP-пакети DROP або DROP на основі певних критеріїв відповідності.
  2. Набір модулів NAT дозволяє виконувати трансляцію мережевих адрес (SNAT, DNAT, MASQUERADE).
  3. Модуль MANGLE дозволяє нам змінювати певні поля IP-пакетів (TOS, TTL).

Користувачі налаштовують рамку Netfilter відповідно до потреб брандмауера, використовуючи iptables з командного рядка. За допомогою iptables ми визначаємо правила, які вказують ядру, що робити з IP-пакетами, коли вони потрапляють, проходять через них або залишають наш вікно Linux. Кожен основний процес Netfilter представлений таблицею (FILTER, NAT, MANGLE) на мові iptables. Вони мають кілька певних точок гака на карті потоку мережевих пакетів, куди ядро ​​викликає їх для виконання своїх обов'язків. Деякі спеціально розташовані послідовності викликів TABLE загалом називаються вбудованими ланцюгами, які отримують імена PREROUTING, INPUT, FORWARD, OUTPUT та POSTROUTING. Легко запам'ятати, якщо ми пов'язуємо ТАБЛИЦЮ з "типом процесу" та ЦЕТА з "розташуванням" на карті потоку мережевих пакетів, де викликаються екземпляри цих процесів.

введіть тут опис зображення

Оскільки IP-пакет приймається через мережевий інтерфейс або створюється локальним процесом, поки він остаточно не буде доставлений або відкинутий, двигун Netfilter послідовно перевірятиме і застосовуватиме правила, що містяться в мапі потоку мережевих пакетів. На кожен блок, ідентифікований парою TABLE @ CHAIN, користувач може додати одне або більше цих послідовних правил, що містять критерії відповідності пакетів IP та відповідний хід дій. Існують дії (тобто ACCEPT, DROP тощо), які можуть виконуватися більш ніж однією таблицею та іншими діями (наприклад, SNAT, DNAT тощо), які є специфічними для ТАБЛИЦІ.

тобто, коли IP-пакет надходить з мережевого інтерфейсу, він спочатку обробляється ланцюгом PREROUTING, що викликає правила, визначені користувачем таблиці MANGLE, якщо такі є. Якщо немає правил, що відповідають поточному пакету, застосовується відповідний курс дій MANGLE @ PREROUTING або "політика" за замовчуванням. У цей момент, якщо пакет не був відпущений, процес продовжуватиметься тепер викликом правил таблиці NAT у ланцюжку PREROUTING (див. Карту) тощо. Для полегшення розміщення правил користувачі також можуть створювати власні власні ланцюги та "стрибати" в них з різних точок карти за своїм бажанням.

введіть тут опис зображення

Хоча вбудовані ланцюги можуть мати визначені користувачем політики або пакетів ACCEPT, або DROP, визначені користувачем ланцюги завжди мають незмінну політику RETURN за замовчуванням для виклику для продовження процесу.

Команди Iptables

Основні команди iptables заповнюють карту потоку мережевих пакетів необхідними правилами обробки.

Загальне правило iptables можна записати так:

# iptables <table> <Add/Insert/Delete> <CHAIN> <PKT_MATCHING_CRITERIA> <ACTION>

Це можна прочитати так:

Netfilter (kernel module) please <Add/Insert/Delete> this rule for <table> at <CHAIN> where packets matching <PKT_MATCHING_CRITERIA> have to be <ACTION>ed

<table>
  -t filter       (the filter table is assumed when omitted)
  -t nat
  -t mangle 

<Add/Insert/Delete>
  -A              (append rule at the end of the chain list)
  -I              (insert rule at the begining of the chain list)
  -D              (Delete rule)

<CHAIN>
  PREROUTING
  INPUT
  FORWARD
  OUTPUT
  POSTROUTING
  USER_DEFINED_CHAIN

<PKT_MATCHING_CRITERIA>
ISO Level-2 matching:
  -i [!] <if_name>    or --in-interface [!] <if_name>
          (OUTPUT and POSTROUTING chains cannot match on input  interfaces)
  -o [!] <if_name>    or --out-interface [!] <if_name>
          (INPUT  and PREROUTING  chains cannot match on output interfaces) 
    -mac-source [!] <xx-xx-xx-xx-xx-xx>
            (OUTPUT and POSTROUTING chains cannot match on input  interfaces)

ISO Level-3 matching:
  -s [!] <src_ip>     or --src [!] <src_ip>   or --source [!] <src_ip>
  -d [!] <dst_ip>     or --src [!] <dst_ip>   or --destination [!] <dst_ip>

ISO Level-4 matching:
  -p [!] <prot_name>    or --protocol [!] <prot_name>  (udp|tcp|icmp)

  Also available when ICMP protocol is defined
  --icmp-type [!] <icmp_type>

  Also available when UDP protocol is defined
  --source-port [!] <udp_src_port>      or --sport [!] <udp_src_port>
  --destination-port [!] <udp_dst_port> or --dport [!] <udp_dst_port>

  Also available when TCP protocol is defined
  --source-port [!] <tcp_src_port>      or --sport [!] <tcp_src_port>
  --destination-port [!] <tcp_dst_port> or --dport [!] <tcp_dst_port>
  --tcp-flags [!] <tcp_flags>   (SYN|ACK|FIN|RST|URG|PSH|ALL|NONE)
    --syn
  --tcp-option [!] <tcp_option#>

  --state [!] <state>
  -m <match> [options]

    note: [!] = negation operator

<ACTION>                (also called TARGET)
  -j ACCEPT             (process continues with rules of the next table in map)
  -j DROP               (discard current packet)
  -j REJECT             (discard current packet with ICMP notification)
      option:
      --reject-with <reject_type>
  -j USER_DEFINED_CHAIN   (start traversing USER_DEFINED_CHAIN rules)
  -j RETURN               (return from USER_DEFINED_CHAIN)
  -j LOG                  (log to syslog, then process next rule in table)
      options:
      --log-level <level>
      --log-prefix <prefix>
      --log-tcp-sequence
      --log-tcp-options
      --log-ip-options
      --log-uid

nat table specific
  -j SNAT             (rewrite the source IP address of the packet)
      option:
      --to <ip_address>
  -j SAME             (idem SNAT; used when more than one source address)
      options:
      --nodst 
      --to <a1-a2>
  -j MASQUERADE       (idem SNAT; used when the replace IP is dynamic)
  -j DNAT             (rewrite the destination IP address of the packet)
      option:
      --to <ip_address>
  -j REDIRECT         (rewrite dst IP to 127.0.0.1, PREROUTING and OUTPUT only)
      option:
      –-to-port <port#>

mangle table specific
  -j ROUTE            (explicitly route packets, valid at PREROUTING)
      options:
      --iface <iface_name>
      --ifindex <iface_idx>
  -j MARK             (set Netfilter mark values)
      options:
      --set-mark <value>
      --and-mark <value>
      --or-mark <value> 
  -j TOS              (set the IP header Type of Service field) 
      option:
      --set-tos <value>
  -j DSCP             (set the IP header Differentiated Services Field)
      options:
      --set-dscp <value>
      --set-dscp-class <class>
  -j TTL              (set the IP header Time To Live field)
      options:
      --ttl-set <value>
      --ttl-dec <value>
      --ttl-inc <value>

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

#iptables -t <table> -L             
       (Lists the <table> rules in all chains)
#iptables -t <table> -L <CHAIN>     
       (Lists the <table> rules in <CHAIN>)

#iptables -t <table> -N <CHAIN>     
       (Creates a user-defined <CHAIN> for holding <table> rules)
#iptables -t <table> -E <CHAIN> <NEWCHAIN>  
       (Renames <CHAIN> that holds <table> rules to <NEWCHAIN>)

#iptables -t <table> -X   
       (Deletes all user-defined chains created for holding <table> rules)
#iptables -t <table> -X <CHAIN>
       (Deletes user-defined <CHAIN> created for holding <table> rules)

#iptables -t <table> -P <CHAIN> <ACTION>     where <ACTION> = ACCEPT|DROP
       (Sets the default policy of <table> rules at <CHAIN> to <ACTION>)

#iptables -t <table> -F             
       (Flushes (deletes) all <table> rules in all chains)
#iptables -t <table> -F <CHAIN>
       (Flushes (deletes) all <table> rules in <CHAIN>)

#iptables -t <table> -R <CHAIN> <INDEX> <NEWRULE>
       (Replaces <table> rule at position <INDEX> in <CHAIN> with <NEWRULE>

Iptables завантажує наші команди в движок Netfilter під час виконання, Netfilter негайно виконує завантажені правила та налаштування, але вони не є стійкими. Afeter перезавантажить всі раніше завантажені правила та налаштування Netfilter буде втрачено. З цієї причини є утиліти iptables, які дозволяють зберегти поточний активний набір правил у файл та перезавантажити його пізніше.

#iptables-save > fileName
      (Save the currently active Netfilter ruleset to fileName)

#iptables-restore < fileName
      (Restore Netfilter ruleset to the one saved in fileName)

Підсумок Iptables

Netfilter - це надзвичайно гнучка та потужна структура, але за неї є ціна, яку потрібно платити; Iptables складний. З точки зору користувача, деякі терміни, такі як СТІЛЬКА, ЦЕТА, ЦІЛЬ, не дуже добре відповідають поняттю, яке вони представляють, і спочатку не мають великого сенсу. Тема довга, команди, здається, мають нескінченний список параметрів. Щоб погіршити ситуацію, немає жодної книги, яка справді опановує Iptables. Вони здебільшого поділяються на дві категорії: "книга рецептів" або "книга з написанням сторінки". Я думаю, що це вступ дає вам короткий знімок пейзажу Netfilter / Iptables, а також необхідну дозу попередньо перетравлених матеріалів сторінки. Якщо ви новачок у iptables, прочитавши ці параграфи кілька разів, ви будете готові прочитати приклади iptables. З деякою практикою ви незабаром опинитеся на написанні власних правил.

Брандмауери

Брандмауер в основному призначений для динамічного дозволу або заборони мережевого трафіку на основі набору правил. На даний момент легко зрозуміти, чому рамка Linux Netfilter / Iptables ідеально підходить для побудови брандмауера. Дивлячись на карту потоку мережевих пакетів, ми знаходимо два особливо цікавих місця на таблиці FILTER у ланцюгах INPUT та FORWARD; Ми можемо прийняти рішення щодо IP-адреси, IP-протоколу (UDP / TCP), порту призначення (80, 21, 443 тощо) тощо, якщо ми приймемо, відхилимо або просто знищимо певний IP-пакет. Це те, що брандмауер займає 80% часу, коли тобто захищає веб-сервер від несанкціонованих мережевих запитів. Інші 20% часу маніпулює мережевими пакетами (NAT, MANGLE).

Сценарії брандмауерів

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

  1. Простий веб-сервер з одним або декількома інтерфейсами, підключеними до Інтернету. Політика включає основні правила, щоб дозволити обмежений вхідний доступ, необмежений вихідний доступ та правила проти підробки. Переадресація IP вимкнена.
  2. Цей брандмауер підключається до Інтернету та до захищеної внутрішньої зони. Політика включає основні правила, щоб дозволити обмежений вхідний доступ, необмежений вихідний доступ та правила проти підробки. Оскільки захищена територія використовує приватні IP-адреси, джерело NAT необхідний. Переадресація IP включена.
  3. Цей брандмауер підключається до Інтернету, внутрішньої захищеної та демілітаризованої зони. Політика включає основні правила для дозволу обмеженого вхідного доступу, необмеженого вихідного доступу та правил проти спуфінгу. Оскільки зони, що захищаються, та DMZ використовують приватні IP-адреси, їм необхідний NAT та джерело призначення. Переадресація IP включена. введіть тут опис зображення

Я написав це для: http://www.vercot.com/~jeoss/howto/JeossEasyFirewall.html

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.