Sie sind nun wieder eingeladen, die Diskussion spezieller technischer Probleme mit zu verfolgen. Bitte schicken Sie Fragen, Anregungen oder Antworten zu den vorgestellten Themen – ebenso wie Ihre Kritik – an unsere e-Mail-Adressen: dieter.bender@bender-dv.de oder Redaktion@MidrangeMagazin.de
Frage:
Wenn sich ein Benutzer mit seinem PC (der PC hat eine feste IP-Adresse in einem Token Ring-Netzwerk mit IBM Client Access) an der AS/400 anmelden will (zum Beispiel über OpsNav oder Netserver), aber eine falsche User-ID oder ein falsches Kennwort angibt, habe ich dann als Administrator die Möglichkeit, den PC bzw. die IP-Adresse ausfindig zu machen?
Antwort:
Zunächst sind erst mal zwei Fälle zu unterscheiden: Die Eingabe einer gültigen User-ID mit einem falschen Kennwort einerseits und die Eingabe einer ungültigen User-ID andererseits. Bei der Eingabe eines gültigen Benutzers und eines falschen Kennworts wird zunächst einmal bei jedem ungültigen Versuch eine Fehlermeldung CPF2234 in das Systemlog protokolliert. Im Systemwert QMAXSIGN ist dann hinterlegt, wie viele Fehlversuche erlaubt sind, bevor weitere Aktionen ausgelöst werden. Die weiteren Aktionen sind im Systemwert QMAXSGNACN festgelegt; die Aktionen reichen von „Einheit sperren“ über „Kennwort sperren“ bis hin zu einer Kombination beider Aktionen. Der Systemwert QDSPSGNINF legt zudem fest, ob der Benutzer bei einer erfolgreichen Anmeldung eine Information über die vorherigen Fehlversuche angezeigt bekommt.
Die Problematik des „Kennwörter-Ratens“ bei interaktiven Sitzungen bekommt man einigermaßen in den Griff, wenn man die Fehlversuche auf drei begrenzt, den Benutzer deaktiviert und diesem die Information über die bisher erfolgten Fehlversuche anzeigt. Fehlversuche dieser Art lassen sich auch mit DSPLOG MSGID(CPF2234) anzeigen. Bei der Auswahl CPF2200 werden dann alle Meldungen angezeigt, die mit CPF22 anfangen – inklusive weiterer Berechtigungsfehler. Die CP2234 enthält den Namen des Device, aber nicht die IP-Adresse.
Schwieriger sieht es bei der Eingabe eines nicht-existierenden Benutzers aus. Hierbei wird im Systemlog nichts protokolliert. Versuche, Benutzernamen zu raten, fallen also kaum auf. Eine Verstärkung an dieser Stelle lässt sich mit der Aktivierung des System Audit erreichen. Hierzu wird zuerst ein Journal Receiver mit CRTJRNRCV JRNRCV(QUSRSYS/QAUDRCV) erstellt, dann ein Journal in der QSYS mit dem Namen QAUDJRN; dies erfolgt mit CRTJRN JRN(QSYS/QAUDJRN) JRNRCV(QUSRSYS/QAUDRCV). Jetzt wird im Systemwert QAUDLVL der Wert *AUTFAIL hinzugefügt und der Systemwert QAUDCTL auf *AUDLVL eingestellt. Hiermit ist dann das Auditing aktiviert. Jede Berechtigungsverletzung erzeugt nun einen Eintrag im QAUDJRN bzw. in dem zugeordneten Empfänger. Mit dem OS/400-Befehl DSPJRN QAUDJRN kann man sich nun die Einträge ansehen. Im Audit Journal werden jetzt auch Einträge für den Versuch der Verwendung eines ungültigen Benutzers erstellt.
Alle bisher aufgezeigten Protokollierungen lassen allerdings keinen direkten Rückschluss auf die IP-Adresse zu. Dies ist durchaus ein ernsthafter Schwachpunkt. Sie haben zwar in Ihrem Umfeld die Möglichkeit, feste Device-Namen zu verwenden, aber das hindert einen Benutzer nicht unbedingt daran, das zu umgehen. Wenn diese Möglichkeit besteht, verkehrt sich auch das Abhängen von Bildschirmen über QMAXSGNACN ins Gegenteil; nunmehr könnte ein Unbefugter durchaus alle Bildschirm-Einheiten schneller deaktivieren, als der Administrator sie wieder anhängen kann.
An dieser Stelle lassen sich noch über ein Exit-Programm Verstärkungen vornehmen. In der AS/400 Registry ist hierzu ein Exit-Punkt QIBM_QTG_DEVINIT vorgesehen, an dem man mit WRKREGINF ein Programm hinterlegen kann, das bei der Initialisierung der Telnet-Einheiten die Steuerung übertragen bekommt. Dieses Programm bekommt dann unter anderem auch die IP-Adresse übergeben und hat auch die Möglichkeit, eine Sitzungsanforderung abzulehnen. Diesen Mechanismus könnte man nun dazu verwenden, dass man sich nur mittels bestimmter IP-Adressen mit fest hinterlegten Bildschirmeinheiten für jede Adresse anmelden kann. Ähnliche Wege kann man auch gehen, um FTP-Anforderungen vergleichbar abzusichern, denn bei ungültigen Logins über FTP-Anforderungen hat man noch weniger Information, als ein Einheitenname bietet.