Mitternachtshacking

Kostenloses RBL Monitoring & Quick-RBL-Check von Anexia.

http://rbl-check.org/

Könnte man sich trivial auch selber skripten aber ich bin ja faul.

Ein Webmail-Postfach bei Web.de, GMX, Google-Mail etc. ist oft ganz praktisch und insbesondere bei Google kann man Mails recht lange dort gespeichert lassen. Allerdings besteht die Gefahr, dass andere Benutzer an den Mails interessiert sein könnten und irgendwie Zugriff auf das Webmail-Passwort erlangen. Ich erinnere hier nur an den Hushmail-Fall. Wie erkennt man nun so einen unberechtigten Zugriff mit dem eigenen Passwort?

Im Makeuseof-Blog hat Mark O’Neill eine clevere Methode beschrieben, mit Hilfe von Webbugs, kleinen in Mails eingebetteten Bildern, festzustellen wenn unberechtigt auf das eigene Webmail-Postfach zugegriffen wird:

1. Man melde sich bei einem Webcounter an, z.B. www.onestatfree.com, bevorzugt mit einem unverdächtigen Namen
2. Die Welcome-Mail löscht man und merkt sich nur die Account-ID die man später für den Zähler braucht
3. Dann legt man eine interessante Datei, z.B. Passwortliste.html an. In diese HTML-Datei bettet man den Zähler ein
4. Diese Datei schickt man per E-Mail an sich selbst. Am besten mit einem Subject, das einen Angreifer neugierig macht. „Wichtige Passwörter“ ist beispielsweise ein guter Betreff.
5. Damit ist die Falle eingerichtet. Sobald jemand die Mail öffnet, erfasst der Zähler den Zugriff. Über die Auswertungsstatistik des Zählers kann man erkennen, wenn unberechtigte Zugriffe erfolgten.
6. Der Onestatfree-Zähler speichert auch die IP-Adresse und damit weitere Informationen über den Angreifer. Unter Umständen genügt das bereits, den Täter einzugrenzen.

Sehr cool.

Geistige Notiz für mich: Beim Zugriff auf fremde Webpostfächer Javascript abschalten und keine Bilder von fremden Servern nachladen.

„LSO, also known as Flash Cookies or Flash Shared Objects, are somewhat nasty: There are persistent across browsers, don’t get deleted on browser exit nor is there an obvious way for viewing and managing them. One possibility is to use NoScript, disable Flash entirely or disable read/write access to the directories where they get stored is another. But I personally find it interesting to see what sites are actually using those cookies for tracking. So a good solution for this specific issue would something to take back control and have an overview over those sites without giving them access to LSOs.There is one simple solution and it is even supplied by Adobe itself: The Flash Player Settings Manager. It’s actually a Flash movie which is able to access the file system and store the settings.I know, it is weird that it resides on Adobes website and it is far from being perfect at all since it would be much nice to have a real interface to it.“

Direkt geklaut von Fukami. Ich kenne niemanden der sich in Deutschland mit Flash besser auskennt. Es lohnt sich, sein Blog und sein Wiki zu lesen.

Aus den Kommentaren: Für Firefox gibt es die Objection Erweiterung, die ebenfalls LSOs bearbeiten kann.

Das Handbuch of Applied Cryptography von Alfred J. Menezes, Paul C. van Oorschot und Scott A. Vanstone, erschienen bei CRC Press (ISBN 0-8493-8523-7) wird in der 5. Auflage (2001) auch zum Download (PDF und PS) angeboten.

„CRC Press has generously given us permission to make all chapters available for free download.“

und weiter

„Permission is granted to retrieve, print and store a single copy of this chapter for personal use. This permission does not extend to binding multiple chapters of the book, photocopying or producing copies for other than personal use of the person creating the copy, or making electronic copies available for retrieval by others without prior permission in writing from CRC Press.“

Na gut, das Buch neu drucken und binden lassen ist nicht zulässig. Und auch wenn aktuelle Algorithmen wie AES noch nicht behandelt werden, gehört das Buch in jede Sammlung von Online-Büchern.

Eine coole Idee von Heise: Alle Programme und Tools direkt auf einem USB-Stick immer lauffähig dabeihaben und private und dienstliche Programme getrennt verschlüsselt noch dazu.

Pimp my Stick von Axel Vahldiek

unbedingt lesenswert!

Manchmal bin ich selbst überrascht, wenn sich eine Firewall anders verhält, als ich das seit geraumer Zeit angenommen aber eben nie wirklich getestet habe. Gleichzeitig ist das ein Musterbeispiel wie die optische Wahrnehmung die Vorstellung über eine Funktion beeinflussen kann. Heute: Check Point FireWall-1 Implied Rules und Site-to-Site VPN.

Folgendes Szenario:

Ein VPN Remote Access User möchte sich über die linke Firewall mit einem Server im Netz der Filialniederlassung verbinden. Der VPN-User wird von der linken Firewall mit Hilfe eines LDAP-Servers in der Zentrale authentisiert. Zwischen Filiale und Zentrale gibt es ein VPN. Die Konfiguration ist relativ einfach. Zuerst das Site-to-Site VPN von Filiale zu Zentrale einrichten, wahlweise als Simplified oder Tradional VPN. Anschließend eine LDAP Account Unit konfigurieren und testen. Anschließend Konfiguration des Remote Access VPNs und der LDAP-Gruppe und Installation der Policy. Der folgende Screenshot zeigt die Konfiguration:

Sobald die Policy installiert ist, passiert folgendes: Die Anfragen an den LDAP-Server in der Zentrale werden nicht mehr verschlüsselt im VPN-Tunnel sondern plötzlich im Klartext am VPN-Tunnel vorbei übertragen. Sehr seltsam. Wenn man sich die impliziten VPN-Regeln und die regulären Implied Rules anschaut sieht man, dass oben eine implizite VPN-Regel existiert mit der Action „Encrypt & Continue“ und weiter unten eine implizite Regel für ldap zur Kommunikation mit dem LDAP-Server existiert. Die relevanten Regeln sind farbig hervorgehoben:

Die stillschweigende Annahme dieser Darstellung ist, dass wenn zuerst verschlüsselt wird und anschließend ldap erlaubt wird, die LDAP-Anfrage ebenfalls verschlüsselt wird. Das ist leider falsch. In der Check Point SecureKnowledgeBase gibt es dazu einen Artikel #sk26059, der sich mit der Thematik beschäftigt:

Solution: Remove all LDAP queries from the Control Connections and manually define these connections in the Rule Base as encrypted.

Dazu muss auf dem Management Server die Datei $FWDIR\lib\implied_rules.def editiert werden. Die Zeilen

#define enable_ldap_queries { \
all@all accept \
src in firewalled_list, \
<dst,dport> in ldap_servers_list, \
set sr3 0, RECORD_CONN(0xffffff0b); \
}


müssen zu

#define enable_ldap_queries 0


geändert werden. Danach wird LDAP nicht mehr in den impliziten Regeln berücksichtigt und die Verschlüsselung des VPN-Tunnels greift wieder.

Die Alternative zum Editieren von def-Dateien ist in #sk15983 beschrieben. Hier wird empfohlen, die Control Connections statt „first“ als „before last“ bearbeiten zu lassen. Das ist in NGX leider nicht mehr möglich und hat auch den Nachteil, dass dann keine brauchbare Stealth Rule zum Schutz der Firewall mehr konfiguriert werden kann. Also eigentlich auch keine Alternative.

Was ich mir wünschen würde, ist eine Konfigurationsseite in der man auswählen kann, welche Dienste denn in den Implied Rules enthalten sein sollen. So ist das ganz schon ein wenig intransparent, wenn man die Programmdateien von Check Point nicht lesen will.

Und warum fällt mir so etwas in der Praxis eigentlich nicht eher auf? Ganz einfach, wir empfehlen allen Kunden sehr dringend, solche Anfragen an einen LDAP-Server nicht im Klartext mittels ldap sondern verschlüsselt mit LDAP über SSL durchzuführen. Bei Active Directory, das die meisten mittelständischen Firmen einsetzen, ist das recht einfach zu lösen. LDAP über SSL ist von Haus aus eingebaut und muss nur mit passenden Zertifikaten eingerichtet werden. Und wenn man die Implied Rules genau anschaut dann sieht man, dass nur ldap in der impliziten Regel enthalten ist, nicht jedoch LDAP über SSL.

Mit speziellem Dank an Christian B., der mich durch seine unablässigen Fragen überhaupt erst dazu gebracht hat, das auch mal zu testen.

Ich war neulich bei einem Kunden, um eine (relativ) einfache Failover-Lösung zu konfigurieren. In der Hauptniederlassung steht eine Juniper NetScreen-50 Firewall (HA-Konfiguration) angeschlossen an eine Standleitung, in den diversen Niederlassungen NetScreen-5GT Firewalls mit günstigem DSL. Das alles mit einem hübschen Site-to-Site VPN, ein paar Zertifikate zur Authentisierung, alles soweit ganz ok.

Jetzt kam die Geschäftsleitung auf die Idee, wenn das VPN ausfällt, z.B. weil eine DSL-Leitung ausfällt, dann muss es eine Wählbackupleitung geben. Also wurde für jede Niederlassung ein kleiner Cisco 800 angeschafft, der sich bei Ausfall des VPN-Tunnels in die Zentrale einwählen soll. Natürlich auch verschlüsselt. In der Zentrale steht dafür ein etwas größerer Cisco Router. Wie konfiguriert man das nun am einfachsten? Austausch der NetScreen-Geräte war natürlich nicht erwünscht 🙂

Ich hab ein wenig rumexperimentiert, z.B. mit OSPF über die Cisco und Juniper, aber bei Routing im VPN will Cisco einen GRE-Tunnel, den Juniper wieder nicht so gerne hat, die Konfiguration wird richtig fies komplex und das hat sich alles nicht so recht als zufriedenstellend herausgestellt.

