Tartalom

Bevezető

Szerverünk minél összetettebb, annál nagyobb az esélye hogy ok-okozati alapon összeakad valami, és olyan alattomos hibákat idéz elő, amit nehéz kibogozni. Így történt ez a minap velem is, amkor egyik napról a másikra nem tudtam elérni a szerveremen lévő weboldalakat, webalkalmazásokat. A böngésző ilyenkor az "ERR_TIMED_OUT" hibaüzenetet írta, ami nem túl ritka hiba, és többféle dolog is okozhatja, ennél fogva nehezebb az okok beazonosítása.

Ebben a hibaelhárítóban felgöngyölítünk egy Fail2Ban tiltást, amit egy "AH01630: client denied by server configuration" típusú Apache hiba vált ki, amit a Matomo webanalitikai rendszere okoz. A problémát végül az apache-auth Fail2Ban szűrőjének módosításával orvosoljuk.

A hibajelenség

Ahogy a bevezetőben is említettem, a szerveren lévő weboldalak és egyéb webes alkalmazások nem érhetők el, a böngésző pedig az "ERR_TIMED_OUT" hibaüzenetet adja. Emellett minden egyéb szolgáltatás elérhető, mint például az SSH kapcsolódás, a levelezés (IMAP) vagy az FTP, stb.

A hiba az itthoni vezetékes interneten volt tapasztalható, mobilnetről viszont működött minden. A vezetékes internet modemet újraindítva a probléma átmenetileg megszűnt, majd pár perc múlva ismét elérhetetlenné váltak az oldalak. Mindezt többször elismételtem, és véletlenszerű idők múlva újra előjött a probléma. Elég furcsának tűnt az egész, mivel a szerver SSH-n keresztül elérhető volt, ezért elkezdtem kutakodni. A szolgáltatót is kérdeztem, de nem volt semmilyen karbantartás, se a szervert érintő hálózati probléma, így a szerveren kezdtem körülnézni.

A hiba okának keresése

Eszembe jutott, hogy esetleg a Fail2ban tilthatta ki az IP-címem, ezért benéztem a Fail2ban log fájljába:

cat /var/log/fail2ban.log | grep "<saját ip-cím>" | tail -40

[...]
2022-05-18 14:43:53,508 fail2ban.filter         [1781]: INFO    [apache-auth] Found 85.238.74.10 - 2022-05-18 14:43:53
2022-05-18 15:10:23,905 fail2ban.filter         [1781]: INFO    [apache-auth] Found 85.238.74.10 - 2022-05-18 15:10:23
2022-05-18 15:10:24,067 fail2ban.actions        [1781]: NOTICE  [apache-auth] Ban 85.238.74.10
2022-05-18 15:10:26,821 fail2ban.actions        [1781]: NOTICE  [apache-auth] Unban 85.238.74.10
2022-05-18 15:10:29,840 fail2ban.filter         [1781]: INFO    [apache-auth] Found 85.238.74.10 - 2022-05-18 15:10:29
2022-05-18 15:11:21,488 fail2ban.filter         [1781]: INFO    [apache-auth] Found 85.238.74.10 - 2022-05-18 15:11:21
2022-05-18 15:11:22,158 fail2ban.actions        [1781]: NOTICE  [apache-auth] Ban 85.238.74.10
2022-05-18 15:11:24,443 fail2ban.actions        [1781]: NOTICE  [apache-auth] Unban 85.238.74.10
2022-05-18 15:20:53,763 fail2ban.filter         [1781]: INFO    [apache-auth] Found 85.238.74.10 - 2022-05-18 15:20:53
2022-05-18 15:20:59,671 fail2ban.filter         [1781]: INFO    [apache-auth] Found 85.238.74.10 - 2022-05-18 15:20:59
2022-05-18 15:21:00,081 fail2ban.actions        [1781]: NOTICE  [apache-auth] Ban 85.238.74.10
2022-05-18 15:21:02,540 fail2ban.actions        [1781]: NOTICE  [apache-auth] Unban 85.238.74.10

Be is jött a tippem, tehát itt előkerültek a tiltások és a feloldások. Ezután, követve a naplóban rögzített "apache-auth" jail-t, megnézzük a jail-hoz tartozó szűrőt is:

nano /etc/fail2ban/filter.d/apache-auth.conf

# Fail2Ban apache-auth filter
#

[INCLUDES]

# Read common prefixes. If any customizations available -- read them from
# apache-common.local
before = apache-common.conf

[Definition]

prefregex = ^%(_apache_error_client)s (?:AH\d+: )?<F-CONTENT>.+</F-CONTENT>$

# auth_type = ((?:Digest|Basic): )?
auth_type = ([A-Z]\w+: )?

failregex = ^client (?:denied by server configuration|used wrong authentication scheme)\b
            ^user <F-USER>(?:\S*|.*?)</F-USER> (?:auth(?:oriz|entic)ation failure|not found|denied by provider)\b
            ^Authorization of user <F-USER>(?:\S*|.*?)</F-USER> to access .*? failed\b
            ^%(auth_type)suser <F-USER>(?:\S*|.*?)</F-USER>: password mismatch\b
            ^%(auth_type)suser `<F-USER>(?:[^']*|.*?)</F-USER>' in realm `.+' (not found|denied by provider)\b
            ^%(auth_type)sinvalid nonce .* received - length is not\b
            ^%(auth_type)srealm mismatch - got `(?:[^']*|.*?)' but expected\b
            ^%(auth_type)sunknown algorithm `(?:[^']*|.*?)' received\b
            ^invalid qop `(?:[^']*|.*?)' received\b
            ^%(auth_type)sinvalid nonce .*? received - user attempted time travel\b

ignoreregex = 

# DEV Notes:
#
# This filter matches the authorization failures of Apache. It takes the log messages
# from the modules in aaa that return HTTP_UNAUTHORIZED, HTTP_METHOD_NOT_ALLOWED or
# HTTP_FORBIDDEN and not AUTH_GENERAL_ERROR or HTTP_INTERNAL_SERVER_ERROR.

[...]

Ez a szűrő a HTTP hitelesítésekkel kapcsolatos hibákat figyeli, tehát ilyen üzeneteket kell keresnünk az Apache hibanapló fájljainkban, amik a "failregex"-nél vannak felsorolva.

Ha egy egyszerűbb LAMP szervert használunk, akkor az Apache hibanapló bejegyzéseit alapértelmezés szerint a /var/log/apache2/error.log fájlban kell keresnünk, amennyiben nem állítottunk be valami egyedi útvonalat. Ez esetben a saját konfigurációnknak megfelelő hibanapló fájlt keressük.

Ha pedig ISPConfig-os szerverkörnyezetet használunk, akkor vélhetően több weboldal is fut a szerveren, amiknek külön fájlokban kerülnek gyűjtésre a futás közben fellépő Apache hibák. Jelen esetben most ezt nézzük át.

Az ISPConfig telepítésekor sok mindent átkonfigurál, így az Apache hibanaplók elérését is, amelyeket az alábbi struktúrában érhetjük el:

/var/log/ispconfig/httpd/

Majd ez alatt minden webtárhelynek van egy alkönyvtára, és abban van az Apache access.log és az error.log fájl is. Ezeket kell átbogarásznunk, hogy kiderítsük melyik webtárhelyhez kötődik a hiba, illetve hogy mi okozza.

Ha több weboldalunk van, akkor a legegyszerűbben egy grep parancs segítségével, a saját IP-címünkre történő szűréssel találhatjuk meg a hiba forrását:

grep -rw --include="error.log" "<saját IP-cím>" /var/log/ispconfig/httpd | tail -12

A -r opció biztosítja a rekurzív keresést, a -w pedig az egész szavas keresést alkalmazza, így csak az elkülönülő IP-cím mintákat adja ki.

/var/log/ispconfig/httpd/linuxportal.info/error.log:[Wed May 18 18:39:23.912143 2022] [authz_core:error] [pid 31857:tid 140418732259072] [client 85.238.74.10:62050] AH01630: client denied by server configuration: /opt/matomo/plugins/CoreHome/javascripts/manifest.json, referer: https://www.linuxportal.info/matomo/index.php?module=CoreHome&action=index&idSite=1&period=day&date=today
/var/log/ispconfig/httpd/linuxportal.info/error.log:[Wed May 18 18:39:48.519643 2022] [authz_core:error] [pid 31857:tid 140418749044480] [client 85.238.74.10:62080] AH01630: client denied by server configuration: /opt/matomo/plugins/CoreHome/javascripts/manifest.json, referer: https://www.linuxportal.info/matomo/index.php?module=CoreHome&action=index&idSite=1&period=day&date=today
/var/log/ispconfig/httpd/linuxportal.info/error.log:[Wed May 18 18:57:54.471065 2022] [authz_core:error] [pid 31858:tid 140418732259072] [client 85.238.74.10:65007] AH01630: client denied by server configuration: /opt/matomo/plugins/CoreHome/javascripts/manifest.json, referer: https://www.linuxportal.info/matomo/index.php?module=CoreHome&action=index&idSite=1&period=day&date=today
/var/log/ispconfig/httpd/linuxportal.info/error.log:[Wed May 18 19:02:51.688512 2022] [authz_core:error] [pid 31858:tid 140418639939328] [client 85.238.74.10:49443] AH01630: client denied by server configuration: /opt/matomo/plugins/CoreHome/javascripts/manifest.json, referer: https://www.linuxportal.info/matomo/index.php?module=CoreHome&action=index&idSite=1&period=day&date=today

És meg is van a hiba okozója. Nálam tehát a Matomo webanalitikai rendszer egyik eleme a gubancok forrása, ami egy "AH01630: client denied by server configuration" típusú hibát okoz, és emiatt tiltja le az IP-címet, ha a megadott időkereten belül összegyűlik a megadott számú hiba.

A hibát okozó lekérés tárgyát képező fájl pedig a Matomo telepítési könyvtárán belül van: /opt/matomo/plugins/CoreHome/javascripts/manifest.json.

Ez nem egy konkrét tárhelyhez kapcsolódik, hanem a Matomo rendszere egy Apache konfigként van beállítva így az a szerver bármelyik weboldala alól elérhető. Én ezt a linuxportal.info alatt szoktam használni.

Most, hogy meglett a hiba forrása, már csak megoldást kell rá találnunk.

A megoldás

Az imént felderített hiba nálam körülbelül egy napja jelentkezett, ami egybeesik a Matomo legutóbbi frissítésével. Ebből arra következtetek, hogy a Matomo szoftverébe kerülhetett hiba, amit lehetne debug-olni, de sokezer sornyi PHP kód átbogarászása nem a mi feladatunk, hanem majd remélhetőleg javítják egy későbbi frissítésben. Mindezt arra alapozom, hogy évek óta használom már a Matomo webanalitikai rendszert - ami mindvégig kiválóan működött -, valamint az ISPConfig-os szerverkörnyezet részeként a Fail2ban biztonsági szoftverrel sem volt semmi gond. Nálam a napokban érkezett Matomo frissítés óta jelentkezett ez a probléma.

Amit tehetünk ebben az esetben, hogy a Matomo szoftverén kívüli körülményeket alakíthatjuk oly módon, hogy a hiba megszűnjön. Erre többféle megoldás is kínálkozik. Például lekapcsolhatnánk az apache-auth jail-t, vagy lazítunk a szűrési feltételeken, azonban ezeket nem javaslom, mert biztonsági kockázatot jelentenek. A Fail2ban jail-jai és szűrői szépen teszik a dolgukat, ezért inkább a szűrőt érdemes közelebbről megvizsgálni és módosítani egy kivétel behelyezésével.

Mielőtt hozzányúlnánk a szűrőkhöz, teszteljük le, nézzük meg a fail2ban-regex parancs segítségével hogy így hány találatot ad a mai napra:

sudo fail2ban-regex /var/log/<saját hibanapló fájlunk útvonala> /etc/fail2ban/filter.d/apache-auth.conf

Itt tehát mindenki a saját hibanapló fájljának útvonalát használja.

Itt nálam 91 darab találatot ad a mai napi hibanapló fájlban talált "AH01630: client denied by server configuration" típusú hibákból. Ebből természetesen nem mind ez a hiba, mert lehetnek más HTTP hibák is más IP-címekről is, de a java része itt a miénk. Ezután módosítsuk a szűrőt.

Fentebb már betettem egy részletet az apache-auth.conf fájl tartalmából, most nyissuk meg újra:

sudo nano /etc/fail2ban/filter.d/apache-auth.conf

Majd itt találunk egy ilyen részt:

failregex = ^client (?:denied by server configuration|used wrong authentication scheme)\b
            ^user <F-USER>(?:\S*|.*?)</F-USER> (?:auth(?:oriz|entic)ation failure|not found|denied by provider)\b
            ^Authorization of user <F-USER>(?:\S*|.*?)</F-USER> to access .*? failed\b
            ^%(auth_type)suser <F-USER>(?:\S*|.*?)</F-USER>: password mismatch\b
            ^%(auth_type)suser `<F-USER>(?:[^']*|.*?)</F-USER>' in realm `.+' (not found|denied by provider)\b
            ^%(auth_type)sinvalid nonce .* received - length is not\b
            ^%(auth_type)srealm mismatch - got `(?:[^']*|.*?)' but expected\b
            ^%(auth_type)sunknown algorithm `(?:[^']*|.*?)' received\b
            ^invalid qop `(?:[^']*|.*?)' received\b
            ^%(auth_type)sinvalid nonce .*? received - user attempted time travel\b

ignoreregex = 

Ebben az ignoreregex = után tegyük be a hibanaplóban talált fájlnevet, ami az én esetemben az alábbi:

/opt/matomo/plugins/CoreHome/javascripts/manifest.json

failregex = ^client (?:denied by server configuration|used wrong authentication scheme)\b
            ^user <F-USER>(?:\S*|.*?)</F-USER> (?:auth(?:oriz|entic)ation failure|not found|denied by provider)\b
            ^Authorization of user <F-USER>(?:\S*|.*?)</F-USER> to access .*? failed\b
            ^%(auth_type)suser <F-USER>(?:\S*|.*?)</F-USER>: password mismatch\b
            ^%(auth_type)suser `<F-USER>(?:[^']*|.*?)</F-USER>' in realm `.+' (not found|denied by provider)\b
            ^%(auth_type)sinvalid nonce .* received - length is not\b
            ^%(auth_type)srealm mismatch - got `(?:[^']*|.*?)' but expected\b
            ^%(auth_type)sunknown algorithm `(?:[^']*|.*?)' received\b
            ^invalid qop `(?:[^']*|.*?)' received\b
            ^%(auth_type)sinvalid nonce .*? received - user attempted time travel\b

ignoreregex = /opt/matomo/plugins/CoreHome/javascripts/manifest.json

Mentsük le, majd futtassunk egy újabb szűrőtesztet:

sudo fail2ban-regex /var/log/<saját hibanapló fájlunk útvonala> /etc/fail2ban/filter.d/apache-auth.conf

Itt látszik szépen a különbség. Itt már csak 19 darab "AH01630: client denied by server configuration" típusú hibát talált, és lejjebb az is előkerül, hogy az Ignoreregex rész pedig 72 darab "/opt/matomo/plugins/CoreHome/javascripts/manifest.json" fájlt hagyott figyelmen kívül.

Ezzel tehát elértük a célunkat: az apache-auth szűrője többé már nem fogja figyelembe venni ezt a Matomo által generált "AH01630: client denied by server configuration" típusú hibát. Persze a hiba ettől még megmarad, amit remélhetőleg javítanak a Matomo-nál, de a Fail2ban már nem fogja letiltani az IP-címünket. Jelenleg ennyit tudunk tenni.

Ha mindennel megvagyunk, akkor indítsuk újra a Fail2ban szolgáltatását:

sudo systemctl restart fail2ban.service

Innentől már nem kell aggódnunk, hogy az általunk vélt Matomo-beli hiba miatt újból letiltja a rendszer az IP-címünket.

Érdekességek

Még pár dolgot említek csak érdekességképpen, hátha másoknak is hasznos információ.

Nálam a Chrome böngésző az elsődleges, amiből több ablakpéldányt is használok több monitoron és virtuális asztalon. Olykor előfordul, hogy több példányban is futtatom a Matomo-t, hogy jobban láthassam több asztalon is. Amikor a keretrendszer betöltődik, akkor jön elő a hiba. Tehát lapfrissítésekkor. Másik ablakban közben figyelem a tail paranccsal amikor jönnek a hibaüzenetek és a letiltások.

A Chrome inkognitó ablakában nem jelentkezik a probléma. A sima változatban töröltem már minden sütit, előzményt, mégis előjön a hiba. Firefox böngészőben szintén nem jön elő a hiba. Tehát ez a hiba kapcsolódhat részben egy belső Chrome hibához is. Persze ezt így nehéz megállapítani, de a kettő együtt (Chrome + Matomo) generál egy HTTP hitelesítési hibát, ami érdekes.

Konklúzió

Ezzel megoldottunk egy újabb furcsaságot. Az egész így utólag elég egyszerű, de az elején sok idő elmegy a probléma megismerésével. A levezetést azért készítettem ilyen részletesre, mert hátha másnál nem pont ugyanez a kombináció okoz hibát, hanem valami más, de ennek analógiájára azt is könnyebben fel lehet deríteni, és elkészíteni rá az egyedi megoldást. Persze ezzel a kivitelezéssel - ebben a konkrét esetben - nem szüntettük meg magát a tényleges hibát, azonban elértük a célunkat, hogy ne kerüljünk tiltásra a saját szerverünkről.

Ez a kis hibaelhárító hasznos példaként szolgálhat más esetekre is, ahol ehhez hasonlóan érdemes a Fail2Ban körül kezdeni a vizsgálódást, hátha az tiltott ki bennünket valamelyik szerver szolgáltatásból.