Sicherheitsproblem "Kennwort knacken"

[Fuerchau]

Wie immer: Wer zu allem offen ist, kann nicht ganz dicht sein !

Das "Umgehen der Anmeldung" ist über den Systemwert QSIGNON (o.ä.) wieder abschaltbar (*FRCSIGNON).
SSL-Verschlüsselung für CA gibt es seit mindestens V4R3 sowoh auf OS als auch auf der Client-Seite.

Der Datenstrom, der da analysiert wurde ist der 5250-Datenstrom, der nun mal Bildschirmfelder überträgt.

Zu den Sicherheitsproblemen:
Seit der Einführung von Client-PC's an der AS/400 gibt es diese "Probleme", die eigentlich gar keine sind !!!
Bei konsequenter Umsetzung des Berechtigungssystems der AS/400 lassen sich alle Probleme abschalten, so dass der Benutzer nur noch das darf, wozu er berechtigt ist.

Mittels REXEC kann man auf jedem System (Windows/Linux/OS400/...) Befehle ausführen, wenn man eine gültige Anmeldung hat und für die Befehle berechtigt ist.
Auch auf den Windows-Servern ist das möglich wenn ich weiß wie es geht.

Die AS/400 ist da um keinen Deut besser, wenn man sich nicht darum kümmert.

Für alle, die sich mit der Berechtigung der AS/400 nicht herumschlagen wollen, gibt es dann Tools wie PCSACC/400, die die Kotrolle der Remote-Zugänge übernehmen.

Dies hat also nichts mit der CA-Version oder dem OS/400 zu tun, sondern damit, wie man seine Systeme per Berechtigungssystem schützt.

Im Intranet sollten ja eh nur vertrauenswürdige Personen Zugang habe, die sich nicht mit krimineller Energie um das Ausspionieren von Daten bemühen.
Man sollte auch seine Mitarbeiter anweisen, den PC immer zu sperren, wenn man mal zur Pause oder aufs Klo geht. Es könnte ja sonst ein Mitarbeiter kommen und mit meiner gültigen Anmeldung Unfug treiben.
Was nützt mir da SSL und verschlüsselte Autentifizierung wenn die Mitarbeiter so nachlässig sind und die einfachsten Sicherheitsregeln nicht beherzigen ?

Ich schreib meine Geheimzahl ja auch nicht auf die Rückseite meiner EC-Karte.

[Sven Schneider]

@Frank
Wie im wahren Leben.
Wenn ich meine Haustür (AS/400) offen lasse, ist es egal ob mein Hab und Gut mit 'nem Rucksack (z.B. ODBC, OLE-DB, Filetransfer) oder per LKW (z.B. FTP) mitgenommen wird.

[Frank.Sobanek]

Hallo,
sicher wenn ich meine Haustür offen lasse ect.... ist schon klar !!!
Aber ich habe nicht gewusst, dass selbst ein User mit der kleinsten Sicherheitsstufe (*user ohne Befehszeile) via RemoteCommand den Befehl WRKREGINF absetzen kann,
also den Namen meine Schutzprogramms herausfindet (zB. FTPTOOL) und dann noch DSPPGMREF(Programm-Referenzen anzeigen) aufruft und die für zB. Ftptool zuständigen Dateien anzeigen lässt und damit mein Schutzprogramm evtl. deaktiviert.
In meinem Fall hat so ein Künstler genau das getan.
Zusätzlich hat er dann noch wie beschrieben mit Microsoft Accsess und ODBC sein eigenes Userprofil hinzugefügt,
und schon war BVS FTPTOOL ausgehebelt.
Haben seitdem ein Tool im einsatz und Client Access komplett
gesperrt.

Gruß

Frank

[loeweadolf]

Wie immer: Wer zu allem offen ist, kann nicht ganz dicht sein !

Der Datenstrom, der da analysiert wurde ist der 5250-Datenstrom, der nun mal Bildschirmfelder überträgt.

Zu den Sicherheitsproblemen:
Seit der Einführung von Client-PC's an der AS/400 gibt es diese "Probleme", die eigentlich gar keine sind !!!
Bei konsequenter Umsetzung des Berechtigungssystems der AS/400 lassen sich alle Probleme abschalten, so dass der Benutzer nur noch das darf, wozu er berechtigt ist.

Dies hat also nichts mit der CA-Version oder dem OS/400 zu tun, sondern damit, wie man seine Systeme per Berechtigungssystem schützt.

