Tartalom

Bevezető

Ahogy szerverünkön egyre több weboldalt üzemeltetünk, úgy a járulékos forgalom is megnövekszik, ami többlet terheléshez vezet. Ezt a felesleges terhelést túlnyomó részt a robotok által generált forgalom okozza. Minél több aloldalból áll egy weboldal, a robotok automatikusan annál több URL címet járnak be, amivel egyre nagyobb mértékben dolgoztatják meg a HTTP webkiszolgálót és a PHP-t is, ami az ezeket működtető hardverek felesleges használatát jelenti. Nem beszélve a felhasznált sávszélességről, amit a lekért weboldalak okoznak. Ezek közül a robotok közül természetesen nem mind felesleges, de a legtöbbjük csak haszontalanul mozgatják feleslegesen a szervert. Ebben a leírásban kétféle módszer segítségével nézzük meg, hogyan tarthatjuk távol weboldalainktól ezeket a szükségtelen robotokat.

Robotok felismerése és megkülönböztetése

Ahogyan már volt róla szó, nem minden robot felesleges, de túlnyomó részük az. A "robot etikett" előírja, hogy az oldalak bejárása során a weboldal gyökérkönyvtárában lévő robots.txt fájlban leírtakat a robotoknak be kell tartaniuk. Azaz, ha a fájlban le van tiltva egy bizonyos robot, vagy le van korlátozva annak látogatási sebessége, akkor azt be kellene tartania. Azonban ezt a legtöbb robot figyelmen kívül hagyja, és járja az oldalainkat, ha szeretnénk, ha nem.

A nagy keresőóriások robotjai, mint például a Google, a Microsoft Bing keresőrobotjai vagy akár a Yahoo robotjai, stb. figyelembe veszik a robots.txt fájlban meghatározottakat, és annak megfelelően hajtják végre, vagy éppen nem hajtják végre a feltérképezést. Valamint ezek a robotok nagyon is hasznosak, mert oldalainkat beindexelik a keresőikbe. Így tehát ezeknek a nagy keresőknek a robotjait mindenképpen be kell engednünk, ha jót akarunk magunknak. De mi a helyzet a másik táborral, akik nem foglalkoznak a mi óhajainkkal?

Apache naplófájl megtekintése

Ezeknek a felismeréséhez a legegyszerűbb, ha benézünk például az Apache vagy Nginx megfelelő naplófájljába. Ebben a leírásban az Apache-al foglalkozunk, így meg is nyithatjuk az access.log fájlját. Ez a fájl egy LAMP rendszeren ahol alap Apache telepítés van a /var/log/apache2/access.log. Nézzünk bele az utolsó néhány sorába:

cat /var/log/apache2/access.log | tail -5

Nálam a legutóbb feltelepített Debian 10 (Buster) LAMP szerverben már rég volt tevékenység, így a Logrotate naplófájl-forgató rendszernek köszönhetően már az access.log.1 fájlban találtam naplóbejegyzést:

Itt például ha kiemelünk egy sort, például egy a phpMyAdminból lekért png fájl sorát, az így néz ki:

192.168.1.100 - - [19/Nov/2019:15:02:58 +0100] "GET /phpmyadmin/themes/pmahomme/img/s_unlink.png HTTP/1.1" 200 873 "http://192.168.1.130/phpmyadmin/phpmyadmin.css.php?nocache=6286344183ltr&server=1" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36"

Tartalmazza a kliens IP-címét, az esemény dátumát és idejét, magát a lekérést, annak az előzményét (referer), és végül pedig a böngészőazonosítót. Itt most ez a legutóbbi adat fontos számunkra, mert ez alapján tudjuk beazonosítani, hogy kiféle, miféle az illető, aki lekért egy fájlt a szerverről.

A robotok többsége szerencsére elküldi a saját böngészőazonosítóját, így ez alapján fel tudjuk ismerni, és ki tudjuk tessékelni a weboldal(ak)ról.

