Il est parfois nécessaire en traitement d'incident d'analyser une machine pour trouver le processus responsable d'une communication TCP ou UDP jugée suspecte. Les outils permettant d'afficher les communications actives des processus (netstat, resmon...) ne sont alors pas toujours adaptés. Par exemple lorsqu'il s'agit d'identifier l'origine d'une communication UDP ou dans le cas d'une communication nocturne qui implique une analyse a posteriori. Il faut alors pouvoir journaliser les événements de communications réseaux des processus de la machine. L'article présente une méthode simple basée sur un outil standard Windows : l'analyseur de performances.

J'ai plus d'abonnements au Gartner, Forrester et autres cabinets d'analystes. Enfin, ma boîte me donne plus les accès à cette si substantifique moelle de réflexion, d'analyse, de synthèse, de futurologie ! Ça tombe bien, car ça commençait à fortement me soûler toute cette logorrhée marketing reprise la bouche en cœur par mes collègues, mes managers, mes clients, ma copine, mon chat... (je n'ose ni n'arrive à mettre d'ordre dans cette liste !)

Vous avez déjà lu de longs fichiers de CSS ? Il est assez difficile de s'y retrouver... Pourtant une solution simple existe : adopter des conventions de nommage permettant d'y voir plus clair. Et plutôt que d'inventer sa propre convention, autant essayer d'utiliser ce qui existe déjà.

Ce logiciel, assez simple d'usage, vous permettra de générer et de déployer rapidement les règles pour votre firewall. Il s'adresse particulièrement aux administrateurs et ingénieurs sécurité chargés de la mise en place et de la gestion de plusieurs pare-feu.

L'idée de paiement sans argent liquide n'est pas récente : « Chaque fois qu'un Gonda désirait quelque chose de nouveau, des vêtements, des objets, il payait avec sa clé. Il pliait le majeur, enfonçait sa clé dans un emplacement prévu à cet effet et son compte, à l'ordinateur central, était aussitôt diminué de la valeur de la marchandise ou du service demandé. » [1]. Depuis plus de vingt ans, la carte à puce est au cœur du système bancaire. Elle fait l'objet de toutes les attentions de la part des banques et des utilisateurs, mais aussi, voire encore plus, de la part des pirates. La carte à puce en tant que coffre-fort électronique impénétrable était censée apporter le niveau de sécurité élevé requis pour les applications bancaires. Mais il semble que deux lois de base aient été oubliées par les banques, à savoir que le niveau de sécurité d'un système est caractérisé par son maillon le plus faible et qu'un système sécurisé ne résiste pas éternellement aux attaques. Nous allons tenter dans cet article de décrire le rôle de la carte à puce dans le système bancaire français. Nous détaillerons d'abord le premier protocole qui était encore en vigueur il y a quelques années. Nous verrons ensuite les failles de sécurité que ce protocole présentait et comment elles ont été exploitées par les pirates avec notamment les « YesCard ». Enfin, nous étudierons les principales évolutions de sécurité liées en particulier à ces attaques.

ELK, acronyme issu des trois composants principaux de la suite (Elasticsearch, Logstash, Kibana) est depuis longtemps maintenant une référence dans la collecte des logs et leur analyse. Les derniers ajouts sur la suite Elastic et notamment sur le Machine Learning posent une question : ELK ne serait-il pas en passe de devenir un SIEM incontournable ?

Ca y est ! Jugeant que les numéros de versions atteints (2.6.39) avec la nomenclature actuelle n'avaient plus de sens, Linus Torvalds a succombé aux chants de sirène du marketing (ou plutôt aux voix dans sa tête, d'après lui-même) en décidant que ce nouveau noyau ne serait jamais celui qu'il était destiné à devenir, le 2.6.40, mais bel et bien le 3.0, premier d'une nouvelle lignée. Changement purement cosmétique, car ce noyau introduit un lot de changements ni plus ni moins importants que les précédentes versions. De notre côté, nous ne changeons rien non plus, en vous présentant la première partie des nouveautés de ce buzz-compliant linux-3.0.tar.gz.

Nous voilà de retour dans cette seconde partie d'analyse des évolutions des noyaux 3.5 et 3.6. Un assez long développement est consacré à l'infrastructure VFIO qui comble les limitations de UIO pour le développement de drivers en espace utilisateur. La sécurité est également abordée avec l'intégration de mécanismes de protection empêchant toute exploitation de vulnérabilités ToCtToU liées à l'utilisation de liens symboliques et physiques. D'autres aspects sont aussi traités, comme l'ajout de l'infrastructure Uprobes.