[redhat-list-de] Schuetzende Netzwerke

[Frank Schneider]

Hallo,

Ich kann mal zur Cisco-Lösung etwas ausholen, da für diese
wie schon gesagt derzeit sehr stark geworben wird...;-(

Die "Selbstschützenden Netzwerke" von Cisco arbeiten auf zwei
Arten, proaktiv und reaktiv.

Proaktiv heißt, das "das Netz", also der Switch, an dem das Endgerät dran
ist, vor dem Connect überprüft, ob der Client einen aktuellen Patchstand
sowie Virenschutz hat.

Das funktioniert technisch über 802.1x, also Authentifizierung am LAN-
Port, setzt also ziemlich hochwertige Access-Switche voraus, möglichst
natürlich von Cisco. Im Background werkelt dann ein zentraler ACS-Server,
also TACACS+ bzw. RADIUS, welcher dann die entsprechende Freigabe
erteilt oder auch nicht. Zusätzlich brauchts eine zentrale Management-Konsole,
welche entsprechende Policies vorrätig hält und z.B. entscheidet, was mit
Systemen passiert, die die "Aufnahmebedingungen" eben nicht erfüllen,
z.B. werden die dann in ein getrenntes VLAN geschaltet, was aber eine
entsprechende Infrastruktur voraussetzt. (doppelt so viele IP-Netze wie vorher,
jedes IP-Netz braucht u.U. sein "Backup-Netz", das kann sich bei 
entsprechender Topologie ziemlich schnell zusammenläppern.)

Damit das alles klappt, brauchts auch eine Software auf allen Clients, eben
den Cisco CSA (Cisco Security Agent), dieser händelt dann das ganze 802.1x-
Gedöhns bzw. checkt auch den Virenschutz ab und den Patchstand.

Obs den CSA jetzt z.B. für Linux gibt und was er da abfragen will (uname -a ?),
weiß ich jetzt nicht, lustig ist vermutlich dann auch, das Linuxsysteme mangels
Virenschutz erstmal vom Netz ausgeschlossen werden würden, wenn man nicht
extra für sie spezielle Policies generiert. 

Normalerweise ist aber die Notwendigkeit des CSA auf den Systemen
schon ein Kill-Kriterium, denn nicht für jedes OS und auf jeder Plattform gibts
das Teil...z.T. kann man auch aus rechtlichen Gründen (Verlust von 
Zertifizierungen) nicht mal "einfach so" eine Fremdsoftware einspielen.
Manche Hardware (Drucker, z.B.) kann auch überhaupt kein 802.1x, für
die muß man sich dann Sonderlösungen (Drittes IP-Netz ?) überlegen.

Der zentrale Knackpunkt ist auch, welche "Karenzzeit" läßt man zu bzw. gegen
wen oder was vergleicht man den Patch- bzw. Virenstand des Clients...wenn da
was schiefgeht, werden evtl. deswegen Clients abgeschaltet, obwohl sie aber 
z.B. den nötigen Patch noch gar nicht installieren konnten...
Speziell im Clientumfeld, wo also Systeme mal 2 Wochen abgeschaltet sein 
können (Urlaub) ist das ein ziemliches Problem, weil solch ein System würde
beim ersten Einschalten sofort ins Quarantäne-Netz geroutet und der Benutzer
müßte dort selbst die entsprechenden Updates einspielen...das kann nicht
jeder Benutzer (nicht jeder User ist Admin bzw. root auf seiner Workstation...),
d.h. man muß einen entsprechenden first-level-Support oder Automatismen
für sowas aufbauen.

Die reaktive Komponente funktioniert so, das bei Ausbruch eines Virus im
Internet und entsprechenden Meldungen der AntiViren-Herstellern (Cisco hat
da u.a. eine Partnerschaft mit Trend Micro) genau auf diesen Virus passende
ACLs (Access Control Lists) generiert werden, die dann die Verbreitung genau
dieses Virus im eigenen Netz verhindern sollen. Das führt dann bei den 
gängigen Würmern wie BLASTER, SASSER zu einer schönen ACL, nämlich:

deny ip any any port 135-139 any
deny ip any any port 445 any

Diese ACL wird dann automatisch (wenn man das möchte) auf allen Routern
eingespielt...ganz großes Tennis, denn die obige ACL legt z.B. nebenbei jede
Windows-Kommunikation (MSX, AD, Fileshare, Printing, etc.) lahm, und das
automatisch im gesamten Netz. Das freut den LAN-Admin dann ungemein...
Man kann sich theoretisch die ACLs vorher noch ansehen, aber welcher
Admin weiß nachts um drei, das z.B. Oracle (auch) auf Port 4711 kommuniziert
oder MSX eben auch 135 benötigt ?
Man steht da sehr schnell vor der "Teufel-oder-Beelzebub"-Frage und wird
die ACL im Ernstfall wohl eher nicht einspielen...

Zusätzlich hat der CSA auf den Clients noch eine Funktion, die, so die Aussage
von Cisco, "böswillige Kommunikation" automatisch erkennt und unterbindet.
In der Theorie funktioniert das so, das wenn das System z.B. plötzlich Port 25
eines anderen Systems ansprechen will, dann wird das blockiert. 
Hat das System dagegen schon vorher so gehandelt, ist es "erlaubt". 
Wie genau die Ciscolösung hier arbeitet und wann genau etwas als "böse"
erkannt wird, da schweigt sich Cisco allerdings aus. 
Zum Teil scheint das konfigurierbar zu sein, z.T. kann man es dem System
"antrainieren" (Learning phase), z.T. scheint es aber auch etwas Black Magic
zu sein.

Wie geblockt wird, kann man dann noch einstellen, also das z.B. gewisse 
Applikationen Port 25 nutzen dürfen und andere nicht, oder ob der User gefragt
wird, etc. Das entspricht dann etwa dem Verhalten einer Personal Firewall.
(Ob eine Sekretärin dann mit der Frage "Explorer .exe auf Port 25 von 
server.mydomain.com zugreifen lassen ?" wirklich etwas anfangen kann, sei mal
dahingestellt.)

> Besser wäre eine gemischte Lösung auf die Frank schon hingewiesen
> hat...ein Switch der über snort oder snort_inline [0] verfügbar ist, am
> einfachsten wenn Linux selbst der Switch ist.  Ich empfehle in dieser Lage
> die Linux bridge Projekt [1] und diese Einleitung, veröffentlicht von
> Linux Magazin [2].  Wer richtig paranoid wird, darf sich vorstellen:
> infizierte Rechner werden automatisch unter ihrem eigenen
> Quarantänenetwzerk (ich denke an VLANs [3]) gestellt werden wo ein
> Updateserver vorhanden ist.

Aus Performancegründen würde ich von Bridging in Software eher
abraten, theoretisch ließe sich damit dann aber wirklich der Endgeräteport
abklemmen. In kleineren Netzen kann auch eine Kombination aus IDS (snort)
und IPTABLES bzw. managebaren Switches schon was bringen, gemein
bleibt diesen Lösungen aber immer, das erst reagiert wird, wenn es schon
brennt, und dann gilt zusätzlich, das wenn ein System infiziert werden konnte,
meist alle infizierbar sind, d.h. man hat sehr schnell ein Massenproblem mit
all seinen Folgen (plattes LAN, Kundenanrufe, finanzielle Verluste)

Durch lokalen Schutz auf den Clients, Patchmanagement bzw. E-Mail-Filtering
hat man aber bereits im Vorfeld die kritische Masse soweit gesenkt, sodaß 
es meist bei wenigen Einzelinfektionen bleibt. Die lassen sich dann z.T. mit
simplen Maßnahmen (Gerät abklemmen, neu installieren, User arbeitet solange
an Ersatz-PC / Praktikantenrechner, etc. weiter) in den Griff bekommen.

Gruß,
Frank.

-- 
Frank Schneider, <SPATZ1 at T-ONLINE.DE>.                           
People would rather live with a problem they cannot solve,
than accept a solution they cannot understand.
... -.-