Keine einfache »Katzenklappe« für den Netzwerkzugang

Keine einfache »Katzenklappe« für den Netzwerkzugang Die geplanten Frameworks zur Netzzugangskontrolle sind weitgehend noch proprietär und vor allem auch noch nicht besonders stabil. Die Anwender sollten deshalb einen Einstieg wählen, der ihnen möglichst wenig verbaut.

Das Thema der Netzzugangskontrolle spielte vor anderthalb Jahren bei unseren Kunden eine große Rolle, derzeit ist es sehr ruhig geworden«, sagt Dr. Christoph Skornia, Technischer Manager bei Checkpoint in Deutschland und hat auch eine plausible Erklärung dafür: »Die Kunden merken sehr schnell, dass das Thema sehr viel konzeptionelle Arbeit erfordert«. In der Tat liegen zwischen der Absichtserklärung, nur »saubere Rechner« ins Netz hineinzulassen beziehungsweise diese vor Einlass auf den neuesten technischen Stand zu bringen und der technischen Umsetzung dieses ebenso verständlichen wie ambitionierten Vorhabens viel Arbeit und noch mehr ungeklärte Fragen. Eine einfache »Katzenklappe«, durch die nur erwünschte Geräte ins Netz kommen, gibt es nicht. Es ist ja nicht unmittelbar einsichtig, wie man den Zustand eines Rechners, der Einlass ins Netz begehrt, umfassend prüfen können soll, ohne ihn ins Netz »wenigstens ein bisschen« einzulassen. Klar doch: Netzseparierung, Quarantäne-Netze oder auch eine ordentliche Authentifizierung und Identifizierung können hier durchaus einige Barrieren aufrichten, doch die große saubere Lösung gibt es nicht und wird es wohl auch nie geben. Das Gleiche gilt für Maßnahmen, wie man Rechner auf Vordermann bringt. Hier sind unter Umständen nicht nur schwierige technische Fragen zu lösen, sondern auch die rechtlich-organisatorische Frage, inwieweit man Fremdrechner überhaupt verändern darf.

