RPC - Remote Procedure Call

Transkript

1 RPC - Remote Procedure Call Dynamische Anmeldung neuer Dienste Vorgänger von DCE, CORBA, RMI, DCOM Sicherheitsapekte anfangs ignoriert Synchroner Funktionsaufruf portmap / rpcbind auf TCP port 111 Meist sehr schwache Authentisierung: keine Benutzernummer und Benutzergruppennummer(n) Authentisierung: Kontaktaufnahme verschlüsselt mit Diffie-Hellman Authentisierung durch Kerberos Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-1 NIS - Network Information Service Früher: yp - yellow pages Zentraler Server für Verzeichnisse, die von einer Menge von Rechnern gemeinsam genutzt werden /etc/passwd, /etc/group, /etc/services, /etc/hosts, Diese Menge von Rechner bildet eine domain. Domains werden durch Namen identifiziert. Einbindung in /etc/passwd durch root:sfr4rtfghzju7:0:1:admin:/:/bin/sh -keller::2001:102::: +::0:0::: [ +:*:0:0::: ] Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-2 1

2 NIS - Network Information Service Freie Verbreitung von Benutzerinformationen und verschlüsselten Passwörter ist Grundsätzlich kritisch. Syntax der Erweiterung von /etc/passwd ist fragwürdig. Wie bei vielen anderen Verzeichnisdiensten: Einspeisen falscher Daten möglich. Kommunikation über RPC Verbesserung: NIS+ nur verschlüsselte Authentisierung bei RPC Für große Organisationen geeignet Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-3 Kerberos Entwickelt am MIT, frei verfügbar Server speichert Passwörter verschlüsselt, kann sie aber entschlüsseln. Anmeldeprozedur für Version 4: Host sendet Benutzernamen an Server. Server antwortet mit einem Ticket Granting Ticket, verschlüsselt mit dem Passwort des Benutzers. Host entschlüsselt Ticket mit eingegebenem Passwort. Anmeldeprozedur für Version 5: Host sendet Benutzernamen und Zeitstempel verschlüsselt mit eingegebenem Passwort an Server. Server antwortet mit einem Ticket Granting Ticket, verschlüsselt mit dem Passwort des Benutzers, nur wenn das Passwort richtig war. Host entschlüsselt Ticket mit eingegebenem Passwort. Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-4 2

3 Kerberos Ticket Granting Ticket TGT enthält Session key Ticket für Ticket Granting Service verschlüsselt mit dem Session key und dem TGS key Mit dem TGT können beim TGS tickets für verschiedene Dienste angefordert werden, z.b. für entfernten Dateizugriff. Ein Dateizugriffsticket enthält verschlüsselt den Benutzernamen, seine Gruppenrechte, seine Internetadresse und ein Ablaufdatum. Bei jedem Zugriff auf entfernte Dateien muss das Ticket mitgeliefert werden. Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-5 Eigenschaftten von Kerberos Passwörter werden nur auf dem Server gespeichert und nicht über das Netz übertragen. Der Server ist ein Sicherheitsrisiko, das er die gespeicherten Passwörter entschlüsselt kann und muss. Installationsaufwand ist hoch, da alle sicherheitsrelevanten Dienste modifiziert werden müssen. Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-6 3

4 NFS - Network File System Transparente Nutzung von Festplatten und anderen Datenspeichern über das Netz Server bietet Datenspeicher an. Client greift über NFS darauf zu. Entwickelt von Sun, erste Version (2): 1985 Version 3 seit 1996 Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-7 Eigenschaften von NFS Server ist zustandslos kann neu gebootet werden - Client wartet solange Zugriff über File Handles file system identifier file identifier generation count Kombination von mount-protokoll und dem eigentlichen NFS-Protokoll Protokolle setzt auf RPC auf Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-8 4

5 mount-protokoll Server: mountd oder rpc.mountd Anfragen: NULL MNT DUMP UMNT UMNTALL EXPORT Tut gar nichts Liefert File Handle für Dateisystem, registriert Anfragenden Liefert Liste der gemounteten Dateisysteme Löscht Registrierung des Anfragenden dito für alle vom Anfragenden gemounteten Dateisysteme Liefert die Exportliste des Servers Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-9 NFS-Protokoll Dateioperationen: GETATTR SETATTR READLINK READ WRITE Liefert Dateiattribute Setzt Dateiattribute Liest einen Symbolischen Link Liest Datei Schreibt Datei Verzeichnisoperationen: CREATE, LINK, LOOKUP, MKDIR, READDIR, REMOVE, RENAME, RMDIR, SYMLINK Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

