ZAM-TKI-0147 - Hinweise zur Systemkonfiguration von TCP/IP Hosts

Seit Anfang 1990 unterstützt JuNet (ehemals KFAnet/INTERNET) IP-basierende Protokolle und Kommunikationsdienste sowohl innerhalb des Forschungszentrums Jülich (FZJ) als auch weltweit ins Internet. Grundsätzlich garantiert JuNet als langfristiges Angebot unabhängig von den zugrunde liegenden Transportprotokollen die für den wissenschaftlich-technischen Einsatz benötigten Netzdienste wie z.B. File-Transfer oder Electronic Mail.

Um dieses Angebot nutzen zu können, muß das Betriebssystem eines Rechners gemäß den für JuNet geltenden Richtlinien konfiguriert sein, bevor es hardwaremäßig ans JuNet (Siehe ZAM-TKI-0146) angeschlossen wird. Die vorliegende TKI soll dem Systemverantwortlichen (Administrator, root) ergänzend zu den üblichen Firmenunterlagen allgemeingültige Hinweise zur korrekten Einrichtung der IP-Kommunikationsdienste für JuNet geben. Alle Netzwerkeinstellungen sind, da sie Benutzer-unabhängig für das ganze System gelten, unter Unix als "root" oder als "Administrator" auf Windows-NT/2000-Systemen durchzuführen.

Weitergehende Beratung bieten die benannten Netzwerk-Ansprechpartner in den Instituten oder ggf. auch das ZAM unter Tel. 4772 oder 6421.

2. Rechneranmeldung

Die Netzwerkadressen der JuNet/INTERNET-Hosts werden zentral vom ZAM verwaltet: Das ZAM vergibt für jeden Rechner in JuNet weltweit gültige Internet-Adressen (Klasse-B-Netzwerk) und stellt die zum Netzbetrieb erforderlichen Tabellen sowie für alle Rechner gemeinsam einen Name-Service (BIND) zur Verfügung. Bevor ein Systemverwalter TCP/IP konfiguriert und seinen Rechner physikalisch ans Netz anschließt, muß die Bearbeitung eines entsprechenden Antrags im ZAM abgeschlossen sein.

Voraussetzung für die Rechneranmeldung ist eine "offizielle Mailadresse" des Systemadministrators, die unter der URL

durch eine E-Mail an dispatch.zam@fz-juelich.de oder persönlich beim ZAM-Dispatch (G16.3, Raum 04) beantragt werden kann.

Die Anmeldung des Rechners erfolgt anschließend über das Formblatt ZAM-TKI0146 oder on-line über den URL

bzw. durch eine E-Mail an junet@fz-juelich.de . Das ZAM vergibt dabei für jedes System eindeutige Konfigurationsparameter, die einen reibungslosen Netzbetrieb und Kommunikation im internationalen Netzverbund gewährleisten. Über alle Änderungen wie Tausch der Netzwerkkarte (Hardware-Adresse), Ortswechsel oder Änderung der E-Mail-Adresse des Systemverantwortlichen ist das ZAM durch Anschreiben, E-Mail oder telefonisch unter Tel. 4772 zu informieren. Nur auf der Basis korrekter Einträge in der JuNet-Datenbank kann das ZAM die Benutzer über wichtige Ereignisse im Netzbetrieb informieren oder im Problemfall eine gezielte Fehlersuche durchführen.

2. Netzwerk-Konfiguration

In der Regel stellt das jeweilige Betriebssystem Prozeduren oder Menus zur Konfiguration der TCP/IP-Komponenten bereit. Diese sind z.B. bei den folgenden Systemen:

Trotz der unterschiedlichen Bedienoberfläche sind in der Regel vom Systemverwalter die gleichen Konfigurationsparameter zu definieren:

P a r a m e t e r	B e i s p i e l
INTERNET-Hostname (canonical name)	zam049
Aliasnamen	mueller1
Internet- (IP-) Adresse	134.94.80.8
Subnetz-Routing	yes
Netzmaske	255.255.255.0 oder FF.FF.FF.00
Broadcast-Adresse (all one)	134.94.80.255
Netzwerk-Interface	se0
Netzwerkname	JuNet
Gateway (Router im eigenen Subnetz)	zam047

Jeder Host wird im ZAM in eine Datenbank mit einer zusätzlichen, ZAM-internen Host-ID eingetragen, die ihn dort eindeutig identifiziert. Der INTERNET-Hostname ist normalerweise identisch mit dieser Host-ID und hat folgendes Format:

wobei iii die dreistellige Kurzbezeichnung der Organisationseinheit (z.B. zel..., zam..., icg...) und nnn die fortlaufende Numerierung der Rechner dieser Organisationseinheit ist. Typische JuNet-Hostnamen sind also beispielsweise zam049 oder iff002. Ausnahmen sind wegen der durch die Host-ID definierten Eindeutigkeit möglich und können aus technischen (Beispiel: zam013-b) oder organisatorischen Gründen (Beispiel: asterix) zugelassen werden.

Hat ein Rechner mehrere Interfaces in verschiedenen Netzen, so muß für jedes Interface eine eigene IP-Adresse und ein zugehöriger canonical name (z.B. "zam363" für Ethernet, "zam363-i" für FDDI) eingetragen werden (Ein Anmeldeformular pro Interface).

Wichtig ist, daß zentrale Dienste stets über ihre Aliasnamen angesprochen werden, da diese sich im Gegensatz zu den canonical names und den numerischen IP-Adressen beim Austausch eines Systems z.B. im Fehlerfalle nicht ändern !

Systeme, deren INTERNET-Hostname nicht der JuNet-Konvention entspricht, erhalten als ersten Aliasnamen zwangsläufig und aus technischen Gründen unverzichtbar die ZAM-interne Host-ID. Jeder Systemverwalter kann weitere Aliasnamen eintragen lassen, sofern diese nicht zu Mehrdeutigkeiten im Gesamtnetz führen.

nnn.nnn	die Netzwerknummer des Klasse-B-Netzes (JuNet)
sss	die Subnetznummer in JuNet (nur bei 24 bit Netzmaske)
hhh	die Hostnummer des einzelnen Rechners in seinem Subnetz (nur bei 24 bit Netzmaske = 8 bit für Hostadressen)

Alle Nummern können Werte von 1 ... 254 (hexadezimal 1 ... FE) annehmen; 0 und 255 (0, FF Hex) sind Broadcastadressen und dürfen nicht als Hostadressen benutzt werden.

Das Forschungszentrum betreibt ein international registriertes IP-Netzwerk der Klasse B mit der

d.h. alle Rechner in JuNet haben in den ersten beiden Bytes die Adresse 134.94. International ist dieses Netz in allen Internet-Gateways bekannt.

Die beiden letzten Felder bestimmen die Hostnummer, wobei bei eingeschaltetem "Subnetting" mit 8 bit Subnetz-Maske (=24 bit Netzmaske) das erste Byte als Subnetzadresse verwendet wird. Beispielsweise befindet sich der JuNet/INTERNET-Host zam049, der am JuNet/Ethernet-Backbone angeschlossen ist, im

Bei der Bearbeitung einer Anmeldung teilt das ZAM die vollständige INTERNET-Adresse und den Namen des Subnetzes mit, in dem der Host installiert wird.

Es wird empfohlen, jeden Rechner im Netz durch einen deutlich sichtbaren Aufkleber mit dieser IP-Adresse, dem Hostnamen und ggf. dem Aliasnamen zu kennzeichnen.

Anzahl Bits für das Subnetz	Netzmaske dezimal	Netzmaske Hexadezimal
8	255.255.255.0	0xFFFFFF00
9	255.255.254.0	0xFFFFFE00
10	255.255.252.0	0xFFFFFC00
11	255.255.248.0	0xFFFFF800

