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

Scheinweltname

Lt. Commander
Registriert
Jan. 2008
Beiträge
1.743
HowTo: Firewall auf Whitelist-Modus umstellen

Hinweis (Swn, 25.07.2013): Dieses HowTo wird schon seit längerer Zeit nicht mehr gepflegt.

Das HowTo beschreibt den Umgang mit der Firewall von Windows7 (die Einstellung der Vista-Firewall ist sehr ähnlich, vgl. Posts #7 und #8), lässt sich aber auf alle Software-Firewalls, die ausgehenden Datenverkehr filtern können, übertragen.
Wichtiger Hinweis: Ein Whitelisting mithilfe der Windows-Firewall ist nur dann sinnvoll möglich, wenn kein Programm installiert ist, das Netzwerkverkehr umleitet (z.B. Kaspersky Anti-Virus). Wer eine Security-Suite inkl. eigener Firewall oder eine separate FW installiert hat, müsste die untenstehenden Regeln ggf. in dieser FW eintragen.

Eine Whitelist-Firewall ist nur eine Ergänzung zu einem guten, aktuellen Anti-Virenprogramm!


Motivation: Warum Whitelist?​
Die Standardeinstellungen von Windows wurden so gewählt, dass das Betriebssystem problemlos funktioniert und alle Funktionen, die ein normaler User womöglich nutzen möchte, standardmäßig zugänglich sind. Microsoft geht offensichtlich davon aus, dass Nutzer auf private Netzwerke zugreifen möchten, in denen sie sich mit den Rechnern der Familie, einem gemeinsamen Drucker oder einem NAS verbinden. Auch und gerade die Netzwerkeinstellungen und -dienste wurden so konfiguriert, dass der Nutzer ein Netzwerkgerät nur anzustöpseln braucht, und schon wird es erkannt und kann eingesetzt werden. Nun gibt es aber viele Menschen, die diese Features gar nicht benötigen. Außerdem gibt es Anwender, die gerne die Kontrolle über alle Netzwerkverbindungen der installierten Anwendungen haben möchten. Normalerweise setzen die Werkseinstellungen von Firewalls (auch in Security Suiten) auf Blacklists: Traffic jeder Art wird zugelassen, es sei denn, eine Regel blockiert ihn. Whitelist bedeutet hingegen, dass Datenverkehr jeder Art blockiert wird, außer er ist durch eine Regel zugelassen. Statt also zig Programme einzeln zu blockieren, kann man eine Firewall einfach auf Whitelist umschalten und gezielt nur diejenigen Programme erlauben, die auch wirklich eine Verbindung herstellen können sollen.

Zielgruppe: An wen richtet sich dieses HowTo?
Whitelisting ist ohne Zweifel viel sicherer, aber auch deutlich unbequemer als das Blacklist-Verfahren. Es ist vor allem für User sinnvoll, die nur wenige Programme nutzen, die eine Internetverbindung unterhalten sollen. Oder solche, die ihren Rechner bis auf ausgewählte Anwendungen (z.B. Spiele) vollständig vom Netz abschotten, aber trotzdem noch die Updates für Windows und das Anti-Viren-Programm herunterladen möchten. Das HowTo richtet sich an alle Nutzer, die nur zum Surfen, Spielen und Updaten ihrer Software eine Netzwerkverbindung benötigen.

Grundlegendes Prinzip
Standardmäßig ALLES blockieren und durch möglichst restriktive Regeln nur ausgewählten Prozessen Netzwerkverbindungen erlauben.
Diese Regeln definieren "Ansprüche" an Verbindungsanfragen: Es wird nur dann eine Verbindung zugelassen, wenn alle Punkte einer Regel gleichzeitig erfüllt sind (z.B. korrekter Netzwerkport + korrektes Protokoll + korrekte Zieladresse). Ist das nicht der Fall, wird eine Verbindung blockiert.
Das Whitelisting einer Firewall bedeutet übrigens nicht, dass Programme aufhören würden, Verbindungsversuche zu unternehmen; diese werden aber automatisch blockiert, wenn sie den Regeln nicht entsprechen. Genausowenig bedeutet Whitelistung, dass Programmen z.B. Zieladressen vorgeschrieben würden. Regeln bestimmen nicht, mit wem und wie Programme Kontakt aufnehmen sollen, sondern wie und mit wem sie es dürfen!

Wie und welche Netzwerkdienste aus Sicherheitsgründen deaktiviert werden sollten, wird in Exkurs 2 in Post #2 beschrieben.

Der Nutzen
Trojaner und andere Malware, die unbemerkt von Servern Schadcode herunterzuladen versuchen, werden automatisch blockiert. Und da es mittlerweile überwiegend vertrauenswürdige Webseiten sind, auf denen von Hackern (unsichtbare) iFrames platziert werden, über die dann Malware heruntergeladen wird (aktuelle Fälle z.B. die offizielle(!) Lenovo-Treiber-Downloadseite oder Vodafone UK), bedeutet eine Whitelist-Firewall (inkl. Whitelist-Regeln für Browser) größere Sicherheit, weil die Adressen, zu denen die iFrames Kontakt herstellen, nicht aufgerufen werden können. Entsprechend kann auch kein Schadcode heruntergeladen werden. Darüber hinaus werden Umleitungen auf DNS-Basis unmöglich (z.B. bei der Manipulation der eingestellten DNS-Server oder der Datei hosts). Außerdem lässt sich der Traffic reduzieren, was angesichts der UMTS-Volumentarife sehr nützlich ist. Hinweis: Man sollte niemals die Verbindung von Windows zu Microsoft blockieren, da dann logischerweise kein Windows Update möglich ist.

Warum eine Software-Firewall?
Router-Firewalls sind nützlich, weil sie nicht auf dem Rechner installiert sind und entsprechend nicht von Malware abgeschaltet werden können. Andererseits sind handelsübliche Privatnutzer-Router blind für die Programme, die den Traffic erzeugen. Wer den eigenen ausgehenden Netzwerktraffic nach eigenen Regeln für Programme mit jeweils individuellen Zielen filtern möchte, der kommt um eine Software-Firewall nicht herum. Die Behauptung, dass Software-Firewalls leicht zu umgehen wären, ist falsch. Eine Whitelisted-Firewall bietet sogar Schutz vor dem Szenario, dass ein Systemprozess von Malware infiziert wird: Die Zieladressen und Ports des infizierten Prozesses sind auch diejenigen in der Firewallregel. Das Nachladen oder Verschicken von Schadcode ist so unmöglich. Ganz zu schweigen davon, dass unbekannte Prozesse gar nicht erst Netzwerkkontakt bekommen. Es müsste schon der Firewalldienst abgeschaltet werden, was aber keine Malware kann, wenn nicht der User selbst, manuell und wissentlich(!) ihr Admin-Rechte verleiht (indem er den UAC/ Benutzerkontensteuerung-Dialog bei der Rechte-Anfrage bestätigt). Und derjenige User wäre selber schuld!

Vorbereitungen
... um sie ggf. wiederherstellen zu können. (Systemsteuerung --> Windows Firewall --> Erweiterte Einstellungen --> Regeln --> (Windows Firewall mit erweiterter Sicherheit – Lokaler Computer) „Richtlinie exportieren“)]. Ich übernehme keine Gewähr, dass die Einstellungen, die mit meiner Rechner- und Netzwerkkonfiguration fehlerfrei funktionieren, dies auch bei anderen Hardware-, Software- und Netzwerkkonfigurationen tun. Aus eigenem Sicherheitsbedürfnis heraus sind alle angegeben IP-Adressen und Links mehrfach überprüft; ein Zahlendreher kann aber trotzdem nie ausgeschlossen werden.
Während eine Netzwerkverbindung besteht: Eingabeaufforderung --> ipconfig /all eingeben und den/ die (primären und ggf. sekundären) DNS-Server notieren. Nutzer von Routern werden dort womöglich die Adresse ihres eigenen Routers sehen (192.168.x.x). In diesem Fall reicht diese Adresse für die DNS-Regel für die Firewall (s.u). Usern mit Modem oder direktem Netzwerkkontakt werden die DNS-Server ihrer Provider angezeigt. Diesen Usern empfehle ich dringend, diese Adressen als einzige, feste Zieladressen in der DNS-Regel (s.u.) einzutragen (zum Schutz vor DNS-Umleitungen jeglicher Art).
Einfachste Möglichkeit, IP-Adressen herauszufinden, ist das Windows-Tool nslookup.
Man starte dazu die Eingabeaufforderung oder Powershell und gebe den Ausdruck nslookup gefolgt vom Hostnamen ein (z.B. google.de). Das hat den Vorteil, dass man gar nicht erst einen Browser starten muss. Statt eine "echte" Verbindung mit einem Server herzustellen, fragt man mithilfe dieses Befehls lediglich beim eigenen DNS-Server nach, welche IP-Adresse aufgerufen würde, wenn man z.B. mit einem Browser z.B. ww*w.google.de aufrufen würde. nslookup google.de liefert folgendes (die Adressen können sich zu verschiedenen Zeitpunkten durchaus unterscheiden; gerade bei Diensten, die viele IP-Bereiche nutzen können, wie z.B. Google oder das Windows Update)
PS C:\Windows\System32\WindowsPowerShell\v1.0> nslookup google.de
Server: [mein DNS-Server]
Address: [Adresse meines DNS-Servers]

