Re: Anmeldung an Squid
Hallo Hans-Dietrich,
>> Im Prinzip sehe ich zwei Möglichkeiten:
>> a) du kannst die Kommunikation Browser<-> squid KOMPLETT verschlüsseln.
>> Ich weiß auf die Schnelle keine Lösung, wie es mit squid alleine
>> geht, sondern du müsstest meiner Meinung nach entweder VPN verwenden,
>> oder z.B. ssh: Wenn du bei jedem Client-Neustart automatisch eine
>> ssh-Verbindung zum Server öffnest, und dann den Web-Verkehr über
>> diesen ssh-Tunnel zum Server laufen lässt, ist es sicher. Im Prinzip:
>> ssh -L 3128:servername:3128 servername
>> leitet den lokalen Port 3128 an den server weiter. Wenn am Server auf
>> 3128 SQUID läuft, kannst du am Client als proxy-Server
>> "localhost:3128" eintragen -- dann ist alles verschlüsselt (auch die
>> Webseiten, die übertragen werden). Die ssh-Anmeldung kannst Du ja
>> z.B. mit einem Passwort-losen Schlüssel machen (damit sie
>> automatisch läuft) und dem ssh-Account auf dem Server dann keinerlei
>> Rechte geben.
>
> die Lösung gefällt mir nicht. Die Anleitung, wie ich sie in der Antwort
> auf die Mail von Uwe angegeben habe wird ja derzeit so überarbeitet,
> dass der Server automatisch so konfiguriert wird. Dazu werden
> Debian-Pakete gebaut, die nichts weiter machen, als über die
> Abhängigkeiten die eigentlichen Debian-Pakete zu installieren und über
> die Maintainer-Scripte die Konfiguration zu übernehmen. - serverseitige
> Lösungen sind okay (sofern sie von Laien wie mir bewältigt werden
> können), aber clientseitig soll es möglichst einfach sein. Das ist hier
> nicht der Fall.
Naja, die ssh - Lösung wäre noch relativ einfach -- du müsstest auf dem
Client lediglich eine Zeile z.B. in /etc/rc.local eintragen (und den
public-Key des Servers einmal kopieren). Aber klar, ich verstehe dein
Unbehagen.
>
>> Als Beispiel:
>> Wenn Du Homeverzeichnisse auf dem Server hast: Werden die verschlüsselt
>> übertragen - oder kann die jeder User 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? :-)
>
>> (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.
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;-))!
Ebenso wenn ich sage "Ich bin User 1234. Gib mir den Inhalt von
/home/kirmse/Latein-Schulaufgabe.pdf" -- kriege ich sofort, keinerlei
Passwortabfrage
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.
b) du kannst die IP-Adressen der erlaubten Clients mit einer Firewall
einschränken.
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, es gibt eine Ausnahme: Der Schüler kann sich NICHT als "root"
ausgeben -- das kannst du verbieten :-)
Das Windows-Netzwerkdateisystem ist eine Stufe sicherer -- bei Samba
braucht man zum Öffnen einer Verbindung erst mal das Passwort. 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).
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...
>
>> -- 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. 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;-))
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 :-)
>
>
> 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.
Schönen Abend,
Axel
Reply to: