[HowTo]Firewall im Whitelist-Modus --> Ungewollten Traffic automatisch blockieren

Falkner schrieb:
Bedeutet also, dass man mit einer IP wie z.B. 87.230.75.0/24 (ist die IP von Computerbase.de) nur eine Seite aufrufen kann.
Das hast du falsch verstanden! Gerade am Beispiel der zitierten CIDR lässt sich das leicht zeigen: Das ist der Netblock von Hosteurope, nicht nur von CB. Es wird mit Sicherheit noch andere Webseiten geben, die man über IP-Adressen aus dem Bereich erreicht. Was ich meinte, ist, dass IP-Adressen eindeutig auf bestimmte Server verweisen. Und diese wiederum gehören jemandem (z.B. Hosteurope); und dieser jemand lässt nur von authorisierten Nutzern (z.B. den Admins und Co. von CB) Veränderungen am Server vornehmen. Es könnte aber unter bestimmten Umständen auch möglich sein, dass auf einem Server mehr liegt als nur eine Webseite. Und im Falle von Youtube ist es genau umgekehrt: Beim Abspielen eines Videos werden mehrere verschiedene Server kontaktiert (deswegen mehreren IP-Adressen), weil auf jedem jeweils andere Daten draufliegen (z.B. auf dem einen das Video, auf einem anderen die Daten für die Youtube-Webseite, ein anderer wiederum ist für irgendwelche Scripte veratnwortlich usw.).

IP-Adressen sind die Internet-Adressen von Hardware (Servern), und nicht direkt von Webseiten!

Falkner schrieb:
Doch alle Server die mir angezeigt werden, haben einen Ping von 999 und auf keinen lässt sich verbiden.
auf Anhieb würde ich vermuten, dass es mit ICMP zusammenhängt; dem "Protokoll" für Pings. Probier es mal mit einer Regel, mit der auch das Protokoll "ICMPv4" für die entsprechenden *.exes freigegeben wird.
 
Zuletzt bearbeitet:
Versuche es mal in ganz einfache Worten wieder zu geben, mal gucken ob ichs jetzt verstanden habe.

Diese CIRD 87.230.75.0/24 ist die Adresse von Hosteurope.
Auf Hosteurope können viele Seiten liegen. Eine davon ist Computerbase.de

Wenn ich für meine Firefox.exe eine Regel erstelle, in der nur die o.g. CIRD eintragen wird, dann gellange ich, wenn ich in meinem Browser www.computerbase.de eingebe, auf die Seite von Computerbase.

Im Grunde: Ich gebe "Computerbase.de" im Browser ein -> mein Browser kontaktiert Hosteurope und Hosteurope leitet mich dann auf Computerbase.de weiter.


Es ist aber auch möglich auf eine andere Seite zu gellangen wenn "www.123xyz.??" eingegeben wird und ebenfalls auf den Hosteurope-Server lieg ?

Jetzt hab ichs bestimmt *Kopf einzieh und :mussweg:
 
Falkner schrieb:
Diese CIRD 87.230.75.0/24 ist die Adresse von Hosteurope.
Auf Hosteurope können viele Seiten liegen. Eine davon ist Computerbase.de
ööhm ... nö, nicht so ganz.
Host Europe ist ein Webhoster (-> http://de.wikipedia.org/wiki/Webhosting), der Server zur Verfügung stellt. Dessen verschiedene Server haben bestimmte IP-Adressen. Wenn die den Adressbereich mit /24 komplett ausnutzen würden, dann könnten die an 255 (oder 256?) Server feste IP-Adressen vergeben. Zwei davon werden von CB genutzt (einmal der, der die Daten für "computerbase.de" liefert, und einer, auf dem die Bilder für CB liegen ("pics.computerbase.de")). Wenn Kunden (wie CB) ihre Seiten auf deren Servern "hosten" lassen, dann liegen die Webseiten u.a. als *html-Dateien, Bildern usf. auf diesen Servern. Die Server gehören Hosteurope, aber man kann Server bzw. Speicherplatz bei denen quasi mieten.

Wenn du nun "computerbase.de" in die Adressleiste deines Browsers eingibst, dann sendet dein Browser diesen Hostnamen an deinen DNS-Server. Der DNS-Server durchsucht seine Einträge und findet dann, dass dieser Hostname zur IP-Adresse XY gehört. Dann stellt dein Browser die Verbindung zu den Servern mit derjenigen IP-Adresse her. Und abhängig von der Art und Weise, wie diese Verbindung hergestellt wird (z.B. abhängig vom Remoteport, dem anfragenden Programm usf.), liefert ein Server bestimmte Daten an dich als User (frag mich aber nicht, was da technisch in den einzelnen Datenpaketen enthalten ist, dass du gerade eine ganz bestimmte Seite angezeigt kriegst). Wenn du Webseiten aufrufst, dann lädst du dir im Endeffekt *.html-Dateien, Bilder usf. von einem bestimmten Server runter und dein Browser stellt sie dar.

Technisch könnte es auch sein, dass CB sich irgendwann entschließt, einen anderen Webhoster zu nutzen. Dann müsstest du andere IP-Adressen freigeben, um CB zu erreichen, weil jetzt die Verbindung zu anderen Servern (die selbst eigene, andere IP-Adressen haben) hergestellt werden müsste.

Mach dich mal hier schlau: http://de.wikipedia.org/wiki/Webserver

Falkner schrieb:
Es ist aber auch möglich auf eine andere Seite zu gellangen wenn "www.123xyz.??" eingegeben wird und ebenfalls auf den Hosteurope-Server lieg ?
ja.

http://www.webseiten-infos.de/websites-mit-gleicher-ip-adresse-ermitteln/ schrieb:
1. Vorbemerkung

Wer lediglich ein Webspace-Paket, aber keinen eigenen Server bei seinem Hoster hat, der muss sich im Regelfall die IP-Adresse mit anderen Kunden auf dem Server teilen.

Da kann es durchaus mal Sinn machen, nachzusehen, mit wie vielen anderen Kunden und mit wem man da die IP-Adresse teilt:

* Über die Information mit wie viele Kunden Du die IP-Adresse teilst, kannst Du Dir in etwa ein Bild von dem für Deine Website verfügbaren Anteil an den Serverressourcen machen. Aktuell sind Hunderte von Websites bei einfachen Webhosting-Angeboten nichts Ungewöhnliches. Natürlich kommt es dann auch noch entscheidend auf die Serverausstattung und die Serverkonfiguration an.
* Enthalten andere Websites mit der gleichen IP-Adresse bedenkliche Inhalte (etwa Sex- oder Glücksspielseiten), dann handelt es sich um einen Fall von schlechter Nachbarschaft (bad neighbour). Das kann sowohl das Ranking bei Suchmaschinen negativ beeinträchtigen als auch dazu führen, dass sich Deine Seite beim Filtern von solchen Websites in Ländern und Unternehmen mit entsprechenden IP-Sperren (Webfiltern) plötzlich mit auf der Sperrliste befindet.
Das betrifft aber vor allem kleine und meistens private Webseiten. Große Unternehmen mieten sich generell komplette Server bzw. besitzen ihre eigenen, dann mag man zwar immer noch mehrere Webseiten auf einem Server finden, aber die gehören dann alle zum gleichen Unternehmen.
Deshalb wäre ich bei der Freigabe von CIDR von kleinen Webhostern sehr vorsichtig; man weiß nie, was die vielen Privatpersonen, die Server-Speicherplatz gemietet haben, auf ihre eigenen Webseiten hochladen.
 
Zuletzt bearbeitet:
Das betrifft aber vor allem kleine und meistens private Webseiten. Große Unternehmen mieten sich generell komplette Server bzw. besitzen ihre eigenen, dann mag man zwar immer noch mehrere Webseiten auf einem Server finden, aber die gehören dann alle zum gleichen Unternehmen.
Deshalb wäre ich bei der Freigabe von CIDR von kleinen Webhostern sehr vorsichtig; man weiß nie, was die vielen Privatpersonen, die Server-Speicherplatz gemietet haben, auf ihre eigenen Webseiten hochladen.


Woran erkennt man ob es ein kleiner oder großer Webhoster ist ?

Wo liegt die Gefahr für einen, wenn jemand einen Server-Speicherplatz mietet und dadrauf irgend etwas drauf läd ?

Wenn da z.B. irgendwelche Viren drauf wären, dann würde man doch nur sein System infizieren wenn man auch auf die Seite selbst drauf geht oder nicht ?

Kanst du eventuell ein Beispiel nennen, kann mir das so irgendwie schwer vorstellen.



Besteht auch dann eine Gefahr, wenn man zwar eine CIRD von einem "kleinen" Webhoster in seiner Regel drin hat, aber nur auf eine Seite geht, der man auch vertraut und weiß, dass alles ok ist ?
 
Falkner schrieb:
Woran erkennt man ob es ein kleiner oder großer Webhoster ist ?
das kann man eigentlich nur erkennen, wenn man mal guckt, was für Angebote der hat. Wenn er "eine eigene .de-Domain für nur 99cent im Monat"-Werbung schaltet, dann bedeutet das zumindest, dass da quasi jeder Webspace inkl. eigener Website-Adresse mieten kann.

Falkner schrieb:
Wo liegt die Gefahr für einen, wenn jemand einen Server-Speicherplatz mietet und dadrauf irgend etwas drauf läd ?
Du musst bedenken: Wenn jemand per Hack Malware auf eine Webseite packt, dann liegt diese Malware in aller Regel nicht auf dem gehackten Server selbst, sondern sie wird von irgendwo nachgeladen (auf den Seiten werden meistens unscheinbare Scripte, Flash-Elemente oder iFrames eingebaut, die das bewerkstelligen). Wenn du jetzt z.B. einen Netblock/ CIDR von einem Hoster freigegeben hast, von dessen Servern nachgeladen wird, dann wird das Prinzip des Whitelisting außer Kraft gesetzt - denn du hast unwissentlich den Zugriff auf infizierte Server zugelassen. Das wäre dann ähnlich, als würdest du Verbindungen z.B. zu bekannten Servern eines Botnetzes per Regel erlauben.

Deswegen würde ich raten, immer nur Netblocks freizugeben, die entweder direkt von Unternehmen (Microsoft ist kein Webhoster) oder wenigstens von großen Hostern stammen, die vorwiegend große Geschäftskunden betreuen (z.B. Akamai, Amazonaws).

Wenn man Webseiten, die auf Webservern von Webhostern liegen, freigeben möchte, sollte man direkt nur ausgewählte IP-Adressen anstatt des ganzen CIDR-Bereichs freigeben.

Code:
Name:    computerbase.de
Address:  87.230.75.2
Name:    pics.computerbase.de
Address:  87.230.75.2, 87.230.75.10
Nachteil dabei: Wenn doch mal ein anderer Server ins Spiel kommt, dann wird die Verbindung von der Whitelist-Firewall blockiert; das nervt mich besonders beim Bilder-Hoster Abload.de, wo ich meine Bilder (u.a. vor dieses HowTo) hochgeladen habe. CIDR-Bereiche sind da schon viel bequemer, und man muss es ja mit der Paranoia nicht übertreiben. Immerhin haben auch Webhoster Admins und Möglichkeiten, ihre vermieteten Server frei von Malware zu halten.

Aber mal am Rande: Ich surfe jetzt auch schon seit geraumer Zeit nicht mehr mit Whitelist-Regeln für meinen Firefox (der Rest des System ist aber noch whitelisted), weil es mir einfach auf den Keks ging. Stattdessen verlasse ich mich auf die Sandbox von Kaspersky bzw. surfe auf meinem "Nur-Win7-Firewall und MSE"-Rechner mit einer virtuellen Maschine (XPmode, mit MSE und Threatfire) mit aktiviertem Rückgängig-Datenträger, für die alle Adressen über TCP 80 und 443 zugelassen sind. So fühle ich mich weitestgehend vor Malware durch Websurfen geschützt. Und weil dazu noch alle wichtigen Dateien verschlüsselt gespeichert sind (z.B. die Profildaten von Firefox und Thunderbird), mache ich mir auch keine Gedanken über Datendiebstahl.
 
Zuletzt bearbeitet:
Whitelisting bietet zusätzliche Sicherheit, ist aber bei einem sauberen System nicht erforderlich. Es muss aber immer eine Firewall (ob Router, Windows oder Security Suite, ist egal) installiert sein, die unaufgeforderten, eingehenden Datenverkehr ohne Ausnahme blockiert und die Ports des eigenen Rechners unsichtbar macht (das kann die Windows-Firewall schon seit XP SP2). Testen kann man die eigene Firewall am besten bei GRC‘s ShieldsUp oder mit Heises Port-Test

Genau hier liegt mein Problem: Ich benötige kein Whitelisting, möchte aber sicherstellen, dass Programme (z.B. Skype) nicht automatisch (z.B. ohne Frage an mich) Eingangsregeln in die Regelliste der Windows-Firewall (Windows 7 Pro 64 Bit) eintragen dürfen. Denn das heißt de facto, dass unaufgeforderter, eingehender Datenverkehr (der es durch die Firewall des Routers geschafft hat) nicht effektiv blockiert werden kann. Wie kann ich das sicherstellen?

Hinweis: Im entsprechenden Netzwerkprofil der Windows-Firewall ist für eingehende Verbindungen bereits das Standardverhalten auf "Blockieren" sowie die Einstellung "Benachrichtigungen anzeigen" auf "Ja" gestellt.

Viele Grüße
fuggi
 
fuggi schrieb:
Genau hier liegt mein Problem: Ich benötige kein Whitelisting, möchte aber sicherstellen, dass Programme (z.B. Skype) nicht automatisch (z.B. ohne Frage an mich) Eingangsregeln in die Regelliste der Windows-Firewall (Windows 7 Pro 64 Bit) eintragen dürfen.
kannst du nicht! Selbst Programme mit eingeschränkten Rechten können neue Regeln für eingehenden Traffic erstellen, da hat MS geschlampt.

ABER das hier
fuggi schrieb:
Denn das heißt de facto, dass unaufgeforderter, eingehender Datenverkehr (der es durch die Firewall des Routers geschafft hat) nicht effektiv blockiert werden kann.
ist nicht richtig. Denn du brauchst nur die Einstellung auf "alle blockieren" zu stellen, und schon werden auch alle erstellten Regeln ignoriert. Da macht es dann keinen Unterschied, wenn Programme fröhlich Regeln für eingehenden Traffic erstellen; zum Glück gibt es (noch) keine Programme, die Regeln für ausgehenden Traffic erstellen O_o

Oder: Wenn du sie auf "blockieren" lässt, und die Option für die Meldung aktivierst, bekommst du eine Nachricht, wenn ein Programm eine neue Regel nutzen will. Richtig gelesen: Die Meldung erscheint nicht, wenn eine neue Regel erstellt wird, sondern wenn ein Programm sie nutzen will!
Beschreibung aus Windows schrieb:
Benachrichtigung anzeigen: "Zeigt Benachrichtigungen für den Benutzer an, wenn ein Programm daran
gehindert wird, eingehende Verbindungen zu empfangen."
Da steht nix davon, dass eine Meldung bei der Erstellung einer Regel erscheinen würde ... auch wenn ich das für viel sinnvoller halten würde.

fuggi schrieb:
Wie kann ich das sicherstellen?
Die Einstellungen für "Eingehende Verbindungen" auf "Alle blockieren" stellen. Dann werden auch alle vorhandenen Regeln für eingehenden Traffic ignoriert (Hinweis: Das musst du für alle drei Netzwerkprofile machen!).
Außerdem "Benachrichtigungen anzeigen" für alle drei Netzwerkprofile aktivieren.

lies dir mal die Posts und meine Antworten ab #126 durch
https://www.computerbase.de/forum/t...matisch-blockieren.744697/page-7#post-8089169
 
Zuletzt bearbeitet:
Scheinweltname schrieb:
kannst du nicht! Selbst Programme mit eingeschränkten Rechten können neue Regeln für eingehenden Traffic erstellen, da hat MS geschlampt.
Typisch Microsoft! Das ist nicht die einzige Stelle, wo sie bspw. bei Windows 7 so richtig in die Tonne gegriffen haben.

Scheinweltname schrieb:
ABER das hier
ist nicht richtig. Denn du brauchst nur die Einstellung auf "alle blockieren" zu stellen, und schon werden auch alle erstellten Regeln ignoriert. Da macht es dann keinen Unterschied, wenn Programme fröhlich Regeln für eingehenden Traffic erstellen; zum Glück gibt es (noch) keine Programme, die Regeln für ausgehenden Traffic erstellen O_o
Das ist keine Lösung für meine Anforderungen.

Scheinweltname schrieb:
Oder: Wenn du sie auf "blockieren" lässt, und die Option für die Meldung aktivierst, bekommst du eine Nachricht, wenn ein Programm eine neue Regel nutzen will. Richtig gelesen: Die Meldung erscheint nicht, wenn eine neue Regel erstellt wird, sondern wenn ein Programm sie nutzen will!
Aha, aber das ist der Hinweis, der mir gefehlt hat. Ist die Windows-Firewall also doch nicht nutzlos, nur die Regel-Handhabung in diesem Punkt alles andere als intuitiv.

Vielen Dank!
fuggi
 
fuggi schrieb:
Aha, aber das ist der Hinweis, der mir gefehlt hat. Ist die Windows-Firewall also doch nicht nutzlos, nur die Regel-Handhabung in diesem Punkt alles andere als intuitiv.
ich kann aber nicht sagen, wie oft die Firewall dich warnt. Kann sein, dass ein Programm nach einmaliger Erlaubnis deinerseits von da an für immer durchgewunken wird.
 
tuxianer22 schrieb:
Hallo,
welche Regeln muss ich den hinzufügen, um Ordner über Samba freigeben zu können?
ich kenne Samba nicht, aber google mal nach "Samba" und "Firewall".
Vermutlich werden die notwendigen Regeln den Regelvorlagen zur "Datei- und Druckerfreigabe" ähneln, die man bei der Regelerstellung in der Windows-Firewall auswählen kann.
 
Ich steige gerade so langsam von XP auf Windows 7 um und habe mich deshalb in letzter Zeit mal mit den standardmäßig offenen Ports von Windows 7 vertraut gemacht. Bei XP habe ich standardmäig nur noch die Ports 139 und 445 offen, damit die Dateifreigabe ordentlich im privaten Netzwerk funktioniert. Die restlichen Ports habe ich alle deaktiviert bekommen (ohne Firewall). Nun dachte ich, dies sei auch irgendwie unter Windows 7 zu bewerkstelligen, allerdings bekomme ich auch nach stundenlangem Lesen im Internet nicht alle gewünschten Portlauscher abgeschaltet. Außer auf den o.g. Ports lauscht (derzeit) bei mir Windows 7 nämlich noch auf den folgenden -von mir unerwünschten- Ports: 135, 49152-49156, 49158

Was ich schon erfolglos versucht habe:
Port 135: DCOMCNFG.exe und die bereits bekannten Einstellungen wie unter XP, HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Ole -> "EnableDCOM"="N"
Und gerade bei diesem altbekannten Port 135 war ich mich fast sicher, dass ich diesen auch unter Win7 wieder abgeschaltet bekomme, leider Fehlanzeige. Aber scheinbar lauscht hier nicht mehr nur DCOM sondern noch ein ganzer Blumenstraus voll anderer Programme, z.B.: RPC (LSASS, CertSvc, ClusSvc, Dfs, DFSR, TrkSvr, MSDTC, Gruppenrichtlinie, MSMQ, usw.), zumindest wenn man dieser Liste von MS glauben darf. Ich möchte/kann ja nun nicht alle diese Dienste beenden, außerdem habe ich auch nichts dagegen wenn diese lokal laufen, ich möchte lediglich, dass diese Lauscherei aufhört.

Ports: 49152-49156, 49158
Bei denen wußte ich erstmal gar nicht, welche Funktion die haben. Zum Glück gibt's die vordefinierten Regeln in der Windows Firewall. Also Firewall eingeschaltet, alle vordefinierten Regeln testweise aktiviert und im Auschlußverfahren überprüft welche der Regeln welchen Port schließt, hier das Ergebnis:
49152 -> nichts herausgefunden, obwohl alle vorgegebenen Freigaben von MS in der Windows Firewall eingeschaltet waren, blieb dieser Port trotzdem geschlossen
49153 -> Remote-Ereignisprotokollverwaltung (RPC)
49154 -> Remoteverwaltung geplanter Aufgaben (RPC)
49155 -> Windows-Verwaltungsinstrumentation (WMI eingehend) und/oder iSCSI-Dienst
49156 -> Remotedienstverwaltung (RPC)
49158 -> Windows-Firewallremoteverwaltung (RPC)

Wenn ich diese Ports mit der Firewall blocke, dann läuft trotzdem alles wie von mir gewünscht. Schließlich möchte ich auch keine "geplanten Aufgaben" von einem anderen Recher aus erstellen oder die Windows Firewall von einem anderen Rechner aus fernbedienen. Ich frage mich nur, wieso MS es mir nicht erlaubt diese Funktionen direkt in Windows abzuschalten. Laut o.g. MS-Liste lauschen auch hier wieder mehrere Dienste/Programme an den gleichen Ports, zudem scheinen diese sich gelegentlich zu ändern (Stichwort: dynamische Ports 49152 ff.). Also, ist da schon jemand dahintergekommen?

Jetzt zu meinen Fragen:
1.) Hat es schon jemand geschafft die o.g. Portlauscher ausfindig zu machen und (ohne Firewall) abzuschalten? Wenn ja, wäre ich für sachdienliche Hinweise sehr dankbar.
2.) Kann mir jemand sagen, was über den Port 49152 abgewickelt wird und welcher Dienst/Programm da auf was lauscht/wartet?

