Hin und wieder wundern sich Administratoren, warum aus ihren Netzen heraus p2p Programme wie Skype oder eMule funktionieren, wo doch die Firewall eingehenden Datenverkehr rigoros blockiert.
Ich möchte nun versuchen etwas Licht in dieses eigenartig scheinende Verhalten zu bringen.
Bei den genannten Programmen handelt es sich nicht um reine p2p Protokolle, es spielt immer ein Server eine entscheidende Rolle.
Nehmen wir an, Alice (IP 10.0.0.1) möchte mit Bob (11.0.0.1) kommunizieren. Dafür schickt sie eine entsprechende Anfrage an den Server, welcher diese an Bob weiterleitet, und ihm zusätzlich die Information gibt, das Alice Port 2020 verwendet. Bobs Firewall lässt die Pakete des Servers durch, da zu diesem eine permanente TCP Verbindung besteht. Nun schickt Bob ein UDP (Port 2020) an Alice. Wie erwartet blockt die Firewall von Alice dieses Paket, die Firewall von Bob jedoch erlaubt nun Antworten von Alice. Sobald Alice nun ihrerseits ein Paket an Bob schickt, erlaubt auch ihre Firewall die Kommunikation, welche jetzt p2p zwischen den Partnern stattfindet.
Genutzt wird dabei die Eigenschaft vieler Firewalls, UDP auch „verbindungsorientiert“ zu betrachten. Stimmen die Adressen und Portnummern, so werden die übertragenen Daten schon zu einer Verbindung gehören, eine Schlussfolgerung die nicht immer zutreffend ist. Im Gegensatz dazu werden bei TCP echte Verbindungen ausgehandelt.
Man sollte also sehr genau darüber nachdenken, ob wirklich sämtlicher ausgehender Verkehr erwünscht ist.

Bookmark to:

Allgemein, Security | 3 Kommentare »

Tags: Firewall, eMule, Skype, p2p

Viel wurde, landauf landab, schon über RFID Diskutiert, ist es Segen oder Fluch, wie Sicher ist das ganze, was passiert mit unserer Privatsphäre u.s.w. Sicher, der Komfort ist nicht von der Hand zu weisen. Ich kann mich in Gebäuden frei bewegen, Türen die ich passieren darf öffnen sich magisch, ich muss nicht mehr an der Kasse anstehen, und meine Mikrowelle weiß wie das Fertiggericht zuzubereiten ist. Ebenso vielfältig sind die Nachteile. Sollten Geldscheine mit RFID ausgestattet werden, weiß jeder Mensch mit zweifelhafter Gesinnung, ob ich ein lohnendes Opfer bin, mein Tagesablauf, wann ich mich wo aufhalte, ist auch sauber Nachvollziehbar, ebenso wie mein sozialer Status (RFID in Kleidung, auf Kreditkarten u.s.w.) Und schließlich merkt auch der Müllmann sofort, ob die Verpackung des bequemen Fertiggerichtes in der richtigen Tonne gelandet ist.
Nun, jedoch ist keiner dieser Technik schutzlos ausgeliefert. Seien es kleine Faradaysche Käfige, in welche die Chips gesperrt werden, oder deren komplette Zerstörung, doch diese Verfahren ist zweifelhaft, da umständlich und teilweise irreversibel.
Einer der heftigsten, aber auch angesehensten Kritiker dieser Technik ist Andres S. Tanenbaum, und von ihm kommt ein sehr interessanter Ansatz. Der RFID Guardian würde ursprünglich entwickelt, um den Träger von RFID Chips zu informieren, wenn dessen Informationen ausgelesen werden sollen. Inzwischen entwickelt sich der Guardian zu einer Art ‘personal Firewall’ (nie war diese Bezeichnung passender) für RFID, welche dem Benutzer Kontrolle darüber gibt, wer wann welche Informationen erhalten darf.

Ich finde diesen Ansatz durchaus bemerkenswert, schafft er es doch vielleicht den Komfort von RFID zu erhalten, und die Gefahren/Missbrauchsmöglichkeiten einzudämmen. Für weitere Informationen sei die Homepage des Projektes empfohlen.

Bookmark to:

Thoughts, Adventskalender | 2 Kommentare »

Tags: RFID, Firewall, security

Über den Sinn und Unsinn von Desktop Firewalls wurde vielerorts bereits hinlänglich gestritten. Größter Kritikpunkt: Der normale Nutzer weiß nicht, welchen Programmen und Diensten er welche Art von Verkehr erlauben soll. Mit dem Produkt ‘Integrity‘ bietet Checkpoint dazu ein beeindruckend mächtiges Werkzeug, dieses Problem zu lösen.
Nun, Integrity ist kein Produkt aus dem Hause Checkpoint, sondern gelangte durch den Kauf von ZoneLabs ins Portfolio, und so stellt sich die GUI des Clients auch dar wie die bekannte Desktop Firewall ZomeAlarm.
Doch Checkpoint hat zusätzlich zu diesem Client einen Server entwickelt, welcher das Policy Management (Verwaltung und Verteilung) übernimmt.
Dieser kann Restriktionen auf Zonen- Protokoll- und Applikationsebene einrichten und verwalten. Protokollebene ist klar, eine schnöde Layer 4 Firewall, die anhand von Portnummern und Adressen aus den verschiedenen Zonen (trusted, internet) Pakete zulässt – oder eben nicht. Mächtig sind die Regeln auf Programmebene. Der Client gestattet nur bekannten Programmen (basierend auf Filename, Checksumme u.ä.) den Zugriff aus bestimmte Netzwerkbereiche, oder hindert diese Programme gar ganz an der Ausführung. Ebenso kann er feststellen, welche AV Software installiert ist, ob diese aktuell ist, oder etwa welche Windows Hotfixes auf dem System installiert sind. Erfüllt der Client bestimmte Anforderungen nicht, wird ihm der Netzzugang eingeschränkt, oder ganz verboten.