Es ist wichtig, daß alle JuNet-Hosts die ihnen bei der Anmeldung im ZAM zugeteilte Netzmaske verwenden. Sie wird beim Start des Kommunikationsinterfaces (Unix-Kommando "ifconfig") angegeben und findet sich normalerweise in einer der Startup-Dateien, die beim Booten des Systems durchlaufen werden.

Die jeweiligen Netzwerk-Interfaces müssen beim Booten des Rechners richtig konfiguriert werden (ifconfig-Kommando). Die Namen der Interfaces sind systemabhängig und werden häufig beim Boot-Vorgang auf der Konsole angezeigt. Das Kommando "netstat -i" zeigt bei laufendem System die vorhandenen Interfaces an. Das Kommando "ifconfig {interface}" dient zur Überprüfung der Interface-Konfiguration oder auch zur Änderung von Interface-Parametern. Wo vorhanden, sollten dafür jedoch besser die entsprechenden Werkzeuge der Systemhersteller (s.o.) eingesetzt werden. Auf PC's unter MS-Windows werden diese Einstellungen mit "Start - Einstellungen - Systemsteuerung - Netzwerk" vorgenommen.

3. Host-Tabellen

bereit. Die lokalen Tabellen /etc/hosts bzw. /etc/networks sind durch diese zu ersetzen. Enthalten die lokalen Tabellen bereits Einträge, so können diese erhalten bleiben, wenn die ZAM-Tabellen "unten angehängt" werden. Die Tabellen werden mit dem Webbrowser oder FTP vom Rechner ftp.kfa-juelich.de kopiert, auf Unix-Systemen z.B. durch:

root>	cd /etc
root>	ftp -n ftp.kfa-juelich.de

FTP>	user ftp {lokale Mailadresse}
FTP>	get hosts.FZJ
FTP>	get networks.FZJ
FTP>	quit

Als Paßwort sollte die E-Mail-Adresse des Systemverwalters auf dem lokalen System angegeben werden.

Für Unix-Systeme steht auf dem FTP-Server unter /pub/unix ein Script zam_ip_config zur Verfügung, das automatisch und periodisch die lokalen INTERNET-Tabellen unter Beibehaltung eventueller privater Einträge aktualisiert.

Wie weiter unten erläutert, sollten die lokalen Host-Tabellen zwar stets auf dem aktuellen Stand gehalten werden, sie sollten jedoch nur im Notfall benutzt werden, falls einmal aus irgendwelchen Gründen der Zugang zu allen drei BIND-Servern für JuNet gleichzeitig nicht zur Verfügung stehen sollte.

4. Routing-Einträge zu Netzen und Hosts

Das "Internet-Prinzip" besagt, daß verschiedene IP-Netze oder auch IP-Subnetze durch Gateways (= IP-Router) miteinander verbunden sind. Beim Start eines Netzwerk-Interfaces wird automatisch der eigene Rechner als Gateway zum angeschlossenen Subnetz eingetragen, so daß mit allen Rechnern im gleichen Subnetz direkt kommuniziert werden kann.

Datenpakete an Rechner in fremden Netzen müssen jedoch zu demjenigen Gateway geschickt werden, das die Verbindung zwischen dem eigenen Netz und den Zielnetzen herstellt. Die Kommunikation zu allen nicht-lokalen Netzen, Subnetzen oder Rechnern (Hosts) erfordert also die explizite Angabe eines oder mehrerer Gateways (Router), über die diese Netze oder Rechner zu erreichen sind. Ständig benutzte Routes sollten beim Booten des Systems aktiviert werden, d.h. die entsprechenden Route-Kommandos sollten auf Unix-Systemen z.B. in der Datei /etc/rc.local oder in entsprechenden Initialisierungsdateien für den Systemstart eingetragen werden.

Auf einem Unix-System im Subnetz 134.94.80 (ein Teilnetz im JuNet/Ethernet-Backbone) z.B. definiert das Kommando

root> /..../route add -net JuNetFDDI zam047 [-hopcount 1]
oder
root> /..../route add -net 134.94.100 zam047 [-hopcount 1]

einen Weg (Route) zu allen Rechnern im FZJ-FDDI-backbone (134.94.100), in dem sich die meisten im ZAM betriebenen Server befinden, über das Gateway zam047 (=134.94.80.1), d.h. den zentralen Router im ZAM.

Wichtig ist, daß als Gatewayadresse stets die Adresse oder der Name des Gateways im eigenen Netz eingetragen wird (im Beispiel zam047). Diese Gatewayadresse findet sich auch noch einamal explizit im Auszug der JuNet-Datenbank, der nach Anmeldung eines Rechners im ZAM dem Systemadministrator per E-Mail zugeht. Entsprechend werden also die Routes zu den anderen zentralen Servern des ZAM bzw. zu Netzen außerhalb des Forschungszentrums mit

Es sind grundsätzlich nur Netze und Hosts zu erreichen, für die ein lokaler Routing-Eintrag existiert (überprüfen mit "netstat -r"). Umgekehrt kann ein lokaler Host auch nur dann von außerhalb erreicht werden, wenn eine Route z.B. zum Gateway für externe Netze existiert. Möchte man aus allen externen Netzen erreichbar sein und umgekehrt auch alle externen Netze über diesen Router erreichen, so muß eine sog. Default-Route

eingetragen werden. Weitere, bereits vorhandene Routes werden hiervon nicht beeinflußt. Wer Bedenken mit der Sicherheit seines lokalen Systems im Netz hat, sollte nur Routes zu den Hosts oder Netzen eintragen, mit denen Kommunikation gewünscht wird (also keine Default-Route).

Da im JuNet keine Routing-Protokolle für den automatischen Eintrag von Routes unterstützt werden, sollten eventuell laufende Route-Daemons ("routed") auf Unix-Workstations abgeschaltet bzw. erst gar nicht gestartet werden (Siehe weiter unten).

5. JuNet-Nameserver (BIND)

Insbesondere für weltweite E-Mail, aber auch für den Zugang zu manchen Servern ist es erforderlich, daß der eigene Rechner in der BIND-Tabelle des Servers zam048 eingetragen ist, da er sonst nicht mit seinem Namen adressiert werden kann. Dieser Eintrag erfolgt automatisch bei Anmeldung des Rechners im ZAM.

Der BIND-Service bewerkstelligt die automatische Übersetzung eines Internet-Hostnamens (z.B. pcsrv.zam.kfa-juelich.de) in seine entsprechende numerische Hostadresse (z.B. 134.94.80.84) bzw. umgekehrt (reverse BIND). Die meisten Systeme können so konfiguriert werden, daß zunächst eine Namensumsetzung in die Internet-Adresse eines Hosts über diesen BIND-Service versucht wird. Funktioniert dies nicht, kann alternativ auch die lokale Hosts-Tabelle benutzt werden. Die Adressauflösung über BIND ist im allgemeinen schneller , außerdem wird die Datenbank der Name-Server vom ZAM stets auf dem aktuellen Stand gehalten. Wegen der Wichtigkeit dieses Dienstes steht dieser transparent für den Benutzer auf drei Rechnern innerhalb des Forschungszentrums zur Verfügung.

Die Reihenfolge, in der BIND-Server (DNS) und lokale Hosts-Tabellen durchsucht werden, wird durch die Datei /etc/svc.conf (Digital Unix)

hosts=bind,local

hosts: dns files

festgelegt. Die Adressen der für die Organisation zuständigen Nameserver (davon gibt es aus Backup-Gründen immer mehrere) stehen in

Diese Dateien sollten für einen Rechner in der Organisationseinheit (= lokale Internet-Domain) iff beispielsweise folgende Einträge enthalten:

domain          iff.kfa-juelich.de
nameserver      134.94.80.2
nameserver      134.94.80.3
nameserver      134.94.100.7
search          iff.kfa-juelich.de kfa-juelich.de fz-juelich.de
options         ndots:2

Man kann, z.B. auf PC's, die Benutzung des BIND-Service auch durch Verwendung "voll qualifizierter Namen" wie z.B. pcsrv.kfa-juelich.de statt einfach "pcsrv" erzwingen. Es ist wichtig, daß für E-Mail stets voll qualifizierte Namen benutzt werden !

6. Adressierung von Netzdiensten über Aliasnamen

Für den Fall, daß auf Grund von Netzproblemen einer der zentralen Server im ZAM nicht mehr erreicht werden kann, existieren für diese Server alternative Netzzugänge, auf die durch das JuNet-Operating umgeschaltet werden kann. Ebenso kann ein Server z.B. bei Ersatz durch eine leistungsfähigere Maschine seine Internet-Adresse jederzeit ändern. Deshalb ist es wichtig, daß zur Adressierung solcher Server nur die in den Beschreibungen der Netzdienste publizierten Aliasnamen (Netservice-Namen) benutzt werden, so daß die Umschaltung für den Benutzer praktisch transparent bleibt.

Die IP-Domäne aller FZJ-internen Rechner ist "kfa-juelich.de". Wegen der öffentlichen Sichtbarkeit der E-Mail und Web-Dienste wurden diese in einer weiteren Domäne "fz-juelich.de" eingerichtet. Es sind dies:

www.fz-juelich.de	Der offizielle Webserver der Forschungszentrum Jülich GmbH
popsrv.fz-juelich.de	Der POP3-Server für E-Mail
impsrv.fz-juelich.de	Der IMAP-Server für E-Mail
mailrelay.fz-juelich.de	Der Mailserver für ausgehende E-Mail

7. Weitere Konfigurationsempfehlungen, Sicherheit

Ergänzend zu den Handbüchern der Hersteller (Installation und Security-Guides) und den Installationsempfehlungen des ZAM zu den in JuNet unterstützten Betriebssystemen hier noch einige, für Unix-Betriebssysteme allgemein gültige Konfigurationsempfehlungen:

7.1 Internet Daemons

bestimmt beim Booten des Systems, welche Netzdienste als Server (Daemons) auf einem Unix-System aktiviert werden. Unerwünschte Dienste werden in dieser Konfigurationsdatei durch Editieren mit einem Kommentar-Zeichen " #" deaktiviert. Detailliertes Logging der durch inetd.conf aktivierten Dienste und die Möglichkeit zu einer IP-basierten Zugangskontrolle bietet für Unix-Systeme der TCP-Wrapper, siehe

gestartet werden, so daß auch diese Dateien unter Umständen modifiziert werden müssen.

Für Remote Boot bzw. plattenlose Systeme (Diskless Clients) wird häufig TFTP und BOOTP benutzt. In diesem Fall müssen die Zeilen mit

aktiviert werden. Vorsicht ist geboten, wenn diese Dienste so eingerichtet sind, daß jedermann Schreibrechte auf ihre Root-Directories erhält. In diesem Falle die Zugriffsrechte der Directories unmittelbar nach Beenden des Transfers zurücksetzen bzw. die Dienste selbst abschalten.

Aus Sicherheitsgründen und zur Vermeidung unnötiger Systembelastung wird empfohlen, (falls vorhanden) die Daemons

nicht angelegt bzw. unmittelbar nach (vielleicht vermeidlicher) Benutzung wieder gelöscht werden, um unauthorisierten Zugriff durch "Masquerading" insbesondere zu privilegierten UserID's zu vermeiden.(Keine "trusted hosts" in offenen Netzen !). Automatisch löschen kann man diese Dateien beispielsweise durch einen Crontab-Eintrag

