[Datenschleuder] [31]    DECnet

DECnet DECnet ist ein Netz für Rechner von Digital Equipment Corporation (:= DEC), bzw. für Rechner, die die DECnetsoftware besitzen. DECnet gibt's für die Betriebsysteme VMS (1), RSX (2), ULTRIX bzw. Unix (3), und mit Einschränkungen für DECnet-DOS, das eine DEC-Variante von MS-DOS darstellt und auf IBM-kompatiblen Mühlen läuft. Die physikalische Grundlage von DECnet ist Ethernet, sowohl als Koax als auch neuerdings vermehrt Glasfaser. Die kleinste Übertragungsgeschwindigkeit beträgt 9600 kBaud, die Größte 10 MBaud. DECnet war ursprünglich nur als reines lokales Netz geplant, wird inzwischen aber auch vermehrt als WAN (Wide Area Network) eingesetzt, zum Teil ganze Kontinente umspannend. Es gibt aber nicht nur ein DECnet, so wie es z.B. nur ein Fidonet gibt, sondern sehr viele in der ganzen Welt mit sehr unterschiedlichen Größen. Diese diversen DECnets sind teilweise miteinander verbunden und haben Gateways zu anderen Netzen. Betrieben werden die DECnets meistens von Unis, Instituten und ähnlichem, aber auch Firmen haben welche, bzw. lassen sich dran anschließen. Die meisten DECnet-Installationen enthalten zu 90% VAXen unter VMS und haben damit eine sehr homogene Benutzeroberfläche. Die Adresse eines Rechners im DECnet lautet 'nodename::username', wobei node sein kann: 1) ein logical (4) 2) eine Zahl zwischen 2.1) 0 und 1023; damit werden lokale Rechner angesprochen. 2.2) zwischen 1024 und 64512 (=2**16-2**10) In den folgenden Ausführungen werde ich mich auf VMS beschränken. Netzwerkfunktionen Remote Login: mit dem Befehl 'set host <node>' kann man sich auf einem weiteren Rechner einloggen. Beispiel: set host netvax Remote command: einen Befehl an einen anderen node schicken. Beispiel: NETDCL.COM (siehe unten) Remote job entry: einen task auf einem anderen node starten. Beispiel: NETDCL.COM (siehe unten) Task-to-Task- communication: Prozesse auf verschiedenen Rechnern tauschen Daten untereinander aus. File Transfer: ein Filetransfer ist in beiden Richtungen möglich. Entweder mit: copy source node"user password"::destination oder: copy nod"user password"::source destination Beispiel: copy test.txt netvax"framstag geheim"::disk3:<users.framstag) Mail: Jeder User hat in VMS seine eigene mailbox. Wobei mailbox wörtlich zu nehmen ist: ein Briefkasten in den der Postbote (:=DECnet) Briefe einwirft oder man selbst Briefe an andere User aufgibt. Angekommene mails werden innerhalb der mailbox gespeichert und beim einloggen wird angezeigt, ob und wieviel mails man bekommen hat. Diese mails können dann in normale files umkopiert oder ausgedruckt werden. Beim mail-Aufruf kann entweder ein vorher erstelltes (Text-) File angegeben und abgeschickt werden, oder mail fragt nach dem Text interaktiv. Ist der Adressent eingeloggt, bekommt er die Nachricht, daß er soeben Post erhalten hat. Beispiel: mail/subject="neues vom CCC!" test.txt netvax::framstag Phone: Das ist die Facility zum chatten! PHONE ist eine interaktive Kommunikation zwischen Usern und entspricht dem TALK bei UNIX oder einem "deluxe-"CHAT bei VM/CMS. Der Bildschirm wird in 2 Teile gesplittet, wobei die obere Hälfte einem selber gehört, die untere dem Telefonpartner. Nun kann munter drauflosgetippt werden, wobei jeder Buchstabe sofort übermitteit wird und nicht erst der ganze Satz nach (return> Bei Bedarf kann auch ein Konferenzphone geschaltet werden. der Bildschirm wird dann in x User aufgesplittet und alle können gleichzeitig tippen (*Wahnsinnschaos*). Um sich vor einem möglichen Telefonterror zu schützen gibt's die Möglichkeit sein phone abzuklemmen: set broadcast=nophone, Beispiel: phone 45152::framstag Wie weiß ich nun, welche VAXen in meinem DECnet drin sind? Da gibt's die schöne Utility ncp (Network Control Programm), die einem mit 'mcr ncp show known nodes' ... was wohl zeigt? Dieses NCP bietet aber noch wesentlich mehr Möglichkeiten, von denen ich hier nur eine Übersicht aufliste (siehe Kästchen weiter unten). Tja, und wie komme ich nun an die User? 1. Man kennt diesen kommunikationswilligen User. Prima, alles paletti. 2. Mit 'phone dir node' bekommt man eine Liste der user auf der 'node'-VAX. 3. Falls 2. nicht klappen sollte: NETDCL.COM (7) 'NETDCL.COM' muß im aktuellen Directory gespeichert sein. Der Aufruf erfolgt dann mit: @netdcl Vorausgesetzt die ZielVAX läßt einen herein, ist man als User DECNET drin. Nun schauen wir uns mit 'show user' um, ob jemand bekanntes da ist und phonen oder mailen ihn an (nach logout vom netdcl). Aber Vorsicht: es könnte auch ein Prof oder Sysop dahinter stecken, der gerade beschäftigt ist. Aber da kann man sich ja noch herausreden mit: "Ihr phone war nicht abgestellt und da dachte ich mir, ruf doch mal an...." $ mcr ncp help commands SET Change parameters in the volatile database DEFINE Change parameters in the permanent database CLEAR Remove components or PURGE parameters from the volatile or permanent databases SHOW Display information about LIST components in the volatile or permanent databases CONNECT Connect local terminal to remote node console interface DISCONNECT Disconnect logical links with processes COPY Copy one node database to another LOOP Test lines or connections to nodes LOAD Downline load nodes TRIGGER Inmiliate bootstrap sequence of a node TELL Establish temporary executor node ZERO Zero counters of the specified entity Wie komme ich nun in's DECnet? 1. remote login 1.1 Man ist schon drin. Die meisten Unirechenzentren vergeben Accounts auch an Studenten. 1.2 über einen öffentlichen Account; leider gibt's da sehr sehr wenige...und es werden immer weniger. Das liegt an dem unkollegialen Verhalten einiger 'Mithacker', die solange keine Ruhe geben, bis sie Systemprivilegien besitzen und die VAX zum Absturz bringen. Spätestens dann gibt's einen öffentlichen Account weniger. Also, liebe Leute, diese öffentlichen Accounts sind extra füR UNS eingerichtet worden! Die Uni braucht so was nicht! Mißbraucht diese Gastfreundschaft nicht! Einen Tip habe ich: die VAX der FH der Post in Berlin läßt guest herein, erlaubt ihm aber dann keinen set host (:= remote login). NUA: 45300090864 ...und wenn jemand mal im BELWUE ist: 50184::boerse ist eine offene Mailbox. 2. mail geht eigentlich nur, wenn der Betreffende node noch andere mailsoftware fährt - und entsprechend verkabelt ist. z.B.: JNET für EARN/bitnet-mail oder EAN für x.400-mail. Mail direkt an einen nur-DECnet-Knoten zu schicken geht von außen nicht. Was kann ich mit DECnet anfangen? Im allgemeinen: fast gar nichts, wenn ich vom User ausgehe, der von außen ins DECnet möchte. Der Grund: DECnets sind im Prinzip nicht für den öffentlichen Zugang ausgelegt. DECnet lohnt sich eigentlich nur für den authorisierten User, sei es nun Universitätsangehöriger, Student, Betreiber etc... und latürnich für den Hacker :-) Es gibt keine Standard-Mailboxen, -server, oder andere nützliche Dinge. Der Betreiber des jeweiligen DECnets muß das schon selber einrichten - und die meisten tun es leider nicht. Gateways (falls vorhanden) aus DECnet heraus zu anderen Netzen: Mit FTP oder TELNET über TCP/IP in Arpa/Internet-ähnliche Netze, wie das BELWUE (6), mit JNET ins EARN/bitnet, mit gmail (PD-SW) ins usenet und dessen Derivate, mit EAN ins DFN und andere x.400-Netze oder mit psi ins datex-p. Beispiel eines DECnet(8): Das DECnet im BELWUE. Es enthält zur Zeit ca. 300 nodes und ist noch im Aufbau begriffen. Vernetzt sind alle Unis in Baden-Würtemberg, viele Institute und einige Firmen. Zum Schluß noch eine Story, direkt aus dem Leben eines DECnet-users gegriffen: Es folgt nun die unglaublichste Mär wie man aus User Hacker macht: Auf jeder VAX gibt es einen Standard-Account DECNET mit pw:= DECNET, der aber NICHT mit remote login erreicht werden kann. Dieser account ist für verschiedene DECnet-Utilities und als Pseudo-Gast-Account vorgesehen. Dieser DECNET-Account hat sehr eingeschränkte Rechte, so ist z.B. ein editieren oder ein weiterer Netzwerkzugriff nicht möglich. Das HELP-Menue wird vom System eingerichtet und entspricht dem MAN bei UNIX. Hier an der Uni Ulm gibt es ein *unglaublich* unwissendes Rechenzentrum, mit einem noch größeren Mangel an Literatur (mal abgesehen von den 80 kg VAX/VMS-Manuals). Der aktive User darf sich seine Information, die über "run", "FORTRAN" oder "LOGOUT" hinausgehen, selbst suchen. Gut, daß ich im BELWUE-DECnet noch andere Accounts besitze, wo mehr Informationen für den User angeboten werden. In einem Tübinger Rechner fand ich im HELP-Menue die Erklärung zur Prozedur NETDCL.COM, die Kommandos an den DECNET-Account anderer VAXen schickt und dort ausführen läßt (remote command). Die Anleitung im HELP-Menue war idiotensicher - also auch für mich :-) Mit "$ mcr nep show nodes" bekommt man ja bekanntlich die aktiven VAXen im DECnet und so probierte ich mal der Reihe nach alle durch, um zu sehen, wo es noch mehr Infos für einen wissensdurstigen User gibt. Mit "help", "dir" und ähnlichen Befehlen schaute ich mich dann um. Leider haben 2/3 aller VAXen den DECNET-Account für das NETDCL.COM gesperrt, wahrscheinlich aus Angst vor unberechtigtem Zugriff, wie auch immer der aussehen mag. Von manchen Systemmanagern kam dann auch ab und zu eine mail an mich, in der sie sich bei mir erkundigten, ob sie mir weiter helfen könnten bzw. einer schickte mir eine NETDCL.COM-Version für ULTRIX. Dann, nach einem Monat kam das GRAUEN in Form folgender mail von meinem Systemmanager: From: TUEBINGEN::SYSTEM 31-MAY-1989 15:31:11.38 To: FRAMSTAG CC: Subj: mach bloss kein scheiss sonst fliegst du raus From: ITTGPX::SYSTEM 29-MAY-1989 16:46 To: TUEBINGEN::SYSTEM Subj: Systemeinbruch am 01-May-1989 An den Systemmanager des Rechners TUEBINGEN, wir hatten am 01-May-1989 über den DECnet-Account einen Systemeinbruch, der von Ihrer Maschine ausging. Über unser Accounting konnten wir feststellen, daß Ihr User FRAMSTAG über das "trojanische Pferd" NETDCL.COM auf unseren Brückenrechner und auf jeden Rechner unseres VAXclusters einen interaktiven Login emuliert hat. Nennen Sie uns Namen und Adresse dieses Users und klären Sie den Vorgang vollständig auf. Wir weisen Sie darauf hin, daß sich der User durch diesen Vorgang strafbar gemacht hat. Sollte sich dies wiederholen, so sehen wir uns gezwungen, entsprechende Gegenmaßnahmen einzuleiten. Wir werden überprüfen, ob an unserem System Schaden entstanden ist. Sollte dies nicht der Fall sein, so werden wir von Maßnahmen diesmal absehen. Teilen Sie uns über DECnet die Ergebnisse Ihrer Recherchen mit - wir sind über die Knotennummer 1084::System zu erreichen. Dipl.-Ing. ######### Mein Systemmanager drohte, mir meinen Account zu löschen, falls ich nicht augenblicklich die Sache klären würde. *schluck* Ich war mir meiner Unschuld absolut gewiß; nur - wie sag ich's den anderen? Ich erklärte klitzeklein alles meinem Systemmanager, was er dann auch geblickt hat, aber die Strafandrohung schwebte immer noch... Also schnell zur Tastatur gegriffen, eine Erklärungsfile verfaßt und abgeschickt an diesen wütenden Systemmanager in Stuttgart. Leider war's nichts damit: Er hatte keinen Speicherplatz mehr und meine Erklärungsmail landete im Nirwana: $ mail erklaerung To: 1084::system %MAIL-E, error sending to user SYSTEM at 1084 %MAIL-E-OPENOUT, error opening SYS$SYSROOT:[SYSMGR]MAIL$00040092594FD194.MAI; as output -RMS-E-CRE, ACP file create failed -SYSTEM-F-EXDISKQUOTA, disk quota exceeded Auch der Versuch ihn über PHONE zu erreichen lief schief: er hatte in seiner Hacker-Paranoia auch noch sein PHONE abgeklemmt... nirgendwo gibt's eine Liste in der die REAL-Adressen von den DECnet-Adressen stehen. Nun stand ich mit dem Brandzeichen "GEFÄHRLICHER HACKER" da und konnte mich nicht rechtfertigen. Ich klagte mein Leid bei einem Bekannten, der Sysop im RZ in Freiburg ist - der fragte bei weiteren ihm bekannten Sysops in Stuttgart nach. Irgendjemand hatte dann drei Telefonnummern gefunden. Eine davon war tatsächlich richtig. Ich bekam auch dann diesen ######### ans Telefon und erzählte ihm, was ich denn auf seinem DECnet-Account gemacht hatte. Er nahm auch dann prompt seine Vorwürfe zurück (von Entschuldigung aber keine Spur). Ich bat ihn schnellstmöglich, meinem Systemmanager in Tübingen Entwarnung zu geben, sonst würde mir noch mein Account gelöscht, wie es in einem ähnlichen Fall einem Komilitonen von mir schon passiert war (auch hier war ######### dran schuld). Er sagte mir zu, daß er sofort seine Vorwürfe offiziell zurückziehen würde. Nach über einer Woche ist dies immer noch nicht geschehen (Ich durfte trotzdem meinen Account behalten); dafür kam folgende mail an mich (an einen dritten Account von mir): From: 1084::######### 1-Jun-1989 12:51 To: 50180::STUD-11 Subj: Systemeinbruch An den User STUD-11 des Rechners mit der Kontennummer 50180, Sie haben am 01-Jun-1989 ab 12:29 auf mindestens einem unserer institutionseigenen VAXen einen Systemeinbruch begangen. Wir konnten diesen Vorgang mitprotokolieren. Wir fordern Sie hiermit auf, Rechenschaft über diesen Vorgang abzulegen. Sollten wir bis zum 09-Jun-1989 keine lückenlose Aufklärung über den Vorfall von Ihnen erhalten, sehen wir uns gezwungen, weitere Maßnahmen zu ergreifen. Die dadurch entstehenden Kosten würden wir selbstverständlich Ihnen auferlegen. Eine Aufklärung ist somit in Ihrem eigenen Interesse. Sie können uns über DECnet-Mail mit der Adresse 1084*########## oder über unten folgende Adresse erreichen. Institut für Technische Thermodynamik und Thermische Verfahrenstechnik Dipl.-Ing. ########## Tel.: ########## Dipl.-Ing, ########## Tel.: ########## Pfaffenwaldring 9/10-1 7000 Stuttgart-80 Das war, weil ich "$ PHONE 1084::SYSTEM" gemacht hatte. Auf diese Mail habe ich nicht mehr geantwortet. Ich hab keine Lust mehr. Anhang: NETDCL.COM $ IF f$mode() .EQS. "NETWORK" THEN GOTO network $ IF p1 .EQS. "" THEN READ/PROMPT="-NODE: " sys$command p1 $ nodespec = p1 - "::" $ nodename = f$extract(0,%locate("""",nodespec),nodespec) $ nodespec = nodespec+"""decnet""" $ ON WARNING THEN CONTINUE $ CLOSE/ERR=open-server del-server $open-server: $ OPEN/READ/WRITE del-server 'nodesec'::"TASK=NETDCL"/ERROR=open-failure $ ON WARNING THEN GOTO EXIT $flush-outpu: $ READ dcl-server record $ IF record .EQS. "SEND-ME-A-COMMAND" - THEN GOTO send-command $ WRITE sys$output record $ GOTO flush-output $send-command: $ IF p2 .NES "" THEN GOTO single-command $ READ sys$command record /PROMPT=""nodename'> " /END=exit $ $ record := 'record $ IF record .EQS. "EXIT" THEN GOTO exit $ WRITE del-server record $ GOTO flush-output $single-command: $ command := 'p2' 'p3' 'p4' 'p5' 'p6' 'p7' 'p8' $ WRITE del-server command $single-flush: $ READ del-server record $ IF record .EQS. "SEND-ME-A-COMMAND"- THEN GOTO exit $ WRITE sys$output record $ GOTO single-flush $open-failure: $ ON WARNING THEN EXIT $ ON error then copy/log netdcl.com 'nodespec':: $ COPY/LOG Netdcl.com 'noespec':: $ WAIT 0:01 $ OPEN/READ/WRITE dcl-server 'nodespec'::"TASK-NETDCL" $ ON WARNING THEN GOTO exit $ GOTO flush-output $exit: $ CLOSE dcl-server $ EXIT $network: $ OPEN/READ/WRITE del-link sys§net $ SET NOON $ del-verify = 'f$verify(0)' $ DEFINE sys$output dcl-link: $server-loop: $ WRITE del-link "SEND-ME-A-COMMAND" $ READ del-link del-string /END-OF-FILE=server-exit / ERROR=server-exit $ 'del-string' $ GOTO server-loop $server-exit: $ IF del-verify THEN set verify $ CLOSE del-link $ DEASSIGN sys$output $ EXIT (1) VMS ist das Standardbetriebssystem für die VAX (2) RSX ist das Echtzeitbetriebssystem für die PDP 11 (3) ULTRIX ist UNIX für VAX (4) ein logical ist eine (System- oder Prozeß-weit verfügbare) Variable (5) source und destination sind VMS-Pfad und -Filebezeichnungen, allgemeine Form: disk:<directory.subdir>name.extension wobei es latürnich mehrere verschachtelte subdirs geben kann. (6) BELWUE := Baden-Würtemberg Extended LAN (7) Vorsicht mit NETDCL.COM! Ich hafte nicht für die Anwendung (8) siehe auch der SPAN-Artikel von Stephan Stahl in"Das Chaos Computer Buch" Als weiterführende Literatur kann eigentlich mehr das DECnet Manual von DEC empfohlen werden. Framstag asta@dulruu51.bitnet asta@rz.uni-ulm.dbp.de 50117::asta (im BELWUE)

[Datenschleuder] [31]    DECnet