Фільтр Fail2ban для OpenVPN 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 ёсць уласныя налады аўтабану, якія варта праверыць, перш чым ставіць два абмежавальнікі хуткасці на адзін порт.