• 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.

IPTables - Port auf ein anderes Interface leiten

CryOrDies

Member
Hallo und guten Abend in die Runde.

Ich komme gerade mit den Regeln von IPTables nicht zurecht, wir stehen immer wieder mal auf Kriegsfuß. Ich nutze auf meinem Heimserver Debian 10 Server. Da ich euch hier kein Roman zu lesen geben möchte, lass ich den Detaillierten Hintergrund mal weg.

Ich hab u.a. ein MariaDB SQL-Server laufen der auf alle Interfaces hört ( 0.0.0.0), das möchte ich aber nicht. Alle SQL-Benutzer sind entweder auf localhost oder auf 172.18.0.% gebunden. Ist ja an sich schon recht sicher, aber da der SQL von außen nicht angesprochen wird braucht er darauf auch nicht hören.

Das Problem ist das das 172.18.0.0/16 Netz. Das ist ein virtuelles Interface, heißt pterodactyl0

Ich brauch eine IPTables-Regel die interne Verbindungen aus dem 172.18.0.0/16 Netz mit Port 3306 auf localhost:3306 umleitet, die ESTABLISHED wird und natürlich auch die Anfrage wieder zurückgeben kann. Aber nur Port 3306, alles andere darf die Regel nicht beeinflussen.

Mehrere binding-Adressen funktionieren nicht und auf 172.18.0.1 (Gateway)binden kann ich nicht, weil im localhost Bereich andere Dienste auch drauf zugreifen.

Nach eigenen Suchen im Netz bin auf Postrouting und Prerouting gestoßen.

Ich bin aber nicht sicher bin ob das eine oder das andere klappt und ob es sinnvoll ist. Oder ob es was anderes gibt das besser ist.

1)
iptables -t nat -A POSTROUTING -p tcp -s 172.18.0.0/16 --sport 3306 -d 127.0.0.1 --dport 3306

2)
iptables -t nat -A PREROUTING -p tcp --dport 3306 -i pt10 -j DNAT --to 127.0.0.1:3306


Im Moment läuft es auf einem Heimserver hinter einem Router, aber das soll wenn es fertig ist auf einem Dedizierten Server in einem RZ.

Ich hoffe ich hab es verständlich erklärt.

Liebe Grüße und schönen Abend noch
 
Last edited:
Lass Doch den mysql auf 0.0.0.0 hören und setze iptables-Regeln davor, die den Zugriff nur von 172.18.0.0/16 bzw. loopback(interface lo) zulassen. Da kannst Du Dir den NAT-Kram sparen.

Code:
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i pt10 -p tcp -s 178.18.0.0/16 --dport 3306 -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -j REJECT

Die 3. Regel ist alternativ dazu, dass Du die Chain-Policy auf DROP setzt(Vorsicht, du könntest Dich damit ganz schnell aussperren!).
 
Last edited:
Lass Doch den mysql auf 0.0.0.0 hören und setze iptables-Regeln davor, die den Zugriff nur von 172.18.0.0/16 bzw. loopback(interface lo) zulassen. Da kannst Du Dir den NAT-Kram sparen.

Code:
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i pt10 -p tcp -s 178.18.0.0/16 --dport 3306 -j ACCEPT
iptables -A INPUT -p tcp --dport 3306 -j REJECT

Die 3. Regel ist alternativ dazu, dass Du die Chain-Policy auf DROP setzt(Vorsicht, du könntest Dich damit ganz schnell aussperren!).

Danke für dein Beitrag und entschuldige für die späte Rückmeldung, alles stressig zur Zeit.
Regel 1 und 2 funktionieren nicht. Ich bekomm vom Client aus dem pt10 Netz keine Verbindung auf den SQL im localhost. Als Fehler bekomm ich "Communications link failure"
 
Hast du das Subnetz entsprechend angepasst? In deinem Beitrag wird 172.18.0.0/16 genannt, in den iptables-Rules steht jedoch 178.18.0.0/16
 
MySQL auch entsprechend umkonfiguriert, dass er nicht mehr nur auf localhost bzw. 127.0.0.1 lauscht?
 
MySQL auch entsprechend umkonfiguriert, dass er nicht mehr nur auf localhost bzw. 127.0.0.1 lauscht?
Genau das geht leider nicht. Ich lese überall im Netz, dass man nicht auf mehreren IP´s binden kann.
Hast du da andere Informationen oder Vorgehendweise?
Benutzen tu ich ich MariaDB v10.3.23
 
Last edited:
Genau das geht leider nicht. Ich lese überall im Netz, dass man nicht auf mehreren IP´s binden kann.
Hast du da andere Informationen oder Vorgehendweise?
Benutzen tu ich ich MariaDB v10.3.23
https://mariadb.com/kb/en/server-system-variables/#bind_addresslocalhost durch 0.0.0.0 ersetzen. Dann ist der MySQL-Server auch von außen erreichbar und muss via iptables abgesichert werden.
Also Firewallregeln am besten vor der Konfigurationsänderung entsprechend einpflegen.
 
https://mariadb.com/kb/en/server-system-variables/#bind_addresslocalhost durch 0.0.0.0 ersetzen. Dann ist der MySQL-Server auch von außen erreichbar und muss via iptables abgesichert werden.
Also Firewallregeln am besten vor der Konfigurationsänderung entsprechend einpflegen.
Auf 0.0.0.0 lauscht der SQL aktuell und der/die Client´s können auch eine Verbindung aufbauen. 0.0.0.0 ist genau das Problem, ich würde das gerne aus Sicherheitsgründen auf localhost binden. Alle aktiven Benutzer sind zwar eingeschränkt, sprich root@localhost oder peter@172.18.0.% etc. Ebenso kann ich das Routing vom gesamten 172.18.0.0/16 Netz nicht umleiten, sondern nur Verbindungen die aus dem Subnetz kommen mit Port 3306. In diesem Subnetz laufen Docker Container, diese auch nach und von Außen kommunizieren.
Mit IP-Tables steh ich auf Kriegsfuß, deswegen benötige ich die Hilfe von euch.
Aktuell isses so, dass der SQL auf 0.0.0.0 lauscht und die Clients die im 172er Subnetz sind, Anfragen auf 172.18.0.1:3306 stellen.
 
Die iptables-Befehle oben lassen nur Zugriff zu, die über das Net-Interface pt10 kommen, das gibt es aber in deiner Konfig gar nicht. Das musst du entsprechend in den Befehlen anpassen.
 
Die iptables-Befehle oben lassen nur Zugriff zu, die über das Net-Interface pt10 kommen, das gibt es aber in deiner Konfig gar nicht. Das musst du entsprechend in den Befehlen anpassen.
Ja habe ich, ich hab das Interface beim testen richtig gestellt. Hab es falsch genannt im ersten Post
 
Vermutlich dürfte es bei dir auch reichen, wenn du nur die eingehenden Pakete auf Port 3306 auf deiner Netzwerkkarte blockst und das sollte mit einem Befehl zu erschlagen sein:
Code:
iptables -A INPUT -i enp0s3 -p tcp --dport 3306 -j REJECT
Und dann auch die 172.18.0.1 für die Verbindung zur Mariadb verwenden.
 
0.0.0.0 ist genau das Problem, ich würde das gerne aus Sicherheitsgründen auf localhost binden.
Dann mach das doch einfach, my.cnf:
Code:
[mysqld]
user                            = mysql
port                            = 3306
socket                          = /tmp/mysql.sock
bind-address                    = ::
Wo zum Teufel ist da das Problem und wozu muss man da mit IPTables rumpfuschen?
 
Dann mach das doch einfach, my.cnf:
Code:
[mysqld]
user                            = mysql
port                            = 3306
socket                          = /tmp/mysql.sock
bind-address                    = ::
Wo zum Teufel ist da das Problem und wozu muss man da mit IPTables rumpfuschen?
Danke für deinen Beitrag. Nur wird dieser nicht das gewünschte Ziel liefern. Lies bitte nochmal den ersten Post.
 
Blind aus der Hüfte geschossen, aka ungetestet:
In PF (FreeBSD) müsste es mit diesem Zweizeiler funktionieren, wenn die my.cnf auf :: bindet:
Code:
ext_if = "{ em0 }"

set skip on lo0
set debug urgent
set loginterface em0
set block-policy return
set optimization aggressive
set ruleset-optimization none
set state-policy if-bound
set hostid 10

scrub on $ext_if all no-df random-id max-mss 1440 fragment reassemble

block  in log       on $ext_if                  from any to any
pass   in     quick on $ext_if inet  proto tcp  from 172.18.0.0/16 port 3306 to 172.18.0.1 port 3306  modulate state
Für die Migration zu IPTables musst Du Dir jemanden anderes suchen...


Alternativ die my.cnf auf 172.18.0.1 binden und für localhost den Socket verwenden.
 
Blind aus der Hüfte geschossen, aka ungetestet:
In PF (FreeBSD) müsste es mit diesem Zweizeiler funktionieren, wenn die my.cnf auf :: bindet:
Code:
ext_if = "{ em0 }"

set skip on lo0
set debug urgent
set loginterface em0
set block-policy return
set optimization aggressive
set ruleset-optimization none
set state-policy if-bound
set hostid 10

scrub on $ext_if all no-df random-id max-mss 1440 fragment reassemble

block  in log       on $ext_if                  from any to any
pass   in     quick on $ext_if inet  proto tcp  from 172.18.0.0/16 port 3306 to 172.18.0.1 port 3306  modulate state
Für die Migration zu IPTables musst Du Dir jemanden anderes suchen...


Alternativ die my.cnf auf 172.18.0.1 binden und für localhost den Socket verwenden.
Teste ich heute Nachmittag. Danke!
 
Back
Top