CERT-FR sur Freebox Pro - Utilisation et pertinence ?

[morgyann]

N'étant un super spécialiste de la cybersécurité (il y a des métiers pour cela ), une petite question concernant le pare-feu de ma Freebox Pro.
Sur ma Freebox Pro, j'ai activé le Pare-feu au niveau max. Celui-ci est basé sur CERT-FR



Seul le port 443 est ouvert à l'externe pour le serveur de mes CMS. Aussi, j'ai 2 autres Pare-Feu 1 pour le Serveur (global Docker) + 1 sur chaque site WP.

Je reçois épisodiquement, des alertes par courriel, m'indiquant que mon équipement a communiqué avec une adresse "suspecte" :

"...
RAISONS DE L’ALERTE
Un de vos équipements a communiqué avec une adresse IP localisée dans un pays considérée comme à risque. Ce type de communication n’est pas toujours le fait d’une tentative malveillante, mais peut être le signe d’un échange non autorisé ou d’un logiciel qui contacte un serveur externe à votre insu.
Cela peut être associé à :

• une communication avec un serveur suspect
• un logiciel ou service mal configuré
• une activité inhabituelle sur un équipement ..."

Ce courriel m'indique de prendre les mesures nécessaires :

"... Nous vous recommandons de :

• Vérifier si cette communication est attendue
• Identifier l’équipement concerné
• Contrôler les logiciels ou services qui communiquent vers l’extérieur
• Vérifier qu’aucune donnée n’est envoyée de manière non prévue
• Lancer une analyse antivirus si vous avez un doute
• Bloquer cette destination si elle ne correspond pas à un usage légitime ..."

Il me renvoie sur la FAQ pour les mesures à prendre sur mon Pare-feu à savoir : n'ouvrir que les ports qui doivent communiquer et activer et bloquer et alerter les flux suspects.
J'avoue être un peu interrogatif quant à la formulation du courriel, l'IP est bloquée ou non ?

 

[Bambusa29]

Ce que je comprends : une application sur tes NAS ou ton ordinateur a ouvert une connexion avec un site externe qui est considéré comme suspect.

Par défaut le pare-feu laisse sortir du LAN toutes les connexions vers Internet si l'initiateur est le LAN.

Cas Concret : Logiciel qui fait de la télémétrie, vérifications des mises à jour de logiciel, site suspect ouvert sur ton navigateur, malware...etc bref pas facile de savoir si c'est légitime ou pas... il faut regarder les logs de ta Box.

Concernant le blocage de Port, tu es déjà bien (443 en entré, le reste bloqué). Pour le blocage de ports en sortie c'est plus compliqué, car les mêmes ports DST sont utilisés par plein d'applications. Pour le blocage en sortie, le mieux c'est de le faire au niveau du DNS...

Il y a peu sur un autre post on parlait de DNS auto-hebergé (AddGuard, PiHole...) ou de 'DNS Firewall'. Ce type de logiciel est utile dans ce cas et permet bloquer pas mal d'accès suspect vers l’extérieur.

Savoir si ta box a bien bloqué ou pas, il faut vérifier tes logs ou voir ton interface de configuration au niveau de ta box.

 

[Neo974]

Bonjour,

Le problème c’est que ça peut être n’importe quel équipement sur ton réseau.
Y compris un smartphone connecté au wifi.

 

[morgyann]

bref pas facile de savoir si c'est légitime ou pas... il faut regarder les logs de ta Box.

En fait les alertes concerne mon serveur (IP source en 7) qui se connecte en externe à ???

DETAILS DE L’ALERTE

• IP Source (Votre réseau) : 192.168.1.7
• IP Cible (Malveillante) : 123.160.223.72
• Score de Malveillance : 100/100

Ce type de logiciel est utile dans ce cas et permet bloquer pas mal d'accès suspect vers l’extérieur.

Et c'est quoi le risque quand c'est vers l'externe ?

Je viens de faire une recherche sur cette adresse :

L'adresse 123.160.223.72 est une adresse IP publique (IPv4).

