Sicherheitsproblem "Kennwort knacken"

**Fuerchau** · 12-07-04, 12:21

Nochmal ein "kurzer" Kommentar:

Im Auslieferungszustand der AS/400 brauche ich nur wenige Handgriffe um die Maschine sicher zu machen (kein Hexenwerk).
Der Systemwert QCRTAUT legt fest, wie neue Objekte in der Berechtigung vergeben werden. Hier steht der Default (leider) auf *CHANGE, was bedeutet, dass für jedes Obekt, dass auf die AS/400 kommt, für alle Benutzer die Änderungsberechtigung gilt.
Ändere ich diesen auf *EXCLUDE, habe ich (normalerweise) keine weiteren Sicherheitsprobleme. Dies gilt mindestens seit V2 (V1 kenne ich nicht) und muss daher gar nicht geändert werden.

Nur jetzt fängt das Nachdenken an:

Wie richte ich einen neuen Benutzer ein ?
Wenn ein neuer Benutzer mit der sog. ALLOBJ-Berechtigung angelegt wird, kann und darf dieser natürlich (fast) alles. Im Zweifel (per ftp oder auch sonst wie) eben auch einen "rm *", der jedoch an den Betriebssystemteilen bereits scheitert !
Auf Windows lege ich einen neuen Benutzer ja auch nicht in der Gruppe Admin an.
Wenn ich auf Windows einen User als "Admin" einrichte darf der das natürlich auch.

Aber so ist das nun mal mit der Benutzerberechtigung. Bei Windows überlege ich mir ja auch, mit welchen Rechten ich den User ausstatte. Warum nicht bei der AS/400 ?

Und was das "durchwandern" der Platten angeht, so sehe ich auf der AS/400 nur, wozu ich auch berechtigt bin.
Richte ich auf einem Windows-Server einen Benutzer ein, der auch gleichzeitig AUF DEM SERVER arbeiten können muss, also lokal angemeldet, hat er natürlch auch Zugriff auf alle Verzeichnisse die zumindest zum Lesen berechtigt sind, anders ginge es ja auch nicht, da sonst kein Programm zur Ausführung kommt.
Man darf bei der AS/400 nicht vergessen, dass ein Benutzer AUF DEM RECHNER arbeitet und nicht nur mit freigegebenen Verzeichnissen.

Wenn ich nun neue Bibliotheken erstelle (oder aus Software installiere) erhält erst mal ausser dem Ersteller NIEMAND Berechtigung an der Lib (siehe QCRTAUT). Ich muss also jeden einzelnen Benutzer (oder die Gruppe) explizit berechtigen.

Aber wer macht das schon so ?!?!

Wenn ich schon für neue Objekte den Zugriffsschutz für *PUBLIC auf *CHANGE zulasse ist das genauso, wie wenn ich für einen Windows-Server das Root-Verzeichnis mit der Berechtigung "Jeder/Alles" incl. Vererbung auf alle Unterverzeichnisse einstelle.
Was mich eben wundert ist, dass sich bei Windows über die Grundeinstellung Gedanken gemacht werden, bei der AS/400 eben nicht.

Und genau darin liegt die grundsätzliche Sicherheit des OS/400 (midesten seit V2), wie auch des WindowsNT/2000/XP, begründet. Stelle ich die Sicherheit des System bei der Installation nicht ein (QSECURITY, QCRTAUT) habe ich natürlich später Probleme !!!

Es gibt auch Anwendungen, die z.B. mit Oracle/SQL-Server-DB's arbeiten. Bei diesen Client/Server-Anwendungen habe ich genau das gleiche Problem wie bei AS/400-Anwendungen. Da ich eine gültige DB-Anmeldung benötige um mittels Client-Programmen auf die Daten zugreifen zu können, kann ich genau die gleiche Anmeldung verwenden um per ODBC auf die Daten zuzugreifen.
Für dieses Problem gibt es auf der DB-Seite aber leider keine Lösung (vielleicht kennt ja jemand eine).

Solange ich also die Sicherheit des OS im Griff habe sind auch die "kritischen" Tools der IBM und auch jede Menge anderer Anbieter sicher.

