Re: ext3 et options
On Mon, May 14, 2007 at 02:51:13PM +0200, Sylvain Sauvage wrote: Franck Joncourt, dimanche 13 mai 2007, 13:15:58 CEST [...] Du coup, n'est il pas possible de creer un fichier de test avec un motif et une taille specifique sur la partition avec l'option dir_index. Ensuite, de desactiver cette option sur la partition, et de refaire la meme manipulation en ecrasant les anciennes donnees ? C'est juste une idee qui me passe par la tete. dir_index modifie la façon dont sont gérés les répertoires : utilisation d’arbres B (ou b-trees) pour le stockage des noms de fichiers et de sous-répertoires (au lieu d’une liste plate (?)). Pour faire un test à peu près utile, il faut donc créer un ou plusieurs répertoires, avec une grande quantité de fichiers ou de sous-répertoires. Mais il faut aussi bien choisir ses données de test. En effet, du point de vue théorique, il n’y a aucune question à se poser : on connaît le temps pris par une recherche, une insertion et une suppression (en gros, log(n) pour l’arbre B pour les trois opérations, et n pour une liste triée). Par contre, pour savoir si c’est utile pour toi dans la « vraie vie », il faut, d’une part, avoir des données qui ressemblent à celles que tu utilises tous les jours, que tu utilises le plus, avec une ressemblance suffisante dans la taille et l’organisation (nombre de fichiers par répertoires, noms...), et, d’autre part, faire des tests qui calquent les opérations que tu fais ou que tu comptes faire avec ces données. Sinon, tu fais juste une inutile vérification de ce que la théorie nous dit déjà, et, pire, un test d’une situation totalement artificielle. On c'est bien ecarte du thread de depart à cause de ma curiosité :p! A la base, gaetan voulait simplement savoir si le dir_index etait active sur une ou plusieurs partitions ext3. Je n'ai pas l'intention de mettre en place ce genre de tests, mais je voulais savoir comment il etait possible de verifier l'efficacite de l'option. En tout cas merci pour les infos. Bonne journee. -- Franck Joncourt http://www.debian.org http://smhteam.info/wiki/ GPG server : pgpkeys.mit.edu Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE signature.asc Description: Digital signature
Re: attribution d'adresse à imprimante résau
Bonjour a tous, Je ne passe pas par mon modem-routeur (wifi) quand j'utilise arp. J'ai simplement connecté mon PC à l'imprimante via un cable RJ45. Est-ce bien un cable croisé, et non un cable droit, normal ? -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: attribution d'adresse à imprimante résau
Le Mon, 14 May 2007 22:57:06 +0200 jerry Vat [EMAIL PROTECTED] a écrit: Je ne passe pas par mon modem-routeur (wifi) quand j'utilise arp. J'ai simplement connecté mon PC à l'imprimante via un cable RJ45. Le cable ne doit pas être croisé. Théoriquement le routeur relaie les requêtes arp... François Boisson -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [HS] Proteger un tar.gz
Le 14/05/07, mouss [EMAIL PROTECTED] a écrit : David Soulayrol wrote: La présence du mot de passe de change rien. Une attaque par force brute peut donner un bon résultat très rapidement. ca depend de la taille des clefs et de la valeur des données en absolu, et surtout de leur valeur à l'instant où elles sont craquées. En outre, la sécurité dépend de la durée de vie des données que l'on protège. Laisser un fichier à disposition sur une machine n'est valable que si ses données n'ont qu'un intérêt très limité dans le temps. Parce qu'a plus ou moins long terme, il sera de toutes manières déchiffré. Avec une passphrase assez longue et pas simple, ça protégera contre les petits bandits, ce qui est a priori le besoin du poulpe. Si les données sont trop importantes, c'est la banque ou un disque/bande/... (si on peut les protéger). s'il veut se protéger contre la NSA, il faut qu'il se mette dans une enceinte militaire ;-p -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] Oui la securité n'est pas maximale, M'enfin mon besoin est juste d'empecher la lecture par le premier quidam venu, si la NSA tiens absolument a lire mes fichiers de conf du serveur web, grand bien leur fasse :) Dans mes fichiers de conf sont enregistré mes scripts, dont un script qui contient le login/pass du user de sauvegarde de mysql, c'est pas non plus extremement confidentiel, quelqu'un arrive à l'avoir, il pourra lire mes bases de donées, c'est tout. En definitive, l'option la plus simple et la plus efficace (du moins celle qui m'a le plus plu) c'est avec openssl. Un grand merci pour les idées!
Re: Mise à jour de sécurité non accessible
Didier Raboud wrote: Julien Valroff wrote: Bonjour, En voulant mettre à jour mes machines suite à la publication de DSA 1289-1, je me rends compte que 2 machines n'ont pas accès aux mises à jour : apt-cache policy linux-image-2.6.18-4-vserver-k7 linux-image-2.6.18-4-vserver-k7: Installed: 2.6.18.dfsg.1-12etch1 Candidate: 2.6.18.dfsg.1-12etch1 [...] Où Candidate devrait être 2.6.18.dfsg.1-12etch2 Bien sûr, j'ai l'entrée security.d.o dans /etc/apt/sources.list Je ne fais pas de pining sur ces 2 machines. J'ai bien mis jour 2 autres machines. J'ai tenté de supprimer le cache dans /var/lib/apt/lists, sans succès. Je n'ai jamais rencontré ce cas de figure, et je ne vois pas du tout d'où cela peut venir. Avez-vous une petite idée ? Julien Bonjour, Pas de réponse à donner... Par contre, j'ai remarqué la même chose sur deux de mes serveurs, pourtant pas avec le même noyau (k7 et 686). Bon, je passe par apt-proxy avec ces deux machines (vers une des deux), mais j'ai vérifié la configuration d'apt-proxy : l'alias /security pointe bien au bon endroit. Bizarre, bizarre... Salutations, Didier Bonjour, j'ai finalement installé les mises à jour à la main... À la prochaine mise à jour non-fonctionnelle, je fais un rapport de bogue, promis... Salutations, Didier -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pb avec resolv.conf
Pierre a écrit : Jean-Yves F. Barbier a écrit : Pierre a écrit : Bonjour à tous, Suite à la migration vers Etch je constate l'évolution suivante : Le fichier /etc/resolv.conf est un lien sur /etc/resolvconf/run/resolv.conf - qui n'existe pas... En fait /etc/resolvconf/run est un lien sur /dev/shm/resolvconf... qui est un répertoire contenant: -rw-r--r-- 1 root root 0 2007-05-14 19:19 enable-updates drwxr-xr-x 2 root root 40 2007-05-14 19:19 interface (qui est vide) L'ennui c'est que concrètement, il n'y pas de fichier resolv.conf, et donc plus de résolution. Si je force l'écriture d'un /etc/resolv.conf ou d'un /etc/resolvconf/run/resolv.conf, cela fonctionne; mais au prochain reboot, tout est perdu. Comment faire pour retourner vers une situation saine et stable. Si vous avez des idées et des solutions, elles seront super bienvenues. * purger le package resolvconf J'ai fait un apt-get remove resolvconf et le système me répond que le paquet n'est pas installé... ha, c'est plus galère alors :( ne reste plus qu'à faire un: grep resolv.conf /var/lib/dpkg/info/* pour voir qui a eu l'outrecuidance de scratcher ton fichier. -- If men could get pregnant, abortion would be a sacrament.
Re: attribution d'adresse à imprimante ré sau
François Boisson a écrit : Le Mon, 14 May 2007 22:57:06 +0200 jerry Vat [EMAIL PROTECTED] a écrit: Je ne passe pas par mon modem-routeur (wifi) quand j'utilise arp. J'ai simplement connecté mon PC à l'imprimante via un cable RJ45. Le cable ne doit pas être croisé. Théoriquement le routeur relaie les requêtes arp... Ben si: il a relié les 2 en direct apparemment. Maintenant, comme l'a précédamment dit François, le plus rapide est peut-être d'utiliser un serveur DHCP (si c'est comme pour les HP, d'abord faire une impression de la page system [qui donne l'adresse MAC de l'imprimante], puis configurer le serveur DHCP pour qu'il lui donne la bonne adresse IP) -- Quand la justice n'est pas juste, l'injustice est exacte -- P. Dac
Re: attribution d'adresse à imprimante résau
Le Tue, 15 May 2007 12:50:23 +0200 Jean-Yves F. Barbier [EMAIL PROTECTED] a écrit: Ben si: il a relié les 2 en direct apparemment. Je me suis mal exprimé: Si il y a des pbms, c'est que le cable ne doit pas être croisé, il faut donc soit utiliser un cable croisé, soit un switch (le routeur fait switch) qui relaie les requêtes arp. François Boisson -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pb avec resolv.conf
Jean-Yves F. Barbier a écrit : Pierre a écrit : Jean-Yves F. Barbier a écrit : Pierre a écrit : Bonjour à tous, Suite à la migration vers Etch je constate l'évolution suivante : Le fichier /etc/resolv.conf est un lien sur /etc/resolvconf/run/resolv.conf - qui n'existe pas... En fait /etc/resolvconf/run est un lien sur /dev/shm/resolvconf... qui est un répertoire contenant: -rw-r--r-- 1 root root 0 2007-05-14 19:19 enable-updates drwxr-xr-x 2 root root 40 2007-05-14 19:19 interface (qui est vide) L'ennui c'est que concrètement, il n'y pas de fichier resolv.conf, et donc plus de résolution. Si je force l'écriture d'un /etc/resolv.conf ou d'un /etc/resolvconf/run/resolv.conf, cela fonctionne; mais au prochain reboot, tout est perdu. Comment faire pour retourner vers une situation saine et stable. Si vous avez des idées et des solutions, elles seront super bienvenues. * purger le package resolvconf J'ai fait un apt-get remove resolvconf et le système me répond que le paquet n'est pas installé... ha, c'est plus galère alors :( ne reste plus qu'à faire un: grep "resolv.conf" /var/lib/dpkg/info/* pour voir qui a eu l'outrecuidance de scratcher ton fichier. Merci pour ton aide. Les fichiers contenant "resolv.conf" sont les suivants : -rwxr-xr-x 1 root root 13K 2006-08-24 06:44 mailagent.postinst -rw-r--r-- 1 root root 5,5K 2007-04-19 16:09 manpages-fr.list -rw-r--r-- 1 root root 8,0K 2007-02-03 14:57 manpages-fr.md5sums -rw-r--r-- 1 root root 6,1K 2007-04-17 16:18 manpages.list -rw-r--r-- 1 root root 8,6K 2006-08-17 12:56 manpages.md5sums -rwxr-xr-x 1 root root 16K 2007-03-21 12:17 postfix.postinst -rw-r--r-- 1 root root 598 2007-04-19 16:07 resolvconf.list -rwxr-xr-x 1 root root 1,3K 2005-04-21 15:31 resolvconf.postrm Que dois-je faire pour corriger le problème ? -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:" To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: attribution d'adresse à imprimante ré sau
Bernard MAYER a écrit : Bonjour a tous, Je ne passe pas par mon modem-routeur (wifi) quand j'utilise arp. J'ai simplement connecté mon PC à l'imprimante via un cable RJ45. Est-ce bien un cable croisé, et non un cable droit, normal ? J'ai branché l'imprimante sur un autre PC sous W$, et tenté l'installation avec les drivers W$. Le cable RJ45 est vu comme débranché. Donc ça va certainement concerner le SAV Brother. Je ne vois pas d'autre solution. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: attribution d'adresse à imprimante résau
Le Tue, 15 May 2007 13:25:34 +0200 jerry Vat [EMAIL PROTECTED] a écrit: J'ai branché l'imprimante sur un autre PC sous W$, et tenté l'installation avec les drivers W$. Le cable RJ45 est vu comme débranché. Donc ça va certainement concerner le SAV Brother. Je ne vois pas d'autre solution. Puisqu'on te dit que ce cable doit être un cable croisé pour que ça marche en connexion directe. Ça ne marchera pas plus sous Windows. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: attribution d'adresse à imprimante ré sau
jerry Vat a écrit : J'ai branché l'imprimante sur un autre PC sous W$, et tenté l'installation avec les drivers W$. Le cable RJ45 est vu comme débranché. Donc ça va certainement concerner le SAV Brother. Je ne vois pas d'autre solution. Non, non il faut bien un câble croisé pour un raccordement direct, c'est un câble spécial. C'est normal de ne pas avoir de connexion dans ce cas. (Câble droit en raccordement direct) @+ Sil Pardon si j'ai fait un doublon. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Pb avec resolv.conf
Pierre a écrit : Jean-Yves F. Barbier a écrit : ... Pierre a écrit : Merci pour ton aide. Les fichiers contenant resolv.conf sont les suivants : -rwxr-xr-x 1 root root 13K 2006-08-24 06:44 mailagent.postinst -rw-r--r-- 1 root root 5,5K 2007-04-19 16:09 manpages-fr.list -rw-r--r-- 1 root root 8,0K 2007-02-03 14:57 manpages-fr.md5sums -rw-r--r-- 1 root root 6,1K 2007-04-17 16:18 manpages.list -rw-r--r-- 1 root root 8,6K 2006-08-17 12:56 manpages.md5sums -rwxr-xr-x 1 root root 16K 2007-03-21 12:17 postfix.postinst -rw-r--r-- 1 root root 598 2007-04-19 16:07 resolvconf.list -rwxr-xr-x 1 root root 1,3K 2005-04-21 15:31 resolvconf.postrm Ok, les 2 dernières lignes veulent dire que resolvconf a bien été installé, puis sans doute y'a-t'il eu au PB lors de la désinstallation Que dois-je faire pour corriger le problème ? Etant donné que dselect te dis que le package n'est pas installé, le plus rapide est de l'installer, puis de le désinstaller, afin que tous ses composants soient correctement enlevés. -- I went to the race track once and bet on a horse that was so good that it took seven others to beat him!
Re: attribution d'adresse à imprimante ré sau
jerry Vat a écrit : J'ai branché l'imprimante sur un autre PC sous W$, et tenté l'installation avec les drivers W$. Le cable RJ45 est vu comme débranché. Donc ça va certainement concerner le SAV Brother. Je ne vois pas d'autre solution. Non, non il faut bien un câble croisé pour un raccordement direct, c'est un câble spécial. @+ Sil -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: netinstall et module rt73
En ce Fri, 04 May 2007 23:47:58 +0200, le sermon de Guillaume Dualé [EMAIL PROTECTED] contenait: Salut, tu peux monter par exemple l'iso de la netinstall: #mount -o loop debian-netinstall.iso /mnt Tu copies l'initrd.gz: # cp /mnt/initall.386/initrd.gz /tmp Et tu listes les modules: # gzip -cd /tmp/initrd.gz | cpio -i -t | grep modules | less Bien, ben le module rt75 n'y est pas Comment puis-je reconstruire l'image de la netinstall? Une adresse de doc à me proposer, s'il vous plait? Rémi. -- Merci de m'avoir lu jusqu'ici, longue Vie et Prosperite. http://www.suinot.org
Re: attribution d'adresse à imprimante résau
Bernard MAYER a écrit : Bonjour a tous, Je ne passe pas par mon modem-routeur (wifi) quand j'utilise arp. J'ai simplement connecté mon PC à l'imprimante via un cable RJ45. Est-ce bien un cable croisé, et non un cable droit, normal ? J'ai branché l'imprimante sur un autre PC sous W$, et tenté l'installation avec les drivers W$. Le cable RJ45 est vu comme débranché. Donc ça va certainement concerner le SAV Brother. Je ne vois pas d'autre solution. Peut etre est-ce un simple pb de cable. Si vous disposiez, entre l'imprimante et votre pc, un hub, voir un switch, que vous reliez ces 3 elements au moyen de 2 cables droits, via le hub comme intermediaire, la presence (eventuelle) de signalisation sur le hub/le switch vous permettrait un meilleur dignostic. En l'etat, le sav devrait refuser l'incident. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: attribution d'adresse à imprimante ré sau
Bernard MAYER a écrit : Bernard MAYER a écrit : Bonjour a tous, Je ne passe pas par mon modem-routeur (wifi) quand j'utilise arp. J'ai simplement connecté mon PC à l'imprimante via un cable RJ45. Est-ce bien un cable croisé, et non un cable droit, normal ? J'ai branché l'imprimante sur un autre PC sous W$, et tenté l'installation avec les drivers W$. Le cable RJ45 est vu comme débranché. Donc ça va certainement concerner le SAV Brother. Je ne vois pas d'autre solution. Peut etre est-ce un simple pb de cable. Si vous disposiez, entre l'imprimante et votre pc, un hub, voir un switch, que vous reliez ces 3 elements au moyen de 2 cables droits, via le hub comme intermediaire, la presence (eventuelle) de signalisation sur le hub/le switch vous permettrait un meilleur dignostic. En l'etat, le sav devrait refuser l'incident. Ok. Je vais réfléchir à cette histoire de cable croisé ou /et de hub. Merci -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
felicitation
A VOTRE ATTENTION ALLIANCE FINANCE structure d'épargne et de crédit dont le siège est à Abidjan Côte d'Ivoire avec ses partenaires Sud Africains ,Marocains et Canadien vient de lancer une tombola nommee BILL GATES LOTERIE dans le cadre d'une semaine promotionnelle initié par notre associe Microsoft Au terme de ce tirage supervisé par un huissier , les résultas se présentent comme Suits : 1er lot : une Villa duplex située dans le quartier Chic de Cocody (Abidjan ) 2nd lot : la somme d'un montant de 18.700 Euros 3ième lot :la somme de 10.700 euros 4ième lot : la somme de 7.300 Euros Lors du tirage de cette tombola qui concerne aussi bien les personnes vivant ici en Côte D'ivoire que hors de Côte d'Ivoire mais qui ont une adresse électronique , votre adresse électronique a été tirée au deuxieme rang donc l'heureux (se) bénéficiaire de la somme de 18700 Euros. A la lecture de ce message , nous vous prions de nous adresser un courriel en retour en nous précisant votre nom , prénom, adresse , profession numéro de téléphone afin de vous mettre en contact avec l'huissier qui a eu à superviser la tombola. Mr kango denis Responsable marketing, Alliance Finance. rue des martyrs Abidjan , Cote d 'ivoire 05 bp 1988 abidjan 05 - Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses.
Re: udev et modules...
Pascal Hambourg, mardi 15 mai 2007, 00:52:10 CEST Salut, ’lut, Sylvain Sauvage a écrit : Je pense que Fred imaginait que udev, en plus de créer les dev, chargeait les modules au branchement d'un périphérique. Ce n'est pas le cas : Il semble que si, cf. http://vrfy.org/log/recent-state-of-udev.html Merci pour le lien, je le conserve. Et auparavant c'était hotplug qui le faisait. c'est le noyau qui le fait à partir de la table des identifiants exportée par chaque module (ces tables se retrouvent dans les fichiers modules.*map). C'est hotplug qui faisait comme ça. udev se base sur les alias de modules basés sur les identifiants matériels, qui sont stockés dans le fichier modules.alias créé par depmod dans /lib/modules/version. J’en étais resté au fait que udev remplaçait hotplug. En fait, il a aussi repris une partie des fonctions qui étaient dans le noyau. Rhalala, il faut toujours se remettre à jour. C’est à la fois frustrant et stimulant ;o) -- Sylvain Sauvage
Re: Installation offline
Le Tuesday 08 May 2007 16:30:54 Sébastien Adam, vous avez écrit : Bonjour à tous, Dans le service où je travaille, nous avons installé un PC avec Debian avec un programme bien spécifique (le nom du programme n'a pas vraiment d'importance ici). Nous avons fait l'installation du PC avec le CD 1 de Debian (version 4.0r0), nous avons téléchargé les différents paquets manquant et nous les avons installés en ligne de commande. Après quelques chipotages, nous avons réussi à tout faire fonctionner. Tout se passait bien jusqu'à ce qu'un collègue d'un autre service découvre notre système et en parle au contrôle de qualité pour qu'il puisse être diffusé dans l'entreprise. Nous devons aller faire une démonstration de l'installation. Malheureusement, nous devons mettre au point une procédure et rendre l'installation facile (sans les bidouillages, sans la ligne de commande et sans avoir à télécharger quoique ce soit depuis internet). Ma question est: où puis-je trouver les informations nécessaires pour créer un CD qui va nous permettre d'installer une liste de paquets simplement? Nous devons également modifier les paramètres de la carte réseau et quelques paramètres système. Le système est destiné à des informaticiens qui n'ont pas nécessairement de connaissance de Linux (voir aucune). Les paquets doivent pouvoir s'installer avec un minimum d'opérations (du genre double-click). Nous pourrions faire un script d'installation bash ou autre, mais je ne sais pas trop comment gérer les erreurs éventuelles. L'idéal, serait de pouvoir créer un CD d'installation Debian avec le programme intégré. Mais là j'avoue que ça dépasse totalement mes compétences. Et je ne suis pas sûr que nous ayons assez de temps pour ça (la présentation a lieu le 21 mai). Merci d'avance pour votre aide et à bientôt. Je mentionnerais ces deux autres façons : - L'installation automatisée avec un fichier preseed + scripts de post-installation. - Mondorescue (package mondo) qui crée un CD bootable, permettant de restauré tout en l'état, voir avec un script de post-installation de masteriser des machines. Aller, une troisième que je viens d'expérimenter, mais demandant un peux plusi d'investissement (temps et machine) : - Systemimager (et ça peu gérer d'autres distribs) Le principe : - boot résau (PXE) - création des partitions - restauration d'une image parmis plusieurs - post configuration (pour du Debian pure, il y a aussi FAI) pgpVIfC35W9TF.pgp Description: PGP signature
Protection contre un DDOS tcp open
Bonsoir à tous, De petits rigolos s'amusent à ouvrir des connections TCP sur mon serveur web sans envoyer de requêtes. Donc, on a bien SYN/SYN-ACK/ACK mais rien derrière. Le problème et que j'ai une appli un peu lourde qui nécessite un timeout d'apache à 25 minimum. J'ai beau chercher, je ne trouve pas de système pour se protéger de telles attaques et c'est pourquoi je m'en remets à vous. Une idée ? Merci, JB
Re: Protection contre un DDOS tcp open
Salut, En fait, déjà envisagé mais, j'aurais dû le préciser dans mon premier mail désolé, une dizaine de milliers d'IP (heureusement pas simultanées) provenant d'une 30aine de pays différents... Un peu dur à gérer :-) Merci quand même JB Message du 15/05/07 18:52 De : Benjamin RIOU [EMAIL PROTECTED] A : Jean-Baptiste FAVRE [EMAIL PROTECTED] Copie à : Objet : Re: Protection contre un DDOS tcp open Salut ! Que penses tu de limiter le nombre connexion par IP avec connlimit (si les attaques sont issues d'un sous réseau IP défini) ou bien avec le module recent d'iptables ? ++ Ben
console-data à relancer à chaque boot
Bonjour, j'arrive pas à trouver pourquoi je suis obligé à relancer dpkg-reconfigure console-data pour avoir le bon clavier. Si quelqun pourrait me mettre sur la piste. cordialement mess-mate -- English literature's performing flea. -- Sean O'Casey on P.G. Wodehouse
[Etch] problème de configuration de HAL
Bonjour,
Je désire ajouter des droits aux périphériques montés par pmount. Mon
but serait de les attribuer au groupe disk (gid=6), de rajouter les
droits d'écriture au groupe, ce qui permettrait à tous ceux qui sont
dans le groupe disk de pouvoir écrire sur la clé usb ou le disque
externe.
J'ai donc créé un fichier /etc/hal/fdi/policy/vfat.fdi dans lequel
j'ai mis :
?xml version=1.0 encoding=UTF-8?
deviceinfo version=0.2
device
match key=block.is_volume bool=true
match key=volume.fsusage string=filesystem
match key=volume.fstype string=vfat
merge key=volume.policy.mount_option.gid=6
type=booltrue/merge
merge key=volume.policy.mount_option.iocharset=iso8859-1
type=booltrue/merge
merge key=volume.policy.mount_option.codepage=850
type=booltrue/merge
/match
/match
/match
/device
Je recharge HAL avec /etc/init.d/dbus reload, j'insére ma clé usb et
au montage aucun changement n'a été effectué :
#mount
...
/dev/sda1 on /media/KINGSTON type vfat
(rw,noexec,nosuid,nodev,noatime,uid=1000,utf8,shortname=lower)
# ls -l /media/
total 24
lrwxrwxrwx 1 root root 6 2007-05-07 03:15 cdrom - cdrom0
drwxr-xr-x 2 root root 4096 2007-05-07 03:15 cdrom0
lrwxrwxrwx 1 root root 7 2007-05-07 03:15 floppy - floppy0
drwxr-xr-x 2 root root 4096 2007-05-07 03:15 floppy0
drwxr-xr-x 9 xentor root 16384 1970-01-01 01:00 KINGSTON
Pour vérifier si HAL avait bien pris en compte le fichier vfat.fdi, je
me suis servi de lshal :
...
udi = '/org/freedesktop/Hal/devices/volume_uuid_81E6_9066'
volume.policy.mount_option.codepage=850 = true (bool)
volume.policy.mount_option.iocharset=iso8859-1 = true (bool)
volume.policy.mount_option.gid=6 = true (bool)
volume.unmount.valid_options = {'lazy'} (string list)
volume.mount.valid_options = {'ro', 'sync', 'dirsync', 'noatime',
'nodiratime', 'noexec', 'quiet', 'remount', 'exec', 'utf8',
'shortname=', 'cod
epage=', 'iocharset=', 'umask=', 'dmask=', 'fmask=', 'uid='} (string
list)
org.freedesktop.Hal.Device.Volume.method_execpaths = {'hal-storage-
mount', 'hal-storage-unmount', 'hal-storage-eject'} (string list)
org.freedesktop.Hal.Device.Volume.method_argnames = {'mount_point
fstype extra_options', 'extra_options', 'extra_options'} (string list)
org.freedesktop.Hal.Device.Volume.method_signatures = {'ssas', 'as',
'as'} (string list)
org.freedesktop.Hal.Device.Volume.method_names = {'Mount',
'Unmount', 'Eject'} (string list)
info.interfaces = {'org.freedesktop.Hal.Device.Volume'} (string
list)
volume.ignore = false (bool)
...
Voilà si quelqu'un pourrait m'indiquer une solution ?
Merci d'avance pour votre aide.
Xentor609
Re: Protection contre un DDOS tcp open
Le 15/05/07, Jean-Baptiste FAVRE[EMAIL PROTECTED] a écrit : Salut, En fait, déjà envisagé mais, j'aurais dû le préciser dans mon premier mail désolé, une dizaine de milliers d'IP (heureusement pas simultanées) provenant d'une 30aine de pays différents... Un peu dur à gérer :-) Merci quand même JB Oui, mais tu peux peut être empecher plus de X connexions TCP simultanées pour chaque IP (voir le module recent d'iptables). Genre IP peut pas ouvrir plus de 3 connexions tcp avec ton serveur. Ou sinon, un filtrage de couche 7 est-il envisageable ? (on fait cela contre le p2p déjà) Une question que je me pose : pourquoi tant de haine envers ton serveur ? :-) ++ Ben
Re: Delai IDLE trop grand conntrack
Benjamin RIOU a écrit : Je peux pas avoir plus de 700 connexions ouvertes vers l'exterieur Et donc, malgré que j'aie 150 connexions established, j'avais facilement 750 connexions dans conntrack, ce qui bloquait toute demande de nouvel accès exterieur... :-) Dans quel état, les 600 autres connexions ? Elles sont soit en ESTABLISHED soit en TIME_WAIT. Je m'en doutais. L'état TIME_WAIT indique que la connexion s'est terminée récemment. Il permet d'accepter pendant un délai de grâce (2 minutes par défaut) d'éventuels segments retardataires arrivés en désordre après la séquence FIN avant effacement de la connexion de la table de suivi. Par contre elles sont tous ASSURED Cet indicateur est positionné quand la connexion a eu suffisamment de trafic dans les deux sens, donc toute connexion TCP qui est ou a été ESTABLISHED reste ASSURED même lorsqu'elle est en cours de fermeture. Son rôle, ainsi que celui de l'état TIME_WAIT, est expliqué là en français (forcer le charset Latin-1 ou 9 pour un affichage correct) : http://iptables-tutorial.frozentux.net/fr/x1391.html Si je comprends bien, ton upstream comptabilise des connexions qui sont considérées comme non ESTABLISHED par ta machine, et donc il arrive qu'il bloque les nouvelles connexions qui ont été autorisées par celle-ci ? Mais dans ce cas je ne vois pas trop en quoi réduire le délai d'expiration des connexions ESTABLISHED sur ta machine aiderait à résoudre le problème. Donc la modification que j'ai fait n'a pas pour but d'éradiquer les TIME_WAIT ? Ah non, la réduction de ip_conntrack_tcp_timeout_established a pour conséquence de virer plus vite les connexion établies (ESTABLISHED) inactives. Aucun effet a priori sur les connexions récemment terminées (TIME_WAIT). Et inutile de chercher à jouer sur ip_conntrack_tcp_timeout_time_wait, puisque 'connlimit' ne comptabilise pas les connexions dans cet état. J'avais pourtant l'impression que c'etait efficace ? :-S Ça efface seulement les connexions établies inactives depuis trop longtemps. Si le protocole applicatif le prévoit ou le permet, il est effectivement préférable de maintenir une connexion inactive vivante avec un keepalive géré au niveau applicatif et non au niveau TCP. C'est plus souple dans le choix du délai (réglable par connexion et par application) et ne requiert pas le support du keepalive par la pile TCP/IP. Il y a une option pour ça dans SSH, d'ailleurs. Oui. c'est d'ailleurs tres chiant quand on fait une capture wireshark ;-) Il y a des filtres dans wireshark pour ne pas capturer ce genre de signaux parasites. Dans la mesure où la passerelle sert essentiellement a du surf, et que la majorité de mes clients utilisent IE, c possible que le navigateur ne prenne pas la peine de clore les connexions... Sinon, pourquoi aurais-je autant de connexions pendantes ? Comme expliqué plus haut, l'état TIME_WAIT signale les connexions qui ont été fermées proprement récemment. Et un navigateur, ça peut générer beaucoup de connexions de courte durée pour charger tous les éléments d'une page web. Chaque connexion dure quelques dixièmes de seconde dans l'état ESTABLISHED puis reste dans l'état TIME_WAIT pendant 2 minutes avant d'être effacée. Ça pourrait expliquer la proportion de connexions dans cet état. Cependant normalement HTTP/1.1 permet de réutiliser une même connexion pour faire plusieurs requêtes HTTP consécutives, à condition que le navigateur et le serveur le supportent. C'est ce qu'on appelle une connexion persistante. Si les connexions TIME_WAIT sont majoritairement dues à la navigation web, la mise en place d'un proxy HTTP pourrait peut-être améliorer les choses. Si ton but est de faire en sorte que 'connlimit' comptabilise les connexions en cours à peu près de la même façon que l'upstream, il faudrait modifier ipt_connlimit.c pour qu'il n'exclue pas les connexions dans l'état TIME_WAIT. Ça présenterait au moins l'avantage de ne pénaliser que les clients qui produisent beaucoup de ces connexions et pas les autres. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [HS] Proteger un tar.gz
On Tue, May 15, 2007 at 12:03:42PM +0200, Le poulpe qui bloppe ! wrote: La présence du mot de passe de change rien. Une attaque par force brute peut donner un bon résultat très rapidement. ca depend de la taille des clefs et de la valeur des données en absolu, et surtout de leur valeur à l'instant où elles sont craquées. On parlait de zip/rar/... : pas de clefs, uniquement un mot de passe. Une attaque brute sur un mot de passe, c'est faisable sans problème majeur. Avec une passphrase assez longue et pas simple, ça protégera contre les petits bandits, ce qui est a priori le besoin du poulpe. Au contaire, avec ssl/gpg, il ne me semble pas que la passphrase augmente la sécurité du chiffrage du fichier: elle ne fait que protéger la clé privée, qui devrait, par définition, être conservée sur le système local. M'enfin mon besoin est juste d'empecher la lecture par le premier quidam venu, si la NSA tiens absolument a lire mes fichiers de conf du serveur web, grand bien leur fasse :) Tu disparaitras subitement, et dans quelques mois on verra des photos de toi en combinaison orange dans un comps de vacances à Cuba ;) Dans mes fichiers de conf sont enregistré mes scripts, dont un script qui contient le login/pass du user de sauvegarde de mysql, c'est pas non plus extremement confidentiel, quelqu'un arrive à l'avoir, il pourra lire mes bases de donées, c'est tout. C'est un sujet tout à fait différent, mais pourquoi avoir ce mot de passe dans la conf du serveur Web? Une sauvegarde de base de données faite à partir d'une crontab me paraitrait bien plus judicieuse. Y. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [HS] Proteger un tar.gz
Le Tue, 15 May 2007 20:29:35 +0200 Yves Rutschle [EMAIL PROTECTED] a écrit: On parlait de zip/rar/... : pas de clefs, uniquement un mot de passe. Une attaque brute sur un mot de passe, c'est faisable sans problème majeur. Quand même, avec un mot de passe de longueur 8 ayant majuscules chiffres et symboles, ça donne 70^8 possibilités soit à raison d'un million d'essais à la seconde un temps de craquage de 3300ans en moyenne. À mon avis, c'est jouable comme sécurité... Je ne connais pas bien le cryptage zip mais si sa seule faiblesse est la force brute, ça peut aller... François Boisson PS: Un mot de passe de 8 lettres est un minimum -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Compiler le noyau à partir de la sarge
bonjour, Quelle est la différence entre une installation à partir d'une sarge et en compilant un kernel 2.6.21 et une installation à partir d'une etch et en compilant un kernel 2.6.21 ? merci Ben _ Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Delai IDLE trop grand conntrack
Je m'en doutais. L'état TIME_WAIT indique que la connexion s'est terminée récemment. Il permet d'accepter pendant un délai de grâce (2 minutes par défaut) d'éventuels segments retardataires arrivés en désordre après la séquence FIN avant effacement de la connexion de la table de suivi. La connexion vers l'exterieur est elle fermée ou bien encore ouverte, finalement ? Parce que si elle a été fermée par l'hôte, j'ai pas envie que ma passerelle garde (même pour deux minutes), la connexion. Mon opérateur ne m'octroie pas plus de 700 connexions. Une connection TIME_WAIT est-elle une connexion ouverte ? Par contre elles sont tous ASSURED Cet indicateur est positionné quand la connexion a eu suffisamment de trafic dans les deux sens, donc toute connexion TCP qui est ou a été ESTABLISHED reste ASSURED même lorsqu'elle est en cours de fermeture. Son rôle, ainsi que celui de l'état TIME_WAIT, est expliqué là en français (forcer le charset Latin-1 ou 9 pour un affichage correct) : http://iptables-tutorial.frozentux.net/fr/x1391.html Intéressant ! Si je comprends bien, ton upstream comptabilise des connexions qui sont considérées comme non ESTABLISHED par ta machine, et donc il arrive qu'il bloque les nouvelles connexions qui ont été autorisées par celle-ci ? Mais dans ce cas je ne vois pas trop en quoi réduire le délai d'expiration des connexions ESTABLISHED sur ta machine aiderait à résoudre le problème. Donc la modification que j'ai fait n'a pas pour but d'éradiquer les TIME_WAIT ? Ah non, la réduction de ip_conntrack_tcp_timeout_established a pour conséquence de virer plus vite les connexion établies (ESTABLISHED) inactives. Aucun effet a priori sur les connexions récemment terminées (TIME_WAIT). Et inutile de chercher à jouer sur ip_conntrack_tcp_timeout_time_wait, puisque 'connlimit' ne comptabilise pas les connexions dans cet état. Oui, mais si ca me limite le nombre de connexions TIME_WAIT ouvertes, on va passer de 2 minutes à 20 secondes ! Comme expliqué plus haut, l'état TIME_WAIT signale les connexions qui ont été fermées proprement récemment. Et un navigateur, ça peut générer beaucoup de connexions de courte durée pour charger tous les éléments d'une page web. Chaque connexion dure quelques dixièmes de seconde dans l'état ESTABLISHED puis reste dans l'état TIME_WAIT pendant 2 minutes avant d'être effacée. Ça pourrait expliquer la proportion de connexions dans cet état. Cependant normalement HTTP/1.1 permet de réutiliser une même connexion pour faire plusieurs requêtes HTTP consécutives, à condition que le navigateur et le serveur le supportent. C'est ce qu'on appelle une connexion persistante. D'accord. Si les connexions TIME_WAIT sont majoritairement dues à la navigation web, la mise en place d'un proxy HTTP pourrait peut-être améliorer les choses. Le fichier de conf de squid me donne des aigreurs d'estomac. Si ton but est de faire en sorte que 'connlimit' comptabilise les connexions en cours à peu près de la même façon que l'upstream, il faudrait modifier ipt_connlimit.c pour qu'il n'exclue pas les connexions dans l'état TIME_WAIT. Ça présenterait au moins l'avantage de ne pénaliser que les clients qui produisent beaucoup de ces connexions et pas les autres. C'est quoi l'upstream ? Le flux montant ? Bah si les clients peuvent pas ouvrir plus de 20 connections par periode de 120 secondes, je crois que vais me faire tuer :-) ++ Ben
partenariat,et coopération.
hello, us it is it (Youth Of the Ivory Coast for Supports with the American Actions) J.I. S.A. A: réconnue by the ministry for the interior of the Ivory Coast by the number: 1972 and the town hall of yopougon, by the number: 3083 the human cause, is our reason of living. (to live for the different one) please, we voullons, to weave, of the rélations of partnership, and exchange with you. we rémercions you, for your compréhantion, and of vouloire collaborate with us. president founder: Gaoudi Djedje Thierry: [EMAIL PROTECTED]: 0022506228231. - Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail
RE : Re: Compiler le noyau à partir de la sarge
--- fred [EMAIL PROTECTED] a écrit : ben durand [EMAIL PROTECTED] a écrit : bonjour, Quelle est la différence entre une installation à partir d'une sarge et en compilant un kernel 2.6.21 et une installation à partir d'une etch et en compilant un kernel 2.6.21 ? Hmmm, les paquets fournis ? Ou je n'ai pas compris la question ? Ou formulé autrement : si j'installe avec un cd version sarge, et que je compile avec un noyau 2.6.21, est-il nécessaire que je reinstalle avec la version etch ? Je suppose que ce qui importe, c'est que le noyau soit à jour, mais que ce soit la version sarge ou etch à la base n'a que peut d'importance. Merci Ben ___ Découvrez une nouvelle façon d'obtenir des réponses à toutes vos questions ! Profitez des connaissances, des opinions et des expériences des internautes sur Yahoo! Questions/Réponses http://fr.answers.yahoo.com -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Protection contre un DDOS tcp open
On Tue, May 15, 2007 at 06:47:53PM +0200, Jean-Baptiste FAVRE [EMAIL PROTECTED] wrote a message of 13 lines which said: Donc, on a bien SYN/SYN-ACK/ACK mais rien derrière. Les SYN cookies, sans hésiter. syncookies=yes dans /etc/network/options et redémarrage (ou bien sysctl à la main). -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Protection contre un DDOS tcp open
Salut, Stephane Bortzmeyer a écrit : Jean-Baptiste FAVRE [EMAIL PROTECTED] wrote : Donc, on a bien SYN/SYN-ACK/ACK mais rien derrière. Les SYN cookies, sans hésiter. Si je ne m'abuse, les SYN cookies ne protègent que contre les connexions half-open (pas de ACK en réponse au SYN-ACK). D'autre part, la documentation du noyau prévient qu'ils présentent de sérieux inconvénients : syncookies seriously violate TCP protocol, do not allow to use TCP extensions, can result in serious degradation of some services (f.e. SMTP relaying), visible not by you, but your clients and relays, contacting you. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Protection contre un DDOS tcp open
On Tue, May 15, 2007 at 11:11:25PM +0200, Pascal Hambourg [EMAIL PROTECTED] wrote a message of 26 lines which said: Si je ne m'abuse, les SYN cookies ne protègent que contre les connexions half-open (pas de ACK en réponse au SYN-ACK). Hmmm, oui, en relisant le message originel, en effet. syncookies seriously violate TCP protocol, C'est très discuté. do not allow to use TCP extensions, C'est exact. Qui utilise ces options ? Qui les a déjà vues dans un paquet réel ? -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Protection contre un DDOS tcp open
On Tue, May 15, 2007 at 08:13:39PM +0200, Benjamin RIOU [EMAIL PROTECTED] wrote a message of 24 lines which said: Oui, mais tu peux peut être empecher plus de X connexions TCP simultanées pour chaque IP (voir le module recent d'iptables). connlimit Voir par exemple http://www.gecko26.com/blog/connlimit_sarge -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Delai IDLE trop grand conntrack
Benjamin RIOU a écrit : L'état TIME_WAIT indique que la connexion s'est terminée récemment. La connexion vers l'exterieur est elle fermée ou bien encore ouverte, finalement ? Fermée, mais encore présente dans la table de suivi pendant un certains temps. Parce que si elle a été fermée par l'hôte, j'ai pas envie que ma passerelle garde (même pour deux minutes), la connexion. Peu importe ce que fait ta passerelle. C'est ce que fait le suivi de connexion de l'upstream qui compte au final. Et inutile de chercher à jouer sur ip_conntrack_tcp_timeout_time_wait, puisque 'connlimit' ne comptabilise pas les connexions dans cet état. Oui, mais si ca me limite le nombre de connexions TIME_WAIT ouvertes, on va passer de 2 minutes à 20 secondes ! Qu'est-ce que ça changera ? Si ton but est de faire en sorte que 'connlimit' comptabilise les connexions en cours à peu près de la même façon que l'upstream, il faudrait modifier ipt_connlimit.c pour qu'il n'exclue pas les connexions dans l'état TIME_WAIT. Ça présenterait au moins l'avantage de ne pénaliser que les clients qui produisent beaucoup de ces connexions et pas les autres. C'est quoi l'upstream ? Le flux montant ? C'est le lien amont, le fournisseur de connectivité. Le FAI, quoi. Bah si les clients peuvent pas ouvrir plus de 20 connections par periode de 120 secondes, je crois que vais me faire tuer :-) Si j'ai bien compris, le problème vient de ce que : 1) le fournisseur amont compte les connections TIME_WAIT ; 2) il a un time-out sur cet état trop long. Et je ne vois pas ce que tu peux y faire, vu que tout ça se passe chez lui, pas chez toi. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Protection contre un DDOS tcp open
Je fais une réponse un peu groupée: Netfilter Recent: pourquoi pas mais il faudrait alors que je marque les connexions ouvertes et que je guette le paquet suivant dans une fenêtre de temps définie. Reste qu'Apache prendra quand même la connexion (puisqu'ouverte), et la fenêtre de temps pourrait bien rendre le timeout d'Apache obsolète. Connlimit: j'y ai pensé aussi mais il y a rarement plus de 2-3 connexions simultanées depuis la même IP. En fait, le problème est qu'Apache attend sagement le timeout (et je ne peux pas le baisser, cause l'appli PHP qui tourne... je sais, faut refaire l'appli, mais là, je ne peux pas faire grand'chose.). Dans finalement, je ne suis pas certain de l'efficacité de la mesure. Mais je vais recreuser l'affaire. Pourquoi tant de haine: ben, j'aimerais bien que le proprio du botnet me le dise :-s Plus sérieusement, soit je suis un dégât collatéral, soit il se trompe d'IP. J'vais p'tre creuser un mix des 2 solutions Netfilter. Je vous tiens au courant. Merci pour les réponses, JB Stephane Bortzmeyer a écrit : On Tue, May 15, 2007 at 08:13:39PM +0200, Benjamin RIOU [EMAIL PROTECTED] wrote a message of 24 lines which said: Oui, mais tu peux peut être empecher plus de X connexions TCP simultanées pour chaque IP (voir le module recent d'iptables). connlimit Voir par exemple http://www.gecko26.com/blog/connlimit_sarge
Re: Protection contre un DDOS tcp open
Stephane Bortzmeyer a écrit : syncookies seriously violate TCP protocol, C'est très discuté. do not allow to use TCP extensions, C'est exact. Qui utilise ces options ? Qui les a déjà vues dans un paquet réel ? L'option MSS ? Tout le monde, non ? -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Protection contre un DDOS tcp open
Les SYN-Cookies sont déjà activés, sans problèmes (effets de bord) jusqu'à présent. Merci quand même, JB Stephane Bortzmeyer a écrit : On Tue, May 15, 2007 at 11:11:25PM +0200, Pascal Hambourg [EMAIL PROTECTED] wrote a message of 26 lines which said: Si je ne m'abuse, les SYN cookies ne protègent que contre les connexions half-open (pas de ACK en réponse au SYN-ACK). Hmmm, oui, en relisant le message originel, en effet. syncookies seriously violate TCP protocol, C'est très discuté. do not allow to use TCP extensions, C'est exact. Qui utilise ces options ? Qui les a déjà vues dans un paquet réel ?
Re: Protection contre un DDOS tcp open
Re, J'avais oublié le filtrage de couche 7: Vu qu'aucune requête HTTP ne parvient au serveur, je risque d'avoir un peu de mal :-) Le fond du problème est donc bien de détecter qu'une connexion TCP légitime au sens TCP du terme ne l'est plus au niveau applicatif car aucune requête HTTP n'est envoyée dans un délai à définir (AMHA inférieur à 5 secondes en étant généreux). Et mes connaissances en iptables sont ici trop limitées :-( @+ JB Benjamin RIOU a écrit : Le 15/05/07, Jean-Baptiste FAVRE[EMAIL PROTECTED] a écrit : Salut, En fait, déjà envisagé mais, j'aurais dû le préciser dans mon premier mail désolé, une dizaine de milliers d'IP (heureusement pas simultanées) provenant d'une 30aine de pays différents... Un peu dur à gérer :-) Merci quand même JB Oui, mais tu peux peut être empecher plus de X connexions TCP simultanées pour chaque IP (voir le module recent d'iptables). Genre IP peut pas ouvrir plus de 3 connexions tcp avec ton serveur. Ou sinon, un filtrage de couche 7 est-il envisageable ? (on fait cela contre le p2p déjà) Une question que je me pose : pourquoi tant de haine envers ton serveur ? :-) ++ Ben
Re: Protection contre un DDOS tcp open
On Tue, May 15, 2007 at 10:40:17PM +0200, Stephane Bortzmeyer wrote: On Tue, May 15, 2007 at 06:47:53PM +0200, Jean-Baptiste FAVRE [EMAIL PROTECTED] wrote a message of 13 lines which said: Donc, on a bien SYN/SYN-ACK/ACK mais rien derrière. Les SYN cookies, sans hésiter. syncookies=yes dans /etc/network/options et redémarrage (ou bien sysctl à la main). Si je ne dis pas de betises, les syncookies cela permet simplement d'eviter de sauvegarder trop de ressources pour la gestion des nouvelles connexions, en renvoyant les informations necessaires à la mise en place des ces dernieres au client. En plus de l'activation des syncookies, je pencherais aussi pour la mise en place de regles iptables utilisant la correspondance *recent* pour blacklister les clients au bout d'un certains temps (hitcount). Cela eviterait au serveur d'avoir a traiter les nouvelles connexions associees aux attaquants. -- Franck Joncourt http://www.debian.org http://smhteam.info/wiki/ GPG server : pgpkeys.mit.edu Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE signature.asc Description: Digital signature
Re: Protection contre un DDOS tcp open
On Tue, May 15, 2007 at 11:15:52PM +0200, Stephane Bortzmeyer wrote: On Tue, May 15, 2007 at 11:11:25PM +0200, Pascal Hambourg [EMAIL PROTECTED] wrote a message of 26 lines which said: Si je ne m'abuse, les SYN cookies ne protègent que contre les connexions half-open (pas de ACK en réponse au SYN-ACK). Les syncookies c'est contre le SYN flood. On envoit encore et encore des paquets avec le flag SYN afin de consommer des ressources sur le server, et ainsi on ralentit le système, voire on empeche les nouvelles connexions. Hmmm, oui, en relisant le message originel, en effet. syncookies seriously violate TCP protocol, A mon avis cela vient surtout du fait que l'utilisation des syncookies a pour effet de faire transiter les informations relatives aux connexions sur le reseau. Il est ainsi possible de recuperer ces informations (je ne sais pas comment), et d'ouvrir une nouvelle connexion avec un flag ACK et non plus SYN. -- Franck Joncourt http://www.debian.org http://smhteam.info/wiki/ GPG server : pgpkeys.mit.edu Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE signature.asc Description: Digital signature
Re: Protection contre un DDOS tcp open
On Tue, May 15, 2007 at 11:29:09PM +0200, Pascal Hambourg wrote: Stephane Bortzmeyer a écrit : syncookies seriously violate TCP protocol, C'est très discuté. do not allow to use TCP extensions, C'est exact. Qui utilise ces options ? Qui les a déjà vues dans un paquet réel ? L'option MSS ? Tout le monde, non ? Attends je reflechis ... Non. Mais google il connait ca ! -- Franck Joncourt http://www.debian.org http://smhteam.info/wiki/ GPG server : pgpkeys.mit.edu Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE signature.asc Description: Digital signature
Re: Protection contre un DDOS tcp open
Le Tue, 15 May 2007 23:28:46 +0200 Jean Baptiste Favre [EMAIL PROTECTED] a écrit: Connlimit: j'y ai pensé aussi mais il y a rarement plus de 2-3 connexions simultanées depuis la même IP. En fait, le problème est qu'Apache attend sagement le timeout (et je ne peux pas le baisser, Ces connexions peuvent se faire à l'aveugle non (i.e sans avoir la réponse, on envoit un paquet «SYN» et on se moque du «ACK» qui revient. Il y a donc de grande chances que l'IP d'origine soit fausse. En fait je viens de tester sur mon serveur et une ligne comme # hping2 -S -p 80 --rand-source IP_de_ton_serveur suffit à faire ce genre de choses. Effectivement, le serveur accumule les douilles (sockets) en ouverture, envoit des ACK un peu partout et reste avec ses connexions ouvertes comme un crétin. J'ignore si il y a un moyen de retrouver l'origine sans doute unique de ces paquets. François Boisson -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Protection contre un DDOS tcp open
Ces connexions peuvent se faire à l'aveugle non (i.e sans avoir la réponse, on envoit un paquet «SYN» et on se moque du «ACK» qui revient. Il y a donc de grande chances que l'IP d'origine soit fausse. Je viens de voir que le ACK est renvoyé par le client à chaque fois (tu as donc SYN-- , SYN/ACK--- et ACK---. Ce que j'ai dit ne marche pas sauf si il est possible de fabriquer un paquet ACK indépendamment du paquet SYN/ACK reçu (mais il me semble qu'il y a un numéro de séquence serveur à récupérer et renvoyer (en rajoutant 1). J'ai du mal à croire qu'un gars ait dix mille machines à sa disposition pour te polluer mais je ne comprends pas comment il fait... (Les ACK sont-ils tous valides?) François Boisson -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Protection contre un DDOS tcp open
On Tue, May 15, 2007 at 11:19:16PM +0200, Stephane Bortzmeyer wrote: On Tue, May 15, 2007 at 08:13:39PM +0200, Benjamin RIOU [EMAIL PROTECTED] wrote a message of 24 lines which said: Oui, mais tu peux peut être empecher plus de X connexions TCP simultanées pour chaque IP (voir le module recent d'iptables). connlimit Voir par exemple http://www.gecko26.com/blog/connlimit_sarge Au fait, Pascal, avait mis en evidence la mise en place du patch-o-matic-ng dans un mail sur la liste. En l'occurence cela pourrait etre bien de mettre en oeuvre les deux correspondances (recent, connlimit), non ? -- Franck Joncourt http://www.debian.org http://smhteam.info/wiki/ GPG server : pgpkeys.mit.edu Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE signature.asc Description: Digital signature
Re: Protection contre un DDOS tcp open
On Wed, May 16, 2007 at 12:03:33AM +0200, François Boisson wrote: Le Tue, 15 May 2007 23:28:46 +0200 Ces connexions peuvent se faire à l'aveugle non (i.e sans avoir la réponse, on envoit un paquet «SYN» et on se moque du «ACK» qui revient. Il y a donc de grande chances que l'IP d'origine soit fausse. En fait je viens de tester sur mon serveur et une ligne comme # hping2 -S -p 80 --rand-source IP_de_ton_serveur dans le meme style, il y a aussi *nmap* avec l'option -sS : SYN-SYN/ACK-RST, mais je ne sais pas si il lui est possible de ne pas envoyer le flag RST. On peut aussi regarder du cote de *netcat*. -- Franck Joncourt http://www.debian.org http://smhteam.info/wiki/ GPG server : pgpkeys.mit.edu Fingerprint : C10E D1D0 EF70 0A2A CACF 9A3C C490 534E 75C0 89FE signature.asc Description: Digital signature
Re: Protection contre un DDOS tcp open
Jean Baptiste Favre a écrit : Le fond du problème est donc bien de détecter qu'une connexion TCP légitime au sens TCP du terme ne l'est plus au niveau applicatif car aucune requête HTTP n'est envoyée dans un délai à définir (AMHA inférieur à 5 secondes en étant généreux). Oui, et qui est mieux placé que le processus serveur lui-même (ou un programme de contrôle des connexions placé en amont comme tcpd) pour gérer ce délai ? Et mes connaissances en iptables sont ici trop limitées :-( S'il n'y a pas de point commun entre les adresses IP sources, je vois mal ce qu'iptables ou n'importe quel autre outil de filtrage réseau peut apporter dans la mesure où le mal est fait : la connexion est établie, occupant des ressources du serveur, et plus aucun paquet n'est transmis. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Programmation ALSA
slt a tous : cela fait une semaine que je me casse la tete sur la programmation d'alsa en mode CAPTURE. touts me paré correctement configuré comme le montre la copy d'un snd_pcm_dump() Hardware PCM card 0 'HDA Intel' device 2 subdevice 0 Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat: STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 4096 period_size : 2048 period_time : 46439 tick_time: 4000 tstamp_mode : NONE period_step : 1 sleep_min: 0 avail_min: 2048 xfer_align : 2048 start_threshold : 1 stop_threshold : 4096 silence_threshold: 0 silence_size : 0 boundary : 1073741824 par contre dés que j'appel la fonction snd_pcm_readi() celle-ci me retourne tour -32 ? et les données ne semblent pas correct. voici la liste des fonctions utiliser : Open correct : hw:0,2 OK The PCM device is in the open state. Alloc hardware OK Init Alloc hardware OK Access hardware OK Number channels 2 OK Set to 16 bits format OK Sample rate 44100 OK Hardware Params OK Prepare hardwareOK The PCM device is prepared for operation. Application can use snd_pcm_start() call, write or read data to start the operation. Une autre question si je passe en 8 bits de données, le 0 analogique est-il 128 par exemple ? si vous avez des infos ou autre je suis preneur (pas le lien sur http://www.alsa-project.org je suis deja passé dessus :) Bye et merci de vos reponce Yannick
Re: Delai IDLE trop grand conntrack
On Tue, 15 May 2007 20:22:25 +0200 Pascal Hambourg [EMAIL PROTECTED] wrote: Son rôle, ainsi que celui de l'état TIME_WAIT, est expliqué là en français (forcer le charset Latin-1 ou 9 pour un affichage correct) : http://iptables-tutorial.frozentux.net/fr/x1391.html Sans devoir forcer, c'est là aussi : http://perso.orange.fr/arsace/ http://www.linux-france.org/prj/inetdoc/guides/iptables-tutorial/ -- M.B -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: RE : Re: Compiler le noyau à partir de la sarge
fred a écrit : ben durand [EMAIL PROTECTED] a écrit : Ou formulé autrement : si j'installe avec un cd version sarge, et que je compile avec un noyau 2.6.21, est-il nécessaire que je reinstalle avec la version etch ? Je suppose que ce qui importe, c'est que le noyau soit à jour, mais que ce soit la version sarge ou etch à la base n'a que peut d'importance. Je dirais qu'il se pourrait que la sarge n'aime pas le 2.6.21. (j'ai essayé de caser un troisième conditionnel dans la phrase, mais sans succès). Ceci-dit, je ne comprends toujours pas trop le but de la man½uvre... Pourquoi ne pas installer une etch directement, qui est maintenant stable (et sarge, old-stable) ? Bonjour,soir. Du point de vue du noyau, il n'y a aucune différence. L'interret que j'ai eu à faire ce genre de manip et que sur une machine multi DD, l'install d'etch n'arrivait pas au bout. J'ai donc installer une sarge mini, un kernel 2.6.21 tout neuf et enfin, un aptitude dist-upgrade. Donc, les dernier kernels passent très bien sous sarge. Dans ce cas là, il y a un interret. -- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs From et Reply-To: To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Protection contre un DDOS tcp open
S'il n'y a pas de point commun entre les adresses IP sources, je vois mal ce qu'iptables ou n'importe quel autre outil de filtrage réseau peut apporter dans la mesure où le mal est fait : la connexion est établie, occupant des ressources du serveur, et plus aucun paquet n'est transmis. (ce qui suit est probablement une immense connerie) Mettons que ton service à contacter sur le port 80. Serait-il possible de faire une erreur 301 Moved Permanantly vers un autre port ? Je m'explique, X se connecte à ton serveur sur le port 80. Il fait un GET / La page lui répond d'aller voir sur le port 8040, sur laquelle ton serveur est doresetnavant. X se connecte alors au 8040 et tout va bien. Formidable. Maintenant, le bot va pas aller sur le port 8040 car il fait pas de requette HTTP. Sur ton serveur Apache, tu mets un timeout de 3 secondes sur le port 80, et un timeout plus long sur le 8040. Comme ca ton bot n'aura pas d'accès à ton serveur, et pourra être jetté sur le champ. Qu'est-ce que t'en penses ? ++ Ben
