4. Common Issues (Häufige Themen)

Obwohl die Sicherheitsanforderungen jedes Systems einzigartig sind, tauchen bestimmte gemeinsame Anforderungen in vielen Protokollen auf. Oft wählen unerfahrene Protokollentwerfer bei diesen Anforderungen eine offensichtliche, aber unsichere Lösung, obwohl bessere existieren. Dieser Abschnitt beschreibt eine Reihe von Themen, die in vielen Protokollen vorkommen, und gängige Sicherheitstechnologien, die bei ihrer Bearbeitung helfen können.

4.1. User Authentication (Benutzerauthentifizierung)

Praktisch jedes System, das den Zugang zu seinen Ressourcen steuern will, braucht eine Möglichkeit, Nutzer zu authentifizieren. Eine schier unübersehbare Zahl solcher Mechanismen wurde dafür entworfen. Die folgenden Abschnitte beschreiben einige dieser Techniken.

4.1.1. Username/Password (Benutzername/Passwort)

Der gängigste Zugriffskontrollmechanismus ist einfaches BENUTZERNAME/PASSWORT. Der Nutzer liefert Benutzername und wiederverwendbares Passwort an den Host, den er nutzen will. Dieses System ist anfällig für einen einfachen passiven Angriff: Der Angreifer fängt das Passwort vom Draht ab und startet eine neue Sitzung mit dem Passwort. Die Bedrohung lässt sich mildern, indem das Protokoll über eine verschlüsselte Verbindung wie TLS oder IPSEC betrieben wird. Ungeschützte (Klartext-)Benutzername/Passwort-Systeme sind in IETF-Standards nicht akzeptabel.

4.1.2. Challenge Response and One Time Passwords (Challenge-Response und Einmalpasswörter)

Systeme, die mehr Sicherheit als BENUTZERNAME/PASSWORT wollen, setzen oft ein EINMALPASSWORT [OTP] oder CHALLENGE-RESPONSE ein. Beim Einmalpasswort erhält der Nutzer eine Liste von Passwörtern, die der Reihe nach, jedes nur einmal, genutzt werden müssen. (Oft werden diese Passwörter aus einem geheimen Schlüssel erzeugt, sodass der Nutzer das nächste Passwort einfach berechnen kann.) SecureID und DES Gold sind Varianten. Bei Challenge-Response teilen Host und Nutzer ein Geheimnis (oft als Passwort dargestellt). Zur Authentifizierung stellt der Host eine (zufällig erzeugte) Challenge. Der Nutzer berechnet eine Funktion aus Challenge und Geheimnis und liefert sie dem Host zur Verifikation. Oft geschieht die Berechnung in einem Handgerät, etwa einer DES-Gold-Karte.

Beide Ansätze schützen vor Replay-Angriffen, sind aber oft weiterhin anfällig für einen OFFLINE KEYSEARCH (Form passiven Angriffs): Wie erwähnt wird Einmalpasswort oder Antwort oft aus einem gemeinsamen Geheimnis berechnet. Kennt der Angreifer die Funktion, kann er alle möglichen gemeinsamen Geheimnisse probieren, bis eines die richtige Ausgabe erzeugt. Ist das Geheimnis ein Passwort, kann er einen DICTIONARY ATTACK fahren — er probiert eine Liste gängiger Wörter (oder Zeichenketten) statt zufälliger Zeichenketten.

Diese Systeme sind oft auch aktiven Angriffen ausgesetzt. Wird nicht die gesamte Sitzung kommunikationssicher geschützt, kann der Angreifer warten, bis die Authentifizierung abgeschlossen ist, und die Verbindung kapern.

4.1.3. Shared Keys (Gemeinsame Schlüssel)

CHALLENGE-RESPONSE-Systeme lassen sich gegen Wörterbuchangriffe absichern, indem statt nutzergenerierter Passwörter zufällig erzeugte gemeinsame Schlüssel verwendet werden. Sind die Schlüssel groß genug, werden Schlüsselsuchangriffe unpraktisch. Am besten funktioniert das, wenn die Schlüssel in die Endknoten konfiguriert werden statt von Nutzern auswendig gelernt und eingegeben zu werden, da Nutzer hinreichend lange Schlüssel schwer merken.

