Bin zu blöd für ipchains

Folgendes Problem:

LAN: 192.168.10.0/24
Router:
eth0: => Zugang zum Web
eth1: => Zugang zum LAN
--
ipchains -A -s 192.168.10.0/24 -d ! 192.168.10.0/24 -j MASQ

Chain input (policy DENY)
Chain forward (policy DENY)
Chain output (policy ACCEPT)
____

Soviel zu den angegebenen Chains und Einstellungen...

ipchains -A input -s 0.0.0.0/0 -d 0.0.0.0/0 -p all -j ACCEPT
=> klar, erlaubt den Zugriff von allen auf alles (also auch auf's Web)

warum kann ich dann bei

ipchains -A input -s 192.168.10.13 -d 0.0.0.0/0 -p all -j ACCEPT

nicht auf's Web vom Rechner 192.168.10.13 zugreifen?

TIA X_FISH

Kurze Frage.

Was Passiert mit den Paketen die zurückkommen?

Sie werden Rausgefiltert http://www.linuxforen.de/ubb/smile.gif

Du brauchst noch folgende Zeile:

ipchains -A input -d 192.168.10.13 -j ACCEPT

Du kannst übrigens -s und -p weglassen weil dann angenommen wird das alles gilt!

Bis Bald

Henning Wackernagel

Ich möchte noch kurz eine Erleuterung anbringen:

Warum bekommt man bei

ipchains -A input -s 0.0.0.0/0 -d 0.0.0.0/0 -p all -j ACCEPT

immer eine verbindung?

Das liegt daran das es egal ist welche Adresse als Sourc und als Dest angegeben sind.

Bei der Regel

ipchains -A input -s 192.168.10.13 -d 0.0.0.0/0 -p all -j ACCEPT

sieht es anders aus.

Die Pakete von 192.168.10.13 gehen zwar raus aber wenn die Antwort von dem anderen Rechner kommt ist die Adresse 192.168.10.13 nicht mehr Sourc sondern Dest und damit stimmt die Regel nicht mehr und das Paket wird mit der Policy einfach nach /dev/null geschickt, in das grosse Datennirvana!

Bedenke immer eins wenn du Firewallregeln machst:

- Meistens will man auch eine Antwort haben.

Diese Fehler habe ich am anfang ständig gemacht!

Ich empfehle dir noch die Regeln Devicespezifisch (eth0, eth1) zu machen da es IMHO einfacher ist die Regeln später zu verstehen!

Bis Bald

Henning Wackernagel

THX - An die Antworten habe ich natürlich nicht gedacht *grummel*

CU X_FISH

Tscha - jetzt hat mir einer 'nen Link gegeben: http://www.packetfilter.amotken.com/doit/ .

Da kann man sich ein Script schreiben lassen. Finde ich ganz klasse, vorallem kann ich mir jetzt anschauen wie's funktioniert. Ist gut dokumentiert (im Script selbst).

Dafür habe ich jetzt gleich wieder ein neues Problemchen bekommen: Bei SuSE sind ja die Startdateien woanders... In welches File darf ich denn nun meinen Script-Aufruf einbauen? die /sbin/init.d/boot.local war zu früh, da bekomme ich 'n paar Fehlermeldungen ausgegeben das es nicht mit den ipchains so wollte wie es sollte. Führe ich das Script nachträglich von Hand aus klappt's.

TIA X_FISH

hi,

Schreib sie bei Suse unter /sbin/init.d und bei RedHat unter /etc/rc.d/init.d!

(Dies gilt jetzt für RedHat aber Suse müsste ähnlich sein)

Danach machst du einen Link in das verzeichnis /etc/rc.d/rc3.d von deinem Skript mit einem S und zwei Nummer vorangestellt z.B. S66firwall. Das S bedeutet das es gestartet werden soll und die Nummer an welcher stelle. Es ist zu empfehlen das es noch vor der Initialisierung des Netzwerkes gestartet wird!

Bis Bald

Henning Wackernagel

P.S: Es klingt ein bischen kompliziert, ist aber einfach wenn man es versteht.

Ich habe mir gerade den Skriptgenerator angeschaut. Es ist nicht schlecht doch habe ich auch einiges beim ersten durchlesen gefunden was mir nicht gefällt:

1. Spoofing Protektion

Hat man eine Internet Anschluss reicht es nicht aus nur nach seiner eigenen Adresse zu schauen. Grundsätzlich sollte man auch alle anderen Privaten Adressräume filtern. Dazu gehören:

10.x.x.x/8
192.168.x.x/16
172.16.0.0/12
und das loopback 127.x.x.x/8

2. ICMP Pakete

Es ist genau zu prüfen ob man ICMP Pakete Rauslassen sollte. Hat man z.B Keinen Dienst in seinem Netzwerk Sollte man keine ICMP Pakete rauslassen aber ICMP aus dem Internet sollten nach innen Passieren dürfen.

Sonst sollte man achten welche ICMP Pakete rein oder raus lässt.

Ganz besonders sollte man möglichst keine echo-replay rauslassen oder echo-request reinlassen (nur wenn es wirklich nötig ist und dann auch nur sehr strikt, also mit Sourc und Destinationadresse). Pings sind meist die Vorstufe zu einem Angriff (meine Erfahrung).

Manche Tools die Rechner nach einer Schwachstelle durchsuchen versuchen erst gar nicht ihre Angriffe gegen den Rechner wenn sie keinen Ping erfolgreich machen können (kann man aber meist ausschalten!).

3. Manche der Dienste sollten stränger kontrolliert werden.

Z.B SSH, Meist weis man von welchem Rechner man eine SSH verbindung aufbauen will. Darum sollte man Explizit die Source und Destinationadresse angeben.

Dies sind nur 3 Beispiele die ich an diesem Skriptgenerator bemängle. Darum schreibe ich meine Skripts immer von Hand.

Zum lernen ist der Generator aber nicht schlecht da er einige Erklärungen gibt.

Bis Bald

Henning Wackernagel

Hm. Klingt kompliziert, und wenn man's glaubt kapiert zu haben war's doch nicht so...

in /sbin/init.d/rc3.d habe ich folgenden Befehl gemacht:

ln -s /sbin/init.d/firewall_ms S66firewall_ms

sah dann auch ganz gut aus, aber beim Booten hat sich nix getan von wegen das das Script ausgeführt wird. Die ipchains sind leer, also bei -L steht nix drin. Auch bei der BS-Ausgabe werden die Befehle nirgends ausgegeben - ich konnte aber auch keine Fehlermeldung entdecken.

Im Forum habe ich dann noch entdeckt das andere auch mit K99... zusätzlich zu dem S99... linken. Was bedeuten diese Ks und Sse? Gibt's da irgendwo Lektüre bei SuSE oder so? Konnte leider nix finden, aber vielleicht habe ich ja auch nur falsch gesucht...

TIA X_FISH

[Dieser Beitrag wurde von X_FISH am 11. Oktober 2000 editiert.]

hiho,

K bedeutet Kill!

Schau doch bitte mal nach unter runlevel du hast.

Die Runlevel sind leider unter jeder Distri ein wenig verschieden.
Die Runlevel kannst du dir unter inittab anschauen.

Unter RedHat ist Runlevel
0 Halt
1 Singel User Mode
2 MultiUser Mode ohne NFS
3 Voller MultiUser Mode
4 Nicht benutzt
5 X11 Mode
6 Reboot

Falls dein Rechner Mit X11 Startet dann solltest du das Skript (hier bei RedHat) unter /etc/rc.d/rc5.d Linken!

Sorry, Hab ich dir oben vergessen zu sagen!

Sollte auch unter Suse so funktionieren.

Bis Bald

Henning Wackernagel

0 is halt
1 is multi-user without network
2 is multi-user with network
3 is multi-user with network and xdm
6 is reboot
S is singleuser

=> dann muß ich den symbolischen Link also in das RLevel 2 packen?

Ich probier's einfach mal! X11 ist nicht auf dem Rechner, der soll ja nur routen - und hat einen ganz kleinen Monitor der einem das X nicht wirklich schmackhaft machen würde ;o)

THX vorab, X_FISH

Bingo! Hat geklappt!

Jetzt stehe ich dann nur noch auf dem Schlauch was es die »ICMP Pakete« pakete sind. Ich habe irgendwo in der SuSE Datenbank was gefunden das man (bei einer älteren Version) das Linux damit abschmieren lassen konnte (oder so)...

CU X_FISH

ICMP ist Internet Control Message Protocol.

es ist auf der gleichen Ebene wie IP und ist dazu da das sich Rechner Nachrichten zuschieben können.

Z.B:
- Echo Request #Wird geschickt wenn du ein ping auf einen Rechner machst
- Echo Response #Ist die Antwort des anderen Rechners
- Time Exceeded #Wenn ein Packet looped
- Destination unreachable #Das bekommst du wenn du versuchst einen Rechner zu erreichen den man nicht ereichen kann weil z.B ein Router ausgefallen ist.
usw.

Gib mal folgendes Kommando ein:

ipchains -h ICMP

Dann bekommst du eine Liste aller ICMP Typen.

Diese ICMP-Pakete sind zum teil wichtig aber sie veraten auch viel ueber dein Netzwerk.

Bis Bald

Henning Wackernagel

[blackbird]

hi!

wenn du ICMP-Pakete blocken willst, solltest du nur typ echo und echo-reply blocken, die andren sollten auf alle fälle bleiben. insbesondre source-quench (ists richtig geschrieben? egal..) wenn du das rausnimmst, kannst du recht schnell probleme mit deiner internetverbindung bekommen.. (verlorene pakete etc..)

grüsse blackbird

»echo-request« und »echo-reply« sind das dann wohl. Ich habe beide in dem Script auskommentiert - bis jetzt scheint noch alles zu gehen.

Jetzt habe ich aber noch eine Verständnisfrage: -A input und -A output. Ich habe mir gedacht wenn da output steht wird's auch nur das sein was der Rechner rausschicken will, also Antworten und sowas. In dem Script wird aber immer -A input und -A output freigegeben:

--- schnipp ---

ipchains --append input \
--jump ACCEPT \
--protocol icmp \
--icmp-type echo-reply

ipchains --append output \
--jump ACCEPT \
--protocol icmp \
--icmp-type echo-reply

--- schnapp ---

Demnach habe ich das wohl irgendwie falsch interpretiert...

TIA X_FISH

Hi,

die Netzpakete laufen alle durch den Kernel, wo sie auf die ipchainsregeln treffen. INPUT,FORWARD,OUTPUT ist der Weg, den jedes Paket im Kernel nimmt. Das Ganze hat also nichts mit senden/empfangen zu tun.

Wenn du mehr wissen willst schau doch mal in c't 17/1999 (falls zur Hand).

Gruß

F1B

Leider habe ich hier nur c'ts ab 7/2000...
Aber ich guck nochmal im Web ob ich 'ne gute Page zu dem Thema finde...

THX X_FISH

Habe was gefunden:
http://www.firmen-info.de/firewall/zusammen-52.html

Aber: Demnach ist's doch wieder mit wie ich es mir gedacht habe: input kommt rein, output geht raus. Vermutlich wird das erst so richtig interessant bzw. wichtig wenn ich den Traffic über mehrere bzw. bestimmte Netzwerkkarten leite. Quasi den Ping von eth0 nur nach eth1 rauslassen möchte (blödes Beispiel, ich weiß). Also für Umleitungen wie auf einen Webserver der hinter der Firewall steht oder so (besseres Beispiel für die Anwendung?)

CU X_FISH (leicht irritiert - wie immer halt)

hi,

Es wird erst richtig Spassig wenn du 4 Netzwerkkarten hast so wie ich hier bei unserer Firewall!

Bis Bald

Henning Wackernagel