Re: Anmeldung an Squid
Hallo Axel,
Am 19.09.2010 19:29, schrieb Axel Freyn:
Als Beispiel:
Wenn Du Homeverzeichnisse auf dem Server hast: Werden die verschlüsselt
übertragen - oder kann die jeder User abhören?
Betonung liegt m.E. auf "abhören"
was meinst du damit? die Inhalte werden nicht verschlüsselt übertragen.
Aber die Passworte natürlich schon.
Naja: Wofür braucht ein Angreifer ein Passwort, wenn er auch ohne
Passwort alle fremden Daten lesen und schreiben kann? :-)
lesen und schreiben ist bei mir schon was anderes, als wenn man nur
"abhören" kann. Da muss man unter Umständen lange warten, bis man das
erhält, was man will.
(Wenn du nfs 3 verwendest,
kann jeder, der an einem lokalen Rechner einen root-Account hat, fremde
Home-Verzeichnisse lesen& schreiben...)
an meiner Schule werden derzeit keine eigentlichen Linux-Clients
eingesetzt. NFS ist derzeit auf unseren Server noch nicht installiert,
kommt aber noch. Aber dann ist/wird doch standardmäßig eine Option
gesetzt, dass root keinen Zugriff erhält. oder irre ich mich da?
Naja, was ich meinte: Wenn du NICHT nfs Version 4 + Kerberos und
aktivierte Signatur/Verschlüsselung des Datenverkehrs verwendest (das
ist die schönste Lösung;-)) muss dir folgendes klar sein: Beim
"normalem" NFS (also: Version 3, oder Version 4 Ohne Kerberos):
der SERVER identifiziert die User anhand der Linux-User-ID -- und das
ist eine 4-stellige Nummer, die NICHT geheim ist. Angenommen, du hast
die ID 1234 und Home-Verzeichnis /home/kirmse.
das ist mir schon bewußt, dass NFSv3 nur in vertrauenswürdigen
Netzwerken eingesetzt werden sollte.
Wenn ich jetzt von einem beliebigen Rechner aus eine Anfrage an den
Server schicke "Ich bin User 1234. Lösche alle Dateien im Verzeichnis
/home/kirmse" -- dann TUT DAS DER SERVER -- ich muss dafür KEINERLEI
Passwort an den Server schicken (vorausgesetzt natürlich, du (kirmse)
darfst das;-))!
wie geht das? dann muss man auf diesen Client root-Rechte haben.
ansonsten muss ich zumindest das Passwort des Accounts mit der UID auf
dem Client kennen. => wie gerade angegeben: vertrauenwürdige Umgebung.
Ebenso wenn ich sage "Ich bin User 1234. Gib mir den Inhalt von
/home/kirmse/Latein-Schulaufgabe.pdf" -- kriege ich sofort, keinerlei
Passwortabfrage
wieder: nur wenn man auf dem Client root ist. Zumindest sehe ich das so.
Die einzige Sicherheit, die du mit NFS3 hinbekommst, ist folgendes:
a) du kannst dem Server sagen, er soll nur Anfragen von Ports< 1024
akzeptieren. Derartige Anfragen kann unter Linux nur root (und unter
Windows XP und neuer nur ein Admin) abschicken ==> Damit muss der
Angreifer am lokalen Rechner "root" sein.
kenne mich mit NFS nicht wirklich aus.
b) du kannst die IP-Adressen der erlaubten Clients mit einer Firewall
einschränken.
ich war dem Meinung, dass man das angeben kann, für welche IPs das
Filesystem exportiert wird. Wozu dann die firewall?
Aber: Wenn ein Schüler mit seinem privaten Notebook kommt, ihm die
IP-Adresse eines erlaubten Rechners gibt, und dann per NFS 3 auf den
Server zugreift, hast du verloren -- der Schüler kann sich dem Server
gegenüber als jeder User ausgeben, ohne auch nur irgendein Passwort
eingeben zu müssen. Das IST ein Problem von NFS Version 3...
ja, dass ist mir bekannt.
Ja, es gibt eine Ausnahme: Der Schüler kann sich NICHT als "root"
ausgeben -- das kannst du verbieten :-)
das meinte ich mit "Aber dann ist/wird doch standardmäßig eine Option
gesetzt, dass root keinen Zugriff erhält."
Das Windows-Netzwerkdateisystem ist eine Stufe sicherer -- bei Samba
braucht man zum Öffnen einer Verbindung erst mal das Passwort.
genau: ohne Passwort geht da nichts.
Aber:
Sobald z.B. Du von deinem Client aus als "kirmse" an Samba angemeldet
bist, kann ich von meinem Client aus Samba Befehle in deinem Namen geben
(vorausgesetzt, ich schaffe es, den Datenverkehr zwischen Dir und Samba
abzuhören -- und das geht in den meisten normal-konfigurierten
Netzwerken, sobald ich lokale root-Rechte habe).
und das Passwort wird bei Samba verschlüsselt übertragen.
Ich würde Schüler da lieber nicht unterschätzen... (Die
Gebrauchsanweisungen dazu kann man im Internet finden...)
Dann braucht ein Angreifer die
fremden Passwörter ja gar nicht mehr... (Noch schlimmer: Wenn ein User
z.B. Thunderbird zum Mail-Lesen verwendet& sein Passwort permanent
gespeichert hat
für unseren Server steht eine Lösung mit dem Webmailer Roundcube bereit.
Da die Anmeldung durch den Apache mit TLS verschlüsselt wird, sehe ich
hier kein Problem.
Naja, das Problem ist halt hier auch wieder: WENN ich mal Schreibzugriff
auf Dein Home-Verzeichnis habe, kann ich dir auch ein gefälschtes
TLS-Zertifikat unterjubeln, so dass ich ab dann den TLS-Verschlüsselten
Verkehr abhören kann...
wenn ich das Passwort habe, dann kann ich eh alles machen.
-- dann genügt der Lesezugriff auf das Home-Verzeichnis,
damit der Angreifer das Passwort hat)
Bei uns hat (normalerweise) nur der User Leserecht auf sein
Homeverzeichnis (also nicht wie es bei Debian üblich ist).
Bringt dir gar nichts, wenn das Homeverzeichnis unverschlüsselt übers
Netz übertragen wird.
nochmal: wann wird das Homeverzeichnis übers Netz übertragen? Der User
fordert doch bestimmte Dateien an und ob das gerade die sind, die den
Angreifer interessieren - da muss er u.U. lange warten.
Nachdem du im Moment nur Samba aktiv hast:
Mit lokalem root-Account an einem beliebigen Client (z.B. meinem
privaten Notebook) kann ich den ganzen Netzwerkverkehr zwischen Dir und
dem Server abhören& alle Dateien mitkopieren (die Software dafür gibts
im Internet -- komfortabel mit grafischer Oberfläche;-))
bis dahin gehe ich mit. Aber mit solchen Programmen kann ich nichts
anfangen. Die Schüler können das?
Ebenso kann ich "gefälschte" Kontrollpakete einfügen, so dass ich
(während du an deinem Client angemeldet bist) von meinem Client aus neue
Befehle an den Server schicken kann (in DEINEM Namen), z.B.: "Lösch alle
Dateien von kirmse" -- auch das geht ohne dass ich dein Passwort wissen
müsste :-)
ganz realistisch: das soll man als Schüler bringen?
Lange Rede - kurzer Sinn: dass das Passwort bei der Squidanmeldung im
Klartext übers Netz geht, das ist aus meiner Sicht die Schwachstelle.
OK, dann würde ich auch zu einer ntlm-Anmeldung raten -- so wie in Uwe's
Mail genannt.
und genau dazu bin ich noch nicht fündig geworden.
MfG Hans-Dietrich
Reply to: