[courier-users] Help with apparent relaying problem
Ken Sarkies
We have been using Courier-MTA for about 5-6 years and it has been rock
solid. We have lately experienced a few bizarre instances of mass
spam/physhing emailings that appear to be relayed through our
mailserver. Every day we experience attempts to relay which are solidly
blocked, so this is most surprising. We spent a great deal of time
trying to track down locally compromised computers without success.
Our setup is Fedora 10 (bare install) with Courier-MTA
(courier-0.60.0.20081102), and with the latest Clamav and
courier-pythonfilter-1.6. Our understanding is that relaying is enabled
only through smtpaccess policy files. We used the default supplied with
Courier and opened only the local subnets:
10 allow,RELAYCLIENT
192.168 allow,RELAYCLIENT
After the most recent event we turned off all relaying and now enforce
authentication for 192.168.0.0/16, but this probably won't help if the
originator is outside.
We also have a nogreylisting policy file listing some known
ill-configured servers, but these only have the allow,BLOCK attributes.
The evidence we see for relaying is in the logs. In the mail log file an
example is, immediately after a courier wakeup, the consecutive events
Dec 24 01:08:02 hta21 courierd: newmsg,id=00055639.4B322B44.000076CB:
dns; User (rrcs-24-105-132-156.nyc.biz.rr.com [::ffff:24.105.132.156])
Dec 24 01:08:02 hta21 courierd:
started,id=00055639.4B322B44.000076CB,from=<msgc...@wbhfcu.com>,module=esmtp,host=hotels.com,addr=<vwa...@hotels.com>
There were a number of following outgoing mails with the same id which
apparently derived from the original. In the (daylight saving ignorant)
router log
Dec 24 00:08:03 router Vigor: Virtual Server: 24.105.132.156:18623 ->
192.168.1.2:25 (TCP) SMTP
showing a definite connection to our mailserver from outside.
Is there any configuration mistake that we may have made that would
allow this (or are we reading the logs incorrectly)? We have worked
through the documentation many times over the years and cannot identify
any other setting that might open us up. Can anyone please provide
advice that may help us track this down. I won't dump all our
configuration to the list just yet, awaiting advice.
We are updating Courier to the latest version, although I don't remember
seeing any critical fixes since the version we have.
many thanks, Ken Sarkies
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
courier-users mailing list
courie...@lists.sourceforge.net
Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
Sam Varshavchik
> Dec 24 01:08:02 hta21 courierd: newmsg,id=00055639.4B322B44.000076CB:
> dns; User (rrcs-24-105-132-156.nyc.biz.rr.com [::ffff:24.105.132.156])
> Dec 24 01:08:02 hta21 courierd:
> started,id=00055639.4B322B44.000076CB,from=<msgc...@wbhfcu.com>,module=esmtp,host=hotels.com,addr=<vwa...@hotels.com>
>
> There were a number of following outgoing mails with the same id which
> apparently derived from the original. In the (daylight saving ignorant)
> router log
>
> Dec 24 00:08:03 router Vigor: Virtual Server: 24.105.132.156:18623 ->
> 192.168.1.2:25 (TCP) SMTP
>
> showing a definite connection to our mailserver from outside.
>
> Is there any configuration mistake that we may have made that would
> allow this (or are we reading the logs incorrectly)? We have worked
> through the documentation many times over the years and cannot identify
> any other setting that might open us up. Can anyone please provide
> advice that may help us track this down. I won't dump all our
> configuration to the list just yet, awaiting advice.
>
> We are updating Courier to the latest version, although I don't remember
> seeing any critical fixes since the version we have.
One of your users probably has his PC hacked, and it's being used to spew
spam. From your standpoint, your user validly authenticated through your
mail server, and is sending authenticated mail.
The information needed to identify your user can be pulled from the log
files. In your older version, the authentication information was not readily
available. It had to be dug up with a bit of effort. In the newer version
the authentication logs needed to identify the userid is a little easier to
find. In the new version, the authentication information gets recorded
directly in syslog.
Ken Sarkies
> One of your users probably has his PC hacked, and it's being used to
> spew spam. From your standpoint, your user validly authenticated
> through your mail server, and is sending authenticated mail.
>
Thanks Sam.
Just as a follow up, we think we've found the problem. We had ESMTPAUTH
enabled in the Courier esmptd configuration file. This allows
authenticated relaying through the server. Someone outside had
presumably managed to obtain authentication information to allow them
access (yes, at least one of our users had a weak password). We have
enabled some more logging, but we have to close it off for security so
we may never find out.
A solution to allow internal subnet relaying seems to be to put
ESMTPAUTH into the smtpaccess files. This isn't documented, but I gather
a whole range of environment variables can be enabled for specific
address ranges in these files. Anyway it seems to work so far.
cheers, Ken
> Ken Sarkies writes:
>
>> Dec 24 01:08:02 hta21 courierd: newmsg,id=00055639.4B322B44.000076CB:
>> dns; User (rrcs-24-105-132-156.nyc.biz.rr.com [::ffff:24.105.132.156])
>> Dec 24 01:08:02 hta21 courierd:
>> started,id=00055639.4B322B44.000076CB,from=<msgc...@wbhfcu.com>,module=esmtp,host=hotels.com,addr=<vwa...@hotels.com>
>>
>>
>> There were a number of following outgoing mails with the same id
>> which apparently derived from the original. In the (daylight saving
>> ignorant) router log
>>
>> Dec 24 00:08:03 router Vigor: Virtual Server: 24.105.132.156:18623 ->
>> 192.168.1.2:25 (TCP) SMTP
>>
>> showing a definite connection to our mailserver from outside.
>>
>> Is there any configuration mistake that we may have made that would
>> allow this (or are we reading the logs incorrectly)? We have worked
>> through the documentation many times over the years and cannot
>> identify any other setting that might open us up. Can anyone please
>> provide advice that may help us track this down. I won't dump all our
>> configuration to the list just yet, awaiting advice.
>>
>> We are updating Courier to the latest version, although I don't
>> remember seeing any critical fixes since the version we have.
>
------------------------------------------------------------------------------