ecrire un exploit qui stocke son code dans la pile ou ailleur ne change rien a la difficulté. Les systèmes qui ont déjà une pile non-executable sont aussi sujet aux buffer-overflow exploitables.
a la limite, si toi dans ton coin tu rend la pile linux non executable, tu te protegera des exploits qui stockent leur code en pile, et pas des autres.
si tout le noyau linux a une pile non-executable, tous les exploits seront codés en consequence. et de nouveau tout le monde sera succeptible d'etre infecté par les script-kiddie. Ce probleme de pile-non executable ne protege que des script-kiddies, les autres (ceux qui codent) adapteront l'exploit a ta nouvelle pile de toutes facons.
bref j'ai pas dit que c'etait mal, j'ai juste dit que ca ne change pas vraiment le probleme.
utilisons une comparaison puisque tu as l'air d'apprecier.
la porte de ta maison a un gros trou (buffer overflow), alors tu piege l'allée centrale qui y mène (pile), en esperant que personne ne passera par la pelouse ....
Quels programmes utilisent la possibilite d'executer des instructions en pile ??
Certainement pas les logiciels opensource qui sont compilables a merci sur plein de plateformes ...
Honnetement, je ne voit pas trop ce que cela peut apporter a un programme, ni d'ailleur du point de vue sécurité. C'est d'ailleur pour cela que Linus avait refusé de rendre la pile non-executable par defaut dans Linux.
Rappel:
La plupart des exploit "debordement de buffer" pour x86 utilisent la pile pour stocker le code a executer (lancer un shell root par exemple). C'est pourquoi certains veulent rendre la pile non-executable. Mais rendre la pile non-executable ne change rien au probleme (debordement de buffer) et plusieurs exploits utilisant d'autres endroits que la pile pour stocker leur code ont déjà été diffusés.
Si la pile de linux est non executable, tous les exploits seront fait avec d'autres techniques mais ils existeront toujours.
Cela n'apporte RIEN (ou si peu) puisque cela ne complique meme pas vraiment l'ecriture de nouveaux exploits.
ftp http et https sont effectivement les protocoles qu'il faut laisser passer pour surfer sur le web.
Après il y a le filtrage des sites "interdits" a mettre en place si la direction de la boite veut eviter les heures sur "le loft" ou les sites de cul (mais ca s'ecarte du probleme de sécurité).
filtrer tout et parler ensuitre demande beaucoup plus de boulot que de tout laisser passer dès le depart -- un peu contradictoire avec ton accusation de "paresse".
quand au ssh, honnetement PERSONNE en dehors de l'équipe réseau n'en a jamais fait la demande.
SSH est un protocole embetant a filtrer car il permet de faire des tunnels cryptés donc sans trop laisser aux admins la possibilité de juger du danger que représente ce tunnel. Accepter du ssh sortant c'est aussi accepter les yeux fermer du n'importe-quoi entrant (au gré d'un user lambda donc ni vu ni connu de l'équipe de sécurité).
--alors oui, je suis incompétant a tes yeux et je le revendique --
Pour remédier a ces problèmes liés a SSH, on utilise un "proxy-ssh" spécialement mis en place par moi-meme (deja causé sur linux-fr), qui permet de supprimer toutes les possibilitées de tunnel automatique de ssh (mais les users malins peuvent encore jouer evidement), et d'enregistrer ce qui est fait a travers la connection si besoin (connections ssh entrantes pour maintenance des machines). C'est un peu lourd j'en convient, mais c'est la seule condition qui a été acceptée par la direction. en plus le proxy-ssh oblige les gens a utiliser des clefs (pas de mot de passe) et ces clefs sont filtrés sur des critères que l'on a ajouté comme "date debut de validite" et "date fin de validite", comme ca pas besoin de se souvenir de revoquer la clef.
pour revenir a tes accusations, je passe sur incompétant, je suis mal placé pour juger, quand a FAINEANT, je le revendique haut et fort. Un bon informaticien se doit d'etre faineant, cela le pousse a toujours plus automatiser, scripter, ... au lieu de tout faire a la main. Le fainéant que je décrit aime bien aller au boulot mais pas faire 2 fois la meme chose, il s'arrange donc pour que la 2ieme fois le traitement soit automatique.
les techniques de spoofing peuvent permettre de se connecter a ton intranet si le firewall n'est pas bien configuré (le NAT seul ne suffit pas). Sur internet c'est pas toujours facile a utiliser comme attaque -- en théorie c'est possible (en pratique demande a mitnick, c'est ce qu'il avait utilisé pour se rendre en taule).
un utilisateur peut tres bien creer un tunnel depuis son adresse NATée vers une machine externe et router tout le traffic qu'il veut dedans. Si un des utilisateurs fait cela ton réseau entier est exposé.
De toutes facons la sécurité doit etre en relation avec ce que tu protege.
A la maison un firewall qui fait principalement du NAT et qui est bien parametré suffit largement (confiance maxi dans les utilisateurs).
Au boulot cela depend de la taille de la boite, des données a protéger, du niveau des utilisateurs ...
A mon avis tu n'as pas tord. Mais tu n'es pas assez parano pour opérer dans un milieu hostile/à risque.
Tu as raison mais je prefere aussi tout couper d'abord et parler ensuite :-))
A mon avis, gerer la securite sans savoir quels sont les protocoles utilisés, par qui et pour quoi, c'est impossible. Donc je coupe tout et tout le monde sait a qui s'adresser pour les besoins spécifiques. Sur les 3000 personnes de la boite, il y en a disons une 20aine qui a besoin de ssh/ftp/irc ? et les autres se satisfont des solutions prédéfinies: proxy http/https uniquement.
Du coup les besoins spécifiques sont remontés vers moi pour étudier une méthode sécurisée d'accès, pour documenter le biniou et surtout savoir le surveiller. Quand il y a un besoin spécifique urgent je sais le traiter aussi au coup par coup.
Tu as donc raison: l'admin, est d'abord la pour les utilisateurs. Mais cela ne veut pas dire tout laisser faire. Ca veut dire tout fermer ET SE RENDRE DISPONIBLE immediatement pour tout probleme. C'est le cas ou je bosse en tant qu'architecte, avec l'admin (meme bureau), on est a l'ecoute permanente pour trouver des solutions et améliorer l'architecture, modifier/ajouter des proxy, affiner des regles, ajouter des VPN, mettre au point/adapter le monitoring ...
Et on se rend compte que les besoins spécifiques c'est nous qui les avons (équipe reseau et équipe sécurité). Les developpeurs et l'équipe système en moindre mesure, les autres quasiement pas du tout.
(sauf pour napster mais etre a l'ecoute ne veut pas dire qu'on accepte tout non plus :-)
mais l'admin réseau est, pour être poli, un peu à la masse...
le probleme de l'autonegociation c'est que la plupart des machines ne negocient pas correctement.
je ne sais pas si la norme est "trouée" (si elle permet des interpretations differentes ...), mais le resultat c'est que sur les switch il vaut mieux forcer les parametres par defaut et modifier si besoin apres. comme ca dans la plupart des cas ca marche completement ou pas du tout.
linux est une exception, c'est le systeme avec lequel l'autonegociation marche nickel et quand les ports sont forcés sur le switch linux s'embrouille .... ARG !!
(avec AIX, solaris, windows, les autres switchs, les routeurs, ... il vaut mieux forcer la vitesse des 2 cotes, l'autonegociation merde une fois sur 2).
bref ton admin reseau n'est pas si "a la masse" que cela.
Ton post soulève des problèmes interessants (liberté), mais je te trouve un peu expeditif.
D'abord le post précédent n'est pas "inexact" du tout, vous n'avez simplement pas abordé le probleme de la meme façon.
Dans le blacklistage de wanadoo, interviennent:
-le profiteur du serveur smtp open relai
-"l'administrateur" du serveur smtp open relai
-le serveur smtp de wanadoo
-les gens qui blacklistent un peu trop facilement.
Le coupable dans la "gene" est a mon avis autant le profiteur que ceux qui gèrent les blacklistes.
J'explique: si tu monte un serveur smtp bidon sur une adresse ip dynamique, tu peux envoyer autant de mails que tu veux et changer d'ip dès que tu es blacklisté.
résultat: toutes les ip du FAI finissent par etre blacklistées ...
Donc ceux qui sont embetés sont les clients du FAI et le FAI lui meme.
Le client est par définition pas capable de faire grand chose, alors comment doit réagir le FAI ?
proteger ses propres serveurs smtp:
L'année dernière, wanadoo voulait mettre en oeuvre un filtre sur ses serveurs de mail qui n'auraient plus accepté de relayer le mail seulement si il venait d'un client mail (ils auraient refusé tout mail venant d'un serveur smtp). Je trouvais cela domage (je leur ai dit d'ailleur). Finalement ils auraient peut-etre du le faire.
J'avais pensé aussi que wanadoo pouvait detecter si le serveur smtp qui leur cause est open-relai et refuser de relayer le mail dans cette condition.
proteger sa plage d'adresses IP:
pas d'autres solutions 100% efficace que de filtrer tcp/25.
sinon, des scans réguliers pour detecter les serveurs open-relai et les contacter ...
hehe, j'ai déjà utilisé ce genre de truc pour des connections ssh entrantes:
1/ ne laisse entrer que des clefs dont la partie publique m'a ete envoye par mail (pas de connexion par mot de passe).
2/ dans le command="...", je lance un script qui vérifie la validité de la clef (d'après la date par exemple).
comme ca le type de la maintenance qui doit se connecter le 1 avril, il me donne sa clef publique et avec elle il arrive (par rebond) directement sur le système à maintenir sans connaitre le mot de passe (pas changé assez souvent et plus facile à refiler à un pote), et seulement le jour prévu. la veille ca marche pas, le lendemain ca ne marche plus...
reste a logguer tout ce qu'il fait dans cette connection pour vérifier qu'il se limite a la maintenance prévue.
tu veux une piste ?
essaye 443 (https), tu essaie d'abord avec ton navigateur sur un site de banque, c'est plus discret que nmap :-)).
la plupart des proxy web sont obligé de laisser passer ces requetes, et qui plus est établissent une connexion directe puisque le contenu est de toutes facons chiffré.
chez toi, a grand coup de iptables, tu redirige le port tcp/443 vers tcp/22 (comme ca ton daemon ssh tourne aussi sur le port traditionnel 22), et tu passe a travers le proxy web avec un script perl tout bete (je n'ai pas encore lu l'article j'y vais de suite pour voir ce qu'ils font).
Certes il ne faut pas minimiser l'impact de cette faille ... mais:
elle depend d'un débordement de buffer sur les noms de chemin. Pour l'activer, il faut quand meme créer en local (peut etre sur un drive reseau aussi) une arborescence de fou.
la faille c'est que le noyau, au lieu de renvoyer une erreur, renvoie la taille de son buffer (trop petit) et donc renvoie un chemin tronqué.
A priori ce sera difficile a exploiter a distance, puisqu'il faut avoir le droit de creer des repertoires imbriqués sur la machine.
Cela ne signifie pas que c'est impossible si vous hebergez un serveur FTP avec droit en écriture par exemple.(encore que la création de repertoires imbriqués n'est pas conseillée sur les serveurs FTP).
Il etait une fois un berger et ses moutons au bord de la route.
Tout d'un coup, surgit une Jeep Cherokee flambant neuve, conduite par un jeune homme en chemise Hugo Boss, pantalon YSL, baskets Nike, etc.
La voiture s'arrete et le jeune homme s'adresse au berger :
- Si je devine combien de moutons vous avez, vous m'en donnez un ?
Le berger regarde le jeune homme, regarde les moutons qui broutent et accepte.
Le jeune homme gare la voiture, branche le notebook et le GSM, entre dans un site de la NASA, scrute le terrain a l'aide du GPS, etabli une base de donnees, 60 tableaux Excel pleins d'algorithmes et d'exponentielles, plus un rapport de 150 pages imprime sur sa mini imprimante HIGH-TECH.
Il se tourne vers le berger et dit :
- Vous avez ici 1586 moutons.
- C'est tout a fait correct, vous pouvez avoir votre mouton.
Le jeune homme prend le mouton et le met dans le coffre de la jeep.
A ce moment la, le berger lui demande :
- Si je devine votre profession, vous me rendez mon mouton ?
- Oui.
Le berger dit tout de suite :
- Vous etes consultant
- Comment vous avez devine ?
- Tres facile, repond le berger :
1) Vous etes venu ici sans qu'on vous appelle.
2) Vous me taxez un mouton pour me dire ce que je savais deja..
3) Et vous ne comprenez rien a ce que je fais, parce que vous avez pris mon chien !
Parce que tu crois que les entreprises change leurs equipements informatique tous les 3 ans depuis que l'amortissement se fait sur 3 ans ????
laisse moi rigoler. Je vois des pentium 166 de partout dans les grosse boites. Les postes clients sont changés "relativement" souvent (mais pas tous les 3 ans), et ils deviennent plus rapides que les serveurs. Les equipements reseaux ne sont changés que lorsqu'ils cassent ... quand au cablage c'est encore pire.
alors poser de la fibre aujourd'hui c'est forcement un "surequipement" si on a besoin de 10Mbits, mais c'est fait pour durer.
Bref amortir sur 3 ans c'est un probleme de compta, pas de gestion de parc.
Honnetement, puisqu'on en reparle, il n'est pas le seul a se poser des questions sur le logo.
Ce logo est amusant. le rapport avec les LL est vraiment ... difficile a voir. On reconnait a peine Tux avec son masque, et le plus gros de l'image c'est quand meme une femme qui prends un bain. rapport avec linux, les LL ???
En entreprise, quand le big boss passe dans le bureau, je prefererai un logo plus "hacker" ou "geek" que celui la.
Ce logo ne fait pas site oueb tres serieux. Quand le chef passe, de faire croire que ca a un rapport avec le taf !!
Je comprends que dans certaines boites ou a l'ecole ce ne soit pas un probleme... mais il faut penser a tous, donc peut etre prevoir dans les themes le choix d'un logo plus ... neutre !
je serais très heureux de pouvoir récupérer un DIVX des autres reportages.
Moi aussi !!
J'ai pu telecharger les DivX du reportage sur linux... mais il manque les autres reportages de la soirée "rebelles du net".
De plus je trouve la grille de programme Arte sur le net tres mal faite sur un point: quand on clique sur la fiche d'un reportage, on ne trouve que la date de la premiere diffusion, pas de reference aux eventuelles autres programmations ...il faut donc lire le programme toutes les semaines pour voir si ca repasse !!
ARTE si vous lisez liuxfr, reprogrammez les reportages "rebelles du net" svp, meme a une heure pas possible (4h du mat ?)
Ou alors si quelqu'un a enregistre ca en VHS ou DV, je veux bien produire un divX du bidule si il me prete sa k7.
Moi je rouspete souvent apres RedHat (mais les autres c'est pareil) qui mettent des dependance telles que tu ne peux pas installer un client X sans avoir le serveur.
par exemple je veux mettre fwbuilder, ou meme juste un xload sur un serveur qui ne possede pas de serveur X11. C'est tres utile, il suffit de se logguer en ssh dessus, ssh exporte le display automatiquement et je peux faire tourner le client X11 et afficher sur le serveur X de mon portable.
la seule méthode "propre" que j'ai trouvé c'est de piquer les libs X11 et le binaire sur une autre machine et de la copier sur le serveur.
Sous redhat (mais les autres c'est pareil), pour installer les libs X11 il faut installer le serveur. Pour installer un client (xclock par exemple), il faut avoir les libs ET le serveur. Enfin pour l'export display il faut xauth (un client X11) qui ne s'installe pas sans serveur ...
Bref ces dependances c'est un vrai plat de nouilles. Sans parler des packages utilent pour Gnome (SDL par exemple) qui dependent aussi de truc KDE. soit c'est --nodeps, soit il faut tout installer.
Donc je résume: vous n'utilisez jamais --nodeps. Tant mieux pour vous, mais je présume que c'est parceque vous ne regardez pas trop ce qui est installé sur votre machine. faites un "rpm -qa" et posez vous la question pour chaque package: "a quoi ca sert, en ai-je besoin". Je fait cela systematiquement sur mes machines DE PROD, et ca fout la trouille.
il y a trop de distrib differentes qui utilisent le systeme RPM ?
ou alors les utilisateurs sont trop con pour n'installer que des RPM destinés a leur distrib ??
[si pas dispo, telecharger le rpm source et faire un rpm -ba package n'est pas difficile quand meme !!]
<Humour>
Ah, si seulement RedHat avait release RPM en closed source, les autres distrib ne s'en seraient pas servies et tout le monde serait heureux car en telechargeant un RPM on serait sur qu'il a été fait pour RedHat.
</Humour>
tu recupere la liste des users avec le login graphique.
rien ne t'empeche d'utiliser pop/imap/telnet/ssh/rsh/rlogin/...
pour faire ton attaque brute-force et valider les mots de passe.
voir de profiter d'un cgi a la con ou d'un mot de passe dans squid, .. bref ca laisse des possibilitées.
(meme si je trouve l'annonce un peu dramatisante, ce probleme en lui seul n'en est pas vraiment un).
Rappelons aussi que beaucoup d'"admin" Unix installent X11 sur toutes les machines pour mouvoir lancer linuxconf/smit/... en mode graphique.
Ils n'ont pas encore capté que
1/ c'est dangereux
2/ c'est inutile (on peut installer un client smit graphique et exporter le DISPLAY sans avoir le serveur X sur le serveur !!)
donc X11 lourd, gourmand, inutile et buggé jusqu'a etre dangereux tourne sur beaucoup de serveurs en DMZ ... ARG!!
Humm, désolé mais apparemment tu ne sais pas lire.
je quote la meme phrase que toi: "On many systems, freeing the same memory twice will crash the application"
il y est expliqué les différentes implémentations de malloc/free et quels systèmes les utilises.
il y est aussi expliqué comment en profiter pour lancer un shell sous linux et hurd.
Je cite quelques extraits de l'article (long et tres technique, pas la peine de poster ici):
There are only a few common malloc implementations. The most common ones
are the System V one, implemented by AT&T, the GNU C Library implementation
and the malloc-similar interface of the Microsoft operating systems
(RtlHeap*).
Here is a table of algorithms and which operating systems use them:
Algorithm | Operating System
------------------------+--------------------------------------------------
BSD kingsley | 4.4BSD, AIX (compatibility), Ultrix
BSD phk | BSDI, FreeBSD, OpenBSD
GNU Lib C (Doug Lea) | Hurd, Linux
System V AT&T | Solaris, IRIX
Yorktown | AIX (default)
RtlHeap* | Microsoft Windows *
------------------------+--------------------------------------------------
<snip>
ell, however, exploitation is pretty straight forward now:
si la faille n'est pas exploitable, ce n'est plus un probleme de sécurité mais simplement un BUG.
Chez microsoft, on ne corrige pas les bugs a la volée cela n'est plus a démontrer.
Vu l'ampleur du probleme (zlib est utilisée de partout), il y a des TONNES de logiciels a corriger. Je trouve donc OPTIMAL de vérifier d'abord a quoi cela expose les clients avant de faire des release de patchs a gogo.
Si l'implementation de free() sur windows ne fait rien quand on l'appelle une seconde fois pour le meme segment de mémoire, il y a un bug dans l'algo de zlib qui n'est pas une faille, ni un probleme pour l'utilisateur (puisque ne crash pas le logiciel non plus). Si c'est le cas, je ne comprendrais pas que tout le monde fasse des release de patch pour un bug qui est pour le moins 'virtuel'.
Par contre il est vrai qu'un peu plus de certitude sur le diagnostique du cote windows ne ferai pas de mal.
[^] # Re: Quels sont les défauts ?
Posté par PLuG . En réponse à la dépêche Le patch OpenWall. Évalué à 6.
a la limite, si toi dans ton coin tu rend la pile linux non executable, tu te protegera des exploits qui stockent leur code en pile, et pas des autres.
si tout le noyau linux a une pile non-executable, tous les exploits seront codés en consequence. et de nouveau tout le monde sera succeptible d'etre infecté par les script-kiddie. Ce probleme de pile-non executable ne protege que des script-kiddies, les autres (ceux qui codent) adapteront l'exploit a ta nouvelle pile de toutes facons.
bref j'ai pas dit que c'etait mal, j'ai juste dit que ca ne change pas vraiment le probleme.
utilisons une comparaison puisque tu as l'air d'apprecier.
la porte de ta maison a un gros trou (buffer overflow), alors tu piege l'allée centrale qui y mène (pile), en esperant que personne ne passera par la pelouse ....
[^] # Re: Quels sont les défauts ?
Posté par PLuG . En réponse à la dépêche Le patch OpenWall. Évalué à 9.
Certainement pas les logiciels opensource qui sont compilables a merci sur plein de plateformes ...
Honnetement, je ne voit pas trop ce que cela peut apporter a un programme, ni d'ailleur du point de vue sécurité. C'est d'ailleur pour cela que Linus avait refusé de rendre la pile non-executable par defaut dans Linux.
Rappel:
La plupart des exploit "debordement de buffer" pour x86 utilisent la pile pour stocker le code a executer (lancer un shell root par exemple). C'est pourquoi certains veulent rendre la pile non-executable. Mais rendre la pile non-executable ne change rien au probleme (debordement de buffer) et plusieurs exploits utilisant d'autres endroits que la pile pour stocker leur code ont déjà été diffusés.
Si la pile de linux est non executable, tous les exploits seront fait avec d'autres techniques mais ils existeront toujours.
Cela n'apporte RIEN (ou si peu) puisque cela ne complique meme pas vraiment l'ecriture de nouveaux exploits.
[^] # Re: Les admins chiants ;))
Posté par PLuG . En réponse à la dépêche Mise en place d'un firewall « fort ». Évalué à 10.
Après il y a le filtrage des sites "interdits" a mettre en place si la direction de la boite veut eviter les heures sur "le loft" ou les sites de cul (mais ca s'ecarte du probleme de sécurité).
filtrer tout et parler ensuitre demande beaucoup plus de boulot que de tout laisser passer dès le depart -- un peu contradictoire avec ton accusation de "paresse".
quand au ssh, honnetement PERSONNE en dehors de l'équipe réseau n'en a jamais fait la demande.
SSH est un protocole embetant a filtrer car il permet de faire des tunnels cryptés donc sans trop laisser aux admins la possibilité de juger du danger que représente ce tunnel. Accepter du ssh sortant c'est aussi accepter les yeux fermer du n'importe-quoi entrant (au gré d'un user lambda donc ni vu ni connu de l'équipe de sécurité).
--alors oui, je suis incompétant a tes yeux et je le revendique --
Pour remédier a ces problèmes liés a SSH, on utilise un "proxy-ssh" spécialement mis en place par moi-meme (deja causé sur linux-fr), qui permet de supprimer toutes les possibilitées de tunnel automatique de ssh (mais les users malins peuvent encore jouer evidement), et d'enregistrer ce qui est fait a travers la connection si besoin (connections ssh entrantes pour maintenance des machines). C'est un peu lourd j'en convient, mais c'est la seule condition qui a été acceptée par la direction. en plus le proxy-ssh oblige les gens a utiliser des clefs (pas de mot de passe) et ces clefs sont filtrés sur des critères que l'on a ajouté comme "date debut de validite" et "date fin de validite", comme ca pas besoin de se souvenir de revoquer la clef.
pour revenir a tes accusations, je passe sur incompétant, je suis mal placé pour juger, quand a FAINEANT, je le revendique haut et fort. Un bon informaticien se doit d'etre faineant, cela le pousse a toujours plus automatiser, scripter, ... au lieu de tout faire a la main. Le fainéant que je décrit aime bien aller au boulot mais pas faire 2 fois la meme chose, il s'arrange donc pour que la 2ieme fois le traitement soit automatique.
[^] # Re: Le NAT rien de plus efficace
Posté par PLuG . En réponse à la dépêche Mise en place d'un firewall « fort ». Évalué à 10.
les techniques de spoofing peuvent permettre de se connecter a ton intranet si le firewall n'est pas bien configuré (le NAT seul ne suffit pas). Sur internet c'est pas toujours facile a utiliser comme attaque -- en théorie c'est possible (en pratique demande a mitnick, c'est ce qu'il avait utilisé pour se rendre en taule).
un utilisateur peut tres bien creer un tunnel depuis son adresse NATée vers une machine externe et router tout le traffic qu'il veut dedans. Si un des utilisateurs fait cela ton réseau entier est exposé.
De toutes facons la sécurité doit etre en relation avec ce que tu protege.
A la maison un firewall qui fait principalement du NAT et qui est bien parametré suffit largement (confiance maxi dans les utilisateurs).
Au boulot cela depend de la taille de la boite, des données a protéger, du niveau des utilisateurs ...
A mon avis tu n'as pas tord. Mais tu n'es pas assez parano pour opérer dans un milieu hostile/à risque.
[^] # Re: Et les utilisateurs
Posté par PLuG . En réponse à la dépêche Mise en place d'un firewall « fort ». Évalué à 10.
A mon avis, gerer la securite sans savoir quels sont les protocoles utilisés, par qui et pour quoi, c'est impossible. Donc je coupe tout et tout le monde sait a qui s'adresser pour les besoins spécifiques. Sur les 3000 personnes de la boite, il y en a disons une 20aine qui a besoin de ssh/ftp/irc ? et les autres se satisfont des solutions prédéfinies: proxy http/https uniquement.
Du coup les besoins spécifiques sont remontés vers moi pour étudier une méthode sécurisée d'accès, pour documenter le biniou et surtout savoir le surveiller. Quand il y a un besoin spécifique urgent je sais le traiter aussi au coup par coup.
Tu as donc raison: l'admin, est d'abord la pour les utilisateurs. Mais cela ne veut pas dire tout laisser faire. Ca veut dire tout fermer ET SE RENDRE DISPONIBLE immediatement pour tout probleme. C'est le cas ou je bosse en tant qu'architecte, avec l'admin (meme bureau), on est a l'ecoute permanente pour trouver des solutions et améliorer l'architecture, modifier/ajouter des proxy, affiner des regles, ajouter des VPN, mettre au point/adapter le monitoring ...
Et on se rend compte que les besoins spécifiques c'est nous qui les avons (équipe reseau et équipe sécurité). Les developpeurs et l'équipe système en moindre mesure, les autres quasiement pas du tout.
(sauf pour napster mais etre a l'ecoute ne veut pas dire qu'on accepte tout non plus :-)
[^] # Re: Une autre utilité
Posté par PLuG . En réponse à la dépêche Diagnostiquer l'état d'une carte réseau. Évalué à 10.
le probleme de l'autonegociation c'est que la plupart des machines ne negocient pas correctement.
je ne sais pas si la norme est "trouée" (si elle permet des interpretations differentes ...), mais le resultat c'est que sur les switch il vaut mieux forcer les parametres par defaut et modifier si besoin apres. comme ca dans la plupart des cas ca marche completement ou pas du tout.
linux est une exception, c'est le systeme avec lequel l'autonegociation marche nickel et quand les ports sont forcés sur le switch linux s'embrouille .... ARG !!
(avec AIX, solaris, windows, les autres switchs, les routeurs, ... il vaut mieux forcer la vitesse des 2 cotes, l'autonegociation merde une fois sur 2).
bref ton admin reseau n'est pas si "a la masse" que cela.
# attention ...
Posté par PLuG . En réponse à la dépêche Diagnostiquer l'état d'une carte réseau. Évalué à 10.
pas besoin de le telecharger ailleur ...
[^] # Re: sysctl
Posté par PLuG . En réponse à la dépêche Bidouiller dans le /proc pour sécuriser son Linux. Évalué à 10.
meme pas, cf la page man de sysctl.
sysctl evite juste de faire "echo 1 > /proc/.."
mais il fait la meme chose avec sa syntaxe a lui.
l'interet c'est /etc/sysctl.conf qui garde la config entre les reboot.
[^] # Re: sysctl
Posté par PLuG . En réponse à la dépêche Bidouiller dans le /proc pour sécuriser son Linux. Évalué à 10.
sysctl n'est autre qu'un interface pour manipuler les parametres de /proc .
[^] # Re: Wanadoo et l'open relay
Posté par PLuG . En réponse à la dépêche Serveurs de courriel de Wanadoo et Oléane sur liste noire. Évalué à 10.
D'abord le post précédent n'est pas "inexact" du tout, vous n'avez simplement pas abordé le probleme de la meme façon.
Dans le blacklistage de wanadoo, interviennent:
-le profiteur du serveur smtp open relai
-"l'administrateur" du serveur smtp open relai
-le serveur smtp de wanadoo
-les gens qui blacklistent un peu trop facilement.
Le coupable dans la "gene" est a mon avis autant le profiteur que ceux qui gèrent les blacklistes.
J'explique: si tu monte un serveur smtp bidon sur une adresse ip dynamique, tu peux envoyer autant de mails que tu veux et changer d'ip dès que tu es blacklisté.
résultat: toutes les ip du FAI finissent par etre blacklistées ...
Donc ceux qui sont embetés sont les clients du FAI et le FAI lui meme.
Le client est par définition pas capable de faire grand chose, alors comment doit réagir le FAI ?
proteger ses propres serveurs smtp:
L'année dernière, wanadoo voulait mettre en oeuvre un filtre sur ses serveurs de mail qui n'auraient plus accepté de relayer le mail seulement si il venait d'un client mail (ils auraient refusé tout mail venant d'un serveur smtp). Je trouvais cela domage (je leur ai dit d'ailleur). Finalement ils auraient peut-etre du le faire.
J'avais pensé aussi que wanadoo pouvait detecter si le serveur smtp qui leur cause est open-relai et refuser de relayer le mail dans cette condition.
proteger sa plage d'adresses IP:
pas d'autres solutions 100% efficace que de filtrer tcp/25.
sinon, des scans réguliers pour detecter les serveurs open-relai et les contacter ...
tu le vois, ce n'est pas simple du tout.
# hehe
Posté par PLuG . En réponse à la dépêche Connexion au travers d'une passerelle. Évalué à 10.
1/ ne laisse entrer que des clefs dont la partie publique m'a ete envoye par mail (pas de connexion par mot de passe).
2/ dans le command="...", je lance un script qui vérifie la validité de la clef (d'après la date par exemple).
comme ca le type de la maintenance qui doit se connecter le 1 avril, il me donne sa clef publique et avec elle il arrive (par rebond) directement sur le système à maintenir sans connaitre le mot de passe (pas changé assez souvent et plus facile à refiler à un pote), et seulement le jour prévu. la veille ca marche pas, le lendemain ca ne marche plus...
reste a logguer tout ce qu'il fait dans cette connection pour vérifier qu'il se limite a la maintenance prévue.
[^] # Re: Il faut un accès sur la gateway !
Posté par PLuG . En réponse à la dépêche Connexion au travers d'une passerelle. Évalué à 10.
http://ssh.inet-one.com/dir.1999-05/msg00011.html(...)
[^] # Re: Il faut un accès sur la gateway !
Posté par PLuG . En réponse à la dépêche Connexion au travers d'une passerelle. Évalué à 10.
essaye 443 (https), tu essaie d'abord avec ton navigateur sur un site de banque, c'est plus discret que nmap :-)).
la plupart des proxy web sont obligé de laisser passer ces requetes, et qui plus est établissent une connexion directe puisque le contenu est de toutes facons chiffré.
chez toi, a grand coup de iptables, tu redirige le port tcp/443 vers tcp/22 (comme ca ton daemon ssh tourne aussi sur le port traditionnel 22), et tu passe a travers le proxy web avec un script perl tout bete (je n'ai pas encore lu l'article j'y vais de suite pour voir ce qu'ils font).
[^] # Re: Mettre à jour...
Posté par PLuG . En réponse à la dépêche Faille de sécurité dans les noyaux Linux. Évalué à 9.
elle depend d'un débordement de buffer sur les noms de chemin. Pour l'activer, il faut quand meme créer en local (peut etre sur un drive reseau aussi) une arborescence de fou.
la faille c'est que le noyau, au lieu de renvoyer une erreur, renvoie la taille de son buffer (trop petit) et donc renvoie un chemin tronqué.
A priori ce sera difficile a exploiter a distance, puisqu'il faut avoir le droit de creer des repertoires imbriqués sur la machine.
Cela ne signifie pas que c'est impossible si vous hebergez un serveur FTP avec droit en écriture par exemple.(encore que la création de repertoires imbriqués n'est pas conseillée sur les serveurs FTP).
[^] # Re: Gartner = troll??
Posté par PLuG . En réponse à la dépêche 20% de dépenses inutiles en infrastructures. Évalué à 10.
Il etait une fois un berger et ses moutons au bord de la route.
Tout d'un coup, surgit une Jeep Cherokee flambant neuve, conduite par un jeune homme en chemise Hugo Boss, pantalon YSL, baskets Nike, etc.
La voiture s'arrete et le jeune homme s'adresse au berger :
- Si je devine combien de moutons vous avez, vous m'en donnez un ?
Le berger regarde le jeune homme, regarde les moutons qui broutent et accepte.
Le jeune homme gare la voiture, branche le notebook et le GSM, entre dans un site de la NASA, scrute le terrain a l'aide du GPS, etabli une base de donnees, 60 tableaux Excel pleins d'algorithmes et d'exponentielles, plus un rapport de 150 pages imprime sur sa mini imprimante HIGH-TECH.
Il se tourne vers le berger et dit :
- Vous avez ici 1586 moutons.
- C'est tout a fait correct, vous pouvez avoir votre mouton.
Le jeune homme prend le mouton et le met dans le coffre de la jeep.
A ce moment la, le berger lui demande :
- Si je devine votre profession, vous me rendez mon mouton ?
- Oui.
Le berger dit tout de suite :
- Vous etes consultant
- Comment vous avez devine ?
- Tres facile, repond le berger :
1) Vous etes venu ici sans qu'on vous appelle.
2) Vous me taxez un mouton pour me dire ce que je savais deja..
3) Et vous ne comprenez rien a ce que je fais, parce que vous avez pris mon chien !
[^] # Re: Un miroir partiel en Belgique
Posté par PLuG . En réponse à la dépêche Rediffusion émission Arte : Nom de code Linux. Évalué à -1.
[^] # Re: oui, mais comment les connaitre avant.
Posté par PLuG . En réponse à la dépêche 20% de dépenses inutiles en infrastructures. Évalué à 10.
laisse moi rigoler. Je vois des pentium 166 de partout dans les grosse boites. Les postes clients sont changés "relativement" souvent (mais pas tous les 3 ans), et ils deviennent plus rapides que les serveurs. Les equipements reseaux ne sont changés que lorsqu'ils cassent ... quand au cablage c'est encore pire.
alors poser de la fibre aujourd'hui c'est forcement un "surequipement" si on a besoin de 10Mbits, mais c'est fait pour durer.
Bref amortir sur 3 ans c'est un probleme de compta, pas de gestion de parc.
[^] # Re: Un nouveau logo ? (Encore lui ?) ;)
Posté par PLuG . En réponse à la dépêche Mise à jour LinuxFr. Évalué à 0.
Ce logo est amusant. le rapport avec les LL est vraiment ... difficile a voir. On reconnait a peine Tux avec son masque, et le plus gros de l'image c'est quand meme une femme qui prends un bain. rapport avec linux, les LL ???
En entreprise, quand le big boss passe dans le bureau, je prefererai un logo plus "hacker" ou "geek" que celui la.
Ce logo ne fait pas site oueb tres serieux. Quand le chef passe, de faire croire que ca a un rapport avec le taf !!
Je comprends que dans certaines boites ou a l'ecole ce ne soit pas un probleme... mais il faut penser a tous, donc peut etre prevoir dans les themes le choix d'un logo plus ... neutre !
[^] # Re: Un miroir partiel en Belgique
Posté par PLuG . En réponse à la dépêche Rediffusion émission Arte : Nom de code Linux. Évalué à -1.
Moi aussi !!
J'ai pu telecharger les DivX du reportage sur linux... mais il manque les autres reportages de la soirée "rebelles du net".
De plus je trouve la grille de programme Arte sur le net tres mal faite sur un point: quand on clique sur la fiche d'un reportage, on ne trouve que la date de la premiere diffusion, pas de reference aux eventuelles autres programmations ...il faut donc lire le programme toutes les semaines pour voir si ca repasse !!
ARTE si vous lisez liuxfr, reprogrammez les reportages "rebelles du net" svp, meme a une heure pas possible (4h du mat ?)
Ou alors si quelqu'un a enregistre ca en VHS ou DV, je veux bien produire un divX du bidule si il me prete sa k7.
P'tet qu'on devrait simplement écrire à ARTE ??
[^] # Re: nécessaire mais pas suffisant
Posté par PLuG . En réponse à la dépêche Introduction à urpmi. Évalué à 10.
Moi je rouspete souvent apres RedHat (mais les autres c'est pareil) qui mettent des dependance telles que tu ne peux pas installer un client X sans avoir le serveur.
par exemple je veux mettre fwbuilder, ou meme juste un xload sur un serveur qui ne possede pas de serveur X11. C'est tres utile, il suffit de se logguer en ssh dessus, ssh exporte le display automatiquement et je peux faire tourner le client X11 et afficher sur le serveur X de mon portable.
la seule méthode "propre" que j'ai trouvé c'est de piquer les libs X11 et le binaire sur une autre machine et de la copier sur le serveur.
Sous redhat (mais les autres c'est pareil), pour installer les libs X11 il faut installer le serveur. Pour installer un client (xclock par exemple), il faut avoir les libs ET le serveur. Enfin pour l'export display il faut xauth (un client X11) qui ne s'installe pas sans serveur ...
Bref ces dependances c'est un vrai plat de nouilles. Sans parler des packages utilent pour Gnome (SDL par exemple) qui dependent aussi de truc KDE. soit c'est --nodeps, soit il faut tout installer.
Donc je résume: vous n'utilisez jamais --nodeps. Tant mieux pour vous, mais je présume que c'est parceque vous ne regardez pas trop ce qui est installé sur votre machine. faites un "rpm -qa" et posez vous la question pour chaque package: "a quoi ca sert, en ai-je besoin". Je fait cela systematiquement sur mes machines DE PROD, et ca fout la trouille.
[^] # Re: nécessaire mais pas suffisant
Posté par PLuG . En réponse à la dépêche Introduction à urpmi. Évalué à 3.
il y a trop de distrib differentes qui utilisent le systeme RPM ?
ou alors les utilisateurs sont trop con pour n'installer que des RPM destinés a leur distrib ??
[si pas dispo, telecharger le rpm source et faire un rpm -ba package n'est pas difficile quand meme !!]
<Humour>
Ah, si seulement RedHat avait release RPM en closed source, les autres distrib ne s'en seraient pas servies et tout le monde serait heureux car en telechargeant un RPM on serait sur qu'il a été fait pour RedHat.
</Humour>
[^] # Re: login screen?
Posté par PLuG . En réponse à la dépêche Faille importante sous UNIX. Évalué à 2.
rien ne t'empeche d'utiliser pop/imap/telnet/ssh/rsh/rlogin/...
pour faire ton attaque brute-force et valider les mots de passe.
voir de profiter d'un cgi a la con ou d'un mot de passe dans squid, .. bref ca laisse des possibilitées.
(meme si je trouve l'annonce un peu dramatisante, ce probleme en lui seul n'en est pas vraiment un).
[^] # Re: faut dire...
Posté par PLuG . En réponse à la dépêche Faille importante sous UNIX. Évalué à 7.
Ils n'ont pas encore capté que
1/ c'est dangereux
2/ c'est inutile (on peut installer un client smit graphique et exporter le DISPLAY sans avoir le serveur X sur le serveur !!)
donc X11 lourd, gourmand, inutile et buggé jusqu'a etre dangereux tourne sur beaucoup de serveurs en DMZ ... ARG!!
(alors de la a laisser XDMCP en plus ...)
[^] # Re: Verifions mieux BIS ;-)
Posté par PLuG . En réponse à la dépêche Le bug de Zlib touche aussi des produits Microsoft. Évalué à 6.
je quote la meme phrase que toi:
"On many systems, freeing the same memory twice will crash the application"
comme vous insistez cette fois je vais argumenter avec une URL sur cet exellent article de phrack:
http://www.phrack.org/phrack/57/p57-0x09(...)
il y est expliqué les différentes implémentations de malloc/free et quels systèmes les utilises.
il y est aussi expliqué comment en profiter pour lancer un shell sous linux et hurd.
Je cite quelques extraits de l'article (long et tres technique, pas la peine de poster ici):
There are only a few common malloc implementations. The most common ones
are the System V one, implemented by AT&T, the GNU C Library implementation
and the malloc-similar interface of the Microsoft operating systems
(RtlHeap*).
Here is a table of algorithms and which operating systems use them:
Algorithm | Operating System
------------------------+--------------------------------------------------
BSD kingsley | 4.4BSD, AIX (compatibility), Ultrix
BSD phk | BSDI, FreeBSD, OpenBSD
GNU Lib C (Doug Lea) | Hurd, Linux
System V AT&T | Solaris, IRIX
Yorktown | AIX (default)
RtlHeap* | Microsoft Windows *
------------------------+--------------------------------------------------
<snip>
ell, however, exploitation is pretty straight forward now:
<jmp-ahead, 2> <6> <4 bogus> <nop> <shellcode> |
\xff\xff\xff\xfc \xff\xff\xff\xfc <retloc - 12> <retaddr>
CQFD
[^] # Re: Verifions mieux BIS ;-)
Posté par PLuG . En réponse à la dépêche Le bug de Zlib touche aussi des produits Microsoft. Évalué à 10.
Chez microsoft, on ne corrige pas les bugs a la volée cela n'est plus a démontrer.
Vu l'ampleur du probleme (zlib est utilisée de partout), il y a des TONNES de logiciels a corriger. Je trouve donc OPTIMAL de vérifier d'abord a quoi cela expose les clients avant de faire des release de patchs a gogo.
Si l'implementation de free() sur windows ne fait rien quand on l'appelle une seconde fois pour le meme segment de mémoire, il y a un bug dans l'algo de zlib qui n'est pas une faille, ni un probleme pour l'utilisateur (puisque ne crash pas le logiciel non plus). Si c'est le cas, je ne comprendrais pas que tout le monde fasse des release de patch pour un bug qui est pour le moins 'virtuel'.
Par contre il est vrai qu'un peu plus de certitude sur le diagnostique du cote windows ne ferai pas de mal.