Például egy GoogleBot jellemző sora (amit természetesen soha ne tiltsunk ki!) így néz ki itt a szerveren:

66.249.64.172 - - [26/Nov/2019:18:23:08 +0100] "GET /leirasok/web-hoszting/biztonsag/hogyan-kezeljuk-http-hitelesito-jelszavainkat-a-htpasswd-fajlban-a-htpasswd-parancs-segitsegevel HTTP/1.1" 200 25879 "-" "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)"

Itt épp nemrég kérte le az egyik korábbi leírást az oldalról. Ennek a sornak a végén tehát ott van a robot böngészőazonosítója.

Ez alapján ha rendszeresen figyeljük az Apache naplófájlját, akkor össze tudjuk gyűjteni a robotok neveit.

Feketelista összeállítása

A következő lépésben össze kell állítanunk egy "feketelistát", amiben azok a robotok szerepelnek, amiket nem szeretnénk beengedni az oldalainkra. Itt most összeszedtem párat, amit felsorolok:

• SemrushBot
• AhrefsBot
• Mb2345Browser
• MegaIndex.ru
• MJ12bot
• DotBot
• Baiduspider
• YandexBot
• LieBaoFast
• zh_CN
• zh-CN
• SeznamBot
• trendictionbot
• magpie-crawler

Ezek nem teljes böngészőazonosítók, hanem azoknak olyan egyedi részei, amivel egyértelműen be lehet azonosítani a felsorolt robotot. Persze van még sokkal több is, de azok nem járnak olyan sűrűn, hogy most ki tudtam volna gyűjteni őket a mai/tegnapi naplófájljaimból.

Ezeket a neveket kell "|" karakterekkel összefűzve (és a szükséges karaktereket escape-elve) beilleszteni a megfelelő helyekre, ahol a tiltást el szeretnénk végezni. Erről majd később, most egyelőre csak összeállítjuk a szűrő sort.

Az összefűzött sorunk tehát így néz ki:

SemrushBot|AhrefsBot|Mb2345Browser|MegaIndex\.ru|MJ12bot|DotBot|Baiduspider|YandexBot|LieBaoFast|zh_CN|zh-CN|SeznamBot|trendictionbot|magpie-crawler

Sajnos ezt nem tördelhetem több sorba, egyben kell lennie.

A pontokat tartalmazó tételeknél kell figyelni, hogy a benne lévő pont előtt legyen egy escape karakter (\). Itt egyedül a MegaIndex.ru tartalmaz pontot. Valamint ügyelni kell a kis-és nagybetűkre, tehát ahogy a naplófájlban bukkannak elő, ugyanúgy kell itt is lenniük.

Nálam a szerveren ezek a robotok randalíroztak folyamatosan, amikkel ezelőtt nem foglalkoztam, mert jelentéktelen forgalmat generáltak, de az utóbbi időben elkanászodtak és eléggé megdobták a szerver CPU kihasználtságát. Így hát tegnap kitettem őket.

Sok helyen foglalkoznak a böngészőazonosítókkal, például innen is csemegézhetünk még robotokat.

Robotok tiltása a Fail2Ban védelmi rendszer segítségével

A Fail2ban egy erős és igen hatékony védelmi rendszere az Unix-szerű operációs rendszereknek. Segítségével könnyedén fel lehet venni a harcot a nem kívánatos látogatókkal. A program a különböző naplófájlokat elemezve dinamikusan kezeli a megfelelő tűzfal szabályokat a benne beállított szűrőszabályok alapján, így globálisan állíthatunk be az egész szerverre kiterjedő védelmet. A Fail2Ban segítségével minden szerverszolgáltatást bebiztosíthatunk, azonban itt most csak az Apache webkiszolgálóra koncentrálunk.

Telepítés

Ha még nem lenne a szerverünkön a Fail2Ban, akkor telepítsük a következő paranccsal (Debian alapú szervereken):

apt-get -y install fail2ban

