Чи вважається прийняття ПОВ'ЯЗАНОГО, Встановленого для всіх джерел у iptables "занадто відкритим"?

Я часто бачив, як -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPTзастосовується правило . Хоча я і не фахівець, цей конкретний напрямок стосується мене. Цілком очевидно, що правило дозволяє весь трафік, за винятком лише того, що з'єднання має бути встановлене або пов'язане з встановленим з'єднанням.

Сценарій

• Я дозволю підключення до SSH-порта за замовчуванням 22від локальної мережі серверів у підмережі 192.168.0.0/16чи будь-чого іншого.
• SuperInsecureApp®виставляє щось на порту 1337, що я додаю до свого INPUTланцюга.
• Я додав conntrackправило прийому ESTABLISHEDта RELATEDз усіх джерел
• Ланцюгова політика є DROP

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

Ось тут цвіте моя розгубленість. Чи може яким- conntrackнебудь чином виявити недолік безпеки, який дозволив би встановити встановлене з'єднання 1337 (оскільки він відкритий у світі), а потім використовувати це з'єднання для отримання доступу до порту SSH (або будь-якого іншого порту з цього приводу)?

Я б не вважав встановлений та пов'язаний трафік занадто відкритим. Можливо, ви можете пропустити ПОВ'ЯЗАННЕ, але обов'язково слід дозволити ВИСТАВЛЕНО Обидві ці категорії трафіку використовують стани переходу.

Встановлені з'єднання вже підтверджені іншим правилом. Це значно спрощує реалізацію однонаправлених правил. Це дозволяє лише продовжувати транзакції в одному порту.

ЗВ'ЯЗАНІ З'єднання також перевірені іншим правилом. Вони не застосовуються до багатьох протоколів. Знову вони значно спрощують налаштування правил. Вони також забезпечують належну послідовність з'єднань там, де вони застосовуються. Це фактично робить ваші правила більш безпечними. Хоча це може зробити можливим підключення до іншого порту, цей порт повинен бути лише частиною пов'язаного процесу, наприклад з'єднання даних FTP. Дозволені порти контролюються модулями, що стосуються протоколу conntrack.

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

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

Вкрай малоймовірно, що з'єднання на порту 1337 може використовуватися для доступу до порту 22 віддалено, але можливо, що з'єднання з портом 1337 могло бути використане для проксі-з'єднання до порту 22.

Ви можете переконатися, що SSH захищено в глибині:

• Використовуйте hosts.allow, щоб обмежити доступ на додаток до обмежень брандмауера.
• Запобігати кореневому доступу або хоча б вимагати використання клавіш та обмежувати їх доступ у файлі санкціонованих ключів.
• Аудит збоїв входу. Сканер журналу може надсилати вам періодичні звіти про незвичайні дії.
• Подумайте про використання такого інструменту, як fail2ban, для автоматичного блокування доступу при повторних збоях у доступі.

ВИСТАВЛЕНО та ЗВ'ЯЗАНО - це особливості фільтрування пакетів "станів", де фільтрація залежить не тільки від набору статичних правил, але і від контексту, в рамках якого пакети розглядаються. Вам потрібно ВИСТАВКИ, щоб дозволити роботі з’єднань, і вам потрібно ВЗАЄМО для відповідних повідомлень ICMP Державна фільтрація дозволяє більш точно фільтрувати порівняно зі статичними правилами "без стану".

Давайте спочатку подивимось на СТВОРЕНО. Наприклад, розглянемо TCP на порт 22. Ініціатор (клієнт) надсилає SYNдо serverIPaddr:22. Сервер повертається SYN+ACKдо клієнта. Тепер черга клієнта надіслати його ACK. Як має виглядати правило фільтрації на сервері таким, що ACKприймається лише "відповідність" ? Загальне правило без громадянства виглядало б так

-A INPUT --proto tcp --port 22 -j ACCEPT

що є більш ліберальним, ніж згідно з державним правилом. Правило без стану дозволяє довільні сегменти TCP, наприклад, ACKабо FINбез встановлення спочатку з'єднання. Порти сканери можуть використовувати подібну поведінку для відбитків пальців на ОС.

Тепер давайте подивимось на ПОВ'ЯЗАНІ. Це використовується для повідомлень ICMP, переважно повідомлень про помилки. Наприклад, якщо пакет від сервера до клієнта скинутий, то повідомлення про помилку надсилається на сервер. Це повідомлення про помилку "пов'язане" з раніше встановленим з'єднанням. Без ПОВ'ЯЗАНОГО правила потрібно або дозволити вхідні повідомлення про помилки взагалі (без контексту), або, як це прийнято для багатьох сайтів, взагалі скинути ICMP і чекати очікування часу на транспортному шарі. (Зауважте, що це погана ідея для IPv6; ICMPv6 відіграє важливішу роль для IPv6, ніж ICMP для спадщини IP.)