voodoo a écrit 15 commentaires

J'aimerais bien aussi savoir quelles sont ces "conneries/inexactitues" ... C'est un peu nul de critiquer ce genre d'initiative sans aucun argument ni exemple.

Je ne dis pas ça parce que je n'aime pas le C. Je programme presque exclusivement en C++, mais c'est justement cette expérience-là qui me fait dire : aucun programme écrit en C n'est robuste ou sécurisé. Il y a trop de failles intrinsèques au langage lui-même.

Et pourtant y a des logiciels en C qui ne sont pas codé avec les pieds qui on tres peu de faille : par exemple http://vsftpd.beasts.org/

A cela on ajoute qmail, lighttpd, dovecot ... Et des applis qui n'ont pas le droit a l'erreur (validees par Astree http://www.astree.ens.fr/ par exemple!!)

mouahaha la NSA les grands méchants qui surveillent tout et mettent des backdoors dans tous les softs !

Ce qui me fait rire dans ce genre de propos c'est pourquoi la NSA mettrait un backdoor/vulnérabilité dans un code qu'elle maintient elle-même (donc si à la suite d'un audit quelque chose de suspect est détecté tout retombe sur elle) alors qu'elle peut très bien avoir des agents infiltrés comme dev dans des projets libres et en mettre partout (kernels, implémentations d'algos de chiffrement, ...) ? Pourquoi mettre en danger son propre pays (pourquoi personne n'auditerait ce code ?) en laissant des faiblesses volontaires (à moins qu'un certificat ou une clé ne soit caché dans le code aussi ;p) ?

Brad Spengler (dev de grsecurity) a déjà trouvé des vulnérabilités dans systrace, lids et execshield, pourquoi n'en trouverait-il pas dans SELinux s'il y en a ?

Je prend ton message comme ironique, mais le pire c'est que des gens y croient vraiment ...

question : tu fais confiance aux routeurs de ton FAI ? :)

On a pas du lire les mêmes docs. Il me semble que microsoft a découvert un exploit 0day sur la faille JView profile dans l'un des sites.

D'autre part les black hat ne lourdent pas des exploits de qualité bêtement sur des sites web. En général ils les vendent ou les utilisent quand c'est utile (encore que des boites rachètent des 0days pour des spyware ...).

Ce projet à le même intérêt que des honeynets mais côté client, donc entre autres trouver des méthodes d'exploitation de v ulnérabilités, de nouvelles vulns, etc ... Après comme pour les honeynets faut voir les ip sources utilisées par les machines (si ce sont des plages appartenant à microsoft ou des filiales c'est pas trop dur à reconnaître :p).

ps : on utilise pas une vulnérabilité, on l'exploite ;)

Je cautionne ta démarche ;) que je partage (avec des plus mais j'imagine que tu n'as pas cité tout ce que tu fais). Pour ce qui est du php(comme tu parlais de cacti) il y a hardened-php qui est intérressant et bien sûr dès que tu fais du web modsecurity.

Dans la mesure du possible il est également utile de recompiler les applications sensibles avec les options -fstack-protector de gcc (patché ssp).

Et puis la base c'est aussi une politique de mots de passe correcte avec des protections contre le brute-force.

Patché ne veut pas dire que toutes les fonctionnalités sont activées au boot (sinon pour les RBAC grsecurity tu t'en rendrais compte avec une policy par défaut ;) ). Idem pour PaX à moins que l'équipe mandriva n'ait bien marqué tous les binaires .

Je suis d'accord qu'en dehors des besoins de très forte charge on peut utiliser du libre et je l'encourage.

Jette un coup d'oeil à cette présentation : http://www.grsecurity.net/PaX-presentation.ppt(...)

Et puis au code aussi ;).

Il y a une différence entre ce qui est annoncé et ce qui est réellement implémenté. paxtest est un outil sympa pour voir rapidement qu'elles sont les protections implémenté (dans ces types de technos i.e. pax/W^X/execShield), il a été porté sur openbsd. Pour la compilation avec l'option ssp tu la retrouves aussi chez gentoo-hardened par exemple.

