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

Problem mit iptables: Mysql-Verbindung wird nicht aufgebaut

Xenesis

Newbie
Hallo,

ich bin relativer Linux-Neuling und hab dementsprechend noch einige Probleme bei den Einstellungen. Bisher konnte ich mir alles noch irgendwie zusammensuchen, aber bei dieser Sache komme ich einfach nicht weiter.

Und zwar möchte ich meinen Webserver durch eine Firewall schützen. Das iptables-Skript habe ich auch schon soweit geschrieben und die gewünschten Ports freigeschaltet. Das klappt mit den http, https etc. ports auch gut, aber Mysql will da nicht so wirklich.
Ich möchte aus Backupgründen von meinem Webserver aus auch Mysql-Verbindungen nach "draußen" in das lokale Netz aufbauen (und auch zurück).

Wenn ich bei ausgeschalteter Firewall ein einfaches php-Skript aufrufe, das nur eine Mysql-Verbindung mit dem anderen Webserver aufbaut, dann klappt das auch.
Ich hab testweise in der Firewall alle Policies auf ACCEPT gestellt und nur den Port 3306 geschlossen
Code:
 iptables -A INPUT -p tcp --dport 3306 -j DROP
Logischerweise klappt dann die Verbindung nicht mehr.

Wenn ich aber die Policies auf DROP stelle (vorherige Kette habe ich gelöscht) und nur http (damit ich das Skript über den Browser aufrufen kann) und Mysql durchlasse
Code:
 iptables -A INPUT -p tcp --dport 3306 -j ACCEPT
dann kann ich trotzdem per mysql_connect keine Verbindung zum anderen Server aufbauen.

Die Ports sind auch nicht verändert worden und Mysql läuft über 3306.
Brauch Mysql noch weitere freie Ports oder erlaubte Protokolle, oder hab ich einfach ein riesiges Brett vor dem Kopf?

Im Vorraus bedanke ich mich schonmal für die Hilfe
 

TomcatMJ

Guru
Code:
iptables -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
fehlt dir noch wenn du ansonsten alle(!) Policies per default auf DROP setzt. Ohne diese Regel hast du nämlich auch alle Rückkanäle der angestrebten Verbindungen abgewürgt, weswegen zwar die Verbindung hin zum Server durch deine bisherigen Regen zugelassen wird,aber der Server von dort aus nichts zurückmelden darf. Ergo kann ohne diese Regel ja dein Clientrechner gar nicht erfahren ob sein verbindungsversuch gelungen ist und ob seine gesendeten Datenpakete angeommen sind bzw. kann der Server nur die Anforderung von Daten aufnehmen aber keine Daten senden ;)

Bis denne,
Tom
P.S.:Achja,dasselbe nochmal in die INPUT Chain und dein Server darf auch selbst per Script oder so Verbindungen zu anderen Servern aufnehmen und deren Antworten dann annehmen ;)
 
OP
X

Xenesis

Newbie
Hey Tom,

mit der OUTPUT-Policy hatte ich mich vertan, die stand auch weiterhin auf ACCEPT (hatte nur die für INPUT geändert).
Wenn ich aber das mit dem Code für INPUT versuche, klappt der Verbindungsaufbau.

Könntest du mir evtl. noch erklären, warum das dadurch jetzt geht?
das -m state verfolgt ja irgendwie den Verbindungsstatus.
- ESTABISHED würde ja dann nur zutreffen, wenn die Verbindung schon aufgebaut ist, während
- RELATED nur zutrifft, wenn ein Paket zu einer Verbindung passt, die mit einer anderen Verbindung zusammensteht?!

Warum klappt es denn jetzt nach dieser Regel? Ich habe ja nur ein mysql_connect or die aufgerufen. Da ist ja noch keine bestehende Verbindung und es ist auch keine andere passende Verbindung oder?

Sorry irgendwie versteh ich das noch nicht.

Aber schon mal herzlichen Dank dafür, dass es jetzt klappt :p
 

gameboy

Hacker
Hallo Xenesis,

falls Du eine ausführliche Erklärung haben möchtest, dann kannst Du hier nachlesen: http://iptables-tutorial.frozentux.net/iptables-tutorial.html :)

Viele Grüße,
gameboy.
 
OP
X

Xenesis

Newbie
Mit dem Tutorial wollte ich eigendlich anfangen was über iptables zu lernen. Es ist auch ohne Frage sehr gut, aber es hat mich etwas erschlagen in der komplexität :D. Ich hab dann mit diesem Tutorial gearbeitet (http://www.tutorials.de/forum/linux-tutorials/233339-firewalling-mit-iptables-netfilter.html)

Was die Argumente prinzipell bedeuten hatte ich ja oben versucht zu beschreiben (so wie ich das verstanden habe; irrtümer sind wahrscheinlich ;))

Ich frage mich nur, warum das durch diesen Zusatz funktioniert, da ja weder eine Verbindung besteht noch eine "related" Verbindung aufgebaut ist. Oder sehe ich das falsch?
 

TomcatMJ

Guru
Xenesis schrieb:
Hey Tom,

mit der OUTPUT-Policy hatte ich mich vertan, die stand auch weiterhin auf ACCEPT (hatte nur die für INPUT geändert).
Wenn ich aber das mit dem Code für INPUT versuche, klappt der Verbindungsaufbau.

Könntest du mir evtl. noch erklären, warum das dadurch jetzt geht?
das -m state verfolgt ja irgendwie den Verbindungsstatus.
- ESTABISHED würde ja dann nur zutreffen, wenn die Verbindung schon aufgebaut ist, während
- RELATED nur zutrifft, wenn ein Paket zu einer Verbindung passt, die mit einer anderen Verbindung zusammensteht?!

Warum klappt es denn jetzt nach dieser Regel? Ich habe ja nur ein mysql_connect or die aufgerufen. Da ist ja noch keine bestehende Verbindung und es ist auch keine andere passende Verbindung oder?
Naja,wenn der Server der das "mysql_connect or die" aufruft initiiert er eine verbindung(ist ja laut OUTPUT Policy schon erlaubt gewesen). Um mitzubekommen ob dieser Verbindungsversuch geklappt hat muss er jedoch die Antwortpakete des Zielservers erstmal annehmen dürfen,was ihm durch die neue Regel nun endlich erlaubt wird,da nun erst die Datenpakete, die über die RELATED Ports in der Inputchain ankommen und der ja selbst initiierten OUTPUT Verbindung zugeordnet werden, auch endlich im Gegensatz zu vorher angenommen werden dürfen. Vorher kamen diese Antwortpaete durchaus auch an, nur wurden sie von der Default-Policy DROP der INPUT Chain ja verworfen, wohingegen sie jetzt endlich angenommen werden.
Dasselbe andersherum, also mit der Regel für die OUTPUT Chain, wäre dann für die Abfrage des eigenen Servers durch einen Client und nicht für Abfragen des eigenen Servers bei anderen Servers gedacht.
Der Zusatz ESTABLISHED in beiden Regeln sorgt einfach dafür daß die bereits zugelassenen Verbindungen nicht jedesmal für jedes einzelne Datenpaket nochmal komplett gecheckt werden müssen,sorgt also für weniger Serverlast da damit weniger Datenpakete zigfach gecheckt werden müssen ;)

Bis denne,
Tom
 
Oben