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

Falkner schrieb:
1. Problem :

Empfohlene Windows Updates konnte ich ohne Probleme herrunterladen und installieren.
Zwei wichtige Updates lassen sich nicht herrunterladen
Sicherheitsupdate für Windows 7 für x64-basierte Systeme (KB2032276)
Windows-Tool zum Entfernen bösartiger Software x64 - Juli 2010 (KB890830)

Dieser Fehler erscheint = 80072efd. Normalerweise kommt diese Meldung, wenn svchost.exe keine Verbindung ins Internet findet. Aber das kann bei mir nicht der Fall sein da die empfohlenen Updates herruntergeladen werden konnten.
"efd" ist immer ein Verbindungsproblem. Guck mal in Post #2 bezüglich der Adressen von Level3 und Akamai; besonders das "Windows-Tool zum Entfernen ..." nutzt häufiger nicht-Microsoft-Server. Oder gib mal für den svchost port 80 kurzzeitig komplett frei und guck, welche Adressen kontaktiert werden; vermutlich welche von Akamai oder Level3.


Falkner schrieb:
2. Problem :
Mir ist aufgefallen, dass sich die IP 199.7.71.0/22 (gehört zu VeriSign) die ich in der Regel "Vertrauenswürtige IPs" eingetragen habe von selbst in eine andere IP ändert und zwar in diese hier 199.7.68.0/22


Wie kann das sein ?

Jedes mal wenn ich diese Regel überprüfe, ist 199.7.71.0/22 in 199.7.68.0/22 geändert.
Die Windows-Firewall selbst ändert sowas - meines Wissens - nicht. Die CIDR 199.7.71.0/22 ist eh falsch (muss /24 sein!)(war das die, die ich früher mal gepostet hatte?). Guck mal in Post #2; die sollten richtig sein.

Die Range 199.7.65.0 bis 199.7.69.255 gehört nicht zu Verisign.

EDIT: Krass, hab gerade auch mal auf meinem Nicht-KIS-Rechner nachgeguckt: Auch bei mir wird aus 199.7.71.0/22 automatisch 199.7.68.0/22 :freak: ... jetzt muss ich natürlich erstmal auch meine anderen CIDR prüfen! Aber die "richtige" IP (199.7.71.0/24) bleibt erhalten.
(ok, die anderen CIDR sind normal).
Und laut Firewall-Log hat sich mein Rechner kein einziges Mal mit einer Adresse aus dem Bereich 199.7.65-69 verbunden ... irgendwie vermute ich eine Art Rechnung der Firewall, die den Ausdruck .71.0/22 irgendwie für unsinnig hält und deswegen irgendwas korrigiert


EDIT 2: Es muss sich wohl um irgendeinen mathematischen Zusammenhang handeln; jedenfalls scheint der Ausdruck 199.7.71.0/22 tatsächlich keinen Sinn zu machen. Offenbar muss, um dieses /22 sinnvoll zu interpretieren (d.h. eine bestimmte Menge an IP-Adressen muss "flexibel" sein), von einem Bereich ab 68 statt 71 ausgegangen werden.

Wenn man beim Netzwerkrechner von heise (http://www.heise.de/netze/tools/netzwerkrechner) die IP 199.7.71.0 und dann als CIDR-Suffix 22 eingibt, dann erscheint dort auch als erste Adresse die 199.7.168.0. Vermutlich ist das auch der Grund, warum bei den whois-Diensten drei einzelne, kleinere CIDR stehen statt der einen großen.

Aber da die /22 sowieso aus einem Rechenfehler meinerseits hervorgangen ist (in Post #2 stehen die korrigierten Werte, diskutiert hatten wir das Problem in posts #89, 91 und die Korrektur steht in Post #107), brauchst du dir weiter keine Sorgen zu machen. Alle anderen CIDR, die ich angegeben habe, sind richtig ... und bleiben es auch nach dem Eintragen in eine Firewall-Regel ;)
 
Zuletzt bearbeitet:
Scheinweltname schrieb:
"efd" ist immer ein Verbindungsproblem. Guck mal in Post #2 bezüglich der Adressen von Level3 und Akamai; besonders das "Windows-Tool zum Entfernen ..." nutzt häufiger nicht-Microsoft-Server. Oder gib mal für den svchost port 80 kurzzeitig komplett frei und guck, welche Adressen kontaktiert werden; vermutlich welche von Akamai oder Level3.

Kurze Zeit später hat es mit den wichtigen Updates doch noch geklappt.
Wichtig für diese Updates scheint diese IP zu sein = 217.89.105.128/25
Zumindest konnte ich ohne diese nichts Updaten.


EDIT:



Es scheint als gäbe es jetzt noch weitere IPs die für Windows Updates (für die wichtigen) benötigt werden. Ebenso für MSE.

In meiner FW habe ich die IPs aus Post #2 drin :

- 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

-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

-Microsoft
94.245.64.0/18, 65.52.0.0/14, 207.46.0.0/16, 213.199.144.0/20

-Limelight Networks (llnw)
95.140.224.0/20, 87.248.192.0/19

-Level 3 Communications
199.92.0.0/14, 207.120.0.0/14


Aber dennoch kam diese Meldung wenn versucht wurde die wichtigen Updates herrunterzulden/installieren

Windows-Updatefehler 80072efd



Habe wie du im Post #141 bereits emphoflen hast kurzzeitig für svchost.exe Port 80 und 443 aber ohne Zieladresse freigegeben. Danach konnte ich Updates beziehen.

Das ist mit der Zeit nervig und umständlich wenn sich die IPs für die Updates ständig ändern :freak:

Hatte noch ganz andere Meldung und zwar, dass zu viele Updates gezogen werden müssen und deswegen überhaupt kein Update ziehen konnte ^^
So etwas hatte ich noch nie gehabt. :freak:


PS:
Ist es wenig bedenklich für die svchost.exe Port 80 ohne Zieladresse zu öffnen bis geupdatet wurde ? Oder besteht da ein gewisses Risiko ? ^^




PSS:
Hab alle Updates neu bezogen und dabei geschaut zu welchen IPs Verbindung aufgenommen wird.

Das waren einmal:
217.89.105.170 und 217.89.105.139 hab für die beiden diese IP berechnet: 217.89.105.128/25 (steht aber auch schon in deinem Post #2)

dann habe ich noch diese IP hier aufgeschrieben:
213.199.149.9 habe daraus das hier berechnet: 255.255.144.0
Dazu steht bei http://de.wikipedia.org/wiki/Classle...Domain_Routing keine CIRD ...^^

Mit 65.55.184.26 wurde auch Verbindung aufgenommen.
Aber wenn man die IP auf http://whois.syndicat.com/ eingibt , erscheint: Query terms are too ambiguous. Please refine query.


Und hier noch eine IP für die Liste auf der ersten Seite.
91.198.174.0/24 für wikipedia :)
 
Zuletzt bearbeitet:
Falkner schrieb:
Das ist mit der Zeit nervig und umständlich wenn sich die IPs für die Updates ständig ändern :freak:[
also, ich hatte in letzter Zeit keine Probleme mit dem Update. Ist ja nicht so, dass die Update-Adressen willkürlich wären. Außerdem reicht es häufig, die Updates einfach zu wiederholen. Offenbar speichert Windows irgendwo ab, welche Server es für das Update schon ausprobiert hat und versucht in folgenden Anläufen andere. Meistens werden im 2. Anlauf dann Microsoft-Server benutzt, die in Post #2 aufgelistet sind.

Falkner schrieb:
Ist es wenig bedenklich für die svchost.exe Port 80 ohne Zieladresse zu öffnen bis geupdatet wurde ? Oder besteht da ein gewisses Risiko ?
Wenn dein System sauber ist, stellt das kein Risiko dar. Und normalerweise tauchen dann sowieso nur ein oder zwei neue IPs auf; und die sind in aller Regel auf Level3 oder Akamai gemeldet.

Falkner schrieb:
dann habe ich noch diese IP hier aufgeschrieben:
213.199.149.9 habe daraus das hier berechnet: 255.255.144.0
Dazu steht bei http*//de.wikipedia*org/wiki/Classle...Domain_Routing keine CIRD ...^^
? aus dem Bereich 213.199.144.0 - 213.199.159.255
berechne ich eine Subnetzmaske von 255.255.240.0; d.h. /20 :p

Falkner schrieb:
Aber wenn man die IP auf http*//whois.syndicat*com/ eingibt , erscheint: Query terms are too ambiguous. Please refine query.
ja, syndicat macht im Moment des Öfteren Zicken; aber auch anderswo kommt das häufiger. Ich nutze deswegen in letzter Zeit immer den WhoIs-Dienst auf heise; da kann man noch alternative Server angeben, die dann meistens das gewünschte Ergebnis liefern (wenn auch bei heise eine Fehlermeldung kommt, dann sollte man die Such-Server manuell wählen; meistens wird eh ripe oder arin benutzt)
http://www.heise.de/netze/tools/whois-abfrage
 
Ja, du hast mal wieder recht :)
Ich habe wohl zu oft und zu schnell hintereinder versucht die Windows Updates zu beziehen.
Naja zur Not geht es eben auch wenn svchost.exe kurz mit Port 80 geöffnet wird.
Ich fand das nur etwas unübersichtlich wenn im Updateverlauft haufenweise Updates als fehlgeschlagen angezeigt werden nur weil irgend eine Verbindung nicht zu stande kam.
Aber zur Not gehts auch mit svchost.exe mit Port 80 zu öffnen :)


ja, syndicat macht im Moment des Öfteren Zicken; aber auch anderswo kommt das häufiger. Ich nutze deswegen in letzter Zeit immer den WhoIs-Dienst auf heise; da kann man noch alternative Server angeben, die dann meistens das gewünschte Ergebnis liefern (wenn auch bei heise eine Fehlermeldung kommt, dann sollte man die Such-Server manuell wählen; meistens wird eh ripe oder arin benutzt)
http://www.heise.de/netze/tools/whois-abfrage

Den von Heise habe ich auch schon benutzt.
Bei dem Feld wo whois-Abfrageserver: gefragt wird nehme ich "automatisch"
Hoffe das ist richtig so.


Web.de

217.72.192.0/20

Kann es sein, dass Web.de noch irgend eine andere IP verwendet ?
Mir wird mit dieser Zieladresse die Seite nicht vernünftig angezeigt obwohl ich auch nur diese IP herausbekomme. Vielleicht kannst du mal in deiner KIS mal web.de eingeben und schauen welche IP dort angegeben wird.

Ich wünschte die Windwos Firewall hätte diese Möglichkeit wie sie KIS hat :(
 
Falkner schrieb:
Den von Heise habe ich auch schon benutzt.
Bei dem Feld wo whois-Abfrageserver: gefragt wird nehme ich "automatisch"
Hoffe das ist richtig so.
falsch kannst du da nix machen; nur manchmal kommt auch bei "automatisch" eine Fehlermeldung; dann musst du manuell nen Server wählen ... so wie bei der fehlenden Web.de-IP (s.u.) :D

Bei mir werden auch Verbindungen z.B. zu js.web.de (213.165.65.140) hergestellt; mit einer IP-Adresse aus dem Bereich 213.165.64.0 - 213.165.66.127; der ist auf GMX gemeldet.
Wegen des verqueren Bereichs brauchst du da mindestens 2 CIDR.
ein CIDR-Rechner aus dem Netz schlägt die zwei vor: 213.165.64.0/23 und 213.165.66.0/25; sie erfassen laut heise Netzwerkrechner auch genau den betreffenden Bereich.
 
Klasse, jetzt funktioniert auch web.de vernünftig.
Habe die beiden IPs (213.165.64.0/23 und 213.165.66.0/25) nacheinander eingetragen und habe festgestellt, dass ich nur 213.165.64.0/23 benötige + die IP aus Post #2 (217.72.192.0/20):freaky:


Bei den Windows Updates hab ich das alles nochmal und immer wieder probiert.
Es werden immer 14 wichtige und 13 empfohlene angeboten.
Aber mit den IPs in meinen FW-Regeln (Microsoft, Limelight Networks, Akamai Hamburg, Level 3 Communications, VeriSign) bekomme ich immer nur zwei installiert. Alle anderen (wichtigen) schlagen fehl. Auch das Beziehen der Updates zu unterschiedlichen Zeiten mit größeren Zeitabständen dazwischen bringt kein anderes Ergebnis.


ein CIDR-Rechner aus dem Netz

Welchen hast du da genutzt ?
Hatte selbst schon einen gefunden aber der funktionierte nur gegen Bezahlung :freak:
 
Falkner schrieb:
Aber mit den IPs in meinen FW-Regeln (Microsoft, Limelight Networks, Akamai Hamburg, Level 3 Communications, VeriSign) bekomme ich immer nur zwei installiert. Alle anderen (wichtigen) schlagen fehl. Auch das Beziehen der Updates zu unterschiedlichen Zeiten mit größeren Zeitabständen dazwischen bringt kein anderes Ergebnis.
Dann musst du wohl oder übel mal den port 80 (und ggf. 443) für den svchost kurzfristig freigeben; falls das Problem denn überhaupt mit der Firewall zusammenhängt (manchmal liegt es auch an Microsoft ;) ). Kannst ja dann mal posten, welche Verbindungen hergestellt wurden.

Falkner schrieb:
Welchen hast du da genutzt ?
Hatte selbst schon einen gefunden aber der funktionierte nur gegen Bezahlung :freak:
ich verlinke den nicht direkt, weil es da kein Impressum gibt und ich dem irgendwie nicht 100%ig vertraue (ich mag ".info", ".tv" und solche Domains nicht). Es handelt sich um den "IP / CIDR / IP Calculator", der auf der Wikipedia-Seite zum CIDR ganz unten verlinkt ist.
 
Wie schauts eigentlich mit diesen Diensten aus, darf man diese deaktivieren ?

-Peernetzwerk-Gruppenzuordnung
-Peernetzwerkidentiäts-Manager
-Peer Name Resoluution-Protokoll

Wie schauts mit den graugeschriebenen Diensten auf Post#2 aus ?
Hast du mittlerweile Erfahrung ob man diese deaktivieren kann ?
Bin in Deaktivierungsstimmung heute :D

In deiner Aufzählung hast du den Dienst SNMP-Dienst aufgezählt. Diese habe ich gar nicht.
SNMP-Trap hingegen schon.

Anschlussumleitung für Remotedesktopdienst im Benutzermodus habe ich auch nicht in meiner Liste der Dienste

Liegt das eventuell an Win7 Home Premium, dass es gar nicht drin enthalten ist ?
 
Zuletzt bearbeitet:
Falkner schrieb:
Wie schauts mit den graugeschriebenen Diensten auf Post#2 aus ?
Hast du mittlerweile Erfahrung ob man diese deaktivieren kann ?
könnte das Grau tatsächlich mal schwarz machen :D
Die Dienste (inkl. der Peername-xy-Dienste, stehen in der Liste) sind bei mir jetzt seit Monaten aus, und ich hatte noch keine erkennbaren Probleme.

Edit:
Falkner schrieb:
In deiner Aufzählung hast du den Dienst SNMP-Dienst aufgezählt. Diese habe ich gar nicht.
SNMP-Trap hingegen schon.
Anschlussumleitung für Remotedesktopdienst im Benutzermodus habe ich auch nicht in meiner Liste der Dienste
Liegt das eventuell an Win7 Home Premium, dass es gar nicht drin enthalten ist ?
das kann gut sein. Hab leider nur Win7 Professional ... vermutlich gibt es in der ultimate-Version nochmal andere Dienste, die auch bei mir nicht auftauchen.

Aber wenn die Dienste gar nicht erst installiert sind, dann ist das sogar noch besser als sie nur zu deaktivieren ;)
 