6 NFS-Sicherheitsaspekte Genauso unsicher wie zugrundeliegender RPC Unverschlüsselte Übertragung von Dateien Zugriffsschutz basiert auf Unix-Dateisystem Sicherheit des Servers ist kritisch Keine Benutzer-Accounts auf Server! Authentisierung des Client beruht auf IP-Adresse, wenn sie überhaupt vorgenommen wird Anfragen ganz ohne Authorisierung möglich Keine Authentisierung des Servers Garfinkel/Spafford: For real security, don t use NFS. Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-11 Serversicherheit Konfigurationsdatei /etc/exports oder /etc/dfs/dfstab Je NFS-Dateisystem: Liste der zugelassenen Clients read only / read write root access anon uid setuid security: Secure RPC (Solaris) oder Secure Port (Linux) user squash (unter Linux) Besonders schützen: Home-Verzeichnisse Server-Programme Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

7 SSL - Secure Socket Layer Setzt auf zuverlässigem Übertragungsprotokoll auf (TCP) Aushandeln des Verschlüsselungsverfahrens zwischen Client und Server Vertraulichkeit der Übertragung durch Verschlüsselung, z.b. mit DES oder RC4 Optionale Authentisierung von Client und Serversystem Integrität der Übertragung durch Message Authentication Code (MAC) Zwei Installationen sind nicht notwendigerweise kompatibel Offen für die Integration neuer Verschlüsselungsverfahren Erträgliche Übertragungsrate Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-13 Vertraulichkeit Authentisierung Replay Protection SSL Record Layer Sicherheitscheck: Schlüsselgeneration nicht vorhersagbar Unabhängige Schlüssel für jede Datenrichtung Neue Schlüssel für jede Verbindung Schlüsselaustausch Initialisierung Synchronisierung SSL Handshake Protocol Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

8 ssh - Secure Shell Vollständiger Ersatz für telnet rlogin rsh rcp (ftp) Client- und Server-Authentisierung Verschlüsselte Passwort- und Datenübertragung Direkte Unterstützung von verschlüsselter X11-Übertragung Andere TCP-Protokolle können unterstützt werden Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-15 Sicherheit durch die Secure Shell Die Secure Shell schützt vor IP spoofing Netzschnüfflern Abhören von Passwörtern Hijacking von Sitzungen Abhören von X11 Authentisierung durch RSA Verschlüsselung durch verschiedene (wählbare) Methoden IDEA, DES, triple-des, blowfish Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

9 Protokoll der Secure Shell: Verbindungsaufbau 1. Client öffnet Verbindung zum Server. 2. Server sendet seinen public host key und public server key (stündliche Änderung). 3. Client prüft public host key. /etc/ssh_known_hosts oder $HOME/.ssh/known_hosts Client generiert session key und schickt ihn dem Server, verschlüsselt mit public host key und public server key. Der Server entschlüsselt den session key. Ab nun: verschlüsselte Übertragung Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-17 Passwortabfrage Protokoll der Secure Shell: Benutzeranmeldung RSA-Authentisierung des Benutzers Privaten und öffentlichen Schlüssel mit ssh-keygen generieren. Öffentlichen Schlüssel auf Server übertragen. eventuell Abfrage einer Passphrase (ssh-passwort) Automatische Übergabe der Passphrase durch ssh-agent und sshadd RSA-Authentisierung des Rechners Analog zu rlogin und rsh /etc/hosts.equiv (/etc/shosts.equiv) (nur bei gleichem Benutzernamen) $HOME/.rhosts ($HOME/.shosts) Server schickt Challenge an Client (verschlüsselt mit öffentlichem Schlüssel des Clients) Client antwortet mit MD5-Prüfsumme des Challenge. Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

10 Benutzung der Secure Shell ssh ssh <entfernterrechner> ssh ssh -l <Benutzername> <entfernterrechner> ssh <entfernterrechner> <Kommando> ssh <Kommando> Optionen -c : Verschlüsselungsalgorithmus -C : Komprimierung bei Dateiübertragung -L : Port-Umleitung Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-19 Weitere Kommandos der Secure Shell scp wie rcp: Kopieren von oder nach entferntem Rechner z.b. scp /home/quitte/datei quittek@hostx:/users/quittek/datei ssh-keygen erzeugt privaten und öffentlichen RSA-Schlüssel $HOME/.ssh/identity $HOME/.ssh/identity.pub ssh-agent ssh-add Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

11 Verlangsamung durch Verschlüsselung Beispiel: scp-aufrufe auf einem relativ langsamen Rechner in einem nur leicht belasteten Ethernet Verschlüsselung Aufsetzzeit Datenrate keine 2,4 s 386 kb/s RC4 2,0 s 318 kb/s blowfish 2,3 s 299 kb/s DES 2.1 s 219 kb/s IDEA 2,3 s 170 kb/s Triple-DES 1,9 s 118 kb/s Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-21 Nachteile der Secure Shell (Noch) nicht standardisiert (Noch) nicht fester Teil von Unix oder Windows Installations- und Verwaltungsaufwand (host keys) Reduzierter Durchsatz wegen Verschlüsselungsaufwand Unterstützung weitere Dienste (z.b. ftp) umständlich Die Sicherheit von Dateien in Home-Verzeichnis ist kritisch, besonders der private RSA-Schlüssel, aber auch die random seed für den Zufallsgenerator zur Generierung von Schlüsseln. Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

12 Weiteres zur Secure Shell Geschätzt: 3 Millionen Benutzer Geschütztes Markenzeichen SSH Communications Security Corporation Protokoll frei verfügbar Standardisierung durch IETF im Gange Neues Protokoll: ssh2 neuer, saubererer Entwurf bessere Integration von ftp nicht kompatibel zu ssh1 Implementationen mit fall back zu ssh1 Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin Zusammen mit WWW meist genutzter Internet-Dienst 1997: 270 Milliarden s -Agenten Benutzer-Agent Transport-Agent Filter-Agent Speicher-Agent SMTP - Simple Mail Transfer Protocol (RFC 821) Adressierung und Versand Formatierung der (RFC 822) -Listen Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

13 Aufbau des -Systems Benutzer-Agent Sender und empfängt nach Benutzer-Interaktion Transport-Agent Ist zuständig für die Zustellung von Speicher-Agent Speichert s bis sie vom Empfänger entgegengenommen und gelöscht werden Filter-Agent Verhindert Weiterleitung unerwünschter Ändert Adressierung Sendet automatische Antworten Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-25 Aufbau des -Systems Benutzer- Agent Filter- Agent Transport- Agent Filter- SMTP SMTP Agent Filter-? Agent Benutzer- Agent SMTP Transport- Agent Filter- Agent POP, IMAP Speicher- Agent Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

14 SMTP Simple Mail Transfer Protocol Definiert durch RFC 821 Kommunikation zwischen einem Client, der eine zustellen möchte und einem Server, der dies tun soll. Wichtige SMTP Kommandos: HELO Identifizierung des Clients MAIL FROM: Identifizierung des Senders der RCPT TO: Einer oder mehrere Empfänger der VRFY und EPND Zustellbarkeit einer Adresse prüfen DATA Beginn der Übertragung der eigentlichen QUIT Beenden der Verbindung Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-27 Einige SMTP-Antworten 220 <domain> Service ready 221 <domain> Service closing transmission channel 250 Requested mail action okay, completed 251 User not local; will forward to <forward-path> 354 Start mail input; end with <CRLF>.<CRLF> 500 Syntax error, command unrecognized [This may include errors such as command line too long] 502 Command not implemented 503 Bad sequence of commands 550 Requested action not taken: mailbox unavailable [E.g., mailbox not found, no access] 571 (RFC 1893) Error when trying to forward a message [E.g. relaying is not allowed] Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

15 SMTP-Sitzung, Beispiel 1 telnet example.com mail.example.de ESMTP Sendmail /8.10.1; Mon, 26 Jun :10: (CEST) HELO test 250 mail.example.de Hello test [ ], pleased to meet you VRFY kunz 250 kunz User kunz@example.de QUIT 221 mail.example.de closing connection VRFY kunz 550 kunz... User unknown VRFY kunz 252 Cannot VRFY user; try RCPT to attempt delivery Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-29 SMTP-Sitzung, Beispiel 2 telnet example.de mail.example.de ESMTP Sendmail /8.10.1; Mon, 26 Jun :11: (CEST) HELO test 250 mail.example.de Hello test [ ], pleased to meet you MAIL FROM: <hinz@hinzkunz.de> 250 hinz@hinzkunz.de...sender ok RCPT TO: <kunz> 250 kunz@example.de...recipient ok DATA 354 Enter mail, end with "." on a line by itself From: hinz@hinzkunz.de To: kunz Subject: Hallo Hallo Kunz, bis bald e5pl2kr19462 Message accepted for delivery QUIT 221 mail.example.com closing connection Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