Quelles sont les implémentations de rbac sous openbsd (j'avoue ne pas avoir touché un openbsd depuis un moment) ?

http://www.grsecurity.net/PaX-presentation.ppt(...)

D'autant plus que dans le libre ce sont souvent des équipes d'audit des distributions ou les dev des softs eux-mêmes qui trouvent des vulns (contrairement aux gros constructeurs comme microsoft et oracle où ce sont des chercheurs externes qui trouvent les vulns). Ca met en avant le modèle qualité du libre et l'importance de la sécurité aux yeux des dévelopeurs et des mainteneurs.

C'est essentiel d'avoir une bonne chaîne qualité et de devancer les audits des "méchants" car failles non publiée ne veut pas dire faille inexistante.

Ok, merci pour ta réponse, c'est toujours interressant d'avoir des retours d'expérience.

Pour les réponses ARP je vais vérifier, ça me semble inutile (limite idiot) de répondre sur toutes les interfaces (je vais chercher des discussions dans le ml kernel, mais si tu as déjà des références sous la main je suis preneur).

J'ai tout à fait conscience qu'un linux sait traiter un trafic important et que la limite avant d'être soft se produit souvent côté hard. Il existe beaucoup de preuves concrètes avec l'utilisation de plate-forme linux chez des gros opérateurs ou bien dans des appliances. Je citerais l'exemple d'Arkoon (http://open-source.arkoon.net)(...) côté firewall. Par contre pour ce qui est des routeurs c'est plus rare (il y a souvent une raison juridique à cela je pense, c'est à dire une grosse sur qui tapper en cas de problème et puis le discours marketing aussi).

Disons qu'il faut un couple hard/os qui offre les performances requises et la c'est beaucoup plus dur avec un noyau linux vanilla. Pour le routage et la commutation je pense que des processeurs spécifiques sont utiles (contrairement aux firewall ou ca reste quand même très marketing/hype). Donc dans ce cas il faut du hard et du dev dédié (ça n'empêche pas de le faire en libre mais c'est plus fastidieux que du générique).

Ce qui me fait plaisir avec les travaux sur l'exploitation de vulns dans IOS c'est qu'on sort du modèle appliance == secure, car un des arguments contre l'utilisation d'os libre pour des routeurs ou des firewall est d'avoir une plate-forme difficile à compromettre.

Pour l'audit des sources d'IOS, j'émets davantage de réserve (vu que j'ai lu un démenti d'un membre d'ISS). Par contre, Michael Lynn avait l'air tenu par un NDA entre ISS et Cisco.

Aujoud'hui Lynn s'est vu interdir de reparler et retrailler sur l'exploitation d'IOS.

Pour bien suivre cette affaire :
http://blogs.washingtonpost.com/securityfix/(...)

Pour Quagga je suis d'accord avec toi et suis un des premiers à recommander du libre quand il est utilisable et efficace. Mais lorsque tu prends du Cisco c'est en général que tu dois pouvoir tenir une charge importante (donc tu ne te limites pas aux besoins fonctionnels). La partie hardware est essentielle dans ce type d'équipement pour avoir le traitement le plus rapide possible et répondre aux besoins de performances.

Peux-tu détailler (liens, références, ...) "Linux ayant tendance à causer l'arp de manière exotique" et "la table de routage que le noyau plombe régulièrement", ça m'interresse.

grsecurity/PaX n'existe pas sous *BSD :p

Comment as-tu évalué leur niveau de sécurité ?
Depuis quand le nombre de failles reportées est-il représensatif du niveau de sécurité d'un équipement ?

ya What The Hack et la conf XFocus. Mais Las Vegas est devenu une institution avec le Black Hat et le Defcon. Et puis ya plein d'autres confs sécurité aux US.

Michael Lynn n'est pas un expert indépendant, mais un ex-chercheur en sécurité chez ISS (il a démissionné suite/pendant cette affaire blackhat).

La présentation parlait essentiellement de heap corruption et de comment manipuler et exploiter le heap. Il semblerait qu'il ait étudié l'implémentation d'IOS lors d'un audit de code source demandé par Cisco à ISS (ce qui implique un NDA).

Il est important de noter que Michael Lynn n'a pas fourni de 0day, d'exploit ou même de shellcode (d'après des gens ayant assisté à la conférence, je n'y étais pas personnellement présent). Les fruits de recherches sur l'exploitation de vuln IOS étaient déjà dispo.

Les DoS IOS publiées cette année seraient potentiellement exploitables en utilisant les techniques présentées par Lynn.

Un admin réseau doit toujours garder un oeil attentif sur ses routeurs (c'est quand même le point d'entrée souvent ou bien un point important d'interconnexion).

Il y a des alternatives à Cisco comme Juniper qui marchent très bien (faut arrêter de s'obséder avec Cisco).