Anmelden

View Full Version : Aktuelle Virenwarnungen



Seiten : 1 [2] 3 4

Pikachu
17-12-15, 15:50
Bibliotheken/Dateien sind selbst Teil des IFS:
/QSYS.LIB/Bibliothek.LIB/Datei.FILE/Teildatei.MBR

Es kommt natürlich immer auf die Berechtigung an,
ob jemand (Benutzername/Kennwort) Daten verändern darf.


Meine Bedenken hier sind eher, wäre es möglich vom IFS/QDLS aus gezielt auf Bibliotheken/Dateien zuzugreifen?

BenderD
17-12-15, 16:13
Bibliotheken/Dateien sind selbst Teil des IFS:
/QSYS.LIB/Bibliothek.LIB/Datei.FILE/Teildatei.MBR

Es kommt natürlich immer auf die Berechtigung an,
ob jemand (Benutzername/Kennwort) Daten verändern darf.

... über einen Zugriff via IFS auf QSYS.LIB Objekte ist eine Verschlüsselung/Zerstörung per Modifikation der Objekte nicht möglich; anders könnte es da mit löschen aussehen. Diese Art von Virus wäre da wohl verpufft.

D*B

Pikachu
17-12-15, 16:58
Also den Inhalt einer Teildatei kann man darüber (mit nem Editor) schon irgendwie verändern ...


... über einen Zugriff via IFS auf QSYS.LIB Objekte ist eine Verschlüsselung/Zerstörung per Modifikation der Objekte nicht möglich; anders könnte es da mit löschen aussehen. Diese Art von Virus wäre da wohl verpufft.D*B

BenderD
17-12-15, 19:03
mit nem Editor
... aber nur wenn der Editor auf den entsprechenden Schnittstellen aufsetzt. Es zieht schon noch das Obejkt basierte Design der AS/400, dass jedes Objekt nur mit dafür vorgesehenen Methoden angefasst werden kann und unter der Oberfläche werden dann bestimmte Konsistenz Bedingungen eingehalten. Man kann also zum Beispiel einer Teildatei nicht erzählen, dass sie nun ein Programm sei oder umgekehrt. Unfug kann man da immer noch machen, aber eben anders als unter Windoof.

D*B

holgerscherer
18-12-15, 00:54
Und ob einer gezielt einen Compiler mit Virencode anschmeißt halte ich eher für ein Gerücht.
...
Bei der AS/400 sitzen die Trojaner meist vor den Bildschirmen.

Virencode kann ich auch mit CL erstellen. Allerdings kann der Virencode nix machen, da (wie schon hier geschrieben) es nicht ganz so einfach ist, *PGM Objekte zu modifizieren...

Was im IFS passiert, ist dem i erst mal egal, das muss man ausklammern oder über Virenscanner verhindern.

Was aber schon immer geht: die Client Access APIs mal so richtig zum Glühen zu bringen. Wer CA installiert hat, und am besten noch automatische Anmeldung (via SSO) aktiv hat, dem ist sowieso nicht zu helfen...

-h

MoselRBA
18-12-15, 06:08
Wer CA installiert hat, und am besten noch automatische Anmeldung (via SSO) aktiv hat, dem ist sowieso nicht zu helfen...-hAutsch! Der sitzt, was kann man da besser machen? Gibt es Literatur wo man sich mal mit beschäftigen könnte?

Fuerchau
18-12-15, 07:42
Die Literatur bezieht sich i.W. auf das Berechtigungskonzept der AS/400.
Hier kann ich jedes Objekt (eine Lib gehört auch dazu) gegen unbefugten Zugriff schützen.
Ein Virus hat nur dann eine Chance wenn der User über *ALLOBJ-Berechtigung verfügt und diese ist z.B. dem QSECOFR vorbehalten.
Wie Dieter schon schreibt, jedes AS/400-Objekt hat seine Zugriffsmethoden die unbedingt einzuhalten sind (ja, die AS/400 ist von Grund auf ein objektorientiertes System).
Schadsoftware á la Windows hat da nun mal schlechte Karten.

Was den Rest der IFS-Welt angeht so ist diese genauso gut geschützt wie jeder Windowsserver.

andreaspr@aon.at
18-12-15, 08:17
Mein Lieblingsvergleich ist der, dass Security im OS der IBM i von Anfang an im Kern mitentwickelt wurde.
Anders bei Windows und Unix wo Security quasi ein "Add-On" ist.
Du kannst einen Kernel erstellen der kein Berechtigungssystem hat. Wenn du zum Zusammenbauen eines Kernels eine SW verwendest, kannst du neben den Prozessor Treibern uvm. auch ein Hacken bei Berechtigungen machen oder nicht.

Das macht es schwieriger Sicherheitslücken zu finden. Nicht umsonst gibt es Berichte wo die AS/400 frei im Internet stand weil ein Admin diverse Firewall Regeln vergessen hatte und das jahrelang keinem auffiel.

Natürlich wenn z.B. alle user mit *ALLOBJ ausgestattet sind, hilft die beste Security nicht.
Oder Passwörter aus den Top 25 häufig verwendeten stammen.

AG1965_2
18-12-15, 09:57
Ein Virus ist erst dann bedrohlich, wenn er eine CPU findet, die ihn verstehen kann und ausführen will.
Das wird einem auf einem System i nicht so leicht gelingen wie auf einer anderen Plattform.
Schließlich kann man hier - zumindest im klassischen Bibliotheksdateisystem - nicht so leicht aus z.B. einem Textfile ein Programm machen.

Fuerchau
18-12-15, 10:07
Wer sich ein wenig mit REXX auskennt der weiß, dass mit der entsprechenden Berechtigung eine REXX-Prozedur dynamisch erstellt und ausgeführt werden kann.
Da REXX immer verfügbar ist kann dies für Makroviren ein interessanter Ansatz sein.
Allerdings muss das Virus sich schon per SQL oder API in die AS/400 einloggen.