Фільтр Fail2ban для OpenVPN Access Server: real_ip і jail

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

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

Це процедура, якої я дотримуюся на хості з Access Server: підтвердити форму запису, написати один закріплений вираз, перевірити його на справжньому журналі, потім поділити jail за атакованою поверхнею і переконатися, що блокування доходить до міжмережевого екрана.

Переконайтеся, що запис про невдачу існує

Access Server пише свої структуровані рядки в /var/log/openvpnas.log, а адреса клієнта міститься в полі real_ip у лапках, а не на початку рядка syslog. Перш ніж писати будь-який шаблон, знайдіть невдалий вхід, який, як ви знаєте, відбувся:

grep -i 'LOG ERR' /var/log/openvpnas.log | tail -20

Якщо нічого не з'явилося, наступний підозрюваний — рівень журналювання. У Access Server є налагоджувальний перемикач бази даних журналу в /usr/local/openvpn_as/etc/as.conf (DEBUG_LOGDB=1), і службу потрібно перезапустити після його зміни. Ставтеся до цього перемикача як до діагностичного налаштування, яке треба знову знизити, коли шаблон готовий, а не як до постійної конфігурації.

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

Закріпіть один фільтр на real_ip

Тримайте вираз вузьким. Фільтр, який привласнює кожен рядок з IP-адресою, блокуватиме людей за звичайні обриви зв'язку, а на завантаженому сервері єдиний симптом — скарги користувачів, що їх заблокували за закриття ноутбука. Привласніть запис про помилку й захопіть адресу в лапках:

# /etc/fail2ban/filter.d/openvpnaccess.local
[Definition]
failregex = ^ .*LOG ERR.*"real_ip": "<HOST>".*
ignoreregex =

Провідний пробіл — не косметика. Access Server робить відступ у своїх записах, і закріплення на ньому не дає шаблону привласнювати ще й рядки, які в той самий файл пишуть не пов'язані служби. Якщо у ваших записах натомість на початку стоїть позначка часу, зіставте цей префікс, але закріпіться на тому, що справді присутнє в кожному записі, який ви збираєтеся привласнити.

Коли потрібна точність за поверхнями, звужте ще більше, вимагаючи маркер поверхні (WEB_CLIENT, WEB_ADMIN або VPN) у тому самому рядку. Один фільтр із трьома шаблонами простіше перевіряти, ніж три фільтри, що різняться одним словом.

Перевірте вираз до вмикання jail

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

fail2ban-regex --print-all-missed /var/log/openvpnas.log \
  /etc/fail2ban/filter.d/openvpnaccess.local \
  /etc/fail2ban/filter.d/openvpnaccess.local > missed.txt

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

Робіть цей тест на копії, якщо журнал великий, і повторюйте його після кожного оновлення Access Server. Формат журналу — це інтерфейс, з яким ви зіставляєте, і він не є стабільним API.

Поділіть jail за поверхнею, а не за демоном

Один Access Server надає кілька поверхонь автентифікації: клієнтський і адміністративний веб-інтерфейси на 943/tcp і тунель на 1194/udp або 443/tcp у більшості розгортань. Один jail, що покриває їх усі, дозволяє спробам перебору на тунелі блокувати адресу, яка також є вашим адміністративним шляхом, і приховує, яка поверхня насправді під атакою. Дайте кожній поверхні власний jail зі своїм портом і порогами:

# /etc/fail2ban/jail.d/openvpnaccess.local
[openvpnas-web-client]
enabled  = true
port     = 943
protocol = tcp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 3
findtime = 10m
bantime  = 1h
[openvpnas-tunnel]
enabled  = true
port     = 443
protocol = udp
filter   = openvpnaccess
logpath  = /var/log/openvpnas.log
maxretry = 5
findtime = 10m
bantime  = 1h

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

Перевірте блокування, бекенд і побічну шкоду

Після перезапуску вивід статусу — найшвидше підтвердження того, що jail існує й рахує:

fail2ban-client status
fail2ban-client status openvpnas-tunnel

Потім переконайтеся, що блокування доходить до міжмережевого екрана, який ви справді ведете, бо jail, налаштований для бекенду, який ніхто не застосовує, нічого не захищає. З дією iptables адреси з'являються в ланцюжку, названому за jail (f2b-openvpnas-tunnel); з дією nftables вони потрапляють до набору у власній таблиці fail2ban. Перевірте той, який використовує ваш хост, замість того щоб припускати.

Дві побічні перевірки важливіші за саме блокування. По-перше, переконайтеся, що real_ip — це адреса клієнта, а не балансувальник навантаження чи зворотний проксі; за проксі кожне блокування потрапляє на проксі й тягне за собою весь сервіс. По-друге, запишіть процедуру розблокування, бо адреса, яка в 02:00 перевищує поріг, зазвичай належить черговому інженерові: fail2ban-client set openvpnas-tunnel unbanip 203.0.113.24.

Тримайте межу в голові, поки налаштовуєте. Fail2ban — це обмежувач швидкості на одній поверхні автентифікації, а не шар контролю доступу. Він не замінює MFA, обмежень за обліковими записами чи утримання адміністративного інтерфейсу поза публічним інтернетом, і в Access Server є власні налаштування autoban, які варто перевірити, перш ніж ставити два обмежувачі швидкості на один і той самий порт.

Схожі статті