von Dan Riehl
Eines meiner liebsten Projekte ist die Sicherheitsüberprüfung von iSeries Systemen. Es ist fast so etwas wie eine Schatzsuche. Ich weiß, dass die Schwachstellen definitiv vorhanden sind – manchmal sehr gut verborgen, meist jedoch nicht. Der eigentliche Spaß besteht im Auffinden, Erläutern und Planen zukünftiger Vermeidung.
Eine der Schwachstellen, die sich auf vielen Systemen befinden, sind Benutzerprofile mit gleichlautenden Passwörtern (z. B. Benutzer-ID HANSMEIER mit dem Passwort HANSMEIER). Kritisch wird es, wenn solche Benutzerprofile über umfangreiche Berechtigungen verfügen, was leider häufig der Fall ist. Dies stellt dann eine klare Gefährdung der gesamten Systemintegrität einschließlich der Daten dar. Solche Benutzerprofile lassen sich mit der CL-Anweisung ANZDFTPWD (Analyze Default Passwords) ausfindig zu machen. Diese CL-Anweisung kann aus dem Menü SECTOOLS heraus oder direkt über die Befehlszeile aufgerufen werden. Bei der Ausführung lassen sich Aktionen festlegen, die für aufgefundene Benutzprofile mit identischen Passwörtern angewendet werden sollen. Mögliche Aktionen sind beispielsweise die Deaktivierung betroffener Benutzerprofile (der Benutzer kann sich nicht mehr anmelden) oder eine Statusänderung des Passwortes auf „abgelaufen“ (der Benutzer muss bei der nächsten Anmeldung ein neues Passwort vergeben).
Soll diese Überprüfung wöchentlich automatisch ablaufen, so kann dem Job-Scheduler ein Eintrag hinzugefügt werden, um die Anweisung ANZDFTPWD mit den gewünschten Optionen auszuführen. ANZDFTPWD ACTION(*PWDEXP) beispielsweise druckt einen Bericht und setzt alle aufgefundenen Passwörter, die identisch mit dem Benutzerprofil sind, auf den Status „abgelaufen“.
Beim ersten Aufruf der Anweisung ANZDFTPWD sollte allerdings unbedingt ACTION(*NONE) angegeben werden. Die Option (*NONE) erstellt nur eine Auflistung der betroffenen Benutzerprofile, führt aber keine weiteren Aktionen durch.
Die erstellte Auflistung sollte sorgsam durchgesehen werden, um festzustellen, welches Benutzerprofil wozu dient. Ich selbst habe es auf die harte Tour probiert, was ich Ihnen allerdings ersparen möchte. Ich habe einmal gleich zu Beginn die Option (*PWDEXP) gewählt, was dazu führte, dass auch das Passwort des Benutzerprofils QUSER (mit gleichlautendem Passwort) auf „abgelaufen“ gesetzt wurde. Das wiederum bewirkte, dass die gesamte SNA-Kommunikation zwischen zwei Systemen zum Erliegen kam. Lassen Sie also Vorsicht walten, denn es gibt Erfahrungen, die man nicht unbedingt selber machen muss. Das obige Beispiel-Programm wurde unter Release V5R2M0 erstellt. Aus diesem Grund wurde der zweite Parameter (&LENTEXT = Länge des übergebenen Textes) alphanumerisch mit einer Länge von 4 Byte definiert. Um einen Initial-Wert zu setzen, musste die hexadezimale Darstellung verwendet werden. Ab Release V5R3M0 ist es möglich diesen Parameter direkt als Integer mit dem Datentyp *INT und einer Länge von 4 Byte zu definieren. Da es sich bei Integer-Feldern um numerische Felder handelt, ist eine Initialisierung mit hexadezimalen Werten nicht mehr erforderlich, vielmehr können die numerischen Werte direkt angegeben werden.
Ab Release V5R4M0 kann dann die Error-Datenstruktur als echte Datenstruktur definiert werden. Die beiden ersten Felder dieser Datenstruktur, (zurückgegebene Bytes und übergebene Bytes) können dann direkt als Integer-Felder (Datentyp *INT) mit einer Länge von 4 Byte angelegt werden. Da es sich dann um numerische Felder handelt, kann für die Anzahl der übergebenen Bytes direkt der numerische Wert übergeben werden.
Ähnliche Artikel:
