Le changement, c'est maintenant !

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 ;)

Au début des ordinateurs personnels était le ZX81 : 3h de frénétiques frappes sur le clavier pour entrer un programme, qui ne pouvait être sauvegardé. 1 min de compilation. Et là... 2h de rage parce que le programme affiche une erreur incompréhensible digne des meilleurs messages LaTeX.

L'informatique n'a jamais été une discipline facile. Je suis tombé dedans au début des années 80 [2] et continue aujourd'hui à m'amuser dans ce secteur. Et pourtant, les choses ont radicalement changé, et plus encore quand on s'intéresse à la sécurité, domaine protéiforme par excellence. Se lancer aujourd'hui dans ce domaine demande beaucoup d'abnégation et de persévérance, à de nombreux égards.

Depuis quelques années, la sécurité est enseignée en cours, souvent en option de 20h dans diverses formations, écoles d'ingénieurs et facs confondues, ou dans des formations spécialisées. Ceci dit, avant de se lancer en sécurité, de nombreux préalables sont nécessaires, de sujets concrets (architecture des systèmes, des réseaux, noyau, programmation) à la théorie de l'informatique (compilation, algorithmique, complexité). On constate aussi une opposition de style, entre le « tout théorique » et le « tout projet », aucune des 2 approches n'étant évidemment optimale. À la fin, ceux qui s'en sortent le mieux sont ceux qui ont bossé par eux-mêmes, souvent en dehors des sentiers balisés.

Ceci dit, vu les besoins des entreprises et autres entités gouvernementales dans ce secteur, de plus en plus de personnes s'orientent dans cette voie, en y voyant des opportunités de carrière. C'est un domaine où la technique est essentielle, même si certains l'oublient ou croient le contraire. Du coup, les petits jeunes à peine dégrossis se retrouvent encadrés par des managers qui n'ont pas forcément les compétences techniques voulues, et qui pensent plus business qu'efficacité ou progression.

En plus, en face, quand on est un petit jeune, on trouve que les « clients » manquent parfois de maturité (pour être poli). Dans le meilleur des cas, ils ne savent pas ce qu'ils veulent : il est alors possible, voire essentiel, de faire de la pédagogie. Dans le pire, ils savent pertinemment ce qu'ils veulent, c'est-à-dire juste un tampon qui dit que tout va bien.

Ça fait vraiment plaisir de voir des gamins qui bossent comme des fous pour réussir, progresser et innover. La sécurité n'est pas un domaine statique, il faut perpétuellement se remettre en question, il y a tous les écueils évoqués précédemment, et les vieux croûtons avec une vision sécuritaire passéiste.

Cette fougue et cette énergie viennent à propos pour la transformation qui nous attend, car la manière de faire de la sécurité porte aussi un choix de Société. De plus en plus, « on » tente d'imposer une régulation totale, hiérarchique et centralisée à Internet, à l'opposé des idées originelles d'Internet. Pouvoir intercepter des communications autorise-t-il de toutes les intercepter ? Écrire des exploits autorise-t-il de les vendre à n'importe qui ? La sécurité est aussi une affaire d'éthique.

Dans mon précédent édito, je disais que les « jeunes » auraient des challenges à relever, différents de leurs aînés. En voilà un sacré : trouver le bon compromis entre sécurité générale et liberté individuelle. Richard Buckminster Fuller, architecte, designer, inventeur, philosophe et théoricien des systèmes du 20ème siècle, disait : « You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete ». [3]

Les gars, vous avez un nouveau modèle à imaginer, si vous ne voulez pas vous en voir imposer un qui ne vous correspond pas.

Bonnes lecture et initiatives !

Fred Raynal  -  @fredraynal / @MISCRedac

[1] http://www.unixgarden.com/index.php/misc/edito-misc-n71
[2] Étant né la même année que ce numéro... ceci explique cela.
[3] On ne change jamais les choses en s'opposant à la réalité présente. Pour changer quelque chose, il faut construire un nouveau modèle qui rend le modèle actuel obsolète.

Les dénis de service, l'attaque informatique à la portée des caniches

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.

