Merkwürdiges Verhalten der Firewall
Hi Folks, seit Kurzem benutze ich nun auch eine Firewall auf meiner Kiste (Suse 9.3). Eingerichtet habe ich diese Firewall mit GUARDDOG. Das klappt auch soweit sehr gut. Allerdings habe ich ein kleines Problem. Ich habe ein kleines selbst geschriebenes Proggi, welches an einem Port xyz lauscht. Diesen Port habe ich auch in GUARDDOG freigegeben. Dabei ist zu bemerken, dass dieses Proggi irgend wann im Laufe des Tages von mir "per Hand" (je nach Bedarf) gestartet wird,. Also nicht beim Start des Rechners. Starte ich dann also dieses Programm, dann ist der Port "zu". Es wird nichts darauf empfangen. Ich muss "händisch" nochmals /etc/rc.firewall starten, dann funzt es. Ist aber doch recht umständlich - und bestimmt nicht so vorgesehen, oder? Was muss ich wo, wie ändern, damit alles wie gewünscht funktioniert? Thx Timotrhy -- "Es gibt zwei Dinge im Leben, die du nicht zurücknehmen kannst: Den Pfeil den du verschossen und das Wort, das du gesprochen" - altes indianisches Sprichwort
Timothy Kesten schrieb:
Ich muss "händisch" nochmals /etc/rc.firewall starten, dann funzt es. Ist aber doch recht umständlich - und bestimmt nicht so vorgesehen, oder? Was muss ich wo, wie ändern, damit alles wie gewünscht funktioniert?
Hallo Timothy! anderer Rechner, ähnliches Problem! Mein Problem ist mit Samba und Apache! Ich mache Freigaben und einen Apache an, die anderen sollen zugreifen. Das funktioniert erst nach einem rcSuSEFirewall2 restart. Aber nur nach einem Neustart des Systems. Wenn ich erstmal das rcSuseFirewall restart gemacht habe, macht ein Neustart der jeweiligen Dienste keine Probleme mehr. Woran es liegt, steht wohl in den Sternen. Gibt es da Lösungsansätze? Hat jemand ein ähnliches Problem? Grüße Martin Ereth
Hallo, Timothy Kesten, 4.12.2005 21:17:
Hi Folks,
seit Kurzem benutze ich nun auch eine Firewall auf meiner Kiste (Suse 9.3). Eingerichtet habe ich diese Firewall mit GUARDDOG. Das klappt auch soweit sehr gut. Allerdings habe ich ein kleines Problem. Ich habe ein kleines selbst geschriebenes Proggi, welches an einem Port xyz lauscht. Diesen Port habe ich auch in GUARDDOG freigegeben. Dabei ist zu bemerken, dass dieses Proggi irgend wann im Laufe des Tages von mir "per Hand" (je nach Bedarf) gestartet wird,. Also nicht beim Start des Rechners. Starte ich dann also dieses Programm, dann ist der Port "zu". Es wird nichts darauf empfangen. Ich muss "händisch" nochmals /etc/rc.firewall starten, dann funzt es. Ist aber doch recht umständlich - und bestimmt nicht so vorgesehen, oder? Was muss ich wo, wie ändern, damit alles wie gewünscht funktioniert?
Zwei Fragen: 1) Wie hast du den Port freigegeben? 2) Hast du auch das Protokoll aktiviert, das dein Programm zum Lauschen an einem Port verwendet? Gruß Kimmo
Am Sonntag, 4. Dezember 2005 21:17 schrieb K. Elo:
Zwei Fragen: 1) Wie hast du den Port freigegeben? Wie meinst du das?
2) Hast du auch das Protokoll aktiviert, das dein Programm zum Lauschen an einem Port verwendet? Klar doch. Unter Advanced ein neues Protokoll erstellt. Typ: TCP Range: 17500 - 17500
Unter Internet das "neue Protokoll" lokal freigegeben (zugelassen). Timothy -- "Es gibt zwei Dinge im Leben, die du nicht zurücknehmen kannst: Den Pfeil den du verschossen und das Wort, das du gesprochen" - altes indianisches Sprichwort
Hi Folks, also: Alles gaaaanz anders ;-) Nur einfach, ohne Hintergründe zu kennen eine GUI zu verwenden ist auch nicht das Richtige. ;-) Guarddog erlaubt (wohl) kein bidirektionalen Einstellungen (jedenfalls habe ich bisher nichts dazu gefunden). Mein Proggi auf Port 17500 kann zwar senden, aber nicht empfangen. Wenn ich die entsprechende Regel in die von Guarddog erstellte rc.firewall "per Hand" hinzufüge, dann klappt alles so, wie ich es mir vorstelle. Jetzt habe ich mich im Netz ein bißchen "belesen" und verstehe auch ein paar Dinge - zwar noch nicht vollständig - aber immerhin. Und der Rest wird auch noch kommen. Bis denne Timothy -- "Es gibt zwei Dinge im Leben, die du nicht zurücknehmen kannst: Den Pfeil den du verschossen und das Wort, das du gesprochen" - altes indianisches Sprichwort
Hallo nochmals, Timothy Kesten, 4.12.2005 22:26:
Am Sonntag, 4. Dezember 2005 21:17 schrieb K. Elo:
Zwei Fragen: 1) Wie hast du den Port freigegeben?
Wie meinst du das?
S.u.
2) Hast du auch das Protokoll aktiviert, das dein Programm zum Lauschen an einem Port verwendet?
Klar doch. Unter Advanced ein neues Protokoll erstellt. Typ: TCP Range: 17500 - 17500
Das ist die Antwort auf die Frag Nr. 1 :) Hier hast du den Port 17500 geöffnet.
Unter Internet das "neue Protokoll" lokal freigegeben (zugelassen).
Aber damit kann dein Programm nur aus dem Interner empfangen aber noch nichts senden. Du muss das Protokoll in _beide_ Richtungen erlauben (local->internet, internet->local), um erfolgreich am Port lauschen zu können. Hatte mal ein ähnliches Problem mit NFS und GD. Gruß Kimmo
Am Montag, 5. Dezember 2005 18:00 schrieb K. Elo:
Unter Internet das "neue Protokoll" lokal freigegeben (zugelassen).
Aber damit kann dein Programm nur aus dem Interner empfangen aber noch nichts senden. Du muss das Protokoll in _beide_ Richtungen erlauben (local->internet, internet->local), um erfolgreich am Port lauschen zu können. Hatte mal ein ähnliches Problem mit NFS und GD. Okay - habe ich getan:
# "Internet" -> "lokal" iptables -A f0to1 -p tcp --sport 0:65535 --dport 17500:17500 -m state --state NEW -j ACCEPT # "lokal" -> "Internet" iptables -A f1to0 -p tcp --sport 0:65535 --dport 17500:17500 -m state --state NEW -j ACCEPT Klappt aber trotzdem nicht. Ein Test des Ports über http://grc.com/default.htm bringt (mein Proggi "lauscht" bereits) GRC Port Authority Report created on UTC: 2005-12-05 at 18:13:10 Results from probe of port: 17500 0 Ports Open 0 Ports Closed 1 Ports Stealth --------------------- 1 Ports Tested THE PORT tested was found to be: STEALTH. TruStealth: PASSED - ALL tested ports were STEALTH, - NO unsolicited packets were received, - NO Ping reply (ICMP Echo) was received. Starte ich jetzt rc.firewall nocheinmal (Proggi "lauscht" immer noch), dann geht alles wie gewünscht - und http://grc.com/default.htm bringt jetzt: GRC Port Authority Report created on UTC: 2005-12-05 at 18:15:03 Results from probe of port: 17500 1 Ports Open 0 Ports Closed 0 Ports Stealth --------------------- 1 Ports Tested THE PORT tested was found to be: OPEN. TruStealth: FAILED - NOT all tested ports were STEALTH, - NO unsolicited packets were received, - NO Ping reply (ICMP Echo) was received. Und nun? Übrigens: meine andere Mail ("...solved") war etwas übereilt. Ich hatte auch nur per Hand die iptables... Zeile eingefügt - allerdings versäumt, den Rechner neu zu starten :-( Alles ziemlich blöd. Na, ich probiere mal weiter. Vielleicht finde ich ja noch etwas Bye Timothy -- "Es gibt zwei Dinge im Leben, die du nicht zurücknehmen kannst: Den Pfeil den du verschossen und das Wort, das du gesprochen" - altes indianisches Sprichwort
Irgendwie scheint da ein genereller Bug zu sein. Ich habe jetzt auch Port 80 in beide Richtungen freigeben. Und auch dort das selbe Verhalten. rechner neu gestartet. Kein Zugriff auf meinen Web-Server. Dann rc.firewall nochmals ausgeführt - und siehe da, jetzt ist der Webserver erreichbar. Woran kann das denn nun liegen ???????? ratlose Grüße Timothy -- "Es gibt zwei Dinge im Leben, die du nicht zurücknehmen kannst: Den Pfeil den du verschossen und das Wort, das du gesprochen" - altes indianisches Sprichwort
Hallo, Am Mon, 05 Dec 2005, Timothy Kesten schrieb:
Irgendwie scheint da ein genereller Bug zu sein. Ich habe jetzt auch Port 80 in beide Richtungen freigeben. Und auch dort das selbe Verhalten. rechner neu gestartet. Kein Zugriff auf meinen Web-Server. Dann rc.firewall nochmals ausgeführt - und siehe da, jetzt ist der Webserver erreichbar. Woran kann das denn nun liegen ????????
Das koennte daran liegen, dass die Firewall zu frueh gestartet wird. Pruefe a) die Logs auf Fehlermeldungen von iptables b) die Abhaengigkeiten von /etc/init.d/firewall vgl. man insserv, /etc/init.d/README -dnh -- Love your enemies: they'll go crazy trying to figure out what you're up to. -- BSD fortune file
Am Dienstag, 6. Dezember 2005 00:47 schrieb David Haller:
Das koennte daran liegen, dass die Firewall zu frueh gestartet wird. Ich habe zwar (noch) relativ wenig Ahnung vom Mechanismus einer Firewall (belese mich gerade), aber genau dieses habe ich mir auch so langsam mal gedacht.
deshalb werde ich genau dieses
Pruefe a) die Logs auf Fehlermeldungen von iptables b) die Abhaengigkeiten von /etc/init.d/firewall vgl. man insserv, /etc/init.d/README ...auch tun. Leider heute wenig Zeit. Aber danke für die Tipps. Erst mal raus bekommen, wie die Firewall vom System wann gestartet wird
allerdings finde ich nur ein /etc/rc.firewall. In /etc/init.d gibt es nur scripte für die SuSEfirewall /etc/init.d/SuSEfirewall2_init /etc/init.d/SuSEfirewall2_setup /etc/preload.d/SuSEfirewall2_final /etc/preload.d/SuSEfirewall2_init /etc/preload.d/SuSEfirewall2_setup Wer ruft also /etc/rc.firewall auf? Denn das es aufgerufen wird steht erst enmal fest. Nur die Regeln für die Richtung "Internet" -> "lokal" werden nicht ausgeführt. Bye Timothy -- "Es gibt zwei Dinge im Leben, die du nicht zurücknehmen kannst: Den Pfeil den du verschossen und das Wort, das du gesprochen" - altes indianisches Sprichwort
Hallo, Am Tue, 06 Dec 2005, Timothy Kesten schrieb:
allerdings finde ich nur ein /etc/rc.firewall. In /etc/init.d gibt es nur scripte für die SuSEfirewall
Koennte es sein, dass das rc-script nicht so recht zu deiner SuSE passt? Oder doch, und dann aber z.B nach /etc/init.d/firewall versymlinkt werden koennte (wenn die Header stimmen -> /etc/init.d/README)? Gefolgt von nem 'insserv firewall'? Nur mal so ins Blaue geraten, ich hab noch ne SuSE 6.2 und kein insserv aber ein selbstgestricktes firewall-script, das auch als init-script funktioniert ;) -dnh, der damit nur darauf hinweisen will, dass all diese "tollen" automatismen nicht immer hilfreich sind ;) Wenn man's haendisch konfiguriert/automatisiert (vgl. den klassischen SysV init-Ablauf mit haendisch aenderbaren symlinks in /sbin/init.d/rc*.d/ *scnr*) --
Was ist das, "Nacht"? Das ist der Zeitraum, in dem Du effektiv administrieren kannst. Weil anscheinend die User alle total faul sind, und sich ausgeloggt haben. -- Wilfried Kramer
Am Dienstag, 6. Dezember 2005 09:58 schrieb David Haller:
Koennte es sein, dass das rc-script nicht so recht zu deiner SuSE passt? Woran erkenne ich dies? Wie Kimmo schrieb, befindet sich unter
/etc/sysconfig/network/if-up.d/ Link 10Guarddog - verlinkt nach /etc/rc.firewall Die Regeln für beide Richtungen stehen in dieser rc.firewall. Nur werden eben die Regeln "Internet" -> "lokal" beim Systemstart, aus welchen gründen auch immer, nicht angewendet bzw. sie greifen nicht. Nur nach einem "händischen" /etc/rc.firewall ist alles wie gewünscht.
-dnh, der damit nur darauf hinweisen will, dass all diese "tollen" automatismen nicht immer hilfreich sind ;) Wenn man's haendisch konfiguriert/automatisiert (vgl. den klassischen SysV init-Ablauf mit haendisch aenderbaren symlinks in /sbin/init.d/rc*.d/ *scnr*) Okay, okay - sehe ich zumindest in diesem Falle auch so. Ein workaround habe ich ja. Und mein Ziel ist ja schon, das "endgültige" Script per Hand zu erstellen. Und zumindest als "Vorlage" ist das Guarddog-Script ganz hilfreich.
Und Kimmo - fwbuilder habe ich auch schon installiert - und werde ihn auch ausprobieren. Sollte ich noch die Ursache für diesesmerkwürdige Verhalten finden, dann poste ich es hier. Hat jemand anderes eine Lösung (!!!!)- nehme ich gern entgegen. Aber der Thread kann hier auch beendet werden. Die Firewall arbeitet ja , wenn auch stotternd ;-) und Ziel bleibt ja das Erstellen eines endgültigen Scriptes per Hand. Trotzdem Danke an Alle, die sich um Tipps/Lösungenen bemüht haben. Bye Timothy -- "Es gibt zwei Dinge im Leben, die du nicht zurücknehmen kannst: Den Pfeil den du verschossen und das Wort, das du gesprochen" - altes indianisches Sprichwort
Hallo, Timothy Kesten, 6.12.2005 08:35:
Am Dienstag, 6. Dezember 2005 00:47 schrieb David Haller:
Das koennte daran liegen, dass die Firewall zu frueh gestartet wird.
Ich habe zwar (noch) relativ wenig Ahnung vom Mechanismus einer Firewall (belese mich gerade), aber genau dieses habe ich mir auch so langsam mal gedacht.
deshalb werde ich genau dieses
Pruefe a) die Logs auf Fehlermeldungen von iptables b) die Abhaengigkeiten von /etc/init.d/firewall vgl. man insserv, /etc/init.d/README
...auch tun. Leider heute wenig Zeit. Aber danke für die Tipps. Erst mal raus bekommen, wie die Firewall vom System wann gestartet wird
allerdings finde ich nur ein /etc/rc.firewall. In /etc/init.d gibt es nur scripte für die SuSEfirewall
/etc/init.d/SuSEfirewall2_init /etc/init.d/SuSEfirewall2_setup /etc/preload.d/SuSEfirewall2_final /etc/preload.d/SuSEfirewall2_init /etc/preload.d/SuSEfirewall2_setup
Wer ruft also /etc/rc.firewall auf?
In /etc/sysconfig/network/if-up.d solltest du fündig werden.
Denn das es aufgerufen wird steht erst enmal fest. Nur die Regeln für die Richtung "Internet" -> "lokal" werden nicht ausgeführt.
Zugegeben, GD hat bestimmte Probleme mit einigen Konfigurationen. Sollte es zu kompliziert werden, gibt's auch andere Proggis wie z.B. Firestarter oder FWBuilder... (Ich übe gerade mit FWBuilder an einem Testserver. Scheint recht "powerful" und leicht konfigurierbar zu sein.) Gruß Kimmo
Hallo, Am Tue, 06 Dec 2005, K. Elo schrieb:
Zugegeben, [Guarddog] hat bestimmte Probleme mit einigen Konfigurationen. Sollte es zu kompliziert werden, gibt's auch andere Proggis wie z.B. Firestarter oder FWBuilder... (Ich übe gerade mit FWBuilder an einem Testserver. Scheint recht "powerful" und leicht konfigurierbar zu sein.)
Was hast du dagegen, direkt [oder per script] iptables-Regeln zu setzen? -dnh -- "...[T]he harried saints of the tech department (who can never be paid enough as far as I'm concerned--I cannot imagine what it's like to know nearly everything about systems and have to deal, daily, with people who know nearly nothing about systems. It's like being a cosmologist at an astrology convention)...." -- James Lileks
Hallo David, hallo Liste, David Haller, 6.12.2005 11:57:
Hallo,
Am Tue, 06 Dec 2005, K. Elo schrieb:
Zugegeben, [Guarddog] hat bestimmte Probleme mit einigen Konfigurationen. Sollte es zu kompliziert werden, gibt's auch andere Proggis wie z.B. Firestarter oder FWBuilder... (Ich übe gerade mit FWBuilder an einem Testserver. Scheint recht "powerful" und leicht konfigurierbar zu sein.)
Was hast du dagegen, direkt [oder per script] iptables-Regeln zu setzen?
Nichts grundsätzliches. Es geht mir nur darum, dass ich nicht überall auf "grassroot level" arbeiten will. Wenn es also Tools gibt, die diese Arbeit für mich machen (damit meine ich, wenn wie beim FW-Thema bleiben, vor allem die Übersetzung von FW-policies in iptables-Regeln), verwende ich solche Tools nicht ungern. Ich habe hier auch GD auf einigen Computern im Einsatz und habe bisher keine solchen Probleme mit diesen FWs gehabt, die ich nicht hätte beheben können. Man muss ja auch merken, dass nicht alle Linux-Benutzer vom Beruf her Sysadmins sind. Ich selbst bin das auch nicht, sondern verwalte "nebenberuflich" ein kleineres Hausnetz. Zwar möchte ich schon die Arbeitsweise aller eingesetzen "Elemente" unseres Systems kennen, um ggf. mögliche Probleme finden und beheben zu können, aber dafür muss ich ja doch nicht alles per Hand machen, oder :) Gruß Kimmo
Am Sonntag, 4. Dezember 2005 20:17 schrieb Timothy Kesten:
Ich muss "händisch" nochmals /etc/rc.firewall starten, dann funzt es.
Moin Timothy, entschuldige wenn ich hier so ahnungslos zwischen funke, aber irgendwie versteh ich hier was nicht. Ich hab zwar keine Ahnung von Guardog, persönlich verwende ich die Linux Firewall von Webmin basierend auf einem eigenen Firewall script, aber sollte nicht auch bei guardog ein boot script unter init.d liegen ? Ich wundere mich also zum einen wie bzw warum du die firewall über etc starten kannst bzw mußt, und zum anderen frage ich mich ob guardog bzw dessen firewall script während des bootens überhaupt gestartet wird. Du sagst Du mußt rc.firewall erneut starten, wurde es denn überhaupt gestartet ? Gruß Micha
Am Dienstag, 6. Dezember 2005 02:37 schrieb Michael Schueller:
Ich wundere mich also zum einen wie bzw warum du die firewall über etc starten kannst bzw mußt, und zum anderen frage ich mich ob guardog bzw dessen firewall script während des bootens überhaupt gestartet wird. Du sagst Du mußt rc.firewall erneut starten, wurde es denn überhaupt gestartet ?
Ja - siehe meine Antwort auf David Hallers Posting. Timothy -- "Es gibt zwei Dinge im Leben, die du nicht zurücknehmen kannst: Den Pfeil den du verschossen und das Wort, das du gesprochen" - altes indianisches Sprichwort
participants (5)
-
David Haller -
K. Elo -
Martin Ereth -
Michael Schueller -
Timothy Kesten