Bonjour,
voila : j'ai un réseau à domicile de trois postes (2 Windows XP + 1 Ubuntu feisty et Ethernet 10 adresses statiques 192.168.0.x). On accède depuis chaque poste XP à internet via le poste feisty et une freebox en RJ45 (eth1).
J'ai installé p3scan et clamav sur la feisty. En testant la connection par telnet comme dans le tuto de coolaman sur Ubuntu doc j'ai bien l'activation du scan à réception d'un de mes mails (message : "p3scan'ing").
Par contre, quand je fais pareil (soit sous mon ident ou celui de ma femme par exemple) depuis un poste XP : néant ; je récupère le mail sans scan apparemment.
Comme j'entrevoyais là une solution pour protéger mes postes XP roll, je m'inquiète.
Ma question sera simple : est-ce possible ? subsidiairement que dois-je faire pour que les mails à destination d'un poste XP soient scannés/analysés par p3scan+clamav ?
Merci d'avance.
Michel
postes XP SP2 sur station "hand-made" avec pare-feu Windows activé et anti-virus (WinClam/freshclam et Norton en attente de fin d'abonnement) raccordés ethernet 10 en ip statiques 192.168.0.x, Mozilla Firefox 2.0.0.5 et Mozilla Thunderbird 1.5.0.12.
feisty sur station "hand made" (céléron 2,4GHz)
p3scan version 2:2.1-3 (feisty)
clamd version 0.90.2-0ubuntu1.3 (feisty-security)
Mozilla Firefox 2.0.0.5
Mozilla Thunderbird 1.5.0.12
eth0 interface le réseau domestique
eth1 donne accès au net via freebox V3 sur adresse dynamique
Règles iptables
#!/bin/sh
# /etc/network/if-pre-up.d/iptables-start
# Script qui démarre les règles de filtrage "iptables"
# Formation Debian GNU/Linux par Alexis de Lattre
# http://formation-debian.via.ecp.fr/
# REMISE à ZERO des règles de filtrage
iptables -F
iptables -X
iptables -t nat -F
# DEBUT des "politiques par défaut"
# Je veux que les connexions entrantes soient bloquées par défaut
iptables -P INPUT DROP
# Je veux que les connexions destinées à être forwardées
# soient acceptées par défaut
iptables -P FORWARD ACCEPT
# Je veux que les connexions sortantes soient acceptées par défaut
iptables -P OUTPUT ACCEPT
# FIN des "politiques par défaut"
# DEBUT des règles de filtrage
# Pas de filtrage sur l'interface de "loopback"
iptables -A INPUT -i lo -j ACCEPT
# J'accepte le protocole ICMP (i.e. le "ping")
iptables -A INPUT -p icmp -j ACCEPT
# J'accepte le protocole IGMP (pour le multicast)
iptables -A INPUT -p igmp -j ACCEPT
# J'accepte les paquets entrants relatifs à des connexions déjà établies
iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# La règle par défaut pour la chaine INPUT devient "REJECT"
# (il n'est pas possible de mettre REJECT comme politique par défaut)
iptables -A INPUT -j REJECT
# J'accepte les paquets entrants relatifs à des connexions déjà établies pour les flux vidéo
iptables -A INPUT -p tcp --dport 8080 -j ACCEPT
iptables -A INPUT -p udp --dport 1234 -j ACCEPT
# FIN des règles de filtrage
# DEBUT des règles pour le partage de connexion (i.e. le NAT)
# Activation du pontage NAT entre les cartes réseau.
echo 1 >/proc/sys/net/ipv4/ip_forward
# Décommentez la ligne suivante pour que le système fasse office de
# "serveur NAT".
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
# Si la connexion que vous partagez est une connexion ADSL, vous
# serez probablement confronté au fameux problème du MTU. En résumé,
# le problème vient du fait que le MTU de la liaison entre votre
# fournisseur d'accès et le serveur NAT est un petit peu inférieur au
# MTU de la liaison Ethernet qui relie le serveur NAT aux machines qui
# sont derrière le NAT. Pour résoudre ce problème, décommentez la ligne
# suivante.
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS -o eth1 --clamp-mss-to-pmtu
# mise en place de l'interception des courriels par p3scan pour analyse
# par ClamAV et Spamassassin.
# Prise en compte sur le port POP3 (25) et redirection vers p3scan sur
# le port 8110
iptables -t nat -A OUTPUT -p tcp --dport pop3 -m owner --uid-owner 1004 -j ACCEPT
iptables -t nat -A OUTPUT -p tcp --dport pop3 -j REDIRECT --to 8110
# FIN des règles pour le partage de connexion (i.e. le NAT)
Configuration p3scan
Groupe p3scan GID 111, User p3scan GUID 1004
/etc/p3scan/p3scan.conf
# PID File
# default: /var/run/p3scan/p3scan.pid
pidfile = /var/run/p3scan/p3scan.pid
# Max Childs
# default: 10
maxchilds = 10
# IP Address
ip = 0.0.0.0
# Port
# default: 8110
port = 8110
# TargetIP, TargetPort
# default: targetport is ignored in transparent proxy mode
# targetip = 0.0.0.0
# targetport = 8110
# Username
# default: mail
user = p3scan
# Notify Directory
# default: /var/spool/p3scan/notify
notifydir = /var/spool/p3scan/notify
# Virus Directory
# default: /var/spool/p3scan
virusdir = /var/spool/p3scan
# Just Delete
# default: Keep infected messages in Virus Directory
# justdelete
# Bytes Free
# default: bytesfree = 0 (disable checking for space)
# bytesfree = 100000
# Scanner Type
# default: basic
scannertype = basic
# Virusscanner
scanner = /usr/bin/clamdscan --no-summary -i
# Scanner Returncode
# default: 1
# Good Scanner return codes
# default: none
# Regular Expression for Virusname
# default:
# deMIME Setting
# default: <no demime>
# Broken email clients
# broken
# ISP Spam
# default:
# Enable Spam checking
# default: no checking of spam
# checkspam
# Mail::SpamAssassin
# spamcheck = /usr/bin/spamc
# DSPAM
#spamcheck = /usr/bin/dspam --user dspamuser --mode=teft --stdout --deliver=innocent,spam --feature=ch,no,wh
# Rename Attachments
# default: none
# Overwrite (disable) HTML
# default: do not disable HTML
# Quiet
# default: display all less debug info
# Template
# default: /etc/p3scan/p3scan.mail
# Subject
# default: Subject: "[Virus] found in a mail to you:" <virus name>
# Notify
# default: Per instruction, the message has been deleted.
# END of configuration
Configuration de Clamav
Groupe clamav GID 1001 User clamav 1003
/etc/clamav/clamd.conf
#Automatically Generated by clamav-base postinst
#To reconfigure clamd run #dpkg-reconfigure clamav-base
#Please read /usr/share/doc/clamav-base/README.Debian.gz for details
LocalSocket /var/run/clamav/clamd.ctl
FixStaleSocket true
User p3scan
AllowSupplementaryGroups true
ScanMail true
ScanArchive true
ArchiveMaxRecursion 5
ArchiveMaxFiles 1000
ArchiveMaxFileSize 10M
ArchiveMaxCompressionRatio 250
ArchiveLimitMemoryUsage false
ArchiveBlockEncrypted false
MaxDirectoryRecursion 15
FollowDirectorySymlinks false
FollowFileSymlinks false
ReadTimeout 180
MaxThreads 12
MaxConnectionQueueLength 15
StreamMaxLength 10M
LogSyslog false
LogFacility LOG_LOCAL6
LogClean false
LogVerbose false
PidFile /var/run/clamav/clamd.pid
DatabaseDirectory /var/lib/clamav
TemporaryDirectory /tmp
SelfCheck 3600
Foreground false
Debug false
ScanPE true
ScanOLE2 true
ScanHTML true
DetectBrokenExecutables false
MailFollowURLs false
ArchiveBlockMax false
ExitOnOOM false
LeaveTemporaryFiles false
AlgorithmicDetection true
ScanELF true
NodalCoreAcceleration false
IdleTimeout 30
MailMaxRecursion 64
PhishingSignatures true
LogFile /var/log/clamav/clamav.log
LogTime true
LogFileUnlock false
LogFileMaxSize 0
# sans avoir tout lu...
Posté par NeoX . Évalué à 1.
1°) mettre ton ubuntu en passerelle ou serveur email.
2°) les postes XP ne se connecte pas à la messagerie sur internet, mais à ton serveur de mail
3°) et c'est le serveur de mail qui recupere les emails chez le founisseur.
[^] # en ayant lu
Posté par symoon . Évalué à 2.
[..]
Description: transparent POP3-proxy with virus- and spam-scanning
Donc il n'est pas nécessaire d'aller chercher les mails sur le poste sous linux.
iptables -t nat -A OUTPUT -p tcp --dport pop3 -j REDIRECT --to 8110
Je pense qu'il faudrait plutôt utiliser la chaine INPUT pour rediriger tout ce qui va à destination du POP vers p3scan.
Essaie de regarder la doc dans /usr/share/doc/p3scan
[^] # Re: en ayant lu
Posté par michel44 . Évalué à 1.
il n'est pas nécessaire d'aller chercher les mails sur le poste sous linux : c'est ce qui me semble, on ne fait que passer sur le poste linux pour le NAT et le masquerade sans mettre en oeuvre quoi que ce soit d'autre. Question subsidiaire : quel est le serveur de mail sur le poste XP et peut-il (doit-il) interagir avec p3scan ?
Pour les iptables, effectivement j'aurais intuitivement plutôt pensé à la chaîne INPUT mais comme je suis loin de dominer la chose j'ai fait comme dans le tuto que j'ai suivi.
Je me replonge donc dans la /us/share/doc/p3scan et éventuellement je tenterai une règle avec INPUT.
Pourrais-tu me dire comment avoir un log de ma connexion sous XP car le telnet est peu bavard à l'écran ?
D'avance merci
A +
Michel
[^] # Re: en ayant lu
Posté par Sylvain Sauvage . Évalué à 2.
iptables -t nat -A PREROUTING -p tcp --syn --dport pop3 -j REDIRECT --to-port 8110
Par contre, ça ne bloque pas les connexions depuis la passerelle (puisqu’elles ne passent pas par la chaîne PREROUTING). Ce qui est logique puisque p3scan va faire ces connexions vers les vrais serveurs : ce serait bête de le faire boucler sur lui-même.
Donc, pour filtrer les connexions depuis la passerelle, il faut différencier celles qui viennent de p3scan et les autres. Et on le fait sur la chaîne OUTPUT :
D’abord, autoriser p3scan à sortir (on vérifie le propriétaire du processus) :
iptables -t nat -A OUTPUT -p tcp --dport pop3 -m owner --uid-owner p3scan -j ACCEPT
puis rediriger les autres :
iptables -t nat -A OUTPUT -p tcp --dport pop3 -j REDIRECT --to-port 8110
Voilà. Avec ces trois règles, ça devrait fonctionner.
[^] # Re: en ayant lu
Posté par michel44 . Évalué à 1.
j'ai bien les deux règles OUTPUT pour le "serveur" issues de la doc p3scan (comme le suggérait Symoon).
C'est la première fois que j'entends parler directement de PREROUTING comme solution mais effectivement ça paraît toutà fait logique.
Je tente ma chance.
Encore deux trois coups comme ça et je vais finir par comprendre comment fonctionnent les iptables lol.
A +
Michel
[^] # Re: en ayant lu
Posté par michel44 . Évalué à 1.
Scan impect sur le "serveur" mais la règle PREROUTING bloque les connexions à pop.free.fr : "Impossible d'ouvrir une connexion à l'hôte sur le port 23 : Echec lors de la connexion" me bégaye Microsoft Telnet.
D'abord c'est quoi ce port 23 ?
Est-ce que le problème ne viendrait pas, encore une fois lol, du côté windaube ?
La, j'avoue pédaler un peu dans la semoule...
A suivre, je continue mes fouilles
Michel
[^] # Re: en ayant lu
Posté par symoon . Évalué à 2.
=> Précise le port 110 à ton client telnet.
[^] # Re: en ayant lu
Posté par michel44 . Évalué à 1.
Je viens de m'en rendre compte tout seul lol
Malheureusement, la bonne commande me renvoie : "Impossible d'ouvrir une connexion à l'hôte sur le port 110 : Echec lors de la connexion"
Ma bourde permet donc de savoir qu'il y a quelque chose qui coince avec cette règle car si je la commente tout se passe nickel... sauf le scan !
A suivre
Merci de ton aide
Michel
[^] # Re: en ayant lu
Posté par Sylvain Sauvage . Évalué à 2.
En ce qui concerne la règle en PREROUTING, c’est une règle classique de proxy transparent (p.ex. Squid). Elle devrait fonctionner.
En revanche, je n’ai pas testé les deux en même temps mais ça ne devrait pas poser de problème : les connexions internes ne passent pas par le PREROUTING et les connexions externes sont directement dirigées vers p3scan (qui peut sortir).
Tu as d’autres règles en jeu (en plus du NAT évidemment (qui doit se trouver après, d’ailleurs)) ?
[^] # Re: en ayant lu
Posté par michel44 . Évalué à 1.
- remise des tables à zéro
- règles par défaut
- règles sur les INPUT
- règles de NAT
Elles sont en tête de mon post initial. Il y a une règle par défaut pour les sorties : iptables -P OUTPUT ACCEPT
A +
Michel
[^] # Re: en ayant lu
Posté par Sylvain Sauvage . Évalué à 2.
Je ne vois pas le problème (mais je ne suis pas un compilateur de règles iptables).
Tu as essayé d’ajouter, temporairement, des règles de LOG (doublon d’une règle, placé _avant_ elle, avec l’action « -j LOG --log-prefix "règle xxx" ») pour voir où ça coince ?
La règle (je la redonne sous la forme donnée par iptables-save : iptables -t nat -A PREROUTING -p tcp -m tcp --dport 110 --tcp-flags FIN,SYN,RST,ACK SYN -j REDIRECT --to-ports 8110) est-elle vraiment la première ?
[^] # Re: en ayant lu
Posté par michel44 . Évalué à 1.
Ah oui, suis-je bête :o) meuh non.
Tu as essayé d’ajouter, temporairement, des règles de LOG ... pour voir où ça coince ?
Fait :
[331513.009852] PREROUTING port 110IN=eth0 OUT= MAC=00:08:54:09:a3:b0:00:11:09:90:f1:4d:08:00 SRC=192.168.0.2 DST=212.27.48.3 LEN=48 TOS=0x00 PREC=0x00 TTL=128 ID=38409 DF PROTO=TCP SPT=3447 DPT=110 WINDOW=16384 RES=0x00 SYN URGP=0
Il répète ça deux fois (trois tentatives de connexion sans doute) dans /dev/log. SRC=le micro XP, DEST=DNS free, eth0=carte réseau local de la passerelle linux, MAC=adresse physique de ma eth0 sur la passerelle linux, après pour le reste à toi de voir.
Ah oui, ça s'arrête là. Il n'y a rien après.
La règle ... est-elle vraiment la première ?
Même mise en première place des règles NAT ça ne change rien.
Voici la partie NAT de iptables (le reste est inchangé) :
# DEBUT des règles pour le partage de connexion (i.e. le NAT)
# mise en place de l'interception des courriels par p3scan pour analyse
# par ClamAV et Spamassassin.
# Prise en compte des messages destinés au port POP3 (ie 110) et redirection
# vers p3scan sur le port 8110
#
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 110 --tcp-flags FIN,SYN,RST,ACK SYN -j LOG --log-prefix "PREROUTING port 110"
iptables -t nat -A PREROUTING -p tcp -m tcp --dport 110 --tcp-flags FIN,SYN,RST,ACK SYN -j REDIRECT --to-ports 8110
iptables -t nat -A OUTPUT -p tcp --dport pop3 -m owner --uid-owner 1004 -j ACCEPT
iptables -t nat -A OUTPUT -p tcp --dport pop3 -j REDIRECT --to 8110
# Activation du pontage NAT entre les cartes réseau.
echo 1 >/proc/sys/net/ipv4/ip_forward
# Décommentez la ligne suivante pour que le système fasse office de
# "serveur NAT".
iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
# Si la connexion que vous partagez est une connexion ADSL, vous
# serez probablement confronté au fameux problème du MTU. En résumé,
# le problème vient du fait que le MTU de la liaison entre votre
# fournisseur d'accès et le serveur NAT est un petit peu inférieur au
# MTU de la liaison Ethernet qui relie le serveur NAT aux machines qui
# sont derrière le NAT. Pour résoudre ce problème, décommentez la ligne
# suivante.
iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS -o eth1 --clamp-mss-to-pmtu
# FIN des règles pour le partage de connexion (i.e. le NAT)
Rien de nouveau dans mes recherches. J'avais aussi envisagé une histoire d'ordre des règles mais ça doit être plus subtil que ça. Je continue mes fouilles sur un super cours/tuto iptables qui me fasse tout comprendre.
A + si tu n'en n'as pas marre ;)
Michel
PS : je vais loguer mes règles de NAT pour avoir la meilleure traçabilité possible.
[^] # Re: en ayant lu
Posté par Sylvain Sauvage . Évalué à 2.
Sinon, pour un filtrage efficace et simple à gérer, j’ai déjà testé celui de Bastille : il te pose quelques questions et tu n’as plus qu’à ajouter tes règles de proxy transparent dans un fichier (dans /etc/Bastille/firewall.d/early.d p.ex.). Il a aussi l’avantage d’avoir été fait et testé par des gens qui s’y connaissent. Il s’occupe aussi d’autres problèmes de sécurité sur la machine.
[^] # Re: sans avoir tout lu...
Posté par michel44 . Évalué à 1.
Pourrais-tu préciser ce que tu veux dire par :
1°) mettre ton ubuntu en passerelle ou serveur email.
Le poste linux est la passerelle pour l'accès au net.
Pour le serveur de mail, Thunderbird d'un poste XP s'adresse à qui comme serveur de mail (ouais ça fait ignorance crasse mais je bidouille tout seul dans mon petit coin lol) ?
D'avance merci
A +
Michel
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.