Wie passwortbasierte Systeme leiden gemeinsame Schlüssel unter Verwaltungsproblemen. Jedes kommunizierende Paar braucht einen eigenen vereinbarten Schlüssel — es gibt viele Schlüssel.

4.1.4. Key Distribution Centers (Schlüsselverteilungszentren)

Ein Ansatz für das Problem der großen Schlüsselzahl ist eine Online-„vertrauenswürdige dritte Partei“ zwischen den authentifizierenden Parteien. Die vertrauenswürdige dritte Partei (meist KEY DISTRIBUTION CENTER, KDC genannt) teilt mit jeder Partei im System einen symmetrischen Schlüssel oder ein Passwort. Eine Partei wendet sich zuerst an das KDC, das ein TICKET mit einem zufällig erzeugten symmetrischen Schlüssel liefert, verschlüsselt unter den Schlüsseln beider Peers. Da nur die richtigen Peers den symmetrischen Schlüssel entschlüsseln können, etabliert das Ticket eine vertrauenswürdige Bindung. Das mit Abstand populärste KDC-System ist Kerberos [KERBEROS].

4.1.5. Certificates (Zertifikate)

Ein einfacher Ansatz: Alle Nutzer haben ZERTIFIKATE [PKIX] und authentifizieren sich protokollspezifisch, wie in [TLS] oder [S/MIME]. Ein Zertifikat ist ein signiertes Credential, das die Identität einer Entität an ihren öffentlichen Schlüssel bindet. Der Unterzeichner ist eine CERTIFICATE AUTHORITY (CA), deren Zertifikat wiederum von einer übergeordneten CA signiert sein kann. Damit das funktioniert, muss Vertrauen in eine oder mehrere CAs außerband etabliert werden. Solche CAs heißen TRUSTED ROOTS oder ROOT CAs. Das Hauptproblem in Client-Server-Systemen ist, dass Clients Zertifikate brauchen — ein Bereitstellungsproblem.

4.1.6. Some Uncommon Systems (Einige weniger verbreitete Systeme)

Es gibt bessere Ansätze als die oben genannten, aber sie bringen typischerweise wenig zusätzliche Sicherheit, wenn nicht mindestens Kommunikationssicherheit (zumindest Nachrichtenintegrität) die Verbindung schützt — sonst kann der Angreifer nach erfolgter Authentifizierung einfach die Verbindung kapern. Mehrere Protokolle ([EKE], [SPEKE], [SRP]) erlauben, das Nutzerpasswort sicher in einen gemeinsamen Schlüssel zu überführen, der als Eingabe für ein kryptographisches Protokoll dient. Ein großes Hindernis für die Bereitstellung war oft unklarer Intellectual-Property-Status. Ebenso kann der Nutzer mit öffentlichen Schlüsselzertifikaten authentifizieren (z. B. S-HTTP-Client-Authentifizierung). Typischerweise sind diese Methoden Teil eines umfassenderen Sicherheitsprotokolls.

4.1.7. Host Authentication (Host-Authentifizierung)

Host-Authentifizierung ist ein besonderes Problem. Oft werden Dienstadressen als DNS-Hostname angegeben, etwa in einer URL [URL]. Beim Anfordern eines solchen Dienstes muss man sicherstellen, dass der Gesprächspartner nicht nur ein Zertifikat hat, sondern dass es zur erwarteten Serveridentität passt. Wichtig ist eine sichere Bindung zwischen Zertifikat und erwartetem Hostnamen.

Enthält das Zertifikat typischerweise nur eine IP-Adresse als Identität, war die Anfrage aber für einen Hostnamen, ist das inakzeptabel. Das liefert keine Ende-zu-Ende-Sicherheit, weil Hostname-IP-Zuordnung unsicher ist, sofern keine sichere Namensauflösung [DNSSEC] genutzt wird. Das ist besonders problematisch, wenn der Hostname in der Anwendungsschicht erscheint, die Authentifizierung aber in einer tieferen Schicht erfolgt.

