Configuration du réseau et de pfSense dans vSphere 6.5

Chap 1. Configuration d’un serveur DNS-DHCP avec Zentyal
Chap 2. Installation de vSphere 6.5 dans Proxmox
Chap 3. Nested ESXi – ESXi imbriqué dans un autre ESXi
Chap 4. Configuration du réseau et de pfSense dans vSphere 6.5
Chap 5. FreeNAS – Configuration d’un serveur NFS avec VMware vSphere 6.5
Chap 6. FreeNAS – Configuration d’un SAN iSCSI avec VMware vSphere 6.5
Annexe. Topologie complète avec les icones de VMware

Chap 4. Configuration du réseau et de pfSense dans vSphere 6.5

 

I. Reconfiguration des différents serveurs, physique et virtuels

Le chapitre précédent présente la base du lab à créer. Cependant, je ne le trouve pas parfait et il y a encore quelques améliorations qu’on peut y ajouter. Entre autre, il n’y a plus besoin d’accéder à vCenter directement en dehors du lab et se fier à notre parefeux qui fait office de passerelle (pfSense).

Concernant l’installation de pfSense, je vous recommande de lire la documentation. Il n’y a pas grand chose à faire, à part accepter toutes les options proposées, et de les laisser tel quelles en gardant tout par défaut.

1. Ajout d’un nouvel adapter pour l’ESXi physique

Jusqu’ici, la gestion de l’ESXi host se fait à partir du réseau physique en 127.X.Y.Z. Afin d’éviter au vCenter de passer par multiple réseau afin de gérer cet hôte, j’ai décidé d’ajouter ce dernier dans le même réseau que le vCenter.

L’hôte physique ESXi a donc besoin d’un adapteur (carte réseau virtuelle) pour pouvoir communiquer avec le réseau du lab en 192.168.1.0/24.

Pour celà,

  • Créer un nouveau port group que j’ai appelé « ESXi host mgt », dans vSwitch1. Vous pouvez l’appeler autrement
  • Ne pas attacher une carte physique au port nouvellement créé. Il n’y en a pas besoin vu que tout le traffic passera par pfSense

Pour rappel, toutes les machines virtuelles se trouvent aussi dans le réseau géré par vSwitch1, c’est pour celà que j’ai choisi cette option pour ajouter notre hôte auquel j’ai assigné l’adresse IP 192.168.1.111.

Verifier que vous pouvez y acceder à la gestion de l’ESXi physique à partir de n’importe quel VM du réseau 192.168.1.0.

Une fois que l’hôte est joignable par le vCenter, il faut le supprimer de l’inventaire de ce dernier pour l’ajouter avec l’adresse IP dans le même réseau que le vCenter lui même.

2. Déconnecter l’hôte

Pour ce faire, sélectionner l’ESXi physique puis sélectionner Déconnecter avant de cliquer sur Supprimer de l’inventaire du vCenter.

3. Reconnecter l’hôte

Une fois c’est fait, rajouter l’hôte en utilisant l’adresse IP du réseau du lab, ici 192.168.1.111.

4. Supprimer les adapteurs non utilisés des différents VMs

Vu que tout notre traffic passera par pfSense, vous pouvez supprimer l’adapter VM network pour chacunes des VMs qui l’utilisent.

Dans vSwitch0, pfSense devrait être la seule machine virtuelle à y être présente.

Pourquoi s’embêter à faire toutes ces étapes, alors qu’on aurait pu le faire depuis le précédent chapitre? Je vous rappelle que ceci est une initiation à l’utilisation de l’environement vSphere. En passant par toutes ces étapes, celà m’a permis de mieux comprendre comment s’y prendre pour créer un lab fonctionnel.

II. Configurer pfSense

Une fois pfSense installé, il s’autoconfigure en questionnant votre DHCP.

S’il n’arrive pas à récupérer une adresse IP, ce n’est pas grave. Vous pouvez le faire manuellement.

Un petit conseil, vu qu’il y a deux cartes et que vous ne saurez pas laquelle qui est attachée à quelle interface, je vous conseille de ne configurer qu’une interface à la fois. Une fois ceci fait, et que tout marche bien, vous pouvez ensuite configurer en toute sécurité l’autre interface.
Un autre conseil, si ce n’est pas la bonne carte qui est attachée à l’interface du pfSense, au lieu de configurer l’interface avec l’option 1, modifier l’interface directement au niveau de la configuration de la machine virtuelle. C’est comme çà que vous devrez procéder pour tout problème d’interface.

Une fois que vous avez accès à l’interface de gestion du pfSense, les identifiants par défaut sont: admin/pfsense.

1. Système

Dans System>General Setup,

  • Dans le champ hostname, j’ai donné le nom de la VM, avec pour domaine « mylab.local » qui est le nom de domaine que j’utilise via Zentyal
  • Pour la partie DNS Serveurs, vu que j’utilise un des labs de mon entreprise, je dois ajouter l’adresse IP du DNS forwarder qui est un serveur DNS dans le même réseau que l’ESXi physique, sans oublier de rajouter mon domaine local. Aussi je dois préciser la passerelle pour accéder à internet.

2. Interfaces

Configurer l’interface WAN, avec l’adresse IP que vous voulez utiliser pour accéder à pfSense sur le réseau local du lab.

Très important, décocher l’option « block private network », sinon vous n’aurez pas accès au pfsense en dehors de votre lab.

En ce qui concerne l’interface LAN, il n’y a pas grand chose à modifier à part qu’il faut choisir une interface statique.

3. Parefeux

Je vais simplifier les règles du parefeux pour avoir accès à mon environment. En entreprise, il faut prendre toutes les précautions afin de ne pas exposer votre réseau par inadvertance à d’enventuel accès de l’extérieur.

Une fois ces règles appliquées, vous devriez avoir deux règles au total.

 

III. Configuration de réseau pour la préparation à la connection avec freeNAS

Dans cette partie, je vais préparer et configurer les différents switchs des ESXi embarqués (nested ESXi) afin de pouvoir accéder au serveur de données freeNAS.

Après l’installation de l’ESXi, vous ne devriez avoir qu’un seul switch de disponible (vswitch0). Je vais garder ce switch pour la communication des différents VM que je vais ajouter à cet hôte embarqué.

De ce fait, je vais créer un nouveau switch pour la communication entre l’hôte embarqué et freeNAS.

Dans les configurations au niveau du Virtual Switch, sélectionner Add Host networking.

Ensuite, choisissez l’option VMkernel Network Adapter.

Et c’est à ce niveau que vous pouvez créer un nouveau switch virtuel.

Sélectionner ensuite les trois carters réseaux, un pour NFS et les deux autres pour le traffic iSCSI.

1. Création d’un switch virtuel et ajout du premier port group pour les traffics iSCSIs

Vu qu’il y a deux cartes pour les traffics iSCSI, il va falloir ajouter deux ports groupes, iSCSI1 et iSCSI2.

Appliquer une adresse IP statique à ce port.

Le traffic iSCSI1 passera par le réseau 172.16.10.0/24, et celui de iSCSI2 par 172.16.20.0/24.


Vérifier que tout est bon avant de valider la création de vswitch1 ainsi que du port group iSCSI1.


Assigner l’un des adapteurs physiques au port group nouvellement créé.

L’idée ici est de ne faire passer qu’un type de traffic par adapteur physique.

Editer les configurations de l’iSCSI1.


Garder toutes les options par défaut, par contre au niveau du Teaming and Failover, sélectionner Override, puis déplacer les adapteurs non utilisé pour ce traffic dans Unused Adapter.


Vérifier ensuite que le port groupe iSCI1 n’est connecté qu’à un seul adapteur physique.

Ce n’est pas tout, éditer ensuite la configuration de l’adapteur physique pour changer la MTU en 9000 (jumbo frame), puisqu’on va configurer de même les interfaces de freeNAS.


Modifier de ce fait le vmkernel adapteur de l’iSCSI1 afin d’accepter les jumbo frames.

2. Ajout du deuxième port group pour traffic iSCSI et du troisième pour le traffic NFS

Il suffit de suivre les mêmes étapes que précédement.


Par contre, il n’y a plus besoin de créer un nouveau switch virtuel. On va utiliser vswitch1.


Je ne vais pas refaire toute les étapes pour ajouter le port groupe iSCSI2. Revoyez les étapes ci-dessus.

Créer le port group NFS pour les traffics NFS.


Tous les serveurs qu’un réseau devrait avoir une adresse IP statique et non dynamique.

Le traffic NFS passera par le réseau 172.31.255.0/24.


Editer ensuite le port group NFS pour utiliser l’adapteur qui lui est dédié.


Configurer le vmkernel (vmk3) avec un MTU de 9000 pour les jumbo frames.

 

Et voilà, je pense que c’est l’une des parties les plus « dure » du lab. Une fois le réseau est configuré comme il faut, vous devriez être bon pour la suite.

Publicités

Sécuriser votre RPi

Chap 1. Prise en main du RPi et installation de Mate sur un Raspbian
Chap 2. Installation de OwnCloud sur un Raspberry Pi
Chap 3. Sécuriser votre RPi
Chap 4. Accès au serveur Web server à partir de son nom de domaine
Chap 5. Connection SSH
Chap 6. Les fichiers journaux
Chap 7. Let’s Encrypt (LE)
Chap 8. Ajout d’un disque dur externe et migration de données
Chap 9. Suppression et ajout d’une interface graphique
Chap 10. Rappel sur les différentes étapes pour mettre en place un server dédié à Owncloud

Chap 3. Sécuriser votre RPi

Pour sécuriser le RPi, il nous faut:

1. Créer un utilisateur autre que Pi
2. Créer une connection sécurisée entre votre ordinateur et le RPi
3. Désactiver l’authentification SSH par mot de passe ainsi que la connection en tant que Root
4. Créer des règles de parefeux
5. Installer Fail2ban

Comme toujours, lisez l’article jusqu’au bout avant d’effectuer des modifications sur votre(vos) appareil(s).

I. Création d’un nouvel utilisateur Pi

Vous l’avez surement remarqué que le système d’exploitation Raspbian, a deux utilisateurs par défaut: root et pi. Pour plus de sécurité, mieux vaut désactiver ces deux comptes, et d’en créer un qui aura les mêmes permissions que root en utilisant la commande « sudo ».

Création du nouvel utilisateur

Méthode 1:

Lancer une connection ssh avec l’utilisateur pi, le temps d’activer temporairement le compte root puisque ce dernier est inactif par défaut.

Le format pour se connecter en ssh à partir d’un terminal sous linux est de la forme « ssh pi@ ».

mon@ordi$ ssh pi@10.1.2.3

Puis taper la commande ci-dessous et entrer deux fois le mot de passe pour l’utilisateur root.

pi@raspberrypi:~$ sudo passwd
Enter new UNIX password: 
Retype new UNIX password:
pi@raspberrypi:~$ exit

Après avoir fermée la connection ssh, relancez-en une nouvelle en vous connectant cette fois-ci avec l’utilisateur root.

mon@ordi$ ssh root@10.1.2.3

La commande suivante permet de renommer l’utilisateur pi  (option -l) par le nom d’utilisateur de votre choix. Ici; j’ai décidé d’appeler mon utilisateur « USERNAME », puis créer un nouvel espace /home (option -d) et d’y placer le contenu de l’ancien /home (option -m).

root@raspberrypi:~# su -
root@raspberrypi:~# usermod -l USERNAME -d /home/USERNAME -m pi 
root@raspberrypi:~# groups USERNAME 
USERNAME : pi adm dialout cdrom sudo audio video plugdev games users input netdev spi i2c gpio root@raspberrypi:~# sudo groupmod -n USERNAME pi

La commande groupmod permet de remplacer le nom du groupe initialement associé à USERNAME, qui est « pi », par USERNAME. Pour rappel, généralement sous linux, le nom d’utilisateur et le nom du groupe sont identique.

root@raspberrypi:~# groups USERNAME
USERNAME : USERNAME adm dialout cdrom sudo audio video plugdev games users input netdev spi i2c gpio

La commande utilisée avec « usermod », peut se décomposer en deux étapes:

1. Renommer pi par USERNAME

root@raspberrypi:~# usermod -l USERNAME pi

2. Supprimer le /home/pi après avoir déplacé son contenu dans /home/USERNAME (option -d -m)

pi@raspberrypi:~$ usermod -d /home/USERNAME -m pi

Ci-dessous les quelques messages d’erreur que j’ai rencontré, mais je ne vais pas trop tarder dessus.

root@raspberrypi:~# usermod -l USERNAME -d /home/USERNAME -m pi
bash: usermod: command not found

Lancer la commande « su – » pour se placer dans le même environnement que root.

Ensuite, tuer le process utilisé par l’utilisateur PI lors de sa connection en mode GUI, sinon vous risquez d’avoir une erreur du type:

root@raspberrypi:~# su -
root@raspberrypi:~# usermod -l USERNAME -d /home/USERNAME -m pi
usermod: user pi is currently used by process 1234
root@raspberrypi:~# ps -lp 1234
F S   UID   PID  PPID  C PRI  NI ADDR SZ WCHAN  TTY          TIME CMD
4 S  1000  4146  4141  0  80   0 - 12556 poll_s ?        00:00:00 x-session-manag
root@raspberrypi:~# kill 4146


Méthode 2:

Cette deuxième méthode demande un peu plus d’étapes à suivre, pour arriver aux mêmes fins que précédement. Cependant, il n’est pas nécessaire d’activer le compte root pour l’ajout et la suppression d’utilisateurs. De ce fait, vous pouvez vous connecter directement en ssh avec l’utilisateur pi.

mon@ordi$ ssh pi@10.1.2.3

1. Création d’un nouvel utilisateur

$ sudo adduser USERNAME
$ sudo adduser USERNAME sudo

Vérifier que USERNAME fait bien du groupe « sudo ».

$ groups USERNAME
USERNAME : USERNAME adm dialout cdrom sudo audio video plugdev games users input netdev spi i2c gpio

Fermer la session pour l’ouvrir de nouveau, en vous connectant cette fois-ci avec le nouvel utilisateur .

mon@ordi$ ssh USERNAME@10.1.2.3

Pour information, le groupe SUDO n’a pas de “pouvoirs” (permissions) particuliers. C’est un groupe comme un autre. Par contre, il est spécifié dans /etc/sudoers, que tous les membres de ce groupe peuvent avoir les mêmes permissions que root lorsque la commande sudo est évoquée.
Pour vérifier cette information, taper visudo dans une console.

Nano étant le mode d’édition utilisé par défaut, si vous préférez un éditeur, lancer la commande update-alternatives pour faire votre choix.

sudo update-alternatives --config editor

Mon choix se limite à Vim, et donc je passe par une commande plus directe.

sudo update-alternatives --set editor /usr/bin/vim.tiny

Lancer maintenant visudo:

sudo visudo

Je tiens à préciser qu’il est fortement déconseillé de modifier directement le contenu de /etc/sudoers, sans passer par la commande visudo.

La ligne qui nous intéresse:

# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL

Je vous renvoie sur cette page pour plus d’information concernant cette ligne.
2. Vérification

Vérifier que les utilisateurs USERNAME et pi font parti des mêmes groupes avant de supprimer définitivement ce deuxième.

$ groups pi
$ groups USERNAME

S’il manque des groupes au nouvel utilisateur, n’hésitez pas à en rajouter avec la commande:

$ sudo usermod -a -G  USERNAME

3. Suppression de l’utilisateur Pi

N’oubliez pas que parmis les choix possible de ce que vous pouvez faire avec cet utilisateur pi. Le mien est de le supprimer définitivement ainsi que de le dossier home associé.

sudo deluser --remove-home USERNAME

Pour supprimer tous les fichiers ayant appartenu à cet utilisateur (je vous déconseille de le faire à moins que vous sachiez exactement ce que vous faites),

sudo deluser --remove-all-files USERNAME

4. Redémarrer le Raspi

Et voilà. Il nous a fallu quatre étapes, pour faire plus ou moins la même chose qu’avec la méthode 1.

Avant de clôturer ce chapitre, je tiens à vous préciser qu’en utilisant un système debian, il est fortement conseillé d’utiliser les commandes adduser/deluser au lieu des commandes généralement trouvées sur les autres distributions linux, que je ne vais pas citer ici afin de réduire les risques de confusions.

Désactivation/activation du compte Root

Maintenant qu’avec le nouvel utilisateur, on peut utiliser sudo, vous pouvez désactiver le compte Root si ce n’est déjà fait.

Supprimer le mot de passe du compte root (option -d, –delete), puis le vérouiller ensuite avec l’option -l (–lock).

$ sudo passwd -dl root
passwd: password expiry information changed.

Verification:

$ su -
Password:
su: Authentication failure

