pas mal.
Je crois que Timo avait parlé d'un système similaire.
Vu dans mes logs ce matin :
192.3.138.103 - - [07/Oct/2014:05:09:27 +0200] "GET /?x=() { :; }; echo Content-type:text/plain;echo;echo;echo Mexpr 1330 + 7
H; HTTP/1.0" 302 539 "() { :; }; echo Co
ntent-type:text/plain;echo;echo;echo Mexpr 1330 + 7
H;" "() { :; }; echo Content-type:text/plain;echo;echo;echo Mexpr 1330 + 7
H;"
Hum… faut se méfier même des ip qui viennent de chez OVH… J’ai déjà eu à plusieurs reprises des machines en *.kimsufi.com qui ont essayé de se connecter sur mon serveur…
du coup, comme je l’ai écrit ici https://chabotsi.fr/links/?kNj0oA un coup de fail2ban et de denyhost, pas de pitié…
Bonne remarque de PCInpact. Le danger vient des sites sécurisés qui se taisent (ou se sont tus). Les règles sont pourtant simples :
- couper l’accès au site
- corriger la faille et changer la clé privée du certificat
- informer les clients (ou utilisateurs)
Ne pas informer les clients (et laisser la faille béante plus de 24h) est une honte…
Claire et efficace comme explication.
Répétons le : si OpenSSL n’avait pas été libre, nous n’aurions jamais su qu’il y avait une faille.
« Mais du coup, on est sensé changer nos clés privées ? »
Il semble que oui : http://www.pcinpact.com/news/86934-openssl-faille-heartbleed-menace-securite-web-sites-ferment.htm
edit: done ;)