Cédrix
1 line
13 KiB
JSON
1 line
13 KiB
JSON
[{"uuid":"423c197b-c7d4-45be-81cd-2f3180d3c8cb","slug":"20231126-google-ip-protection","title":"Google IP protection","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-11-25 08:24:54","created_at":"2023-11-25 08:24:54","updated_at":"2023-11-25 08:24:54","tags":[],"plain":"Le site protonvpn.com a publié un article critiquant la nouvelle fonctionnalité de Google Chrome appelée \"Protection IP\", la qualifiant de tromperie en matière de protection de la vie privée. L'article explique que cette fonctionnalité permet à Google de surveiller vos activités en ligne tout en prétendant offrir une protection de la vie privée. Il souligne que Google utilise cette tactique de \"lavage de la vie privée\" pour masquer ses véritables intentions. L'article révèle que Google utilise la Protection IP pour collecter des données sur les utilisateurs, ce qui renforce son modèle commercial basé sur la publicité ciblée. Il explique également que Google a déjà de nombreuses autres méthodes pour suivre les utilisateurs, rendant la Protection IP redondante. Enfin, l'article encourage les utilisateurs à opter pour des navigateurs respectueux de la vie privée et des VPN indépendants pour réellement protéger leur vie privée en ligne. Il conclut en encourageant les utilisateurs à faire des choix éclairés pour préserver leur vie privée en ligne. source : https:protonvpn.com/blog/google-ip-protection/ Crédit image : //"},{"uuid":"919b79e5-92da-40e4-9720-d29093d952dc","slug":"configurer-l-ip-phone-spa942-pour-ovh","title":"Configuration du Linksys IP Phone SPA942 pour OVH","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2023-02-09 19:05:25","created_at":"2023-02-09 19:05:25","updated_at":"2023-02-09 19:05:25","tags":[],"plain":"Pour accéder au menu de configuration, branchez le téléphone sur votre réseau et allez dans le menu : Configuration / Réseau pour obtenir l'IP locale attribuée au téléphone (ex : 192.168.XXX.XXX) Dans un navigateur internet, entrez cette IP dans la barre d'adresse. Vous devriez accéder à l'interface de configuration de votre téléphone Linksys. Dans celle ci, cliquez sur le lien Admin login situé en haut à droite, puis cliquez sur advanced afin d'accéder au paramètres qui nous intéressent. Voici les différents paramètres utilisables pour les lignes VOIP de chez OVH : Dans l'onglet System, section Optional Network Configuration :\\\\\nPrimary NTP Server : fr.pool.ntp.org (il s'agit là d'un exemple de serveur NTP qui permet la mise à l'heure automatique du terminal)\nSecondary NTP Server : fr.pool.ntp.org Dans l'onglet SIP, section NAT Support Parameters :\nSTUN enable : no\nSTUN Test Enable : no Dans l'onglet SIP, section RTP Parameters :\nRTP Port Min : 30000\nRTP Port Max : 40000 Dans l'onglet Regional, section Miscellaneous :\nTime Zone : GMT+01:00 (il s'agit du fuseau horaire, ici celui pour la France)\nDaylight Saving Time Rule : start=3/24/7/02:0:0;end=10/24/7/02:0:0;save=1 . Cette règle permettra au téléphone de passer à l'heure d'été du dernier dimanche de mars au dernier dimanche d'octobre. Dans l'onglet \"Phone\", section General :\nStation Name: Le nom de station qui sera affiché sur le téléphone\nVoice Mail Number: le numéro de messagerie est 123 par défaut Dans l'onglet \"Ext 1\", section Call Feature Settings :\nVoice Mail Server : mwi.voip.ovh.net Dans la section Proxy and Registration :\nProxy : sip.ovh.fr (depuis octobre 2012, l'adresse du proxy est sip.ovh.fr et non plus sip.ovh.net)\nUse Outbound Proxy : YES\nOutbound Proxy : 91.121.129.20:5962\nRegister Expires : 3600\nDans la section Subscriber Information :\nDisplay Name : Nom de la ligne (apparait lors de vos communications entre lignes OVH)\nUser ID : l'userId fournit dans le mail reçu par OVH (en général le numéro de la ligne (00339XXX...))\nPassword : Le mot de passe fournit avec la ligne (ou un autre si vous l'avez modifié)\nUse Auth ID : mettre à YES\nAuth ID : identique à User ID normalement (c'est à dire en général le numéro de la ligne (00339XXX...))\nDans la section Audio Configuration :\nPreferred Codec : G711u\nSecond Preferred Codec : G711a\nThird Preferred Codec : G729a Dans l'onglet Dial Plan :\nDial Plan : \nEmergency Number : 112 Dans l'onglet User :\nDate Format : day/month\nTime Format : 24hr"},{"uuid":"53f60783-eae4-4347-854e-a12d8389d292","slug":"ip","title":"ip","category":"Informatique","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2021-01-16 04:03:11","created_at":"2021-01-16 04:03:11","updated_at":"2021-01-16 04:03:11","tags":[],"plain":"Utilitaire de configuration réseau TCP/IP. A noter que le manuel de cette commande se résume à un renvoi vers une page Internet. Exemples\nLister les interfaces avec leurs paramètres\nLister les interfaces avec adresses IP v.4 et V.6 et un peu de couleurs"},{"uuid":"b39be5dd-2533-4487-9957-ca8cd26ed75d","slug":"2024-05-13-de-la-couleur-dans-ip","title":"De la couleur dans la commande ip","category":"Journal geek","author":"cedric@abonnel.fr","cover":"","published":true,"published_at":"2024-06-19 06:06:06","created_at":"2024-06-19 06:06:06","updated_at":"2024-06-19 06:06:06","tags":[],"plain":"Dans Fedora 40, la commande (généralement utilisée pour configurer les paramètres réseau) semble avoir une nouvelle fonctionnalité où la couleur est désormais toujours activée. Cela signifie que même si vous n'utilisez pas d'options spécifiques pour activer la couleur dans la sortie de la commande , elle sera toujours colorée par défaut. Cela peut rendre la sortie de la commande plus visuellement distincte et facile à interpréter. Crédit image : Cedrix"},{"uuid":"0bba1ad7-e4cb-49a6-9467-fcfac2e09a93","slug":"deuxiemes-pas-devops-durcir-et-fiabiliser-un-serveur-debian","title":"Deuxièmes pas DevOps : durcir et fiabiliser un serveur Debian","category":"informatique","author":"cedric@abonnel.fr","cover":"cover.jpg","published":true,"published_at":"2026-06-08 07:00","created_at":"2026-05-12 23:01:34","updated_at":"2026-05-13 22:53:46","tags":{"logiciels":["Fail2ban","Debian"]},"plain":"Une fois le système de base configuré (dépôts, mises à jour, , identification — sujets traités dans l'article précédent), la machine est fonctionnelle mais encore vulnérable et un peu fragile pour un usage sérieux. Ce deuxième article s'attaque aux gestes qui transforment un serveur « qui marche » en un serveur sur lequel on peut raisonnablement faire tourner quelque chose : sécuriser l'accès SSH, mettre en place un pare-feu, automatiser les correctifs de sécurité et soigner quelques détails opérationnels.\r\n\r\nSécuriser l'accès SSH\r\n\r\nSSH est la porte d'entrée principale d'un serveur Linux. C'est aussi, statistiquement, la cible la plus attaquée : n'importe quelle IP publique reçoit en permanence des tentatives de connexion automatisées. Deux gestes simples changent radicalement la donne.\r\n\r\nPasser à l'authentification par clé\r\n\r\nLes mots de passe, même longs, restent vulnérables aux attaques par force brute et au phishing. Une paire de clés cryptographiques est à la fois plus sûre et plus pratique au quotidien.\r\n\r\nCôté poste de travail, on génère une paire de clés modernes :\r\n\r\n\r\n\r\nL'algorithme est aujourd'hui le choix par défaut recommandé : clés courtes, signatures rapides, sécurité solide. Le commentaire () facilite l'identification de la clé quand on en gère plusieurs.\r\n\r\nOn copie ensuite la clé publique sur le serveur :\r\n\r\n\r\n\r\nCette commande dépose la clé publique dans côté serveur avec les bonnes permissions. À partir de là, la connexion se fait sans saisir de mot de passe — il faut tester depuis une nouvelle session avant de passer à l'étape suivante, sous peine de risquer de se retrouver enfermé dehors.\r\n\r\nDésactiver la connexion root et les mots de passe\r\n\r\nUne fois la connexion par clé validée, on durcit la configuration SSH. Le fichier à modifier est :\r\n\r\n\r\n\r\nLes directives importantes à positionner (ou décommenter) sont :\r\n\r\n\r\n\r\nLa première interdit toute connexion directe en via SSH : on devra obligatoirement se connecter avec un utilisateur normal puis élever ses droits via . La deuxième supprime complètement l'authentification par mot de passe, ne laissant plus que les clés. La troisième confirme explicitement que l'authentification par clé est active.\r\n\r\nOn recharge ensuite le service pour appliquer les changements :\r\n\r\n\r\n\r\nImportant : garder la session SSH actuelle ouverte et tester la nouvelle configuration depuis un autre terminal avant de fermer la première. En cas de problème, on peut encore corriger le tir.\r\n\r\nPour aller un cran plus loin, changer le port SSH par défaut (22) vers un port moins évident réduit considérablement le bruit dans les logs. Ce n'est pas de la sécurité au sens strict (un scan le retrouvera), mais c'est un filtre efficace contre les attaques automatisées.\r\n\r\nMettre en place un pare-feu\r\n\r\nPar défaut, Debian n'a aucun pare-feu actif. Tout port ouvert par un service installé sera donc directement exposé. Deux outils standards existent : (le successeur officiel d', bas niveau et puissant) et (une surcouche pensée pour la simplicité). Pour démarrer, est le bon compromis.\r\n\r\n\r\n\r\nLa logique consiste à tout bloquer en entrée par défaut, puis à n'ouvrir explicitement que ce qui doit l'être :\r\n\r\n\r\n\r\nSi SSH écoute sur un port non standard, remplacer par (ou le port choisi). Oublier cette étape avant un est un grand classique du verrouillage involontaire.\r\n\r\nPour les services web, on ouvrira typiquement les ports 80 et 443 :\r\n\r\n\r\n\r\nL'état du pare-feu se vérifie avec :\r\n\r\n\r\n\r\nSur une architecture où la machine est derrière un reverse proxy (cas fréquent quand on expose plusieurs services sur un même domaine), seuls les ports utiles côté proxy doivent être ouverts au monde extérieur. Les services applicatifs eux-mêmes restent accessibles uniquement depuis le réseau interne.\r\n\r\nAutomatiser les correctifs de sécurité\r\n\r\nLes failles de sécurité ne préviennent pas, et personne n'a envie de lancer manuellement chaque matin sur dix machines. Le paquet applique automatiquement les mises à jour du dépôt .\r\n\r\n\r\n\r\nLa configuration se trouve ensuite dans . Par défaut, seuls les correctifs de sécurité sont appliqués automatiquement, ce qui est généralement le bon compromis : on profite des patches critiques sans risquer qu'une mise à jour fonctionnelle introduise une régression sur un service en production.\r\n\r\nQuelques options qui méritent l'attention dans ce fichier :\r\n: à régler sur si l'on accepte les redémarrages automatiques après une mise à jour de noyau, ou si l'on préfère les piloter à la main. La directive permet alors de choisir l'horaire.\r\n: pour recevoir un rapport par mail des mises à jour appliquées, à condition d'avoir un MTA configuré sur la machine.\r\n\r\nLe bon réflexe consiste à vérifier de temps en temps les logs dans pour s'assurer que tout se déroule sans heurts.\r\n\r\nSoigner les détails opérationnels\r\n\r\nQuelques outils complémentaires améliorent significativement le confort et la résilience d'un serveur.\r\n\r\nFail2ban surveille les logs d'authentification et bannit temporairement les IP qui tentent trop de connexions échouées. Même avec SSH par clé uniquement, le service réduit considérablement le bruit dans les journaux :\r\n\r\n\r\n\r\nLa configuration par défaut surveille déjà SSH ; elle peut être étendue à d'autres services (nginx, Postfix, etc.) via des fichiers dans .\r\n\r\nLogwatch ou journalctl méritent qu'on s'y attarde. Sur une Debian récente, est l'outil central pour consulter les logs systemd :\r\n\r\n\r\n\r\nPrendre l'habitude de jeter un œil aux logs régulièrement — ou de mettre en place une remontée centralisée si l'on gère plusieurs machines — change beaucoup de choses en exploitation.\r\n\r\nUn swap raisonnable, sur une VM ou un serveur dédié, évite que la machine ne devienne complètement injoignable en cas de pic de consommation mémoire. Sur un conteneur LXC en revanche, c'est généralement géré au niveau de l'hyperviseur.\r\n\r\nEt après ?\r\n\r\nAvec ces réglages, le serveur est dans un état correct pour accueillir des services réels : la surface d'attaque est réduite, les correctifs s'appliquent tout seuls, et les logs racontent ce qui se passe. La suite logique est l'installation de la pile applicative proprement dite (serveur web, base de données, runtime) et la mise en place d'un reverse proxy pour exposer plusieurs services derrière un même point d'entrée.\r\n\r\nComme évoqué dans le premier article, le moment où l'on commence à enchaîner ces étapes sur plusieurs machines est exactement celui où il faut basculer vers de l'automatisation : un script shell bien rangé pour commencer, puis Ansible ou un équivalent quand le parc grossit. Une bonne pratique consiste à versionner ces scripts dans un dépôt Git dédié à l'infrastructure, au même titre que le code applicatif."}] |