Yksi banaction, kaksi transporttia: fail2ban-VPN-jailin korjaaminen

Mikään fail2banissa ei pudota pakettia itsestään: se kutsuu toiminnon, ja juuri tuo toiminto nimeää protokollan ja portin. Kun jail raportoi banista samalla kun daemon jatkaa kirjautumisten vastaanottamista, ban on yleensä todellinen ja kapeampi kuin loki antaa ymmärtää. Asiakas, joka yhdistää uudelleen toisen transportin kautta, ei koskaan kohtaa asennettua sääntöä. Vertaa ennen muutoksia sitä, mitä toiminto asensi, siihen, mitä daemon kuuntelee, sillä todiste on palomuuriketjussa, jonka toiminto kirjoitti, ei jailin listassa.

Lue ketju, älä jailin yhteenvetoa

fail2ban lisää oman ketjunsa palvelun ketjun eteen, joten laskurilistaus näyttää tarkalleen, mitä on olemassa. Jailin mukaan nimetty ketju, jossa on yksi sääntö ja jonka protokollasarake näyttää udp, on täydellinen selitys yhä saapuville TCP-kirjautumisille. Vain estetyn lähteen UDP-paketit hylätään. Palvelulla on TCP-kuuntelija, eikä mikään tuossa ketjussa kosketa sitä.

Huomaa myös naapuri-jailin vaikutus. Yksi isäntä voi näyttää täydellisesti määritetyltä vain siksi, että toinen jail toimittaa puuttuvan puolikkaan, eikä sama build tee mitään siellä, missä tuota jailia ei ole asennettu.

Toiminto nimeää yhden protokollan, ja juuri siinä se murtuu

Jokainen banaction on palomuurikomennon mallipohja, ja protokolla on yhdessä sen paikkamerkeistä. Kapeus on tarkoituksellista, sillä verkkosivun jaililla ja DNS-jaililla ei ole mitään tekemistä identtisten porttien estämisen kanssa. Siitä tulee ansa, kun palvelu kuuntelee useampaa kuin yhtä transporttia, mitä VPN-daemonit tekevät säännöllisesti. Suodatin voi seurata epäonnistuneita kirjautumisia molemmista transporteista, kun toiminto kattaa yhden.

SoftEther- ja OpenVPN-käyttöönotot kuuntelevat yleensä UDP:tä ja TCP:tä yhtä aikaa, ja koska lokirivi näyttää molemmissa tapauksissa samalta, suodatin seuraa molempia. Epäsymmetria ei koskaan näy jailin omassa raportissa. fail2ban laski epäonnistumiset oikein ja asensi sitten säännön, joka koskee puolta siitä liikenteestä, jolla ne epäonnistumiset saapuivat.

Anna banin kattaa molemmat transportit

Korjaa se sen sijaan jailin määritelmässä; käsin kirjoitetut säännöt sekoitetaan seuraavassa uudelleenlatauksessa. Kirjoita kaksi toimintoa auki, yksi kullekin protokollalle:

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

Älä yritä lyhentää sitä asetuksella protocol = all. Oletusarvoinen banaction on multiport-toiminto, ja se laajenee muotoon -p <protocol> -m multiport --dports <port>; ilman L4-protokollaa porttiosumalla ei ole mitään testattavaa, joten iptables hylkää säännön, kun taas jail raportoi edelleen onnistuneesta banista. Kaikki portit kattava toiminto kuten iptables-allports tai nftables-allports hyväksyy yhden merkinnän, mutta estää jokaisen portin kyseisessä lähteessä, mikä on eri päätös ja vaatii oman perustelunsa. Jätä protocol arvoon tcp tai udp ja hyväksy kaksi merkintää.

Todista, että sääntö on olemassa sen sijaan että luottaisit asetukseen, sillä asetus kuvaa aikomuksen, kunnes ketju pitää sitä:

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

Jokaisen ketjun tulisi luetella yksi sääntö, ensimmäisessä -p tcp ja toisessa -p udp, ja molempien tulee nimetä estetty osoite. Vahvista sitten, että sama osoite hylätään molemmissa transporteissa. Ban, jota et ole nähnyt ketjussa, on toivo, ja seuraava raportti samasta oireesta maksaa jälleen saman tunnin.

Mitä ban yhä ohittaa, ja seuraava tapaus

Toiminto hylkää yhden lähteen, ja vain siinä luetelluilla porteilla. Se ei tee mitään hyökkääjää vastaan, joka vaihtaa osoitteita, eikä se pysty erottamaan vihamielistä konetta operaattoritason NAT-uloskäynnistä, jota sadat käyttäjät jakavat, missä yksi ban sulkee ulos ihmisiä, jotka eivät tehneet mitään. Varmista, että suodatin lukee osoitteen, joka asiakkaalla todella on, ei välitettyä otsikkoa tai välityspalvelimen osoitetta. Pidä ikkuna tarpeeksi lyhyenä, jotta virhe vanhenee itsestään.

Mikään tuosta ei perustele protokollakorjauksen väliin jättämistä; se perustelee kahden idean pitämistä yhtä aikaa. Ban on kapeampi kuin jailin yhteenveto antaa ymmärtää, ja jopa täydellinen ban on uhkaa kapeampi. Aseta palomuuriketju daemonin kuuntelijalistan viereen ja vertaa protokolla protokollalta, sillä nuo kaksi listaa päättävät, voiko ban ylipäätään päästä palveluun.

Pidä uudelleenlatauskomento ja ketjulistaus runbookissa jailin vieressä. Seuraava henkilö tarvitsee molemmat, eikä jailin yhteenveto kerro hänelle kummastakaan.