4.2. Generic Security Frameworks (Generische Sicherheits-Frameworks)

Sicherheitsfunktionalität in ein Protokoll einzubauen ist schwierig. Neben der Wahl von Authentifizierung und Schlüsselaustausch muss man sie ins Protokoll integrieren. Eine Antwort (in IPsec und TLS verkörpert) ist ein Sicherheitsprotokoll unterhalb zu schaffen und zu verlangen, dass neue Protokolle darüber laufen. Ein anderer, jünger populärer Ansatz sind generische Sicherheits-Frameworks auf Anwendungsebene. Die Idee: ein Protokoll, das verschiedene Sicherheitsmechanismen steckbar aushandelt. Anwendungsprotokollentwerfer transportieren dann die PDUs des Sicherheitsprotokolls in ihrem Anwendungsprotokoll. Beispiele: GSS-API [GSS] und SASL [SASL].

Der generische Framework-Ansatz hat Probleme. Erstens ist er sehr anfällig für DOWNGRADE-ANGRIFFE. In einem Downgrade-Angriff manipuliert ein aktiver Angreifer die Aushandlung, um schwächere Schutzmechanismen zu erzwingen. Man kann nach Aushandlung und Schlüsselaustausch eine Integritätsprüfung einfügen, aber die Stärke ist notwendig auf den schwächsten gemeinsamen Algorithmus begrenzt. Das Problem gibt es bei jeder Aushandlung, aber

generische Frameworks verschärfen es, weil Autoren oft nur das Framework spezifizieren statt über die passenden unterliegenden Mechanismen nachzudenken — und die Mechanismen stark in der gebotenen Sicherheit variieren.

Zweitens ist nicht immer klar, wie Framework-Features mit dem Anwendungsprotokoll interagieren. SASL kann etwa nur zur Authentifizierung dienen — dann läuft der SASL-Austausch, der Rest der Verbindung bleibt ungeschützt — oder auch Verkehrsschutz etwa via GSS aushandeln. Wann Verkehrsschutz optional oder erforderlich ist, hängt vom Bedrohungsmodell ab.

Authentifizierungs-Frameworks sind am nützlichsten, wenn neue Protokolle zu Systemen mit bestehenden Legacy-Authentifizierungssystemen hinzukommen. Ein Framework erlaubt neuen Installationen bessere Authentifizierung, ohne bestehende Sites komplett umzubauen. Sind die Sicherheitsanforderungen klar und nur wenige Authentifizierungsformen im Einsatz, führt ein einzelner Mechanismus zu mehr Einfachheit und Vorhersagbarkeit. Wo ein Framework nötig ist, SOLLTEN Entwerfer die Optionen prüfen und nur zum Bedrohungsmodell passende Mechanismen vorschreiben. Ist ein Framework nötig, SOLLTEN sie ein etabliertes wählen statt ein eigenes zu erfinden.

4.3. Non-repudiation (Nichtabstreitbarkeit)

Der naive Ansatz zu Nichtabstreitbarkeit ist öffentliche digitale Signaturen über den Inhalt. Die Partei, die gebunden sein will (SIGNING PARTY), signiert die Nachricht digital. Die Gegenpartei (RELYING PARTY) kann später auf die Signatur als Beweis verweisen, dass die signierende Partei der streitigen Nachricht zugestimmt hat. Leider reicht das nicht.

Am einfachsten bestreitet die signierende Partei, indem sie behauptet, ihr privater Schlüssel sei kompromittiert und ein Angreifer (nicht notwendig die relying party) habe signiert. Zur Abwehr muss die relying party zeigen, dass der private Schlüssel zum Zeitpunkt der Signatur nicht kompromittiert war. Das erfordert erhebliche Infrastruktur: Archivierung von Zertifikatswiderrufsinformationen und Zeitstempelserver, um die Signaturzeit zu belegen.

