Hallo,

ich versuche einen Suse-Server per iptables zu schuetzen, bzw. mit einigen wenigen Skriptzeilen das Teil save zu machen.
Leider nur mit beschraenktem Erfolg.
Die Regel für https funktioniert, d.h. nur aus einem bestimmten Subnetz kann man per https auf den Webserver zugreifen. SSH dagegen funktioniert nicht! Wenn ich das Skript über das Netz starte, trennt sich sofort die SSH Verbindung, und ein erneuter Verbindungsaufbau ist nicht mehr möglich, nur lokal kann ich es wieder abstellen. Das ICMP Filter funktioniert, der Server ist nicht aus em Inet ping-bar, aus dem lokalen Netz aber schon. So solls ja sein.
PS. die IP im Skript ist nur ein Beispiel!

Wo liegt der Fehler??

#! /bin/bash
iptables -F INPUT
iptables -F OUTPUT
iptables -F FORWARD

for i in INPUT OUTPUT
do iptables -P $i ACCEPT
done
for i in FORWARD
do iptables -P $i DROP
done
#1.Regel ssh , icmp und https Zugriff erlauben, fuer alle aus #dem Subnetz 136.52.234.0/24

iptables -A INPUT -p tcp -i eth0 -s 136.52.234.0/24 -d 136.52.234.6 --dport 22 -j ACCEPT
iptables -A INPUT -p tcp -i eth0 -s 136.52.234.0/24 -d 136.52.234.6 --dport 443 -j ACCEPT
iptables -A INPUT -p icmp -i eth0 -s 136.52.234.0/24 -d 136.52.234.6 -j ACCEPT

#2.Regel ALLES ANDERE verbieten

iptables - A INPUT -i eth0 -j DROP

Hi spacyfreak

Die Iptables-rules sehen für mich eigentlich i.O. aus.

Ist der sshd auch auf dem entsprechenden Interface (eth0) auf "listen"?

Mit einem "netstat -lnp" kannst du das überprüfen und in der "sshd_config" ändern falls nötig.

Eine andere Möglichkeit wäre noch das Routing... falls die Maschine z.B. zwei Interfaces hat. Dann müsste man das FORWARD entsprechend ändern.

Servus,
ich hab zwár ne zweite Netzwerkkarte, die hat aber ne private IP, und dient nur zur Datenbank-Replikation mit einem anderen identischen Server der direkt angeschlossen ist über Crossoverkabel.
Routing brauch ich also nicht.

Ich kapiers nich so ganz. Der ssh kakkt völlig ab. Selbst wenn ich dann den Befehl

iptables -F

lokal eingebe, gehts noch nicht. Ich muss die Kiste erst neustarten, dann geht ssh übers Netz wieder.
Irgendwo is der Wurm drin.

Lokal funktioniert ssh einwandfrei in dieser Situation? Oder geht das dann auch nicht mehr?

Was ist wenn du alle chains flushst? Also mit:
iptables --flush
iptables -t nat --flush
iptables -t mangle --flush

lokal gehts. iptables blockt ja nur was über eth0 will.

Ich hab bestimmt nen Script-fehler. Mich wundert halt, wiso die Regel für https und icmp funktioniert, aber die selbe für ssh nicht. very strange. naja, ich finds schon raus.

Jetzt geht das Firewall - Script wie ein geölter Blitz!
Hier isses (die IP-Adressen stimmen nicht mit dem wahren Leben überein)


#! /bin/bash

#Firewall Script

#1. Initialisieren alter Regeln

iptables -F -v
iptables -F -t nat -v
iptables -X

#2. Benötigte Module in den Kernel laden

modprobe ip-tables
modprobe iptable-nat
modprobe ipt-LOG

#3. Alles wird per default gedroppt

iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -P FORWARD DROP

#4. Interfaces definieren (erspart Tipp-Arbeit)

#Netzwerkkarte eth0 (privates Netzwerk fuer MySQL Replikation)
privat="192.168.0.1"

#Netzwerkkarte eth1 (LAN)
inside="145.55.5.5"

#Lokaler Horst (Horst im Lokal
localhost="127.0.0.1"

#Firmen-Netz
LAN="145.55.0.0/16"

##############################################

#Regel: ALLES erlauben auf privater eth0 das von und #zu 192.168.0.1 geht

iptables -A OUTPUT -i eth0 -s §privat -d 192.168.0.1 -j ACCEPT
iptables -A INPUT -i eth0 -s 192.168.0.1 -j ACCEPT

#Regel: Lokale Prozesse erlauben
iptables -OUTPUT -s $localhost -j ACCEPT
iptables -INPUT -s $localhost -j ACCEPT

#Regel:Erlaube https + ssh Zugriff auf Webserver für das lokale Netz

iptables -A INPUT -p tcp -i eth1 -s $LAN -d $inside --dport 443 -j ACCEPT
iptables -A INPUT -p tcp -i eth1 -s $LAn -d $inside --dport 22 -j ACCEPT

#Auch ausgehend muss erlaubt werden! Wir erlauben einfach alles ausgehende.

