On 11/24/06, Jon Smith <[EMAIL PROTECTED]> wrote:

On 11/24/06, Jon Smith <[EMAIL PROTECTED]> wrote:
>
> On 11/24/06, Jon Smith <[EMAIL PROTECTED] > wrote:
> >
> > On 11/24/06, Tomasz Papszun <[EMAIL PROTECTED] > wrote:
> > >
> > > On Fri, 24 Nov 2006 at 13:34:37 -0600, Jon Smith wrote:
> > > > On 11/24/06, Jon Smith <[EMAIL PROTECTED] > wrote:
> > > [...]
> > > > So, apparently it's just not tagging the messages?  I'm going to
> > > man
> > > > clamav-milter conf to see if maybe I just forgot to enable the
> > > addition of
> > > > the X-Spam-Status tags?
> > >
> > > Sorry if I've missed some detail but why not just send a test
> > > message
> > > containing EICAR test "virus" and see whether the system stops it or
> > >
> > > not?
> > >
> >
> > That's what I'm doing right now, Thanks Tomasz :)
> >
> > Still wondering a) why isn't it writing anything to my clamd.milterlog file 
and b) why isn't it tagging messages as clean in the header?
> >
>
>
> I changed my milter.conf to scan Archives, and restarted clamav-milter.
>
> Then I tested it with the EICAR signature, and the mail went through
> without clamav saying a word.  From the maillog:
>
> Nov 24 14:26:28 <hostname> sendmail[18996]: kAOKQSta018996: from=root,
> size=653, class=0, nrcpts=1, 
msgid=<20061124202628.GA18990@<hostname>..<domain>>,
> [EMAIL PROTECTED]
> Nov 24 14:26:28 <hostname> sendmail[18997]: NOQUEUE: connect from
> <hostname>..<domain> [ 127.0.0.1]
> Nov 24 14:26:28 <hostname> sendmail[18997]: AUTH: available mech=PLAIN
> LOGIN ANONYMOUS, allowed mech=EXTERNAL GSSAPI KERBEROS_V4 DIGEST-MD5
> CRAM-MD5
> Nov 24 14:26:28 <hostname> sendmail[18997]: kAOKQSHo018997: Milter
> (Clamav): init success to negotiate
> Nov 24 14:26:28 <hostname> sendmail[18997]: kAOKQSHo018997: Milter:
> connect to filters
> Nov 24 14:26:28 <hostname> sendmail[18997]: kAOKQSHo018997:
> milter=Clamav, action=connect, accepted
> Nov 24 14:26:28 <hostname> sendmail[18997]: kAOKQSHo018997:
> from=<root@<hostname>..<domain>>, size=832, class=0, nrcpts=1, msgid=<
> 20061124202628.GA18990@<hostname>..<domain>>, proto=ESMTP, daemon=MTA,
> relay=<hostname>..<domain> [ 127.0.0.1]
> Nov 24 14:26:28 <hostname> sendmail[18997]: kAOKQSHo018997: Milter
> accept: message
> Nov 24 14:26:28 <hostname> sendmail[18996]: kAOKQSta018996:
> to=<user>@<hostname>..<domain>, ctladdr=root (0/0), delay=00:00:00,
> xdelay=00:00:00, mailer=relay, pri=30653, relay=[ 127.0.0.1] [127.0.0.1],
> dsn=2.0.0, stat=Sent (kAOKQSHo018997 Message accepted for delivery)
> Nov 24 14:26:28 <hostname> sendmail[18999]: kAOKQSHo018997:
> to=<<user>@<hostname>..<domain>>, ctladdr=<root@<hostname>..<domain>> (0/0),
> delay=00:00:00, xdelay=00:00:00, mailer=local, pri=31096, dsn= 2.0.0,
> stat=Sent
> Nov 24 14:26:28 <hostname> sendmail[18999]: kAOKQSHo018997: done;
> delay=00:00:00, ntries=1
>
> But, if I clamdscan the attached file:
> [root@<hostname> ~]# clamdscan --config-file=/etc/clamd.d/srv.conf
> /tmp/eicarcom2.zip
> /tmp/eicarcom2.zip: Eicar-Test-Signature FOUND
>
> ----------- SCAN SUMMARY -----------
> Infected files: 1
> Time: 0.000 sec (0 m 0 s)
>
> I'm a little lost here.  The message was obviously passed to the milter
> ... which accepted it, and never detected the virus.  To send this I just
> used mutt to write a quick message to another local user and attached the
> eicarcom2.zip (yes I'm scanning up to 9 levels of archive depth, 15mb
> limit, no reason this shouldn't have been scanned).
>
> Anyone have any ideas?  I'm about to the point where I'm ready to just
> start digging through the clamav-milter source and see what in the world is
> going on.
>


So I just downloaded the source and compiled it with --enable-milter and
--enable-debug, and I'm seeing something interesting in my clamd.milterlog now. 
 Basically the instant I connect to the SMTP service I get the
following:

[-1232434288] got cmd 'O' len 12
[-1232434288] cur 0 new 1 nextmask 2
[-1232434288] got cmd 'D' len 124
[-1232434288] cur 1 new ffffffff nextmask 2004
[-1232434288] got cmd 'C' len 25
[-1232434288] cur 1 new 2 nextmask 2004
LibClamAV debug: clamfi_connect: not scanning local messages
[-1232434288] got cmd 'Q' len 0
[-1232434288] cur 3 new b nextmask 2018
[-1232434288] abort: cur 3 (8) new 11 (800) next 2018
LibClamAV debug: clamfi_close

and from the maillog:
Nov 24 15:59:37 <hostname> clamav-milter[20301]: clamfi_connect: not
scanning local messages

It appears to be totally relying on the ip address of the client.

From clamav-milter.c (some debug macros removed):

        if((!lflag) && isLocalAddr(inet_addr(remoteIP))) {
                if(use_syslog)
                        syslog(LOG_DEBUG, _("clamfi_connect: not scanning
local messages"));
                cli_dbgmsg(_("clamfi_connect: not scanning local
messages\n"));
                return SMFIS_ACCEPT;
        }

But, I'm not relaying these messages locally.  Not from localhost and
they're not destined to localhost.  I'm telnet'ing to the smtp service on
the mail server and manually relaying these messages, which then get sent
(via a mailerable entry) to another mail exchanger.  What I can't figure out
is how is it that clamav-milter is determining that an address that's not in
the same subnet, not even in the same (what would be) classful Class A
network, is a local address, and not scanning it?  We're talking about a
server with an IP address in the 172.16.3.X subnet and my PC deep in a
10.X.X.X/24 subnet.




Ok, sorry I keep replying to myself but I got it straightened out.  After
switching lflag to 1 and still having the same problem, I found this in
clamav-milter.c:

       if(strncasecmp(port, "inet:", 5) == 0)
               if(!lflag) {
                       /*
                        * Barmy but true. It seems that clamfi_connect
will,
                        * in this case, get the IP address of the machine
                        * running sendmail, not of the machine sending the
                        * mail, so the remote end will be a local address
so
                        * we must scan by enabling --local
                        *
                        * TODO: this is probably not needed if the remote
                        * machine is localhost, need to check though
                        */
                       fprintf(stderr, _("%s: when using inet: connection
to sendmail you must enable --local\n"), argv[0]);
                       return EX_USAGE;
               }

So I tried the --local flag and voila, works perfectly fine now.

Can anyone explain to me what the deal is with the "inet:" ?  I'm using a
socket between sendmail and clamav-milter, so that can't be what they mean
by inet?  I'm just trying to figure out why clamav-milter grabbed the
address of the machine running sendmail instead of the client connecting.

Thanks for everyone's help, hopefully this may help someone else in the
future.
_______________________________________________
Help us build a comprehensive ClamAV guide: visit http://wiki.clamav.net
http://lurker.clamav.net/list/clamav-users.html

Reply via email to