PLuG a écrit 1006 commentaires

voir le site www.outguess.org pour un autre outil de steganographie, ainsi que des outils qui essaient de detecter d'eventuels messages cachés ...

a comparer...

il y a de tres bons boot-disk howto qui trainent sur le net.
en gros: le probleme c'est la taille disponible sur la disquette qui n'est pas enorme, si tu veux te lancer dans l'aventure, je te conseilles de generer un cdrom bootable ce qui est beaucoup plus souple.

sinon, il faut generer un noyau le plus petit possible, ensuite tu as le choix entre:
1 disquette (noyau petit pour garder de la place pour le filesysteme compressé qui sera ecrit a la suite sur la disquette, les 2 sont déposés avec dd)

2 disquettes: noyau jusqu'a 1,4Mo, seconde disquette pour le fs compressé.

Pour avoir joué avec ce genre de manip, sur le fs compressé il n'y a besoin de quasiement rien: un shell statique tout petit que tu nommes init,
quelques fichiers (protocols, services, ...) et un joli shell script pour lancer ce que tu veux faire. ensuite il te faudra surement quelques binaires supplementaires: ping, ssh, ... gnome (ah non filesysteme full :-).

Ensuite, l'optimisation des paquets par rapport au processeur, à part le noyau... Qu'est ce que cela veut dire cette phrase ?? Si tu sous entend que SEUL le noyau peut gagner a etre compilé pour ton CPU, je dirais que c'est plutot l'inverse: a l'epoque des noyaux 2.2 j'avais effectué des mesures (bench) de serveurs de fichiers smb pour un client. la difference entre un noyau 386 fourni par redhat et un noyau recompile pour la machine (pentium) n'etais meme pas mesurable, encore moins "visible". les processeurs recents apportent surtout des instructions nouvelles et rapides pour le traitement du signal (mmx, 3dnow ...). Je ne pense pas que le traitement du signal soit fait par le kernel :-) Certes ces meme processeurs apportent aussi des registres nouveaux dont le kernel peut profiter, je n'ai pas dit qu'il ne faut pas recompiler son noyau hein ... mais GCC ne sait pas tirer partis des multi-pipeline de la mort des CPU et on ne peut pas compiler le kernel avec icc. quand tu lance une tache, normalement elle passe plus de temps en mode user qu'en mode kernel (cf time ta-commande), et c'est normal. Le kernel n'est la que pour gerer le materiel, pas pour faire des calculs. bref si le kernel est utile a tous, il est deja pas mal optimise "a la main" par ses developpeurs, a tel point que le code est GCC -certaines version- ONLY. Par contre recompiler les librairies, surtout celles 3D/SON/VIDEO... et les applis qui s'en servent (comme mplayer) la oui !

certaines cartes wireless sont reconnues par le noyau linux nativement. Pour faire un routeur pour chez toi, comme d'habitude il suffit d'un petit pc (un 486 par exemple). De fait si ton routeur a une carte 100Mb et une carte Wireless, le maxi consommé sera 11Mb (limite Wireless), ce qui est pas enorme comme trafic, tu pourrais d'ailleur lui mettre une carte ethernet 10Mb plutot que 100, ca se trouve gratos et ca suffira de toutes facons (les 11Mb du wireless sont théoriques, en pratique on est en dessous). Bref le probleme se sera plutot que les adaptateurs PCMCIA permettant de connecter les cartes wireless dans ton routeur sont souvent sur bus PCI. donc n'importe quel pc a bus pci fera l'affaire. Pour la distrib, c'est celle que tu preferes. mais le routage wireless/ethernet n'est que du routage IP, il n'y a pas de particularite. (les distrib mono disquette genre LRP conviennent si elles supportent les modules wireless, sinon une recompile du noyau et hop ...)

Merci pour ces remarques constructives ;-) , je vais les prendre en compte.
Désolé pour le ton employé, ce n'est pas celui que j'aurai du utiliser.

