Едно 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. Действието по подразбиране за бан е 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 няма да му каже нито едното.