tbz-repos/m346
1
0
Fork 0
mirror of https://gitlab.com/ser-cal/m346.git synced 2024-11-26 10:11:56 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity

Auftrag ergänzt mit Infos zu DoS

Browse Source
This commit is contained in:
Marcello Calisto 2023-10-16 10:22:55 +02:00
parent 26c4641f65
commit e9fe1ec38f
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
KN06/KN06.md
View File

@ -123,7 +123,7 @@ Beachten Sie ausserdem die [llgemeinen Informationen zu den Abgaben](../Abgaben.
#### Wissenswertes vor dem nächsten Challenge:<br> #### Wissenswertes vor dem nächsten Challenge:<br>
:bulb: Für eine **perfekte High Availability-Plattform** würde dieser Load Balander **noch nicht alle Bedingungen** erfüllen. Das **Beispiel unten** zeigt, dass die Instanzen in **unterschiedlichen** Availability-Zones sind. Damit ist zwar schon mal **ein wichtiges Kriterium** erfüllt. Was würde jetzt aber passieren, wenn plötzlich gleichzeitig **10'000x mehr** Requests reinkämen und die Applikation unter dieser Last zusammenbricht? :bulb: Für eine **perfekte High Availability-Plattform** würde dieser Load Balander **noch nicht alle Bedingungen** erfüllen. Das **Beispiel unten** zeigt, dass die Instanzen in **unterschiedlichen** Availability-Zones sind. Damit ist zwar schon mal **ein wichtiges Kriterium** erfüllt. Was würde jetzt aber passieren, wenn plötzlich gleichzeitig **10'000x mehr** Requests reinkämen und die Applikation unter dieser Last zusammenbricht?
Genau. Um diesen - oder ähnliche - **Use-cases** in den Griff zu bekommen, benötigt der **Load Balancer** Unterstützung von seinem besten Freund, dem **Auto Scaler** :two_men_holding_hands:. Was dieser unternimmt und wie er es macht, erfahren Sie gleich, nachdem wir noch abschliessend zu diesem Challenge einen möglichen Use-Case eines Service-Ausfalls (DoS-Attacke) angeschaut haben. Sie werden dann im nächsten Challenge auch gleich selber einen **Auto Scaler** aufsetzen und diesen dann im übernächsten Challenge mit dem Load Balancer vereinen. :wrench: Genau. Um diesen - oder ähnliche - **Use-cases** in den Griff zu bekommen, benötigt der **Load Balancer** Unterstützung von seinem besten Freund, dem **Auto Scaler** :two_men_holding_hands:. Was dieser unternimmt und wie er es macht, erfahren Sie gleich, nachdem wir noch abschliessend zu diesem Challenge einen möglichen Use-Case eines Service-Ausfalls (DoS-Attacke) angeschaut haben. Sie werden dann im nächsten Challenge auch gleich selber einen **Auto Scaler** aufsetzen und diesen dann im übernächsten Challenge mit dem **Load Balancer** zum unschlagbaren Team **High Availabiliy** vereinen. :wrench:
##### Use Case: Denial of Service ##### Use Case: Denial of Service
Denial of Service (DoS) bezeichnet eine Cyberangriffstechnik, bei der ein Angreifer versucht, ein Computersystem oder eine Website durch Überlastung mit Traffic oder Anfragen unzugänglich zu machen. Das Ziel ist, legitimen Nutzern den Zugriff zu verweigern, indem die Ressourcen des Zielsystems erschöpft werden. DoS-Angriffe oder auch gewöhnliche technische Störungen können erhebliche Schäden verursachen und werden durch verschiedene **proaktive** Sicherheitsmaßnahmen wie Firewalls, Intrusion Detection Systems bekämpft und zusätzlich mit Monitoring-Software überwacht. Der Load Balancer hat aber eine andere Aufgabe und ist nicht darauf ausgelegt, solche Problem zu lösen. Und genau da kommt der **Auto Scaler** ins Spiel. Der **Auto Scaler** gehört zu den **reaktiven** Sicherheitsmassnahmen. Er wird durch einen **Trigger** aktiviert. Das ist entweder ein **Status Check** der einen Alarm auslöst, oder eine **CloudWatch-Metrics**, die eine Grenzwertüberschreitung meldet. Er kommt also erst zum Zug, wenn irgendetwas **nicht** stimmt. Die vier Bilder unten zeigen genau ein solches Szenario auf. Denial of Service (DoS) bezeichnet eine Cyberangriffstechnik, bei der ein Angreifer versucht, ein Computersystem oder eine Website durch Überlastung mit Traffic oder Anfragen unzugänglich zu machen. Das Ziel ist, legitimen Nutzern den Zugriff zu verweigern, indem die Ressourcen des Zielsystems erschöpft werden. DoS-Angriffe oder auch gewöhnliche technische Störungen können erhebliche Schäden verursachen und werden durch verschiedene **proaktive** Sicherheitsmaßnahmen wie Firewalls, Intrusion Detection Systems bekämpft und zusätzlich mit Monitoring-Software überwacht. Der Load Balancer hat aber eine andere Aufgabe und ist nicht darauf ausgelegt, solche Problem zu lösen. Und genau da kommt der **Auto Scaler** ins Spiel. Der **Auto Scaler** gehört zu den **reaktiven** Sicherheitsmassnahmen. Er wird durch einen **Trigger** aktiviert. Das ist entweder ein **Status Check** der einen Alarm auslöst, oder eine **CloudWatch-Metrics**, die eine Grenzwertüberschreitung meldet. Er kommt also erst zum Zug, wenn irgendetwas **nicht** stimmt. Die vier Bilder unten zeigen genau ein solches Szenario auf.