1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
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.
|