Si l'on remonte un peu l'histoire, les dénis de service, ou plus généralement l’atteinte à la disponibilité des données, sont un des plus anciens problèmes de sécurité informatique. L’attaque par IP Spoofing de Kevin Mitnick en 1994 commençait par un Syn Flooding vers la machine dont il usurpait l’identité. Le « Smurf », attaque par réflexion s’appuyant sur l'envoi de pings sur les adresses broadcast des réseaux, a fait le bonheur de nombreux assaillants à la fin des années 1990.

L’avantage, côté attaquant, est que ce type d’attaque est en général techniquement assez simple à conduire. Le simple rejeu en boucle d’un formulaire web via « ab » (apache benchmark) depuis sa ligne DSL suffit à faire tomber bien des sites. Et comme l’union fait la force, même ceux qui résistent à une attaque individuelle risquent de s’écrouler face à une attaque coordonnée avec LOIC. Le code ayant été porté en JavaScript, il est même possible d’utiliser un smartphone pour participer à l’effort collectif.

Pour une poignée d’euros et quelques minutes passées sur Google, vous pouvez également commander un DDoS vers une cible de votre choix. Les marchands offrent même souvent les cinq premières minutes pour prouver leur force de frappe, et ainsi montrer que vous ne dépensez pas vos 3,50 € pour rien. De quoi rendre abordable un DDoS pour des collégiens voulant rendre leur relevé de notes en ligne inaccessible le jour de la négociation de leur cadeau d’anniversaire.

Pour le responsable sécurité, le déni de service a tout de l’épée de Damoclès. Justifier l’investissement dans une infrastructure de protection contre les dénis de service, qu’elle soit interne ou dans le cloud, quand votre société n’a jamais été victime d’une telle attaque et qu’elle ne le sera peut être jamais risque d’être assez complexe. Si vous avez la chance d’être certifié ISO 27001, une petite astuce dans la norme peut vous faire retrouver le sommeil sans dépenser un euro (de toute façon, tout votre budget sécurité est certainement passé dans la certification) : il suffit d’« accepter le risque ». Pratique. Admettons qu’à défaut de vous protéger, cette solution a au moins le bon goût de mettre la direction devant ses responsabilités.

Si l’on aime les montées d’adrénaline, être dérangé en plein milieu de ses vacances sous les tropiques parce que le réseau devient subitement inaccessible, une autre approche est possible. On peut tout simplement considérer que lorsque son réseau se prendra un DDoS dans la face, il sera toujours temps, à l’arrache, de souscrire à un abonnement chez un CDN en priant pour que l’attaquant mette à jour son cache DNS et déporte son attaque vers leurs gros tuyaux. Mais comme vous allez le découvrir dans ce dossier, ce n’est malheureusement pas si simple. Les attaquants ne sont pas tous aussi naïfs et la famille des dénis de service est bien plus polymorphe que ne le laissent supposer les médias, fussent-ils spécialisés.

Et vous aurez beau mettre en place des infrastructures de protection ou souscrire à des offres en mode SaaS, si votre applicatif est développé n’importe comment et passe son temps à faire des requêtes monstrueuses sur des données non indexées, un simple clic en boucle sur l’icône « reload » d’un navigateur suffira à le mettre à genoux.

Bref, les DDoS ne sont décidément pas qu’une affaire de gros tuyaux.

Excellente lecture, merci à mes relecteurs, contributeurs et tous les auteurs ayant participé au dossier !

Cedric Foll / @follc

Au sommaire de ce numéro :

Pentest Corner

p. 04  Pentest en environnement SAP

Forensic Corner

p. 10  Volatilisons Linux : partie 1

Malware Corner

p. 16  Tour d'horizon du malware bancaire Hesperbot

Dossier - Les dénis de service, l’attaque informatique à la portée des caniches

p. 22  Préambule
p. 23  Les Dénis de Service
p. 30  Les mécanismes d'amplification
p. 36  Comment se protéger des DDoS
p. 45  WebBotNets

Application

p. 54  Protections de couche 2 contre les attaques visant les réseaux IPv6

Système

p. 63  TLS, état des lieux côté serveur

Réseau

p. 70  Stratégies de protection contre les dénis de service
p. 74  La détection d'intrusion : une approche globale