iptables -A OUTPUT -i eth1 -p tcp -j ACCEPT

#Neue Verbindungen zulassen

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

#Alles andere das reinwill wird gedropt

iptables -A INPUT -i eth1 -j DROP

#zur Ueberpruefung der Regeln, wird nach Ausfuehrung des Scripts
#iptables -L -n ausgefuehrt, das die Portbeschraenkungen anzeigt

echo "Die Firewall ist aktiviert! Folgende Regeln gelten:"

iptables -L -n
############################




Das ganze kann man entweder manuell ausführen, oder als Startskript automatisch starten lassen.

ausführbach machen mit

chmod 660 mein_firewallscript

###########################
Für automatischen Start beim Systemstart, zb. im Runlevel 3 (Multiuser ohne Grafik == typischer Server)

cp mein_firewallscript /etc/init.d
cd /etc/initd.d/rc3.d
Symbolischen Link ablegen, der auf das Script zeigt. Im rc3.d Ordner liegen lauter symbolische Links, die auf irgendwelche Startscripte zeigen. Die S32blablah stehen für "S"tartscript u. werden beim Start ausgeführt. Die Nummer zeigt die Reihenfolge. Scripte die später als andere gestartet werden sollen, bekommen eine höhere Nummer.

ln -s /etc/init.d/mein_firewallscript S18mein_firewallscript

Das ganze kann man auch mit dem Skeleton in /etc/init.d machen, und recht einfach in das "Skript-Skelet" die IPtables Anweisungen reingeben. Unter dem "Stop" abschnitt im Skelett dann die iptables - Deaktiverbefehle eingeben. Dann kann mit mit
/etc/init.d/mein_firewallscript start
und
/etc/init.d/mein_firewallscript stop

das starten und stoppen auch manuell durchführen.

Der Befehl insserv wertet die /init.d scripte aus und legt automatisch die symb. Links in rc3.d an. Dabei schaut insserv zb. auf die Eintragungen "Default Start 235" und startet dementsprechend in den Runlevels 2, 3 und 5 das Script.
Man kann es aber wie oben erwähnt auch selber machen mit dem symbolischen Link.

#############################

In welchem Runlevel das system überhaupt startet, macht man in der /etc/inittab klar. Einfach unter Runlevel eingeben. Default ist 5. Das ist multiuser mit Grafik. Da wir keine Graifk brauchen und es ein Server ist, ändern wir dies auf "3".
Beim Systemstart wird dann die inittab ausgewertet. Da dort die 3 steht, werden alle Startskripte aus /etc/init.d/rc3.d ausgeführt.

Hoi spacyfreak

Diesen Eintrag:

---schnipp---
#Alles andere das reinwill wird gedropt

iptables -A INPUT -i eth1 -j DROP
---schnipp---

kannst du dir ersparen, da du am Anfang mit

iptables -P INPUT DROP

schon grundsätzlich mal alles blockst.

Bei den folgenden beiden Einträgen fehlt glaube ich noch was

---schnipp---
#Regel: Lokale Prozesse erlauben
iptables -OUTPUT -s $localhost -j ACCEPT
iptables -INPUT -s $localhost -j ACCEPT
---schnipp---

entweder "iptables -A INPUT/OUTPUT bla bla" oder "iptables -I INPUT/OUTPUT bla bla"

Nun, wenn ich schon oben alles droppe, dürften ja auch meine darunterstehenden Regeln nicht mehr wirken, die bestimmte Dinge öffnen, da die Regeln von oben nach unten abgearbeitet werden. Sobald eine Regel zutrifft, wird die nächste nicht mehr angeguggt.

Naja, auf jeden Fall ist der Server so wie das Script ist, safe. Die notwendigen Ports sind offen, alles andere wird geblockt.

Du hast zwei Möglichkeiten die Firewall zu konfigurieren.
Entweder lässt du standardmässig mal alles zu
"iptables -P INPUT ACCEPT" und fängst dann an alles unötige zu blockieren.

Oder du blockst standardmässig alles "iptables -P INPUT DROP" und regelst dann was erlaubt ist. -> Ist viel die bessere Variante! (ist auch so in deinem Script)

Mit deinem Firewallscript bist du auf jeden Fall gut abgesichert - doppelt hält besser

Ok, verstehe.

Ja, in irgendner Hilfe hab ich gelesen, dass man mit
iptables -P INPUT (P steht für Policy) die INPUT-Kette erstmal auf DROP oder ACCEPT stellen kann.

Andererseits ist es doch so, dass prinzipiell (ähnlich wie auch bei MS RAS-Regeln oder Cisco ACLs) die Regeln von oben nach unten abgearbeitet werden. Wenn nun die erste Regel alles einkommende dropped, wiso werden dann die darunterstehenden Regeln dennoch ausgeführt?

Oder ist es so (weil es so sein muss) dass der Parameter -p eben die Default Einstellung tätigt, und die darunterstehenden Regeln dennoch zur Ausführung kommen? So muss es wohl sein.

Kanz schön gombliziert, diese Kombjuter-Dechnik!