DDoS-Schutz für einen VPS: Kapazität, Anwendungsregeln und Wiederherstellung

Ein überfluteter Netzwerkpfad, eine erschöpfte Verbindungstabelle und eine teure Anwendungsabfrage erfordern unterschiedliche Kontrollen. Erfassen Sie Netzwerkzähler, Anfragequoten und Antwortzeiten. Das erste Symptom ist ein Hinweis zum Untersuchen, kein Beweis für einen einzelnen Angriffstyp.

Server-Portgeschwindigkeit, Perioden-Transferkontingent und Mitigationskapazität sind unterschiedliche Spezifikationen. Die Mitigationswerte des vorbereiteten Katalogs reichen je nach Plan von 10 bis 400 Gbps. Nichts davon ändert die CPU-Zeit, die benötigt wird, um eine kostspielige Anfrage zu beantworten.

Umbra 1 listet einen Server-Port mit 1 Gbps, 1 TB monatlichen Transfer und eine Mitigationsspezifikation von 10 Gbps auf. Das erste beschreibt die Verbindung, das zweite ein Periodenkontingent und das dritte eine vorgeschlagene Filterhülle. Keines bedeutet, dass die Anwendung 10 Gbps nützlicher Anfragen beantworten kann. Filterverhalten und zulässiger Datenverkehr müssen im Startnetzwerk validiert werden.

Das vorbereitete Design erkennt Verkehrsanomalien, leitet Angriffe in die Filterung um und gibt zulässigen Verkehr zurück. Das beabsichtigte Aktivierungsziel liegt unter 60 Sekunden, aber Live-Routing und Upstream-Steuerungen müssen getestet werden, bevor daraus ein Versprechen wird. Fragen Sie, was jenseits der enthaltenen Hülle passiert und wie legitimer Verkehr wiederhergestellt wird.

Cachen Sie geeignete Antworten, begrenzen Sie die Rate teurer Pfade und sichern Sie den administrativen Zugriff. Ein WAF oder Reverse Proxy muss als separate Schicht konfiguriert und gewartet werden. Beschränken Sie den Web-Ursprungszugriff auf vertrauenswürdige Proxy-Quellen, wenn dies Teil des Designs ist, ohne den Wiederherstellungsweg zu schließen.

Legen Sie fest, wer Regeln ändern kann, welche Nachweise in ein Ticket gehören und wie Benutzer den Status erfahren. Testen Sie Alarmzustellung und den Ersatzweg. Ein funktionierendes Backup und ein nüchternes Vorfallprotokoll sind nützlich, selbst wenn das Ereignis ein Anwendungsfehler ist.

L3/L4-Vorfälle können UDP-Amplifikation über DNS, NTP oder memcached oder TCP-SYN-Floods umfassen, die den Verbindungszustand belasten. L7-Vorfälle zielen auf Anwendungsarbeit wie wiederholte Suchen oder Login-Versuche. Vergleiche Bits pro Sekunde, Pakete pro Sekunde und Anfragen pro Sekunde getrennt. Ein Edge-Filter, eine Verbindungskontrolle und eine Anwendungsregel lösen unterschiedliche Teile des Problems.

• Schließen oder beschränken Sie unnötige öffentliche UDP-Dienste und halten Sie den Origin-Zugriff bewusst.
• Ein geografisch verteiltes Anycast-Design erfordert Routenrücknahme, Zustandsbehandlung und Failover-Tests; es wird nicht durch eine Angabe zur Mitigationskapazität etabliert.

Eine Challenge-, CAPTCHA- oder Proof-of-Work-Hürde kann verdächtigen Anfragen Reibung hinzufügen. Sie kann auch legitime Besucher, automatisierte Clients und Barrierefreiheit beeinträchtigen, daher sollten Sie sie auf geeignete Endpunkte anwenden und das Ergebnis messen. Eine langsame Antwort oder ein Tarpit belegt ebenfalls Ressourcen; testen Sie die Kosten, bevor Sie annehmen, dass es billiger ist als das Ablehnen der Anfrage.

• Halten Sie einen zugänglichen Wiederherstellungs- oder Supportweg bereit, wenn eine Herausforderung den Eintritt verhindert.
• Anfragelimits, Caching und Anwendungsfixes bleiben auch dann nützlich, wenn eine Challenge aktiviert ist.