# Vérifier les connexions sortantes d'un serveur

> Vérifier les connexions sortantes d'un serveur : rattacher les processus avec ss et lsof, évaluer les destinations inconnues, limiter la fuite de données.

Source : https://phpsos.de/fr/blog/ausgehende-verbindungen-pruefen/  
État : 25/10/2026  
Fournisseur : PHP SOS, Assistance d'urgence PHP et sécurité des serveurs. Aide immédiate par WhatsApp : https://wa.me/491736494914?text=Bonjour%20PHP%20SOS%2C%20nous%20avons%20besoin%20d%27aide%20avec%20notre%20serveur%20PHP.%20Entreprise%20%3A%20%E2%80%A6%20Site%20web%20%3A%20%E2%80%A6

**En bref :** vous vérifiez les connexions sortantes d'un serveur avec `ss -tunap` ou `lsof -i`, qui rattachent chaque connexion à un processus. Les connexions vers la base de données, le serveur de messagerie, les serveurs de mise à jour et les interfaces connues sont normales. Les connexions de processus PHP ou du serveur web vers des destinations inconnues, les ports inhabituels et les connexions durables sans motif sont des signaux d'alerte d'un contrôle à distance ou d'une fuite de données. À long terme, un filtrage sortant qui n'autorise que les destinations nécessaires aide.

## Pourquoi regarder vers l'extérieur en dit autant

Dans la recherche d'une intrusion, la plupart regardent les fichiers. Mais un attaquant veut faire quelque chose de son accès : recharger des outils, recevoir des commandes, exfiltrer des données ou utiliser le serveur pour du spam ou des attaques contre d'autres. Tout cela exige des connexions vers l'extérieur.

Un serveur web n'établit de lui-même que peu de connexions, et la plupart sont prévisibles : il interroge la base de données, transmet des courriels, appelle des interfaces de paiement ou d'expédition et récupère des mises à jour. C'est pourquoi les connexions étrangères se remarquent ici particulièrement. Selon les rapports dont nous disposons, les connexions sortantes font partie des signaux d'alerte généraux après une intrusion ; il n'existe pas d'indicateurs de compromission (Indicators of Compromise) confirmés spécifiquement pour PHP2Shell. D'autres signes sont résumés dans [Suis-je déjà compromis ?](https://phpsos.de/fr/php2shell/bin-ich-gehackt-anzeichen/).

## Lister les connexions sortantes et les rattacher aux processus

Les commandes suivantes ne font que lire. Exécutez-les en tant que root, sinon les indications de processus manquent.

```bash
# Toutes les connexions TCP établies avec processus
ss -tnp state established

# TCP et UDP, y compris les services en écoute
ss -tunap

# Connexions par programme et par utilisateur, sans résolution de noms
lsof -i -n -P | grep -v LISTEN

# Seulement les connexions des processus des utilisateurs du serveur web
lsof -i -n -P -u www-data 2>/dev/null
```

Dans la sortie, faites attention à trois colonnes : le processus, l'adresse de destination avec le port et l'utilisateur. Une connexion de `php-fpm` vers la base de données sur le port 3306 est normale. Une connexion d'un programme de nom inconnu issu de `/tmp` vers une adresse étrangère sur un port inhabituel ne l'est pas. Sous quel utilisateur PHP tourne dépend de la distribution et du panneau.

## Normal ou suspect ? Un classement

| Observation | Plutôt normal | Plutôt suspect |
|---|---|---|
| Destination | propre base de données, serveur de messagerie, API connues, serveurs de mise à jour | adresses inconnues sans rapport avec l'application |
| Processus | php-fpm, serveur web, services de messagerie et de mise à jour | programmes inconnus, processus issus de `/tmp` ou `/dev/shm` |
| Port | 443, 3306, 5432, 587 | ports hauts inhabituels, ports typiques d'IRC |
| Durée | brève, en phase avec les requêtes | ouverte en permanence, aussi la nuit sans visiteurs |
| Volume | faible et régulier | pics soudains du volume de données sortant |
| Trafic de messagerie | envoi via le serveur de messagerie prévu | nombreuses connexions directes sur le port 25 |

De nombreuses connexions sur le port 25 indiquent un envoi de spam ; un article distinct y est consacré, [Le serveur envoie du spam](https://phpsos.de/fr/blog/server-verschickt-spam/).

## Évaluer une destination inconnue

Une adresse étrangère dans la liste n'est pas encore une preuve. Avant de décider, établissez où mène la connexion et qui l'a établie. Ces étapes ne modifient pas non plus quoi que ce soit :

1. **Déterminer le processus :** prendre le PID dans `ss` et vérifier avec `ls -l /proc/PID/exe` et la ligne de commande quel programme se trouve derrière.
2. **Chercher la destination :** avec `dig -x <IP>`, déterminer le nom, et avec `whois <IP>`, l'opérateur réseau.
3. **Rapprocher de l'application :** demander au développeur ou au prestataire si votre application utilise ce service.
4. **Vérifier l'historique :** les journaux du pare-feu et du réseau montrent depuis quand la connexion existe et combien de données ont circulé.
5. **Sauvegarder les résultats :** enregistrer les sorties avec l'heure avant d'arrêter ou de bloquer quoi que ce soit.

Comptez avec des résultats ambigus. De nombreux services légitimes tournent chez de grands fournisseurs de cloud et de CDN, dont les adresses ne permettent aucune conclusion sur le client. Inversement, les attaquants utilisent eux aussi des serveurs cloud loués. Un opérateur réseau connu n'est donc ni une levée de doute ni une preuve ; ce qui est décisif, c'est que le processus et l'objectif correspondent à votre application.

Un instantané avec `ss` ne montre que ce qui est ouvert à l'instant. Les connexions brèves, établies à la minute, ne se voient que dans les journaux. C'est pourquoi les journaux du pare-feu ou de flux sont souvent plus importants que le regard sur le serveur lui-même pour la question d'une fuite de données.

> **Important:**
> Si des données ont peut-être quitté votre serveur et que des données à caractère personnel sont concernées, une obligation de notification au titre du RGPD peut exister, en règle générale sous 72 heures. Clarifiez cela tôt avec votre délégué à la protection des données ; contexte sous [Obligation de notification RGPD en 72 heures](https://phpsos.de/fr/compliance/dsgvo-meldepflicht-72-stunden/). Ceci ne constitue pas un conseil juridique.

## Ne pas oublier DNS et conteneurs

Toute fuite de données n'exige pas une connexion visible vers une adresse étrangère. Les résolutions de noms via DNS vont au résolveur de votre centre de données et passent à peine inaperçues dans la liste de `ss`. Les attaquants peuvent empaqueter des données dans de longs sous-domaines d'apparence aléatoire et les faire sortir ainsi par des requêtes DNS. Les journaux du résolveur en fournissent des indices : un nombre inhabituel de requêtes vers le même domaine étranger, des noms très longs ou des requêtes à des moments où personne n'utilise le site.

Si vos applications tournent dans des conteneurs, l'hôte ne voit souvent les connexions des conteneurs que comme du trafic du réseau de conteneurs. Vérifiez alors dans chaque conteneur séparément, dans la mesure où les outils y sont présents, ou exploitez les connexions au niveau de l'hôte et du pare-feu.

```bash
# Connexions à l'intérieur d'un conteneur (si ss est présent dans l'image)
docker exec <container> ss -tnp 2>/dev/null

# Sur l'hôte : connexions suivies par le noyau, si conntrack est installé
sudo conntrack -L 2>/dev/null | head -50
```

## Limiter durablement le trafic sortant

La prévention la plus efficace est un filtrage sortant : le serveur ne peut atteindre que les destinations dont il a réellement besoin, tout le reste est bloqué et journalisé. Pour les attaquants, il devient ainsi nettement plus difficile de recharger des outils ou de siphonner des données, même s'ils peuvent exécuter du code.

Le chemin commence par une liste des destinations nécessaires, que vous déduisez des connexions collectées ci-dessus. Suit une phase où les connexions bloquées ne sont que journalisées, avant que le blocage soit activé. Les services de paiement, les serveurs de mise à jour et les interfaces à adresses changeantes exigent ici un soin particulier. La façon dont un pare-feu pour serveurs web est construit dans son ensemble est décrite dans [Pare-feu pour serveurs web : n'ouvrir que les ports nécessaires](https://phpsos.de/fr/blog/firewall-fuer-webserver/).

## Comment PHP SOS aide-t-il concrètement ?

- **Vérifier les connexions :** nous rattachons toutes les connexions actives à des processus et à des usages et évaluons les destinations inconnues.
- **Estimer la fuite de données :** nous exploitons les journaux du pare-feu et du réseau et établissons si et quand des données ont été transmises.
- **Limiter la sortie :** avec vous, nous élaborons une liste de destinations autorisées et mettons en place le filtrage sortant progressivement.
- **Surveiller durablement :** avec la [surveillance de sécurité](https://phpsos.de/fr/leistungen/security-monitoring/), nous signalons les connexions nouvelles ou inhabituelles.


## Questions fréquentes

**Quelles connexions sortantes sont normales pour un serveur web ?**  
Sont typiques les connexions vers la base de données, le serveur de messagerie, les services de paiement et d'expédition, les serveurs de mise à jour et les interfaces connues de l'application. Tout ce qui ne se rattache à aucun de ces usages mérite un examen plus attentif.

**Comment voir quel processus a établi une connexion ?**  
Avec ss -tunap ou lsof -i -n -P en tant que root. Les deux affichent pour chaque connexion l'ID du processus et le nom du programme. Vous reconnaissez ainsi si la connexion provient de PHP, du serveur web ou d'un programme étranger.

**Une connexion inconnue signifie-t-elle que des données ont fui ?**  
Pas nécessairement. C'est toutefois un indice qui doit être clarifié. Savoir si et quelles données ont été transmises ne se détermine souvent qu'avec les journaux du pare-feu ou du réseau. Si des données à caractère personnel sont concernées, des obligations de notification peuvent exister.

**Un serveur web devrait-il seulement avoir le droit d'établir des connexions sortantes ?**  
Seulement vers les destinations dont il a besoin. Un filtrage sortant qui bloque tout le reste complique considérablement pour les attaquants le rechargement d'outils et la fuite de données. Il doit toutefois être soigneusement testé.

## Sources

- [BSI : office fédéral allemand de la sécurité des technologies de l'information](https://www.bsi.bund.de/)
- [RGPD, art. 33 : notification à l'autorité de contrôle](https://dsgvo-gesetz.de/art-33-dsgvo/)
- [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)