In Abbiamo spiegato come avviare una versione stabile di Suricata su Ubuntu 18.04 LTS. Configurare un IDS su un nodo e collegare regole gratuite è piuttosto semplice. Oggi vedremo come proteggere la rete aziendale da uno degli attacchi più comuni utilizzando Suricata installato su un server virtuale. Per questo avremo bisogno di un VDS su Linux con due core CPU. La quantità di memoria RAM dipende dal carico: per alcuni 2 GB sono sufficienti, mentre per compiti più seri possono essere necessari 4 o addirittura 6. Il vantaggio della macchina virtuale è la possibilità di sperimentare: si può partire con una configurazione minima e aumentare le risorse secondo necessità.
foto: Reuters
Unire reti
Portare l'IDS su una macchina virtuale può essere necessario prima di tutto per test. Se non hai mai avuto a che fare con soluzioni simili, non è consigliabile ordinare hardware fisico e cambiare l'architettura della rete. È meglio testare il sistema in modo sicuro e senza spese eccessive per determinare le esigenze di risorse di calcolo. È importante capire che tutto il traffico aziendale dovrà passare attraverso un unico nodo esterno: per collegare la rete locale (o più reti) al VDS con l'IDS Suricata installata, si può utilizzare un server VPN cross-platform, facile da configurare, che fornisce una crittografia affidabile. La connessione internet dell'ufficio potrebbe non avere un IP reale, quindi è meglio effettuarla su un VPS. Nel repository di Ubuntu non ci sono pacchetti pronti, il software deve essere scaricato o dal , oppure da un repository esterno del servizio (se ti fidi):
sudo add-apt-repository ppa:paskal-07/softethervpn
sudo apt-get updatePuoi visualizzare l'elenco dei pacchetti disponibili utilizzando il seguente comando:
apt-cache search softether 
Avremo bisogno di softether-vpnserver (il server in configurazione di test è in esecuzione sul VDS), oltre a softether-vpncmd – un'utilità da riga di comando per la sua configurazione.
sudo apt-get install softether-vpnserver softether-vpncmdPer configurare il server si utilizza un'apposita utilità da riga di comando:
sudo vpncmd 
Non entreremo nei dettagli della configurazione: la procedura è piuttosto semplice, ben descritta in numerose pubblicazioni e non è direttamente collegata all'argomento dell'articolo. In breve, dopo aver avviato vpncmd, è necessario scegliere l'opzione 1 per accedere alla console di gestione del server. A questo scopo, è necessario inserire il nome localhost e premere invio invece di inserire il nome del hub. Nella console, è possibile impostare la password dell'amministratore con il comando serverpasswordset, rimuovere il hub virtuale DEFAULT (comando hubdelete) e crearne uno nuovo chiamato Suricata_VPN, impostando anche la sua password (comando hubcreate). Successivamente, è necessario accedere alla console di gestione del nuovo hub utilizzando il comando hub Suricata_VPN, per creare un gruppo e un utente utilizzando i comandi groupcreate e usercreate. La password dell'utente si imposta con userpasswordset.
SoftEther supporta due modalità di trasmissione del traffico: SecureNAT e Local Bridge. La prima rappresenta una tecnologia esclusiva per la creazione di una rete privata virtuale con un proprio NAT e DHCP. SecureNAT non richiede TUN/TAP e nemmeno la configurazione di Netfilter o di un altro firewall. La routing non incide sul kernel del sistema e tutti i processi sono virtualizzati e funzionano su qualsiasi VPS/VDS, indipendentemente dal hypervisor utilizzato. Questo porta a un aumento del carico sulla CPU e a una diminuzione della velocità rispetto alla modalità Local Bridge, che collega il hub virtuale SoftEther con l'adattatore di rete fisico o il dispositivo TAP.
La configurazione in questo caso si complica, poiché la routing avviene a livello di kernel attraverso Netfilter. I nostri VDS sono costruiti su Hyper-V, quindi nell'ultimo passaggio creiamo un ponte locale e attiviamo il dispositivo TAP con il comando bridgecreate Suricate_VPN -device:suricate_vpn -tap:yes. Dopo essere usciti dalla console di gestione del hub, vedremo un nuovo'interfaccia di rete nel sistema, a cui non è ancora stato assegnato un IP:
ifconfig 
Successivamente, sarà necessario abilitare la routing dei pacchetti tra le interfacce (ip forward), se non è attivata:
sudo nano /etc/sysctl.confDecommentare la seguente riga:
net.ipv4.ip_forward = 1Salviamo le modifiche nel file, usciamo dall'editor e le applichiamo con il seguente comando:
sudo sysctl -pOra dobbiamo definire per la rete virtuale una sottorete con indirizzi IP fittizi (ad esempio, 10.0.10.0/24) e assegnare un indirizzo all'interfaccia:
sudo ifconfig tap_suricata_vp 10.0.10.1/24In seguito, sarà necessario scrivere le regole di Netfilter.
1. Se necessario, abilitare i pacchetti in ingresso sulle porte ascoltate (il protocollo proprietario SoftEther utilizza HTTPS e la porta 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 ACCEPT2. Configuriamo il NAT dalla sottorete 10.0.10.0/24 all'IP principale del server
sudo iptables -t nat -A POSTROUTING -s 10.0.10.0/24 -j SNAT --to-source 45.132.17.1403. Consentiamo il passaggio dei pacchetti dalla sottorete 10.0.10.0/24
sudo iptables -A FORWARD -s 10.0.10.0/24 -j ACCEPT4. Consentiamo il passaggio dei pacchetti per le connessioni già stabilite
sudo iptables -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPTLasceremo l'automazione del processo al riavvio del sistema utilizzando script di inizializzazione come compito a casa per i lettori.
Se desideri assegnare automaticamente gli IP ai client, dovrai anche installare un servizio DHCP per il bridge locale. A questo punto, la configurazione del server è completata e possiamo passare ai client. SoftEther supporta vari protocolli, il cui utilizzo dipende dalle capacità dell'hardware della rete locale.
netstat -ap |grep vpnserver 
Poiché il nostro router di test funziona anche con Ubuntu, installeremo i pacchetti softether-vpnclient e softether-vpncmd da un repository esterno, per sfruttare il protocollo proprietario. Dovremo avviare il client:
sudo vpnclient startPer la configurazione utilizziamo l'utilità vpncmd, selezionando localhost come macchina su cui è in esecuzione vpnclient. Tutti i comandi vengono eseguiti nella console: sarà necessario creare un'interfaccia virtuale (NicCreate) e un account (AccountCreate).
In alcuni casi è necessario specificare il metodo di autenticazione utilizzando i comandi AccountAnonymousSet, AccountPasswordSet, AccountCertSet e AccountSecureCertSet. Poiché non utilizziamo DHCP, l'indirizzo per l'adattatore virtuale viene impostato manualmente.
Inoltre, sarà necessario abilitare l'ip forward (parametro net.ipv4.ip_forward=1 nel file /etc/sysctl.conf) e configurare rotte statiche. Se necessario, su VDS con Suricata è possibile configurare il port forwarding per utilizzare i servizi installati nella rete locale. A questo punto l'unione delle reti può considerarsi completata.
La configurazione che proponiamo apparirà circa in questo modo:
Configuriamo Suricata
In Abbiamo parlato di due modalità di funzionamento dell'IDS: tramite la coda NFQUEUE (modalità NFQ) e tramite zero copy (modalità AF_PACKET). Quest'ultima richiede la presenza di due interfacce, ma offre prestazioni superiori — utilizzeremo proprio quest'ultima. Il parametro è impostato per default in /etc/default/suricata. Dobbiamo anche modificare la sezione vars in /etc/suricata/suricata.yaml, specificando la sottorete virtuale come rete locale.
Per riavviare l'IDS utilizziamo il comando:
systemctl restart suricataLa soluzione è pronta, ora potrebbe essere necessario verificarne la resistenza ad azioni malevole.
Modelliamo gli attacchi
Ci possono essere diversi scenari di utilizzo pratico del servizio IDS:
Protezione contro gli attacchi DDoS (principale scopo)
Realizzare una tale soluzione all'interno di una rete aziendale è complicato, poiché i pacchetti da analizzare devono arrivare sull'interfaccia che si affaccia su Internet del sistema. Anche se l'IDS li blocca, il traffico non desiderato può saturare la banda di trasmissione dati. Per evitare questo, è necessario ordinare un VPS con una connessione Internet sufficientemente potente, in grado di gestire tutto il traffico della rete locale e quello esterno. Spesso è più semplice ed economico fare ciò piuttosto che ampliare la banda dell'ufficio. Come alternativa, si possono menzionare servizi specializzati per la protezione da DDoS. Il costo dei loro servizi è paragonabile a quello di un server virtuale, senza la necessità di configurazioni complesse, ma ci sono anche svantaggi: con i soldi spesi il cliente ottiene solo protezione da DDoS, mentre un IDS di proprietà è configurabile come si desidera.
Protezione contro attacchi esterni di altri tipi
Suricata è in grado di gestire i tentativi di sfruttamento di varie vulnerabilità nei servizi della rete aziendale accessibili da Internet (server di posta, server web e applicazioni web, ecc.). Di solito, l'IDS viene installato all'interno della rete locale dopo i dispositivi di confine, ma ha senso anche portarlo all'esterno.
Protezione contro insider malintenzionati
Nonostante gli sforzi dell'amministratore di sistema, i computer della rete aziendale possono essere infettati da malware. Inoltre, nella rete locale possono presentarsi vandalismi che tentano di eseguire operazioni illecite. Suricata può aiutare a bloccare tali tentativi, anche se per proteggere la rete interna è meglio installarla all'interno del perimetro e utilizzarla in coppia con uno switch gestito in grado di mirrorare il traffico su una sola porta. Un IDS esterno in questo caso non è inutile: almeno sarà in grado di catturare i tentativi dei malware nella LAN di connettersi a un server esterno.
Iniziamo creando un'altra VPS di attacco di test, e sul router della rete locale configureremo Apache con la configurazione predefinita, dopo di che instraderemo la porta 80 dal server IDS. Successivamente, simuleremo un attacco DDoS dal nodo attaccante. A tal fine, scaricheremo da GitHub, compileremo e avvieremo un piccolo programma xerxes sul nodo attaccante (potrebbe essere necessaria l'installazione del pacchetto gcc):
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 80Il risultato del suo lavoro è stato il seguente:
Suricata blocca il malfattore, e la pagina Apache predefinita si apre, nonostante il nostro attacco improvvisato e il canale piuttosto debole della rete «d'ufficio» (in realtà domestica). Per compiti più seri, vale la pena utilizzare . È progettato per condurre test di penetrazione e consente di simulare vari attacchi. Le istruzioni per l'installazione sono disponibili sul sito del progetto. Dopo l'installazione, sarà necessario un aggiornamento:
sudo msfupdatePer testare, avviamo msfconsole.
Purtroppo, nelle ultime versioni del framework manca la possibilità di hackare automaticamente, quindi gli exploit devono essere scansionati manualmente e avviati con il comando use. Per iniziare, vale la pena identificare le porte aperte sulla macchina bersaglio, ad esempio, utilizzando nmap (nel nostro caso, può essere sostituito da netstat sul nodo bersaglio), e poi trovare e utilizzare i .
Esistono anche altri strumenti per verificare la resilienza degli IDS agli attacchi, inclusi servizi online. Per curiosità, si può fare un test di stress utilizzando la versione di prova Per verificare la reazione alle azioni di insider malintenzionati, è consigliabile installare strumenti speciali su una delle macchine della rete locale. Ci sono molte opzioni e vale la pena applicarle non solo al campo di esperimento, ma anche ai sistemi di lavoro, ma questa è un'altra storia.
Fonte: habr.com