16 SMTP-Sitzung, Beispiel 3 telnet example.de mail.example.de ESMTP Sendmail /8.10.1; Mon, 26 Jun :12: (CEST) HELO test 250 mail.example.de Hello test [ ], pleased to meet you MAIL FROM: <hinz@hinzkunz.de> 250 hinz@hinzkunz.de...sender ok RCPT TO: <sonstwer@sonstwo.de> 250 sonstwer@sonstwo.de...relaying denied QUIT 221 mail.example.com closing connection Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-31 Formatierung der (RFC 822) Einige Felder des -Kopfes: To Adressen und Optional Namen der Empfänger Cc Durchschriftenempfänger Bcc Durchschriftenempfänger, unsichtbar für andere Empfänger From Autor Sender Absender Subject Betreff Date Lokales Datum und lokale Uhrzeit Received Transportvermerk, eine Zeile je Transport-Agent Reply-To Antwortadresse Message-Id global eindeutige Identifikation dieser einzelnen Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

17 Beispiel einer Return-Path: Received: from tokyo.ccrle.nec.de [ ]) by kyoto.berlin.ccrle.nec.de (8.9.3/8.9.3) with ESMTP id WAA05037 for Sun, 25 Jun :59: From: Received: from test (yamato1.berlin.ccrle.nec.de [ ]) by tokyo.ccrle.nec.de (8.10.1/8.10.1) with SMTP id e5pl2kr19462 for <quittek>; Sun, 25 Jun :03: (CEST) Date: Sun, 25 Jun :03: (CEST) Message-Id: To: Subject: Tach Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-33 Standardformat des Received-Feldes Received: from H1 (H2 [A.B.C.D]) by H3 (V1/V2) with SMTP id MID; for <ADR>; DATE mit H1 H2 H3 V1 V2 SMTP MID ADR DATE Identifikation, die mit dem HELO-Kommando gesendet wurde Name, der der Internet-Adresse A.B.C.D des Clienten entspricht Rechner, der diesen Eintrag vorgenommen hat Versionsnummer des Transport-Agenten Versionsnummer der Konfiguration des Transport-Agenten Benutztes Protokoll zum Transport der lokale eindeutige Identifikation der Adresse, die mit dem RCPT TO-Kommando angegeben wurde lokales Datum und Uhrzeit des Empfangs der Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

18 Gefälschte Absender Alle Felder des -Kopfes können falsch sein. Ausnahme: Die (oberen) Received-Felder der letzten als zuverlässig eingestuften Transport-Agenten. Das Format der Received-Felder kann variieren. Eine Übereinstimmung zwischen dem Adressaten im - Kopf und dem durch RCPT TO spezifizierten Empfänger muss nicht vorliegen. Gleiches gilt für das From-Feld und den durch MAIL FROM spezifizierten Autor. Authentisierung von s z.b. durch PGP ist anzuraten. Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-35 Spam Große Mengen unverlangt zugesandter . Unsolicited Commercial (UCE) Unsolicited Bulk (UBE) Kostet den Empfänger Online-Zeit, Speicherplatz, Arbeitszeit. Erster Fall in der Mitte der 70er Jahre. 1994: Zwei Green Card-Anwälte verschickten Werbung an über 6000 news groups. Große Mailing-Listen und beliebte News Groups ersparen dem Sender von Spam viel Zeit und Übertragungskosten Gleiches gilt für Transport-Agenten, die als Relais arbeiten. Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

19 Typische Spam-Inhalte Untersuchung der Federal Trade Commission 1998 (Analyse von s) Geschäftsgelegenheiten mit Gebühr (Pyramiden-Schema) Making Money by Sending Bulk ings Kettenbriefe Heimarbeitsangebote Gesundheits- und Diätenangebote Pläne und Angebote für leicht verdientes Geld Investitionsangebote Kreditangebote Touristikangebote Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-37 Verhaltensempfehlung beim Empfang von Spam Nicht aggressiv über Belästigung beschweren. Das trifft oft den falschen. Keine Anleitungen befolgen, die versprechen, daß man danach keine s aus dieser Quelle erhält. Diese Bestätigen dem Sender den Empfang und die geweckte Aufmerksamkeit. Berichten an den Administrator der Quelle. Installation von Spam-Filtern. Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

20 Bekämpfung von Spam Abschalten der Relais-Funktion in Transport-Agenten Blacklisting und Blackholing von Spam-Quellen und offenen Relais Mail Abuse Protection System (MAPS) Realtime Blackhole List (RBL) Installation und Benutzung von Mail-Filtern. eingebaut in Benutzer-Agent Unabhängiger Filter, z.b. procmail Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-39 Transport-Agent Sendmail Von Eric Allman, UC Berkeley, seit % aller Transport-Agenten sind Sendmail oder Sendmail- Varianten von Dritten. Ständige Aktualisierung und Stopfen von Sicherheitslücken Aktuelle Version: , , je nach Betriebssystem Alternativen: qmail, exim, Post.Office, pmdf, smail Konfiguration sendmail.cf /etc/aliases $HOME/.forward Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

21 Weitere Sicherheitsaspekte von Abhören von s Übertragung im Klartext Abfangen von s gefälschte MX Records Manipulation von Konfigurationsdateien der Transport-Agenten Denial of Service-Angriffe durch Überlastung von Transport- Agenten Große s Große Mengen von s -Schleifen Verstecken von Namen sendender Rechner durch sendmail Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-41 HTTP - Hypertext Transfer Protcol Wird verwendet seit erste öffentliche Spezifikation durch RFC 1945 HTTP/1.0, frühere Version unter HTTP/0.9 bekannt. Standardisiert in Version HTTP/1.1 durch RFCs 2068 und 2616 Einfaches und schnelles Protokoll Kommunikation zwischen Benutzeragenten (meist Browser), Proxies, Gateways und Servern Anfrage-Antwort-Schema Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

22 HTTP-Anfragen GET Anfrage nach einer Datei Erwarte diese geschickt zu bekommen Angabe der Protokollversion GET /dateien/123.html HTTP/1.0 HEAD wie get, jedoch ohne Dateitransfer POST Daten senden PUT (HTTP/1.1) DELETE (HTTP/1.1) Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-43 HTTP/1.0-Antworten 200 OK 201 Created 202 Accepted 204 No Content 301 Moved Permanently 302 Moved Temporarily 304 Not Modified 400 Bad Request 401 Unauthorized 403 Forbidden 404 Not Found 500 Internal server Error 501 Not Implemented 502 Bad Gateway 503 Service Unavailable Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

23 HTTP-Nachrichtenköpfe Der Kopf einer Anfrage darf folgende Felder enthalten: Authorization - Übergabe eines Passworts o.ä. From - Angabe der adresse des anfragenden Benutzers If-Modified-Since - Macht get conditional Referer - Angabe, woher der Link kam User-Agent - Angabe von Produkt und Versionsnummer Der Kopf einer Antwort darf folgende Felder enthalten: Location - eine URL Server - Angabe von Produkt und Versionsnummer WWW-Authenticate - Aufforderung zur Authorisierung Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-45 HTTP-Datenübertragung Felder des Kopfes eines Datenblocks Allow - Liste der erlaubten Anfragen Content-Encoding - Art der Kodierung des Datenblocks, z.b. x-gzip Content-Length - Länge des Datenblocks in Byte Content-Type - z.b. text/html Expires Last-Modified Je nach Art der Nachricht können Felder erforderlich, optional oder nicht vorgesehen sein. Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

24 HTTP-Authentisierung Nur Authentisierung des Client vorgesehen Prozedur: Server schickt auf eine Anfrage die Antwort 401 (Unauthorized). Die Antwort enthält ein WWW-Authenticate-Feld mit einer challenge. Client sendet mit der erneuten Anfrage ein Authorization-Feld, das eine gültige Antwort die challenge enthält. Art der challenge ist nicht durch HTTP festgelegt. Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-47 HTTP-Sicherheitsprobleme Persönliche Daten auf Web-Servern Mißbrauch von Server Log-Dateien Refer-, From- und User-Agent-Feld Vertraulichkeit bei der Datenübertragung Klartextübertragung Passwörter in URI (URL) Dateisicherheit auf Server Pfadnamen außerhalb des Serverbereichs abblocken! Große Abhängigkeit von DNS-Dienst Falsche Proxies und Caches Trennung unterschiedlicher logischer Server auf einem Physischen ist oft kritisch bei der Implementierung des Servers Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

25 SSL fuer HTTP S-HTTP: Secure HTTP HTTP-Erweiterung für Vertraulichkeit durch Verschlüsselung (symmetrisch und unsymmetr.) (Server-) Authentisierung Digitalen Signatur Kapselung von HTTP in S-HTTP Zusätzliche Felder für Schlüsselaustausch oder Schlüsselindizierung Integrität einer Nachricht und Authentisierung des Senders durch Message Authentication Code (MAC) Auch HTTP-Anfragen und Felder der Köpfe werden verschlüsselt Verhandlung der Kommunikationspartner über das Verschlüsselungsverfahren Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-49 Sicherheit von HTTP-Anwendungen Geschützt werden soll der Server (Webserver) der Client (Browser) die Datenübertragung Gefahren drohen von Server-Erweiterungen Browser-Erweiterungen der Datenübertragung über das Internet auch: Unterbrechung von Verbindungen Abhängigkeit von anderen Diesnten Unterbrechung von Verbindungen Geschwindigkeit des Fortschritts Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

26 Mögliche weitere Sicherheitsanforderungen Authentisierung des Benutzer Authentisierung des Servers Sicherstellung einer maximalen Bearbeitungszeit Protokollierung von Vorgängen Lastverteilung zwischen mehreren Servern Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-51 Typische Angriffspunkte beim E-Commerce Anschlussleitung des Benutzers zum Internet Service Provider Systeme des Internet Service Provider Internet Backbone Anschlussleitung des Server-Betreibers Der Server selbst Das Datenbanksystem des Servers Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

27 Sicherheit des Servers Allgemeine Systemsicherheit sollte hoch sein, da Webserver ein beliebtes Angriffsziel sind Sicherheit des eigentlichen Webservers nur ausgereifte Webserver sollten verwendet werden... das reicht oft jedoch nicht Sicherheit der Erweiterungen CGI, Servlets ASP, JSP... Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-53 Sicherheit des Client Authentisierung des Servers wird selten angewandt Größte Gefahren Java Applets Scripts (JavaScript) Plug-ins Java-Applets Java Sicherheit Kein Zugriff auf Dateien Keine Netzwerkverbindung (Socket) zu anderen Systemen als dem Webserver, und dies nur aktiv Erscheinungsbild der erzeugten Fenster ist eingeschränkt kein Erzeugen eines neuen Security Manager oder Class Loader Kein Starten von Systemprogrammen Signierte Applets Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

28 Core JavaScript Allgemeine Sprachdefinition JavaScript Client Side Java Script Core JavaScript mit Objekten zur Manipulation von HTML-Code Interaktion mit dem Benutzer Eingaben HTML-Dokumente Zustand des Browsers Tastatur- und Mauseingaben Server Side Java Script Core JavaScript mit Erweiterungen Generierung von HTML-Code Anbindung and andere Serverapplikationen, z.b. Datenbanken Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin 1-55 Client Side JavaScript Security Zugriffsschutz durch Sprachdefinition Zugriff nur auf Dokumente von demselben Server Kein Zugriff auf Browser Cache und Browser History Dateiname für FileUpload kann nicht gesetzt werden Versenden von s und News nicht erlaubt Schließen von Fenstern nur mit Benutzer-Interaktion Keine versteckten Fenster oder getarnte Fenster erlaubt Maus- und Tastatureingaben sind nur zugänglich, wenn das betreffende Dokument von demselben Server stammt Zugriff auf Benutzereinstellungen (Preferences) verboten Alle Schutzmechanismen sind abschaltbar! Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin

29 Literatur zum Thema Netzwerksicherheit Charles P. Pfleeger: Security in Computing, 2nd edition, Prentice-Hall, Simon Garfinkel, Gene Spafford: Practical UNIX and Internet Security, 2nd edition, O Reilly, Andrew Tanenbaum: Computernetzwerke, Dritte Auflage, Prentice Hall, München, Vorlesung Datensicherheit Institut für Informatik Freie Universität Berlin