Traffic Übersicht
- Normal: Regeln und Limits greifen, Besucher merken nichts. Für den Alltag.
- Angriff: Jeder Besucher löst einmalig eine kurze Browser-Prüfung (2–3 s) aus. Bei laufenden Angriffen.
- CAPTCHA: Jeder Besucher muss ein Bild-Rätsel lösen. Nur bei schweren Angriffen.
- Aus: Keine Web-Prüfung, nur noch Weiterleitung. Nur zur Fehlersuche.
Einzelne Websites stellst du auf ihrer eigenen Seite ein (Websites & Dienste → Website anklicken → Schutz). Der Netzwerk-Schutz (XDP) läuft unabhängig davon immer.
Die Automatik vergleicht die aktuellen Anfragen mit dem Durchschnitt der letzten 60 Minuten und stellt die Schutzstufe selbst hoch und wieder herunter.
Traffic-Überwachung
Analysiere Traffic-Muster...
Anfragen (24 h)
0
Anfragen pro Sek.
0
Abgewehrt (24 h)
0
Gesperrte IPs
0
CrowdSec-Liste
0
Anfragen und Abwehr (letzte 30 Minuten)
Häufigste Angreifer-IPs
letzte 500 BansHerkunftsländer
letzte 500 BansAngriffs-Heatmap Wochentag × Stunde
Challenge Erfolgsrate
Global Threat Map
Echtzeit-Visualisierung abgewehrter XDP- & WAF-Angriffe auf dein Rechenzentrum.
Zuletzt gesperrte IPs
| IP Adresse | Herkunft | Grund | Zeitpunkt |
|---|
Website oder Dienst hinzufügen
Der VortexShield nimmt die Besucher an, prüft sie und leitet saubere Anfragen an den Server weiter, auf dem die Website oder der Gameserver wirklich läuft (der Origin). Websites prüft er Anfrage für Anfrage (Layer 7), Gameserver und andere TCP-Dienste auf Paketebene (Layer 4).
Für Spieleserver und Dienste über UDP, z. B. Counter-Strike, Rust, ARK, Valheim, Minecraft Bedrock oder eigene Protokolle. Der VortexShield prüft nicht den Inhalt, begrenzt aber die Pakete pro IP, wehrt Reflection-Angriffe ab und lässt gesperrte IPs und Länder nicht durch. Öffentliche Ports 30000–30099. Der Server sieht die IP des Shields statt der Spieler-IP.
Für alles, was über TCP läuft und keine Website oder kein Spieleserver ist: eigene Anwendungen, Mail (IMAP/SMTP mit eigenem Port), Datenbank- oder Admin-Zugänge. Der VortexShield prüft nicht den Inhalt, bremst aber Verbindungsfluten und lässt gesperrte IPs und Länder nicht durch. Öffentliche Ports 20000–20099; Standard-Ports wie 25 oder 993 sind auf den Filter-Nodes nicht möglich.
Ohne https:// und ohne Pfad.
Der echte Server, z. B. 203.0.113.10:443. Diese Adresse sollte niemand außer dem VortexShield kennen. Ohne Port: 443 bei HTTPS, 80 bei HTTP.
Auf diesem Port verbinden sich die Spieler mit dem VortexShield. Er muss im Bereich des Spiels liegen.
„Geprüft“ braucht auf dem Origin ein gültiges Zertifikat für die Domain: z. B. Let's Encrypt oder kostenlos aus der VortexShield-Origin-CA (shield-origin-ca issue <domain> auf dem Management-Server).
Nur nötig, wenn das Zertifikat des Origins auf einen anderen Namen lautet, z. B. origin.kunde1.de.
Subdomains oder Preload nur wählen, wenn jede Subdomain dauerhaft HTTPS hat. Browser merken sich das bis zu 2 Jahre.
Deine Websites & Dienste
| Domain / Name | Art | Origin | Port | Origin erreichbar | Aktionen |
|---|
Vorgaben für alle Websites
Diese Werte gelten für jede Website ohne eigene Einstellungen. Eine einzelne Website stellst du so ein: → Website anklicken → Reiter „Schutz“.
Einstellungen je Website
Die Vorgaben passen für die meisten Websites. Wähle „Alle Websites“, um die Vorgabe für alle zu ändern, oder eine einzelne Website, wenn nur diese anders behandelt werden soll (z.B. eine WordPress-Seite oder eine API mit vielen Anfragen).
Grenzwerte & Schutzstufe je Website
Gemessen als Durchschnitt über eine Minute (25 = 1.500 Anfragen/Min). Wer darüber liegt, wird gesperrt. Ein normaler Besucher kommt selten über 5. Vorgabe: 25. Erhöhen für APIs, Apps oder viele Nutzer hinter einer gemeinsamen IP (Firmen, Schulen).
Wie lange eine IP nach einem Verstoß gesperrt bleibt. Vorgabe: 3600 (1 Stunde). Wiederholungstäter werden automatisch länger gesperrt (siehe Einstellungen).
Bei „Alle Websites“ ist das dieselbe Schutzstufe wie oben in der Kopfzeile.
Schutzfunktionen (WAF)
/wp-admin, /xmlrpc.php, /.env oder /config.php aufruft, wird sofort gesperrt. Das sind typische Scanner. Bei WordPress-Seiten würde das auch dich beim Anmelden treffen: Dann für diese Website ausschalten oder deine IP unter „Vertrauenswürdige IPs“ eintragen.Regelsatz, Uploads & Login-Schutz
Erkennt SQL-Injection, eingeschleusten JavaScript-Code, Pfad-Tricks (../../etc/passwd), Befehlsausführung, Log4Shell und Shellshock in Adresse, Parametern und Kopfzeilen. Treffer werden abgewiesen, wer dreimal trifft, gesperrt.
Fehlalarm bei einem bestimmten Pfad? Eine eigene Regel „Erlauben“ für diesen Pfad nimmt ihn aus.
Anfragen mit größerem Inhalt werden sofort mit 413 abgewiesen, bevor sie den Origin erreichen. Formulare brauchen nur wenige KB; Bild- und Datei-Uploads entsprechend mehr.
Gleichzeitige Verbindungen pro Besucher-IP sind auf 200 begrenzt, Kopfzeilen und Inhalt müssen innerhalb von 5 s ankommen (gegen Slowloris).
Auf Anmeldeseiten muss jeder die Browser-Prüfung bestehen, und zu viele Anmeldeversuche einer IP werden abgewiesen. Gegen Passwort-Raten durch Bots.
Welche Bots dürfen auf die Website?
Eingeschaltet = diese Bots kommen ohne Browser-Prüfung und ohne CAPTCHA durch, auch bei der Schutzstufe „Angriff“. Ausgeschaltet = sie werden wie normale Besucher behandelt und scheitern meist an der Browser-Prüfung. Suchmaschinen werden über ihren DNS-Namen bestätigt (eine IP, die sich „Googlebot“ nennt, muss wirklich zu googlebot.com gehören) und dürfen dann auch beliebig viele Seiten abrufen. SEO-Werkzeuge und KI-Crawler erkennt der Filter nur an ihrer Kennung (User-Agent), die jeder fälschen kann. Für sie gilt deshalb weiter das Anfragen-Limit.
python-requests, Go-http-client und Java sofort gesperrt. Einschalten, wenn eigene Skripte oder Apps mit solchen Bibliotheken auf die Website zugreifen.Anfragen-Limits (Rate-Limiting)
Eigenes Limit für einzelne Pfade, z.B. ein strengeres für /login gegen Passwort-Raten (empfohlen: 1–2) oder ein höheres für eine API. Ohne Eintrag gilt das allgemeine Limit von oben. Der Pfad muss genau passen, /login gilt also nicht für /login/reset.
| Domain | Pfad | Limit | Aktion |
|---|
Eigene Regel erstellen
Für Sonderfälle, z.B. wenn ein bestimmter Bot oder ein bestimmter Pfad Ärger macht. Beispiel: Feld „Pfad“, „Enthält“, Wert /wp-login.php, Aktion „Browser-Prüfung“. „Erlauben“ (nur für eine einzelne Website) schaltet für passende Anfragen die Formular-Prüfung und die Regeln für alle Websites ab, z.B. für ein Forum, in dem Nutzer Code posten. Im Normalbetrieb braucht man keine eigenen Regeln.
Eigene Regeln
Zwischenspeicher (Cache)
Die Filter-Nodes speichern Seiten und Dateien kurz zwischen und liefern sie selbst aus. Eine Flut auf dieselbe Seite erreicht den Origin dann kaum noch. Eine einzelne Website stellst du auf ihrer Seite im Reiter „Zwischenspeicher“ ein.
Sperren & Listen
Gilt für alle Websites und Spieleserver auf einmal. Die Sperren greifen schon in der Netzwerkkarte aller Filter-Nodes. Länder und Netzbetreiber hier nur als Notbremse bei großen Angriffen sperren, denn sie treffen alle Kunden. Für eine einzelne Website gibt es dafür eine eigene Länder-Sperre auf ihrer Seite.
Gesperrte IPs
Automatisch gesperrte Angreifer und deine eigenen Sperren. Eine IP entsperrst du mit dem Papierkorb.
| IP-Adresse | Ablauf in | Aktion |
|---|
Vertrauenswürdige IPs (Whitelist)
Diese IPs werden nie gesperrt und nie geprüft. Unbedingt eintragen: deine eigene IP sowie die IPs aller VortexShield-Server und Origins. Sonst nur Adressen, denen du voll vertraust.
| IP-Adresse | Aktion |
|---|
Länder sperren (alle Dienste)
Sperrt ein ganzes Land zentral auf allen Filter-Nodes, direkt im XDP-Filter (Layer 3). Das gilt für alle Websites, Minecraft- und TCP-Dienste. Pakete aus dem Land werden verworfen, bevor sie einen Dienst erreichen. Das kostet praktisch keine Leistung, auch nicht bei einem Angriff.
Achtung: trifft auch echte Besucher, die gerade dort sind, und Suchmaschinen-Bots. IPs auf der Whitelist bleiben erlaubt. Nur eine einzelne Website einschränken, oder „nur bestimmte Länder erlauben“? Das geht auf der Seite der Website (Websites & Dienste → Website anklicken → „Länder für diese Website“).
| Gesperrtes Land | Aktion |
|---|
Netzbetreiber sperren (ASN)
Sperrt alle IPs eines Netzbetreibers, z.B. eines Cloud-Anbieters, von dem viele Angriffe kommen (AS14061 = DigitalOcean). Die AS-Nummer zu einer IP findest du z.B. auf bgp.he.net. Vorsicht bei großen Anbietern: Über sie kommen oft auch echte Besucher, Firmen-VPNs und Dienste wie Zahlungsanbieter.
| Gesperrte ASN | Aktion |
|---|
Anonymisierungsdienste (Tor, VPN)
Sperrt Zugriffe über Tor und bekannte VPN- und Proxy-Dienste. Gilt für alle Websites. Empfohlen: beides aus. Nur bei hartnäckigen Angriffen über solche Dienste einschalten, denn viele echte Nutzer surfen per VPN.
CrowdSec-Sperrliste
Präventiv blockierte Botnetz-IPs aus der CrowdSec-Gemeinschaftsliste. Sie werden automatisch aktualisiert und gelten wie alle Sperren auf allen Filter-Nodes.
| IP-Adresse | Status | Aktion |
|---|
Aktive Alarme
Server im Cluster
1–20 Filter-Nodes (je etwa 10 Gbit/s) und 1–2 Management-Server. Eingang gesamt: —
| Node | Rolle | Status | Eingang | XDP Drops | Dienste | Zuletzt gesehen / Aktionen |
|---|
Netz & Zugang
Wie die Server miteinander verbunden sind und wie du selbst ans Dashboard kommst.
Server hinzufügen
Du brauchst nur einen frischen Server mit Debian 13, auf dem du dich als root anmelden kannst. Den Rest richtet das Management selbst ein.
Was passiert dabei? Und von Hand ohne Dashboard?
- Das Management öffnet den Anmelde-Port 8444 nur für die eingegebene IP, höchstens 30 Minuten lang. Das Dashboard bleibt dabei für alle anderen gesperrt.
- Der Befehl prüft, dass er wirklich mit diesem Management spricht (Schlüssel des Zertifikats). Er installiert WireGuard, erzeugt einen eigenen Schlüssel und meldet sich an. Der private Schlüssel verlässt den Server nie.
- Über den Tunnel richtet das Management den Server ein und verteilt die Dateien. Der Fortschritt erscheint im Fenster.
- Ist der Node online, seine öffentliche IP in den DNS-Round-Robin der Domains aufnehmen.
Von Hand: Doku, Kapitel Rollout & Betrieb → Neuen Filter-Node in Betrieb nehmen.
Ports sperren
Ein Filter-Node braucht nur wenige offene Ports. Pakete an gesperrte Ports verwerfen die Filter-Nodes sofort (z.B. 3306 oder Bereich 1000-2000). Ports, die eine eingetragene Website oder ein Spieleserver braucht, nicht sperren.
| Port/Bereich | Protokoll | Aktion |
|---|
Ports nur für bestimmte IPs öffnen
Sobald für einen Port ein Eintrag existiert, kommen nur noch die eingetragenen IPs durch, alle anderen werden verworfen. Typisch: SSH (22) nur von deiner Admin-IP.
10.10.0.0/24). Hast du eine wechselnde IP, sperrst du dich sonst beim nächsten Wechsel aus und kommst nur noch über die Konsole des Hosters herein.| Port | Erlaubt für | Aktionen |
|---|
Schutz vor SYN-Floods empfohlen: an
Jeder Verbindungsaufbau beginnt mit einem SYN-Paket. Ein Angreifer schickt davon Millionen, um den Server zu überlasten. Mit diesem Schutz verwirft die Netzwerkkarte alle SYN-Pakete einer IP, die über dem Limit liegen.
Vorgabe: 100. Ein Browser öffnet pro Seite meist unter 10 Verbindungen. Nur erhöhen, wenn viele Nutzer hinter einer IP sitzen (Firmen, Mobilfunk).
Ping (ICMP) blockieren empfohlen: aus
Die Filter-Nodes antworten nicht mehr auf ping. Bringt wenig Schutz, erschwert aber die Fehlersuche, und Überwachungsdienste (auch die des Hosters) melden den Server dann eventuell als „down“.
Verbindungs-Limits (Connection Tracking)
Begrenzt, wie viele Verbindungen eine einzelne IP gleichzeitig offen halten darf. Schützt vor Angriffen, die den Server mit vielen langsamen Verbindungen blockieren (Slowloris). nur bei Bedarf
| Höchstens | Bei Überschreitung | Aktionen |
|---|
Ungültige Pakete verwerfen empfohlen: an
Verwirft TCP-Pakete mit unmöglichen Kombinationen (z.B. gleichzeitig „Verbindung öffnen“ und „schließen“), wie sie Port-Scanner und manche Angriffe verwenden. Normale Programme erzeugen solche Pakete nie.
Schutz vor UDP-Reflection empfohlen: an
Bei diesem Angriff schicken fremde, falsch konfigurierte Server (DNS, NTP, Memcached …) riesige Antworten an deinen Server, um die Leitung zu füllen. Empfohlen: die Quell-Ports 53, 123, 389, 1900 und 11211 eintragen.
Verwirft UDP-Pakete mit diesem Quell-Port, die auf einem hohen Port (ab 32768) ankommen, also Antworten, die der Node nie angefragt hat. Zeit (123) und DNS (53) holen die Filter-Nodes über WireGuard von den Management-Servern, beide Ports lassen sich deshalb gefahrlos sperren.
| Protokoll | Port | Typ | Aktionen |
|---|
Paketinhalte prüfen (DPI)
Für Spieleserver mit eigenem Protokoll: Auf dem Port kommen nur noch Pakete durch, die mit einer bestimmten Byte-Folge beginnen. Alles andere (also Müll-Pakete eines Floods) wird verworfen. nur bei Bedarf
| Port | Beginnt mit | Andere Pakete | Aktionen |
|---|
Erweiterte Analyse
Alarm bei voller Leitung und Feineinstellungen der Paketprüfung.
Betriebssystem-Erkennung empfohlen: aus
Schätzt bei jedem Verbindungsaufbau das Betriebssystem des Absenders und legt das als Statistik ab. Sperrt nichts und wird im Dashboard derzeit nicht angezeigt. Kostet bei SYN-Floods zusätzlich Rechenzeit, deshalb aus lassen.
Bandbreiten-Alarm empfohlen: an
Schickt eine Nachricht an den Webhook, wenn ein Filter-Node mehr empfängt als hier eingestellt. Ist die Leitung voll, hilft keine Filterregel mehr, dann muss der Hoster helfen. Empfohlen: 80 % der Portgeschwindigkeit, also 8000 bei 10 Gbit/s, 800 bei 1 Gbit/s. 0 = aus.
Fragment-Filter
Zu große Pakete werden unterwegs in Stücke (Fragmente) geteilt. Die Folgestücke lassen sich nicht prüfen und werden gern für Floods benutzt. Web- und Spiele-Verkehr ist praktisch nie fragmentiert. Empfohlen: an. Nur ausschalten, wenn ein Dienst mit sehr großen UDP-Paketen (z.B. manche VPNs) nicht mehr funktioniert.
Umgang mit gesperrten Paketen
Was mit gesperrten Paketen passiert. Empfohlen: „Verwerfen“. Die anderen Varianten schicken eine Antwort zurück. Da Angreifer ihre Absender-IP meist fälschen, trifft diese Antwort Unbeteiligte, kostet eigene Bandbreite und kann beim Hoster als Missbrauch gemeldet werden.
Paketgrößen-Validierung
Verwirft Pakete an einen Port, die kleiner oder größer sind als erlaubt. Nützlich für Spieleserver, deren Pakete eine bekannte Größe haben. nur bei Bedarf Zu enge Grenzen trennen echte Spieler, im Zweifel keinen Eintrag anlegen.
| Port | Mindestens | Höchstens | Aktionen |
|---|
Paket-Limits pro Verbindung
Begrenzt, wie viele Pakete pro Sekunde eine IP an einen Port schicken darf. Fängt Floods auf einen einzelnen Spieleserver ab. nur bei Bedarf
TLS-Fingerabdruck
Sperrt HTTPS-Verbindungen, deren Fingerabdruck (Hash) du einträgst. Er ist grob: Viele Programme und Browser teilen denselben, eine Sperre kann also auch echte Besucher treffen. nur bei Bedarf Ohne Einträge bewirkt der Schalter nichts.
Schutz vor HTTP/2 Rapid Reset
Eine 2023 bekannt gewordene Angriffsart (CVE-2023-44487): Der Angreifer startet über eine Verbindung extrem viele Anfragen und bricht sie sofort wieder ab. Dieses Limit begrenzt HTTP/2-Anfragen pro IP in 10 Sekunden. nur bei Bedarf
Paket-Mitschnitt
Zeichnet 10 Sekunden lang den Netzwerkverkehr eines Filter-Nodes auf (tcpdump). Die Datei kannst du herunterladen und z.B. in Wireshark öffnen, oder unten hochladen und Sperr-Vorschläge erhalten. Nur für die Fehlersuche bei ungewöhnlichen Angriffen nötig. Hinweis: XDP verwirft Pakete vor tcpdump — gebannter Traffic ist im Mitschnitt nicht sichtbar.
Mitschnitt analysieren
Einen Mitschnitt von oben direkt analysieren oder hier eine .pcap-Datei hochladen. Die Auswertung zeigt, woher der Verkehr kommt und wohin er geht, und schlägt passende Regeln vor, die du mit einem Klick übernimmst.
Dieser Management-Server
Zeigt nur den Server, auf dem du gerade angemeldet bist. Den Zustand aller Filter-Nodes und des zweiten Management-Servers siehst du unter .
Geladene Sperrlisten
Hintergrund-Dienste
Datenbank (Valkey)
SSL-Zertifikate
Treffer je Regel
Sperrlisten importieren / exportieren
CSV-Format: ip,duration_seconds — eine IP pro Zeile
Wartung
Änderungsprotokoll
| Zeitpunkt | User | Aktion | Details |
|---|
Wiederherstellungspunkte
Stände aller Einstellungen zum Zurückrollen. Jede Stunde automatisch, wenn sich etwas geändert hat, und vor jedem Zurückrollen. Liegen auf beiden Management-Servern.
| Zeitpunkt | Art | Inhalt | Aktionen |
|---|
Vollständige Sicherung herunterladen
Alles in einer Datei: Einstellungen, Datenbank (auch Bans und Protokoll), Zugangsdaten, WireGuard-Schlüssel und Zertifikate. Verschlüsselt mit einem Passwort, das du hier festlegst. Bewahre Datei und Passwort getrennt auf, z. B. das Passwort im Passwort-Manager.
Ohne das Passwort lässt sich die Datei nicht öffnen, auch nicht auf dem Management-Server. Geht es verloren, ist die Sicherung wertlos.
Aus Datei wiederherstellen
Spielt die Einstellungen aus einer heruntergeladenen Sicherung zurück. Websites, Regeln, Whitelist, Sperren und alles Weitere aus dem Dashboard. Vorher wird automatisch ein Wiederherstellungspunkt angelegt.
Bans, Statistiken und Protokoll bleiben, wie sie sind. Zugangsdaten und Schlüssel aus der Datei braucht man nur, wenn ein Server komplett neu aufgesetzt wird. Das geht auf der Konsole, siehe Hilfe.
Externe Sicherung (täglich)
Mein Konto
· · Sitzung endet um
1. In der Authenticator-App (z. B. Google Authenticator, Microsoft Authenticator, 2FAS, Aegis) „Konto hinzufügen“ wählen und diesen QR-Code scannen:
Oder „Schlüssel eingeben“ wählen und diesen Schlüssel eintragen (Typ: zeitbasiert):
Am Handy geht auch dieser Link: in der App öffnen
2. Den sechsstelligen Code aus der App hier eingeben:
Angemeldete Geräte
Jede Anmeldung gilt höchstens 6 Stunden, danach muss man sich neu anmelden.
Kunden
Ein Kunde sieht nur die ihm zugeordneten Websites und Dienste und kann sie selbst einstellen. Anlegen, Löschen und alles, was den ganzen Cluster betrifft, bleibt den Administratoren vorbehalten.
| Kunde | Dienste | 2FA | Letzte Anmeldung | Status | Aktionen |
|---|
Beim Anlegen entsteht ein Einmal-Passwort. Der Kunde muss es bei der ersten Anmeldung ersetzen.
Benutzer
Jeder, der das Dashboard benutzt, bekommt ein eigenes Konto. Dann steht im Änderungsprotokoll, wer was geändert hat, und ein Konto lässt sich einzeln sperren.
| Benutzer | Rolle | 2FA | Letzte Anmeldung | Status | Aktionen |
|---|
Das Startpasswort persönlich oder über einen sicheren Weg weitergeben. Die Person sollte es danach unter „Mein Konto“ ändern und den zweiten Faktor oder einen Passkey einrichten.
Darstellung
Gilt für diesen Browser.
Wartung eines Filter-Nodes
Bevor du einen Filter-Node neu startest oder aktualisierst, nimm ihn aus dem Betrieb, damit keine Besucher abbrechen:
- Unter beim Node auf klicken (oder auf dem Management-Server
shield-cluster drain <node>). Die DNS-Health-Checks nehmen ihn dann aus der Rotation. - Einige Minuten warten, bis kaum noch Anfragen auf dem Node ankommen.
- Wartung durchführen und mit wieder einschalten. Updates für alle Nodes nacheinander erledigt
shield-cluster upgradeautomatisch.
Benachrichtigungen & Integrationen
Ohne Webhook bemerkst du Angriffe und Ausfälle nur, wenn du gerade ins Dashboard schaust. Die URL erzeugst du in Discord unter Kanal-Einstellungen → Integrationen → Webhooks.
Automatik — ab wann sie eingreift
Ist oben die Automatik eingeschaltet, stellt sie die Schutzstufe bei einem Ansturm selbst auf „Angriff“ bzw. „CAPTCHA“. Sie greift ein, wenn beide Werte überschritten sind: die Mindestzahl an Anfragen pro Minute und das Vielfache des Durchschnitts der letzten Stunde. Die Vorgaben passen für die meisten Seiten — nur ändern, wenn die Automatik zu früh oder zu spät reagiert.
Vorgabe: 100
Vielfaches des normalen Traffics
Vorgabe: 200
Vielfaches des normalen Traffics
Wiederholungstäter länger sperren
Wer innerhalb von 30 Tagen erneut gesperrt wird, bleibt jedes Mal doppelt so lange gesperrt (empfohlen).
Volumetrische Angriffe (> 10 Gbit/s pro Node)
XDP filtert nur, was die Netzwerkkarte erreicht. Ist der 10G-Port eines Filter-Nodes voll, hilft keine Regel auf dem Server mehr.
- Hoster-DDoS-Schutz (Upstream-Scrubbing) für alle Filter-IPs aktiv lassen.
- Betroffenen Node aus dem DNS-Round-Robin nehmen — die übrigen Nodes tragen die Last.
- Den Bandbreiten-Alarm (Netzwerk-Schutz (L3/L4)) auf ca. 80 % der Portkapazität setzen.