Nicht autorisierende Antwort:
Name: google.de
Addresses: 209.85.135.104
209.85.135.103
209.85.135.99
209.85.135.147
209.85.135.106
209.85.135.105
Eine kompliziertere Variante:
(Vorteil dieses Vorgehens ist, dass man tatsächlich alle nötigen IP-Adressen, die zum Aufbau einer Webseite nötig sind, sehen kann. Wer z.B. nur die IP-Adresse für "computerbase.de" zulässt, dem werden alle Bilder vorenthalten bleiben, weil "pics.computerbase.de" eine eigene IP-Adresse hat).
Mit dem Server verbinden (z.B. eine Webseite auf- oder E-Mails abrufen)(vor dem Whitelisting!) und in die Eingabeaufforderung (oder Powershell) netstat -n eingeben und die entsprechende Remote-IP-Adresse (und ggf. den Remoteport, falls es sich nicht um die unten angegebenen handelt) notieren (per Rechtsklick kann man mit "markieren" einen anderen Cursor-Modus wählen, damit Text markieren und dann per Strg+C kopieren). Einfacher geht das mit TCPView [2] von Microsoft, das auch die Programme anzeigt, die die Verbindungen aufbauen. So findet sich die IP-Adresse leichter und man kann auch alle Verbindungen als Text-Datei speichern. Manche (besonders SSL-)Verbindungen werden vom Server sehr schnell wieder beendet, dann tauchen die IP-Adressen teilweise nur für wenige Sekunden in den Listen auf. In diesem Falle ist TCPView deutlich bequemer.

Zum Prüfen die IP-Adresse bei einer Whois-Datenbank [3] eingeben und vergleichen, ob das angegebene Unternehmen mit der aufgerufenen Seite übereinstimmt. Wenn nicht, wurde vermutlich die falsche IP-Adresse notiert. Genauso sollte man vorgehen, wenn man auch andere Programme per Whitelisting absichern will: Erst alle Verbindungen für ein Programm zulassen, dann die gewünschte Verbindung herstellen (zur entsprechenden Website, E-Mail-Account usf.), IP-Adressen notieren, CIDR berechnen, Regel erstellen. Dann die Firewall auf Whitelisting umschalten, sodass die gerade notierte Verbindung funktioniert aber alles andere automatisch blockiert wird.
Konfigurationsschritte
  • Schritt 1A: In den Firewalleinstellungen ALLE Regeln für eingehenden Verkehr löschen
    Schritt 1B: Alle Regeln für ausgehenden Verkehr löschen. [Systemsteuerung --> Windows-Firewall --> Erweiterte Einstellungen --> Regeln für ausgehende Verbindungen: Alles markieren und löschen. Das gleiche Prozedere für ausgehende Verbindungen]
  • Schritt 2: In den Einstellungen der einzelnen Profile alles blockieren (für alle drei Netzwerkprofile! Domäne, Privat & Öffentlich), Protokollierung der Verbindungen einschalten (falls gewünscht; das Öffnen der Protokolldatei erfordert Admin-Rechte). [Systemsteuerung --> Windows-Firewall --> Erweiterte Einstellungen --> Windows-Firewalleigenschaften]
    (Die Änderungen gelten jeweils nur für ein Profil. Diese Einstellungen für alle drei Profile vornehmen!)
    • Firewallstatus: Ein (empfohlen)
    • Eingehende Verbindungen: Alle Blockieren (Damit werden auch die eingetragenen Ausnahmen ignoriert!)
    • Ausgehende Verbindungen: Blockieren (mit dieser Einstellung stellt man die Firewall von Blacklist-Modus auf Whitelist-Modus um!)
    • Unter „Einstellungen. Anpassen“: Benachrichtigungen anzeigen: Ja, Unicastantwort zulassen: Nein (nur im Profil „Öffentlich“ muss sie auf „Ja (Standard)“ stehen, ansonsten kriegt man immer nur „Nicht identifiziertes Netzwerk“ zu sehen). Unter "Protokollierung" kann eingestellt werden, ob Windows eine Protokolldatei mit den Adressen der kontaktierten (und/ oder abgelehnten) Server führen soll. Nach meiner Erfahrung hat das keinen negativen Einfluss auf die Geschwindigkeit oder Bandbreite der Netzwerkverbindung).
  • Schritt 3: Regeln für ausgehenden Traffic erstellen [Systemsteuerung --> Windows-Firewall --> Erweiterte Einstellungen --> Ausgehende Regeln --> Neue Regel]

Erstellen von Firewallregeln
  • Diese Regel ist zwingend notwendig, damit Programme Webadressen erreichen können. Beispielhaft wird hier die gemeinte DNS-Regel erstellt. Alle anderen Regeln funktionieren nach dem gleichen Muster
    Systemsteuerung --> Windows-Firewall --> Erweiterte Einstellungen --> Ausgehende Regeln --> Neue Regel.

    DNS-Regel: --> Benutzerdefiniert --> alle Prozesse --> Protokolltyp UDP, Remoteport 53 --> Remote-Adressen (die notierten DNS-Server eintragen!, s.o.) --> Zulassen --> nur „Öffentlich“ wählen --> Namen (und ggf. Beschreibung) --> fertig

    Diese Regel erlaubt allen installierten Programmen, Domainnamen (z.B. google.de) zu IP-Adressen aufzulösen. Man könnte diese Regel auch für jedes zugelassene Programm einzeln erstellen, würde damit aber die Anzahl der Regeln vervielfachen.
  • Diese Regel erlaubt dem Internetbrowser, hinsichtlich der Adressen uneingeschränkt auf Webseiten zuzugreifen, beschränkt aber die zugelassenen Netzwerports auf das benötigte Minimum.
    … Neue Regel --> Benutzerdefiniert --> „Dieser Programmpfad“ (die *.exe des Browsers suchen) --> Protokolltyp TCP, Remoteport 80, 443 --> (beliebige IP-Adressen) --> Verbindung zulassen --> Nur „Öffentlich“ aktivieren --> Namen und Beschreibung --> fertig

    Hinweis zur Regelerstellung für Google Chrome: Post #181.
  • Nutzer mit Programmen, die einen Web-Filter installiert haben, müssen zwingend folgende Regel erstellen: --> Benutzerdefiniert --> [*.exe-Datei des Programms und/ oder des Updaters zum Programm] --> Protokolltyp TCP (andere werden normalerweise nicht benötigt) --> Remote-Adressen: Beliebig (weil auch der Traffic von Browsern und E-Mail-Clients über das AV-Programm umgeleitet wird) --> Zulassen --> Öffentliches Profil --> Namen/ Beschreibung --> fertig
    Hinweis: Avast! 5 Free nutzt einen etwas verkorksten Update-Mechanismus, der eine eigene Regel braucht. Hinweise dazu siehe Post #121

    Unter Umständen umgehen Programme, die den Netzwerkverkehr über sich umleiten, die Filterung durch die WindowsFirewall. Das entsprechende Programm muss zugelassen werden (sonst gibt es kein Internet); alle Netzwerk-Regeln für dieses Programm betreffen aber dann ALLE Prozesse auf dem Rechner (siehe den linken Screenshot und die Regel zu Kaspersky)(übliche Verdächtige sind Anti-Viren-Programme und Security Suiten, aber auch "Traffic Shaping"-Programme)
    • AV-Programme, die Netzwerkverkehr nicht umleiten: Norton AV, Microsoft Security Essentials, Eset NOD32 Anti-Virus, AVG Free
    • Programme, die Netzwerkverkehr umleiten (und damit die Windows-Firewall umgehen): Kaspersky AV, Avast! Free Antivirus, diverse Cfos-Produkte (und andere Netzwerk-Tweaking-Programme).
    Wanted: Infos darüber, wie es sich bei Avira, G-Data usf. verhält, wären sehr hilfreich!
    • Für alle Programme: DNS, UDP-Remoteport 53, Remoteadressen: die notierten DNS-Server
    • Für alle Programme: Kontakt zu Microsoft/ Windows Update, TCP-Remoteports 80 und 443, Remoteadressen: Die Adressen für das Windows Update (siehe Post #2)
    • Browser brauchen nur die TCP-Remoteports 80 und 443.
    • Anti-Virenprogramme müssen noch Updates machen können. Dazu reichen normalerweise TCP-Remoteports 80 und 443 für die Programm-*.exe bzw. den zum Programm gehörigen Updater (muss nicht im Standard-Programmordner liegen!); als Zieladressen entweder direkt die Update-Server eingeben, oder ohne Adresse (man sollte einem AV-Programm vertrauen können). Die Microsoft Security Essentials und der Defender brauchen keine eigene Regel, wenn die vorgeschlagene Kontakt-zu-Microsoft-Regel eingestellt wird.
 
Zuletzt bearbeitet: (Bilder entfernt, da nicht mehr bei Bilder-Hoster vorhanden.)
Wichtige Protokolle, Remoteports und Adressen

  • UDP 53 --> DNS, auflösen von URL zu IP-Adressen
  • (DHCP braucht keine eigene Regel, weil die Windows-Firewall darauf automatisch reagiert)
  • TCP 80 --> HTTP, Internet
  • TCP 443 -->HTTPS, sichere SSL-Verbindungen
  • TCP 465 --> SSL/TLS-SMTP, sicherer E-Mail-Versand
  • TCP 993 --> SSL/TLS-IMAP, sicherer E-Mail-Empfang
  • POP3 und ungesicherte IMAP/ SMTP-Verbindungen nutzen andere Ports.
  • Spiele nutzen sehr häufig Ports jenseits der 5000 (von 65535 möglichen).
  • Eine Liste häufig genutzer Ports gibts bei Wikipedia [5].
Hinweis: Diese Liste wird - jedenfalls vorerst - nicht mehr gepflegt.

Windows greift für Windows Update und die Signatur-Updates von Windows Defender und Microsoft Security Essentials relativ flexibel auf mehrere IP-Adressen zurück (je nachdem, wie gerade die entsprechenden Hostnamen wie etwa download.windowsupdate.com per DNS aufgelöst werden). Für das Update ist der Systemprozess svchost.exe ("Hostprozess für Windows-Dienste") zuständig (taucht wegen seiner vielfältigen Aufgaben mehrfach im Taskmanager auf).
Damit Windows Update durch eine Whitelist-Firewall möglich ist, müssen die TCP-Remoteports 80 und 443 für den Prozess svchost.exe zu den entsprechenden Adressen freigegeben werden (Anmerkung: svchost.exe liegt immer im Ordner C:\Windows\System32 bzw. %systemroot%\system32; liegt sie woanders, stimmt etwas nicht).

Folgende IP-Adressen-Bereiche musste ich schon mindestens einmal freigeben, um ein Windows Update bzw. Signatur-Update für Microsoft Security Essentials durchführen zu können (die häufigsten Adressen sind fett formatiert, neue Einträge sind grün).

Microsoft
  • 65.52.0.0/14
  • 207.46.0.0/16
  • 213.199.144.0/20
  • 94.245.64.0/18
Akamai Technologies
  • 217.89.105.128/25
  • 208.29.69.128/25 (Akamai @ Sprintlink)
  • 208.19.38.0/24 (Akamai @ Sprintlink)
  • 208.28.236.128/25 (Akamai @ Sprintlink)
  • 195.145.147.0/24 (Akamai München)
  • 80.157.170.0/24 (Akamai Düsseldorf)
  • 80.157.150.0/24 (Akamai Frankfurt)
  • 77.67.0.128/25 (Akamai TINET)
  • 213.254.249.0/24 (Akamai TINET)
    [*]62.41.0.0/16 (KPN Eurorings)
  • 62.41.80.0/24 (Akamai Amsterdam)
  • 96.6.0.0/15 (Akamai)
  • 96.16.0.0/15 (Akamai)
  • 95.100.96.0/20 (Akamai PA)
  • 165.254.6.0/24 (Akamai @ NTT)
  • 205.247.221.0/24 (Akamai @ Sprintlink)
  • 81.52.205.128/25 (Akamai-FT-UK)
  • 81.52.140.0/24 (Akamai-FT-FR)
  • 194.221.64.0/24 (CW-Akamai-Net)
  • 195.59.126.0/24 (CW-Akamai-NET)
  • 62.156.238.0/24 (Akamai Frankfurt)
  • 80.154.79.0/24 (Akamai Frankfurt)
  • 216.246.66.0/23 (Akamai @SCNET)
  • 217.7.48.0/24 (Akamai Amsterdam)
    [*]80.239.228.0/25 (Akamai/ Telianet)
    [*]46.33.64.0 - 46.33.77.255 (Akamai TINET)
    [*]66.171.231.0/24 (Akamai@NLayer)
Level 3 Communications
  • 199.92.0.0/14
  • 207.120.0.0/14
  • 4.0.0.0/8 , 8.0.0.0/8 (**) (Anmerkung: Auch wenn mir Adressen aus diesem Bereich beim Windows Update schon mehrfach begegnet sind, rate ich vom Freigeben dieses riesigen Bereichs ab!)
Global Crossing
  • 207.138.0.0/16
  • 217.156.128.0/17
  • 64.212.0.0/14
    [*]64.211.0.0 - 64.211.223.255
  • 206.132.192.0/18

Hinweis: Auch wenn sich Probleme beim Windows Update leicht durch den Verzicht auf feste Ziel-Adressen vermeiden lassen, sollte man für svchost.exe niemals Regeln ohne solche Adressen erstellen (bzw. sollte solche Regeln nur gezielt und kurzfristig aktivieren)! Denn dieser Prozess enthält eine Programmschnittstelle, die (nur authorisierte?) Programme benutzen können, um Netzwerkverbindungen aufzubauen. Beispiel: Der Adobe Reader kann über svchost.exe die Verbindungen zu seinen Updateservern herstellen!
Einige CIDR-Bereiche (Ohne Sortierung)
  • Die meisten größeren Unternehmen besitzen mehrere Netblocks; die Angaben sind nicht vollständig. Ich begegne alle Nase lang neuen IP-Adressen z.B. von Akamai oder Google.

    [*]VeriSign
    199.7.71.0/24, 199.7.72.0/22, 199.7.76.0/24, 199.7.48.0/20, 199.16.80.0/20 (svchost.exe prüft beim Starten von digital signierten *.exe-Dateien die Gültigkeit der Signatur mithilfe von VeriSign-Servern; d.h. eine Freigabe der VeriSign-IPs ist sinnvoll)​
  • Google und Youtube
    74.125.0.0/16, 173.194.0.0/16 [#], 209.85.128.0/17, 72.14.192.0/18, 208.117.224.0/19. Hinweis: Wer Youtube und andere Google-Dienste nicht braucht, sollte diese [#] CIDR nicht erlauben. Ich beobachte quasi permanente Verbindungen zu Adressen aus diesem Bereich, egal, welche Seiten ich aufrufe. Hängt vermutlich mit Google-Scripten und -Ads zusammen.​

    [*]Akamai
    212.201.100.128/26, 92.123.48.0/21, 92.122.176.0/21, 217.89.105.128/25, 80.157.170.0/24​
  • Adobe
    192.150.8.0/24​

    [*]Computerbase
    87.230.75.0/24 (HostEurope) (bei Firewalls, die auch Hostnamen verstehen (wie die von Kaspersky), reicht es, "computerbase.de" und "pics.computerbase.de" freizugeben).​
  • Geizhals.at
    213.229.61.32/29​

    [*]Spiegel Online
    195.71.8.0/22 (Telefonica München)​
  • [gelöscht, SWN]
    [*]heise.de
    193.99.144.0/24​
  • Blizzard (World of Warcraft)
    80.239.186.0/24​
    [*][gelöscht, SWN]
  • Web.de
    217.72.192.0/20, 213.165.64.0/23 und ggf. 213.165.66.0/25 (vgl. Post #144 - #146)​

    [*]Finanz Informatik GmbH & Co. KG (Server der/ vieler Sparkassen)
    195.140.0.0/17​
  • Gibson Research Corporation (GRC ShieldsUp!)
    4.79.142.192/28​

    [*]Amazon.de
    etwas kompliziert ... siehe Post #125
  • Wikipedia
    91.198.174.0/24​

    [*]SELFHTML (HTML/ CSS -Tutorials)
    213.198.84.176/28​
  • PCTools @ ThePlanet (für Updates von ThreatFire)
    64.246.4.64/27​
    ... to be continued

    Hinweis Der Umgang mit dem zum IP-Adressen-Herausfinden extrem nützlichen Windows-Tool nslookup wird im Abschnitt "Wichtige IP-Adressen herausfinden" in Post #1 beschrieben.

####
Allgemeine Hinweise

  • Stellt bei Problemen mit dem Netzwerk zuerst probehalber die Standard-Konfiguration wieder her (vorher die Einstellungen exportieren! s.o.). Wenn ihr keine Routerfirewall habt, solltet ihr die Firewall niemals ganz abschalten (da sonst alle Ports für Zugriffe von außen offen sind).
  • Wer kein Heimnetzwerk unterhält (für Drücker, NAS oder so), der sollte allen seinen Netzwerken das Profil "Öffentliches Netzwerk" zuordnen, weil so die Freigabeeinstellungen automatisch maximal eingeschränkt werden. Vergleiche post #10.
  • Es ist außerdem sinnvoll, in den Adaptereinstellungen der (WLan-)Netzwerkkarte alle Einträge bis auf "IPv4" zu deinstallieren ((bei IPv6 das Häkchen entfernen; etwaige Filter von installierten Antiviren-Programmen (wie der NDIS-Filter von Kaspersky, siehe Screenshot) müssen aktiv bleiben). Besonders der "Datei-und Druckerfreigabe"-Client sollte deinstalliert werden, wenn kein Heimnetzwerk vorhanden ist.
  • Das in diesem HowTo beschriebene Vorgehen funktionierte bei mir sowohl in Verbindung mit einem Router (DHCP-IP-Vergabe), als auch direkt am DSL-Modem (per PPPoE zum Provider), sowohl mit einer Internet Security Suite (+Firewall), als auch ohne.
  • 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 [1].
Exkurse
  • Exkurs 1: Erzeugen des CIDR-Ausdrucks (IP-Adressen-Bereich-Ausdruck mit der Zahl hinterm /)

    Ein Whitelisting ist ohne CIDR (Classless Inter-Domain Routing)[4] undenkbar. Damit ist gemeint, dass man nicht jede IP-Adresse einzeln eingibt, sondern ganze IP-Adressen-Bereiche. Firewalls verstehen den Ausdruck 192.168.0.0 – 192.168.255.255 nicht (auch wenn die Windows-Firewall erlaubt, jeweils erste und letzte Adresse einzugeben und versteht so ebenfalls den Bereich). Folgende Schreibweise erfasst den gleichen IP-Bereich, ist aber viel kürzer und wird von allen Firewalls verstanden: 192.168.0.0/16
    Die CIDR-Bereiche findet man nur sehr selten direkt im Netz (komisch eigentlich, das könnte Firewalls so viel sicherer machen). Auch IP-Whois-Dienste [3] geben meistens nur den Bereich an, aber nicht die Zahl hinter dem Slash. Wenn man nun also die IP-Adresse eines der Server hat, die man Whitelisten möchte, dann gibt man diese Adresse bei einem WhoIs-Dienst [3] ein und kann dort dann den gesamten Bereich ablesen. Um Probleme mit „echten“ IP-Adressen zu vermeiden, nehme ich Beispiele aus lokalen Netzwerken. Die Berechnung ist immer identisch (diese Berechnung ist extrem vereinfacht, führt aber dennoch ans Ziel. Was genau diese Zahl hinter dem Slash nun inhaltlich ausdrückt, ist hier nicht von Belang).

    Beispiel: Man möchte die Webseite von Unternehmen XY whitelisten. Man ruft also diese Seite mit einem Browser auf und notiert sich die IP-Adressen (z.B. mit geöffnetem TCPView[2]). Eine könnte z.B. lauten: 192.168.245.13. Das gibt man bei einem IP-Whois-Dienst [3] ein und erfährt, dass das Unternehmen folgenden Bereich von IP-Adressen besitzt (fiktiv!):
    192.168.240.0 bis 192.168.255.255

    Aus diesen beiden muss man nun ableiten, wie viele IP-Adressen das Unternehmen mit diesem Bereich vergeben kann. Eine IP-Adresse besteht aus vier Blöcken, die je durch einen Punkt getrennt sind. Jeder Block kann Werte von 0 bis 255 annehmen. Man muss nun die erste Adresse des Bereichs (192.168.240.0) mit der letzten (192.168.255.255) vergleichen. Bei diesem Vergleich notiert man, wie viele Adressen schon fest vergeben sind.

    Beispielrechnung
    192.168.240.0 (erste Adresse des Bereichs)
    192.168.255.255 (letzte Adresse des Bereichs)
    ______________

    192-192 = 0 --> kein Wert ist flexibel, alle 255 möglichen Werte sind vergeben --> 255.
    168-168 = 0 --> s.o. --> 255.
    240-255 = (-)15 --> von insgesamt 255 möglichen Werten sind 15 flexibel --> 255-15 = 240 sind fest vorgegeben--> 240.
    0-255 = (-)255 --> alle 255 möglichen Werte sind flexibel, d.h. 0 sind fest vorgegeben --> 0

    Jetzt hat man den Wert 255.255.240.0 (das ist die Subnetzmaske). Diesen vergleicht man mit der Liste auf Wikipedia[4] und sucht die dazugehörige „Notation“. Dort steht dann der Ausdruck mit dem Slash, für mein Beispiel ist es /20.

    Der CIDR-Ausdruck im Beispiel lautet also: 192.168.240.0/20 (den Slash-Ausdruck immer an die erste Adresse des Bereichs anhängen).
    Hinweis:
    In aller Regel sind die errechneten Subnetzmasken und CIDR-Suffixe eindeutig. In Fällen, in denen das nicht so ist (z.B. in einem Fall von VeriSign) müssen meistens mehrere kleinere statt einer großen errechnet werden. Dabei rate ich vom Netzwerk-Rechner von heise ab, weil dieser immer größere statt kleinere Bereiche errechnet, sodass zuviele IPs erfasst würden. Im CIDR-Artikel auf Wikipedia [4] steht ganz unten ein Link zu einem CIDR-Calculator, der die kleineren Bereiche korrekt berechnet.​
________________________________________
Fußnoten
[1] Heise: http://www.heise.de/security/dienste/portscan/test/go.shtml?scanart=1
GRC ShieldsUp!: https://www.grc.com/x/ne.dll?bh0bkyd2 (auf "proceed" klicken; die Port-Test-Seite ist leider nicht direkt verlinkbar). Die Ergebnisse lauten im besten Fall für alle Ports "gefiltert" (Heise) oder "stealth" (GRC).
[2] TCPView von Sysinternals/ Microsoft: http://technet.microsoft.com/de-de/sysinternals/bb897437.aspx
[3] Umfangreiche Whois-Abfrage: http://www.heise.de/netze/tools/whois/
[4] Wikipedia CIDR: http://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing
[5] Eine Liste wichtiger Netzwerkports bei Wikipedia: http://de.wikipedia.org/wiki/Port_(Protokoll)

###################################
Changelog
(... da dieses HowTo doch schon so manche nicht unerhebliche Veränderung erfahren hat)
3.8.2010
  • Hinweise zum Windows-Tool nslookup hinzugefügt (Posts #1 und #2)
  • Hinweis zum Umgang mit nicht eindeutigen CIDR/ Subnetzmasken hinzugefügt (Post #2)
  • CIDR der Kaspersky-Update-Server entfernt (falsch)
15.8.2010
2.9.2010
  • CIDR von SELFHTML hinzugefügt
  • CIDR-Bereiche von Web.de ergänzt
3.9.2010
  • Korrekturen an Formulierungen, u.a. bei den Hinweisen zu den am WindowsUpdate beteiligten CIDR
  • CIDR von und Verweise auf syndicat.whois entfernt. Der Server machte in letzter Zeit sehr viele Probleme.
5.9.2010
  • Komplette (total übertriebene ;) ) Überarbeitung des Layouts mithilfe dieses gei.en neuen spoiler-Tags
  • Einige Formulierungen überarbeitet
14.9.2010
  • CIDR von Akamai @Sprintlink (für das WinUpdate) ergänzt
15.9.2010
  • Weitere CIDR von Youtube ergänzt
16.9.2010
  • Kleinere Korrekturen in Bezug auf Infos zu Google/ Youtube
  • Die Wörter "Netblock" und "IP-Adressen-Bereich" an mehreren Stellen eingefügt, damit Google dieses HowTo mit mehr Suchbegriffen verknüpft
  • Kleine (Formatierungs-)Änderungen in Exkurs 2
17.9.2010
  • Noch eine Akamai@Sprintlink-CIDR für das Windows Update ergänzt
6.10.2010
  • Eine Liste von nur unregelmäßig am Windows Update beteiligten Netblocks hinzugefügt
  • Änderungen an der Beschreibung zum Windows Update/ svchost.exe
9.10.2010 + 11.10.2010 + 13.10.2010 + 26.10.2010 + 31.10.2010 + 21.11.2010 + 14.12.2010 + 23.12.2010 + 25.12.2010 + 7.1.2011 + 9.2.2011 + 11.2.2011
  • Neue Netblocks für das WinUpdate hinzugefügt
13.2.2011
  • CIDR von PCTools/ ThreatFire hinzugefügt
14.2.2011 + 19.5.2011
  • Neuen Netblock für das WinUpdate hinzugefügt
21.5.2011
  • Neuen Netblock für das Winupdate; Übersicht über WinUpdate-Bereiche umformatiert
9.9.2011
  • Neue Netblocks für das Winupdate hinzugefügt
 
Zuletzt bearbeitet: (Bilder entfernt, da nicht mehr bei Bilder-Hoster vorhanden. Abschnitt "Exkurs 2" entfernt.)
Sehr interessant, und sicherlich viel Arbeit, werde ich mir später nochmal genauer durchlesen. :) Leider bin ich mit Vista und XP noch außen vor.

Bis dato benutze ich für solche Zwecke nie die Windows-Lösung sondern Comodo Firewall.
Die Einstellungsöglichkeiten und Regeln sind hier sehr komfortabler zu nutzen und mächtig.
Stellt man z.B. die "Alert Settings" auf "Very High" wird bei jedem Programm für jede IP und jeden Port eine Anfrage gestellt, wodurch man nach einer gewissen Zeit seine Filterregeln perfektioniert hat.
Auch wenn man einen VPN benutzen will kann man so sehr gut verhindern dass außer mit dem DNS-Server und der IP-Range des VPN-Anbieters keinerlei andere Verbindungen über die eigene IP möglich sind.
 
x.treme schrieb:
Stellt man z.B. die "Alert Settings" auf "Very High" wird bei jedem Programm für jede IP und jeden Port eine Anfrage gestellt, wodurch man nach einer gewissen Zeit seine Filterregeln perfektioniert hat.
genau deswegen hab ich den Exkurs über den CIDR-Ausdruck hinzugefügt! Denn allein google.de kann über zig verschiedene Server aufgerufen werden (von Youtube ganz zu schweigen). Dann hast du am Ende hunderte Regeln, die für das betreffende Programm jeweils eine einzelne IP-Adresse zulassen.

Aber man kann sich mit Nachfrage-Pop-Ups immerhin die Mühe sparen, die einzelnen IP-Adressen mühselig zu notieren. Stattdessen kommt ein Pop-Up mit der IP-Adresse, von der aus man dann mit den im HowTo beschriebenen Schritten den CIDR-Ausdruck bestimmen kann. So entstehen dann immerhin "nur" einzelne Regeln für einzelne Unternehmen/ Webseiten.
 
Die Methode mit den PopUps empfielt sich auch nicht wirklich für Browser, doch bei anderen Programmen ist es sinnvoll um ihnen das Nach-Hause-Telefonieren abzugewöhnen, und nur die Verbindungen zu erlauben die wirklich benötigt werden. Außerdem hat man dadurch wie bereits gesagt einen guten Überblick, zu was überhaupt verbunden wird.

Bei Browsern sehe ich für die meisten auch keinen großen Sinn in einer Whitelist. Scripts, Flash und vieleicht noch Cookies nur für bekannte Seiten erlauben, dazu noch einen Werbeblocker/Blacklist um die bekannten Spione wie Analytics zu verbieten ... mehr ist eigentlich nicht nötig.
 
x.treme schrieb:
Die Methode mit den PopUps empfielt sich auch nicht wirklich für Browser.
vollkommen richtig. Richtig "Surfen" (z.B. recherchieren, bequem verlinkte Bilder aus dem Forum öffnen usf.) kann man mit einer Whitelist-Firewall oder ständigen Pop-Ups nicht wirklich; jedenfalls nicht ohne Wutausbrüche, Stahlseilnerven und Engelsgeduld (die Bilder im HowTo liegen z.B. auf den Servern von Abload. Wer deren Adressen nicht erlaubt hätte, könnte die Bilder nicht sehen). Es ist aber nützlich, wenn man eh nur wenige Ziele aufruft (z.B. Online-Banking). Außerdem ist man so geschützt, wenn eine Website versucht, über irgendeine Lücke Malware zu laden: Der Browser kann gar nicht auf den betreffenden Malwareserver zugreifen!

Man kann ja auch zwei verschiedene Regeln erstellen und je nach Bedarf eine Deaktivieren/ Aktivieren. Ich käme z.B. nicht auf die Idee, andere Verbindungen zuzulassen, wenn ich online spiele ... mein Ping ist sowieso schon zu hoch. Wenn ich surfen will, aktiviere ich wiederum eine andere Regel.
 
Hey Scheinweltname, da haste dir aber mal Mühe gemacht, vielen Dank :D


Aber ich muss zugeben, für mich das alles schon fast etwas zu "hoch" ^^
Es steht eigentlich alles da was ich will, nur mit dem Umsetzen und verstehen funkt es bei mir nicht so ganz :freak: :D

Für die Windows Updates musste ich bei den ausgehenden Regeln, Port 80 und 443 einrichten. Dann klappt es mit dem Windows-Update trotz blockirung des Domänenprofils, Private Profil und das Öffentliche Profill für die ausgehende Verbindung.



… Neue Regel --> Benutzerdefiniert --> „Dieser Programmpfad“ (die *.exe des Browsers suchen) --> Protokolltyp TCP, Remoteport 80, 443 --> (beliebige IP-Adressen) --> Verbindung zulassen --> Nur „Öffentlich“ aktivieren --> Namen und Beschreibung --> fertig

Warum nur „öffentlich“? Weil die Regeln dadurch noch stärker eingeschränkt werden und vermieden wird, dass bei falscher Zuordnung des Netzwerktyps (z.B. Internet als Privat) Internetverbindungen hergestellt werden können.

Habe ich genau so gemacht.
Aber Internetseiten lassen sich nur dann öffnen, wenn ich den Haken bei Privat stehen lasse.
Setze ich den Haken nur bei Öffentlich, kommt beim ansurfen einer Seite :Fehler: Verbindung fehlgeschlagen.

Kanns daran liegen, weil bei mir AKTIV hinterm privaten Profil steht ?
Bei dir steht es ja nur hinter öffentliches Profil.
 
Zuletzt bearbeitet:
x.treme schrieb:
Sehr interessant, und sicherlich viel Arbeit, werde ich mir später nochmal genauer durchlesen. :) Leider bin ich mit Vista und XP noch außen vor.

Vista bietet nahezu die gleichen Firewalleinstellungen, da sollte das hier beschriebene genau so funktionieren. Jedenfalls habe ich das 2006 schon mit Vista auch so gemacht ^^.

Sehr schöner Guide :-)
 
Da habe ich mich auf Scheinweltnames Einleitungssatz verlassen ;)
Aber jetzt wo du es sagst: Auführen -> wf.msc und dann öffnet sich der "Windows Firewall mit erweiterter Sicherheit", siehe auch diesen Artikel ... aber warum muss Microsoft das auch so verstecken, da kommt doch keiner alleine drauf xD
 
Falkner schrieb:
Kanns daran liegen, weil bei mir AKTIV hinterm privaten Profil steht ?
Bei dir steht es ja nur hinter öffentliches Profil.
Ja, das wäre logisch, denn du hast ja die Regel für Netzwerke mit dem Profil "öffentlich" erstellt. Wenn du nun aber ein "Privates" Netzwerk hast, dann wird diese Regel darauf nicht angewendet (es sei denn, du setzt auch den Haken bei "Privat" bzw. "Domäne").

Allerdings: Die Netzwerk-Typen haben vor allem den Sinn, Standard-Netzwerkeinstellungen nach Profilen zu sortieren, sodass man nicht jedes Netzwerk einzeln konfigurieren muss. Dabei ist es mit den Windows-Standard-Einstellungen eine große Sicherheitslücke, wenn das Internet "Privat" ist, denn dann ist für das gesamte Internet deine Datei- und Druckerfreigabe aktiv und die Netzwerkerkennung ist eingeschaltet (müsste man erst manuell ändern). Internet muss immer "Öffentlich" sein, weil nur in diesem Profil standardmäßig alles bezüglich Netzwerkfreigaben etc. deaktiviert ist. "Privat" sind Netzwerke zwischen den Rechnern der Familie und dem gemeinsamen Drucker, oder so.

WindowsHilfe-Datei schrieb:
Öffentliches Netzwerk für Netzwerke an öffentlichen Orten aus (z.B. Internetcafés und Flughäfen). Diese Netzwerkadresse verhindert, dass der Computer für andere Computer in der Umgebung sichtbar ist. Außerdem trägt sie dazu bei, den Computer vor Schadsoftware aus dem Internet zu schützen. Die Heimnetzgruppe ist in öffentlichen Netzwerken nicht verfügbar, und die Netzwerkerkennung ist deaktiviert. Sie sollten diese Option auch auswählen, wenn Sie ohne Verwendung eines Routers direkt mit dem Internet verbunden sind, oder wenn Sie eine mobile Breitbandverbindung verwenden.

Du solltest also unbedingt dein Netzwerk auf "öffentlich" umschalten! (bei bestehender Verbindung: Systemsteuerung --> Netzwerk & Freigabecenter --> (unter "Aktive Netzwerke anzeigen" auf den Link unter dem Netzwerknamen (bei dir müsste "Privates Netzwerk" stehen)) --> draufklicken und dann "Öffentliches Netzwerk" wählen.

JP-M schrieb:
Vista bietet nahezu die gleichen Firewalleinstellungen, da sollte das hier beschriebene genau so funktionieren. Jedenfalls habe ich das 2006 schon mit Vista auch so gemacht ^^.
da nutzt man fast 2 Jahre Vista und hats nicht mitbekommen ^^. Werd den Einleitungssatz ändern.
 
Zuletzt bearbeitet:
Danke, habs gefunden und auf öffentlich gestellt.



Habe die google/youtube CIDRs bei meiner Firefoxregel eingetragen.
Konnte danach auch die seiten aufrufen.
Nach einem Neustart aber konnte ich google nicht mehr aufrufen. Musste dann einen ganz anderen CIDR eintragen den ich erst noch berechnen musste: 72.14.192.0/18
Danach gings wieder.


Und hier noch eine CIRD für die World of Warcraft Seite. 80.239.186.0/24
Vielleicht sollten sich die Leute den in die Whitelist packen um nicht auf gefakten WoW Seiten zu gelangen ^^



E-Mail-Clients sollten am besten nur TCP Remoteports 465 und 993 nutzen

Bei mir: Thunderbird (Email bei web.de) gehts mit den beiden Ports nicht, aber mit Port 995 funktioniert es. Ist vielleicht von Emailanbieter zu Emailanbieter unterschiedlich...

Port 465 = smtp protocol over TLS | SSL (was ssmtp) (TCP/UDP)
Port 994 = irc protocol over TLS | SSL (TCP/UDP)
Port 995 = pop3 protocol over TLS | SSL (was spop3) (TCP/UDP)


Und noch eine Verständnisfrage zu:

Für svchost: TCP-Remoteports 80 und 443 zu den Windows-Update Adressen (sinnvoll ist auch, die Windows-Update-Adressen und auch die IPs von Verisign für alle Programme freizugeben. Ist wohl unwahrscheinlich, dass von Microsoft-Servern Malware verbreitet wird.)

und

Für Windows Update und die Signatur-Updates von Windows Defender und Microsoft Security Essentials[*]
Microsoft: 94.245.64.0/18, 65.52.0.0/14, 207.46.0.0/16, 213.199.144.0/20


Habe eine Benutzerdefinierte Regel mit svchost.exe erstellt. Bei der erstellung kam eine Warnung, siehe screen. Ich hoffe es war richtig auf "ja" zu klicken ?
Und die genannten CRIDs
94.245.64.0/18
65.52.0.0/14
207.46.0.0/16
213.199.144.0/20

habe ich dann beim nächsten Schritt im unteren Feld bei Remote IP-Adresse hinzugefügt.

Habe ich das jetzt richig gemacht ?
Oder muss das für das WindowsUpdate anders gemacht werden ?
WindowsUpdates funktionieren bei mir auch wenn ich einfach eine Regel erstelle in der für alle Programme Port 80 und 443 freigeschlatet ist. Aber das soll vermutlich nicht so gemacht werden ... sondern speziell für die Win-Updates eingestellt werden, nur wie genau weiß ich noch nicht.



Bei

Eine Regel ist zwingend notwendig, damit überhaupt eine Internetverbindung möglich ist, nämlich der Zugriff der Programme auf den DNS-Server. Beispielhaft wird hier die entsprechende Regel erstellt. Alle anderen Regeln funktionieren nach dem gleichen Muster
und
Für alle Programme: DNS UDP-Remoteport 53, Remoteadressen: die notierten DNS-Server

Bei dir sehe ich, dass du bei deiner Regel für den Port 53: DNS (UDP) für alle Programme noch extra Remoteadressen eingetragen hast.
Was sollte man dort für Remoteadressen eintagen ? Ich habe dort keine eingetragen und den Punkt/Haken bei beliebige IP-Adresse belassen weil Port 53 doch für alle Programme gelten soll die ins Internet wollen oder nichts ?
 

Anhänge

  • bild.jpg
    bild.jpg
    42,7 KB · Aufrufe: 787
Zuletzt bearbeitet:
Falkner schrieb:
Habe die google/youtube CIRDs bei meiner Firefoxregel eingetragen.
Konnte danach auch die seiten aufrufen.
Nach einem Neustart aber konnte ich google nicht mehr aufrufen. Musste dann einen ganz anderen CRID eintragen den ich erst noch berechnen musste
Danach gings wieder.
du hättest auch einfach mehrfach im Browser neu laden können. google.de wird immer von verschiedenen Servern ausgeliefert. Nach ein paar Mal Neuladen der Seite wäre dann auch wieder eine White-Listed-Server drangewesen. Aber Google hat eh viele CIDR. Übrigens lautet die CIDR "72.14.192.0/18" (die Subnetzmaske ist 255.255.192.0), der Ausdruck von dir macht keinen Sinn. Für /16 müssen die beiden letzten Stellen immer x.x.0.0 sein (255.255.0.0). Du hast mit deinem CIDR-Ausdruck mit der /16 auch IP-Adressen der "Seattle Cancer Care Alliance" und "Fastfreedom.net" freigegeben ^^ (je höher der Wert hinter dem /, desto weniger IP-Adressen werden erfasst).

Falkner schrieb:
Bei mir: Thunderbird (Email bei web.de) gehts mit den beiden Ports nicht, aber mit Port 995 funktioniert es. Ist vielleicht von Emailanbieter zu Emailanbieter unterschiedlich...

Port 465 = smtp protocol over TLS | SSL (was ssmtp) (TCP/UDP)
Port 994 = irc protocol over TLS | SSL (TCP/UDP)
Port 995 = pop3 protocol over TLS | SSL (was spop3) (TCP/UDP)
die von mir angegebenen E-Mail-Ports gelten für SSL-IMAP (993) und SSL-SMTP (465). Wer andere Protokolle benutzt, um seine Mails abzurufen, der braucht andere Ports.

Falkner schrieb:
Habe eine Benutzerdefinierte Regel mit svchost.exe erstellt. Bei der erstellung kam eine Warnung, siehe screen. Ich hoffe es war richtig auf "ja" zu klicken ?
Und die genannten CRIDs
94.245.64.0/18
65.52.0.0/14
207.46.0.0/16
213.199.144.0/20

habe ich dann beim nächsten Schritt im unteren Feld bei Remote IP-Adresse hinzugefügt.

Habe ich das jetzt richig gemacht ?
Oder muss das für das WindowsUpdate anders gemacht werden ?
Die Warnung erscheint bei allen Systemdiensten. Dein WindowsUpdate wird aber nicht funktionieren, weil du die Adressen von Limelight nicht zugelassen hast. Die hosten die Dateien von Microsoft. Zusammen mit den Limelight-Adressen sollte es aber für das Win-Update ausreichen, den svchost so einzurichten. Falls es falsch eingestellt ist, bekommst du beim WinUpdate eine Fehlermeldung, die auf "EFD" endet. Das deutet immer auf Firewallprobleme hin (falls eine Internetverbindung an sich vorhanden ist).

Falkner schrieb:
WindowsUpdates funktionieren bei mir auch wenn ich einfach eine Regel erstelle in der für alle Programme Port 80 und 443 freigeschlatet ist. Aber das soll vermutlich nicht so gemacht werden ... sondern speziell für die Win-Updates eingestellt werden, nur wie genau weiß ich noch nicht.
wenn du für alle Programme die Ports 80 und 443 zulässt, kannst du die Firewall genausogut auch auf Blacklist lassen, denn die beiden ports sind nunmal die Wichtigsten. Fast alle Verbindungen laufen über diese Ports. Dazu zählt aber auch Malware und Programme, die nach Hause telefonieren.

Falkner schrieb:
Bei dir sehe ich, dass du bei deiner Regel für den Port 53: DNS (UDP) für alle Programme noch extra Remoteadressen eingetragen hast.
Was sollte man dort für Remoteadressen eintagen ? Ich habe dort keine eingetragen und den Punkt/Haken bei beliebige IP-Adresse belassen weil Port 53 doch für alle Programme gelten soll die ins Internet wollen oder nichts ?
Die Ip-Adressen sind die zwei DNS-Server meines Providers. Das solltest du auch bei dir eintragen, weil die Regel nur so vor DNS-Umleitungen usf. schützt. Guck mal im Abschnitt "Vorbereitungen", wie du deine DNS-Server rausfinden kannst und gib sie in der Regel als Remote-IP-Adressen ein.

Ich würde aber nicht nur die DNS-UDP-53-Regel (mit deinen DNS-Servern als Ziel) für alle Programme anwenden. Ich würde auch die TCP-Ports 80 und 443 für alle Programme aber nur zu ausgewählten Zielen zulassen. Zu diesen Zielen würde ich z.B. die Adressen von Microsoft, Limelight und VeriSign zählen. Damit ersparst du dir viele Regeln für Microsoft-Programme und Systemdienste (dann kannst du dir auch die Warnung ersparen).
 
Zuletzt bearbeitet:
Scheinweltname schrieb:
Übrigens lautet die CIDR "72.14.192.0/18" (die Subnetzmaske ist 255.255.192.0), der Ausdruck von dir macht keinen Sinn. Für /16 müssen die beiden letzten Stellen immer x.x.0.0 sein (255.255.0.0). Du hast mit deinem CIDR-Ausdruck mit der /16 auch IP-Adressen der "Seattle Cancer Care Alliance" und "Fastfreedom.net" freigegeben ^^ (je höher der Wert hinter dem /, desto weniger IP-Adressen werden erfasst).

Gut das dir das aufgefallen ist !
Habs zwar richtig aufgeschrieben aber falsch eingetippt. :freak: :lol:
Werde es korrigieren.


Die Warnung erscheint bei allen Systemdiensten. Dein WindowsUpdate wird aber nicht funktionieren, weil du die Adressen von Limelight nicht zugelassen hast. Die hosten die Dateien von Microsoft. Zusammen mit den Limelight-Adressen sollte es aber für das Win-Update ausreichen, den svchost so einzurichten. Falls es falsch eingestellt ist, bekommst du beim WinUpdate eine Fehlermeldung, die auf "EFD" endet. Das deutet immer auf Firewallprobleme hin (falls eine Internetverbindung an sich vorhanden ist).


Komisch, ich bekomme keine Fehlermeldung und bekomme immer 2 optional verfügbare Updates zu sehen die ich aber nicht will ^^
Für die svchost.exe habe ich eine ausgehende Regel nur mit Port 80 und 443 erstellt und die Updates funktionieren soweit.
Habe jetzt auch diese Adressen in die Regel eingefügt:

* Microsoft: 94.245.64.0/18, 65.52.0.0/14, 207.46.0.0/16, 213.199.144.0/20
* Limelight Networks: 95.140.224.0/20, 87.248.192.0/19

und die eine von Akami.

Aber dadurch erscheinen nicht mehr als 2 optional verfügbare Updates.
Hab nochmal nachgeschaut, ob ich eventuell Port 80 udn 443 für alle Programme verfügbar gemacht habe, aber nein. 80 und 443 habe ich nur bei einzellnen Programmen.



Die Ip-Adressen sind die zwei DNS-Server meines Providers. Das solltest du auch bei dir eintragen, weil die Regel nur so vor DNS-Umleitungen usf. schützt. Guck mal im Abschnitt "Vorbereitungen", wie du deine DNS-Server rausfinden kannst und gib sie in der Regel als Remote-IP-Adressen ein.

Habe in die Eingabeaufforderung ipconfig /all eingegeben und bei DNS-Server steht eine IP:192.168.2.1 , hoffe ich darf die hier posten ^^
Wenn ich diese IP in die Browserzeile eingebe, kann ich Einstellungen an meinem Speedport W 700v vornehmen. Habe ich damit jetzt meinen eignen DNS-Server gefundren ?
Mein Nachbar meint das wäre sie nicht...



Ich würde aber nicht nur die DNS-UDP-53-Regel (mit deinen DNS-Servern als Ziel) für alle Programme anwenden. Ich würde auch die TCP-Ports 80 und 443 für alle Programme aber nur zu ausgewählten Zielen zulassen. Zu diesen Zielen würde ich z.B. die Adressen von Microsoft, Limelight und VeriSign zählen. Damit ersparst du dir viele Regeln für Microsoft-Programme und Systemdienste (dann kannst du dir auch die Warnung ersparen).

Ok und wie sieht es mit Spielen aus ?
Für dein UT3 hast du TCP und UDP freigeschaltet ohne Ports und ohne Remoteadresse und Port 80 geblockt (vermutlich für einen besseren Ping ? )

Wie schaut es denn bei MMORPG-Spielen bzw. generell bei Spielen aus ?
Sind extra Portfreigaben und Remoteadresse überflüssig ?

Für WoW z.B. sind Port 80, 1119, 3724 (TCP) und für den WoW-Updater 3724, 6112, 6881-6999 (TCP) nötig wenn man dem Spiel nicht alle Ports zugänglich machen will.

Steigert das die Sicherheit, nicht gehakt zu werden ?



EDIT: Toll, jetzt hat dieser Post offensichtlich knapp 25.000 Zeichen ... jetzt muss ich bei Änderungen immer erst was löschen ... Die Forensoftware mag Vielschreiber nicht, wa? ^^

Dann lösch doch einfach den Eintrag über die SoftwareFirewalls ^^
 
Falkner schrieb:
Aber dadurch erscheinen nicht mehr als 2 optional verfügbare Updates.
was daran liegen könnte, dass keine anderen Updates verfügbar sind ^^. Musst es morgen (abend) mal probieren. Morgen ist MS-Patchday; laut News ein ziemlich umfangreicher. Dass du auch ohne Limelight nach Updates suchen kannst, ist verständlich, weil die Prüfung an sich von Microsoft-Servern vorgenommen wird. Erst beim Download von Dateien kommen die Limelight-Server zum Einsatz.

Falkner schrieb:
]Habe in die Eingabeaufforderung ipconfig /all eingegeben und bei DNS-Server steht eine IP:192.168.2.1 , hoffe ich darf die hier posten ^^
Wenn ich diese IP in die Browserzeile eingebe, kann ich Einstellungen an meinem Speedport W 700v vornehmen. Habe ich damit jetzt meinen eignen DNS-Server gefundren ?
Mein Nachbar meint das wäre sie nicht...
Dein Nachbar hat Recht. Die Adresse ist die deines Routers (und die Adresse der Router des gesamten Nation ^^. Quasi alle Privat-Router sind über lokal verbundene Rechner per 192.168.x.x erreichbar). Dein Router bezieht die DNS-Server dann vermutlich bei der Einwahl beim Provider. Guck mal in der Serverkonfiguration bei den aktuellen Daten der Verbindung ("WAN Status" oder so); da wo steht, wie lange der Router schon läuft, welche (WAN) IP-Adresse er hat usw. Da werden dann wahrscheinlich auch die "echten" DNS-Server stehen, auf die dein Router zugreift. Man kann das so lassen; ich persönlich habe aber die DNS-Funktion meines Routers eingeschaltet und direkt die DNS-Server meines Providers fest eingetragen. Find ich angenehmer, weil ich so mit ipconfig /all direkt die DNS-Server sehen kann und nicht nur meinen Router. Außerdem hab ich seitdem keine Verbindungsprobleme mehr.
(Allerdings war das auch notgedrungen, denn in meinem Router war der DNS-Server eines Chinesischen Internet-Providers voreingestellt :freak: :D ... "made in China" halt ^^ ... und wenn ich die DNS-Server nicht fest eingestellt hab, brauche ich mehrere Anläufe, bis mein Router endlich die richtigen gefunden hat)

Falkner schrieb:
Ok und wie sieht es mit Spielen aus ?
Für dein UT3 hast du TCP und UDP freigeschaltet ohne Ports und ohne Remoteadresse und Port 80 geblockt (vermutlich für einen besseren Ping ? )
Wie schaut es denn bei MMORPG-Spielen bzw. generell bei Spielen aus ?
Sind extra Portfreigaben und Remoteadresse überflüssig ?
Für WoW z.B. sind Port 80, 1119, 3724 (TCP) und für den WoW-Updater 3724, 6112, 6881-6999 (TCP) nötig wenn man dem Spiel nicht alle Ports zugänglich machen will.

Steigert das die Sicherheit, nicht gehakt zu werden ?
Nein. Und um "gehackt werden" geht es hier eh nicht. Dem Schutz vor Hacking dienen Firewalls sowieso immer, dazu braucht es kein Whitelisting. Auch wenn du die ports für ausgehenden Verkehr freigibst, kann trotzdem niemand über diese Ports auf deinen Rechner zugreifen (dafür sorgt die Firewall automatisch; das ist der ursprüngliche Sinn einer Firewall). Bei UT3 musste ich so viel freigeben, weil das login z.B. tcp443 braucht; Gamespy braucht eine dauerhafte Verbindung auf TCP 29990(?), für den Serverbrowser brauche ich TCP 29810; Gameserver nutzen z.B. ports wie 6666 oder 12000 ... Port 80 kann ich allerdings gut blocken, weil der nur dazu dient, überflüssige News usf. von Gamespy-Servern zu laden, was den ping a) schwanken lässt und b) erhöht. Allerdings muss ich ihn einschalten, wenn ich eine neue Map von einem Server laden will ... umständlich ^^
Allerdings ist der Ping-Gewinn minimal. Bei einem Spiel wie WoW macht das wenig aus; bei Unreal ändern 10ms das Spielgefühl schon ziemlich deutlich; ganz zu schweigen von den Folgen von Paket Loss, wenn zig Projektile berechnet werden müssen ...
Kurz: Eigentlich lohnt sich der Aufwand nicht ;)
Spiele haben i.d.R. sowieso keine Routinen, mit denen willkürlich andere Software auf dem Rechner gestartet oder installiert werden könnte; insofern dürften die meisten Spiele sicher sein (wobei ich mit WoW keine Erfahrung habe).

Falkner schrieb:
Dann lösch doch einfach den Eintrag über die SoftwareFirewalls ^^
geht nicht. Es gibt hier Leute, die Firewalls und Anti-Virensoftware im Allgemeinen für überflüssig halten und immer mit den selben unrealistischen Argumenten kommen. Um mich nicht auf Diskussionen einlassen zu müssen, brauche ich nur zu schreiben "Siehe Abschnitt "Warum eine Software-Firewall?"" und schon sind alle Argumente entkräftet :)
 
Zuletzt bearbeitet:
was daran liegen könnte, dass keine anderen Updates verfügbar sind ^^. Musst es morgen (abend) mal probieren. Morgen ist MS-Patchday; laut News ein ziemlich umfangreicher. Dass du auch ohne Limelight nach Updates suchen kannst, ist verständlich, weil die Prüfung an sich von Microsoft-Servern vorgenommen wird. Erst beim Download von Dateien kommen die Limelight-Server zum Einsatz.

Mal schauen ob du recht hast (wovon ich stark ausgehe :D )



Guck mal in der Serverkonfiguration bei den aktuellen Daten der Verbindung ("WAN Status" oder so); da wo steht, wie lange der Router schon läuft, welche (WAN) IP-Adresse er hat usw. Da werden dann wahrscheinlich auch die "echten" DNS-Server stehen, auf die dein Router zugreift. Man kann das so lassen; ich persönlich habe aber die DNS-Funktion meines Routers eingeschaltet und direkt die DNS-Server meines Providers fest eingetragen. Find ich angenehmer, weil ich so mit ipconfig /all direkt die DNS-Server sehen kann und nicht nur meinen Router.


