Ankündigungen 16. Mai 2007

Transcription

Ankündigungen 16. Mai 2007
• Gastvortrag von Katja Könnecke fällt leider aus
• Seminaristen aufgepasst:
– Terminliste für Vorträge liegt im Sekretariat aus
– Seminaristen bekommen noch zusätzlich eine Diskette
• Nächster Gastvortrag:
– 30.5.: Knut Eckstein (ESA)
• Vorlesungsplanung (siehe auch Webseite):
– 16.5.: Abschluss Ext2/3, Internetforensik
– 23.5.: Tools, rechtliche Rahmenbedingungen
– 30.5. und 6.6.: Vorträge Seminararbeiter
Vorlesung Computerforensik, Frühjahrssemester 2007, Universität Mannheim, http://pi1.informatik.uni-mannheim.de
Seite 219
Belegungsstrategien
• Belegungsstrategie nachlesbar im Linux-Quellcode
– Hier Beispiel aus Fedora Core 2
• Für eine neue Datei wird neuer Platz für den Indexknoten
gesucht...
– zunächst in derselben Blockgruppe des Elternverzeichnisses
– Wenn das voll ist, wird mittels quadratischem Hashing eine andere
(quasi-zufällige) Blockgruppe gesucht
• Für ein neues Verzeichnis wird eine Blockgruppe gesucht, die
bisher wenig benutzt wurde
– Im Gruppendeskriptor werden statistische Daten gespeichert
• Wieviele freie Indexknoten, wieviele freie Blöcke existieren noch in der
Blockgruppe?
– Die erste „unterdurchschnittliche“ Blockgruppe wird ausgewählt
Seite 220
Löschen von Einträgen
• Ext3 setzt Dateigröße auf 0 und löscht die
Blockverweise
– Auch die Verweise in den indirekten Blöcken
• Ext2 löscht diese Werte nicht
– Macht Dateiwiederherstellung viel einfacher
– Zeitstempel werden sogar aktualisiert
Seite 221
Analyse
• Zur Analyse der Metadaten muss man immer den
Indexknoten der Datei finden
• Durchsuchen aller belegten oder unbelegten
Indexknoten:
– Belegtstatus mittels Inode Bitmap analysieren
– Anschliessend Inode auslesen
• Zeitstempel verraten, wann Datei gelöscht wurde
• In Ext3 ist Dateiwiederherstellung viel schwerer als in
Ext2
– Muss auf Anwendungsebene Daten interpretieren
Seite 222
Häufiger Trick
• Ein Prozess öffnet eine Datei zum Lesen und/oder
Schreiben
• Der Prozess löscht mittels Systemkommando die
Datei
– Datei verschwindet aus dem Verzeichnis, existiert aber so
lange, bis sie von Prozess geschlossen wird
• Im „toten“ Dateisystem wird eine solche Datei in eine
Liste im Superblock eingestellt
– Kann mittels fsstat (Sleuthkit) analysiert werden
Seite 223
Dateinamen
• Verzeichniseinträge liegen in Datenblöcken von Verzeichnissen
– Enthalten Dateiname und Verweis auf Indexknoten
• Verzeichniseinträge bilden eine Liste
– Angaben jeweils wie lang der Name ist und wo der nächste Eintrag
beginnt
• Beim Löschen wird der „Next“-Zeiger einfach weitergeschaltet
– Dateiname bleibt weiter stehen
• Beispiel:
[Carrier Abb 14.6]
Seite 224
Hard Links und Soft Links
• Verzeichniseintrag ist ein „Hard Link“
– Direkter Verweis auf den Indexknoten
– Es kann mehrere davon auf dieselbe Datei geben
• Dieselbe Datei unter mehreren Namen
• Wird erst gelöscht, wenn der letzte Hardlink verschwunden ist
– „.“ und „..“ sind Hard Links auf das aktuelle und das
Elternverzeichnis
• Datei kann als Soft Link markiert sein
– Dateninhalt enthält Dateinamen, auf den der Soft Link
verweist
– Nützlich für Verweise in andere Dateisysteme
– Nützlich für Verweise auf Verzeichnisse
Seite 225
Beispiel [Carrier Abb 14.7]
Seite 226
Belegungsstrategien
• Ein neuer Verzeichniseintrag soll angelegt werden
• Linux sucht von Beginn des Verzeichnisses nach
freiem Platz für den Eintrag
• Falls kein Platz gefunden, füge Dateinamen ans Ende
des Verzeichnisses an
• Verzeichnisse werden standardmäßig nicht
defragmentiert
Seite 227
Analyse
• Beginne mit der Suche im Wurzelverzeichnis
– Inode 2
• Suche nach gelöschten Dateinamen
– Gehe komplettes Verzeichnis durch
– Betrachte auch die „Zwischenräume“ zwischen den
Dateinamen
• Belegungsstrategie für Dateinamen:
– Ein Eintrag für einen kurzen Dateinamen wird nach dem
Löschen länger vorhanden sein als ein langer Dateiname
• fsck kann Verzeichnisse defragmentieren
• Man kann in „unbenutzten“ Verzeichniseinträgen
auch Daten verstecken
Seite 228
Anwendungsdaten
• Journal
– Typischerweise Inode 8
– Heute gängiges feature
– Führt Updates in Form von Transaktionen durch
• Journal speichert:
– Welche Updates auf Blöcken durchgeführt werden sollen
– Ob der Update fertig wurde
– Fortlaufende Nummer des Updates
• Journal arbeitet auf vollständigen Blöcken
– Falls auch nur ein Bit eines Indexknotens aktualisiert werden soll,
wird der gesamte Block ins Journal geschrieben
• Im Journal kann man zum Beispiel Indexknoten mit korrekten
Verweisen finden, bevor sie gelöscht wurden
Seite 229
Übersicht: Datei Erstellen und
Löschen [Carrier, Abb. 14.14]
Seite 230
Details: Erstellen der Datei
• Superblock lesen, Identifiziere Beginn, Ort, Größe der
Blockgruppen
• Suche über den Indexknoten des
Wurzelverzeichnisses den Indexknoten zum
Verzeichnis dir1
• Belege Platz im Inhalt von dir1 für den Dateinamen
file1.dat
• Belege einen Indexknoten für file1.dat in derselben
Blockgruppe
• Belege Blöcke für file1.dat und verknüpfe die Blöcke
mit den Blockverweisen im Indexknoten von file1.dat
• Schreibe Daten von file1.dat in diese Blöcke
Seite 231
Details: Löschen der Datei
• Finden des Eintrags file1.dat durch Ablaufen der
Verzeichnisse und Verzeichniseinträge
• Durch Ändern der „Next“-Zeigers des
vorhergehenden Verzeichniseintrages wird der Name
file1.dat gelöscht
• Falls Verweiszeiger im Indexknoten von file1.dat 0
ist, wird
–
–
–
–
Inode in Inode Bitmap auf unbelegt gesetzt
Datenblöcke werden auf unbelegt gesetzt
Verweise auf Blöcke werden ausgenullt (Ext3)
Löschzeitpunkt im Inode aktualisiert
Seite 232
Rückblick
• Festplattentechnologie
– Boot Prozess, Arten von Festplatten, Standards
• Sicherung (Preservation) von Festplattendaten
–
–
–
–
Allgemeine Methodik und Verlässlichkeit der Tools
Lesen des Originals
Schreiben der Kopie
Integrität der Kopie
• Festplattenanalyse
– Festplatten und Partitionen
• Dateisystemanalyse
– FAT, NTFS, Ext2/Ext3
Seite 233
Zusammenfassung
• Der größte Teil an digitalen Spuren fällt heute (noch)
auf Festplatten an
• Festplattendaten müssen forensisch gesichert und
ausgewertet werden
• Allgemeine Methodik hilft bei der Vorgehensweise
– Wo können welche Daten versteckt sein?
– Welche Daten sind essentiell, welche nicht?
Seite 234
Communications of the ACM, 48(8), 2006
Ausblick
• Bisher “dead
analysis”
• Als nächstes “live
analysis”
• Live Response und
Internetforensik
• Fragen?
Name und Datumwww.uni-mannheim.de
Seite 235
Computerforensik
Vorlesung im Frühjahrssemester 2007
Universität Mannheim
Teil 6: Spuren im Netz
Prof. Dr. Felix Freiling
Universität Mannheim
Lehrstuhl für Praktische Informatik 1
http://pi1.informatik.uni-mannheim.de
Seite 1
Motivation
• Analyse von Festplatten: dead analysis
– Heute noch der überwiegende Teil der gesammelten Spuren
(mehr als 95%)
– Weit entwickelte Methodik (siehe Kapitel 5 der Vorlesung)
– Einfach zu sichern, geringe Flüchtigkeit
• Herausforderung heute: Sichern von flüchtigeren
Spuren
– Spuren auf dem laufenden System (live response)
– Spuren im Netz
• Problem bei der Tatortsicherung
– Man kann ein Netz nicht anhalten, um eine Kopie
anzufertigen
– Spuren sind verteilt vorhanden
Seite 2
Spuren im Netz
• Teil der digitalen Forensik, der noch recht schwach
entwickelt ist
• Auch diese Vorlesung setzt einen Schwerpunkt auf
praktisch verwertbare Ansätze
– Sichern von Indizien im Internet
• Sichern und Analyse von Spuren im lokalen Netz ist
für die Vorlesung ein Zukunftsthema
– Server Logs, Firewall und IDS Logs, Accounting
Informationen, Netflow Informationen
• Auch Live Response wird in Zukunft noch ausgebaut
Seite 3
Übersicht: Themen der Vorlesung
1.
2.
3.
4.
5.
6.
7.
8.
9.
Motivation und Überblick
Forensik und digitale Spuren
Forensische Prinzipien und Beweise
Vorgehensmodelle: Incident Response vs.
Computerforensik
Dateisystemanalyse
Internet-Forensik und Live Response
Computerforensische Werkzeuge
Rechtliche Rahmenbedingungen
Zusammenfassung
Seite 4
Quellen
• Dornseif, Vorlesung RWTH 2004, Kapitel
„Internetforensik“
• Casey, Kapitel 15 und 18
• Geschonneck, Kapitel 9
– Insbesondere IP-Backtracing
• Diverse Internet-Seiten
Seite 5
Übersicht
•
•
•
•
Klassifikation und Abgrenzung
Live Response
Spuren im lokalen Netz (kurz)
Spuren im Internet
– Mail
– Zurückverfolgen von IP-Adressen
– Spuren im WWW
• Zusammenfassung
Seite 6
Flüchtigkeit von Daten
• Hierarchie der Flüchtigkeit von Daten im Rechner:
–
–
–
–
–
–
–
–
–
CPU-Register
Arbeitsspeicher
Kommunikationspuffer im Netzadapter
Offene Dateien
Aktive Netzwerkverbindungen
Aktive Prozesse
Log-Dateien
Benutzerdateien
...
Seite 7
Sichern der Daten
• Regel: Daten in Reihenfolge abnehmender
Flüchtigkeit am Tatort sichern
• Probleme:
– Expertise muss vor Ort sein
– Gefahr der Modifikation der Daten
– „Original“ ist nach dem Sichern verschwunden
Seite 8
Wo fallen Spuren an?
• Bereiche zunehmender geographischer Entfernung
vom Tatort
– Rechner, lokales Netz, Internet
– Übergang lokales Netz/Internet oft fliessend
– Probleme bei überlagerten Netzen (VPNs, P2P, etc.)
Seite 9
Übersicht
•
•
•
•
Live Response
Spuren im Internet
– Mail
– Spuren im WWW
• Zusammenfassung
Seite 10
Live Response
• Datensammlung auf dem „lebenden System“
• Ermöglicht Sammlung vieler flüchtiger Daten:
–
–
–
–
–
Aktive Verbindungen
Laufende Prozesse
Systemdatum und -uhrzeit
Geladene Kernelmodule
Liste offener Dateien
• Teilweise auch nicht-flüchtige Daten
– Beispiel: Windows Logs sind offline schwer auslesbar
– Vorteil auch bei anderen Daten: Spuren stehen früher zur
Verfügung als bei dead analysis
Seite 11
Probleme bei Live Response
• Aktivitäten verändern das System!
– Ändert Hauptspeicher
– Erzeugt Prozesse
– Legt ggf. temporäre Dateien an
• Alle Aktivitäten müssen gut verstanden sein
– Aktivitäten gut dokumentieren und absichern
– Videoaufzeichnung oder Vier Augen-Prinzip
– Abwägen der Vor- und Nachzeile notwendig
• Angaben des Systems kann nicht vertraut werden
– Kernel-Modifikationen, Root Kits
– Manche Root Kits hinterlassen keine Spuren auf der Festplatte
– 100%ige Root Kit-Erkennung a posteriori möglich
• Benötigt aber Schnappschuss des laufenden Systems
Seite 12
Übersicht
•
•
•
•
Live Response
Spuren im Internet
– Mail
– Spuren im WWW
• Zusammenfassung
Seite 13
Quellen
•
•
•
•
Server Logs
Firewall und IDS Logs
Anmeldeinformationen
Netflow Informationen
• Wichtig zur ...
–
–
–
–
Zuordnung von Aktivitäten zu einem Loginnamen
Zuordnung von IP-Adressen zu Rechnern (DHCP, ARP)
Bestimmung von (Angriffs-)Zeitpunkten
...
Seite 14
Zuordnung PC zu Person
• Oft erwünscht: Nachweis, dass eine bestimmte
Person etwas mit dem Rechner gemacht hat
– Beispielsweise E-Mail-Schreiben oder E-Bay-Bieten
• Verbindungsdaten (IP-Adresse) weisen auf Rechner
hin
• Logindaten weisen auf Benutzerkennung hin
• Zusätzliche (nicht-digitale) Spuren weisen auf Person
hin
– Alibi, Zeugenaussagen, Gebäudeüberwachung, etc.
Seite 15
„Preemptive Forensik“
• Sammeln von Spuren ohne konkreten Verdacht im
Voraus
– Vorratsdatenspeicherung
– Sehr dünnes Eis wegen Datenschutz
• Wichtiger Unterschied:
– Kommunikationsdaten: Inhalt einer Verbindung
– Verbindungsdaten: End- und Zeitpunkte einer Verbindung
Seite 16
Übersicht
•
•
•
•
Live Response
Spuren im Internet
– Mail
– Spuren im WWW
• Zusammenfassung
Seite 17
Mail Spoofing
sonic:~ freiling$ telnet localhost 25
Trying ::1...
telnet: connect to address ::1: Connection refused
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
telnet: Unable to connect to remote host
sonic:~ freiling$ telnet rumms.uni-mannheim.de 25
Trying 134.155.50.52...
Connected to rumms.uni-mannheim.de.
Escape character is '^]'.
220 SMTPSERVER ESMTP der UNIVERSITAET MANNHEIM; Tue, 15 May 2007 23:09:57 +0200 (MEST)
HELO mail.hotmail.com
250 rumms.uni-mannheim.de Hello sonic.informatik.uni-mannheim.de [134.155.88.225], pleased to meet you
MAIL FROM: <bush@whitehouse.gov>
250 2.1.0 <bush@whitehouse.gov>... Sender ok
RCPT TO: <freiling@informatik.uni-mannheim.de>
250 2.1.5 <freiling@informatik.uni-mannheim.de>... Recipient ok
DATA
354 Enter mail, end with "." on a line by itself
Hi Felix,
great lecture!
George
.
250 2.0.0 l4FL9viX022216 Message accepted for delivery
quit
221 2.0.0 rumms.uni-mannheim.de closing connection
Connection closed by foreign host.
sonic:~ freiling$
Seite 18
You have mail!
Date: Tue, 15 May 2007 23:09:57 +0200 (MEST)
From: bush@whitehouse.gov
Message-Id: <200705152111.l4FL9viX022216@rumms.unimannheim.de>
To: undisclosed-recipients:;
X-Virus-Scanned: amavisd-new at staffmail.uni-mannheim.de
Status: O
Content-Length: 33
Lines: 4
Hi Felix,
great lecture!
George
Seite 19
Mail Header
From bush@whitehouse.gov Tue May 15 23:11:33 2007
Return-Path: <bush@whitehouse.gov>
Received: from murder ([unix socket])
by imap.uni-mannheim.de (Cyrus v2.2.12) with LMTPA;
Tue, 15 May 2007 23:11:33 +0200
X-Sieve: CMU Sieve 2.2
Received: from localhost (localhost [127.0.0.1])
by staffmail.uni-mannheim.de (Postfix) with ESMTP id 9BC0B4BEA4
for <freiling@staffmail.uni-mannheim.de>; Tue, 15 May 2007 23:11:33 +0200 (CEST)
Received: from staffmail.uni-mannheim.de ([127.0.0.1])
by localhost (mail-v71.rz.uni-mannheim.de [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 22699-08 for <freiling@staffmail.uni-mannheim.de>;
Tue, 15 May 2007 23:11:32 +0200 (CEST)
Received: from rumms.uni-mannheim.de (rumms.uni-mannheim.de [134.155.50.52])
by staffmail.uni-mannheim.de (Postfix) with ESMTP id DE3823FC71
for <freiling@staffmail.uni-mannheim.de>; Tue, 15 May 2007 23:11:32 +0200 (CEST)
Received: from mail.hotmail.com (sonic.informatik.uni-mannheim.de [134.155.88.225])
by rumms.uni-mannheim.de (8.13.8/8.13.8) with SMTP id l4FL9viX022216
for <freiling@informatik.uni-mannheim.de>; Tue, 15 May 2007 23:11:03 +0200 (MEST)
Date: Tue, 15 May 2007 23:09:57 +0200 (MEST)
From: bush@whitehouse.gov
[...]
Seite 20
Mail Struktur
• Envelope
– Wird oft als „Header“ bezeichnet
• Eigentliche Mail (mit Header und Body)
–
–
–
–
From:
To:
Subject:
eigentliche Mail
• Für die Zustellung ist nur der Envelope wichtig
– Envelope wird bei den meisten Mailern nicht angezeigt
• Anzeige der Header in (fast allen) Mailern:
– http://www.spamcop.net/fom-serve/cache/19.html
Seite 21
Lesen des Envelopes
• „Return-Path“ ist das, was bei „MAIL FROM:“ angegeben wurde
• „Received:“ Zeilen sind Zustellvermerke
–
–
–
–
Werden durch Mailserver jeweils vorne angefügt
Für die Rückverfolgung also von hinten nach vorne lesen
Erster Eintrag ist der eigene Mailserver
Empfänger in Zeile i ist Sender in Zeile i-1
• Received-Zeilen können auch beliebig gefälscht sein
– Spammer fügen oft vor „ihrer“ ersten Received-Zeile eine Reihe
von gefälschten Zeilen ein
• Wo beginnen die „echten“ Zeilen?
– Auf kleine Inkonsistenzen achten
– Aber auch Gewohnheiten von großen Mailversendern
– Gutes Diplomarbeitsthema
Seite 22
Übersicht
•
•
•
•
Live Response
Spuren im Internet
– Mail
– Spuren im WWW
• Zusammenfassung
Seite 23
Organisation des IP-Adressraums
• IP-Adressraum wird von der IANA verwaltet
– Internet Assigned Numbers Authority, www.iana.org
• Verwaltung mittlerweile delegiert an regionale
Registrare
• Die wichtigsten sind:
– ARIN: American Registry for Internet Numbers
– APNIC: Asia Pacific Network Information Center
– RIPE NCC: Réseaux IP Européens Network Coordination
Center
• Verwalten eine verteilte Datenbank über
– IP-Adresszuordnungen (DNS) und
– Besitzerinformationen (whois)
Seite 24
dig
dig - DNS lookup utility
SYNOPSIS
dig [@server] [-b address] [-c class] [-f filename] [-k filename]
[-p port#] [-t type] [-x addr] [-y name:key] [-4] [-6] [name]
[type] [class] [queryopt...]
dig [-h]
dig [global-queryopt...] [query...]
DESCRIPTION
dig (domain information groper) is a flexible tool for interrogating
DNS name servers. It performs DNS lookups and displays the answers that
are returned from the name server(s) that were queried. Most DNS
administrators use dig to troubleshoot DNS problems because of its
flexibility, ease of use and clarity of output. Other lookup tools tend
to have less functionality than dig.
Seite 25
Beispiel: Reverse DNS Lookup
; <<>> DiG 9.3.2 <<>> @ns.kloth.net 225.88.155.134.in-addr.arpa ANY
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42245
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;225.88.155.134.in-addr.arpa. IN ANY
;; ANSWER SECTION: 225.88.155.134.in-addr.arpa. 172731 IN PTR
sonic.informatik.uni-mannheim.de.
;; Query time: 0 msec
;; SERVER: 88.198.39.133#53(88.198.39.133)
;; WHEN: Wed May 16 00:11:05 2007
;; MSG SIZE rcvd: 91
Seite 26
Whois
NAME
whois -- Internet domain name and network number directory service
SYNOPSIS
whois [-aAbdgiIlmQrR6] [-c country-code | -h host] [-p port] name ...
DESCRIPTION
The whois utility looks up records in the databases maintained
by several Network Information Centers (NICs).
...
Seite 27
Whois-Abfrage
• Liefert
– Domaininhaber
– Adminstrativer Ansprechpartner
– Technischer Ansprechpartner
Seite 28
traceroute
traceroute -- print the route packets take to network host
SYNOPSIS
traceroute [-dFISdnrvx] [-f first_ttl] [-g gateway] [-i iface]
[-M first_ttl] [-m max_ttl] [-P proto] [-p port] [-q nqueries]
[-s src_addr] [-t tos] [-w waittime] [-z pausemsecs] host
[packetsize]
DESCRIPTION
The Internet is a large and complex aggregation of network hardware, connected together by gateways. Tracking the route one's packets follow (or
finding the miscreant gateway that's discarding your packets) can be difficult. Traceroute utilizes the IP protocol `time to live' field and
attempts to elicit an ICMP TIME_EXCEEDED response from each gateway along
the path to some host.
The only mandatory parameter is the destination host name or IP number.
The default probe datagram length is 40 bytes, but this may be increased
by specifying a packet size (in bytes) after the destination host name.
Seite 29
IP Geolocation
• Geolocation ordnet einer IP-Adresse ihre
geographische Position zu
• IP-Adressen haben oft zwar keine feste Zuordnung zu
Rechnern, aber immer einen Besitzer
• Besitzerinformationen können zur Eingrenzung des
Ortes dienen (Universität, Region, Land)
Seite 30
Seite 31
Dienste im WWW
•
•
•
•
DIG: http://www.kloth.net/services/dig-de.php
Whois: http://www.denic.de/de/whois/index.jsp
traceroute: http://clez.net/net.traceroute
Geolocation: http://www.geoiptool.com/
Seite 32
Übersicht
•
•
•
•
Live Response
Spuren im Internet
– Mail
– Spuren im WWW
• Zusammenfassung
Seite 33
Google
•
Durch spezielle Modifikatoren kann man die Google-Suche verfeinern
– filetype:abc
• Suche einschränken auf Dateien mit Endung abc
– site:foo.com
• Suche beschränken auf Domain foo.com
– intext:foo
• Klassische google-Suche: foo irgendwo im Text der Seite
– intitle:foo
• Seiten, die foo im Titel haben
– inurl:foo
• Seiten, die foo in der URL haben
– link:www.foo.com
• Seiten, die auf www.foo.com verlinken
– cache:www.foo.com/bar.html
• Seite im google cache
•
Siehe: http://www.google.com/help/operators.html
Seite 34
Seite 35
Seite 36
Seite 37
Seite 38
archive.org
• Internet-Archiv
• Non-profit Organisation in den USA
• Ziel: Aufbewahren regelmäßiger Schnappschüsse des
Internet für die Nachwelt
• Wayback Machine: Zugang zum Schnappschussarchiv
• http://www.archive.org
• Im Gegensatz zum Google Cache ist archive.org
persistent, dafür aber langsamer
Seite 39
Seite 40
Seite 41
Übersicht
•
•
•
•
Live Response
Spuren im Internet
– Mail und News
– Spuren im WWW
• Zusammenfassung
Seite 42
Zusammenfassung
• Sammlung flüchtiger Spuren ist besonders schwierig
• Insbesondere Spuren im Netz sind sehr vielfältig
– Thema bei weitem nicht vollständig behandelt
• Noch viel Arbeit für die Wissenschaft:
– Klassifikation von Spuren im Netz
– Standardvorgehen zur Sicherung von Spuren
– Methoden der Suche und Korrelation
• Im Internet liegen viele Schätze verborgen
Seite 43
Communications of the ACM, 48(8), 2006
Ausblick
• Kurzüberblick über
(kommerzielle)
Werkzeuge
• Rechtliche
Rahmenbedingungen
Seite 44

Ankündigungen 16. Mai 2007

Transcription

Similar documents

Spuren im WWW

Datierungshilfe für Datierungshilfe für - Musiker

outdoorreport 04/04

Der Bundestrojaner - Fakultät für Mathematik und Informatik

Übersicht

Folie 1

Rekord und Premiere

PDF Version

Bachelorarbeit

Online-Shop-Betreiber unterschätzen Risiken

Foliensatz 6 - Prof. Dr. Christian Baun

4 Datenträger/Dateiverwaltung

Kursprogramm 2016 / 2017