Während unserer jährlichen Sicherheitsüberprüfung wurde ich an einen Vorfall Anfang des Jahres erinnert, bei dem wir eine Bedrohung für den Webserver unserer Organisation erhielten. Es ging um eine Unternehmensrichtlinie und es wurde mit einem DDoS-Angriff auf unsere Site gedroht. Glücklicherweise ist nichts Schlimmes dabei herausgekommen und es stellte sich als leere Drohung heraus. Wir haben jedoch trotzdem sofort den CIO, CSO und CEO sowie unseren Hosting-Anbieter benachrichtigt, die unsere Reaktion begrüßten. Aufgrund der Art unserer Organisation (im Bildungsbereich) waren an der präventiven Reaktion viele Personen beteiligt, einschließlich der Koordination mit den örtlichen Strafverfolgungsbehörden.
Obwohl unsere Antwort für eine leere Drohung ausreichte, wird mir klar, wie wenig Angriffsplanung die Web-App durchlaufen hat. Im Moment sieht das Setup so aus:
- Ein Linode VPS, der sich nicht hinter der Firewall des Unternehmens befindet (dazu gibt es eine lange Geschichte, die nicht erklärt werden muss)
- eine PostgreSQL-Datenbank auf demselben Server, die nur lokale Verbindungen zulässt
- ein Nginx-Server, für den wir derzeit Best Practices befolgen, um [1]
- SSH-Zugriff, den wir auf Zertifikatsauthentifizierung migrieren
- Ein Backup-VPS mit den aktuellsten Servereinstellungen, für den lediglich die neueste Codeversion und die Migration der Datenbankeinstellungen benötigt werden (derzeit als Testserver verwendet, aber auch als Georedundanzoption vorgesehen)
Ich denke, meine Frage lässt sich wahrscheinlich darauf reduzieren, welche weiteren Schritte ich unternehmen sollte, um meinen Server zu sperren und vor DDoS zu schützen? Wir würden gerne verwendenCloudflare-Geschäftmit ihrem DDoS-Schutz, aber wir brauchen ihn nicht immer und 200 $ im Monat sind für die Organisation etwas happig. Brauche ich das überhaupt? Gibt es eine Lösung, die einen temporären DDoS-Schutz bietet? Wenn nicht, wie kann die Stabilität während/nach einem Angriff am besten aufrechterhalten werden? Und schließlich: Welche Protokollierung sollte implementiert werden, damit wir die Strafverfolgungsbehörden im Falle eines Angriffs unterstützen können?
Antwort1
welche weiteren Schritte sollte ich unternehmen, um meinen Server zu sperren und vor DDoS zu schützen?
- Sperren Sie alle Ports und Protokolle, die nicht verwendet werden, mit einer Firewall. Beschränken Sie den Zugriff, sofern möglich, nur auf vertrauenswürdige IP-Adressen.
- Wenden Sie alle Sicherheitspatches und Updates zeitnah an
- Implementieren Sie einen Netzwerkmonitor, der bei verdächtigen Aktivitätsspitzen warnt
200 $ im Monat sind für die Organisation etwas happig. Brauche ich das überhaupt?
Nein. Nicht, bis es einen Mehrwert bietet und zu einem Must-have wird.
Gibt es eine Lösung, die einen temporären DDoS-Schutz bietet?
Ja. Sie können im Vorfeld eine beträchtliche Zeitinvestition erfordern, um die Komplikationen bei der Implementierung ihres DDoS-Dienstes zu beseitigen. http://www.blacklotus.net/protect/emergency-ddos-protectionist ein solcher On-Demand-Dienst.
Wenn nicht, was ist der beste Weg, die Stabilität während/nach einem Angriff aufrechtzuerhalten?
Sitzen Sie einfach da und lassen Sie es sich gefallen. Das ist die Natur von DDoS. Sie können versuchen, IPs mit einer Firewall abzuschirmen, aber wenn der Angriff wirklich verteilt ist ... nun, das ist, als würde man einen Waldbrand mit einer Wasserpistole bekämpfen.
Und schließlich: Welche Protokollierung sollte implementiert werden, damit wir die Strafverfolgungsbehörden im Falle eines Angriffs unterstützen können?
Führen Sie Protokolle über eingehende Quell-IPs und Zeitstempel sowie alle anderen relevanten forensischen Daten. Wenn es sich beispielsweise um einen Webserver handelt, versuchen Sie, den Benutzeragenten und die angeforderten Ressourcen zu protokollieren. Verkehrsraten wie Pakete pro Sekunde und die Anzahl der Anfragen pro Sekunde sind hilfreich.
DDoS läuft auf eine mathematische Analyse hinaus. Wenn jemand versucht, Sie zu erpressen, setzt er darauf, dass er Ihr Geschäft so stark stören kann, dass Sie Schutzgeld zahlen müssen, um dies zu verhindern. Die Größe ist ein Faktor. Kleinere Betreiber sind leichter auszuschalten, aber sie können weniger zahlen. Wenn Sie eine E-Mail-Bedrohung erhalten, ist es am besten, sie zu ignorieren. Es sind erhebliche Botnet-Ressourcen erforderlich, um DDoS-Angriffe zu initiieren und aufrechtzuerhalten. Sie können nicht einfach alle wie Spammer in die Luft jagen. Wahrscheinlich führen sie einfach eine massive Phishing-Attacke durch und suchen nach leichten Zielen, die sie einschüchtern können. Aufgrund der Natur des DDoS-Monsters sind die Opfer ziemlich hilflos, es sei denn, sie können ein ausgeklügeltes Paketfilter-Präventionssystem einsetzen oder über das Budget verfügen, um externe Dienste zu beauftragen.
Antwort2
Die Antwort von inetplumber ist großartig.
Ich möchte hinzufügen, dass eine weitere Option darin besteht, Ihre App so zu konfigurieren, dass sie skalierbar ist, sodass Sie einen größeren Angriff bewältigen können, ohne Ihren Benutzer zu beeinträchtigen. Sie können beispielsweise eine Virtual Private Cloud (VPC) auf Amazon AWS einrichten, wobei Ihr PostgreSQL-Server nur von innerhalb Ihrer VPC aus zugänglich ist. Sie können ein Load Balancer-Frontend einrichten, um die Last auf mehrere Server zu verteilen.
Der Vorteil dieser Vorgehensweise besteht darin, dass Sie ohne Vorabinvestitionen schnell auf Hunderte (oder mehr) Server hochskalieren können (wenn Sie bereits konfiguriert sind), was Sie zu einem viel schwierigeren Ziel macht. Sie müssen für diese Server nur während der Stunden bezahlen, in denen Sie tatsächlich angegriffen werden. Wenn Sie nicht angegriffen werden, müssen Sie nur für Ihren einen Webserver und einen Datenbankserver bezahlen.
Der schwierigste Teil wäre die Einrichtung, und diese ist sicherlich etwas komplexer als Ihre aktuelle Konfiguration. Die Einrichtung für eine schnelle Skalierung würde noch mehr Arbeit erfordern. Aber wenn Sie nach etwas suchen, das Sie planen könnten (insbesondere, wenn Sie aufgrund anderer Probleme glauben, dass Sie in Zukunft ein Ziel sein könnten), dann wäre dies das Richtige.
Antwort3
welche weiteren Schritte sollte ich unternehmen, um meinen Server zu sperren und vor DDoS zu schützen?
Wenn Ihre Webanwendung nicht interaktiv ist und nur Inhalte anzeigt: Verwenden Sie Nginx + Proxy-Cache mit einer kurzen Cache-Zeit (1-5 Minuten sind normalerweise in Ordnung). Dies erhöht die Leistung erheblich und zwingt einen Angreifer, mehr Ressourcen zuzuweisen
Richten Sie eine eingeschränkte Firewall ein, die alles Unnötige filtertIN und OUTindem Sie die INPUT/OUTPUT/FORWARD-Richtlinie auf DROP setzen; achten Sie darauf, jeden ausgehenden Verbindungsversuch zu protokollieren (außer für UPD-Port 53 :)
Wenn Sie SSH nicht auf eine statische Verwaltungs-IP beschränken können, verwenden Sie einen alternativen hohen Port wie 22222. Dies verhindert viele "Hallo McFyl, da ist jemand"-Kritiker.
Verwenden Sie zusätzlich fail2ban/denyhosts, um SSH vor Brute-Force-Angriffen zu schützen
wenn Sie über Administratorressourcen verfügen: Verwenden Sie OSSEC und ein leichtes WAF (es gibt Naxsi für Nginx, das leicht ist und nicht so ein PITA wie mod_security), aber Sie benötigen jemanden, der solche Installationen einrichtet und wartet
Durchführung von Backups und Nutzung des Standby-Servers als Backup-Ziel
Halten Sie Ihren Webapp-Code auf dem neuesten Stand. Wenn Sie ein Open-Source-Projekt verwenden, melden Sie sich für deren Sicherheits-Mailingliste an.
Vermeiden Sie Software, die bekanntermaßen viele Schwachstellen aufweist
wenn Sie den Administrator-Login und/oder Management-Webanwendungen verwenden: Richten Sie für diese Logins eine Basisauthentifizierung + SSL ein (selbstsigniertes Zertifikat ist OK).
Verwenden Sie SSH-Tunneling, wann immer Sie können, anstatt Ports zu öffnen, z. B. für die Entwicklung
Wenn nicht, was ist der beste Weg, die Stabilität während/nach einem Angriff aufrechtzuerhalten?
- ruhig halten
- jemanden mit Erfahrung für einen solchen Fall zur Hand haben
- Halten Sie Notfallpläne bereit
Das Wichtigste haben Sie bereits getan: Sie haben darüber nachgedacht (und mögliche Gegenmaßnahmen ergriffen), bevor es passiert.