A telepítés után a program alapbeállításai megfelelők, így most ezekkel nem foglalkozunk.

Akár el is indíthatjuk ezekkel az alapbeállításokkal:

systemctl start fail2ban

Saját szűrő létrehozása

Következő lépésként létrehozzuk a saját szűrőnket. Ehhez root-ként lépjünk be a /etc/fail2ban/filter.d könyvtárba:

/etc/fail2ban/filter.d

Ez a könyvtár tartalmazza a program előre beépített szűrőit, amit tetszés szerint ki/be kapcsolgathatunk a későbbiek során. Most hozzunk létre egy új szűrőfájlt ebben a könyvtárban:

nano apache-mycustombots.conf

És tegyük bele az alábbi részt, ami már tartalmazza a fent összeállított szűrő sorunkat is:

# Saját robot szűrő
[Definition]

mycustombots = SemrushBot|AhrefsBot|Mb2345Browser|MegaIndex\.ru|MJ12bot|DotBot|Baiduspider|YandexBot|LieBaoFast|zh_CN|zh-CN|SeznamBot|trendictionbot|magpie-crawler

failregex  = ^<HOST> .*(GET|POST|HEAD).*(%(mycustombots)s).*$

ignoreregex =

datepattern = ^[^\[]*\[({DATE})
              {^LN-BEG}

Saját szűrő tesztelése

A szűrő bekapcsolása előtt hajtsunk végre egy száraz tesztet az Apache naplófájlunkkal és a szűrővel, hogy működik-e, és hogy hány egyezést talál a naplóban. Ehhez futtassuk a fail2ban-regex parancsot:

fail2ban-regex  <apache access.log naplófájl elérése> /etc/fail2ban/filter.d/apache-mycustombots.conf

Nálam az egyik weboldalon ilyen kimenetet ad ez a szűrő:

Running tests
=============

Use   failregex filter file : apache-mycustombots, basedir: /etc/fail2ban
Use      datepattern : Default Detectors
Use         log file : /var/www/xxxx.hu/log/access.log
Use         encoding : UTF-8


Results
=======

Failregex: 17836 total
|-  #) [# of hits] regular expression
|   1) [17836] ^<HOST> .*(GET|POST|HEAD).*(SemrushBot|AhrefsBot|Mb2345Browser|MegaIndex\.ru|MJ12bot|DotBot|Baiduspider|YandexBot|LieBaoFast|zh_CN|zh-CN|SeznamBot|trendictionbot|magpie-crawler).*$
`-

Ignoreregex: 0 total

Date template hits:
|- [# of hits] date format
|  [19797] ^[^\[]*\[(Day(?P<_sep>[-/])MON(?P=_sep)ExYear[ :]?24hour:Minute:Second(?:\.Microseconds)?(?: Zone offset)?)
`-

Lines: 19797 lines, 0 ignored, 17836 matched, 1961 missed
[processed in 3.48 sec]

Missed line(s): too many to print.  Use --print-all-missed to print all 1961 lines

Zölddel emeltem ki a lényeges sort: itt most talált 17836 robot egyezést a weboldal mai Apache naplójában. Ez természetesen nem ennyi oldalletöltést jelent, hanem itt minden egyes kis erőforrás lekérése külön sorként szerepel a naplóban, mint ahogy fentebb is láthattuk a phpMyAdmin-ból lekért .png fájl esetében. Minden esetre így a nap felénél járva ez sem kevés, pláne, ha azt is figyelembe vesszük, hogy alul a "Missed lines" sorban csak 1961 találat szerepel, ami a nem robot forgalmat jelenti. Tehát ezen az oldalon arányaiban körülbelül 10x annyi robot jár, mint valódi látogató. Ez így elég pazarlás, ezért kapcsoljuk is be a szűrőt.

Szűrő bekapcsolása

A szűrő bekapcsolásához nyissuk meg a /etc/fail2ban/jail.local fájlt:

nano /etc/fail2ban/jail.local

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

[apache-mycustombots]
enabled   = true
port      = http,https
filter    = apache-mycustombots
logpath   = /var/log/ispconfig/httpd/*/access.log
findtime  = 3600
maxretry  = 1
bantime   = 86400

Egy korábbi leírásban ezeknek a jelentéséről már esett szó, de most itt is átnézzük őket:

• enabled: Itt kapcsolhatjuk be a szűrőt.
• port: Ezekre az előre definiált portokra alkalmazza a Fail2Ban a tiltást.
• filter: Itt kell megadnunk a korábban létrehozott szűrőfájlunk nevét (a kiterjesztése nélkül).
• logpath: Itt kell megadni a vizsgálni kívánt naplófájl nevét. Jelen esetben az Apache access.log fájljának elérését.
  LAMP szerverek esetén a leírás elején említett útvonalat adjuk meg, egyedi beállításoknál pedig a beállított access.log fájl útvonalát.
  Itt pedig én egy ISPConfigos szerverkörnyezetre mutatok példát, ahol a "*" joker karakter használatával adhatjuk meg egyszerre az összes weboldal apache naplófájlját. Természetesen itt meg lehet adni akár egy bizonyos weboldal naplófájlját is, amennyiben erre van szükség. De így levédhetjük a szerveren lévő összes weboldalt is, beleértve az ez után létrehozott webhelyeket is.
• findtime: Ez az az időablak (mp-ben megadva), amiben figyeli a találatokat. Tehát ha 3600-ra állítjuk, akkor a naplófájl elmúlt 1 órájának tartalmát vizsgálja csak.
• maxretry: Alapesetben ezt például a különböző szerverszolgáltatásokban bekövetkezett hibák, vagy elvétett jelszavak által generált naplóesemények ismétlődésének korlátozására találták ki, itt pedig az adott robot  előfordulásának korlátozását jelenti.
  Tehát itt is állítsunk be egy olyan értéket, ahányszor engedni szeretnénk, hogy felbukkanhasson a robot egy adott IP-címről. A következő előfordulásnál már jön a tiltás. Tehát egyszer mindenképpen be kell kerülnie a naplóba, mielőtt a Fail2Ban tiltaná.
• bantime: Ez pedig a tiltás ideje. Én itt egy kerek napot állítottam be.

Az utolsó 3 paraméterrel kísérletezgethetünk, hogy elérjük a számunkra megfelelő hatást, attól függően, hogy milyen forgalmak vannak a weboldalainkon, stb.

Ha ezt elmentettük, akkor indítsuk újra a fail2ban szolgáltatást:

systemctl restart fail2ban

Innentől a rendszer szépen blokkolja a nem kívánatos robotok IP-címeit.

Ellenőrzés

Egy új szűrő bekapcsolása után mindig célszerű ellenőrizni a fail2ban szolgáltatásunkat:

systemctl status fail2ban

A szokásos kimenet normál működés esetén:

● fail2ban.service - Fail2Ban Service
   Loaded: loaded (/lib/systemd/system/fail2ban.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2019-11-27 12:34:55 CET; 2h 21min ago
     Docs: man:fail2ban(1)
  Process: xxx ExecStartPre=/bin/mkdir -p /var/run/fail2ban (code=exited, status=0/SUCCESS)
 Main PID: xxx (fail2ban-server)
    Tasks: 21 (limit: 4915)
   Memory: 85.4M
   CGroup: /system.slice/fail2ban.service
           └─xxx /usr/bin/python3 /usr/bin/fail2ban-server -xf start

nov 27 12:34:55 szerver systemd[1]: Starting Fail2Ban Service...
nov 27 12:34:55 szerver systemd[1]: Started Fail2Ban Service.
nov 27 12:34:57 szerver fail2ban-server[27518]: Server ready

Továbbá külön ellenőrizhetjük is az új jail-unkat a fail2ban-client paranccsal:

fail2ban-client status apache-mycustombots

A kimenet, szintén nálam a szerveren pedig:

Status for the jail: apache-mycustombots
|- Filter
|  |- Currently failed:	0
|  |- Total failed:	1214
|  `- File list:	/var/log/ispconfig/httpd/xxx/access.log /var/log/ispconfig/httpd/yyy/access.log /var/log/ispconfig/httpd/zzz/access.log ...
`- Actions
   |- Currently banned:	15505
   |- Total banned:	16690
   `- Banned IP list:	1.180.164.122 1.180.164.125 1.180.164.128 ...

Itt pedig látszik, hogy éppen hány új IP-cím van "megfigyelés alatt", amik még nem kerültek tiltásra (1214), ezeknél ha mégegy Apache lekérés történik, akkor tiltásra kerülnek. Valamint hogy éppen 15505 IP-cím van tiltva jelenleg, alatta pedig összesen. Ezek ugye már 24 óránál régebbiek, amik már feloldásra kerülnek.

Előnyök/hátrányok

Előnyök:

• Globális beállítást tesz lehetővé, így nem kell külön weboldalanként állítgatni.
• A tiltás még a tűzfalban történik, így a bejövő kérés már nem jut el az Apache-ig.
• A tiltási művelet beállításától függően a tűzfal egyszerűen el is dobhatja a kapcsolatot, anélkül, hogy válaszolna rá. Ezáltal a próbálkozók vagy robotok azt gondolhatják hogy nem is él a szerver, így idővel arrébb állnak...
• A tiltás alatt lévő IP-címek a tiltás ideje alatt nem jutnak el az Apache-ig, így további naplóbejegyzésekkel sem növelik a naplófájl méretét, aminek köszönhetően a Fail2Ban terhelése csökken.

Hátrányok:

• Sok ezer, sok 10 ezer IP-cím esetén a tűzfalban létrehozott (nem a Fail2Ban-ban) szűrőszabályok folyamatos alkalmazása megterhelheti a CPU-t.
• Beállítása bonyolultabb, és root hozzáférést igényel, így az egyéni webmesterek nem végezgetik el.

Robotok tiltása az Apache .htaccess fájlok segítségével

Az Apache .htaccess fájljait gondolom mindenki ismeri, így ezeket nem kell bemutatni. Itt a beállítás végtelenül egyszerű, csak nyissuk meg vagy hozzuk létre a védeni kívánt weboldal gyökérkönyvtárában a .htaccess fájlt, és tegyük bele a következő részt, ami szintén tartalmazza a korábbi robot szűrő sorunkat:

RewriteEngine on

# Felesleges robotok tiltása.
RewriteCond %{HTTP_USER_AGENT} ^.*(SemrushBot|AhrefsBot|Mb2345Browser|MegaIndex\.ru|MJ12bot|DotBot|Baiduspider|YandexBot|LieBaoFast|zh_CN|zh-CN|SeznamBot|trendictionbot|magpie-crawler).*$ [NC]
RewriteRule .* - [F,L]

Majd mentsük le, és már működik is a szűrő. Itt annyi a lényeg, hogy ha a .htaccess már tartalmazza valahol a RewriteEngine on részt, akkor az alá tegyük be ezeket a sorokat.

Ilyenkor az Apache "hárítja el" forbidden (403-as HTTP válaszkód) jelzéssel a kérést a weboldaltól, de előfordulhat 500-as hiba is.

Keressünk rá a naplófájlban is a tiltásra került bejegyzésekre, amelyeket a 403-as vagy az 500-as hibakóddal tűntet fel a rendszer. Az ilyen lekéréseket az alábbi grep vagy egrep parancsokkal szűrhetjük ki a naplófájlban (amelyik szimpatikusabb):

cat access.log | grep " 403 \| 500 "
cat access.log | grep -E " 403 | 500 "
cat access.log | egrep " 403 | 500 "

Ha az itt kapott kimenetben csak 403-as kódokat találunk a tiltott robotjaink esetében, akkor rendben is vagyunk. Néhány példa:

114.119.146.18 - - [21/Sep/2022:23:38:13 +0200] "GET /enciklopedia/g HTTP/1.1" 403 6774 "https://www.linuxportal.info/index.php/enciklopedia/m/matomo-piwik-webanalitika?amp" "Mozilla/5.0 (Linux; Android 7.0;) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 (compatible; PetalBot;+https://webmaster.petalsearch.com/site/petalbot)"
54.38.96.32 - - [21/Sep/2022:23:50:12 +0200] "GET /robots.txt HTTP/1.1" 403 6767 "-" "Mozilla/5.0 (compatible; DotBot/1.2; +https://opensiteexplorer.org/dotbot; help@moz.com)"
216.244.66.248 - - [21/Sep/2022:23:50:13 +0200] "GET /robots.txt HTTP/1.1" 403 6728 "-" "Mozilla/5.0 (compatible; DotBot/1.2; +https://opensiteexplorer.org/dotbot; help@moz.com)"
5.196.175.154 - - [21/Sep/2022:23:56:11 +0200] "GET /taxonomia/samba HTTP/1.1" 403 6774 "https://en.linuxportal.info/tutorials/filesystem/how-to-share-directories-on-linux-and-windows-systems-page-2" "Mozilla/5.0 (Linux; Android 7.0;) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 (compatible; PetalBot;+https://webmaster.petalsearch.com/site/petalbot)"

Ha viszont 500-as hibakódokat látunk a robotoknál, például:

216.244.66.248 - - [20/Sep/2022:01:26:03 +0200] "GET /robots.txt HTTP/1.1" 500 5117 "-" "Mozilla/5.0 (compatible; DotBot/1.2; +https://opensiteexplorer.org/dotbot; help@moz.com)"
87.250.224.29 - - [20/Sep/2022:04:30:59 +0200] "GET /robots.txt HTTP/1.1" 500 5163 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)"
116.179.37.84 - - [20/Sep/2022:16:39:50 +0200] "GET /sites/default/files/theme/linux-logo_kicsi.png HTTP/1.1" 500 5674 "https://en.linuxportal.info/" "Mozilla/5.0 (compatible; Baiduspider-render/2.0; +http://www.baidu.com/search/spider.html)"

Akkor még van egy apró szépséghiba, ami ugyan nem jelent problémát, de ha precízek szeretnénk lenni, akkor az alábbi leírásban tájékozódhatunk ennek a javításáról:

• Hogyan javítsuk az "AH00124: Request exceeded the limit of 10 internal redirects due to probable configuration error." típusú Apache hibákat?

Előnyök/hátrányok

Előnyök:

• Itt nem jön létre új tűzfal szabály minden IP-cím számára, így nagyobb mennyiségű IP-cím esetén nem terheli meg a tűzfalat.
• Beállítása egyszerű, és nem igényel root hozzáférést, így az egyéni webmesterek is elvégezhetik weboldalaikon.

Hátrányok:

• Itt nincs lehetőség globális beállításra, hanem weboldalanként külön kell elvégezni. Ha globálisan szeretnénk beállítani, akkor ezt az Apache konfigurációjában tehetjük csak meg root hozzáféréssel.
• A tiltást az Apache hajtja végre, így a terhelést is ez kapja. Valamint az Apache process-ek is lefoglalásra kerülnek, még ha rövid időre is.
• Mivel az Apache visszaad egy "Forbidden" választ, ezért a támadóknak/robotoknak tudomásuk lesz a szerver üzemeléséről, így kitartóbban próbálkozhatnak.

Elemzések

A fenti két módszert alkalmazva tegnap óta hasznos eredményekhez jutottam, így most megosztom őket.

Nálam a szerveren fel van telepítve a Munin szerver erőforrásokat mérő statisztika, melynek telepítéséről majd egy másik leírásban lesz szó, most csak annyit, hogy ezeknek a grafikonjait használom most itt fel.

Tegnap a Fail2Ban elindítása után rögtön elkezdett emelkedni a blokkolt IP-címek száma:

Itt látható, hogy az apache-mycustombots szűrőnkben lévő címek ugrásnak indultak. Kicsivel később a CPU grafikon pedig:

Itt volt egy nagy CPU emelkedés reggel 6 és 12 óra között. Ez után ugyan lecsillapodott a robot forgalom, de utána állítottam be a szűrőt.

Majd ez után kis idővel betettem a .htaccess fájlokba is a szűrőket, így a kettőnek az együttes hatása volt érezhető. A mai Fail2Ban grafikon elég érdekesen néz ki:

Itt annyi történt, hogy a blokkolt IP-címek száma elérte érdekes módon a 16 ezres szintet, és utána elkezdett laposodni. Ezt annak tudom be, hogy sok nagyobb robot üzemeltetője olyan IP-cím tartománnyal rendelkezik, ahol 16 384 db IP-cím van. Vagy ha nagyobb tartománnyal is rendelkeznek, erre a régióra ekkora kapacitással jöhetnek. Így a robotok nagy átlagánál kezdhettek kifogyni a szabad címek, mert ugye a többi még tiltás alatt volt ekkor.

A robotok IP-címeit egyébként ha lekérjük a whois paranccsal, akkor a szolgáltató adatai között megkapjuk az IP-cím tartományt is, vagy a CIDR értéket is, amikből például ezen az oldalon kiszámoltathatjuk a tartományban lévő IP-címek számát. Mindez csak azért hasznos, hogy fel tudjuk mérni, hogy milyen kapacitással rendelkeznek kedvenc robotjaink.

Időben kicsit később látható egy hirtelen leesés, amikor ma újraindítottam a Fail2Ban-t, mert még betettem pár újabb robotot a szűrőbe. És ezután látszik, hogy a visszaemelkedés már kicsit lassabb volt, tehát idő kellett a Fail2Ban-nak, míg visszapakolta a szűrőszabályokat az nftables-be. Ezután visszaállt az azelőtti szintre, majd amikor elérte a 24 órát, elkezdett lassan ereszkedni. Ekkora bantime-t állítottam be a Jail-ba, így a lejárt tiltások feloldásra kerülnek. Így beáll szépen egy körforgás.

Ez alatt pedig a CPU is érdekesen alakult:

A tegnapi Fail2Ban szűrő és a .htaccess fájlok együttes használata meg is hozta az eredményt: lecsillapodott minden. Utána volt ugyan egy kis tüske, ami más miatt volt, de azután látható az egyenletesebb felugrás, amit a Fail2Ban újraindítása okozott. Tehát ekkora IP-cím mennyiségnél már jelentkezik egy kis terhelés az újraindításnál. Ami a fentebbi grafikonon is jól látszik, ahogy időbe telt, amíg visszapakolta a tűzfal szűrőszabályaiba a címeket. Majd ezután pedig az előzőnél ugyan alacsonyabb szintű, de tartósabb CPU terhelésbeli emelkedés alakult ki, ami tart most is.

Konklúzió

Összegzésképpen tehát érdemes szem előtt tartani a robot forgalom mértékét, összetételét, a weboldalak mennyiségét és azok forgalmait és a szerverünk kapacitását, amikor beállítjuk ezeket a szűrőket. Nagy mennyiségű IP-címek tiltása esetén fennállhat az ehhez hasonló helyzet, hogy megemelkedik a CPU terhelésünk, pláne egy gyengébb, kevesebb CPU magos szerver esetén nagy load értékeket is eredményezhet.

Természetesen a nagy tömegű IP-cím tiltások kezelésére is van hatékony megoldás, mégpedig az ipset alkalmazásával, és még arra is van mód, hogy mindezt együtt használhassuk a Fail2Ban rendszerünkkel. Mindezzel még alkalmunk lesz megismerkedni egy későbbi leírásban. Addig is figyeljük szerverünk erőforrásait, és optimálisan használjuk mindkét szűrési módszert.