dimis linkdump

Posts tagged ‘firewall’

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.

Windows Update in der Windows Firewall freischalten

Die darauffolgende Fehlermeldung können wir ignorieren.

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

Windows Update in der Windows Firewall freischalten

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.

Nachdem man einige Zeit Dansguardian genutzt hat erkennt man, dass Dansguardian doch einige Sachen blockt, die eigentlich harmlos sind. Folgende Einstellung habe ich nach einer Testwoche bei mir getätigt.

Zuerst habe ich etwas aktiviert, was man eigentlich nur im privaten Bereich aktivieren sollte. Den Filter-Bypass. Damit lässt sich per Link eine geblockte Seite temporär freischalten. Dazu klickt man einfach auf den in der Block-Seite eingeblendeten Link (ganz unten im Bild):

Dansguardian ByPass

Der Bypass-Link übergibt Dansguardian eine GET-Variable mit einer Bypass-Key:

http://www.google.de/search?hl=de&q=[...];GBYPASS=AD92B73FD7BA874240BF9C7708DDA9FA1244672750


Diesen Key kann Dansguardian entweder automatisch generieren oder man kann selbst einen Key festlegen. Wird nun in einem eigentlich gesperrten Link, diese GBYPASS-Variable mit gültigem Wert übergeben, schaltet Dansguardian die Seite für eine bestimmte Zeit frei.

Anzumerken ist hierbei, dass bei einem Virus-Fund der Bypass-Link auch erscheint, aber keine gütlige Bypass-ID mit übergeben wird – d.h. ein Anwender kann keinen durch ClamAV gefundenen Virus mit dem Bypass auf den Rechner laden.

Einstellen des Filter-Bypass

In der gruppenspezifischen Konfigurationsdatei (/etc/dansguardian/dansguardianf1.conf) gibt es eine Zeile bypass = 0. Hier wird in Sekunden eingestellt, wie lange ein Bypass gütlig ist. Mein Wert: bypass = 300. Damit ist mein Bypass also 5 Minuten gültig. 0 deaktiviert den Bypass. Mit dem Eintrag bypasskey = ‘ ‘ könnte man einen eigenen Bypass-Key festlegen. Lässt man den Eintrag leer, generiert Dansguardian selbst einen Key.

Nun muss der Link noch in das Template der Blockseite eingebaut werden. Dazu bearbeiten wir folgende Datei: /etc/dansguardian/languages/german/template.html.  German ist hier natürlich entsprechen der in der dansguardian.conf eingestellten Sprache zu wählen. (Siehe 1. Blogeintrag zu Dansguardian).

In diese Datei fügen wir nun, an der gewünschten Stelle, folgenden HTML-Code ein:

<tr>

<td>

<td>

<center><a href=”-BYPASS-”>Bypass</a></center>

</td>

</tr>

Die Variable -BYPASS- ersetzt Dansguardian durch den Bypass-Link. Also z.B. durch:

http://www.google.de/search?hl=[…[&GBYPASS=AD92B73FD7BA874240BF9C7708DDA9FA1244672750

Damit hat nun jeder User die Möglichkeit den Filter kurzfristig zu umgehen.

Früher war es so, dass ein Großteil der Malware per E-Mail den Weg auf die Rechner fand. Heute ist es so, dass die meiste Malware über HTTP, also über Webseiten, verbreitet. Da bietet es sich doch an einen Contentfilter einzusetzen, der HTTP-Traffic scannen kann.

Ich habe mich dazu entschieden Dansguardian in Verbindung mit dem kostenlosen Virenscanner ClamAV auf meinem Gateway zu testen.

Installation

Dank Debian ist die Installation von Dansguardian ein Kinderspiel:

apt-get install dansguardian squid3

Mit diesem Befehl installiert Debian automatisch Dansguardian und squid3.

Konfiguration

Für den Anfang ist in der Squid-Konfigurationsdatei nichts zu machen – wenn sich Squid und Dansguardian auf dem gleichen Server befinden. Squid erlaubt per Default dansguarianden Zugriff, wenn die Quelle des Zugriffs der localhost ist. Da sich in diesem Fall Squid und Dansguarian auf dem gleichen System befinden, sind die default-Einstellungen des Squid ausreichend.

/etc/squid3/squid.conf

acl localhost src 127.0.0.1/32
http_access allow localhost

Im Dansguardian hingegen gibt es Einstellungen, die geändert werden müssen / können / sollten:

/etc/dansguardian/dansguardian.conf

language = ‘german’

contentscanner = ‘/etc/dansguardian/contentscanners/clamav.conf’

Damit, funktioniert Dansguardian erstmal und untersucht allen Traffic mit ClamAV. Dansguarian lauscht per default auf Port 8080. Also muss im Browser die IP des Servers und dieser Port als Proxy eingetragen werden.

Noch einige wichtige Verzeichnisse:

/var/log/dansguardian/access.log – Speichert die Webseiten-Zugriffe

/etc/dansguardian/lists /- beinhaltet alle Listen, nach denen Dansguarian filtert.

/etc/dansguardian/languages/ – beinhaltet alle verfügbaren Sprachen

Soweit für den Anfang. Vor allem wenn man Dansguarian im privaten Bereich einsetzt, findet man mit der Zeit sicher einige Einstellungen, die man gerne ändern will. Mein Feintuning beschreibe ich dann in einem weiteren Post…

RSS-Feed Creative Commons License