Für die Absicherung eines CorpNet ist es unerlässlich, dass die Kommunikation nur mittels definierten, dokumentierten und gewollten – sprich vom Admin erlaubten – Protokollen funktioniert. Der Rest mag vielleicht gewollt sein, ist aber schlichtweg nicht erlaubt und wird bei guter Netzabsicherung schlichtweg irgendwo protokolliert und anschließend verworfen.
Der Security-GAU
Für die Sicherheit von Firmendaten sind Programme wie Skype ein großes Risiko, erlauben Sie doch mittels ausgefeilten Techniken übliche Absicherungsmaßnahmen zu umgehen.
Sieht man mal von der benötigten Bandbreite dieser Anwendungen ab, baut der Skypeclient durch die P2P Architektur Verbindungen zu unbekannten IP Adressen auf und verschlüsselt den Datenverkehr Ende-zu-Ende – sprich von Client zu Client. Ein Angreifer muss sich also nicht mehr mit lästigen Sicherungsmaßnahmen an der Firewall, etc. kümmern sondern kommt bei Kontakt gleich zum Client durch.
Entscheidet die Sicherheit einer lokal installierten Anwendung oder die Absicherung fremder, nicht zum CorpNet gehörender Systeme (Skypeserver, Supernodes, …) über die Sicherheit im gesamten CorpNet hat ein Admin spätestens hier ein Problem.
Ein Grundsatz im Netzwerkbereich lautet
All traffic is evil.
Ein Fehler im Skypeclient oder der Anwender klickt einmal falsch und ein 0-day befindet sich im CorpNet. Die Tatsache, das der Skypeclient nicht quelloffen verfügbar ist, reduziert die Angst vor Risiken nicht gerade. Somit ist nur eins wirklich sicher: Skype ist eine Blackbox. Dokumente wie dieses (PDF) belegen dieses eindrucksvoll.
Also was kann man tun? Irgendwer meinte mal, die beste Methode das Programm von der Kommunikation abzuhalten ist, das Programm erst nicht zu installieren. Das mag zwar sein, hilft aber nicht, wenn man bereits Skypeinstallationen im CorpNet hat. Also lassen wir mal die zahlreichen Möglichkeiten der GPO außen vor, und schauen uns die Ebene der Kommunikation an.
1) Wer verschlüsselt, hat etwas zu verbergen!
An dem Paketfilter für ausgehende Kommunikation kann man als Sofortmaßnahme verschlüsselte Datenkommunikationen blocken.
Der Vorteil
Da das Skype Protokoll verschlüsselt funktioniert, wäre somit keine Datenkommunikation über Skype mehr möglich.
Der Nachteil
Die einfache Firewall reicht nicht – ein Paketfilter muss es sein. In der Realität unpraktikabel da viele Businessprozesse sofort zum erliegen kommen. Will ein Mitarbeiter z.B. etwas über eine verschlüsselte Verbindung bei einem Lieferanten bestellen, wäre dieses so nicht mehr möglich. Auch dürfen meist die Mitarbeiter privat das Internet nutzen – und ein verschlüsselter Zugriff auf den Webmailer ist alle Mal sicherer – und erwünschter – als ein unverschlüsselter Zugriff über http.
2) Mistraue jedem, jeder fremde ist böse!
Für ein sauber geplantes CorpNet existieren nicht nur Netzpläne sondern für jeden Client ist klar, mit welchen Maschinen er kommunizieren können muss.
Der Vorteil
Plant man die Kommunikation sauber, kann man nicht nur schneller Fehler diagnostizieren sondern auch einfacher seine Daten im Netzwerk halten.
Der Nachteil
Der Aufwand für die Ersteinrichtung ist vielleicht etwas höher, da man Anwendungen genauer analysieren muss – sich mit Lieferanten und Herstellern auseinander setzen muss und die besten Ergebnisse in einer homogenen Umgebung erzielt – wo die Geräte zentral gemanaged werden.
Szenario: Man stelle sich vor, ein Vertreter kommt ins Haus, präsentiert eine Onlinedemo seiner Software und muss dazu sein Notebook ans CorpNet anschließen. Im Hintergrund verteilt der Vertreter nicht nur unbemerkt Viren und Würmer im CorpNet sondern protokolliert auch den Traffic mit.
Also was tun? Die alten Hubs rauswerfen und auf Switching setzen? Möglich aber für die Problematik bringt das wenig Vorteile. Frei verfügbare Tools erlauben das aushebeln von ARP Tabellen und dem Spoofing steht nichts mehr im Weg.
Ein möglicher Ansatz für die clientseitige Netzabsicherung beschreibt das BSI in seinem Grundschutzkatalog: Windows mit der Unterstützung von IPSec härten. Über eine zentrale Verwaltung wie die Gruppenrichtlinien kann man einem Domänenmitglied diesbezüglich alle Vorgaben machen, die benötigt werden, um Szenarien wie Skype und Co die rote Karte zu zeigen.
Unter Windows 2003 Server sorgt die Domänenisolierung dafür, dass nur Domänenmitglieder untereinander Daten tauschen können – eine starke verschlüsselte und digital signierte Kommunikation reduziert das Man-In-The-Middle Problem erheblich und ignoriert andere Pakete
Hat ein Netzwerkwurm oder ein Virus ein System im CorpNet befallen, und versucht dieser sich zu verbreiten, kann man dem durch den geschickten Einsatz von IPSec Richtlinien die Kommunikation soweit einschränken, dass eine Verbreitung stark eingeschränkt wird.
Dazu muss man sich nur die Frage stellen ob sich zwei Clientsysteme im CorpNet unbedingt miteinander unterhalten müssen. Was stellt ein Client für Netzwerkdienste bereit, die es erfordern, das andere Clients darauf zugreifen müssen?
Drucker? In einem CorpNet werden die in der Regel von einem Printserver bereit gestellt der neben der Druckertreiberausbringung auch noch andere Verwaltungsfunktionen bereitstellt.
Serverdienste? Ein Client ist in der Regel technisch nicht für den 24×7 Betrieb ausgelegt – und so ist es immer eine schlechte Wahl, wichtige Dienste auf einem Clientsystem auszuführen.
Fileservice? Keine gute Lösung denn ein lokal arbeitender Mitarbeiter gefährdet bei Unachtsamkeit ggf. vertrauliche Dokumente. Zumal – wird das Clientsystem nachts heruntergefahren oder kommt es zu einem Stromausfall (selten sind die Clientsysteme mit einer unterbrechungsfreien Stromversorgung ausgestattet) können Dokumente beschädigt werden.
IPSec hat den Vorteil dass es auf der 3. OSI Ebene angesiedelt ist. So kann es Pakete analysieren und verwerfen, bevor die Anwendungen etwas davon erfahren.
Z.B. wird so ein unsigniertes Paket von dem infizierten Client A an den Port 139 von Client B verworfen, noch bevor der Windows-Dienst erreicht.
Als Nachteil wirkt sich aus, dass IPSec serverseitig nicht alles absichern kann: bestimmte Netzwerkdienste müssen eben frei zugänglich bleiben da diese zum Teil greifen, bevor der IPSec Treiber geladen worden ist – z.B. DHCP. Will man mittels RIS ein Bootimage ausbringen, benötigt der Client eine IP Adresse, noch bevor Windows überhaupt geladen ist.
Teil II folgt.
No Comments on "Blocking evil communication (Teil I)"