Daniel Wolpert
Eilert Brinkmann wrote:
Dazu kommt, dass der Username nur ermittelt werden kann, wenn auf dem Client-Host der identd laeuft, was im allgemeinen nicht vorausgesetzt werden kann.
Nun, wenn eine Identd-Anfrage nicht 'erfolgreich' verläuft wäre es ein weiterer Grund die Verbindung abzubrechen oder ?
Man koennte sich fuer dieses Vorgehen entscheiden, aber in den meisten Faellen ist das nicht sinnvoll. Z.B. findet man einen identd allenfalls auf Linux- bzw. Unix-Clients, und auch bei denen kann man sich nicht darauf verlassen. Immerhin gibt es durchaus Gruende, warum sich jemand zum Verzicht auf den identd entscheiden koennte. Und schliesslich ist der identd zwar ganz nett, aber nicht wirklich sicher. Wenn's um Sicherheit geht, sollte man nicht allzuviel auf identd-Antworten geben, es sei denn, man kontrolliert den Rechner, auf dem der identd laeuft, und das Netz dazwischen. Kurz: identd-Ausgaben koennen eine ganz nette zusaetzliche Information in Logfiles sein, aber die eigentliche Zugriffskontrolle wuerde ich nicht davon abhaengig machen.
Dann wäre das sinnigträchtigste wohl eine eigene Login-Prozedur zu entwickeln und den tcpd diese anstatt des üblichen /bin/login verwenden zu lassen oder ? a la (/usr/sbin/in.telnetd -L /usr/local/bin/mylogin)
Moeglich, aber das sollte man sich sehr gut ueberlegen. Schliesslich ist das eine gute Stelle, um ein paar Sicherheitsluecken einzubauen ;-) Besser ist es, man kommt mit den Konfigurationsmoeglichkeiten der ueblichen Programme aus, und in den meisten Faellen reichen die aus. Eilert -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Eilert Brinkmann -- Universitaet Bremen -- FB 3, Informatik eilert@informatik.uni-bremen.de - eilert@tzi.org - eilert@linuxfreak.com http://www.informatik.uni-bremen.de/~eilert/ --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Eilert Brinkmann wrote:
Moeglich, aber das sollte man sich sehr gut ueberlegen. Schliesslich ist das eine gute Stelle, um ein paar Sicherheitsluecken einzubauen ;-)
wird wohl kaum der einbauen, der sich schützen möchte oder ?
Besser ist es, man kommt mit den Konfigurationsmoeglichkeiten der ueblichen Programme aus, und in den meisten Faellen reichen die aus.
Nun, letztenendes muß an irgendeinem Punkt angesetzt werden. Bisher ist es so, und wird wohl auch so bleiben, gibt es für nichts eine absolute Sicherheit. Mit bekannten, bzw. nutzbaren Vorgaben zu arbeiten erhält die Portabilität & Kompatibilität; das darin auch nicht der Weisheit letzte Schluß zu finden ist dürfte einsehbar sein. Pauschallösungen sind leider nur bedingt anwendbar. Zu entscheiden welcher Weg, um möglichst am eigentlich Problem zu bleiben, der hier geeigetste ist liegt beim Initiator dieses Threads, da nur dieser das 'Sicherheitsbedürfnis' quantifizieren und eine vertretbare Abwägung zwischen diesem, möglichst geringem Aufwand & möglichst flexibler Nutzbarkeit treffen kann. daniel ---------------------------------------------------------- "come day, go day - wijshing me hard it was sunday. drinking bottermil all the wwek, Whiskey on a sunday" To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (2)
-
dw@siebel.de
-
eilert@Informatik.Uni-Bremen.DE