O-SAFT/fetchfile ================== Mit der Protokollerweiterung O-SAFT (Offer Simple Asynchronous File Transfer) und dem passenden Client fetchfile existiert nun eine Moeglichkeit Files von einem SAFT-Server abzuholen. Im Mailbereich gibt es einen analogen Mechanismus mit smtp und POP bzw APOP. Uebersicht: - Wie funktioniert O-SAFT/fetchfile? - Was ist auf Clientseite zu tun? - Was ist auf Serverseite zu tun? - Wie stehts mit der Security? Wie funktioniert O-SAFT/fetchfile? ----------------------------------- O-SAFT ist eine Erweiterung des SAFT Protokolls und erlaubt es authentifizierten Clients Files von einem (remote) Server abzuholen. Die Implementierung dazu ist sendfiled (Server) und fetchfile (Client). O-SAFT benutzt ein spezielles pgp Schluesselpaar zur Authentifizierung der fetchfile-Session. Dazu braucht der Client den Secret Key und der Server den Public Key. Dabei handelt es sich aus Sicherheitsgruenden NICHT um den normalen E-mail pgp key, sondern um einen extra Schluessel, exklusiv fuer fetchfile. Dieser muss einmal am Anfang erzeugt werden (siehe weiter unten). fetchfile kann vom Server Files anzeigen lassen, abholen oder nur loeschen. Nach dem Abholen durch fetchfile befinden sich die Files im lokalen Spool, nicht jedoch bereits im aktuellen Directory! Nach dem fetchfile Aufruf muss deshalb ganz normal receive gestartet werden, um die Files regulaer zu empfangen. Ist auf Client-Seite bereits ein lokales Spool /var/spool/sendfile vorhanden, so wird dieses benutzt, andernfalls $HOME/.sfspool angelegt. Dementsprechend laeuft fetchfile auf Clientseite voellig ohne root-Rechte ab. Was ist auf Clientseite zu tun? --------------------------------- pgp muss installiert und in $PATH enthalten sein. Zuallererst ist EINMAL das fetchfile pgp Schluesselpaar zu erzeugen mit: fetchfile -I Bitte unbedingt darauf achten, dass bei der Frage nach der Pass Phrase nur ENTER eingegeben wird! (Damit wird ein exklusives, nicht-Passphrase geschuetztes pgp-Schluesselpaar fuer O-SAFT erzeugt.) Nach erfolgreicher Initialisierung ist das File /var/spool/sendfile/$USER/config/public.pgp bzw $HOME/.sfspool/public.pgp vorhanden. Dieses ist an root@SAFT-Server zu schicken, damit dieser es in dem entsprechenden User Config-Directory ablegt. Beispiel: sendfile -c "mein O-SAFT puplic key" /var/spool/sendfile/$USER/config/public.pgp \ root@bofh.belwue.de (Dieser Schritt ist noetig, um den Empfaenger zu authentisieren und um vor Missbrauch zu schuetzen.) Danach kann fetchfile ganz normal benutzt werden, zB: fetchfile -l listet die Files auf dem Server fetchfile -a holt alle Files ab fetchfile -daf *aol.com loescht alle Files, die von aol gekommen sind Die weiteren Optionen koennen mittels "man fetchfile" nachgelesen werden. Mit zwei speziellen Optionen kann der Server-SAFT-Account konfiguriert werden: fetchfile -Cw=config fetchfile -Cw=restrictions Damit werden die betreffende Configfiles aus dem aktuellen Directory an den Server transferiert. Dessen Inhalt und Beudeutung koennen mit "man sendfile" nachgelesen werden. Mittels fetchfile -Cr=config fetchfile -Cr=restrictions koennen diese Files auch wieder ausgelesen werden (nach stdout). Was ist auf Serverseite zu tun? --------------------------------- pgp muss installiert sein. In /usr/local/etc/sendfile.cf muessen die folgenden Zeilen rein: # allow O-SAFT extension (on/off) fetchfile = on # where is the pgp programm? (for fetchfile) pgp = /usr/local/bin/pgp Der Administrator muss dann einen Account fuer den betreffenden User generieren (falls nicht schon vorhanden). Dieser Account muss nicht unbedingt interaktiv zugaenglich sein, dh, er braucht kein gueltiges Passwort zu haben und die login-Shell darf /bin/false sein. Sinn und Zweck ist es, dem sendfiled die Moeglichkeit zu geben den User zu ueberpruefen und ein Spooldirectory fuer ihn anzulegen (bei POP funktioniert das ebenso). Vom Client-User bekommt der Admin dann den fetchfile public key (public.pgp). Diesen muss er in das Config Directory des Users ablegen. Angenommen dieser User heisst gaga, dann tippt der Admin als root: receive -f gaga@* -b gaga public.pgp su gaga cd /var/spool/sendfile/gaga/config receive public.pgp (Das erste receive macht folgendes: es schickt das File public.pgp vom Absender gaga@* weiter an den lokalen User gaga) Wie stehts mit der Security? ------------------------------ O-SAFT benutzt eine tcp challenge/response Authentifizierung mittels pgp-Signatur. Dies bedeutet, dass die Session u.U. durch tcp hijacking uebernommen werden kann. Dieses ist aber relativ aufwendig und nur moeglich, wenn der Angreifer direkten Zugang zum Transportmedium hat, zB am selben Ethernetstrang sitzt und ueber hochwertige Hackertools verfuegt. Mit normalen Betriebssystemkomponenten ist so ein Angriff nicht moeglich.