• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

[jelöööst] iptables / modsecurity

suwelo

Member
Moin zusammen,
auf meinem System werkeln iptables, der apache2 und seit kurzem modsecurity vor sich hin.
Modsecurity verhindert z.b. Zugriffe auf den "apache" über die IP Adresse und kann Script Attacken blocken bzw. umleiten.

Netzwerktopologie:
Eine FritzBox habe ich als NAT Router und diese leitet Anfragen nach draussen.
Eine Portfreigabe an der FritzBox, Port 80, ist geöffnet und leitet HTTP Anfragen an den Apache2 von aussen nach innen (Ubuntu 16.04.2 Server).
Die Systeme befinden sich alle im gleichen "Private Class C" Netzwerksegment, ausser der öffentlichen IP Adresse der FritzBox, die ich vom Provider zugewiesen bekomme.

iptables:
ich habe in der iptables einige IP Adressen eingetragen, die ich an der Konsole in nachfolgender Form eingebe.

Code:
iptables -A INPUT -s IPADD.RESS/16 -i eth0 -p tcp --dport 0:65534 -j DROP
iptables -A INPUT -s IPADD.RESS/16 -i eth0 -p udp --dport 0:65534 -j DROP


Ein "iptables -L" zeigt mir:

Code:
DROP       tcp  --  IPADD.RESS/16       anywhere             tcp dpts:0:65534
DROP       udp  -- IPADD.RESS/16       anywhere             udp dpts:0:65534


Selbstversuche mit der eigenen öffentlichen IP Adresse, die ich zuvor in die iptables eingefügt habe, suchen sich über den Aufruf der DynDomain erstmal tot und erzeugen danach, soweit ich mich erinnere, einen 404 Fehler - "Page not found or unable to stat".
Soweit ist das denke ich in Ordnung, zumal auch modsecurity eine Seitenumleitung vornimmt, wenn ein "HTTP get request" über die IP Adresse ohne HTTP Header an Port 80 ankommt.


Was mich nun verwirrt sind Einträge in der apache_error.log von IP Adressen, die über IP Tables gesperrt sein sollten aber dennoch nachfolgende Einträge erzeugen:

Code:
[Sat Aug 05 15:52:57.277333 2017] [core:error] [pid 29092] [client IP.AD.DR.ESS:23366] AH00126: Invalid URI in request GET login.cgi HTTP/1.0

ODER

[Fri Aug 04 22:51:33.398778 2017] [:error] [pid 9688] [client IP.AD.DR.ESS:50633] script '/var/www/html/vhosts/host.dyn-domain.org/html/testproxy.php' not found or unable to stat


Im letzten Beispiel habe ich aus Datenschutzgründen die "client IP.AD.DR.ESS" heraus genommen. Die IP Adressen sind jedoch in gezeigten Logauszügen weiterhin auffindbar, obwohl in den iptables vollständig gesperrt.
Mir ist auch klar, dass die Portweiterleitung der FritzBox ankommende HTTP Anfragen grundsätzlich weiterleiten muss und die FritzBox wohl keinen Einfluss auf das logging ausübt.

Dennoch bin ich der Meinung, dass Logauszüge wie im letzten Beispiel genannt, keinen Logeintrag erzeugen dürften.

Oder denke ich da was falsches zusammen?

Kann mir evtl. jemand dabei helfen, meinen Denkfehler zu entwirren?

Danke

:???:
 
OP
suwelo

suwelo

Member
Moin zusammen,
ein funktionierendes System ist cool, wenn es läuft.
Sicherheit ist auch cool, wenn man es versteht.

Aus dem englischen heisst das Wort (to) "drop", verwerfen.
Nach meinem profanen denken, dürfte da kein Eintrag in der Log Datei entstehen, weil die Anfrage durch iptables "verworfen" werden sollte -> "Zeitüberschreitung der Anfrage".

Aus welchem Grund loggt das die gesperrten IP Adressen bzw. Netzwerke?
In meinen Ausführungen loggt Apache als bsp. eine ungültige URL Anfrage (input), von einer in den iptables eingetragenen und gesperrten "IP Adress Quelle (-s)".

Wenn ich iptables richtig verstehe, wird eine ankommende Anfrage zuerst von iptables gegengeprüft, bevor Apache irgendtwas ausgibt.

Oder ist es anders herum?
Apache stellt fest, da ist ne ungültige Anfrage -> logeintrag,
danach wirft sich iptables dazwischen und verwirft die Anfrage?


Ich wollte die Frage umstellen, doch habe ich Schwierigkeiten das richtig zu formulieren, möglicherweise weil ich grundsätzliche Verstehensprobleme mit den Abläufen habe, wie Anfragen und Ausgaben beantwortet werden.

Ich kann mir noch vorstellen, dass iptables, "numerisch" basiert ist und zu HTTP Anfragen keinen Bezug hat

:???:
 

spoensche

Moderator
Teammitglied
Pakete, eingehend von der IP IPADD.RESS/16 sollen verworfen werden. Stimmt den die Netzmaske der Quell IP (/16)?

Sind vor den beiden Regeln, Regeln vorhanden, die den Verkehr zulassen?
 
OP
suwelo

suwelo

Member
Moin zusammen,

iptables -S gibt folgenden Inhalt aus:

Code:
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

192.168/16 in den iptables, müsste für mein Denken 192.168.224.225(/32) auf jeden Fall mit einschliessen, da die Bedingung bis zum 2ten Oktett (192.168/16) bereits erreicht ist.

Hier in diesem bsp. habe ich "Private Class C" Adressen benutzt.
In meinen iptables sieht es für die öffentlichen IP Adressen genauso aus.

:???:
 
Vorweg: Ich habe schon lange nichts mehr mit iptables gemacht, aber deine IP/MASK sieht für mich merkwürdig aus. Normalerweise (bei anderen mir bekannten Netzwerkanwendungen) sollte es 192.168.0.0/16 heißen. Aber das kann bei iptables durchaus anders sein. Wenn Du dir dessen sicher bist, gut. Ansonsten ändere das mal und guck ob es dann klappt.
Was meiner Meinung nach überflüssig aber nicht schädlich ist, ist deine Angabe zum dport. Wenn Du da gar nichts angibst werden alle Ports blockiert (so zumindest mein Wissensstand). Oder ist es erwünscht das der Port 65535 erreichbar ist? Ich würde da erst einmal auf einen Fehler deinerseits tippen. Guckst Du Port Range
 
suwelo schrieb:
Oder ist es anders herum?
Apache stellt fest, da ist ne ungültige Anfrage -> logeintrag,
danach wirft sich iptables dazwischen und verwirft die Anfrage?
iptables ist ein Werkzeug, mit dem du Anweisungen (rules) in den Kernel schreiben kannst.
Über die Netzwerkkarte kommt der Datenstrom herein und fließt in den Kernel. Dort drinnen sitzen dein Rules. Der Apache lauscht an der anderen Seite des Kernels.
Wenn also der Kernel dein DROP (Datenpaket verwerfen) ausführt, bekommt der Apache das gar nicht mit und kann deshalb auch keine Logausgabe generieren.

suwelo schrieb:
Aus welchem Grund loggt das die gesperrten IP Adressen bzw. Netzwerke?
Das kann mehrere Gründe haben.
1. Deine rule ist falsch. Auf Grund deiner undeutlchen Angaben kann ich das aber nicht feststellen.
2. modsecurity erzeugt parallel zu deinen rules irgendwelche anderen rules, (z.B. ein forwarding), die du und ich nicht kennen.
modsecurity zu entfernen ist eine deiner ersten Aufgaben.
Sicherheit heißt, du weißt genau, was in deinem System passiert und du lagerst diese Sicherheit nicht an Dritte aus.

suwelo schrieb:
Ich wollte die Frage umstellen, doch habe ich Schwierigkeiten das richtig zu formulieren, möglicherweise weil ich grundsätzliche Verstehensprobleme mit den Abläufen habe, wie Anfragen und Ausgaben beantwortet werden.
:???:
Du wirst dich wohl in iptables einlesen müssen - das füllt Bücher.
Darüber hier zu schreiben ist müßig und führt zu nichts.

Ein paar Tipps:
Wenn ich dich richtig verstehe, fließen Datenströme aus dem öffentlichen Netz in dein privates class C Netz,
DAS IST VERBOTEN! Der router ist dein Feind und kann in deinem Fall kein Teil deines privaten Netzwerkes sein.
Du mußt diese beiden Netze klar voneinder trennen, sonst wirst du - egal mit welchen Super_rules auch immer - scheitern.

Deine rules werden in der Reihenfolge, so wie du sie angibst, von oben nach unten vom kernel abgearbeitet.
Diese Reihe an rules nennt sich chain. Es ist sehr schwierig, eine funktionierende chain ohne Kontrolle eines Logs zu erstellen.
Deshalb baust du dir zuerst spezielle chains, die über den kernel ein log ausgeben.
Beispiel einer chain mit dem Namen "drop-invalid" die logged und dropped:
Code:
iptables -N drop-invalid
iptables -A drop-invalid -m limit --limit 10/sec --limit-burst 1 -j LOG --log-level 4 --log-prefix "DropInvalid:"
iptables -A drop-invalid -j DROP
Danach ein Beispiel einer deiner rules die dropped:
Code:
iptables -A INPUT -s IPADD.RESS/16 -i eth0 -p tcp --dport 0:65534 -j drop-invalid
Erst damit kannst du herumprobieren und siehst auch im KernelLog was passiert.

Du beginnst deine chain mit rules die Sperren, also DROP.
Das ist falsch. Du kannst ja nicht alles Sperren was gesperrt werden muß, das führt ins Nirvana.
Zuerst ernöglichst du Pakete unter bestimmten Konditionen mit z.B. ACCEPT.
Die letzte rule in der chain ist dann ein fettes DROP das ausgeführt wird, wenn keine ACCEPT Kondition von vorher greift.
Hier solltest du umdenken.

Alles andere mußt du dir unter iptables selbst erlesen.

Gruß
Gräfin Klara
 
OP
suwelo

suwelo

Member
Moin zusammen,

die IP Adressen sind in meinen Rules so eingetragen, mit den Nullen.

Und manchmal ist es sinnvoll, dass man Wissen nochmal auffrischt.

Es sind 65535 Ports

Ich habe bei mir zuhause das Buch "Linux Firewalls", in das ich mich nochmals hineinvertiefen will.

Vielen Dank für die Anregungen.
 

spoensche

Moderator
Teammitglied
Gräfin Klara schrieb:
Du beginnst deine chain mit rules die Sperren, also DROP.
Das ist falsch. Du kannst ja nicht alles Sperren was gesperrt werden muß, das führt ins Nirvana.
Zuerst ernöglichst du Pakete unter bestimmten Konditionen mit z.B. ACCEPT.
Die letzte rule in der chain ist dann ein fettes DROP das ausgeführt wird, wenn keine ACCEPT Kondition von vorher greift.
Hier solltest du umdenken.

Das stimmt so nicht ganz. Du kannst z.B. als erste Regel sehr wohl alle Invalid Pakete droppen. Natürlich kann man per Default erst mal alles droppen, bis es explizit erlaubt worden ist. Ansonsten könnte man nicht "Alles was nicht explizit erlaubt ist, ist verboten umsetzen". Dafür verwendet man allerdings die Policies.

Beispiel:
Code:
iptables -P INPUT DROP

iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

.....

Setze die Default Policy der Input CHAIN auf DROP. D.h. sofern nicht explizit freigeschaltet wird jedes Paket gedroppt.
Anschließend folgt das akzeptieren von Paketen, die keine neu initierte Verbindung sind (also alles was zu bereits bestehenden Verbindungen gehört wird akzeptiert und evtl. durch darauffolgende Regeln weiter eingeschränkt.
 
Oben