Habs gefunden :) , Dort stehen zwei.
Primäre DNS-Server und Sekundäre DNS-Server
Habe beide in die UDP 53 für alle Programme Regel eingefügt, aber dann kann ich keine Internetseiten mehr aufrufen. Irgend etwas scheine ich falsch zu machen.


Nein. Und um "gehackt werden" geht es hier eh nicht. Dem Schutz vor Hacking dienen Firewalls sowieso immer, dazu braucht es kein Whitelisting. Auch wenn du die ports für ausgehenden Verkehr freigibst, kann trotzdem niemand über diese Ports auf deinen Rechner zugreifen (dafür sorgt die Firewall automatisch; das ist der ursprüngliche Sinn einer Firewall).

Dachte es gäbe bestimmte Ports, denen Trojaner nützlich sind.

Hier z.B. lassen sich solche als Trojaner-Ports auflisten.
http://www.emsisoft.de/de/kb/portlist/default.aspx

Bei Port 53 steht dort:
Port 53:
DNS (Domain Name Server) (TCP/UDP)
Bonk (DoS) (TCP)

Sollte man einen Trojaner auf dem Rechner haben, dann kann dieser doch nachhause funken, wenn Ports generell für alle Programme geöffnet sind.


Und danke nochmal für die Hilfe und die Tipps ;)
Hast ne Engelsgedult bei meiner Fragerei ^^
 
