Re: FreeBSD-basierter Firewall

Marian Hettwer wrote:
> Oliver Fromme wrote:
> > Man kann es nicht oft genug betonen: SSL hat, ebenso wie ssh,
> > die Grundvoraussetzung, dass man beiden Endpunkten traut. (Das
> > ist auch der Grund, warum man z.B. in einem Internet-Cafe auf
> > gar keinen Fall Online-Banking machen oder sich per ssh irgendwo
> > einloggen sollte.)
> >
>
> Der Mail thread ist zwar schon lang genug, aber: was spricht dagegen
> sich aus nem öffentlichen WLAN via ssh auf einen Vertrauten Server
> einzuloggen? Gegeben, dass der Host Key vorher bekannt ist und man
> Public Key auth einsetzt sehe ich da kein Problem...

Das Entscheidende ist, dass Du den _Endpunkten_ vertrauen musst,
wie ich oben schrieb, also dem Server (der sich ja mit seinem
Host-Key identifiziert) und der Maschine, auf der Dein Client
läuft.

Die Netze dazwischen sind egal; das dürfen auch durchaus fremde
bzw. öffentliche WLANs sein. Das ist ja gerade der Zweck von
ssh, dass man eine sichere Verbindung durch unsicheres Terrain
herstellen kann.

Meine Bemerkung bezog sich auf Internet-Cafes, wo man sich an
einen bereitgestellten PC hockt -- also eben _kein_ Endpunkt,
dem man vertrauen kann. Die Hardware kann manipuliert sein,
das Betriebssystem kann manipuliert sein, der ssh-Client kann
manipuliert sein ... entweder vom Betreiber oder von einem
anderen Kunden. Da würde ich niemals ein Passwort oder eine
PIN eintippen oder dort einen USB-Stick mit einem Private-Key
einstecken.

Wenn man auf einer fremden Maschine unbedingt ssh machen muss,
dann sollte man unbedingt ein Authentisierungsverfahren nutzen,
das keine statischen Informationen benutzt (also kein Passwort
und kein Private-Key). Denkbar wäre ein Token-Verfahren, oder
ein OTP-Verfahren (z.B. OPIE; siehe die Manpage). Allerdings
sind auch diese Verfahren theoretisch durch Client-Manipulation
angreifbar, wenn es jemand gezielt darauf abgesehen hat. In
der Praxis sind aber Angriffe eher simpel gestrickt und sammeln
einfach nur Passwörter und/oder Keys ein; OTP schützt dagegen.

@Polytropon: Bitte nicht immer auf dem armen telnet rumhacken.
Man kann auch durchaus mit telnet sichere Verbindungen aufbauen,
beispielsweise unterstützt es Kerberos. Außerdem hat telnet
auch eine eigene Verschlüsselung eingebaut (siehe Manpage: -x),
die so gut wie unbekannt zu sein scheint. Sie ist zwar nicht
so stark (verwendet nur DES, soviel ich weiß) und kennt nicht
die Vielzahl an Authentisierungsverfahren, die ssh kann, aber
im Notfall ist es besser als gar nichts, und die meisten Hacker
dürften wohl eher nicht damit rechnen, dass jemand telnet mit
Verschlüsselung verwendet. (Gut, auf "security-by-obscurity"
sollte man sich natürlich besser nicht verlassen.)

Ich wollt's nur mal erwähnt haben. :-) Die meisten denken bei
telnet, dass das grundsätzlich unverschlüsselt sei, aber das
stimmt nicht.

Gruß
   Olli

-- 
Oliver Fromme,  secnetix GmbH & Co. KG,  Marktplatz 29, 85567 Grafing
Handelsregister:  Amtsgericht Muenchen, HRA 74606, Geschäftsfuehrung:
secnetix Verwaltungsgesellsch. mbH, Handelsreg.: Amtsgericht München,
HRB 125758, Geschäftsführer:  Maik Bachmann,  Olaf Erb,  Ralf Gebhart
FreeBSD-Dienstleistungen/-Produkte + mehr: http://www.secnetix.de/bsd
"Life is short (You need Python)"
        -- Bruce Eckel, ANSI C++ Comitee member, author
           of "Thinking in C++" and "Thinking in Java"
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message