PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : TCP-Wrapper ohne inetd sinnvoll?



Cerox
14.08.06, 10:36
Hallo zusammen,

da mein inetd überhaupt nicht genutzt wird und er keine Dienste überwacht, habe ich ihn abgeschaltet.

Ich habe mich gerade mal kurz in das Thema TCP-Wrapper eingelesen; normalerweise stellt er ja eine Schnittstelle zwischen dem inetd und den vom inetd gesteuerten Diensten dar. Allerdings wurde auch gesagt, dass der TCP-Wrapper ohne einen Superdaemon wie inetd eingesetzt werden könnte.

Meine Frage erstmal: Macht das überhaupt Sinn?

-> Habt ihr den inetd (xinetd o.ä. zählt auch dazu) und/oder TCP-Wrapper im Einsatz?

Ansonsten wird der Zugriff auf Serverdienste durch netfilter und Listen-Direktiven der Dienste (sofern vorhanden) gesteuert.

mbo
15.08.06, 11:24
da mein inetd überhaupt nicht genutzt wird und er keine Dienste überwacht, habe ich ihn abgeschaltet.

inetd und xinetd (sie unterscheiden sich eben doch), kommen hauptsächlich zum Einsatz, wenn der Dienst nicht als Daemon laufen soll, oder kann.



Ich habe mich gerade mal kurz in das Thema TCP-Wrapper eingelesen; normalerweise stellt er ja eine Schnittstelle zwischen dem inetd und den vom inetd gesteuerten Diensten dar. Allerdings wurde auch gesagt, dass der TCP-Wrapper ohne einen Superdaemon wie inetd eingesetzt werden könnte.

Nein, der tcp-wrapper ist keine Schnittstelle, eher ein Inhaltverbindungsstück, und er ist nicht vom x/inetd abhängig, aber eine sinnvolle Ergänzung dazu.



Meine Frage erstmal: Macht das überhaupt Sinn?

Nein, aber es könnte einen Sinn haben ...



-> Habt ihr den inetd (xinetd o.ä. zählt auch dazu) und/oder TCP-Wrapper im Einsatz?

Ja, zB im Sinne von Logindamons. Beispiel wäre ein Script, daß per xinetd gestartet wird, aber über den tcpwrapper geschützt wird. So wird festgelegt, daß zB bekannte dyndns-Hosts einen Login auf SSHD bekommen, in dem die Filterregel gesetzt wird, wenn der bekannte Host sich zB auf den Port 999 connectiert. Unbekannte Hosts werden automatisch per iptables auf DENY gesetzt. Alternativ gibt es auch Port-Knocking-Methoden.
Möglich wäre auch eine Verkettung oder zB das Login automatisch in screen umzulenken etc etc etc ...


cu/2

Cerox
15.08.06, 13:20
Hi,

danke für deine Antwort erstmal.

Mein OpenSSH-Server läuft als Dämon.


Unbekannte Hosts werden automatisch per iptables auf DENY gesetzt

Jetzt sprichst du von iptables; was hat das mit TCP-Wrapper zu tun? Ich dachte, der Wrapper wäre in der Anwendungsschicht angesiedelt und kam früher zum Einsatz, als es noch keine Paketfilter gab. Allerdings wäre er als Ergänzung natürlich auch sinnvoll, sofern im Paketfilter eine Lücke vorhanden ist und der Angreifer somit bis zur Applikation vordringt, die wiederrum durch der Wrapper geschützt wird. Mein SSHd akzeptiert nur Verbindungen von einer Adresse im LAN; dies habe ich jedoch durch iptables realisiert. Ansonsten müsste der Angreifer einen gültigen Benutzer raten, den PrivatKey stehlen und die Passphrase wissen, um sich trotzdem einloggen zu können. Von daher halte ich solch eine zusätzliche Sicherheitsschicht für den SSHd nicht für notwendig.

Eine Frage: Wird der TCP-Wrapper überhaupt noch eingesetzt (nicht vereinzelnd sondern mal auf die Masse betrachtet)? Ist er, seit dem es stateful-Paketfilter gibt, nicht etwas überflüssig geworden?