Hallo Baldur,
in diesem Falle spielen die Berechtigungsvergaben keine Rolle.
Der Datenstrom im Netzwerk wurde ausgelesen und ausgewertet. Alle User und deren Kennwörter sind wie in einer öffentlichen Leihbücherei zu entnehmen.
So kann mit dem User-Name eines berechtigten Benutzers und dessen Kennwort alles gemacht werden. Berechtigungsvergaben auf der AS/400 sind Makulatur.

mfg. Ludger

[Fuerchau]

@Ludger

Ich sag doch, wenn das Intranet besonders geschützt werden muss, dann muss die CA-Kommunikation auf SSL umgestellt werden.

@Frank

"Ohne Befehlszeile" heißt nicht, dass ich keine Kommandos ausführen darf. Das wäre ja ein grosses Problem bei Kommandos in CL-Programmen oder per QCMDEXC.
WRKREGINF ist nicht das Problem.
Wieso hat der Benutzer die Berechtigung an der Lib wo das Programm drinsteht ?
Wieso hat der Benutzer die Berechtigung an den Dateien, um sich dann selbst einzutragen ?
Das, was der User da getrieben hat, kann ich auch mit SQL-Befehlen erreichen. Selbst wenn ich nicht CA verwende, kann ich mir einen ODBC-Treiber "besorgen", im Zweifel halt auch Java, und mach das dann ohne CA !
Per SQL kann ich ja auch CALL QCMDEXC durchführen um genau das zu erreichen.

Also auch hier: Die AS/400 ist viel zu weit offen !!

Übrigens:
Mit PCSACC/400 kann das nicht passieren. Das Programm steht zwar in den REGINF's (ich kann also nachschauen), die Lib ist aber für *PUBLIC auf *EXCLUDE gesetzt !
Solange ich also kein *ALLOBJ besitze (auch das haben leider viele User), komme ich an die Pgm'e und Dateien nicht dran.

Mach deine AS/400 also dicht, aber mit den richtigen Berechtigungen, dann kannst du auch CA nutzen.

Links:
http://www.newsolutions.de/news400/a...lio/sic_ip.php
http://www-1.ibm.com/servers/eserver...telnet/ssl.htm

[loeweadolf]

Vielen Dank für Eure Mühe.

Ich habe den Link zu diesem Thema dem entspr. Mitarbeiter weitergeleitet. Die angegeben Links bzgl. SSL scheinen interessant.

mfg. Ludger

[loeweadolf]

Ich habe mir erlaubt, den letzten Kommentar des Kunden-Mitarbeiters zu diesem Thema nachstehend hier einzustellen.

mfg. Ludger

Nachfolgende (lange!) Kommentare konnte ich mir denn doch nicht verkneifen :-) :
Fuerchau
[rlp_Moderator]

Registrierungsdatum: Feb 2001
Beiträge: 1.738
@Ludger
<...>
Klar ist:
Sobald ich eine Tür aufmache, muss ich zusehen wen ich hereinlasse oder nicht.
Das Problem kommt leider in umgekehrter Reihenfolge: die Türen stehen zuerst auf und müssen nachträglich geschlossen werden. Der Eindruck vermittelt das Bild einer sicheren Maschine und kaum jemand glaubt, das ein schweres Sicherheitsrisko gerade auf AS400 vorliegen könnte. Folglich wird über lange Zeit nicht angemessen gehandelt und das Problem wird mit wachsender Zahl von Anwendungen und Daten größer und größer.
Die AS/400 ist eine der sichersten Maschinen !
Offensichtlich nicht die bei Leco (ich kenne zwar nur diese eine aber an verschiedensten Stellen im Internet wird von ähnlichen und noch zusätzlichen Problemen berichtet). Und ich sehe da auch nicht so richtig, wo das Ding grundsätzlich auf besondere Sicherheit ausgelegt sein soll?

Beispiel FTP: wo bei einem "normalen" FTP-Server der User (z.B. mittels chroot) in einem speziellen Verzeichnis landet (z.B. Home-Verzeichnis) und nicht in eine übergeordnete Ebene wechseln kann, kann man bei AS400 den kompletten Platteninhalt durchwandern, lesen und schreiben. Das gleiche bei den IBM-Tools "Datenübertragung" und "Excel-Plugin". Was soll daran sicher konzipiert sein?

Die Behauptung "ein PC mit Windows ist eine der sichersten Maschinen" ist genau so haltbar/unhaltbar. Auch hier kann man mit entsprechenden Vorkehrungen, Tools und womöglich selbstprogrammierten Patches eine höchste Sicherheit erreichen.

