Am Sonntag, 17. April 2005 12:10 schrieb Michael Bischof:
> Silv�rio, warum nicht ? "ps aux" (den Tippfehler hatte ich bemerkt) zeigt
> doch die Liste der laufenden Prozesse und "| grep X11R6" zeigt wo X11R6
> darin vorkommt ? In der KDE-System�berwachung (als user ausgef�hrt) finde
> ich die aufgef�hrten PIDs aber nicht. Wo ist jetzt der Zusammenhang zum
> Problem: mit eingeschalteter Firewall keine Verbindung ins Netz
> ^
>
> v
> ohne diese Firewall scheint die Internet-Verbindung unsicher zu sein ?
>
Mal langsam. Man braucht nicht zwingend einen Paketfilter (die Bezeichnung
"Firewall" empfinde ich in diesem Zusammenhang als falsch), um sicher im Netz
unterwegs zu sein.
Was ist bei Dir passiert?
Du hast einen entfernten Rechner beauftragt zu versuchen, Verbindungen zu
Deinem Rechner auf eine Reihe von Ports aufzubauen. Das ist der entfernten
Maschine bei 4 der getesteten Ports gelungen.
Warum ist das gelungen?
Weil auf Deiner Maschine Programme laufen, die eingehende Verbindungen auf
diesen Ports akzeptieren, die also einen "Dienst" an andere Rechner anbieten.
Was ist mit den anderen Ports, die �berpr�ft wurden?
Da ist der Verbindungsaufbau fehlgeschlagen, weil eben keine Programme auf
Deinem Rechner laufen, die dort eingehende Verbindungen zulassen. Der
IP-Stack Deiner Maschine hat also das getan, was in einem solchen Fall
sinnvoll ist - er hat dem entfernten Rechner gesagt: "Geh weg".
Was ist jetzt das Problem?
Programme, die einen Dienst �ber das Netzwerk anbieten, also eingehende
Verbindungen akzeptieren, k�nnen Fehler haben (wie jedes andere Programm
auch). Sie k�nnen sogar solche Fehler haben, die dazu f�hren, da� bspw.
Deiner Maschine �ber das Netzwerk fremder Code untergejubelt werden kann.
Genau das hat z. B. der Blaster-Wurm gemacht.
Es gibt nun zwei M�glichkeiten:
1. Du willst explizit einen Netzwerkdienst anbieten (z. B. Webserver). Dann
mu�t Du das Risiko eingehen, da� das Dienstprogramm evtl. Fehler enth�lt, die
sich ausnutzen lassen. Hier wirst Du dann aber sinnvollerweise zus�tzliche
Ma�nahmen treffen, um das Risiko zu minimieren: Rechner in eine separates
Netzwerk (DMZ) stellen, auf dem Laufenden bleiben, welche Sicherheitsl�cken
im Serverprogramm evtl. bekannt werden und diese sofort patchen etc.
2. Du willst keinen Netzwerkdienst anbieten. Dann ist folgendes Vorgehen
sinnvoll: Biete keinen Netzwerkdienst an.
Der IP-Stack Deines Rechners weist dann sehr zuverl�ssig eingehende
Verbindungsversuche zur�ck. Das tut er auch ohne einen aktivierten
Paketfilter (s. o.).
Wie schon an anderer Stelle in diesem Thread geschrieben, erreichst Du das,
indem Du Programme, die einen Dienst anbieten entweder gar nicht startest
oder so konfigurierst, da� sie nicht auf der �ffentlichen Schnittstelle
Deiner Maschine Verbindungen annehmen.
Nat�rlich kannst Du auch einen Paketfilter ("Firewall") verwenden, um
eingehende Verbindungsversuche zur�ckzuweisen, unabh�ngig davon, ob auf dem
jeweiligen Port ein Dienst lauscht oder nicht. Der Nachteil, den ich an
dieser L�sung sehe, ist aber, da� Du wissen mu�t, wie Du diesen Paketfilter
konfigurierst, damit der so arbeitet, wie Du willst.
Alternativ k�nntest Du Dich auch darauf verlassen, da� Deine Distribution eine
Standardkonfiguration f�r den Paketfilter mitbringt, die genau f�r Deine
Anforderungen passend ist. Nach dem, was Du schreibst (Firewall an --> surfen
aus), bezweifle ich das. Auch rate ich Dir davon ab, blind die Filterregeln
anderer zu verwenden, wenn Du nicht verstehst, was diese bewirken.
Noch ein Hinweis zum Schlu�:
netstat --inet -anp
zeigt u. a. Dir an, welche Programme auf welcher IP und welchem Port
eingehende Verbindungen akzeptieren.
Gru�
mks
--
----------------------------------------------------------------------------
PUG - Penguin User Group Wiesbaden - http://www.pug.org