Falkner schrieb:
Habs gefunden :) , Dort stehen zwei.
Primäre DNS-Server und Sekundäre DNS-Server
Habe beide in die UDP 53 für alle Programme Regel eingefügt, aber dann kann ich keine Internetseiten mehr aufrufen. Irgend etwas scheine ich falsch zu machen.
nein, du machst nichts falsch. Das liegt daran, dass dein Rechner erst deinen Router kontaktiert; und im Router sind die "echten" DNS-Server nicht fest eingetragen. Wenn du deine Routereinstellungen belassen möchtest, müsstest du die Adresse deines Routers als Remote-Adresse für UDP-53 eintragen.
Aber immerhin hast du jetzt gemerkt, was passiert, wenn Programme keinen DNS-Server kontaktieren können ;)

Falkner schrieb:
Bei Port 53 steht dort:
Sollte man einen Trojaner auf dem Rechner haben, dann kann dieser doch nachhause funken, wenn Ports generell für alle Programme geöffnet sind.
genau deswegen bin ich ja dafür, direkt die Adressen der DNS-Server einzutragen, denn es nutzt Malware nix, wenn es Daten an diese Server senden würde.
Whitelisting wird erst dann richtig sinnvoll, wenn man nicht nur die Programme einzeln auswählt, sondern auch deren Ziele.
Prinzipiell sind Remote-Ports eh nicht unumgänglich vorgegegen, sondern orientieren sich an einer Leitlinie der IANA. Es ist nur so, dass es "üblich" ist, dass Server z.B. HTTP-Anfragen über Remote-Port 80 erwarten. Wenn du selbst einen Server hättest, könntest du aber auch einstellen, dass das ganze über Port 48901 abgewickelt werden soll. Insofern könnte es durchaus sein, dass ein Malwareserver über den Remoteport 53 seine Daten an installierte Malware verschickt, die an genau diesem Port anfragt. Umso wichtiger ist es eben, feste Zieladressen einzugeben (jedenfalls bei Programmen mit Sicherheitsrisiko; was z.B. die meisten Spiele ausschließt). D.h., wenn man Regeln für ALLE Programme erstellt, sollten sie IMMER feste Zieladressen enthalten.

