Snort oder Suricata. Teil 3: Sicherung des Büronetzwerks

In im vorherigen Artikel haben wir erklärt, wie man eine stabile Version von Suricata auf Ubuntu 18.04 LTS einrichtet. Es ist relativ einfach, ein IDS auf einem einzelnen Knoten zu konfigurieren und kostenlose Regelsets anzubinden. Heute werden wir untersuchen, wie wir mit der auf einem virtuellen Server installierten Suricata das Unternehmensnetzwerk vor den häufigsten Angriffsarten schützen. Dazu benötigen wir einen VDS mit Linux und zwei Rechenkernen. Der Arbeitsspeicher hängt von der Auslastung ab: Für einige reicht 2 GB, während für ernstere Aufgaben 4 oder sogar 6 GB erforderlich sein könnten. Der Vorteil einer virtuellen Maschine liegt in der Möglichkeit, Experimente durchzuführen: Man kann mit einer minimalen Konfiguration beginnen und die Ressourcen nach Bedarf erhöhen.

Foto: Reuters

• Snort oder Suricata. Teil 1: Auswahl einer kostenlosen IDS/IPS zum Schutz des Unternehmensnetzwerks
• Snort oder Suricata. Teil 2: Installation und erste Konfiguration von Suricata.

Netzwerke zusammenführen

Die Einrichtung von IDS auf einer virtuellen Maschine kann zunächst für Tests erforderlich sein. Wenn Sie noch nie mit solchen Lösungen gearbeitet haben, sollten Sie nicht sofort dazu übergehen, physische Hardware zu bestellen und die Netzwerktopologie zu ändern. Es ist besser, das System sicher und ohne unnötige Ausgaben zu testen, um den Bedarf an Rechenressourcen zu bestimmen. Es ist wichtig zu verstehen, dass der gesamte Unternehmensverkehr über einen einzigen externen Knoten geleitet werden muss: Um ein lokales Netzwerk (oder mehrere Netzwerke) mit einem VDS, auf dem die IDS Suricata installiert ist, zu verbinden, können Sie SoftEther — ein einfach einzurichtender plattformübergreifender VPN-Server, der zuverlässige Verschlüsselung bietet. Ein Büroanschluss zum Internet hat möglicherweise keine echte IP, daher wäre es besser, ihn auf einem VPS zu betreiben. Im Ubuntu-Repository sind keine vorgefertigten Pakete verfügbar, die Software muss entweder von der Projektwebsite, oder aus einem externen Repository auf dem Service Launchpad heruntergeladen werden (wenn Sie ihm vertrauen):

sudo add-apt-repository ppa:paskal-07/softethervpn
sudo apt-get update

Die Liste der verfügbaren Pakete kann mit folgendem Befehl angezeigt werden:

apt-cache search softether

Wir benötigen softether-vpnserver (der Server wird in einer Testkonfiguration auf VDS ausgeführt) sowie softether-vpncmd – das Kommandozeilen-Tool zur Einrichtung.

sudo apt-get install softether-vpnserver softether-vpncmd

Zur Konfiguration des Servers verwenden wir ein spezielles Kommandozeilen-Tool:

sudo vpncmd

Wir werden nicht im Detail auf die Konfiguration eingehen: Der Prozess ist ziemlich einfach und gut in zahlreichen Veröffentlichungen beschrieben, sodass er nicht direkt zum Thema des Artikels gehört. Kurz gesagt, nach dem Start von vpncmd müssen Sie Punkt 1 auswählen, um zur Server-Verwaltungskonsole zu gelangen. Dazu geben Sie "localhost" ein und drücken Enter anstelle des Hub-Namens. In der Konsole wird das Administratorpasswort mit dem Befehl serverpasswordset festgelegt, der virtuelle Hub DEFAULT wird gelöscht (Befehl hubdelete), und es wird ein neuer Hub mit dem Namen Suricata_VPN erstellt, und sein Passwort wird festgelegt (Befehl hubcreate). Danach wechseln Sie mit dem Befehl hub Suricata_VPN in die Verwaltungsoberfläche des neuen Hubs, um eine Gruppe und einen Benutzer mit den Befehlen groupcreate und usercreate zu erstellen. Das Benutzerpasswort wird mit userpasswordset festgelegt.

SoftEther unterstützt zwei Verkehrstransfermodi: SecureNAT und Local Bridge. Der erste ist eine proprietäre Technologie zum Aufbau eines virtuellen privaten Netzwerks mit eigenem NAT und DHCP. SecureNAT benötigt kein TUN/TAP und keine Anpassung von Netfilter oder einer anderen Firewall. Die Routingprozesse betreffen nicht den Systemkern, sondern sind vollständig virtualisiert und funktionieren auf jedem VPS/VDS, unabhängig vom verwendeten Hypervisor. Dies kann zu einer höheren CPU-Auslastung und einer verringerten Geschwindigkeit im Vergleich zum Local Bridge-Modus führen, der den virtuellen Hub von SoftEther mit dem physischen Netzwerkadapter oder dem TAP-Gerät verbindet.

