 Herzlich Willkommen zu unserem Abendprogramm hier auf der GPN. Sebastian und Moritz haben von selbst gesagt, sie tun Dinge im Internet. Und wir uns jetzt erzählen, was Delos ist und wie wir uns am besten dagegen schützen können. Viel Spaß beim Vortag und einen kräftigen Applaus für die beiden. Ja, danke schön. Schön, dass ihr alle da seid. Es freut mich, dass ihr insbesondere rechtzeitig gekommen seid. Wir versuchen auch rechtzeitig aufzuhören. Wir wissen, DFB-Pokalfinale, ihr wollt da alle unbedingt hin. Kurzes Show-Fans, Freiburg, Leipzig. Wem ist scheißegal? Ah. Okay, gut. Dann erkläre ich das Eisoffiziell für gebrochen und wir fangen an. Das ist Neuner. Neuner ist bei dem baden-württembergischen Landeshochschulenetz Backbone-Klempner. Ich bin Freelance-Network-Architekt, bin noch beim Denok mit dabei. Das ist der Gruppe der Deutschen Network Operators. Wir machen zusammen den Spätzle-IX, den schönen Internet Exchange in Stuttgart. Und ja, ich würde sagen, das reicht auch an Vorstellung. Vielleicht noch ein kurzer Disclaimer. Wir beide sind Network Engineers. Das heißt, für uns ist so Isolayer 1 bis 3 das, wo wir uns wohlfühlen, sprich so das, wo die IP-Adresse aufhört. Und manchmal finden wir auch noch so Sachen wie Ports auf Layer 4, aber da hört es dann auf. Habt es bitte im Hinterkopf, wenn wir jetzt gerade den Vortag halten und ihr irgendwas nicht seht, was ihr gewohnt seid, das liegt einfach an der Natur unserer Gattung. Das sollte außerdem ein Steiger-Talk werden. Deswegen kann es sein, dass technische Details auf der Strecke bleiben. Dementsprechend, wenn euch einfach Begriff nicht perfekt genug erklärt ist, dann verwendet bitte Google und nicht insbesondere die YouTube-Kommentare in Zukunft. Und ja, wir sind hier in der Open Source veranstalteten Summe. Deswegen werden wir uns mit kommerziellen Lösungen, die in dieser Branche sehr häufig unterwegs sind, etwas bedeckt erhalten. Und vielleicht noch, es ist das Abendprogramm, deswegen entschuldigt schon mal vorweg den einen oder anderen schlechten Joke. Ja, damit an neuner die schlechten Witze und was ein DDoS eigentlich ist. Sehr gut, danke schön. Also es geht naturgemäß los mit, was ist ein DDoS? Ja, also die, die ab kurz und kurz erklärt, ich fange hinten mit dem DDoS an. Es steht für Denial of Service. Also es geht irgendwie darum, irgendwas dazu zu kriegen, einen Service dazu zu kriegen, was nicht mehr funktioniert auf irgendeine Art. Ich habe es jetzt hier mal an ein paar Real World Beispielen erklärt. Also zum Beispiel ganz links das Bild S-Bahn Tür zugemauert. Jetzt kann man den Service S-Bahn fahren nicht mehr benutzen. Ja, dadurch, dass jemand da eine Lücke gefunden hat. Danke, danke. Das zweite kennt vielleicht auch viele. Das typische Bild Reddit Underload. Also wenn irgendwie wieder jemand großes drauf gelingt hat oder da irgendwie was Großes passiert und dann sind die Server langsam oder es gibt irgendwie Wartungsarbeiten und es fehlt Kapazität. Ja, das ist dann auch auf irgendeine Art den Denial of Service, weil der Service dann halt nachher nicht mehr tut. Das kann man dann auch irgendwie vielleicht auch zwingen. Und dann auch noch ein ganz schönes Beispiel vom Duncan Donuts Distributed Denial of Service beim 26. Chaos Communication Congress. Als man sich noch mit Pinwänden organisiert hat bei Chaos Communication Congressen, wer es noch weiß. Und dann irgendwie hunderte Leute losgezogen sind zu Duncan Donuts und gerufen haben Donuts, Donuts, Donuts. Ja, also andere Leute haben dann auch nichts mehr gekriegt. Und die meisten, die mitgekommen sind, auch nicht. Dann muss man jetzt gucken, DDoS ist ein bisschen Sammelbegriff für viele verschiedene Dinge. Zum einen kann man unterscheiden der normale Denial of Service, wo es jetzt quasi drum geht, dass ein Angreifer versucht, eine Applikation irgendwie in die Knie zu zwingen. Also irgendwie eine Schwachstelle ausnutzt, um irgendwas zu überlasten, um irgendeinen Deadlock herzustellen. Und auf der anderen Seite den Distributed Denial of Service, wo es eben darum geht, dass man das halt mit ganz vielen Hosts von ganz vielen Quellen macht und eben das Ganze so weit hoch skaliert und einfach ganz viele Quellen nutzt, um einen größeren Angriff hinzukriegen. Das ist dann meistens ein eher, ich sag mal, dummer Angriff, wo man einfach durch große Mengen irgendeinen Service Platt kriegt. Im Prinzip ist eine Art Vandalismus. Eine andere Unterscheidung, die man dann noch machen kann, wäre jetzt so die Unterscheidung zwischen Application Layer Deadlock und einem Volumetric Deadlock. Application Layer heißt im Prinzip, ich habe irgendeine Anwendung und ich schaffe diese Anwendung in die Knie zu zwingen, indem ich irgendwas ausnutze, was da last verursacht. Also so ganz klassische Beispiele sind, es gibt irgendwo zum Beispiel ein Tickets-System mit vielen tausend Tickets und der Kollege macht eine Volltext-Suche und alle anderen müssen dann fünf Minuten warten, bis die Volltext-Suche fertig ist, weil die lockt die Datenbank oder irgend so ein Kram. Was es auch manchmal gibt, sind irgendwelche Suchfelder auf Webseiten, wo man dann auch eine Regular Expression eingeben kann als Suche und die kann man dann irgendwie ein bisschen komplexer oder rekursiver bauen und dann erzeugt es halt sehr viel Last und wenn man das halt nicht einmal macht, sondern halt irgendwie hundert Suchen, tausend Suchen, eine Million Suchen gleichzeitig laufen hat, dann sorgt es dafür, dass die Applikation auch wieder nicht erreichbar ist oder Resource Exhaustion, wo es zum Beispiel darum geht, dass man irgendeine Ressource, die da ist, zum Beispiel TCP-Ports, einfach alle aufbraucht. Das gibt es dann gerne mal bei Websourvern, wo man die Verbindungen zu dem Webserver aufmacht, gar nicht wirklich was tut, aber so ein paar Tricks macht, dass die Verbindung halt offen bleibt und wenn das Server quasi alle TCP-Ports belegt hat, dann kann der einfach keine neuen mehr allokieren und wenn dann halt eine richtige Anfrage kommt, dann kann der nicht drauf antworten. Genau. Das sind jetzt so die Applikationsachen, die interessieren uns als Netzwerker jetzt eher nicht so. Da würde man jetzt sagen, na ja, dann fix halt eine Applikation. Guck halt, dass man da irgendwie keinen komplexen Regex reintun kann oder das ist irgendwie sinnvoll skaliert. Aus Netzwerkersicht kann man da jetzt nicht so wahnsinnig viel dagegen tun. Was für uns viel interessanter ist, sind die Volumetric-Dados. Also Volumetric heißt, ich mach ganz viel Wandbreite, also entweder ganz viel Mega-Bit oder Gigabit oder Terabit oder ich mach ganz viel Packets per Second. Und es kommt dann so ein bisschen drauf an, was es bringen soll. Also Volumetric sorgt dann dafür, dass es zwischen Routern-Switches irgendwie im Netzwerk komplett überlastet sind und halt für echten legitimen Treffig nicht mehr so viel Platz da ist und viele Packets per Second belastend an Geräte, die irgendwie last beim Packet-Switchen haben oder beim Packets-Routen haben. Das heißt, die nur, also wo das Bottleneck quasi zuerst hittet, wenn man eine gewisse Anzahl Packets per Second als obere Grenze hat, dann kann man halt zum Beispiel mit vielen kleinen Netzwerkpaketen arbeiten einen schneller einen Effekt, wie mit gleich vielen großen oder weniger großen. Genau, das sind da so die Unterscheidungen. Wie gesagt, jedes ist so ein bisschen Sammelbegriff. Bei dem Volumetric geht es jetzt nicht nur darum, den Host selber zu überlasten, sondern man hat ja vor dem Host noch so ein paar andere Sachen. Ich habe das jetzt hier mal aufgemalt. Das ist auch Server oder Service, der hängt irgendwie an einem Switch. Oben dran ist ein Netzwerk, hier ist jetzt ein Netzwerk mal aus vier Routern aufgemalt und oben an den Routern da sind noch so Wölkchen, das sind jetzt zum Beispiel Internet-Provider von dem Hoster oder von dem Netzwerkbetreiber oder Peerings, also quasi andere Netze im Internet, andere Netzbetreiber. Und so ein Detox kommt halt von vielen Quellen rein. Das heißt, es kann an unterschiedlichen Routern, das heißt, ich habe nicht nur unbedingt den Service, der da unten steht überlastet, sondern ich kann auch weiter oben bis hin zum Transit oder in dem Transit-Provider-Netz ganz oben sogar Überlastsituationen haben. Und das gilt es natürlich zu vermeiden. Dann noch kurz die andere Frage. Warum gibt es Detox? Naja, weil Leute blöd sind. Also es gibt die Möglichkeit, Erpressungen irgendwie zu versuchen. Bezahlen mir Bitcoin, sonst Detox ich dein Netz weg oder so. Es gibt politisch motivierte Detox, wo man dann irgendwelche Webseiten von irgendwelchen Parteien zum Beispiel irgendwie versucht wegzukriegen oder Zeitungen oder was auch immer. Es wird auch eingesetzt um irgendwie Konkurrenten zu schaden. Also wenn wir jetzt irgendwie Firmen, Hackergruppen, whatever, hat die irgendwie in Konkurrenz zueinander stehen, dann kann man da irgendwie Spielchen spielen. Ja oder halt ich persönlich würde das jetzt irgendwie unter Dummheit zusammenfassen. Ja, jemand hat keine Lust auf Prüfungen und dann kann man ja einfach gucken, auf welchem Server die Prüfung gehostet wird, wenn es eine Online-Prüfung ist und kann irgendwie gucken, dass es ja nicht mehr geht. Genauso irgendwie, ganz klassisch gibt es das bei so Spiele-Hostern. Die haben ganz viele Probleme mit Detox. Wenn dann halt der eine versucht irgendeinen Spiel zu spielen und gewinnt nicht und dann halt irgendwie wegzureißen, auf dem er gerade verliert. Ja, also das sind so glaube ich die meisten Hintergründe. Das ist sicherlich keine erschöpfende Liste. Da gibt es sicherlich noch ganz andere Gründe. Also es hat im Prinzip eine Vielzahl von Ursachen. Aber woher kommt so was in der Praxis? Ja, woher kommt so was in der Praxis? Am Ende vom Tag muss man sich glaube ich als erstes die Frage stellen make or buy. Bei dem meisten, was man so im Internet sieht, gibt es sogenannte Stresserservices. Das kann man sich super günstig einkaufen. Also grob 100 G kosten 100 Euro am Tag an Traffic und für die meisten kleinen Provider ist das eigentlich schon genug. Und das passiert leider sehr häufig, dass irgendwelche Kiddies ein paar Bitcoins gefunden haben irgendwo im Internet und das dann nutzen, um den Teamspeak-Server von dem anderen Clan wegzubeusen oder so. Die Slide ist jetzt vielleicht in dem Sinne ihr Marketing für irgendwelche Leute, was ich damit eigentlich zeigen möchte, ist, dass es unglaublich billig ist, so ein DDoS zu kaufen und damit dementsprechend man sich auf jeden Fall vorbereiten sollte, wenn man ein Netz betreibt oder ein Dienst betreibt. Weil 100 Gigabit Traffic wegmachen können hier glaube ich im Raum wenige behaupte ich jetzt einfach mal. Aber kaufen kann es hier jeder für ein Uni. Und wenn eure Website euer Netz für einen Tag weg ist, für 100 Euro tut richtig weh. Falls ihr euch überlegt eure Gamer Buddies den Teamspeak wegzuschießen, dann sei vielleicht noch gesagt Vorsicht, das sind alles Kriminelle und unter Kriminellen gibt es keine Ehre. Dementsprechend ist auch unglaublich viel Scam unterwegs. Es gab mal eine relativ große Research dazu, wie viele von denen eigentlich liefern oder das liefern, was sie können. Ja, also die schönen Fans, die zahlen, sind leider auch dann nicht mal in dieser Branche das, was sie versprechen, insofern. Vorsicht beim DDoS-Kauf. Aber gut. Wie entsteht jetzt mein DDoS? Option 1 ist natürlich, wir gehen her, knacken uns eine Großzahl von Systemen. Ich glaube, jeder kennt das irgendein verwundbares Linux, irgendein Windows-System im Internet. Die Glühbirne macht am DDoS mit die smarte IP-Kamera oder eben die schlechte Netzwerk-Hardware. Ich möchte jetzt hier niemand direkt anschauen. Aber die Mitigation von so was ist einfacher. Also die Komplexität hinter diesem Angriff geht oder die Mitigation geht eigentlich darin, die Systeme, die mich jetzt gerade angreifen, zu identifizieren. Und dann blackhole ich die halt und gucke, dass sie mir keinen Traffic mehr schicken können. Das ist also einfacher. Misty Slide wollte ich löschen. Naja. Nun ja, also Option 2, wie geht das schwieriger? Ich habe euch mal ein kleines Netz mitgebracht und wir machen das jetzt am Beispiel NTP. NTP-DDoS-Monlist hat vielleicht der ein oder andere Systeme im Raum schon mal gehört. Wer hat das gehört? Okay, relativ wenige. Dann lernt ihr was, sehr schön. Gibt es aber auch andere verwundbare Systeme, Memcash, die gab es vor längerem eine Sicherheitslücke, die hat richtig weh getan. Klassisch kann man das auch mit DNS-Zonen-Transfer machen. Aber um an diesen Punkt zu kommen, wie man diese Attacke macht, braucht man ein paar Vorbereitungen. Zum einen müssen wir trotzdem irgendeinen System haben in einem Netz. Dann ist es nicht irgendwie das, dass wir das mit unserer Einenkreditkarte kaufen, weil das kommt dann irgendwann auch wieder raus. Und dann brauchen wir ganz wichtig einen Internet-Service-Provider. Und der werden wir gleich sehen, macht leider auch alles nicht richtig. Aber er macht es nicht richtig, weil er daran Spaß hat, sondern aufgrund von Unwissen. Genau, dann haben wir noch ein NTP-Service im Internet. Der macht auch nicht alles richtig. Der hat Monlist aktiv. Das ist ein kleines, liebes, unschuldiges Einhorn. Das ist unser Webserver. Und der möchte eigentlich nur ganz viel Liebe über harte TP verteilen. Aber irgendjemand hat da was dagegen. Nun, greifen wir an. Wir sind der Angreifer und wir bauen uns ein UDP-Paket. Wir nehmen UDP, da haben wir keine Handshakes, da müssen wir nichts für können. Wir müssen einfach nur ein Paket irgendwo hinschicken. Und da muss nicht irgendwie erst ein Session aufgebaut werden, bevor wir Mengen an payload schicken können. Das ist unser NTP-Server, den wir vorhin hatten. Und wir fragen den in seiner payload nach dem Monlist-Befahrer. IP-Härter und UDP-Härter und sonst, was wir eigentlich relativ unverändert. Das können wir einfach mal nur hin. Aber jedenfalls, wir schicken diesen NTP-Mon-Getlist-Befahrer an diesen NTP-Server. Aber unser Paket, wir sind ja ein böser Hacker und unser Paket ist etwas verändert. Deswegen schicken wir das nicht mit der Source-IP unseres kleines niedlichen Einhorns. Das heißt, die Source-IP, Einhorn, Destination-IP, NTP-Server. Okay, wir schicken unser Paket auf die Reise zu dem Router des Internet-Service-Provides. Ein Router per See hat eigentlich nur den Job, das Paket zuzustellen. Dementsprechend, schaut er gar nicht erst auf den Absender, der ist ihm erst mal egal, sondern er schaut nur auf den Empfänger und das Paket geht an unseren NTP-Server. Der Atmen von unserem NTP-Server kann nicht vergessen, Mon-List auszumachen. Also antwortet er. Vielleicht für die, die nicht wissen, was Mon-List ist. Mon-List ist im Endeffekt ein Befehl, den ich an einen NTP-Server schicken kann und der schickt mir dann eine Liste an allen Kleins zurück, die ihn in letzter Zeit angefragt haben. Dementsprechend geht unser NTP-Server her und baut das Paket so gut, er kann. Er schickt es allerdings nicht an den NTP-Server zurück, sondern er hat aus der Source-Adresse gelernt, dass das Paket an unser Einhorn zugestellt werden soll. Dementsprechend antworten wir mit der Mon-List, eine IP-Adresse hier in dem Beispiel von einem Klein, der da angefragt hat vorhin und schicken das zurück an unser Einhorn. Das Problem an der Geschichte ist, dass ein Mon-List-Item hier 72 beitrat. Aber unseren Server, der steht im Internet, das ist ein öffentlicher NTP-Server, den hat ja nicht nur einer gefragt, sondern haben Tausende oder vielleicht sogar Millionen gefragt, weil er am NTP-Pool mitmacht. Dementsprechend antworten wir auch nicht nur mit einer IP-Adresse, sondern mit einer riesigen Mon-List. Und dadurch wird natürlich unser Paket auch deutlich größer. Jetzt muss man vielleicht wissen, im Internet hat so ein Paket normalerweise eine MTU von 1500, das heißt, das Paket ist 1500 Byte groß, abzüglich ein paar Headers, also gar nicht so schlimm. Aber der NTP-Server möchte alles richtig machen und der ihn nach der Mon-List gefragt hat, richtig beantworten. Deswegen schicken wir viele Pakete und halt eben ganz normale fragmentierte Pakete. Die gehen den Weg über das Internet. Das Internet weiß ja nichts davon, dass die IP-Adresse gespucht wurde. Und im Endeffekt kommt dann das NTP zu unserem kleinen Einhorn. Das hat viele Pakete auf einmal, was eben dieses Packet per second Problem ist, das neuner Freund erwähnt hatte. Es hat große Pakete und die IP-Adresse ist nirgends aufgetaucht in unserem Paket. Und wenn man das jetzt nicht nur mit einer Maschine hier macht, sondern man hat eben tausende Glühbirne, die Pakete schicken können, in tausenden beschissenen Netzen, dann kommt auf einmal viel Spufbraber-Traffik dazu und das tut richtig weh. Zum Vergleich, dieses NTP-Mon-List-Paket hat irgendwie auch so eine Größe von grob 100 Byte, ich habe es jetzt gerade nicht im Kopf und die Amplification wird eben aus diesem einen Paket 9000 Pakete. Beim M-Cache die ist das noch viel schlimmer, das ist so eine Amplification von 1 zu 20.000. Und das ist eigentlich aktuell die größte Schmachstelle im Internet, dass wir eben Netze haben, deren Provider Spoofing erlauben oder es eben nicht aktiv ausgemacht haben und dann eben verwundbare Services, die für Amplification genutzt werden können. Und so können wir Pakete zustellen, uns dahinter verstecken und wir machen nicht mal die Drecksarbeit, die auffallen würde, wenn wir jetzt hier eben Gigabitweise traffic schicken, sondern das machen die NTP-Server für uns, sondern eben irgendwelche ahnungslosen Hoste. Ja, dann ist natürlich jetzt die Frage, okay, wir haben ein DOS, wir müssen den irgendwie erkennen. Meistens geht es irgendwie so los, Slack bimmelt, mist, die GPN-Webseite ist down, außerdem ist dazu gleichzeitig noch unser Backend, hat irgendwie eine 100 CPU Load, dann meckert das Netz noch irgendwie rum. Es kommen also eine unglaubliche Menge an Alarm rein, weil während so einem Angriff extrem viel los ist. Und ja, als erstes, wenn so was passiert, ich habe es euch auf der GPN 19 erzählt, ist natürlich, wir starten uns ein Inzidenprozess und schauen in unserem Monitoring nach, wer das noch mal nachlesen möchte, bitte auf media.cc.de. Sobald man sich dann die Monitoring-Daten anschaut, läuft es ungefähr so. Das Netz ist überlastet, das merken wir relativ schnell, es ist irgendwie ein DEROS, dann wackelt auch das ganze Netz irgendwie und es ist haaruckelt und irgendwann geht gar nichts mehr. Und dann wollen wir irgendwie rausfinden, wer es jetzt eigentlich war. Und das erzählt euch noch nicht, wie es geht. Genau. So, also wir gucken jetzt erstmal, kommen wir überhaupt noch auf den Server drauf, der irgendwie angegriffen wird, also vorausgesetzt, wir haben einen Alert, wo drin steht, es geht um den Server und wir haben nicht einen Alert, wo drin steht, es geht um das ganze Netz. Dann kann man sich da einloggen vielleicht und kann irgendwie so ein paar Tools benutzen, IP Top, IP Treff, kann gucken, was ist da los, wo kommt mein Traffic her, was ist es für Traffic, was soll der da, ist es überhaupt was Bösartiges oder ist irgendwie tatsächlich einfach nur ein Server-Problem. Wenn ich das noch machen kann, vielleicht ein TCP-Dump immer mit Minus-NN benutzen, sonst fängt es noch an, DNS-Request zu machen und alles wird schlimmer. Wenn man TCP-Dump irgendwie ankriegt, noch gleich ein PCAP-File wegspeichern, wo irgendwie so ein paar Pakete zu ein paar Pakete drin sind, wo man das noch gucken kann, wird später nochmal wichtig. Aber wenn TCP-Dump tut, Paket Capture machen, hilft später. Wenn ich nicht mehr auf den Server kommen, dann kann ich vielleicht dem Netz davor noch irgendwie gucken. Also es gibt zum Beispiel Netzwerk-Hardware, die hat ACLs, das sind quasi kleine Fireballs auf dem Port. Und da kann ich Counter haben und dann kann ich so etwas sagen, wie irgendeine Fireball-Regel da drin erlaubt irgendwelchen Treffig oder verwirft irgendwelchen Treffig und sagen, ich habe eine Regel, die mir irgendwie UDP wegfiltert und kann dann gucken, okay, kommt da ganz viel UDP, kann damit ein bisschen arbeiten. Es ist alles ein bisschen unhandlich, ein bisschen handlicher, aber eigentlich immer noch unhandlich wäre es, wenn ich jetzt sage, ich gucke meine Netzwerk-Monitoring-Software an, ich habe vielleicht eine Weathermap von meinem Netzwerk und kann da gucken und da gibt es eine dicke rote Linie, wo geht die hin? Oder ich kann einfach so wie jetzt hier kurz angucken und nachverfolgen, wo geht das hin und wo kommt es her und kann halt einfach so ein bisschen Insight gewinnen, weil solange ich nicht weiß, was angegriffen wird und wie es angegriffen wird, kann ich natürlich auch nichts dagegen tun. Das wird schwierig. Wie gesagt, das ist alles ein bisschen manueller Prozess und unhandlich und will man eigentlich nicht machen im Notfall, weil dauert natürlich dann auch seine Zeit viel besser Flow-Daten. Switcher und Router können Flow-Daten sammeln und ich halt viel mehr Infos über was im Netz gerade passiert. Was sind Flow-Daten? Es gibt verschiedene Geschmacksrichtungen davon. S-Flow, J-Flow, NetFlow, IP-Fix sind so die gängigen Beispiele und die Idee dabei ist, ich habe das auf einem Router oder Switch-Port konfiguriert und alle Pakete, die da durchgehen, werden gesampelt, das heißt, ich nehme dann zum Beispiel jedes Tausend Stück Paket raus. Klingt jetzt nach wenig, aber wenn so ein Angriff läuft also 1.000-2.000 immer noch sehr viele und dann gucke ich mir die Header an, nur die Header, anstrengend genug für den Router nehmen die IP-Source und Destination-Adressen raus, ich gucke mir die Ports an und die Protokoll-Nummer also zum Beispiel TCP, UDP, ICMP und zum Teil wird dann auch noch Flows aggregiert, im Fall von NetFlow zum Beispiel und dann schicke ich diese Flow-Information an einen zentralen Server. Auf dem Server habe ich dann irgendwelche Auswertesoftware laufen, die sich die ganzen Flow-Daten anguckt, da muss man dann immer gucken, wie es mit dem Datenschutz lässt man das nur in Memory laufen oder schreibt man das auf die Platte und hat irgendwie 2 Stunden History oder eine ganze Woche History oder so, das muss man dann immer jeweils für den Einzelfall klären. Aber da läuft dann irgendeine Software, die mir das auswertet. Bekannte Beispiele sind zum Beispiel NF-Send, Elastiflow, Fastnetmon oder Flow-Pipeline da kann ich mir dann zum Beispiel Builder plotten lassen, also wenn ich zum Beispiel weiß, es geht um einen bestimmten Server, kann ich schon mal sagen zeig mir die Flow-Daten für diese Ziel-IP-Adresse und kann damit halt ein bisschen mehr auswerten. Ziel wäre es dann jetzt die Top-Talker zu identifizieren, also wohin geht das DDoS oder wenn ich schon weiß, kann ich dann direkt den Top-Talker angucken und kann gucken, was ist für eine Art von Traffic. Ich muss gucken, ist der Traffic legitim oder ist es ein DDoS, also es kann natürlich auch immer passieren, dass irgendwie Alerts anschlagen und eigentlich wollten nur jemanden Backup machen und das Backup macht die Leitung voll. Also false positives sind ein Ding und es geht mir halt darum, einfach Insights zu gewinnen auch was ist der gute Traffic, also wenn ich nachher irgendwie eine Mitigation machen will, wenn ich den DDoS irgendwie abwehren will, dann muss ich natürlich auch wissen, was für ein Service läuft, was tut der, was soll nachher noch funktionieren, wo muss ich aufpassen. Disclaimer, NetFlow ist so ein bisschen drinking from the hose, also wenn das ein Angriff mit million packets per second läuft und ich habe irgendwie 100 Interfaces wo das durchgeht, dann kommt irgendwie echt viel an Flowdaten an und es kommt natürlich auch noch der ganze andere Kram der okay ist an, das heißt so Server, der sowas auswertet, der braucht dann auch schon ein bisschen Power und ich muss dann halt auch irgendwie gut filtern, was ich damit mache und ich kann dann auch nicht irgendwie ein Jahr lang Datenspeichern war, sonst brauche ich irgendwie ein eigenes Rechenzentrum für die Flowdaten. Außer ich aggregiere die entsprechend und so weiter. Ja, was macht man damit? Wie gesagt, es gibt verschiedene Tools, die einem das anzeigen, die einem da irgendwie Insights geben und es gibt auch Tools, die automatisch Anomalien erkennen. So ein Open Source Tool, ich habe es gerade schon genannt, ist Fastnetmon, da kann man dann zum Beispiel sagen, ich habe da eine Farm von Web Servern mit diesem Prefix und die machen HTTPS, das heißt wenn da jetzt irgendwie mehr als 100 Mbit NTP reinkommt, dann ist definitiv irgendwas falsch und dann kommt ein Alert und dann habe ich irgendwie eine Anomalie erkannt. Und es gibt natürlich auch noch einen Haufen kommerzielle Produkte, die sowas tun, die dann irgendwie auch Smart, Self-Learning, AI, whatnot alles machen. Wollten wir aber wie gesagt nicht drauf eingehen. Es gibt auch Feeds von bekannten Angriffsmustern. Auch da gibt es wieder freie und kommerzielle Quellen, die ich mir dann da rein tun kann und das Alerts bauen kann. Es gibt ein paar Probleme dabei. Zum Beispiel, wo fängt Anomalie an? Also zum Beispiel ich habe eine Web Server Farm, die macht irgendwie so ein Tagesmittel, immer so 10 Gigabit. Jetzt macht die irgendwie mal 12 Gigabit. Ist das schon eine Anomalie? Ist das schon irgendwas komisch? Muss man da schon gucken? Wahrscheinlich nicht. Dann habe ich da plötzlich irgendwie ein FTP Transfer. Ist das eine Anomalie? Macht da jemand Backups? Man weiß es nicht. Wenn ich eine Anomalie gefunden habe, ist die Anomalie überhaupt böse? Es könnte ja zum Beispiel sein, dass es irgendwie ein neues Release von irgendeinem Spiel gibt, dass ein Champions League Spiel läuft und plötzlich da irgendwie ganz viel Video Streaming im Netzwerk passiert. Also es kann ja durchaus Anomalien geben, die irgendwie gutartig sind, sag ich mal. Und so Anomalie-Detection von kommerziellen Herstellern, die kriegt dann da gleich mal Panik und dann muss man halt von Hand nochmal gucken, was passiert da jetzt? Will ich das wirklich weggefiltert haben? Hängt aber auch ein bisschen davon ab, ob der Traffic jetzt irgendwo hingeht, wo ich weiß, was da passiert. Also wenn es eine Web-Sauberfarm ist, dann kann ich relativ klar sagen, da muss kein Gigabit-NTP-Traffic ankommen. Wenn es jetzt aber ein Internetanschluss von einem Kunden ist, dann kann ich vielleicht nicht so genau sagen, was macht der Kunde da eigentlich und sieht das legitim aus? In Zweifelsfall muss ich den anrufen und fragen. Dann geht das ganz gut. Und wenn ich dann so eine Anomalie erkannt habe und das schlecht aussieht, dann kann ich auch damit mit diesen Informationen automatisch Mitigation triggern. Also ich kann dann irgendwie ein Skript schreiben, das man dann quasi sagt. Wenn die DDoS-Anomalie erkannt wird, also wenn der NTP-Anomalie erkannt wird, dann läuft eben skriptlos das irgendeine Art von Mitigation nachher triggert. Genau, hier nochmal so ein Beispiel. Ein letztes Wort zur Anomalie-Erkennung. Das ist ein Bild von einem Transit-Provider-Anschluss. Da dümpelt irgendwie so eine Woche lang ganz wenig Traffic rum und dann sind da plötzlich 54 Gigabit drauf. Und das ist Legitima-Traffic. Das ist kein DDoS-Angriff. Das hat möglicherweise was mit einem Teilchenbeschleuniger in der Schweiz zu tun. Aber das ist Legitima-Traffic. Aber was würde ich jetzt so nehmen? So eine AI, so eine automatische Self-Learning, irgendwas Erkennung damit tun? Also die werde wahrscheinlich ein bisschen irritiert von. Das heißt, man muss halt gucken, in welchem Szenario setze ich das ein. In manchen Szenarien funktioniert das sehr gut. In manchen Szenarien muss ich wirklich aufpassen, was ich da tue. Genau. Und wenn ich jetzt so eine automatische Anomalie-Erkennung habe und ich weiß, die sind volle Dinge, die ich ordentlich konfiguriert, kann ich dann halt sagen, ich mitigiere es jetzt automatisiert. Genau. Und das bringt uns ja eigentlich zu der Frage, wie man eigentlich so ein DDoS mitigiert. Ich fange jetzt gleich mal relativ einfach an und wir werden dann immer Stückchen für Stückchen fortgeschritten. Ich glaube, das Wichtige an der Geschichte, die wir jetzt in den nächsten 10 Minuten oder so erzählen ist, dass das nicht die Patentlösung ist, sondern die Lösung ist Teile davon richtig einsetzen und dann, wer greift denn eigentlich an? Kommen das, kommen vielleicht 80% des Traffics von einer Handvoll Hosts? Mitigation relativ einfach, ich mach die Handvoll Hosts aus. Dann vielleicht, wie Neuner schon sagte, welches Service wird angegriffen? Wenn ich ein Web-Server betreibe und da gerade hunderte megabit oder Gigabit an DNS-Traffic oder NTP-Traffic draufkomme, dann kann ich die einfach dropen. Das macht es mir viel einfacher, das Zeug zu mitigieren, um solche automatischen Regeln zu deployen. Meistens hilft es einfach noch mal, wenn man damit gesundem Verstand und gesundem Verständnis von diesem Netz sich überlegt, was hier gerade eigentlich passiert. Aber wie gesagt, unser Ziel ist es, jetzt ein paar Methoden vorzustellen und ihr schaut euch dann an, was für euch die beste Methode ist. Das Einfachste ist natürlich Black Hole, Nullroute setzen, wie auch immer man es nennen möchte, manche nennens Diskartroute. Das kommt darauf an, wir gehen entweder her und Nullroute natürlich den Angreifer. Oder wenn wir den Angreifer nicht kennen, aber wir jetzt gerade einen Web-Server weggeschossen kriegen, aber noch 100 anderen nebenan zu betreiben haben, dann schießen wir halt diesen einen Web-Server selber weg. Dann ist der zwar offline, aber hoffentlich lebt der Rest vom Netz. Meistens in unserem Provider-Geschäft geht es darum, 99% der Kunden glücklich zu machen bei solchen DDoS-Angriffen und wenn es den einen erwischt, dann ist das im Zweifel das leichtere Opfer. Natürlich möchte man idealerweise 100% schützen, aber das geht nicht immer. Also diese Nullroute, Diskartroute, dieses Black Hole installieren wir jetzt eben auf unserem, wir nennen sowas meistens Internet-Edge, also auf den Routern, die ganz nah am Internet hängen, weil dann muss der Traffic eben nicht durchs ganze Netz, sondern wird zu früh wie möglich weggeschmissen. Hat natürlich Vorteile, das ist super einfach und super schnell, insbesondere wenn man dafür nicht das von Hand macht und auf dem Router irgendwie sagt, hier diese Diskartroute, das muss man dann auf jedem Router von Hand machen, sondern idealerweise kann man sowas über BGP signalisieren, ihr werdet es heute noch häufiger hören, wir als Netzwerke finden BGP super und würden gerne am liebsten alles darüber signalisieren, auch, dass wir Hunger haben oder Bier brauchen. Nun, Contra ist natürlich, das Ganze ist ziemlich näher. Weiteres Contra, wenn der Angreif, also wenn ich jetzt hier keine Ahnung, 100 Gigabit Ablink-Kapazität hab und der Angreifer mehr, bin ich trotzdem aus, weil es kommt ja alles an meinem Internet-Edge an und ich kann nicht mehr Bandbreite herzaubern. Dementsprechend ist es limitiert. Außerdem können Typos bei der Geschichte extrem schnell, extrem wehtun, wer ein Slash, schon mal ein Slash 30 statt einem Slash 32 gelten beruhtet hat, weiß wie schmerzhaft das wird. Also passt da auf und idealerweise baut euch auch bei sowas Sicherheitsmechanismen ein. Gut, aber was, wenn wir nicht genug Bandbreite haben und der Angreifer uns jetzt hier eben mit 400, 400, 500 oder 700 Gigabit oder sogar im Terra bedrehen knallt. Dann haben wir immer noch unsere Transit-Provider. Mit denen sprechen wir, er hätte jetzt nicht gedacht, BGP. Und da gibt es eine Technik, die nennt sich RTBH, Remotely Triggered Black Hole. Damit installiert sich dann auch euer Transit-Provider eben diese Null-Route in seinem gesamten Netz und schmeißt den Traffic ein, zweiter oben weg. Und idealerweise hat euer Transit-Provider hoffentlich mehr Bandbreite als ihr selber sonst würde ich diese Wahl des Transit-Providers vielleicht nochmal überdenken. Und idealerweise gibt auch der Transit-Provider also euer Transit-Provider gibt die dann auch an seine Transit-Provider weiter, sodass quasi das ganze Internet in der Zukunft hoffentlich diesen Traffic zu euch droppt. Wer sowas mal sehen möchte, von jedem Transit-Provider kriegt man im Endeffekt so ein PDF oder es gibt eine Webseite wo die ganzen Communities draufstehen. Hier jetzt bei der Deutschen Telekom, die haben eine wirklich ausgezeichnete Dokumentation schicken wir eben hier die BGP-Community 65.000 Doppel.0 mit einer Slash 32-Route oder eben Slash 128 bei IPv6 und dann gehen die her und Blackholen das. Ist natürlich super. Es ist im Endeffekt das Gleiche wie diese Null-Route die wir vorhin hatten, nur mehr Bandbreite als wir selber haben. Kontra ist, das kann nicht jeder Transit falls eure das nicht kann, kündigen. Wenn der Geld dafür will kündigen weil das kostet nix und es ist eine Frechheit für sowas Geld zu verlangen meines Erachtens und sowas braucht Vorbereitung. Sowas fangt ihr nicht mal an wenn ihr jetzt gerade angegriffen werdet sondern überlegt euch sowas im Vorfeld. Dementsprechend auch nachschauen exakt was der Provider da will zum Beispiel bei der Telekom steht hier auch schön drin Requires Authorization from Holder of Adress Space d.h. da müsst ihr vielleicht entsprechend der Objekte anlegen. Lest es vorher, sprecht mit euren Provider nehmt es auch insbesondere in euren Provider Auswahl mit wenn ihr sowas macht. Gut aber es ist immer noch ausmachen. Dementsprechend versuchen wir das mal vielleicht nicht ganz subinär zu lösen und den Service am Laufen zu lassen. Dazu darf der neuen Arbeiter machen. Ja, ich glaube wir müssen ein bisschen Gas geben damit nachher noch schön Zeit für Q&A ist. Ja, also alles weggetraubt ist natürlich blöd für den Kunden oder den Service oder wie auch immer d.h. im besten Fall versuchen wir das irgendwie so hinzukriegen dass der schlechte Traffic der DDoS gedraubt wird und die Servicezugriffe quasi weiterhin durchkommen. Ganz klar schon angesprochenen Webserver braucht nicht unbedingt NTP von außen, manche Dienststellen müssen überhaupt gar nicht von außen erreichbar sein da wäre dann die Frage warum habe ich überhaupt irgendwie die Firewall von außen offen macht Sinn für manche Dienststellen eine ACL oder eine Firewall sehr weit vorn im Netz zu haben dass der Traffic gar nicht bis dahin kommt oder ich benutze sogar Rate Limits die statisch konfiguriert sind kein Server braucht mehr als 10 mbit DNS außer es ist vielleicht irgendwie eine ganz große DNS Resolver oder so zum Teil können Router schon die Rate Limits das heißt das muss ich nicht mal unbedingt auf dem Server machen sondern ich kann das auf dem Router vorne dran machen das quasi ein bisschen mehr im Netz verteilen und der Rest der dann auch übrig bleibt den könnte ich dann zum Beispiel auf dem Server jetzt machen also ja im Zweifel halt eine Art von IP Tables Firewall oder was auch immer ich dann einsetze um das noch ein bisschen fein granularer zu filtern Vorteil der Service kann wenn man das schlau macht wenn man das schlau hinkriegt irgendwie weiterlaufen Nachteil das ganz spät am Host fein granular zu filtern kann natürlich schwierig sein wenn der DDoS so groß ist dass das ganze Netz der Forschung überlastet wird das heißt am Host zu filtern ist dann schon zu spät das ganze ist auch relativ langsam im Zweifels Firewall also wenn ich jetzt erst mal gucken muss was ist genau der Angriffstreffig wie muss die Firewall-Regel dafür aussehen das ist alles viel manuelle Arbeit das ist aufwendig vielleicht kompliziert vielleicht muss man noch den RFC lesen wie DNS funktioniert um das richtig auseinander deswegen gibt es Flow-Spec genau kurze Frage in Raum wer hier weiß was Flow-Spec ist 3, 4, ok cool, dann lernen wir jetzt was also wie ihr schon erwähnt Flow-Spec, wir Netzwerke möchten alles mit BGP signalisieren deswegen Firewall aber über BGP im Endeffekt sieht das so aus BGP ist nicht nur dazu da um Routen auszutauschen es ist nicht Multi-Protocol-BGP und wir können da drin alles mögliche machen wir können Mac-Adressen über BGP verteilen was davor so ein Up gemacht hätte oder eben auch Firewall-Filter im vereinfachten Sinne das sieht dann so aus wir gehen im Endeffekt her wir haben das jetzt mal auf dem GPN-Router gemacht in der Vorbereitung des Talks die Regel ist nicht mehr drin ihr könnt den NTP so mit mehr als 100mbit erreichen im Endeffekt gehen wir her und legen uns eine Route an und dann auf UDP Port 1.2.3, also NTP schreiben noch eine Source rein in dem Fall jetzt der NTP-Service des Bellevue und dann Rate-Limiten wir den dann passiert in dem Router was ganz nettes er installiert diese Route in Hardware das heißt die ganzen Pakete der Reihen kommen müssen nicht erst irgendwie zur CPU der Rechnung muss sich überlegen ist das jetzt gut oder schlecht sondern das passiert alles in Hardware die gleiche Menge an Bandbreite die wir mitigieren können wie auch unser Router an angeschlossener Bandbreite hat oder falls der Router eben nicht in Line Rate funktioniert dann die entsprechenden Limits und das Schöne ist dann diese Route ist nicht nur auf dem Router selber sondern die wird durchs ganze Netz per BGP verteilt und somit installieren automatisch ab dem Zeitpunkt wo diese Route in Injected wurde das ganze Netz diese Firewall-Regel es ist super schnell, super performant und es kann halt auch von programmatischen BGP-Speakers Injected werden also wenn zum Beispiel die Flow Anomolierkönnung die der neuner Fallen erwählt hat erkennt da ist irgendwas blöd und wir haben sie richtig eingestellt dann kann die direkt hergehen einen Exa-BGPD oder Go-BGPD nehmen und entsprechend direkt schon diese Flow-Regel reinhauen und dann mitigiert man Netz von ganz selber seinen Delos das ganze hilft aber auch wie vorhin nur wenn wir genug Edge-Kapazität haben also wir können eben hier diese Flow-Spec-Regel meistens nicht an Transit-Provider weitergeben das ist gerade so in der Mache dass es den einen oder anderen gibt der Flow-Spec mit euch spricht aber da wiederum gibt es glaube ich gerade wirklich kein einen der es tut und das ganze geht halt auch nur wieder bis Layer 4 also über den Port hinaus werden wir nicht kommen dementsprechend müssen wir irgendwie auf Layer 5 bis Layer 7 weitermachen ja ein guter Delos sieht aus wie legitimer Treffig man sieht das manchmal wenn Hosts angegriffen werden ganz dumme NTP-Amplification-Attacke die ist super schnell weggefeuert oder vielleicht sogar schon von Anfang an kommt gar nicht durch und dann wenn es einen Angreifer wirklich wissen will dann wird das manchmal so über die Zeit, über Tage immer so ein bisschen besser und irgendwann sieht dann der gute Delos-Angriff so ein bisschen aus wie User-Traffig also bei einem Webster aber dann vielleicht tatsächlich HTTPS-Requests auf irgendeine URL und es wird halt irgendwann echt schwer das von legitimem Treffig zu unterscheiden auf dem Router habe ich dann keine Chance mehr das gute ist so ein gut gemachter Delos, der irgendwie komplex ist und der aussieht wie User-Traffig den kann ich nicht mehr irgendwie mit Amplifications machen sondern der hat dann in der Regel ein kleineres Volumen und dann muss ich es vielleicht auch gar nicht mehr auf dem Router machen, sondern ich brauche einfach ein Host der genug Bandbreite hat, der das dann hinkriegt das heißt für den Beauftrager, für den Ursprung des Delos wird das alles ein bisschen teurer und aufwendiger und man kann das in der Regel auch nicht mehr so einfach reinkaufen, also ein bisschen unterschiedlich, also zumindest wird es teurer die Unterscheidung, was jetzt gut und böse ist muss deswegen aber im Application-Lehrer stattfinden das heißt, bei HTTPS gucke ich dann irgendwie in den User-Agent, ich muss mir Header angucken, ich muss mir irgendwelche Flex und so Sachen angucken was man auch machen kann ist das klassische Fail-to-Band kennt vielleicht der eine oder andere von SSH wo man dann sagt irgendeinen Klein, der sich dreimal versucht hat einzulocken und es nicht geschafft hat der kommt dann taglang auf die Spalliste oder sowas, so Sachen kann man machen und letztendlich kann man auch versuchen, bekannte Angriffsmuster aus irgendwelchen Quellen sich anzugucken und zu gucken, ob das hier zutrifft oder muss da selber finden da kommt wieder das P-CAP-File ins Spiel, das wir am Anfang gezogen haben ich gucke mir dann quasi die Pakete an und gucke ob es irgendwelche Gemeinsamkeiten gibt das ist auch wieder ein manueller Prozess das kann aufwendig sein es kann das Problem lösen also wenn ich es geschafft habe irgendeinen Pattern zu finden und dann mit einer Firewall-Regel sagen kann den ganzen Mist kannst du wegschmeißen und der gute Treffi kommt noch durch, habe ich gewonnen aber wie gesagt ist kompliziert, ist aufwendig und geht nur, wenn dann tatsächlich da wo ich die Firewall-Regel setzen kann, auch genug Kapazität da ist das heißt im Zweifel will ich es vielleicht noch ein bisschen kombinieren mit einem Rate-Limit oder so das sind so die Optionen ein Beispiel dazu wir können uns jetzt überlegen so eine UDP-Flat also zum Beispiel das ist so ähnlich wie das NTP-Modlist wenn jemand einen Zonentransfer zum Beispiel anfragt bei einem DNS-Server dann gibt es einen endlichen Prozess dann kommen ganz viele UDP-Pakete zum Beispiel sagen wir jetzt hier mal zu einem DNS-Server und dann gucken wir uns das an gucken mal in das P-CAP rein und stellen fest da sind ganz viele Queries das sind irgendwie große, oder nicht nur die Queries aber da sind ganz viele große UDP-DNS-Pakete und wenn man sich ein bisschen auskennt dann stellt man fest, okay DNS-Queries sind normalerweise eher klein und dürfen laut Standard auch irgendwie nur so 300 Byte groß sein also da gibt es irgendwie so Limits da kommen aber ganz viele große Pakete und dann könnten wir jetzt schon mal sagen wir nehmen eine IP-Tables-Regel filtern auf eine bestimmte Paketgröße und schmeißen die großen Pakete alle weg und damit haben wir schon extrem viel gewonnen kann natürlich immer sein da muss man jetzt Hand Service genau kennen dass es da ein bisschen Kollateralschaden gibt aber das gibt es bei einem DDoS so oder so aber vielleicht habe ich damit schon sehr viel gewonnen wenn ich jetzt ins Wire-Shark ein bisschen mehr reinguck dann muss ich vielleicht eine Weile stöbern finde ich vielleicht noch mehr Pattern also häufig sind in so Angriffen Magik-Numbers hardcoded also da gibt es ein Skript, da ist ein Template drin wie das Paket aussehen muss und da sind irgendwelche Query-IDs Transaction-IDs, UALs und dann gibt es so tolle Sachen so tolle abgefahrene Sachen wie das IP-Tables-U32-Module wo man irgendwie so irgendwo im Paket sagen kann dieses Byte muss aber irgendwie 1,3 also 0x1,3 und das andere Byte muss 0x3,7 sein und dann kann man quasi auf diese hardcoded Magik-Numbers, wenn man welche gefunden hat, matchen und kann den Kram dann auch noch rausfiltern, also das ist jetzt dann so die Königsklasse von man hat wirklich alles getan und hat dann wirklich irgendwie die letzten Reste auch noch rausgekriegt ich habe ja noch geschrieben Netzwerkschirurgie am lebenden Objekt da muss man sich dann auch wirklich hinsetzen und die Pakete angucken und so Pattern finden das ganze gibt es auch als fertige proprietäre Firewall, fertig zu kaufen das ist quasi das gleiche in hat schon jemand für dich gemacht die Kosten die dabei entstehen sind in der Regel für das Knowledge über die Regeln die da drin stecken, das heißt die Hardware Server schmeißt es gar nicht so besonders aber die Regeln sind halt das was kostet die wird in der Regel einmal dimensioniert für sagen wir mal ein Servernetz stellt dann die Firewall vor das Servernetz und die ja filtert dann alles weg ist häufig einfach hübsch angemalt die Commodity Hardware und könnte man im Prinzip auch selber machen, aber man müsste halt die ganzen Regeln kennen, das heißt wenn ich mir so ein Ding hinstelle das ist super einfach, das ist gar kein Stress enthält ganz viel tolle Magie die häufig die richtigen Dinge tut manchmal nicht in 90% wahrscheinlich schon Problem ist diese Dinge werden in der Regel in ihrem Eigengewicht in Gold aufgewogen das heißt das ist normalerweise richtig schmerzhaft sich so ein Ding irgendwo in entsprechender Kapazität hinzustellen und die braucht dann natürlich auch die Kapazität weil das muss ja den kompletten DDoS ingressen können damit das irgendwie auch alle Pakete wirklich die gut sind nachher wieder rauslassen kann genau im Endeffekt wird es jetzt noch teurer per Flow-Spec können wir nicht nur irgendwelche Regel machen, sondern wir können per Flow-Spec auch den Next-Hop modifizieren das heißt, es kommt ein Paket quasi rein und wir setzen den Next-Hop auf unsere justylistisch dargestellte Waschmaschine und dann setzen wir uns quasi einfach dazwischen und leiten allen Traffic durch, das mache ich natürlich nicht wenn ich so eine Firewall hab, wie der 9er grad eben erwähnt hat aber vielleicht bin ich Internet Service Provider und kann nicht für jeden von meinen Kunden so eine Firewall stellen die macht dann auch hier ganz viel Magie für ganz viel Geld so als grobe Daumenregel 100G davon kosten einen sehr hohen, sechsstelligen Betrag vielleicht sogar siebenstellig, wenn ihr wenig davon kauft also überlegt euch so was vorher gut es ist natürlich auch hier wieder viel schwarze Magie die buggen könnt das eh nicht und auch die Integration von so einer Waschmaschine ins Netz braucht einiges an Know-How also das wird euch nicht der kleine Systemhaus-Netzwerker machen das wird sich konfiguriert und auch hier wieder hilft nur wenn wir selber genug Edge-Kapazität haben ich glaube wir müssen ein bisschen beschleunigen das ganze gibt es natürlich auch in der Cloud im Endeffekt nichts anderes nur dass ich dann sage ok ich möchte das Netz nicht selber betreiben sondern wenn ich angegriffen werde hab ich meine Internetablings und lass einen Cloud Provider die Werbung dafür habt ihr bestimmt schon tausendmal gesehen oder auch die Captures sich drum kümmern und dann kriege ich quasi von dem nur sauberen Traffic aus seiner Cloudwaschmaschine zurück super ist einfach muss selber keine Edge-Bandbreite haben es hat hoffentlich die Cloud kostet aber ungefähr pro IP-Adresse die ihr schützen wollt 10.000 Euro pro Jahr und das Setup kostet auch nochmal 20.000 bis 30.000 Euro pro IP und wenn du das dann noch möchtest dass es always on ist und dein Traffic immer nur sauber zurück kommt dann kannst du es quasi gar nicht mehr bezahlen genau Strategie würde ich jetzt vielleicht mal skippen nur ein kurzes Wort dazu also überlegt euch halt quasi wann fahre ich was bei kleinen D-Dossen black hole ich vielleicht wenn es größer wird Rate Limite ich oder schiebs in die Waschmaschine und je nachdem ob jemand dafür zahlt wird es halt geblack hole oder kommt in die Waschmaschine ich glaube zwei Slides würden wir auf jeden Fall gern noch machen nämlich was wir jetzt tun können wenn das in Ordnung ist was kann ich jetzt tun ja die Punkte stehen im Prinzip alle da das Monitoring muss laufen das muss jetzt laufen wo der Delos Angriff hingeht ihr müsst die Communities vom Provider gelesen haben ihr müsst im Prinzip auch wissen wie sieht euer Netz aus ihr müsst alles von Anfang an resilient auslegen also die wichtigen Dinge jetzt schon geschützt haben die Firewall sollte jetzt schon da sein vor dem Management Netz eh klar was auch sinnvoll sein kann sind die Strategie sich vorne weg bereit zu legen und Risk Groups zu trennen dass ich quasi sage ich hab hier das eine Servernetz das tut irgendwelche Dinge komplett getrenntes Netz irgendwo anders und wenn das eine irgendwie in Flammen steht dann funktioniert das andere noch weiter und wenn ein Angriff stattfindet ganz viele Dinge vorbereiten dass man irgendwie mit Copy-Paste quasi Mitigation einschalten kann genau die zweite Slide kennt dein Netz kennt deine Protokolle weiß du musst wissen was da passiert wenn ein Angriff stattfindet hol vielleicht noch die Sysadminst dazu hol möglichst viele Leute dazu die sagen können was ist gut und was ist schlecht und auch nicht blind drauf vertrauen dass automatisierte Dinge automatisiert funktionieren und die Bandbreite muss da sein throwing bandwidth at the problem machen Provider immer gerne yeah mind your manners ganz kurz wenn diese Punkte erfüllt sind haben wir kein dedos mehr also ISPs müssen quasi Source Address Boothing verhindern Hoster sollten schneller auf Abuse für gehackte Server reagieren Sysadminst müssen gucken dass die Services richtig konfiguriert sind dass so Reflections einfach nicht funktionieren und auch ganz wichtig entkunden kein billigen Krempel kaufen die dann mit Default-Passwörtern irgendwie ungefeier wollt im Internet hängen seit wie Momo rate limited euer Glühbirnen-V-Lan das ist kein Witz ja, Dankeschön