Falkner schrieb:
Hast ne Engelsgedult bei meiner Fragerei ^^
es fragt ja sonst niemand :D
 
Zuletzt bearbeitet:
Scheinweltname schrieb:
nein, du machst nichts falsch. Das liegt daran, dass dein Rechner erst deinen Router kontaktiert; und im Router sind die "echten" DNS-Server nicht fest eingetragen. Wenn du deine Routereinstellungen belassen möchtest, müsstest du die Adresse deines Routers als Remote-Adresse für UDP-53 eintragen.
Aber immerhin hast du jetzt gemerkt, was passiert, wenn Programme keinen DNS-Server kontaktieren können ;)

Hmm, Quantenphysik ³ ^^

Was mache ich jetzt weil so ist das total nervig.
Habe die Primäre und Sekundäre DNS-Server IP bei mir in die ausgehende Regel (DNS) UDP Port-53 für alle Programme eingetragen. Was mir auffällt. Google.de kann ich gar nicht mehr aufrufen. Computerbase und heise funktionieren, aber es daaaauert bis sie angezeigt werden.
PS: Was wären die "echten" DNS-Server ?


Wenn du deine Routereinstellungen belassen möchtest, müsstest du die Adresse deines Routers als Remote-Adresse für UDP-53 eintragen


Das Eintragen der beiden IPs, die ich aus meinem Router habe ( Primäre und Sekundäre DNS-Server IP), in meine ausgehende UDP-53 Regel, zählt wohl nicht dazu ?

Brauche ich jetzt dafür die Gateway-Adresse ?
Was genau würde sich durch das Eintragen meiner Router- Adresse in meine ausgehende UDP-53 Regel ändern ?
Also die beiden DNS-Server IPs sind beide von T-Online und nicht irgendwo aus China wie es bei dir war ^^

PS: Also nochmal zum Verständnis: Entweder man trägt die DNS-Server ip seines Providers in sein UDP-53 Regel für alle Programme ein oder man trägt die Adresse seines Routers ein in diese Regel ein.
Und der unterschied ist ?


genau deswegen bin ich ja dafür, direkt die Adressen der DNS-Server einzutragen, denn es nutzt Malware nix, wenn es Daten an diese Server senden würde.
Whitelisting wird erst dann richtig sinnvoll, wenn man nicht nur die Programme einzeln auswählt, sondern auch deren Ziele.


