Joris Dedieu a écrit 1614 commentaires

>Et du coup je me pose la question de la faisabilité et de la pertinence d'installer >e système complet sur un raid miroir réalisé avec 2 clés usb

Mis à part que c'est une idée rigolote, cela n'a aucun intérêt. Tu vas perdre en performance et user tes périphériques pour rien.

Un système sur mémoire flash, doit être optimisé pour minimiser les écritures. C'est ça qui va compter avant tout.

Il vaut mieux utiliser sh que csh pour les scripts :
http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/

Les paiement pour lesquels il n'y a n'y a pas utilisation physique de la carte sont "à la bonne foi de l'acheteur". Si tu conteste, on doit te rembourser.:

C'est en tout cas comme ça que sont géneralement interprétés le bulletin n° 658 de la Cour de cassation (1er avril 2007) et l'article L. 132-4 du code monétaire et financier


La responsabilité du titulaire d'une carte mentionnée à l'article L. 132-1 n'est pas engagée si le paiement contesté a été effectué frauduleusement, à distance, sans utilisation physique de sa carte.

De même, sa responsabilité n'est pas engagée en cas de contrefaçon de sa carte au sens de l'article L. 163-4 et si, au moment de l'opération contestée, il était en possession physique de sa carte.
Dans les cas prévus aux deux alinéas précédents, si le titulaire de la carte conteste par écrit avoir effectué un paiement ou un retrait, les sommes contestées lui sont recréditées sur son compte par l'émetteur de la carte ou restituées, sans frais, au plus tard dans le délai d'un mois à compter de la réception de la contestation.

A moins que ça n'ait évolué depuis qu'on m'a appris cela .

Ils cherchent "Celle qui se souvient"


----------->

sinon tu peux faure awk '{ print "ls",$1 }' | sh

Google a plantéé ! Gooooooglllllle à plllllllannnnnnnnnntéééééééééé ...

>Justement pas. De nombreux spams sont simplement envoyés aux MX de basse priorité, dans l'espoir que les mesures antispam y seront plus légères

Ou tout simplement pour y balancer le backscatter.
http://en.wikipedia.org/wiki/Backscatter

Si c'est linéaire ça fait quand même 500 GO pour 30000 comptes. Soit environ 20 MO par compte : 20971520 caractères ascii. C'est proprement énorme.
Si je dois économiser des serveurs par rapport à la charge d'un spamassassin mais qu'au final, il me faut autant voir plus de machine pour la base de données c'est proprement délirant.
La question qui soutend derrière ça s'est la pertinence d'avoir à maintenir un service de base de données important pour le filtrage du spam.

Une BDD de 500 GO c'est pas de la gniognote. Quand tu défragmente les tables ça prends pas 3 secondes. Quand ça se corrompt ...

10go pour ~600 comptes mails filtrés
Questions : Comment faire quand tu as 30000 comptes ?

>Sinon, je ne comprends pas ta solution : me conseilles-tu de choisir un FAI à IP fixes ?

