UFW ne bloque pas

[PRSoftware]

Bonjour,

Ayant constaté dans les logs de mon serveur Apache beaucoup d'accès depuis des adresses IP non désirées, j'ai voulu bloquer la plage d'adresses en amont dans le pare-feu UFW.

Pour cela, j'ai entré la commande "sudo ufw insert 1 deny from 162.142.0.0/17".

Je vois bien le blocage dans la commande "sudo ufw status" :

Code: Select all

État : actif

Vers                       Action      De
----                       ------      --
Anywhere                   DENY        162.142.0.0/17 

Je pensais que, ayant interdit l'accès à ces adresses dans le pare-feu, aucune de ces adresses ne pourraient plus accéder à mes serveurs (Apache, SSH, FTP) mais, malgré cela, je vois toujours dans le log d'Apache et des autres serveurs des accès provenant de cette plage d'adresses IP.

L'état de UFW est le suivant :

Code: Select all

● ufw.service - Uncomplicated firewall
     Loaded: loaded (/lib/systemd/system/ufw.service; enabled; vendor preset: enabled)
     Active: active (exited) since Sat 2022-04-30 15:27:12 CEST; 3 weeks 3 days ago
       Docs: man:ufw(8)
   Main PID: 388 (code=exited, status=0/SUCCESS)
      Tasks: 0 (limit: 28610)
     Memory: 0B
     CGroup: /system.slice/ufw.service

avril 30 15:27:12 patrick systemd[1]: Finished Uncomplicated firewall.
Warning: journal has been rotated since unit was started, output may be incomplete.

J'ai dû oublier de faire quelque chose, mais quoi ???

Je vous remercie par avance de votre aide.

Patrick

[MikeNovember]

Bonjour,

Votre règle "Vers Anywhere... De 162.42.0.0" ressemble à une règle de blocage de connexion sortante.

Il faudrait plutôt une règle de blocage de connexion entrante.

Cordialement,

MN

[PRSoftware]

La règle "deny from address" ne bloque pas les connexions entrantes ?

C'est pourtant ce que j'avais lu dans la doc de UFW ...

Pouvez-vous me confirmer cela ? Et m'indiquer quelle règle utiliser pour bloquer les connexions entrantes depuis une adresse IP externe ?

[MikeNovember]

Bonjour,

J'aurais plutôt écrit ""sudo ufw insert 1 deny in from 162.142.0.0/17". D'après le man le "in" est facultatif (en l'absence de direction précisée in ou out c'est in par défaut) mais visiblement ça ne marche pas chez vous.

Ceci dit, ce n'est pas comme ça que je configurerais mon parefeu:
- je commencerais par des règles autorisant une connexion entrante sur un port donné pour des adresses données (si je dois accepter des connexions entrantes),
- puis j'ajouterais juste après une règle de blocage de toutes les connexions entrantes.

Les premières règles, ayant un numéro plus petit, sont exécutées d'abord, puis la dernière. Ainsi, les adresses IP qui ne sont pas formellement autorisées à se connecter ne pourront pas le faire (toutes, pas seulement certaines vues dans les logs).

Cordialement,

MN

[PRSoftware]

Le problème avec votre solution est que je ne maîtrise pas la liste des adresses que j'autorise à se connecter sur ma machine.

Par exemple, si je veux me connecter sur ma machine depuis mon téléphone portable, je ne connais pas par avance l'adresse IP qui m'est allouée sur le réseau 4G par mon opérateur.

Je ne peux donc pas faire de la protection préventive mais uniquement de la curative quand l'analyse des logs me montre une adresse IP qui cherche à se connecter de façon anormale (en essayant plein d'identifiants différents par exemple) : dans ce cas, je banni la plage d'adresses IP qui contient cette adresse indésirable.

[MikeNovember]

Le problème avec votre solution est que je ne maîtrise pas la liste des adresses que j'autorise à se connecter sur ma machine.

Par exemple, si je veux me connecter sur ma machine depuis mon téléphone portable, je ne connais pas par avance l'adresse IP qui m'est allouée sur le réseau 4G par mon opérateur.

Je ne peux donc pas faire de la protection préventive mais uniquement de la curative quand l'analyse des logs me montre une adresse IP qui cherche à se connecter de façon anormale (en essayant plein d'identifiants différents par exemple) : dans ce cas, je banni la plage d'adresses IP qui contient cette adresse indésirable.

