Server - Telnet & Co. |
| Übersicht |
|
| Vorbereitungen |
|
Die Server für Telnet und die Remote Shell werden nahezu ausschließlich erst bei Bedarf durch den inetd gestartet. Überprüfen Sie vorab die Datei /etc/inetd.conf, ob die entsprechenden Einträge enthalten und freigeschaltet sind:
|
user@sonne> egrep 'telnet|rsh' /etc/inetd.conf # If you want telnetd not to "keep-alives" (e.g. if it runs over a ISDN # uplink), add "-n". See 'man telnetd' for more details. telnet stream tcp nowait root /usr/sbin/tcpd in.telnetd # man-page of rlogind and rshd to see more configuration possibilities about shell stream tcp nowait root /usr/sbin/tcpd in.rshd -L # shell stream tcp nowait root /usr/sbin/tcpd in.rshd -aL # Try "telnet localhost systat" and "telnet localhost netstat" to see that |
Entfernen Sie ggf. Kommentarzeichen vor den Einträgen oder ergänzen Sie obige Zeilen. Starten Sie nach Änderungen den inetd neu:
| root@sonne> /etc/init.d/inetd restart |
Enthält Ihre Distribution kein ähnlich lautendes Startskript, so sollten Sie den Daemon per Hand neu starten (killall inetd; /usr/sbin/inetd).
Verwenden Sie den moderneren xinetd (Voreinstellung bspw. bei RedHat), so sollte dessen Konfigurationsdatei /etc/xinetd.conf Einträge ähnlich der folgenden aufweisen:
| user@sonne> less /etc/xinetd.conf ... service telnet { socket_type = stream protocol = tcp wait = no user = root server = /usr/sbin/in.telnetd log_on_failure += RECORD log_type = SYSLOG auth warn } service shell { socket_type = stream protocol = tcp wait = no user = root server = /usr/sbin/in.rshd server_args = -aL log_on_failure += RECORD log_type = SYSLOG auth warn } ... |
Auch der xinetd ist neu zu starten, damit die Änderungen in der Konfiguration wirksam werden.
Der Ssh-Serverprozess wird i.d.R. als permanenter Dienst bereits während des Systemstarts aktiviert; eine Konfiguration zum Start durch den [x]inetd ist dennoch möglich.
Zumindest Telnet und Rsh beinhalten einige bedenkliche Mechanismen, die Sicherheitsanforderungen in kritischem Umfeld nicht genügen. Aus diesem Grund wurden zusätzliche Barrieren eingeführt, die den Zugang zu den Diensten einschränken können.
Eine der Sicherheitsvorkehrungen wäre der konsequente Einsatz des moderneren Internet-Daemons xinetd anstatt des alteingesessenen inetd. Für jeden Dienst können Sie mittels der Einträge only_from bzw. no_access explizit festlegen, von welchen Rechnern/Netzwerken aus der Zugriff gestattet ist oder von wo aus er verwehrt wird.
In vielen Distributionen wird nach wie vor am Inetd als »Verwalter der Internet-Dienste« festgehalten. Dessen fehlendes Sicherheitskonzept übernimmt der TCP-Wrapper, der den Zugriff anhand der Einträge der Dateien /etc/hosts.allow und /etc/hosts.deny verifiziert. Der Zugang zu Telnet- und Remote-Shell-Server sollte - falls Sie auf die beiden Dienste nicht verzichten können - in offenen Netzwerken stets durch den TCP-Wrapper überwacht und nur für konkrete Rechner geöffnet werden. Die beiden Dateien /etc/hosts.allow und /etc/hosts.deny sollten um folgende Einträge ergänzt werden (im Beispiel gestatten wir den Zugriff von allen Rechnern des lokalen Netzwerkes aus:
| root@sonne> vi /etc/hosts.deny # Alles pauschal verbieten ALL : ALL root@sonne> vi /etc/hosts.allow # Telnet und Rsh für Rechner des lokalen Netzwerkes öffnen; Rsh erfordert neben dem rsh-Daemon noch Zugang zum rlogin-Daemon in.telnetd : LOCAL in.rlogind : LOCAL in.rshd : LOCAL |
In aktuellen Implementierungen des Ssh-Daemons ist die Auswertung der Dateien /etc/hosts.allow und /etc/hosts.deny zumeist fest verdrahtet; Sie können das leicht mit Hilfe von strings überprüfen:
| user@sonne> strings /usr/sbin/sshd | egrep 'hosts.allow|hosts.deny' hosts_allow_table hosts_deny_table /etc/hosts.allow /etc/hosts.deny |
Erhalten Sie obige Ausgaben, so muss der Zugriff auf den Daemon ebenso durch die Einträge in den beiden Dateien möglich sein. Bspw. genügt folgende Zeile, um den Rechnern des lokalen Netzwerks den Ssh-Zugang zu gewähren:
| root@sonne> vi /etc/hosts.allow # Zugang zur Secure Shell sshd : LOCAL |
Bei weiteren Zugangsproblemen auf einen der Dienste sollten Sie ggf. die Konfiguration der betreffenden Pluggable Authentificaton Modules prüfen.
| Telnet |
|
Die Basis von Telnet (Telecommunication Network) ist so alt wie das Internet (genauer das ARPAnet) selbst, denn die Motivation zur Verbindung von Rechnern entsprang dem Wunsch, vom »lokalen« Terminal Resourcen auf entfernten Rechnern in Anspruch nehmen zu können. So verfügten die 1969 verbundenen 4 Interface Message Processors (IMP) über eine rudimentäre Lösung der Terminalverbindung, die zumindest als Anfänge der Protokollentwicklung zu Telnet gelten dürften. 1970 markierte das Network Control Protocol (NCP) einen weiteren Meilenstein, indem es erstmals die Netzwerkschicht von den Anwendungsprozessen getrennt realisierte und eine Benutzerauthentifizierung einführte.
Die Erweiterung des ARPAnets um neue Rechner zeigte deutlich die Schwächen der bisherigen Realisierung auf: das System funktionierte nur zufriedenstellend, wenn die verbundenen Rechner den gleichen Zeichensatz verwendeten. Unter anderem diese Erfahrungen spiegelten sich im RFC-97 (1971) als erstem Vorschlag des Telnet-Protokolls wider. Weitere Protokolländerungen bzw. -erweiterungen spezifizierten u.a. die RFCs 318, 328, 340, 393 (1972) und 435 (1973). Der noch heutige gültige Standard wurde erst 1983 (RFC 854) festgeschrieben.
Abbildung 1: Interne Vorgänge während einer Telnet-Sitzung
| Die r-Utilities | |
| Secure Shell |  |