substituer eth0 par ppp0 est effectivement facile, mais qui prouve que ce sera suffisant pour obtenir un script qui fonctionne ??
<mode avocat du diable>
le fait que l'exemple soit bugge montre que cet exemple n'est que theorique. On est face a un article bien ecrit mais pas fiable. Si cela se trouve certaines options utilisee ne marchent pas non plus ...
</mode avocat du diable>

La doc sur QoS manquait cruellement l'annee derniere quand j'en ai eu besoin, ces articles sont donc tres interessants pour les nouveaux venus.
Par contre il faut rester credible.
Qui ne se souvient pas des listing d'hebdologiciel que l'on devait debugger une fois sur 5. Ton article m'a rappelé un peu cette époque ... meme si je n'ai pas tappé ton listing :-)

C'est moi qui deconne ou son article est un peu baclé ?

un coup il gere le device eth0, puis le device ppp0 dans la meme suite de regles QoS.

je pense donc qu'il n'a pas testé ce qu'il a écrit (ou il n'a pas écrit ce qu'il a testé :-)).

C'est tres domage, autant un article sans exemple c'est pas utile, autant un article avec des exemples buggés, ca met en difficulté les débutants ... et ca les rebutte.

ça sent les mecs qui se font de la pub à pas cher sur le dos d'un projet ouvert auquel il ne participent même pas !

ouais, bof.
Sur bugtrack les types disent bien qu'ils voulaient entrer en contact avec Netscape pour toucher leur 1000$. Comme les developpeurs de mozilla sont en grande partie TOUJOURS des employes de Netscape, le chemin vers bugzilla aurait pu etre fait en interne...

La bonne question c'est plutot: pourquoi netscape n'a pas daigné répondre / ni avertir les developpeurs ???

oui le bug a ete ouvert dans mozilla suite aux remarques que les inventeurs du bug se sont vu opposer quand ils ont publie sur bugtrack.

je crois meme que ce ne sont pas eux qui ont ouvert le bug mais un gentil lecteur de bugtrack.

Comme cela est dit plus haut, les inventeurs du bug reprochent surtout a Netscape d'avoir fait le mort pour ne pas avoir a distribuer les 1000$ promis ...

pas tres cool avec les utilisateurs ...

J'ai lu cet article qui n'est qu'une traduction du thread sur bugtrack qui date de quelques jours.

Il se trouve que l'inventeur du bug (si on prend la terminologie valable aussi pour les inventeurs de trésors), a signale le probleme a Netscape et que Netscape a apparement pas daigne repondre.
NB: l'inventeur n'avait pas ouvert de bug dans bugzilla par contre, mais Netscape aurait pu le lui demander.

