In Abbiamo descritto come avviare una versione stabile di Suricata su Ubuntu 18.04 LTS. Configurare l'IDS su un nodo e collegare i set di regole gratuiti è abbastanza semplice. Oggi vedremo come proteggere la rete aziendale contro i più comuni tipi di attacchi utilizzando Suricata installata su un server virtuale. Avremo bisogno di un VDS su Linux con due core di elaborazione. La quantità di memoria RAM dipende dal carico: per qualcuno, 2 GB sono sufficienti, mentre per compiti più seri potrebbero essere necessari 4 o addirittura 6 GB. Il vantaggio della macchina virtuale è la possibilità di sperimentare: è possibile iniziare con una configurazione minima e aumentare le risorse secondo necessità.
foto: Reuters
Unire reti
L'implementazione di IDS su una macchina virtuale può essere necessaria per condurre dei test. Se non hai mai avuto a che fare con soluzioni simili, non è consigliabile precipitarsi a ordinare hardware fisico e cambiare l'architettura della rete. È meglio testare il sistema in modo sicuro e senza spese aggiuntive, per determinare le esigenze in termini di risorse computazionali. È importante capire che tutto il traffico aziendale dovrà passare attraverso un'unica interfaccia esterna: per connettere la rete locale (o più reti) al VDS con IDS Suricata, puoi utilizzare — un server VPN multipiattaforma facile da configurare, che offre una crittografia sicura. La connessione a Internet dell'ufficio potrebbe non avere un IP reale, quindi è meglio configurarla su un VPS. Nel repository di Ubuntu non ci sono pacchetti pronti, quindi dovrai scaricare il software dal , oppure da un repository esterno sul 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 su VDS), così come di 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 ci dilungheremo sulla configurazione: la procedura è piuttosto semplice ed è ben documentata in numerose pubblicazioni, e non rientra direttamente nell'argomento dell'articolo. In breve, dopo aver avviato vpncmd, è necessario selezionare l'opzione 1 per accedere alla console di gestione del server. Per fare ciò, bisogna inserire localhost e premere invio invece di inserire il nome dell'hub. Nella console si imposta la password dell'amministratore con il comando serverpasswordset, si elimina l'hub virtuale DEFAULT (comando hubdelete) e si crea un nuovo hub chiamato Suricata_VPN, assegnandogli anche una password (comando hubcreate). Successivamente, bisogna passare alla console di gestione del nuovo hub utilizzando il comando hub Suricata_VPN, per creare un gruppo e un utente con i comandi groupcreate e usercreate. La password dell'utente è impostata utilizzando il comando userpasswordset.
SoftEther supporta due modalità di trasmissione del traffico: SecureNAT e Local Bridge. La prima è una tecnologia proprietaria per la creazione di una rete privata virtuale con il proprio NAT e DHCP. SecureNAT non richiede TUN/TAP, né la configurazione di Netfilter o di un altro firewall. Il routing non influisce sul kernel del sistema, mentre tutti i processi sono virtualizzati e funzionano su qualsiasi VPS/VDS indipendentemente dal hypervisor utilizzato. Questo comporta un maggiore carico sulla CPU e una riduzione della velocità rispetto alla modalità Local Bridge, che collega l'hub virtuale SoftEther con l'adattatore di rete fisico o il dispositivo TAP.
La configurazione in questo caso si complica poiché il routing avviene a livello di kernel tramite 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 aver lasciato la console di gestione dell'hub, vedremo nel sistema una nuova interfaccia di rete, alla quale non è ancora stato assegnato un IP:
ifconfig 
Dobbiamo abilitare il routing dei pacchetti tra le interfacce (ip forward) se non è già attivo:
sudo nano /etc/sysctl.confDecommentare la seguente riga:
net.ipv4.ip_forward = 1Salviamo le modifiche al file, usciamo dall'editor e le applichiamo con il seguente comando:
sudo sysctl -pSuccessivamente, dobbiamo definire per la rete virtuale una subnet 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/24Dopo di che, sarà necessario impostare le regole di Netfilter.
1. Se necessario, consentire i pacchetti in entrata sulle porte in ascolto (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 subnet 10.0.10.0/24 all'indirizzo 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 i pacchetti in transito dalla subnet 10.0.10.0/24
sudo iptables -A FORWARD -s 10.0.10.0/24 -j ACCEPT4. Consentiamo i pacchetti in transito per le connessioni già stabilite
sudo iptables -A FORWARD -p all -m state --state ESTABLISHED,RELATED -j ACCEPTLasciamo ai lettori l'automazione del processo durante il riavvio del sistema tramite script di inizializzazione come compito.
Se desideri assegnare automaticamente indirizzi IP ai client, dovrai anche installare un servizio DHCP per il ponte locale. A questo punto, la configurazione del server è completa e puoi passare ai client. SoftEther supporta diversi protocolli, la cui utilizzazione dipende dalle capacità dell'hardware della rete locale.
netstat -ap |grep vpnserver 
Poiché anche il nostro router di test gira su Ubuntu, installeremo da un repository esterno i pacchetti softether-vpnclient e softether-vpncmd, per sfruttare il protocollo proprietario. Dobbiamo 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 attivare l'ip forwarding (parametro net.ipv4.ip_forward=1 nel file /etc/sysctl.conf) e configurare le route statiche. Se necessario, su VDS con Suricata, si possono configurare le porte per consentire l'accesso ai servizi installati nella rete locale. A questo punto, l'unione delle reti può considerarsi completata.
La configurazione che proponiamo avrà un aspetto simile a questo:
Configurazione di Suricata
In Abbiamo parlato di due modi di funzionamento dell'IDS: tramite la coda NFQUEUE (modalità NFQ) e tramite zero copy (modalità AF_PACKET). La seconda richiede la presenza di due interfacce, ma offre prestazioni superiori; utilizzeremo proprio questa. Il parametro è impostato di default in /etc/default/suricata. Dobbiamo anche modificare la sezione vars in /etc/suricata/suricata.yaml, inserendo lì la sottorete virtuale come quella domestica.
Per riavviare l'IDS utilizziamo il comando:
systemctl restart suricataLa soluzione è pronta, ora potrebbe essere necessario verificarne la resistenza agli attacchi di malintenzionati.
Simuliamo attacchi
Ci sono diversi scenari di utilizzo del servizio IDS:
Protezione contro gli attacchi DDoS (principale scopo)
Implementare una soluzione del genere all'interno di una rete aziendale è complicato, poiché i pacchetti da analizzare devono raggiungere l'interfaccia del sistema che guarda verso Internet. Anche se l'IDS li blocca, il traffico indesiderato può saturare il canale di trasmissione dati. Per evitarlo, è necessario ordinare un VPS con una connessione Internet sufficientemente performante, capace di gestire tutto il traffico della rete locale e quello esterno. Spesso è più semplice e meno costoso rispetto all'ampliamento della connessione dell'ufficio. Come alternativa, è utile menzionare i servizi specializzati per la protezione contro gli attacchi DDoS. Il costo dei loro servizi è comparabile a quello di un server virtuale, senza necessità di una complessa configurazione, ma ci sono anche svantaggi: con il proprio investimento, il cliente ottiene solo protezione DDoS, mentre un IDS personale può essere configurato a piacimento.
Protezione da altri tipi di attacchi esterni
Suricata è in grado di affrontare i tentativi di sfruttamento di diverse vulnerabilità nei servizi accessibili da Internet della rete aziendale (server di posta, server web e applicazioni web, ecc.). Di solito, per questo, l'IDS viene installato all'interno della rete interna dopo i dispositivi di confine, ma anche l'installazione all'esterno ha il suo legittimo diritto.
Protezione contro gli intrusi interni
Nonostante tutti gli sforzi dell'amministratore di sistema, i computer della rete aziendale possono essere infettati da malware. Inoltre, all'interno della rete interna a volte possono apparire teppisti che tentano di eseguire alcune operazioni illecite. Suricata può aiutare a bloccare tali tentativi; tuttavia, per proteggere la rete interna, è meglio installarla all'interno del perimetro e utilizzarla in coppia con uno switch gestito capace di mirrorare il traffico su una porta. Anche un IDS esterno in questo caso non è inutile: almeno sarà in grado di catturare i tentativi di malware che risiedono nella LAN di contattare un server esterno.
Iniziamo creando un altro VPS attaccante di test, mentre sul router della rete locale avviamo Apache con la configurazione di default, dopodiché apriremo la porta 80 sul server IDS. Proseguiremo quindi simulando un attacco DDoS dal nodo attaccante. A tal fine, scaricheremo da GitHub, compileremo e avvieremo sul nodo attaccante un piccolo programma chiamato xerxes (potrebbe essere necessario installare il 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 l'aggressore, mentre la pagina Apache di default si apre, nonostante il nostro attacco improvvisato e il canale piuttosto debole della rete "d'ufficio" (in realtà domestica). Per compiti più seri, è consigliabile utilizzare . È progettato per effettuare test di penetrazione e consente di simulare vari tipi di attacchi. Le istruzioni per l'installazione sono disponibili sul sito del progetto. Dopo l'installazione, sarà necessario eseguire un aggiornamento:
sudo msfupdatePer testare, avviamo msfconsole.
Purtroppo, nelle ultime versioni del framework non è presente la possibilità di exploit automatici, quindi gli exploit devono essere eseguiti manualmente con il comando use. Innanzitutto, è utile identificare le porte aperte sulla macchina bersaglio, ad esempio usando nmap (nel nostro caso, netstat sulla macchina bersaglio è una valida alternativa), e poi selezionare e utilizzare i moduli appropriati. .
Esistono anche altri strumenti per testare la resilienza degli IDS agli attacchi, inclusi servizi online. Per curiosità, è possibile eseguire uno stress test utilizzando una versione di prova di . Per monitorare la reazione a potenziali attacchi interni, è consigliabile installare strumenti specifici su una delle macchine della rete locale. Ci sono molte opzioni e dovrebbero essere applicate non solo nell'ambiente di test, ma anche nei sistemi di produzione, sebbene questa sia un'altra storia.
Fonte: habr.com