Tu peux avoir un FAI a IP fixe (ce n'est pas suffisant) ou utiliser un smarthost (serveur smtp).

>Non, ce n'est pas normal, ou alors, c'est le fait d'attribuer aux abonnés des IP dynamiques qui est anormal

Une IP identifie une ressource sur internet. Lorsque l'ip est sur une plage dynamique elle identifie une ressource de type "abonné adsl" donc une ou plusieurs machine clientes pas un serveur. Quelque chose qui n'est "pas un serveur" n'a pas a envoyer des mails.

Cette chose n'est "pas un serveur" pas simplement par décret. Mais pour une raison simple : lorsque tu as une ip dynamique, tu as effectivement vraiment accès à internet. Mais puisque tu n'est pas identifiable, internet n'a pas accès à toi. Et ça c'est la base actuelle, l'esprit que tous les acteurs essayent d'insuffler au protocole smpt ; des mta qui se parlent et se repondent.

Pas besoin d'aller jusque là. Autoriser un usager à voyager gartuitement, offrir un mois d'électricité ... C'est du vol. C'est faute lourde et tribunal correctionnel.
Tu peux refuser de vendre des tickets, tu peux refuser de contrôler les tickets. Tu peux refuser de rouler ou de réparer la ligne. Tu peux refuser de faire ton travail. Mais si tu remet tous les compteurs EDF de France à zéro (ce qui serait très rigolo), ou que tu rajoute plein de trains gratuit, tu es un terroriste. Un criminel. Au bucher !!!!

Tu pense bien que sinon, ils l'auraient déjà fait.

Dans le monde proprio on utilise des "preuves de concept" pour dévoiler la faille sans montrer comment on peut l'exploiter.

ça c'est vraiment plus class ...

" Je ne colporte pas de choses obsolètes, je répondais à une question que je crois importante : pourquoi une distribution aussi bien fichue est-elle "boudée" à ce point ? "

La question à 1000 € !!


Mandrake était la distribution numéro 1 sur le desktop :
- n° 1 sur la gestion des dépendance
- n° 1 sur l'internationnalisation
- n° 1 sur les outils graphiques d'installation et de configuration
- n° 1 sur la compatibilité materielle et logicielle (quitte à inclure du proprio qui pu)

Soit

Maintenant regarde combien de projets ont été placés au coeur de la distro puis abandonnés : multi network firewall, kolab, CLIC (le truc de cluster avec BULL), ADVX et tant d'autres ..

Maintenant demande toi pourquoi, drakdisk n'est pas l'outil de référence pour le partitionnement sous Linux et printerdrake avec lui.
Mandriva a Monsieur imprimante et Monsieur Gravure dans son staff. Est-ce que cela apparait ? Est-ce que lorsque tu pense imprimante et gravure libre tu penses Mandriva.
Des choix techniques évasifs et changeants, des outils inimportables sur d'autres distros, son petit monde à soi, voilà les raisons de l'échec de Mandriva. Regarde MDS, Pulse, mandrivamini qui connaît ? Tout ça va crever comme le reste dans l'indifférence générale.
Mandriva ne contribue pas au libre des gens de Mandriva y contribuent. Voila la différence avec RedHat. Voila la différence avec Debian.
Lors du départ de Gaël Duval puis Warly, tout le monde se disait que Mandriva allait se baser sur Debian. Tout le monde en rêvait.

A la place de ça on a eu l'ubuntu
Tout ça vaut 1 cent pas plus

À noter l'existence du plugin antispam [1] pour dovecot qui permet de spécifier un répertoire "spam" et qui, lorsqu'on y met un message, le classifie comme spam pour dspam (et autres .. ?) et qui, lorsqu'on en sort un message, le classifie comme non spam !

Je ne sais pas qui tu es mais si un jour je te vois, je t'embrasse :)

>En quoi l'utilisation de rbl_check dans spamassassin est désastreuse ?
C'est du simple vécu.
Essaye un filtrage avec et sans. Tu verra que seul le nombre de faux positifs diminue (je parle de la règle par défaut sans configuration particulière).

Cette règle au mieux ne sert à rien. L'utilisation de sorbs en particulier manque de finesse. Je ne parle même pas de contrôler les mails en sortie.

Brèf ça fait beaucoup de dns pour pas grand chose. Je me trompe peut-être mais c'est mon impression.

au fait tant que j'y suis j'ai pondu ça l'autre jour si y en a que ça intéresse


#!/usr/bin/perl -w

use strict;
use Net::DNS;

my $ip = $ARGV[0];
my $usage="Usage dnsblcheck ip";
die $usage unless($ip);

sub rev {
my $ip = shift;
my @tab = split(/\./,$ip);
@tab = reverse(@tab);
return join('.',@tab);
}

sub resolve {
my ($ip, $blacklist) = @_ ;
my $res = Net::DNS::Resolver->new;
my $qs = rev($ip);
$qs .= '.'.$blacklist;
my $query = $res->query("$qs","A");
if ($query) {
($query->answer)[0]->print;
$query = $res->query("$qs","TXT");
if ($query) {
($query->answer)[0]->print;
}
} else {
print "Pas dans $blacklist \n";
}
}
my @blacklists = qw/ list.dsbl.org
bl.spamcop.net
dynablock.easynet.nl
blackholes.easynet.nl
cbl.abuseat.org
dnsbl.sorbs.net
dnsbl.njabl.org
zen.spamhaus.org
spews.dnsbl.net.au
relays.ordb.org
proxies.blackholes.easynet.nl
dsbl.org /;
foreach(@blacklists){
resolve $ip, $_;
}


>Ah oui, et quand tu es un petit abonné ADSL avec un IP dynamique ? Tu ne >peux pas poster ? L'Internet, ce n'est pas réservé aux grandes entreprise

Non tu ne peut pas envoyer des mail à partir d'une ip dynamique et c'est normal. Par contre en choissant un fournisseur d'accès, pas un proxy pour héberger un serveur connecté à l'internet, ou en définissant un smarthost ça marche plutôt bien.

Et ce n'est pas spécialement plus cher.

Je vous trouve dur avec les rbl.

J'utilise énormément zen.spamhaus.org (qui certes n'est pas totalement gratuite) et je trouve qu'il y a de très bon résultats.
Je l'utilise au niveau smtp donc les spam n'encombrent pas mes spools et le travail de l'antispam est réduit.
La règle rbl_check de spamassassin est désastreuse dans certains cas. Mais je pense que l'utilisation des rbl dans ce contexte n'est pas appropriée.
Les rbl doivent aider ta mta à décider si légitimement elle peut accepter ce mail ou pas.

