 |
|
|
|
|
||||||||
 |
||||||||||||
|
||||||||||||
 |
||||||||||||
|
|
|
|
|
|||
Gebührenoptimierung durch Spoofing Da ISDN
universell einsetzbar, skalierbar und insbesondere auch bezahlbar ist, verbindet man heute räumlich voneinander getrennte LANs häufig mittels ISDN-Wählverbindungen. Dabei ist jedoch Vorsicht geboten: „Geschwätzige“
Protokolle und ungeeignete ISDN-Router können dafür sorgen, daß Wählleitungen schnell zu teuren Standleitungen mutieren. Von Klaus Eppele
Wenn zwischen zwei LANs nur sporadisch Daten auszutauschen sind, rechnet sich eine Wählverbindung gegenüber einer Festverbindung. Geeignete ISDN-Router erkennen von selbst, ob Daten zum entfernten LAN hin zu übertragen
sind und bauen bei Bedarf sehr schnell eine Verbindung zum gegenüberliegenden Netz auf. Problematisch ist hierbei, daß viele Protokolle, die wir in unseren heutigen Netzwerken verwenden, vom Design her auf ständig
verfügbare Übertragungswege angewiesen sind. Diese Protokolle wurden rein für den Einsatz in lokal begrenzten Netzwerken konzipiert und setzen eine permanente Verbindung zwischen Clients und Servern voraus; von
Wählleitungen und Kostenaspekten wissen diese Protokolle nichts. Insbesondere Novells NetWare ist sehr geschwätzig und generiert andauernd periodische Meldungen und Broadcasts, die ohne entsprechende Vorkehrungen über
alle WAN-Strecken übertragen werden und dafür sorgen, daß Wählverbindungen niemals abgebaut werden können. Bild 1: Die Protokoll-Architektur von NetWare. RIP und SAP Zwei zentrale Komponenten des NetWare
Internet Packet Exchange (IPX) Protokolls sind RIP (Routing Information Protocol) und SAP (Service Advertisement Protocol). Beide Protokolle generieren in einer NetWare-Standardkonfiguration alle 60 Sekunden Broadcasts,
die von den Routern über alle WAN-Strecken an alle Netze verteilt werden. RIP-Frames informieren alle Router über die aktuelle Verfügbarkeit der einzelnen Netze. Mittels SAP geben Platten-, Print-, Archiv- oder
Time-Server allen Netzteilnehmern im Minutenabstand ihre Dienste bekannt. Um dieser Flut an Protokollinformationen Herr zu werden, kann man beispielsweise die Zeitabstände zwischen den Broadcasts vergrößern. Dies hat
allerdings den negativen Nebeneffekt, daß die entfernten Netzteilnehmer erst recht spät über Änderungen in den vorhandenen Routen oder im verfügbaren Dienstangebot informiert werden. Auch statisches Routing bzw.
statisches SAP kann eine Lösung sein. Auf RIP- und SAP-Broadcasts kann man vollständig verzichten, wenn der Netzmanager die Routing- und Service-Informationen manuell konfiguriert und bei Bedarf manuell anpaßt. Diese
Vorgehensweise macht selbstverständlich nur Sinn für kleinere Netze, deren Konfiguration sich nur selten ändert. Zwei weitere Lösungsansätze heißen „Event-Triggered Update“ und „Snapshot-Routing“. Beim Event-Triggered
Update konfiguriert man die Router so, daß RIP-Frames nicht regelmäßig, sondern nur dann verschickt werden, wenn wirklich eine Änderung eingetreten ist. Das Snapshot-Routing sorgt dafür, daß Routing- und Service-News
nur dann bekannt gegeben werden, wenn sowieso eine Verbindung aufgebaut wird, um effektive Nutzdaten zu übertragen. Die RIP-/SAP-Informationen werden dann einfach diesen Nutzdaten angehängt. NCP-/SPX-Spoofing Jeder Server sendet regelmäßig über das NetWare Core Protocol (NCP) Watchdog-Pakete an alle angemeldeten Clienten. Aufgrund der Antwort der Clienten auf diese Watchdog- oder Keep-Alive-Pakete kann der Server
erkennen, welche Clienten noch aktiv erreichbar sind. Damit dieser Mechnismus auch über ISDN-Wählverbindungen funktioniert, ohne daß unnötige Gebühren anfallen, benötigt man Router, die in der Lage sind zu schwindeln
(zu spoofen). Bild 2: Ein Router, der schwindelt, kann Verbindungkosten sparen. Der zuständige ISDN-Router filtert hierzu die Server-Anfragen aus und beantwortet diese lokal (siehe Bild 2). Wichtig ist
hierbei, daß die Anwender sich ordnungsgemäß ausloggen. Wenn diese nämlich nur ihren Client-PC ausschalten, bekommt der Router dies nicht mit und bestätigt dem NetWare-Server weiterhin eine aktive Sitzung. Beim nächsten
Login des Anwenders wird dann eine weitere Sitzung auf dem Server geöffnet. Somit werden sowohl im Router als auch im Server wertvolle Ressourcen verschwendet. Beim Sequenced Packet Exchange Protocol (SPX) geht die
Sache sogar noch einen Schritt weiter. Während bei IPX nur Datagramme ausgetauscht werden, handelt es sich bei SPX um eine gesicherte, verbindungsorientierte und symmetrische Datenübertragung, die auch von Clienten
initiiert werden kann. Beide Kommunikationspartner senden und bestätigen sich wechselseitig Keep-Alive-Pakete. Das Spoofing darf sich also nicht nur auf die Serverseite beschränken. Vielmehr muß der entfernte
ISDN-Router regelmäßig Keep-Alive-Nachrichten von selbst generieren und diese an die entfernten Clienten aussenden, ohne diese Nachrichten tatsächlich vom Server über die Wählleitung empfangen zu haben. Der ISDN-Router
baut nur dann eine ISDN-Verbindung auf, wenn Nutzdaten zu übertragen sind, oder wenn er den Server davon unterrichten will, daß ein Client auf diese selbstgenerierten Keep-Alive-Anfragen nicht mehr antwortet.
Serialization Protocol NetWare prüft regelmäßig, ob im Netzwerk illegale Kopien von Serverlizenzen installiert sind. Dazu verschickt jeder Server seine Seriennummer alle 66 Sekunden per Broadcast. Diese
Broadcasts können einfach ausgefiltert werden (Type=0x457), da hier keine Antwort von der Gegenseite erwartet wird. Eventuelle Mehrfachinstallationen von NetWare-Lizenzen kann man dann allerdings nicht mehr entdecken.
NetBIOS-Spoofing NetBIOS (Network Basic Input/Output System) setzt direkt auf dem LLC-Layer (Logical Link Control) auf und kann deshalb nicht geroutet werden. Es existieren zwei Lösungsansätze, um
NetBIOS-Broadcasts nicht unkontrolliert über die ISDN-Wählverbindungen übertragen zu müssen. Zum einen kann die Netzlast durch lokales Name Caching reduziert werden, zum anderen kann man LLC-Frames (und somit auch
NetBIOS) mittels DLSw (Data Link Switching) nach RFC 1434 auf der WAN-Strecke in TCP verpacken und somit gezielt routen. NetWare 4.1 - NDS und NLSP NetWare 4.1 stellt mit dem NetWare Directory
Service (NDS) neue Anforderungen an ISDN-Router. Denn dieser hierarchische, objektorientierte Directory Service, der auf X.500 basiert, erfordert eine kontinuierliche Zeitsynchronisation der beteiligten Komponenten.
Jeder Server sendet alle 10 Minuten eine Synchronisierungsanfrage an einen beliebigen Time-Server seiner Wahl. Diese Anfragen kann man nicht einfach ausfiltern. Zum einen sollte man die Synchronisation der Server nicht
vollständig unterdrücken. Zum anderen sind die NDS-Pakete numeriert, so daß ein Router, der einzelne Pakete ausfiltert, alle anderen NDS-Pakete getrennt für jede Server-Server-Verbindung neu numerieren müßte. Sinnvoller
ist es,
Auch das neue Routingprotokoll, Network Link Services Protocol (NLSP), von NetWare 4.1 sorgt für eine erhebliche Zunahme periodischer Meldungen. NLSP sendet alle 20 Sekunden „Hello Pakete“, um bestehende Routen
aufrecht zu erhalten. Zur Lösung dieser Problematik greifen ähnliche Ansätze wie schon oben unter RIP/SAP erwähnt. AppleTalk Nicht nur beim Einsatz von NetWare ist Vorsicht geboten, wenn man seine
LANs über Wählstrecken miteinander verbinden will. Auch alle anderen Protokolle muß man erst auf ihre WAN-Tauglichkeit hin überprüfen. So tauschen z.B. viele Protokolle der AppleTalk-Familie, ähnlich wie bei NetWare,
regelmäßig zyklische Pakete aus. Hierzu gehören:
Um diesen für WAN-Strecken unbrauchbaren Datenverkehr einzudämmen, sollte man AppleTalk-Zonen nicht über WAN-Strecken hinweg konfigurieren und zwischen den Zonen gezielt Filter setzen.
Bild 3: Die umfangreiche AppleTalk-Protokollfamilie. In jedem Fall ist es ratsam, nicht einfach gutgläubig seine ISDN-Router anzuschließen und dann nach Hause zu gehen. Die Telekom-Rechnung am Monatsende könnte sonst
ein böses Erwachen bereiten.
Autor Der Autor Dipl. Inform.
Klaus Eppele ist Inhaber der Firma improve marketing-training-consulting, Karlsruhe, www.improve-mtc.de. improve Erschienen in Datacom 12/96, Seiten 56 - 58 |
|||