Bonjour,

Votre solution est dangereuse : vous laissez des ports ouverts, à un très grand nombre d'adresses IP (presque toutes).

Pour limiter les risques :
- Commencez par des règles ouvrant seulement les ports que vous utilisez, puis une règle de blocage de toutes les connexions entrantes. Idéalement, un seul port (par exemple prise de contrôle à distance, VNC, ssh...) permettant tout ce que vous voulez faire.
- Supprimez les services non utilisés écoutant les connexions entrantes.
- Utilisez des mots de passe forts, par exemple une passe de phrase (plus facile à mémoriser qu'un mot de passe long).

Cordialement,

MN

[PRSoftware]

Pas si dangereuse que ça, en fait, puisque mon PC est derrière une box sur laquelle seuls 3 ports sont redirigés vers mon PC (HTTPS, SSH, FTP) sachant que pour SSH et FTP, les numéros de ports vus depuis l'extérieur ne sont pas les ports standards (22 et 21), ce qui limite très fortement les accès sur ces services.

En fait, il n'y a que le HTTPS sur le port standard 443 qui pose un vrai soucis d'accès non désirés, même si ce n'est pas si grave vu qu'une authentification est nécessaire pour accéder à toutes les pages sur le serveur web Apache sur ma machine.

Pour moi, réaliser un blocage au niveau du pare-feu est surtout un moyen d'en apprendre un peu plus sur le fonctionnement de la sécurité sur Linux que je découvre depuis seulement un an après de longues années sous Windows.

[MikeNovember]

Pas si dangereuse que ça, en fait, puisque mon PC est derrière une box sur laquelle seuls 3 ports sont redirigés vers mon PC (HTTPS, SSH, FTP) sachant que pour SSH et FTP, les numéros de ports vus depuis l'extérieur ne sont pas les ports standards (22 et 21), ce qui limite très fortement les accès sur ces services.

En fait, il n'y a que le HTTPS sur le port standard 443 qui pose un vrai soucis d'accès non désirés, même si ce n'est pas si grave vu qu'une authentification est nécessaire pour accéder à toutes les pages sur le serveur web Apache sur ma machine.

Pour moi, réaliser un blocage au niveau du pare-feu est surtout un moyen d'en apprendre un peu plus sur le fonctionnement de la sécurité sur Linux que je découvre depuis seulement un an après de longues années sous Windows.

Tout d'abord, vous ne savez pas si votre box est munie d'un vrai pare-feu ou pas. Vous ne savez pas non plus si le logiciel de votre box est sûr, ou bien s'il est farci de failles de sécurité non corrigées. Il vous faut donc faire comme si votre box n'apportait rien en matière de sécurité et ne faisait que du NAT.

Le fait que vous ayez changé les ports 22 et 21 en d'autres ports n'apporte non plus aucune sécurité : il ne faut que quelques dizaines de secondes pour scanner les 65536 ports de votre box, et voir ceux qui sont ouverts (qui correspondent à ssh et ftp).

Mes suggestions:

- FTP n'est pas sécurisé (les mots de passe transitent en clair), il faudrait le remplacer par du SFTP, ou même le supprimer, car SSH permet l'accès aux fichiers.

- Il faut vous assurer que tous les accès se font via une authentification forte (mot de passe seul de 16 octets aléatoires ou phrase de passe de force équivalente, ou mieux mot de passe + certificat client).

- Rajouter une dernière règle de blocage de toutes les connexions entrantes, après les premières règles autorisant les connexions entrantes pour les protocoles (et les ports) que vous avez choisis.

D'un point de vue sécurité, la gestion des accès entrants à un serveur via un pare-feu repose sur les mêmes principes, que vous soyez sous Windows ou Linux, et vos principes ne sont pas sûrs !

De manière plus générale, à partir du moment où vous gérez un serveur, il vous faut mettre en place un système de prévention et de détection d'intrusion, dont le parefeu n'est qu'une brique. Regardez du côté de Tripwire, fail2ban, OSSEC, Snort, Suricata, Zeek, Wrap-up, Security onion, Samhain... Les plus complets sont Samhain et OSSEC.

Cordialement,

MN

[PRSoftware]

Merci pour tous ces conseils, je vais essayer de les mettre en oeuvre.