Außerdem könnte die relying party die signierende Partei dazu bringen, eine Nachricht zu signieren, während sie eine andere meint. Das ist besonders schwerwiegend, wenn die relying party die Infrastruktur kontrolliert, die die signierende Partei zum Signieren nutzt, etwa Kioske. Oft liegt der Schlüssel der signierenden Partei auf einer Smartcard, die zu signierende Nachricht wird aber von der relying party angezeigt.

All diese Komplikationen machen Nichtabstreitbarkeit in der Praxis schwer bereitzustellen.

4.4. Authorization vs. Authentication (Autorisierung versus Authentifizierung)

AUTHORIZATION (Autorisierung) ist der Prozess, zu bestimmen, ob eine authentifizierte Partei Zugriff auf eine bestimmte Ressource oder einen Dienst hat. Obwohl eng gekoppelt, sind Authentifizierung und Autorisierung getrennte Mechanismen. Wegen dieser engen Kopplung wird Authentifizierung manchmal fälschlich als Autorisierung verstanden. Authentifizierung identifiziert nur eine Partei; Autorisierung legt fest, ob eine Aktion erlaubt ist.

Autorisierung setzt Authentifizierung voraus, aber Authentifizierung allein impliziert keine Autorisierung. Vor Erteilung einer Erlaubnis muss der Autorisierungsmechanismus prüfen, ob die Aktion gestattet ist.

4.4.1. Access Control Lists (Zugriffskontrolllisten)

Eine gängige Autorisierungsform ist eine Zugriffskontrollliste (ACL), die Nutzer auflistet, denen Zugang zu einer Ressource gestattet ist. Da die Zuweisung einzelner Rechte je Ressource mühsam ist, sind Ressourcen oft hierarchisch angeordnet, sodass die ACL der übergeordneten Ressource an Kindressourcen vererbt wird. Administratoren können so oberste Richtlinien setzen und bei Bedarf überschreiben.

4.4.2. Certificate Based Systems (Zertifikatsbasierte Systeme)

Bei einfachen Mechanismen wie Benutzername und Passwort ist der Unterschied zwischen Authentifizierung und Autorisierung intuitiv (jeder versteht Administrator- vs. Nutzerkonto); bei komplexeren Mechanismen geht die Unterscheidung mitunter verloren.

Bei Zertifikaten etwa impliziert eine gültige Signatur keine Autorisierung. Die Signatur muss durch eine Zertifikatskette mit vertrauenswürdiger Wurzel gestützt sein, und diese Wurzel muss im jeweiligen Kontext vertrauenswürdig sein. Nutzer mit Zertifikaten der Acme-MIS-CA können etwa andere Webzugriffsrechte haben als Nutzer mit Zertifikaten der Acme-Accounting-CA, obwohl beide CAs vom Acme-Webserver „vertraut“ werden.

Mechanismen zur Durchsetzung solcher Eigenschaften sind noch nicht vollständig erforscht. Ein Ansatz ist, Richtlinien an ACLs zu hängen, die beschreiben, welche Zertifikate vertrauenswürdig sind. Ein anderer trägt die Information im Zertifikat, etwa als Erweiterung/Attribut [PKIX, SPKI] oder als separates „Attribute Certificate“.

4.5. Providing Traffic Security (Verkehrssicherheit bereitstellen)

Sicher entworfene Protokolle sollten einen Mechanismus bieten, um (Integrität, Authentifizierung und ggf. Verschlüsselung) den gesamten sensiblen Verkehr zu schützen. Ein Ansatz ist das Protokoll selbst zu sichern, wie [DNSSEC], [S/MIME] oder [S-HTTP]. Das liefert die am Protokoll am besten passende Sicherheit, erfordert aber erheblichen Aufwand, es richtig zu machen.

Viele Protokolle lassen sich mit einem der verfügbaren Kanalsicherheitssysteme ausreichend schützen. Wir besprechen die zwei gängigsten, IPsec [AH, ESP] und [TLS].

4.5.1. IPsec (IP-Sicherheit)