Die Konfiguration wird in diesem Fall komplizierter, da das Routing auf Kernel-Ebene über Netfilter erfolgt. Unsere VDS basieren auf Hyper-V, weshalb wir im letzten Schritt einen lokalen Bridge erstellen und das TAP-Gerät mit dem Befehl bridgecreate Suricate_VPN -device:suricate_vpn -tap:yes aktivieren. Nach dem Verlassen der Verwaltungskonsole des Hubs sehen wir in dem System eine neue Netzwerkschnittstelle, die noch keine IP zugewiesen bekommen hat:

ifconfig

Dann müssen wir das Routing von Paketen zwischen den Schnittstellen aktivieren (ip forward), falls es nicht aktiv ist:

sudo nano /etc/sysctl.conf

Kommentieren Sie die folgende Zeile aus:

net.ipv4.ip_forward = 1

Wir speichern die Änderungen in der Datei, verlassen den Editor und wenden sie mit dem folgenden Befehl an:

sudo sysctl -p

Als Nächstes müssen wir für das virtuelle Netzwerk ein Subnetz mit fiktiven IPs definieren (zum Beispiel 10.0.10.0/24) und die Adresse dem Interface zuweisen:

sudo ifconfig tap_suricata_vp 10.0.10.1/24

Dann müssen wir die Netfilter-Regeln festlegen.

1. Falls nötig, eingehende Pakete auf den abgehörten Ports erlauben (das proprietäre SoftEther-Protokoll verwendet HTTPS und Port 443)

sudo iptables -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 992 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 1194 -j ACCEPT
sudo iptables -A INPUT -p udp -m udp --dport 1194 -j ACCEPT
sudo iptables -A INPUT -p tcp -m tcp --dport 5555 -j ACCEPT

2. Wir konfigurieren NAT aus dem Subnetz 10.0.10.0/24 auf die öffentliche IP des Servers

sudo iptables -t nat -A POSTROUTING -s 10.0.10.0/24 -j SNAT --to-source 45.132.17.140

3. Wir erlauben durchgehende Pakete aus dem Subnetz 10.0.10.0/24

sudo iptables -A FORWARD -s 10.0.10.0/24 -j ACCEPT

4. Erlauben Sie durchgehende Pakete für bereits etablierte Verbindungen

sudo iptables -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPT

Die Automatisierung des Prozesses beim Neustart des Systems mithilfe von Init-Skripten überlassen wir den Lesern als Hausaufgabe.

Wenn Sie IPs automatisch an Kunden vergeben möchten, müssen Sie einen DHCP-Dienst für den lokalen Bridge einrichten. Damit ist die Serverkonfiguration abgeschlossen und Sie können zu den Clients übergehen. SoftEther unterstützt eine Vielzahl von Protokollen, deren Nutzung von den Möglichkeiten der vorhandenen Netzwerkausrüstung abhängt.

netstat -ap |grep vpnserver

Da unser Test-Router ebenfalls unter Ubuntu läuft, installieren wir aus einem externen Repository die Pakete softether-vpnclient und softether-vpncmd, um das proprietäre Protokoll zu nutzen. Wir müssen den Client starten:

sudo vpnclient start

Zur Konfiguration verwenden wir das Tool vpncmd und wählen localhost als Maschine aus, auf der vpnclient läuft. Alle Befehle erfolgen in der Konsole: Wir müssen eine virtuelle Schnittstelle (NicCreate) und ein Konto (AccountCreate) erstellen.

In einigen Fällen ist es erforderlich, die Art der Authentifizierung mit den Befehlen AccountAnonymousSet, AccountPasswordSet, AccountCertSet und AccountSecureCertSet festzulegen. Da wir kein DHCP verwenden, wird die Adresse für den virtuellen Adapter manuell festgelegt.

Darüber hinaus müssen wir das IP-Forwarding aktivieren (Parameter net.ipv4.ip_forward=1 in der Datei /etc/sysctl.conf) und statische Routen konfigurieren. Falls nötig, kann auf dem VDS mit Suricata eine Portweiterleitung für die Nutzung in einem lokalen Netzwerk eingerichtet werden. Damit ist die Netzwerkverbindung abgeschlossen.

So wird unsere vorgeschlagene Konfiguration aussehen:

Suricata konfigurieren

In im vorherigen Artikel Wir haben über zwei Betriebsmodi des IDS gesprochen: über die NFQUEUE (NFQ-Modus) und über Zero Copy (AF_PACKET-Modus). Letzterer erfordert zwei Schnittstellen, bietet jedoch eine höhere Geschwindigkeit — genau diesen werden wir nutzen. Der Parameter ist standardmäßig in /etc/default/suricata gesetzt. Außerdem müssen wir den Abschnitt vars in /etc/suricata/suricata.yaml bearbeiten, um dort das virtuelle Subnetz als Heimnetzwerk anzugeben.

Zum Neustarten des IDS verwenden wir den Befehl:

systemctl restart suricata

Die Lösung ist fertig, nun möchten Sie möglicherweise deren Widerstandsfähigkeit gegen Angriffe von Schadsoftware überprüfen.

