Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Modul: B-BS Betriebssysteme WS 2012/13 Prof. Dr. Rüdiger Brause Adaptive Systemarchitektur Institut für Informatik Fachbereich Informatik und Mathematik.

Ähnliche Präsentationen


Präsentation zum Thema: "Modul: B-BS Betriebssysteme WS 2012/13 Prof. Dr. Rüdiger Brause Adaptive Systemarchitektur Institut für Informatik Fachbereich Informatik und Mathematik."—  Präsentation transkript:

1

2 Modul: B-BS Betriebssysteme WS 2012/13 Prof. Dr. Rüdiger Brause Adaptive Systemarchitektur Institut für Informatik Fachbereich Informatik und Mathematik (12) Sicherheit

3 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 2 Sicherheit Zugriffsrechte und Authentifizierung Sicherheit – Wozu? Einbruchsmöglichkeiten Sicherheit im Netz

4 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 3 Sicherheit Sicherheit – wozu? Sicherheit ist kein technisches Problem, sondern ein menschliches. IT-Sicherheitskonzepte sind nötig für: Datenschutzkonzept Virenschutz Programminstallationen (Keine unkontrollierten!) backup.....

5 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 4 Sicherheit Sicherheit – wozu? Haftungsverpflichtung Betriebs- und Geschäftsgeheimnisse §204 Abs 1 StGB, §17 Unlauterer Wettbewerb UWG Datenschutz (Kreditkarten!): zivil.+strafr.Haftung §7 Bundesdatenschutzgesetz BDSG Kontrolle und Transparenz im Unternehmensbereich KonTraG: effizientes Risikomanagement verlangt (§91,2 AktG) vom Vorstand einer AG (§§76ff,93 AktG) und vom Geschäftsführer einer GmbH (§43 GmbHG) sonst persönlich schadensersatzpflichtig! Abschlußtestat für börsennotierte AG nur wenn Risiko-Früherkennungssystem ex. EU-Eigenkapitalrichtlinie (Basel II) Rating von Kreditnehmern, auch nach IT-Sicherheit: Kreditzinsen! Sarbanes-Oxley-Act SOX Sektion 404 Funktionsfähiges internes Kontrollsystem incl. IT-Risikomanagement nötig, sonst persönliche Haftung!

6 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 5 Sicherheit Kontext Risikomanagement

7 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 6 Sicherheit Bot-Netze Bot-Herden ca. 0.30$ pro PC, mit Rating Quelle:

8 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 7 Sicherheit Bot-Netz Verbreitung Stand: 5 Mill. Rechner im 1.HJ 2007 Problem: Bot-Netze haben nur mittl. Lebensdauer von 54 Tagen: schwer zu entdecken. Phishing- Attacken DDoS SPAM

9 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 8 Sicherheit Verkauf von Bankdaten

10 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 9 Sicherheit Hintergrundfakten Kriminelle Dienstleistungen Einbruch in Webseiten und Foren Massenanwendung Malware DDoS-Angriff pro 24 h Bot-Builder mit DDoS-Funktion Software Limbo zur Bot-Steuerung Server für SPAM nutzen Mehr als 10 Mill. SPAM versenden Software MPack für Angriff von Webseiten 50 $ 100 $ 250 $ 500 $ 600 $ 1000 $ Quelle: Technology Review, 4/2008

11 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 10 Sicherheit Webangriff via Browser exploit Beispiel: Storm-AngriffJuni 2007 IPS Webserver Seiten infiziert Italien BadBoys Server Infiltration mit Mpack Hongkong Server San Francisco Bot- Kontrolle Chicago Trojaner Valentinskarte..

12 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 11 Sicherheit Kriminelle Energie: Hintergrundfakten

13 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 12 Sicherheit Frage Gesetz §202c StGB (2007): Wer eine Straftat nach §202a oder b (Ausspähen und Abfangen von Daten) vorbereitet, indem er … Computerprogramme, deren Zweck die Begehung einer solchen Tat ist, herstellt, sich oder einem anderen verschafft, verkauft, einem anderen überlässt, verbreitet oder sonst zugänglich macht,… wird mit Freiheitsstrafe bis zu einem Jahr oder mit einer Geldstrafe bestraft. Frage: Welchen Effekt hat dieses Gesetz? 1.Es werden mehr Verbrechen verhindert, da die Täter Angst vor Strafe haben 2.Es werden Verbrechen gefördert, da damit sichere Systeme verhindert werden 3.Keins von beiden Grundlagen der Programmierung 1 - Teil 3 R.Brause: Sicherheit und Schutz

14 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 13 Sicherheit Zugriffsrechte und Authentifizierung Sicherheit – Wozu? Einbruchsmöglichkeiten Sicherheit im Netz

15 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 14 Sicherheit Einbruchsmöglichkeiten Passworte erlangen Passwort erraten logist. Angriff (Telefon, pers. Besuch,...) Auslesen der Paßwortdatei unter Unix: /etc/passwd, Anwenden von Lexika von Namen und Begriffen, Anwenden von finger, who für Daten wie Namen, ZimmerNr.,... Aber: Willkürl. Passworte sind keine Lösung! Besser: Biosignatur, Chipkarten,... Passwort abhören Datenpakete mithören z.B. von Telnet. Abhilfe: Verschlüsselung, z.B. secure shell, secute file transfer

16 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 15 Sicherheit Einbruchsmöglichkeiten Trojanische Pferde: harmlose Programme mit Nebenfunktionen Pseudo-login Programme -Programme: s mit Kontroll-Zeichen, Multimedia mit Active-X oder link zu Webseite (blended Threat) WWW-Dienste: Active-X, postscript-viewer, FTP file transfer: falsche Zugriffsrechte => Überschreiben von Systemdateien nützlicheProgramme (Spiele etc.): spyware key-logger! Würmer Programmierter Einbruch, Errichtung von backdoors Viren Selbst-Replizierendes Programm, Errichtung von backdoors

17 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 16 Sicherheit Einbruchsmöglichkeiten Infektion Start user program code Start virus program user program code Virusinfektion

18 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 17 Sicherheit Einbruchsmöglichkeiten Kontrollübernahme durch Buffer-Overflow > 90% Überladen von Unix-ProgrammCode bzw. Rücksprungadresse auf Stack String 1 String2 SP Rückadr. String2 String1 Virus code VStart Start Virus code VStart Argumentpuffer Stackbereich

19 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 18 Sicherheit Buffer-Overflow-Angriff Stackframe bei normalem Funktionsaufruf C-Code void function(int a, int b, int c) { char buffer1[8]; char buffer2[16];...} void main() { function(1,2,3); } Assembler-Code Auszug aus "gcc -S -o example1.s example1.c" function : pushl %ebp # sichert EBP 32-Bit base pointer movl %esp,%ebp # kopiert ESP stack pointer nach EBP subl $24,%esp # schafft Platz f. buffer1+2 movl %ebp,%esp # korrigiert EBP... popl %ebp ret main: pushl %ebp movl %esp,%ebp pushl $3 # Parameter auf den Stack pushl $2 pushl $1 call function # Funktionsaufruf addl $12,%esp # Stack aufräumen

20 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 19 Sicherheit Buffer-Overflow-Angriff Beispiel: Stackmanipulation C-Code 1 void function(int a, int b, int c) { 2 char buffer1[8]; 3 char buffer2[16]; 4 int *ret; 5 6 ret = buffer1 + 12; 7 (*ret) += 8; 8 } 9 10 void main() { 11 int x; x = 0; 14 function(1,2,3); 15 x = 1; 16 printf("%d\n",x); 17 } return-Adresse überschrieben, x unverändert, Ausgabe = 0 Ausgabe = ? 12 // skip x=1

21 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 20 Sicherheit Buffer-Overflow-Angriff Kodierung des Angriffstrings unsicherer Ort der RET-Adr. NOPs Virencode darf keine Null enthalten (warum?) XOR mit Zahl

22 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 21 Sicherheit Buffer-Overflow-Angriff Einsatz einer sicheren Bibliothek (Link!) libsafe für strcpy (char *dest, const char *src) strcat (char *dest, const char *src) getwd (char *buf) gets (char *s) fscanf (FILE *stream, const char *format,...) scanf (const char *format,...) realpath (char *path, char *reolved_path([ ]) sprintf (char *str, const char *format,...)... Also : strncpy( Quelladr,Zieladr ) statt strcpy( Quelladr, Zieladr ) in C verwenden ! Benutzung von Stacksicherung wie StackShield, StackGuard, SecureStack,… HW: Kein write auf read-only-Code, kein execute auf read/write-Daten zulassen (AMD64)

23 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 22 Sicherheit Der Rootkit-Angriff Idee: Verhindere, dass ein Virus (Wurm,Trojaner,...) entdeckt und beseitigt wird Angriff: Fange alle Aufrufe ab, die Dateien, Ordner, Prozesse auflisten können und manipuliere sie. Programm (Prozess-/Dateilisting) rootkit System-API oder lib Betriebssystem API-Methode user mode rootkits Treiber-Methode kernel mode rootkits Programm (Prozess-/Dateilisting) System-API oder lib rootkit Betriebssystem Sys Call

24 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 23 Sicherheit Der Rootkit-Angriff Beispiel Windows NT user mode rootkits Userprocess Kernel32.dll Ntdll.dll Betriebssystem Rootkit dll dll import hooking FindFirstFile Beispiel Hacker Defender von user mode kernel mode

25 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 24 Sicherheit Phase 2: Vergleich Rootkit-Erkennung Phase 1: Datensammlung

26 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 25 Sicherheit Der Rootkit-Angriff Beispiel Windows NT kernel mode rootkits user mode kernel mode Systemdienste Object Manager Process Manager Local Proc.Calls Memory Manager Security Monitor I/O System Kernel HardwareAbstractionLayer HAL Hardware Win32 rootkit driver Process list system call hooking Methode: system call hooking

27 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 26 Sicherheit Der Rootkit-Angriff Beispiel Windows NT kernel mode rootkits user mode kernel mode Systemdienste Object Manager Process Manager Local Proc.Calls Memory Manager Security Monitor I/O System Kernel HardwareAbstractionLayer HAL Hardware Win32 rootkit driver Process list Manipulation von Kerndaten Methode: Manipulation von Kerndaten

28 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 27 Sicherheit Der Rootkit-Angriff Beispiel Windows NT kernel mode rootkits Beispiel: NT-rootkit Liste der malware Dateien Userprocess Kernelsystemcall I/O Manager rootkit filter driver Regularfiledriver Harddisk user mode kernel mode Filter-Treiber-Angriff Methode: Filter-Treiber-Angriff

29 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 28 Sicherheit Einbruchsphasen Malware-Entdeckung Fehlverhalten (reboot, langsam, s), Prüfsummen, Systemscan Lockvögel honey pots: Virussignatur, Agent in Bot-Netzen Malware-Entfernung log. Vertrauenskette (alte Systemdatenträger booten, Minimalsystem aufsetzen, alte Nutzerdaten einspielen) Phasen Malware einschleppen (ca Stck/Tag neu) (Bootstrap, -Anhang, Makro, Freie Programme..)

30 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 29 Sicherheit Zugriffsrechte und Authentifizierung Sicherheit – Wozu? Einbruchsmöglichkeiten Sicherheit im Netz

31 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 30 Sicherheit Einbruch über Zugriffsrechte Kontrollübernahme (Viren, Würmer etc.) durch Dateisystem-Zugriffsrechte falsche Schreib/leserechte für Systemdateien => Überschreiben möglich, falsche PATH-Angabe (zuerst. ) => falsches Systemprogramm wird ausgeführt Systemprogramme-Zugriffsrechte Ausnutzen von Fehlern, um mit Systemrechten zu schreiben. Beispiel: emacs, CGI-Scripts Administratorrechte für die Installation dubioser Programme

32 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 31 Sicherheit ACL Problem: Zugriff auf 1000 Rechner durch 1000 Benutzer Muss jeder sich bei jedem registrieren mit Paßwort? Idee: Capability-Modell vs. ACL Capability-orientierte Zugriffsrechte Capab. Objekt 1Objekt 2Objekt 3Objekt 4 User A r w User Br w xr x User Cr w User Drr

33 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 32 Sicherheit Frage Angenommen, Sie haben 8 Nutzer und 16 Dateien,wieviele ACL gibt es im System? Bitte schreiben Sie die Zahl auf und geben Sie Ihrem linken Nachbar. Grundlagen der Programmierung 1 - Teil 3 R.Brause: Sicherheit und Schutz Antwort : Jede der Dateien hat eine ACL für die Nutzer und ihre Zugriffsrechte. Also 16 ACL.

34 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 33 Sicherheit Grundlagen der Programmierung 1 - Teil 3 R.Brause: Sicherheit und Schutz Rollenbasierte Zugriffsrechte Capability-Erweiterungen Rollen-basiertes Modell: User können Rollen mit Capabilities annehmen Vertraulichkeit (Informationsweitergabe) Kein User darf Objekte lesen/schreiben, die höher klassifiziert sind als er selbst Beispiel Krankenhausrollen Person Rolle Objekt Patient Kranken blatt Anästhesie protokoll Müller Schmidt Paulsen Meier Chirurg Anäs thesist Kranken- pfleger stützen schreiben operieren lesen

35 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 34 Sicherheit Authentifizierung Authentifizierungsquellen Etwas, was Sie wissen Passwort, PIN, Testfragen Etwas, was Sie haben Kreditkarte, Handy, Token-Generator Etwas, was Sie sind Fingerabdruck, Iris, Bio-Daten Zwei Faktoren-Authentifizierung (T-FA) starke Authentifizierung z.B. PIN und Fingerabdruck Grundlagen der Programmierung 1 - Teil 3 R.Brause: Sicherheit und Schutz Aber: Hilft nicht gegen Trojaner oder man-in-the-middle-Angriff!

36 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 35 Sicherheit Beispiel Unix Authentifizierung am Rechner Prozeßfolge: /etc/passwd : root:Igl6derBr45Tc:0:0:The Superuser:/:/bin/sh brause:ntkyb1io ø kk3j:105:12:&Brause:/user/user2/ASA:/bin/csh LoginName Paßwort PersonId GruppeId Name StartPfad ShellName /etc/group: staff:*:12:boris,peter,brause GruppenName GruppenPaßwort GruppenId Benutzerliste Authentifizierung Autorisierung BenutzerProzeßRechte = ruid, rgid ProgrammErzeugerRechte = uid, gid effektive ProzeßRechte = euid, egid Laufzeit: euid ruid, egid rgid Aber: set userId/groupId: euid uid, egid gid Authentifizierung im Netz Dominoeffekt! rsh remote shell, rlogin remote login: basierend auf etc/hosts.equiv init Prozeßgetty login sh Kommando 1 Kommando 2

37 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 36 Sicherheit Authentifizierung Beispiel Windows NTBenutzerauthentifikation lokale Anmeldung, bei der sich der Benutzer mit seinem lokalen Benutzernamen auf seinem Computer anmeldet (lokale ACL) Netzwerk-Anmeldung, um Zugriff auf die Dateien eines Dateiservers zu erhalten (Server-ACL) Anmeldung in einer Domäne, mit der der Zugriff auf die Rechner und die Dienste der Domäne geregelt wird primary domain controller (R/W), backup domain controller (R) Anmeldung in einem Domänennetz durch trust relationship = ACL

38 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 37 Sicherheit Trusted Computing Initiative, Programme kontrolliert HW-geprüft auszuführen Konzept: Vertrauenskette ( chain of trust ) Problem:Schützt nicht gegen Programmierfehler CPU boot BIOS BS- Lader BS Anwen dung Hash 0 Hash 1 Hash 2 Hash k platform configuration register Trusted Platform Module TPM chip z.B. Secure Startup Windows Vista Vergleich Messung Vergleich Hash Messung Hash Messung Hash Messung Hash

39 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 38 Sicherheit Zugriffsrechte und Authentifizierung Sicherheit – Wozu? Einbruchsmöglichkeiten Sicherheit im Netz

40 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 39 Sicherheit Sicherheit im Netz: Fire wall fire wall router: IP-screening der Datenpakete, IP-Übersetzung (HW/SW) Problem: IP-Screening unzureichend (PortNr. wechselt, ex. mehrere Ports für 1 task, Rückantwort an unbekannten Sender nötig) relay host oder Gateway: Netz-Programme und –Dienste, kontrolliert mit positiv/negativ-Liste (ACL) Wer darf was. Billiglösung dual homed host: external router & relay host & fire wall router andere Netze Internet LAN external router fire wall router relay host

41 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 40 Sicherheit Grundlagen der Programmierung 1 - Teil 3 R.Brause: Sicherheit und Schutz Computerbetrug: Phishing Prinzip: Vorspiegeln falscher Anfragen ( ) Speziell: Spear-Phishing Beispiel Postbank-Anfrage Abhilfe: I-TAN M-TAN Indizierte TANDynamische TAN Bank Kunde Anfrage SMS

42 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 41 Sicherheit Grundlagen der Programmierung 1 - Teil 3 R.Brause: Sicherheit und Schutz Netzgestützter Angriff Problem: Man-in-the-middle Angriff Bank Kunde Anfrage Antwort Angreifer Problem: key logger Angriff Bank Kunde Angreifer Key logger verändert

43 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 42 Abhilfe: Isolierung der Prozesse Beispiel Qubes OS Joanna Rutkowska Isolierung aller Prozesse von einander durch individuelle, leichte VMs Isolierung auch der grafischen Benutzeroberflächeninstanzen! (trusted window manager) Isolierung auch der benötigten Bs-Kernfunktionen (im Unterschied zu VirtualBox etc.) Abgesicherte Arbeit auf gemeinsamen Dateien Mikrokern-Basis: Xen Hypervisor, Typ 1 (HW-basiert) Sicherheit Quelle: Qubes-os.org

44 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 43 Sicherheit = symmetrische Schlüssel asymmetrische Schlüssel Abhilfe: Verschlüsselung SenderEmpfänger Bob Alice Ver- schlüsselungs- Algorithmus Ent- schlüsselungs- Algorithmus Original verschlüsselt Kodier- schlüssel inverser Schlüssel öffentlich privat public key - Systeme

45 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 44 Sicherheit Abhilfe: Verschlüsselung Public key – Systeme Asymmetrische Systeme Verschlüsselte Nachricht = f(Nachricht, Schlüssel _ 1) = y Entschlüsselte Nachricht (Schlüssel_2 = bekannt public ) = g( verschlüsselte Nachricht, Schlüssel_2) = g(y, s 2 ) = g( f(Nachricht, s 1 ), s 2 ) = g s2 ( f s1 (Nachricht) ) Wähle Einwegfunktion f(.) ( trap function ) zur Verschlüsselung, wobei g(.) = f -1 (.) nicht aus f(.) schließbar. z.B. RSA-Algorithmus Rivest, Shamir, Adleman (1978) p q = c, p, q prim, (p,q) private key, c public key Faktorisierung langsamer als Multiplikation ! (one way function) Symmetrische Systeme geheime Schlüssel f = g, s 1 = s 2 z.B. DES data encryption standard

46 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 45 Sicherheit Grundlagen der Programmierung 1 - Teil 3 R.Brause: Sicherheit und Schutz Abhilfe: Verschlüsselung Beispiel einfache modulo-Verschlüsselung mit Primzahlen p = public key, q = private key mit p q mod n = 1 z.B. p = 7, q = 13, n = 90 Original: U B O O T ASCII: a = kodiert: x = x = a p mod n ASCII 7 0 Dekodiert a = a = q x mod n Problem: p, n gegeben – q kann durch Ausprobieren bestimmt werden, allgemein in log 2 (n)-Zeit. Lösung: RSA-Algorithmus (1978) Rivest, Shamir, Adleman p q = c, p,q prim, (p,q) private key, c public key Faktorisierung c p,q langsamer als Multiplikation p q c (one way function)

47 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 46 Sicherheit Kerberos-Authentifizierung Die Kerberos-Authentifizierung Athena-Projekt (MIT 1988) Symmetrische Verschlüsselung durch DES Benutzerauthentifizierung login protocol Anfrage beim AS (Authentication Server) UserName Ergebnis: Sitzungsausweis valide ca. 8 h Service-Einleitung Authentication protocol Anfrage beim Server: ServiceRequest,UserName, Authentifikation, Transaktionsausweis, Ergebnis:ServiceResultat Schlüsselverteilung Single Sign on protocol Anfrage beim TGS (Ticket Granting Service) ServiceName, UserName, Authentification, Sitzungsausweis Ergebnis: Transaktionsausweis (Ticket) valide ca. 5 Min.

48 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 47 Sicherheit Service-Einleitung Service UserName, IP, Zeit Anfrage UserName Ergebnisse UserName, IP, Zeit Schlüsselverteilung Authenticator Kerberos-Authentifizierung Benutzerauthentifizierung Sitzungs-Ausweis UserName A S UserName TGS Service UserName UserName, IP, Zeit Service Ticket UserName

49 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 48 Sicherheit Kerberos-Authentifizierung Vorteile Kopie der Ausweise oder Tickets möglich, aber für jede Anfrage fehlt der Authentikator. Eine Fälschung der Ausweise oder Tickets ist nicht möglich, da die Schlüssel von TGS und Dienst unbekannt sind. Alle Tickets und Authentifikatoren lassen sich auch vom Benutzer selbst nicht beliebig lange aufbewahren und verwenden: Benutzerrechte können dynamisch verändert werden. Da das Benutzerpasswort nur einmal eingegeben werden muss, bemerkt der Benutzer von dem ganzen Authentifikationsprotokoll nichts weiter – eine wichtige Voraussetzung für die Akzeptanz.

50 Betriebssysteme: © R.Brause, J.W.G-Universität Frankfurt a.M. Folie 49 Sicherheit Kerberos-Authentifizierung Probleme Ausdehnung auf gekoppelte Domänen-LANs(V.5) Anfrage für Nachbar-Domänentransaktion an RemoteTGS Ausdehnung auf Nachbarn vom Nachbarn, etc., iterativ bis zum Ziel Probleme Uhrensynchronität nötig für Zeitschranken. Aber: Zeitauthentizität benötigt selbst das Protokoll; Widerspruch! Feste Zeitschranken brechen Transaktionen ungewollt ab Schlüssel und Tickets können evtl. von anderen lokal gelesen werden Übergang zu abweichenden Systemen bietet Angriffsfläche einheitliche Sicherheitsrichtlinien XBSS (X/Open Baseline Security Specifications)


Herunterladen ppt "Modul: B-BS Betriebssysteme WS 2012/13 Prof. Dr. Rüdiger Brause Adaptive Systemarchitektur Institut für Informatik Fachbereich Informatik und Mathematik."

Ähnliche Präsentationen


Google-Anzeigen