Один banaction, два транспорти: виправлення fail2ban VPN jail

Ніщо у fail2ban саме по собі не відкидає пакет: воно викликає дію, і саме ця дія називає протокол і порт. Коли jail повідомляє про ban, а демон продовжує приймати входи, ban зазвичай реальний і вужчий, ніж випливає з логу. Клієнт, який перепідключається через інший транспорт, ніколи не зустрічає встановлене правило. Перш ніж щось змінювати, порівняйте, що встановила дія, з тим, що слухає демон, бо доказ лежить у ланцюжку міжмережевого екрана, який записала дія, а не в списку jail.

Читайте ланцюжок, а не підсумок jail

fail2ban вставляє свій ланцюжок перед ланцюжком сервісу, тому список лічильників показує рівно те, що існує. Ланцюжок, названий за jail, що містить одне правило, у стовпці протоколу якого читається udp, — це повне пояснення для входів TCP, які продовжують надходити. Відхиляються лише пакети UDP із заблокованого джерела. Сервіс має слухача TCP, і ніщо в тому ланцюжку його не торкається.

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

Дія називає один протокол, і саме там вона ламається

Кожен banaction — це шаблон команди міжмережевого екрана, і протокол стоїть в одному з його заповнювачів. Вузькість навмисна, бо web-jail і DNS-jail не мають стосунку до блокування однакових портів. Це стає пасткою, коли сервіс слухає більше ніж один транспорт, що демони VPN роблять регулярно. Фільтр може відстежувати невдалі входи з обох транспортів, поки дія покриває один.

Розгортання SoftEther і OpenVPN зазвичай слухають UDP і TCP одночасно, і оскільки рядок логу виглядає однаково в обох випадках, фільтр стежить за обома. Асиметрія ніколи не проявляється у звіті самого jail. fail2ban правильно порахував збої, а потім встановив правило, яке діє на половину трафіку, на якому прийшли ці збої.

Нехай ban покриває обидва транспорти

Виправте це у визначенні jail; правила, написані вручну, буде перемішано під час наступного перезавантаження. Випишіть дві дії, по одній на кожен протокол:

action = %(banaction)s[name=%(__name__)s-tcp, actionname=%(__name__)s-tcp, protocol="tcp", port="%(port)s", chain="%(chain)s"]
         %(banaction)s[name=%(__name__)s-udp, actionname=%(__name__)s-udp, protocol="udp", port="%(port)s", chain="%(chain)s"]

Не намагайтеся скоротити це за допомогою protocol = all. Типовий banaction — це multiport-дія, і вона розгортається в -p <protocol> -m multiport --dports <port>; без протоколу L4 зіставленню порту нема чого перевіряти, тому iptables відхиляє правило, поки jail досі повідомляє про успішний ban. Дія для всіх портів, наприклад iptables-allports або nftables-allports, приймає один запис, але блокує кожен порт на цьому джерелі, що є іншим рішенням і потребує власного обґрунтування. Залиште protocol на tcp або udp і прийміть два записи.

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

iptables -S f2b-vpn-tcp
iptables -S f2b-vpn-udp

Кожен ланцюжок має перелічувати одне правило: у першому -p tcp, у другому -p udp, і обидва називають заблоковану адресу. Потім підтвердьте, що та сама адреса відхиляється на обох транспортах. ban, якого ви не бачили в ланцюжку, — це надія, і наступний звіт про той самий симптом знову коштуватиме тієї ж години.

Що ban досі пропускає, і наступний випадок

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

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

Тримайте команду перезавантаження і список ланцюжків у runbook поряд із jail. Наступній людині знадобиться і те й інше, а підсумок jail не скаже їй ані того, ані того.