☰

Gibt es noch einen Grund, warum die Bindung an Port < 1024 auf Unix-Systemen nur für Root autorisiert ist?

tag-icon • tag-icon security unix ip socket
Gibt es noch einen Grund, warum die Bindung an Port < 1024 auf Unix-Systemen nur für Root autorisiert ist?

Auf Unix-Systemen wird die Bindung an TCP-Port < 1024 von einem Prozess ohne Root-Berechtigungen verweigert.

Was war der ursprüngliche Grund und ist dieser noch gültig?

Beispielsweise benötigt ein HTTP-Server keine Root-Berechtigungen, um HTML-Seiten bereitzustellen.

Welchen Prozess/welches Protokoll benötigt ein Unix-Benutzer, um sicherzugehen, dass es mit Root-Rechten ausgeführt wird?

Danke

Antwort1

Dieser Portbereich sollte nicht vom Programmierer definiert werden.
Er istreserviert durch IANA,

Die bekannten Ports sind jene von 0 bis 1023.

DCCP Well Known Ports sollten NICHT ohne IANA-Registrierung verwendet werden. Das Registrierungsverfahren ist in [RFC4340], Abschnitt 19.9 definiert.

Für abweichende Meinungen überprüfen Sie,

  1. Von einemThread zu Linuxfragen(weitere Informationen finden Sie unter dem Link)

    Die Beschränkung auf Port 1024 ist eigentlich ein Problem. Sie erzwingt eine Daemon-Praxis, die Sicherheitslücken öffnen kann, die die Beschränkung als Sicherheitsmaßnahme unwirksam machen.

    • DerSANS Top-20-SchwachstellenAnmerkungen

      Mehrere der zentralen Systemdienste bieten Remoteschnittstellen zu Clientkomponenten über Remote Procedure Calls (RPC). Sie werden meist über Named Pipe-Endpunkte bereitgestellt, die über das CIFS-Protokoll (Common Internet File System), bekannte TCP/UDP-Ports und in bestimmten Fällen temporäre TCP/UDP-Ports zugänglich sind. In der Vergangenheit gab es viele Schwachstellen in Diensten, die von anonymen Benutzern ausgenutzt werden konnten. Wenn diese Schwachstellen ausgenutzt werden, gewähren sie dem Angreifer dieselben Berechtigungen, die der Dienst auf dem Host hatte.

Heutzutage werden Protokolle wieBitTorrentUndSkypesind über temporäre Ports in den nicht reservierten Bereich umgezogen und kümmern sich nicht um Root-Zugriff. Das Ziel istnicht nur die Umgehung dieser alten reservierten Portsicherheit; Die heutigen Protokolle wollenUmgehen Sie sogar den Netzwerkperipheriebereich(Skype ist ein gutes Beispiel dafür). Die Dinge werden noch weiter gehen, wenn die Netzwerkbandbreite und -verfügbarkeit zunimmt, wenn jeder Computerbenutzer wahrscheinlicheinen Webserver selbst betreiben-- UndVielleicht,unwissentlich, SeiTeil eines Botnetz.

Wir benötigen die von diesen alten Methoden gewünschte Sicherheit,
müssen dies jedoch nun mit neueren Mitteln erreichen.

Antwort2

Nun, soweit ich mich erinnere, war die ursprüngliche Überlegung aus der Zeit von BSD Unix, dass Ports < 1024 für „bekannte Dienste“ reserviert sein sollten, und man ging immer noch davon aus, dass Server relativ selten sein würden und dass Leute mit Root-Rechten in gewisser Weise als „vertrauenswürdig“ gelten würden. Man musste also die Berechtigung haben, einen Socket so zu binden, dass er auf einem Port lauscht, der einen Netzwerkdienst darstellt, auf den andere Benutzer zugreifen würden.

Die Ports 1024-4999 sollten als „flüchtige“ Ports verwendet werden, die die Clientseite einer TCP-Verbindung darstellen. Die Ports 5000+ waren für Nicht-Root-Server vorgesehen.

Offensichtlich waren all diese Annahmen ziemlich schnell über Bord geworfen worden. Überprüfen Sie die IANA-TCP-Portnummernreservierungsliste, um zu sehen, wie hoch die Werte gestiegen sind.

Eine Lösung für dieses Problem war die Idee des RPC-Portmappers. Anstatt für jeden Dienst einen TCP-Port zu reservieren, startete der Dienst auf einem zufälligen Port und teilte dem Portmapper-Daemon mit, wo er lauschte. Clients fragten den Portmapper: „Wo lauscht Dienst X?“ und machten von dort aus weiter. Ich kann mich nicht erinnern, welche Sicherheitsmechanismen vorhanden waren, um bekannte RPC-Dienste vor Identitätsbetrug zu schützen.

Ich bin mir nicht sicher, ob es dafür heutzutage einen guten Grund gibt, aber wie in den meisten Teilen der *nix-Welt neigen die Dinge dazu, sich anzuhäufen, anstatt völlig neu erfunden zu werden.

Hat jemand Vernor Vinge gelesen? Ich erinnere mich, dass er in einem seiner Romane von einem Computersystem in der fernen Zukunft schrieb, das viele Schichten von Code aus der Vergangenheit enthielt, wobei die Zeit immer noch durch die Anzahl der Sekunden seit einem alten Datum (genauer gesagt dem 1.1.1970) dargestellt wurde. Wahrscheinlich liegt er damit nicht ganz falsch.

Antwort3

Früher haben sich normale Benutzer bei Unix-Rechnern angemeldet. Sie möchten also nicht, dass ein durchschnittlicher Benutzer einen gefälschten FTP-Dienst oder etwas Ähnliches einrichtet.

Heutzutage ist es in der Regel so, dass nur der Administrator und einige andere vertrauenswürdige Personen über Anmeldeinformationen für einen Server verfügen. Würde das Modell heute überarbeitet, wäre die Einschränkung < 1024 möglicherweise nicht vorhanden.

Antwort4

Es ist sinnvoll, dass Dienste, die Systemkennwörter akzeptieren, auf privilegierten Ports ausgeführt werden. Dies bedeutet, dass Benutzer mit Shell-Konten keine „gefälschten“ Dienste auf demselben Port einrichten können, um die Anmeldedaten anderer Benutzer abzufangen, oder den Zugriff verweigern können, indem sie auf denselben Ports nicht funktionsfähige Dienste einrichten.

Wenn Sie eine Multiuser-Box hätten und ein nicht privilegierter Benutzer einen Rogue-SSH-Daemon einrichten könnte, könnte er die Passwörter anderer Benutzer abfangen und auf deren Konten zugreifen (natürlich müsste er das tun, während der legitime SSH-Daemon ausgefallen ist, vielleicht wegen Wartungsarbeiten oder während des Systemstarts bzw. -herunterfahrens).

Dinge, die keine Systemkennwörter akzeptieren, spielen keine so große Rolle, obwohl es große Sicherheitsprobleme gibt, wenn Dinge wie Webserver von mehreren Benutzern auf einer Mehrbenutzer-Box gemeinsam genutzt werden (wie Shared-Hosting-Anbieter festgestellt haben).

verwandte Informationen