Man öffnet also einmal die Tür (Ports) und zeigt dem Programm gleichzeitig den Weg (Remoteadresse/CIDRs). Und dann gibt es noch Remoteadressen, die man für alle Programme zulassen kann ( Microsoft, Limelight Networks, Versign). Ich hoffe ich habs verstanden ^^

Ja, mir fehlen jetzt noch die Zieladressen für die Malwarebytes Updateserver.
Aber irgendwie bekomme ich diese nicht raus und errechne eine falsche CIDR.
Auch wenn ich einen höheren Wert nehme, klappt es nicht.
Wenn ich Update, lautet die IP 87.248.217.253
Ich errechne dann immer 255.255.226.0/?
Nur was hinten beim ? raus kommt weiß ich nicht.
87.248.194.0/20 klappt zumindest nicht.

Bei Thunderbird bin ich mir nicht so sicher ob ich das nutzen, oder ob ich die web.de-Seite in die whitelist aufnehmen soll um dann über die web.de-Seite meine E-Mail nachzuschauen.


Umso wichtiger ist es eben, feste Zieladressen einzugeben (jedenfalls bei Programmen mit Sicherheitsrisiko; was z.B. die meisten Spiele ausschließt). D.h., wenn man Regeln für ALLE Programme erstellt, sollten sie IMMER feste Zieladressen enthalten.

Haben Spiele (die meisten) kein Sicherheitsrisiko und brauchen deswegen keine Zieladresse? Ich ging davon aus, dass man Spiele wie Bad Company2, UT3 oder auch MMORPGs die auf Server connecten, generell keine Zieladresse verpassen könnte.


PS: Habe nach den CIDRs für Malwarebytes gegoogelt und bin auf das Kasperskyforum gesoßen. Dort habe ich eine interessante Unterhaltung gelesen und ab der Hälfte kam mir der Schreibstil und der enorme Aufwand an Sicherheit bekannt vor. ^^

Übrigens, auch ich kann mir meine Passwörter nicht merken und merke mir dafür die Wege, bzw. die Reihenfolge wo ich mit meinen Händen als nächstes hin muss :D :D :D


EDIT: Auf deinem Screenshot sehe ich, dass du für dein Kaspersky zwar vier Ports aber keine Remoteadressen eingestellt hast. Ist das bei AV und ISS Programmen nicht nötig ?

Ich teste grad Norton-AV und habe als Port 80, 443 und die Akamai CIDR = 217.89.105.128/25 eingestelt für die Updates.
 
Zuletzt bearbeitet:
Zu den DNS-Servern: Die DNS-Server sind diejenigen, die jedes Programm kontaktiert, wenn es für Hostnamen wie "google.de" die IP-Adresse sucht. Dein Router kennt diese IP-Adresse nicht, weil er die Information dafür gar nicht hat. Deshalb muss er seinerseits die "echten" DNS-Server kontaktieren (die du beim WAN-Status des Routers gefunden hast). Bei dir ist es so eingestellt, dass dein Rechner seine DNS-Anfragen an deinen Router leitet, und der wiederum fragt dann bei "echten" DNS-Servern nach.
Man kann es aber auch so einstellen, dass der Router den Rechner direkt an die DNS-Server weiterleitet; das kann ich bei der Konfiguration meines Routers bei den DNS-Einstellungen ändern. Dort sind dann, in meinem Router, die Adressen meiner DNS-Server fest eingetragen. Muss man aber nicht zwingend machen. Da nur extrem seltene Malware die Einstellungen von Routern ändern kann, kannst du ruhig die Adresse deines Routers als Zieladresse der UDP-53-Regel nehmen.
Man öffnet also einmal die Tür (Ports) und zeigt dem Programm gleichzeitig den Weg (Remoteadresse/CIDRs). Und dann gibt es noch Remoteadressen, die man für alle Programme zulassen kann ( Microsoft, Limelight Networks, Versign). Ich hoffe ich habs verstanden ^^
joa, so meinte ich das ^^

Ja, mir fehlen jetzt noch die Zieladressen für die Malwarebytes Updateserver.
Aber irgendwie bekomme ich diese nicht raus und errechne eine falsche CIDR.
Auch wenn ich einen höheren Wert nehme, klappt es nicht.
Wenn ich Update, lautet die IP 87.248.217.253
die IP-Adresse stammt von Limelight Networks. Du hast den Bereich für das Windows Update auch schon freigegeben --> 87.248.192.0/19 (der Bereich ist: 87.248.192.0 - 87.248.223.255, Subnetzmaske 255.255.224.0)

Bei Thunderbird bin ich mir nicht so sicher ob ich das nutzen, oder ob ich die web.de-Seite in die whitelist aufnehmen soll um dann über die web.de-Seite meine E-Mail nachzuschauen.
? Geht es um die Entscheidung ob E-Mail-Client oder Versand über den Browser? Thunderbird und Co sind sehr bequem; man kann allerdings auch einiges falsch einstellen. Wenn du eh nicht viel verschickst, kannst du auch beim Browser und der Website bleiben (die sich ja relativ leicht whitelisten lassen sollte).

Haben Spiele (die meisten) kein Sicherheitsrisiko und brauchen deswegen keine Zieladresse? Ich ging davon aus, dass man Spiele wie Bad Company2, UT3 oder auch MMORPGs die auf Server connecten, generell keine Zieladresse verpassen könnte.
bei Unreal Tournament läuft alles über Server von Gamespy; insofern könnte man das vielleicht whitelisten. Aber erstens dürfte es keinen Hacker geben, der UT3 zum Laden von Malware nutzt; und außerdem kann man mit der UT3.exe keine Software installieren. Das dürfte beides für die meisten Spiele gelten. Ich habe lange versucht, UT3 per whitelist zu regulieren; aber immer ging irgendwas nicht (serverbrowser, login, Verbindung zu einem Server usf.).
Ich würde sagen: Alle Spiele, die nicht in-game z.B. den Windows-Explorer aufrufen können und mit denen man nicht im Netz surfen und Dateien von Webseiten downloaden kann (d.h. keine Web-Browser-Funktion besitzen), die sollten - wenn überhaupt - nur eine geringe Gefahr darstellen.

PS: Auf deinem Screenshot sehe ich, dass du für dein Kaspersky nur Ports aber eine Remoteadressen eingestellt hast. Ist das bei AV und ISS Programmen nicht nötig ?
wenn ich Kaspersky selbst IP-Adressen vorgeben würde, könnte ich nicht vernünftig im Netz surfen. Da mein Firefox sowieso immer in der Sicheren Umgebung von Kaspersky läuft, bin ich beim Surfen auch ziemlich beruhigt.

Übrigens ist heute Kaspersky Internet Security 2011 erschienen; nach Windows-Update und Image-Backup werd ich mir das heute abend erstmal drauftun :)
 
Zuletzt bearbeitet:
Scheinweltname schrieb:
Da nur extrem seltene Malware die Einstellungen von Routern ändern kann, kannst du ruhig die Adresse deines Routers als Zieladresse der UDP-53-Regel nehmen.

Und das wäre dann die Gateway Adresse oder eine andere ?

die IP-Adresse stammt von Limelight Networks. Du hast den Bereich für das Windows Update auch schon freigegeben --> 87.248.192.0/19 (der Bereich ist: 87.248.192.0 - 87.248.223.255, Subnetzmaske 255.255.224.0)

Woher du das nur weißt ^^aber stimmt, habe diese Zieladresse bereits in Vertrauenswürdige IPs (alle Programme).

Aber wenn ich für das Programm Malwarebytes' Anti-Malware nicht extra eine Zieladresse zuweise und nur Port 80 und 443 offen lassen, woher weiß ich, dass es dann nur Updates von den vertrauenswürdigen IPs zieht ? Es könnte doch dann Updates von jeder Zieladresse beziehen.



? Geht es um die Entscheidung ob E-Mail-Client oder Versand über den Browser? Thunderbird und Co sind sehr bequem; man kann allerdings auch einiges falsch einstellen. Wenn du eh nicht viel verschickst, kannst du auch beim Browser und der Website bleiben (die sich ja relativ leicht whitelisten lassen sollte).

Ja, ich bin mir nicht sicher ob ich mit TB alles richtig eingestellt habe.
im Endeffekt benötige ich meine E-Mail adresse für Supportanfragen, meine Spiele und Forum-Accounts. Wird wohl das Beste sein, web.de auf die whitelist zu packen.



Übrigens ist heute Kaspersky Internet Security 2011 erschienen; nach Windows-Update und Image-Backup werd ich mir das heute abend erstmal drauftun :)

Nach dem WinUpdate schreibe ich hier erstmal rein ob es auch nur mit port80, 443 geklappt hat, ohne Zieladressen ^^
Und dann lese ich mir mal durch was Kasperle 11 alles kann :D




Edit:

Achso noch was, auf deinen Screens, sehe ich gar nicht die Regel mit der du die Windows-Updates geregelt hast. Hast du nicht extra eine Regel für svchost.exe erstellt ?
Oder lass mich raten, mass muss keine extra Regel für svchost.exe erstellen. Es reicht die Zieladressen von Microsoft und co. in die die Vertrauenswürdige IPs (alle Programme) Regel aufzunehmen ^^

Dann erklärt sich auch, warum ich für das Programm Malwarebytes keine extra Regel benötige weil die Zieladressen (Limelight Networks) für dessen Updates ebenfallss in der Vertrauenswürdige IPs (alle Programme)-Regel enthalten ist. Langsam gibt das Ganze ein Bild für mich ^^ Ihr sein guter Meister, die Macht ist mit mir, ich bekommen jetzt Lazzerschwert ? ^^


Bei mir sieht das ganze jetzt so aus. Siehe Screen
 

Anhänge

  • FW.jpg
    FW.jpg
    215,5 KB · Aufrufe: 860
Zuletzt bearbeitet:
Zurück
Oben