Angriffe simulieren

Es kann mehrere Szenarien für den produktiven Einsatz des externen IDS-Dienstes geben:

Schutz vor DDoS-Angriffen (Hauptzweck)

Die Implementierung einer solchen Lösung innerhalb eines Firmennetzwerks ist komplex, da die zu analysierenden Pakete den Internet-gerichteten Anschluss des Systems erreichen müssen. Selbst wenn das IDS diese blockiert, kann parasitärer Datenverkehr die Übertragungsleitung überlasten. Um dies zu vermeiden, sollte ein VPS mit einer ausreichend leistungsfähigen Internetverbindung bestellt werden, der in der Lage ist, den gesamten Verkehr des lokalen Netzwerks sowie den gesamten externen Datenverkehr zu verarbeiten. Oft ist das einfacher und kostengünstiger als eine Erweiterung der Büroanbindung. Alternativ kann auf spezialisierte DDoS-Schutzdienste verwiesen werden. Die Kosten für deren Dienste sind vergleichbar mit den Kosten für einen virtuellen Server, wobei jedoch keine aufwendige Konfiguration erforderlich ist. Es gibt allerdings auch Nachteile: Für sein Geld erhält der Kunde lediglich DDoS-Schutz, während ein eigenes IDS beliebig konfiguriert werden kann.

Schutz vor externen Angriffen anderer Art

Suricata kann mit Versuchen umgehen, verschiedene Schwachstellen in den über das Internet zugänglichen Diensten des Unternehmensnetzwerks (wie E-Mail-Server, Webserver und Webanwendungen) auszunutzen. In der Regel wird IDS innerhalb des lokalen Netzwerks nach den Grenzgeräten installiert, jedoch ist auch eine externe Installation sinnvoll.

Schutz vor internen Bedrohungen

Trotz aller Bemühungen des Systemadministrators können Computer im Unternehmensnetzwerk mit Malware infiziert werden. Zudem gibt es manchmal Unruhestifter im lokalen Netzwerk, die versuchen, unerlaubte Aktivitäten auszuführen. Suricata kann helfen, solche Versuche zu blockieren, allerdings ist es besser, sie innerhalb des Perimeters zu installieren und in Kombination mit einem Managed Switch zu verwenden, der den Datenverkehr auf einen Port spiegeln kann. Eine externe IDS ist in diesem Fall ebenfalls nicht nutzlos — zumindest kann sie versuchen, die Versuche von im LAN lebenden Malware-Angreifern, mit externen Servern zu kommunizieren, zu erfassen.

Zunächst erstellen wir einen weiteren Test-AngriffsvPS, und auf dem Router des lokalen Netzwerks richten wir Apache mit der Standardkonfiguration ein. Danach leiten wir den Port 80 von dem IDS-Server zu ihm weiter. Anschließend simulieren wir einen DDoS-Angriff von dem angreifenden Knoten. Dazu laden wir ein kleines Programm namens xerxes von GitHub herunter, kompilieren es und starten es auf dem angreifenden Knoten (eine gcc-Paketinstallation könnte erforderlich sein):

git clone https://github.com/Soldie/xerxes-DDos-zanyarjamal-C.git
cd xerxes-DDos-zanyarjamal-C/
gcc xerxes.c -o xerxes
./xerxes 45.132.17.140 80

Das Ergebnis seiner Ausführung war folgendes:

Suricata blockiert den Angreifer, und die Standardseite von Apache öffnet sich trotz unseres improvisierten Angriffs und des recht schwachen Kanals des "Büro"- (in Wirklichkeit heimischen) Netzwerks. Für ernsthaftere Aufgaben sollten Sie Metasploit Frameworkverwenden. Es ist auf die Durchführung von Penetrationstests ausgelegt und ermöglicht die Simulation verschiedenster Angriffe. Eine Installationsanleitung finden Sie verfügbar auf der Projektwebsite. Nach der Installation ist ein Update erforderlich:

sudo msfupdate

Um zu testen, starten wir msfconsole.

Leider bietet die neueste Version des Frameworks keine Möglichkeit für automatisierte Exploits, daher müssen die Exploits manuell durchgegangen und mit dem Befehl use ausgeführt werden. Zunächst sollte man die offenen Ports auf dem angegriffenen Gerät identifizieren, beispielsweise mit nmap (in unserem Fall kann netstat auf dem angegriffenen Knoten dies gut ersetzen), und dann geeignete Module auswählen und nutzen. Metasploit-Module. 

Es gibt auch andere Tools zur Überprüfung der Widerstandsfähigkeit von IDS gegen Angriffe, einschließlich Online-Diensten. Neugierige können sogar einen Stresstest mit einer Testversion durchführen. IP Stresser. Um die Reaktion auf interne Angreifer zu überprüfen, sollten spezielle Werkzeuge auf einem der Maschinen im lokalen Netzwerk installiert werden. Es gibt zahlreiche Optionen, die regelmäßig nicht nur im Testumfeld, sondern auch in produktiven Systemen eingesetzt werden sollten, aber das ist eine ganz andere Geschichte.

Quelle: habr.com