8 Sicherheitsmechanismen in lokalen Netzen
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
8 Sicherheitsmechanismen in lokalen Netzen
Lokales Rechnernetz (Intranet)
besteht aus kooperierenden, häufig spezialisierten
Rechnersystemen (Client/Server-Architektur), die unter
einheitlicher Verwaltung stehen (Betrieb, Institut, ...) und
von außen (aus dem Internet) nur begrenzt zugänglich sind.
Somit einerseits zusätzliche Gefahren durch Vernetzung,
andererseits wegen Abschottung nach außen und wegen
vertrauenswürdiger Mitarbeiter (?) begrenzter Umfang
dieser Gefahren.
SS-8 1Gefahren durch Vernetzung:
Angriffe auf die Systemsicherheit sind nicht nur lokal,
sondern auch über das Netz ausführbar
Datenverkehr im Netz ist angreifbar
(z.B. Leitung abhören, etwa Passwörter!)
das Netz selbst,
d.h. die Kommunikationsinfrastruktur ist angreifbar
(z.B. Leitung stören, Vermittlungssystem unterwandern, ...)
SS-8 28.1 Zugangskontrolle über NIS
(Network Information System, Sun)
Authentisierung und Autorisierung (3,4 )
sind auch im Netz die Grundvoraussetzung für wirksamen
Schutz gegen alle neu hinzukommenden Angriffsmöglichkeiten
Anforderungen an Authentisierung im lokalen Netz:
1. Zentrale Zugangskontrolle für alle beteiligten Rechner
2. Komfortable Fernbenutzung (remote login)
3. Unsichtbare/automatische Authentisierung bei der
Inanspruchnahme von Diensten im Netz
(z.B. Dateidienst, Druckdienst, E-mail, ...)
SS-8 38.1.1 Authentisierung beim Einloggen
Ein NIS Server besorgt die zentrale Verwaltung von Betriebsdaten,
die sonst nur in lokalen Dateien stehen, z.B. in
/etc/hosts Rechnernamen und IP-Adressen
/etc/group Benutzergruppen
/etc/passwd Benutzernamen, Passwörter,... (3.1.1)
...
Zur Erinnerung – Anfragen an NIS (früher „Yellow Pages“):
jefe: ypmatch lohr passwd
lohr:X4sCwh/Da%pT2:123:97:Peter Loehr,,1/11/2020,00201!,/bin/
jefe: ypmatch jefe hosts
160.45.110.13 jefe prtinf1 prtinf2 smbjefe
SS-8 4Lokale Passwortdatei /etc/passwd enthält dann nicht viel mehr als
root:x:0:1:super_user:/:/bin/sh
+::0:0:::
veranlasst das Login-Programm, den NIS Server zu fragen
SS-8 5Login-Vorgang im Detail:
1. Login mit Benutzername lohr und Passwort pass.
2. /etc/passwd nach lohr durchsuchen.
3. Wenn dabei + erreicht wird,
NIS Server nach lohr in dortigem /etc/passwd befragen.
4. Wenn dort gefunden, wird der lohr–Datensatz zurückgeliefert:
lohr:X4sCwh/Da%pT2:123:97:Peter Loehr:..........
5. Damit: - pass verschlüsseln und überprüfen
- uid, gid und Shell-Namen entnehmen
- uid und gid setzen (4.2) und Shell starten
Effekt: Auf jedem System, auf dem lohr sich einloggt,
haben seine Prozesse immer die gleiche uid/gid 123:97
SS-8 68.1.2 Einschränkungen des Imports vom NIS Server
+felix::123:45:::
bewirkt, dass nur für felix der Server befragt wird
(uid/gid ist hier aus technischen Gründen notwendig,
wird aber ignoriert)
-crook::123:45:::
+::::::
bewirkt, dass crook - auch wenn im NIS verzeichnet -
auf dieser Maschine nicht zugelassen wird
(vielleicht auf anderen)
SS-8 78.1.3 Netzgruppen
Zwecks einfacherer (und damit sichererer!) Verwaltung des Zugangs
zu bestimmten Rechnern können neben einzelnen Benutzern auch
Benutzergruppen in /etc/passwd aufgenommen werden. Beispiele:
+@operators
lässt die Mitglieder dieser Gruppe an den Rechner
-@students
-dean::123:45:::
+::::::
lässt alle außer dean und Studenten an den Rechner
SS-8 8... und ein Beispiel aus dem wirklichen Leben: jefe: more /etc/passwd root:x:0:1:Super-User:/:/sbin/sh daemon:x:1:1::/: bin:x:2:2::/usr/bin: sys:x:3:3::/: adm:x:4:4:Admin:/var/adm: lp:x:71:8:Line Printer Admin:/usr/spool/lp: uucp:x:5:5:uucp Admin:/usr/lib/uucp: nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uuci listen:x:37:4:Network Admin:/usr/net/nls: oracle:x:11400:10138:Oracle,(sabisch),1/11/2002,00000,/bin/csh: nobody:x:60001:60001:Nobody:/: noaccess:x:60002:60002:No Access User:/: nobody4:x:65534:65534:SunOS 4.x Nobody:/: +@technics +@jefe-x +::::::/home/fubinf/staff/bin/skripts/no_rlogin.csh SS-8 9
... aber z.B. auch: athos: more /etc/passwd root:x:0:0:Super-User:/:/sbin/sh daemon:x:1:1::/: bin:x:2:2::/usr/bin: sys:x:3:3::/: adm:x:4:4:Admin:/var/adm: lp:x:71:8:Line Printer Admin:/usr/spool/lp: uucp:x:5:5:uucp Admin:/usr/lib/uucp: nuucp:x:9:9:uucp Admin:/var/spool/uucppublic:/usr/lib/uucp/uuci smmsp:x:25:25:SendMail Message Submission Program:/: listen:x:37:4:Network Admin:/usr/net/nls: gdm:x:50:50:GDM Reserved UID:/: webservd:x:80:80:WebServer Reserved UID:/: nobody:x:60001:60001:NFS Anonymous Access User:/: noaccess:x:60002:60002:No Access User:/: nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: athos: SS-8 10
Diese Gruppen sind ein Spezialfall des Konzepts
Netzgruppe (netgroup)
und die Netzgruppen sind ebenfalls im NIS verzeichnet – genauer:
beim NIS Server unter /etc/netgroup in folgendem Format:
groupname member1 member2 . . .
mit den Gruppenmitgliedern in folgendem Format:
(hostname, username, domainname)
oder groupname
Beispiel:
jefe: ypmatch technics netgroup
(,vesligaj,) (,stucki,) (,staff,) (,scherf,) (,schauble,)
SS-8 118.2 Fernbenutzung
(remote login)
innerhalb eines lokalen Unix-Netzes mit statt mit telnet, ssh, ...
auch mit rlogin möglich:
rlogin [ –l user ] host
fragt normalerweise nach Passwort
(das zudem im Klartext übers Netz geht!)
Aber: rlogin host verzichtet auf Passwort,
wenn der Zielrechner dem Quellrechner vertraut.
Quellrechner heißt dann
vertrauenswürdiger Rechner (trusted host)
Vorteil:Komfort, Sicherheit
SS-8 128.2.1 Vertrauenswürdige Rechner
Bedeutung von „A vertraut B“:
Verwalter von A ist sich sicher, dass ein bei ihm registrierter
„Benutzer b auf A“ derselbe ist, der sich bei ihm als
„Benutzer b auf B“ mit einem rlogin-Wunsch meldet.
Effekt: Wenn Benutzername b bei A und B registriert ist,
darf b den Rechner A von B aus fernbenutzen,
ohne dass A nach einem Passwort fragt.
B A
b auf B macht
rlogin A
bxy... abc...
SS-8 13Systemverwalter von A verzeichnet die für A
vertrauenswürdigen Rechner in
/etc/hosts.equiv
Format der Einträge (siehe man hosts.equiv):
[ + | - ] [ host | @ netgroup ]
mit Einträgen der Form (host , , domain)
Z.B. bwana
-@training
+@production (Reihenfolge entscheidet)
oder + (bedeutet „alle“)
SS-8 14Beispiel aus dem wirklichen Leben:
jefe: more /etc/hosts.equiv
+@localnet
jefe: ypmatch localnet netgroup
serv pi tire oe zombie m-suns m-pcs
jefe: ypmatch serv netgroup
iserver lserver cserver xserver mserver (atom,,mi) (ts,,mi)
jefe: ypmatch xserver netgroup
(troll,,mi) (elfe,,mi)
jefe:
! Ausnahme: Bei Zugangsversuch als root
wird /etc/hosts.equiv ignoriert!
SS-8 158.2.2 Vertrauenswürdige Benutzer
(trusted users)
bedeutet: bestimmten Benutzern eines fremden Rechners
- z.B. deren Verwaltern - wird so sehr vertraut,
daß sie sich als beliebige lokale Benutzer anmelden dürfen
(praktisch für Netzverwaltung - ! aber riskant !)
/etc/hosts.equiv kann entsprechend erweiterte Einträge enthalten:
hostspec [ userspec ]
[ + | - ] ( host | @ netgroup ) [ + | - ] ( user | @ netgroup )
Benutzergruppe
SS-8 16Beispiel:
bwana netadm
xyz -suspect
+ -@outlaws
+
SS-8 178.2.3 Benutzer-Vertrauen
bedeutet – anders als Verwalter-Vertrauen (8.2.1):
Benutzer b auf A ist sich sicher, dass ein Benutzer b auf B,
der sich bei A mit einem rlogin-Wunsch meldet, er selbst ist;
oder Benutzer b auf A vertraut einem anderen
Benutzer c auf B so sehr, dass er ihm das rlogin als b erlaubt!
Benutzer macht die entsprechenden Angaben in
~/.rhosts
im gleichen Format wie bei /etc/hosts.equiv
Geprüft wird zunächst /etc/hosts.equiv , dann ~/.rhosts
SS-8 18Beispiel: ~mark/.rhosts auf daisy enthalte
shark.cs.ucsb.edu
+@marksprivatenet
+@localnet mary
Effekt: Mark kann sich ohne Passwort einloggen
von shark.cs.ucsb.edu
und allen Rechnern in marksprivatenet;
Mary kann sich als Mark ohne Passwort einloggen mit
login –l mark daisy
(sofern diese Möglichkeit nicht bei der
Systemkonfiguration explizit unterbunden wurde
- vgl. 6.2.1.3).
SS-8 198.2.4 Fernausführung mit rsh und rexec
jefe:lohr% rsh elfe command
führt command unter Benutzer lohr auf elfe aus –
sofern auf elfe dem Rechner jefe oder wenigstens
dem Benutzer lohr vertraut wird
( rsh elfe wie rlogin elfe )
jefe:lohr% rexec elfe command
arbeitet ohne Vertrauens-Mechanismus
– und verlangt Passwort !
Außerdem: Fehlermeldung bereits nach falschem
Benutzernamen (ermöglicht Ausprobieren !)
In vielen Unix-Versionen nicht verfügbar.
SS-8 208.2.5 Gefahren von Trusted Hosts/Users
Zur Erinnerung: „Vertrauen ist gut – Kontrolle ist besser“ !
Trusted Hosts / Trusted Users
dienen einerseits der Sicherheit, schaffen aber andererseits
neue Gefahren:
Verwaltung von /etc/hosts.equiv und ~/.rhosts riskant
Vertrauen ist transitiv: wenn A B vertraut, dann implizit
auch allen C, D, ..., denen B vertraut, usw.; d.h. Einbruch
in Rechner, von dessen Existenz ich vielleicht gar nichts
weiß, erleichtert u.U. Einbruch in meinen Rechner.
Übers Netz gehen zwar keine Passwörter,
aber IP-Adressen und Benutzernamen
- beides kann gefälscht werden.
SS-8 21 Sicherheitsregeln:
Alle beteiligten Systeme praktizieren sicheres Booting.
Die Systemverwalter (root) aller beteiligten Systeme
sind wohlbekannt und vertrauenswürdig.
Fremde Systeme dürfen nicht ad-hoc angeschlossen werden.
Das lokale Netz ist nach außen sehr gut abgeschottet.
SS-8 228.3 Zugriffsschutz im verteilten Dateisystem
am Beispiel Sun NFS – Network File System:
NFS File Server besorgt Verwaltung von Teil-Dateisystemen.
Benutzer sieht diese als normale Unterbäume im Dateibaum.
Lokale Unix-Systeme beauftragen den File Server mit
dem Lesen und Schreiben von Blöcken, ferner .....
File Server wir über Fernaufrufe angesprochen.
Zentrale Frage: Wie kann der Unix-Zugriffsschutz praktiziert werden,
wenn ein entfernter Systemprozess den tatsächlichen
Zugriff stellvertretend für den zugreifenden Prozess
ausführt?
SS-8 238.3.1 Authentisierung bei Fernaufrufen
Vorgesehen sind
AUTH_NONE keine Authentisierung
AUTH_SYS uid/gid (oder mehrere gids) werden
als „Credentials“ („Papiere“) mitgeschickt
Vor.: netzweit einheitliche uid/gids (NIS)
ermöglicht auch den NFS-Zugriffsschutz
AUTH_DES kryptographisch gesichert mittels DES ( 9)
(„Secure RPC“)
AUTH_KERB kryptographisch besser gesichert über einen
zusätzlichen Kerberos Server ( 10)
SS-8 24AUTH_SYS weit verbreitet,
aber ähnlich angreifbar wie bei 8.2.5 :
Fälschung der uid/gids !
SS-8 258.3.2 Exportbeschränkung
Konfigurierung des File Servers erlaubt
grobkörnigen Zugriffsschutz –
bezogen auf ganze Dateisysteme.
Schutz ist spezifiziert in
/etc/exports
Format der Einträge: directory –options [ , moreoptions ]
Server wird dementsprechend konfiguriert mittels
% exportfs -a
SS-8 26Typische Inhalte von /etc/exports:
/bin –ro indiscriminate read-only export
/var/mail –rw=host1:group3 read/write export to host1 and
netgroup (of hosts) group3
Effekt: Nur auf denjenigen Klienten(-Rechnern),
zu denen exportiert wird, dürfen die angegebenen
Dateisysteme mit dem mount-Befehl in den lokalen
Dateibaum eingebunden werden.
SS-8 27Sie können auch lesen
