Egy banaction, két átvitel: egy fail2ban-VPN-jail javítása

Semmi sem dob el egy csomagot magától a fail2banben: meghív egy műveletet, és az a művelet nevezi meg a protokollt és a portot. Amikor a jail bant jelent, miközben a démon tovább fogadja a bejelentkezéseket, a ban általában valódi és szűkebb annál, mint amit a napló sugall. Az az ügyfél, amely a másik átvitelen keresztül csatlakozik újra, soha nem találkozik a telepített szabállyal. Mielőtt bármit módosítana, hasonlítsa össze, mit telepített a művelet azzal, mire a démon figyel, mert a bizonyíték abban a tűzfal-láncban van, amelyet a művelet írt, nem a jail listájában.

A láncot olvassa, ne a jail összefoglalóját

A fail2ban saját láncát a szolgáltatás lánca elé szúrja be, így a számlálók listája pontosan megmutatja, mi létezik. Egy jailről elnevezett lánc, amely egyetlen szabályt tartalmaz, és amelynek protokoll oszlopa udp-t mutat, teljes magyarázat a továbbra is érkező TCP-bejelentkezésekre. Csak a tiltott forrás UDP-csomagjai kerülnek elutasításra. A szolgáltatásnak van egy TCP-figyelője, és abban a láncban semmi sem nyúl hozzá.

Figyeljen a szomszédos jail hatására is. Egy hoszt tökéletesen konfiguráltnak tűnhet csupán azért, mert egy másik jail biztosítja a hiányzó felét, és ugyanaz a build semmit sem tesz ott, ahol az a jail nincs telepítve.

A művelet egy protokollt nevez meg, és ott törik el

Minden banaction egy tűzfalparancs-sablon, és a protokoll az egyik helyőrzőjében ül. A szűkösség szándékos, hiszen egy webes jailnek és egy DNS-jailnek semmi keresnivalója azonos portok blokkolásában. Akkor válik csapdává, amikor a szolgáltatás egynél több átvitelen figyel, amit a VPN-démonok rendszeresen tesznek. A szűrő figyelheti mindkét átvitel sikertelen bejelentkezéseit, miközben a művelet csak egyet fed le.

A SoftEther és OpenVPN telepítések általában egyszerre figyelnek UDP-n és TCP-n, és mivel a naplósor mindkét esetben ugyanúgy néz ki, a szűrő mindkettőt figyeli. Az aszimmetria soha nem jelenik meg a jail saját jelentésében. A fail2ban helyesen megszámolta a hibákat, majd olyan szabályt telepített, amely annak a forgalomnak a felére vonatkozik, amelyen ezek a hibák érkeztek.

Tegye a bant mindkét átvitelre kiterjedővé

Inkább a jail definíciójában javítsa; a kézzel írt szabályokat a következő újratöltés összekeveri. Írjon ki két műveletet, egyet-egyet minden protokollhoz:

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"]

Ne próbálja ezt a protocol = all beállítással lerövidíteni. Az alapértelmezett banaction egy multiport művelet, és -p <protocol> -m multiport --dports <port>-re bővül; L4-protokoll nélkül nincs mit tesztelnie a portegyezésnek, ezért az iptables elutasítja a szabályt, miközben a jail továbbra is sikeres bant jelent. Egy minden portot érintő művelet, például a iptables-allports vagy a nftables-allports, elfogad egyetlen bejegyzést, de minden portot blokkol azon a forráson, ami más döntés, és saját indoklást igényel. Hagyja a protocol-t tcp-n vagy udp-n, és fogadja el a két bejegyzést.

Bizonyítsa, hogy a szabály létezik, ahelyett hogy a beállításban bízna, mert a beállítás szándékot ír le, amíg egy lánc nem tartja:

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

Minden láncnak egy szabályt kell felsorolnia, az elsőben -p tcp, a másodikban -p udp, és mindkettő a tiltott címet nevezi meg. Ezután erősítse meg, hogy ugyanaz a cím mindkét átvitelen elutasításra kerül. Az a ban, amelyet nem látott a láncban, remény, és ugyanazon tünet következő jelentése újra ugyanabba az órába kerül.

Amit egy ban még mindig kihagy, és a következő eset

A művelet egyetlen forrást utasít el, és csak az abban felsorolt portokon. Nem tesz semmit a címeket váltogató támadó ellen, és nem tudja elválasztani egy ellenséges gépet egy szolgáltatói szintű NAT-kijárattól, amelyet több száz felhasználó oszt meg, ahol egy ban kizárja azokat, akik semmit sem tettek. Győződjön meg róla, hogy a szűrő azt a címet olvassa, amellyel az ügyfél valóban rendelkezik, nem egy továbbított fejlécet vagy proxycímet. Tartsa elég rövidre az ablakot ahhoz, hogy egy hiba magától lejárjon.

Ezek egyike sem amellett érvel, hogy kihagyja a protokolljavítást; amellett érvel, hogy két gondolatot tartson egyszerre. A ban szűkebb annál, mint amit a jail összefoglalója sugall, és még egy teljes ban is szűkebb a fenyegetésnél. Tegye a tűzfal-láncot a démon figyelőlistája mellé, és hasonlítsa össze protokollról protokollra, mert ez a két lista dönti el, hogy egy ban egyáltalán elérheti-e a szolgáltatást.

Tartsa az újratöltési parancsot és a lánclistát a runbookban a jail mellett. A következő embernek mindkettőre szüksége lesz, és a jail összefoglalója egyiket sem fogja megmondani neki.