On va faire simple. Une PME n’a pas besoin d’un SOC à 2 millions pour arrêter les attaques les plus courantes. Mais elle a besoin d’un pare-feu bien réglé. Et surtout, de règles qui ne partent pas dans tous les sens au bout de 6 mois parce que « on a ouvert un port vite fait ».
Dans ce billet, je te propose un modèle de règles minimales, raisonnables, et franchement applicables dans la vraie vie. C’est pensé pour une PME classique : un accès internet, un LAN utilisateurs, quelques serveurs, un VPN, parfois un site web, et un prestataire qui passe de temps en temps.
Ce contenu s’inscrit dans l’esprit du BTS SIO2 SISR Tech Lab (https://sio1blog.blogspot.com/) : du concret, des choix défendables, et un peu de méthode pour ne pas bricoler.
Le principe de base : tout refuser, puis autoriser au compte-gouttes
La « règle zéro » est connue, mais rarement tenue.
- Politique par défaut : deny all (entrant et sortant)
- Ensuite seulement : on autorise ce qui est nécessaire, avec le moins d’ouverture possible
- Et on documente, sinon ça meurt
Je le dis maintenant parce que c’est le piège numéro 1 : si tu commences avec « allow any any » et que tu ajoutes des exceptions, tu ne reviens jamais en arrière. Jamais.
Hypothèses de départ (pour que le modèle colle à quelque chose)
Je pars sur un plan d’adressage et des zones simples :
- WAN : internet
- LAN_users : 192.168.10.0/24
- LAN_admin : 192.168.20.0/24 (poste(s) d’admin)
- SERVERS : 192.168.30.0/24 (AD, fichiers, appli interne)
- DMZ : 192.168.40.0/24 (web, reverse proxy, passerelle mail éventuelle)
- VPN : 10.10.10.0/24 (clients nomades)
Adapte les IP, mais garde l’idée : des zones, pas « un gros LAN » unique.
Les règles minimales à avoir (dans le bon ordre)
Un pare-feu, ce n’est pas juste une liste. L’ordre compte. Et la lisibilité compte aussi, sinon tu te fais piéger par tes propres règles.
1) Règles globales : hygiène réseau et sécurité de base
R1 : anti spoofing (bloquer les sources privées sur WAN)
- Source : RFC1918 (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), link-local, loopback
- Interface : WAN
- Action : deny, log
R2 : bloquer l’administration du pare-feu depuis internet
- WAN vers firewall management : deny, log
- Puis autoriser uniquement depuis LAN_admin (voir plus bas)
R3 : autoriser le trafic établi et lié (stateful)
- State : established, related
- Action : allow
C’est ce qui évite de devoir autoriser les retours à la main.
R4 : drop invalid
- State : invalid
- Action : drop, log (au moins au début)
2) Sortant : la partie la plus négligée (et pourtant)
Beaucoup de PME filtrent l’entrant… et laissent le sortant en « any ». Résultat : si un poste est compromis, il discute tranquillement avec son serveur de commande.
Objectif : limiter le sortant aux usages utiles, par zone.
LAN_users vers internet
R10 : DNS autorisé uniquement vers résolveurs choisis
- Source : LAN_users
- Destination : DNS interne (AD) ou DNS public filtré (ex : 1.1.1.2, 9.9.9.9)
- Service : UDP 53, TCP 53
- Action : allow, log (au début)
Et surtout, interdire LAN_users vers « any DNS ».
R11 : HTTP/HTTPS vers internet
- Source : LAN_users
- Destination : internet
- Service : TCP 80, 443
- Action : allow
Option : passer par proxy, filtrage URL, inspection TLS selon le contexte.
R12 : NTP vers serveurs NTP définis
- UDP 123 vers NTP du pare-feu, de l’AD, ou des pools autorisés
- Action : allow
R13 : bloquer le reste (sortant)
- Source : LAN_users
- Destination : internet
- Service : any
- Action : deny, log (avec une politique de logs raisonnable)
Oui, ça va casser des trucs au début. C’est normal. Tu ajustes ensuite, mais tu ajustes avec une justification.
SERVERS vers internet
Les serveurs n’ont pas à « naviguer ». Ils ont besoin de mises à jour, de dépôts, parfois d’API.
R20 : mises à jour (Windows Update, dépôts Linux) via règles ciblées
- Soit par FQDN objects si ton pare-feu gère ça
- Soit via un proxy de mise à jour interne (WSUS, repo miroir)
- Action : allow
Le but, c’est d’éviter « serveurs vers any en 443 ».
R21 : supervision et alerting sortant (si utilisé)
- SMTP sortant vers relais mail, ou HTTPS vers service d’alerting
- Action : allow
R22 : deny all le reste
- SERVERS vers internet : deny, log
3) Entrant : n’exposer que ce qui doit l’être, et le mettre en DMZ
Si tu exposes un service, mets-le en DMZ. Même si c’est « juste un petit site vitrine ».
Publication web (exemple simple)
R30 : WAN vers reverse proxy en DMZ (HTTPS uniquement)
- Source : internet
- Destination : DMZ_reverse_proxy
- Service : TCP 443
- Action : allow
- Option : activer WAF, rate limiting, GeoIP si pertinent
R31 : WAN vers DMZ (HTTP) redirigé ou refusé
- Idéal : redirection 80 vers 443 au niveau reverse proxy
- Sinon : deny
R32 : DMZ vers SERVERS (uniquement ce qui est nécessaire)
Exemple : le reverse proxy parle à l’appli interne.
- Source : DMZ_reverse_proxy
- Destination : SERVERS_app
- Service : TCP 443 (ou port applicatif précis)
- Action : allow
Et pas « DMZ vers LAN any ».
Accès distant (VPN)
R40 : WAN vers VPN gateway
- IPsec : UDP 500, UDP 4500, ESP selon implémentation
- SSL VPN : TCP 443 (sur portail dédié si possible)
- Action : allow
- Option : limiter par pays, activer protections brute force
4) Inter zones : segmenter pour limiter la casse
C’est là que beaucoup de réseaux tombent. Tout le monde parle à tout le monde.
LAN_users vers SERVERS
R50 : utilisateurs vers AD/DNS
- LAN_users vers DC : TCP/UDP 53, TCP/UDP 88, TCP/UDP 389, TCP 445, TCP 135 + ports dynamiques RPC si nécessaire
Oui, c’est pénible. Mais tu peux aussi mettre les DC sur un VLAN dédié et utiliser des règles « service AD » si ton firewall a des objets prédéfinis.
R51 : utilisateurs vers serveur fichiers
- TCP 445 uniquement, vers serveurs autorisés
R52 : utilisateurs vers applis internes
- Ports applicatifs nécessaires, rien de plus
R53 : interdire LAN_users vers SERVERS en « any »
- Deny + log au début, puis logs allégés
VPN vers LAN
R60 : VPN vers services strictement nécessaires
- Accès RDP ou SSH : uniquement vers jump server ou postes ciblés
- Accès applis : ports nécessaires
- Action : allow
R61 : VPN interdit vers LAN_users
- Sauf besoin explicite (et là, on documente)
5) Administration : réduire la surface d’attaque (vraiment)
Le management du pare-feu et des équipements, c’est sacré.
R70 : autoriser l’admin du pare-feu uniquement depuis LAN_admin
- Source : LAN_admin
- Destination : firewall
- Services : HTTPS admin, SSH admin (si utilisé), SNMP (si supervision)
- Action : allow
- Condition : MFA si possible, IP fixes, certificats
R71 : interdire admin depuis LAN_users, SERVERS, VPN par défaut
- Action : deny, log
Astuce simple : un poste bastion dans LAN_admin, durci, et c’est tout. Ça évite que l’admin se fasse depuis un PC utilisateur qui traîne.
NAT : propre, lisible, et pas de « magie »
Quelques règles NAT suffisent.
- SNAT : LAN_users, SERVERS, DMZ vers WAN (masquerading)
- DNAT : WAN:443 vers DMZ_reverse_proxy:443
Et si possible, pas de DNAT direct vers un serveur en LAN. DMZ d’abord.
Documente chaque DNAT : service, propriétaire, contact, date, justification.
Journalisation : loguer ce qui est utile, pas tout et n’importe quoi
Oui, tu veux des logs. Non, tu ne veux pas 300 Go de bruit.
Minimum conseillé :
- Loguer : deny en entrée WAN, deny inter zones sensibles, événements VPN, admin, changements de config
- Échantillonnage ou désactivation : certains denies sortants trop bavards (après validation)
- Centraliser : syslog vers un serveur, ou SIEM light (Wazuh par exemple)
Services « à bannir » en clair (ou presque)
Dans une PME, si tu veux gagner vite en sécurité, commence par ça :
- Pas de RDP exposé sur internet (3389). Jamais. VPN + MFA, ou passerelle RDS.
- Pas de SMB sur internet (445). Évident, mais on le voit encore.
- Pas d’admin en HTTP. Que du HTTPS, et idéalement certificats.
- Pas de SSH exposé sauf cas très particulier, et alors IP restrictions + clés + fail2ban ou équivalent.
- Pas de règles any any temporaires qui restent 2 ans.
Un modèle de matrice de règles (lisible) à recopier
Tu peux littéralement partir de ce tableau et le remplir. Dans nos labs sur BTS SIO2 SISR Tech Lab, c’est typiquement le genre de trame qui évite de se perdre.
| ID | Source | Destination | Service | Action | Log | Commentaire |
| R1 | WAN | RFC1918, LAN subnets | any | deny | oui | anti spoofing |
| R3 | any | any | established/related | allow | non | stateful |
| R4 | any | any | invalid | drop | oui | hygiène |
| R10 | LAN_users | DNS_resolvers | DNS | allow | oui | DNS contrôlé |
| R11 | LAN_users | internet | 80, 443 | allow | non | web |
| R13 | LAN_users | internet | any | deny | oui | blocage sortant |
| R30 | internet | DMZ_reverse_proxy | 443 | allow | oui | publication web |
| R40 | internet | VPN_gateway | IPsec/SSL | allow | oui | VPN |
| R50 | LAN_users | DC | AD services | allow | non | authentification |
| R70 | LAN_admin | firewall | admin | allow | oui | gestion |
Garde des IDs, même simples. Ça change tout quand tu dois dépanner.
Points bonus (pas obligatoires, mais très rentables)
Inspection TLS : à manier avec prudence
Ça peut aider pour détecter des malwares en HTTPS, mais ça casse des applis, ça pose des questions RGPD, et ça demande des postes bien gérés (PKI, déploiement de CA). Donc pour une PME, ce n’est pas automatique. Mais à connaître.
Filtrage par FQDN
Très pratique pour autoriser des services cloud sans ouvrir « tout 443 ». Pas tous les pare-feu le font bien. Teste.
Géorestriction
Si ton activité est locale, bloquer des zones géographiques entières en entrée sur les services publiés peut réduire le bruit et certains scans. Ce n’est pas une protection magique, mais ça aide.
La règle que tout le monde oublie : la maintenance
Un pare-feu, c’est vivant.
Checklist minimale, mensuelle ou trimestrielle :
- Supprimer les règles inutiles
- Revalider les ouvertures « temporaires »
- Vérifier les objets (IP, FQDN, groupes)
- Mettre à jour le firmware
- Sauvegarder la конфигураtion (oui, on le fait avant un changement, pas après)
- Tester la restauration
- Vérifier certificats VPN et portail
Et note quelque part : qui valide quoi. Même une mini PME a besoin d’un mini processus.
Exemple concret : petite PME avec site web et VPN
Scénario : 25 utilisateurs, un AD, un serveur fichiers, un Nextcloud interne, un site vitrine, 5 nomades.
- Site vitrine : WAN:443 vers reverse proxy en DMZ, puis DMZ vers serveur web interne sur port unique
- VPN SSL : WAN:443 vers portail VPN sur un autre vhost ou une autre IP publique si possible
- VPN clients : accès uniquement à SERVERS (applis) + un jump server
- Sortant users : DNS vers AD, web 80/443, NTP
- Sortant servers : updates strictes, pas de navigation
Tu réduis la surface d’attaque, tu contiens les dégâts si un poste tombe, et tu te facilites la vie pour investiguer.
Conclusion : un pare-feu simple, mais tenu, vaut mieux qu’un pare-feu « parfait » et oublié
Le but ici, ce n’est pas de faire une cathédrale. C’est d’avoir un socle solide.
Si tu ne devais retenir que 5 idées :
- Refus par défaut, partout.
- Sortant filtré, au moins sur DNS et les ports inutiles.
- DMZ pour ce qui est exposé.
- Segmentation inter zones (LAN users ne parle pas à tout).
- Admin verrouillée (LAN_admin seulement, MFA si possible).
Si tu veux d’autres trames comme celle-ci, des labs Packet Tracer, GNS3, pfSense, OPNsense, ou même des exemples de politiques par service (AD, VoIP, sauvegardes, supervision), passe sur BTS SIO2 SISR Tech Lab : https://sio1blog.blogspot.com/
On continue à empiler des petits morceaux utiles, et au final, ça fait une vraie boîte à outils.
Questions fréquemment posées
Pourquoi une PME n'a-t-elle pas besoin d'un SOC à 2 millions pour sa sécurité ?
Une PME n'a pas besoin d'un SOC coûteux pour stopper les attaques courantes. Elle a surtout besoin d'un pare-feu bien configuré avec des règles simples, raisonnables et maintenues dans le temps pour protéger efficacement son réseau.
Quelle est la règle de base pour configurer un pare-feu efficace en PME ?
La règle zéro est de tout refuser par défaut (deny all), puis d'autoriser uniquement ce qui est nécessaire, de façon minimaliste et documentée. Cela évite les ouvertures non contrôlées et renforce la sécurité.
Comment organiser le plan d'adressage réseau pour une PME typique ?
Il est conseillé de segmenter le réseau en zones : WAN (internet), LAN utilisateurs (exemple 192.168.10.0/24), LAN admin, serveurs, DMZ et VPN. Cette segmentation facilite la gestion des règles et améliore la sécurité.
Quelles sont les règles globales essentielles à appliquer sur un pare-feu PME ?
Les règles globales comprennent : bloquer le spoofing sur l'interface WAN, interdire l'administration du pare-feu depuis internet sauf depuis LAN admin, autoriser le trafic établi et lié (stateful), et bloquer les paquets invalides avec journalisation.
Pourquoi est-il important de filtrer aussi le trafic sortant dans une PME ?
Beaucoup de PME ne filtrent que le trafic entrant mais laissent le sortant libre, ce qui permet à un poste compromis de communiquer avec un serveur malveillant. Limiter le sortant aux usages indispensables réduit ce risque.
Quelles sont les règles minimales recommandées pour le trafic sortant des utilisateurs LAN ?
Les règles minimales incluent : autoriser DNS uniquement vers des résolveurs choisis, autoriser HTTP/HTTPS vers internet (avec éventuellement proxy ou inspection TLS), autoriser NTP vers serveurs définis, puis bloquer tout autre trafic sortant non justifié.
0 Commentaires