Re: inetd vs. standalone

Martin Kropfinger wrote:
> Und zwar nutzt FreeBSD wohl gerne den inetd so wie ich die Sache sehe.
> In den letzten Jahren in denen ich hin und wieder unter Linux
> unterwegs war ist mir aufgefallen, dass zunehmend auf Standalone-
> Server gegangen wurde und der inetd kaum noch Verwendung findet.
> Zumindest ist das so mein subjektives Empfinden.

Genau das Gegenteil ist der Fall, wie Christian schon schrieb.

Früher (bevor es Linux gab) wurde der inetd recht gern
verwendet und war auch per Default eingeschaltet. Da
wurden der nntpd, ftpd und diverse andere Dinge per inetd
gestartet.

Einige "klassische" Server-Programme aus dem Basis-System
können übrigens auch heute noch ausschließlich per inetd
gestartet werden (fingerd, talkd, tftpd, ...). Die sind
so simpel gestrickt, dass sie keinen selbständigen Server-
Code enthalten.

Die Verwendung des inetd hat dann aber nachgelassen, bei
(Free)BSD sogar noch eher als in der Linux-Welt, wo sich
der xinetd lange Zeit einer gewissen Beliebtheit erfreute,
und es teilweise immer noch tut. Mir kommen beruflich
öfters mal Linux-Rechner unter die Finger, wo zum Beispiel
der identd per xinetd gestartet wird. Über die Gründe kann
ich nur spekulieren ... Vielleicht ist es einfach Faulheit
(man spart sich ein separates Start-/Stop-Skript).

Bei FreeBSD dagegen wird der inetd kaum noch verwendet;
er ist seit geraumer Zeit per Default disabled, und in
der inetd.conf ist alles auskommentiert.

> Ich frage mich nur was sind die Vor- und Nachteile der beiden Varianten.

In früheren Zeiten, als die Rechner noch wenig RAM hatten,
als die Shared-Libraries und Memory-Overcommit noch nicht
erfunden waren, und als die Verbindungsaufnahmen häufig
eher pro Stunde als pro Sekunde gemessen wurden, hatte der
inetd den Vorteil, dass nur ein einziger, relativ schlanker
Prozess im Speicher gehalten werden musste, der nur bei
Bedarf dann die jeweiligen Server-Prozesse startete, die
nach dem Ende der jeweiligen Verbindung wieder aus dem
Speicher entfernt wurden. Der fork/exec-Overhead fiel
damals nicht so ins Gewicht.

Heute ist die Situation gerade umgekehrt; die genannten
Voraussetzungen treffen größtenteils nicht mehr zu.

> Zusätzlich denke ich wenn der inetd angreifbar wäre durch eine Lücke
> sind damit doch alle Dienste gefährdet die hierüber initialisiert
> werden oder?

Nein, generell nicht, höchstens im Fall eines DoS-Angriffs:
Wenn der inetd selbst durch einen DoS-Angriff ausgeschaltet
oder behindert wird, dann betrifft dies selbstverständlich
alle Dienste, die über ihn gestartet werden. Moderne inetd-
Varianten bieten aber Optionen, mit denen man die Anzahl der
Verbindungsaufnahmen reglementieren kann, was erfoglreiche
DoS-Angriffe erschwert.

Wenn der inetd dagegen irgendeiner anderen Art von Angriff
(schlimmstenfalls ein Remote-Root-Exploit) ausgesetzt ist,
hat das mit den Diensten, die er startet, nichts zu tun.
Der inetd tut ja nichts weiter, als die Netzwerkverbindung
an den Server-Prozess zu vermitteln.

> Wie denkt Ihr darüber? Warum inetd?

Wie gesagt, heutzutage kommt der inet nur noch in Ausnahme-
fällen zur Anwendung. Bei mir persönlich gibt es i.allg.
drei Fälle, wo ich ihn (vorübergehend) einschalte:

1. Wenn ich mal schnell irgendwas testen möchte, kommen
mir die eingebauten echo- und discard-Dienste manchmal
gelegen. (Man kann die gleiche Funktion auch z.B. mit
netcat "basteln", aber ich finde, dass der inetd dafür
geeigneter ist.)

2. Als Developer, um mal eben schnell den Prototyp eines
Dienstes "hochzuprügeln", ohne dass man sich am Anfang
um die Verbindungsaufnahme und "Daemonifizierung" kümmern
muss.

3. Als Admin, um vorübergehend einen simplen Dienst
zu starten. Das kann sogar ein einfaches Shell-Skript
sein. Beispielsweise habe ich schon folgendes Shell-
Skript per inetd auf Port 80 laufen lassen. Es ist
natürlich kein richtiger Webserver, aber es genügt,
um Redirects auf einen anderen Server zu erzeugen:

  #!/bin/sh -
  REDIRECT="http://www.secnetix.de/"
  cat <<tac
  HTTP/1.0 302 Found
  Date: $(date -u +'%a, %d %b %Y %T GMT')
  Location: $REDIRECT
  Content-Type: text/html

  <HTML><HEAD><TITLE>302 Found</TITLE></HEAD><BODY>
  <H1>Temporary Redirect</H1>
  </BODY></HTML>
  tac

Einfach das Script als /usr/local/sbin/httpd speichern,
chmod 755 (d.h. ausführbar machen), und folgende Zeile in
/etc/inetd.conf ergänzen:

http stream tcp nowait nobody /usr/local/sbin/httpd httpd

Dann als root »/etc/rc.d/inetd onestart« eingeben, und
schon hat man mit Bordmitteln einen Webserver laufen, der
zu einem anderen Server redirected.

Es mag noch einige andere Sonderfälle geben, in denen man
inetd in Erwägung ziehen könnte. Beispielsweise hat inetd
ein paar Features, die einige Serverprogramme nicht selbst
mitbringen, sei es die Einbindung des TCP-Wrappers oder die
Optionen, mit denen man die Anzahl der Verbindungen (pro
Zeitintervall bzw. gleichzeitig) begrenzen kann. Außerdem
ermöglicht es der inetd, einen nichtprivilegierten Prozess
auf einem privolegierten Port zu starten, wie im obigen
Beispiel, wo der httpd als "nobody" auf Port 80 läuft.
(Es gibt natürlich auch hier andere Möglichkeiten, wie man
das gleiche erreichen kann, aber der inetd ist halt die
klassische Lösung, die schnell bei der Hand ist.)

Sobald Performance eine kritische Rolle spielt, scheidet
der inetd allerdings aus. Ein Server-Prozess, der permanent
läuft, selbst die Verbindungen annimmt und ggf. Pre-fork
oder Threading verwendet, gewinnt dann haushoch.

> Hiermit erkläre ich schriftlich und rechtswirksam, dass alle in dieser
> E-Mail genannten personenbezogenen Daten ausschliesslich zur Klärung
> [...]

Du glaubst doch nicht ernsthaft, dass das irgendeinen Spammer
interessiert?

> - Traurig, dass solche Hinweise in der heutigen Zeit Erwähnung finden
> müssen, nicht wahr? -

Wieso "müssen"? Das ist komplett überflüssig und unwirksam.

Gruß
   Olli

-- 
Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M.
Handelsregister: Registergericht Muenchen, HRA 74606,  Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün-
chen, HRB 125758,  Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart
FreeBSD-Dienstleistungen, -Produkte und mehr:  http://www.secnetix.de/bsd
"That's what I love about GUIs: They make simple tasks easier,
and complex tasks impossible."
        -- John William Chambless
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message