Sicherheit im Rechnernetz DESY Zeuthen
Eine Anleitung für den Nutzer

1. Aktuelle Situation der System- und Netzwerkadministratoren

Die Hacker"profis" stellen immer ausgefeiltere Methoden zur Verfügung:

1.4 Integrität und Vertraulichkeit im Internet

1.5 Sicherheitsrisiken

• Organisatorische Mängel
• Menschliche Fehlhandlungen
• Technisches Versagen
• Höhere Gewalt

2. Statistik von Sicherheitsvorfällen im DESY Zeuthen

Im Dezember 1997 bemerkten wir lange unentdeckt gebliebene Häckeraktivitäten auf einem wenig administrierten Rechner. In den letzten Jahren wurden zahlreiche Sicherheitsmaßnahmen realisiert, z.B. TCP Wrapper, Login von Remoterechnern nur über SecureShell oder Einmalpaßwörter, Installation eines zentralen Loghosts und Auswertung der Logfiles. Wer zu diesem Thema mehr wissen möchte, kann sich an security@ifh.de wenden.
Seit Dezember 1997 bemerkten wir keinen weiteren Hackereinbruch.

Sicherheitsvorfälle:

Portscans: sendmail, popper, imap, telnet, ftp, ssh !
die zum Teil einzelne Maschinen, aber auch die ganze Domäne ifh.de betrafen.

DESY Zeuthen ist nicht isoliert. In der HEP Gemeinde sind nicht überall die gleichen Sicherheitsmaßnahmen realisiert. Zum Teil arbeiten Benutzer, die auch einen Account in Zeuthen haben, auf nicht zentral oder gar nicht administrierten Rechnern. Hackern kann der Zugang zu DESY Zeuthen ermöglicht werden.

Nach einem Hackereinbruch in einem anderem LAB werden meist Sniffer installiert, die die Paßwörter abgehören.
Ist einer dieser gesnifften Accounts durch einen Benutzer getrustet zu einem Account in ifh.de ist für den Hacker auch der Zugang zu ifh.de gesichert. Die Hacker wissen auch, daß die Benutzer oft die gleichen Paßwörter in verschiedenen LABs benutzen. So hangeln sich die Hacker zu einem Rechner des anderen LABs.

Die Hacker suchen wiederum auf diesem Rechner nach Sicherheitslücken. Die Administratoren versuchen, die Rechner auf dem neuesten Patchstand zu halten, aber es gibt Situationen, wo ein Rootzugang nicht verhindert werden kann (z.B. vom Hersteller kann noch kein Patch zur Verfügung gestellt werden).

Files können modifiziert oder gelöscht werden. Informationen können mißbraucht werden. Der Account kann mißbraucht werden für Attacken gegen andere Einrichtungen. Damit wird der Ruf von DESY geschädigt.

3.2.1. Gute Paßwörter

• nur dem Accountinhaber bekannt sein
• nie im Klartext in einem File oder Programm oder auf einem Zettel am Terminal erscheinen
• zwar leicht zu merken sein, aber nicht leicht zu erraten
• nicht in Wörterbüchern stehen
• zusammengesetzt sein aus Zahlen, Sonderzeichen,Groß- und Kleinbuchstaben
• möglichst lang sein: 6 - 8 Zeichen lang
• kein CTRL, #, @, \ enthalten

3.2.2. Keine abhörbaren Paßwörter übertragen, abhörsichere Verbindungen aufbauen

man ssh: "encrypted communications between two untrusted hosts over an insecure network"

Die Einbindung von xscreensaver als X11 Client in die HEPiX X11 Umgebung erfolgt beim fvwm2 (Standard Windowmanager in DESY Zeuthen) wie folgt:

editieren Sie das File ~/.hepix/xclients
und fügen Sie folgende Zeile hinzu:

/usr/local/bin/X11/xscreensaver -lock-mode &

/usr/local/bin/X11/xscreensaver-command -lock

#and now your own User-menu
AddToMenu UserPopup "User menu" Title
...
+ "Loc\&k Screen\%small.lock.xpm\%" \
Exec /usr/local/bin/X11/xscreensaver-command -lock
...


Nach der jetzt installierten Authentisierungmethode erhält der Benutzer ein Kerberos Ticket und ein AFS Token, das der Benutzer benötigt, um sich gegenüber AFS zu authentisieren, damit er also Zugriffsrechte für sein AFS Homedirectory erhält. Zwar haben die Benutzer nur auf Linux standardmäßig das AFS Homedirectory als Homedirectory, aber auch bei den anderen UNIX Rechnern wird das AFS Homedirectory in Zukunft eingeführt und ist jetzt schon erreichbar.

Hilfsprogramme:

tokens	(Links auf /usr/afsws/bin/tokens.krb) dient zur Kontrolle von Existenz und Lebensdauer von Kerberos Ticket und AFS Token, Gültigkeit von 25 Stunden (Standard im CERN und DESY)
tklife	warnt eine Stunde vor Ablauf, ist in den Shellprofiles eingebaut.

Warum wird keine automatische Verlängerung angestrebt?

• Diese wäre nicht im Sinne des Erfinders.
• Tickets/Tokens könnten mißbraucht werden.
• Passwörter nicht im Klartext abspeichern.

Wozu brauche ich Tokens/Tickets

• für den Zugriff auf die AFS Homedirectories
  Auf den Linux Rechnern sind die AFS Homedirectories Standard.
• in pine (mit Kerberos Authentisierung) für den Zugang auf den Mailserver
  Bitte vor Aufruf mit tokens überprüfen, ob ein Kerberos Ticket vorhanden ist.
  Es ist ein Unterschied, ob man sich vorher ein Ticket besorgt, oder ob es beim Verbindungsaufbau zum imap-Server im Klartext übers Netz übertragen wird!

Wann bekomme ich ein neues Token/Ticket?

• beim Einloggen über X11 (XDM) (außer Digital UNIX, SunOS4)
• beim Einloggen über telnet, ftp und rsh (außer Digital UNIX)
  nur innerhalb ifh.de zulässig und NICHT empfohlen, da Paßwörter im Klartext übertragen werden
• beim Einloggen über ssh/xssh/xrsh (DESY Zeuthen spez.) wenn eine Paßwortauthentisierung erfolgt, d.h. die Rhost-RSA Methode nicht verwendet wird
• durch Ticket-/Tokenforwarding durch ssh/xssh/xrsh (DESY Zeuthen spez.)
• durch Reaktivierung der Session, die durch xscreensaver geschützt ist
  Ein neues Token/Ticket erhält man aber nur auf dem Loginrechner.
  Es gibt noch kein Kommando, um überall die Tokens/Tickets zu verlängern

Wie besorge ich mir neue Tokens/Tickets, wenn sie abgelaufen sind ?

mit klog ( -> /usr/afsws/bin/klog.krb)

(/usr/afsws/bin/klog erzeugt nur AFS Token)

UNIX Filesystem: Zugriffsrechte für Files und Directories

Rechte für User/Group/Other	read/write/execute
chmod	Änderung der Rechte
umask	entscheidund für neue Files/Directories

Sicherheitsrelevante Files:

.netrc, .rhosts	in Nutzerverantwortung
.Xauthority	X11 Authentisierung mit xauth
Login profiles
Startupfiles und Konfigurationsfiles der Applikationen .pinerc, .emacs, ...
Directories: .ssh, .ssl, .pgp, ...	werden automatisch von den entsprechenden Applikationen und bei Einrichtung des Accounts richtig angelegt

AFS Filesystem: Zugriffsrechte NUR für Directories

-> zu schützende Files müssen in entsprechend gesicherte Directories