Aber vermutlich hat MS diese Dinge so sehr in das Betriebssystem eingebaut, dass man die Lauscher nicht mal mehr abgeschaltet bekommt und eine Firewall regelrecht verwenden muss. Aber vielleicht gibts ja doch noch den ein oder anderen Geheimschalter in der Windows Registrierung?
 
Guliver schrieb:
Jetzt zu meinen Fragen:
1.) Hat es schon jemand geschafft die o.g. Portlauscher ausfindig zu machen und (ohne Firewall) abzuschalten? Wenn ja, wäre ich für sachdienliche Hinweise sehr dankbar.
2.) Kann mir jemand sagen, was über den Port 49152 abgewickelt wird und welcher Dienst/Programm da auf was lauscht/wartet?
Port 135 habe ich auch lange vergeblich abzuschalten versucht. Wenn du eine Lösung findest, würde ich die gerne erfahren.
Die Ports ab 40.0000 sind mir nie so richtig aufgefallen; ich dachte mir, dass das System nunmal auf irgendwelchen Ports lauschen muss, um überhaupt Netzwerktraffic verarbeiten zu können.

Guliver schrieb:
Wenn ich diese Ports mit der Firewall blocke, dann läuft trotzdem alles wie von mir gewünscht.
Vermutlich liegt das daran, dass du diese Ports nicht blockieren kannst; egal welche Regeln du erstellst. Wie dieser Faden schon aussagt, nutze ich eine Whitelist-Firewall, laut der die Verbindungen gar nicht aufgebaut werden dürften. Trotzdem sind sie da.
Du kannst z. B. mit der Windows-Firewall auch nicht verhindern, dass Windows DHCP-Anfragen absetzt.