mbo
15.08.06, 13:45
Relativierend hatte ich oben ein mögliches, schon eingesetztes Szenario beschrieben. Der Hinweis mit iptables basiert auf diesem Szenario.
Beispiel:
Ich habe einen Server, der die üblichen Dienste anbietet, einige Ports, wie zB SSH aber nicht permanent anbieten soll. Erschwerend kommt hinzu, daß die Clients alle dynamische IP-Adressen nutzen. Ausgehend davon, daß ein Portknocking aufgrund der Filterregeln (zB mehr als 3 Syn in der Minuten oder mehr als 3 Ports in der Minute) nicht möglich ist, bieten sich tcp-wrapper in zwei Möglichkeiten an.
1.) über host_deny und host_allow die Clients mit DynDNS-Adressen eintragen und per vom wrapper gestartetem Script die iptables-Regeln neu laden (da iptables DynDNS-Adressen statisch einträgt.
2.) sofern keine DynDNS existiert, den Wrapper zur Authentifizierung nutzen und bei #?=0 die iptables-Regeln für SSH-Port erstellen.

Wie oben auch schon erwähnt, kann man Clientabhängig (nicht Benutzerabhängig, zB weil viele den gleichen Benutzer root nutzen sollen, aber die Revision unterjocht wird und es keine personalisierten Logins gibt) per wrapper das Login in screen schicken.

Mit entsprechendem Wissen könnte man auch eine Art Contentfilter darüber realisieren.

Gerade in "vertrauenswürdigen" Umgebungen kann man den Wrapper finden, wenn zB ein DHCP-Range mit Subdomain im DNS existiert und nur die Admin-PC zB den SSH-Port bekommen sollen, aber Paketfilter auf den System nicht eingesetzt werden sollen oder zu umständlich zu handhaben sind. Anwendungsmöglichkeiten gibt es viele und im Endeffekt ist es eine Frage der Philosophie und Paranoia und Anforderungen.
Zu bedenken ist auch, daß Dienste heutzutage sich sehr viel weiterentwickelt haben, so kann zB der SSHD letzt genanntes Szenario mittlerweile selbst händeln.


cu/2


<edit>
Für Ansätze wäre zB auch das http://www.it-academy.cc/article/490/IDS+aber+wie.html verwendbar.
</edit>

Cerox
16.08.06, 08:27
Hi,

habe gerade mal eine DnyDNS-Adresse als Source bei einer neuen Regel genommen; ich wusste nicht, dass er die DNS zuerst auflöst; ich dachte das würde er jedes mal bei neuen eingehenden Paketen machen - naja^^

Da ich nur einen Server im LAN betreibe, habe ich eine private IP-Adresse, welche Zugang zum SSH-Port bekommt. Bei einem Root-Server oder dem Homeserver eines Kollegen, auf den nur die öffentliche, dynamische IP Zugriff haben soll, wäre das schon problematisch.

Es ist natürlich paranoid, da auch so keiner über den SSH-Server reinkommt. Schließlich müsste er wie glaube ich schon gesagt, einen Benutzer wissen, einen Publickey haben und die Passphrase haben - alles sehr unwahrscheinlich.

Trotzdem interessiert mich das Thema...

Wie konfiguriere ich den OpenSSH-Server, so dass er inetd/xinetd (was wäre empfehlenswerter) nutzt?

Verschlechtert sich die Sicherheit dann nicht, da ich gelesen habe, dass inetd anfälliger für DoS Angriffe ist?

Harry
18.08.06, 11:24
Hallo,

der TCP-Wrapper wird von TCP-basierenden Serverdiensten nicht ausschließlich über den inetd/xinetd benutzt.
Je nach Distributor gibt es eine Reihe weiterer Serverdienste, die nativ gegen den TCP-Wrapper gelinkt sind und somit die Dateien /etc/hosts.allow bzw. /etc/hosts.deny auswerten, ohne dass der betroffene Dienst über den inetd/xinetd gestartet wird.

Das können z.B. sein:
- OpenSSH
- sendmail
- NFS-Server
- RPC-Portmapper
- CUPS
- und weitere

Ob der eigene Serverdienst gegen den TCP-Wrapper (libwrap.so.X) gelinkt ist, kann man mit dem Kommando

ldd <Server-Binary>
einsehen.
Steht in der Ausgabe eine Zeile mit "libwrap.so.X", dann ist das die Verlinkung auf den TCP-Wrapper.

cu
Harry

Cerox
18.08.06, 11:35
Ja, der sshd hat libwrap eingetragen. Also kann ich ja die hosts.deny und hosts.allow trotzdem verwenden; vielen Dank.