Die Sicherheit liegt im Betriebssystem des Servers, von einem Server-OS mit dem Ansehen einer AS400 sollte man mehr grundsätzliche Sicherheit erwarten können. Falsche Pauschalaussagen wie "Die AS/400 ist eine der sichersten Maschinen" führen zu falschem Sicherheitsverständnis und falscher Erwartungshaltung. Richtiger wäre die Aussage "Die AS/400 ist eine der sichersten Maschinen, nachdem die vorhanden schweren Sicherheitslücken geschlossen wurden!", allerdings unterscheidet sich AS400 dann nicht mehr positiv von Windows oder jedem anderen OS sondern steht m.E. zunächst eher schlechter da.
Wenn ich natürlich von vorneherein das Sicherheitskonzept vernachlässige und offene Türen und Fenster (Windows) einfach ignoriere, kan man natürlich schnell sagen, dass die AS/400 nicht sicher ist.
Was ist denn dem Windows-Betriebssystem vorzuwerfen, wenn IBM-gelieferte Programme - nämlich CA400+Tools - bereits bei normaler Benutzung zum Risiko werden??? Die offenen Türen und Fenster bzgl. der AS400-Sicherheit liegen ja wohl auf AS400 und nicht in Windows begründet - also ist AS400 nicht sicher.
Die bekannten Lücken lassen sich genau so gut von einer anderen AS400, einem UNIX-System oder wie in diesem Fall von einem Linux-Server ausnutzen. Letzere dürften wohl kaum unsicherer als AS400 sein.

Man kann keine sichere Sparkasse ohne Türen und ohne Tresor bauen und hoffen, daß kein Einbrecher vorbeikommt. Sicherlich könnte man die Einbrecher bitten, hier nicht mehr einzusteigen...
Und genau darum geht es doch: Seit es PC's gibt MUSS man sich um seine Sicherheit kümmern und kann sich nicht darauf berufen, dass das doch alles automatisch geht.
Seit es PC's gibt? Ich glaube IBM selbst liefert die kritischen Tools ohne ein Wort über Sicherheitsrisiken zu verlieren (soweit ich weiß!) und FTP gibt es solange, wie es IP-Netzwerke gibt - ja, zufälligerweise auch auf PCs.

Aber darum geht es tatsächlich. Solange nämlich nur Terminals an AS400 waren, hat man die Sicherheitsfrage offensichtlich einfach vernachlässigt ("Wenn ich natürlich von vorneherein das Sicherheitskonzept vernachlässige und offene Türen und Fenster..."). Dummerweise kann man aber auch als unpriviligierter User am Terminal den FTP-Befehl "rm *" ausführen und die Platte putzen, sofern irgendwie an die Kommandozeile zu kommen ist! Vorteil bei Terminals ist natürlich, daß der "menügesteuerte" User sowas wie FTP oft gar nicht kennt.

Spätestens mit dem Anbinden von AS400 an "Standard-"Netzwerke hätte auf Seite des Server-OS auf die neue Situation reagiert werden müssen, anstatt die kritischen Tools (m.W(!)->) gleich kommentarlos mitzuliefern. Es müsste also besser heißen:
"Und genau darum geht es doch: Seit AS400 nicht mehr mit ein paar Terminals hinter verschlossenen Türen steht, MUSS man sich um seine Sicherheit kümmern..."
Nicht umsonst ist die AS/400 bisher virenfrei !!!
Was hat das hiermit zu tun? Mein programmierbarer Taschenrechner ist auch virenfrei :-)
Und was die Kommunikation AS/400 zu AS/400 ist, so muss die sich überhaupt nicht im Klartext unterhalten und das ohne weitere Produkte einzusetzen.
Muss sie vielleicht nicht, tut sie aber solange normales Telnet benutzt wird bzw. durch OS-Version auf einer Seite bedingt benutzt werden muss, oder? Ist es den Usern/Admins/Verantwortlichen älterer OS's bewusst, daß das so ist? Wann ja, dann dürfte der Telnet-Server auf AS400 in den letzten Jahren (bevor SSL möglich war) nirgendwo aktiviert gewesen sein. Weder im lokalen Netzwerk...
Das funktioniert sogar über WAN's !
...und schon gar nicht in WAN's. Wie hat dann aber die AS400<->AS400 bzw. AS400<->PC-ClientAccess Kommunikation bisher funktionert? Oder hat man

a) nicht gewusst
b) stillschweigend akzeptiert
c) sich keine Gedanken darum gemacht, weil AS400 sowieso "eine der sichersten Maschinen ist",

daß Anmeldungen an der "Hochsicherheitsmaschine" besonders einfach im Klartext mitzulesen sind?

*********
Fuerchau
[rlp_Moderator]

