Tartalom

Bevezető

Weboldalaink folyamatos támadásnak vannak kitéve a külvilág felől. Ezeknek túlnyomó részét robotok végzik, amik megpróbálják felderíteni a szerveren futó weboldalak gyenge pontjait. Az ilyen célú robotoknak egy része ezt úgy próbálja megtenni, hogy weboldalaink felé különböző, véletlenszerűnek tűnő HTTP lekéréseket intéznek, amiknek a java része nem létező URL címekre irányul. Ennek következtében szerverünk 404-es HTTP válaszkóddal reagál. Ezzel alapból még nem is lenne gond, azonban az ilyen támadási kísérletek általában rövid időintervallumokban történnek, ami alatt nagyon nagy mennyiségű lekérést küldenek szerverünk felé, ami szintén nagy mennyiségű 404-es vagy esetenként más 4xx válaszkódokat eredményez. A nagy mennyiségű lekérések viszont már okozhatnak terhelési tüskéket, amik a szerver nem kívánt teljesítménycsökkenéséhez vezethetnek.

Korábban már készítettem egy hasonló leírást, amiben robotokat tiltogattunk ki a Fail2Ban, illetve az Apache .htaccess fájljainak segítségével, ebben
a leírásban pedig megnézzük hogyan tilthatjuk ki a nagy mennyiségben érkező, 404 és egyéb 4xx HTTP válaszkódokat eredményező próbálkozásokat szintén a Fail2Ban segítségével.

A támadás mikéntje

Ilyenkor általában a támadást végrehajtó fél megpróbálja feltérképezni weboldalaink vélt gyenge pontjait, amit úgy próbál elérni, hogy az általa ismert fájl- és könyvtár mintákat kutatva megpróbálja megállapítani rendszerünk típusát, ezáltal például ismertebb CMS rendszerek esetén felmérni azoknak biztonsági hiányosságait. Ez a jelenség általában egy átfogóbb elemzés egy kisebb része, ahol például még DNS ellenőrzéseket is szoktak végezni, vagy akár egy port szkennelést is végrehajtanak, amivel a nyitot portjainkat ellenőrzik. Míg az első tevékenységeket nehezebb tetten érni, addig ezek a nagy mennyiségű 404-es és egyéb 4xx HTTP hibakódok a legárulkodóbb jelek erre a fajta támadási kísérletre nézve, valamint ezeknek a szűrését és tiltását könnyen elvégezhetjük.

Az alábbi képen láthatunk egy tegnapi  Apache napló részletet, ahol szűrve megjelennek ezek a 404-es és egyéb 4xx-es HTTP válaszkódokat eredményező lekérések:

Amint láthatjuk, itt igen rövid idő alatt érkeznek nagyon nagy mennyiségben ezek a lekérések. Bár a sorozat eleje nem látszik a képen, de ezek tegnap körülbelül 5-10 perc leforgása alatt generáltak összesen több, mint 6000 Apache lekérést. Amikre ha jobban ránézünk, ezeknek a túlnyomó többsége 404-es hiba:

Ha használunk valamilyen rendszer erőforrás monitorozó szoftvert, mint például a Munin-t, akkor ebben is jól látszik az Apache grafikon közepén a környezetéből erősen kiemelkedő tüske:

A grafikon szerint ebben az 5 perces ciklusban elérte a lekérések száma a másodpercenkénti 20 lekérést is. Amit ha kivetítenénk mondjuk egy órára, akkor az 72.000 lekérésnél is több lehet. Persze szerencsére időben észrevettem, és átmeneti megoldásként tiltottam az IP-címet az UFW tűzfalban. Ki tudja meddig jött volna még, ha nem tiltom.

Szerencsére ezek az ilyen 404-es HTTP hibakódokat eredményező lekérések fajlagosan nem kavarnak nagy port a CPU terhelés környékén, mert ahogy a CPU grafikonon láthatjuk, abban az idősávban nincs semmilyen tüske. Amik itt 12 óránként kicsúcsosodnak, azok a WordPress oldalak belső cachelési mechanizmusai által generált terhelés (WP Super cache plugin):

Átmeneti megoldás

Átmeneti megoldásként az UFW tiltó parancsa ilyenkor a gyors helyzetekre egyszerű:

sudo ufw insert 1 deny from 34.64.0.0/10

Természetesen nem ez a megfelelő megoldás, ezzel csak ideiglenesen megállítottam kb 6300-nál a lekérések számát, hanem tartós megoldásként egy Fail2Ban Jail-t fogunk létrehozni, ami automatán kezeli majd ezeket a próbálkozásokat is. Az után pedig már feloldhatjuk a kézi tiltásunkat, mert egy nagyobb IP tartományból érkezhetnek normális látogatások is (persze egy hoszting szolgáltató IP-címeiről erre kicsi az esély, mert az ilyen helyekről többnyire robotokat szoktak indítani).

A támadás elhárítása a Fail2Ban segítségével

Aki még nem ismerné a Fail2Ban programot, azoknak csak röviden annyit érdemes tudni róla, hogy a webszerverek működtetése során használt talán a leghatékonyabb védelmi eszköz. A működési elve annyi, hogy a különböző naplófájlokban - reguláris kifejezésekkel definiált - mintákat keresgélve számlálja a találatokat, majd a meghatározott limitek elérésekor tűzfal szabályokkal tiltja a kérdéses IP-címeket. Azután a szintén beállított idő elteltével pedig feloldja a letiltott klienseket. Így a "körforgás" folytonos, nem marad végleg letiltott IP-cím, a frissen elemzett gyanús eseteket pedig egyből tiltja. Nagyszerűsége tehát éppen az egyszerűségében rejlik. Ha még nincs fent a szerverünkön, akkor kezdjük is a telepítésével.

Amennyiben például ISPConfig-os szerverkörnyezetet használunk, akkor már telepítve van szerverünkön ez a védelmi eszköz, ebben az esetben átugorva a telepítést és a naplófájlok forgatását, folytassuk a beállítással.

A Fail2Ban telepítése

A Fail2Ban telepítéséhez futtassuk az alábbi parancsot root-ként:

apt-get install fail2ban

Naplófájlok forgatása

A Fail2Ban idővel méretes naplófájlokat produkál, ezért erősen ajánlott gondoskodnunk a naplófájlok forgatásáról is. Erre itt most nem térünk ki, mert ennek a leírásnak nem ez a témája, valamint már több másik leírásban is foglalkoztunk ezzel, amiket az alábbi linkeken tekinthetünk meg:

• Naplófájlok forgatása és tömörítése a Logrotate programmal
• Hogyan telepíthetjük fel a PHP 8-at Debian vagy Ubuntu rendszerű szerverünkre - Log fájlok lekezelése
• UFW tűzfal telepítése, alapvető beállítása és használata Debian / Ubuntu rendszereken - Naplófájlok forgatása

Fail2Ban beállítása

A Fail2Ban beállításához két dolgot kell tenni:

• először létre kell hozni egy szűrőfájlt a /etc/fail2ban/filter.d/ könyvtárban
• ezután be kell állítani a jail-t a /etc/fail2ban/jail.local fájlban, ami alkalmazza a szűrőt a megfelelő naplófájlon, és működteti a jail-t

Az egyes beállítási módok bemutatása előtt még tekintsük meg az alábbi képet, amin 4 terminál látszódik egyszerre, ahol jobban észrevehető az egyes naplófájlok közötti különbség:

Ezt a másik VPS-emen készítettem, ahol az első három terminál különböző Apache naplófájlokat jelenít meg, a negyedik pedig a Fail2Ban naplóját mutatja.

Itt előre elkészítettem a beállításokat, amiket teszteltem mobiltelefonról, mobilnetről, hogy látható legyen a dolgok működése, és könnyebben érthetők legyenek az ez után következő beállítások.

A mobilról két virtualhost-on is teszteltem a 404-es hibák előidézését:

• a teljes hosztnéven elérhető címen (vps.linuxportal.eu), ami alól a különböző webalkalmazások érhetők el, pl ISPConfig, webmail, phpMyAdmin, stb.
• valamint az ezen a VPS-en található (jelenleg) egy szem "demó" tárhelyen (linuxportal.eu), ahol pedig egy sima webtárhely érhető el.

Itt lényeges megjegyezni, hogy ezek a támadások bárhova (bármelyik virtualhostra) érkezhetnek, tehát nem csak a normál weboldalainkat támadhatják, hanem a teljes hosztnév (FQDN) alatt elérhető webalkalmazásainkat is. Ennek megfelelően bármelyik virtualhoston számíthatunk az ilyen tömeges 404-es hibákra, ezért én is teszteltem a VPS-en jelenleg elérhető mindkét helyen:

A teljes hosztnév alatt a 8081-es porton (a 8081-es portnak később lesz még jelentősége) egy /aaaaaaa betöltést próbáltam, amire értelemszerűen hibát dobott. Ez a fentebbi 4 felé osztott terminálos képen a bal felső részen látszik a /var/log/ispconfig/httpd/vps.linuxportal.eu/access.log fájl ellenőrzésével. És a másik pedig:

a normál webtárhely alatti hibás próbálkozás, ahol a /bbbbbbbbbbbb útvonal elérését próbáltam, természetesen itt is hibával. Itt már azonban az ISPConfig kezelőpanel egyedi hibaoldala jön be, ami alapból be van állítva a létrehozott webtárhelyeken. Ennek az eredményét pedig az osztott képernyőn a jobb felső terminálban láthatjuk a /var/log/ispconfig/httpd/linuxportal.eu/access.log fájlba történő betekintéssel.

A Fail2Ban naplójában pedig látszik, ahogy néhány kísérlet után le is tiltotta a telefon IP-címét, ami után már nem is töltődött be semmi.

Ezek ismeretében akkor most lássuk a különböző naplófájlok felépítését, tehát innentől ágazik két lehetőségre a Fail2Ban beállítása.

IP-címek keresése a sorok elején

Az első variáció esetén azokat az Apache naplófájlokat használjuk, ahol a sorok az IP-címekkel kezdődnek, tehát az első oszlopban kell őket vizsgálnunk. Ilyen naplófájlok az ISPConfig-os szerverkörnyezet esetén a már fentebb is mutatott /var/log/ispconfig/httpd/ könyvtár alatt vannak további alkönyvtárakban:

(A webtárhelyek esetén ugyanezek a naplófájlok egyébként az ISPConfig által beállított bind mount segítségével a webtárhelyek struktúrájában is elérhetők, de ezzel most nem foglalkozunk)

Itt tehát a képen az alábbiak láthatók:

• A /var/log/ispconfig/httpd/ könyvtárban lévő virtualhost-ok (a webtárhely(ek) és a teljes hosztnévhez tartozó virtualhost) naplófájljait tartalmazó könyvtárak
• A könyvtárakban lévő access.log fájlok
• valamint egy rövid betekintés mindkét könyvtárban lévő access.log fájlba, ahol a 404-es hibákra szűrve láthatjuk a fentebbi mobiltelefonnal készített hiba teszteket, mindegyiket a saját könyvtárában lévő access.log fájlban.

Szűrőfájl beállítása

Ha tehát a /var/log/ispconfig/httpd/ struktúra alatt lévő naplófájlokkal szeretnénk beállítani a szűrőnket, akkor hozzunk létre egy fájlt a /etc/fail2ban/filter.d/ könyvtárban, amit most én apache-4xx.conf nak nevezek el:

nano /etc/fail2ban/filter.d/apache-4xx.conf

És tegyük bele az alábbi tartalmat.

[Definition]
# IP-címek keresése a sorok elején:
failregex = ^<HOST> -.*"(GET|POST|HEAD).*" (400|401|403|404) .*$

# Kivételek:
ignoreregex =.*(robots.txt|favicon.ico)

És mentsük le.

Rövid magyarázat:

• Itt a failregex elején megadott ^<HOST> résszel jelezzük, hogy a napló sorok az IP-címekkel kezdődnek, tehát ha tiltásra kerül a sor, akkor ezt használja a Fail2Ban.
• A középső részben GET, POST és HEAD lekéréseket is vizsgálunk
• Végül pedig a felsorolt hibakódok bármelyikének előfordulását figyelembe vesszük
• A kivételeknél pedig megadhatunk néhány olyan fájltípust, aminek nem kötelező ott lennie, de például a keresők robotjai időnként ott kereshetik. Hogy elkerüljük az ilyen hibákat, betesszük a kivételek közé ezeket.

Jail beállítása

Ha készen van a szűrőfájlunk, akkor ezután a jail-t kell még beállítani. Ehhez nyissuk meg szerkesztésre a /etc/fail2ban/jail.local fájlt:

nano /etc/fail2ban/jail.local 

Ha nem létezett még eddig ez a fájlt, akkor tegyük bele, ha már létezett és van benne valami, akkor pedig tegyük a végére az alábbi tartalmat:

[apache-4xx]
enabled = true
port = http,https,8080,8081
filter = apache-4xx
logpath  = /var/log/ispconfig/httpd/*/access.log
findtime = 60
maxretry = 5
banaction = %(known/banaction)s[blocktype=DROP]
bantime = 3600
ignoreip =

Magyarázat:

• [apache-4xx]: Ez a Jail-unk neve. Ez lehet bármi, de ne ütközzön a többi jail nevével, valamint célszerű, ha a név megegyezik a szűrőnk nevével is, így később könnyebb a karbantartás, stb. Mivel én a szűrőmnek ezt a nevet adtam, ezért itt is ezt használom. Persze ez nem kötelező, de logikus, ha így használjuk.
• enabled: Logikai kapcsoló: jail engedélyezve van-e.
• port: Itt kell vesszővel felsorolva megadni a figyelt portokat. A szokványos "http" és "https" mellett itt még adjuk meg a 8080 és 8081 portokat is, ezzel levédjük az ISPConfig kezelőpanelünket a 8080-ás porton, valamint a 8081-es porton a webalkalmazásokat (phpMyAdmin, webmail, Munin, stb). Természetesen ha ezek helyett egyedi portokat használunk, akkor azokat adjuk itt meg.
• filter: Itt a szűrőfájlunk pontos nevét kell megadni a .jail kiterjesztés nélkül. Én itt az "apache-4xx" nevet használom, amit a Fail2Ban "apache-4xx.conf" néven fog keresni a /etc/fail2ban/filter.d/ könyvtárban. Itt tehát pontos egyezőség szükséges.
• logpath: Itt kell megadni a naplófájl elérését. A "*" karakterrel helyettesíthetünk is. Ennek megfelelően a fenti beállítás pontosan illeszkedik az itt tárgyalt Apache naplófájl struktúrára, amivel az összes virtualhost access.log fájlja vizsgálatra kerül. Ennek a működését pedig a korábbi osztott képernyős terminálos kép jobb alsó terminálján láthatjuk, ahol a két darab "Added logfile" sorban mutatja a felhasznált naplófájlokat.
• findtime: A találatok során figyelt "időkeret" másodpercekben megadott értéke. Tehát ezen az időkereten belül kell teljesülnie a lentebb beállított maxretry (próbálkozások száma) értéknek. Ha nem adjuk meg, akkor az alapértelmezés 10 perc (10m). Ez az alapbeállítás a /etc/fail2ban/jail.conf fájlban van definiálva.
• maxretry: Próbálkozások száma. Ennyi előfordulás lehet a findtime időablakon belül. Ha ezt a számot eléri, akkor az IP-cím tiltásra kerül. Alapértelmezett értéke 5.
• banaction: A tiltás életbe lépésekor végrehajtott művelet. Ezt nem muszáj megadni. Ha nem adjuk meg, akkor a Fail2Ban alapértelmezetten egy REJECT típusú tiltó szabályt helyez el az iptables tűzfalban. Én viszont jobban szeretem a DROP használatát, ezért teszem bele. Ezeknek a különbségeiről az UFW fűzfal esetén írtam korábban (Az UFW tűzfal esetén használt DENY házirend megfelel az iptables DROP házirendjének). Tehát ez nem kötelező, de én jobban szeretem, ha ilyenkor teljesen eldobja a kapcsolatot és nem bíbelődik különböző válaszok küldésével.
• bantime: Tiltás időtartama másodpercekben megadva. Ha nem adjuk meg, akkor alapértelmezetten ez is 10 perc ("10m")
• ignoreip: Ez a fehér listázáshoz kell majd; az itt felsorolt IP-címeket nem tiltja a Fail2Ban. Mivel ez egy nagyon fontos része az egész beállításnak, ezt egy külön fejezetben tárgyaljuk a beállítások után, addig most hagyjuk üresen.

ISPConfig használata esetén tehát választhatjuk ezt a beállítást is, ezzel mindegyik virtualhostunk védésre kerül. A fenti osztott képernyős képen tehát ez a szűrési módszer a két felső terminálban megjelenített naplófájlt szűri. Természetesen ha több webtárhely van a szerveren, akkor ugyanúgy mindegyikét.

A jail további finomhangolásáról majd a másik variáció után írok, mivel az majd mindkettőre érvényes beállításokat fog tartalmazni.

És most jöjjön a másik beállítási variáció.

IP-címek keresése a sorok belsejében

Ez a beállítás nagyon hasonló az előzőhöz, csupán a következőkben tér el az előzőtől: Az előző variációban virtualhost-onkénti külön Apache naplófájlok helyett itt a /var/log/apache2/ könyvtárban lévő other_vhosts_access.log fájlt fogjuk használni, ami egyébként a Fail2Ban alapértelmezett Apache naplófájlja is egyben. Ez a naplófájl egy összesített naplófájl, ami - szemben a korábbiakkal -, itt egy naplóban gyűjti össze az összes virtualhost apache adatait. A fájl használata különösen kényelmes akkor, amikor például egy terminálon szeretnénk követni a szerveren működő összes weboldalon zajló tevékenységet, valamint a teljes hosztnéven elérhető webalkalmazásokon történő további tevékenységet is. Ez a fájl tehát minden virtualhost adatot magában foglal. Erre példát a fenti, osztott terminálos kép bal alsó termináljában láthatunk, ahol a telefonnal készített tesztek mindegyike megjelenik ugyanabban a fájlban.

De itt most mutatok erről egy frissebb képet is, ahol szintén szűrtem a 404-es hibákra:

Nagyobb képernyőn jobban látszik.

Itt láthatunk az elején ismét "idegen" lekéréseket, amik a már említett HTTP/1.1 -el érkeznek, és látszólag random lekéréseket küldenek, de van köztük például "/favicon.ico" lekérés is, amit fentebb nem véletlenül tettünk a szűrő kivételei közé, mert ezek a lekérések többnyire valamelyik keresőrobothoz köthetők, amik ártalmatlan szándékkal keresik a weboldal ikon fájlját. Újabban például a Google kereső is megjeleníti őket a találati listájában. Így tehát ezeket célszerű a szűrő "ignoreregex" részében beállítani. De a többi idegen lekérés az szemmel láthatóan is minimum kétes szándékkal érkezett.

Valamint az alsó részekben látható "/aaaaaaa" és a "/bbbbbbbbbbbb" lekérések azok itt is én vagyok a mobiltelefonomról és mobilnetről. Itt a HTTP/2 is mutatja, hogy rendes böngészőből történtek ezek a hibás lekérések.

A naplófájl érdekessége viszont éppen ebből adódik, hogy mivel itt több virtualhost adatunk kerül egy fájlba, ezáltal a korábban ismertetett naplófájlok esetén a sorok elején lévő IP-címek helyén ebben a naplófájlban a saját hosztneveink kapnak helyet, ami jelzi hogy éppen melyik virtualhost-on (tárhelyeken vagy az applikációknál) történt az adott lekérés. Itt tehát az első oszlopban megjelenhetnek a szerverünkön lévő tárhelyek domain nevei, valamint megjelenhet a szerver FQDN neve is, ha éppen azon keresztül nyitunk meg például egy phpMyAdmin-t vagy egy webmailt.

Ennek következtében a kliensek IP-címei az előző naplóhoz képest a "második hasábba" kerültek, aminek következtében a szűrőben használt korábbi reguláris kifejezésünk nem találná meg az IP-címeket, hanem folyamatosan a saját hosztneveinket próbálná meg letiltani, mivel azok vannak itt most a sorok elején (a "^<HOST>" résznek köszönhetően).

Itt tehát egy apró módosítást kell végeznünk a szűrőnkön is, és utána a jail logfile beállításán is. Lássuk ezeket!

Szűrőfájl beállítása

Ebben az esetben is hozzuk létre a szűrőfájlunkat a /etc/fail2ban/filter.d/ könyvtárban, amit most is apache-4xx.conf nak nevezek el:

nano /etc/fail2ban/filter.d/apache-4xx.conf

És tegyük bele az alábbi tartalmat.

[Definition]
# IP-címek keresése a sorok belsejében:
failregex = .* <HOST> -.*"(GET|POST|HEAD).*" (400|401|403|404) .*$

# Kivételek:
ignoreregex =.*(robots.txt|favicon.ico)

És mentsük le.

Itt tehát annyi a különbség az első variációhoz képest, hogy a failregex-nél megadott reguláris kifejezés nem a sorok elején keresi az IP-címeket (^<HOST>), hanem a sor elején lehet egy bármilyen egybefüggő rész (.*), amit egy szóközzel elválasztva követ az IP-cím (.* <HOST>). így tehát a sor elején lévő saját hosztneveinket és portszámainkat tartalmazó karakterlánc után fogja keresni a kliensek IP-címeit. Ezen kívül nincs egyéb eltérés a korábbi szűrőfájljoz képest.

Jail beállítása

Ha lementettük a szűrőfájlt, akkor ezután itt is be kell még állítani a jail-t. Ehhez nyissuk meg szerkesztésre ugyancsak a /etc/fail2ban/jail.local fájlt:

nano /etc/fail2ban/jail.local 

Ha nem létezett még eddig ez a fájlt, akkor tegyük bele, ha már létezett és van benne valami, akkor pedig tegyük a végére, ha pedig itt az első variációt is kipróbáltuk, akkor azt felül írva tegyük bele az alábbi tartalmat:

[apache-4xx]
enabled = true
port = http,https,8080,8081
filter = apache-4xx
logpath  = %(apache_access_log)s
findtime = 60
maxretry = 5
banaction = %(known/banaction)s[blocktype=DROP]
bantime = 3600
ignoreip =

Itt majdnem minden ugyanaz, mint az első variáció esetén, egyedül csak a logpath beállítás tér el. Itt tehát nem a /var/log/ispconfig/httpd/*/access.log fájlokat figyeltetjük a jail-unkkal, hanem egy Fail2Ban belső változót adunk meg, ami tartalmazza az alapértelmezett naplófájl(oka)t, ami jelen esetben az alábbi két fájlból áll:

