9 Sicherheitsmechanismen in lokalen Netzen
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
9 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
der zusätzlichen Gefahren.Gefahren 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 Paßwörter!)
das Netz selbst,
d.h. die Kommunikationsinfrastruktur ist angreifbar
(z.B. Leitung stören, Vermittlungssystem unterwandern, ...)9.1 Zugangskontrolle über NIS
(Network Information System, Sun)
Authentisierung und Autorisierung
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, ...)9.1.1 Authentisierung beim Einloggen
Ein NIS Server besorgt die zentrale Verwaltung von Betriebsdaten,
die sonst in lokalen Dateien stehen, z.B.
/etc/hosts Rechnernamen und IP-Adressen
/etc/group Benutzergruppen
/etc/passwd Benutzernamen, Paßwörter,... (4.1.1)
...
Zur Erinnerung – Anfragen an NIS (früher „Yellow Pages“):
jefe: ypmatch lohr passwd
lohr:TRrnZPnbfSVsU:10000:10005:Peter Loehr,,1/11/2020,0
jefe: ypmatch jefe hosts
160.45.110.13 jefe prtinf1 smbjefe smbbwana smbdarwinLokale Paßwortdatei /etc/passwd enthält dann nicht viel mehr als
root:x:0:1:super_user:/:/bin/sh
+::0:0:::
veranlaßt das Login-Programm, den NIS Server zu fragenLogin-Vorgang im Detail:
1. Login mit Benutzername lohr und Paßwort 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 Löhr:..........
5. Damit: - pass verschlüsseln und überprüfen
- uid, gid und Shell-Namen entnehmen
- uid und gid setzen (5.2) und Shell starten
Effekt: Auf jedem System, auf dem lohr sich einloggt, haben seine
Prozesse immer die gleiche uid/gid 123:979.1.2 Einschränkungen des Imports vom NIS Server
+felix::123:45:::
bewirkt, daß nur für felix der Server befragt wird
(uid/gid ist hier aus technischen Gründen notwendig,
wird aber ignoriert)
-crook::123:45:::
+::::::
bewirkt, daß crook auf dieser Maschine nicht zugelassen wird
(vielleicht auf anderen)9.1.3 Netzgruppen
Zwecks einfacherer (und damit sicherer!) Verwaltung des Zugangs zu
bestimmten Rechnern können neben einzelnen Benutzern auch
Benutzergruppen in /etc/passwd aufgenommen werden. Beispiele:
+@operators
läßt nur die Mitglieder dieser Gruppe an den Rechner
-@students
-dean::123:45:::
+::::::
läßt alle außer dean und Studenten an den Rechner... und ein Beispiel aus dem wirklichen Leben: jefe: m /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/uu listen:x:37:4:Network Admin:/usr/net/nls: oracle:x:11400:10138:Oracle,(sabisch),1/11/2002,00000,/b 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
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,) (,ring,) (,stucki,) (,staff,) (,scherf,) (,s9.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 Paßwort
(das zudem im Klartext übers Netz geht!)
Aber: rlogin host verzichtet auf Paßwort,
wenn der Zielrechner dem Quellrechner vertraut.
Quellrechner heißt dann
vertrauenswürdiger Rechner (trusted host)
Vorteil: Komfort, Sicherheit9.2.1 Vertrauenswürdige Rechner
Bedeutung von „A vertraut B“:
Verwalter von A ist sich sicher, daß 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 daß A nach einem Paßwort fragt.
B A
b auf B macht
rlogin A
bxy... abc...Systemverwalter 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“)Beispiel 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
jefe: ypmatch xserver netgroup
(troll,,mi) (elfe,,mi)
jefe:
! Ausnahme: Bei Zugangsversuch als root
wird /etc/hosts.equiv ignoriert!9.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 )
(9.1.2.1)
Benutzergruppe (9.1.1.2)Beispiel:
bwana netadm
xyz -suspect
+ -@outlaws
+9.2.3 Benutzer-Vertrauen
bedeutet – anders als Verwalter-Vertrauen (9.1.2.1):
Benutzer b auf A ist sich sicher, daß 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, daß 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 ~/.rhostsBeispiel: ~mark/.rhosts auf daisy enthalte
shark.cs.ucsb.edu
+@marksprivatenet
+@localnet mary
Effekt: Mark kann sich ohne Paßwort einloggen
von shark.cs.ucsb.edu
und allen Rechnern in marksprivatenet;
Mary kann sich als Mark ohne Paßwort einloggen mit
login –l mark daisy
(sofern diese Möglichkeit nicht bei der
Systemkonfiguration explizit unterbunden wurde
- vgl. 7.2.1.3).9.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
jefe:lohr% rexec elfe command
arbeitet ohne Vertrauens-Mechanismus
– und verlangt Paßwort !
Außerdem: Fehlermeldung bereits nach falschem
Benutzernamen (ermöglicht Ausprobieren !)
In vielen Unix-Versionen nicht verfügbar.9.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:
1 Verwaltung von /etc/hosts.equiv und ~/.rhosts riskant
2 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.
3 Übers Netz gehen zwar keine Paßwörter,
aber IP-Adressen und Benutzernamen
- beides kann gefälscht werden.¼ 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.9.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/Solaris-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 Systemprozeß den tatsächlichen
Zugriff stellvertretend für den zugreifenden Prozeß
ausführt?9.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 (¼ 10)
(„Secure RPC“)
AUTH_KERB kryptographisch besser gesichert über einen
zusätzlichen Kerberos Server (¼ 11)AUTH_SYS weit verbreitet,
aber ähnlich angreifbar wie bei 9.2.5 3 :
Fälschung der uid/gids !9.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 -aTypische 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.Sie können auch lesen
