iptables, Regeln beim starten laden, richtig so?

D

Domi

Member
Hallöchen Leute...
Gestern fragte ich, wie ich meinen MySQL Server nach außen hin offen machen kann, aber auch nur für bestimmte IP Adressen. Als Tipp sagte man dann, dass ich "bind adress" für alle öffnen könnte, davor solle ich aber die Firewall richtig konfigurieren.

Gut, in der Schule hatten wir im Kurs für Netzwerktechnik etc. mal mit "iptables" gearbeitet, also habe ich mich da noch mal ein wenig belesen. Ich habe einen vServer zum testen, da ist nichts drauf und der wird regelmäßig neu installiert :D

Meine erste Amtshandlung war erst mal, dass ich mich selbst aussperrte :D
-> iptables -P INPUT DROP

Gut dachte ich mir, also neu installiert und noch mal versucht...
1. iptables -F
2. iptables -P INPUT DROP;iptables -A INPUT -p tcp --dport 3729 -j ACCEPT

Das ist der Port für mein SSH, hat auch geklappt und die Verbindung stand. Blöd war nur, dass ich dachte das er mit iptables -F auch die policy zurück setzt. Also noch mal neu installiert, da ich ja "policy = drop" hatte und mit iptables -F alles gelöscht hatte. Also war bei mir schon mal "Vorsicht" angesagt :)

Alle Regeln wieder eingetragen, geschaut und gefreut. Nach einem Reboot war natürlich alles weg, also weiter gelesen... Ich bin jetzt wie folgt vor gegangen und hoffe das es richtig war, denn da bin ich mir nicht 100% sicher.

1. Regeln festgelegt...
- iptables -F
- iptables -A INPUT -p tcp --dport 3729 -j ACCEPT
- iptables -P INPUT DROP

2. Regeln gesichert...
- mkdir /var/lib/iptables
- iptables-save > /var/lib/iptables/rules (hab die Datei auch so angelegt)

3. Restore Skript erstellt "/etc/init.d/iptables-restore"
Code: 
#! /bin/sh
### BEGIN INIT INFO
# Provides:          iptables-restore
# Required-Start:
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
# Short-Description: Wiederherstellen der IP Tables
# Description:
### END INIT INFO

# Author: xxxx
iptables-restore < /var/lib/iptables/rules

Anschließend habe ich im Ubuntu-Wiki gelesen das man mit "update-rc.d" die Dienste in die Runlevel bringen kann, also führte ich folgenden Befehl aus und bekam dann folgendes zurück,
Code: 
root@s05 ~ # update-rc.d iptables-restore defaults
update-rc.d: using dependency based boot sequencing
mein englisch ist nicht so der Brenner, aber ist die Meldung jetzt gut? Wenn ich das richtig verstanden habe, geht es da um eine Abhängigkeit oder so etwas :o

Vor allem, es handelt sich ja um eine Netzwerkaufgabe, und nun steht der Dienst in allen rc.d Ordnern... :confused:
Code: 
root@s05 ~ # ls -l /etc/rc2.d/
total 4.0K
-rw-r--r-- 1 root root 677 Jan  1  2011 README
lrwxrwxrwx 1 root root  26 Nov 24 11:56 S01iptables-restore -> ../init.d/iptables-restore
lrwxrwxrwx 1 root root  17 Nov 24 10:57 S01rsyslog -> ../init.d/rsyslog
lrwxrwxrwx 1 root root  15 Nov 24 10:57 S02acpid -> ../init.d/acpid
.......
Ist das jetzt richtig, oder war das schlecht?

Mfg. Anubis
 
Das mit dem "Networking" klingt schon mal nicht verkehrt...
Ich hatte auch erst im Nachhinein gelesen, dass die ersten Zeilen auch benötigt werden und Daten übergeben. Ich wollte das nämlich erst ganz leer lassen :)

Das iptables nach einem Neustart dann die Daten verworfen hat, wusste ich allerdings auch erst nach dem zweiten oder dritten re-initialisieren :D

Was mir gestern noch ein Bekannter ans Herz gelegt hatte war REJECT, er wies mich darauf hin, dass ich statt DROP ein REJECT einbauen sollte. Somit hab ich dann noch mal ein wenig geknobelt, und mir dann folgendes zusammen gebaut.
Code: 
# Generated by iptables-save v1.4.8 on Fri Nov 25 09:48:39 2011
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [820:75162]
-A INPUT -i lo -j ACCEPT
-A INPUT -i eth0 -p tcp -m tcp --dport 3729 -j ACCEPT
-A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -j REJECT --reject-with icmp-port-unreachable
COMMIT
Local hab ich alles erlaubt, damit die Dienste untereinander (Server-Intern) miteinander arbeiten können, 3729 ist mein SSH, den Parameter mit RELATED habe ich angelegt damit er mir bei aktiven Verbindungen auch etwas rein lässt (z.B. Aptitude, dass funktionierte ohne den Parameter nicht) und ganz ans Ende halt meine REJECT Policy :)

Gibt es eigentlich eine bestimmte Anzahl die man in die Kette INPUT packen darf / kann? Wenn ich hinterher Apache darauf laufen lasse, muss ich ja noch mehr Ports öffnen..
 
Okay, also ist das REJECT für einen root-Server oder v-Server ehr eine schlechte Wahl. Dann lieber einfach DROP machen und fertig ist der Spaß...

Ich vermute mal, dann sollte man ICMP auch komplett blocken, außer man will den Server von einer bestimmten IP ansprechen können... Oder?
 