Registrierungsdatum: Feb 2001
Beiträge: 1.738
Wenn ich einen Telnet zu einem Windows-Server aufbaue, wird da die Kennworteingabe verschlüsselt übertragen ?
Nein, das ist bekannt und trotzdem nicht so einfach mitzulesen wie bei einer CA400-Sitzung. Deswegen benutzt man den Telnet-Server nicht auf Windows (wozu auch) und nimmt auf anderen Maschinen SSH, ggf. auch auf Windows.

AS400 steht aber auch nicht deswegen besser da, weil Windows auch unverschlüsseltes Telnet verwenden könnte!
Wie sieht es bei einer DCOM-Anwendung aus ? Erfolgt die Anmeldung da verschlüsselt ?
Wie sieht es bei einer Anmeldung bei einem SQL-Server (Microsoft/Oracle) aus, wenn ich in meinem Connection-String (ODBC/OLEDB) UID und PASSWORD im Klartext angebe ?

Ich glaube auch hier läßt sich trefflich darüber streiten, wie sicher denn die PC's im Intranet gegen Datenspionage sind !
Ist schon klar: die PCs im Intranet sind auch nicht besser und deswegen für die Sicherheitslöcher auf AS400 verantwortlich ;-)
Und das löst die AS400-Probleme oder macht sie weniger kritisch?

Genau unter dem Hintergrund "PC-Sicherheit" sind die AS400-Probleme übrigens erst aufgedeckt worden, die vorhandenen rd. 60 PCs und 4 Server auf PC-Basis sollten hinsichtlich der Sicherheit überprüft werden: diese lassen sich keineswegs so einfach "knacken", auch weil bekannte (!) Probleme auch schon bei der Installation berücksichtigt wurden. Sozusagen als Nebenergebnis wurden die AS400-Namen/Kennwörter auf den Schirm geblättert und vorgeführt, daß mit der Anmeldung einer der niedrigsten Privilegstufen (z.B. Test-User) das Durchwandern, Lesen und Schreiben sämtlicher AS400-Daten möglich ist, auch am Terminal. Und zwar nicht nur mit dem bösen PC-FTP-Client, sondern auch mit den IBM-Tools, auch unabhängig von Windows-PCs.

Natürlich muss man sich auch bei PCs um die Sicherheit kümmern, folgende Überlegung ist natürlich keine Entschuldigung für unsichere PCs: es dürfte wohl weit weniger dramatisch werden, wenn ein PC mit ein paar Briefchen geknackt wird, als wenn der Kundenstamm, Rechnungsarchiv, Lohndaten... auf AS400 ausgelesen/verändert werden können. Es muss ja auch nicht ausschließlich "kriminelle Energie" vorausgesetzt werden, solche Fälle können auch versehentlich bei normaler Benutzung der entsprechenden Programme auftreten.

Auch wegen der scheinbar hohen Sicherheit liegen die unternehmenskritischen Daten schließlich auf AS400 und bei dem derzeitigen Stand der Dinge ist das offensichtlich gleich aus mehreren Gründen ein Schuss in den Ofen. Wie im Internet an vielen Stellen nachzulesen ist, ist dies kein Einzelfall.
SSL-Verschlüsselung bei PC-PC-Kommunikation findet man (ausser im Internet) auch eher selten.

Auch für WindowsXP gilt ja eigentlich dass es sicher ist. Aber wenn ich keine Firewall verwende oder zumindest die "Internetverbindungsfirewall" aktiviere kommt jeder rein und bei den "erweiterten Sicherheitseinstellungen" ist normalerweise auch nichts aktiviert sondern die Intra-/Internet-Anmeldung läuft da auch unverschlüsselt.
Also zumindest die Netzwerkanmeldung läuft m.W. seit Win 98 verschlüsselt, wenn man das anders haben will, muss ein Registry-Eintrag ausdrücklich geändert werden. Aber auch diese Überlegung wie auch die Vorsichtsmaßnahmen, daß z.B. auf PCs selbstverständlich nicht das Wurzelverzeichnis planlos freigegeben wird und unnötige Dienste wegen bekannter Probleme selbstverständlich nicht gestartet werden, lösen die AS400-Probleme nicht.

Firewall: natürlich kommt das Firmennetzwerk hinter eine vernünftige Firewall und nicht jeder PC wurschtelt per ISDN im Internet herum, wie er will. In diesem Fall sind sogar zwei unabhägige Full-NAT-Router+jeweils Firewall vorgeschaltet. Linux-Server bringen die erforderliche (m.E. sehr effektive) Software im Kernel mit, bei Windows ist auch schon eine "Sparta-Firewall" dabei. Wer damit nicht zufrieden ist, kann sich auch weitere Firewall-Software (legal und kostenlos) besorgen.
Wie sieht die Firewall bei AS400 aus?
Vor allem: was soll damit gesperrt werden?

