TCP-Wrapper und SSH

[Firew]

Hallo

Wieß jemand von euch, ob ich SSH mittel hosts.allow frei geben kann, wenn ich in hosts.deny ALL:ALL eingetragen habe? Ist es überhaupt möglich Ports mit den TCP-Wrapper frei zugeben?

Gruß
Marcus

[mbo]

moin,

im zweifelsfall setze eine EXCEPT dahinter

cu/2 iae

[Firew]

Nee, alles korrekt verstanden! ;-)

Ich sperre auf meinem Server alle Dienste mit ALL:ALL in hosts.deny. Nun, muss ich ja SSH freigeben.
Damit ich den unsicheren TCP-Wrapper gar nicht erst benutzen brauch, und alles verbiete, meinst du, ich sollte denn ssh über den xinetd laufen lassen. So, das werde ich mal versuchen. Hast du dazu irgendeine Doku? Oder Seite?

Noch nen schönen Abend!
Marcus

[Firew]

Tja, hmm...

Ist denn SSH ein Dienst? Es ist doch nur die Beschreibung eines Ports. Oder gilt das auch??
Meines Wissens nach, kann ich ja nur Dienste freigeben bzw. sperren, daher auch meine Frage wie das mit SSH läuft.


Marcus

[mbo]

ham wa wieda net alles gelesen?

moin,
sorry, hab dat mit dem port überlesen.
die host.xxx greifen eh nur da, wo du dienste bereitstellst, und net da, von wo du die dienste in anspruch nimmst.

im serverbereich kannst du den sshd über (x)inetd starten lassen, dann greifen die hosts.xxx, dann gibst einfach den sshd einzeln an.

ansonsten bliebe noch ipchains iptables ...

es sei denn, du willst mir gerade sagen, daß du mit ssh im client-modus nicht auf den server zugreifen kannst und bei die die hosts.xxx exitieren. DANN gibt es nicht viele möglichkeiten. serverseitig siehe oben, clientseitigt kommen dafür nur ssh-client, ipchains oder -tables in frage.

wenn du clientseitig ssh unterbinden willst, brauchst die host.xxx aus genannten gründen gar net erst anfassen.

oder hab ich wieder mal alles falsch verstanden?

cu/2 iae

[thommy]

Der TCP-Wrapper arbeitet im Zusammenhang mit dem inetd; der xinetd verwendet den Wrapper nicht!!!

D.h. wenn Du auf xinetd zurückgreifst, brauchst Du Dich um hosts.[allow|deny] nicht zu kümmern.

Davon abgesehen, arbeitet der Wrapper so, dass er zuerst die hosts.allow betrachtet. Ein dortiger Eintrag hat VORRANG vor einem Eintrag aus hosts.deny. D.h. was bereits erlaubt ist, kann nicht nochmals verboten werden.

Thomas

[Firew]

@thommy:

>Der TCP-Wrapper arbeitet im Zusammenhang mit dem inetd; der xinetd verwendet den Wrapper nicht!!!
D.h. wenn Du auf xinetd zurückgreifst, brauchst Du Dich um hosts.[allow|deny] nicht zu kümmern.

Das stimmt so nicht.
Ich habe über xinetd den pop3s-Zugriff laufen. Habe ich jetzt in hosts.deny ALL:ALL stehen, wird der Zugriff verweigert. Also, arbeiten beide doch zusammen.

[thommy]

<BLOCKQUOTE><font size="1" face="Arial,Helvetica,Geneva">Zitat:</font><HR>
Das stimmt so nicht.
Ich habe über xinetd den pop3s-Zugriff laufen. Habe ich jetzt in hosts.deny ALL:ALL stehen, wird der Zugriff verweigert. Also, arbeiten beide doch zusammen.[/quote]

Dann hast Du aber in der Datei /etc/xinetd.conf explizit den Aufruf des TCP-Wrappers drin (Server-Eintrag). Das ist ungewöhnlich und nicht notwendig, da der Zugriff über only_from, no_access und access_times geregelt wird.

Thomas

[mbo]

moin,

der inetd verlangt auch keinen tcp-wrapper, war auch optional, genauso kann man es in xinetd machen, allerdings ist er erweitert um das, was thommy schrieb ...

cu/2 iae

[Firew]

Hmmm, ...

also, das ist meine Datei:

service pop3s
{
socket_type = stream
wait = no
user = root
server = /usr/local/sbin/stunnel
server_args = pop3s -l /usr/local/lib/popper -- -R -s -t /var/log/pop3s
log_on_success += USERID
log_on_failure += USERID
nice = 10
}

Wo sage ich den hier explizit, das der TCP-Wrapper genutzt werden soll? Und wie müsste den die Datei aussehen, wenn er nicht auf den TCP-Wrapper zugreifen sollte?

Marcus

[thommy]

Das liegt an stunnel, die von Dir verwendete Version hat offensichtlich die TCP-Wrapper-Funktion fest einkompiliert. Näheres dazu hier:
http://www.stunnel.org/faq/run.html

Und dennoch ist xinetd geschaffen worden, um die Sicherheitslücken des inetd zu schließen. Für xinetd ist der Wrapper nicht mehr notwendig.

Aber um auf Dein ursprüngliches Problem zurückzukommen. Wenn Du alle Dienste per xinetd startest, also auch den sshd, dann sollten für andere Dienste die Einträge aus hosts.allow und hosts.deny keine Rolle spielen.

Thomas

[Firew]

Okay! :-)

So, wenn ich also stunnel neu kompilieren würde, dann könnte ich es auch ohne TCP-Warpper benutzen.

Weißt du denn dann auch wie eine Datei für SSH aussehen würde? Etwa so:

service ssh
service pop3s
{
socket_type = stream
wait = no
user = root
server = /usr/bin/ssh
server_args = ???
log_on_success += USERID
log_on_failure += USERID
nice = 10
}

:confused:

[Firew]

Ein Tippfehler war dabei! Könnte sie in etwa so aussehen?

service ssh
{
socket_type = stream
wait = no
user = root
server = /usr/bin/ssh
server_args = ???
log_on_success += USERID
log_on_failure += USERID
nice = 10
}

[thommy]

...fast ;)

Der Server ist sshd und liegt oft unter /usr/sbin.
Serveroptionen benötigst Du vermutlich keine (also die Option leer lassen oder gleich entfernen).

Ansonsten wird der Ssh-Server bei vielen Distris nicht über [x]inetd sondern als Daemon gestartet. Wenn Du ihn selten brauchst, ist xinetd sicher eine gute Alternative.

Und Du brauchst stunnel nicht unbedingt neu zu übersetzen, denn die anderen Dienste (sofern sie nicht direkt die Dateien hosts.xxxx auswerten) betrifft das ohnehin nicht.

Thomas

[Firew]

Jau!

Dann danke ich dir erst mal recht herzlich! Jetzt habe ich jedenfalls eine genauere Vorstellung von xinetd. Ich werde mich mal etwas genauer in das xinetd-Geheimnis einarbeiten. :-)

Thx
Marcus

[thommy]

Dann schau doch mal in der Fibel (http://www.linuxfibel.de/inetd.htm#xinetd) nach.

Thomas