• This forum has a zero tolerance policy regarding spam. If you register here to publish advertising, your user account will be deleted without further questions.

mod_security mit ip2location blockiert zufällige Zugriffe einer erlaubten IP

maisen20

New Member
Hallo zusammen

Folgendes Szenario:
Auf meinem kleinen Heim-Server (Raspberry pi 4 8GB, boot und ganzes System über angeschlossene SSD) läuft Apache2, wobei ich da über mod_secuity Zugriffe von aussen, welche nicht zu einigen wenigen Ländern gehören, blockiere.
Das funktioniert eigentlich auch gut, nur werden einige wenige Zugriffe von mir dann doch blockiert.

Bei der "Webseite" handelt es sich um eine eigens entwickelte Galerie bzw. Webapplikation. Da werden nun aber einige Bildaufrufe vom Server blockiert, wobei ich dann bei den Logs auch sehe, dass die Zugriffe von mod_security wegen meiner Regel blockiert werden.

Irgendwie scheint das erst so zu sein, seit ich von http/1.1 zu http/2 gewechselt habe. Sicher kann ich es aber nicht sagen, ob das Problem erst seit dieser Umstellung auftaucht.

Systeminfos
  • Raspberry pi 4 8GB (Raspian)
  • Apache/2.4.38
  • Von http/1.1 zu http/2 gewechselt
  • ip2location IPV6 & IPV4 bin file (7.1 MB)

mod_security Regel
Code:
SecRule ENV:IP2LOCATION_COUNTRY_SHORT "!^(ES|DE|CH|AT)$" "deny,status:500,id:5000888,msg:'Only allow visitors from Spain, Germany, Switzerland and Austria'"

mod_security error
Code:
[Mon Aug 17 18:11:11.238628 2020] [:error] [pid 2414:tid 2961126432] [client xx.xx.x.xxx:xxx] [client xx.xx.x.xxx] ModSecurity: Access denied with code 500 (phase 2). Match of "rx ^(ES|DE|CH|AT)$" against "ENV:IP2LOCATION_COUNTRY_SHORT" required. [file "/etc/modsecurity/modsecurity.conf"] [line "228"] [id "5000888"] [msg "Only allow visitors from Spain, Germany, Switzerland and Austria"] [hostname "my.domain.com"] [uri "/api/thumb/18025"] [unique_id "XzqsH@7lp2KaJ3J4ELTYqwAATSE"], referer: https://my.domain.com:xxx/

mod_security log
Code:
[Mon Aug 17 18:25:40.328146 2020] [:notice] [pid 9832:tid 3069669904] ModSecurity for Apache/2.9.3 (http://www.modsecurity.org/) configured.
    [Mon Aug 17 18:25:40.328265 2020] [:notice] [pid 9832:tid 3069669904] ModSecurity: APR compiled version="1.6.5"; loaded version="1.6.5"
    [Mon Aug 17 18:25:40.328282 2020] [:notice] [pid 9832:tid 3069669904] ModSecurity: PCRE compiled version="8.39 "; loaded version="8.39 2016-06-14"
    [Mon Aug 17 18:25:40.328295 2020] [:notice] [pid 9832:tid 3069669904] ModSecurity: LUA compiled version="Lua 5.1"
    [Mon Aug 17 18:25:40.328306 2020] [:notice] [pid 9832:tid 3069669904] ModSecurity: YAJL compiled version="2.1.0"
    [Mon Aug 17 18:25:40.328318 2020] [:notice] [pid 9832:tid 3069669904] ModSecurity: LIBXML compiled version="2.9.4"
    [Mon Aug 17 18:25:40.328389 2020] [:notice] [pid 9832:tid 3069669904] ModSecurity: StatusEngine call: "2.9.3,Apache/2.4.38 (Raspbian),1.6.5/1.6.5,8.39/8.39 2016-06-14,Lua 5.1,2.9.4,8c"
    [Mon Aug 17 18:25:40.603403 2020] [:notice] [pid 9832:tid 3069669904] ModSecurity: StatusEngine call successfully sent. For more information visit: http://status.modsecurity.org/


Kann es sein, dass es bei der apache2 Konfiguration ein Problem gibt? In den Logs steht da irgendwie was von " ModSecurity for Apache/2.9.3", wenn ich aber apache2 -version ausführe, erhalte ich die Version Apache/2.4.38. Müssen diese Versionen nicht übereinstimmen?

Oder kann es sein, dass der Server mit den Anfragen nicht nach kommt und dann einfach blockiert? Schliesslich ist das bin File von ip2location 7.1 MB.

Vielen Dank und beste Grüsse
maisen20
 
Die Versionen müssen nicht zwingend übereinstimmen. Dein Apache hat die Version 2.4.38, das Modsecurity hingegen die Version 2.9.3
Bezüglich der Verwendung von Länderregeln basieren diese auf Datenbanken, die IP-Bereiche bestimmten Ländern zuordnen. Je nach verwendeter Datenbank und Land stimmen diese Informationen mal mehr mal weniger mit der Realität überein. Google hat beispielsweise mal unseren dienstlichen Vodafone-DSL-Anschluss (IPv4 only) in Russland verortet und dann auf google.ru weitergeleitet - nach ein paar Tagen war der Spuk aber vorbei.
 
Hi danton,

danke für deine Antwort.

Dass die Zuordnung da nicht immer stimmt, ist mir bewusst. Das sehe ich auch täglich beim programmieren der Webapp in unserem Geschäft.
Nur kann das wohl kaum das Problem sein, da ich ja bei zB. 26 von 30 Seiten-/Bildaufrufen den Zugriff korrekterweise erhalte. Nur bei einigen wenigen Bildern (immer zufällig), wird dann doch mal blockiert. Also kann das ja wohl nicht an der IP liegen.
 
Ich würde spontan behaupten dass die Env-Variable aus einem zu klärenden Grund nicht bei jedem Aufruf korrekt defininiert wird und potentiell schlicht leer ist; bspw wenn der Lookup fehlschlägt. Die Filterregel macht damit ihre Arbeit vermutlich korrekt.
Ich würde empfehlen die Env-Variable zu loggen um zu prüfen ob dies die Ursache sein kann.
 
Okay, vielen Dank für den Tipp! Ich werde das mal anschauen, muss aber zuerst noch herausfinden, wie ich das mache.
Werde mich wieder melden.

Besten Dank an euch!
 
Ich würde spontan behaupten dass die Env-Variable aus einem zu klärenden Grund nicht bei jedem Aufruf korrekt defininiert wird und potentiell schlicht leer ist; bspw wenn der Lookup fehlschlägt. Die Filterregel macht damit ihre Arbeit vermutlich korrekt.
Ich würde empfehlen die Env-Variable zu loggen um zu prüfen ob dies die Ursache sein kann.

Du hattest recht, genau so ist es. In den Logs sehe ich bei den meisten Zugriffen der korrekte Ländercode, leider aber gibt es vereinzelt leere Zeilen oder Zeilen mit "-".

Nun weiss ich ehrlich gesagt nicht, wie ich das Problem weiter eingrenzen kann, da ich kein Server-Spezialist bin. Hast du mir da einen Tipp?

Aufgesetzt habe ich alles wie im Link beschrieben:
 
Könnte auch an der veralteten Versionen von Apache und mod_security liegen...
Gerade im Bereich HTTP/2 gab es da etliche Verbesserungen/Bugfixe...

Ansonsten zeigt der Thread mal wieder, wie unsinnig und fehlerhaft Geolocation-basiertes Blocking ist.
 
Hmm okay... Ich wusste nicht, dass Geolocation-basiertes Blocking so unsinnig ist.
Gibts denn einfachere und bessere Wege, um meinen kleinen Heimserver mit unseren privaten Bildern und Videos von unbefugten zu schützen?

Natürlich habe ich alles mittels Login geschützt und der Server ist nicht unter den Standardports 80 & 443 erreichbar, da habe ich andere konfiguriert.

Nur einige wenige IPs zuzulassen ist auch keine Lösung, da man vor allem mit dem Smartphone ja mal schnell wieder eine andere IP vom Netzbetreiber bekommt!?
 
die beste White-Liste-Methode sind Client-Zerts - da kommt wirklich nur rein, wer das passende Zert. hat.

ansonsten sollte Login / PW eigentlich völlig ausreichend sein - alles andere nervt nur, wenn man mal irgendwo ist, wo man warum auch immer plötzlich nicht eine der vermeintlich freigegeben Ranges hat...
 
Nur einige wenige IPs zuzulassen ist auch keine Lösung, da man vor allem mit dem Smartphone ja mal schnell wieder eine andere IP vom Netzbetreiber bekommt!?
Ein eigenes VPN wäre noch eine mögliche Option.
Bonus dabei: Die Smartphones sind grundsätzlich besser geschützt, speziell wenn man öffentliche WLANs unterwegs nutzt.
 
Ein eigenes VPN wäre noch eine mögliche Option.
Bonus dabei: Die Smartphones sind grundsätzlich besser geschützt, speziell wenn man öffentliche WLANs unterwegs nutzt.

Ja das wäre sicher die beste/sicherste Lösung. Nur ist das nicht so praktisch... Deswegen hatte ich schnell wieder von dieser Idee abgesehen.
 
Weil meine Familienmitglieder keine Ahnung davon haben. Ich das ihnen sicher einrichten kann, aber dann müssen sie beispielsweise vor dem Zugriff immer mit meinem Heimnetz per VPN verbinden. Zudem wird dann meine Internetleitung (Up und Down) noch mehr belastet - oder verstehe ich das falsch?
 
aber dann müssen sie beispielsweise vor dem Zugriff immer mit meinem Heimnetz per VPN verbinden
Man kann die WG-App auf dem Handy so einrichten, daß die den VPN-Tunnel schon beim Handystart aufbaut und daß die VPN-Verbindung permanent aktiv bleibt. Ich bin mit meinem Handy auch dauerhaft mit dem VPN verbunden, egal ob ich in einem WLAN bin oder mobile Daten nutze.

Zudem wird dann meine Internetleitung (Up und Down) noch mehr belastet
Das kann ich dir leider nicht sagen, da ich die Rahmenwerte deines DSL-Anschlusses nicht kenne.
Hier wäre aber auch die Auslagerung des VPN-Servers auf einen kleinen vServer im Netz eine mögliche Alternative...Bei einem großen französichen Hoster (inzwischen auch mit deutschem RZ) bekommst du einen kleinen vServer schon für 3,56€ im Monat mit 10TB Traffic...Ist halt immer eine Frage von Aufwand nund Nutzen, aber das kannst nur du entscheiden, ob solch ein Ansatz sinnvoll ist.
 
Rein für das Absichern einer Webseite einen VPN auf zu bauen finde ich gelinde gesagt overkill. HTTPS basiert auf der gleichen Verschlüsselungstechnik TLS und bietet doch so einige Vorteile und Bequemlichkeiten. TLS über TLS ist unnütz und kostet nur Leistung sowie Komplexität.
Wenn wir, wie es hier scheint, über eine Umgebung reden wo Bequemlichkeit wichtig ist und Unterstüutzung bei der Erstkonfiguration möglich ist, wären X509 Client-Zertifikate ein sehr gangbarer Weg und mittlerweile von den gängigen Browser (auch mobil) unterstützt.
 
Zum Lernen wie man mod_security mit vernünftigen und individuellen Rules versorgt, ohne Geolocation zu nutzen:
Setzt zwingend das Lesen+Verstehen der mod_security-Dokumentation voraus, lohnt sich aber, wenn man mod_security unbedingt einsetzen will.


Ich persönlich nutze lieber meinen Paketfilter (FreeBSD PF) um die allgemein bekannten Malware-/Spamschleudern, Botnetze und selbstverständlich das Tor-Netzwerk weitestgehend auszufiltern, bevor sie meine Dienste erreichen können. Dazu gibt es noch temporäre Filter für übereifrige Zugriffe.
Alles was dann noch übrig bleibt, ist harmloses Grundrauschen oder derart geziehltes Hacking, dass der Kosten-Nutzen-Faktor zur Abwehr auf dieser Ebene meist nicht mehr gegeben ist (dafür existieren dann selbstverständlich noch ein paar nachrangige Sicherheitsmechanismen).
Mehr ist nicht nötig und nur überflüssiger Ballast (und obendrein auch noch ein völlig unnötiges weiteres Sicherheitsrisiko)...
 
Back
Top