Outils
ces outils sont disponibles sous licence GPL v2.
SpamStats génère des statistiques à partir de
fichiers journaux issus d'un système tournant avec {exim/postfix/sendmail} et spamd.
HeadersFilter peut servir à cacher vos relais
de mails internes de l'extérieur, en enlevant certains en-têtes (configurables)
des emails sortants.
Règles de filtrage pour proxy inversé pour Apache, conçues
au départ pour une configuration de proxy inversé sous Apache.
Génère des statistiques sur le spam reçu sur votre serveur.
Ce projet a été déplacé. Il est désormais accesible sur le site d'INL
Ce script est utile si vous disposez de plusieurs relais de mails chaînés en sortie de
votre réseau, et que vous voulez les cacher au monde. Par défaut chaque relais
ajoute ses informations à l'en-tête des emails, ce qui peut donner des
informations sur votre architecture à des individus malveillants.
Ce script est à positionner de préférence sur le dernier relais en sortie de
votre réseau.
Il est absolument nécessaire d'éditer ce script et de le configurer
pour qu'il fonctionne correctement sur votre réseau.
Il va de soi que ce script va tout casser si il est mal configuré (ou qu'il
comporte des bugs pas encore trouvés).
Vous devriez donc le tester, le qualifier et le retester encore avant de
l'adopter sur vos machines de production.
Ce script fonctionne tout à fait correctement sur au moins une machine en
production, avec des milliers de mails traités chaque jour, et la charge de la
machine (sous postfix) est très acceptable.
Ce script est conçu pour être le plus léger possible (il n'utilise pas les
modules perl de gestion du Mime, ces modules sont très lourds notamment au
chargement).
Ce script ne fait que regarder les en-têtes des emails, et ne traite
absolument pas leur contenu. Quand il a fini son traitement sur l'en-tête, il
copie bêtement son entrée sur sa sortie.
Un fichier Postfix master.cf est fourni ici, afin d'aider à la
configuration.
ENTREE
Les emails doivent être passés via STDIN. Ce script doit être appelé avec
tous les arguments à envoyer au programme sendmail. Ces arguments seront
repassés directement à sendmail par le script.
Voir le fichier master.cf fourni pour plus de détails.
SORTIE
L'email filtré est envoyé à /usr/lib/sendmail
ATTENTION: le script va tout simplement ne rien faire si /usr/lib/sendmail
n'existe pas, vous perdrez des emails, et votre chef furieux vous mettre à la
porte. Je vous aurai prévenu :-).
BUGS
Ne fournit aucun fichier journal.
Il serait très utile de journaliser des informations via syslog, une ligne
par email filtré, pour dire si les choses vont bien, pour débugger, etc.
En l'état actuel des choses, il faudrait pour ce faire charger le module
Perl Syslog à chaque lancement du script, ce qui n'est pas pensable.
Une version démon de ce script devrait être écrite, un peu à la spamd. Ou
peut-être un petit démon SMTP. Je peux le faire pour vous, contactez moi :)
Téléchargement
headers_filter Version 0.2a (current)
fichier d'exemple Postfix master.cf
Dernières modifications:
0.2a: 03 Dec 2002 Les emails dont l'adresse destination contenait un "&"
étaient perdus, le "&" était très salement interprété au lancement de sendmail.
Voici des règles pour mod_rewrite,
utilisables pour sécuriser un serveur proxy inversé Apache, ou une configuration simple en serveur
web. La plupart de ces règles, si pas toutes, sont dérivées de règles Snort. Le principe est de répertorier les
attaques connues et de les bloquer. L'utilisation de ces règles peut bloquer des
fonctionnalités ou des pages légitimes de votre site. Il est donc nécessaire de
les tester !
Il est bien sûr possible de modifier ces règles, afin de protéger des
applications particulières, des CGIs, etc.
Ce travail est perfectible, vous êtes invités à m'envoyer un retour si vous
utilisez ces règles, ou des patches si vous en trouvez d'autres ou de meilleures.
Utilisation :
Extraire le fichier rules.tar.gz dans votre répertoire /etc/apache[2], un
sous répertoire security/ est créé.
Pensez à adapter le fichier security/403.conf aux graphismes de votre site.
Ce fichier doit comporter une ligne du genre :
RewriteRule .* http://error.foo.bar/unauthorized [P]
Où l'URL "http://error.foo.bar/unauthorized" est l'URL de votre site qui
donne l'erreur 403 et refuse l'accès.
Ce fichier est appelé depuis chaque fichier dans les sous-répertoire de
security/
Il va de soi que vous pouvez également positionner d'autres erreurs HTTP,
comme 404, etc. et les appeler à votre convenance depuis les fichiers du
sous-répertoire subdir/, suivant les cas.
La configuration par défaut de ces règles est de rediriger les requêtes
jugées mauvaises sur la page d'erreur 403.
Ajouter :
RewriteEngine On
Include security/rules/all.conf
dans la définition de votre site ou VirtualHost dans la configuration d'Apache.
Très important : N'utilisez pas la directive ProxyPass pour
proxifier vos machines, si votre proxy entrant est sous Apache 1.3.
Utilisez une règle RewriteRule, avec l'option [P], sinon les règles de filtrage
ne seront pas utilisées!
Téléchargement
rules-1.1.tar.gz : Les règles
build_rpconf.sh : un
script shell qui génère récursivement les fichiers "all.conf", nécessaires au
bon fonctionnement des règles. Lancez ce script si vous ajoutez ou enlevez des
fichiers de règles. Attention, si vous utilisez ce script, votre arborescence
security/rules ne doit PAS contenir d'autres fichiers que les fichiers de
règles!
Il est souhaitable de tester les performances de votre serveur si vous
activez ces règles, surtout si votre site est chargé. Ces règles fonctionnent
correctement sur au moins un proxy inverse en production.
Dernières modifications :
1.1 : Mises à jour des règles sur les dernières règle Snort (3
nouvelles règles) 11 Juin 2003
1.0b : Correction de rules/products/iis/readmeeml.conf qui
n'était pas l'image de la règle snort #1284 11 Juin 2003
Si vous utilisez ces outils, j'aimerais savoir ce que vous en pensez.
|