Forum Linux.débutant p3scan : ce qu'il fait ou ne fait pas

Posté par  .
Étiquettes :
0
4
août
2007
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  . Évalué à 1.

    doc j'ai peut-etre sauté des etapes.

    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  . Évalué à 2.

      Package: p3scan
      [..]
      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  . Évalué à 1.

        Bonjour et merci de ta réponse.

        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  . Évalué à 2.

          Pour du proxy transparent pour des machines différentes de la passerelle, la règle à utiliser s’occupe du NAT en PREROUTING :
          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  . Évalué à 1.

            Bonjour Sylvain,
            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  . Évalué à 1.

            Ben non Sylvain ça fonctionne pas !
            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  . Évalué à 2.

              Si tu ne précises pas à ton client telnet le port de pop3 (110), celui-ci va utiliser le port par défaut de telnet, le port 23.

              => Précise le port 110 à ton client telnet.
              • [^] # Re: en ayant lu

                Posté par  . Évalué à 1.

                OUPS !
                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  . Évalué à 2.

                  J’avais pas vu que p3scan donnait déjà les règles sur OUTPUT en exemple. Je m’étais servi de règles similaires pour un test de contrôle parental (tinyproxy).

                  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  . Évalué à 1.

                    Oui mais rien que du classique :
                    - 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  . Évalué à 2.

                      Ah oui, suis-je bête :o)
                      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  . Évalué à 1.

                        Bonjour,
                        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  . Évalué à 2.

                          Pour le log : ce sont des infos sur le paquet lui-même, pas très intéressant si on ne connaît pas TCP/IP par c½ur. Le plus intéressant, c’est que ça permet de suivre les paquets : si ça logue, c’est que la règle correspondante doit être appliquée, sinon, c’est que c’est bloqué/passé ailleurs.

                          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  . Évalué à 1.

      Bonjour et merci de ta réponse.
      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.