tag:linuxfr.org,2005:/tags/stuxnet/publicLinuxFr.org : les contenus étiquetés avec « stuxnet »2017-10-02T10:50:05+02:00/favicon.pngtag:linuxfr.org,2005:Post/385102017-09-24T22:30:21+02:002017-09-24T22:30:21+02:00bien plus que le noyau, stuxnet<p>Alors voilà,<br>
je me suis rendu <a href="https://github.com/janishar/mit-deep-learning-book-pdf">là dessus</a>, pour un rappel sur l'algèbre linéaire et éventuellement sur l'IA.<br>
Mais ne jamais se rendre sur l'adresse du book…<br>
ce n'est pas un stuxnet comme l'énoncé l'indique mais ça m'a bousillé mon noyau!!!<br>
Impossible de faire un simple "ls"…<br>
À bon entendeur, salut<br>
gunsailor</p><div><a href="https://linuxfr.org/forums/linux-noyau/posts/bien-plus-que-le-noyau-stuxnet.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/112742/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/forums/linux-noyau/posts/bien-plus-que-le-noyau-stuxnet#comments">ouvrir dans le navigateur</a>
</p>
gunsailorhttps://linuxfr.org/nodes/112742/comments.atomtag:linuxfr.org,2005:News/331992012-08-07T13:22:56+02:002012-08-07T13:22:56+02:00État des lieux de la sécurité industrielleLicence CC By‑SA http://creativecommons.org/licenses/by-sa/3.0/deed.fr<div><p>Depuis la découverte de Stuxnet en juin 2010 et son analyse, les experts se sont aperçu que certaines des failles utilisées par le malware étaient inconnues (0-day) et de très haut niveau, et que certaines autres étaient au contraire connues et relativement triviales, cette dernière catégorie est majoritairement représentée parmi celles affectant les systèmes <a href="http://fr.wikipedia.org/wiki/SCADA" title="Définition Wikipédia">SCADA</a> Siemens WinCC (<em>Supervisory Control And Data Acquisition</em>, télésurveillance et acquisition de données).</p>
<p>Depuis, beaucoup de personnes se sont intéressées à la sécurité des systèmes de contrôle industriel au sens large. Les systèmes SCADA sont dorénavant bien connus pour être vulnérables mais ils ne sont pas les seuls.</p>
<p>Le monde de la sécurité informatique découvre depuis peu ce que beaucoup de gens savent déjà, les systèmes de contrôle industriel sont de vraies passoires et la mise en péril d'un processus industriel est relativement simple.</p></div><ul><li>lien nᵒ 1 : <a title="http://securid.novaclic.com" hreflang="fr" href="https://linuxfr.org/redirect/82918">Blog Securid</a></li><li>lien nᵒ 2 : <a title="http://aluigi.org" hreflang="en" href="https://linuxfr.org/redirect/82919">Blog de Luigi Alummi</a></li><li>lien nᵒ 3 : <a title="http://securid.novaclic.com/securite-internet/referentiels-securite-si.html?utm_source=rss&utm_medium=rss&utm_campaign=referentiels-securite-si" hreflang="fr" href="https://linuxfr.org/redirect/82920">Référentiels de sécurité qui vont bien</a></li></ul><div><h2 id="sommaire">Sommaire</h2>
<ul><li>
<a href="#toc_0">Systèmes de contrôle industriel</a>
<ul><li>
<a href="#toc_1">Bases</a>
</li>
<li>
<a href="#toc_2">Nécessité du couplage avec les systèmes de gestion</a>
</li>
</ul></li>
<li>
<a href="#toc_3">Des mauvaises habitudes, la réalité du terrain</a>
</li>
<li>
<a href="#toc_4">Un monde de failles</a>
</li>
<li>
<a href="#toc_5">La jungle du web</a>
</li>
<li>
<a href="#toc_6">Des automates qui font le café</a>
</li>
<li>
<a href="#toc_7">La réponse des acteurs</a>
<ul><li>
<a href="#toc_8">Les failles «&nbsp;Forever Day&nbsp;»</a>
</li>
<li>
<a href="#toc_9">Les constructeurs inconscients</a>
</li>
</ul></li>
<li>
<a href="#toc_10">Que faire ?</a>
<ul><li>
<a href="#toc_11">Pour les admins réseaux</a>
</li>
<li>
<a href="#toc_12">Pour les exploitants de systèmes</a>
</li>
<li>
<a href="#toc_13">Pour les concepteurs de systèmes de contrôle</a>
</li>
</ul></li>
<li>
<a href="#toc_14">Conclusion</a>
</li>
</ul><h2 id="toc_0">Systèmes de contrôle industriel</h2>
<p>Par systèmes de contrôle industriel (en anglais ICS pour Industrial Control System), on désigne les systèmes qui dans l'industrie permettent de contrôler certains processus industriels, ces systèmes permettent par exemple de contrôler les actionneurs sur une ligne de fabrication, de piloter des installations ou de réguler des procédés…</p>
<p>Ces systèmes doivent répondre à un certain nombre de contraintes liées à leur nature telles que la sûreté de fonctionnement, le temps réel, la disponibilité 24/7, un environnement contraignant, des utilisateurs non spécialisés en informatique…</p>
<p>Les motivations pour un attaquant de s'attaquer à un système de contrôle industriels peuvent être multiples :</p>
<ul><li>éroder la sûreté de fonctionnement de la ligne de fabrication afin de ralentir ou saboter un processus ;</li>
<li>voler le programme d'un système de contrôle à des fins d'espionnage.</li>
</ul><h3 id="toc_1">Bases</h3>
<p>Les systèmes de contrôle industriels répondent bien évidement à une certaine théorie. À l'instar du modèle OSI pour les réseaux informatiques, les concepteurs de ces systèmes ont leur propre pseudo-modèle :</p>
<pre>
<code class=""> +---+-----------------+
| 3 | Supervision |
+---+-----------------+
| 2 | Automatisme |
+---+-----------------+
| 1 | Terrain/bus |
+---+-----------------+
</code>
</pre>
<p>La couche terrain désigne la couche physique, là où les divers bus industriels se situent, on y retrouve notamment des technologies telles que <a href="http://fr.wikipedia.org/wiki/Modbus">ModBus</a>¹, <a href="http://en.wikipedia.org/wiki/EtherCAT">Ethercat</a>¹, <a href="http://fr.wikipedia.org/wiki/Controller_Area_Network">CAN</a>… C'est sur ces réseaux que sont connectés les divers actionneurs d'une chaîne de fabrication.</p>
<p>La couche automatisme est la couche où s'exerce la pseudo-intelligence de ces réseaux ; les automates, connectés aux réseaux sus-cités sont les chefs d'orchestre, ils commandent les actionneurs suivant un ordre bien défini et suivant diverses conditions.</p>
<p>La couche supervision est quant à elle celle qui est la plus liée à l'informatique, elle permet, via un ordinateur connecté sur le réseau de terrain ou sur l'automate de récolter diverses informations sur l’exécution du processus, ces informations remontent alors via des protocoles tels que OPC¹ ou SCADA¹ vers des logiciels de supervision dédiés tels que PcVue¹ ou Panorama¹. On est donc loin de la supervision classique connue des administrateurs réseaux via SNMP et des logiciels de la famille de Nagios.</p>
<p>Viennent à côté les logiciels de configuration qui permettent de programmer les automates afin de leur faire réaliser les opérations voulues, ces configurations sont la plupart du temps réalisées grâce à des langages de programmation propres à chaque automate. Ensuite, la programmation est chargée soit en envoyant un binaire du programme, soit en reflashant tout le microcode/firmware de l'automate via USB ou autres.</p>
<p>Le point qui fâche quant à la plupart de ces logiciels, automates et protocoles est qu'ils sont propriétaires et sont pour la plupart la définition même du <em>bloatware</em>. Certaines implémentations sont très douteuses, notoirement buggées, et on va le voir, très faciles à défaire d'un point de vue sécurité.</p>
<p>¹ <em>: technologies connues comme vulnérables</em></p>
<h3 id="toc_2">Nécessité du couplage avec les systèmes de gestion</h3>
<p>On pourrait se dire qu'isoler les systèmes incriminés sur des réseaux physiques dédiés devrait suffire à les rendre moins vulnérables. Malheureusement, ce n'est pas si simple, la prédisposition des utilisateurs à se servir de clé USB rompt souvent cet isolement, de nombreux exemples sont là pour le prouver ; en outre, les grands progiciels du marché cherchent actuellement à étendre leurs champs d'actions afin d'englober également la partie production, ceci doit permettre d'ajuster au plus près la production d'un bien à sa demande. Les décideurs pressés sont friands de ce genre de fonctionnalités afin de pouvoir être encore plus pressés. Il faut donc <a href="http://securid.novaclic.com/cyber-securite-industrielle/linter-connexion-des-reseaux-de-production-et-de-gestion-boite-de-pandore-ou-solution.html">composer avec cette contrainte</a>.</p>
<p>On constate donc qu'un isolement n'est pas souhaité et serait de toute façon faillible ; ce rapprochement est très récent et certaines habitudes des utilisateurs ne sont plus du tout adaptées aux nouvelles contraintes entraînées par ces nouvelles interconnexions.</p>
<h2 id="toc_3">Des mauvaises habitudes, la réalité du terrain</h2>
<p>On constate que de nombreuses mauvaises habitudes existent tant de la part des concepteurs/installateurs que des exploitants.</p>
<p>Certains installateurs ont tout d'abord comme habitude de connecter les automates qu'ils installent à l'Internet afin de pouvoir intervenir rapidement dessus en cas de besoin. Des recherches sur <a href="http://www.shodanhq.com/">Shodan HQ</a> avec les noms de marques d'automates révèlent plusieurs milliers d'unités connectées à l'Internet et sans doutes vulnérables tout autour du monde. Il faut noter que certains exploitants ne sont pas au courant que leurs systèmes sont ainsi connectés à l'Internet.</p>
<p>La seconde mauvaise habitude est l'utilisation de couples identifiant/mot de passe très faibles tel que : admin/1234 ou admin/00 ou 01/01…</p>
<p>Certains postes de supervision ont également un utilisateur qui est continuellement connecté et sur lequel n'importe qui peut donc intervenir en bien ou en mal.</p>
<p>Il s'agit là d'un florilège de mauvaises pratiques, cette liste n'est pas exhaustive ; mais par contre, tous les éléments de cette liste peuvent facilement être retrouvés sur un seul et même système de gestion.</p>
<h2 id="toc_4">Un monde de failles</h2>
<p>En plus de toutes ces mauvaises pratiques, les technologies employées sont vulnérables. Un hacker italien, Luigi Auriemma, s'est intéressé de près au sujet, mais face à l'ampleur de l'insécurité, il s'est fixé une règle : lorsqu'il trouve 6 failles sur un automate ou un logiciel, il passe à un autre et ne passe pas plus de deux jours d'investigation par automate/logiciel. Le résultat est impressionnant, des dizaines de produits <a href="http://aluigi.org/">sont devenus vulnérables</a> !</p>
<p>On constate grâce à ses travaux et grâce aux travaux des autres hackers que toutes les couches des systèmes de gestion sont impactés : les réseaux sont parfois perméables, les automates peuvent manifestement être tous compromis car dotés d'architectures trop anciennes, et les outils de supervision sont également faillibles. Un attaquant a donc une surface d'attaque potentiellement très grande à exploiter.</p>
<p>Quelques logiciels de configuration sont également touchés, pour ne rien arranger.</p>
<h2 id="toc_5">La jungle du web</h2>
<p>Ajouté à cela, les constructeurs ont eux aussi succombé à la mode du web (pas 2.0 néanmoins) et proposent presque tous des serveurs web sur leurs automates afin de les administrer.</p>
<p>L'interface web permet divers niveaux de contrôle suivant les marques allant de la modification du code s'exécutant sur l'automate à la simple activation d'options.</p>
<p>Ces serveurs web sont bien souvent de piètre qualité, utilisant des technologies telles qu'ActiveX, Flash et consort. Les pages HTML sont de très mauvaise qualité généralement.</p>
<p>On constate qu'une grande part des failles divulguées concernent ces serveurs web. Ces serveurs web ne sont pas toujours désactivables, et leur utilité est très limitée ; les installateurs leur préfèrent souvent le logiciel de configuration pour des raisons d'ergonomie.</p>
<p>Ces serveurs web sont donc un vecteur d'attaque très important alors qu'ils ne sont que très peu utilisés par les installateurs et les exploitants, une personne malintentionnée et techniquement douée arrivera par contre à faire des choses très poussées avec ce même serveur web.</p>
<p>En prime, certains automates ne proposent pas de page d'authentification en HTTPS pour l'administration de ces automates, seule une authentification en HTTP est possible (qui est parfois utilisée au travers du grand Ternet), négligence des concepteurs ou incapacité à implémenter une pile SSL valide sur leur matériel spécifique ?</p>
<h2 id="toc_6">Des automates qui font le café</h2>
<p>Certaines marques telles que Wago essaient d'être les plus généralistes possibles : quatre langages de programmation différents, un très large panel de protocoles pris en charge ; on peut raisonnablement s'inquiéter de la nécessité de toutes ces fonctionnalités qui élargissent la surface d'attaque et le nombre de bugs possibles.</p>
<p>Cette même marque s'est également démarquée via la révélation d'une porte dérobée dans certains de ces automates, cette <em>backdoor</em> est maintenant publique.</p>
<h2 id="toc_7">La réponse des acteurs</h2>
<h3 id="toc_8">Les failles « Forever Day »</h3>
<p>Face à cet afflux de rapport de vulnérabilités, les constructeurs réagissent de diverses façons : beaucoup ne communiquent pas, certains assument même publiquement qu'ils ne vont <a href="http://securid.novaclic.com/cyber-securite-industrielle/forever-day.html?utm_source=rss&utm_medium=rss&utm_campaign=forever-day">pas publier de correctif</a>. C'est par exemple le cas d'ABB qui a annoncé qu'ils n'allaient pas corriger une vulnérabilité affectant toute une gamme de produit SCADA car considérée en fin de vie, mais malgré tout toujours très utilisée dans l'industrie. </p>
<p>Au delà des failles qui ne seront jamais corrigées, certains exploitants ne peuvent mettre à jour certains automates car les programmes qu'ils exécutent ont besoin de certaines failles pour fonctionner (cas de la synchronisation de deux automates grâce à la lecture/écriture de la mémoire de l'un dans l'autre par exemple).</p>
<p>On est donc confronté à des mises en œuvre de processus qui seront vulnérables tant qu'elles seront en fonctionnement du fait de ces problématiques.</p>
<h3 id="toc_9">Les constructeurs inconscients</h3>
<p>Les constructeurs n'ayant pas encore été touchés par une vulnérabilité se cantonnent quant à eux à croire en la sécurité de leurs produits ; certains tels que WIT vont même jusqu'à vanter sur les salons la sécurité en avançant des points tels que le coté propriétaire du système, tout en présentant en toute confiance des pages web d'authentification en HTTP depuis l'Internet…</p>
<p>Certaines réponses sont aussi très maladroites, le fabricant américain Tridium a récemment répondu à une faille de type <a href="http://en.wikipedia.org/wiki/Directory_traversal_attack">directory traversal</a> permettant de récupérer le fichier <em>/etc/passwd</em> de ses automates Niagara JACE à travers l'interface web en changeant simplement l'emplacement du fichier incriminé, ce qui n'a bien sûr pas changé quoi que ce soit au problème.</p>
<h2 id="toc_10">Que faire ?</h2>
<h3 id="toc_11">Pour les admins réseaux</h3>
<p>Les administrateurs réseaux doivent auditer tous leurs réseaux, des automates peuvent se cacher dans des endroits improbables (gestion de la ventilation ou autre) et isoler les équipements en question ; il faut aussi bien s'assurer qu'aucun automate ne soit connecté à Internet de quelque manière que ce soit.</p>
<p>Les postes de supervision sont tout aussi sensibles et doivent subir le même traitement. Une politique de gestion des droits très fine par utilisateur doit être mise place afin de répondre de manière efficace aux différents problèmes exposés plus haut.</p>
<p>Des outils tels que <code>metasploit</code> et <code>nessus</code> sont régulièrement mis à jour avec les nouveaux exploits, donc vous pouvez les utiliser (avec précaution tout de même sur les systèmes en production), des scripts <code>nmap</code> sont également de la partie.</p>
<h3 id="toc_12">Pour les exploitants de systèmes</h3>
<p>La responsabilité des exploitants est de demander un audit complet du réseau et notamment de la partie production. Ils peuvent également faire inclure dans leur contrat de support avec les installateurs une clause pour être averti des failles affectant les produits qu'ils ont en exploitation.</p>
<h3 id="toc_13">Pour les concepteurs de systèmes de contrôle</h3>
<p>Les concepteurs sont ceux qui ont le plus de travail, certains constructeurs avouent sans rougir ne pas avoir mis à jour leurs produits depuis plusieurs années, ce qui fera autant de retard à rattraper.<br />
Les conseils qui peuvent leur être prodigués sont nombreux mais on peut déjà citer :</p>
<ul><li>publier des mises à jour quand le besoin s'en fait sentir ;</li>
<li>mettre à la poubelle les automates des années 90 et 2000 pour repartir sur des bases saines ;</li>
<li>reléguer la partie basse du logiciel à des spécialistes en employant des noyaux reconnus tel FreeRT, Linux, QNX ou autres qui savent implémenter correctement des protections et qui permettent de réutiliser des composants plus haut niveau tels que des piles SSL valables ou des interfaces SSH correctement implémentées ;</li>
<li>ne pas implémenter des serveur web partout et se contenter des protocoles déjà reconnus ;</li>
<li>publier des mises-à-jour quand le besoin s'en fait sentir ;</li>
<li>être compatible avec SNMP v3 ;</li>
<li>ne pas installer de porte dérobée.</li>
</ul><h2 id="toc_14">Conclusion</h2>
<p>Vous l'aurez compris, le bilan est loin d'être rose.<br />
Les systèmes de contrôle industriels étant des systèmes ayant des durées de vie très importantes (jusqu'à 15 ans), on est en droit de s'inquiéter actuellement de leur sécurisation, afin d'éviter les problèmes dans les années à venir.</p>
<p>Ces systèmes de contrôles se retrouvent partout, et ils se retrouvent employés dans de nombreux autres domaines, où si ce ne sont pas les mêmes systèmes, les mêmes erreurs de conception sont réalisées…</p>
<p>Par exemple, dans le célèbre fast-food au clown, les bornes de commande « commande facile » sont vulnérables à une série de tapotement alterné sur les coins de l'écran tactile de la page d'accueil suivie d'un PIN à quatre chiffres, permettant d'accéder à une interface… très intéressante (NdM.: nous avons retiré une partie des infos détaillant la faille).</p>
<p>La <a href="https://www.digitalbond.com/wp-content/uploads/2011/11/DecisionTree.png">nimage de circonstance</a>. </p></div><div><a href="https://linuxfr.org/news/etat-des-lieux-de-la-securite-industrielle.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/95088/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/news/etat-des-lieux-de-la-securite-industrielle#comments">ouvrir dans le navigateur</a>
</p>
RbNNils Ratusznikbaud123Benoît SibaudNÿcopatrick_ghttps://linuxfr.org/nodes/95088/comments.atomtag:linuxfr.org,2005:Diary/327062012-06-11T23:28:15+02:002012-06-11T23:28:15+02:00De tout, de rien, des liens, du vrac (mais moins bookmarks cette fois)<p>Et voici un nouveau numéro !</p>
<p>Bon, faudrait que j'arrive à me caler sur trolldi pour publier, ça pourrait être un peu plus marrant…</p>
<p>Quoi qu'il en soit, j'ai essayé de faire ça un peu mieux en catégorisant un peu plus, même si c'est pas encore parfait. Les liens sont plutôt inclus dans le texte, à vous de dire si c'est mieux ou si vous préférez de bêtes listes.</p>
<p>Pour cette fois, principalement trois thèmes :</p>
<ul><li>Des histoires de boulot</li>
<li>Quelques news de sécurité</li>
<li>Un peu de développement</li>
</ul><p>Alors commençons avec le boulot.</p>
<p>Connaissez-vous le principe de Peter ? Non, je ne parle pas du <a href="http://fr.wikipedia.org/wiki/syndrome de peter pan" title="Définition Wikipédia">syndrome de peter pan</a>.</p>
<p>Le <a href="http://fr.wikipedia.org/wiki/Principe_de_Peter">Principe de Peter</a> est un principe vraiment intéressant qui dit, en gros « <em>Avec le temps, tout poste sera occupé par un incompétent incapable d'en assumer la responsabilité</em> ».</p>
<p>En résumé rapide (si vous voulez en savoir plus allez lire le lien) lorsqu'on est compétent à un poste, qu'on réussi, on a tendance à monter dans la hiérarchie. Le truc c'est qu'on est probablement moins compétent dans ce nouveau poste. Et ainsi de suite on s'élève jusqu'à un niveau d'incompétence problématique alors qu'initialement on était compétent.</p>
<p>A méditer lors des choix d'évolution de carrière…</p>
<p>En parlant de postes, pour vous développeurs (enfin ça peut sûrement s'appliquer à d'autres) comment se passe votre temps de travail ? Etes-vous contraint par des horaires strictes ? Horaire libres ? Finalement, dans quel cas êtes vous le plus productif et combien d'heures par jour de boulot ? Voici deux articles sur le sujet, l'un sur le fait d'avoir <a href="http://n.survol.fr/n/2-a-3-heures-par-jour">2 à 3 heures par jour</a> de réellement productives, l'autre sur le fait d'<a href="http://n.survol.fr/n/etre-comptable-de-son-temps">Être comptable de son temps</a>.</p>
<p>Pour ma part je suis plutôt d'accord avec ces posts. Souvent, avoir un décompte trop précis ou vouloir que chaque minute soit réellement productive a l'effet inverse. Combien de fois trouvons-nous des solutions en regardant par la fenêtre ou une fois sorti du boulot ?</p>
<p>Je me souviens que, lorsque je travaillais à 100km de chez moi, je faisais alors pas mal de voiture (ok, 2h en temps normal, 2h20 si c'était sous la neige). Histoire de rajouter un peu, le temps était mesuré, en gros je pointais… Mais quelle connerie au final ! Parfois, j'étais bloqué sur un problème en fin d'après midi. Pas moyen de s'en sortir. Et pas question de quitter puisque je pointais et avait un nombre d'heure mini à faire (le résultat de la pointeuse était aussi que personne ne faisait plus lorsqu'il l'aurait fallu). Donc j'attendais en gros. Je cherchais quand même, j'étais pas en train de me promener sur facebook (faudrait que je regarde la date mais ça n'existait peut-être même pas, en tout cas je ne connaissais pas - et de toute façon j'avais pas le net sur mon poste…). Puis, arrivé l'heure fatidique, je repartais prendre ma voiture et faire 100 bornes. Souvent, au bout de quelques kilomètres je trouvais la solution. Alors je la notais pour le faire le lendemain matin.</p>
<p>Au final, n'aurais-je pas été gagnant (et mon entreprise également) à pouvoir m'échapper un moment puis revenir avec la solution ? Si j'avais pu, j'aurais résolu le problème avant la fin de la journée. En voulant me forcer à rester, la solution n'a été implémentée que le lendemain. En croyant augmenter la <em>productivité</em> au final elle a été réduite, en plus de ne pas donner envie.</p>
<p>Mais d'ailleurs, si on laissait plus de liberté à ces gens qui font des logiciels, ça donnerait quoi ? Et pourquoi pas un <s>plan de domination mondiale</s> <a href="http://undergoogle.com/tools/GoogleMasterPlanEN.html">Master plan</a> !</p>
<p>Et en parlant de domination, où on en est côté cyberwar ces derniers temps ? Car il semble que ça avance réellement. Notamment côté Stuxnet, où il semblerait que <a href="http://reflets.info/la-nsa-et-lunite-8200-etaient-a-lorigine-de-stuxnet/">La NSA et l’Unité 8200 étaient à l’origine de Stuxnet</a>.</p>
<p>En même temps, dans certains cas, pas besoin de puissance folle pour bouffer du mot de passe Linkedin. Ils ont oubliés le poivre. Ou le sel. Rha je sais plus :-) <a href="http://blog.linkedin.com/2012/06/06/linkedin-member-passwords-compromised/">An Update on LinkedIn Member Passwords Compromised</a></p>
<p>Par contre, impossible évidemment de passer sous silence la jolie <a href="http://seclists.org/oss-sec/2012/q2/493">0day concernant MySQL et MariaDB</a>. Tellement gros qu'on a du mal à y croire, surtout à quel point c'est <a href="http://pastie.org/private/903voijkkz8nmde3yqj4rw">facile</a>. On souffle par contre dans l'oreille que certaines debian ne seraient pas concerné, il faut une version suffisamment récente pour que ça se produise :-)</p>
<p>Ces petites news vous ont mis en bouche ? Ok, il ne reste plus qu'à passer à la partie développement alors.</p>
<p>D'ailleurs, pour ceux qui font du java, vous connaissez <a href="http://code.google.com/p/google-guice/">Guice</a> ? C'est un système d'injection de dépendance vraiment bien foutu, développé par Google. De mon côté ça a complètement changé mon point de vue sur Java. J'ai enfin pu faire du java qui soit agréable avec ça et je conseil à tous ceux qui font du java d'aller voir d'un peu plus près.</p>
<p>Quoi qu'il en soit, je ne suis pas le seul à penser ça. Et on peut le voir par exemple dans <a href="http://sitebricks.org/#home">Sitebricks :: A Web platform</a>. Il s'agit d'un petit framework web java, utilisant massivement Guice. Je ne l'ai pas encore testé mais ça ne saurait tarder, ça me tente vraiment bien. Ha oui, l'auteur était développeur Google Wave, mainteneur Guice. Pour lui des outils comme GWT mais aussi <a href="https://developers.google.com/closure/">closure</a> sont <em>overengineered</em> et il a voulu faire quelque chose de plus simple.</p>
<p>Histoire de rester dans le web, quelques petits liens en vrac :</p>
<ul><li><a href="http://www.slideshare.net/JMF/gestion-des-dpendances-dans-un-projet-php-forum-php-2012">Gestion des dépendances dans un projet PHP</a></li>
<li><a href="http://keynote.hoa-project.net/ForumPHP12/">Anatomie du test</a></li>
<li><a href="http://news.dartlang.org/2012/06/dart-editor-can-debug-command-line-apps.html">Dart Editor can debug command-line apps</a></li>
<li><a href="http://www.igvita.com/2012/06/04/chrome-networking-dns-prefetch-and-tcp-preconnect/">Chrome Networking: DNS Prefetch & TCP Preconnect</a></li>
<li><a href="http://static.zealous-studios.co.uk/projects/web_tests/PPI%20tests.html">Pixels Per Inch Awareness and CSS Px</a></li>
</ul><p>Voici dans un autre registre une <a href="http://www.cpprocks.com/cpp-ruby-coffeescript-language-complexity/">comparaison visuelle de C++, Ruby et CoffeeScript</a>. Intéressant, mais peut-on réellement comparer des langages aussi différents et donc les objectifs (notamment d'abstraction) sont plutôt éloignés ?</p>
<p>Pour continuer, voici une présentation pour le moins intéressante : <a href="http://www.slideshare.net/jedi4ever/devops-is-a-verb-its-all-about-feedback-13174519">Devops is a verb its all about feedback</a></p>
<p>Si vous pensiez vous ennuyer les jours qui arrivent, j'ai ce qu'il vous faut. Rien de moins qu'une petite <a href="http://fabiensanglard.net/doom3/index.php">revue du code source de Doom3</a> ! Mine de rien un sacré travail de réalisé. Ce gars est un peu un malade je crois. Pour ma part je ne l'ai pas encore lu. Par contre je suis convaincu que c'est entre autre en lisant ou étudiant les codes d'autres personnes qu'on peut s'améliorer. C'est loin d'être négligeable, alors un titre pareil.</p>
<p>Ha oui, et il y a aussi twitter qui vient de libérer <a href="https://github.com/twitter/zipkin">zipkin</a>. Si j'ai bien compris c'est utilisé pour tracer une <em>application</em> dans un contexte distribué. Et il est vrai que nous en avons de plus en plus. Tous ceux qui bossent avec de multiples machines, de multiples services, savent combien il est difficile de savoir précisément ce qui se passe entre l'arrivée du requête et sa réponse. Comment visualiser ceci et pouvoir agir ensuite ? C'est un peu le but de cet outil. Et c'est construit à partir du <a href="http://research.google.com/pubs/pub36356.html">papier de Google Research sur le sujet, Dapper</a>.</p>
<p>Et pour finir ce petit épisode, un peu de lol !</p>
<p><a href="http://www.happyprog.com/pairhero/">PairHero: A game of collaboration for pair programming</a> Vous trouviez le pair programming ennuyant ? Ce petite plugin Eclipse est fait pour vous alors !</p>
<p>J'aimerais vraiment bien mettre en place ce qui suit. Si les gens le prennent bien il y a vraiment moyen de rigoler. D'ailleurs, certains d'entre vous ont-ils déjà mis en place <a href="https://github.com/mroth/lolcommits">lolcommits</a> ?</p><div><a href="https://linuxfr.org/users/crev/journaux/de-tout-de-rien-des-liens-du-vrac-mais-moins-bookmarks-cette-fois.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/94482/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/crev/journaux/de-tout-de-rien-des-liens-du-vrac-mais-moins-bookmarks-cette-fois#comments">ouvrir dans le navigateur</a>
</p>
CrEvhttps://linuxfr.org/nodes/94482/comments.atomtag:linuxfr.org,2005:Diary/325042012-04-25T11:53:51+02:002012-04-25T11:53:51+02:00Après Stuxnet, le virus Viper force l'Iran à arrêter les installations pétrolières de l’île de KhargLicence CC By‑SA http://creativecommons.org/licenses/by-sa/3.0/deed.fr<p>Ave</p>
<p>Vous vous souvenez de <a href="http://fr.wikipedia.org/wiki/Stuxnet">Stuxnet</a>, ce virus qui avait bloqué les installations nucléaires de l'Iran ?</p>
<p>Récemment les installations pétrolières iraniennes de l'île de Kharg ont été arrêtées à cause de Viper, un nouveau virus.<br />
Un lien<br /><a href="http://english.sina.com/world/2012/0423/460971.html">http://english.sina.com/world/2012/0423/460971.html</a></p>
<p>Je cite<br />
"a virus, which has been used to attack, has firstly damaged the motherboards and then deleted the data."</p>
<p>Reste à savoir qui a écrit et diffusé ce virus…</p>
<p>Attendons l'analyse de ce virus.</p><div><a href="https://linuxfr.org/users/palm123/journaux/apres-stuxnet-le-virus-viper-force-l-iran-a-arreter-les-installations-petrolieres-de-l-ile-de-kharg.epub">Télécharger ce contenu au format EPUB</a></div> <p>
<strong>Commentaires :</strong>
<a href="//linuxfr.org/nodes/90443/comments.atom">voir le flux Atom</a>
<a href="https://linuxfr.org/users/palm123/journaux/apres-stuxnet-le-virus-viper-force-l-iran-a-arreter-les-installations-petrolieres-de-l-ile-de-kharg#comments">ouvrir dans le navigateur</a>
</p>
palm123https://linuxfr.org/nodes/90443/comments.atom