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

!!Kann bei SuSEfirewall2 Ports nicht freigeben!!!

C

Chip@linux

Member
Hallo

Als ich Heute bei der Susefirewall2 die Ports TCP:6699 und UDP:6257 freigeben wollte, ging es nicht.. Obwohl ich die Ports in der SuSEfirewall2-Konfigurationsdatei hinzugefüght habe, will es nicht gehen. Als ich nach dem speichern der Konfigurationsdatei die Firewall per Console mit rcSuSEfirewall2 reload erneuern wollte, stand etwas von Phase 2 of 3. Ich weiss nicht, wo das Problem liegt.

Danke schon mal für die Antwort.[/quote]
 
OP
C

Chip@linux

Member
Bei :


#Common: smtp domain
FW_SERVICES_EXT_TCP="ftp ssh http smtp"

## Type: string
# Common: domain
FW_SERVICES_EXT_UDP=""
# Common: domain
 
G

gaw

Hacker
Dort legst du nur fest was von außen auf die Firewall zugreifen darf. Hattest du das beabsichtigt?

Oder sollten Clients aus dem Netz über die Firewall diese Portnummern im Internet ansprechen?


mfG
gaw
 
OP
C

Chip@linux

Member
Ich will, dass ich mit diesen Ports von meinen Clientpc's aus nach Aussen ins Web kommen kann und vom Web auf die Client's können. Brauche es für WinMX(Eine Tauschbörse wie Emule) und WinMX verwendet TCP:6699 und UDP:5672.
 
G

gaw

Hacker
Ach so, dann muss aber auch noch ein D-NAT eingesetzt werden. Das Problem ist, das ein Zugriff von außen immer nur die Adresse deines Routers sieht. Die Clients sind nicht sichtbar. Wenn also so ein Zugriff stattfinden soll zum Beispiel auf den Port 6699 muß er mit D-NAT umgeschrieben werden so dass er deinen Rechner erreicht.
Neben wir an deine Schnittstelle nach außen ist ppp0

/usr/sbin/iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 6699 -j DNAT --to 192.168.0.113

In diesem Fall würden die Aufrufe also über die Firewall nach 192.168.0.113 durchgreicht.


mfG
gaw
 
OP
C

Chip@linux

Member
Danke für deine Antwort.

Gibt es zu diesem Thema im SuSE Linux 9.1 Administrationsbuch etwas zum lesen, eine Anleitung oder so? Würde mich darüber gerne mehr informiernen mir "Port-forwarding".
 
OP
C

Chip@linux

Member
Noch ne Frage:

Wieso funktioniert das den mit dem Surfen, wenn ich mit 2 PC's gleichzeitig am surfen bin, geht das auch und das www braucht ja auch Port's. Wieso funktioniert das bei Progremmen die wie z.B. Port 6699 brauchen nicht? Noch was, wieso ist eine Hardwarefirewall oder Software(Norton Internet Security) fähig ohne konfigurieren, diese Pakete an die "richtige" IP umzuleiten?

Ich bin noch ein Linuxanfänger und kenne mich deshalb noch nicht sehr aus. Wo muss ich diese Zeile einfügen, damit ich en DNAT erstellen kann:

/usr/sbin/iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 6699 -j DNAT --to 192.168.0.113
 
G

gaw

Hacker
Chip@linux schrieb:
Noch ne Frage:

Wieso funktioniert das den mit dem Surfen, wenn ich mit 2 PC's gleichzeitig am surfen bin, geht das auch und das www braucht ja auch Port's. Wieso funktioniert das bei Progremmen die wie z.B. Port 6699 brauchen nicht? Noch was, wieso ist eine Hardwarefirewall oder Software(Norton Internet Security) fähig ohne konfigurieren, diese Pakete an die "richtige" IP umzuleiten?

Ich bin noch ein Linuxanfänger und kenne mich deshalb noch nicht sehr aus. Wo muss ich diese Zeile einfügen, damit ich en DNAT erstellen kann:

/usr/sbin/iptables -t nat -A PREROUTING -i ppp0 -p tcp --dport 6699 -j DNAT --to 192.168.0.113
Zum Vergrößern anklicken....


So viele Fragen auf einmal. Ich versuch mal das zu beantworten. TCP verwendet zwei Portnummern eine Zielportnummer und eine Quellportnummer. Diese Portnummern sind eine Art Adresse die es ermöglichen jedes Paket im Internet nicht nur hinsichtlich Quell- und Zielrechner sondern auch hinsichtlich einer ganz bestimmten Verbindung zwischen den beiden zu identifizieren. Daher ist es möglich zwischen 2 Rechnern mehrere unabhängige Verbindungen laufen zu lassen, zum Beispiel kannst du einen zweiten Browser öffnen und ohne Bedenken die gleiche Seite noch einmal öffnen. Läuft dort ein Java Programm sio wirst du erkennen das beide Verbindungen getrennt voneinander laufen.