Zuletzt bearbeitet:
höchst hilfreich dein howto, weil ich gerade sensible firmen-rechner abhärten will. schon irgendwie zynisch dass die software nur mit windows läuft :lol: jedenfalls gabs 5 sterne für dich ^^

gut zu wissen wäre noch ob man statt festen IPs auch domain-namen angeben kann. speziell auch für windows update und MSE. denn ständig IPs ändern für rechner die gerne 10 jahre laufen sollen macht keinen spaß. wenn nicht wäre es gut eine regel zu haben die zumindest nur einen dienst (windows update) erlaubt statt alle svchost.exe. hast du mal sowas in der richtung gehört?

was mir noch aufgefallen ist: MAC-adressen kann man ganz einfach per treiber-option faken, sogar mit windows. ein MAC-filter nervt also eigentlich nur, denn wer ein WPA2 mit sicherem passwort knackt hält sich an sowas nicht auf. aber wer gerne möglichst sicher sein will hat sicher seinen spaß daran. und einen verschärften RADIUS-server :D

EDIT: ok, regeln für dienste erstellen scheint zu funktionieren, für das windows update reicht der intelligente hintergrundübertragungsdienst.
dringend not tun würde aber immer noch die angabe eines DNS-namens statt eines IP-bereichs. schon für die zeit der umstellung auf IPv6 würde das jedem eine menge kopfschmerzen ersparen. microsoft gibt sogar in der knowledgebase die vielen DNS-namen für windows update (mit wildcard) an.

den DNS-server kann man übrigens noch flexibler angeben als über die IP des routers, die sich ja ändern kann, nämlich einfach "dns server" angeben, dann wird wohl automatisch der aktuelle dns-server aus den dhcp-infos benutzt.
 
Zuletzt bearbeitet von einem Moderator:
enteon schrieb:
gut zu wissen wäre noch ob man statt festen IPs auch domain-namen angeben kann.
das geht mit der Windows-Firewall nicht. Und das aus gutem Grund: Wenn man direkt IP-Adressen angibt, ist man vor DNS-Umleitungen geschützt!
Aber es gibt bestimmt andere Softwarefirewalls (z.B. die von Kaspersky Internet Security), bei deren Regeln braucht man nur Hostnamen anzugeben. Ist aber auch nicht ernsthaft bequemer (für die Anzeige vieler Webseiten muss man mehrere Domainnamen freigeben).

enteon schrieb:
denn ständig IPs ändern für rechner die gerne 10 jahre laufen sollen macht keinen spaß. wenn nicht wäre es gut eine regel zu haben die zumindest nur einen dienst (windows update) erlaubt statt alle svchost.exe. hast du mal sowas in der richtung gehört?
Im Kern verändern sich die IP-Adressen für das WinUpdate nicht sooo grundlegend. Im Moment ist es nur umständlich, weil wechselnde Server von Akamai beteiligt sind. Für einen Admin würde das Whitelisten des Svchost für das WinUpdate aber definitiv einen großen Aufwand bedeuten.
Dieser Aufwand würde sich aber lohnen! Denn - ich hab das selbst erst vor kurzem festgestellt - Programme können eine Schnittstelle des svchost nutzen, um über ihn Internetkontakt herzustellen. Der Adobe Reader updated sich auf diese Weise.