• /var/log/apache2/other_vhosts_access.log
• /var/log/apache2/access.log

Az alábbi képeken pedig ennek a beállításnak a működése látható:

Itt a kis terminálokon sorban haladva a következőket láthatjuk:

• bal felső: Az apache-4xx.conf fájl, ahol én itt csak a kommentekkel váltogatom az aktív beállításaimat, tehát az itt lévő állapot felel meg a most leírt szűrőbeállításnak, ami itt nem a sor elején keresi az IP-címeket.
• jobb felső: A jail.local konfigurációs fájl, ahol szintén kommenttel váltogatok a beállítások között. Itt is az imént leírt "%(apache_access_log)s" logpath az érvényes beállítás.
• bal alsó: A /var/log/apache2/access.log fájl tartalma, csak érdekességképpen, mivel ezt is használja a logpath beállítása. Azonban ez a fájl nem tartalmaz kliens IP-címeket, tehát ez itt nem releváns a jail-unk szempontjából. A formátumát is ha ellenőrizzük, nem zavarja meg a szűrőnk működését, mert figyelmen kívül hagyja a sor elején lévő "127.0.0.1" IP-címeket, mivel ez a szűrőbeállítás éppen a "második hasábban" keresi az IP-címeket. Mivel ebből nem nyerünk ki IP-címeket ezért ez a naplófájl jelen szempontból haszontalan számunkra, de nem is zavarja a szűrőnket, ezért nem foglalkozunk vele tovább.
• Jobb alsó: Itt pedig a Fail2Ban újraindítása látható.

A következő szintén osztott képernyőképen pedig az újraindítást követő működés látható:

Itt pedig a következőket láthatjuk:

• bal felső: A /var/log/ispconfig/httpd/vps.linuxportal.eu/access.log fájl, amit most ezzel a jail beállítással nem figyeltetünk, de ettől még ebben is gyűlnek az adatok. Itt éppen a saját tesztjeim láthatók ismét.
• jobb felső: A mostani beállításunk alapján szintén nem használt /var/log/ispconfig/httpd/linuxportal.eu/access.log fájl, de ettől még ebben is ugyanígy gyűlnek az adatok. Itt is a tesztek, a tárhelyre érkező hibás lekérésekről.
• bal alsó: A /var/log/apache2/other_vhosts_access.log naplófájl, amit most figyeltetünk ebben a beállításban, tehát ebben "zajlik" most a lényeg. Itt tehát láthatók mindkét virtualhost-ra érkező hibás lekérések. Több tárhely esetén természetesen ugyanúgy az összes vonatkozó adat megjelenik.
• jobb alsó: Itt a /var/log/fail2ban.log fájl látható a frissen elindított jail-okkal, ahol láthatjuk a két felhasznált naplófájlt, amit fentebb már felsoroltam ennél a beállításnál, valamint a mobiltelefonos tesztjeim eredménye, amint az 5. kísérlet után letiltja a telefon IP-címét.

Itt tehát látható ennek a beállításnak is a működése.

IP-cím feloldása

Ha a kísérletezgetések, tesztelések során kitiltjuk IP-címünket - ami itt pont a célunk is, hogy teszteljük a működő Fail2Ban szűrőket és jail-okat -, akkor ezt az alábbi paranccsal oldhatjuk fel egyszerűen:

fail2ban-client unban ip <ip-cím>

A parancs bármelyik jail-ban történt tiltást felold, tehát a teszteléseink során ez a leggyorsabb feloldási lehetőség. Itt a képen is látszik egy újraindított állapot után, ahol visszaállította (újra nyilvántartásba vette) a tiltott IP-címemet, amit utána feloldok:

A tiltott Fail2Ban címek feloldásáról már korábban írtam egy részletesebb leírást:

• Hogyan oldjuk fel blokkolt IP címünket, ha kitiltottuk magunkat szerverünk valamelyik szolgáltatásából

Jail finomhangolása

Ahogy fentebb már ígértem, itt ejtünk néhány szót a jail-unk finomhangolásáról. A jail paramétereit itt most nem kívánom elismételni, csak néhány mondatban összefoglalnám, hogy miket érdemes szem előtt tartanunk, amikor még éles használat előtt finomhangoljuk ezeket a paramétereket:

A findtime (időkeret), maxretry (próbálkozások száma) és a bantime (tiltás időtartama) viszonyát célszerű úgy beállítanunk, hogy előtte vizsgáljuk meg szerverünk forgalmát, weboldalaink látogatóinak forgalmát, stb, és ehhez igazítsuk ezeket a beállításokat. Természetesen itt most nem szükséges egy teljesen mélyreható elemzés, főleg ha ismerjük a szerverünkön lévő weboldalak forgalmát, de ha nem ismerjük ezeket, akkor csak egy rövid ideig figyeljük ezt az alábbi paranccsal:

tail -f /var/log/apache2/other_vhosts_access.log | grep " 404 "

És látni fogjuk hogy mennyire kell szigorú beállításokat alkalmaznunk. De ha nem kívánjuk figyelni, bogarászni a naplófájlokat, akkor csak a logika és a józan paraszti ész mentén mérlegeljünk. Néhány szempont:

• Vegyük figyelembe, hogy lesznek látogatók, akik rossz URL címre érkeznek, ami 404-es hibát eredményez. Ilyenkor érkezhetnek akár egy hibásan kapott linkre, vagy akár elgépeli valaki a címsorban az alkönyvtárat (igen, ilyenek is vannak, akik belenyúlnak a címsorba, és átírnak dolgokat).
• Vegyük figyelembe, hogy weboldalainkat a keresőrobotok is indexelik (ők a jó robotok, pl Google, Bing, Yahoo, stb.), és ezek a robotok is elég gyakran érkeznek hibás címekre, amik szintén 404-es hibákat eredményeznek.
  • Például dinamikus weboldalak esetén ha beindexelték a keresők oldalainkat, majd később például törlünk egy már nem szükséges tartalmat, vagy hozzászólást, stb, akkor ezeket még egy ideig "keresni fogják" a robotok is, és a látogatók is.
• Ha valamilyen felhő alapú hálózatot használunk, amik proxy-ként működve kérik le tartalmainkat, akkor az ő IP-címeikről fognak sokan érkezni, tehát ilyenkor akár több felhasználó is érkezhet ugyanarról az IP-címről, ami megnöveli az egy IP-címre jutó lekérések számát, így a 404-es hibák számát is.
  Nálam például az oldal angol nyelvű fordítását egy proxy rendszeren keresztül végzi egy külső rendszer, így az ő IP-címeikről érkeznek nagyon sokan.
• Fehér listázás. Vannak olyan hálózatok, amiket semmilyen körülmények között nem szeretnénk kitiltani. Pl keresők, és egyéb partnerek, stb. Erről kicsit lejjebb részletesebben értekezünk.

Tehát amikor beállítjuk ezeket a paramétereket, akkor ilyesmiket tartsunk szem előtt.

Célszerű elindulni egy lazább beállítással, és időnként ránézni a Fail2Ban jail-unkra, vagy ha van például Munin-unk, akkor ott is nyomon követhetjük a jail alakulását, és ennek függvényében lehet tovább szigorítani.

Erről többet nem is érdemes osztani a szót, tehát a józan ész mentén döntsünk saját szerverünk forgalmához igazítva állítsuk be ezeket a paramétereket. Amit még itt fontos megemlíteni az a fehér listázás. Erről a jail-ok magyarázatánál már ejtettünk szót, de mivel ez egy nagyon fontos rész, ezért ezt egy külön fejezetben fogjuk mindjárt átnézni.

Fehér listázás - avagy akiket sosem szeretnénk kitiltani

Mielőtt még élesítenénk a jail-unkat, egy nagyon fontos részt még át kell néznünk, mégpedig ez a fehér listázás. Ez legalább annyira fontos rész, mint maga a tiltás beállítása. Fontossága miatt ki is emeltem ebbe a külön fejezetbe. Ha ezt nem készítjük el rendesen, akkor már középtávon is nagyobb kárt okozhatunk weboldalainknak a tiltásokkal, mintha nem csináltuk volna semmit. Ezért fontos, hogy pontosan meghatározzuk azokat a csoportokat, akiket vagy amiket semmilyen körülmények között nem szeretnénk kitiltani weboldalainkról. Gyűjtsük össze ezeket:

• Keresőrobotok. Jellemzően az ismertebb keresők robotjai. Ezt mindenki a saját forgalmából kell hogy tudja, hogy melyek azok a robotok, amik a legtöbb forgalmat szállítják weboldalainkra. Nálam például a robotok által közvetített forgalom megoszlása sorrendben (1 éves időkeretet elemezve): 
  Google (91,7%), Yandex (5,1%), DuckDuckGo (1,2%), StartPage (0,6%), Brave (0,6%), Bing, Baidu, Facebook, Qwant
  Itt természetesen - a Google alatti keresőknél - erősen függ a robotok megoszlása a weboldalunk nyelvétől, témájától, stb. A Google általában mindenhol fixen vezeti az ilyen toplistákat, de amik utána jönnek, azok már oldalanként eltérhetnek.