Das bedeutet dass sie unterschieden werden müssen, TCP erreicht das indem jedes TCP-Segment eine Zielportnummer und eine Quellportnummer erhält. Nehmen wir an du öffnest einen Browser und wählst eine URL. Dann erfolgt der Verbindungsaufbau von deinem Rechner aus. Die TCP-Segmente zu einem Webserver irgendwo im Internet erhalten den Zielport 80 und eine zufällig ausgewählte Portnummer > 1024 die nicht mit vorhandenen Diensten auf deiner Maschine kollidiert (Dazu testet deine Maschine die freigegeben Portnummern in der Datei /etc/service).
Normalerweise ginge das von einem Rechner mit privater IP-Nummer gar nicht, weil die entprechenden Pakete im Internet nicht geroutet werden. Hier setzt nun Masquerading ein. Alle Pakete die von den Clients kommen erhalten als Quelladresse automatisch die offizielle IP-Adresse des Routers und können damit im Internet geroutet werden. iptables merkt sich an Hand der Portnummern zu welche Verbindung rücklaufende Pakete gehören und sendet sie an die Ursprungsadresse. Von außen sehen andere Rechner immer nur eine Adresse, die des Routers.
Wenn du zum Beispiel ein Webserver hinter dem Router im LAN stehen hast kann er von außen nicht gesehen werden. Es kann auch keine Automatik geben, weil du könntest zum Beispiel mehrere Webserver hinter dem Router am Laufen haben. Wenn nun jemand einen solchen Webserver von außen erreichen will, gibt es ein Problem. Er kennt nur die offizielle Adresse des Routers und der TCP-Verbindungsaufbau von außen erfolgt auf den Zielport 80 des Routers. Es gibt nun die Möglichkeit auf dem Router einen Proxy zu installieren der auf http-Ebene die richtigen Seiten von dem oder von mehreren Webserver holt. Ein Proxy erwartet aber bestimmte Ressourcen.

Auf Paketebene, eben das was sich mit einem Paketfilter wie iptables konfigurieren läßt muß die Anweisung eindeutig sein. Dass heißt du musst ihm schon sagen wohin er Anfragen von außen an den Netz weiterleiten muss. Das gilt für jeden Paketfilter. Ansonsten benötigst du einen Proxy oder relay Agent der die Inhalte der Pakete analysiert.

Das erklärt auch warum manche Firewall Verbindungen anders behandeln. Der Begriff Hardwarefirewall ist übrigens irreführend, meistens werkelt ein gewöhnliches Linux auf einem solchen Router und iptables arbeitet als Paketfilter im Hintergrund. Ob weitere Relayagenten oder Proxiees auf einer solchen Firewall arbeiten hängt vom Hersteller ab. Auf den meisten Firewall muss du allerdings DNAT Anweisungen in der ein oder anderen Form aktivieren.

Die DNAT- Anweisungen mit iptables kannst du als root in einer shell ausführen zum Beispiel in einem xterm oder in einer konsole. Du kannst sie natürlich auch in einem Skript packen und bei Bedarf starten oder in ein Customfile der SuSEFirewall packen. Wichtig ist im Zusammenhang mit der SuSEfirewall, dass sie nach dem Einschalten der Firewall ausgeführt werden. ( passiert im Custom File automatisch).

Ich hoffe ich konnte die wichtigsten Fragen klären, ansonsten empfehle ich ein gutes Buch über das TCP-Protokoll.


mfG
gaw
 
OP
C

Chip@linux

Member
Danke, für die sehr ausführliche Antwort. Du hast mir damit geholfen. Also etwas ist mir immer noch nicht klar. Wenn ich iptables-anweisungen als Skript mache, wo muss ich das speichern und wie mache ich den link zur firewall?Und wie erstelle ich so ein Customfile?

greez Chip
 
G

gaw

Hacker
Es ist eigentlich gleichgültig wo das Skript gespeichert wird. Es muss nur von demjenigen der es aufruft erreichbar sein, d.h. die Umgebungsvariable PATH muss das Verzeichnis enthalten in dem sich das Skript befindet.
Nennen wir das Skript dnatscript. Der Kopf des Skriptes sieht dann so aus:
Code: 
#/bin/sh

# Hier folgt die iptables Anweisung
/us/bin/iptables ....
Mit chmod 700 dnatscript wird das Skript nur für den Besitzer (sollte root sein) lauffähig.

Soll es automatisch starten kann man es nach /etc/init.d/ kopieren und in /etc/init.d/rc3.d und /etc/init.d/rc5.d/ jeweils ein link setzen:
ln -s ../dnatscript S100dnatscript

Die Zahl 100 bewirkt dass das Skript auf jeden Fall nach dem Start der SuSEfirewall aktiviert wird.

Eine Alternative dazu ist es ein customary file der SuSEfirewall zu verwenden. Dazu muß der Pfad in die Variable FW_CUSTOMRULES in /etc/sysconfig/SuSEfirewall2 eingetragen werden beispielsweise:
Code: 
FW_CUSTOMRULES="/etc/sysconfig/scripts/SuSEfirewall2-custom"

Und in diese Datei schreibst du dann die iptables Anweisungen. Dort stehen schon Kommentare und Beispiele. Du kannst aber eine neue Datei nehmen, dass ist dir überlassen. Nur der Pfad und der Dateiname muss eben mit dem Eintrag in FW_CUSTOMRULES übereinstimmen.


mfG
gaw
 
G

gaw

Hacker
Das war ein Tippfehler, es soll
Code: 
/usr/bin/iptables

lauten. Es ist besser in Skripten die Programme mit Pfad aufzurufen. So wird ein Skript unabhängig von Pfadeinstellungen. Eine andere Möglichkeit, die auch oft angewendet wird, besteht darin, den Pfad+Programmname in eine Variable zu setzen. So muss bei Änderungen nur die Variable angepaßt werden.

Code: 
....
IPTABLES=/usr/bin/iptables

#

$IPTABLES -A INPUT......


mfG
gaw
 
OP
C

Chip@linux

Member
Hallo

Ich habe es mit dem "Custumary File" versucht, aber dort gibt es unterschiedlichr Bereiche und ich habe keine Ahnung in welchen Bereich ich es schreiben muss.

Danke für die Antwort. Bin halt no ein n8b unter Linux(leider)

Greez: Chip
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben