Tractatus Logico-Philosophicus Instrumentum Computatorium |
Vorwort | Einführung | | Begriffe | Kontakt |
Letztes Update des Tractatus: 12.04.2018 Darstellung: Liste | Logik | Prosa | Diagramm (474 kb) Details: 6 | 5 | 4 | 3 | 2 | 1 Informale Herleitung zu 1.1.4.2.1 (aufheben): Sicherheit ist ein Zustand. Er sieht eine wohldefinierte Anzahl an erlaubten Handlungen vor. Eine passive (reaktionäre) Handlung ist eine provozierte und unausweichliche Reaktion auf einen vorangegangenen Reiz. Ein Reiz lässt sich im Computerbereich am ehesten als Eingabe oder Anfrage (z.B. HTTP Request) beschreiben. Eine Eingabe (Reiz) führt zu einer Datenverarbeitung (Reaktion). q.e.d. 1 Sicherheit ist ein Zustand. 1.1 Er sieht eine wohldefinierte Anzahl an erlaubten Handlungen vor. 1.1.1 Eine Handlung ist eine ausgeführte Tätigkeit. 1.1.2 Eine Handlung kann sowohl aktiv (aktionär) als auch passiv (reaktionär) erfolgen. 1.1.3 Eine aktive (aktionäre) Handlung ist eine freiwillige Aktion ohne vorausgehenden Reiz. 1.1.3.1 Nur Menschen können freiwillige Aktionen durchführen. (Vielleicht noch nicht mal diese.) 1.1.3.2 Provozierte Reaktionen sind hingegen vorzugsweise durch Computer, Maschinen und Roboter gegeben. 1.1.4 Eine passive (reaktionäre) Handlung ist eine provozierte und unausweichliche Reaktion auf einen vorangegangenen Reiz. 1.1.4.1 Der vorangegangene Reiz kann entweder selber eine aktive oder eine passive Handlung gewesen sein. 1.1.4.2 Ein Reiz lässt sich im Computerbereich am ehesten als Eingabe oder Anfrage (z.B. HTTP Request) beschreiben. 1.1.4.2.1 Eine Eingabe (Reiz) führt zu einer Datenverarbeitung (Reaktion). 1.1.4.2.2 Oft wird eine Ausgabe als die eigentliche Reaktion verstanden. In der Regel liegt dabei jedoch eine transparente Verarbeitung dazwischen (Datenannahme und Berechnungen). In der Psychologie wird dies als S-O-R-Paradigma bezeichnet (Robert S. Woodworth, 1929). 1.1.4.2.3 Auf die HTTP-Anfrage "GET / HTTP/1.0\n\n" wird die Rückgabe für die entsprechende Ressource / generiert. 1.1.4.2.3.1 Der Webserver muss eine TCP-Verbindung etablieren (RFC 793). Dabei wird die SYN-Anfrage auf dem Zielport empfangen und eine SYN/ACK-Antwort zurückgeschickt. Sobald der Client den Verbindungsaaufbau mit dem finalen ACK-Segment bestätigt, ist die Kommunikation im Rahmen von TCP etabliert. 1.1.4.2.3.2 Über das Anwendungsprotokoll HTTP wird die Anfrage vom Client an den Server geschickt (RFC 1945). 1.1.4.2.3.3 Sobald der Webserver die HTTP-Anfrage empfangen hat, wird diese geparst und die Datenteile verarbeitet (z.B. Methode, Ressource, Protokoll, Optionen, ...). 1.1.4.2.3.4 Wurde eine Ressource angefordert, wird auf diese zugegriffen, sie aufbereitet und im Rahmen von HTTP zurückgeschickt. Der initiale Reiz wurde damit verarbeitet. 1.1.4.3 Ein Reiz, der eine Antwort generiert, die wiederum ein Reiz ist, der die gleiche Antwort generiert, wird als Loop bezeichnet. 1.1.4.3.1 Durch Loops lassen sich Ressourcen belegen und damit eine Denial of Service-Attacke (Ping-Pong) umsetzen. 1.1.4.3.2 Populär sind Routing-Loops, bei denen Pakete im Kreis weitergeleitet werden und deshalb nie die eigentliche Destination erreichen können. 1.1.4.3.3 Loops, bei denen schlussendlich eine Blockierung des Systems stattfindet, sind eine spezielle Form von Race Conditions. Sie werden Deadlocks oder Livelocks genannt. 1.1.4.3.4 Bei intelligenten Systemen werden Mechanismen eingesetzt, die Loops und Deadlocks erkennen und auf sie reagieren können. 1.1.4.3.4.1 Um Loops im Routing zu verhindern, wird durch IP ein initialer Time-to-Live Wert (TTL) gesetzt. Er wird bei jeder Weiterleitung verringert. Erreicht er den Wert 0, wird das Paket verworfen und eine ICMP-Fehlermeldung generiert (RFC 791). 1.1.4.3.4.2 Um Loops in Kommunikationen zu verhindern, werden eindeutige, berechenbare und nachvollziehbare Sequenznummern verwenden (z.B. bei TCP). 1.1.4.3.4.3 Um Ping-Pong-Attacken zu verhindern, wird versucht automatische Anfragen als solche zu erkennen und keine automatischen Antworten zu generieren (z.B. Anfragetypen bei ICMP). 1.1.4.3.4.4 Bei Betriebssystemen können Scheduler zum Tragen kommen (Mutexe oder Semaphore), um eine Doppelbelegung von Ressourcen zu vermeiden. 1.2 Die produktive Sicherheit eines Systems (im Betrieb) wird in erster Linie an der Unterbindung unerwünschter Handlungen gemessen. 1.2.1 Eine Möglichkeit ist der Spielraum einer Handlung. 1.2.2 Das Ausbleiben jeglicher Möglichkeiten lässt absolute Sicherheit erlangen. 1.2.2.1 Ein System ohne Möglichkeiten erfüllt jedoch keinen Nutzen. 1.2.2.2 Ein produktives System muss mindestens eine Möglichkeit bereitstellen, um einen Nutzen gewähren zu können. 1.2.2.3 Viele Systeme bieten eine Vielzahl an Möglichkeiten. 1.2.2.4 Die Qualität und der Nutzen eines Produkts wird oftmals gar an seinen Möglichkeiten gemessen. 1.2.3 Sind alle unerwünschten Handlungen unterbunden, kann mit grösstmöglicher Wahrscheinlichkeit von einem sicheren Produkt ausgegangen werden. 1.2.3.1 Werden ausschliesslich gewünschte Handlungen und Zugriffe gewährleistet, spricht man vom "need to know" Prinzip. 1.2.3.2 Spätestens das Erlangen einer unerwarteten und unvorhergesehenen Möglichkeit mündet also in reaktionärer (nach Reiz) oder aktionärer (ohne Reiz) Unsicherheit. 1.2.4 Auch eine ursprünglich vorgesehene Möglichkeit kann eine Unsicherheit darstellen. 1.2.4.1 Nur weil eine Möglichkeit vorgesehen ist, heisst es nicht, dass sie sich bei näherer Betrachtung nicht doch als unsicher herausstellt. 1.2.4.1.1 Bei der Entwicklung eines Systems könnte eine umfassende Fehlermeldung als unkritisch vorgesehen werden. 1.2.4.1.2 Im Rahmen eines Angriffsversuch könnte sich eine akzeptierte Nichtigkeit als wichtiges Element zur Beweisbarkeit oder Ausnutzung der Unsicherheit herausstellen. 1.2.4.1.3 Der gewollte Handlungspielraum erfüllt sich damit mit einer indirekten Unsicherheit. 1.2.4.2 Die gegebene Unsicherheit einer vorgesehenen Möglichkeit hat sich schon bei ihrer Realisation manifestiert und war stetig präsent (im Hintergrund). 1.2.4.2.1 Eine Unsicherheit generiert sich also nicht erst dann, wenn sie als solche beobachtet werden kann. 1.2.4.2.2 Wird ein Produkt X im Januar 2000 veröffentlicht und im Januar 2005 eine Schwachstelle darin gefunden, so ist sie im Januar 2006 nicht ein Jahr alt sondern derer gar sechs. 1.2.4.2.2.1 Microsoft Windows XP wurde am 25.10.2001 veröffentlicht. Eine schwerwiegende Pufferüberlauf-Schwachstelle im RPC-Dienst wurde am 16.07.2003 publiziert (CVE-2003-0352, VU568148). Das Problem war also mindestens 629 Tage (vielleicht schon länger während der Entwicklungsphase) existent. 1.2.4.2.2.2 Der US-amerikanische Sicherheitsspezialist Dan Kaminsky entdeckte eine generische DNS-Attacke, welche versehentlich frühzeitig am 21. Juli 2008 veröffentlicht wurde (CVE-2008-1447). Die betroffenen Hersteller wurden jedoch frühzeitig informiert und reagierten bis am 08. Juli 2008 mit Patches (VU800113). Der designtechnische Fehler war aber seit der ersten Implementierung eines Nameservers im Jahr 1983 existent (RFC 882, 883). Damit war das Problem rund 25 Jahre gegeben. 1.2.4.2.2.3 Das Problem von TCP SYN Flooding Attacks wurde ab 1996 wahrgenommen und im 2007 in einem eigenen RFC behandelt (RFC 4987). Dabei wird eine generische Eigenschaft von TCP ausgenutzt. Diese war schon immer, seit der ersten Spezifizierung des Protokolls im Jahr 1974, gegeben (RFC 675). Und ohne eine konzeptionelle und architektonische Änderung des Protokolls wird sie auch weiterhin bestehen bleiben.
2 Unsicherheit gewährt eine nicht zugelassene Handlung. 2.1 Unsicherheit sowie Sicherheit existieren auf theoretischer (ℑ) und auf praktischer (ℜ) Ebene. 2.1.1 Eine (praktische) Unsicherheit lässt sich stets theoretisch erfassen. 2.1.1.1 Theoretische Unsicherheit erfordert, dass in erster Linie ausserhalb der Praxis eine nicht zugelassene Handlung möglich ist. 2.1.1.2 Praktische Unsicherheit erfordert, dass auch in der Praxis die nicht zugelassene Handlung umgesetzt werden kann. 2.1.1.3 Praktische Unsicherheit lässt sich theoretisch erfassen. Theoretische Unsicherheit manifestiert sich hingegen nicht zwangsweise in der Praxis. 2.1.1.4 Nur die praktische Unsicherheit (theoretisch bewiesen oder praktisch ermittelt) gibt Aufschluss über die produktive Sicherheit des Systems. 2.1.1.4.1 Die produktive Unsicherheit eines Systems wird ihm frühstmöglich bei der Umsetzung/Aktivierung dessen anhaften. 2.1.1.4.2 Die produktive Unsicherheit verschwindet gänzlich spätestens dann, wenn das System komplett deaktiviert wird. 2.1.2 Der maximale Aufwand des Erkennens der Sicherheit eines Systems erfordert das Erkennen und Bewerten sämtlicher möglichen Zustände dessen. 2.1.2.1 Der Aufwand einer solchen Erfassung ist immer grösser als Null, da es mindestens immer einen Zustand (die Existenz als solche) gibt. 2.1.2.1.1 Ein System bestehend aus einem Bit, welches zwei Zustände 0 und 1 annehmen kann, muss für diese beiden Zustände [1]b = {0, 1} geprüft werden. 2.1.2.1.2 Ein System mit zwei Bit weist schon 4=2^2 Zustände der Form [2]b = {00, 01, 10, 11} auf. Bei drei Bit sind es 8=2^3, usf. 2.1.2.1.3 Der Aufwand der Prüfung eines Systems mit gleichem poliadischem Zahlensystem steigt mit der Zunahme jeder Zustandsstelle exponentiell an. Ein System mit n Bit kennt 2^n Zustände. 2.1.2.4 Je komplexer ein System ist, desto mehr Zustände lässt es zu. 2.1.2.4.1 Es sei davon auszugehen, dass unser Universum endlich ist. 2.1.2.4.2 Die Endlichkeit des Universums sieht vor, dass es ebenso eine endliche Anzahl an Zuständen in diesem gibt. 2.1.2.4.3 Da wir sowie die zu prüfenden Systeme ein Teil dieses endlichen Universums sind, kennen also auch wir lediglich eine endliche Anzahl an Zuständen. 2.1.2.4.4 Ein Computersystem kann aufgrund der Endlichkeit unseres Universums niemals eine unendliche Anzahl an Zuständen und damit eine unendliche Komplexität der Form x^∞ (infinity) aufweisen. 2.1.2.4.5 Die Prüfung eines Systems ist aufgrund seiner Endlichkeit ebenso mit endlichen Aufwänden durchführbar. 2.1.2.5 Je mehr Zustände ein System zulässt, desto aufwendiger wird die Prüfung eben dieses. 2.1.2.5.1 Auch der einzelne Zustand kann unterschiedliche Komplexitäten mitbringen. Der Zustand 0 ist weniger schwierig zu überblicken weder der Zustand 010011. 2.1.2.5.3 Es ist anzunehmen, dass die beiden Zustände 010011 und 001010 in Bezug auf ihre eigene Komplexität gleichwertig sind. 2.1.2.6 Das Durchführen einer absoluten Prüfung aller möglicher Zustände ist bei heutigen Computersystemen aufgrund der vielfältigen und umfassenden Ressourcen (CPU, Festplatte, RAM, ...) wohl nie wirtschaftlich rechtfertigbar. 2.1.2.6.1 Aus diesem Grund wird gerne davon gesprochen, dass es nie 100 %ige Sicherheit gibt. 2.1.2.6.2 Richtig muss es aufgrund dessen heissen, "dass sich 100 %ige Sicherheit in der Praxis in der Regel wirtschaftlich nicht beweisen (oder erreichen) lässt". 2.1.2.6.3 Statistisch gesehen vermag es durchaus in der absoluten Mehrheit der Fälle (~99,9 %) gegeben sein, dass Sicherheit weder vorhanden noch beweisbar ist. 2.2 Eine Gefahr generiert sich dadurch, dass die gegebene Unsicherheit auch ausgenutzt werden wird. Dies wird als Risiko bezeichnet. 2.2.1 Das Ausnutzen einer Unsicherheit kann verschiedene Motive haben. 2.2.1.1 Es wird in der Gegenwart und Zukunft immer jemanden geben, der mit einem entsprechenden Motiv daherkommen wird. 2.2.1.1 In populistischen Diskussionen wird fälschlicherweise gerne angenommen, dass Geldgier das zentrale Motiv der meisten Übergriffe darstellt. 2.2.1.2 Spieltrieb und Neugierde sind wohl die wichtigsten Motive vieler Errungenschaften, auch im Bereich der Computersichersicherheit. 2.2.1.3 Es zeichnet sich der Trend ab, dass die meisten effektiv ausgenutzten Unsicherheiten aus Gründen des Gelds angegangen werden. 2.2.2 Je einfacher ein Handlungsspielraum ist, desto eher werden sich Leute in diesem bewegen wollen. 2.2.2.1 Deshalb werden statistisch und längerfristig auch mehr in diesem agieren. 2.2.2.2 Die Einfachheit einer Umgebung führt zu mehr Akzeptanz. Die Popularität vieler Produkte ist auf ihre Einfachheit zurückzuführen. 2.2.2.2.1 Neben Funktionalität ist Ergonomie längerfristig die treibende Kraft für den Verkauf von Produkten. 2.2.2.2.2 Microsoft konnte ihre Windows-Plattform mitunter wegen der damals herausragenden Einfachheit der Bedienung etablieren. 2.2.2.2.3 Apple konnte ihre Produkte (z.B. iPod und iPhone) als Stilmittel etablieren und damit eine ungeahnte Akzeptanz für sich gewinnen. 2.2.2.3 Mit einem Mehr an Akzeptanz für eine Umgebung wird automatisch ein Mehr an potentiellen Angreifern erschlossen. Wer in einer Umgebung agieren kann, ist ein potentieller Angreifer. 2.2.2.3.1 Unpopuläre Betriebssysteme und Applikationen sehen sich mit einer geringen Anzahl an interessierten Angreifern konfrontiert. 2.2.2.3.2 Nur weil für ein Produkt wenige Schwachstellen publiziert wurden, heisst dies nicht, dass es auch wenige Schwachstellen in diesem gibt. Ebenso könnte es sein, dass sich halt nur wenige auf die Suche nach diesen gemacht haben. 2.2.3 Je wertvoller die erreichbaren Möglichkeiten sind, desto eher werden sich die Leute diesen nähern wollen. 2.2.3.1 Der Wert einer Möglichkeit ist nur bedingt objektiv. 2.2.3.1.1 Die Existenz ihrer wird sich noch am ehesten objektiv mit dem dualen Zustand {gegeben, nicht gegeben} bestimmen lassen. 2.2.3.1.2 Spätestens bei der Quantisierung wird es schwierig, einen Konsens zu finden. 2.2.3.2 Wohl in den meisten Fällen ist der absolute Wert vollumfänglich subjektiv definiert. 2.2.3.2.1 Eine Information A kann für eine Person X sehr wertvoll sein. Für Person Y ist sie es hingegen nicht. 2.2.3.2.2 Das Stehlen von Ressourcen (z.B. CPU-Leistung) kann für einen Schüler sehr wertvoll sein. Für einen Mathematiker mit freiem Zugang ins akademische Rechenzentrum jedoch eher weniger. 2.2.3.2.3 Die Möglichkeit des Abbuchens von sFr. 10'000.- kann für Person Y sehr viel sein. Für Person X jedoch nicht (da sie sowieso mehr Geld besitzt oder sich weniger für dieses begeistern kann). 2.2.4 Das potentielle Risiko orientiert sich an der Qualität und Quantität der drohenden Gefahr. 2.2.4.1 Die Qualität der Gefahr ist durch ihre Mächtigkeit definiert. Diese ist aus den verfügbaren Ressourcen (Zeit und Wissen) beschaffen. 2.2.4.1.1 Zeit ohne Wissen ist genauso unbrauchbar wie Wissen ohne Zeit. 2.2.4.1.2 Wissen und Zeit kann man sich in beschränktem Masse "erkaufen". Es wird sich meistens jemanden finden lassen, der etwas kann sowie machen will und auch die Zeit dafür hat. 2.2.4.2 Die Quantität der Gefahr ist durch die Anzahl potentieller Angreifer definiert. 2.2.4.2.1 Ein jeder Mensch gilt im weitesten Sinn theoretisch als potentieller Angreifer. 2.2.4.2.2 Die Anzahl der effektiven potentiellen Angreifer kann nie die Anzahl der existierenden Nutzer (potentiell agierende Entitäten eines Systems) übersteigen. 2.2.4.2.3 Die Anzahl der effektiven Angreifer kann nicht ermittelt werden, bevor sie nicht einen Angriffsversuch unternommen haben. 3 Eine unzulässige Handlung ist ein Angriff. 3.1 Ein Angriffsversuch ist die Grundlage eines erfolgreichen Angriffs. 3.1.1 Ein Angriffsversuch erfordert die Möglichkeit mindestens einer Handlung. 3.1.2 Ein Angriffsversuch, der mit ausschliesslich einer Handlung initiiert wird, wird als One-Shot bezeichnet. 3.1.2.1 Ein misslungener One-Shot Angriff sagt lediglich etwas über die Sicherheit bezüglich des spezifischen Angriffsversuchs aus. 3.1.3 Je mehr Angriffsversuche durchgeführt werden können, desto eher lässt sich die Qualität des Angriffs optimieren. 3.1.3.1 Mittels Iteration wird zum perfekten Angriff konvergiert. 3.1.3.2 Es gibt immer mindestens einen perfekten Angriff. 3.1.3.2.1 Ein Angriff ist dann perfekt, wenn er ausschliesslich und unmittelbar das ihm vorgegebene Ziel erreicht. 3.1.3.2.2 Zwei Angriffsvarianten zur Ausnutzung einer Schwachstelle können bezüglich ihres Perfektionismus gleichwertig sein. 3.1.3.3 Intelligente Systeme versuchen Angriffsversuche frühzeitig zu erkennen und weitere Zugriffe zu unterbinden. 3.1.3.3.1 Für die Erkennung von Angriffsversuchen ist traditionell ein Intrusion Detection-System (IDS) zuständig. 3.1.3.3.1.1 Das Erkennen von Angriffsversuchen kann durch verschiedene Mechanismen erreicht werden. 3.1.3.3.1.2 Bei einem pattern-basierten Ansatz werden typische Muster von Angriffen gesucht (z.B. Vielzahl an fehlgeschlagenen Authentisierungsversuchen indizieren eine Bruteforce-Attacke). 3.1.3.3.1.3 Das Erkennen von Angriffsmustern erfordert, dass diese bekannt und eindeutig identifizierbar sein müssen. 3.1.3.3.1.4 Um die Nachteile der pattern-basierten Lösung auszumerzen, wird eine Anomaly Detection angestrebt. Bei dieser werden Abweichungen vom üblichen Verhalten als Angriffsversuche verstanden. 3.1.3.3.2 Für das Unterbinden von weiteren Angriffsversuchen ist in der Regel ein Intrusion Prevention-System (IPS) verwendet.
3.1.3.3.2.1 Im weitesten Sinn kann auch ein restriktives Firewall-Element als Intrusion Prevention-System verstanden werden. 3.1.3.3.2.2 Ebenso ist irgendwodurch eine Antiviren-Lösung, die den Zugriff auf infizierte Objekte unterbindet, eine Intrusion Prevention-Lösung. 3.1.3.3.3 Ein Intrusion Prevention-System kann entweder durch Unterbinden von Kommunikationsübertragungen oder Unterbinden von Kommunikationsmöglichkeiten funktionieren. 3.1.3.3.3.1 Durch das Unterbinden von Kommunikationsübertragungen wird der Datenaustausch zwischen Angreifer und Opfer verhindert. 3.1.3.3.3.2 Durch das Unterbinden von Kommunikationsübertragungen wird mit dem Angreifer derartig umgegangen, dass er nicht mehr wie gewünscht agieren kann. 3.1.3.3.3.3 Das Unterbinden von Kommunikationsübertragungen durch den Angreifer erfolgt durch einen Gegenangriff. 3.1.3.3.3.4 Ein Gegenangriff durch ein Sicherheitssystem wird als Strike-Back Verfahren bezeichnet. 3.1.3.3.3.5 Ein jeder automatische Mechanismus zur Veränderung von Nutzungsmöglichkeiten kann missbraucht werden. Automatische Filter-Listen oder Strike-Back Verfahren lassen sich oftmals für Denial of Service-Zwecke einspannen. 3.2 Ein erfolgreicher Angriff erfordert die Möglichkeit einer erfolgreichen Handlung ausserhalb des vorgesehenen Handlungsspielraums. 3.2.1 Er beweist die praktische Unsicherheit des Systems im gegenwärtigen Zustand. 3.2.2 Ist nach dem Durchspielen aller erdenklichen Angriffsversuche kein erfolgreicher Angriff erreicht, kann das System punktuell (bezüglich der Angriffstechnik und des Angriffszeitpunkts) als sicher eingestuft werden. 3.3 Ein erfolgreicher Angriff kann zu einem späteren Zeitpunkt in gleicher Weise wiederholt werden. In manchen Fällen ist dies aber nicht möglich. 3.3.1 Nur weil sich ein Angriff zu einem späteren Zeitpunkt nicht mehr wiederholen lässt, heisst dies nicht, dass eben diese Unsicherheit nicht bestand, nicht mehr besteht oder nicht mehr bestehen wird. 3.3.1.1 Sicherheit ist und bleibt ein Zustand, der sofort wieder verfallen kann. 3.3.1.1.1 Die Sicherheit verfällt unter Umständen dann, wenn sich etwas am System ändert. 3.3.1.1.1.1 Ein geprüftes und als sicher identifiziertes System, sollte nach einer Änderung einer erneuten Prüfung unterzogen werden. 3.3.1.1.1.2 Eine erneute Prüfung eines Systems nach einer Änderung wird als Re-Check bezeichnet. 3.3.1.1.1.3 Eine erneute Prüfung eines Systems nach einer Änderung erfordert im Idealfall nur die Prüfung der veränderten und tangierten Elemente. Man spricht in diesem Fall von einer Delta-Analyse. 3.3.1.1.2 Die Sicherheit kann aber auch erst dann verfallen, wenn mit dem System interagiert wird (Faktor Mensch). 3.3.1.1.2.1 Eine umfassende Sicherheitsüberprüfung untersucht also auch die Möglichkeiten des effektiven Betriebs. 3.3.1.1.2.2 Eine umfassende Sicherheitsüberprüfung im laufenden Betrieb wird als Live-Test bezeichnet. 3.3.1.2 Sicherheit muss als fortwährenden Prozess verstanden werden. 3.3.1.2.1 Dieser erdachte Prozess versucht einzelne Zustände der erreichten Sicherheit aneinanderzureihen. 3.3.1.2.1.1 Die Aussage "Sicherheit ist ein Prozess" (Bruce Schneier, Crypto-Gram Newsletter, May 15, 2000) müsste also korrekterweise "Beständige Sicherheit ist ein Prozess" lauten. 3.3.1.2.1.2 Nicht jeder Prozess schafft automatisch die gewünschte und erforderliche Sicherheit. 3.3.1.2.1.3 Ein Prozess hat aufgrund des individuellen Handlungsspielraums und der individuellen Unsicherheit ebenso in individueller Weise zu erfolgen. Es gibt keinen allgemeingültigen Prozess. 3.3.1.2.2 Dadurch wird der Schein der stetigen Sicherheit erschaffen und gewahrt. 3.3.2 Eine geringe Änderung im System kann dazu führen, dass ein Angriff nicht mehr erfolgreich sein kann. 3.3.2.1 Zur Erhöhung der Sicherheit müssen Massnahmen ergriffen werden, die den Handlungsspielraum derartig anpassen, dass kein erfolgreicher Angriff mehr erfolgen kann. Ist eine Massnahme erfolgreich, wird sie als Gegenmassnahme (Gegen die Unsicherheit) bezeichnet. 3.3.2.1.1 Eine Massnahme kann auf unterschiedlichen Ebenen angesetzt werden. 3.3.2.1.1.1 Die offensichtliche Lösung besteht in der Anpassung der betroffenen Komponente selbst. Dies kann ein System, eine Applikation, ein Modul, eine Codeblock oder ein Funktionsaufruf sein. Das Problem wird hierbei "an der Wurzel gepackt". 3.3.2.1.1.2 Im Rahmen der vielschichtigen Sicherheit (Layered Security) können komplementäre Lösungen aber auch auf anderen Komponenten (Routing, Firewall, vertragliche Anpassung, ...) umgesetzt werden. 3.3.2.1.1.3 Wo eine Massnahme umgesetzt wird, ist in Bezug auf das Verhindern der Unsicherheit sekundär. Bevorzugt sollte aber die zentrale Herangehensweise sein, um Kompetenzüberschneidungen, Missverständnisse und Lücken zu verhindern. 3.3.2.1.3 Eine effektive Massnahme bringt lediglich solche Änderungen ein, die die Möglichkeiten des Angriffs verändern. Nicht jedoch die Möglichkeiten der erlaubten Handlungen. 3.3.2.1.3.1 Die geringste Veränderung, die von einer Unsicherheit zur Sicherheit führt, gilt als die effizienteste Massnahme. Sie wird auch als minimales Delta (mindel) bezeichnet. 3.3.2.1.3.2 Das gänzliche Eliminieren eines Handlungsspielraums zur Behebung einer Unsicherheit ist am effektivsten, da ebenfalls sämtliche Varianten adressiert werden. 3.3.2.1.3.3 Eine Veränderung, die den Angriff in seiner Form verändert, ihn jedoch nicht verhindert, ist nicht als (umfassende) Gegenmassnahme zu verstehen. 3.3.2.1.4 Das Erhöhen der Kompliziertheit bzw. Komplexität eines Systems kann als Massnahme verstanden werden. 3.3.2.1.4.1 Das Erweitern der Kompliziertheit eines Systems zur Erhöhung der Sicherheit wird abwertend als "Security By Obscurity" bezeichnet. 3.3.2.1.4.2 Das Erhöhen der Kompliziertheit einer Lösung lässt im besten Fall einen erfolgreichen Angriff verhindern, sofern der Angreifer an der Kompliziertheit unmittelbar scheitert. 3.3.2.1.4.3 Das Erhöhen der Kompliziertheit einer Lösung lässt jedoch im schlechtesten Fall einen Angriff nur verzögern, wenn der Angreifer in der Lage ist, irgendwann mit dieser umzugehen. 3.3.2.1.4.4 Nur weil einem etwas komplex oder kompliziert erscheint, heisst es nicht, dass es (für andere) komplex oder kompliziert ist. 3.3.2.1.4.5 Echte langfristige Sicherheit kann nicht mit der Erhöhung der Kompliziertheit erreicht werden, wie Auguste Kerckhoffs in seinem Kerckhoffs’schen Prinzip bewiesen hat: "Il faut qu'il n'exigé pas le secret, et qu'il puisse sans inconvénient tomber entre les mains de l'ennemi". ("La cryptographie militaire", 1883, S. 12) 3.3.2.1.4.6 Mit dem Erhöhen der Kompliziertheit wird in überproportionaler Weise das Risiko für Fehler verdichtet. Längerfristig wird damit also die Sicherheit verringert. Der vermeintliche Vorteil wird damit zum latenten Nachteil. (Avishai Wool, "A quantitative study of firewall configuration errors", 2004) 3.3.2.1.4.7 Unabsichtlich eingeführte Kompliziertheit gründet sich oftmals darin, überhastet ein unmittelbares Problem lösen zu wollen. Damit verbaut man sich langfristig Möglichkeiten. 3.3.2.1.4.8 Das Entgegenwirken von Kompliziertheit zur Verhinderung von Fehlern wird umgangssprachlich mit dem an das KISS-Prinzip und Ockhams Rasiermesser angelehnten Spruch "Keep it simple and secure" zusammengefasst. (Johannes Clauberg, 1654) 3.3.2.2 Es gibt Situationen, in denen soll oder kann die Sicherheit durch Massnahmen nicht erhöht werden. 3.3.2.2.1 Eine exakte Risikokalkulation hilft zu erkennen, ob und inwiefern das Akzeptieren eines Risikos die richtige Entscheidung ist. 3.3.2.2.1 Eine umfassende Gegenmassnahme adressiert ebenfalls die Varianten eines Angriffs. 3.3.2.2.1.1 Die Variante eines Angriffs nimmt eine Kardinaleigenschaft dessen und führt diesen mit anderen Optionen durch. 3.3.2.2.1.1 Eine Risikokalkulation orientiert sich an der Wirtschaftlichkeit der Möglichkeiten. 3.3.2.2.1.2 Die Wirtschaftlichkeit einer Risikokalkulation kennt nur sich selbst als Antrieb. Auf Schönheit und Eleganz wird verzichtet. 3.3.2.2.1.2 Ein Angriff ohne Eigenschaften gibt es nicht. Eine Handlung ist die Summe ihrer Eigenschaften. 3.3.2.2.1.3 Besteht ein Angriff aus lediglich einer Eigenschaft und wird diese als Variante verändert, entsteht jedoch ein komplett neuer Angriff und keine eigentliche Variante. 3.3.2.2.1.4 Schlussendlich sind alle Angriffe miteinander verwandt (ähnliche Varianten/Eigenschaften). 3.3.2.2.2 Handelt es sich um die richtige Entscheidung auf eine technische Massnahme zu verzichten, wird das Risiko als gegeben akzeptiert. 3.3.2.2.2.1 Tritt ein Ereignis ein, bei dem das Risiko akzeptiert wurde, und stellt sich die Tragweite des Angriffs grösser dar als erwartet, war die erste Kalkulation nicht korrekt. 3.3.2.2.2.2 Eine als falsch erwiesene Risikokalkulation ist unter gewissen Umständen unbrauchbar, da das Risiko nicht wie gewünscht getragen wird. 3.3.2.2.2.3 Eine fehlerhafte Risikokalkulation ist spätestens dann als unbrauchbar anzusehen, wenn durch sie die falschen Entscheidungen getroffen wurden. Sie muss in diesem Fall neu berechnet werden. 4 Unsicherheiten und Angriffe sind unter sich nicht gleichwertig. 4.1 Die Qualität einer Unsicherheit ist von der erforderlichen Effizienz und Eleganz, die für einen erfolgreichen Angriff unabdingbar ist, abhängig. 4.1.1 Die Qualität einer Unsicherheit hat in einem gewissen Rahmen Einfluss auf die Qualität eines Angriffs. 4.1.2 Die Qualität einer Unsicherheit ist umso grösser, je mehr Handlungspielraum sie ungewollt zur Verfügung stellen kann. 4.1.3 Die Einstufung einer Unsicherheit muss objektiv erfolgen. 4.1.3.1 Leider ist das Erstellen eines metrischen Systems in höchstem Mass einer Subjektivität unterworfen. 4.1.3.1.1 Es gibt verschiedene metrische Systeme zur Bewertung von Unsicherheiten. 4.1.3.1.2 Ein Metrisches System kann eine Skala von 1 bis 100 aufweisen. Alternativ kann es vier Abstufungen Low (L), Medium (M), High (H) und Emergency (E) haben. 4.1.3.1.2.1 Das Common Vulnerability Scoring System (CVSS) hat sich als einheitliches System zur Ausweisung von Wichtigkeit und Priorität von Schwachstellen etabliert (http://www.first.org/cvss/). Es verwendet sechs unterschiedliche Basis Metriken, die ihrerseits individuelle Abstufungen mitbringen.
4.1.3.1.2.2 Nessus, der bekannte und ehemals quelloffene Vulnerability Scanner, verwendet die sechs Risikoabstufungen None, Low, Medium, High, Serious und Critical.
4.1.3.1.3 Je mehr Stufen eine Skala zulässt, desto genauer lassen sich Fehler klassifizieren. 4.1.3.1.4 Je genauer sich ein Fehler klassifizieren lässt, desto schwieriger und aufwendiger wird dieser Prozess. 4.1.3.2 Eine Unsicherheit kann in den Phasen der Risikoanalyse und Risikobewertung nach verschiedenen Gesichtspunkten klassifiziert werden.
4.1.3.2.1 Typischerweise wird das Risiko (risk) einer Unsicherheit eruiert.
4.1.3.2.2 Alternativ wird der Schweregrad (severity) einer Unsicherheit eruiert.
4.1.3.2.3 Granulare Bewertungen berücksichtigen Eigenschaften wie Eintrittswahrscheinlichkeit (frequency), Schadensauswirkung (impact), Einfachheit (simplicity) und Popularität (popularity) einer Unsicherheit.
4.1.4 Eine Unsicherheit A kann als Grundlage für eine Unsicherheit B dienen. 4.1.4.1 Die Grundlage A kann dabei eine niedrige oder gleichwertige Einstufung wie die weiterführende Unsicherheit B haben. 4.1.4.1.1 Beispiel für eine niedrige Voraussetzung und eine mittlere Konsequenz: (1) Ein System ist über das Internet erreichbar. (2) Das Betriebssystem kann mittels TCP/IP-Fingerprinting identifiziert werden. 4.1.4.1.2 Beispiel für eine mittlere Voraussetzung und eine mittlere Konsequenz: (1) Ein Dienst wird mit dem Klartextprotokoll HTTP bereitgestellt. (2) Über diesen Dienst werden kundenspezifische Daten übertragen. 4.1.4.2 Es ist jedoch nicht möglich, dass eine Grundlage A höher eingestuft wird, weder die weiterführende Unsicherheit B. 4.1.4.3 Ebenso ist es nicht möglich, dass in symmetrischer und zeitgleicher Weise sowohl die Unsicherheit A die Grundlage für Unsicherheit B als auch die Unsicherheit B die Grundlage für Unsicherheit A ist.
4.2 Die Qualität eines Angriffs kann, unabhängig vom charakteristischen Erfolg dessen, unterschiedlich ausfallen. 4.2.1 Ein Angriff gilt als effizient, wenn er mit einem Minimum an Bewegung im auferlegten Handlungsspielraum durchgeführt werden kann. 4.2.2 Ein Angriff gilt als elegant, wenn er den auferlegten Handlungspielraum in unerwarteter und kreativer Weise nutzt. 4.2.2.1 Die Definition von Kreativität ist vom gegebenen Handlungsspielraum abhängig. 4.2.2.2 Je grösser der Handlungsspielraum ist, desto mehr Möglichkeiten gibt es für Komplexität, nicht jedoch automatisch ebenso für Kreativität. 4.2.2.3 Kreativität ist verbrauchbar. Ein erfolgreicher und bekannter Angriff mit einem gewissen Mass an Kreativität verliert mit zunehmender Durchführung eben diese. 4.2.2.3.1 Ein erstmalig ausgeführter Angriff wird als 0-Day (Zero-Day) bezeichnet.
4.2.2.3.2 Ein Angriff in seiner gegebenen Form kann keine Kreativität gewinnen [+], sondern diese nur erstellen [*] oder wahren [=]. 4.2.2.3.3 Erst Varianten und Weiterführungen können weitere Kreativität wieder bzw. weiter aufbauen [+]. 4.2.2.4 Ein fortwährend erfolgreich durchführbarer Angriff hat in seiner Rohform keine Kreativität mehr. 4.2.2.4.1 Subkulturell gesehen werden Angriffe ohne Kreativität nicht mehr als "Hack" verstanden. 4.2.2.4.2 Angriffe ohne Kreativität werden vorzugsweise durch Skriptkiddies durchgeführt. 4.2.2.4.3 Die Möglichkeit der fortwährenden Ausführbarkeit eines Angriffs bildet die Grundlage für das systematische Automatisieren dessen.
4.2.2.4.3.1 Das unmittelbare automatische Ausnutzen einer Schwachstelle wird durch einen dedizierten Exploit erreicht.
4.2.2.4.3.2 Das breitflächige Ausnutzen einer Schwachstelle kann durch einen automatisierten Wurm vorangetrieben werden.
4.2.2.4.3.3 Das automatische Prüfen einer Schwachstelle wird durch die Integration des Angriffsverfahrens in einen Vulnerability Scanner erreicht.
4.2.3 Ein Angriff gilt als einfach, wenn für die erfolgreiche Durchführung ein Minimum an Effizienz und Eleganz erforderlich ist. 4.2.3.1 Eine grosse Unsicherheit erfordert lediglich einen kleinen Angriff. 4.2.3.2 Die kleinste Unsicherheit erfordert hingegen den effektivsten Angriff. 4.2.4 Das Messen der Qualität eines Angriffs an der Qualität des Angreifers ist subjektiv und damit minderwertig. 4.2.4.1 Es lassen sich vier unterschiedliche Angreifertypen definieren. 4.2.4.1.1 Der Angreifertyp mit dem niedrigsten technischen Verständnis ist der normale Endanwender (User). 4.2.4.1.1.1 Jeder Mensch ist mindestens zu Beginn seines Herangehens an Technologien ein normaler Endanwender.
4.2.4.1.1.2 Die Altersstruktur von Endanwendern ist nicht klar definierbar. Dies kann sowohl ein Jungendlicher sein, der sein erstes Mobiltelefon bekommen hat. Oder eine erwachsene Person, die seit jeher alltägliche Dinge mit dem Computer macht (z.B. Emails lesen und Briefe schreiben).
4.2.4.1.2 Interessiert sich ein Endanwender ein bisschen für Sicherheit und versucht er mit Tools und Exploits zu hantieren, spricht man von einem Skriptkiddie (SK). (Eric S. Raymond, The New Hacker's Dictionary. 1996, ISBN 0-262-68092-0) 4.2.4.1.2.1 Skriptkiddies haben ihren Namen daher, weil sie vordefinierte Angriffsmuster befolgen (Skripte), ohne diese zu verstehen. 4.2.4.1.2.2 Ein Skriptliddie ist nicht in der Lage, bekannte Angriffsstrategien der Situation anzupassen oder eigene Angriffstechniken zu entwickeln. 4.2.4.1.2.3 Das typische Alter von Skriptkiddies ist zwischen 16 und 25 Jahren angesiedelt. 4.2.4.1.2.4 Die Hauptmotivationen für Skriptkiddies sind in der Regel Geltungsdrang oder kindliche Neugierde. 4.2.4.1.2.5 Skriptkiddies sind, wohl in erster Linie wegen ihrer typischen Motivation, zu einem hohen Anteil männlich. 4.2.4.1.3 Das intensive Auseinandersetzen mit einem spezifischen Fachgebiet führt zu einem semi-professionellen Fachspezialisten. 4.2.4.1.3.1 Fachspezialisten tendieren dazu, eher einzelgängerisch und sozial zurückgezogen zu leben. 4.2.4.1.3.2 Fachspezialisten sind normalerweise junge Erwachsene im Alter zwischen 20 und 35 Jahren. 4.2.4.1.3.3 Fachspezialisten stammen aus bzw. finden sich in erster Linie im universitären Umfeld (Studenten). 4.2.4.1.3.5 Eine jede Person kann in einem Bereich ein Fachspezialist sein (z.B. Telefonie) und zeitgleich in einem anderen ein normaler Endanwender (z.B. Betriebssysteme). 4.2.4.1.4 Das grösste technische Verständnis erlangen professionelle Angreifer. 4.2.4.1.4.1 Professionelle Angreifer verdienen hauptberuflich oder nebenher Geld mit ihrer Tätigkeit. 4.2.4.1.4.2 Professionelle Angreifer arbeiten hauptsächlich als Security Consultants (Marktwirtschaft), für Nachrichtendienste oder die organisierte Kriminalität. 4.2.4.1.4.3 Ein professioneller Angreifer, der regulär als Security Consultant arbeitet und deshalb keine bösartigen Ziele verfolgt, wird als White Hat bezeichnet. 4.2.4.1.4.4 Ein professioneller Angreifer, der in krimineller Weise vorgeht, wird als Black Hat bezeichnet. 4.2.4.1.4.4 Fachspezialisten arbeiten typischerweise als Administratoren oder Programmierer. 4.2.4.1.4.5 In der Regel sehen sich nur professionelle Angreifer in der Lage, Angriffe in systematischer und wirtschaftlicher Weise anzugehen. 4.2.4.1.4.6 Professionelle Angreifer sind die einzigen, die sich in der Lage sehen, immerwährend bekannte Angriffsstrategien den aktuellen Bedürfnissen anzupassen oder neue Angriffstechniken zu entwickeln. 4.2.4.2 Ein kleiner Angriff eines professionellen Angreifers kann nämlich ein grosser Angriff eines unbedarften Skriptkiddies darstellen. 4.2.4.3 Die Vergleichbarkeit der Qualität von Angriffen auf einzelne Unsicherheiten erfordert eine objektive Messung in Relation zur tangierten Unsicherheit als solche. 5 Eine Programmcode mit unerwünschten Nebeneffekten gilt als korrupter Programmcode. 5.1 Ein korrupter Programmcode ist nur dann korrupt, wenn er unerwünscht ist. Jeglicher andere Code ist bis zu dieser Definition entweder legitim oder unnötig. 5.1.1 Programmcode ist dann legitim, wenn er eine Arbeit ausführt, die ausgeführt werden will und soll. 5.1.2 Programmcode ist dann unnötig, wenn er Arbeit ausführt, die nicht ausgeführt werden muss oder müsste. 5.1.2.1 Unnötiger Programmcode ist für die Ineffizienz von Anwendungen und Computersystemen verantwortlich. 5.1.2.2 Ein Computersystem ist umso ineffiizenter, desto mehr unnötiger Programmcode ausgeführt wird. 5.1.2.3 In gewissem Sinne ist also auch eine NOP-Anweisung ineffizient. Es sei denn, sie wird für eine höhere Aufgabe (z.B. Synchronisation von Threads) genutzt. Wie zum Beispiel ein Leerlaufprozess (Idle Task). 5.1.3 Um einen korrupten Programmcode als solchen erkennen zu können, muss man sich seiner Nützlichkeit/Erwünschtheit bewusst werden. 5.2 Es gibt verschiedene Arten korrupten Programmcodes. 5.2.1 Die populärste Form korrupten Programmcodes sind Computerviren. 5.2.1.1 Computerviren waren zu Zeiten des Computer-/Internet-Booms am meisten verbreitet, sind aufgrund dessen am meisten diskutiert und auch von der breiten Öffentlichkeit am ehesten verstanden. 5.2.1.2 Die kleinste Definition eines Computervirus lautet, dass es sich dabei um sich selber reproduzierenden Programmcode handelt. 5.2.1.2.1 Die offensichtlichste und einfachste Replikation liegt im Anlegen einer Kopie. 5.2.1.2.2 Ein Computervirus, der sich selbst in den Programmcode anderer Dateien kopiert und die Original-Datei damit (teilweise) überschreibt, wird als Overwriting-Virus bezeichnet. 5.2.1.2.3 Ein Computervirus, der sich selbst an den Programmcode einer bestehenden Datei anhängt, wird als Appending-Virus bezeichnet. 5.2.1.2.4 Ein Computervirus kann auch alternative Bereiche eines Computers als Brutstätte gebrauchen (z.B. RAM als TSR-Virus oder Bootsektor als Bootsektor-Virus). 5.2.1.3 Die Schadensroutine eines Computervirus ist optional und nicht als Kardinaleigenschaft eines solchen anzusehen. 5.2.1.3.1 Es gibt bewusste dedizierte Schadensroutinen, die Daten manipulieren oder löschen können. 5.2.1.3.2 Je nach Definition und Umsetzung kann aber auch die Reproduktion des Virus selbst als Schadensroutine verstanden werden (Ressourcen verbrauchen: Speicherplatz und CPU-Zeit). Nach dieser Definition ist also jeder Computervirus schädlich. 5.2.1.3.3 Die Schadensroutine ist massgeblich für die Risikoeinstufung und Popularität vieler Viren verantwortlich. 5.2.2 Fast so populär wie Computerviren sind Trojanische Pferde. 5.2.2.1 Trojanische Pferde werden im Volksmund auch als Trojaner bezeichnet. 5.2.2.2 Trojanische Pferd gehören einer gänzlich anderen Familie korrupten Programmcodes an. Es ist nicht selbst um eine Reproduzierung von sich selbst bemüht. 5.2.2.3 Ein Trojanisches Pferd führt im Hintergrund ohne das Wissen oder Einwilligen des Anwenders Operationen durch. 5.2.2.3.1 Ein Trojanisches Pferd, welches Tastatureingaben aufzeichnet, wird als Keylogger bezeichnet. 5.2.2.3.2 Moderne Trojanische Pferde fungieren als Remote-Control-Utilities und erlauben damit die Fernsteuerung eines kompromittierten Systems (z.B. NetBus oder BackOrifice). 5.2.2.4 Ein Trojanisches Pferd kann aber auch zu rein zerstörerischen Zwecken eingesetzt werden. 5.2.2.4.1 In klassischer Hinsicht werden ANSI-Bomben erstellt, um bei einer speziellen Tastatureingabe eine destruktive Aktion durchzuführen (z.B. Löschen von Dateien). 5.2.2.4.2 Es gibt Remote-Control-Utilities, mit denen sich Distributed Denial of Service-Attacken orchestrieren lassen (z.B. TFN und Trin00). 5.2.3 Im weitesten Sinne lässt sich auch ein Exploit als korrupten Programmcode bezeichnen. 5.2.3.1 Ein Exploit ist eine Anleitung oder eine Software, die das Ausnutzen einer Schwachstelle erleichtert oder automatisiert. 5.2.3.1.1 Im weitesten Sinn ist also auch ein Advisory als Exploit (Anleitung) zu verstehen. 5.2.3.1.1.1 Ein Advisory ist eine Meldung, die einen Fehler skizziert. Sie wurden früher auch Bulletin genannt. 5.2.3.1.1.2 Advisories können sowohl vom Finder einer Schwachstelle als auch vom Unternehmen, dessen Software betroffen ist, herausgegeben werden. 5.2.3.1.1.3 Als effiziente und freundliche Lösung wird empfunden, dass der Finder den Entwickler zuerst über das Problem informiert und ihm einige Tage/Wochen Zeit einräumt, sich dessen anzunehmen (z.B. Patch oder Upgrade). Nach der Herausgabe einer Lösung wird sodann ein Advisory veröffentlicht. Dies wird als Disclosure bezeichnet. 5.2.3.1.1.4 Advisories werden in der Regel über Security-Mailinglisten (z.B. Bugtraq oder Full-Disclosure) publiziert und durch Nachrichtenportale (z.B. Heise) weiterverbreitet. 5.2.3.1.1.5 In Verwundbarkeitsdatenbanken (z.B. http://www.securityfocus.com/bid und http://www.scip.ch/cgi-bin/smss/showadvf.pl) werden bisher veröffentlichte Fehler katalogisiert und damit für Recherchen zugänglich. 5.2.3.1.2 Exploits lassen sich sowohl für bösartige als auch für gutartige Zwecke einsetzen. 5.2.3.1.3 Exploits helfen dabei, Schwachstellen systematisch auszunutzen. Dadurch wird in Sicherheitsüberprüfungen effizient ihre Existenz bewiesen sowie ihre Tragweite determiniert. 5.2.3.1.4 Das pauschale Verbieten von Exploits verhindert, dass Penetration Tester effizient und zuverlässig Sicherheitslücken analysieren können. 5.2.3.1.4.1 Gegen sogenannte Hackerparagrafen (z.B. StGB § 202c in Deutschland), die Exploits verbieten wollen, wird damit argumentiert, dass die Professionalisierung von Sicherheitsüberprüfungen verhindert wird. 5.2.3.1.4.2 Exploits sollten nicht pauschal verboten werden. Ein ethischer Kodex sowie klar definierte Kommunikationswege können jedoch dabei helfen, dass auch Entwickler, Administratoren und Nutzer von vermeintlich bösartiger Software profitieren können. 5.2.3.2 Will ein Anwender einen Exploit nutzen, ist er für ihn selbst nicht als korrupter Programmcode zu verstehen. Jedoch gegenüber dem System, welches damit angegriffen wird. 5.3 Korrupter Programmcode lässt sich unter gewissen Umständen als solchen erkennen. 5.3.2 Viele Antiviren-Lösungen benutzen eine patternbasierte Methode, um typische Zeichen bekannter Schädlinge zu entdecken. 5.3.2.1 Dies setzt voraus, dass der Schädling und seine Struktur bekannt sind, analysiert und in der Pattern-Datenbank vermerkt wurden. 5.3.2.1.1 Ein Pattern kann also immer nur nach der Entwicklung eines korrupten Programmcodes erstellt werden. 5.3.2.1.2 Durch diese naturbedingte Latenz handelt es sich hier zwangsweise um ein reaktionäres Verfahren. 5.3.2.1.3 Das Umsetzen von präventiven Patterns ist zwar theoretisch möglich, in der Praxis jedoch nicht anwendbar, da man nicht im Vornherein wissen kann, welche Struktur neue Schädlinge aufweisen werden. 5.3.2.2 Starre Pattern-Mechanismen sehen sich ausser Stand, Varianten von korruptem Programmcode ebenfalls als solchen zu erkennen. 5.3.2.2.1 Hersteller von Antiviren-Lösungen pflegen Varianten von korruptem Programmcode mit Buchstaben-Codes zu nummerieren (z.B. W32.Troj.a, W32.Troj.b, ...). 5.3.2.2.2 Polymorpher Programmcode ist explizit darum bemüht, sein Auftreten (jedoch nicht zwingend auch sein Verhalten) bei unterschiedlichen Ausführungen zu ändern, um einem Pattern-Matching entgegenzuwirken. 5.3.3 Bei einer heuristischen Analyse wird das Verhalten einer Software auf potentiell schädliche Routinen hin geprüft (z.B. Funktion zum Löschen ganzer Datenträger). 5.3.3.1 Ein heuristisches Verfahren sieht sich in der Lage, die Latenz des patternbasierten Ansatzes wettzumachen, indem sich auch neue und unbekannte Schädlinge aufgrund ihres dubiosen Verhaltens identifizieren lassen. 5.3.3.2 Auch eine heuristische Analyse kann man kompromittieren, indem absichtlich scheinbar legitime Kommandoabfolgen programmiert werden. 5.3.3.2.1 Soll mittels Heuristik eine destruktive Routine zum Löschen ganzer Laufwerke der Form delvolume("C:\") entdeckt werden, kann mit mehrmaligem Aufrufen dedizierter Löschbefehle while(sleep 1); delfile(volume, directory, file); die Mächtigkeit der Schadensroutine verschleiert werden. 5.3.3.2.2 Durch das Überdecken von Verhaltensmustern können die wahren Absichten verschleiert werden. Das Löschen von Dateien kann zum Beispiel auffälliger sein weder das Überschreiben dieser. Letzteres ist nämlich das legitime Verhalten der meisten Applikationen. 5.3.3.3 Da bei einer heuristischen Analyse jeder Funktionsaufruf des Programms geprüft werden muss, hat dies entsprechend negative Auswirkungen auf Ressourcen und Performance des Systems. 5.3.4 Korrupter Programmcode lässt sich entfernen. 5.3.4.1 Um korrupten Programmcode entfernen zu können, muss dieser eindeutig als solcher identifiziert und vom legitimen Programmcode getrennt werden können. 5.3.4.1.1 Hat ein korrupter Programmcode legitimen Programmcode zerstört (z.B. gelöscht oder überschrieben), kann durch das Entfernen des korrupten Programmcodes nicht wieder automatisch eine saubere und voll funktionstüchtige Umgebung gewährleistet werden. 5.3.4.1.2 Bei bekannten Schädlingen, die Daten mutwillig zerstören, können gewisse Antiviren-Lösungen mit eigenen Patches aufwarten, um beschädigte Datenteile wieder herstellen zu können. 5.3.4.2 Nur weil ein korrupter Programmcode A als solcher identifiziert und entfernt wurde, muss das desinfizierte System nicht zwangsweise komplett gesäubert sein. Ein anderer korrupter Programmcode B könnte übersehen worden sein. 5.3.4.2.1 Ein kompromittiertes System kann nur mit absoluter Sicherheit gesäubert werden, wenn es komplett und unter strengster Beobachtung neu aufgesetzt wird. 6 Sensitive Daten müssen vor Manipulationen geschützt werden. 6.1 Eine unerwünschte Manipulation ist die unerlaubte Einsicht durch Dritte. Die Daten verlieren dadurch ihre Vertraulichkeit. 6.1.1 Das Mitlesen einer Kommunikation wird umgangssprachlich als Lauschangriff bezeichnet.
6.1.1.1 Als "Grosser Lauschangriff" werden Überwachungen staatlicher Dienste (Strafverfolgungsbehörden und Nachrichtendienste) bezeichnet.
6.1.1.1.1 Echelon ist der Name eines der bekanntesten Spionagenetzes der Welt.
6.1.1.1.1.1 Der Name Echelon leitet sich wohl von der antiken Schlachtordnung ab. Im deutschen Sprachgebrauch wird sie "Schiefe Schlachtordnung" genannt und im Englischen als gestaffelte Schlachtordnung verstanden.
6.1.1.1.1.2 An Echelon sind die Staaten USA, Vereinigtes Königreich (UK), Kanada, Australien und Neuseeland beteiligt.
6.1.1.1.1.3 Echelon war ursprüngliche dazu gedacht, die militärische und diplomatische Kommunikation der Sowjetunion und ihrer Verbündeten abzuhören.
6.1.1.1.1.4 Heute wird das System zur Suche nach terroristischen Verschwörungen, Aufdeckung im Bereich der organisierten Kriminalität und als politischer sowie diplomatischer Nachrichtendienst benutzt.
6.1.1.1.1.5 Seit Ende des Kalten Krieges dient dieses System angeblich auch der Wirtschaftsspionage. Verschiedene Zwischenfälle und Berichte erhärten diese Mutmassung.
6.1.1.1.2 Mit Onyx wird das Satellitenabhörsystem der Schweiz bezeichnet.
6.1.1.1.2.1 Onyx wird durch den Militärischen Nachrichtendienst (MND) sowie durch den Strategischen Nachrichtendienst (SND), welcher für das Ausland zuständig ist, genutzt.
6.1.1.1.2.2 Die erste Inbetriebnahme von Onyx erfolgte 2000.
6.1.1.1.2.3 Der operationelle Probebetrieb wurde 2001 gestartet.
6.1.1.1.2.4 Im Jahr 2004 wurde dann der operationelle Betrieb von Onyx aufgenommen.
6.1.2 Um eine unerwünschte Einsicht zu verhindern, kann ein abgeschotteter (dedizierter) Kanal genutzt werden. 6.1.2.1 Ein Kanal gilt als abgeschottet, wenn er nicht durch andere Medien benutzt wird oder werden kann. 6.1.2.2 Mit einem VPN (Virtual Private Network) lässt sich auch über geteilte Leitungen (vorwiegend dem Internet) ein abgeschotteter Kanal realisieren. 6.1.3 Ist das Einsetzen eines dedizierten Kanals nicht möglich, muss eine Verschlüsselung ihre Anwendung finden. 6.1.3.1 Daten, die ohne Verschlüsselung übertragen werden, werden als Klartext (Cleartext oder Plaintext) bezeichnet. 6.1.3.2 Daten, die mit einer Verschlüsselung übertragen werden, werden als Geheimtext (Ciphertext) bezeichnet. 6.1.3.3 Eine symmetrische Verschlüsselung benutzt den gleichen Schlüssel K. Für die Verschlüsselung der Nachricht M wird die Funktion EK(M) = C verwendet. Die Entschlüsselung findet sodann mit der Funktion DK(C) = M statt. 6.1.3.3.1 Die Funktionen für die Verschlüsselung und die Entschlüsselung sind invers, weshalb DK(EK(M)) = M sowie EK(DK(C) = C gelten. 6.1.3.3.2 Da die Sicherheit einer symmetrischen Verschlüsselung auf der Geheimhaltung des Schlüssels basiert, wird sie auch als Private-Key Encryption bezeichnet. 6.1.3.3.3 Ist einem Angreifer der Schlüssel sowie die mit diesem verschlüsselten Geheimtexte bekannt, kann er sie nach Belieben wieder entschlüsseln. 6.1.3.3.4 Ist einem Angreifer der Schlüssel bekannt, kann er nach Belieben eigene Geheimtexte generieren (Forgery). 6.1.3.3.5 Lange Zeit wurde DES (Data Encryption Standard) als Standardverschlüsselung eingesetzt. Im Oktober 2000 wurde er jedoch vom NIST durch AES (Advanced Encryption Standard) abgelöst. 6.1.3.4 Eine asymmetrische Verschlüsselung benutzt für die Verschlüsselung und die Entschlüsselung zwei unterschiedliche Schlüssel. 6.1.3.4.1 Es wird ein sogenanntes Schlüsselpaar (Key Pair) mit den Schlüsseln K1 und K2 verwendet. 6.1.3.4.2 Mit dem eigenen geheimen Schlüssel K1 (Private Key) werden Daten durch EK1(M) = C verschlüsselt. 6.1.3.4.3 Mit dem öffentlichen Schlüssel einer anderen Person (Public Key) K2 werden die Daten durch DK2(M) = M wieder entschlüsselt. Damit gilt DK2(EK1(M)) = M. 6.1.3.4.4 Da eine asymmetrische Verschlüsselung die Weitergabe des öffentlichen Teils des Schlüsselpaars erfordert, wird sie auch als Public-Key Encryption bezeichnet. 6.1.3.4.5 Die grössten Nachteile asymmetrischer Verschlüsselungen sind die Performance sowie der Schlüsselaustausch. 6.1.3.4.5.1 Der Schlüsselaustausch bei asymmetrischen Verfahren wird normalerweise mit klassischer symmetrischer Methoden bewerkstelligt. Man spricht sodann von Hybridverfahren, die die Vorteile beider Ansätze kombinieren.
6.1.3.4.5.2 Um Fälschungen und Manipulationen der bereitgestellten öffentlichen Schlüssel zu erkennen bzw. verhindern, kann eine Public Key Infrastructure (PKI) eingesetzt werden. Diese lässt mittels vertrauenswürdiger Zertifikate der Certificate Authority (CA) die Bestätigung der Echtheit der öffentlichen Schlüssel zu.
6.1.3.4.6 Es gibt eine Reihe asymmetrischer Kryptosysteme.
6.1.3.4.6.1 Das im Jahr 1977 entwickelte RSA (Ronald L. Rivest, Adi Shamir und Leonard M. Adleman) geniesst die meiste Akzeptanz. 6.1.3.4.6.2 Darauf folgten Systeme wie McEliece (1978). Rabin (1979), Chor-Rivest (1984) und Elgamal (1985).
6.1.3.5 Es gibt verschiedene Methoden, wie eine verschlüsselte Kommunikation angegriffen werden kann. Dies wird als Kryptoanalyse (cryptanalysis) bezeichnet. 6.1.3.5.1 Bevor eine verschlüsselte Nachricht angegriffen werden kann, muss man in den Besitz dieser kommen. 6.1.3.5.1.1 Typischerweise werden hierzu Geheimtexte abgefangen (Sniffing). 6.1.3.5.1.2 In gewissen Fällen lassen sich Geheimtexte auch selber generieren. 6.1.3.5.2 Man unterscheidet zwischen sechs Angriffsmethoden auf kryptgrafische Systeme. 6.1.3.5.2.1 Die Grundlage der meisten kryptoanalytischen Attacken sind statistische Analysen (z.B. Häufigkeitsanalyse), bei denen Auffälligkeiten als solche erkannt werden. 6.1.3.5.2.3 Bei einer Known-Plaintext Attacke hat der Kryptoanalytiker sowohl Zugriff auf den Klartext als auch auf den Geheimtext von Nachrichten. Aus dem Klartex Pi sowie dem Geheimtext Ci = EK(Pi) soll entweder der Schlüssel K oder das Verständnis für Pi+1 von Ci+1 = EK(Pi+1) ermittelt werden. 6.1.3.5.2.4 Bei einer Chosen-Plaintext Attacke sieht sich der Kryptoanalytiker in der Lage, aus eigens definierten Klartexten entsprechende Geheimtexte zu generieren. So definiert sich der Klartext Pi sowie der Geheimtext Ci = EK(Pi), wobei entweder der Schlüsel K ermittelt oder ein Algorithmus gleichwertig zu Pi+1 von Ci+1 = EK(Pi+1) ermittelt werden soll. 6.1.3.5.2.5 Bei einer Chosen-Ciphertext Attacke wählt der Kryptoanalytiker verschiedene Klartexte, die es zu entschlüsseln gilt. Durch den Zugriff auf die generierten Geheimtexte soll der Schlüssel K ermittelt werden. Diese Angriffstechnik wird primär bei Public-Key Algorithmen angewendet. Chosen-Plaintext Attacken kombiniert mit Chosen-Ciphertext Attacken werden auch als Chosen-Text Attacken bezeichnet. 6.1.3.5.2.6 Eine eher unpopuläre und unpraktikable Technik der Kryptoanalyse ist die Chosen-Key Attack. Bei dieser bringt der Kryptoanalytiker einige Kenntnisse bezüglich der Relationen verschiedener Schlüssel mit. 6.1.3.5.2.7 Bei Rubber-Hose Cryptanalysis wird jemand bedroht, erpresst oder gefoltert, damit er Informationen zu einem kryptographischen System herausgibt. Hierbei handelt es sich nicht um eine klassische Kryptoanalyse auf technischer Ebene. 6.1.3.5.3 Man unterscheidet zwischen vier unterschiedlichen Stufen der erfolgreichen Kryptoanalyse. 6.1.3.5.3.1 Bei einem totalen Bruch findet der Kryptoanalytiker den geheimen Schlüssel K, so dass er DK(C) = P generieren kann. 6.1.3.5.3.2 Bei einer Ciphertext-Only Attacke wird aus der Reihe von Geheimtexten {C1 = EK(P1), C = EK(P2), ... Ci = EK(Pi)} entweder der Klartext {P1, P2, ... Pi}, der Schlüssel K oder ein Algorithmus gleichwertig zu Pi+1 von Ci+1 = EK(Pi+1) ermittelt. 6.1.3.5.3.2 Bei einer Global Deduction findet der Kryptoanalytiker einen alternativen Algorithmus A, mit dem er DK(C) = P durchführen kann, ohne den Schlüssel K zu kennen. 6.1.3.5.3.3 Bei einer Instance oder Local Deduction identifiziert der Kryptoanalytiker einen dedizierten Geheimtext einer abgefangenen Nachricht. 6.1.3.5.3.4 Bei einer Information Deduction ermittelt der Kryptoanalytiker etwelche Infromationen über den Schlüssel oder den Klartext. Dies können einzelne Teile des Schlüssels oder die grundlegende Struktur der Nachricht sein. 6.1.3.5.3.5 Ein Kryptoalgorithmus gilt als unbedingt sicher, wenn ein Kryptoanalytiker selbst mit einer beliebigen Anzahl an Geheimtexten keine erfolgreiche Kryptoanalyse durchführen kann. 6.1.3.6 Durch Quantenkryptografie kann ein auf physikalischer Ebene abhörsicherer Kanal erreicht werden.
6.1.3.6.1 Das rein passive und damit unidentifizierbare Mithören des quantenkryptografisch geschützten Datenaustauschs ist aufgrund der heisenberg'schen Unschärferelation nicht möglich.
6.1.3.6.1.1 Durch das Messen eines Zustands, dies ist beim Abhören einer elektronischen Kommunikation ebenso erforderlich, wird dieser unweigerlich verändert (Werner Heisenberg, Physikalische Prinzipien der Quantentheorie, 1930).
6.1.3.6.1.2 Das Mitlesen der Kommunikation kann so bemerkt und neu initiiert werden.
6.1.3.6.2 Die Quantenkryptografie ist aufgrund ihrer Komplexität und Instabilität in erster Linie nur für einen sicheren Schlüsselaustausch vorgesehen.
6.1.3.6.3 Das BB84-Protokoll ist in der Quantenkryptografie das wohl bekannteste Verfahren zur Schlüsselerzeugung (Charles H. Bennett, Gilles Brassard, 1984).
6.2 Eine weitere unerwünschte Manipulation ist die Veränderung. Die Daten verlieren dadurch ihre Integrität. 6.2.1 Typischerweise werden digitale Signaturen eingesetzt, um die Integrität (Fälschbarkeit) und Authentizität (Herkunft) von Daten verifizieren zu können. 6.2.1.1 Bei einer digitalen Signatur wird der private Schlüssel nicht direkt auf die Nachricht angewendet, sondern auf deren Hash-Wert, der mittels einer Hash-Funktion (wie z. B. SHA-1) aus der Nachricht berechnet wird. 6.2.1.2 Bei deterministischen digitalen Signaturverfahren ist die digitale Signatur durch die Nachricht und den Schlüssel eindeutig festgelegt. 6.2.1.3 Bei probabilistischen digitalen Signaturverfahren gehen Zufallswerte in die Signaturberechnung ein, so dass die digitale Signatur zu einer Nachricht und einem Schlüssel viele verschiedene Werte annehmen kann. 6.2.2 Es gibt auch hier verschiedene Verfahren zur Generierung elektronischer Signaturen. 6.2.2.1 Das mit Abstand und seit Jeher bekannteste Verfahren ist RSA, welches sich die Schwierigkeit der Faktorisierung grosser Primzahlen zunutze macht. 6.2.2.1.1 Es gibt verschiedene Arten, Primzahlen zu generieren. 6.2.2.1.1.1 Eine gerade für die Generierung grosser Primzahlen beliebte Methode ist die Mersenne-Zahl Mn = 2^n - 1, bei der Mn zuvor ebenfalls eine Primzahl ist. 6.2.2.1.1.2 Fermat vermutete, dass alle Zahlen der Form 2^2^n + 1 prim sind. Tatsächlich ist aber für n > 4 keine solche Fermat-Zahl bekannt. 6.2.2.1.2 Bei der Primfaktorzerlegung wird eine natürliche Zahl als Produkt von Primzahlen dargestellt (z.B. 30 = 2 × 3 × 5). 6.2.2.1.2.1 Die Primfaktorzerlegung der natürlichen Zahl 1 besteht aus einem leeren Produkt. 6.2.2.1.2.2 Bei einer kanonischen Primfaktorzerlegung sind die Primfaktoren nach ihrer Grösse geordnet und zu Potenzen zusammengefasst (z.B. 6936 = 2^3 × 3 × 17^2). 6.2.2.1.3 Es ist in der Regel viel einfacher eine Primzahl zu generieren, weder auf diese eine Primfaktorzerlegung anzuwenden. 6.2.2.1.3.1 Die Firma RSA Security startete am 18. März 1991 die RSA Factoring Challenge, bei der die Sicherheit von RSA durch die Schwierigkeit der Faktorisierungen bewiesen werden soll. 6.2.2.1.3.2 Die Primfaktorzerlegung der 174-stelligen Zahl für RSA576 wurde im Dezember 2003 von J. Franke und T. Kleinjung vom Max Planck Institut für Mathematik in Bonn und dem Experimentellen Mathematischen Institut in Essen gefunden. Das Preisgeld lag bei 10.000 US$. 6.2.2.1.3.3 Die Primfaktorzerlegung der 193-stelligen Zahl von RSA640 wurden im November 2005 von F. Bahr, M. Boehm, J. Franke, T. Kleinjung, die zuvor schon RSA 200 faktorisiert hatten, gefunden. Das Preisgeld lag bei 20.000 US$. 6.2.2.2 Alternativ werden DSA, El-Gamal und Schnorr-Signaturen eingesetzt, die einen diskreten Logarithmus in endlichen Körpern anwenden. 6.2.2.3 ECDSA, ECGDSA oder Nyberg-Rueppel-Signaturen verwenden einen diskreten Logarithmus in elliptischen Kurven. 6.2.2.3.1 Systeme auf der Basis elliptischer Kurven (Elliptic Curve Cryptosystems, ECC) wurden immer populärer, da sie mit wesentlich kleineren Schlüssellängen auskommen.
6.2.3 Das Gewährleisten der Integrität kann ebenso durch eine Verschlüsselung realisiert werden. 6.2.3.1 Um die Daten bewusst zu verändern, müsste die Verschlüsselung dem Angreifer bekannt und durch ihn reproduzierbar sein. 6.3 Eine andere unerwünschte Manipulation ist das Verzögern oder Unterbinden des Datenflusses. Die Daten verlieren dadurch ihre Verfügbarkeit. 6.3.1 Eine destruktive Attacke auf einen Dienst wird als Denial of Service (DoS) bezeichnet. 6.3.1.1 Werden verschiedene Systeme eingespannt, um eine Denial of Service-Attacke durchzusetzen, spricht man von einer Distributed Denial of Service Attacke (DDoS). 6.3.1.1.1 Um orchestrierte DDoS-Attacken durchzuführen, wird ein Multi-Tier-Modell angestrebt.
6.3.1.1.2 DDoS-Attacken werden in der Regel von einem Management-System orchestriert.
6.3.1.1.3 In einem 3-Tier-Modell werden die Anweisungen des Management-Systems von einem Handler entgegengenommen und an die jeweiligen Agents verteilt. Der Handler agiert dabei quasi als intelligenter Proxy.
6.3.1.1.4 Das Durchführen der eigentlichen DoS-Attacke wird durch die unterschiedlichen Agents vorgenommen.
6.3.1.1.4.1 Ein Agent in einem DDoS-Netz ist normalerweise zuvor kompromittiert und zweckentfremdet worden.
6.3.1.1.4.2 Ein DDoS-Agent, der zuvor kompromittiert und zweckentfremdet wurde, wird als Zombie bezeichnet.
6.3.1.1.4.3 Der DDoS-Server auf einem Zombie-Host ist als spezielle Hintertür zu verstehen.
6.3.1.1.5 Zu den klassischen Implementierungen von DDoS-Lösungen gehören Trinoo, TFN (Tribe Flood Network) und Stacheldraht. Sie wurden teilweise seit Ende der 90er Jahren öffentlich gemacht, jedoch erst zu Beginn des neuen Jahrtausends breitflächig eingesetzt (CERT® Incident Note IN-99-04).
6.3.2 Die einfachste und direkteste Methode einen Dienst unbrauchbar zu machen, ist diesen zu überlasten. 6.3.2.1 Das Überlasten eines Dienstes mittels einer Vielzahl an (grossen) Anfragen wird als Flooding bezeichnet.
6.3.2.2 Das erfolgreiche Überlasten eines Dienstes erfordert, dass man mit den eigenen verfügbaren Ressourcen die bereitgestellten Ressourcen des Ziels aufbrauchen kann. 6.3.2.2.1 Davon ist grundsätzlich jegliche Ressource betroffen, die limitiert und und alloziiert werden kann. 6.3.2.2.2 Klassisches Beispiel aus dem Betriebssystem-/Netzwerkumfeld ist ein SYN-Flooding, bei dem die Backlog Queue für TCP-Verbindungen aufgebraucht wird. (W. Richard Stevens, TCP/IP Illustrated, Volume 1: The Protocols) 6.3.2.2.2.1 Das Aufbrauchen von Ressourcen kann nie gänzlich verhindert werden.
6.3.2.2.2.2 Durch das intelligente Zuweisen und Entziehen von Ressourcen wird es jedoch möglich, derlei Angriffe sehr aufwendig und damit eher uninteressant zu machen.
6.3.2.3 Da Überlastungsangriffe keine intelligente Interaktion mit einem Zielsystem erfordern, werden sie als besonders einfach und primitiv angesehen. (Marc Ruef, Die Kunst des Penetration Testing, 2007)
6.3.3 Schlecht umgesetzte oder gewartete Dienste lassen sich unter Umständen als Drittperson einfachso deaktivieren. 6.3.3.1 Im Rahmen von TCP/IP kann beispielsweise ein ARP-Segment mit falscher Adresse für ein Drittsystem verschickt werden, um die Netzwerkkommunikation abrupt abzubrechen. Dies funktioniert jedoch naturbedingt nur in lokalen Netzen (LAN). 6.3.3.2 ICMP-, TCP- und UDP-Kommunikationen lassen sich ebenfalls mit diversen ICMP-Fehlermeldungen (z.B. ICMP port unreachable) beenden. 6.3.3.2.1 Die meisten Verbindungen lassen sich mit spezifischen ICMP-Fehlermeldungen unterbrechen.
6.3.3.2.1.1 Durch das Filtern und/oder Prüfen eingehender ICMP-Fehlermeldungen können derlei Angriffe verhindert werden.
6.3.3.2.1.2 Durch das Filtern und/oder Prüfen ausgehender ICMP-Fehlermeldungen können andere Systeme davor geschützt werden, selber als Agent oder Amplifier für derlei Attacken herzuhalten.
6.3.3.2.2 Eine etablierte TCP-Verbindung kann, sofern die TCP-Sequenznummern richtig erraten werden, mit einem TCP-Verbindungsabbau (RST oder FIN) beendet werden. 6.3.3.2.2.1 Das Voraussagen von TCP-Sequenznummern erfordert, den TCP-Verkehr mitlesen und auswerten zu können. Hierzu wäre also ein Re-Routing-Angriff sowie Sniffing erforderlich.
6.3.3.2.2.2 Das Übernehmen von etablierten Kommunikationsbeziehungen wird als Hijacking bezeichnet.
6.3.3.2.2.3 Erfolgreich übernommene Kommunikationsbeziehungen werden meistens für produktive Zwecke missbraucht (z.B. Mitlesen des Datenaustauschs) anstatt eine destruktive Denial of Service-Attacke durchzusetzen.
6.3.3.2.3 Eine UDP-Verbindung kann in vielen Fällen mit einem gefälschten Verbindungsabbau des Anwendungsprotokolls beendet werden.
6.3.3.2.3.1 UDP-Verbindungen gelten aufgrund fehlender Schutzmechanismen (z.B. keine Sequenznummern) als unzuverlässig. Sie sollten nach Möglichkeiten nie von und über unsichere Netze zugelassen werden.
6.3.3.2.3.2 Der Austausch grösserer Datenmengen sollte aufgrund der Verbindungslosigkeit von UDP lieber mit TCP umgesetzt werden.
6.3.3.3 Wird der Zugriff auf administrative Bereiche möglich (z.B. da eine Authentisierung fehlt), können die Deaktivierungen ganz normal umgesetzt werden. 6.3.3.3.1 Dienste/Systeme können heruntergefahren bzw. deaktiviert werden, um Nutzungsmöglichkeiten zu entziehen.
6.3.3.3.2 Zugriffsmöglichkeiten/-rechte können entzogen oder erweiterte Authentisierugen forciert werden, um Zugriffsmöglichkeiten zu entziehen.
|
© 2007-2024 by Marc Ruef |