Entsprechende Hinweise wie für Unix gelten auch für PC's unter Windows (NT oder Win95): Auch hier sollte man nicht benötigte Protokolle und Server (z.B. NETBEUI oder den "Personal Web-Server") abschalten und darauf achten, daß nicht unbemerkt oder ungewollt Dateiordner freigegeben werden (Überprüfen mit dem Netzwerk-Monitor "NETWATCH.EXE"). Für Konfigurationshinweise zur PC-Sicherheit einschließlich der Verwendung eines persönlichen Firewalls siehe

Für eine sichere Benutzerauthentisierung und einen abhörsicheren, interaktiven Zugang zu Unix-Rechnern über das Netz empfiehlt sich die Verwendung der "Secure Shell" SSH, die es auch erlaubt, Anwendungen wie REXEC, FTP oder X-Window abhörsicher über einen verschlüsselten "Tunnel" zu transportieren . Nähere Hinweise enthält die

7.2 IP-Routing

für Systeme im JuNet/INTERNET abgeschaltet werden (üblicherweise in den Startup-Dateien). Dies vor allem, wenn Verbindung nur zu bestimmen Hosts und Netzen gewünscht wird. Der Daemon trägt sonst alle ihm von (meist falsch konfigurierten) Workstations mitgeteilten Routes automatisch ein. Ob der Daemon läuft, kann leicht mit "ps -ef | grep routed" überprüft werden.

7.3 Interaktiver Zugang über Terminals und Netze

definieren mit ihren Einträgen die Zugangsmöglichkeiten zum System über virtuelle, direkt oder über Modems angeschlossene Terminals. Ein Eintrag "secure" bedeutet, daß über dieses Gerät privilegierter Zugang zur User-ID ROOT möglich ist. Aus Sicherheitsgründen empfiehlt es sich, nur den Zugang zur Konsole ("console") als secure einzutragen. Ein normales Login und anschließendes "su" nach root erlaubt dann auch privilegierten Zugang, wird aber wenigstens in "sulog" protokolliert.

In diesem Zusammenhang wird auch dringend empfohlen, keine anonymen User-Accounts (d.h. durch mehrere Personen gemeinsam genutzte Accounts wie z.B. "guest") einzurichten und Logging bzw. Accounting nicht völlig abzuschalten.

Die häufigste Einbruchsursache in Fremdsysteme ist noch immer die Wahl "schlechter" oder nicht vertraulich gehaltener Paßwörter. Gute Paßwörter sollten lang sein, möglichst Sonderzeichen und keine allgemein oder im eigenen Arbeitsumfeld gängigen Begriffe enthalten. Siehe hierzu auch

7.4 Interaktiver Zugang mit X-Window (X11)

Für den Aufbau einer X11-Verbindung muß dem X11-Clienten (d.h. der Anwendung, die auf einem entfernten Rechner ausgeführt werden soll) Zugangsrechte auf dem X11-Server (lokales X-Terminal oder Workstation) eingeräumt werden. Jeder Rechner, dem mit dem Kommando

dieser Zugang erlaubt wurde, ist in der Lage, den gesamten X11-Datenverkehr zu diesem X11-Server (Terminal) mitzuschneiden und auf den eigenen Bildschirm zu kopieren !

Deshalb sollte auf keinen Fall ein genereller Zugang zum eigenen X-Server ("xhost +") erlaubt werden, und es wird empfohlen, statt der xhost-Authorisierung die

mit "MIT magic cookies" zu benutzen und den xhost-Zugang generell abzuschalten ("xhost -"). Weitere Informationen in der

Besser noch ist die komplette Verschlüsselung des X-Window-Verkehrs über SSH, die auch von PC's mit einem entsprechenden SSH-Clienten (z.B. F-Secure von Data Fellows) benutzt werden kann. Siehe hierzu die

7.5 Booten in den Single-User Mode