Es gibt aber auch irgendwo in den Richtlinien des System versteckt bestimmte Regeln, in denen festgelegt ist, dass bestimmte Dinge zugelassen werden, auch wenn das-und-das eingestellt ist (irgendwo über MMC.exe und Administrative Vorlagen oder so ...), solange es nicht ausdrücklich deaktiviert wird.
 
Zuletzt bearbeitet:
... Du kannst z. B. mit der Windows-Firewall auch nicht verhindern, dass Windows DHCP-Anfragen absetzt.
Das wollte ich erst gar nicht glauben und habe es deswegen selbst getestet, das ist echt ein Ding! Was läßt denn MS noch so alles durch, ohne das man davon etwas mitbekommt oder es beinflussen kann? Nun gut DHCP könnte man deaktivieren, indem man den entsprechenden Dienst abschaltet, aber möchte man DHCP nur in "privaten Netzwerken" zulassen und nicht in öffentlichen/unbekannten, dann wirds schon schwierig :(. Die restlichen TCP-Ports habe ich aber meines Erachtens dicht bekommen, und dies wie folgt:
1.) Firewall.cpl -> Programm durch die Firewall hindurchlassen -> dort alles außer "Datei- und Druckfreigabe" für's private Netzwerk abgewählt
2.) WF.msc -> eingehende Regeln -> alle markiert -> alle deaktiviert, außer
a.) Datei- und Druckerfreigabe (Echoanforderung - ICMPv4 eingehend), damit der Ping von einem anderen lokalen Rechner im privaten Netzwerk noch funktioniert
b.) Datei- und Druckerfreigabe (NB-Sitzung eingehend), damit der Netzwerkzugriff per NetBios-Name noch funktioniert (Port 139 TCP)
Beide Dinge habe ich wie gesagt nur fürs "private Profil" und fürs "lokale Subnetz" zugelassen.
Ein anschließender Portscan im privaten Netz zeigte dann auch nur noch den Port 139 als offen an. In wieweit die anderen Protokolle (allen voran UDP) aber trotzdem noch löchrig sind, ist allerdings unklar. Das die Windows-Firewall nichtmal DHCP blockt, obwohl ich sie testweise "auf komplett alles blocken" eingestellt habe, macht sie nicht gerade sehr vertrauenswürdig.

Mein persönliches Fazit lautet daher: Seit Vista/Win7 ist man regelrecht gezwungen die Firewall einzuschalten, weil man es nur noch mit dieser schafft alle unerwünschten/ungenutzten Ports zumindest zu blocken. Umgangssprachlich könnte man sagen, ein löchriger Flickenteppich wieder notdürftig gestopft. Denn seit Vista/Win7 ist es nicht mehr möglich alle unbenötigten Dienste/Ports einfach abzuschalten. Und Abschalten ist immer besser als "nur" blocken.
 
Zuletzt bearbeitet:
Guliver schrieb:
Das die Windows-Firewall nichtmal DHCP blockt, obwohl ich sie testweise "auf komplett alles blocken" eingestellt habe, macht sie nicht gerade sehr vertrauenswürdig.
Es handelt sich dabei aber nicht um einen Fehler, sondern ist eine bewusste Einrichtung seitens MS zugunsten der Kompatibilität/Bedienung. Wenn man das auch blockieren will, kann man ja eine zweite Firewall installieren ;)

Guliver schrieb:
Die restlichen TCP-Ports habe ich aber meines Erachtens dicht bekommen, [...]
öffne mal TCPView und guck dir die "LISTENING"-Ports an.
Bei meinen Firewall-Einstellungen wird nur extrem wenig erlaubt; der Remote-Port 0 (das Ziel der Lauscher wie den lokalen Ports 135 oder 49152) ist nirgends erlaubt; weder eingehend noch ausgehend. Und trotzdem sind sie vorhanden. Sie sind aber insofern "dicht", als sie nicht von außen angesprochen werden können. Aber "Abschalten" wäre einem bloßen "Dichtmachen" immer vorzuziehen.
Code:
Prozess		PID	Prot. Lok.Adr.	LokPort	Rem.Adr.RemPort	Status
svchost.exe	764	  TCP	[1]	epmap	[1]	0	LISTENING
wininit.exe	444	  TCP	-	49152	-	0	LISTENING
svchost.exe	916	  TCP	-	49153	-	0	LISTENING
svchost.exe	1020      TCP	-	49154	-	0	LISTENING
services.exe	492	  TCP	-	49155	-	0	LISTENING
lsass.exe	516	  TCP	-	49156	-	0	LISTENING
svchost.exe	764	  TCPV6	[2]	epmap* 	[2]	0	LISTENING
wininit.exe	444	  TCPV6	-	49152	-	0	LISTENING
svchost.exe	916	  TCPV6	-	49153	-	0	LISTENING
svchost.exe	1020      TCPV6	-	49154	-	0	LISTENING
services.exe	492	  TCPV6	-	49155	-	0	LISTENING
lsass.exe	516	  TCPV6	-	49156	-	0	LISTENING
* epmap = Port 135
[1] = 0.0.0.0 (TCP)
[2] = 0:0:0:0:0:0:0:0 (TCPv6)

Nachtrag:
Nach ein bisschen Rumspielen mit dem Befehl "netstat" (nützlich, das Ding)
habe ich herausgefunden:
  • Der Port 135 wird von der Komponenten RPCSS genutzt, die offenbar nicht nur mit dem Netzwerk kommuniziert, sondern auch mit dem Windows-Kernel. Von daher scheint es mir sehr unwahrscheinlich, dass man ihn abschalten/blockieren kann, ohne funktionale Einschränkungen zu erleben.
  • Port 49152 wird von Wininit.exe belauscht.
  • Port 49155 von services.exe
  • Port 49158 ist bei mir nicht geöffnet.

Befehl mit cmd.exe ausführen:
Code:
netstat -a -b -f
Info zu weiteren Parametern
Code:
netstat /?
 
Zuletzt bearbeitet:
Es handelt sich dabei aber nicht um einen Fehler, sondern ....
Ja ich weiß: "it's not a bug, it's a feature" :D

... kann man ja eine zweite Firewall installieren
Na toll, 2 Firewalls für Win7 wofür man unter XP "keine" benötigt hätte. Ich habe mal testweise ZoneAlarm installiert, da handelt man sich mehr Bugs ein, als es nützt. Ping 127.0.0.1 funzt dann z.B. nicht mehr und die vsmon.exe lauscht gelegentlich auf diversen UDP-Ports in der 54.000'er Region. Da muss ich die Experten vom CCC zitieren: Mehr Software bedeutet mehr Code, bedeutet höhere Wahrscheinlichkeit, dass ein Fehler, Bug, Sicherheitsloch auftritt. Deswegen schalte ich auch lieber etwas ab, als eine weitere Software/Bug dazu.

öffne mal TCPView und guck dir die "LISTENING"-Ports an.
Wenn ich TCPView auf meinem geFirewall'ten Rechner anstoße, dann sieht man logischerweise alle lauschenden Ports. Die Firewall blockt schließlich nur nach außen. Ein Portscan von außen, trommelt aber nur auf der Firewall herum, sprich alles ist dicht, solange die Firewall hält was sie verspricht.

Bei mit sieht's ähnlich aus, nur dass ich hier die Dateifreigabe noch lokal benötige. Der Übersichtlichkeit halber habe ich mal IPv6 weggelassen:
Code:
Prozess		PID	Prot. 	Lok.Adr.	LokPort			Rem.Adr.	RemPort	Status
svchost.exe	780	TCP	0.0.0.0		epmap/135		0.0.0.0		0	lauscht
System		4	UDP	192.168.2.100	netbios-ns/137		*		*	
System		4	UDP	192.168.2.100	netbios-dgm/138		*		*
System		4	TCP	192.168.2.100	netbios-ssn/139		0.0.0.0		0	lauscht
System		4	TCP	0.0.0.0		microsoft-ds/445	0.0.0.0		0	lauscht
wininit.exe	476	TCP	0.0.0.0		49152			0.0.0.0		0	lauscht
svchost.exe	880	TCP	0.0.0.0		49153			0.0.0.0		0	lauscht
lsass.exe	588	TCP	0.0.0.0		49154			0.0.0.0		0	lauscht
svchost.exe	940	TCP	0.0.0.0		49155			0.0.0.0		0	lauscht
services.exe	580	TCP	0.0.0.0		49157			0.0.0.0		0	lauscht
Damit lauscht nur die Drucker- und Netzwerkfreigabe (Netbios) im Netzwerk auf eventuelle Verbindungsanfragen. Angeblich soll die von "guten" Routern verworfen werden, also nicht aus dem eigenen/privaten Adressbereich heraus können!? Wie könnte man überprüfen, ob dies bei mir tatsächlich so ist?! Ein simpler Portscan von außen bringt leider nichts, da die interne Firewall des Routers (NAT) schon blockt. Aber es gibt ja auch noch die Einwahlverbindungen (z.B. analoges Modem, ISDN oder UMTS) und die haben dann keinen Router mit Firewall dazwischen. Der Rechner könnte dann u.U. eine öffentliche IP vom Provider erhalten, inwieweit bestünde für diese Rechner die Gefahr, dass sich andere Leute z.B. die Netzwerkfreigabe ansehen könnten? Ich habe zwar die Windows Firewall so eingestellt, dass Netbios nur im lokalen Adressbereich zugelassen wird, allerdings würde ich es gern selbst mal irgenwie überprüfen. Leider kann ich dies mangels Direkteinwahlzugang nicht. Würde es deswegen Sinn machen testweise einfach mal eine Portweiterleitung im Router auf die Ports 137-139 einzustellen, um anschließend einen Portscan aus dem Internet zu starten?

Übrigens habe ich die folgenden standardmäßig offenen Ports wie folgt abgeschaltet bekommen:
Code:
svchost.exe	940	UDP	0.0.0.0		isakmp/500		*		*
svchost.exe	940	UDP	0.0.0.0		ipsec-msft/4500		*		*
---> Dienst "IKE- und AuthIP IPsec-Schlüsselerstellungsmodule" abgeschaltet

