Humboldt University Computer Science Department Systems Architecture Group IT-Sicherheit Grundlagen...

Humboldt University Computer Science Department Systems Architecture Group http://sar.informatik.hu-berlin.de

IT-SicherheitGrundlagen

Sichere Implementierung

Netzwerksicherheit I: Schwachstellen & Gegenmaßnahmen

Gruppenaufgaben: Terminplan

Dr. Wolf Müller2

UE/VL Tag Gruppe ThemaVL Mi 4. 7. Marta Reyes Ojeda, Juan Manuel Leflet Estrada, Sergej Geger, Taras Iks GPU Implementations of ciphers or hash functions VL Mi 4. 7. Marco Lutz, Stephan Müller Secret Sharing/Threshold KryptografieVL Mi 4. 7. Florian Kaase, Dirk Mattes, Clemens Peter Seibold, Alexander Bobach Keyboard Sniffer reloaded UE Mi 4. 7. Kai Gärtner, Peter Witzel Analyse ChipTAN UE Mi 4. 7. D. Sander, N. Beierle, Irina Glushanok, David Salomon, Philippe Lieser SSL Cert fetcher UE Mi 4. 7.VL Mo 9. 7. Valerij Serediouk , Boris Zielinski , Uwe Reinbacher Static Analysis VL Mo 9. 7. Bastian Hauda, Denis Allen Washington, Cavan King Sicherheit von Cloud-FS XtreemFS/Tahoe-LAFSVL Mo 9. 7. Elias Rohrer, Florian Häber, Tom Grassmann, Christian Steinfeldt Advanced memory corruption techniques UE Mo 9. 7. Daniel Hartmann, Jens Bork, Christopher Schiefer Sicherheit mobiler PlattformenUE Mo 9. 7. Malte Schmidt, Tim Repke, Hendryk Köppel Keyboard Sniffer reloaded UE Mo 9. 7. Christian Palatz , Tilman Stampe, Rico Weber, Moritz von Wedel-Parlow SSL Cert fetcher

Prüfungstermine (August)

Modul(e): VL IT-Sicherheit Grundlagen

Prüfungstermin(e): Mi., 08.08.2012, Do., 09.08.2012Prüfer/in: Dr. Wolf MüllerOrt: Haus 3, Raum 327Prüfungsart: mündliche PrüfungAnmeldung: Beginn: am 01.07.2012 bis 24.07.2012

bei: Name: Frau Albrecht/ Frau SchochRaum-Nr.: Haus 3, R. 302Sprechzeiten: 10 – 16 Uhr

Abmeldung: unter: albrecht@informatik.hu-berlin.de

Dr. Wolf Müller3

Prüfungstermine (September)

Modul(e): VL IT-Sicherheit Grundlagen

Prüfungstermin(e): Mi., 12.09.2012, Do., 13.09.2012Prüfer/in: Dr. Wolf MüllerOrt: Haus 3, Raum 327Prüfungsart: mündliche PrüfungAnmeldung: Beginn: am 06.08.2012 bis 28.08.2012

bei: Name: Frau Albrecht/ Frau SchochRaum-Nr.: Haus 3, R. 302Sprechzeiten: 10 – 16 Uhr

Abmeldung: unter: albrecht@informatik.hu-berlin.de

Dr. Wolf Müller4

IT-SicherheitGrundlagenDr. Wolf Müller5

Internet

Quelle: Wikipedia: Internet

Internet-(Un)sicherheit• IT in allen privaten und geschäftlichen Lebensbereichen

präsent• Zunehmende Vernetzung zunehmende Abhängigkeit• Fragen der Informationssicherheit immer wichtiger• Bedrohungen:

– Unautorisiertes Lesen elektronischer Nachrichten– Verändern gesendeter Daten– Maskieren, Vortäuschen falscher Absenderidentität– Zerstörung von Daten– Erschleichung von Dienstleistungen– Unterbrechung oder Störung der Kommunikation– D(DOS)

Internet: Historie

• ARPA, 70-er Jahre US-Verteidigungsministerium• Protokolle:

– Internet Protocol (IP)– Internet Control Message Protokoll (ICMP)– Transport Control Protocol (TCP)

am 1.1.1983 ins ARPA übernommen = Geburtsstunde des Internets

• Kommunikation zwischen Mainframes, später PC in Militär, Regierung, Forschung– Begrenzter Teilnehmerkreis,– Kooperativ– Equipment teuer– Übertragungssicherheit im technischen Sinne wichtig

Internet: Historie (2)• Weitere Netzwerkdienste:

– für BSD UNIX entwickelt (Berkley University of Carlifornia)– Telnet– FTP– E-Mail– 1991 Gopher, erstmals GUI, Texte, Bilder, Ton

• 1993 WWW, Mosaic, CERN• Internet öffnet sich für Massenbenutzerkreis• Rascher Anstieg des Nutzerkreises,

– Etwa alle 12 – 15 Monate Verdopplung der Anzahl der angeschlossen Rechner seit 1993

• Ursprung im wissenschaftlichen Bereich, Ziel flexible Nutzung dezentrale Verwaltung– Rasante Ausweitung, nahezu unbeschränkte Möglichkeiten, Rechner

anzuschließen (zumindest mit IPv6)– Keine Basis für Kontrollmöglichkeiten, die bei der verstärkten beruflichen

und privaten Nutzung verstärkt erforderlich werden.

Internet: Situation heute

• Öffnung für breite Anwenderschaft von Nichtspezialisten– Rudimentäre Kenntnisse über Internet und damit verbundene

Gefährdungen– Anstieg der potentiellen Opfer von Computerkriminalität

• Zunehmende kommerzielle Nutzung– Wachsende Abhängigkeit– Wachsende Schadenshöhe bei erfolgreichen Angriffen

• Keine zentrale Kontrollinstanz zur Verhinderung von Missbrauch– Kenntnisse des Nutzers unabdingbar– Einsatz verfügbarer Softwareprodukte

Einteilung von Netzwerken

• Firmennetzwerke– Physisch absicherbar– Eventuell WLAN?

• Netzwerke zwischen Standorten– Kommunikationspartner kennen sich gegenseitig– Provider sichert gewissen Schutz– Eventuell Funkübertragung, LaserLink– Virtuelle Private Netzwerke

• Internet– Unvorhersehbares Routing– Authentifizierung schwierig– Keine Vertrauensbeziehungen– Kein sicherer Kanal

Sicherheit auf verschiedenenNetzwerkschichten

Belauschen von Datentransfers

• Abhängig von der Topologie des Netzwerkes und von der Art des Routings– Paketorientierte Netzwerke sind schwieriger abzuhören, da jedes

Paket potenziell eine andere Route nehmen kann.– Abhören an Knotenpunkten sinnvoll– Abhören direkt am Sender oder Empfänger, weil nur eine Leitung

vorhanden ist.– Hub besser abhörbar als Switch– Drahtlos besser abhörbar als Draht, Glasfieber– WLAN ist Hub (insbesondere WEP)

Physisches Abhören

• Abfangen der elektromagnetischen oder optischen Abstrahlung von Netzwerkkabeln

• Funknetzwerke• Richtfunk• Mobilfunk

Frequency Hopping

Frequency Hopping• Sicherheit auf Layer 1• Häufiges Wechseln der Trägerfrequenz nach nur den

Kommunikationspartnern bekanntem Muster, z.B. Pseudozufällig gewählt

• Abhörer kann nicht alle Frequenzen überwachen

Wide Spectrum Spread

• Aufteilung des Signals auf ein breites Spektrum– Signal geht im Rauschen unter– Nur Empfänger kennt richtige Chipping Codes und kann durch

„Aufintegrieren“ das Signal wieder lesbar machen– Auch Code Division Multiplex genannt

neon.tcpip-lab.edu"Neon"

128.143.71.21

argon.tcpip-lab.edu "Argon"128.143.137.144

router137.tcpip-lab.edu"Router137"

128.143.137.1

router71.tcpip-lab.edu"Router71"128.143.71.1

Ethernet NetworkEthernet Network

Router

Dr. Wolf Müller16

frame frame

ARP: MAC-Adresse von 128.143.71.21?

ARP: MAC-Adresse von 128.143.137.1 ist 00:20:af:03:98:28

ARP: MAC-Adresse von 128.143.137.1 ist 00:e0:f9:23:a8:20

DNS: IP-Adresse von “neon.tcpip-lab.edu”? ARP: MAC-Adresse von

128.143.137.1??

DNS: IP-Adresse von “neon.tcpip-lab.edu” ist 128.143.71.21

128.143.71.21 im lokalen Netzwerk.Paket kann direkt gesendet werden. 128.143.71.21 nicht im lokalen Netzwerk.

Packet muss über default gateway 128.143.137.1 gesendet werden.

Was passiert beim Senden von Argon zu Neon?

Bitübertragungsschicht

Physical layer• Herstellung einer physikalischen Verbindung zwischen zwei

direkt verbundenen Kommunikationspunkten• Übertragung von Bitströmen• Medien: Koaxial, TP, Lichtwellenleiter, Funk, Licht

Angriff: Jamming

Sicherungsschicht

Data link layer• Bündelung der Bitströme der unteren Ebene zu

Datenpaketen (frames)• Aufteilung der Pakete der darüberliegenden Ebene in

Datenpakete• Kontrollinformation (Prüfsummen)

– Fehlerkorrigierende Verfahren Cyclic Redudancy Check (CRC) CRC ist kein MAC!

– Behebung, Erkennung von Übertragungsfehlern– Behandlung beschädigter, duplizierter, verloren gegangener Frames

• Regelung des Medienzugangs • Regulierung des Datenflusses

Vermittlungsschicht

Network layer• Kontrollierte Verknüpfung von Netzwerkteilen• Ende-zu-Ende Kommunikation zwischen

Kommunikationspartnern• Vermittlung möglich auch bei:

– Unterschiedlichem Addressierungsschemata,– Verschiedenen Paketgrößen– Heterogenen Protokollen

• ROUTING– Dynamisch– Statisch

• Zuständig für Accounting

Transportschicht

Transport layer• Etablierung einer von höheren Schichten gewünschten

Verbindung– Abhängig von Datenaufkommen und Netzbelastung kann pro

Wunsch eine logische Verbindung aufgebaut werden oder zur Kostenreduzierung mehrere Verbindungen in einem Kanal gebündelt werden (Multiplexing)

• Ermöglicht Ende-zu-Ende Kommunikation zwischen einzelnen Prozessen, Diensten (TCP)

• Realisierung von zuverlässigem paketorientiertem Ende-zu-Ende Protokoll (UDP)– Darüberliegendes Protokoll macht Paketaufteilung, Reihenfolge und

Quittung• Flusssteuerung

– Verhinderung von Überlauf (Regulierung der Senderate)

Präsentationsschicht

• Presetation layer• Umwandlung der maschinenspezifischen Präsentation von

Daten in einheitliche Netzwerkdarstellung (und umgekehrt)• Fokus: Syntax und Semantik der Übertragenen Information

– Häufig Datenkompression, Verschlüsselung– ASN.1– Serialization (Java, Objects)

Anwendungsschicht

• Application Layer• Vielzahl von Protokollen

– X.400, SMTP– FATM, FTP– HTTP,– Pop– Imap– DNS

Einordnung der Protokolle in Schichten

NetworkLayer

Routing Protocols

ApplicationLayer

Data LinkLayer

ARP Ethernet

NetworkInterface

TransportLayer

TCP UDP

SNMPFTP DNSHTTP

pingapplication Telnet

Encapsulation and Demultiplexing

• Wenn sich die Daten den Protokollstack nach unten bewegen, fügt jedes Protokoll schichtabhängige Kontrollinformation dazu.

Ethernet

User data

User dataHTTP Header

TCP Header

TCP HeaderIP Header

TCP HeaderIP HeaderEthernetHeader

EthernetTrailer

IP datagram

TCP segment

Ethernet frame

User dataHTTP Header

Netzwerkkomponenten (layer 1)

• Repeater– Erhöhung der Signalreichweite, Verstärkung– Vergrößerte Kollisionsdomäne bei Broadcastmedien

• Hub– Multiportrepeater– Verbindung mehrerer Netze– Eingehende Signale werden aufbereitet und an alle aktiven Ports

weitergeleitet– Keine Kontrollfunktion– Sniffen einfach, Ethernetzkarte im Promiscous-Mode (tcpdump,

ngrep)

Netzwerkkomponenten (layer 2)• Bridge

– Verbindung von Netzen auf Data-Link Layer– Weiterleitung von Datenframes an MAC-Addressen – Verwaltet Tabelle über bekannte MAC-Addressen– Kann unterschiedliche Medien verbinden.– WLAN-Access Point– Trennt Kollisionsdomänen, sonst aber nur begrenzte Kontrolle– Weiterleitung von Broadcasts in angeschlossene Netzsegmente

• Switch– Multiport Bridge– Filterung der Pakete nach MAC-Adressen– ARP Cache (Zuordnung IP – MAC)– Datenpakete nicht generell als Broadcast– Ziel: Erhöhung der Bandbreite– Sniffen schwerer, aber nicht unmöglich

Maskierungsangriffe auf ARP-Cache (Angreifer schickt ARP Nachricht an Sender, dass sich MAC von X geändert hat, gibt seine eigene MAC als neue an.

Antworten auf ARP-Request für X mit eigener MAC Weiterleitung per IP-Forwarding an eigentlichen Zielrechner Fälschung der eigenen MAC ethercap

Netzwerkkomponenten (layer 3)

• Router– Verbindung von Netzen auf der Schicht 3– Wegewahl für Pakete der Ebene 3 (im Internetkontext IP)– Können Kontroll- und Filterfunktionen wahrnehmen

Einfache Paketfilter, Firewalls können durch Router realisiert werden

• Gatway– Verbindung unterschiedlicher Typen– IP mit GPRS

Internet-Protokoll IP

Aufgaben der Netzwerkschicht• Paketvermittelnder, verbindungsloser Dienst• Keine Bestätigung für Erhalt von Paketen• Man spricht von unzuverlässigen Dienst• Max. Länge 65.535 Byte

– Fragmentierung je nach Netzwerkinfrastruktur– Ethernet 1.500 Byte– Jedes Fragment besitzt IP-Header + Teil der ursprünglichen Daten

• Keine Maßnahmen für vollständigen Erhalt oder richtige Reihenfolge oder Erhalt überhaupt

IP-Addresse, physikalische Addresse

• IP-Adresse 32-Bit: 141.20.20.55• Oft Domänenname verwendet:

– www.informatik.hu-berlin.de– Zuordnung über DNS, hosts

• Physikalische Adressen (für Geräte aus 1. und 2. Schicht)– Jedem Rechner / Netzwerkinterface physikalische Adresse

zugeordnet– 48 Bit (oft HEX 08:00:20:fa:03:e4)– Erste 24 Bit Hersteller (Sun)– Zuordnung eindeutig– Aber leicht zu ändern (Driver ifconfig, Karten-Bios, Vmware,

Hardwarebrücke)

Aufbau eines IP-Pakets

• Dynamic Host Configuration Protocol– Dynamisch Zuordnung von IP-Addressen– RFC 2131, 2132– Client fragt mit Broadcast nach eindeutiger IP– Alle DHCP-Server, die diese Nachricht empfangen antworten mit

Adressen-Angebot– Client nimmt erstes Angebot, fordert über Request-Nachricht diese

IP-Adresse an– Vergebender Server macht dies durch Acknowledgment bekannt– Lease nur beschränkte Zeit gültig– Weitere Informationen zum Netzwerk können übermittelt werden.

DNS Gateway Nextserver WINS

Sicherheitsproblem: Spoofing

• Authentizität:– Häufigste Angriffe:

Address Spoofing– Angreifer maskiert und

unter falscher Identität– Ansatzpunkt: MAC-, IP-

Adressen in Ethernet-,IP-Paketen, insbesondere Absender, DNS-Namen

ARP-Spoofing

• ARP-Spoofing nutzt Designschwäche ARP im ARP-Protokoll (zustandslos)

• Jeder Host hat eigenen ARP-Cache, wo (MAC,IP)-Adressenpaare verwaltet werden.

• ARP-Spoofing “vergiftet” diesen Cache durch Senden gefäschter ARP-Replies

ARP-Spoofing

Host A192.168.0.2

00-E0-F0-25-41-7E

Host B192.168.0.3

00-00-1C-9E-69-30

Attacker 192.168.0.4

00-E0-DA-8B-B4-05

192.168.0.3 is at 00-00-1C-9E-69-30 192.168.0.4 is at 00-E0-DA-8B-B4-05

192.168.0.2 is at 00-E0-F0-25-41-7E192.168.0.4 is at 00-E0-DA-8B-B4-05

192.168.0.2 is at 00-E0-F0-25-41-7E192.168.0.3 is at 00-00-1C-9E-69-30

ARP-Spoofing

Host A192.168.0.2

00-E0-F0-25-41-7E

Host B192.168.0.3

00-00-1C-9E-69-30

00-E0-DA-8B-B4-05

192.168.0.3 is at 00-00-1C-9E-69-30 192.168.0.4 is at 00-E0-DA-8B-B4-05

192.168.0.2 is at 00-E0-F0-25-41-7E192.168.0.3 is at 00-00-1C-9E-69-30

192.168.0.3 is at 00-E0-DA-8B-B4-05

ARP-Spoofing

Host A192.168.0.2

00-E0-F0-25-41-7E

Host B192.168.0.3

00-00-1C-9E-69-30

00-E0-DA-8B-B4-05

192.168.0.3 is at 00-E0-DA-8B-B4-05192.168.0.4 is at 00-E0-DA-8B-B4-05

192.168.0.2 is at 00-E0-F0-25-41-7E192.168.0.3 is at 00-00-1C-9E-69-30

ARP-Spoofing

Host A192.168.0.2

00-E0-F0-25-41-7E

Host B192.168.0.3

00-00-1C-9E-69-30

00-E0-DA-8B-B4-05

192.168.0.3 is at 00-E0-DA-8B-B4-05192.168.0.4 is at 00-E0-DA-8B-B4-05

192.168.0.2 is at 00-E0-F0-25-41-7E192.168.0.3 is at 00-00-1C-9E-69-30

ARP Spoofing

• Alle von A nach B gesendeten Pakete werden über den Angreifer geleitet, der sie an B weiterleitet.

• Rückweg kann in gleicher Weise manipuliert werden. • Erlaubt „Man in the Middle Attack“• Kann lokal automatisch gestartet werden mit Tools

wie: dsniff oder ettercap.

ARP Spoofing - Gegenmaßnahmen

• Statische Einträge in ARP-Cache beugen ARP-Spoofing vor

• Funktioniert nicht MS OS's (Wird „static” eingetragen, aber trotzdem durch Replies überschrieben)

• Netzwerk ist unflexibler, aber zumindest die MAC des Gateways sollte statisch funktionieren

• IDS (intrusion detection system): Angriffe dieser Art sind offensichtlich und leicht zu erkennen

• Tool: arpwatch

Sicherheitsprobleme von IP: Spoofing (2)

Router

Angreifer Rechner10.0.42.1

interner Rechner141.20.20.131

Internet

gespoofter Rechner141.20.20.2

141.20.20.2 141.20.20.131 …Absender Empfänger

Beispiel 1: Trusted Hosts

• Unix (trusted host) ziel.de• /etc/hosts.equiv, .rhosts:

– freund.de• rlogin, rsh möglich ohne Passwort• Rechner mit Berechtigungen für NFS-Freigaben

Beispiel 2: DoS

Denial of Service:• Öffentliche Beachtung ab 2000,

Angriffe auf Yahoo, Amazon, eBay• Finanzielle Abhängigkeit von

Erreichbarkeit• Details:

– Zombie-Rechner unter vollständiger Kontrolle des Angreifers

– Bei Startkommando Angriff– Auch DDoS genannt

• Abwehr:– Ermittlung der Adressen aller Zombie-

Rechner, blockieren jeglichen Verkehrs von diesen

– Abwehr zunehmend schwierig, da sehr dynamisch

Beispiel 2.1: UDP-flood Angriff

• Basiert auf UDP-Diensten• UDP-Paket mit gefälschter Absender-Adresse an Opfer• Verbindung mit Dienst chargen, den das Opfer zur

Zeichenerzeugung anbietet• Opfer sendet nun Strom von Zeichen an gespooften

Absender, beide werden gelähmt

Beispiel 2.2: Smurf-Angriff

• Angreifer sendet Strom von ping Packeten (ICMP) mit gefälschter Absender-Adresse (alice.victim.com) an IP-Broadcast Adresse von stooge.com

• Alle Rechner aus dem Netz von stooge.com antworten an alice.victim.com

Smurf-Angriff: Gegenmaßnahmen

• ICMP deaktivieren (nur bedingt möglich und sinnvoll)• IP-Broadcast am Router deaktivieren

– Problem DDoS: nicht ein Angreifer sondern sehr viele Angreifer, die nicht Broadcast sondern verschiedene Rechner verwenden, oder Alice direkt angreifen

Beispiel 2.3: SYN-flood-Angriff• TCP 3-Wege Handshake zum Verbindungsaufbau• SYN Flooding

• Solange „halboffene“ TCP-Verbindungen aufbauen, bis Ressourcen des angegriffenen Systems verbraucht sind

Alice Bob

SYN SeqNr=x

SYN SeqNr=y; ACK x+1

ACK y+1

Mallet Bob

SYN SeqNr=x

SYN SeqNr=y; ACK x+1

SYN SeqNr=z

SYN SeqNr=a

SYN-Flood-Verletzlichkeit der Betriebssysteme

• Minimale Anzahl von SYN Paketen für erfolgreichen DoS Quelle: [Chang 02]

• Wiederholung von „verlorenen“ SYN Paketen:– Exponential Backoff zur

Berechnung der Wartezeit Linux und W2K

(3s, 6s, 12s, 24s,....) BSD

6s, 24s, 48s, ....)– Abbruch des Retransmit

W2Knach 2 Versuchen (d.h. nach 9 Sekunden)

Linux nach 7 Versuchen (d.h. nach 381 Sekunden)

BSDnach 75 Sekunden

SYN-flood-Angriff: Gegenmaßnahmen

• Timer definieren– Falls ACK nicht innerhalb dieser Zeitspanne erfolgt, Ressourcen

wieder freigeben– Nutzt nur bedingt

• Falls alle Ressourcen belegt zufällig eine halboffene Verbindung schließen– Nutzt nur bedingt

• Maximale Anzahl gleichzeitig halboffener Verbindungen pro Quell-Adresse festlegen– Problem DDoS

Prinzipielle Unterscheidung zwischen legitimer Nutzung und Angriff nicht möglich.

Sicherheitsproblem: Vertraulichkeit

• Weder Nutzdaten noch Verwaltungsdaten (Header) eines IP-Pakets vor Übertragung verschlüsselt

• Liegen auf allen Kommunikationsverbindungen und in allen Vermittlungsstellen im Klartext vor– Passworte für Remote-Login– Vertrauliche Firmendaten– Personenbezogene vertrauliche Daten

• Verkehrsflussanalysen (aus Sende- / Empfangsadressen werden Zugriffs- und Kommunikationsprofile erstellt.Keine Anonymität.

Sicherheitsproblem: Integrität

• IP-Protokoll stellt keine Mechanismen wie Hashfunktionen oder Message Authentication Codes für Nutzdaten zur Verfügung

• Keine Möglichkeit, Modifikationen zu erkennen und derartige Angriffe abzuwehren.– CRC nur für Bitübertragungsfehler, – Angreifer kann korrekte CRC berechnen und in das Datenpaket

integrieren

Sicherheitsproblem: Verbindlichkeit

• Identifikation der Kommunikationspartner anhand der im IP-Paket eingetragenen, nicht fälschungssicheren IP-Adresse

• Keine weiteren Maßnahmen wie digitale Signaturen, um Daten den absendenden Prozessen oder Benutzern zuzuordnen

• Konsequenz:IP-basierte Aktionen sind ohne zusätzliche Maßnahmen nicht verbindlich!

Beispiel 1: Routing Angriffe

• Zur Wegwahl Routing-Protokolle– Meist symmetrisch

• Optionsfeld des IP-Pakets:– Strict Source Routing (Sender trägt IP-Adressen alle

Zwischenstationen in korrekter Reinfolge ein, diese müssen direkt verbunden sein)

Kenntnisse über Netzinfrastruktur nötig– Loose Source Routing (Sender trägt Zwischenstationen ein, diese

müssen nicht direkt miteinander verbunden sein)• Angreifer trägt eigene IP in die Route ein, damit

zurückgesendete Pakete über seinen Rechner geleitet werden, Information extrahiert werden kann.

Beispiel 1: Routing Angriffe (2)

• Routing Information Protocol (RIP)– Propagiert Routing-Information im Netzwerk– Typischer Weise überprüft Empfänger diese Information nicht

Angreifer M kann Kommunikation zwischen A und B über eigene Maschine umleiten

M simuliert A und sendet manipulierte RIP Pakete an B und an die zwischen M und B liegenden Gateways

Darin werden B und alle Gateways aufgefordert, an A gerichtete Pakete zum Rechner M zu senden.

Nach Auswertung durch M, Weiterleitung an A. Mit Option Source Routing kann M erreichen, dass auch Antwortpakete

bei ihm vorbeikommen.

• Abwehr: Konfiguration der Router, so dass Änderungen von Routen nur unter speziellen Bedingungen möglich sind.

Sicherheitsprobleme von ICMP

• Internet Control Message Protocol: Übermittlung von Fehler- und Statusmeldungen– Fehler:

Nichterreichbarkeit (destination unreachable)

Aufforderung zur Fragmentierung (fragmentation needed)

– Status: Umleitung bei Stau ICMP-redirect Drosseln des Senderate des potentiellen Verursachers

(ICMP-source quench)

Angriffe mit ICMP

• Abbruch der Verbindung– destination unreachable + Packet-Header des zu

vermittelnden Pakets Sendestation erkennt, welche Verbindung terminiert werden soll (Port) Ältere Implementationen beenden alle Verbindungen

• Erhöhung der Netzlast– fragmentation needed

• Gezielte Umleitung von Paketen– redirect

• ping of death– ICMP-Ping mehr als 65.510 Byte– veraltet

• Domain Name Service• Abbildung von Namen auf IP-Adressen

– sar.informatik.hu-berlin.de -> 141.20.23.63• Reverse DNS Lookup = Abfrage in entgegengesetzter

Richtung• Warum Namen?

– Besser zu merken– Strukturierung

Länder .de .fr Art .com .biz .org .edu

• Abbildung ist nicht eineindeutig– Aliases (mehrere Namen für eine IP-Adresse)– Load-balancing, dyn-DNS: variable IP für festen Namen

DNS Datenbanken

• DNS-Server verwaltet 2 Datenbanken – Reverse-Zonen Datenbank

Zuordnung IP-Adressen -> Domänennamen Verwendet bei rlogin, mount

– Forward-Zonen DatenbankZuordnung Domänennamen -> IP-Adressen

Verwendet zum Verbindungsaufbau• Zur Erhöhung der Verfügbarkeit und Performance werden

diese Datenbanken repliziert, es gibt jedoch „primären DNS-Server“

• DNS-Anfrage (an Port 53) wird zum DNS-Server gesandt der diese aus der eigenen Datenbank, den Cache oder durch Weiterleitung beantwortet wird– Angriffspunkt

Sicherheitsprobleme von DNS

• DNS basiert auf unzuverlässigen, verbindungslosem UDP• DNS-Spoofing:

– Angriffe, bei der Angreifer Zuordnung zwischen IP-Adresse und Domän-Namen fälschen.

• Caching-Problem– Ältere Server akzeptieren auch nicht angeforderte Daten

DNS Spoofing

• Ausnutzung von Schwachstellen im DNS• Ziel: Angreifer A täuscht vor, ein bestimmter (Web-) Server

zu sein.• Opfer greift dann auf „Fälschung“ zu• Dadurch können sensible Informationen beispielsweise

Passwörter o. ä. Zugangscodes ermittelt werden• Bsp.: DNS Spoofing eines Internetbanking Servers• Idee: Einpflanzung einer falschen IP-Adressauflösung für

einen bestimmten Hostnamen• DNS-Anfrage für diesen Host liefert dann die falsche IP-

Adresse (des Angreifers) zurück (bis DNS-Eintrag expired und die Tabelle wieder abgeglichen wird)

DNS Spoofing (2)

Möglich, weil:• Adressinformationen nicht zentral, sondern verteilt gehalten

und über Netzwerk ausgetauscht werden;• Aufgelöste Adressen im Cache des DNS-Servers bzw. des

Clients gehalten werden; erneute Zugriffe geben so weiterhin die Fälschung zurück;

• Authentizität der übermittelten Einträge nicht geprüft werden kann

DNS Spoofing

DNS Spoofing (2)

DNS Spoofing (3)

DNS-Cache-PoisoningDNS-Server1

DNS-Cache

Nutzer

1. Request IP für www.k.de

2. Weiterleiten der Anfrage

DNS-Server fürwww.k.de

Angreifer5.6.7.8

DNS-Server1

DNS-Cache

www.x.com 1.2.3.4

3. Antwortwww.k.de 5.6.7.8www.x.com 5.6.7.8

DNS-Cache-Poisoning (2)DNS-Server1

DNS-Cache

Nutzer

5. Request IP für www.x.com

DNS-Server fürwww.k.de

Angreifer5.6.7.8

DNS-Server1

DNS-Cache

www.x.com 1.2.3.4www.k.de 5.6.7.8www.x.com 5.6.7.84.

6. Response 5.6.7.8

7. Login www.x.com BenutzerPassword

DNS: Fazit

• Authentifizierung mit IP-Adressen oder Domännamen ist unzureichend.

• Abwehr– Signierte Antworten von DNS-Servern

Problem: Verifikation, PKI nötig, Dezentralität noch umsetzbar?– Speicherung der gestellten Fragen durch DNS-Server, exakter

Abgleich mit eingehenden Antworten

– DNSSec http://www.dnssec.net/Schutz gegen:

Bösartige DNS-Administratoren Netzwerkprotokollangriffe DNS-Cache poisoning

– Sicherheits-Erweiterungen sind noch wenig verbreitet!

• Network File System (NFS) • 1984 durch Sun Microsystems entwickelt• Client / Server –Modell• In Version 2 und 3 zustandslos• Version 2: UDP• Version 3: Unterstützt TCP• Weit verbreitet• Erst Version 4: Von AFS beeinflusst, beinhaltet

Sicherheitserweiterungen

NFS (2)

• Server:/etc/exports legt fest, welche Rechner zugreifen dürfen, welche Zugriffe zulässig sind./NETBOOT *(ro,no_root_squash,sync)

/tmp a(rw,no_root_squash,sync) b(rw,no_root_squash,sync) exportfs –a exportiert die Verzeichnisse

• Client:showmount rechnername listet exportierte Verzeichnisse, diese werden z.B. mit mount –t nfs server:/tmp /my_tmp in das lokale Dateisystem eingebunden.

NFS-Client NFS-Server

Dr. Wolf Müller76

NFS: Mounten

mount mountd

Anwen-dung nfsd

1. Mount-Anforderung

4. Dateihandle übergeben

3. Dateihandle2. Dateihandleanfordern

5. Direkter Zugriff: - Lesen - Schreiben

NFS: Zugriffskontrolle

• Unterscheidung zwischen Berechtigung zum Mounten und Zugriff auf einzelne Dateien innerhalb des Dateisystems (lesend, schreibend, ausführend)

• Client: Mount-Request• Anhand der Mount-Beschränkungen prüft Server, ob Client

zum Mounten berechtigt ist, erzeugt File Handle für Wurzelverzeichnis, sendet dieses zurück an Client.

• Kontrolle der tatsächlichen Dateizugriffe basiert auf der Zugriffskontrolle von UNIX (auf dem Client), und wird vom (uid,gid) realisiert, ein (Nutzer-) Password wird nicht gefordert!

• Inode spezifiziert Zugriffsrechte, falls Client berechtigt ist, erzeugt NFS-Server ein File Handle, danach wird Datei direkt geöffnet.

NFS: Zugriffskontrolle (2)

Server Z

/etc/exports /usr

Client 1

mout z:/usr /mnt

/mnt/usr

Mounten

Zugriffsrechte für /usruid 0 rwx------

Zugriffsrechte für fuid 100 rwxr--r--

NFS: Sicherheitsprobleme

• Design & Implementierungsfehler– Mount-Berechtigung: Protokoll erlaubt Mount, solange nicht

explizit verboten (Widerspricht minimalen Rechtekonzept)– Mount-Protokoll (manche Systeme): Prüfung nur zum Mount-

Zeitpunkt of Client berechtigt ist, ohne Freigabe auch selbst wenn /etc/exports geändert ist, weiter nutzbar

– Zugriffskontrolle Designentscheidung, Zugriffskontrolle zentraler UNIX-Systeme auf verteilte Umgebung zu übertragen (Client prüft Nutzeridentität), uids fälschbar.Hier existieren weitergehende Ansätze:

auth_sys, auth_kerb, auth_DH192, RPCSEC_GSS Besitzen zwar Schwächen, aber schon wesentliche Verbesserungen

– Zustandsloser Server: Keine Information über Clienten, Clienten verwalten Zugriffsausweise (File Handles). Diese werden zufällig erzeugt, aber sind statisch, werden unverschlüsselt übertragen.

NFS: Sicherheitsprobleme (2)

• Administrative Fehler:– Unbeschränkter Export eines Dateisystems: (.rhosts, .ssh)– Schreibrechte (Trojaner, s-Bit, root-Shell)

• Zugriffskontrolle Name/IP-basiert fälschbar

NFS: Version 4

• Ziel: höhere Sicherheit• Verbesserte Authentifikationsverfahren• Firewall-kompatibel: fester Port 2049

– In Version 2, 3 war über das Mount-Protokoll ein Austausch eines File Handles notwendig, Kommunikation über RPC ohne feste Portaddresse

• GSS-API: (Generic Security Services) – Verwendet RPC-SEC_GSS (RFC 2203)– GSS-API bietet darauf aufsetzenden Protokollen Sicherheitsdienste

wie: (Integrität, Authentizität, Vertraulichkeit von Nachrichten)– Authentifizierung über:

Kerberos Version 5 Public Key

• Network Information System /Yellow Pages

• Sun 80er Jahre• Verteilte Password-Datenbank, auch Schlüsseldatenbanken

für Kerberos- und Secure-RPC-basiertes NFS• Zentrale Speicherung auf NIS-Master-Server

NIS: Ablauf

• Client:– Angabe der NIS-Domian– + -Eintrag in /etc/passwd (+:Joe:*0:0:::)

• Bei Login für Joe zum Client wird Nachricht an NIS-Master gesendet, Passwortdatei angefordert

• Client führt Authentifikation auf dieser Basis durch.• NIS kann falls Secure RPC verfügbar, verschlüsselt

übertragen werden.

NIS: Sicherheitsprobleme

• Datenbankzugriff NIS gewährt jedem System, das NIS-Domänennamen kennt Zugriff auf NIS-DB (Password-Crack möglich)

• Server-Maskierung Fehlende Authentifikation des NIS-Servers, Clients senden Anfragen unter Nutzung von RPC, Echtheit der Antwort kann nicht geprüft werden.Für Angreifer ausreichend, als erster zu antworten, weitere Antworten werden Verworfen (UDP-basiert)

• Portmapper Portmapper-Dämon wird verwendet, um RPC-Dienst zu binden, Annahme von „trusted Ports“ nicht gültig für alle Portmapper-Implementationen (Angreifer ersetzt RPC-Dienste durch eigene, z.B. Trojaner)

• Fazit: NIS für offene Umgebungen ungeeignet

Probleme der Internetprotokolle

• Vertraulichkeit• Authentizität der Absender / Empfänger• Verbindlichkeit• Datensicherheit • Verfügbarkeit

Fazit: Weitere Mechanismen zur Absicherung nötig.

Dr. Wolf Müller85

Gefährliche Protokolle:

• telnet• rlogin• rsh• ftp• http• pop• imap

Dr. Wolf Müller86

Werkzeuge

• ntop– Statistik, Protokolle, Verbindungsdaten– ntop -u wwwrun

• tcpdump, snoop– Lauschen, Aufzeichnen von Paketen

• nmap– Offene Ports / Protokolle erkennen

• wireshark(ethereal), dsniff– Lauschen, Aufzeichnen, Inspektion des Paketinhalts– Aber auch aktive Angriffe möglich

Dr. Wolf Müller87

Werkzeug: dsniff (1)

Sammlung von Passwortsniffern und Spoofern– ftp, telnet, smtp, nis ...– http://naughty.monkey.org/~dugsong/dsniff

(Etwas veraltet, schwer zu bauen.)• arpspoof

– Manipulation des ARP-Caches von Switchen• dnsspoof

– DNS spoofing• dsniff

– Passwortsniffing• filesnarf

– Ablauschen von Dateien beim NFS-Transport• macof

– Fluten geswitchter Netze mit MAC-Adressen

Dr. Wolf Müller88

Werkzeug: dsniff (2)• mailsnarf

– Speicherung übertragener Mails in Mailbox• msgsnarf

– Belauschung von CHAT-Nachrichten• sshmitm

– ssh „man in the middle“-Angriff• sshow

– SSH[12]-Protokollanalyse (Passwortlänge,..)• tcpkill

– Terminieren einer TCP-Verbindung• tcpnice

– Bremsen von TCP-Verbindungen• urlsnarf

– Protokoll aller HTTP-Requests• webmitm

– WWW „man in the middle” Angriff mit dnsspoof• webspy

– Anzeige von fremden WWW-Requests im eigenen Browser (FF)

Dr. Wolf Müller89

Log: dsniffwolftux:/home # dsniff -mdsniff: listening on eth011/02/07 09:32:15 tcp 192.168.5.185.12444 -> mail.informatik.hu-

berlin.de.110 (pop)AUTH LOGINd29sZm14 [wolfmx]VkxTZWMhMDc= [VLSec!07]11/02/07 09:32:49 tcp 192.168.5.185.15495 -> mail.informatik.hu-

berlin.de.143 (imap)LOGIN wolfmx VLSec!0711/02/07 09:40:28 tcp 192.168.5.185.16419 -> sar.informatik.hu-

berlin.de.80 (http)GET /teaching/2007-w%20Security%20Engineering%20(Basics)/slides/

HTTP/1.1Host: sar.informatik.hu-berlin.deAuthorization: Basic c2Fyc3R1ZDpzYXIhcGRmLzA3 [sarstud:sar!pdf/07]11/02/07 10:26:10 tcp 192.168.5.185.10175 -> ftp.informatik.hu-

berlin.de.21 (ftp)USER anonymousPASS wolfm@foo.de

Dr. Wolf Müller90

Demo: ntop -u wwwrun

Dr. Wolf Müller91

Demo: wireshark

Dr. Wolf Müller92

Humboldt University Computer Science Department Systems Architecture Group IT-Sicherheit Grundlagen...

Documents

Tutorial - AutoCAD Architecture 2016 - acadgraph.de · Tutorial - AutoCAD® Architecture 2016 S Support Ihre Vorteile mit dem Tutorial AutoCAD® Architecture 2016 >> Schnelle Erlernung

Schuhschnabel Bec-en-sabot · I Pinguino di Humboldt Manchot de Humboldt D Humboldtpinguin F Manchot de Humboldt E Humboldt’s penguin I Pinguino di Humboldt Pinguino di Humboldt

FURIOS 03 – Humboldt

HUMBOLDT-UNIVERSITÄT ZU BERLIN HUMBOLDT-UNIVERSITÄT ZU BERLIN DAAD Alumni-Programms

Service Orientated Architecture

nm - architecture portfolio

Architecture Kata Tomatentimer

Carl Stahl Architecture

Humboldt University Computer Science Department Systems Architecture Group IT-Sicherheit Grundlagen Sicherer Kanal:

Voodoo architecture

Von neumann architecture

Service Oriented Architecture

HOLIDAY ARCHITECTURE - URLAUBSARCHITEKTUR

Humboldt University Computer Science Department Systems Architecture Group IT-Sicherheit Grundlagen Übung 2 Übungsaufgabe,

AutoCAD Architecture 2008 - Styleguide · PDF fileAutoCAD® Architecture 2008 – Styleguide Deutschland Seite 4 von 149 1. Darstellung von Planinhalten AutoCAD Architecture 2008 bietet

Implementierung eines UWB-Lokalisierungsalgorithmus in C++ ...€¦ · Grundlagen BeamLoc-Algorithmus Implementierung Analyse des zirkularen Arrays Simulation Zusammenfassung Implementierung

Humboldt University Computer Science Department Systems Architecture Group IT-Sicherheit Grundlagen Begriffe

Buzzword Information Architecture

Architecture portfolio

Wir müssen also überlegen: Implementierung der Knoten, Implementierung der Kanten, daraus: Implementierung des Graphen insgesamt. Annahme: die Knoteninhalte