Am Ende bin ich auf eine ganz primitive Lösung verfallen: Die NetScreen Firewalls bekommen eine statische Route mit hohen Kosten zum jeweiligen Cisco Router, über den VPN-Tunnel sprechen die Firewalls OSPF und wenn der Tunnel steht bekommt man eine Route mit niedriger Metrik. Das klappt erstaunlich gut, man muss auf den Juniper Firewalls lediglich Route-based VPN einrichten, mit Policy-based VPN geht das leider nicht. OSPF sprechen so nur die NetScreen, nur im VPN und ohne GRE. Die Cisco-Geräte bekommen davon gar nichts mit.

Sehr hilfreich war in diesem Zusammenhang die Juniper Dokumentation. Es gibt da eine Reihe von Anleitungen unter dem Begriff ScreenOS Concepts & Examples. Da sind diverse Konfigurationsvarianten anschaulich sowohl mit GUI als auch CLI beschrieben. Zwar leider nur zwischen Juniper-Geräten aber besser als nichts.

Schade, dass es vergleichbares von Check Point nicht gibt. Da fehlt mir das immer wieder. Könnte fast eine Marktlücke für ein Buch werden. Fall jemand ein solches Buch schreiben will, bitte melden. Ich steuere ein Kapitel zu „Check Point VPN-1 SecureClient zertifikatsbasierte Authentisierung mittels Active Directory und Microsoft Zertifikatsdiensten“ bei. Also LDAP-User mit AD-Zertifikaten authentisieren. Die kurze Anleitung mit ein paar Screenshots hat 68 Seiten 🙂

Ich hatte neulich mal wieder die beliebte Diskussion zur letzten Regel einer Check Point Firewall: „Was ist besser? Drop oder Reject?“ Ich finde, die Frage lässt sich gar nicht so einfach beantworten.

Drop, das ist klar, lässt ein Datenpaket einfach verschwinden. Weg. Futsch. Keine Antwort. Für einen NMap SYN-Scan schön erkennbar: open, closed, filtered. Keine Antwort = filtered. Bei UDP ist das jedoch ein wenig komplizierter, da lässt sich zwischen open und filtered nur schwer unterscheiden. Die IP-Adresse der Firewall krieg man meist trotzdem raus, zum Beispiel oft mit einem TCP-Traceroute. Cain& Abel kann so etwas.

Reject schickt eine Antwort zurück. Nur … welche? Und ist das konfigurierbar wie bei Netfilter?

• ICMP Type 3, Code 0 (Network Unreachable)
• ICMP Type 3, Code 1 (Host Unreachable)
• ICMP Type 3, Code 3 (Port Unreachable)
• ICMP Type 3, Code 13 (Communication Administratively Prohibited)

Zumindest die letzte Fehlermeldung gibt schon sehr genau Aufschluss darüber, dass ein Paketfilter vorhanden ist.

Andere Überlegung: Im Idealfall sollte es eigentlich egal sein, ob der Angreifer weiß, dass eine Firewall vorhanden ist, welche IP-Adresse die Firewall hat, von welchem Hersteller sie ist und welcher Regelsatz implementiert ist. Gut, in der Praxis trifft das oft nicht zu, aber wir glauben heute mal an das Gute im Firewall-Administrator. 🙂

Dann bleibt für mich übrig: Bei einem Reject schickt die Firewall Pakete an eine fremde (d.h. nicht näher bekannte) IP-Adresse. Wenn die Absenderadresse nun gefaked ist, kann man die Firewall leichter z.B. für einen DoS-Sturm missbrauchen und das will ich lieber nicht.

Das ist so ähnlich wie mit den Rückmeldungen per E-Mail, dass eine angeblich von mir verschickte Mail einen Virus enthalten hätte. Nur verwenden viele Viren gefälschte Absenderadressen aus den Adressbüchern und meistens ist genau der, der als Absender drinsteht für den Virus gar nicht verantwortlich. Und ich freue mich bestimmt nicht über die penetrante Werbung einzelner Virenscannerhersteller, dass sie wieder einen Virus vernichtet haben (aber nicht in der Lage sind zu erkennen, dass die Absenderadresse gefälscht war und eine Rückmeldung daher sinnlos).

Ich habe letztens von einem Kollegen die ersten Kapitel seines neuen Check Point Buchs vorab zum Lesen bekommen. Weil das Buch noch nicht beim Verlag auf der Webseite steht, will ich hier keine Details nennen. Die Buchdaten folgen also später.
Jedenfalls ist das Buch hochinteressant! Da stehen einige Sachen drin, die ich nicht wusste, z.B. dass es möglich ist, in einem Check Point Cluster auch dann die einzelnen Nodes synchronisieren zu lassen, wenn darauf unterschiedliche Versionen laufen.

Mit dem Kommando fw fcu <IP-Adresse> kann man manuell die State Table vom alten auf den neuen Node synchronisieren und dann den alten Node abschalten. Allerdings muss dazu vorher das Cluster Control Protocol auf Broadcast umgeschaltet werden

Ein Buch für den fortgeschrittenen Anwender 🙂