Malgre ce que tu dis, le bug est sérieux et d'autant plus triste que tout le monde est tombe sur le dos de microsoft a propos DU MEME PROBLEME. Aujourd'hui IE est corrige de ce point de vue, et pas netscape 6 ni le futur mozilla 1.0 (la rc1 n'est pas vulnerable car le composant XMLHttpRequest ne fonctionne pas du tout :-))

T'es bien gentil toi aussi ...

Les camescopes numeriques DV, relies en ieee1394 sont tous supportes, a condition que ta carte ieee1394 soit supportee par linux (les recentes le sont tous puisqu'elles ont aussi ete normalisees sous la pression de ... Microsoft :-))

J'utilise donc linux et le soft GPL dvgrab pour recuperer mes video sur mon disque dur.
Puis je reboote sous W2K pour faire le montage car sous linux je n'ai pas encore trouve de soft de montage equivalent a Premiere.
Ensuite je stocke le resultat sur une bande DV avec un shareware sous windows (ou avec premiere directement, c'est selon), car je ne connais pas de soft pour exporter la video DV en ieee1394 sous linux.

Donc je comprends tres bien la personne a qui tu repondais, AMHA, trop vite.

XFree a 10 ans, mais l'interface a beaucoup plus puisque XFree est un implementation de X11.
X11 a évolué dans le temps (X11R6 maintenant), en gardant la compatibilite ascendante.

je sais cela ne fait pas avancer le schmilblick, mais je pense qu'il ne faut pas confondre le projet et les API qui ont été pensées et retravillées bien avant que XFree naisse ... ce qui a aidé à faire un e bonne conception dès le départ :-))

effectivement,

Comment une application (suid ou pas d'ailleur) peut elle se premunir contre cela ?

A priori quand elle ouvre un fichier il obtient le plus petit descripteur disponible (posix), donc eventuellement stderr ou stdout si c'est libre.
du coup tout "printf" est fait dans le fichier, c'est le probleme d'aujourd'hui.

pour s'en premunir, elle pourrait tester que lors de l'ouverture elle obtient bien un id>2 ...
ou ne rien ecrire/lire dans les descripteur par defaut si elle ne fait pas le test.

le plus simple c'est quand meme pour une fois de tester dans le noyau. C'est pas pareil que "la pile non executable" ou le patch ne garanti pas que les exploits n'auront pas lieu.
Ici la correction noyau est efficace, par contre le test dans le kernel devrait peut etre (en plus) sortir un gros warning dans les logs de manière a attirer l'attention des developpeurs ...

Comme le dit la news, "ticket/Token passing" se refere a kerberos (et AFS qui se marie bien avec kerberos). En gros si j'ai bien compris, ssh peut utiliser les systèmes d'autentification de kerberos (qui sont tres bien AMHA). Dans la terminologie kerberos, on parle de ticket et de token qui passent de machines en machines (une machine server de ticket ...). Bref ssh doit pouvoir forwarder de rebond en rebond ces autentifications kerberos si on lui demande gentiment, comme il le fait avec ses propres clefs et un ssh-agent. Pour moi c'est clair. Sont impactés ceux qui ont compilé ssh avec le support kerberos et qui l'ont configuré pour propager les "clefs kerberos" de machines en machines.

bof.

ca coute cher mais ca permet de RE-vendre le meme produit aux memes clients donc ca rapporte.

au bout d'un certain temps comme les .doc de Word 2010 ne sont pas compatibles avec ceux d'avant tout le monde est obligé de passer à la caisse...

Ces carte Wi-Fi microsoft devront etre compatibles Wi-Fi je présume (certifiées WiFi). Je ne trouve donc pas cela très grave si c'est le cas.
En effet, comme les gens avertis n'achetent pas de winmodem, ils n'acheterons pas non plus de WinWiFi...
Les gens qui "dual bootent" quelques fois sous linux sont surpris de s'etre fait avoir en achetant leur WinPrinter, mais ils s'en rappellent et vérifient mieux le matériel qu'ils achetent par la suite...
Je connais de plus en plus de gens dans ce cas.
Ou je bosse, avant d'acheter des cartes reseau ou autre matériel, il n'est pas rare que je soit consulté pour l'aspect "utilisable sous tous les os" ...

Bref je pense qu'avec la montée en puissance des OS autres que windows, un jour microsoft sera obligé de ne pas se priver de ces parts de marché pour ses matériels.

Sinon, approchons un autre aspect: Microsoft fabriquerai des cartes WiFi spéciales pour son OS. Je ne voit pas d'arnaque la dedans si tous le monde est conscient des limitations. Apple vends bien des souris spéciales apple et audi des autoradios spéciaux pour ses voitures.
Tant que ne nous oblige pas a les acheter ... et que ca capte les meme emissions de radio !

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.

oui et non.

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.

ce soft est deja installe sur les redhat 7.2 (au moins), il s'appelle mii-tool, et vient avec le package "net-tools".

pas besoin de le telecharger ailleur ...

sysctl permet d'y accéder si /proc n'est pas monté, je suppose.

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.

sysctl et /proc c'est blanc bonnet et bonnet blanc ...

sysctl n'est autre qu'un interface pour manipuler les parametres de /proc .

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 ...

tu le vois, ce n'est pas simple du tout.