Правила вхідного трафіку SSH і VPN: чим насправді керує список дозволених

Прослідкуйте одне з’єднання від клієнта до хоста: який гак воно перетинає, чому зависання й відмова означають різні правила і чому відхилення ніколи не є політикою.

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

Прослідкуйте одну спробу SSH до гака входу

Клієнт надсилає SYN на адресу хоста через порт 22, і ядро вирішує, чи цей пакет для локальної служби. Якщо так, виконується вхідний шлях і набір правил приймає пакет або відкидає його. Тиша означає, що SYN загинув раніше, ніж слухач його побачив, а швидка відмова означає, що щось відповіло скиданням. Це різні вердикти різних правил, і обидва — законні результати.

Далі перевірте слухача, бо жодне правило не врятує службу, якої немає. Запустіть ss -ltnp і переконайтеся, що щось прив’язане до очікуваного порту й родини адрес, а потім прочитайте ssh -v на клієнті, щоб побачити, де він зупиняється.

Пересилання — окреме рішення

На VPN-сервері цікавіший гак — forward, бо трафік клієнта маршрутизується через машину, а не доставляється їй. Хост, який запускає лише власний VPN-клієнт, потребує значно меншого набору правил, ніж той, що пересилає чужі пакети. Змішування двох схем на одній машині породжує правила, які виглядають правильними і нічого не пропускають.

Запишіть внутрішню політику як окреме питання: які адреси клієнтів можуть досягати яких призначень через тунель. Тримайте адміністративний шлях, наприклад SSH, на вхідному шляху з власним обмеженням джерела. Дозвільне правило forward, додане під час тестування, — класичний дефект, що переживає тест, тому після зміни переглядайте весь набір правил, а не той рядок, який ви редагували. Відкриття слухача тунелю не є дозволом кожному підключеному клієнту адмініструвати хост.

Відкидання й відхилення — це дії, а не політики

Політика базового ланцюжка приймає або відкидає, і це весь перелік вибору, як зазначає довідка з nftables. Відхилення існує як дія правила з обраною відповіддю, тому запис його як політики зазнає невдачі і на nftables, і на iptables. На практиці drop не дає клієнтові жодної інформації, тоді як reject дає йому помилку, з якою можна працювати.

table inet admin {
    chain input {
        type filter hook input priority filter; policy drop;
        ct state established,related accept
        ip saddr 203.0.113.0/28 tcp dport 22 accept
        udp dport 51820 accept
        icmp type { destination-unreachable, time-exceeded } accept
    }
}

Читайте цей начерк як форму рішення, а не як файл для вставлення, бо діапазони адрес — це приклади. Явний reject на порту SSH змушує неавторизованого клієнта зазнати невдачі за секунду замість очікування тайм-ауту, що скорочує ваше власне налагодження. Тиша відлякує випадкове сканування і не повідомляє авторизованому користувачеві геть нічого. Вибирайте для кожної служби й записуйте чому, інакше наступна людина все поверне.

Збережіть той керуючий трафік, який справді потрібен

Блокування всього ICMP — популярне типове налаштування, яке ламає виявлення MTU шляху, а симптом — з’єднання, що встановлюється і потім застрягає на більших пакетах. Виявлення сусідів у IPv6 залежить від власних типів ICMPv6, і їх відкидання ламає канал раніше, ніж буде прочитано будь-яке правило TCP. І те, і те належить до списку дозволених як названі залежності, а не як суцільні дозволи. Політика, яка мовчки ламає виявлення, гірша за ту, що допускає трохи діагностичного трафіку.

Дозвольте стани established і related для з’єднань, які ви почали самі, і залиште обробку відповідей механізму станів. Потім переконайтеся, що шлях відповіді не заблокований далі, бо обмеження лише на вихідний трафік вище дає той самий тайм-аут, який ви збиралися списати на хост.

Доведіть відновлення, перш ніж відмовитися від старого шляху

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

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

Схожі статті