Could you please share your script for detecting failed massages with us? It sounds like a good stop-gap treatment for this insidious issue.
>________________________________ > From: Dan McAllister <[email protected]> >To: [email protected] >Sent: Sunday, February 16, 2014 12:33 PM >Subject: Re: [qmailtoaster] Re: Spamming via valid vpopmail account > > >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 > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [email protected] >For additional commands, e-mail: [email protected] > > > >
