13.06.00 - 04.07.00 - Institut für Informatik

Transcrição

RPC - Remote Procedure Call
o
Dynamische Anmeldung neuer Dienste
å Vorgänger von DCE, CORBA, RMI, DCOM
o
Sicherheitsapekte anfangs ignoriert
o
Synchroner Funktionsaufruf
o
portmap / rpcbind auf TCP port 111
o
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
o
Früher: yp - yellow pages
o
Zentraler Server für Verzeichnisse, die von einer Menge von
Rechnern gemeinsam genutzt werden
å /etc/passwd, /etc/group, /etc/services, /etc/hosts, …
o
Diese Menge von Rechner bildet eine domain.
o
Domains werden durch Namen identifiziert.
o
Einbindung in /etc/passwd durch
root:sFr4RtfgHzjU7:0:1:admin:/:/bin/sh
-keller::2001:102:::
+::0:0:::
[ +:*:0:0::: ]
1
1-2
NIS - Network Information Service
o
Freie Verbreitung von Benutzerinformationen und
verschlüsselten Passwörter ist Grundsätzlich kritisch.
o
Syntax der Erweiterung von /etc/passwd ist fragwürdig.
o
Wie bei vielen anderen Verzeichnisdiensten: Einspeisen
falscher Daten möglich.
o
Kommunikation über RPC
o
Verbesserung: NIS+
å nur verschlüsselte Authentisierung bei RPC
å Für große Organisationen geeignet
1-3
Kerberos
o
Entwickelt am MIT, frei verfügbar
o
Server speichert Passwörter verschlüsselt, kann sie aber
entschlüsseln.
o
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.
o
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.
2
1-4
Kerberos Ticket Granting Ticket
o
TGT enthält
å Session key
å Ticket für Ticket Granting Service verschlüsselt mit dem Session key
und dem TGS key
o
Mit dem TGT können beim TGS tickets für verschiedene
Dienste angefordert werden, z.B. für entfernten Dateizugriff.
o
Ein Dateizugriffsticket enthält verschlüsselt den
Benutzernamen, seine Gruppenrechte, seine Internetadresse
und ein Ablaufdatum.
o
Bei jedem Zugriff auf entfernte Dateien muss das Ticket
mitgeliefert werden.
1-5
Eigenschaftten von Kerberos
o
Passwörter werden nur auf dem Server gespeichert und nicht
über das Netz übertragen.
o
Der Server ist ein Sicherheitsrisiko, das er die gespeicherten
Passwörter entschlüsselt kann und muss.
o
Installationsaufwand ist hoch, da alle sicherheitsrelevanten
Dienste modifiziert werden müssen.
3
1-6
NFS - Network File System
o
Transparente Nutzung von Festplatten und anderen
Datenspeichern über das Netz
o
Server bietet Datenspeicher an.
o
Client greift über NFS darauf zu.
o
Entwickelt von Sun, erste Version (2): 1985
o
Version 3 seit 1996
1-7
Eigenschaften von NFS
o
Server ist zustandslos
å kann neu gebootet werden - Client wartet solange
o
Zugriff über File Handles
å file system identifier
å file identifier
å generation count
o
Kombination von mount-Protokoll
und dem eigentlichen NFS-Protokoll
o
Protokolle setzt auf RPC auf
4
1-8
mount-Protokoll
o
Server: mountd oder rpc.mountd
o
Anfragen:
NULL
MNT
Tut gar nichts
Liefert File Handle für Dateisystem,
registriert Anfragenden
DUMP
Liefert Liste der gemounteten Dateisysteme
UMNT
Löscht Registrierung des Anfragenden
UMNTALL dito für alle vom Anfragenden gemounteten
Dateisysteme
EXPORT
Liefert die Exportliste des Servers
1-9
NFS-Protokoll
o
Dateioperationen:
GETATTR
SETATTR
READLINK
READ
WRITE
o
Liefert Dateiattribute
Setzt Dateiattribute
Liest einen Symbolischen Link
Liest Datei
Schreibt Datei
Verzeichnisoperationen:
CREATE, LINK, LOOKUP, MKDIR, READDIR, REMOVE,
RENAME, RMDIR, SYMLINK
5
1-10
NFS-Sicherheitsaspekte
o
Genauso unsicher wie zugrundeliegender RPC
o
Unverschlüsselte Übertragung von Dateien
o
Zugriffsschutz basiert auf Unix-Dateisystem
o
Sicherheit des Servers ist kritisch
å Keine Benutzer-Accounts auf Server!
o
Authentisierung des Client beruht auf IP-Adresse,
wenn sie überhaupt vorgenommen wird
o
Anfragen ganz ohne Authorisierung möglich
o
Keine Authentisierung des Servers
Garfinkel/Spafford: “For real security, don’t use NFS.”
1-11
Serversicherheit
o
Konfigurationsdatei
å /etc/exports oder /etc/dfs/dfstab
å Je NFS-Dateisystem:
•
•
•
•
•
•
•
o
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
6
1-12
SSL - Secure Socket Layer
o
Setzt auf zuverlässigem Übertragungsprotokoll auf (TCP)
o
Aushandeln des Verschlüsselungsverfahrens zwischen Client
und Server
o
Vertraulichkeit der Übertragung durch Verschlüsselung, z.B.
mit DES oder RC4
o
Optionale Authentisierung von Client und Serversystem
o
Integrität der Übertragung durch Message Authentication
Code (MAC)
o
Zwei Installationen sind nicht notwendigerweise kompatibel
o
Offen für die Integration neuer Verschlüsselungsverfahren
o
Erträgliche Übertragungsrate
1-13
SSL Record Layer
o
Vertraulichkeit
o
Authentisierung
o
Replay Protection
o
Sicherheitscheck:
å Schlüsselgeneration nicht vorhersagbar
å Unabhängige Schlüssel für jede Datenrichtung
å Neue Schlüssel für jede Verbindung
SSL Handshake Protocol
o
Schlüsselaustausch
å Initialisierung
å Synchronisierung
7
1-14
ssh - Secure Shell
o
Vollständiger Ersatz für
å telnet
å rlogin
å rsh
å rcp
å (ftp)
o
Client- und Server-Authentisierung
o
Verschlüsselte Passwort- und Datenübertragung
o
Direkte Unterstützung von verschlüsselter X11-Übertragung
o
Andere TCP-Protokolle können unterstützt werden
1-15
Sicherheit durch die Secure Shell
o
Die Secure Shell schützt vor
å IP spoofing
å Netzschnüfflern
å Abhören von Passwörtern
å Hijacking von Sitzungen
å Abhören von X11
o
Authentisierung durch RSA
o
Verschlüsselung durch verschiedene (wählbare) Methoden
å IDEA, DES, triple-DES, blowfish
8
1-16
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
o
Client generiert session key und schickt ihn dem Server,
verschlüsselt mit public host key und public server key.
o
Der Server entschlüsselt den session key.
o
Ab nun: verschlüsselte Übertragung
1-17
Protokoll der Secure Shell:
Benutzeranmeldung
o
Passwortabfrage
o
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
o
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.
9
1-18
Benutzung der Secure Shell
o
ssh
ssh
ssh
ssh
ssh
ssh
o
<entfernterRechner>
<Benutzernamer>@<entfernterRechner>
-l <Benutzername> <entfernterRechner>
<entfernterRechner> <Kommando>
<Benutzernamer>@<entfernterRechner> <Kommando>
Optionen
-c : Verschlüsselungsalgorithmus
-C : Komprimierung bei Dateiübertragung
-L : Port-Umleitung
1-19
Weitere Kommandos der Secure Shell
o
scp
å wie rcp: Kopieren von oder nach entferntem Rechner
å z.B. scp /home/quitte/datei quittek@hostx:/users/quittek/datei
o
ssh-keygen
å erzeugt privaten und öffentlichen RSA-Schlüssel
å $HOME/.ssh/identity
å $HOME/.ssh/identity.pub
o
ssh-agent
o
ssh-add
10
1-20
Verlangsamung durch
Verschlüsselung
o
Beispiel: scp-Aufrufe auf einem relativ langsamen Rechner in
einem nur leicht belasteten Ethernet
Verschlüsselung
keine
RC4
blowfish
DES
IDEA
Triple-DES
Aufsetzzeit
2,4 s
2,0 s
2,3 s
2.1 s
2,3 s
1,9 s
Datenrate
386 kB/s
318 kB/s
299 kB/s
219 kB/s
170 kB/s
118 kB/s
1-21
Nachteile der Secure Shell
o
(Noch) nicht standardisiert
o
(Noch) nicht fester Teil von Unix oder Windows
o
Installations- und Verwaltungsaufwand (host keys)
o
Reduzierter Durchsatz wegen Verschlüsselungsaufwand
o
Unterstützung weitere Dienste (z.B. ftp) umständlich
o
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.
11
1-22
Weiteres zur Secure Shell
o
Geschätzt: 3 Millionen Benutzer
o
Geschütztes Markenzeichen
å SSH Communications Security Corporation
o
Protokoll frei verfügbar
å Standardisierung durch IETF im Gange
o
Neues Protokoll: ssh2
å neuer, saubererer Entwurf
å bessere Integration von ftp
å nicht kompatibel zu ssh1
å Implementationen mit ‘fall back’ zu ssh1
1-23
E-mail
o
Zusammen mit WWW meist genutzter Internet-Dienst
å 1997: 270 Milliarden E-mails
o
E-mail-Agenten
å Benutzer-Agent
å Transport-Agent
å Filter-Agent
å Speicher-Agent
o
SMTP - Simple Mail Transfer Protocol (RFC 821)
å Adressierung und Versand
o
Formatierung der E-mail (RFC 822)
o
E-mail-Listen
12
1-24
Aufbau des E-mail-Systems
o
Benutzer-Agent
å Sender und empfängt E-mail nach Benutzer-Interaktion
o
Transport-Agent
å Ist zuständig für die Zustellung von E-mail
o
Speicher-Agent
å Speichert E-mails bis sie vom Empfänger entgegengenommen und
gelöscht werden
o
Filter-Agent
å Verhindert Weiterleitung unerwünschter E-mail
å Ändert Adressierung
å Sendet automatische Antworten
1-25
Aufbau des E-mail-Systems
BenutzerBenutzerAgent
Agent
BenutzerBenutzerAgent
Agent
FilterFilterAgent
Agent
SMTP
POP, IMAP
TransportTransportAgent
Agent
FilterFilterAgent
Agent
TransportTransportAgent
Agent
SMTP
FilterFilterAgent
Agent
SMTP
13
FilterFilterAgent
Agent
?
SpeicherSpeicherAgent
Agent
1-26
SMTP
Simple Mail Transfer Protocol
o
Definiert durch RFC 821
o
Kommunikation zwischen einem Client, der eine E-mail
zustellen möchte und einem Server, der dies tun soll.
o
Wichtige SMTP Kommandos:
å HELO
å MAIL FROM:
å RCPT TO:
å VRFY und EPND
å DATA
å QUIT
Identifizierung des Clients
Identifizierung des Senders der E-mail
Einer oder mehrere Empfänger der E-mail
Zustellbarkeit einer Adresse prüfen
Beginn der Übertragung der eigentlichen E-mail
Beenden der Verbindung
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]
14
1-28
SMTP-Sitzung, Beispiel 1
telnet example.com 25
220 mail.example.de ESMTP Sendmail 8.10.1/8.10.1; Mon, 26
Jun 2000 08:10:00 +0200 (CEST)
HELO test
250 mail.example.de Hello test [1.1.1.1], pleased to meet you
VRFY kunz
250 kunz User [email protected]
QUIT
221 mail.example.de closing connection
VRFY kunz
550 kunz... User unknown
VRFY kunz
252 Cannot VRFY user; try RCPT to attempt delivery
1-29
telnet example.de 25
Jun 2000 08:11:00 +0200 (CEST)
HELO test
MAIL FROM: <[email protected]>
250 [email protected] ok
RCPT TO: <kunz>
DATA
354 Enter mail, end with "." on a line by itself
From: [email protected]
To: kunz
Subject: Hallo
Hallo Kunz, bis bald.
.
250 e5PL2kR19462 Message accepted for delivery
QUIT
221 mail.example.com closing connection
15
1-30
telnet example.de 25
Jun 2000 08:12:00 +0200 (CEST)
HELO test
MAIL FROM: <[email protected]>
RCPT TO: <[email protected]>
250 [email protected] denied
QUIT
221 mail.example.com closing connection
1-31
Formatierung der E-mail (RFC 822)
o
Einige Felder des E-mail-Kopfes:
To
Cc
Bcc
From
Sender
Subject
Date
Received
Reply-To
Message-Id
E-mail Adressen und Optional Namen der Empfänger
Durchschriftenempfänger
Durchschriftenempfänger, unsichtbar für andere Empfänger
Autor
Absender
Betreff
Lokales Datum und lokale Uhrzeit
Transportvermerk, eine Zeile je Transport-Agent
Antwortadresse
global eindeutige Identifikation dieser einzelnen E-mail
16
1-32
Beispiel einer E-mail
Return-Path: <[email protected]>
Received: from tokyo.ccrle.nec.de ([email protected] [192.168.100.30])
by kyoto.berlin.ccrle.nec.de (8.9.3/8.9.3) with ESMTP id WAA05037
for <[email protected]>; Sun, 25 Jun 2000 22:59:33 +0200
From: [email protected]
Received: from test (yamato1.berlin.ccrle.nec.de [192.168.100.29])
by tokyo.ccrle.nec.de (8.10.1/8.10.1) with SMTP id e5PL2kR19462
for <quittek>; Sun, 25 Jun 2000 23:03:19 +0200 (CEST)
Date: Sun, 25 Jun 2000 23:03:19 +0200 (CEST)
Message-Id: <[email protected]>
To: [email protected]
Subject: Tach
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 E-mail
lokale eindeutige Identifikation der E-mail
Adresse, die mit dem RCPT TO-Kommando angegeben wurde
lokales Datum und Uhrzeit des Empfangs der E-mail
17
1-34
Gefälschte Absender
o
Alle Felder des E-mail-Kopfes können falsch sein.
o
Ausnahme: Die (oberen) Received-Felder der letzten als
zuverlässig eingestuften Transport-Agenten.
o
Das Format der Received-Felder kann variieren.
o
Eine Übereinstimmung zwischen dem Adressaten im E-mailKopf und dem durch RCPT TO spezifizierten Empfänger muss
nicht vorliegen.
o
Gleiches gilt für das From-Feld und den durch MAIL FROM
spezifizierten Autor.
o
Authentisierung von E-mails z.B. durch PGP ist anzuraten.
1-35
Spam
o
Große Mengen unverlangt zugesandter E-mail.
å Unsolicited Commercial Email (UCE)
å Unsolicited Bulk Email (UBE)
o
Kostet den Empfänger Online-Zeit, Speicherplatz, Arbeitszeit.
o
Erster Fall in der Mitte der 70er Jahre.
o
1994: Zwei Green Card-Anwälte verschickten Werbung an
über 6000 news groups.
o
Große Mailing-Listen und beliebte News Groups ersparen dem
Sender von Spam viel Zeit und Übertragungskosten
o
Gleiches gilt für Transport-Agenten, die als Relais arbeiten.
18
1-36
Typische Spam-Inhalte
Untersuchung der Federal Trade Commission 1998
(Analyse von 250.000 E-mails)
å Geschäftsgelegenheiten mit Gebühr (Pyramiden-Schema)
å Making Money by Sending Bulk Emailings
å Kettenbriefe
å Heimarbeitsangebote
å Gesundheits- und Diätenangebote
å Pläne und Angebote für leicht verdientes Geld
å Investitionsangebote
å Kreditangebote
å Touristikangebote
1-37
Verhaltensempfehlung beim
Empfang von Spam
o
Nicht aggressiv über Belästigung beschweren. Das trifft oft
den falschen.
o
Keine Anleitungen befolgen, die versprechen, daß man danach
keine E-mails aus dieser Quelle erhält. Diese Bestätigen dem
Sender den Empfang und die geweckte Aufmerksamkeit.
o
Berichten an den Administrator der Quelle.
o
Installation von Spam-Filtern.
19
1-38
Bekämpfung von Spam
o
Abschalten der Relais-Funktion in Transport-Agenten
o
Blacklisting und Blackholing von Spam-Quellen und
offenen Relais
å Mail Abuse Protection System (MAPS)
å Realtime Blackhole List (RBL)
o
Installation und Benutzung von Mail-Filtern.
å eingebaut in Benutzer-Agent
å Unabhängiger Filter, z.B. procmail
1-39
Transport-Agent Sendmail
o
Von Eric Allman, UC Berkeley, seit 1980
o
90% aller Transport-Agenten sind Sendmail oder SendmailVarianten von Dritten.
o
Ständige Aktualisierung und Stopfen von Sicherheitslücken
o
Aktuelle Version: 8.10.0, 8.10.1, 8.10.2 je nach Betriebssystem
o
Alternativen:
å qmail, exim, Post.Office, pmdf, smail
o
Konfiguration
å sendmail.cf
å /etc/aliases
å $HOME/.forward
20
1-40
Weitere Sicherheitsaspekte von E-mail
o
Abhören von E-mails
å Übertragung im Klartext
o
Abfangen von E-mails
å gefälschte MX Records
å Manipulation von Konfigurationsdateien der Transport-Agenten
o
Denial of Service-Angriffe durch Überlastung von TransportAgenten
å Große E-mails
å Große Mengen von E-mails
å E-mail-Schleifen
o
Verstecken von Namen sendender Rechner durch sendmail
1-41
HTTP - Hypertext Transfer Protcol
o
Wird verwendet seit 1990
o
1996 erste öffentliche Spezifikation durch RFC 1945
å HTTP/1.0, frühere Version unter HTTP/0.9 bekannt.
o
Standardisiert in Version HTTP/1.1 durch RFCs 2068 und 2616
o
Einfaches und schnelles Protokoll
o
Kommunikation zwischen Benutzeragenten (meist Browser),
Proxies, Gateways und Servern
o
Anfrage-Antwort-Schema
21
1-42
HTTP-Anfragen
o
GET
å Anfrage nach einer Datei
å Erwarte diese geschickt zu bekommen
å Angabe der Protokollversion
å GET /dateien/123.html HTTP/1.0
o
HEAD
å wie get, jedoch ohne Dateitransfer
o
POST
å Daten senden
o
PUT (HTTP/1.1)
o
DELETE (HTTP/1.1)
1-43
HTTP/1.0-Antworten
200
201
202
204
301
302
304
400
401
403
404
500
501
502
OK
Created
Accepted
No Content
Moved Permanently
Moved Temporarily
Not Modified
Bad Request
Unauthorized
Forbidden
Not Found
Internal server Error
Not Implemented
Bad Gateway
503
Service Unavailable
22
1-44
HTTP-Nachrichtenköpfe
o
Der Kopf einer Anfrage darf folgende Felder enthalten:
å Authorization - Übergabe eines Passworts o.ä.
å From - Angabe der E-mailadresse des anfragenden Benutzers
å If-Modified-Since - Macht get conditional
å Referer - Angabe, woher der Link kam
å User-Agent - Angabe von Produkt und Versionsnummer
o
Der Kopf einer Antwort darf folgende Felder enthalten:
å Location - eine URL
å Server - Angabe von Produkt und Versionsnummer
å WWW-Authenticate - Aufforderung zur Authorisierung
1-45
HTTP-Datenübertragung
o
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
o
Je nach Art der Nachricht können Felder erforderlich, optional
oder nicht vorgesehen sein.
23
1-46
HTTP-Authentisierung
o
Nur Authentisierung des Client vorgesehen
o
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.
o
Art der “challenge” ist nicht durch HTTP festgelegt.
1-47
HTTP-Sicherheitsprobleme
o
Persönliche Daten auf Web-Servern
å Mißbrauch von Server Log-Dateien
å Refer-, From- und User-Agent-Feld
o
Vertraulichkeit bei der Datenübertragung
å Klartextübertragung
å Passwörter in URI (URL)
o
Dateisicherheit auf Server
å Pfadnamen außerhalb des Serverbereichs abblocken!
o
Große Abhängigkeit von DNS-Dienst
o
Falsche Proxies und Caches
o
Trennung unterschiedlicher logischer Server auf einem
Physischen ist oft kritisch bei der Implementierung des Servers
24
1-48
S-HTTP: Secure HTTP
o
“SSL fuer HTTP”
o
HTTP-Erweiterung für
å Vertraulichkeit durch Verschlüsselung (symmetrisch und unsymmetr.)
å (Server-) Authentisierung
å Digitalen Signatur
o
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
o
Verhandlung der Kommunikationspartner über das
Verschlüsselungsverfahren
1-49
Sicherheit von
HTTP-Anwendungen
o
Geschützt werden soll
å der Server (Webserver)
å der Client (Browser)
å die Datenübertragung
o
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
25
1-50
Mögliche weitere
Sicherheitsanforderungen
o
Authentisierung des Benutzer
o
Authentisierung des Servers
o
Sicherstellung einer maximalen Bearbeitungszeit
o
Protokollierung von Vorgängen
o
Lastverteilung zwischen mehreren Servern
1-51
Typische Angriffspunkte
beim E-Commerce
o
Anschlussleitung des Benutzers zum Internet Service Provider
o
Systeme des Internet Service Provider
o
Internet Backbone
o
Anschlussleitung des Server-Betreibers
o
Der Server selbst
o
Das Datenbanksystem des Servers
26
1-52
Sicherheit des Servers
o
Allgemeine Systemsicherheit
å sollte hoch sein, da Webserver ein beliebtes Angriffsziel sind
o
Sicherheit des eigentlichen Webservers
å nur ausgereifte Webserver sollten verwendet werden
å . . . das reicht oft jedoch nicht
o
Sicherheit der Erweiterungen
å CGI, Servlets
å ASP, JSP
å. . .
1-53
Sicherheit des Client
o
Authentisierung des Servers wird selten angewandt
o
Größte Gefahren
å Java Applets
å Scripts (JavaScript)
å Plug-ins
o
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
27
1-54
JavaScript
o
Core JavaScript
å Allgemeine Sprachdefinition
o
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
o
Server Side Java Script
å Core JavaScript mit Erweiterungen
• Generierung von HTML-Code
• Anbindung and andere Serverapplikationen, z.B. Datenbanken
1-55
Client Side JavaScript Security
o
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 E-mails 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
o
Alle Schutzmechanismen sind abschaltbar!
28
1-56
Literatur zum Thema
Netzwerksicherheit
o
Charles P. Pfleeger: “Security in Computing”, 2nd edition,
Prentice-Hall, 1997.
o
Simon Garfinkel, Gene Spafford: “Practical UNIX and
Internet Security”, 2nd edition, O’Reilly, 1996.
o
Andrew Tanenbaum: “Computernetzwerke“, Dritte Auflage,
Prentice Hall, München, 1996.
29
1-57

13.06.00 - 04.07.00 - Institut für Informatik

Transcrição

Documentos relacionados

Netzwerktechnik CHS Villach Mag. Rainer Swatek Dauer: 2

¨Ubungen zu Computergraphik I

Modul 2: Allgemeine und anorganische Chemie

"Mathematische Modelle und Methoden der Theorie der Verbrennung"

Truehouse Internet Streaming Installation

Chemische Gleichgewichte

Expectations vs. Reality Ein kleiner avant

Willkommen zum WM-Newsletter des Lehrstuhls Hefendehl vom 31

Vorkonfigurierte Server für Medienpark - silber

Herzlich willkommen