Wenn FTP auch nur auf einem Client benötigt wird, kann FTP nicht per Firewall gesperrt werden. Andernfalls müsste der FTP-Server erst gar nicht gestartet werden. D.h. die Dienste, die auch benutzt werden sollen/müssen, können nicht gesperrt werden und bringen Probleme mit sich. Was und wie soll die Firewall also schützen?
Fazit:
Um Sicherheit muss man sich kümmern !!
Automatisch läuft da nix !!
Umso trauriger, daß es im Auslieferungszustand (m.W. sind die Probleme nicht nachträglich/absichtlich/versehentlich dazugekommen) heißt "Tür und Tor sind offen" und IBM-gelieferte Tools sowie 0815-Programme wie FTP-Clients schon zum Chaos führen können. Hackerware nicht erforderlich.

Es bringt nichts, das Problem auf die PCs+Windows abwälzen zu wollen und die AS400-Sicherheit schön zu reden. Schließlich hat IBM selbst mit der Anbindung von PCs über ClientAccess den Zugang über PCs verbreitet eingeführt und hätte dann auch serverseitig auf entstehende Risiken reagieren müssen, insbesondere bei eigenen Tools CA400&Co wie auch grundsätzlich bei der Anbindung an IP-Netzwerke.
Wie soll die Sicherheit eines Servers denn auch durch Maßnahmen auf der Client-Seite erzeugt werden? Soll man die User bitten, möglichst das IBM-Excel-Plugin / Datenübertragung nicht zu benutzen oder bloß nicht den Befehl "FTP" einzutippen um dann sagen zu können "der AS400-Server ist sicher"? Das passt doch irgendwie nicht...

Und noch etwas: die hier beschrieben Probleme (FTP, Excel-Plugin, Datenübertragung) resultieren schon allein daraus, daß entsprechende Programme im Prinzip ordnungsgemäß genutzt werden, "Hacker-Aufwand" ist gar nicht erforderlich. Die besonders einfache Möglichkeit, Kennwörter auf dem Netz mitzulesen, ist vorläufig nur der Punkt auf dem i. Da AS400-OS-Programmierer wohl kaum frei von Fehlern sein dürften, wäre interessant, wie die Viren-/Sicherheitsfrage aussehen würde, wenn AS400 wie PC-Systeme im Mittelpunkt von Hacker-Aktivitäten stehen würde und für Übungszwecke in jedem zweiten Haushalt vorhanden wäre, also echte Fehler im System ausgenutzt würden (s.a. http://as400.holgerscherer.de/hackerinfo.html).

Fazit: Die vorhandenen Löcher müssen irgendwann nachträglich auf AS400 geflickt werden und das ist (soweit ich das aus anderen Berichten im Internet verstanden habe) mit Boardmitteln eben nicht sinnvoll bzw. vollständig möglich. Eventuell muss serverseitig zusätzliche Software angeschafft werden, die Clients müssen neue Software bekommen. Es ist auch wahrscheinlich, daß das nachträgliche Aufsetzen eines Sicherheitskonzeptes - wie auf anderen Systemen auch - zu einem erheblichen Planungs- und Durchführungs-Aufwand führen und gar nicht so einfach machbar sein wird. Folgefehler aufgrund fehlender Rechte an Dateien werden auszubügeln sein, usw. usw.

Viel Aufwand, um "eine der sichersten Maschinen" gegen den Daten-GAU durch Normal-User und 0815-Programme zu schützen.


Schönen Sonntag-Abend noch,
Ingo K.

[Fuerchau]

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]

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

[Fuerchau]

Ach Dieter, so schön kann ich das leider nicht beschreiben aber du sprichst mir aus der Seele.

[Fuerchau]

Noch ein kleiner Nachtrag:
http://publib.boulder.ibm.com/iserie...trolaccess.htm

[loeweadolf]

Stellungsnahme von Holger Scherer:

Hallo Ludger,

diese Diskusssion ufert (oder ist bereits) wie üblich in
den Bereich des Emotionellen aus. Das passiert oft, wenn
iSeries- und RestDerWelt-Netzwerker aufeinander treffen.
Die alte Weisheit "AS/400 ist sicher wie eine Burg"
trifft auch nur zu, wenn die Burg leer ist (keine PCs).

Solange nicht jeder Client mit jedem Server glaubwürdig
verschlüsselt kommuniziert, ist kein System mehr sicher.

Hach, was waren das noch für schöne Zeiten, damals mit reinen
Twinax-Clients ;-)

-h