Was die Kommunikation OS/400 zu OS/400 angeht so bin ich nicht auf Telnet angewiesen sondern kann da ganz locker mit SNA bzw. SNA over IP arbeiten, da das SNA bereits vor IP existierte. Wenn ich dann per CHGNETA die Datenverdichtung (seit V3) einschalte hilft mir auch kein Leitungstrace mehr weiter, da nicht jeder Block einzeln verdichtet wird sondern eine Verdichtungshistorie (Huffmann) aufgebaut wird.
Gerade da Telnet nicht sicher ist, sollte eben SNA verwendet werden und es gibt kein OS/400 dass nicht SNA beherrscht.

Wie sieht das Ganze eigentlich unter Verwendung von Thin-Clients aus ? Denn das ist wohl eher mit einer AS/400 vergleichbar. Alle Programme laufen auf dem Server, ich melde micht auf dem Server an, starte einen Explorer auf dem Server usw. usw. usw.

Also nix für ungut, man kann noch seitenlang über das Thema Sicherheit diskutieren.
Ich persönlich halte die AS/400 aber immer noch für sicherer als Windows !

Aber: Reden allein hilft nicht ! Tun muss man es !

**BenderD** · 12-07-04, 13:08

Hallo auch nochmal,

Die Debatte selber legt die Problematik offen:

wer das Etikett in Anspruch nimmt sicherster Rechner der Welt zu sein, kann nicht damit argumentieren, dass andere auch nicht besser sind, sondern müsste dazu in der Lage sein, zu zeigen was besser ist. Ein Rückzug auf SNA hilft hier überhaupt nicht weiter, das Konzept vertrauenswürdiger Rechner ist aus Sicherheitsgründen gescheitert und faktisch vom Markt gezogen worden. Reste davon, die noch in Client Access drinstecken sind eher Sicherheitslücken als Inseln der Glückseligkeit (ich sage dazu nur ALLOBJ Verbindung zu AS400 wg. Management Central und Scheunentor).

Beim Hersteller wird bis heute Sicherheitsdenken ersetzt durch platte Marketingsprüche (Hacker verzweifeln) Der Auslieferungszustand von AS400 Systemen hat sich gebessert, ist aber keineswegs konsequent an Sicherheit orientiert. (Security Level mittlerweile hochgesetzt, Berechtigungen an Systembibliotheken und LIBCRTAUT unzureichend).

Software Anbieter sind meist auf noch schlechterem Stand. Entweder erfordert die Installation von Standardsoftware Scheunentore, damit sie läuft (wir brauchen jetzt mal den Qsecofr, damit wir installieren können), oder die Implementierung bringt selber Lücken ein (Stichwort adopted Authority und LIBL).

Auf Anwenderseite sieht die Lage oft traurig aus: die unzureichenden Sicherheitseinstellungen der Vergangenheit (vor V4 wurde faktisch ohne jede Security ausgeliefert) sind noch aufgeweicht worden, man sieht immer noch Maschinen bei denen auf den "bewährten Menüschutz" vertraut wird; wenn der dann zusammenbricht, weil jeder alles darf, wird mit Tools nachgeflickt (ich widersteher der Versuchnung Produkte beim Namen zu nennen), die die verfehlte Installation nur kaschieren, aber nicht beheben.

Letztlich gilt aber: jeder Missstand, der länger als 10 Jahre besteht ist gewollt und in den meisten AS400 Umgebungen besteht der offenkundige Missstand im Sicherheitsbereich bereits mehr als 10 Jahre.
Hier wird halt Wirtschaftlichkeit höher als Sicherheit priorisiert, in der Hoffnung dass es gut geht. (gilt nebenbei bemerkt auch für anderes).

Im Grunde ist es kein Geheimnis, was man tun muss:
- physikalischer Schutz von Servern, Bandgeräten Netzwerkanschlüssen
- Sicherheitszonen durch spezialisierte Firewalls abschotten
- jeglichen Transfer über ungeschützte Kanäle verschlüsseln
- Beutzerprofile nur mit adäquaten Rechten versehen
- nur private Objekte zum Abschuss freigeben
- alle gemeinsam benutzten Objekte nur über kontrollierte Schnittstellen verwendbar machen
- alles andere auf der zentralsten Ebene dicht machen
- Protokollierung und Auswertung aller Security events

Wer eins von obigem nicht macht, kann das andere im Grunde auch bleiben lassen.

Dieter Bender