svchost.exe	1340	TCP	0.0.0.0		49158			0.0.0.0		0	lauscht
--> Dienst "IPsec-Richtlinien-Agent" abgeschaltet

svchost.exe	688	UDP	0.0.0.0		llmnr/5535		*		*
--> Dienst "IPsec-Richtlinien-Agent" abgeschaltet
Schade, dass man die restlichen Lauscher auf den Ports 4915x nicht auch noch irgendwie abgeschaltet bekommt. Das Abschalten weiterer Dienste bringt zumindest nichts! Port 135 (RPC) wurde scheinbar im Vergleich zu XP/2003 vom Microsoft mächtig aufgebohrt, ob diese zusätzlichen unabschaltbaren Funktionen für den Endverbraucher tatsächlich diesen ständig offenen Port Wert sind, wage ich zu bezweifeln. Unter WinXP ging es doch auch noch ohne Port 135, zumindest ließ er sich da noch deaktivieren. :mad:

Nun noch eine Verständnisfrage zu TCPview, wo liegt der Unterschied, wenn bei "lokaler Adresse" 0.0.0.0 oder eine andere IP (z.B. 192.168.2.100) steht? Und macht es ebenfalls einen Unterschied, wenn bei Remote-Adresse 0.0.0.0 oder ein Stern (*) eingetragen ist? Mir ist die Bedeutung dieser Anzeige nämlich noch nicht ganz klar.
 
Sehr guter Guide *2x Daumen hoch*

Funktioniert insgesamt so wie es soll, allerdings nutze ich 3 Browser wovon einer nicht geht.
Google Chrome (Ausweichbrowser) funktioniert mit den Ports 80 und 443 leider nicht, obwohl die .exe eine Regel bekommen hat. Die exe befindet sich unter ..User/Name/AppData/Local/Chrome.

Gibt es dafür eine Lösung?
Auf den Browser kann ich Notfalls auch verzichten, allerdings würde ich gerne wissen, wo genau das Problem liegt.

Grüße, TP


PS:
Eingehende Verbindungen ist für P2P-Software wichtig.
Darunter fallen Programme wie uTorrent, WoW-Downloadmanager etc.
Wer solche P2P- Programme nutzt und auch Daten an andere Leute korrekt/schnell weitergeben möchte, der braucht für solche Programme auch eine zusätzliche Regel für Eingehende Verbindungen.

Ohne eine Regel für Eingehende Verbindungen kann man zwar weiterhin runterladen, allerdings ist das weitergeben der Daten dadurch eingeschränkt.

PS2:
Im 2. Beitrag könnte man noch unter "Wichtige Protokolle und Remoteports" die FTP-Ports 20 und 21 angeben.


Edit:
Das Problem mit dem Google Chrome hat sich erstmal erledigt, da als Ersatz der Iron genutzt wird (auf Datenschutz getrimmter Chrome).
Dort greift die Regel komischerweise.

Edit2:
Ich habe noch etwas wegen des Problems bei Google Chrome rumgedoktort und die Lösung gefunden.
Nun funktioniert es, es lag an der Pfadangabe ->
Falsch (das legt Windows standardmäßig an):
%USERPROFILE%\AppData\Local\Google\Chrome\Application\chrome.exe
Richtig (den genauen Pfad muss man per Copy&Paste manuell unter "Programme und Dienste" reinkopieren):
C:\Users\Benutzername\AppData\Local\Google\Chrome\Application\chrome.exe
 
Zuletzt bearbeitet:
Info:
Avast! Free Antivirus in der aktuellen Version leitet den Webtraffic über den Avast Service (AvastSvc.exe).
Bekommt diese Datei keine Regel, bekommen die anderen Programme keinen Internetzugang.
Da diese Datei quasi alle Ports braucht, sind alle weiteren speziellen Regeln für Programme nutzlos.

Hart formuliert: Avast Antivirus hebelt die Windows-Firewall aus

Konnte ich heute auf 3 Rechnern testen und reproduzieren.
 
The Prodigy schrieb:
Avast! Free Antivirus in der aktuellen Version leitet den Webtraffic über den Avast Service (AvastSvc.exe).
Kaspersky macht das schon lange; als ich das HowTo geschrieben habe, hat aber Avast! das noch nicht gemacht. Das muss wohl tatsächlich ein "Feature" der neuen Version sein; habe das im Abschnitt "Sonderfall: Programme, die den Netzwerktraffic über sich umleiten" in Post #1 aufgenommen.

Wer eine Whitelist-Firewall benutzen möchte, muss demnach auf Avast! Free Antivirus und Kaspersky Anti-Virus verzichten bzw. die entsprechenden Internet-Security-Versionen mit eigener Firewall benutzen.
 
Zuletzt bearbeitet:
Zurück
Oben