DE60206856T2 - Verfahren und Vorrichtung zum Schutz von Internetanlagen gegen Denial-of-Service Angriffen - Google Patents

Verfahren und Vorrichtung zum Schutz von Internetanlagen gegen Denial-of-Service Angriffen Download PDF

Info

Publication number
DE60206856T2
DE60206856T2 DE60206856T DE60206856T DE60206856T2 DE 60206856 T2 DE60206856 T2 DE 60206856T2 DE 60206856 T DE60206856 T DE 60206856T DE 60206856 T DE60206856 T DE 60206856T DE 60206856 T2 DE60206856 T2 DE 60206856T2
Authority
DE
Germany
Prior art keywords
packet
service
spe
site
participating
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
DE60206856T
Other languages
English (en)
Other versions
DE60206856D1 (de
Inventor
Jose C. Westfield Brustoloni
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Nokia of America Corp
Original Assignee
Lucent Technologies Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Lucent Technologies Inc filed Critical Lucent Technologies Inc
Application granted granted Critical
Publication of DE60206856D1 publication Critical patent/DE60206856D1/de
Publication of DE60206856T2 publication Critical patent/DE60206856T2/de
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/12Avoiding congestion; Recovering from congestion
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/20Traffic policing
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/31Flow control; Congestion control by tagging of packets, e.g. using discard eligibility [DE] bits
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00Traffic control in data switching networks
    • H04L47/10Flow control; Congestion control
    • H04L47/32Flow control; Congestion control by discarding or delaying data units, e.g. packets or frames
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1408Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • H04L63/1458Denial of Service
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00Network arrangements or protocols for supporting network services or applications
    • H04L67/50Network services
    • H04L67/60Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • H04L67/61Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources taking into account QoS or priority requirements
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40Network security protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/30Definitions, standards or architectural aspects of layered protocol stacks
    • H04L69/32Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
    • H04L69/322Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
    • H04L69/329Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

  • Technisches Gebiet
  • Die vorliegende Erfindung betrifft die Kommunikation über das Internet und insbesondere den Schutz von Servern im Internet vor böswilligen Angriffen, die den Dienst teilweise oder völlig unterbrechen können.
  • Allgemeiner Stand der Technik
  • Bei einem Angriff des Typs Denial-of-Service (DoS) führt ein böswilliger Client (der als Angreifer bezeichnet wird) Operationen durch, die dafür ausgelegt sind, teilweise oder vollständig zu verhindern, daß rechtmäßige Clients mit einem (als Opfer bezeichneten) Server kommunizieren bzw. Dienst von ihm erhalten. Denial-of-Service-Angriffe sind häufig und verursachen signifikante Schäden. Wohlbekannte E-Händler, wie zum Beispiel Amazon, buy.com, E*Trade und eBay, sind unter den neueren Opfern. Denial-of-Service-Angriffe können E-Händler auf zweierlei Weise Schaden zufügen. Erstens verliert, wenn ein E-Händler seine Kunden nicht bedienen kann, der E-Händler Werbe- und Verkaufsumsatz. Zweitens werden die Clients, Werber und Investoren des E-Händlers frustriert und können deshalb nach konkurrierenden Alternativen suchen.
  • Bestimmte Denial-of-Service-Angriffe können durch ordnungsgemäße Systemadministration verhindert werden. Dazu gehören physische oder abgesetzte Übernahmeangriffe und Death-Pill-Angriffe. Bei einem Angriff des physischen Übernehmens erhält der Angreifer physischen Zugang zu Komponenten der Infrastruktur (z.B. einer oder mehreren Strecken, Routern oder Servern) des Internet-Dienstanbieters (ISP) oder E-Händlers und kompromittiert ihre Funktionalität. Bei einem Angriff des abgesetzten Übernehmens nutzt der Angreifer einen bestimmten Programmierfehler in der Software der Infrastruktur aus, um so privilegierten Zugang zu erhalten und somit in der Lage zu sein, die Software aus der Ferne zu modifizieren. Bei einem Death-Pill-Angriff sendet der Angreifer ein Paket oder einige wenige Pakete zu einer Infrastrukturkomponente (z.B. einem Router oder Server), wovon bekannt ist, daß sie einen Programmierfehler enthalten, so daß die Pakete einen Absturz der Komponente bewirken. Ordnungsgemäße physische Sicherheitsmaßnahmen des ISP und E-Händlers können Angriffe der physischen Übernahme eliminieren. Ähnlich kann eine prompte Installation von Patches oder Updates, die Software-Programmierfehler beheben, solche Programmierfehler ausnutzende zukünftige abgesetzte Übernahme- oder Death-Pill-Angriffe verhindern.
  • Denial-of-Service-Angriffe des Stautyps können dagegen nicht ähnlich verhindert werden. Bei einem Angriff des Stautyps überflutet ein Angreifer einen Server mit so vielen Paketen, daß der Server auf von rechtmäßigen Clients gesendete Anforderungen nicht antworten kann. Durch vier Faktoren wird es schwierig, sich vor Angriffen des Stautyps zu verteidigen. Erstens kann jeder beliebige mit dem Internet verbundene Host dazu verwendet werden, einen Angriff des Stautyps gegen ein beliebiges, auch mit dem Internet verbundenes Opfer, zu führen. Durch seinen Entwurf leitet das Internet Pakete von jedem beliebigen Host zu jedem beliebigen anderen Host auf Best-Effort-Basis weiter, ohne die Paketrate oder das Paketvolumen zu begrenzen. Zweitens gibt es viele Hosts (z.B. in Privatwohnungen und Universitäten), die mit dem Internet verbunden sind und nicht über ordnungsgemäße Systemadministration verfügen. Solche Hosts können häufig Programmierfehler enthalten oder sind so konfiguriert, daß Angreifer ohne Autorisation diese als Agenten, d.h. als die Hosts, die tatsächlich Angriffspakete zu einem Opfer senden können, benutzen können. Agenten ermöglichen Tarnung und Verstärkung für einen Angreifer, d.h. verbergen die Identität des Angreifers bzw. vervielfachen die Betriebsmittel (z.B. Bandbreite) des Angreifers.
  • Drittens können Angreifer Angriffspakete fälschen, d.h. die Quellenadresse der Pakete verfälschen. Fälschung ist möglich, weil das Internet Quellenadressen nicht validiert. Durch Fälschung wird die Tarnung eines Angreifers weiter verstärkt. Schließlich können leicht automatisierte Werkzeuge zunehmender Kompliziertheit zum Organisieren von Denial-of-Service-Angriffen aus dem Web heruntergeladen werden. Mit solchen Werkzeugen können sogar unerfahrene Webbenutzer erfolgreiche Angriffe organisieren.
  • Die beiden zur Zeit am beliebtesten Techniken der Denial-of-Service-Angriffe, Smurf und TCP-SYN-Überflutung, sind beide vom Stautyp. Bei einem Smurf-Angriff sendet der Angreifer ICMP-Echoanforderungen zu einer Broadcast-Adresse eines Netzwerks. Der Angreifer fälscht die Anforderungen mit der Adresse des Opfers. Deshalb sendet jeder Host in dem Netzwerk eine Antwort nicht zu dem Angreifer, sondern zu dem Opfer und wird somit unwissend zu einem Agenten des Angriffs. Bei einem TCP-SYN-Überflutungsangriff senden der Angreifer oder seine Agenten gefälschte TCP-SYN-(d.h. Verbindungsanforderungs-)Pakete zu dem Opfer. Jede solche falsche Anforderung bewirkt, daß das Opfer Betriebsmittel belegt, die ansonsten für Anforderungen von rechtmäßigen Clients verwendet werden könnten.
  • Um Smurf-Angriffe zu verhindern, hat die IETF (Internet Engineering Task Force) die Vorgabebehandlung von gerichteten Broadcast-Paketen durch Router verändert. Anstatt gerichtete Broadcast-Pakete anzunehmen und weiterzuleiten, sollten Router diese nun per Vorgabe abwerfen. Um Fälschung unwirksam zu machen, hat die IETF zusätzlich Eingangsfilterung empfohlen (siehe z.B. P. Ferguson und D. Senie, „Network Ingress Filtering: Defeating Denial of Service Attacks Which Employ IP Source Address Spoofing", IETF, RFC 2827 (auch BCP 0038), Mai 2000). Mit Eingangsfilterung sollten ISP-Eingangsrouter ein Paket, das in einem Port ankommt, abwerfen, wenn die Quellenadresse des Pakets nicht mit einem mit dem Port assoziierten Präfix übereinstimmt. Eingangsfilterung stoppt automatisch Angriffe, die Fälschung erfordern. Wenn ein Angriff, der keine Fälschung verwendet, auftritt, ermöglicht die Eingangsfilterung darüber hinaus eine Bestimmung des Ursprungs des Angriffs einfach durch Untersuchen der Quellenadressen von Angriffspaketen. Die Eingangsfilterung kann die Wiederherstellung nach solchen Angriffen deshalb beschleunigen. Nachteiligerweise müssen die Empfehlungen der IETF von vielen Teilnehmern (unwissend bei Smurf-Angriffen verwendeten Netzwerken und ISPs) angewendet werden, die dadurch durch neue Verantwortlichkeiten und Kosten belastet werden, aber kein Entgeld zur Lösung von etwas, was sie möglicherweise als das Problem eines anderen (des E-Händlers) betrachten, erhalten. Außerdem schrecken diese Empfehlungen nicht alle möglichen Denial-of-Service-Angriffe des Stautyps ab. Auch ohne Fälschung und gerichtetes Broadcast können Angreifer Agenten dazu verwenden, die für erfolgreiche Angriffe notwendige Tarnung und Verstärkung zu erhalten. Die Annahme dieser Empfehlungen (insbesondere der Eingangsfilterung) hat deshalb bisher nicht sehr um sich gegriffen.
  • IP-Rückverfolgung ist eine in letzter Zeit vorgeschlagene Alternative zur Eingangsfilterung (siehe z.B. S. Savage, D. Wetherall, A. Karlin und T. Anderson, „Practical Network Support for IP Traceback", Proc. SIGCOMM'2000, Seiten 295–306, ACM, Stockholm, Schweden, Aug. 2000). Im Gegensatz zur Eingangsfilterung kann IP-Rückverfolgung auch dann effektiv sein, wenn sie nicht weithin eingesetzt wird. IP-Rückverfolgung modifiziert Router dergestalt, daß sie Rückverfolgungsinformationen probabilistisch zu dem Ziel eines Pakets senden können. Durch statistische Verfahren kann ein Opfer mit solchen Informationen den Angriffsweg (den rekonstruierten Teil, der dem Opfer am nächsten kommt) teilweise rekonstruieren. IP-Rückverfolgung hat jedoch Schwächen, die sich nachteilig auf die Wahrscheinlichkeit ihrer Anwendung auswirken können. Es scheint, daß Angreifer IP-Rückverfolgung leicht unwirksam machen können, indem Angriffe indirekt durchgeführt werden, d.h. indem vorgeblich Nachbarn des Opfers anstelle des Opfers selbst aufs Korn genommen werden. Außerdem können Rückverfolgungsinformationen, die von Routern gesendet werden, die weiter von dem Opfer entfernt sind als der nächste Angreifer, gefälscht werden und erfordern deshalb Authentifikation. Die notwendige Infrastruktur für eine solche Authentifikation kann für sich beträchtliche Komplexität und Anfälligkeiten hinzufügen. Ähnlich wie die Eingangsfilterung hält die Rückverfolgung schließlich Angreifer nicht davon ab, Agenten zu verwenden und kann die ISP-verantwortlichkeiten und -kosten erhöhen, ohne zu ISP-Umsätzen beizutragen.
  • Opfer können ihre Internetkonnektivität häufig dadurch wiederherstellen, daß sie einfach im Fall eines Angriffs ihre Adresse wechseln. Diese Lösung ist natürlich gegenüber Angreifern, die über die aktuelle DNS-Abbildung periodisch die Adresse des Opfers prüfen, nicht robust. Eine allgemeinere Lösung gegenüber Denial-of-Service-Angriffen des Stautyps besteht in dem Kombinieren von Eingangsprotokollierung und Ratenbegrenzung (siehe z.B. „Characterizing and Tracing Packet Floods Using Cisco Routers", Cisco, erhältlich bei http://www.cisco.com/warp/public/707/22.htm1). Um diese Techniken zu nutzen, muß das Opfer zu Anfang die Signatur des Angriffs bestimmen, d.h. wie die Angriffspakete von rechtmäßigen Paketen verschieden sind. ISP-Personal installiert dann ein Filter, das mit der Signatur des Angriffs übereinstimmt, in dem Ausgangsport des dem Opfer nächstgelegenen Routers. Das Filter erzeugt eine Protokollierung, die enthüllt, von welchem Eingangsport der Angriff kommt. Eingangsprotokollierung wird dann für den nächsten signalaufwärtsgelegenen Router iteriert, bis der dem Ursprung des Angriffs nächstgelegene Router gefunden ist. Ein Ratenbegrenzungsfilter, das mit der Signatur des Angriffs übereinstimmt, wird dann in dem Eingangsport, von dem der Angriff kommt, installiert gelassen.
  • Eingangsprotokollierung und Ratenbegrenzung haben viele Begrenzungen. Erstens können Angreifer einen obenerwähnten indirekten Angriff durchführen, d.h. den Angriff durch vorgebliches Abzielen auf einen Nachbarn des beabsichtigten Opfers vernebeln. Somit hat das Opfer möglicherweise nicht die Gelegenheit, Angriffspakete zu untersuchen. Auch wenn Angriffspakete das Opfer erreichen, kann zweitens die Signatur schwierig zu charakterisieren sein. Zum Beispiel kann ein Angreifer Agenten so koordinieren, daß sie endlose Ströme anscheinend rechtmäßiger aber fruchtloser Anforderungen zu dem Opfer senden, um so Anforderungen von rechtmäßigen Clients in der Menge verschwinden zu lassen. Im Gegensatz zu Smurf- und TCP-SYN-Überflutungsangriffen verursachen solche Mengenangriffe keine leicht identifizierbaren Anomalien in der Netzwerk- oder Transportschicht und können deshalb in Routern schwierig zu filtern sein. Drittens kann Filterung, Protokollierung und Ratenbegrenzung nicht verfügbar sein oder viele Router zu sehr verlangsamen, insbesondere im Netzwerkkernpunkt. Viertens kann die Ratenbegrenzung möglicherweise nicht in der Lage sein, zwischen böswilligen und rechtmäßigen Paketen (z.B. TCP-SYN-Paketen), die in demselben Eingangsport ankommen, zu unterscheiden. Somit kann die Ratenbegrenzung unwirksam sein, wenn der Angriff gleichmäßig über Eingangsports verteilt ist. Schließlich sind Eingangsprotokollierung und Ratenbegrenzung häufig arbeitsaufwendige und umständliche Prozeduren, die unter Druck und gewöhnlich ohne angemessene Entlohnung für den ISP durchgeführt werden.
  • Obwohl das Patent EP-B-1284558 mit dem Titel: „Method and Apparatus For Protecting Electronic Commerce Sites From Distributed Denial-of-Service Attacks" viele dieser Probleme für E-Commerce-Anwendungen löst, wird eine Methodologie benötigt, die die Auswirkungen einer großen Klasse von Denial-of-Service-Angriffen auf Sites mit unterschiedlichem Unternehmensmodell wie zum Beispiel Sites auf der Basis von Werbung, Teilnahme oder Profitlosigkeit, automatisch begrenzt.
  • Aus US-A-6 167 445 ist bekannt, daß bestimmte Einrichtungen der Schicht 3 Zugangssteuerlisten oder Filter verwenden, um auf der Basis bestimmter vordefinierter Kriterien zu steuern, ob geroutete Pakete durch die Einrichtung weitergeleitet oder abgeworfen werden sollen. Zu diesen Kriterien gehören die Quellenadresse, die Zieladresse oder Anwendung auf der oberen Schicht auf der Basis ihrer TCP/UDP-Portnummern.
  • Smith R. N. et al: "Operating Firewalls Outside the LAN Perimeter", 1999 IEEE International Performance, Computing and Communications Conference, Phoenix, AZ, 10.-12.2.1999, IEEE International Performance, Computing and Communications Conference, New York, NY: IEEE, US, 10.2.1999 (1999-02-10), Seiten 493–498, XP000859730 ISBN: 0-7803-5259-9, beschreiben das Einfügen einer Firewall in das Internet außerhalb der Grenzen eines Firmennetzwerks zum zweck des Wirkens als ein Agent für die Firma, um Angreifer offensiv an ihrem Quellen-Gateway zu stoppen. Die Gateway-Firewall überwacht auf Denial-of-Service-Angriffe einer ihrer Kundenfirmen und filtert diese Angriffe.
  • Kurze Darstellung der Erfindung
  • Ein Verfahren und eine Vorrichtung gemäß der Erfindung werden in den unabhängigen Ansprüchen definiert.
  • Bevorzugte Formen werden in den abhängigen Ansprüchen definiert.
  • Kurze Darstellung der Erfindung
  • Gemäß der erfindungsgemäßen Methodologie der Serverprofildurchsetzung (SPE – Server Profile Enforcement) gibt eine Internet-verbundene Site, die Schutz vor Denial-of-Service-Angriffen wünscht, einem ISP ein Profil des rechtmäßigen Client-Verkehrs der Site. Das Profil kann zum Beispiel angeben, welche Protokolle zulässig sind, und für jedes solches Protokoll, welche Zielportnummern oder Nachrichtentypen zulässig sind, die maximale Übertragungsrate, die maximale Anzahl von Verbindungen und ob eine Entsprechung mit Stauvermeidungsregeln durchgesetzt werden soll. Zusätzlich kann ein Profil vorgeben, daß Pakete, die dem Profil nicht entsprechen, abgeworfen, für vorzugsweises Abwerfen markiert oder in einer spezifischen Dienstklasse geführt werden. Der ISP filtert auf seinen Zugangsstrecken ankommende Pakete, die für die Site bestimmt sind, gemäß dem Profil der Site. Eine solche Site wird als ein SPE-Teilnehmer bezeichnet und für diesen Dienst kann der ISP von ihm Gebühren oder andere Entlohnung erhalten.
  • Um den SPE-Dienst bereitzustellen, verwendet ein ISP Einrichtungen, die als SPE-Einheiten bezeichnet werden und in der Regel in den Zugangs-Gateways des ISPs implementiert werden. Als Alternative können SPE-Einheiten in IP-Dienst-Switches oder als selbständige Einrichtungen implementiert werden. Ein ISP installiert in seinen SPE-Einheiten die Profile der SPE-Teilnehmer. Die SPE-Einheiten führen eine zuvor beschriebene Eingangsfilterung durch, um zu bestimmen, ob die Quellenadresse eines auf einer Zugangsstrecke ankommenden Pakets ordnungsgemäß mit dem Port assoziiert ist, auf dem das Paket angekommen ist. Gefälschte Pakete werden somit sofort vor dem Eintritt in das Internet gefiltert. Zusätzlich filtern die SPE-Einheiten Pakete, die für einen SPE-Teilnehmer bestimmt sind oder zu einer Verbindung zu ihm gehören. Denial-of-Service-Angriffe und anderer Verkehr, die bzw. der nicht dem Profil der SPE-Teilnehmer entsprechen bzw. entspricht, wird also abgeworfen, für vorzugsweises Abwerfen markiert oder in eine spezifische Dienstklasse aufgeteilt, bevor er in das Internet eintritt.
  • Der SPE-Dienst kann unter Verwendung von einer oder mehreren Best-Effort-Dienstklassen eingesetzt werden. Beim derzeitigen Internet könnte man solche mehreren Dienstklassen zum Beispiel unter Verwendung des sogenannten Diffserv implementieren (siehe z.B. S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang und W. Weiss, „An Architecture for Differentiated Services", IETF, RFC 2475, Dezember 1998). Bei einer solchen Ausführungsform wird Verkehr in einer von vier Dienstklassen geführt. Es werden drei solche Klassen verwendet, um Verkehr von ISPs zu führen, der eingangsgefiltert wird und entweder a) TCP-freundlicher Verkehr; Verkehr, dessen Quelle und Ziel ein teilnehmender Standort ist und der dem Profil und den TCP-Stauvermeidungsregeln, die durch SPE-Einheiten verifiziert werden, gehorcht; oder b) profilgefilterter Verkehr; Verkehr, dessen Ziel eine teilnehmende Site ist und der dem Profil der Site gehorcht, aber nicht TCP-Stauvermeidungsregeln, wie durch SPE-Einheiten verifiziert; oder c) quellengefilterter Verkehr ist; Verkehr, dessen Quelle oder Ziel keine teilnehmende Site ist, der aber eingangsgefiltert wird. Eine als fälschbar bezeichnete vierte Dienstklasse dient zum Führen von Verkehr, der von ISPs ankommt, die keine Eingangsfilterung unterstützen. Bei alternativen Ausführungsformen kann die profilgefilterte Dienstklasse in die quellengefilterte Dienstklasse zusammengeführt werden, die quellengefilterte Dienstklasse kann in die fälschbare Dienstklasse zusammengeführt werden, oder die profilgefilterte, quellengefil terte und fälschbare Dienstklasse können zu einer einzigen Dienstklasse zusammengeführt werden oder alle Dienstklassen können zu einer einzigen Dienstklasse zusammengeführt werden. Ausführungsformen mit einer größeren Anzahl von Dienstklassen sind gegenüber einer größeren Vielfalt von Angriffen effektiv. Ausführungsformen mit zwei oder mehr Dienstklassen sind sogar dann effektiv, wenn sie nur von gewählten ISPs eingesetzt werden. Die Ausführungsform mit einer einzigen Dienstklasse ist bei universellem Einsatz am effektivsten.
  • Kurze Beschreibung der Zeichnung
  • 1 ist ein Blockschaltbild eines Systems, das eine einzige Dienstklasse zum Führen von Verkehr verwendet und in dem SPE-Einheiten in ISP-Zugangs-Gateways enthalten sind;
  • 2 ist ein Flußdiagramm der von einer SPE-Einheit in dem System von 1 durchgeführten Schritte;
  • 3 ist ein Blockschaltbild eines Systems mit einer zweiten Ausführungsform der Erfindung, das mehrere Dienstklassen zum Führen von Verkehr benutzt;
  • 4 ist ein Flußdiagramm der von einer SPE-Einheit in dem System von 3 ausgeführten Schritte; und
  • 5 ist ein Flußdiagramm von von einem Grenzrouter an einem Peering-Punkt, an dem zwei ISPs Pakete austauschen, ausgeführten Schritten.
  • Ausführliche Beschreibung
  • Mit Bezug auf 1 integriert der ISP 101, der den SPE-Dienst unterstützt, eine SPE-Einheit 102 in sein Zugangs-Gateway 103. Obwohl in 1 nur ein einziges Zugangs-Gateway 103 gezeigt ist, versteht sich, daß ein ISP mindestens ein solches, mit jedem seiner wahrscheinlichen mehreren Zugangspunkte (PoPs) assoziiertes Zugangs-Gateway besitzt. Es sind mehrere Clients 104-1104-N über Zugangsstrecken mit dem Zugangs-Gateway 102 verbunden gezeigt. Die Zugangsstrecken, die die Clients und die Zugangs-Gateways verbinden, können über ein beliebiges Telekommunikationsnetz verlaufen, wie zum Beispiel ein POTS-Netz oder eine DSL-Verbindung, ein Kabelnetzwerk unter Verwendung eines Kabelmodems oder jedes beliebige andere Netzwerk oder jede beliebige andere Methodologie, verdrahtet oder drahtlos, das bzw. die Internet-Konnektivität für die Clients bereitstellt.
  • Verkehr zwischen einem Client 104 und einem Server 107 wird zwischen dem ISP 101 und dem Internet 105 und zwischen dem Internet 105 und dem ISP 106, mit dem der Server 107 verbunden ist, geführt. Der Server 107, eine teilnehmende Site des SPE-Dienstes, ist über eine Zugangsstrecke durch ein Zugangs-Gateway 108, das eine später zu beschreibende SPE-Antwortvorrichtung 109 enthält, mit dem ISP 106 verbunden. Andere nicht teilnehmende Sites, wie zum Beispiel der Server 110, können mit demselben Zugangs-Gateway 108 verbunden sein, oder mit anderen PoPs des ISP 106, die in 1 nicht gezeigt sind. Andere ISPs, die keinen SPE-Dienst unterstützen, wie zum Beispiel der ISP 111, sind mit dem Internet 105 verbunden. Ein Client-Kunde, der mit dem ISP 111 verbunden ist, wie zum Beispiel der Client 112, kann durch das Zugangs-Gateway 113 entweder auf den Server 107 oder den Server 110 oder auf einen beliebigen anderen mit dem Internet verbundenen Server zugreifen.
  • Um den Filterungsdienst für eine Server-Site bereitzustellen, erhält der ISP von der teilnehmenden Server-Site eine Entlohnung bestimmter Art (geldlich oder anderweitig).
  • Der Server 107, der den SPE-Dienst mit dem ISP 101 einleiten möchte, gibt diesem ISP ein Profil, das den rechtmäßigen Client-Verkehr des Servers charakterisiert. Dieses Profil wird von dem ISP 101 in der SPE-Einheit 102 in dem Zugangs-Gateway 103 gespeichert. Jeder Zugangsrouter in dem ISP 101 enthält eine ähnliche SPE-Einheit. Die SPE-Einheit 102 überwacht von Clients 104 ankommende Pakete und wirft die Pakete ab, die nicht dem Profil des Zieles des Pakets entsprechen, wenn ein solches Profil existiert. Das Profil gibt Informationen an wie zum Beispiel, welche Protokolle vom Server zugelassen werden, und für jedes solches Protokoll, welche Zielportnummern oder Nachrichtentypen zulässig sind, eine maximale Übertragungsrate und für verbindungsorientierte Protokolle, wie zum Beispiel TCP/IP, die maximale Anzahl zulässiger Verbindungen zwischen einer Paketquelle und einem Paketziel, und ob Stauvermeidung durchgesetzt werden soll. Für letzteres gibt das Serverprofil außerdem eine ISP-Kennung und einen Geheimschlüssel an, die wie nachfolgend beschrieben verwendet werden. Das Profil kann angeben, daß nicht entsprechende Pakete abgeworfen werden, oder, wenn das Netzwerk ein solches Prinzip unterstützt, im Fall von Stau für ein bevorzugtes Abwerfen markiert werden.
  • Die SPE-Einheit 102 enthält außerdem die Funktionen der Eingangsfilterung. Wie zuvor beschrieben, bestimmt die Eingangsfilterung, ob die Quellenadresse eines Pakets von einem Client ordnungsgemäß mit dem Port assoziiert ist, auf dem das Paket angekommen ist. Bei nicht ordnungsgemäßer Assoziation wird das Paket abgeworfen.
  • Der ISP 101 kann außerdem mit der SPE-Einheit 102 ungeachtet des Ziels den Verkehr einschränken, den er von seinen Clients 104 annimmt. Solche Einschränkungen werden in einem Vorgabeprofil spezifiziert und versuchen, die Strecken und Router des ISPs vor böswilligen Staus zu schützen. Ein ISP kann in einer SPE-Einheit höchstens ein Vorgabeprofil installieren.
  • Das Flußdiagramm von 2 zeigt die Operationen, die von einer SPE-Einheit ausgeführt werden, wenn ein Paket von einer Zugangsstrecke ankommt. Im Schritt 201 kommt ein Paket von einer Zugangsstrecke an. Im Schritt 202 wird bestimmt, ob die Quellenadresse des Pakets ordnungsgemäß mit dem Port assoziiert ist, auf dem es angekommen ist. Wenn sie nicht ordnungsgemäß assoziiert ist, wird im Schritt 203 das Paket dann abgeworfen. Wenn sie ordnungsgemäß assoziiert ist, wird im Schritt 204 bestimmt, ob das Ziel des Pakets eine teilnehmende Site ist. Wenn es nicht eine teilnehmende Site ist, wird das Paket im Schritt 205 weitergeleitet. Wenn das Ziel eine teilnehmende Site ist, wird im Schritt 206 bestimmt, ob das Paket dem Profil der Ziel-Site entspricht. Wenn nicht, wird im Schritt 207 das Paket abgeworfen (oder abhängig von dem Profil und den Fähigkeiten des Netzwerks für ein bevorzugtes Abwerfen markiert). Bei Entsprechung wird das Paket in einem Schritt 208 dann weitergeleitet. Obwohl wie oben beschrieben der Schritt der Eingangsfilterung des Schritts 202 als vor den Schritten ausgeführt gezeigt ist, die mit der Bestimmung assoziiert sind, ob ein Paket dem Profil seiner Ziel-Site entspricht, ist für Fachleute erkennbar, daß die Reihenfolge, in der diese Subprozesse ausgeführt werden, unerheblich ist und umgekehrt werden kann.
  • Die Durchsetzung der TCP-Stauvermeidung verhindert, daß ein böswilliger Client das Netzwerk oder einen Server mit TCP-Paketen überflutet. Im Gegensatz zu der Begrenzung der Übertragungsrate auf einen vorbestimmten Wert ermöglicht die Durchsetzung der Stauvermeidung ein dynamisches und skalierbares Drosseln der Pakete jedes Client.
  • Eine Schwierigkeit bei der Durchsetzung der Stauvermeidung besteht darin, daß, obwohl Eingangsfilterung nicht universell verwendet wird, Angreifer Bestätigungen fälschen können. In einem möglichen Szenario sendet ein erster Angriffsagent zu einem zweiten Angriffsagenten Bestätigungen mit einer mit der IP-Adresse des Opfers gefälschten Quellen-IP-Adresse. Wenn sie solchen Bestätigungen gehorcht, könnte eine SPE-Einheit es dem zweiten Angriffsagenten erlauben, das Opfer mit Nicht-SYN-TCP-Segmenten zu überfluten.
  • Um gefälschte Bestätigungen zu vermeiden, verwenden bei dieser ersten Ausführungsform der Erfindung SPE-Einheiten ein Authentifikationsprotokoll mit Abfrage und Antwort. Wenn die SPE-Einheit 102 das anfängliche (SYN-)TCP-Segment von einem Client 104 zu einem Server 107 weiterleitet, der eine Durchsetzung der Stauvermeidung wünscht, dann fügt die SPE-Einheit als TCP-Optionen in das Segment die ISP-Kennung des ISP 101 (die in dem Profil des Servers gefunden wird) und eine Abfrage ein. Die Abfrage ist eine sich nicht wiederholende kryptographisch sichere Zufallszahl vorzugsweise derselben Länge wie der ISP-Geheimschlüssel in dem Profil des Servers. Nach dem Empfang eines solchen Segments verifiziert der Server 107, daß der Server tatsächlich die Durchsetzung von Stauvermeidung durch den ISP angefordert hat und daß die Quellen-IP-Adresse des Segments tatsächlich in diesem ISP 101 vorliegt. Der Server erzeugt dann eine unter Verwendung einer Einbahn-Hash-Funktion berechnete Antwort mit der Abfrage und dem ISP-Geheimschlüssel als Argumente. Danach fügt der Server die Antwort als eine TCP-Option in alle zu dem Client 104 zurückgesendete Segmente ein. Die SPE-Einheit 102 prüft und löscht diese TCP-Option, bevor sie ein Segment zu dem Client 104 weiterleitet. Wenn das TCP-Segment nicht die korrekte Antwort enthält, wirft die SPE-Einheit 102 das Segment ab; andernfalls verzeichnet die SPE-Einheit 102 die Rückmeldung des TCP-Kopfteils, löscht die Antwort-TCP-Option und leitet das Segment zu dem Client 104 weiter.
  • Dieses Protokoll von Abfrage und Antwort nimmt an, daß SPE-Einheiten eines ISPs und Strecken und Router zwischen den SPE-Einheiten und einem teilnehmenden Server und dem Server selbst nicht kompromittiert sind. Unter solchen Umständen können Angreifer die von einer SPE-Einheit gesendete Abfrage oder die von dem Server gesendete Antwort nicht beobachten. Ein Angreifer kann eine Abfrage fälschen, aber der Server verifiziert, daß ihre Quellenadresse in einem ISP liegt, der Eingangsfilterung und Durchsetzung von Stauvermeidung unterstützt. Deshalb wird der Angreifer nicht in der Lage sein, die Antwort auf eine gefälschte Abfrage zu beobachten.
  • Die Antwortlänge sollte vorzugsweise groß genug sein, um Angreifer von dem Versuch abzubringen, Rückmeldungsdurchsetzung zu umgehen, indem sie gefälschte Rückmeldungspakete mit geratenen Antworten zu dem Client senden. Eine Antwortlänge von sechs Byte ist probabilistisch ausreichend und fügt jedem von dem Server gesendeten Segment nur acht Byte hinzu (wobei zwei Byte für den Optionstyp und die Länge notwendig sind). Für eine gegebene Antwortlänge kann die Sicherheit vergrößert werden, indem man die SPE-Einheit häufiger eine neue Abfrage erzeugen und eine neue Antwort erwarten läßt. Die Sicherheit läßt sich weiter vergrößern, indem der von dem ISP und dem Server verwendete Geheimschlüssel periodisch gewechselt wird.
  • Das von einem teilnehmenden Server einem ISP gegebene Profil definiert akzeptable Paketverkehrseigenschaften. Zum Beispiel könnte das Profil eines Servers folgendes bewirken: a) nur Pakete zulassen, die TCP-Protokoll und Zielport 80 benutzen; b) Begrenzen der Anzahl von TCP-Verbindungen; und c) Aktivieren der Durchsetzung von Stauvermeidung. Ein solches Profil würde bewirken, daß die SPE-Einheit Überflutungspakete des Typs ICMP, UDP und TCP-SYN abwirft und dadurch den Server vor den zur Zeit am beliebtesten Denial-of-Service-Angriffen schützt. Dieses Profil würde außerdem bereits den Server vor vielen Denial-of-Service-Angriffen schützen, die in der Zukunft beliebt werden können, wie zum Beispiel Angriffe, die Nicht-SYN-TCP-Pakete verwenden.
  • SPE setzt voraus, daß zur Kommunikation zwischen einem Server und einem ISP und zwischen einem ISP und seinen SPE-Einheiten gegenseitig authentifizierte und verschlüsselte Kanäle verwendet werden. Solche Kanäle kann man zum Beispiel mit dem Protokoll der Transportschichtsicherheit (TLS) implementieren.
  • Wie bereits beschrieben, wird die SPE-Einheit 102 in dem Zugangs-Gateway 103 des ISP 101 implementiert, wodurch ankommende Pakete leicht mit dem jeweiligen ISP-Client assoziiert werden können. Folglich ist dies ein bevorzugter Standort für die Implementierung der SPE-Einheit, die Übertragungsraten und Verbindungszahlen pro ISP-Client 104 messen und durchsetzen muß.
  • Asymmetrisch Zugangsarchitekturen, wie zum Beispiel die, die Pakete zu und von einem Client über verschiedene Wege routen, erfordern besondere Berücksichtigung für die SPE-Einheit-Installation. Zum Beispiel stellen bestimmte ISPs jedem Kunden eine schnelle unidirektionale Satelliten- oder Kabelabwärtsstrecke und eine langsamere Telefonaufwärtsstrecke zur Verfügung. In solchen Fällen kann abhängig davon, wo eine SPE-Einheit installiert ist, sie nicht in der Lage sein, die Bestätigungen des Servers zu beobachten. In asymmetrischen Zugangsarchitekturen muß deshalb eine SPE-Einheit entweder an einer empfangsfähigen Zuführung installiert werden, wie zum Beispiel in einem sowohl mit Kundenabwärtsstrecken als auch -aufwärtsstrecken verbundenen Router, oder signalabwärts solcher Zuführungen, d.h. weiter vom Kunden entfernt.
  • Wenn eine SPE-Einheit nicht in einem Zugangs-Gateway implementiert ist, sollte letzteres vorzugsweise Eingangsfilterung enthalten, um so IP-Adressenfälschung zu begrenzen und genaue Abwärtsstreckenmessungen pro ISP-Client zu ermöglichen.
  • Wie oben beschrieben, erfordert die Durchsetzung der Stauvermeidung das Ändern des Betriebssystems des Servers zur Implementierung des serverseitigen Protokolls von Abfrage und Antwort. Eine Änderung des Betriebssystems kann in bestimmten Fällen unerwünscht oder unmöglich sein. Eine praktischere Alternative kann darin bestehen, das Protokoll signalaufwärts des Servers zu implementieren, wie zum Beispiel in einem Router am Kundenstandort oder in einem ISP-Diensteswitch oder Zugangs-Gateway. Als ein Beispiel für diese letztere Alternative wird die SPE-Antwortvorrichtung 109 in dem Zugangs-Gateway 108 implementiert, mit dem der Server 107 die serverseitigen Protokollfunktionen der Abfrage und Antwort ausführt. Für diesen Fall verwendet der Server 107 eine kleinere Maximalübertragungseinheit (MTU), so daß Platz für die Einfügung der Antwortoption in die übertragenen Pakete bleibt.
  • SPE-Dienst bietet in bezug auf Eingangsfilterung und Ratenbegrenzung mehrere Vorteile, d.h. die Techniken, die wie zuvor beschrieben zur Zeit typischerweise in Fällen von Denial-of-Service-Angriffen verwendet werden. Erstens kann man SPE präventiv verwenden, wodurch Server-Ausfallzeit beseitigt wird, im Gegensatz zur Eingangsprotokollierung, die reaktiv ist und nur dann verwendet wird, wenn Verluste bereits auftreten. Zweitens ist es für SPE nicht notwendig, daß die Signatur eines Angriffs bekannt ist. Ein Server muß nur eine Charakterisierung seines rechtmäßigen Verkehrs in einem Profil bereitstellen. Drittens kann SPE sogar dann funktionieren, wenn Angriffspakete nur schwer von rechtmäßigen Paketen zu unterscheiden sind. Zum Beispiel kann SPE verhindern, daß Angreifer einen Webserver mit TCP-Paketen überfluten, die die Stauvermeidungsregeln ignorieren. Viertens verwendet SPE an der Netzwerkgrenze installierte SPE-Einheiten und modifiziert den Netzwerkkern nicht. Fazit: (1) SPE verlangsamt die Kern-Router nicht; (2) liefert eine feine Filterung auf dem Niveau jedes ISP-Kunden; und (3) ermöglicht es insbesondere Client-Paketen bestimmter Arten, den Zugang verweigert zu bekommen (z.B. ICMP), ohne daß die Fähigkeit des Servers beeinträchtigt wird, ähnliche Pakete zur Kommunikation mit Knoten innerhalb des ISP zu verwenden, wobei zum Beispiel verschiedene Diagnosewerkzeuge verwendet werden. Schließlich ist SPE ein automatisierter Dienst, für den der ISP entlohnt wird.
  • Die zuvor beschriebene Ausführungsform ist am effektivsten, wenn sie universell eingesetzt wird. Nachteiligerweise vereitelt die beschriebene Ausführungsform jedoch keine Denial-of-Service-Angriffe, die durch ISPs gestartet werden, die den SPE-Dienst nicht unterstützen. Ein Angriff gegen den Server 107, der von einem Client 112 gestartet wird, der durch den ISP 111, der den SPE-Dienst nicht unterstützt, mit dem Internet 105 verbunden ist, wird also z.B. durch das Zugangs-Gateway 113 nicht gefiltert und kann erfolgreich sein. Außerdem können indirekte Attacken Denial-of-Service gegen den Server 107 erzielen. Ein indirekter Angriff gegen den Server kann erfolgreich sein, indem ein Nachbar des Servers 107 auf's Korn genommen wird, so daß Routen zwischen Angriffsagenten und einem solchen Nachbarn des Servers 107 gemeinsam Strecken mit Routen zwischen rechtmäßigen Clients des Servers 107 und dem Server 107 teilen. Ein indirekter Angriff gegen den Nachbarserver 110 auf den Server 107, der zum Beispiel durch einen Agenten durch den ISP 111, der keinen SPE-Dienst unterstützt, gestartet wird, kann Denial-of-Service für den Server 107 verursachen. Wenn der Nachbarserver 110 nicht an dem SPE-Dienst durch den ISP 101 teilnimmt, der SPE-Dienst unterstützt, kann außerdem ein mit dem ISP 101 verbundener Agent in der Lage sein, einen erfolgreichen indirekten Angriff zu starten, der Denial-of-Service für den Server 107 verursacht, und derselbe Client hätte dies nicht direkt gegen den Server 107 bewirken können.
  • Eine alternative Ausführungsform, die bei der Verhinderung frontaler Angriffe gegen einen Server von Agenten, die über Dienstanbieter, die keinen SPE-Dienst unterstützen, auf das Internet zugreifen, und gegen indirekte Angriffe erfolgreicher ist, nimmt Internet-Unterstützung für mehrere Dienstklassen an. Beim derzeitigen Internet könnten diese mehreren Dienstklassen zum Beispiel unter Verwendung des obenerwähnten und zitierten Diffserv implementiert werden. Andere Implementierungen könnten integrierte Dienste (Intserv) verwenden (siehe z.B. R. Braden, D. Clark, S. Shenker, „Integrated Services in the Internet Architecture: an Overview", IETF, RFC, 1633, Juni 1994), oder jedes beliebige andere Dienstqualitätsschema. Die meisten zur Zeit erhältlichen Router unterstützen mindestens ein solches Schema. Die Dienstklasse eines Pakets kann zum Beispiel in dem TOS-Feld (Diensttyp) des IP-Kopfteils des Pakets markiert werden.
  • Die Architektur dieser Ausführungsform ist in 3 gezeigt. In 3 unterstützt der ISP 301 SPE-Dienst. In dem Zugangs-Gateway 303 ist eine SPE-Einheit 302 enthalten. Die Clients 304-1304-N werden über Zugangsstrecken mit den Eingangsports des Zugangs-Gateway 303 verbunden. Wie beschrieben werden wird, wird Best-Effort-Verkehr in und zwischen ISPs, die SPE unterstützen, in vier verschiedene Dienstklassen aufgeteilt. Um zu zeigen, daß Pakete in vier verschiedenen Dienstklassen geführt werden können, sind der ISP 301 und die Internet-Vermittlung 305 in einem Zwischen-ISP 306 durch vier Verbindungen 307, 308, 309 und 310 für separate Übertragung von Paketen in jeder der vier Dienstklassen verbunden gezeigt.
  • In der Internet-Vermittlung 305 tauschen zwei oder mehr ISP Pakete aus. Es sind zwei weitere ISP mit der Internet-Vermittlung 305 verbunden gezeigt: Der ISP 311 und der ISP 312. Der ISP 311 unterstützt keinen SPE-Dienst und ist als ein beispielhaftes Zugangs-Gateway 313 enthaltend gezeigt, mit dem ein oder mehrere Clients 315 über Zugangsstrecken verbunden sind. Da ISP 311 keinen SPE-Dienst unterstützt, verwendet er eine Best-Effort-Klasse für den Transport von Paketen zu und von der Internet-Vermittlung 305. Zur Veranschaulichung ist somit nur eine einzige Verbindung 316 gezeigt, die den ISP 310 und die Internet-Vermittlung 305 verbindet. Der ISP 312 unterstützt SPE-Dienst und enthält das Zugangs-Gateway 317, mit dem der Server 318, ein Teilnehmer des SPE-Dienstes, über eine Zugangsstrecke verbunden ist. Es sind separate Verbindungen 319, 320, 321 und 322 für die vier Dienstklassen gezeigt, die die Internet-Vermittlung 305 und den ISP 312 verbinden. Der Server 323, der nicht an dem SPE-Dienst in dem ISP 301 teilnimmt, ist auch mit dem Zugangs-Gateway 317 verbunden gezeigt.
  • Wie bereits beschrieben, stellt die SPE-Einheit 302 Eingangsfilterung aller Pakete von jedem beliebigen Client 304, die für jede beliebige Site bestimmt sind, ob es sich um eine teilnehmende Site handelt oder nicht, bereit. Für für eine teilnehmende Site, wie zum Beispiel den Server 318, bestimmte Pakete stellt die SPE-Einheit 302 außerdem Filterung von Paketen gemäß dem gespeicherten Profil dieses Servers bereit. Pakete, die von einem der Clients 304 stammen, werden in einer der drei verschiedenen Dienstklassen geführt. Eine erste Dienstklasse dient zum Führen von TCP-freundlichem Verkehr; Verkehr, dessen Quelle oder Ziel eine an SPE teilnehmende Site ist und der dem Profil der Site und TCP-Stauvermeidungsregeln, die durch die SPE-Einheiten 302 und 324 verifiziert werden, gehorcht, wobei letztere die SPE-Einheit ist, die mit dem Zugangs-Gateway 317 assoziiert ist, mit dem der Server 318 verbunden ist. (Pakete, die irgendein anderes verbindungsorientiertes Protokoll verwenden, das denen von TCP ähnliche Stauvermeidungsregeln enthält, würden auch in dieser Dienstklasse geführt). Die zweite Dienstklasse dient zum Führen von profilgefiltertem Verkehr; Verkehr, dessen Ziel eine an SPE teilnehmende Site ist und der dem Profil der Site gehorcht, wie durch SPE-Einheiten verifiziert wird, aber möglicherweise nicht Stauvermeidungsregeln des TCP gehorcht (wenn zum Beispiel das verwendete Protokoll UDP oder ICMP ist). Die dritte Dienstklasse dient zum Führen von quellengefiltertem Verkehr; Verkehr, der eingangsgefiltert wurde, aber sich weder für die TCP-freundliche, noch für die profilgefilterte Dienstklasse qualifiziert (zum Beispiel wenn Quelle und Ziel keine SPE-Teilnehmer sind). Die vierte Dienstklasse dient zum Führen von Best-Effort-Verkehr, der nicht eingangsgefiltert wird (der zum Beispiel von Clients ankommt, die über Dienstanbieter auf das Internet zugreifen, die keine Eingangsfilterung unterstützen). Diese Klasse ist als fälschbar gekennzeichnet, da man einer Quellenadresse eines Pakets nicht vertrauen kann.
  • Wenn ein Paket von dem ISP 301, der SPE unterstützt, an der Internet-Vermittlung 305 ankommt, wird es in der Klasse weitergeleitet, in der es bereits markiert ist. Ein Paket, das für den teilnehmenden Server 318 bestimmt ist und in der TCP-freundlichen Dienstklasse von dem ISP 301 von dem Client 304-1, der das TCP-Protokoll verwendet, ankommt, wird also beispielsweise durch die Internet-Vermittlung 305 in dieser selben TCP-freundlichen Klasse zu dem ISP 312 weitergeleitet. Ein Paket, das für den teilnehmenden Server 318 bestimmt ist und in der profilgefilterten Dienstklasse von ISP 301 von dem Client 304-2 ankommt, der das ICMP-Protokoll verwendet, wird in dieser selbigen profil gefilterten Klasse durch die Internet-Vermittlung 305 zu dem ISP 312 weitergeleitet. Ein Paket, das für einen nichtteilnehmenden Server 323 bestimmt ist und in der quellengefilterten Dienstklasse von dem ISP 301 von dem Client 304-N, der ein beliebiges Protokoll verwendet, ankommt, wird durch die Internet-Vermittlung 305 in dieser selben quellengefilterten Klasse weitergeleitet. Wenn ein Paket an der Internet-Vermittlung 305 von einem ISP ankommt, der keinen SPE-Dienst unterstützt, wird es in der fälschbaren Dienstklasse weitergeleitet, gleichgültig, in welcher Klasse es ankommt. Ein Paket, das entweder für den teilnehmenden Server 318 oder für den nichtteilnehmenden Server 323 bestimmt ist und von dem ISP 311 ankommt, der keinen SPE-Dienst unterstützt und keine Eingangsfilterung durchführt, wird also in der fälschbaren Dienstklasse zu dem ISP 312 weitergeleitet.
  • Bei dieser Ausführungsform ist keine Abfrage und Antwort notwendig, um Bestätigungen von einer teilnehmenden Site zu authentifizieren, da eine SPE-Einheit eine Bestätigung einfach dadurch authentifizieren kann, daß sie verifiziert, daß sie nicht die fälschbare Dienstklasse verwendet. Die SPE-Einheit 302 kann also Bestätigungen von dem Server 318 verifizieren, indem sie verifiziert, daß sie nicht in dieser vierten Dienstklasse markiert sind und empfangen werden.
  • Die vier Dienstklassen werden in der folgenden absteigenden Rangfolge eingestuft: TCP-freundlich, profilgefiltert, quellengefiltert und fälschbar, wobei die Belastung einer niedriger eingestuften Dienstklasse sich höchstens begrenzt auf die Leistungsfähigkeit für in einer höher eingestuften Dienstklasse geführten Verkehr auswirken kann. Diese verschiedenen Dienstklassen können auf gemeinsam benutzten physischen Betriebsmitteln unter Verwendung von Standard-Einteilungsmechanismen, wie zum Beispiel faire Warteschlangen auf Prioritätsbasis oder mit Warten, implementiert werden. Eine höher eingestufte Dienstklasse kann eine höhere Priorität für die Verwendung eines Netzwerkbetriebsmittels als eine niedriger eingestufte Dienstklasse besitzen oder alternativ dazu kann jede Dienstklasse einen proportionalen Anteil von Netzwerkbetriebsmitteln besitzen.
  • Die Durchsetzung von Stauvermeidungsregeln befreit automatisch die TCP-freundliche Klasse von den am meisten stauenden Denial-of-Service-Angriffen. Eine andere automatische Filterung gemäß dem Profil einer Site erschwert ein Organisieren von Angriffen in der profilgefilterten Klasse. Die quellengefilterte Klasse erlaubt Angriffe, die keine Fälschung verwenden, beschleunigt aber eine manuelle Reaktion auf solche Angriffe, weil der Angriffsursprung sich durch einfaches Untersuchen der Quellenadresse der Angriffspakete finden läßt. Die fälschbare Klasse hilft nicht bei der Linderung von Angriffen, ermöglicht aber einen inkrementellen Einsatz des SPE-Dienstes, da sich Angriffe in dieser Dienstklasse nur begrenzt auf den Verkehr auswirken, der in den drei höher eingestuften Dienstklassen geführt wird.
  • wenn nur drei Dienstklassen verfügbar sind, kann die profilgefilterte Dienstklasse in die quellengefilterte Dienstklasse zusammengeführt werden, oder die quellengefilterte Dienstklasse kann in die fälschbare Dienstklasse zusammengeführt werden. Wenn nur zwei Dienstklassen verfügbar sind, kann die profilgefilterte Dienstklasse, die quellengefilterte Dienstklasse und die fälschbare Dienstklasse zu einer einzigen Dienstklasse zusammengeführt werden.
  • Das Flußdiagramm von 4 detailliert die von einer SPE-Einheit in dem System von 3 ausgeführten Schritte. Im Schritt 401 kommt ein Paket an. Da die SPE-Einheit Eingangsfilterung durchführt, wird im Schritt 401 bestimmt, ob die Quellenadresse des Pakets ordnungsgemäß mit dem Port assoziiert ist, auf dem das Paket angekommen ist. Wenn sie nicht ordnungsgemäß assoziiert ist, dann wird das Paket im Schritt 403 abgeworfen. Wenn sie ordnungsgemäß assoziiert ist, wird in Schritt 404 bestimmt, ob das Ziel des Pakets eine teilnehmende Site des SPE-Dienstes ist. Wenn es eine teilnehmende Site ist, dann wird im Schritt 405 bestimmt, ob das Paket dem Profil seines Ziels entspricht. Wenn es entspricht, dann wird im Schritt 406 bestimmt, ob das Paket zu einer TCP-Verbindung (oder einem ähnlich verbindungsorientierten Protokoll) gehört, dann die Stauvermeidungsregeln beachtet. Wenn es dazu gehört, dann wird das Paket im Schritt 407 in der TCP-freundlichen Dienstklasse markiert und weitergeleitet. Wenn das Paket nicht zu einer TCP-Verbindung (oder einem ähnlichen verbindungsorientierten Protokoll) gehört, die Stauvermeidungsregeln beachtet, aber dem Profil seines Ziels entspricht, dann wird das Paket im Schritt 408 in der profilfreundlichen Dienstklasse markiert und weitergeleitet. Wenn das Paket im Schritt 405 nicht seinem Zielprofil entspricht, dann wird das Paket im Schritt 409 abhängig von dem Profil entweder abgeworfen oder in der quellengefilterten Dienstklasse markiert und weitergeleitet. Wenn das Ziel des Pakets im Schritt 404 als eine nichtteilnehmende Site bestimmt wird, dann wird im Schritt 410 bestimmt, ob die Quelle des Pakets eine teilnehmende Site ist. Wenn die Quelle des Pakets eine teilnehmende Site ist, dann wird im Schritt 411 bestimmt, ob das Paket zu einer TCP-Verbindung (oder einem ähnlichen verbindungsorientierten Protokoll) gehört, die Stauvermeidungsregeln beachtet. Wenn dies der Fall ist, dann wird im Schritt 407 das Paket in der TCP-freundlichen Dienstklasse markiert und weitergeleitet. Wenn es nicht zu einer TCP-Verbindung (oder einem ähnlichen verbindungsorientierten Protokoll) gehört, die Stauvermeidungsregeln beachtet, dann wird im Schritt 412 das Paket in der quellengefilterten Dienstklasse markiert und weitergeleitet. Wenn im Schritt 410 bestimmt wird, daß weder das Ziel des Pakets noch die Quelle des Pakets eine teilnehmende Site ist, dann wird im Schritt 409 das Paket in der quellengefilterten Dienstklasse markiert und weitergeleitet.
  • Das Flußdiagramm von 5 detailliert die von einem Grenzrouter in einem ISP, der entweder direkt durch einen Peering-Punkt oder durch eine Internet-Vermittlung mit einem anderen ISP verbindet, ausgeführten Schritte. Im Schritt 501 kommt ein Paket an. Im Schritt 502 wird bestimmt, ob das Paket von einem ISP ankam, der SPE-Dienst unterstützt. Wenn es von einem ISP ankam, der SPE-Dienst unterstützt, wird im Schritt 503 die Dienstklassenmarkierung des Pakets in eine äquivalente Markierung für den ISP, worin das Paket transferiert wird, übersetzt. Im Schritt 504 wird das Paket dann gemäß der übersetzten Dienstklassenmarkierung des Pakets weitergeleitet. wenn im Schritt 502 bestimmt wird, daß das Paket von einem ISP ankam, der keinen SPE-Dienst unterstützt, wird im Schritt 505 bestimmt, ob das Paket von einem Nicht-Transit-ISP ankam, der Eingangsfilterung unterstützt. Wenn dies der Fall ist, dann wird das Paket im Schritt 506 für die quellenverifizierte Dienstklasse markiert und im Schritt 504 gemäß dieser Dienstklassenmarkierung weitergeleitet. Wenn im Schritt 505 bestimmt wird, daß das Paket von einem Nicht-Transit-ISP ankam, der keine Eingangsfilterung unterstützt, wird im Schritt 507 das Paket für die fälschbare Dienstklasse markiert und im Schritt 504 gemäß dieser Dienstklassenmarkierung weitergeleitet.
  • Wie bereits erwähnt wird die vorliegende Erfindung wahrscheinlich teilweise als ein oder mehrere Computerprogramme oder Anwendungen implementiert werden, die in der Peripherie des Internet, ganz besonders bevorzugt in einem Zugangs-Gateway, ablaufen. Wie bereits erwähnt, kann sie auch teilweise in einem Computerprogramm oder in einer Anwendung implementiert werden, das bzw. die signalabwärts eines zugangs-Gateways abläuft.
  • Ferner ist für Fachleute erkennbar, daß die vorliegenden Blockschaltbilder konzeptuelle Ansichten repräsentieren, die die Prinzipien der Erfindung realisieren. Ähnlich versteht sich, daß das Flußdiagramm verschiedene Prozesse repräsentiert, die im wesentlichen in einem computerlesbaren Medium repräsentiert und somit durch einen Computer oder Prozessor ausgeführt werden können, gleichgültig, ob ein solcher Computer oder Prozessor explizit gezeigt ist oder nicht.

Claims (7)

  1. Verfahren zum Schutz von Internet-verbundenen Sites vor Denial-of-Service-Angriffen, mit den folgenden Schritten: beim Internet-Dienstanbieter Bestimmen, ob ein auf einer Zugangsstrecke empfangenes Paket weitergeleitet oder abgeworfen werden soll, auf der Basis eines gespeicherten vorbestimmten Kriteriums; dadurch gekennzeichnet, daß das Verfahren ferner die folgenden Schritte umfaßt: Bestimmen, ob das Ziel des Pakets in einer Verbindungsanforderung eine Internet-verbundene Site ist, die an einem Dienst der Serverprofildurchsetzung, SPE, teilnimmt, oder ob das Paket auf einer durch eine Internet-verbundene Site, die an dem SPE-Dienst teilnimmt, angenommenen Verbindung gesendet wird (204, 404, 410); wenn das Ziel des Pakets in einer Verbindungsanforderung eine Site ist, die an dem SPE-Dienst teilnimmt, oder wenn das Paket auf einer durch eine Site, die an dem SPE-Dienst teilnimmt, angenommenen Verbindung gesendet wird, Weiterleiten des Pakets zu seinem Ziel, wenn das Paket einem durch die teilnehmende Site bereitgestellten gespeicherten Profil entspricht, das Verbindungen definiert, die die teilnehmende Site bereit ist, zu akzeptieren (208, 407), und wenn die Site an dem SPE-Dienst teilnimmt und das Paket nicht dem gespeicherten Profil entspricht, Abwerfen des Pakets, Markieren des Pakets für vorzugsweises Abwerfen oder Markieren und Weiterleiten des Pakets in eine von mehreren Dienstklassen (207, 409); und wenn das Ziel des Pakets in einer Verbindungsanforderung eine Site ist, die nicht an dem SPE-Dienst teilnimmt, oder wenn das Paket auf einer durch eine Site, die nicht an dem SPE-Dienst teilnimmt, angenommenen Verbindung gesendet wird, Weiterleiten des Pakets zu seinem Ziel (205, 412).
  2. Verfahren nach Anspruch 1, wobei das gespeicherte Profil mindestens eine der folgenden Paketverkehrseigenschaften definiert, die ein Paket aufweisen muß, um dem Profil zu entsprechen: Verwenden eines zulässigen vorbestimmten Protokolls; Verwenden einer zulässigen vorbestimmten Zielportnummer für ein zulässiges vorbestimmtes Protokoll; Verwenden eines zulässigen vorbestimmten Nachrichtentyps für ein zulässiges vorbestimmtes Protokoll; Aufweisen einer Übertragungsrate unter einer vorbestimmten maximalen Rate; Gehören zu einer Verbindung, die innerhalb der vorbestimmten maximalen Anzahl zulässiger Verbindungen zwischen der Quelle und dem Ziel des Pakets liegt; und Gehören zu einer Verbindung, die Überlastungsvermeidungsregeln beachtet.
  3. Verfahren nach Anspruch 1, ferner mit den folgenden Schritten: Bestimmen, ob die Quellenadresse des Pakets ordnungsgemäß mit einem Port assoziiert ist, auf dem das Paket ankam (202, 402); und Abwerfen des Pakets, wenn von seiner Quellenadresse bestimmt wird, daß sie nicht ordnungsgemäß mit einem Port assoziiert ist, auf dem das Paket ankam (203, 403).
  4. Vorrichtung (102, 302) zum Schutz von internetverbundenen Sites vor Denial-of-Service-Angriffen, umfassend: ein Eingangsfiltermittel zum Bestimmen, ob die empfangene Quellenadresse eines Pakets ordnungsgemäß mit einem Port assoziiert ist, auf dem das Paket ankam; ein Mittel zum Bestimmen, ob das Paket weitergeleitet oder abgeworfen werden soll, auf der Basis eines gespeicherten vorbestimmten Kriteriums; dadurch gekennzeichnet, daß die Vorrichtung ferner folgendes umfaßt: ein Mittel zum Bestimmen, ob das Ziel des Pakets in einer Verbindungsanforderung eine internetverbundene Site ist, die an einem Dienst der Serverprofildurchsetzung, SPE, teilnimmt, oder ob das Paket auf einer durch eine Internet-verbundene Site, die an dem SPE-Dienst teilnimmt, angenommenen Verbindung gesendet wird; ein Mittel zum Weiterleiten des Pakets zu seinem Ziel, wenn das Ziel des Pakets in einer Verbindungsanforderung eine Site ist, die an dem SPE-Dienst teilnimmt, oder wenn das Paket auf einer durch eine Site, die an dem SPE-Dienst teilnimmt, angenommenen Verbindung gesendet wird, und wenn das Paket einem durch die teilnehmende Site bereitgestellten gespeicherten Profil entspricht, das Verbindungen definiert, die die teilnehmende Site bereit ist, zu akzeptieren, und Abwerfen des Pakets, Markieren des Pakets für vorzugsweises Abwerfen oder Markieren und Weiterleiten des Pakets in eine von mehreren Dienstklassen, wenn die Site an dem SPE-Dienst teilnimmt und das Paket nicht dem gespeicherten Profil entspricht; und ein Mittel zum Weiterleiten des Pakets zu seinem Ziel, wenn das Ziel des Pakets in einer Verbindungsanforderung eine Site ist, die nicht an dem SPE-Dienst teilnimmt, oder wenn das Paket auf einer durch eine Site, die nicht an dem SPE-Dienst teilnimmt, angenommenen Verbindung gesendet wird.
  5. Vorrichtung nach Anspruch 4, wobei das gespeicherte Profil mindestens eine der folgenden Paketverkehrseigenschaften definiert, die ein Paket aufweisen muß, um dem Profil zu entsprechen: Verwenden eines zulässigen vorbestimmten Protokolls; Verwenden einer zulässigen vorbestimmten Zielportnummer für ein zulässiges vorbestimmtes Protokoll; Verwenden eines zulässigen vorbestimmten Nachrichtentyps für ein zulässiges vorbestimmtes Protokoll; Aufweisen einer Übertragungsrate unter einer vorbestimmten maximalen Rate; Gehören zu einer Verbindung, die innerhalb der vorbestimmten maximalen Anzahl zulässiger Verbindungen zwischen der Quelle und dem Ziel des Pakets liegt; und Gehören zu einer Verbindung, die Überlastungsvermeidungsregeln beachtet.
  6. Vorrichtung nach Anspruch 4, wobei das Paket abgeworfen wird, wenn das Eingangsfiltermittel bestimmt, daß die Quellenadresse des Pakets nicht ordnungsgemäß mit einem Port assoziiert ist, auf dem das Paket ankam.
  7. Vorrichtung nach Anspruch 4, wobei sich die Vorrichtung in einem Zugangs-Gateway (103, 303) befindet.
DE60206856T 2001-08-16 2002-08-07 Verfahren und Vorrichtung zum Schutz von Internetanlagen gegen Denial-of-Service Angriffen Expired - Lifetime DE60206856T2 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US31303101P 2001-08-16 2001-08-16
US313031P 2001-08-16
US10/175,458 US7207062B2 (en) 2001-08-16 2002-06-19 Method and apparatus for protecting web sites from distributed denial-of-service attacks
US175458 2002-06-19

Publications (2)

Publication Number Publication Date
DE60206856D1 DE60206856D1 (de) 2005-12-01
DE60206856T2 true DE60206856T2 (de) 2006-06-22

Family

ID=26871224

Family Applications (1)

Application Number Title Priority Date Filing Date
DE60206856T Expired - Lifetime DE60206856T2 (de) 2001-08-16 2002-08-07 Verfahren und Vorrichtung zum Schutz von Internetanlagen gegen Denial-of-Service Angriffen

Country Status (3)

Country Link
US (1) US7207062B2 (de)
EP (1) EP1284573B1 (de)
DE (1) DE60206856T2 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021127714A1 (de) 2021-10-25 2023-04-27 marbis GmbH Verfahren und Vorrichtung zum Verhindern von böswilligem Netzverkehr

Families Citing this family (80)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7917647B2 (en) * 2000-06-16 2011-03-29 Mcafee, Inc. Method and apparatus for rate limiting
US7801978B1 (en) 2000-10-18 2010-09-21 Citrix Systems, Inc. Apparatus, method and computer program product for efficiently pooling connections between clients and servers
US7774492B2 (en) * 2001-07-26 2010-08-10 Citrix Systems, Inc. System, method and computer program product to maximize server throughput while avoiding server overload by controlling the rate of establishing server-side net work connections
US7092357B1 (en) * 2001-11-13 2006-08-15 Verizon Services Corp. Anti-flooding flow-control methods and apparatus
US7295516B1 (en) * 2001-11-13 2007-11-13 Verizon Services Corp. Early traffic regulation techniques to protect against network flooding
DE60139883D1 (de) * 2001-11-29 2009-10-22 Stonesoft Oy Kundenspezifische Firewall
US8346951B2 (en) * 2002-03-05 2013-01-01 Blackridge Technology Holdings, Inc. Method for first packet authentication
US20030185368A1 (en) * 2002-03-28 2003-10-02 Intel Corporation Methods and systems to install a network service
AU2003247700A1 (en) * 2002-07-02 2004-01-23 Netscaler, Inc System, method and computer program product to avoid server overload by controlling http denial of service (dos) attacks
US7752324B2 (en) * 2002-07-12 2010-07-06 Penn State Research Foundation Real-time packet traceback and associated packet marking strategies
US7069438B2 (en) * 2002-08-19 2006-06-27 Sowl Associates, Inc. Establishing authenticated network connections
US7542471B2 (en) * 2002-10-30 2009-06-02 Citrix Systems, Inc. Method of determining path maximum transmission unit
US8233392B2 (en) 2003-07-29 2012-07-31 Citrix Systems, Inc. Transaction boundary detection for reduction in timeout penalties
US7630305B2 (en) * 2003-07-29 2009-12-08 Orbital Data Corporation TCP selective acknowledgements for communicating delivered and missed data packets
US7616638B2 (en) 2003-07-29 2009-11-10 Orbital Data Corporation Wavefront detection and disambiguation of acknowledgments
US8270423B2 (en) * 2003-07-29 2012-09-18 Citrix Systems, Inc. Systems and methods of using packet boundaries for reduction in timeout prevention
US7751569B2 (en) * 2002-11-19 2010-07-06 Oracle America, Inc. Group admission control apparatus and methods
US9106479B1 (en) 2003-07-10 2015-08-11 F5 Networks, Inc. System and method for managing network communications
US7656799B2 (en) * 2003-07-29 2010-02-02 Citrix Systems, Inc. Flow control system architecture
US8238241B2 (en) 2003-07-29 2012-08-07 Citrix Systems, Inc. Automatic detection and window virtualization for flow control
US8432800B2 (en) * 2003-07-29 2013-04-30 Citrix Systems, Inc. Systems and methods for stochastic-based quality of service
US8437284B2 (en) 2003-07-29 2013-05-07 Citrix Systems, Inc. Systems and methods for additional retransmissions of dropped packets
US7565426B2 (en) * 2003-08-07 2009-07-21 Alcatel Lucent Mechanism for tracing back anonymous network flows in autonomous systems
US7530112B2 (en) 2003-09-10 2009-05-05 Cisco Technology, Inc. Method and apparatus for providing network security using role-based access control
US7836490B2 (en) 2003-10-29 2010-11-16 Cisco Technology, Inc. Method and apparatus for providing network security using security labeling
US20050177717A1 (en) * 2004-02-11 2005-08-11 Grosse Eric H. Method and apparatus for defending against denial on service attacks which employ IP source spoofing
US8423758B2 (en) * 2004-05-10 2013-04-16 Tara Chand Singhal Method and apparatus for packet source validation architecture system for enhanced internet security
CN100370757C (zh) * 2004-07-09 2008-02-20 国际商业机器公司 识别网络内分布式拒绝服务攻击和防御攻击的方法和系统
US8620915B1 (en) 2007-03-13 2013-12-31 Google Inc. Systems and methods for promoting personalized search results based on personal information
US8078607B2 (en) * 2006-03-30 2011-12-13 Google Inc. Generating website profiles based on queries from webistes and user activities on the search results
US7382779B1 (en) * 2004-08-20 2008-06-03 Trend Micro Incorporated Method and apparatus for configuring a network component
US8234705B1 (en) * 2004-09-27 2012-07-31 Radix Holdings, Llc Contagion isolation and inoculation
US7478429B2 (en) * 2004-10-01 2009-01-13 Prolexic Technologies, Inc. Network overload detection and mitigation system and method
US7669244B2 (en) * 2004-10-21 2010-02-23 Cisco Technology, Inc. Method and system for generating user group permission lists
US7877796B2 (en) * 2004-11-16 2011-01-25 Cisco Technology, Inc. Method and apparatus for best effort propagation of security group information
US7886145B2 (en) * 2004-11-23 2011-02-08 Cisco Technology, Inc. Method and system for including security information with a packet
US7721323B2 (en) * 2004-11-23 2010-05-18 Cisco Technology, Inc. Method and system for including network security information in a frame
US8874570B1 (en) 2004-11-30 2014-10-28 Google Inc. Search boost vector based on co-visitation information
US7827402B2 (en) * 2004-12-01 2010-11-02 Cisco Technology, Inc. Method and apparatus for ingress filtering using security group information
US7434047B2 (en) * 2004-12-30 2008-10-07 Nokia, Inc. System, method and computer program product for detecting a rogue member in a multicast group
FI20050561A0 (fi) * 2005-05-26 2005-05-26 Nokia Corp Pakettidatan käsittely viestintäjärjestelmässä
JP4557815B2 (ja) * 2005-06-13 2010-10-06 富士通株式会社 中継装置および中継システム
US20070011732A1 (en) * 2005-07-05 2007-01-11 Yang-Hung Peng Network device for secure packet dispatching via port isolation
US8225399B1 (en) * 2005-12-14 2012-07-17 At&T Intellectual Property Ii, Lp System and method for avoiding and mitigating a DDoS attack
US7797738B1 (en) * 2005-12-14 2010-09-14 At&T Corp. System and method for avoiding and mitigating a DDoS attack
US8205252B2 (en) 2006-07-28 2012-06-19 Microsoft Corporation Network accountability among autonomous systems
US7907621B2 (en) * 2006-08-03 2011-03-15 Citrix Systems, Inc. Systems and methods for using a client agent to manage ICMP traffic in a virtual private network environment
US7706266B2 (en) 2007-03-12 2010-04-27 Citrix Systems, Inc. Systems and methods of providing proxy-based quality of service
US7760642B2 (en) 2007-03-12 2010-07-20 Citrix Systems, Inc. Systems and methods for providing quality of service precedence in TCP congestion control
US7796510B2 (en) * 2007-03-12 2010-09-14 Citrix Systems, Inc. Systems and methods for providing virtual fair queueing of network traffic
US8209748B1 (en) 2007-03-27 2012-06-26 Amazon Technologies, Inc. Protecting network sites during adverse network conditions
US7840708B2 (en) * 2007-08-13 2010-11-23 Cisco Technology, Inc. Method and system for the assignment of security group information using a proxy
US7844707B2 (en) * 2007-12-20 2010-11-30 Yahoo! Inc. Web service multi-key rate limiting method and system
US8782656B2 (en) * 2011-02-24 2014-07-15 International Business Machines Corporation Analysis of operator graph and dynamic reallocation of a resource to improve performance
US8938804B2 (en) * 2012-07-12 2015-01-20 Telcordia Technologies, Inc. System and method for creating BGP route-based network traffic profiles to detect spoofed traffic
US9565213B2 (en) 2012-10-22 2017-02-07 Centripetal Networks, Inc. Methods and systems for protecting a secured network
US9137205B2 (en) * 2012-10-22 2015-09-15 Centripetal Networks, Inc. Methods and systems for protecting a secured network
US9203806B2 (en) 2013-01-11 2015-12-01 Centripetal Networks, Inc. Rule swapping in a packet network
US9124552B2 (en) 2013-03-12 2015-09-01 Centripetal Networks, Inc. Filtering network data transfers
US9094445B2 (en) 2013-03-15 2015-07-28 Centripetal Networks, Inc. Protecting networks from cyber attacks and overloading
US9942265B2 (en) 2014-01-06 2018-04-10 International Business Machines Corporation Preventing application-level denial-of-service in a multi-tenant system
US9900253B2 (en) * 2014-08-28 2018-02-20 Cavium, Inc. Phantom queue link level load balancing system, method and device
US9264370B1 (en) 2015-02-10 2016-02-16 Centripetal Networks, Inc. Correlating packets in communications networks
US10582508B2 (en) * 2015-03-31 2020-03-03 At&T Intellectual Property I, L.P. Facilitation of network resources
US10834065B1 (en) 2015-03-31 2020-11-10 F5 Networks, Inc. Methods for SSL protected NTLM re-authentication and devices thereof
US9866576B2 (en) 2015-04-17 2018-01-09 Centripetal Networks, Inc. Rule-based network-threat detection
US9917856B2 (en) 2015-12-23 2018-03-13 Centripetal Networks, Inc. Rule-based network-threat detection for encrypted communications
US11729144B2 (en) 2016-01-04 2023-08-15 Centripetal Networks, Llc Efficient packet capture for cyber threat analysis
US10404698B1 (en) 2016-01-15 2019-09-03 F5 Networks, Inc. Methods for adaptive organization of web application access points in webtops and devices thereof
US10171493B2 (en) 2016-03-05 2019-01-01 Sears Brands, L.L.C. Method and system to dynamically obfuscate a web services interface
EP3270569B1 (de) * 2016-07-14 2021-01-13 Deutsche Telekom AG Netzwerkschutzeinheit und verfahren zum schutz eines kommunikationsnetzwerks gegen falsch formatierte datenpakete
US10503899B2 (en) 2017-07-10 2019-12-10 Centripetal Networks, Inc. Cyberanalysis workflow acceleration
US10284526B2 (en) 2017-07-24 2019-05-07 Centripetal Networks, Inc. Efficient SSL/TLS proxy
US11233777B2 (en) 2017-07-24 2022-01-25 Centripetal Networks, Inc. Efficient SSL/TLS proxy
US10567441B2 (en) * 2018-01-14 2020-02-18 Cisco Technology, Inc. Distributed security system
CA3090091A1 (en) * 2018-01-31 2019-08-08 Assia Spe, Llc Systems and methods for net neutrality testing
US10333898B1 (en) 2018-07-09 2019-06-25 Centripetal Networks, Inc. Methods and systems for efficient network protection
US12063245B2 (en) * 2019-05-10 2024-08-13 Akamai Technologies, Inc. Using the state of a request routing mechanism to inform attack detection and mitigation
US11362996B2 (en) 2020-10-27 2022-06-14 Centripetal Networks, Inc. Methods and systems for efficient adaptive logging of cyber threat incidents
US11159546B1 (en) 2021-04-20 2021-10-26 Centripetal Networks, Inc. Methods and systems for efficient threat context-aware packet filtering for network protection

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6119235A (en) 1997-05-27 2000-09-12 Ukiah Software, Inc. Method and apparatus for quality of service management
US6459682B1 (en) * 1998-04-07 2002-10-01 International Business Machines Corporation Architecture for supporting service level agreements in an IP network
US6073175A (en) * 1998-04-27 2000-06-06 International Business Machines Corporation Method for supporting different service levels in a network using web page content information
US6167445A (en) * 1998-10-26 2000-12-26 Cisco Technology, Inc. Method and apparatus for defining and implementing high-level quality of service policies in computer networks
US6738377B1 (en) * 1999-01-29 2004-05-18 International Business Machines Corporation System and method for dynamic micro placement of IP connection filters

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102021127714A1 (de) 2021-10-25 2023-04-27 marbis GmbH Verfahren und Vorrichtung zum Verhindern von böswilligem Netzverkehr

Also Published As

Publication number Publication date
EP1284573B1 (de) 2005-10-26
US20030035370A1 (en) 2003-02-20
DE60206856D1 (de) 2005-12-01
US7207062B2 (en) 2007-04-17
EP1284573A1 (de) 2003-02-19

Similar Documents

Publication Publication Date Title
DE60206856T2 (de) Verfahren und Vorrichtung zum Schutz von Internetanlagen gegen Denial-of-Service Angriffen
DE60110792T2 (de) Paketkommunikationssystem
Douligeris et al. DDoS attacks and defense mechanisms: classification and state-of-the-art
Abliz Internet denial of service attacks and defense mechanisms
EP1560398B1 (de) Messung eines Stroms von Datenpaketen zum Begrenzen der Wirkungen von Denial-of-service Angriffen
US7331060B1 (en) Dynamic DoS flooding protection
DE102005037968B4 (de) Schutzsystem für eine Netzwerkinformationssicherheitszone
US6973040B1 (en) Method of maintaining lists of network characteristics
DE60201716T2 (de) Verfahren und Vorrichtung zum Schutz von E-Commerce-Site gegen Distributed-Denial-of-Service Angriffen
DE602004009356T2 (de) Verfahren und Vorrichtung zum Schutz einer Netzwerkinfrastruktur und zur gesicherten Kommunikation von Kontrollinformationen
US7930740B2 (en) System and method for detection and mitigation of distributed denial of service attacks
US7861292B2 (en) Method and apparatus for incrementally deploying ingress filtering on the Internet
DE60116754T2 (de) Sicherere registrierung von domänennamen
EP1721235B1 (de) Kommunikationssystem und verfahren zur bereitstellung eines mobilen kommunikationsdienstes
Siris et al. Provider-based deterministic packet marking against distributed DoS attacks
EP1464150B1 (de) Verfahren, datenträger, computersystem und computerprogrammprodukt zur erkennung und abwehr von angriffen auf serversysteme von netzwerk-diensteanbietern und -betreibern
Simon et al. AS-based accountability as a cost-effective DDoS defense
EP3170295B1 (de) Erhöhen der sicherheit beim port-knocking durch externe computersysteme
DE102016100692A1 (de) Netzwerkschutzentität und Verfahren zum Schutz eines Kommunikationsnetzwerks gegen betrügerische Nachrichten
EP1935163A1 (de) Netzwerkzugangsknotenrechner zu einem kommunikationsnetzwerk, kommunikationssystem und verfahren zum betreiben eines kommunikationssystems
EP1776821B1 (de) System und verfahren zum sicheren anmelden in einem kommuniktionssystem mit netzwerkverbindungs- und verbindungssteuerungs-rechnern
Bavosa GPRS security threats and solution recommendations
EP2887604B1 (de) Verfahren und Telekommunikationsnetz zur Erhöhung der Sicherheit beim paketorientierten Datenaustausch
Chuat et al. Availability Guarantees
Chou et al. gore: Routing-assisted defense against DDoS attacks

Legal Events

Date Code Title Description
8364 No opposition during term of opposition