• Közösségi oldalak robotjai. Amennyiben számítunk forgalomra a különböző közösségi oldalakról, akkor ezeknek is be kell szereznünk az IP-címeit, mert gyakran alkalmaznak ezek is saját robotokat, amik ellenőrzik például a megosztott tartalmak forrás URL címein elérhető képeket, meta tag-eket, tehát ezek is gyakran járhatják oldalainkat. Még ha magunk nem is vagyunk nagy közösségi fan-ok, attól még látogatóink oszthatják az általuk kedvelt tartalmainkat a közösségi oldalakon.
• Felhő alapú szolgáltatások, amik proxyként működve továbbítják a forgalmat. Pl CloudFlare, stb. Ezek a szolgáltók általában közzéteszik az IP-címeik listáját. Nálam nincs ilyen, de aki ilyesmit használ, az tájékozódjon a szolgáltatónál.
• Egyéb partnerek, akik proxyként működve továbbítják a forgalmat hozzánk. Nálam például az en.linuxportal.info angol nyelvi fordítását egy ilyen cég végzi, tehát akik az angol nyelvű oldalakra érkeznek, azok az ő szervereikre érkeznek, majd az ő szervereikről történik a lekérés. Így alapból a fordító cég IP-címei jelennek meg az Apache naplókban. Ez a cég biztosítja számomra az ő általuk használt IP-címeket, tehát ezek könnyen fehér listázhatók.
• API alapú szolgáltatások. Ilyen lehet például egy PayPal vagy más fizetési kapu, aminek oda-vissza kell tudnia kommunikálni szerverünkkel, amik jellemzően a HTTP/HTTPS portokon zajlanak. Ezek ha jól be vannak állítva és működnek, akkor nem szoktak 404-es hibákat generálni, de ha bármi hiba becsúszik, és "félrecsúszik" egy lekérés, akkor bizony ezek is tiltásra kerülhetnek. Tehát ha ilyesmiket használunk, ezt is mérlegeljük.
• Saját Fix IP-cím. Ha otthon a saját internetszolgáltatásunk Fix IP-címmel megy (mert kértük a szolgáltatótól, stb), akkor ezt is ajánlott beállítani, nehogy véletlenül kitiltsuk magunkat.
• Egyéb. Minden olyan egyéb eset, ami például nem publikus szolgáltatásokon alapul, hanem például egy másik vállalat ismert IP-címeinek kell lekéréseket intéznie weboldalaink felé. Ezeket a címeket is magunknak kell összegyűjtenünk.

Mindezek így egyszerre soknak tűnhetnek, de felsoroltam őket, mert nem szeretném, ha valaki beállítja magának az itt leírt Fail2Ban tiltást, majd egy rossz beállítás következtében kitiltja a fél internetet a weboldalairól. Így tehát ezeknek ismeretében alkalmazzunk bármilyen tiltó mechanizmust akár innen származót, akár más helyen talált leírás alapján elkészített megoldást.

Fehér lista beállítása

A fehér listát, vagyis a kivételeket a fentebb már bemutatott jail beállítások "ignoreip" paraméterével tudjuk beállítani. Példa:

ignoreip = 192.168.1.1 192.168.2.0/24 10.0.0.1

Itt megadhatunk több IP-címet is, vagy CIDR (Classless Inter-Domain Routing) címtartományokat. Ha egynél több tételt szeretnénk megadni, akkor szóközökkel választhatjuk el őket. Ha nagyon sok tételünk van, és szeretnénk áttekinthetővé tenni a felsorolást, akkor több sorba is törhetjük ezeket. Ezt a "\ " (a \ jel után egy szóköz is kell) karakterekkel tehetjük meg. Példa:

ignoreip = 192.168.1.1 192.168.2.0/24 \
           10.0.0.1

Ennek megfelelően állítsuk be a szükséges IP-címeket.

JSON formátumban tárolt IP-címek feldolgozása

Sok nagy szolgáltató JSON adatstruktúrában teszi közzé a saját IP-címeit, amiken a saját szolgáltatásaikat érheti el a külvilág. Ilyenek például az alábbiak:

• Google robotok: https://developers.google.com/search/apis/ipranges/googlebot.json
• Bing robotok: https://www.bing.com/toolbox/bingbot.json
• Amazon AWS IP-címek: https://ip-ranges.amazonaws.com/ip-ranges.json

Stb. Ha a fejezet elején felsorolt robot csoportok IP-címeire vagyunk kíváncsiak, keressük az adott szolgáltatónál.

Itt most a példa kedvéért megnézzük a Google robotok listáját, és hogy hogyan tudjuk azt úgy automatizáltan feldolgozni, hogy egy szóközökkel elválasztott listát kapjunk.

Ha rákattintunk a robotokat tartalmazó lista linkjére, akkor kapunk egy ilyen tartalmat:

{
    "creationTime": "2023-03-07T23:03:55.000000",
    "prefixes": [
        {
            "ipv6Prefix": "2001:4860:4801:10::/64"
        },
        {
            "ipv6Prefix": "2001:4860:4801:11::/64"
        },
[...]
        {
            "ipv4Prefix": "34.100.182.96/28"
        },
        {
            "ipv4Prefix": "34.101.50.144/28"
        },
        {
            "ipv4Prefix": "34.118.254.0/28"
        },
[...]
        {
            "ipv4Prefix": "66.249.79.32/27"
        },
        {
            "ipv4Prefix": "66.249.79.64/27"
        },
        {
            "ipv4Prefix": "66.249.79.96/27"
        }
    ]
}

Itt most én ebből kivágtam a nagy részét, csak a minta kedvéért hagytam benne pár tételt.

Tehát így néz ki a listánk, ebből szeretnénk egy szóközökkel elválasztott felsorolást készíteni.

Első körben a wget parancs segítségével töltsük le a listát:

wget -q -O- https://developers.google.com/static/search/apis/ipranges/googlebot.json

Ekkor megkapjuk a böngészőben megjelent JSON tartalmat egy az egyben a terminálban. A parancs paraméterei a következők:

• -q: quiet mode. Csendes mód. Nem kapunk program kimenetet, csak magát a letöltött tartalmat.
• -O: (Itt a nagy O betűről van szó) Kimeneti fájlnév, ebbe menti le a letöltött tartalmat. Ha "-" -t adunk meg, akkor a szabványos kimenetre írja a tartalmat.

Itt tehát megvan a teljes JSON kimenetünk, ezt kell átalakítanunk a megfelelő formára.

A JSON adatokat a leghatékonyabban a jq parancs segítségével dolgozhatjuk fel. Alapból nincs fent ez a csomag Debian/Ubuntu rendszereken, ezért telepítenünk kell az alábbi paranccsal:

sudo apt-get install jq

Ha feltelepült, kombinálhatjuk is egy csővezeték segítségével a korábbi paranccsal:

wget -q -O- https://developers.google.com/static/search/apis/ipranges/googlebot.json | jq -r '.prefixes | .[] | .ipv4Prefix'

Itt annyi történik, hogy a korábban kapott JSON objektumot tartalmazó szöveges kimenetet egy csővezetékkel a jq parancs bemenetére irányítjuk, ami már JSON objektumként fogja kezelni a kapott tartalmat, amennyiben az szintaktikailag helyes. Majd ennek adunk még pár opciót:

• -r: Az opcióval, ha a szűrő eredménye egy karakterlánc, akkor közvetlenül a szabványos kimenetre lesz írva, nem pedig idézőjelekkel ellátott JSON-karakterláncként. Ez hasznos lehet a jq-szűrők nem JSON-alapú rendszerekkel való kommunikációjához. Leegyszerűsítve: leszedi az idézőjeleket.
• '.prefixes | .[] | .ipv4Prefix' : Szűrő parancs. Konkrétan ennél a JSON adatstruktúránál ez kiszűri csak a ".prefixes"  mezőket, majd azon belül a tömb felsorolásokat, és azon belül az ".ipv4Prefix" mezőket. Tehát ez a szűrőparancs kimondottan ehhez a struktúrához jó.

A parancs kimenete az alábbi:

[...]
null
null
null
null
null
34.100.182.96/28
34.101.50.144/28
34.118.254.0/28
34.118.66.0/28
34.126.178.96/28
[...]
66.249.79.128/27
66.249.79.160/27
66.249.79.192/27
[...]

Itt is levágtam az elejét és a végét (a legvégén már megjelennek a Google jól ismert 66.249 kezdetű IP-címei is). Itt a lényeg annyi, hogy a parancs hatására kapunk egy listát, amiben a tételek új sorban vannak egyesével. A null értékeket azért kapjuk, mert a szűrőparancsunk utolsó eleme a ".ipv4Prefix" csak az IPv4-es mezőket adja vissza, és minden egyéb esetén, amire nem alkalmazható ez a mezőnév, így például az "ipv6Prefix" mezők esetén null értékeket fog adni. A következő lépésben ezeket a null értékeket kell eltávolítanunk.

A null értékeket többféle módon is levághatjuk:

Ha nem akarunk annyira kifinomultak lenni, viszont hatékonyak és lényegre törők, akkor alkalmazhatjuk a shell más hatékony eszközeit is, így például a grep parancs -v kapcsolójával is kiszűrhetjük:

wget -q -O- https://developers.google.com/static/search/apis/ipranges/googlebot.json | jq -r '.prefixes | .[] | .ipv4Prefix' | grep -v "null"

Ennek hatására megkapjuk a fenti eredményt, annyi különbséggel, hogy a "null" sorokat kiszedi nekünk a grep. Ebben az esetben a "null" értékeket string-ként kezeljük.

De ha elegánsak szeretnénk lenni, akkor a null értékeket kiszűrhetjük a jq parancs saját eszközeivel is:

wget -q -O- https://developers.google.com/static/search/apis/ipranges/googlebot.json | jq -r '.prefixes[] | .ipv4Prefix as $ip | if $ip != null then $ip else empty end'

Persze ez a kivitelezés bonyolultabb, viszont elegánsan a jq parancs saját if-then-else szerkezetével oldjuk meg. Itt pedig ügyelni kell rá, hogy a null érték ilyenkor nem karakterláncként kerül értelmezésre, így nem szabad idézőjelek közé tenni.

Itt tulajdonképpen bármelyik verziót használhatjuk, a végeredmény ugyanaz: lekerülnek a null értékek, és csak az IPv4 címek és CIDR tartományok maradnak.

A parancs rövidebb mivolta miatt én itt most az első, grep -v módszerrel megyek tovább, hogy ne legyen annyira hosszú a parancsunk.

Ha idáig megvagyunk, akkor már csak ezt a listát kell egy szóközökkel elválasztott sorrá alakítanunk. Erre a feladatra pedig a paste parancs a legjobb választás. Egészítsük tehát ki az előző parancsunkat, én itt a grep-es változatot használom:

wget -q -O- https://developers.google.com/static/search/apis/ipranges/googlebot.json | jq -r '.prefixes | .[] | .ipv4Prefix' | grep -v "null" | paste -s -d " " -

Itt pedig a következő történik, nézzük meg a paste parancs kapcsolóit:

• -s: serial: Egy fájlból / bemenetből veszi az adatokat, nem pedig több fájlból.
• -d: határoló karakter, ami jelen esetben egy szóköz " ". Mert hogy szóközökkel elválasztott tételekre van szükségünk
• -: Egy linux egyezmény alapján (amit nem minden program követ) a fájlnév helyén lévő egyedülálló kötőjel a szabványos bemenetre (stdin) vagy a szabványos kimenetre (stdout) utal, a kontextusnak megfelelően. Mivel jelen esetben ez a kimeneti fájlnév helye, ezért az stdout-ra vonatkozik. Ezzel tehát arra utasítjuk a paste parancsot, hogy az összefűzött tartalmat irányítsa át a szabványos kimenetre, azaz jelenjen meg a terminálban.
  Erről már ejtettünk szót egy másik leírásban.

Ennek a parancsnak a kimenete nálam:

Itt tehát kapunk egy szép egy soros felsorolást, amit itt most csak a terminál ablak tördel több sorba. 

Másoljuk ki ezt a listát, és a fejezet elején leírt módon tegyük be az "ignoreip" sorába:

ignoreip = 34.100.182.96/28 34.101.50.144/28 34.118.254.0/28 34.118.66.0/28 34.126.178.96/28 34.146.150.144/28 34.147.110.144/28 34.151.74.144/28 34.152.50.64/28 34.154.114.144/28 34.155.98.32/28 34.165.18.176/28 34.175.160.64/28 34.176.130.16/28 34.22.85.0/27 34.64.82.64/28 34.65.242.112/28 34.80.50.80/28 34.88.194.0/28 34.89.10.80/28 34.89.198.80/28 34.96.162.48/28 35.247.243.240/28 66.249.64.0/27 66.249.64.128/27 66.249.64.160/27 66.249.64.192/27 66.249.64.224/27 66.249.64.32/27 66.249.64.64/27 66.249.64.96/27 66.249.65.0/27 66.249.65.128/27 66.249.65.160/27 66.249.65.192/27 66.249.65.224/27 66.249.65.32/27 66.249.65.64/27 66.249.65.96/27 66.249.66.0/27 66.249.66.128/27 66.249.66.192/27 66.249.66.32/27 66.249.66.64/27 66.249.68.0/27 66.249.68.32/27 66.249.68.64/27 66.249.69.0/27 66.249.69.128/27 66.249.69.160/27 66.249.69.192/27 66.249.69.224/27 66.249.69.32/27 66.249.69.64/27 66.249.69.96/27 66.249.70.0/27 66.249.70.128/27 66.249.70.160/27 66.249.70.192/27 66.249.70.224/27 66.249.70.32/27 66.249.70.64/27 66.249.70.96/27 66.249.71.0/27 66.249.71.128/27 66.249.71.160/27 66.249.71.192/27 66.249.71.32/27 66.249.71.64/27 66.249.71.96/27 66.249.72.0/27 66.249.72.128/27 66.249.72.160/27 66.249.72.192/27 66.249.72.224/27 66.249.72.32/27 66.249.72.64/27 66.249.72.96/27 66.249.73.0/27 66.249.73.128/27 66.249.73.160/27 66.249.73.192/27 66.249.73.224/27 66.249.73.32/27 66.249.73.64/27 66.249.73.96/27 66.249.74.0/27 66.249.74.128/27 66.249.74.32/27 66.249.74.64/27 66.249.74.96/27 66.249.75.0/27 66.249.75.128/27 66.249.75.160/27 66.249.75.192/27 66.249.75.224/27 66.249.75.32/27 66.249.75.64/27 66.249.75.96/27 66.249.76.0/27 66.249.76.128/27 66.249.76.160/27 66.249.76.192/27 66.249.76.224/27 66.249.76.32/27 66.249.76.64/27 66.249.76.96/27 66.249.77.0/27 66.249.77.128/27 66.249.77.32/27 66.249.77.64/27 66.249.77.96/27 66.249.79.0/27 66.249.79.128/27 66.249.79.160/27 66.249.79.192/27 66.249.79.224/27 66.249.79.32/27 66.249.79.64/27 66.249.79.96/27

Ha pedig vannak még más IP-cím csoportjaink is, amiket nem szeretnénk kitiltani, azokat vagy fűzzük utána, vagy a fentebb már mutatott módon a "\ " sortöréssel tegyük új sorba.

Ugyanilyen módon a fent linkelt IP-cím forrásokat is átalakíthatjuk és beállíthatjuk, amennyiben szükségünk van rájuk.

Az Amazon AWS JSON tömb nem az "ipv4Prefix" mezőt használja, hanem az IPv4 címek esetén az "ip_prefix" mezőt. ennek megfelelően tehát az Amazon JSON tömbje esetén az alábbi feldolgozó parancsot használhatjuk:

wget -q -O- https://ip-ranges.amazonaws.com/ip-ranges.json | jq -r '.prefixes | .[] | .ip_prefix' | grep -v "null" | paste -s -d " " -

Itt nem rakok be kimenetet, mert iszonyat sok IP-cím van benne.

Ezzel készen is állunk a beállításokkal. Ha minden megvan, akkor indítsuk újra a Fail2Ban szolgáltatását:

systemctl restart fail2ban

Természetesen közben nézzünk rá a /var/log/fail2ban.log fájlban is az eredményre, hogy biztosan minden jail elindult, újra felvette a korábban már tiltott IP-címeket (Restore Ban xxx.xxx.xxx.xxx), stb.

Haladó

Az alábbiakban kétféleképpen állíthatjuk be a Fail2Ban rendszert.

IP-címek keresése a sorok elején

Ha olyan Apache konfigurációs fájlokat használunk, amelyekben a napló sorok a kliensek IP-címeivel kezdődnek, akkor az alábbi beállításokat alkalmazzuk:

Szűrőfájl beállítása:

nano /etc/fail2ban/filter.d/apache-4xx.conf

És tegyük bele az alábbi tartalmat.

[Definition]
# IP-címek keresése a sorok elején:
failregex = ^<HOST> -.*"(GET|POST|HEAD).*" (400|401|403|404) .*$

# Kivételek:
ignoreregex =.*(robots.txt|favicon.ico)

Mentsük le.

Jail beállítása:

nano /etc/fail2ban/jail.local

Tegyük bele / fűzzük a végére az alábbi tartalmat:

[apache-4xx]
enabled = true
port = http,https,8080,8081
filter = apache-4xx
logpath  = /var/log/ispconfig/httpd/*/access.log
findtime = 60
maxretry = 10
banaction = %(known/banaction)s[blocktype=DROP]
bantime = 3600
ignoreip =

IP-címek keresése a sorok belsejében

Ha olyan Apache konfigurációs fájlokat használunk, amelyekben a napló sorok nem a kliensek IP-címeivel kezdődnek, hanem azok a sorok belsejében találhatók, akkor az alábbi beállításokat alkalmazzuk:

Szűrőfájl beállítása:

nano /etc/fail2ban/filter.d/apache-4xx.conf

Tegyük bele az alábbi tartalmat:

[Definition]
# IP-címek keresése a sorok belsejében:
failregex = .* <HOST> -.*"(GET|POST|HEAD).*" (400|401|403|404) .*$

# Kivételek:
ignoreregex =.*(robots.txt|favicon.ico)

Mentsük le.

Jail beállítása:

nano /etc/fail2ban/jail.local

Tegyük bele / füzzük a végéhez az alábbi tartalmat:

[apache-4xx]
enabled = true
port = http,https,8080,8081
filter = apache-4xx
logpath  = %(apache_access_log)s
findtime = 60
maxretry = 10
banaction = %(known/banaction)s[blocktype=DROP]
bantime = 3600
ignoreip =

Mentsük le.

Ezután bármelyik beállítást is használjuk, állítsuk be a jail-okban az ignoreip paramétert, tegyük bele azokat az IP-címeket, amiket ki szeretnénk zárni ebből az ellenőrzésből, tehát nem akarjuk, hogy kitiltsa őket a rendszer, akárhány találatot is okoznak.

Itt a maxretry értékét szándékosan 10-re emeltem a részletes leírásban lévőhöz képest, hogy itt az elméleti részek hiányában kisebb eséllyel idézzünk elő nem kívánt kitiltásokat. Természetesen finomhangoljuk ezeket a beállításokat a saját igényeinknek megfelelően.

Ha mindent beállítottunk, akkor indítsuk újra a Fail2Ban-t:

systemctl restart fail2ban

Konklúzió

Ezekkel a beállításokkal letilthatjuk a nagy mennyiségben érkező 4xx HTTP válaszkódokat előidéző lekéréseket. A leírás terjedelmére való tekintettel készítettem egy haladó részt is, ahol tömören leírtam a beállításokat. Így mindenki használja a számára megfelelő részét a leírásnak.

A Jail megfelelő finomhangolására azonban mindenképpen fordítsunk kellő figyelmet, mert egy rosszul beállított jail esetén sok olyan látogatást is kitilthatunk, amiket eredetileg nem szándékoztunk távol tartani weboldalainktól.