Ja, super, schönen Dank für die Einladung.
Mein Name ist Frank Thias von der Firma 5 Networks.
Und mein Vortrag behandelt im Prinzip das Thema Sicherheit,
aber über die gesamten Anwendungsschichten, die es gibt.
Also es gibt ja verschiedene Netzwerklayer, es geht los mit
Layer 2, Layer 3 Konfigurationen und Sicherheitsproblemen.
Und dann, wie wir eben schon von meinem Vorredner gehört haben,
geht es natürlich auch in die Anwendung rein.
Und wenn ich Anwendungen absichern möchte, muss ich alle Layer betrachten.
Das heißt, es reicht nicht,
bin ich nur eine Geschichte, analysiere und absichere,
sondern im Prinzip muss alles
gesichert werden
Mit was für Business-Problemen haben wir es heutzutage zu tun,
wenn wir uns Netze anschauen oder wenn wir Anwendungen absichern wollen.
Es sind verschiedenste Themen, die betrachtet werden müssen,
sind zum einen die Verbifikation von Anwendungen.
Das ist aus meiner Sicht eine gute Entwicklung,
denn man hat im Prinzip nur noch einen Protokoll auf,
was man aufpassen muss.
Das ist typischerweise das Protokoll HTTP oder eingepackt eben in SSL.
HTTPS und damit kann man Firewall-Regelwerke in der Regel relativ einfach aufbauen.
Das zweite, womit wir es zu tun haben,
ist mit der Anzahl von Geräten.
Jeder hat typischerweise, also zumindest ich in meinem Haushalt,
mehrere Endgeräte,
mit denen
ich auf Anwendungen zugreife
Heutzutage ein Problem der Skalierbarkeit, dass ich diese Anwendung auch
performant zur Verfügung stellen kann und gleichzeitig aber auch das Ganze noch absichern muss.
Das heißt, es muss sicher sein, aber auch schnell
sein und dem gegenüber gibt es dann die Angriffe auf Anwendungslogik.
Das heißt, hier, was wir eben gesehen haben,
so eine SQL-Injection, das geht auf die Anwendung an sich,
das muss ich erkennen können, das muss ich absichern und braucht dafür geeignete Maßnahmen.
Seien die jetzt in der Anwendung selbst oder seien das durch Geräte,
die ich im Prinzip vor die Anwendung konfiguriere,
damit ich eine Eingabeüberprüfung letzten Endes machen kann.
Und das Letzte, was hier noch dargestellt ist,
sehr viele Unternehmen, Verlagern die Anwendungen in die Cloud.
Das heißt, die läuft nicht mehr im eigenen Rechenzentrum,
sondern beispielsweise in einem anderen Rechenzentrum. Und ich brauche die Möglichkeit,
den Netzwerksverkehr umzulenken, aber auch gleichzeitig kontrollieren zu können.
Und diese Anforderungen versucht man mit Technologien zu erfüllen,
um da letzten Endes auch eine Absicherung herbeileiten zu können.
Ein Schlagwort oder ein Thema, was wir heute schon gehört haben,
ist im Bereich der Netzwerksicherheit, die nicht mehr zur Verfügungsstehung eines Dienstes.
Das heißt, man macht eine sogenannte Night-of-Service-Attacke.
Sehr viele unserer Kunden haben schon Erfahrungen damit gemacht und zielfrei
Von entsprechenden Geräten ist es eben so, in den Isle of Service abzuwehren.
Und auch dafür gibt es wieder verschiedene Technologien,
wie wir gleich sehen. Man kann zunächst mal unterscheiden,
auf welcher Schicht innerhalb des Netzwerkmodells mache ich so einen Angriff.
Man kann die Möglichkeit auf dem Player 7 in die Night
of Service zu machen. Das bedeutet beispielsweise,
dass ich eine hohe Anzahl von HTTP-Requests auf eine Web-Anwendung sende,
sodass die überlaufen wird und die Anwendung nicht mehr arbeiten kann,
die Anfragen nicht mehr beantworten kann.
Oder demgegenüber gibt es auch Anwendungsschicht, auch genau den umgekehrten
Fall, das ist ein sogenanntes Slow-HTTP-Post-Attacken. Das heißt,
wo ich mit einer HTTP-Posterbindungen öffnen und die sehr lange offen halte.
Und damit im Prinzip die Webanwendung beschäftige oder so stark beschäftige.
Also die Anfragen nicht mehr beantworten kann. Und das sind
eben Anwendungsproblematiken, die hier auf die Anwendung selbst zielen,
auf den Layer 7. Demgegenüber gibt es aber auch Angriffe,
die volumenbasierend sind.
Das heißt, ich habe einzelne Clients oder auch mehrere kleinen, sogenannte Bot-Netzwerke.
Und mit diesen Bot-Netzwerken versuche ich ein sehr hohes Trafficvolumen zu erzeugen.
Das kann ich dann auch wieder auf den unterschiedlichsten Netzwerkschichten machen,
beispielsweise auf einem Layer 4 mit einem sogenannten Sündflooding oder aber auch mit einem Connection-Flooding,
wo dann tatsächlich auch TCP-Verbindungen aufgebaut werden.
Oder ich kann wieder hochgehen bis zum Layer 7 und ein TCP-Request-Flooding
machen. Also da habe ich dann die Möglichkeit,
hier entsprechende Funktionen einzusetzen, um diese Angriffe abzuwehren.
Was setze ich jetzt als Kunde ein,
um ein möglichst sicheres oder funktionales Konstrukt zu haben?
Es wird im richtigen Leben sicherlich eine Mischung aus
mehreren Technologien sein
Das eine Thema, das Thema Connection-Flarding kriege ich sehr gut in dem Griff,
in dem ich hier Cloud-basierende Deed-of-Services verwende, stellen Sie sich vor,
Sie haben eine Netzwerkanbindung mit zwei Gigabit und Sie kriegen dann
einen Sonnenflarding über zwei Gigabit, dann ist die Netzwerkverbindung überfüllt.
Es können keine neuen Pakete mehr zusendet werden. Das heißt,
solche Problematiken kriege ich im Prinzip nur mit Service-Provider,
Technologien in den Griff oder mit Lösungen,
die eben schon beim Service-Provider stehen und dort die Datenpakete abfangen.
Auf der anderen Seite, wenn ich mir in den Isle of Service anschaue,
der auf die Anwendungsebene geht oder der beispielsweise SSL ausnutzt,
SSL Reanegociations macht, also neue SSL-Handshakes in der bestehenden SSL-Verbindung,
kann ich sowas nur erkennen mit einem System,
wo ich zum Beispiel auch das SSL unterbreche,
intercepte und den Inhalt der Verbindung verstehe.
Das heißt, man arbeitet typischerweise mit einem Mix aus diesen Technologien,
um eben ein gutes Maß an Sicherheit zu erreichen und die Anwendung abzusichern.
Das heißt, typischerweise wird es nicht ausreichen,
wenn sie sich verschiedene Denial of Service-Szenarien anschauen oder auch Netzwerksicherheitsszenarien,
wenn sie mit einer Technologie arbeiten.
Damit kriegen sie vielleicht 60 bis 70 Prozent der Probleme in den Griff,
aber es fehlt dann letzten Endes die Anwendungs-Awareness oder die Möglichkeit,
die fehlten 30 Prozent zu kontrollieren oder überprüfen zu können.
Das Ganze ist hier noch mal ein Beispiel dargestellt.
Hier haben wir noch mal ein Beispiel, wo ich im Prinzip
einen Netzwerkattacke habe von Benutzern oder Angreifern, die im Internet sind.
Das heißt, die machen einen Angriff auf ein Unternehmensnetzwerk,
was eine öffentliche Webpräsenz hat.
Und wenn ich so ein Scrubbing-Provider oder Anti-Didos-Provider einsetze,
dauert es zunächst mal eine gewisse Zeit,
bis die Pakete auf diesen DDoS-Provider umgeleitet werden.
Das heißt, braucht typischerweise bis zu einer Stunde,
bis dieser Detos-Service hier aktiv ist,
wo ich dann eben diese volumenbasierenden Angriffe erkennen kann.
Und das bedeutet, dass innerhalb dieser einen Stunde die Anwendung
hier angegriffen werden kann und dass der Angreifer damit die Möglichkeit hat,
hier die Anwendung lahmzulegen. Wenn die Anwendung erst mal lahmgelegt ist,
braucht es eben auch eine gewisse Weile oder eine gewisse Dauer,
bis sich die Anwendung wieder hochfahren kann. Das heißt,
wenn ich hier diese Latenz von einer Stunde habe,
ist das ganze System aktiv ist und ich dann
etwa 90 Prozent des Datenvolumens des Angriffs limitieren kann,
in dieser Zeit ist hier hinten alles lahmgelegt und
diese Arbeit sind erst mal platt
Und man braucht dann quasi wieder eine Ramp-Up-Phase,
wo ich die Möglichkeit habe, die Services dann hochzufahren.
Das ist dann auch wieder ein asymmetrischer Prozess. Das heißt,
ich fahre die Services nacheinander hoch und es dauert eine gewisse Weise oder eine gewisse Zeit,
bis der Service wieder zur Verfügung steht und verwendet werden kann.
Und deswegen ist es im richtigen Leben oder im produktiven Betrieb
notwendig, dass ich mehrere Technologien verwende.
Hier sehen wir auch nochmal ein Schaubild dazu. Da habe ich
im Prinzip die Angreifer, die diesen den Ilove-Service machen.
Das geht hier durch so einen Anti-Didos-Service. Damit kriege ich so etwa 90 Prozent des Datenverkehrs,
dieser bösen Clients hier in den Griff, kriegst sie blockiert,
die legen mir aber hier schon die ganze Anwendung lahm,
wenn ich auf dieser Seite hier keine Schutzmaßnahmen habe,
die direkt vor meinen Anwendungen stehen und in Traffic im Prinzip im Rechenzentrum direkt auch limitieren.
Also ich muss eine Kombination aus beiden Technologien betreiben und was man da machen kann,
ich kann Richtung Internet hier diesen Antidididos-Service verwenden,
um hier die Hauptlast abzuwehren und parallel kann man hier sehr schnelle Proxy-Technologien platzieren,
die eben auch in der Lage sind,
zunächst mal auf einem Layer 4
Eine Traffic-Management- oder Schutzentscheidung herzuleiten, das heißt,
hier kann ich auch Synflatter-Tags erkennen und direkt blockieren mit sogenannten Full-Proxy-Technologien.
Ich habe gleichzeitig aber auch die Möglichkeit,
da sieht man hier an einem kleinen Beispiel,
dass ich Business in Layer 7 hochgehen kann.
Und dann zum Beispiel die einzelnen URLs blockieren kann,
die angegriffen werden. Das kann programmatisch stattfinden, typischerweise.
Das heißt, Proxy-Systeme sind in der Regel programmierbar.
Es gibt aber auch Proxy-Systeme, die hier dynamisch reagieren.
Das heißt, moderne Systeme sind heutzutage in der Lage,
hier zu analysieren, wie ist denn beispielsweise die Latenzzeit zu
der Web-Anwendung
Dann ist es ja ein Problem festzustellen,
woher leide ich überhaupt unter den Night of Service oder nicht,
wenn es beispielsweise in Layer 7 Genial of Service Thema ist.
Das heißt, man kann hier die Latenzzeit mitmessen. Wenn man dort feststellt,
dass ich die Latenzzeit beispielsweise um den Faktor 5 erhöht,
beispielsweise von 20 Millisekunden auf 100 Millisekunden oder wenn das Trafficvolumen
hier von 1.000 HTTTP-Requests auf 5.000 HTTP-Requests ansteigen pro Sekunde,
dann kann ich hier Schutzmaßnahmen einleiten.
Das heißt, ich habe auf der einen Seite die Möglichkeit,
hier diese Volumen basierenden Angriffe kennen und zu blockieren
Und auf der anderen Seite habe ich hier noch Schutzverfahren direkt im Rechenzentrum selbst,
vor der Web-Anwendung, wo ich direkt und immer reagieren kann.
Bei dieser Didos-Service ja typischerweise zugeschaltet wird. Das zweite Beispiel,
was man machen kann, wenn man unter einem Denial-of-Service leitet, dass man dynamisch quasi die Sicherheitseinstellung anhebt. Das heißt,
ich habe hier wieder diese Angreifer,
die meiner Web-Anwendung penetrieren und versuchen, lahmzulegen und für bestimmte Prozesse,
die ich beispielsweise normalerweise nicht mit einem Capture überprüfe,
habe ich die Möglichkeit,
auch wieder über eine relativ einfache Programmierung zu sagen,
Wenn ich hier eine hohe Anzahl von Harged de Perequest pro Sekunde sehe,
von unterschiedlichen kleinen Systemen oder eine bestimmte Anzahl beispielsweise von Login Fehlversuchen,
was ja auch in Denial of Service sein könnte,
dann blende mir hier auf der Kleinseite dynamischen Capture ein.
Das heißt, normalerweise, die normalen Benutzer,
die mit der Webanwendung arbeiten, die sich normal verhalten,
für die ist alles in Ordnung. Aber die Systeme,
die hier auftauchen und eine hohe Anzahl beispielsweise von fehlerhaften Logins haben,
denen präsentiere ich beispielsweise nach dem dritten oder vierten fehlerhaften Login in Capture,
sodass er sich dann eben über Scapture zusätzlich mit authentifizieren muss,
sodass man automatisierte Touren und Kenner auf der Art und Weise,
auf die Art und Weise aussperren kann.
Das letzte Beispiel, was ich hier noch kurz darstellen möchte,
ist, dass ich hier direkt auf dem System auch ein Authentisierungslayer hinzufüge.
Ist auch wieder ein Beispiel, dass ich normalerweise hier eine
öffentliche Anwendung habe, die normalerweise von jedermann besucht werden kann.
Und ich habe aber dann die Möglichkeit,
im Angriffsfall oder ja, in dem Fall,
wo ich hier eine hohe Anzahl von Client-Sessions habe,
die versuchen, meine Anwendung wieder da anzulegen,
dass ich dort einen zusätzlichen Authentisierungslayer an der Stelle wieder hinzufüge,
dass ich hier eben eine vorgelagerte Authentisierung habe und damit hier eben diese angreifenden Systeme aussperren kann.
Und das sind so Schutzfunktionen,
die ich zusätzlich zu externen Providern verwenden kann und eben die
Sicherheit im Rechenzentrum selbst zu gewährleisten und die Sicherheit zu erhöhen.
Eine weitere Funktion, die es heutzutage auf dem Markt gibt und
die man einsetzen kann, ist die Verwendung von IP-Deputationsdatenbanken.
Das ist im Prinzip ein Service, der im Internet läuft, den man abfragen kann.
Und ich habe dann die Möglichkeit, im Prinzip zu sagen,
wenn hier eine bestimmte Absenderadresse an dem System ankommt,
dass ich diese Adresse in eine Kategorie unterteilen kann.
Und so bin ich beispielsweise in der Lage,
den Kleinen zu unterscheiden, ob er aus einem Botnet kommt
oder ob er aus einem Tor-Netzwerk kommt oder von einem Anonymous-Proxy.
Und dann kann ich hier zentral auch wieder eine Sicherheitsentscheidung treffen.
Die Sicherheitsentscheidung könnte beispielsweise lauten, dass ich in die Bandbreite limitiere. Das heißt,
wenn ich Absenderadressen sehe, die aus einem Botnet kommen,
gebe ich dir nicht die gesamte zur Verfügung stehende Bandbreite,
sondern ich limitiere die Bandbreite. Oder wenn ich weiß,
die Clients kommen über irgendwelche Anonymous-Proxys,
dass ich die beispielsweise ganz sperre und gar nicht erst auf meine Webanwendung drauflassen und das ist eine weitere Möglichkeit,
wie ich eben eine einzelne Verbindung zu einem entsprechenden Kontext hinzufügen kann und dann wir eine Entscheidung treffe,
lasse ich das auf die Anwendung zu,
blende ich den beispielsweise in Capture ein,
mache ich für die Verbindung, die hier aus irgendeinem Netzwerk kommt,
noch eine zusätzliche Authentisierung, beispielsweise eine Mehrfaktor-Authentisierung.
Und damit kann ich eben die Sicherheit erhöhen und das bedeutet eben auch,
dass ich nicht nur auf den oberen Lehren arbeiten muss,
sondern durch die Möglichkeit,
dass ich das Ganze programmieren und steuern kann,
kann ich das im Prinzip
beliebig beeinflussen und konfigurieren
Ich habe jetzt schon einige Angriffe kurz vorgestellt. Ich versuche
jetzt später gleich hier auch noch eine Demo zu machen.
Ich habe hier eine virtuelle Maschine mit einem Client,
einem Server und dann kann ich Ihnen so ein paar Sachen noch zeigen,
bevor ich dazu übergehe,
will ich aber auch nochmal hier auf diese einzelnen Layer des Osi-Modells eingehen und kurz erwähnen,
was es zumindest für Möglichkeiten gibt und wo Angriffe stattfinden können und welche Abwehrverfahren es eben gibt.
Also typischerweise bewegen wir uns hier im Bereich der Netzwerksicherheit.
Es geht los beim Data-Link-Player, dass das Layer 2-Geschäft,
wo man Max-Boofing beispielsweise machen kann. Das ist eigentlich ein Thema,
was ich typischerweise nur im lokalen Netzwerk betrachte und es für Leute,
die mit Internet-Business zu tun haben, eigentlich nicht so sehr interessant.
Das Internet-Geschäft geht hier typischerweise im Layer-3-Bereich los. Das ist
der Netzwerk-Layer. Da geht es im Prinzip um das Routing
. Das heißt, da unterscheide ich Upstandard-Adressen, Zieleadressen,
dann hier beim Transport-Layer habe ich dann die entsprechenden Ports,
beispielsweise Port 80 für HTDP, Port 4-4-3 für eine verschlüsselte HTDP-Verbindung für SSL.
Und dann geht es hier in diesen Session-Bereich über,
wo ich dann die entsprechenden DNS-Verfahren teilweise, wenn ich sie angreife schon,
unterscheiden kann oder eben hier in die Anwendung rein,
was wir von ihrem Kollegen eben schon gehört haben,
Overstop 10, die Möglichkeit, dann eben die Anwendung zu missbrauchen,
mit einer SQL-Injection oder Cross-Site-Script,
denn hier Slow-Post oder Get Flights.
Was gibt es da für Angriffsmöglichkeiten? Hier auf dem Network-Layer
gibt es diese Volumen-basierenden Attacken, die ich schon erwähnt habe,
die ich gut mit den Scrubber-Services oder Cloud-Diensten in den Griff bekommen kann.
Und typischerweise hat man es hier eben mit Sun-Flouding, Connection-Flouding-Attacken
zu tun. Also hier ist ja nicht ein Angreifer,
hohe Anzahl von Sund-Paketen, die Programme dafür sind im Internet frei verfügbar.
Es ist kein Hexenwerk, sich da eine Kenntnis anzueignen und
dann diese Services hier zu betreiben. Tatsächliche Angreifer,
die steuern teilweise ganze Botnetze, das heißt,
da sind Sammlungen von mehreren Rechnersystemen, was können 10,
100.000 Rechner sein und die senden dann eben hier eine sehr
hohe Paketanzahl in Richtung ihrer Anwendung und versuchen diese Anwendung ladenzulegen.
Und das sind eben dann hier,
wenn man diesen Network-Layer betrachtet,
diese Netzwerkangriffe
Auf Netzwerkebene und teilweise hier auch auf Transportebene eingehen.
Das ist wie so ein Flatt-Attacke. Als Metigation-Technologien oder Technologien,
um solche Angriffe abzuwehren, kann ich klassischerweise IPS-Systeme verwenden.
Firewall-Systeme haben durchaus auch Funktionen in dem Bereich, dass ich
so etwas abwehren kann. Oder ich habe die Möglichkeit,
hier vor meiner Anwendung beispielsweise einen vollständigen TCP-Proxy zu definieren,
der erst mal abprüft, ist das überhaupt ein vollständiger TCP-Handcheck,
der aufgebaut wird von einem Kleinen zur Anwendung,
wenn ja, lasse ich ihn durch.
Und wenn nein, kommt das Paket hier gar nicht bis zur Anwendung durch.
Das heißt, ich habe vorneweg dann schon eine Möglichkeit geschaffen,
diesen Angriff abzuwehren. Das Zweite, was wir dann hier
haben in diesem Bereich, sind die Angriffe auf die Sessions.
Und das ist zum Beispiel in DNS UDP-Lading.
Das heißt, ihre Webanwendung ist ja unter einem Namen erreichbar.
Die wenigsten Menschen können sich ja IP-Adressen merken. Also hat
man ja irgendwann, oder ziemlich am Anfang schon Namen eingeführt.
Und mit so einem DNS ein UDP-Lading versuche ich im Prinzip den DNS-Service lahmzulegen,
damit der nicht mehr auf eine Namensanfrage antworten kann.
Und hierüber kann ich eben auch einen entsprechenden Missbrauch machen an der Stelle.
Ich kann den versuchen lahmzulegen. Die letzten populären Opfer in
der Presse hier, waren diese sogenannten DNS-Amplification Attacks.
Da hat man im Prinzip offene DNS-Server genommen, die im Internet standen.
Man hat eine relativ kleine DNS-Anfrage dorthin gesendet mit einer falschen Absender-Adresse.
Und dieser Server hat dann eine relativ große Response,
um den Faktor 50 etwa geantwortet und damit eben dem Opfer diese Antwortpakete gesendet.
Und man hat damit ungefähr eine Verstärkung um den Faktor 50
erreicht und konnte damit dann die Opfersysteme im Prinzip über
ein Fludding mit der DNS-Response Slam
Hier auch reinzählt, sind SSL-Platz. Das heißt,
eine hohe Anzahl von neuen SSL-Verbindungen, die von einem Client aufgebaut werden.
Was ich versuchen muss, irgendwie zu erkennen, oder Renegociations,
das sind neue SSL-Schlüssel, die ausgetauscht werden.
Und damit kann ich entsprechender Serversystem überlasten,
wenn ich das nicht in einer sehr performanten Hardware beantworte.
Das heißt, hier haben wir auch genügend Angriffsmöglichkeiten,
wie ich eine Anwendung missbrauchen kann oder wie ich die Anwendung schlichtweg lahmlegen kann.
Und dann sind wir hier nach diesen Session-Angriffen bei den Applicational Text angekommen.
Da gibt es Beispiele, die eben Die Programmierlogik ausnutzen,
wo teilweise eine mangelhafte Eingabeüberprüfung gemacht wird, ein mangelhaftes Session-Handling.
Wenn wir uns an das Beispiel von eben erinnern, mit diesem Session-Cookie,
sodass ich genügend Angriffsmöglichkeiten habe, um sowas zu missbrauchen.
Ein paar von diesen Angriffen kann ich Ihnen mal hier kurz zeigen und auch,
wie die funktionieren, was man dazu im Prinzip braucht,
ist typischerweise ein Linux-Betriebssystem, da stehen die Programme eigentlich zur Verfügung,
wenn nicht, kann man sie nachinstallieren in einem Programm,
was ich zum Beispiel zum Testen von Netzwerkpaketen oder zum Generieren von Netzwerkpaketen verwenden kann, ist das Programm HPP3.
Das heißt, das kann mir hier alle 20 Mikrosekunden
ein Sündenpaket senden auf dem Port 80 zu dieser Zieladresse.
Und vor dieser Zielatesse habe ich noch ein System konfiguriert und dass das Paket ankommt,
kann ich hier mal kurz überwachen oder kontrollieren mit einem TCP-Dump.
Hier sehen wir jetzt quasi die Serverseite der Verbindung.
Also der Angreifer ist dieses System hier. Das endet mir
die Sündenpakete und das hier ist der entsprechende Sava.
Und zwischendrin habe ich noch ein System konfiguriert
Was ich zum einen erst mal... Das ist jetzt keine Werbung.
Was ich zum einen erst mal Paket orientiert konfiguriert habe,
das heißt, ich habe hier ein sogenanntes Performance Layer 4-Profil zugeordnet.
Und damit arbeitet das System in einem Paket basierenden Ansatz.
Das heißt, wenn ich jetzt hier dieses Synflading starte,
sehen wir hier, es werden Pakete generiert.
Und hier sehen Sie auf der Server-Seite, dass diese Pakete ankommen.
Und wenn ich das eben in richtiger Hardware mache,
kann das das Kleinsystem schon überlasten, beziehungsweise das Server-System,
was ja angegriffen wird.
Wenn ich das hier mal abbreche,
sehen Sie hier schon auf dem Server,
dass der irgendwelche Probleme hat
Und irgendwelche Meldungen nicht mehr ganz mit protokollieren kann.
Und das liegt eben an der hohen Anzahl,
ich breche das jetzt mal ab, nicht, dass hier alles zusammenbricht.
Das liegt eben an der hohen Anzahl von Paketen, die hier entsprechend übermittelt worden sind.
Sie sehen eben hier in dieser kurzen Zeit,
waren das über 500.000 Pakete, die ein einziger Client hier in so einer virtuellen Umgebung konfiguriert hat.
Hätte ich jetzt eine Full Proxy davor,
dann würde ich im Prinzip sagen, hier klein, pass mal auf,
du musst mit mir erst einen ordentlichen TCP-Handshake machen und erst wenn du das gemacht hast,
der Client zur Maschine, ein ordentlicher TCP-Handschek,
dann wird die Verbindung zu den Backend-Server,
der geschützt wird, erst aufgebaut.
Und wenn wir quasi das hier so konfiguriert haben,
ist ja nicht das Ganze nochmal.
Habe ich den Update-Knopf gedrückt, gestern manchmal?
Ja. Und jetzt starten wir das nochmal.
Jetzt wieder da Harping. Und hier sehen sie eben,
dass auf der Backend-Anwendung noch ein paar Sessions von eben gewesen sind,
aber sie sehen das Backend-System, bekommt die Verbindung im Prinzip nicht ab.
Dadurch, dass der Full Proxy vorne eben diese kompletten Verbindungen
kontrollieren kann und entsprechend steuern kann. Das war so das
erste Beispiel, was auch auf dieser Folie hier gewesen ist.
Das war im Prinzip ein Beispiel aus diesem Bereich Synflodding.
Das war ein klassisches Synflodding. Man könnte da auch noch
ein Connection-Flirting zeigen und da muss ich im Prinzip die neuen Verbindungen pro Sekunde erkennen.
Das sind dann auch tatsächlich aufgebaute Verbindungen von tatsächlichen Kleinsystemen.
Und die kann ich dann auch wieder versuchen zu erkennen
und ich könnte sie dann beispielsweise pro Absender-Adresse limitieren.
Ein anderes Beispiel, was ein bisschen interessanter ist,
ich baue eine SSL-Verbindung auf, das ist erstmal Okay.
Und dann, wenn die SSL-Verbindung steht oder TCP-Session,
kann ich versuchen, die SSL-Hardware zu überlasten,
indem ich innerhalb der verschlüsselten Verbindung immer wieder neue Schlüssel anfordere,
das ist ein Mechanismus,
der durchaus stadthaft ist und auch verwendet werden kann.
Und wenn ich so einen Mechanismus verwenden möchte,
nehme ich jetzt einfach mal einen Service hier, der SSL terminiert.
Das ist dieses Teil hier auf der 10, 255,
0, 2, 2 oder 1. Und für so ein SSL-Flading,
gibt es auch entsprechende Tools,
sagen wir mal
Warte mal gucken. Genau,
das ist dieses Tool von THC, das ist ein SSL-DOS-Programm,
da gebe ich auch wieder als Schalter die Zieladresse an,
die ich komme und promittieren möchte und dann eben den entsprechenden Port,
ich öffne hier nochmal einen Performance-Monitor, dass man auch sehen kann,
dass die Maschine tatsächlich dann unter Belastung kommt.
So, es dauert jetzt einen Augenblick,
weil ich dann dieses Tool jetzt hier starte,
kommt noch eine freche Bemerkung vom Programmierer, okay,
das kann man auch rausnehmen und wenn man jetzt einen Augenblick wartet,
fängt das Programm dann eben an,
eine SSL-Verbindung aufzubauen und dann innerhalb dieser aufgebauten TCP-Verbindung immer wieder neue SSL-Session-IDs aufzubauen.
Sie sehen hier, kriege ich mit einem einfachen PC 440 neue SSL-Handshakes pro Sekunde hin.
Und wie will ich das jetzt überprüfen? Das ist eine
TCP-Verbindung, das kriegen sie mit einer DDoS-Metigation-Technologie nicht hin.
Das kriegen sie nur in den Griff oder erkannt,
wenn sie tatsächlich die SSL-Verbindung verstehen und terminieren.
Ansonsten haben sie da relativ wenig Chancen, sowas zu erkennen.
Und man sieht das dann auch hier an den entsprechenden CPU-Auslastungen,
die sehen hier okay, das ist jetzt eine virtuelle Maschine in der WM-WM-Umgebung,
dass die CPU hier schon was zu schaffen hat.
Jetzt gibt es für bestimmte Plattformen Programmiermöglichkeiten. Und diese Programmiermöglichkeiten können dann zum Beispiel sagen,
hier, passt mal auf,
wenn du zum Beispiel mehr als fünf oder zehn rienige Ociations pro IP-Adresse hast,
dann blockiere bitte diesen Client aktuell und setze ihn beispielsweise auch für fünf Minuten auf eine Plackliste drauf,
dass der gar nicht mehr bis zur Back-and-Anwendung kommt.
Und solche Programmiermöglichkeiten kann man durchaus zur Verfügung stellen.
Das heißt, ich kann hier So eine Regel zuordnen,
wo ich dann eben sage, wie heißt DDoS, SSL-TPS.
Und wenn ich das jetzt hier entsprechend konfiguriere und zuordne,
dann dauert es wieder einen Augenblick, bis er anfängt.
Er baut dann die TCP-Verbindung auf, er macht doch wieder Ruiniosciations,
aber nach relativ kurzer Zeit wird man dann feststellen, er kommt nicht weiter.
Und wenn ich dann das Skript nochmal neu starte,
kommt dann eine Fehlermeldung, die besagt,
Renégosciations sind für diese Anwendung im Moment,
wir sehen es schon, dass es gar nicht mehr durchläuft,
abgeschaltet.
Und somit habe ich eine Möglichkeit,
eben die Anwendung oder das SSL-System
vor einer Überlastung
zu schürzen
Nur deswegen gut, weil ich tatsächlich den Kontext der SSL-Verbindung verstehe.
Das ist ganz wichtig, mit einem normalen System,
was ein TCP-Limiting machen würde, könnte ich diesen Angriff hier nicht erkennen.
Und so kann man sich eben über die OSI-Layer hochhangeln und
die einen Layer missbrauchen und die anderen Layer,
bis man dann letzten Endes beim Anwendungslayer ist.
Und beim Anwendungslayer gehe ich noch mal kurz auf dieses Beispiel SQL-Intection ein.
Es wurde ja von meinem Vorredner verwendet. Das ist eine
ganz schlechte Anwendung. Das ist so eine Demo-Anwendung,
wo man Hacking-Übungen mitmachen kann. Die hat verschiedenste Verletzbarkeiten und
die ist zum einen auch verletzbar in den Bereichen SQL-Enjection.
Was kann man da machen? Man kann hier zum Beispiel
bei diesem Userfeld Tick or 1 ist gleich 1,
versuchen da SQL-Injection zu machen.
Und dann kann ich mich eben als dieser Benutzer hier anmelden,
das ist jetzt erstmal blöd, den Benutzer haben sie wahrscheinlich nicht in ihrer Datenbank drin.
Also es sieht hier schon mal ziemlich doof aus, dass der sich anmelden kann.
Aber wenn der dann eben auf sein Kontrollpanel geht,
dann sieht er den Inhalt der kompletten Datenbank mit allen Adressaten.
Und das kann eben ein Problem sein von einer nicht guten Eingabeüberprüfung.
Das heißt, man überprüft nicht, welche Zeichen dürfen denn überhaupt
von einem Kleinen über einen Parameter an die Anwendung gesendet werden.
Und Republication Firewall oder eine Eingabeüberprüfung an eine Anwendung,
könnte es so ein Angriff beispielsweise erkennen. Das will ich
auch noch mal kurz darstellen, was es da für Möglichkeiten gibt.
Ich ordne einfach mal hier jetzt eine Security Policy zu,
die eben dann dem System die Möglichkeit schafft auf Layer 7.
Hier bin ich tatsächlich eine Überprüfung machen zu können.
Es wird über eine sogenannte Klasse realisiert, okay,
dafür brauche ich noch, muss ich dem System noch sagen,
dass der Verkehr,
der hierüber übermittelt wird,
auch tatsächlich HTTP ist
Gleich bin ich soweit. Okay, jetzt ordne ich die Klasse noch zu.
Okay. Und dann gucken wir uns das nochmal an.
Mach nochmal eine komplett neue Session hier auf, dass da keine Fragmente,
so 55-0-2-0-1, da bin ich wieder.
Und wenn ich jetzt hier diese Quellinjection nochmal versuche,
bitte im Prinzip eine Eingabeüberprüfung gemacht, das kann gegen Placklisten stattfinden,
also gegen sogenannte Signaturen, die man kennt,
oder man kann auch ein Whitelisting machen an der Stelle und eben sagen,
Was für Zeichen lasse ich denn da überhaupt zu,
lasse ich den Tick zu,
lasse ich das Gatter zu.
Und dann kann eben diese Einklaberüberprüfung sagen, okay,
die Zeichen habe ich da nicht erlaubt,
anstatt der Benutzer sich dann eben an der Anmeldung anmelden kann,
bekommt Anne-Blocking-Seite generiert.
Das geht dann teilweise sogar so weit. Das Ganze geht auf Requestbasis,
dass ich tatsächlich auch in die Logik der Web-Anwendung eingreifen kann.
Das heißt, was ich hier an dieser schlecht programmierten Anwendung
auch machen kann, würde ich auch kurz zeigen.
Ich nehme nochmal die Security Policy weg
Das ist ein sogenanntes Parameter-Tempering, Parameter-Tempering kann ich verwenden,
um billiger einzukaufen. Das heißt, ich kriege einen Betrag
beispielsweise als Hidden Field ausgeliefert. Da steht drin,
eine Socke kostet 10 Euro und dann kann ich so 10 Euro
nach 1 Euro ändern und kaufe dann die Socke für 1 Euro.
Das wäre ein Beispiel für sowas. Das geht aber auch
beispielsweise für andere Felder, je nachdem,
was man da in seiner Anwendung hat.
Ich melde mich mal hier an, als ein gültiger Benutzer,
dass der Frank 007. Und wenn der sich jetzt hier anmeldet,
sieht er zunächst mal hier all seine Sachen.
Und wenn er jetzt auf sein Kontrollpanel geht,
sehen sie hier oben im Pfad diesen Frank 007
und der kann das ändern
Auf James 007, den habe ich auch mal hinzugefügt.
Und dann sieht er eben vom Chanks die Informationen.
Also das ist so ein typisches Parameter-Tempering-Beispiel. Und mit einer
Web-Application-Firewall kann ich eben, wenn ich das Teil aktiviere,
diese Manipulation erkennen, was technologisch gemacht wird,
das wird im Prinzip der Parameter wert.
Und der Parameternamen in den Session-Cookie mit reingerechnet, der wird verschlüsselt.
Und wenn ich dann eben diesen Wert ändere,
passt der Verschlüsselung, das Verschlüsselungsergebnis nicht mehr zu dem geänderten Parameterpaar.
Und dann kann das Ganze blockiert werden. Das heißt,
ich schalte nochmal kurz hier die Policy an.
Und wenn wir dann Das Beispiel nochmal probieren. Was sind
wir hier? Ich melde mich kurz an. So,
jetzt gehe ich auf mein Kontrollpanel und ändere den Benutzer,
was weiß ich, auf Frank 06 beispielsweise, dann kriege ich eine Blocking-Seite.
Und das ist zum Beispiel was, was ich nicht mit einer Eingabeüberprüfung kontrollieren kann.
Ich habe jetzt hier kein Sonderzeichen hängen gesehen oder so,
wo ich sage, ein Tick.
Oder hier arbeite jetzt im Hintergrund auch keine Signatur,
die sagt, Frank 006,
das ist jetzt ein gefährlicher Benutzer,
den blockiere ich mal
Man kann eben dieses Paar, was man hier sieht,
in den Cookie mit reinrechnen, die die Web-Application Firewall ausstellt.
Und dann kann ich solche Manipulationen eben auch erkennen.
Und das war schon eigentlich das Ende meines Vortrags.
Sie sehen also Netzwerksicherheit, gehen im Prinzip über alle Layer.
Es sind diese niedrigen Layer,
die man angreifen kann durch falsch kontrollierte oder konfigurierte Access-Controlllisten,
durch Fludding-Angriffe im Bereich den Isle of Service.
Dann hat man hier diese Session-Problematiken, wo ich auch wieder
die Services lahmlegen kann, wenn ich das nicht steuern kann.
Und dann eben hier die Möglichkeit, den Layer 7,
also die Anwendung selbst zu missbrauchen,
die Business-Logik
Im Prinzip auszutricksen. Und mit geeigneten Technologien kann man diese,
ich darf keine Werbung hier machen,
kann man diese Angriffe erkennen,
und das müssen auch nicht unbedingt komplexe Architekturen sein,
denn diese Technologien kann man alle in einem Gerät betreiben und hat damit eine relativ einfache Architektur,
die einfach zu warten ist.
Ja, und das war mein Vortrag.