View Full Version : Sicherheitsproblem "Kennwort knacken"
@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/artikel/biblio/sic_ip.php
http://www-1.ibm.com/servers/eserver/iseries/tcpip/telnet/ssl.htm
loeweadolf
07-07-04, 12:22
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
07-07-04, 13:13
Ich habe nachstehend die Stellungnahme des Mitarbeiters aufgeführt, der diem Kennwörter rausgefunden hat.
mfg. Ludger
Tagchen!
Ist ja schon interessant...
Also muss CA mit SSL/Telnet her? Da muss CA auf ALLEN PC's neu
installiert werden - na dann Prost&Mahlzeit!
> Seit der Einführung von Client-PC's an der AS/400 gibt es diese
> "Probleme", die eigentlich gar keine sind !!!
Wie gesagt: das gleiche (Kennwort-Auslesen-)Problem wäre auch, wenn zwei
AS400's sich über's Netz unterhalten.
Es ist schon klar, daß das nicht problematisch ist, wenn AS400
ausschließlich über "Russenschirme" bedient wird. Es ist auch klar, daß
mein uralter Windows-3.11-PC auch nicht zu knacken ist, wenn der keine
Netzwerkverbindung hat und ich die Festplatte in der Hosentasche herumtrage.
> 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.
Das Problem ist nur, daß man zunächst von höchster Sicherheit ausgeht
(Werbung, Anschein der Sitzungen, Aufwand mit Anmeldungen usw.), in
Wirklichkeit aber "offen wie ein Scheunentor" ist. Jetzt, 10 Jahre und
1000e Dateien später, muss man sich nachträglich um die Sicherheit
kümmern - soweit ich die Sache verstanden habe (!), ist das mit
AS400-Bordmitteln auch nicht unbedingt vollständig möglich (zumindest im
Excel-DÜ/FTP-Fall), es werden u.U. zusätzliche Tools benötigt.
Das wird schwierig - wie auf anderen Systemen auch, wenn das
Sicherheitskonzept erst nachträglich angelegt wird.
Sicher kommt mit den PCs noch das Problem dazu, daß viele "interessante"
Programme verfügbar sind (Sniffer usw., bequeme
Datenübertragungsprogramme wie FTP-Clients oder Excel-Datenübertragung,
ODBC-Treiber usw. z.T von IBM selbst geliefert) und zudem nicht mehr
ausschließlich "menugesteuerte" User vor dem Schirm sitzen. Für viele
PC-User ist der Begriff "FTP" sicherlich kein Fremdwort, schon wer
Excel+IBM-Datenübertragung-Plugin auf dem PC hat, ist ein
Sicherheitsrisiko.
Na dann,
I. K.
Hallo Ludger,
diese Probleme sind keineswegs auf PCs als Terminals beschränkt. Auch Terminals lassen sich sniffen auch auf Twinax oder sonstigen beliebigen Leitungen. Noch besser sind alle Funkstrecken, zum Beispiel lässt sich der Transfer zwischen kabelloser Tastatur und Rechner abfressen, selbst nach potentieller Umstellung auf SSL; mit empfindlichen Geräten sicherlich auch von außerhalb des Büros oder sogar Gebäudes.
Sicherheit besteht im wesentlichen aus vier Bausteinen:
1. geschützte Netzwerkverbindungen, oder Verschlüsselung (SSL)
2. physikalischer Schutz zentraler Rechner (manuell hochgefahren von einem alternativen Boot Device fressen diese Viecher aus der Hand!)
3. selektive Installation zentraler Rechner und kontrollierter Betrieb (nur die Dienste, die benötigt werden)
4. adäquate Rechtevergabe und Benutzer Authentifikation
Menüschutz und was es da noch so alles an Pseudolösungen gibt (beinahe hätte ich hier Produkte erwähnt) bringen da nicht weiter, beruhigen allenfalls ungemein.
Wenn da noch offene Außenverbindungen da sind, dann geht das nur mit spezieller Firewall (Hardware/Software) alles andere ist Prinzip Hoffnung.
mfg
Dieter Bender,
der sich nicht mehr mit diesen Dingen beschäftigt.
Ich habe nachstehend die Stellungnahme des Mitarbeiters aufgeführt, der diem Kennwörter rausgefunden hat.
mfg. Ludger
@Ludger
Die Stellungnahme deines Kollegen finde ich ja höchst interessant!
Klar ist:
Sobald ich eine Tür aufmache, muss ich zusehen wen ich hereinlasse oder nicht.
Die AS/400 ist eine der sichersten Maschinen !
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.
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.
Nicht umsonst ist die AS/400 bisher 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. Das funktioniert sogar über WAN's !
@Dieter
Wenn man den Gerüchten glauben soll, besitzt der CIA einen Generalschlüssel für die 128-Bit-Verschlüsselung, da kann man sich mit SSL ja auf den Kopf stellen.
Wie war der Closed-Shop-Betrieb doch so angenehm.
@Baldur
Das erste ist das klassische Missverständnis überhaupt. Die AS400 hat bis V3R2 gebraucht, um C2 Security zu bekommen (was nicht das höchste Level ist) und die Prüfer müssen damals volltrunken gewesen sein, wenn man sich den Stand von V3R2 ansieht (kein Adressschutz, schwache Kennwörter etc.). Was hier richtiger wäre: die AS400 ist ein System, das man mit wenig Aufwand für die Sicherheitsanforderungen typischer kommerzieller Nutzer einrichten kann. Aber auch hier muss man was tun. Ein Hochsicherheitsrechner ist dies keinesfalls: es ist kein Zufall, dass nie eine Firewall auf der AS gelaufen ist (es gab mal auf dem IPCS unter einem kastrierten OS2). Der Auslieferungszustand der Maschine hat sich zwar gebessert, aber der reicht nicht einmal für niedrige Anforderungen aus.
Das zweite ist auch so eines von selbigen; die AS400 hat sogar ein eingebautes Schadprogramm (CFINT lässt grüßen) das ist kein Virus, sondern eher ein Wurm, aber der klassische Beleg, dass das sehr wohl geht, mit ähnlich unkontrollierbaren Auswirkungen und beabsichtigten und versehentlichen Schadwirkungen. Wenn es nicht soviele gibt und da nix publiziert wird, liegt das eher daran, dass die kritische Masse an Installationen nicht da ist und sich die meisten hacker mit anderen Betriebssystemen beschäftigen (auch hier sollte man mal über die kommerziellen Aspekte nachdenken.
Das mit dem CIA, naja wenn man höchste Sicherheitsanforderungen hat, darf man eigentlich generell keine amerikanischen Produkte kaufen; aber auch hier gäbe es Alternativen PGP ist noch in ungepatchten Versionen zu bekommen.
In jedem Fall ist es eine gute Idee, wenn man sich darum kümmert, was eigentlich alles so auf einem Rechner los ist, damit man merkt, wenn jemand versucht Unfug anzurichten, damit man ihn wenigstens erwischt, wenn er Schaden angerichtet hat und ihn rechtzeitig aus dem verkehr ziehen kann. Verhindern kann man das ohnehin nur wenn man den Rechner zum Authismus verdammt.
Dieter
Klar ist:
Die AS/400 ist eine der sichersten Maschinen !
Nicht umsonst ist die AS/400 bisher virenfrei !!!
Wenn man den Gerüchten glauben soll, besitzt der CIA einen Generalschlüssel für die 128-Bit-Verschlüsselung, da kann man sich mit SSL ja auf den Kopf stellen.
Wie war der Closed-Shop-Betrieb doch so angenehm.
Wenn ich einen Telnet zu einem Windows-Server aufbaue, wird da die Kennworteingabe verschlüsselt übertragen ?
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 !
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.
Fazit:
Um Sicherheit muss man sich kümmern !!
Automatisch läuft da nix !!
loeweadolf
11-07-04, 22:39
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.
loeweadolf
12-07-04, 11:20
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
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 !