von den UNIX Zugriffsrechten hat nur noch das x-Bit (Execute) des Eigentümers Bedeutung.
! Alle anderen Rechte werden durch ACLs festgelegt.

Die Zugriffsrechte werden auf Subdirectories beim Erzeugen vererbt, aber nicht bei Änderung der ACLs in den darüberliegenden Directories.

3.2.6. X11 Security beachten

Die ssh bietet die Möglichkeit des X11 Tunneling, so daß der gesamte X11 Traffic verschlüsselt wird. Ist X11-Forwarding eingeschaltet, kann der Benutzer auf dem Zielrechner X11 Applikationen starten, ohne sich um X11 Authentisierung zu kümmern. Die DISPLAY Variable wird generiert von der ssh und zeigt auf den Zielrechner. Die ssh erzeugt einen Proxy Xserver, verwendet dabei einen Zufallsauthorisierungskey. Der richtige Authorisierungskey wird nicht im Netzwerk verwendet.

ssh -f host xterm	xterm wird nach Authentisierung (wenn notwendig in der Shell) im Hintergrund gestartet
ssh -n host emacs	Applikation wird im Hintergrund gestartet, funktioniert nur, wenn keine Paßwortabfrage notwendig ist

Beispiele:

xssh machine.domain
xssh -l user machine.domain
xssh machine command


• kein pseudo-tty blockiert
• kein zusätzlicher Prozeß
• wenn Paßwortabfrage notwendig, wird kleines zusätzliches Fenster (ssh-askpass) gestartet

Zielrechner hat keine ssh

Die User basierte X11 Zugriffskontrolle ist beim XDM Login eingeschaltet. Das File .Xauthority enthält den MIT-MAGIC-COOKIE Key, der vom XDM generiert wird. Der für diesen Display erzeugte Key wird von xauth extract extrahiert und kann mit xauth merge auf dem Zielrechner eingebunden werden.

xrsh realisiert automatisch die Übertragung des Keys.

xrsh ( -> xssh in DESY Zeuthen )

xrsh -rsh -auth xauth machine.domain (DESY Zeuthen spezifisch)
(xrsh -auth xauth machine.domain MIT )

Zielrechner hat keine User basierte X11 Zugriffskontrolle

Display schützen!

Niemals xhost +	weltweite Schreib-und Leserechte
	Abhören von Paßwörtern möglich, in Hacker-Tools eingebunden

Host basierte Zugriffskontrolle:

xhost + machine.domain

wenn die Domäne nicht angegeben wird, kann jeder Host, der diesen Namen hat, die X11 Verbindung abhören

Aufruf:

xrsh -rsh -auth xhost machine.domain

xrsh mit rsh kann nur verwendet werden, wenn die DISPLAY Variable auf den Xserver zeigt und nicht durch ssh erzeugt wurde, d.h. also nicht auf den Proxy-Xserver zeigt

Achtung:

Beim Einloggen in WinCenter muß die DISPLAY Variable auf den Xserver zeigen!

3.2.7. Signieren von Mails und Verschlüsselung von Files

Weitere Informationen findet man unter:

• Code nicht von unbekannten ftp Servern Code installieren, nur authorisierte Server verwenden. Check-Summen überprüfen (MD5).
• Ausführbarer Code kann in PostScript Dateien versteckt sein. PosstScript-Viewer sind standardmässig so konfiguriert, daß sie das Ausführen von Kommandos nicht zulassen.
• Bitte beachten Sie die Hinweise zum Virenschutz.
• Websecurity
  • Webserver Securityprobleme (cgi-bin)
  • aktive Webinhalte
    vom Webserver heruntergeladener und in seinem Kontext ablaufender ausführbarer Code
    Java, ActiveX, JavaScript

3.3 Weitere Informationsquellen

Bitte achten auf:

• beim Einloggen auf ``Last login from ...''
• auf obscure File ``.. .'' oder ähnliches
• auf fehlerhafte Zugriffsrechte
• auf modifizierte Files