Encore une preuve qu'on ne résout pas un problème relationnel à l'aide d'une solution technique : le contrôle parental doit être fait par les parents, pas par une machine.
Il n'est pas toujours aisé de s'y retrouver dans les ROM pour Android entre GrapheneOS, /e/, LineageOS, etc. Ce comparatif permet d'y voir plus clair en matière de vie privée, de sécurité et d'autres critères.
Sans surprise pour ma part, GrapheneOS se hisse au-dessus du lot (cf. liens partagés par le passé dans mon Shaarli). Mais il ne supporte que les Google Pixel, alors si vous avez un smartphone d'une autre marque, il faudra partir sur une autre ROM.
Le même auteur a publié d'autres comparatifs, en entête de la page.
Lorsque votre certificat SSL est compromis (par exemple parce que sa clé privée a été volée), vous pouvez le révoquer, c'est-à-dire le signaler comme étant invalide et plus digne de confiance.
Mais comment le navigateur sait-il qu'un certificat est révoqué, car ce n'est pas une information que celui-ci contient ? Deux mécanismes existent : CRL et OCSP.
Cet article les présente ainsi que les problématiques liées.
ÉDIT : OCSP a depuis été déprécié en faveur de CRL : https://www.abetterinternet.org/post/replacing-ocsp-with-crls/
Lorsque vous achetez un certificat SSL, il n'est pas rare que des garanties, des assurances, soient proposées pour couvrir certains dommages pouvant résulter de mauvais usages. Quels usages ? Est-ce que ces assurances servent vraiment à quelque chose ?
Potyos s'est intéressé aux connexions massives vers une machine, souvent connu sous le terme d'attaque DDoS ou attaque par déni de service. Avec la création d'un petit lab à la maison pour tester différents outils et observer la réaction du serveur face à autant de connexions simultanées :
J'aime bien son approche empirique, cela me rappelle un peu "ici Amy Plant".
Il le rappelle dans sa vidéo mais il vaut mieux 2 fois qu'une : mais ne tentez pas ça sur autre chose que des machines vous appartenant. Vous risquez d'avoir de gros ennuis et pensez que les pare-feux n'ont pas de log serait une grossière erreur.
CloudFlare vient d'ailleurs de déjouer une attaque monumentale de 7.3Tbps, ce qui constitue un nouveau record mondial. Autant dire qu'avec votre serveur dédié hébergé chez AWS ou OVH vous ne risquez pas de pouvoir absorber autant de trafic sans tout planter 
mais heureusement ces hébergeurs fournissent souvent une protection native en amont pour éviter d'écrouler leur infra.
En bonus une autre vidéo de Potyos qui s'était intéressé aux protections WiFi WPA :
Merci Potyos pour la vulgarisation 
Article original écrit par Mr Xhark publié sur Blogmotion le 22/06/2025 |
Pas de commentaire |
Attention : l'intégralité de ce billet est protégée par la licence Creative Commons
Il va falloir que je me penche sur Reaction, car comme le souligne l'auteur, Fail2Ban fait le taf et très bien, mais est gourmand, trop
J'ai essayer Crowdsec, pas compris le bouzin du tout. Je ne doute pas que cela vient de moi, mais il faut installer beaucoup de truc,en configurer encore plus pour qu'au final il ne bloque que ce qui l'arrange, sans comprendre pourquoi (avec les règles de base fourni par Crowdsec). Sans compter qu'il faut un compte et que tout passe par leur serveur, bref pas convaincu du tout.
Reaction a l'air simple à prendre en main et a configurer et souvent quand ça parait simple, c'est que l'on s'est donné du mal à faire un bon produit. De plus la version 2 passe de Go à Rust.
Et c'est français en plus !!!
Edit : la documentation
Voici un module Python bien pratique pour injecter les entêtes HTTP de sécurité, avec des valeurs par défaut et strictes qui font bien le travail (cf HSTS, COEP, COOP, CSP, Cache-Control, Server, Permissions-Policy, Referrer-Policy, X-Content-Type-Options, X-Frame-Options, et custom).
Et il prend en charge quasiment tous les framework web actuels !
Connexion