Snort ou Suricata. Partie 3 : protéger le réseau de bureau

Dans l'article précédent Nous avons expliqué comment lancer une version stable de Suricata sur Ubuntu 18.04 LTS. Configurer un IDS sur un nœud unique et connecter des ensembles de règles gratuits est assez simple. Aujourd'hui, nous allons voir comment protéger le réseau d'entreprise contre les types d'attaques les plus courants grâce à Suricata installé sur un serveur virtuel. Pour cela, nous aurons besoin d'un VDS sous Linux avec deux cœurs de calcul. La taille de la mémoire RAM dépend de la charge : pour certains, 2 Go suffisent, tandis que pour des tâches plus sérieuses, 4 ou même 6 Go peuvent être nécessaires. L'avantage de la machine virtuelle réside dans les possibilités d'expérimentation : on peut commencer avec une configuration minimale et augmenter les ressources au fur et à mesure des besoins.

Photo : Reuters

• Snort ou Suricata. Partie 1 : choisir un IDS/IPS gratuit pour protéger le réseau d'entreprise
• Snort ou Suricata. Partie 2 : installation et configuration initiale de Suricata

Fusion des réseaux

Déployer l'IDS sur une machine virtuelle peut d'abord être nécessaire pour des tests. Si vous n'avez jamais eu affaire à de telles solutions, il n'est pas judicieux de se précipiter pour commander du matériel physique et changer l'architecture réseau. Il vaut mieux tester le système de manière sécurisée et sans dépenses superflues, afin de déterminer les besoins en ressources de calcul. Il est important de comprendre que tout le trafic d'entreprise devra passer par un seul nœud externe : pour connecter le réseau local (ou plusieurs réseaux) au VDS avec l'IDS Suricata installé, vous pouvez utiliser SoftEther — un serveur VPN multiplateforme facile à configurer, offrant un chiffrement fiable. La connexion Internet du bureau peut ne pas avoir d'IP réelle, donc il est préférable d'utiliser un VPS. Il n'y a pas de paquets préparés dans le dépôt Ubuntu, le logiciel doit être téléchargé soit depuis le site du projet, soit depuis un dépôt externe sur le service Launchpad (si vous lui faites confiance) :

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

Vous pouvez voir la liste des paquets disponibles avec la commande suivante :

apt-cache search softether

Nous aurons besoin de softether-vpnserver (le serveur en configuration de test est lancé sur VDS), ainsi que softether-vpncmd — des outils en ligne de commande pour sa configuration.

sudo apt-get install softether-vpnserver softether-vpncmd

Un utilitaire en ligne de commande spécial est utilisé pour configurer le serveur :

sudo vpncmd

Nous n'entrerons pas dans les détails de la configuration : la procédure est assez simple et elle est bien décrite dans de nombreuses publications, n'étant pas directement liée au sujet de l'article. En résumé, après le lancement de vpncmd, il faut sélectionner le point 1 pour accéder à la console de gestion du serveur. Pour ce faire, il est nécessaire de saisir le nom localhost et d'appuyer sur entrer au lieu de saisir le nom du hub. Dans la console, le mot de passe administrateur est défini avec la commande serverpasswordset, le hub virtuel DEFAULT est supprimé (commande hubdelete) et un nouveau nommé Suricata_VPN est créé, ainsi que son mot de passe (commande hubcreate). Ensuite, il faut accéder à la console de gestion du nouveau hub avec la commande hub Suricata_VPN pour créer un groupe et un utilisateur avec les commandes groupcreate et usercreate. Le mot de passe de l'utilisateur est défini avec userpasswordset.

SoftEther prend en charge deux modes de transmission du trafic : SecureNAT et Local Bridge. Le premier est une technologie propriétaire de création de réseau privé virtuel avec son propre NAT et DHCP. SecureNAT ne nécessite pas de TUN/TAP, ni de configuration de Netfilter ou d'un autre pare-feu. Le routage n'impacte pas le noyau du système, et tous les processus sont virtualisés et fonctionnent sur n'importe quel VPS/VDS, quel que soit l'hyperviseur utilisé. Cela entraîne une charge accrue sur le processeur et une diminution de la vitesse par rapport au mode Local Bridge, qui connecte le hub virtuel SoftEther à un adaptateur réseau physique ou à un dispositif TAP.