Die IPsec-Protokolle (insbesondere AH und ESP) können Übertragungssicherheit für den gesamten Verkehr zwischen zwei Hosts bieten. IPsec unterstützt verschiedene Granularitäten der Nutzeridentifikation, z. B. „IP-Subnetz“, „IP-Adresse“, „vollqualifizierter Domainname“ und einzelner Nutzer („Mailbox-Name“). Diese Identifikationsstufen dienen als Eingaben für Zugriffskontrolleinrichtungen, die integraler Bestandteil von IPsec sind. Eine gegebene IPsec-Implementierung unterstützt jedoch nicht notwendig alle Identitätstypen. Insbesondere können Sicherheitsgateways keine Nutzer-zu-Nutzer-Authentifizierung bieten oder Mechanismen haben, diese Information an Anwendungen zu liefern.

Bei AH oder ESP muss der Anwendungsprogrammierer nichts tun (wenn systemweit aktiviert) oder spezifische Softwareänderungen vornehmen (z. B. setsockopt()-Aufrufe) — je nach Implementierung. APIs zur Steuerung von IPsec sind leider noch nicht standardisiert.

Das Haupthindernis für IPsec zum Schutz anderer Protokolle ist die Bereitstellung. Der Haupteinsatz von IPsec sind VPNs, besonders Remote-Zugang. Ohne sehr enge Abstimmung zwischen Sicherheitsadministratoren und Anwendungsentwicklern eignet sich VPN schlecht für sichere Dienste einzelner Anwendungen, da diese schwer erkennen, welche Dienste tatsächlich geliefert wurden.

IPsec-Host-zu-Host-Bereitstellung war langsam. Anders als TLS erfordert das Hinzufügen von IPsec zu einem Nicht-IPsec-System meist Änderungen am Betriebssystem, Kernel oder neue Treiber — deutlich mehr Aufwand als eine neue Anwendung zu installieren. Neuere Versionen gängiger Betriebssysteme enthalten jedoch IPsec-Stacks, die Bereitstellung wird einfacher.

Wo IPsec sicher verfügbar ist, ist es eine praktikable Option zum Schutz des Anwendungsverkehrs. Ist der zu schützende Verkehr UDP, sind IPsec und objektspezifische Anwendungssicherheit die einzigen Optionen. Entwerfer DÜRFEN NICHT annehmen, dass IPsec verfügbar ist. Eine Sicherheitsrichtlinie für ein generisches Anwendungsprotokoll SOLLTE NICHT einfach fordern, IPsec zu nutzen, ohne Grund zu der Annahme, dass es in der Zielumgebung vorhanden ist. Wo IPsec fehlen kann und der Verkehr nur TCP ist, ist TLS die Methode der Wahl, da der Entwickler die Anwesenheit leicht durch Einbinden einer TLS-Implementierung sicherstellen kann.

Im Sonderfall IPv6 sind AH und ESP implementierungspflichtig. Daher ist es plausibel anzunehmen, dass AH/ESP für IPv6-only-Protokolle oder -Deployments verfügbar sind. Automatisches Schlüsselmanagement (IKE) ist jedoch nicht implementierungspflichtig; Protokollentwerfer SOLLTEN nicht annehmen, dass es vorhanden ist. [USEIPSEC] gibt viel Orientierung, wann IPsec sinnvoll ist.

4.5.2. SSL/TLS (Transportschichtsicherheit)

Derzeit ist der gängigste Ansatz SSL oder den Nachfolger TLS. Sie bieten Kanalsicherheit für eine TCP-Verbindung auf Anwendungsebene, laufen also über TCP. SSL-Implementierungen bieten typisch eine Berkeley-Sockets-ähnliche Schnittstelle. Die Hauptfrage beim Entwurf um TLS ist, TLS-geschützte von ungeschützten Verbindungen zu unterscheiden.

