In einem der Artikel habe ich darüber gesprochen, wie das Kinderskript das Leben unserer Kunden beeinträchtigt . In diesem Artikel möchte ich über Lösungen sprechen: Wie werden wir versuchen, damit umzugehen?
Bisher werden sie ohne vollständigen Quellcode in den nächsten Artikeln veröffentlicht. In der Zwischenzeit eher über die Strategie und Taktik der Verteidigung.
Standard "Lösungen"
Beschwerden senden
Ein sehr verbreiteter Ansatz. Wenn ein Eingriff in Ihren IS festgestellt wird, geben Sie den Angreifer in die Firewall ein (oder nicht) und senden Sie eine automatische Beschwerde per E-Mail, die in whois gefunden wurde.
Wir erhalten Beschwerden über unsere Kunden von den Intrusion Detection-Systemen verschiedener Banken, Büros und Websites. Sogar große Unternehmen führen anscheinend fail2ban ein und das war's.
Es wird alles jedes Mal funktionieren. Was ist, wenn der Angreifer nicht gebannt ist? Ja, und es ist falsch, die Gelegenheit zu geben, an Ihre Tür zu klopfen. Was ist, wenn jemand das Passwort für die Stufe solarwinds123 festlegt und beim ersten Versuch gehackt wird?
Benutzer zwingen, das Richtige zu tun.
Sie können Ihren eigenen Dienst erstellen, fast Malware, wie Godaddy es getan hat, einen weiteren Benutzer unter dem Nydys-Login hinzufügen und vergessen, den Cloud-Init-Administrator zu deaktivieren, wie Godaddy es getan hat, 8 zusätzliche Zertifikate im System zu installieren, wie es Godaddy getan hat.
Sie können auch AD und andere "unsichere Ports" blockieren, wie dies bei anderen Hostings der Fall war, und das ist alles.
Sie können Ihre Crawler ausführen und Ihre eigenen Netze scannen. Scannen Sie Ports, finden Sie anfällige Dienste oder versuchen Sie sogar, unter den am häufigsten geknackten Kennwörtern in Ihre eigenen Clients einzudringen.
Dies wird in etwas wirklich helfen, aber was und wie auf den Servern des Benutzers angeordnet werden soll, muss vom Benutzer entschieden werden. Wenn Sie dies alles auf einer Skala tun, werden wir auf eine Ausbreitung des technischen Könnens der Benutzer und ein Missverständnis stoßen: "Nun, was habe ich getan ?!" und "Ich bin kein Programmierer!", aber jeder sollte in Sicherheit sein.
Mit Sicherheit umgehen
Alles oben ist sehr cool und kann nützlich sein. Benutzer müssen jedoch geschützt werden. Besonders Neulinge. Virtuelle Server werden häufig als Experimentierfeld verwendet, als Plattform, um sich mit Serversystemen vertraut zu machen, und manchmal verstehen es Benutzer falsch.
Wir haben mit den Besitzern der kompromittierten Maschinen gesprochen und sie gebeten, ehrlich zu sagen, welches Passwort festgelegt wurde, und leider Anmeldungen und Passwörter des Tests: Test oder 111: 111-Level, dies ist immer noch eine gängige Praxis.
Linux-Benutzer werden immer schlechter, sie sind nicht so kontaktfreudig wie Windows-Benutzer, obwohl sie nach der Anzahl der Beschwerden über Linux-Server häufiger von Cyberkriminellen gehackt oder verwendet werden.
Es ist klar, dass nicht jeder seine Richtlinien verliert und Kennwörter der Stufe "12345678" im Stammverzeichnis festlegt. Dies geschieht jedoch regelmäßig. Versuchen Sie es daher.
Die Architektur
Einfach wie ein Schläfer. Hier ist ein Bild:
- Der Trap-Server sammelt 1 Stunde lang Statistiken und sendet die gesammelten Daten an die Datenbank.
- Der Richterserver sammelt Daten aus der Datenbank und trifft Entscheidungen über Verbote. Verbote werden auch für die Krankengeschichte jeder spezifischen IP-Adresse aufgezeichnet.
- Der BGP-Server analysiert die generierte Sperrliste und überträgt diese Liste als BGP-Feed weiter an die Router.
Von Trap-Servern werden die Daten in demselben Format von derselben „Get-Bruteforce“ gesendet , die wir zuvor angeboten haben, nämlich:
- Hacking-Versuche
- Anmeldungen verwendet
- IP Adresse
- PTR-Aufzeichnung
Wie Entscheidungen abgewogen werden
Wir sprechen über eine potenzielle Kampflösung, daher ist es unmöglich, alle hintereinander zu verbieten. Es ist notwendig, diskrete, verständliche Kriterien einzuführen, damit klar ist, wie, was und warum.
Derzeit werden 6 Faktoren berücksichtigt:
- Wie oft hat der Angreifer versucht einzubrechen
- Wie viele verschiedene Köder hat er geschlagen?
- Ist die IP-Adresse statisch?
- Gehört die IP-Adresse dem Hosting- oder Heimanbieter?
- Hat der Angreifer "schlechte" Logins verwendet?
- Was andere gute Jungs sagen
Quantitative Ausdrücke
Hier ist alles klar. Je intensiver die Suche und je größer die Fläche und je größer das Wörterbuch ist, desto höher ist die Bedrohung durch den Angreifer. Es macht keinen Sinn, diesen Artikel zu erweitern.
PTR und alles damit verbundene
Als wir die erste Brute-Force-Analyse veröffentlichten, wurde deutlich, dass der PTR-Datensatz viel aussagt.
Die Anzahl der chinesischen Hosting-Unternehmen, die unsere Server angriffen, war einfach überwältigend, aber dies ist keine Ausnahme. Azure- und AWS-Kunden waren ebenfalls sehr fröhlich involviert und belegten nicht die letzten Plätze.
Die meisten Angriffe wurden von statischen IP-Adressen von Hosting-Anbietern ausgeführt. Wenn also Server die größte Sicherheitsbedrohung darstellen, warum sollten reguläre Benutzer gesperrt werden?
Schlechte Anmeldungen
Dort sind einige. Zum Beispiel ist aus dem leicht gegoogelten "k8h3d" der erste Kandidat für ein Verbot. Dies ist ein Login von einem sehr dummen Crypto-Miner-Wurm, der unter diesem Benutzernamen eine Hintertür in RDP hinterlassen hat. Gleiches gilt für Anmeldungen in Hindi, Chinesisch und anderen Layouts, die für unsere Kunden nicht typisch sind.
Sie können sich eine Situation vorstellen, in der eine Person einen Fehler in einer Ziffer der IP-Adresse macht, nicht eingibt und alle in ihrem Leben vorhandenen Passwörter aussortiert. Es ist jedoch schwer vorstellbar, von unserem Kunden zu erwarten, dass er etwas anderes als den Standardadministrator eingibt. Wir bieten Betriebssysteme nur unter englischen Anmeldungen an, daher ist das Verbot des Tastaturlayouts möglicherweise am effektivsten und sichersten.
Andere gute Jungs
Spamhaus als Beispiel für die Guten, danke ihnen für die offenen Sperrlisten. Nehmen wir an, ein Angreifer hat nur einen Honigtopf getroffen, aber seine Adresse ist schon lange in der SBL. Warum dann ziehen?
Ähnlich verhält es sich mit offenen Fail2Ban-Listen. Die Meinung anderer guter Leute ermöglicht es Ihnen, Entscheidungen sicherer zu treffen.
Testen
Wie in der Medizin. Randomisierte Doppelblindstudie. Überwachte Server (außer Traps) sind in zwei Gruppen unterteilt.
- Kontrollgruppe
- Die Patienten
In den ersten zwei Wochen wenden wir Filterregeln nur für Patienten an. Die Kontrollgruppe empfängt den gesamten Datenverkehr ohne Filterung. Danach wird genau die Hälfte der Server aus beiden Gruppen ausgetauscht.
Zusätzliche Kontrollgruppen werden sich in anderen DCs befinden, um die "Saisonalität" zu berücksichtigen und den Einfluss anderer Faktoren auszuschließen, z. B. die Schließung von Controllern usw.
Auf diese Weise kann am zuverlässigsten festgestellt werden, wie effektiv das Honeypotting ist, um etwas anderes als die Honeypots selbst zu schützen.
Was weiter?
Nach dem Sammeln der Primärdaten werden kampfnahe Tests in nur wenigen Rechenzentren durchgeführt. Wenn dies die Anzahl der Angriffe erheblich verringert, werden wir Folgendes veröffentlichen:
- Öffnen Sie das Blockierungsblatt mit erweiterten Kommentaren im TXT-, XML- und JSON-Format
- Skript für RouterOS und separates Blockierungsblatt für RouterOS
- Open Feed für Router mit BGP-Unterstützung.
- Quellcodes.
Wenn es nicht weniger Angriffe oder mehr Probleme gibt, veröffentlichen wir nur den Quellcode und einen Bericht darüber, warum er ausgebrannt ist.
Ich hoffe, dass das Thema für Sie genauso interessant ist, wie es auf Ihre Gedanken zum vorgeschlagenen System wartet. Alle Gedanken werden nützlich sein.