La configuration est compliquée dans ce cas, car le routage est effectué au niveau du noyau à l'aide de Netfilter. Nos VDS sont construits sur Hyper-V, donc à la dernière étape, nous créons un pont local et activons le dispositif TAP avec la commande bridgecreate Suricate_VPN -device:suricate_vpn -tap:yes. Après avoir quitté la console de gestion du hub, nous verrons dans le système une nouvelle interface réseau qui n'a pas encore d'IP attribuée :

ifconfig

Il faudra ensuite activer le routage des paquets entre les interfaces (ip forward), si ce n'est pas déjà fait :

sudo nano /etc/sysctl.conf

Décommenter la ligne suivante :

net.ipv4.ip_forward = 1

Sauvegardez les modifications dans le fichier, quittez l'éditeur et appliquez-les avec la commande suivante :

sudo sysctl -p

Ensuite, nous devons définir pour le réseau virtuel une sous-réseau avec des IP fictives (par exemple, 10.0.10.0/24) et attribuer une adresse à l'interface :

sudo ifconfig tap_suricata_vp 10.0.10.1/24

Il faudra ensuite inscrire les règles Netfilter.

1. Autoriser les paquets entrants sur les ports écoutés si nécessaire (le protocole propriétaire SoftEther utilise HTTPS et le 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. Configurer le NAT de la sous-réseau 10.0.10.0/24 vers l'adresse IP principale du serveur

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

3. Autoriser les paquets passant de la sous-réseau 10.0.10.0/24

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

4. Autoriser les paquets passants pour les connexions déjà établies

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

Nous laisserons aux lecteurs l'automatisation du processus lors du redémarrage du système à l'aide de scripts d'initialisation.

Si vous souhaitez attribuer des IP aux clients automatiquement, vous devrez également installer un service DHCP pour le pont local. La configuration du serveur est maintenant terminée et nous pouvons passer aux clients. SoftEther prend en charge de nombreux protocoles, dont l'utilisation dépend des capacités du matériel du réseau local.

netstat -ap |grep vpnserver

Étant donné que notre routeur de test fonctionne également sous Ubuntu, nous allons y installer les paquets softether-vpnclient et softether-vpncmd depuis un dépôt externe, afin de bénéficier du protocole propriétaire. Vous devrez ensuite lancer le client :

sudo vpnclient start

Pour la configuration, nous utiliserons l'outil vpncmd, en choisissant localhost comme machine sur laquelle vpnclient est en cours d'exécution. Toutes les commandes se font dans la console : il sera nécessaire de créer une interface virtuelle (NicCreate) et un compte (AccountCreate).

Dans certains cas, il est nécessaire de définir le mode d'authentification à l'aide des commandes AccountAnonymousSet, AccountPasswordSet, AccountCertSet et AccountSecureCertSet. Comme nous n'utilisons pas DHCP, l'adresse de l'adaptateur virtuel sera définie manuellement.

De plus, nous devrons activer le transfert IP (paramètre net.ipv4.ip_forward=1 dans le fichier /etc/sysctl.conf) et configurer des routes statiques. Si nécessaire, un redirectionnement de ports peut être configuré sur le VDS avec Suricata pour utiliser les services installés dans le réseau local. L'unification des réseaux peut alors être considérée comme terminée.

La configuration que nous proposons devrait ressembler à ceci :

Configurer Suricata

Dans l'article précédent Nous avons parlé des deux modes de fonctionnement d'IDS : via la file d'attente NFQUEUE (mode NFQ) et via le zero copy (mode AF_PACKET). Le second nécessite deux interfaces, mais se distingue par une performance supérieure — c'est celui que nous allons utiliser. Le paramètre est défini par défaut dans /etc/default/suricata. Nous devrons également modifier la section vars dans /etc/suricata/suricata.yaml, en spécifiant le sous-réseau virtuel comme étant local.

Pour redémarrer l'IDS, nous utilisons la commande :

systemctl restart suricata

La solution est prête, vous devrez maintenant peut-être la tester pour sa résistance aux actions des attaquants.

Modéliser des attaques

Il peut y avoir plusieurs scénarios d'application opérationnelle du service IDS :

Protection contre les attaques DDoS (principal objectif)

Réalisé ce type à l'intérieur d'un réseau d'entreprise est compliqué, car les paquets à analyser doivent atteindre l'interface de la système qui regarde vers Internet. Même si l'IDS les bloque, le trafic parasite peut saturer le canal de transmission de données. Pour éviter cela, il est nécessaire de commander un VPS avec une connexion Internet suffisamment performante pour gérer tout le trafic local et tout le trafic externe. Cela est souvent plus simple et moins coûteux que d'élargir le canal de bureau. Comme alternative, il convient de mentionner des services spécialisés pour la protection contre les DDoS. Le coût de leurs services est comparable à celui d'un serveur virtuel, sans nécessiter de configuration laborieuse, mais il y a des inconvénients : pour le prix payé, le client obtient uniquement une protection contre les DDoS, alors qu'un IDS propre peut être configuré comme bon lui semble.

Protection contre d'autres types d'attaques externes

Suricata est capable de gérer des tentatives d'exploitation de diverses vulnérabilités dans les services accessibles depuis Internet au sein d'un réseau d'entreprise (serveur de messagerie, serveur web et applications web, etc.). En général, pour cela, l'IDS est installé à l'intérieur du réseau local après les dispositifs de périmètre, mais il a également sa place à l'extérieur.

Protection contre les utilisateurs malveillants internes

Malgré tous les efforts de l'administrateur système, les ordinateurs du réseau d'entreprise peuvent être infectés par des logiciels malveillants. De plus, il arrive parfois que des fauteurs de troubles apparaissent dans le réseau local, tentant de réaliser des opérations illicites. Suricata peut aider à bloquer de telles tentatives, bien qu'il soit préférable de l'installer à l'intérieur du périmètre pour protéger le réseau interne, en l'utilisant en conjonction avec un commutateur géré capable de faire du mirroring de trafic sur un port. Une IDS externe n'est pas non plus inutile dans ce cas, car elle pourra au moins capturer les tentatives de malwares vivant dans le LAN de se connecter à un serveur externe.

Pour commencer, créons un autre VPS d'attaque de test, et sur le routeur du réseau local, faisons tourner Apache avec la configuration par défaut, puis redirigeons le port 80 vers le serveur IDS. Ensuite, nous simulerons une attaque DDoS depuis le nœud d'attaque. Pour cela, téléchargeons depuis GitHub, compilons et exécutons sur le nœud d'attaque un petit programme xerxes (l'installation du paquet gcc peut être nécessaire) :

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

