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

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.