Pour lancer un shell en mode root, utiliser plutôt l’option -s  avec sudo (similaire à “sudo su”) au lieu de l’option -i (similaire à sudo su -). Le premier garde les informations actuel du shell, par contre la deuxième option vous envoie dans l’environement du root. Cette deuxième option est à déconseiller puisque vous allez perdre les bénéfices de sécurité offerts par sudo.

sudo -s

Si, pour une raison quelconque, vous avez besoin d’activer l’utilisateur root, l’option -u (–unlock) fera l’affaire.

$ sudo passwd -u root

Pour donner un mot de passe à l’utilisateur root,

$ sudo passwd root

II. Connection sécurisée

Je vous recommande vivement de lire l’article SSH Tutorial for Linux. Pour plus d’information sur le SSH et sur ce qu’on va faire par la suite, je vous renvoie sur le site officiel de Debian, ainsi que de lire les bonnes pratiques pour l’utilisation de SSH.

Pour créer une connection de type sécurisée, entre votre machine et le RPi, nous allons utiliser le système d’authentification SSH par clé plutôt que par mot de passe. Pour ce faire, générer une paire de clé (une privée, et une autre publique) à partir du poste qui va se connecter en ssh au RPi. Puis, envoyer une copie de la clé publique sur notre serveur RPi. Garder ensuite précieusement et loin de tout regards indiscrets, votre clé privée.

La méthode d’authentification par paire de clés a pour avantage de limiter les attaques par force brute de votre mot de passe, pour l’authentification au RPi.

Côté client

Sur votre ordinateur, vérifier que le paquet openssh-client est bien installé. Si ce n’est pas le cas, il faut le faire.

mon@ordi$ dpkg -l | grep ssh
mon@ordi$ sudo apt-get install openssh-client

Générer une paire de clés avec l’utilitaire SSH keygen.

mon@ordi$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/matakasi/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:

N’ommetez pas la passphrase, qui est une forme de sécurité supplémentaire. Si quelqu’un réussit à s’approprier vos clés, il lui faut toujours entrer cette passphrase pour pouvoir se connecter à votre Serveur.

Pour bien choisir son mot de passe, je vous conseille de lire cet article.

Les clés générées devraient se trouver dans le répertoire ~/.ssh:
– clé privée: id_rsa (vous devez ne jamais fournir cette clé à personne)
– clé publique: id_rsa.pub.

Copier la clé publique sur l’hôte distant (RPi) avec la commande ssh-copy-id.

mon@ordi$ ssh-copy-id -i ~/.ssh/id_rsa.pub USERNAME@10.1.2.3

Le fichier .ssh/authorized_keys sera créé automatiquement suite à cette commande. Pour voir son contenu,

mon@ordi$ ssh USERNAME@10.1.2.3
USERNAME@raspberrypi$ cat ~/.ssh/authorized_keys

Le fichier /home/.ssh/authorized_keys est le fichier contenant les clés publiques permettant à un utilisateur de s’authentifier à l’aide de sa clé privée.

Côté Serveur

Vérifier que openssh-server est déjà installé ou non.

USERNAME@raspberrypi$ aptitude search ssh-server

Si ce n’est pas le cas,

USERNAME@raspberrypi$ sudo apt-get install openssh-server

Modifier ensuite les permissions du dossier /home/.ssh si vous n’avez pas les mêmes informations que ci-dessous.

USERNAME@raspberrypi$ ls -al | grep .ssh
drwx------ 2 USERNAME USERNAME 4096 Feb 23 00:14 .ssh

USERNAME@raspberrypi$ ls -al .ssh/authorized_keys
-rw------- 1 USERNAME USERNAME 397 Feb 23 00:14 .ssh/authorized_keys

Vous ne devriez pas avoir à modifier quoi que ce soit concernant les permissions, mais si vous n’avez pas les mêmes permissions que moi, vous pouvez toujours mettre à jour vos permissions avec la commande chmod.

sudo chmod 700 .ssh
sudo chmod 600 .ssh/authorized_keys

III. Désactivation du mot de passe pour l’autentification SSH et du compte Root

sudo vim /etc/ssh/sshd_config

Rechercher les informations PasswordAuthentication puis PermitRootLogin, et de remplacer leurs valeurs par « no ».

#Désactiver l’utilisation du mot de passe pour l’authentification
PasswordAuthentication no

#Désactiver l’utilisation du compte root
PermitRootLogin no