• Propriétaire : Elle est attribuée à PT. Telekomunikasi Indonesia (l'opérateur télécom indonésien).
• Localisation géographique : Elle est généralement localisée en Indonésie, bien que la précision exacte de la ville dépende du routeur spécifique de l'utilisateur.
• Type : Il s'agit d'une adresse dynamique ou résidentielle/professionnelle utilisée pour la connexion Internet, et non d'une adresse postale.

 

[cooper]

En fait les alertes concerne mon serveur (IP source en 7) qui se connecte en externe à ???

DETAILS DE L’ALERTE

• IP Source (Votre réseau) : 192.168.1.7
• IP Cible (Malveillante) : 123.160.223.72
• Score de Malveillance : 100/100

Et c'est quoi le risque quand c'est vers l'externe ?

Envoi de données à l'extérieur. Pour savoir ce qui l'est, étudier une capture du trafic avec tcpdump (ou via une des interfaces graphiques telles que Wireshark).

Problème : si les échanges sont chiffrés, tu ne verras que peu d'informations utiles.

Je viens de faire une recherche sur cette adresse :

L'adresse 123.160.223.72 est une adresse IP publique (IPv4).

• Propriétaire : Elle est attribuée à PT. Telekomunikasi Indonesia (l'opérateur télécom indonésien).
• Localisation géographique : Elle est généralement localisée en Indonésie, bien que la précision exacte de la ville dépende du routeur spécifique de l'utilisateur.
• Type : Il s'agit d'une adresse dynamique ou résidentielle/professionnelle utilisée pour la connexion Internet, et non d'une adresse postale.

Alors je ne sais pas où tu as récupéré ces informations mais elles sont fausses.
En interrogeant le whois de l'APNIC, la délégation de cette IPv4 et de son /8 (123.0.0.0/8) est à China Telecom :

% whois 123.160.223.72
% IANA WHOIS server
% for more information on IANA, visit http://www.iana.org
% This query returned 1 object

refer:        whois.apnic.net

inetnum:      123.0.0.0 - 123.255.255.255
organisation: APNIC
status:       ALLOCATED

whois:        whois.apnic.net

changed:      2006-01
source:       IANA

# whois.apnic.net

% [whois.apnic.net]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

% Information related to '123.160.0.0 - 123.163.255.255'

% Abuse contact for '123.160.0.0 - 123.163.255.255' is 'anti-spam@chinatelecom.cn'

inetnum:        123.160.0.0 - 123.163.255.255
netname:        CHINANET-HA
descr:          CHINANET henan province network
descr:          China Telecom
descr:          No.31,jingrong street
descr:          Beijing 100032
country:        CN
admin-c:        HZ149-AP
tech-c:         HZ149-AP
abuse-c:        AC1573-AP
status:         ALLOCATED PORTABLE
remarks:        Henan Telecom Corporation hostmaster
remarks:        --------------------------------------------------------
remarks:        To report network abuse, please contact mnt-irt
remarks:        For troubleshooting, please contact tech-c and admin-c
remarks:        Report invalid contact via www.apnic.net/invalidcontact
remarks:        --------------------------------------------------------
mnt-by:         APNIC-HM
mnt-lower:      MAINT-CHINANET-HA
mnt-routes:     MAINT-CHINANET-HA
mnt-irt:        IRT-CHINANET-CN
last-modified:  2021-06-15T08:05:12Z
source:         APNIC

irt:            IRT-CHINANET-CN
address:        No.31 ,jingrong street,beijing
address:        100032
e-mail:         anti-spam@chinatelecom.cn
abuse-mailbox:  anti-spam@chinatelecom.cn
admin-c:        CH93-AP
tech-c:         CH93-AP
auth:           # Filtered
remarks:        anti-spam@chinatelecom.cn was validated on 2026-05-21
mnt-by:         MAINT-CHINANET
last-modified:  2026-05-21T01:31:36Z
source:         APNIC

role:           ABUSE CHINANETCN
country:        ZZ
address:        No.31 ,jingrong street,beijing
address:        100032
phone:          +000000000
e-mail:         anti-spam@chinatelecom.cn
admin-c:        CH93-AP
tech-c:         CH93-AP
nic-hdl:        AC1573-AP
remarks:        Generated from irt object IRT-CHINANET-CN
remarks:        anti-spam@chinatelecom.cn was validated on 2026-05-21
abuse-mailbox:  anti-spam@chinatelecom.cn
mnt-by:         APNIC-ABUSE
last-modified:  2026-05-21T01:32:00Z
source:         APNIC

person:         Hongbiao Zhang
nic-hdl:        HZ149-AP
e-mail:         ip@hntele.com
address:        97# Zhongyuan Street, Zhengzhou City, China
phone:          +86 371 65310018
fax-no:         +86 371 65310015
country:        CN
mnt-by:         MAINT-CHINANET-HA
last-modified:  2008-09-04T07:29:40Z
source:         APNIC

% This query was served by the APNIC Whois Service version 1.88.48 (WHOIS-UK2)

 

[cooper]

Concernant le blocage de Port, tu es déjà bien (443 en entré, le reste bloqué). Pour le blocage de ports en sortie c'est plus compliqué, car les mêmes ports DST sont utilisés par plein d'applications. Pour le blocage en sortie, le mieux c'est de le faire au niveau du DNS...

Il y a peu sur un autre post on parlait de DNS auto-hebergé (AddGuard, PiHole...) ou de 'DNS Firewall'. Ce type de logiciel est utile dans ce cas et permet bloquer pas mal d'accès suspect vers l’extérieur.

La bonne façon de faire est de paramétrer une règle dans son pare-feu. « DNS firewall » ne veut rien dire
De plus l'IPv4 123.160.223.72 n'a pas de PTR, donc un DNS ne peut rien faire et ne s'occupe absolument pas de ça :

% host 123.160.223.72
Host 72.223.160.123.in-addr.arpa. not found: 3(NXDOMAIN)

Savoir si ta box a bien bloqué ou pas, il faut vérifier tes logs ou voir ton interface de configuration au niveau de ta box.

D'après le message d'alerte, rien n'a été bloqué. Juste un signalement par la gateway (la freeboîte dans le cas de @morgyann)

@morgyann : paramètres le pare-feu du terminal de ton LAN ayant 192.168.1.7 comme IPv4 attribuée, et fais en sorte que toute tentative de connexion à 123.0.0.0/8 soit consignée par ton pare-feu.

De cette façon tu pourras savoir quel logiciel tente d'établir des connexions à ce réseau, si tant est que ton pare-feu permet de signaler le PID étant à l'origine de la connexion.

 

[Bambusa29]

La bonne façon de faire est de paramétrer une règle dans son pare-feu. « DNS firewall » ne veut rien dire

J'ai fais une réponse générique n'ayant pas lu depuis, les réponses suivantes du sujet.

Je ne comprends pas ta réponse ; un DNS Firewall permet de filtrer les requêtes DNS entrantes ou sortantes au niveau d'un pare-feu. Le mien (IpFire) le fait en sortie de Box via des listes génériques et customisées, comme pourrait le ferait un DNS auto hébergé comme Adguard ou Pi-Hole.



Effectivement pour son cas précis, il faut bloquer autrement.

De plus l'IPv4 123.160.223.72 n'a pas de PTR, donc un DNS ne peut rien faire et ne s'occupe absolument pas de ça :

% host 123.160.223.72
Host 72.223.160.123.in-addr.arpa. not found: 3(NXDOMAIN)

D'après le message d'alerte, rien n'a été bloqué. Juste un signalement par la gateway (la freeboîte dans le cas de @morgyann)

@morgyann : paramètres le pare-feu du terminal de ton LAN ayant 192.168.1.7 comme IPv4 attribuée, et fais en sorte que toute tentative de connexion à 123.0.0.0/8 soit consignée par ton pare-feu.

De cette façon tu pourras savoir quel logiciel tente d'établir des connexions à ce réseau, si tant est que ton pare-feu permet de signaler le PID étant à l'origine de la connexion.

 

[morgyann]

@Bambusa29 @cooper Merci pour vos réponses

Quel est le risque de ces alertes ? ​

J'ai eu ce mois de juillet 3 alertes 1 pour mon PC de W → France et 2 de la même IP → Chine (@cooper je viens de revérifier sur un site).

Je viens de configurer ma Freebox Pro de cette manière : cela vous semble bon ?

 

[Bambusa29]

@Bambusa29 @cooper Merci pour vos réponses

Quel est le risque de ces alertes ? ​

J'ai eu ce mois de juillet 3 alertes 1 pour mon PC de W → France et 2 de la même IP → Chine (@cooper je viens de revérifier sur un site).

Je viens de configurer ma Freebox Pro de cette manière : cela vous semble bon ?

Voir la pièce jointe 20992

Oui c'est bon si c’était bien du trafic TCP. Par contre c'est fastidieux, si tu dois le faire IP par IP à chaque fois que tu découvre une nouvelle IP suspecte... Tu peux aussi bloquer le bloc complet 123.160.0.0 - 123.163.255.255 pour être tranquille. -> 123.160.0.0/14 a mettre a la place de 123.160.223.72.

Ideallement un système de 'Black List' d'adresse IP auto alimenté avec possibilité de liste blanche, mais je ne pense pas que ta box permettent de gérer des listes de blocage IP. Pour cela il te faudrait un 'vrai' pare feu après ta box.

 

[cooper]

J'ai fais une réponse générique n'ayant pas lu depuis, les réponses suivantes du sujet.

Je ne comprends pas ta réponse ; un DNS Firewall permet de filtrer les requêtes DNS entrantes ou sortantes au niveau d'un pare-feu. Le mien (IpFire) le fait en sortie de Box via des listes génériques et customisées, comme pourrait le ferait un DNS auto hébergé comme Adguard ou Pi-Hole.

DNS / Pare-feu c'est antinomique.

Un DNS fait de la résolution adresse IP <-> PTR (Pointer Record, permettant de pratiquer le rDNS : reverse DNS).

On peut à l'aide d'un résolveur renvoyer une autre résolution (principe des listes de blocage tel que tu cites) mais en aucun cas procéder à du filtrage IP. Ce sont deux choses complètement différentes.

Le cas de @morgyann se règle avec un pare-feu.

Ideallement un système de 'Black List' d'adresse IP auto alimenté avec possibilité de liste blanche, mais je ne pense pas que ta box permettent de gérer des listes de blocage IP. Pour cela il te faudrait un 'vrai' pare feu après ta box.

C'est ce qu'il faut faire. Les box d'opérateurs proposent des fonctions basiques mais dans ce cas précis il faut utiliser un pare-feu pour la machine 192.168.1.7 du lan de @morgyann.

Plusieurs solutions, à combiner de préférence :

1. Soit un « sentry » (fail2ban, blacklistd (sur *BSD), CrowdSec, SSHGuard, etc.) qui gère dynamiquement des règles de filtrage d'IP suspectes ;
2. Ou faire du « geofencing » (filtrage géographique d'après les registres de l'IANA (un département de l'ICANN) et les RIRs régionaux (APNIC, ARIN, RIPE, AFNIC, etc.)

 

[cooper]

@Bambusa29 @cooper Merci pour vos réponses

Quel est le risque de ces alertes ? ​

J'ai eu ce mois de juillet 3 alertes 1 pour mon PC de W → France et 2 de la même IP → Chine (@cooper je viens de revérifier sur un site).

Pour vérifier une adresse IP, toujours interroger le whois. C'est disponible de base depuis un shell dans tous les Un*x like/Unix ou bien directement depuis l'ICANN.

Je viens de configurer ma Freebox Pro de cette manière : cela vous semble bon ?

Voir la pièce jointe 20992

Cela va bloquer toute connexion TCP externe de ton lan vers les deux adresses sus-mentionnées mais ne bloquera pas les paquets UDP ou QUIC.

Utilises un pare-feu sur ta machine hébergeant des services. Toujours.

Les pare-feux de routeurs, qu'ils soient les merdes fournies par les opérateurs de réseau ou du matériel sérieux prévu pour (pfSsense, OPNsense, etc.) sont en général utilisés pour les clients (tout terminal n'hébergeant pas de services).

 

[Bambusa29]

DNS / Pare-feu c'est antinomique.

Un DNS fait de la résolution adresse IP <-> PTR (Pointer Record, également appelé rDNS : reverse DNS).

On peut à l'aide d'un résolveur renvoyer une autre résolution (principe des listes de blocage tel que tu cites) mais en aucun cas procéder à du filtrage IP. Ce sont deux choses complètement différentes.

Je n'ai jamais parlé de blocage IP, mais de filtrage DNS. Le terme 'DNS Firewall' est largement utilisé dans la littérature (je ne l'ai pas inventé ; il suffit de faire une recherche avec ce terme, par exemple : https://developers.cloudflare.com/dns/dns-firewall/) et je l'avais mis entre guillemet dans mon post d'origine.

Le cas de @morgyann se règle avec un pare-feu.



C'est ce qu'il faut faire. Les box d'opérateurs proposent des fonctions basiques mais dans ce cas précis il faut utiliser un pare-feu pour la machine 192.168.1.7 du lan de @morgyann.

Plusieurs solutions, à combiner de préférence :

1. Soit un « sentry » (fail2ban, blacklistd (sur *BSD), CrowdSec, SSHGuard, etc.) qui gère dynamiquement des règles de filtrage d'IP suspectes ;
2. Ou faire du « geofencing » (filtrage géographique d'après les registres de l'IANA (un département de l'ICANN) et les RIRs régionaux (APNIC, ARIN, RIPE, AFNIC, etc.)

Le geofencing est malheureusement faussé par l'utilisation d'un VPN.

@morgyann Si tu veux utiliser une des solutions cités plus haut ; il te faudra changer d'image Docker, comme celle de https://github.com/ZoeyVid/NPMplus par exemple qui intègre Crowdsec; sinon gérer cela au niveau de ton hôte Docker (il y a plusieurs tutos sur le sujet sur le forum).

 

[cooper]

Je n'ai jamais parlé de blocage IP, mais de filtrage DNS. Le terme 'DNS Firewall' est largement utilisé dans la littérature (je ne l'ai pas inventé ; il suffit de faire une recherche avec ce terme, par exemple : https://developers.cloudflare.com/dns/dns-firewall/) et je l'avais mis entre guillemet dans mon post d'origine.

Ce terme inventé par une société commerciale privée n'en fait pas un standard et dans le cas présent est hors de propos.
En le colportant, cela fausse la compréhension des technologies et ne fait pas avancer le schmilblick.

Le geofencing est malheureusement faussé par l'utilisation d'un VPN.

Les script kiddies ou botnet ont très rarement recours à des tunnels. Cela demande des ressources supplémentaires. En revanche être la cible d'un attaquant, oui. C'est pourquoi il ne faut pas utiliser uniquement ce type de mitigation et reste un complément dans une mise en place de défenses appropriées comme je l'ai souligné

 

[morgyann]

Bon, les informaticiens, inutile de vous crêper le chignon pour un simple terme ⁣. ⁣ Nous sommes sur le Forum des NAS

J'ai fait quelques recherches pour voir s'il pouvait y avoir des risques… Apparemment oui... cependant, je n'arrive pas à voir quelle application peut être en cause
Je pense mettre en route, un second serveur dédié pour le réseau et mes CMS (celui que j'utilise en prod a un défaut du Bios/CM qui me met "le bazar à mes CMS" à chaque redémarrage).
La solution la plus simple à gérer (pour mon organisation) semble être effectivement d'installer, comme proposée par @Bambusa29 et sur ce Forum → NPMPlus. Je renforcerai la protection — si j'utilise toujours ZimaOS pour ce nouveau serveur — avec ZFW. Mes CMS sont aussi renforcés avec pare-feu dédié et mode de connexion. Et, bloquer les IP dangereuses détectées par Freebox Pro dans la mesure où les alertes restent épisodiques (je précise que sur ce modèle, la conf ne se fait qu'en ligne et pas en local).

 

[cooper]

Bon, les informaticiens, inutile de vous crêper le chignon pour un simple terme ⁣. ⁣ Nous sommes sur le Forum des NAS

Manque juste une bonne binouze pour débattre de tout ça

J'ai fait quelques recherches pour voir s'il pouvait y avoir des risques… Apparemment oui... cependant, je n'arrive pas à voir quelle application peut être en cause

Des outils comme audictl ou lsof permettent de vérifier ça mais n'utilisant pas GNU/Linux concernant le premier outil, il faudra rechercher comment il s'utilise.

Pour lsof, c'est assez simple :

lsof -PniTCP:443 -r 1 | grep :443

 

[Bambusa29]

Bon, les informaticiens, inutile de vous crêper le chignon pour un simple terme ⁣. ⁣ Nous sommes sur le Forum des NAS

J'ai fait quelques recherches pour voir s'il pouvait y avoir des risques… Apparemment oui... cependant, je n'arrive pas à voir quelle application peut être en cause
Je pense mettre en route, un second serveur dédié pour le réseau et mes CMS (celui que j'utilise en prod a un défaut du Bios/CM qui me met "le bazar à mes CMS" à chaque redémarrage).
La solution la plus simple à gérer (pour mon organisation) semble être effectivement d'installer, comme proposée par @Bambusa29 et sur ce Forum → NPMPlus. Je renforcerai la protection — si j'utilise toujours ZimaOS pour ce nouveau serveur — avec ZFW. Mes CMS sont aussi renforcés avec pare-feu dédié et mode de connexion. Et, bloquer les IP dangereuses détectées par Freebox Pro dans la mesure où les alertes restent épisodiques (je précise que sur ce modèle, la conf ne se fait qu'en ligne et pas en local).

Si tu ne veux pas te prendre la tête, migre vers NPMPlus et active Crowdsec, mais je ne peux pas t'aider plus car je n'utilise pas, bien que je l'avais testé il y a longtemps avec 'Swag'. J'utilise une alternative à fail2ban moderne écrite en Rust (https://blog.ppom.me/en-reaction-v2/).

Sinon ce que tu peux déjà faire sur NPM, c'est modifié les en têtes HTTP du proxy pour le protéger contre les injections XSS et autres (faut le faire à la main via fichier de config)... cela te permettra déjà de passer d'un score médiocre/mauvais à un bon score, voir maximum sur les site de tests des en têtes HTTP.

Fait déjà un test de tes CMS sur : https://securityheaders.com/ tu aura sans doute un score 'D' voir pire 'F' et en modifiant les en tête HTTP de NPM, tu pourra passer au score 'A', voir 'A+' (sur des sites dynamiques comme Worpress c'est compliqué d'avoir un score mieux que 'A').

Perso je suis A+ sur tous mes Blog et CMS, mais j'utilise des moteurs de Blog Statique ou sites perso en PHP sans javascript.

 

[morgyann]

Pour lsof, c'est assez simple :

Viens de tester, mais ZimaOS ne prend pas en charge toutes les commandes Linux (uniquement Docker).

Fait déjà un test de tes CMS sur : https://securityheaders.com/ tu aura sans doute un score 'D'

Effectivement, je suis sur D
J'ai fait aussi un test de vérif sur GreyNoise et mon IP semble "propre".

Si tu ne veux pas te prendre la tête, migre vers NPMPlus et active Crowdsec

Bon… plus qu'à bosser la sécurité du réseau pour la rentrée.
Dès que mon second serveur est prêt avec NPMPlus je vous fais un retour et voir si je passe à A.