Le proxy ou comment renforcer anonymat et sécurité photo

Proxy, VPN ou Tor : protéger son anonymat et sa sécurité en ligne

par · Lecture: 12 minutes

Un proxy est un serveur intermédiaire entre votre appareil et un service distant. Au lieu de contacter directement un site web, votre navigateur demande au proxy de le faire pour vous. Le site voit alors l’adresse IP du proxy, pas forcément la vôtre.

Sur le papier, c’est simple. Dans la vraie vie, c’est plus subtil. Un proxy peut aider à filtrer, journaliser, accélérer, contrôler, contourner certains blocages ou masquer partiellement une adresse IP. En revanche, il ne garantit pas l’anonymat complet. Et un mauvais proxy peut même réduire votre sécurité.

Cet article remplace donc l’ancienne logique des “listes de proxies anonymes” par une approche plus moderne : comprendre ce qu’un proxy protège, ce qu’il ne protège pas, et quand il vaut mieux utiliser un VPN, Tor Browser, HTTPS ou du DNS chiffré.

Lire Proxy, VPN ou Tor : protéger son anonymat et sa sécurité en ligne

Serveur dédié : sécurisation de la couche TCP/IP photo

Sécuriser la couche TCP/IP d’un serveur Linux avec sysctl

par · Lecture: 7 minutes

Durcir la couche TCP/IP d’un serveur Linux avec sysctl

Un serveur dédié n’a pas besoin de se comporter comme un routeur de bordure. Dans la majorité des cas, il héberge des services, répond à des connexions entrantes, puis renvoie ses réponses proprement. C’est tout. Pas besoin d’accepter des redirections ICMP douteuses, du source routing exotique ou des paquets qui sentent le spoofing à trois baies de distance.

On peut donc durcir une partie de la pile TCP/IP directement au niveau du noyau Linux avec sysctl. Ce n’est pas un pare-feu. Ce n’est pas une baguette magique. Toutefois, c’est une couche de défense saine, rapide à appliquer, et complémentaire à iptables, nftables, UFW et fail2ban.

Ce que l’on va sécuriser

L’objectif est de réduire la surface d’attaque réseau côté noyau. Nous allons notamment :

  • limiter le spoofing IP avec le reverse path filtering ;
  • activer une protection de base contre les attaques SYN flood ;
  • refuser les redirections ICMP ;
  • désactiver le source routing IPv4 et IPv6 ;
  • ignorer les réponses ICMP manifestement invalides ;
  • éviter les vieux scénarios de smurfing ;
  • désactiver le forwarding si le serveur ne fait pas routeur ;
  • garder IPv6 proprement configuré, sans casser la connectivité.

Sur un serveur web classique, ces réglages conviennent très bien. En revanche, adaptez-les si votre machine fait du routage, du VPN, du VRRP, du conteneur réseau avancé, du BGP, du Anycast, du multi-WAN ou du load-balancing bas niveau. Là, sysctl devient vite un sport de combat.

Lire Sécuriser la couche TCP/IP d’un serveur Linux avec sysctl

Solution pour l'erreur cURL error 7: Failed to connect to XXX port 443: Connection refused photo 1

cURL error 7 : corriger “Failed to connect to port 443”

par · Lecture: 13 minutes

L’erreur cURL error 7: Failed to connect to port 443 apparaît quand cURL n’arrive pas à établir une connexion réseau vers un serveur distant. Le port 443 correspond généralement à HTTPS.

Exemple fréquent avec WordPress, WP-CLI, Composer, GitHub, une API externe ou un plugin :

cURL error 7: Failed to connect to api.github.com port 443: Connection refusedLangage du code : CSS (css)

Le message peut varier légèrement :

cURL error 7: Failed to connect to example.com port 443 after 0 ms: Couldn't connect to server

Dans tous les cas, l’idée est la même : cURL a tenté d’ouvrir une connexion TCP vers l’hôte distant, mais elle a échoué. Il faut donc diagnostiquer le chemin réseau avant d’accuser WordPress, PHP ou le certificat SSL.

Lire cURL error 7 : corriger “Failed to connect to port 443”

Articles suivants →