Viele Unix-Systeme können durch Hard-Reboot in den privilegierten Single User Mode gebracht werden. Es wird empfohlen, sensitive Systeme und Backup-Medien (Boot-Tapes) unter Verschluß zu halten und, soweit vorhanden, Konsolschlüssel (AIX-6000) bzw. Konsolpaßwörter (DEC, SUN) zu benutzen.

7.6 Benutzer-spezifisches Login-File

Um Verwechslungen bei der Arbeit auf mehreren Systemen im Netz zu vermeiden wird empfohlen, den Login-Prompt in .login (cshell) bzw. .profile (bshell, kshell) auf

Zur Vermeidung von weltweitem Lese-Zugriff auf alle neu angelegten, privaten Dateien sollte

gesetzt werden ( Ausnahme ROOT). Wer auch für Angehörige seiner eigenen Gruppe (siehe Kommando "id") oder der Default-Benutzergruppe den Lesezugriff erlauben möchte, kann statt dessen umask=027 als Default wählen.

Zur Sicherheit sollte man die Login-Profiles auch auf Path-Definitionen der Form

überprüfen und sicherstellen, daß das eigene, benutzerspezifische Arbeitsverzeichnis ( ".") nicht vor den wichtigen System-Directories im Suchpfad eingetragen ist. Dies gilt vor allem für den Systemadministrator "root", der am besten auf den Punkt im Pfad völlig verzichten sollte.

7.7 E-Mail und PGP

Elektronisch im Internet versandte Mitteilungen (E-Mails) durchlaufen nicht vorherbestimmbare Wege zu ihrem Empfänger. Sie können entweder während des Transports oder auf einem der auf dem Weg befindlichen Netzknoten ("Store-and-Forward"-Prinzip) durch unbefugte Personen eingesehen werden.

Sicherheit bietet hier nur eine "gute" Verschlüsselung z.B. mit dem Programm PGP (Pretty Good Privacy). Da ein beliebiger Absender einer E-Mail leicht vorgetäuscht werden kann, bietet PGP auch gleichzeitig die notwendigen Hilfsmittel zur Erstellung und Überprüfung elektronischer Unterschriften. Das vom ZAM unterstützte "Z-Mail" (ZAM-TKI-0258) unterstützt PGP beim Versenden und Lesen von Nachrichten. Die PGP-Programme und Beispiele für Anwendungen finden sich unter

Selbstverständlich kann PGP auch lokal zur Verschlüsselung beliebiger Dateien eingesetzt werden, die damit sicher vor unbefugtem Zugriff z.B. bei versehentlich falsch gesetzten Zugriffsrechten geschützt sind (siehe ZAM-TKI-0337).

Wer häufig sog. SPAM-Mail, d.h. unerwünschte Mails von dubiosen Internet-Anbietern erhält, sollte diese ungelesen löschen. Auf keinen Fall sollte man Aufforderungen wie "please reply with Subject delete to avoid further mail" nachkommen (dies wird häufig von Spam'mern zur Verifizierung der Mailadresse benutzt) oder gar versuchen, den Spammer selbst mit Mail "zuzuschütten". Letzteres kann dazu führen, daß als Racheakt die eigene Mailadresse benutzt wird, um Mail übelsten Inhalts weltweit ins Internet zu verschicken.

Vorsicht auch beim Lesen makrofähiger Dokumente oder Attachments (beispielsweise alle MS-Office-Dokumente auf PC's). Solche Dokumente sollten nicht ungeprüft (Viren-Scanner) angezeigt oder abgelegt werden.

Weitere Hinweise zur System-Konfiguration finden sich in den System- oder Dienst-spezifischen ZAM-TKI's zum Thema JuNet/INTERNET sowie in den systemspezifischen Installationsanleitungen (Siehe Liste der technischen Kurzinformationen ZAM-TKI-0000 und Handbücher http://www.kfa-juelich.de/zam/docs/bhb/bhb_d.html).