Das Management solch einer Fülle von Programmen und Regeln kann schnell unübersichtlich werden, doch auch hier hilft der Integrity Server weiter. Zum einen meldet jeder Client die Programme, welche ins Internet wollen, an den Server (und behandelt die erstmal nach seinem default Schema). So bekommt der Administrator einen Überblick, welche Software auf welchen Versionsständen in seinem Netz aktiv ist. Danach kann er anhand dieser Liste Regeln für die Programme definieren. Ein zweites Hilfsmittel sind Referenzsysteme, nach dem Motto: “Die Software auf diesem System ist auch auf allen anderen erlaubt”. So genügt es, ein System aktuell zu halten, die Restlichen folgen von allein, denn wird ihnen aufgrund eines fehlenden Patches der Netzzugang verwehrt, kann der Integrity Server zusammen mit der Fehlermeldung auch gleich den entsprechenden Patch ausliefern.

In Zeiten, in denen Laptops und PDA’s immer selbstverständlicher werden, und Mitarbeiter durchaus auch in wenig vertrauenswürdigen Netzen unterwegs sind, ist diese Lösung sicher eine gute Hilfe für jeden Administrator, um nicht nur die Schnittstelle seines Netzes mit der Außenwelt, sondern auch den Verkehr in seinem Netz zu überwachen. Denn die Lösung funktioniert auch mit VPN Verbindungen: Während eMule läuft, ist kein VPN möglich.

Integrity ist hier noch lange nicht am Ende, falls jemand Interesse hat möge er einen kurzen Kommentar hinterlassen, evtl. entsteht ein zweiter Teil zum Überblick, oder ein kurzes HowTo.

Bookmark to:

Security, Checkpoint | Kein Kommentar »

Tags: Checkpoint, Firewall

Eine Firewall sollte das dahinter liegende Netzwerk beschützen, und tut dies so gut es ihre Regelbasis zulässt. Demnach ist eine Firewall nur so gut wie ihr Administrator. In der Literatur wird immer wieder von zwei Regeln gesprochen, die quasi als obligatorisch angesehen werden. Unbestritten ist die „Cleanup Rule“ eine solche Regel. Sie stellt im Allgemeinen den Abschluss der Regelbasis dar, und blockt jedwede Kommunikation, die bis dahin nicht erlaubt wurde. Die zweite dieser Standardregeln ist oft eine der ersten, die so genannte „Stealth Rule“. Sie verbietet jede direkte Kommunikation mit der Firewall selbst, so das diese quasi unsichtbar wird. Natürlich muss der Administrator dafür Sorge tragen, das er sich damit nicht selbst aussperrt. Bei vielen Produkten geschieht dies über vordefinierte implizierte Regeln, die den Verbindungsaufbau zum Firewallmanagement von bestimmten Rechnern aus erlauben.

Nun, ich sehe diese Regel durchaus kritisch. Natürlich sollte man kein unnötiges Risiko eingehen, und zum Beispiel ssh „von außen“ verbieten, wenn man ohnehin nicht vorhat, es derart zu nutzen. Schließlich muss man einem Angreifer nicht die Chance geben, das Passwort dafür zu erraten. Das auf der Firewall keine weiteren Dienste laufen sollten, welche nicht unbedingt notwendig sind, bedarf eigentlich keiner weiteren Erwähnung. Bleibt noch ICMP. Ist dessen Sperrung notwendig? Mit, wie es bei Planetopia hieße, „einschlägigen Tools“ (ping, nmap) lässt sich eine Menge über das System in Erfahrung bringen. In der Vergangenheit wurde ICMP auch für Angriffe genutzt, wobei der „Ping of Death“ wohl die bekannteste Attacke ist. Wieso also solche Risiken auf sich nehmen, und dem Angreifer einige Ansatzpunkte für Angriffe liefern? Es gibt aber auch Stimmen, welche ICMP als derart essentiell ansehen, das dessen Einschränkung für sie einen nicht hinnehmbaren Verlust darstellt. In der Tat ist Netzwerkdiagnose ohne ICMP gelinde gesagt ein Ding der Unmöglichkeit. Ich möchte mit dieser Einleitung gern eine kleine Diskussion über das Für und wieder der „Stealth Rule“ beginnen. Wohlgemerkt geht es dabei um Verbindungen zur Firewall, ob, wie und wo ICMP im restlichen Netz behandelt wird soll hier zweitrangig sein.

Bookmark to:

Security | 3 Kommentare »

Tags: Firewall