Die zwei Hauptansätze: separater Well-Known-Port für TLS (z. B. HTTP über TLS Port 443) [HTTPTLS] oder Aushandlung vom Basisprotokoll hinauf zu TLS wie in [UPGRADE] oder [STARTTLS]. Bei Aushandlung nach oben muss verhindert werden, dass ein Angreifer Klartext erzwingt, wenn beide Parteien TLS wollen.

TLS hängt von einem zuverlässigen Protokoll wie TCP oder SCTP ab. Zwei Schwierigkeiten: Erstens kann es Datagrammprotokolle über UDP nicht schützen. Zweitens ist TLS IP-Schicht-Angriffen ausgesetzt, IPsec nicht. Typisch DoS oder „connection assassination“. Ein Angreifer könnte z. B. TCP RST fälschen und SSL-Verbindungen schließen. TLS hat Mechanismen gegen Trunkierungsangriffe, die dem Opfer nur zeigen, dass es angegriffen wird, nicht aber Verbindungsüberleben. Mit IPsec könnte ein solches RST verworfen werden, ohne TCP zu beeinträchtigen. Sind gefälschte RSTs ein Thema, sind AH/ESP oder TCP-MD5-Option [TCPMD5] vorzuziehen.

4.5.2.1. Virtual Hosts (Virtuelle Hosts)

Bei separatem Port wird TLS vor Anwendungsverkehr ausgehandelt. Das kann Protokolle mit virtuellen Hosts stören, z. B. [HTTP], weil der Server während des TLS-Handshake nicht weiß, welches Zertifikat er anbieten soll. Die TLS-Hostname-Erweiterung [TLSEXT] kann helfen, ist aber zu neu für breite Bereitstellung.

4.5.2.2. Remote Authentication and TLS (Fernauthentifizierung und TLS)

Eine Schwierigkeit: Der Server wird per Zertifikat authentifiziert. Das ist unbequem, wo bisher nur ein gemeinsames Passwort existierte. Es lockt, TLS ohne authentifizierten Server (anonymes DH oder selbstsigniertes RSA) zu nutzen und dann per Challenge-Response wie SASL mit CRAM-MD5 zu authentifizieren.

Leider ist diese Kombination aus SASL und TLS schwächer als erwartet. Ein aktiver Angreifer kann die Verbindung kapern. Der Client führt MITM auf SSL aus (Server wird nicht authentifiziert, was sonst verhindert) und leitet den SASL-Handshake nur weiter. Danach ist die Verbindung für den Angreifer wie

im Klartext. Zur Abwehr muss der Client das Serverzertifikat prüfen.

Ist der Server authentifiziert, ist Challenge-Response weniger attraktiv. Mit gehärtetem Kanal reichen einfache Passwörter; sie erfordern kein Klartext-Passwort auf dem Server. Kompromittierung der Schlüsseldatei bei Challenge-Response ist ernster als bei einfachen Passwörtern.

Hat der Client ein Zertifikat, kann SSL-Client-Authentifizierung genutzt werden. SASL bietet EXTERNAL: Der Client sagt dem Server, die äußere Kanalidentität zu prüfen. Das unterliegt nicht den obigen Schichtangriffen.

In Spezialfällen kann Kanalsicherheit direkt in der Anwendung statt IPSEC oder SSL/TLS sinnvoll sein, etwa Remote-Terminal-Sicherheit. Zeichen gehen typischerweise einzeln vom Client zum Server. SSL/TLS und AH/ESP authentifizieren und verschlüsseln jedes Paket — das kann die Daten um den Faktor 20 aufblähen. Die Telnet-Verschlüsselungsoption [ENCOPT] verzichtet auf Nachrichtenintegrität und vermeidet diese Expansion.

Beim Remote-Terminal will man oft weitere Kommunikation sicher abwickeln. Neben Remote-Login bietet SSH [SSH] sicheres Port-Forwarding für beliebige TCP-Ports. SSH-Port-Forwarding kann ein Sicherheitsrisiko sein, wenn es Firewalls umgeht und unsichere interne Anwendungen nach außen exponiert.

4.6. Denial of Service Attacks and Countermeasures (Dienstverweigerungsangriffe und Gegenmaßnahmen)

