MISC N°
Numéro
72

Comprendre le déni de service pour mieux le prévenir

Temporalité
Mars/Avril 2014
Article mis en avant

Résumé

Il n'est pas simple de définir correctement ce qu'est exactement un déni de service. Tout simplement parce qu'il y en a une infinité. La cible peut-être le service à un utilisateur, un logiciel client, un logiciel serveur, une machine complète, voire un ou plusieurs réseaux. L'attaque peut parfois n'être qu'un simple octet qui titille le bogue d'une application qui plantera.

Dans ce numéro...


D'une certaine manière, cet édito est la suite du précédent [1]. Sans doute une manie de vieux con de parler dans le vide, et donc de faire les questions et les réponses ;)
SAP est la solution d'ERP la plus utilisée parmi les grandes sociétés. Sa popularité la rend néanmoins plus sujette aux malwares ou aux attaques plus ciblées. L'objectif de cet article est de détailler comment certaines fonctionnalités ou vulnérabilités peuvent être exploitées. Quelques pistes de protection seront également présentées.
Depuis sa version 2.2, Volatility supporte les images mémoire des systèmes Linux en proposant des fonctionnalités similaires à l'analyse d'acquisition RAM Windows. Cependant, à l'heure actuelle, il existe peu de littérature autour de son utilisation sur un environnement Linux. Nous allons donc voir dans cet article en deux parties comment se préparer au mieux, de la phase d'acquisition à l'analyse de l'image mémoire résultante ainsi que les fonctionnalités proposées par Volatility. La première présente la phase d'acquisition et le fonctionnement interne de Volatility tandis que la seconde sera une analyse en profondeur d'une acquisition mémoire d'un système Linux.
Dans la jungle des malwares se cachent les malwares bancaires, ces programmes malveillants s'efforçant de vous dérober vos économies lorsque vous consultez le site de votre banque en ligne. À l'ombre des très connus ZeuS, Citadel et autres SpyEye parviennent à émerger de nouvelles familles comme Hesperbot, qui provoque de sensibles dégâts financiers depuis l'été 2013.
Les DoS, distribués ou non sont vieux comme Internet. Déjà Morris paralysait le réseau dans les années 80 et ce qui est longtemps apparu comme une légende est (enfin) considéré comme une menace réelle. Cet article ne traitera donc pas d'innovation, mais offre une vue globale sur les techniques utilisées pour « interrompre de manière temporaire ou permanente tout ou partie d'un service ».
Dans le petit monde des attaques par déni de service, les attaques par amplification sont particulièrement redoutées. Elles sont efficaces quelle que soit la cible, sont très difficiles à contrer et permettent à des attaquants dont les moyens sont modestes de mettre à mal les plus grands acteurs d'Internet. Le concept d'amplification est ancien, mais de nouveaux vecteurs sont régulièrement découverts. Cet article se propose d'en expliquer le fonctionnement, d'analyser les exemples les plus populaires et de présenter certaines contre-mesures.
Il est de plus en plus facile de générer une attaque de type DDoS. Pourquoi pourriez-vous en être victime ? Comment vous en prémunir ?
Pour lancer un DDoS, il faut évidemment contrôler plusieurs machines. Mais au lieu de prendre la main sur le PC poussif de monsieur tout le monde simplement connecté via l'ADSL, pourquoi ne pas prendre directement la main sur des serveurs Web ?
Les communications utilisant le protocole IPv6 sur Internet représentent un taux très minime de l'ensemble des communications. À titre d’exemple, les utilisateurs accédant à Google en IPv6 ne représentent que 1,78% de l'ensemble des connexions [1]. Cependant, ces communications sont souvent présentes dans la majorité des réseaux internes, soit d'une manière officielle, et cela après déploiement du protocole par les administrateurs, soit sous forme de trafic « non officiel » utilisant les adresses générées automatiquement par les nœuds du réseau. Ce dernier cas est souvent négligé par les administrateurs, même s'il peut être source d’attaques contre le réseau. Dans cet article, nous allons présenter quelques types d'attaques auxquelles les réseaux IPv6 sont vulnérables, ainsi que différents outils de protection et de supervision permettant de réduire le risque contre ces attaques.
Configurer TLS côté serveur est difficile. 19% des sites en HTTPS proposent toujours SSLv2. 28% vont négocier une session avec DES_CBC_SHA et ses clés de 56 bits si le client le demande. Il y a un peu plus d'un an, la majorité des experts en SSL/TLS recommandaient RC4 à AES. Quelques mois plus tard, c'était l'inverse. Une partie de la communauté cryptographique supporte Perfect Forward Secrecy, alors qu'une autre le refuse pour cause de lenteur. Il existe même des doutes sur le niveau réel de sécurité fourni par AES-256, par rapport à la version 128 bits. Ajoutons à cela une bonne dose de perte de confiance dans les standards existants, en particulier depuis que l'on sait Dual_EC_DRBG backdoored, et nous voici avec une parfaite recette de confusion et d'incohérence. Les désaccords sur la meilleure façon de configurer HTTPS sont nombreux. Et si le débat est utile aux experts, il est presque impossible pour un non-initié de naviguer dans la nébuleuse TLS, et d'en extraire une configuration de référence.
Le paradoxe de la sécurité informatique est que plus une attaque est simple à mettre en œuvre, plus il est difficile de s'en protéger. Les DoS ne font pas exception à cette règle. Néanmoins des solutions existent, souvent complexes, structurantes et onéreuses.
Chaque année, le nombre d’incidents et d’attaques ne cesse d’augmenter. Quelles que soient les méthodes d’intrusion utilisées par les attaquants, elles évoluent rapidement et aucun système d'information n'est sûr à 100 %. Beaucoup de travaux traitent du sujet de la détection d’intrusion en temps réel sous l'angle des systèmes IDS dits « passifs ». Sur la même échelle de temps et le même spectre d’analyse (un paquet, une requête), nous trouvons également des systèmes dits « actifs » de prévention d’intrusion (IPS, WAF) qui bloquent le trafic suspect. Il faut préciser que ces sondes IDS/IPS servent à détecter des tentatives d'intrusion, mais pas au sens d'attaques réussies. Elles remontent des événements en temps réel et visent à identifier de manière proactive ou réactive des comportements malveillants. Les plus efficaces d’entre elles peuvent inclure, dans leur mécanisme d’alerte, une information liée au succès de l’attaque.

