Re: kleine verstaendisfrage zu iptables
Hallo,
Andreas Pakulat <apaku@gmx.de>:
>> Um die .rhosts Semantik von rlogin/rsh/rcp nachbilden zu können.
>>
>> Diese besagt, dass sich User unter gleichem Benutzernamen auf der
>> Zielmaschine ohne Passwort einloggen können, wenn die Zielmaschine der
>> Quellmaschine entsprechend vertraut.
>
>Das klingt nach ssh public-key authentication und erfordert keinen
>Port < 1024 auf der Quellmaschine.
Lass mich raten: Du bist unter 25 und hast noch nie auf einem System
ohne SSH mit rlogin, rsh und rcp gearbeitet?
>> Das setzt authentische
>> Informationen über den Benutzernamen auf der Quellmaschine
>> voraus. Verbindungen von Quellports >= 1024 sind dazu nicht geeignet,
>> da prinzipiell jeder Benutzer einem modifizierten rlogin Client mit
>> gefaktem Benutzernamen selber compilieren könnte.
>
>Das verstehe ich nicht so ganz, was hat ein Benutzername mit Ports zu
>tun, mal abgesehen davon dass man als Normalouser nur Ports >1024
>kriegt?
Es war einmal, in grauer Vorzeit, ein Betriebssystem namens UNIX,
welches sich in Universitäten großer Beliebtheut erfreute. Computer
waren teuer; kein Student, Assistent und auch kein Professor konnte
sich einen eigenen leisten. Also loggten sich die Benutzer auf dem
UNIX-Cluster ihrer Universität ein, verfassten ihre Diplomarbeiten,
Doktorarbeiten und Vorlesungsmanuskripte mit ed, vi, troff und TeX,
programmierten in C und sh, schrieben E-Mails mit mail und msg und
unterhielten sich über talk.
Um sich auf einem anderen Rechner im Cluster einzuloggen, gab es Telnet.
Nach Eingabe des Benutzernamens und des Passwortes konnte man auf dem
anderen Rechner weiter arbeiten. Dass das Passwort und die Nutzdaten
im Klartext übertragen wurden, störte keinen, denn das Netzwerk wurde
ohnehin von den gleichen, wenigen Personen verwaltet wie der Rechnercluster
selbst. Die Eingabe von Benutzernamen und Passwort war aber lästig, denn
die Accounts und Passwörter und Homeverzeichnisse waren sowieso überall
im Cluster die selben. Wer einmal auf einem Rechner eingeloggt war, der
hatte seine Identität bereits nachgewiesen.
Dies brachte findige Köpfe an der Universität zu Kalifornien in
Berkeley auf die Idee, ein Protokoll namens rlogin zu entwerfen, was
dieses Problem löst. Der Client überträgt beim Login den Benutzernamen
des lokalen Benutzers. Wenn die Gegenstelle der Meinung ist, dass der
Rechner des Clients zum Cluster gehört (identifiziert über die
IP-Nummer) und damit vertrauenswürdig ist, dann wird der Login auf dem
Zielrechner erlaubt, ohne dass eine erneute Authentifikation notwendig
ist.
Problematisch daran war aber, dass es Studenten gab, die, anstatt ihre
Seminararbeiten zu schreiben und auf die Prüfungen zu lernen, lieber
Programme schrieben, mit denen sich die Authentifikation von rlogin
austricksen lies. Genauer gesagt programmierten sie einen Client, der
das genaue Protokoll von rlogin sprach und damit von der Gegenseite nicht
vom echten rlogin zu unterscheiden war. Er übertrug aber anstelle des
eigenen Login-Namens den des Professors. Die Gegenseite war der Meinung,
dass der Professor auf dem Quellhost bereits eingeloggt war, und erlaubte
ein Login ohne Authentifikation auf dem Zielhost. Hier fanden die
Studenten dann die Prüfungsfragen oder modifizierten die Gutachten für
ihre Diplomarbeiten. Sie bestanden das Examen mit Auszeichnung und sind
heute Politiker, Richter, Anwälte oder Aufsichtsräte.
Da eine Volkswirtschaft sich nur eine begrenzte Anzahl Nieten in
führenden Positionen leisten kann, ohne aufzufallen, musste eine
Lösung her. So ersannen die findigen Köpfe an der Universität
Berkeley, dass der rlogin-Daemon auf dem Zielhost auch die
Quell-Portnummer des rlogin Clients als Authentifikationsmerkmal
verwenden kann. Verbindungen mit Portnummern >= 1024 können von
potenziell gefälschten rlogin Clients stammen, die einen falschen
Benutzernamen angeben. Das unverfälschte Original-rlogin, welches
vertrauenswürdig ist und immer den richtigen Benutzernamen übergibt,
wird setuid-root gesetzt und öffnet damit seine Verbindungen immer von
einer privilegierten Quellportnummer. Kein Student kann einen
gefälschten rlogin-Client selber schreiben, der auch setuid-root
läuft. Die Universitäten wurden wieder sicher und das Vertrauen in
die Dekokratie kehrte zurück.
Heute, viele Jahre nach dieser Idylle, reichen die Konzepte von
rlogin, Telnet und Verwandten schon lange nicht mehr aus. Computer
sind erschwinglich geworden; jeder Erstsemester bringt sein eigenes
Notebook mit, auf dem er beliebige TCP-Verbindungen mit beliebigem
Quellport erzeugen kann. Falls er selber nicht weiss, wie das geht,
ergoogelt er sich ein Skript, zieht es von einem IRC Bot oder shared
es in einer Tauschbörse. Merkmale wie Quellports oder auch IP-Nummern
sind nicht mehr zu Zwecken der Authentifikation geeignet. Statt dessen
gibt es Verschlüsselung, Public Key Authentifikation, Fingerprints und
Zertifizierungshierarchien, die jede theoretische Angriffsmöglichkeit
im Keim ersticken und allenfalls noch wegen ihrer ständigen
Implementierungsfehler anfällig sind. Die Administratoren haben längst
alle Vorkommen von rlogin, rsh und rcp auf ihren Systemen eliminiert
und durch SSH ersetzt.
Dennoch gibt es alternde Doktoranden und Habilitanten, die, anstelle
endlich ihre Arbeit zzum Abschluss zu bringen, eine Arbeitsumgebung
wie in den Anfängen erwarten. Daher unterstützt SSH die Semantik des
Einloggens ohne Passwort zwischen Maschinen im selben Rechnercluster
weiterhin. Natürlich unterwandert von Public Key Verschlüsselung mit
Host Keys und anderem modernen Schnickschnack, aber für den Benutzer
transparent. Nur taucht auch hier das selbe Problem von damals auf:
ein SSH Client, der von Quellports >= 1024 kommuniziert, kann
potenziell gefälscht sein; dem Usernamen, den er überträgt, kann nicht
vertraut werden. Also setzt man den systemweit zur Verfügung
gestellten Original-SSH-Client setuid-root; denn dieses Merkmal kann
kein Benutzer fälschen.
Die Zeiten haben sich geändert, und die Manpage von OpenSSH sagt dazu:
[Note to the administrator: /etc/hosts.equiv, $HOME/.rhosts, and the
rlogin/rsh protocol in general, are inherently insecure and should be
disabled if security is desired.] Dennoch, sollten die Studenten,
Assistenten, Habilitanten und Professoren von damals nicht gestorben,
emeritiert oder exmatrikuliert sein, dann leben sie noch heute, loggen
sich auf dem universitären UNIX-Cluster per rlogin ein und merken von der
Migration auf SSH genau nichts.
Gruß, Harald
--
Harald Weidner hweidner@gmx.net
Reply to: