Pour se protéger du zero-day Follina / ms-msdt :
reg copy HKEY_CLASSES_ROOT\ms-msdt HKEY_CLASSES_ROOT\ms-msdt.bak /s /f
reg delete HKEY_CLASSES_ROOT\ms-msdt /f

Lorsque le patch sera dispo:
reg copy HKEY_CLASSES_ROOT\ms-msdt.bak HKEY_CLASSES_ROOT\ms-msdt /s /f
reg delete HKEY_CLASSES_ROOT\ms-msdt.bak /f

Apparemment le bon vieux Rainloop n'est plus trop maintenu ... J'ai donc switché vers SnappyMail et j'en suis pour l'instant vraiment content !

sécuriser ces sysctl système
via https://sebsauvage.net/links/?lNBlBA

Securisation d'openssh via l'ANSSI
via https://sebsauvage.net/links/?ZA7gHA

une faille de sécu sur l'excellent outil RUFUS pour créer des clé usb bootable sur windows.

Mail reçu par (certains?) utilisateurs de Medifile:

Signalement d'une faille de sécurité sur le service Medifile

Madame, Monsieur,

Le 25 août 2021, une faille de sécurité pouvant affecter les comptes utilisateurs du service de partage des images et comptes-rendus d'échographie https://www.medifile.fr/ (« Medifile ») a été détectée.
Le 26 août 2021, les équipes techniques de MONECHO, société éditrice du service Medifile, ont déployé des correctifs permettant de mettre fin à cette faille de sécurité.
Vous êtes titulaire d'un compte utilisateur Medifile et pouvez à ce titre avoir été impacté(e) par cette faille de sécurité présente depuis la mise en ligne du service. MONECHO vous informe de cette faille de sécurité, conformément à ses obligations réglementaires. La Commission Nationale de l'Informatique et des Libertés (CNIL) en a également été informée par MONECHO.
Un tiers malveillant aurait pu utiliser le système d'authentification du site Medifile afin de se connecter sur un ou plusieurs compte(s) utilisateur(s) ne lui appartenant pas et aurait ainsi pu accéder aux données présentes sur ces comptes, à savoir (i) le nom d'utilisateur Medifile, (ii) les coordonnées e-mail du compte Medifile ainsi que (iii) les documents et données de santé partagés par un professionnel de santé avec les utilisateurs concernés via leur compte Medifile. Votre mot de passe Medifile n'est pas concerné par cette faille de sécurité et n'a pas à être modifié.

MONECHO ne dispose d'aucun élément lui permettant d'attester que cette faille de sécurité ait pu être exploitée : aucun signalement de sécurité anormal n'a été adressé à MONECHO par l'un de ses utilisateurs.

Cette faille de sécurité est désormais pleinement résolue.

Au regard de ces éléments, aucune action de votre part n'est nécessaire si ce n'est de continuer à être vigilant comme vous le seriez normalement. Si vous avez le moindre doute concern ant une exploitation illégitime des données de votre compte Medifile (données divulguées sans votre consentement, etc.), nous vous invitons à nous le signaler.

D'ordre plus général, afin de vous sensibiliser aux cyber-risques, vous pouvez prendre connaissance du « Kit de sensibilisation aux risques numériques » édité par le dispositif Cybermalveillance.gouv.fr accessible à l'adresse suivante : https://www.cybermalveillance.gouv.fr/medias/2019/02/kit_complet_de_sensibilisation.pdf

Engagé et vigilant sur le respect des données personnelles des utilisateurs de ses services, MONECHO vous présente ses sincères excuses et reste pleinement mobilisé pour vous fournir une information la plus complète et exhaustive possible. Notre délégué à la protection des données (DPO), M. Florent GASTAUD ( incident@monecho.com ), se tient à votre disposition pour vous fournir toute information complémentaire qui vous serait utile.

Bien cordialement,

Baptiste LEBOCQ,

Directeur MONECHO, éditeur du service Medifile

Dite, suis-je le seul à ne pas pouvoir joindre le flux rss de vmware ici : https://www.vmware.com/security/advisories.xml

Quand je vais un wget, j'ai un 403: Forbidden
$ wget https://www.vmware.com/security/advisories.xml
[...]
2021-05-26 10:38:44 ERROR 403: Forbidden.

$ wget --user-agent="Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:88.0) Gecko/20100101 Firefox/88.0" https://www.vmware.com/security/advisories.xml
[...]
2021-05-26 10:41:54 ERROR 403: Forbidden.

Hahaha, très bizzarement (non), Microsoft supprime les exploits de faille sur leur produit (uniquement) de github... Ça devait arriver, c'est arrivé, ça arrivera encore. Gitlab et concort vont, j'espère, avoir le vent en poupe !

La tournure que prend Netgate pour pfSense CE (la version open-source) va sans doute me faire choisir OPNsense dans un futur proche ...

Gloups

Une pensée à tous ces sportifs (du dimanche?) qui avaient besoin de leur montres pour faire du sport :D

"An internal shell was included in BIOS image in some ThinkPad models that could allow escalation of privilege. CVE-2020-8320" ...

Un (futur) CVE avec un score de 10 pour Salt. C'est le genre de truc qui peut faire très mal...

Une bonne explication de Kr00k, la dernière faille en date de WPA2

Tiens j'avais pas vu passer cette news :D

Jusqu'à présent, j'utilisait "netstat -tunelp" pour avoir les listes des ports ouverts sur un serveur.
Mais dans le cas d'un bind entre IPv6 et IPv4 (qui est parfois activé par défaut, voir /proc/sys/net/ipv6/bindv6only ) certains processus n'était listé QUE en tcp6/IPv6.

Il se trouve que si le bind est activité, le port est aussi en écoute (ouvert) en tcp/ipv4 ! du coup, j'aurais tendance à utiliser "ss -tunelp" qui LUI me montre un poil mieux (voir le flag v6only à la fin) :

netstat -tunelp | grep mysql

tcp6 0 0 :::3306 :::* LISTEN 113 31002 2244/mysqld

ss -tunelp | grep mysql

tcp LISTEN 0 80 :3306 :* users:(("mysqld",pid=2244,fd=17)) uid:113 ino:31002 sk:7e v6only:0 <->

huhuhu

Décorticage d'un cryptominer sur linux assez intéressante :)

Je me note ici quelques liens d'articles sur PFSense (sujet à modifications) :
https://net-security.fr/system/vpn-ipsec-avec-certificats-sur-pfsense/
https://net-security.fr/system/openvpn-et-pfsense-part-1-haute-disponibilite/
https://net-security.fr/system/openvpn-pfsense-part-3-les-certificats/
https://net-security.fr/system/openvpn-pfsense-part-4-openvpn-client-to-site/
https://www.provya.net/?d=2019/05/02/10/21/39-pfsense-troubleshooting-depannage-de-ses-regles-de-filtrage
https://www.provya.net/?d=2019/06/25/08/42/27-best-practices-recommandations-pour-la-configuration-de-votre-firewall

J'en avais marre de renouveller mon certificat wildcard à la main ne faisant pas confiance aux API de facon général ... J'ai craqué, ca s'est plutot bien passé, j'ai du coup également étendu mon certificat "m0le.net" dans le "*.m0le.net", plus qu'un certificat à gerer.
Grosso-merdo :

apt install python3-pip

cp -r /etc/letsencrypt /etc/letsencrypt.bak/

apt purge certbot

pip3 install certbot

pip3 install certbot-dns-ovh

On genere son token sur : https://eu.api.ovh.com/createToken/ avec les droits (Attention, pour tous les domaines): [GET|PUT|POST|DELETE] /domain/zone/*

vi .ovh_creds

dns_ovh_endpoint = ovh-eu
dns_ovh_application_key = xxx
dns_ovh_application_secret = xxx
dns_ovh_consumer_key = xxx

chmod 600 .ovh_creds

/usr/local/bin/certbot certonly --dns-ovh --dns-ovh-credentials .ovh_creds -d *.m0le.net -d m0le.net

Si tout va bien on devrait avoir un fichier de configuration pour le renouvellement dans /etc/letsencrypt/renewal/

La prochaine fois, pour renouveller il faudra (juste) faire:

/usr/local/bin/certbot renew