Le résultat de son exécution a été le suivant :

Suricata bloque le malfaiteur, tandis que la page Apache par défaut s'ouvre malgré notre attaque improvisée et le canal plutôt faible du réseau « de bureau » (qui est en réalité domestique). Pour des tâches plus sérieuses, il est préférable d'utiliser Metasploit Framework. Il est destiné à la réalisation de tests d'intrusion et permet de simuler une grande variété d'attaques. Le guide d'installation disponible est disponible sur le site du projet. Après l'installation, une mise à jour sera nécessaire :

sudo msfupdate

Pour les tests, nous lançons msfconsole.

Malheureusement, dans les dernières versions du framework, il n'est pas possible de faire des compromises automatiques, donc les exploits devront être parcourus manuellement et lancés avec la commande use. Pour commencer, il convient de déterminer les ports ouverts sur la machine cible, par exemple à l'aide de nmap (dans notre cas, netstat sur le nœud d'attaque suffira), puis de sélectionner et utiliser les modules correspondants. modules Metasploit. 

Il existe également d'autres outils pour tester la résistance de l'IDS aux attaques, y compris des services en ligne. Par curiosité, on peut effectuer un test de stress avec la version d'essai de IP Stresser. Pour vérifier les réactions aux actions des attaquants internes, il est conseillé d'installer des outils spéciaux sur l'une des machines du réseau local. Les options sont nombreuses et il est parfois bon de les appliquer non seulement à un banc d'essai expérimental, mais aussi aux systèmes de production, mais c'est une toute autre histoire.

Source : habr.com