Relancer ensuite le serveur SSH.

sudo service ssh restart

IV. Creating a Firewall

Maintenant, il nous faut ajuster les paramètres du parefeux pour limiter/bloquer certain traffics vers le RPi.

Vérifier quelles sont les règles actuelles de votre parefeux sur le RPi

sudo iptables -L

Par défaut, vous ne devriez pas avoir de règles du tout. Tout traffic devrait être autorisé,

Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

 

Créer un fichier pour y placer les règles du parefeux

sudo vim /etc/iptables.firewall.rules

Copier les règles ci-dessous dans /etc/iptables.firewall.rules.

*filter

# Allow all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 -j REJECT

# Accept all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allow all outbound traffic - you can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

# Allow HTTP and HTTPS connections from anywhere (the normal ports for websites and SSL).
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# Allow RDP connections from anywhere (uncomment if rdp connection is needed)
# -A INPUT -p tcp --dport 3389 -j ACCEPT

# Allow SSH connections
# The -dport number should be the same port number you set in sshd_config
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT

# Allow ping
-A INPUT -p icmp --icmp-type echo-request -j ACCEPT

# Log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Drop all other inbound - default deny unless explicitly allowed policy
-A INPUT -j DROP
-A FORWARD -j DROP

COMMIT

Vous pouvez supprimer le commentaire au niveau du RDP (3389), si vous avez besoin d’accéder à l’interface graphique du RPi. Les règles appliquées ci-dessus autorise les traffics en HTTP (80), HTTPS (443), SSH (22), ainsi que les ping.

 

Activer les nouvelles règles du parefeux

sudo iptables-restore < /etc/iptables.firewall.rules

Vérifier de nouveau que les nouvelles règles sont actifs.

sudo iptables -L

Vous devriez maintenant avoir quelque chose de similaire.

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             loopback/8           reject-with icmp-port-unreachable
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:https
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:3389
ACCEPT     tcp  --  anywhere             anywhere             state NEW tcp dpt:ssh
ACCEPT     icmp --  anywhere             anywhere             icmp echo-request
LOG        all  --  anywhere             anywhere             limit: avg 5/min burst 5 LOG level debug prefix "iptables denied: "
DROP       all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
DROP       all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere 

 

Activation automatique des règles du parefeux

Vous devriez vous assurer que ces règles sont toujours activées à chaque fois que vous redémarrer le RPi. Pour ce faire, nous allons créer un script pour automatiser la tâche.

sudo vim /etc/network/if-pre-up.d/firewall

Copier les lignes ci-dessous:

#!/bin/sh
/sbin/iptables-restore < /etc/iptables.firewall.rules

Puis modifier les permissions de ce fichier.

sudo chmod +x /etc/network/if-pre-up.d/firewall

V. Installation et Configuration de Fail2Ban

Fail2Ban est un très bon outil pour détecter les tentatives de connection sur vos serveurs. Une fois une intrusion détectée, après un nombre défini de tentative de connection, Fail2Ban va créer automatiquement une règle dans iptable pour bannir l’adresse IP de l’intrus (blacklister).

Fail2Ban se trouve dans les dépots officiels de Debian. Pour l’installer,

sudo apt-get install fail2ban

Une fois l’installation terminée, il n’y a rien de plus à faire, à part vérifier dans les logs dans /var/log/fail2ban.log les informations enregistrées par l’application.
Pour information, Fail2Ban surveille uniquement les traffics pour le protocol SSH par défaut. Mais vous pouvez le configurer afin de superviser les tentatives de connections à votre serveur pour d’autres protocols tel HTTP, RDP, SMTP, etc.

 

Notes:

How do I change pi’s username?
How can I add a new user as sudoer using the command line?
How to properly configure sudoers file, on debian wheezy?
How to add self to sudoers list?
Allowing other users to run sudo
Add a User to a Group (or Second Group) on Linux
How to change owner and group of a file in Linux
Raspberry Pi Home Server: Part 4, Web Administration
A Complete Guide to Usage of ‘usermod’ command – 15 Practical Examples with Screenshots
What do the “ALL”s in the line “ %admin ALL=(ALL) ALL ” in Ubuntu’s /etc/sudoers file stand for?
Effect of (ALL:ALL) in sudoers?
Sudo and Sudoers Configuration
Securing Your Server
Users and Groups Administration in Linux