enteon schrieb:
was mir noch aufgefallen ist: MAC-adressen kann man ganz einfach per treiber-option faken, sogar mit windows. ein MAC-filter nervt also eigentlich nur, denn wer ein WPA2 mit sicherem passwort knackt hält sich an sowas nicht auf.
Ja, aber woher soll der User wissen, welche MAC-Adressen zugelassen werden? Will er per Brute-Force alle ausprobieren? Und übrigens ist mein WLAN sowieso paradox eingerichtet: Man braucht das Passwort, um testen zu können, welche MAC-Adressen zugelassen werden. Aber man müsste erst eine passende MAC-Adresse haben, um überhaupt am Passwort rumhacken zu können (mit falscher MAC-Adresse würde man auch bei richtigem Passwort nicht angemeldet, d.h. der Hacker würde gar nicht erkennen, ob er das richtige PW erwischt hat).
 
Zuletzt bearbeitet:
ich hab das ganze jetzt ohne svchost.exe gelöst. worüber ich noch froher bin wenn du schreibst, dass jedes dahergelaufene programm darüber mit dem internet kommunizieren kann, was genauso wenig wie browsen erlaubt sein soll.

interessant wäre noch ob auch mit der einstellung 'alles eingehende blockieren' kommunikation mit 127.0.0.1 möglich ist. ping geht schonmal. eine regel dafür ist erstellt, aber ja nur bei 'blockieren' aktiv, was ich aber vermeiden will wenn sich da wie oben geschrieben jedes programm seine eigene regel basteln kann.

zu den MACs: die werden beim login ins WLAN im klartext übertragen. auf den login eines legitimen clients braucht man auch gar nicht zu warten denn mit einem bestimmten kaputten paket kann man alle clients disconnecten. die connecten dann allermeistens sofort wieder und man hat alle MACs. ist kinderleicht, hab ich selbst mal aus langeweile gemacht. nur auf das AES cracken hatte ich dann keinen bock mehr, der nachbar dankts :lol:

PS: betrachtet man dann noch WEP und die offensichtlichen lücken im patch dafür aka. TKIP könnte man meinen dass der WLAN-standard von hirnlosen managern entworfen wurde und nicht vom IEEE :rolleyes:
 
Zuletzt bearbeitet von einem Moderator:
enteon schrieb:
ich hab das ganze jetzt ohne svchost.exe gelöst. worüber ich noch froher bin wenn du schreibst, dass jedes dahergelaufene programm darüber mit dem internet kommunizieren kann, was genauso wenig wie browsen erlaubt sein soll.
Ich weiß nicht, ob wirklich "jedes dahergelaufene Programm" das kann. Im Falle des Adobe Reader gehe ich davon aus, dass es mit Big M vereinbart ist, dass sich der Reader über den svchost updaten kann. Auffällig ist vor allem, dass sich mein svchost fast ausschlißelich zu Microsoft und Akamai (die verbreiten auch die Updates für den Adobe Reader) verbindet. Es könnte also sein, dass der svchost 1.) nur von authorisierten Programmen mit 2.) festgelegten Zielen (Akamai, Microsoft) genutzt werden kann.

enteon schrieb:
interessant wäre noch ob auch mit der einstellung 'alles eingehende blockieren' kommunikation mit 127.0.0.1 möglich ist. ping geht schonmal. eine regel dafür ist erstellt, aber ja nur bei 'blockieren' aktiv, was ich aber vermeiden will wenn sich da wie oben geschrieben jedes programm seine eigene regel basteln kann.
es gibt bestimmte Dinge, die kann man der WindowsFirewall nicht austreiben. Z.B. das Warten auf/ Senden von DHCP-Anfragen (außer man verbietet Unicast-Antworten). Auch wenn du die betreffenden Ports nicht freigibst, funktioniert DHCP trotzdem. Und ich glaube nicht, dass man die Kommunikation/ Loopbacks mit/ über localhost verhindern kann. Aber warum sollte man das auch? Da kann man ja besser gleich die Netzwerkkarte deaktivieren.
 
Zuletzt bearbeitet:
gut, ansonsten werd ich schon bald merken wenn es nicht funktioniert ;)
hab mir auch schon gedacht dass microsoft mal wieder das DAU-bedudeln durchgeht und sie einfach keine komplette firewall abliefern können. aber für den einsatzzweck soll es mir egal sein. flexibler als billig-router ist es allemal.

danke nochmal für deine hilfe und dein how-to :)
 
Hallo, ich bräuchte mal eure Hilfe um PayPal in unseren Netzwerk freizugeben.
Wir kennen zwar schon die IP Bereiche damit der Zahlungsverkehr funktioniert,
aber scheinbar fehlt uns da noch etwas da die Website immer fehlerhaft angezeigt wird.

Hier mal die uns bekannten Bereiche:

66.211.160.0/19 (paypal.de)
64.4.240.0/20 (paypal.com)
216.113.160.0/19 (paypalobjects.com)
62.168.192.0/19 (paypal-deutschland.de)

LG Sandra
 
Sandra80 schrieb:
aber scheinbar fehlt uns da noch etwas da die Website immer fehlerhaft angezeigt wird.
Ich selber habe keinen PayPal-Account und kann entsprechend nicht alle IPs erreichen.
Funktioniert denn alles, wenn alle Adressen zugelassen werden? Wenn nicht, dann ist vielleicht irgendwas bei den Ports falsch eingestellt (https vergessen zu öffnen, d.h. TCP 443? Vielleicht nutzt Paypal auch noch einen anderen Port?).

Beim Aufrufen der Paypal-Seite und ein bisschen Rumgeklicke hat meine Firewall zusätzlich zu den von dir angegebenen noch diese Verbindungen geloggt (muss nicht sein, dass sie zwingend mit PayPal zusammenhängen; könnte auch nur irgendein Update-Vorgang oder so einer meiner Firefox-Addons gewesen sein, was ich aber für unwahrscheinlich halte):
Beides über https (TCP Port 443)
66.235.128.0/19 (Omniture; gehört zu Adobe)
95.100.96.0/20 (Akamai PA)

Könnte durchaus sein, dass PayPal mit Akamai zusammenarbeitet.
 
Zuletzt bearbeitet:
Habe für Hardwareversand.de die IP 81.7.220.128/26 berechnet.
Kannst du ja dann in die Liste eintragen aber bitte überprüfe ob die IP auch richtig ist.

Hardwareversand lässt sich mit der IP aufrufen. Ich weiß allerdings noch nicht ob damit auch alles funktioniert.

Das Tool von Heise gibt mir diese Infos:

inetnum: 81.7.220.128 - 81.7.220.191
inetnum: 81.7.220.128 - 81.7.220.191
netname: IAS-08-004-0232
descr: T-Systems International
descr: Saonestr. 3
descr: 60528 Frankfurt; Germany
descr: Address Range for HP Vaillant
country: DE



EDIT:

IP-Adressen /Netblocks, zu denen - bei mir - die svchost.exe im Zuge des Windows Updates bisher einmal (*) / häufiger (**) / länger nicht mehr (#) Verbindungen hergestellt hat

* 199.92.0.0/14, 207.120.0.0/14 (Level 3 Communications) (*)
* 62.41.0.0/16 (KPN Eurorings) (**)
* 195.145.147.0/24 (Akamai München) (**)
* 77.67.0.128/25, 213.254.249.0/24 (Akamai TINET) (**)
* 96.6.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) (*)
* 95.140.224.0/20, 87.248.192.0/19 (Limelight Network) (#)
* 216.156.194.123 (ich finde nirgends den vollständigen Adressbereich ...) (XO Communications) (*)



Konnte in letzer Zeit keine Updates für MSE ziehen ohne svchost.exe kurzzeitig zu öffnen.
Habe jetzt alle diese (bis auf die letze IP) in eine Regel gepackt und nun funktionierts.
Weiß allerdings nicht welche dieser IP dafür verantwortlich ist , dass es jetzt läuft.
Aber es wird wohl nicht schaden alle diese IPs in der FW zu haben :)



Und was mich noch interessieren würde:

Wenn für die Internetseite XYZ die IP 123.456.789.123/XX berechnet wird, dann kann mit dieser IP nur diese eine bestimmte XYZ Seite geöffnet werden oder eventuell auch andere von denen man nicht weiß , ist das möglich ?

Oder kommt es da mehr auf die CIRD an, um so höher die CIRD um so kleiner der Bereich bzw. weniger Seiten können mit einer bestimmten IP aufgerufen werden ?
 
Zuletzt bearbeitet:
ich habe eine kurze einfache frage:

habe die firewall auf whitelisting umgestellt. genau wie auf den 3 screenshots unter
Schritt 2: Firewall auf Whitelisting umschalten

ich möchte jetzt aber nicht manuell für jede meiner apps eine neue regel erstellen. im falle von steam mit meinen spielen führte das zu keinem erfolg.

ich möchte genauso wie für incoming traffic ,für jede andwendung gefragt werden, ob ich es erlauben oder verbieten will.