DoS-Angriffe gelten zu oft als unvermeidlich. Ein Problem: Der Angreifer kann oft aus vielen DoS-Formen wählen, und weil die meisten nicht zu verhindern sind, wird angenommen, es lohne nicht, sich gegen eine Art zu schützen, wenn viele andere möglich bleiben.

Doch nicht alle DoS sind gleich, und wichtiger: Protokolle können so entworfen werden, dass DoS erschwert oder unpraktisch wird. Jüngere SYN-Fluten [TCPSYN] zeigen beides: SYN-Fluten sind so einfach, anonym und wirksam, dass sie Angreifer mehr anziehen; und TCPs Design ermöglicht den Angriff.

Vollständiger DoS-Schutz ist schwer; pragmatisch vorgehen. Manche wünschenswerte Verteidigungen sind ökonomisch nicht machbar. Ziel ist Risikomanagement: sich gegen Angriffe mit hohem Verhältnis Schwere zu Verteidigungskosten wehren. Schwere und Kosten ändern sich mit der Technologie — ebenso die Menge zu verteidigender Angriffe.

Autoren von Internet-Standards MÜSSEN beschreiben, welchen DoS-Angriffen ihr Protokoll ausgesetzt ist. Die Beschreibung MUSS Gründe nennen, warum es unvernünftig oder außerhalb des Geltungsbereichs war, diese zu vermeiden.

BLINDE DoS-Angriffe sind besonders bösartig. Beim blinden Angriff hat der Angreifer einen großen Vorteil. Muss er Verkehr vom Opfer empfangen, muss er das Routing unterwandern oder seine echte IP nutzen — beides gibt dem Opfer eine Chance, ihn zu verfolgen oder zu filtern. Beim blinden Angriff kann er gefälschte IPs nutzen; Filterung wird extrem schwer. TCP-SYN-Flut ist ein blindes Beispiel. Entwerfer sollten alles tun, blinde DoS zu verhindern.

4.6.2. Distributed Denial of Service (Verteilte Dienstverweigerung)

Noch gefährlicher sind verteilte DoS-Angriffe (DDoS, Distributed Denial of Service) [DDOS]. Der Angreifer organisiert, dass viele Maschinen gleichzeitig das Ziel angreifen, oft durch Infektion vieler Hosts mit Fernsteuerung. Die angreifenden Maschinen heißen ZOMBIEs und gehören oft ahnungslosen Dritten woanders als der echte Angreifer. DDoS sind schwer zu bekämpfen, weil Zombies legitime Protokollanfragen scheinen zu stellen und

echte Nutzer verdrängen. DDoS sind schwer zu stoppen; Protokollentwerfer sollen sich dieser Formen bewusst sein.

4.6.3. Avoiding Denial of Service (Dienstverweigerung vermeiden)

Zwei gängige Ansätze, DoS zu erschweren:

4.6.3.1. Make your attacker do more work than you do (Dem Angreifer mehr Arbeit als sich selbst aufbürden)

Verbraucht der Angreifer beim Angriff mehr eigene Ressourcen als Sie, können schwächere Angreifer nicht wirksam angreifen. Üblich: den Angreifer zeitintensive Operationen wie Kryptographie ausführen lassen. Mit genug CPU kann er dennoch DoS fahren; verteilte Angriffe wie [TCPSYN] stoppt das nicht.

4.6.3.2. Make your attacker prove they can receive data from you (Den Angreifer Datenempfang nachweisen lassen)

Blindangriffe lassen sich erschweren, indem der Angreifer beweisen muss, dass er Daten vom Opfer empfangen kann. Üblich: Antwort mit Information, die früher im Austausch gewonnen wurde. Dann muss der Angreifer seine echte Adresse nutzen (verfolgbar) oder eine Adresse fälschen, deren Antwortroute über den Angriffs-Host führt.

Kleine Subnetz-Host sind dem Angreifer (bei Spoofing) nutzlos, da der Angriff auf ein Subnetz zurückverfolgt werden kann; Grenzrouter können den Subnetzverkehr verwerfen.

4.6.4. Example: TCP SYN Floods (Beispiel: TCP-SYN-Fluten)

TCP/IP ist wegen des Drei-Wege-Handshakes anfällig für SYN-Fluten (siehe 3.3.2). Erstens kann ein Angreifer mit einem Paket erhebliche Ressourcen (Speicher) beim Opfer verbrauchen. Zweitens kann er ohne je Daten vom Opfer zu empfangen anonym mit vielen gefälschten Quelladressen angreifen.

4.6.5. Example: Photuris (Beispiel: Photuris)

[PHOTURIS] spezifiziert einen Anti-Clogging-Mechanismus gegen SYN-ähnliche Angriffe. Photuris nutzt ein zeitvariantes Geheimnis für ein „Cookie“ an den Angreifer. Das Cookie muss in Folgenachrichten zurückkommen. Interessant: Das Cookie kann später vom Opfer regeneriert werden — kein Zustand nötig, bis der Angreifer bewiesen hat, Pakete vom Opfer empfangen zu können.

4.7. Object vs. Channel Security (Objekt- versus Kanalsicherheit)

Es ist nützlich, Objektsicherheit und Kanalsicherheit zu unterscheiden. Objektsicherheit schützt ganze Datenobjekte. Kanalsicherheit liefert einen sicheren Kanal, über den Objekte transparent transportiert werden; der Kanal kennt Objektgrenzen nicht.

E-Mail: Über IPSEC- oder TLS-geschützter Verbindung ist die Nachricht unterwegs geschützt, aber ungeschützt im Postfach und in Zwischen-Spools. Mailserver laufen meist als Daemon, nicht als Nutzer — „Authentifizierung“ der Nachricht bedeutet oft nur Authentifizierung des Daemons. Transport ist hop-by-hop; selbst Authentifizierung am ersten Hop kann der Empfänger nicht sicher verifizieren.

Mit S/MIME oder OpenPGP ist die ganze Nachricht verschlüsselt und integritätsgeschützt bis zur Entschlüsselung durch den Empfänger; starke Authentifizierung des tatsächlichen Absenders statt nur der Maschine — Objektsicherheit. Der Empfänger kann die Signatur Dritten gegenüber belegen.

Der Unterschied ist Perspektivsache: Objektsicherheit einer Schicht wirkt oft wie Kanalsicherheit der darüber liegenden. Auf IP-Ebene wirkt jedes Paket wie gesichertes Objekt; für einen Web-Client liefert IPSEC nur einen sicheren Kanal.

Die Grenze ist nicht immer scharf. S-HTTP sichert eine HTTP-Transaktion auf Objektebene; eine Webseite besteht aber aus vielen Transaktionen (Basisseite und

viele eingebettete Bilder) — aus Sicht der Gesamtseite eher Kanalsicherheit. Objektsicherheit für eine Seite wäre Schutz der transitiven Hülle der Seite und aller eingebetteten Inhalte als Einheit.

4.8. Firewalls and Network Topology (Firewalls und Netzwerktopologie)

Üblich ist, Netze mit einer Firewall in extern und intern zu teilen. Das interne Netz gilt als sicher; dort nur begrenzte Maßnahmen. Der interne Teil heißt oft WALLED GARDEN.

Internet-Protokollentwerfer dürfen nicht sicher annehmen, dass ihre Protokolle so eingesetzt werden. Erstens werden Protokolle, die für geschlossene Umgebungen gedacht waren, später im Internet eingesetzt — schwere Lücken.

Zweitens können scheinbar topologisch getrennte Netze es nicht sein (Neukonfiguration, Außenweltzugriff). Firewalls lassen zunehmend generische Anwendungsprotokolle wie [SOAP] oder [HTTP] durch. Darauf basierende Netzprotokolle können nicht allgemein auf Firewall-Schutz bauen. Schließlich droht oft größere Gefahr von Innen als von Außen; Insider haben internen Zugang — topologischer Schutz wie Firewalls hilft nicht.