Адзін banaction, два транспарты: выпраўленне fail2ban-VPN-jail

Нішто ў fail2ban не адкідае пакет само па сабе: ён выклікае дзеянне, і менавіта гэтае дзеянне называе пратакол і порт. Калі jail паведамляе пра бан, а дэман працягвае прымаць лагіны, бан звычайна рэальны і вузейшы, чым вынікае з лога. Кліент, які перападключаецца праз іншы транспарт, ніколі не сустракае ўстаноўленае правіла. Параўнайце, што ўсталявала дзеянне, з тым, што слухае дэман, перш чым нешта змяняць, бо доказы ляжаць у ланцугу фаервала, які запісала дзеянне, а не ў спісе jail.

Чытайце ланцуг, а не зводку jail

fail2ban устаўляе свой ланцуг перад ланцугом сэрвісу, таму спіс лічыльнікаў паказвае менавіта тое, што існуе. Ланцуг, названы па jail і які змяшчае адно правіла, дзе слупок пратакола чытаецца як udp, цалкам тлумачыць лагіны TCP, якія працягваюць прыходзіць. Адхіляюцца толькі UDP-пакеты з заблакаванай крыніцы. Сэрвіс мае слухач TCP, і нішто ў тым ланцугу яго не закранае.

Звярніце ўвагу і на эфект суседняга jail. Адзін хост можа выглядаць цалкам настроеным проста таму, што іншы jail забяспечвае адсутную палову, і тая ж зборка нічога не робіць там, дзе гэты jail не ўсталяваны.

Дзеянне называе адзін пратакол, і менавіта тут яно ламаецца

Кожны banaction — гэта шаблон каманды фаервала, і пратакол знаходзіцца ў адным з яго запаўняльнікаў. Вузкасць наўмысная, бо вэб-jail і DNS-jail не маюць справы з блакаваннем аднолькавых партоў. Гэта становіцца пасткай, калі сэрвіс слухае больш за адзін транспарт, што дэманы VPN робяць рэгулярна. Фільтр можа назіраць за няўдалымі лагінамі з абодвух транспартаў, пакуль дзеянне пакрывае адзін.

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

Зрабіце так, каб бан пакрываў абодва транспарты

Выпраўце гэта ў вызначэнні 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 усё яшчэ паведамляе пра паспяховы бан. Дзеянне для ўсіх партоў, напрыклад iptables-allports або nftables-allports, прымае адзін запіс, але блакуе ўсе парты на гэтай крыніцы, што з'яўляецца іншым рашэннем і патрабуе ўласнага абгрунтавання. Пакіньце protocol на tcp або udp і прыміце два запісы.

Дакажыце, што правіла існуе, замест таго каб давяраць наладу, бо налад апісвае намер, пакуль ланцуг яго не ўтрымае:

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

Кожны ланцуг павінен змяшчаць адно правіла: у першым -p tcp, у другім -p udp, і абодва называюць заблакаваны адрас. Затым пераканайцеся, што той самы адрас адхіляецца на абодвух транспартах. Бан, якога вы не бачылі ў ланцугу, — гэта надзея, і наступная справаздача пра той самы сімптом зноў каштавацьме тую ж гадзіну.

Што бан усё яшчэ прапускае, і наступны выпадак

Дзеянне адхіляе адну крыніцу і толькі на партах, пералічаных у ім. Яно нічога не робіць з нападаючым, які змяняе адрасы, і не можа аддзяліць варожую машыну ад выхаду carrier-grade NAT, якім карыстаюцца сотні людзей, дзе адзін бан адсякае людзей, якія нічога не зрабілі. Пераканайцеся, што фільтр чытае адрас, які кліент сапраўды мае, а не перададзены загаловак або адрас проксі. Трымайце акно дастаткова кароткім, каб памылка скончылася сама.

Нішто з гэтага не кажа прапускаць выпраўленне пратаколу; гэта кажа трымаць дзве думкі адначасова. Бан вузейшы, чым мяркуе зводка jail, і нават поўны бан вузейшы за пагрозу. Пастаўце ланцуг фаервала побач са спісам слухачоў дэмана і параўнайце пратакол за пратаколам, бо менавіта гэтыя два спісы вырашаюць, ці можа бан наогул дасягнуць сэрвісу.

Трымайце каманду перазагрузкі і спіс ланцугоў у runbook побач з jail. Наступнаму чалавеку спатрэбяцца абодва, а зводка jail не скажа ні пра адно.