wie würde ich das einstellen ?
 
sTrEuNeR78 schrieb:
ich möchte genauso wie für incoming traffic ,für jede andwendung gefragt werden, ob ich es erlauben oder verbieten will.
Das möchte ich auch ;)
Aber die Windows Firewall besitzt keine Einstellungsmöglichkeit, die einem "Trainingsmodus" entspräche. Die Benachrichtungen gibt es ausschließlich für blockierte eingehende Verbindungen.

Falkner schrieb:
Und was mich noch interessieren würde:

Wenn für die Internetseite XYZ die IP 123.456.789.123/XX berechnet wird, dann kann mit dieser IP nur diese eine bestimmte XYZ Seite geöffnet werden oder eventuell auch andere von denen man nicht weiß , ist das möglich ?

Oder kommt es da mehr auf die CIRD an, um so höher die CIRD um so kleiner der Bereich bzw. weniger Seiten können mit einer bestimmten IP aufgerufen werden ?
(sorry wegen der späten Antwort. Hab den Beitrag gar nicht bemerkt)
Über eine IP-Adresse erreicht man einen Server, auf dem Daten gespeichert sind; darunter z.B. viele einzelne Webseiten als *.html. Deshalb funktioniert es ja i.d.R. auch nicht, wenn man einfach eine IP-Adresse in die Adresszeile des Browsers schreibt; dann weiß der Server gar nicht, was (z.B. Webseite, Datei ...) angefordert wurde. D.h. nicht Webseiten haben jeweils eine eigene IP-Adresse, sondern der Server, auf dem die Daten für die Webseiten (*.html-Dateien, Bilder, Layout-Dateien (CSS), Nutzerdatenbanken usf.) liegen. Da aber Server i.d.R. irgendwem gehören, können da auch nicht beliebig irgendwelche anderen Webseiten oder Dateien draufliegen; dafür wird der Besitzer schon sorgen.
 
Zuletzt bearbeitet:
Da aber Server i.d.R. irgendwem gehören, können da auch nicht beliebig irgendwelche anderen Webseiten oder Dateien draufliegen; dafür wird der Besitzer schon sorgen.

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. Mich hat es nur etwas irritiert, wenn bestimmte Seiten mehr als eine IP benötigen, wie z.B. YouTube.

Aber gut, dann weiß ich jetzt, dass mit einer IP niemals mehrere bzw. verschiedene/unterschiedliche Seiten aufgerufen werden können.




Habe für Bad Company Regeln erstellt mit allen Ports die benötigt werden.

Das Einlogen in meinen BC2 Account ist möglich.
Das Finden von Servern auch.
Doch alle Server die mir angezeigt werden, haben einen Ping von 999 und auf keinen lässt sich verbiden.

Dachte mir, das liegt daran weil die Server betimmt selbst auch noch unterschiedliche Ports haben die ich unmöglich alle in eine Regel packen kann ^^


Also habe ich für die .exe Datei eine ausgehende Regel mit UDP und TCP erstellt. Alle Ports offen.

und das Gleiche nochmal bei den eingehenden Regeln in der Firewall.

Aber auch dann, werden mir nur Server mit Ping 999 angezeigt auf die ich nicht verbinden kann.

Erst wenn ich die Firewall wieder auf Blacklist stelle, also in den Einstellungen beim Reiter "Öffentlich" bei Ausgehende Verbindungen auf "zusallen" stelle, sind die Pings der Server normal und kann auch verbinden.


Bei Steamspielen ist das ähnlich.
Kann bei Steam einlogen aber auf keinen Server verbinden.

Woran liegt das ?




Bei WoW passiert was ganz anderes.

Alle für die Spiele.exe/Downloader.exe benötigten Ports sind freigegeben.
Doch mit TCP-Viewer konnte ich sehen, dass auch ein Port offen ist der immer unterschiedlich im Bereich zwischen 49.000-50.000 liegt.
Gibt es überhaupt Ports mit so vielen Stellen hinterm Komma ?

Wie kann sich ein Port freigeben obwohl nicht in der Regel eingetragen ?
 
Zurück
Oben