Fertige Kisten oder grosse NAC-Projekte? »Zwischen dem Wunsch nach einem sauberen Netz und dessen technischer Umsetzung steht viel Beratungsarbeit«, weiß Checkpoint-Manager Skornia aus seiner Projekterfahrung. Ein Netzwerkzugangskontroll-Produkt zum Kaufen und schnellen Installieren gibt es nicht. Freilich gibt es von sehr vielen Anbietern sogenannte NAC-Appliances (NAC steht für »Network Admission Control«), die noch am ehesten einer schnellen Lösung entsprechen. In­wieweit man dann sein Netz wirklich sicher macht, steht dahin. Richtig ist ­sicher, dass man erst einmal in einem überschaubaren Rahmen investiert, während ein echtes Netzwerkzugangskontroll-Projekt nach oben kostenmäßig relativ ­offen ist. Das hat viele Ursachen: Die grundsätzlichen Unsicherheiten wurden weiter oben schon angedeutet. ­Daneben gibt es konkurrierende Framework-Vorschläge (Network Admission Control (NAC) von Cisco, Network Admission Protection (NAP) von Microsoft und Trusted Network Connect (TNC) der Trusted Networking Group. Diese sind allesamt weitgehend auf die Netzwerk­komponenten beziehungsweise Betriebssysteme der jeweiligen Protagonisten ausgelegt (NAC für Cisco-­Komponenten und NAP für Windows Vista) oder sind bisher weitgehend ­Papertiger (TNC) geblieben. Auch wer eine homogene Switch-Landschaft von Cisco hat oder absolut Microsoft-lastig bei den Betriebssystemen ist, kann indes nicht sicher sein, in diesem Fall die entsprechenden Netzzugangskontrollsysteme ohne größeren Aufwand instal­lieren zu können. Es kann leicht sein, dass ältere Hardware- und Software-Komponenten nicht für NAC oder NAP ausgelegt sind. Die Konzepte von Cisco und Microsoft sind übrigens relativ ähnlich – das eine ist eben mehr switch-orientiert, das andere eher betriebssystemorientiert –, sodass unter der IETF-Haube ein Zusammenspiel beider Systeme angestrebt wird. Erste diesbezügliche RFC-Dokumente soll es nach Aussage von Klaus Lenßen, Business Development Manager von Cisco in Deutschland, Anfang Mai 2007 geben.

Schwachstellen bei NAC und NAP Insgesamt sind die genannten Frameworks auch in sich selbst noch im Fluss, sodass die Anwender vor unliebsamen Überraschungen nicht sicher sein können. So stellten die beiden ­Sicherheitsexperten Dror-John Röcher und Michael Thumann der Heidelberger Netzwerk-Beratungsfirma ERNW Enno Rey Netzwerke auf der Black-Hat-Konferenz Ende März in Amsterdam ein Angriffssze­nario vor, mit dem sich das NAC-Framework von Cisco aushebeln lässt. Basis des Angriffs ist ein selbst entwickelter NAC-Client, der die Cisco Prüfsoftware »Cisco Trust Agent (CTA) austrickst. Der CTA kann, so Röcher und Thumann, von einem erfolgreichen Angreifer übernommen und damit das »Selbstverteidigungssystem« (Cisco-Jargon) total unterhöhlt werden [1]. Röcher und Thumann sehen einen Hauptschwachpunkt des Cisco-NAC-Konzepts darin, dass dieses Autorisierungen ohne Authentisierung zulasse. Nach Einschätzung der Netzwerker hat auch das NAC-Pendant NAP von Microsoft mit ähnlichen Problemen zu kämpfen, doch stelle die tiefe Inte­gration des Schutzsystems in das ­Windows-Betriebssystem und das notwendige Zusammenspiel mit Active Directory einen potenziellen Angreifer vor größere praktische Probleme.

Die Crux mit den ­unbekannten Geräten Angesichts der vielen ungeklärten Fragen bei der Netzzugangskontrolle ­einerseits und der Dringlichkeit eines Schutzes andererseits wird man in der Regel gut beraten sein, Lösungen zu wählen, welche die ­Zukunft offen halten. Letztlich erfordert eine konsequente Netzzugangskontrolle weitgehend keine neuen Geräte und Programme, sondern stellt nur (!) eine sehr komplexe Vernetzung all der bereits eingesetzten Abwehrmechanismen dar. Auch ein zentrales Management, was unabdingbar für das Sauberhalten des Netzes ist, ist ja in der Regel in jeder Netzsteuerung, die diesen Namen verdient, enthalten. Die Crux einer Netzzugangskontrolle besteht darin, dass sowohl Authentisierung und Identifizierung als auch die Autorisierung gleichermaßen wichtig sind. Es reicht nicht aus, nur zu autorisieren und auf die strenge Authentisierung zu verzichten (wie in den lascheren Varianten des NAC-Frameworks von Cisco) und andererseits hat man mit einer 802.1x-Authentisierung oder über einen Radius-Server noch nicht den Einlass begehrenden PC inhaltlich geprüft. Erschwerend kommt hinzu, dass eine auf Layer 2 basierende 802.1x-Authentisierung in VPN-Umgebungen nicht eingesetzt werden kann. In diesen Fällen sollte eine starke Authentisierung am VPN selbst aufgebaut werden. Ein weiterer Knackpunkt ist die Überprüfung von unbekannten Ge­räten, auf denen man keine Client-Software aufbringen kann. »Ohne Client-Software ist man bei dem heu­tigen Schadsoftware-Potenzial chancenlos«, sagt Christoph Skornia von Checkpoint. »Die verseuchten Rechner verschlüsseln ja in der Regel ihre Schadsoftware, trojanische Pferde kommen über https ins Netz, was ­wollen Sie da noch ohne Kontrollsoftware direkt auf dem Client machen«, zweifelt Skornia die Wirksamkeit sogenannter klientenloser Lösungen an. Viele Anbieter stellen die Sache etwas allzu einfach dar: Unbekannte Rechner, die keine spezielle Client-Software enthalten, werden in Quarantäne gesteckt und erhalten für sehr eingeschränkte Dienste spezielle IP-Adressen aus dem Gastnetzwerk zugewiesen. Guido Sanchidrián, Sicherheitsspezialist bei Symantec, spricht von einem virtuellen Desktop, der eine »abgeschottete Arbeitsoberfläche bereitstelle«. Damit ist natürlich das Problem nicht gelöst, aber das Schadenspotenzial ist dadurch sicher eingegrenzt. Klaus Gheri, technischer Vordenker beim Innsbrucker Konnektivitätsspezialisten phion zeigt Grenzen und Möglich­keiten einer solchen Vorgehensweise: »Sie schützt innerhalb der Kollisionsdomäne nicht vor bösartigen Angreifern, ist jedoch ausreichend, um Würmer und ähnliche Schädlinge in ihrer Ausbreitung wirksam zu behindern«. Trotz der suggestiven Bezeichnung muss natürlich auch bei der sogenannten client-losen Lösung wenigstens ein kleines Stückchen Software auf den unbekannten Rechner aufgebracht werden Das spielt sich dann auf einer Netzwerkebene ab, die schon so hoch ist, dass man auch sagen könnte, der unbekannte Rechner ist quasi im Netz. Wenn ein solcher Rechner Schad-Software enthält, ist nur zu hoffen, dass die ­installierten Abwehrsysteme das Schlimmste verhindern können.

Offenheit in Richtung ­Framework Wer bei den Herstellern nach tech­nischen Einzelheiten von Authenti­sierung und Autorisierung fragt, ­bekommt einen Wust von Antworten. Grundsätzlich können die Hersteller fast alles: Das ist wahrscheinlich noch nicht einmal falsch, da »Netzwerk­zugangskontrollmechanismen« letztlich kein Produkt, sondern das Er­gebnis eines langen Beratungsprozesses sind« (Christoph Skornia). Zwischen den großen unvollendeten (und wahrscheinlich unvollendet bleibenden Frameworks) bieten Firmen wie phion, Sophos, Juniper, McAfee und Checkpoint (um nur einige zu nennen) ­Lösungen in Hardware und Software an, von denen gesagt wird, dass sie ­einerseits wirksam schützen, die aber ­andererseits nicht den Weg in eine der Framework-Welten verbauen, sollten diese doch einmal ein Ganzes ergeben. Übrigens hat auch der Framework-Protagonist Cisco eine »NAC-App­liance«. Offenheit und spätere Andock­möglichkeiten an die Frameworks sind ­deshalb Verkaufsargumente vieler ­Hersteller. »Bei vorhandener Cisco-Infrastruktur kann Microsoft NAP durch die Unterstützung von EAPo­ver­­UDP und EAP­fast (zwei Authentisierungsprotokollvarianten, d.R.) den Cisco ACS (das ist der Richtlinienserver im Cisco-Framework, d.R.) nutzen« (Originalton Microsoft). Auch HP Pro­Curve preist seine offenen Konzepte: »ProCurve stellt in diesem Zu­sam­menhang die wohl fle­xibelste Lösung bereit, da diese sowohl mit ­dem Framework der Trusted Network Connect-Grup­pe als auch mit dem kommenden MS NAP (in­tegriert im Longhorn-Server, d.R.) zusam­menarbeiten kann und schon heute umfang­reiche Möglichkeiten der Authentisierung, Au­­tori­sierung und Integritätsprüfung bietet«, sagt Holger Hasenaug, Technischer Berater bei HP ProCurve. Nach allen Seiten offen gibt sich auch Sophos: »Sophos NAC nutzt den universellen Charakter von DHCP für die Netzwerkzugangskontrolle und die Durchsetzung von Richtlinien«. Darüber wirbt man aber auch mit ­Zusatzfeatures: Sophos NAC überwacht proaktiv auch Anwendungen wie beispielsweise P2P-Programme, die von Microsoft NAP oder Cisco NAC nicht gemeldet werden« (Originalton Sophos).

Einfache SNMP-Lösung Letztlich dürfte die Vorstellung, nur saubere Endgeräte ins Netz zu lassen, die Schmutzfinken in Quarantäne zu halten oder zu reinigen oder ganz ­isoliert nur ein paar wenige Dinge machen zu lassen, nur schwer in der Praxis umzusetzen sein. Womöglich scheitern diese idealtypischen Vorstellungen an den täglichen Gegebenheiten des Netzbetriebs beziehungsweise den tatsächlichen Abläufen innerhalb eines Unternehmens. Manche Unternehmen mögen sich deshalb auch mit sehr viel weniger ­ambitionierten Lösungen wie der Netzwerküberwachungslösung macmon des Berliner Netzwerkspezialisten mikado zufrieden geben. Dabei handelt es sich um eine Serverlösung, wo die Netzkomponenten über das SNMP-Protokoll abgefragt werden. »Unsere Kunden wollen einen einfachen Betrieb, der keine hochquali­fizierten Netzwerker bindet, sondern wo ein Großteil der organisatorischen Tätigkeiten (Umgang mit Fremdge­räten, Umzüge, Neugeräte einbringen) vom Helpdesk umgesetzt wird«, beschreibt Petter Danielsen, Geschäftsführer bei mikado, die Motivation ­seiner Kunden. Trotz dieser bewusst bescheidenen Haltung im Vergleich zu den Konzepten der großen Zugangs-Frameworks bleibt aber auch bei macmon die Zeit nicht stehen: »In Planung ist eine Erweiterung, in der über eine Agentensoftware die Aktualität der ­Sicherheitspatches und des Virenschutzes überprüft wird und bei Be-darf eine Umschaltung in ein Korrekturnetz ausgelöst werden kann«, sagt Danielsen.

Referenzen [1]: http://www.ernw.de (Newsletter 15 im Newsletterarchiv)