Magazines précédents

Les derniers articles Premiums

Les derniers articles Premium

De la scytale au bit quantique : l’avenir de la cryptographie

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Imaginez un monde où nos données seraient aussi insaisissables que le célèbre chat de Schrödinger : à la fois sécurisées et non sécurisées jusqu'à ce qu'un cryptographe quantique décide d’y jeter un œil. Cet article nous emmène dans les méandres de la cryptographie quantique, où la physique quantique n'est pas seulement une affaire de laboratoires, mais la clé d'un futur numérique très sécurisé. Entre principes quantiques mystérieux, défis techniques, et applications pratiques, nous allons découvrir comment cette technologie s'apprête à encoder nos données dans une dimension où même les meilleurs cryptographes n’y pourraient rien faire.

Les nouvelles menaces liées à l’intelligence artificielle

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Sommes-nous proches de la singularité technologique ? Peu probable. Même si l’intelligence artificielle a fait un bond ces dernières années (elle est étudiée depuis des dizaines d’années), nous sommes loin d’en perdre le contrôle. Et pourtant, une partie de l’utilisation de l’intelligence artificielle échappe aux analystes. Eh oui ! Comme tout système, elle est utilisée par des acteurs malveillants essayant d’en tirer profit pécuniairement. Cet article met en exergue quelques-unes des applications de l’intelligence artificielle par des acteurs malveillants et décrit succinctement comment parer à leurs attaques.

Migration d’une collection Ansible à l’aide de fqcn_migration

Magazine
Marque
Contenu Premium
Spécialité(s)
Résumé

Distribuer du contenu Ansible réutilisable (rôle, playbooks) par l’intermédiaire d’une collection est devenu le standard dans l’écosystème de l’outil d’automatisation. Pour éviter tout conflit de noms, ces collections sont caractérisées par un nom unique, formé d’une espace de nom, qui peut-être employé par plusieurs collections (tel qu'ansible ou community) et d’un nom plus spécifique à la fonction de la collection en elle-même. Cependant, il arrive parfois qu’il faille migrer une collection d’un espace de noms à un autre, par exemple une collection personnelle ou communautaire qui passe à un espace de noms plus connus ou certifiés. De même, le nom même de la collection peut être amené à changer, si elle dépasse son périmètre d’origine ou que le produit qu’elle concerne est lui-même renommé.

Body