A ce propos je ne saurais que trop vous conseiller spamd :
http://www.openbsd.org/cgi-bin/man.cgi?query=spamd&sekti(...)
Il est assez rigolo de voir pf embourber un bot dans une lenteur affligeante.

>grosses entreprises légitimes qui se font blacklister
>faux positifs à foison, et j'en passe

Il suffit de lire sa boite abuse, et de réagir vite lorsqu'un problème est avéré.
Une grosse entreprise, si légitime soit elle qui écrit à une spamtrap est un spammeur comme un autre.
C'est vraiment une question d'attitude.
Free n'est jamais blacklisté. FranceTélécom ou OVH tout le temps.
C'est juste un exemple.

Tu peut rajouter un radius pour l'authentification et limiter la durée des sessions.

Bonjour,
- lorsque le fichier est là tu regarde à quelle heure il a été créé.
- Dans les access log tu cherche les requêtes POST datant du même moment ou les requetes GET avec =http par exemple

C'est comme ça que tu trouvera le script coupable. Par ailleurs, jette un coup d'oeil au mailq histoire de voir s'il n'envoie pas du spam et fait des netstat pour voir s'il n'a installé aucun service.

Désactiver allow_url_fopen est un très bonne idée. Tant que tu y es tu peux rajouter fsockopen, pfsockopen et toute la série des exec, shell_exec ...

Si ce n'est pas possible, il existe des solutions un peu gruick mais qui marchent.
Pour fsockopen et pfsockopen tu peux forcer un $host='localhost' dans fsockopen.c ainsi ton webmail continura à fonctionner sans qu'un pirate ne flood la terre entiere avec son udp pourris.
Pour le reste curl est là.
Pour la fonction exec, il y a un patch ici :
http://www.kyberdigi.cz/projects/execdir/english.html


D'une manière générale le patch Suhosin donne d'assez bon résultat.
http://www.hardened-php.net/suhosin/

Il ne faut pas non plus oublier les choses de bases : openbasedir voir safe-mode, utilisateurs sans privilèges, firewall, selinux ou grsec

Les mises à jours ont déjà été conseillées plus haut.

Il faut bien penser que le pirate ne fait pas ça pour s'amuser.
S'il héberge un phishing, qu'il escroque des gens, s'il envoie du spam, ta responsabilité au moins morale est engagée.

Ta remarque sur le .htaccess m'a choquée.

Tu doit maîtriser absolument tout ce qui se passe sur ton serveur. Si tu commence à être débordé, il faut tout remettre à plat d'urgence. Si c'est trop lourd pour toi, te faire aider soit par un hébergeur (qui fait de l'infogéreance), un prestataire quelconque ou en faisant appel à la communauté.

Reprend la main sur ton serveur c'est important. Tu es root, tu es responsable.

Mes deux cents
Joris

Je te le fais en gros :

-> CURRENT
Version de développement -> debian testing
-> STABLE
Version continue (stabilisation régulière de CURRENT)
Version de développement -> debian unstable
-> RELEASE with errata
Stabilisation de STABLE
Version sans évolution (hors sécurité) -> debian stable

Bien sur cela ne concerne que le système de base et le noyau. Les ports sont indépendants.

>Ah ça je le crois bien volontiers, mais bon attendre une journée de compilation pour ça ... :)

Et 12 Go de libre dans /usr :)

>Et puis recompiler tout le système, pourquoi pas, mais je vois pas l'interet si tu n'es pas sur une archi exotique.

Pour avoir une arbo des sources exactement correspondante au système installé. Et ensuite appliquer au cas par cas les patchs de sécurité qui te semblent pertinent sur cet arbre des sources.

Sur un système en prod c'est une façon de travailler qui évite d'être trop bourrin dans les mise à jour.

>supprimer sendmail
On ne supprime rien du système de base. On le reconstruit en sans ce que l'on ne veux pas.

WITHOUT_SENDMAIL="YES" dans la make.conf

Puis reconstruire le monde sans sendmail

Enfant

Petit extrait pour le plaisir :
http://www.pearson.fr/resources/download.cfm?GCOI=2744010046(...)

Beaucoup de nouveaux utilisateurs de systèmes Unix croient à un conflit entre
les camps BSD et Linux. Mais, si vous regardez un peu plus attentivement, vous verrez
que la plupart des développeurs de ces systèmes d’exploitation communiquent
et collaborent de manière libre et ouverte. Seuls les extrémistes parmi les développeurs
et les utilisateurs provoquent des frictions, un peu comme les hooligans
des clubs de football ou les fans des différentes séries Star Trek.