On 02/16/2014 11:33 AM, Dan McAllister wrote:
Wicus' issues are not uncommon:
An "attacker" gains a password (through guesswork or other means) of a
user on your system, then proceeds to spam the hell out of the world
from your system.
Alternatively, some user gets a malware infection on their system that
uses their mail program (usually Outlook) to spam the hell out of the
world from your system.
So how can you head it off?
I am in the finishing stages of writing a script that, if I am not
mistaken, will be obsoleted rather quickly.
This script is designed to look through the send log file and
essentially build a "message log" for each message:
- who its from
- who its addressed to
- results of each send
- when it is done (final act of removing it from the queue)
The "sticky wicket" in this is that qmail uses the inode number of the
message body in the queue as the tracking ID, thus the same numbers
appear over and over. This is what breaks all other attempts to do this
that I have encountered, and this is the biggest stumbling block that I
can see so far.
I hope to have this completed in the coming week or 2.
How this applies, it that I already have a script that attempts (albeit
with many instances missed currently) to count the number of failed
messages from any single user in any given day. When that number reaches
50, I automatically change the password on the user account (thus,
stopping their authentication) until I can investigate further.
So that will help with DETECTION -- what about deterrence?
Well, for one -- and I've talked about this before -- you can stop
allowing users to AUTHENTICATE on port 25. Port 25 SHOULD be used SOLELY
for inbound messages to your hosted (or relayed) domains. Thus, when you
ran your telnet attempt and used a destination of a gmail address, your
server should have (and did) refused the message.
The problem is that we enable authentication on port 25 because we seem
to think we should be running the same code for submission (port 587)
and smtp-ssl (port 465). IMHO, THOSE ports should be the OPPOSITE of
port 25:
- Port 25 should allow anonymous connections (non authenticated)...
ports 587 and 465 should not
- Port 25 should NOT accept messages for non-local domains... ports
587 and 465 must
- Port 25 must not require SSL or AUTH; ports 587 and 465 SHOULD (or,
as I prefer -- allow it on 587, require it on 465).
This STOPS spammers from connecting on your port 25 interface and
sending all kinds of messages through an authenticated "work around". Of
course, it doesn't stop the same hacker from just switching to ports 587
or 465... but I haven't seen them use those ports YET.
Just my thoughts....
Dan McAllister
IT4SOHO
Dan McAllister
---------------------------------------------------------------------
The only issue I have with this is that port 25 should allow for TLS and
use it when it's requested, allowing email from external domains to be
received on an encrypted connection. This is how QMT presently operates.
This also happens on outgoing emails (qmail-remote uses TLS if it's
offered). As you can see on the spamdyke messages in the smtp logs,
quite a few servers do use TLS.
Note, spamdyke does not presently have a setting which requires that
passwords be sent encrypted (like dovecot does), but that feature has
been requested and might be in the next release.
--
-Eric 'shubes'
---------------------------------------------------------------------
To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com
For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
