dimis linkdump

Vielleicht hatte schonmal jemand das Problem: Die Standard-Konfiguration der Windows-Firewall ist zu lasch oder man will genau wissen, welcher Netzwerkverkehr den Rechner verlässt. Dann darf man natürlich nicht auf die vorkonfigurierten Regeln von Microsoft vertrauen.

Alle bestehenden Regeln können, mit Rechtsklick -  “Regel deaktivieren”, in einem Schwung deaktiviert werden. Anschließend sollten solche Elementaren Dienste wie DNS (“Kernnetzwerk – DNS (UDP ausgehend)”) wieder aktiviert werden. Sonst funktioniert natürlich erstmal nix mehr.

Einer dieser elementaren Dienste ist Windows Update. Leider sucht man sich den Wolf nach einer passenden Standard-Regel für Windows Update, die man wieder aktivieren kann. (Ich hab sie bisher auch nicht gefunden. Wenn die jemand findet, bitte melden!). Außerdem gab’s bei Google keinen passenden Beitrag, der beschreibt wie man Windows Update mit möglichst wenig Rechten den Weg ins Internet durch die Firewall freimachen kann. Das will ich hiermit ändern.

Die Windows Firewall ist bei Vista und Windows 7 unter Systemsteuerung => System und Sicherheit zu finden.

Im ersten Schritt muss eine neue Ausgehende Regel angelegt werden. Wählen wir “Benutzerdefiniert”.

Im nächsten Schritt tragen wir unter Programm “%systemroot%\system32\svchost.exe” ein. Unter Dienst wählen wir “Windows Update”.

Diese Einstellung hat zur Folge, dass nur der Dienst Windows Update freigeschalten wird und nicht pauschal alle Prozesse, die durch den svchost.exe gestartet werden. Die Windows Firewall identifiziert Dienste seit Windows Vista eindeutig über eine SID (Security Identifier). Damit die Regel angewendet wird, muss also SID (also Windows Update) und Programm (also svchost.exe) passen.

Die darauffolgende Fehlermeldung können wir ignorieren.

Im nächsten Fenster tragen wir als Protokoll TCP und als Remoteports 80,443 ein.

Wer lustig ist, kann im nächsten Fenster noch die IP-Ranges von Microsoft eintragen.  Muss aber nicht unbedingt sein…

In den nächsten Schritten sagen wir dem Assistent noch, dass er dei Verbindung zulassen soll und vergeben einen Namen. Zusätzlich sind noch die Netzwerke einzutragen – “öffentlich” sollte natürlich angehakt sein. Sonst funktioniert der ganze Spaß nicht.

Damit ist die Verbindung eingerichtet und Windows Update sollte funktionieren. Ein Test in der Systemsteuerung unter Windows Update “Updates suchen” zeigt uns, dass wir die Verbindung erfolgreich eingerichtet haben.

Eine interessante Idee hatten die Security-Spezialisten von ha.ckers.org. In ihrem aktuellen Blogartikel schreiben sie über eine Möglichkeit wie man z.B das interne Netz eines Surfers über den Browser auf die existenz aktiver Hosts überprüfen könnte.
Hierzu wird natürlich kein echtes ICMP-Packet durch den Browser generiert, sondern ein so genannter Cross-Origin Request an jeden einzelnen Host abgesetzt. Mit dieser Methode will das W3C den Authoren von Webapplicationen eine sichere Möglichkeit bieten, die so geannte Same Origin Policy zu umgehen.

Wie funktioniert das “ping” sweeping?

Diese Methode bediehnt sich eines einfachen Gedankens: Eine IP hinter der ein Host steckt, kann schneller reagieren als eine IP hinter der kein Host steckt. (Wie denn auch, wer soll da reagieren?)

Das W3C verbietet im Entwurf zu Cross Origin Request ganz deutlich, dass keine Informationen an den User ausgegeben werden dürfen, wenn das status flag nicht auf success steht.

Hosting specifications also need to ensure not to reveal anything until the status flag is set to success to prevent e.g. port scanning.

Indirekt tut es der Browser halt trotzdem:

Hier wichtigste Teil des Javascripts:

1:  function processRequest () {
2:    if (req.readyState == 4) {
3:    var d2 = new Date;
4:    var time = d2.getTime() – d.getTime();
5:         if (time < 18000) {
6:             if (time > 10) {
7:                 log (“Exists: ” + url + ” at ” + time + “ms.”);
8:             }
9:         } else {
10:           log (“Doesn’t exist: ” + url + ” at ” + time + “ms.”);
11:       }
12:  }
13: }

Im vorderen Teil des Skripts (hier nicht abgebildet) wird das neue XMLHTTPRequest-Objekt ( req ) sowie die Startzeit des Skripts ( d ) erzeugt.

Wenn der Request beendet ist (Zeile 2) vergleicht das Skript die Anfangs- und Endzeit (d und d2). Wenn die Hosts innerhalb von 10 – 18000 Millisekunden geantwortet haben, dann werden sie als Online deaklatiert.

Diese unterschiedlichen Zeiten entstehen dadurch, dass jeder aktive Host, egal ob er auf Port 80 erreichbar ist oder nicht, dem Browser schneller eine Reaktion auf die Anfrage liefern kann als ein Host der nicht im Netzwerk vorhanden ist. Wenn ein Host nicht im Netzwerk erreichbar ist, läuft der Browser einfach in einen Timeout. Der dauert natürlich deutlich länger…

Es gibt 3 Möglichkeiten, wie ein aktiver Host auf eine Anfrage durch den Browser reagieren kann:

• Er schickt ein RST/FIN-Paket, weil auf diesem Port kein Dienst lauscht.
• Er lässt eine Verbindung zu, weil ein HTTP-Server auf dem Port lauscht.
• Er verwirft das Paket einfach.

Punkt 1 und 3 sind für das Skript ok und geben den Host als aktiv aus. Punkt 3 verfälscht das Ergebnis allerdings enorm. Dieser Fall entsteht durch eine aktive Firewall , die die Pakete einfach verwirft statt diese mit RST zu beantworten. Die Windows-Firewall (ab SP2 XP) ist z.B. so eingestellt. Genauso kann natürlich auch eine iptables-Firewall unter Linux eingestellt sein…

Link zum Test:

http://ha.ckers.org/weird/xhr-ping-sweep.html

Wer selbst ein wenig rumprobieren will, kann sich die Seite einfach abspeichern und im Quelltext das Array “sites”, entsprechend seiner IP-Range im lokalen Netzwerk, anpassen.