On parle souvent de « présence en ligne » comme si c’était une médaille. Mais côté sécurité, c’est plutôt une vitrine avec la porte ouverte. Chaque service exposé, chaque DNS mal rangé, chaque port qui traîne, ça devient une opportunité pour quelqu’un d’autre. Et le pire, c’est que ça s’installe doucement. Un test « temporaire ». Une VM oubliée. Un sous domaine « dev » qui reste public. Et puis voilà.
Ici, on va parler d’exposition internet, au sens très concret : tout ce qui est visible, accessible, attaquable depuis l’extérieur. Et comment réduire la surface en 10 actions pragmatiques et faisables, pas juste « mettez un firewall » et bon courage.
Note rapide : je mélange volontairement un peu l’approche sysadmin et l’approche business en ligne, parce qu’en vrai c’est la même histoire. Ton site, ton tunnel de vente, ton VPS, ton outil no code, ton CRM… tout ça finit sur internet. Et donc exposé.
1. Inventorier ce qui est vraiment exposé (avant de « sécuriser »)
Avant de réduire, il faut voir. Et souvent on se ment, sans faire exprès.
Checklist à faire en 30 minutes :
- domaines et sous domaines actifs (www, app, api, blog, cdn, staging, dev…)
- IP publiques (cloud, VPS, box pro, IP fixe)
- ports ouverts (22, 80, 443, 3389, 5432…)
- services SaaS connectés (Zapier, Make, Notion, Google Drive, Slack, etc.)
- pages et répertoires indexés (Google dorks basiques)
Outils utiles :
nmapdepuis un poste externedig,nslookup,host- un scan type Shodan ou Censys (même juste pour vérifier si tu existes déjà là bas)
Petit rappel qui pique : si Shodan voit ton service, des attaquants le voient aussi. Ils n’ont même pas besoin de te « chercher ».
Il est essentiel d'inventorier ce qui est vraiment exposé avant de sécuriser. Cela peut être réalisé avec quelques commandes Linux utiles que tu peux découvrir ici. Une fois que tu as une idée claire de ton exposition internet et des vulnérabilités potentielles grâce à ces outils comme nmap, dig ou nslookup, il est temps de réduire la surface d'attaque avec des actions concrètes.
Cela dit il ne faut pas oublier que tout cela doit être fait
2. Fermer ce qui n’a rien à faire sur internet (le ménage brutal)
C’est l’action la plus rentable.
Exemples classiques à sortir d’internet :
- SSH (22) accessible au monde entier
- RDP (3389) exposé « juste pour moi »
- bases de données ouvertes (MongoDB, PostgreSQL, Redis…)
- panels admin (phpMyAdmin, Portainer, Grafana, Jenkins) en accès direct
Ce que tu veux idéalement :
- exposition minimale : 80 et 443 seulement, et encore, derrière un reverse proxy
- tout le reste : réseau privé, VPN, ou au minimum IP allowlist
Si tu es sur un VPS : commence par ufw (ou firewalld) et une politique simple.
Si tu es dans le cloud : security groups / NSG / firewall rules bien strictes.
3. Mettre un reverse proxy et standardiser les points d’entrée
Un reverse proxy, c’est ton gardien. C’est lui qui voit passer tout le trafic. Et du coup c’est aussi l’endroit où tu peux appliquer des règles cohérentes.
Options courantes :
- Nginx
- Traefik (super avec Docker)
- Caddy (simple, TLS facile)
- un load balancer managé (selon ton cloud)
Pourquoi c’est important :
- tu réduis les accès directs aux services internes
- tu peux activer des protections (rate limit, headers, WAF léger)
- tu gères mieux TLS, redirections, HSTS, etc.
4. Mettre un WAF ou au minimum un bouclier CDN
Tu n’as pas forcément besoin d’un WAF enterprise. Mais un bouclier basique, oui.
Le combo très courant et efficace :
- Cloudflare (ou équivalent) devant le site
- règles simples : blocage pays si non pertinent, challenge sur chemins sensibles, protection bots
- rate limiting sur endpoints de login
Ça ne remplace pas la sécurité applicative. Mais ça change la vie contre :
- scans automatisés
- tentatives de brute force
- trafic parasite
Pour optimiser ces stratégies de sécurité et en tirer le meilleur parti possible dans le cadre de ta stratégie de growth hacking, il est essentiel d'adopter une approche systématique et réfléchie. Cela inclut non seulement la mise en œuvre des mesures de sécurité mentionnées ci-dessus mais aussi l'exploration de nouvelles opportunités et techniques pour maximiser l'efficacité de ces mesures.
Parallèlement à cela, il peut être utile d'explorer des domaines comme le prompt engineering, qui pourrait offrir des perspectives intéressantes sur la manière d'améliorer l'interaction avec les
5. Réduire la surface DNS (et arrêter de divulguer des infos gratuitement)
Le DNS, c’est souvent un roman. On y trouve tout : anciens serveurs, sous domaines d’environnements, outils internes, endpoints d’API, parfois des fournisseurs.
Actions concrètes :
- supprimer les enregistrements morts
- éviter
staging,dev,preproden public (ou les protéger fortement) - vérifier les CNAME qui pointent vers des services plus utilisés
- traquer les subdomain takeover (CNAME vers ressource inexistante)
Bonus : verrouiller les transferts de zone (AXFR). Ça paraît vieux, mais on voit encore des bêtises.
6. Forcer l’authentification forte partout où c’est possible (oui, même pour « petits » outils)
La surface d’attaque, ce n’est pas que les ports. C’est aussi les comptes.
Priorités :
- activer MFA (TOTP ou clé FIDO2) sur : email, registrar, cloud, GitHub, CMS, outils marketing
- supprimer les comptes inutilisés
- interdire les mots de passe faibles côté app (si tu développes)
- utiliser un gestionnaire de mots de passe, vraiment
Le point critique, c’est le registrar. Si on prend ton compte domaine, c’est fini. Redirections, MX, faux sites, phishing. Et tu cours derrière.
7. Segmenter réseau et services (ne pas tout mettre dans le même panier)
Même sur une petite infra, la segmentation aide énormément.
Exemples simples :
- base de données uniquement sur réseau privé
- admin panels accessibles uniquement via VPN ou IP fixe
- environnements de test isolés du prod
- conteneurs séparés, permissions minimales
Dans Docker par exemple : évite de publier tous les ports sur 0.0.0.0. Beaucoup de gens font -p 3000:3000 par réflexe. Et oublient. Deux semaines après c’est indexé quelque part.
Pour optimiser ces processus et réduire la surface d'attaque tout en améliorant l'efficacité opérationnelle, il serait judicieux d'explorer certains des outils IA disponibles sur le marché qui peuvent automatiser plusieurs aspects de votre business. En outre, pour ceux qui envisagent une carrière dans le growth hacking, il est essentiel de maîtriser ces techniques et outils dès maintenant. Enfin, si vous êtes un digital nomad ou si vous souhaitez travailler tout en voyageant, ces conseils et outils seront également précieux pour maintenir votre sécurité numérique pendant vos déplacements.
8. Durcir SSH et l’accès admin (la base, mais bien faite)
Si SSH doit rester exposé (parfois tu n’as pas le choix), au moins :
- désactiver le login root
- imposer les clés, désactiver le mot de passe
- changer le port ne suffit pas, mais ça réduit un peu le bruit
- fail2ban ou équivalent
- allowlist IP si possible
Fichier sshd_config typique (exemple) :
conf PermitRootLogin no PasswordAuthentication no PubkeyAuthentication yes MaxAuthTries 3 AllowUsers samyn
Et surtout, mets à jour. Les failles OpenSSH ou glibc ne demandent pas ton avis.
Pour plus d'informations sur la sécurité SSH, tu peux consulter cet article sur Adieu SSH, bonjour la liberté : pourquoi.
9. Réduire l’exposition applicative (endpoints, backoffice, fichiers, logs)
Même si tu n’exposes « que » 443, ton application peut exposer trop.
À vérifier :
- backoffice sur
/adminsans restrictions particulières - endpoints d’API non authentifiés
- pages de debug actives
- listing de répertoires
- fichiers sensibles accessibles (
.env, backups.zip, exports, logs)
Un truc très réel : les fichiers de sauvegarde.
site.sql, backup.zip, wp-content/uploads/old/…… ça traîne. Et ça se trouve.
Si tu es sur WordPress, Shopify, ou un stack marketing : fais un tour complet des plugins, scripts, tags, pixels. Moins il y en a, moins tu as de surface.
10. Mettre en place une routine de surveillance (sinon tout revient)
La sécurité, c’est pas un projet. C’est une hygiène. Et une hygiène, si tu la fais une fois, ça ne sert pas longtemps.
Routine simple mensuelle :
- scan des ports depuis l’extérieur
- check DNS et sous domaines
- revue des comptes et accès (qui a encore accès à quoi)
- mises à jour système et applicatives
- audit des secrets (tokens, clés API)
Routine hebdo si tu peux :
- alerting sur connexions admin
- alerting sur nouveaux domaines ou certificats (CT logs)
- surveillance uptime basique et logs
Tu peux aussi te créer une page de notes interne, un mini runbook. Sur Le Blog Tech Pro de Samyn-Antoy ABASSE, j’essaie justement de publier ce genre de ressources actionnables pour éviter d'oublier les bonnes pratiques en matière de sécurité et de productivité digitale. Par exemple, cette méthode pourrait t'aider à mieux gérer ta charge de travail tout en respectant les normes de sécurité recommandées.
Si tu dois faire le strict minimum aujourd’hui :
- fermer tous les ports sauf 80/443
- mettre Cloudflare (ou équivalent) devant le site
- activer MFA sur email + registrar + cloud
- désactiver login root + mot de passe SSH
- vérifier qu’aucune base de données n’est exposée
Ça, rien que ça, réduit déjà énormément la surface.
Quelques erreurs que je vois tout le temps (et qui font mal)
- « c’est un petit site, personne ne va attaquer »
Non. Les bots attaquent tout ce qui répond. - « j’ai caché l’admin en changeant l’URL »
C’est un ralentisseur, pas une serrure. - « j’ai mis un mot de passe fort, ça suffit »
Sans MFA, un phishing ou une fuite de session et c’est terminé. - « on a mis HTTPS, donc c’est sécurisé »
HTTPS protège le transport, pas ton appli.
Conclusion
Réduire l’exposition internet, c’est surtout apprendre à dire non. Non à l’outil ouvert « juste pour tester ». Non au port exposé « en attendant ». Non aux sous domaines qui s’accumulent.
Les 10 actions ci dessus ne demandent pas une équipe sécurité. Elles demandent un peu de discipline, et une vision claire : moins tu montres, moins on peut te prendre.
Si tu souhaites explorer des options intéressantes comme devenir consultant Linux en freelance, je peux également te fournir une version « checklist imprimable » adaptée à ton contexte (freelance, PME, solopreneur, infra Docker, WordPress, stack marketing). En outre, tu peux retrouver d’autres articles dans le même esprit sur mon blog concernant divers sujets tels que Linux et prompt to code, ainsi que des conseils sur les carrières liées à l'IA et prompt engineering.
Questions fréquemment posées
Qu'est-ce que l'exposition internet et pourquoi est-elle un risque pour la sécurité ?
L'exposition internet désigne tout ce qui est visible, accessible et potentiellement attaquable depuis l'extérieur, comme les services, ports ouverts, domaines ou sous-domaines publics. Chaque élément exposé représente une opportunité pour un attaquant. Une mauvaise gestion de cette exposition peut entraîner des failles de sécurité importantes.
Comment inventorier efficacement ce qui est réellement exposé sur internet ?
Il est essentiel de commencer par une inventaire complet comprenant les domaines et sous-domaines actifs, les IP publiques, les ports ouverts et les services SaaS connectés. Des outils comme nmap, dig, nslookup ou des scans Shodan/Censys permettent de détecter ce qui est visible publiquement. Cette étape préalable est cruciale avant toute action de sécurisation.
Pourquoi faut-il fermer les services inutiles exposés sur internet ?
Fermer brutalement les services non nécessaires sur internet est l'action la plus rentable en matière de sécurité. Par exemple, SSH ou RDP accessibles au monde entier, bases de données ouvertes ou panels d'administration en accès direct sont des risques majeurs. Il faut limiter l'exposition aux ports essentiels (80 et 443) et protéger le reste via VPN ou listes d'IP autorisées.
Quel rôle joue un reverse proxy dans la sécurisation de l'exposition internet ?
Un reverse proxy agit comme un gardien du trafic entrant vers vos services internes. Il permet de centraliser les points d'entrée, d'appliquer des règles cohérentes (limitation de débit, headers de sécurité), de gérer TLS facilement et de réduire l'accès direct aux services sensibles. Des solutions courantes incluent Nginx, Traefik ou Caddy.
Dois-je utiliser un WAF pour protéger mon site web ?
Même sans opter pour un WAF enterprise coûteux, il est recommandé d'avoir au minimum un bouclier CDN avec des règles simples comme le blocage géographique ou des challenges sur certains chemins. Des solutions comme Cloudflare offrent une protection basique efficace contre beaucoup d'attaques courantes.
Comment concilier approche sysadmin et business en ligne pour réduire la surface d'attaque ?
Que ce soit votre site web, tunnel de vente, VPS ou outils SaaS, tout finit exposé sur internet. Il faut donc adopter une vision globale mêlant aspects techniques (inventaire, firewall, reverse proxy) et business (gestion des accès aux CRM, automatisations). La réduction pragmatique de la surface d'attaque passe par 10 actions concrètes adaptées à votre contexte.
0 Commentaires