Zunächst zeigt ein DROP dem potentiellen Angreifer direkt, dass bei Dir ein Paketfilter läuft. Desweiteren ist es absoluter Schwachsinn auf ohnehin ungenutzten Ports mit einem Paketfilter zu lauschen um dann damit ein REJECT/DROP abzusondern und die Pakete dadurch unnötigen Code durchlaufen zu lassen. Das macht der Kernel von Hause aus ganz ohne Paketfilter deutlich effizienter...

Aber das ist ein uraltes Thema und auch im SSF zu genüge ausdiskutiert, SUFU hilft...
 
Joe User said:
Desweiteren ist es absoluter Schwachsinn auf ohnehin ungenutzten Ports mit einem Paketfilter zu lauschen um dann damit ein REJECT/DROP abzusondern und die Pakete dadurch unnötigen Code durchlaufen zu lassen. Das macht der Kernel von Hause aus ganz ohne Paketfilter deutlich effizienter...
Click to expand...
Rein von dieser Aussage her, würde ich daraus schließen, dass man INPUT ACCEPT setzen könnte, da der Kernel das ja selbst ganz gut handeln kann. Einzige zusätzliche Regel die man sich anlegen könnte, wäre dann eine für mein MySQLd der Zugriffe auf Port 3306 nur von IP X und Y erlaubt und anschließend alles dicht macht. Richtig?
 
Nix INPUT ACCEPT, sondern ausschliesslich die Regel(n) für den MySQL-Port definieren, nothing more nothing less. Den Rest übernimmt der Kernel OOTB.

BTW: Selbst auf die Regeln für MySQL und damit komplett auf den Paketfilter würde ich persönlich verzichten und stattdessen das Ganze per VPN abfrühstücken.
 
Joe User said:
BTW: Selbst auf die Regeln für MySQL und damit komplett auf den Paketfilter würde ich persönlich verzichten und stattdessen das Ganze per VPN abfrühstücken.
Click to expand...
Geht nicht! Warum? Weil all-inkl Server für mich kein root oder ähnliches bereit halten / stellen ;)

Warum haben wir noch Domains bei anderen hostern als auf unseren vServern? Chef will das so!

Joe User said:
Nix INPUT ACCEPT, sondern ausschliesslich die Regel(n) für den MySQL-Port definieren, nothing more nothing less.
Click to expand...
Und hier bin ich total verwirrt.. Nenn mir mal bitte ein Beispiel WIE Du das jetzt genau meinst :o
 
Du erlaubst auf dem MySQL-Port nur Verbindungen von Deinen anderen Servern und der Rest der Welt bekommt auf diesem Port einen schlichten REJECT, fertig.
Um die anderen Ports lässt Du sich den Kernel kümmern.

Also nur eine Zeile mit "INPUT ACCEPT from Remotesystem on MySQL-Port" und darauf folgend eine Zeile mit "INPUT REJECT from All on MySQL-Port", fertig. Die exakte Syntax entnimmst Du bitte der Dokumentation Deines Paketfilters.

BTW: Seit wann darf eigentlich non-root am Paketfilter schrauben?
 
Joe User said:
Du erlaubst auf dem MySQL-Port nur Verbindungen von Deinen anderen Servern und der Rest der Welt bekommt auf diesem Port einen schlichten REJECT, fertig.
Click to expand...
Ich vermute mal, Du meinst so etwas...?
Code: 
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [820:75162]
-A INPUT -i eth0 -s xx.xx.xx.xx -p tcp --dport 3306 -j ACCEPT
-A INPUT -i eth0 -p tcp --dport 3306 -j REJECT --reject-with icmp-port-unreachable

Joe User said:
BTW: Seit wann darf eigentlich non-root am Paketfilter schrauben?
Click to expand...
Ich habe nie gesagt das ich von dem Server wo ich nicht root bin, einen Port öffnen will. Wir haben Webspace bei all-inkl und zwei anderen Hostern, dazu kommt das wir zwei vServer besitzen. Der eine ist zur Zeit mein Test-System! Auf diesem Test-System möchte ich 3306 für die anderen IPs frei schalten ;)
 
Dir ist aber schon bewust, daß die Webseiten, die auf eine MySQL-Datenbank bei einem anderen Hoster zugreifen u.U. sehr langsam werden?
 
Joe User said:
Las sich etwas anders ;)
Click to expand...
Schande über mein Haupt... Das wollte ich allerdings nicht bezwecken... :o

danton said:
Dir ist aber schon bewust, daß die Webseiten, die auf eine MySQL-Datenbank bei einem anderen Hoster zugreifen u.U. sehr langsam werden?
Click to expand...
Joa, hängt halt von der Leistung, der Anbindung und dem Routing ab. Oder irre ich mich da jetzt? Aber sonst im Prinzip ist es mir klar.. Es nützt mir nichts keine Geschwindigkeitsbegrenzung auf der Autobahn zu haben, wenn ich nur 100Km/h fahren kann ;) (hoffe das war / ist zutreffend)

Joe User said:
Zudem ist fraglich, ob der Webhoster überhaupt Socketverbindungen nach Aussen erlaubt.
Click to expand...
Jou, hab das schon ausprobiert... der vServer steht bei Hetzner und der Webspace ist bei all-inkl gebucht. Die Datenbank würde ich dann auf dem Hetzner-System laufen lassen, und den Webspace über all-inkl. So könnte ich dann von mehreren Domains auf den gleichen Datenbestand zugreifen :)

Ich hab auch schon an ein Sync oder so etwas gedacht, aber das ist dann doof... Der Sync müsste
a. in Live-Time sein
b. Kollisionen durch vielleicht existierende IDs vermeiden
 
You must log in or register to reply here.
Back
Top