RE: [qmailtoaster] Re: Spamming via valid vpopmail account
Quick update on this scenario. The user's email account that got compromised has been in the hospital for the last two weeks for a back operation. His account is only configured on his desktop machine of which the machine has not been switched on. A thorough malware/virus scan on all machines within the network is currently be performed. Will advise should we pick up anything. -Original Message- From: Eric Shubert [mailto:e...@shubes.net] Sent: 17 February 2014 04:50 AM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Re: Spamming via valid vpopmail account On 02/16/2014 02:59 PM, Dan McAllister wrote: > Again, the CORRECT use of port 25 is SOLELY for the receipt of inbound > messages for the local server. Users (who authenticate) should be > using ports 587 or 465 -- which, after they authenticate, will allow > them to relay to other servers. I agree with this. Although it technically goes against RFCs, RFCs don't always represent best practices. QMT will have support for port 465 in its stock configuration at some point. I won't say exactly when (probably COS7), but it will happen. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
RE: [qmailtoaster] Re: Spamming via valid vpopmail account
"Open Relay" was one of the first things I double checked. So, for inbound mail, qmail only checks whether the user is "available" on the system (chkuser) before accepting the mail. (UNAUTHENTICATED) However, for outbound mail (being a domain not hosted on the machine), authentication of the user is required. Therefore, my confusion relates to using Telnet, whereby no authentication is implemented prior to sending the test message? Therefore, as mentioned earlier, the only other logical conclusion is a compromised email account's password. -Original Message-rcp From: Dan McAllister [mailto:q...@it4soho.com] Sent: 17 February 2014 12:00 AM To: qmailtoaster-list@qmailtoaster.com Subject: Re: [qmailtoaster] Re: Spamming via valid vpopmail account Wicus - On port 25 CURRENTLY: - If the connection is for a LOCAL address (that is: the RECIPIENT address is one that is local to the server), the message is accepted -- regardless of whether you are authenticated or not - If the connection is for a REMOTE address (that is: the RECIPIENT address is one that is NOT local to the server), the messages is accepted ONLY IF the user is authenticated. Again, the CORRECT use of port 25 is SOLELY for the receipt of inbound messages for the local server. Users (who authenticate) should be using ports 587 or 465 -- which, after they authenticate, will allow them to relay to other servers. Now here's a kicker -- if you authenticate to the QMail SMTP server (with ANY credentials that work!) you can send as any user to any user. Once you're AUTHENTICATED, you're free to send from anyone TO anyone. This is because the AUTH mechanism is separate from the SMTP mechanism -- and to my knowledge, there is no way to fix this in QMail (maybe with spamdyke? I don't know). Now, if your server accepts UNAUTHENTICATED clients, and forwards to domains that are NOT LOCAL to you, then you are what is referred to as an "OPEN RELAY" -- you've made a mistake that will get you blacklisted within 24-48 hours, for sure! :) I hope this answers your question Wicus... Dan IT4SOHO On 2/16/2014 3:07 PM, Wicus Roets wrote: > Eric, > > This is where I'm confused. If qmail accepts mail for relay based on > authentication of a valid account/pw pair, how could I have send mail > via telnet on port 25 by only supplying a valid account (without a password)? > > -Original Message- > From: Eric Shubert [mailto:e...@shubes.net] > Sent: 16 February 2014 09:56 PM > To: qmailtoaster-list@qmailtoaster.com > Subject: [qmailtoaster] Re: Spamming via valid vpopmail account > > On 02/16/2014 11:32 AM, Wicus Roets wrote: >> That explains is quite nicely. >> >> One more question though ;) >> >> Quoting from "http://gmane.org/post.php"; - " People who do not have >> valid email addresses in their From or Reply-To headers can't use >> Gmane to post to mailing lists." > That's (primarily) because gmane doesn't have accounts with passwords. > It uses the From/Reply-To to verify that an address exists, when the > first message from an account is sent to the list. This is akin to > adding an account. > >> From my earlier mail, qmail accepts mail based only on the "rcpt to:" >> of the header. As an interim, would inclusion of verification on the >> "mail > from:" >> be easier/quicker ? > I'm not sure what you mean by this. qmail accepts mail (for relay) > based on authentication (valid account/pw pair). > > I don't think that verifying the "mail from" is always practical, but > I know that SamC is considering adding some such capability to > spamdyke. I think we should wait and see what he comes up with for > that. QMT doesn't presently use spamdyke on port 587, but it soon > will. spamdyke v5.0 was just released, and once it's deemed stable (by > me), QMT will use it to handle authentication (on port 587). > > -- > -Eric 'shubes' > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: > qmailtoaster-list-h...@qmailtoaster.com > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Spamming via valid vpopmail account
I have every intention of sharing both the message tracking system AND the failure detection scripts once I've completed (to a certain degree) debugging them. Dan IT4SOHO On 2/16/2014 2:04 PM, LHTek wrote: 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 *To:* qmailtoaster-list@qmailtoaster.com *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: qmailtoaster-list-unsubscr...@qmailtoaster.com <mailto:qmailtoaster-list-unsubscr...@qmailtoaster.com> For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com <mailto:qmailtoaster-list-h...@qmailtoaster.com>
Re: [qmailtoaster] Re: Spamming via valid vpopmail account
Wicus - On port 25 CURRENTLY: - If the connection is for a LOCAL address (that is: the RECIPIENT address is one that is local to the server), the message is accepted -- regardless of whether you are authenticated or not - If the connection is for a REMOTE address (that is: the RECIPIENT address is one that is NOT local to the server), the messages is accepted ONLY IF the user is authenticated. Again, the CORRECT use of port 25 is SOLELY for the receipt of inbound messages for the local server. Users (who authenticate) should be using ports 587 or 465 -- which, after they authenticate, will allow them to relay to other servers. Now here's a kicker -- if you authenticate to the QMail SMTP server (with ANY credentials that work!) you can send as any user to any user. Once you're AUTHENTICATED, you're free to send from anyone TO anyone. This is because the AUTH mechanism is separate from the SMTP mechanism -- and to my knowledge, there is no way to fix this in QMail (maybe with spamdyke? I don't know). Now, if your server accepts UNAUTHENTICATED clients, and forwards to domains that are NOT LOCAL to you, then you are what is referred to as an "OPEN RELAY" -- you've made a mistake that will get you blacklisted within 24-48 hours, for sure! :) I hope this answers your question Wicus... Dan IT4SOHO On 2/16/2014 3:07 PM, Wicus Roets wrote: Eric, This is where I'm confused. If qmail accepts mail for relay based on authentication of a valid account/pw pair, how could I have send mail via telnet on port 25 by only supplying a valid account (without a password)? -Original Message- From: Eric Shubert [mailto:e...@shubes.net] Sent: 16 February 2014 09:56 PM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Re: Spamming via valid vpopmail account On 02/16/2014 11:32 AM, Wicus Roets wrote: That explains is quite nicely. One more question though ;) Quoting from "http://gmane.org/post.php"; - " People who do not have valid email addresses in their From or Reply-To headers can't use Gmane to post to mailing lists." That's (primarily) because gmane doesn't have accounts with passwords. It uses the From/Reply-To to verify that an address exists, when the first message from an account is sent to the list. This is akin to adding an account. From my earlier mail, qmail accepts mail based only on the "rcpt to:" of the header. As an interim, would inclusion of verification on the "mail from:" be easier/quicker ? I'm not sure what you mean by this. qmail accepts mail (for relay) based on authentication (valid account/pw pair). I don't think that verifying the "mail from" is always practical, but I know that SamC is considering adding some such capability to spamdyke. I think we should wait and see what he comes up with for that. QMT doesn't presently use spamdyke on port 587, but it soon will. spamdyke v5.0 was just released, and once it's deemed stable (by me), QMT will use it to handle authentication (on port 587). -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Spamming via valid vpopmail account
Hi Eric. You can have Fail2ban check Your logs for bad entries that happens within a given period of time and then ban the IP address (Ip tables). Let Fail2ban check on the LAN ip address that is submitting the email in the submit log and then take action when Your tresholds are triggered - maybe not ban the ip adress (LAN) - send an email to sysadmin or lift the ban after 10 min. Regards, Finn Den 16-02-2014 21:03, Eric Shubert skrev: I don't see how fail2ban would be of any help with this. Can you elaborate? - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
RE: [qmailtoaster] Re: Spamming via valid vpopmail account
Eric, This is where I'm confused. If qmail accepts mail for relay based on authentication of a valid account/pw pair, how could I have send mail via telnet on port 25 by only supplying a valid account (without a password)? -Original Message- From: Eric Shubert [mailto:e...@shubes.net] Sent: 16 February 2014 09:56 PM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Re: Spamming via valid vpopmail account On 02/16/2014 11:32 AM, Wicus Roets wrote: > That explains is quite nicely. > > One more question though ;) > > Quoting from "http://gmane.org/post.php"; - " People who do not have > valid email addresses in their From or Reply-To headers can't use > Gmane to post to mailing lists." That's (primarily) because gmane doesn't have accounts with passwords. It uses the From/Reply-To to verify that an address exists, when the first message from an account is sent to the list. This is akin to adding an account. > From my earlier mail, qmail accepts mail based only on the "rcpt to:" > of the header. As an interim, would inclusion of verification on the "mail from:" > be easier/quicker ? I'm not sure what you mean by this. qmail accepts mail (for relay) based on authentication (valid account/pw pair). I don't think that verifying the "mail from" is always practical, but I know that SamC is considering adding some such capability to spamdyke. I think we should wait and see what he comes up with for that. QMT doesn't presently use spamdyke on port 587, but it soon will. spamdyke v5.0 was just released, and once it's deemed stable (by me), QMT will use it to handle authentication (on port 587). -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Spamming via valid vpopmail account
Hi. Wouldn't it be possible to block port 25 outgoing and let fail2ban check submission logs ? Regards, Finn Den 16-02-2014 19:33, Dan McAllister skrev: 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: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Spamming via valid vpopmail account
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 >To: qmailtoaster-list@qmailtoaster.com >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: qmailtoaster-list-unsubscr...@qmailtoaster.com >For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > > >
RE: [qmailtoaster] Re: Spamming via valid vpopmail account
Dan, By default (and I'm not currently aware of any other situation warranting it differently) users' mail clients are configured to POP3 on port 110 IMAP on port 143 SMTP on port 587 Since the incidents, I've configured SSL for POP3 (993), IMAP(995) and SMTP(465). However, my understanding currently is that we cannot do away with port 25, as this is how our system receives mail from the outside world ... Thereby allowing our spammer to do as he wishes ... Thus, how would I prevent usage of port 25 to foreign mail servers only? -Original Message- From: Dan McAllister [mailto:q...@it4soho.com] Sent: 16 February 2014 08:33 PM To: qmailtoaster-list@qmailtoaster.com 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: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
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: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
RE: [qmailtoaster] Re: Spamming via valid vpopmail account
That explains is quite nicely. One more question though ;) Quoting from "http://gmane.org/post.php"; - " People who do not have valid email addresses in their From or Reply-To headers can't use Gmane to post to mailing lists." >From my earlier mail, qmail accepts mail based only on the "rcpt to:" of the header. As an interim, would inclusion of verification on the "mail from:" be easier/quicker ? Thanks -Original Message- From: Eric Shubert [mailto:e...@shubes.net] Sent: 16 February 2014 08:14 PM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Re: Spamming via valid vpopmail account On 02/16/2014 10:20 AM, Wicus Roets wrote: > In favour of myself and some else referring to this mail list in > future, would you mind elaborating on qmail-remote throttling? (until > the "offending/spamming user" feature gets implemented) Presently, qmail-remote has no throttle other than the concurrencyremote setting, which simply limits the number of external connections that can happen at once. In the event that a spammer (or perhaps even a legitimate user) submits a boatload of messages, qmail-remote dutifully processes messages as quickly as it possibly can (given the concurrencyremote constraint). I think everyone would agree that qmail-remote is not well behaved when this occurs. The idea of a throttle for qmail-remote came to me from gmane.org, the list to news gateway (which I use and highly recommend). http://gmane.org/post.php says: 4. No more than one message is sent per user per five minutes. If you post more than one message per five minutes, the messages are spooled and sent out later. No action is required from you. IMO, this is brilliant. While it doesn't block spam entirely, it prohibits a spam flood, while providing the ability to automatically detect an "event" and take corrective action. The qmail-remote throttle I have written a spec for would simply have a rate limit, being the number of seconds required to elapse between sending out messages from the same account. qmail-remote would keep track of the when the last message was sent for each account, and would only send the next message from each account after the rate limit has been reached (as gmane.org presently does). The rate limit would be specified by host, domain, and/or user account. It could also be unlimited (as things are now). Once the qmail-remote throttle is in place, it'd be a relatively simple matter (for some of us) to write a script which would detect an event, block the account, and clean up the queue. The key (and more complicated) part of all this is the patch for qmail-remote though, which would need to be written in C. I could do this, but it would take some doing (it's been a while since I've written much C code). So there you have it. Questions? -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
Re: [qmailtoaster] Re: Spamming via valid vpopmail account
If someone has hacked a vpopmail account password and is using it to spam, you can check the send, smtp, or submission logs and it will expose the account. I did have this problem in the past. It may very well be a PC in your network with malware on it. Eric B. On 2/16/2014 10:20 AM, Wicus Roets wrote: > I do understand that qmail is not the reason the IP is being blacklisted. > > In favour of myself and some else referring to this mail list in future, > would you mind elaborating on qmail-remote throttling? (until the > "offending/spamming user" feature gets implemented) > > -Original Message- > From: Eric Shubert [mailto:e...@shubes.net] > Sent: 16 February 2014 07:03 PM > To: qmailtoaster-list@qmailtoaster.com > Subject: [qmailtoaster] Re: Spamming via valid vpopmail account > > On 02/16/2014 09:27 AM, Wicus Roets wrote: >> Thanks Eric. >> >> Steps I took upon noticing: >> >> 1.) qmailctl stop >> 2.)qmHandle -S"YOUR BLAH BLAH..." >> 3.) Reviewed bounce messages and deleted them with qmHandle upon review >> qmail-qstat >> qmail-qread >> qmHandle -mxxx quick check on mail message as listed with >> qmail-qread >> qmHandle -dxxx deletes relevant message >> 4.) Changed user's password >> 5.) qmailctl start > I'd do #4 first, but given that qmail is stopped I suppose it doesn't really > matter. > >> It's been under control for the last 6 hours ... > Crossing fingers... > >> Exactly the same scenario played out on Thursday. > Hmmm. Makes one wonder how PW was compromised. I haven't actually heard of > such a thing, but it wouldn't be impossible for some malware to send > credentials to a spammer somewhere. If this happens again for the same > user's account, I'd keep their ability to submit disabled until they've > cleaned their computer of malware (or preferrably obtained a clean > computer). Don't forget to change that password once again after they've got > their computer cleaned up. > >> I'm pondering a script or option to recompile, whereby a specific >> user's account will be disabled (be it via vmoduser) when >> "sender_was_rejected" or related messages is received from an external >> mail server, rather than blocking the static public IP of the entire box. > Keep in mind, the blocking of your static public IP address is something > that you don't have direct control of. IOW, QMT isn't doing that blocking. > > The problem here is that account credentials are sometimes compromised. > Having things set up so passwords are never sent in clear text is something > that should always be done. However, this problem will always be present to > some extent, as there is always the human factor. Bottom line, passwords > will occasionally fall into the hands of spammers. > > I'm convinced that the best solution to this problem is to have a throttle > on qmail-remote which limits the rate at which emails are sent. > This would likely keep QMT's IP from being blacklisted, as spam would be > queued up, but would not flood any recipients. It'd be relatively easy to > detect when this happens (queue has a lot of messages over a period of > time), and the offending account could have submission rights suspended > automatically. It'd also be relatively easy to script a process which cleans > the queue before all the messages (eventually) are sent out. > > I've written some specs for such a feature, but haven't begun writing it > yet. If some of you would like to sponsor work on this, it could be > developed in short order. If anyone's interested in sponsoring this > development so that it happens sooner than later, please contact me off list > and we'll see what we can do. > >> Though I can help myself quite well around a console, scripting at >> present is slightly out of my reach ... >> > Your help is none the less appreciated. > Thanks Wicus. > > -- > -Eric 'shubes' > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > > > > - > To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com > For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
RE: [qmailtoaster] Re: Spamming via valid vpopmail account
As mine is set to 60 for concurrencyremote and 100 for concurrencyincoming. What would you advise ? -Original Message- From: Wicus Roets [mailto:wi...@r4c.co.za] Sent: 16 February 2014 07:21 PM To: qmailtoaster-list@qmailtoaster.com Subject: RE: [qmailtoaster] Re: Spamming via valid vpopmail account I do understand that qmail is not the reason the IP is being blacklisted. In favour of myself and some else referring to this mail list in future, would you mind elaborating on qmail-remote throttling? (until the "offending/spamming user" feature gets implemented) -Original Message- From: Eric Shubert [mailto:e...@shubes.net] Sent: 16 February 2014 07:03 PM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Re: Spamming via valid vpopmail account On 02/16/2014 09:27 AM, Wicus Roets wrote: > Thanks Eric. > > Steps I took upon noticing: > > 1.) qmailctl stop > 2.)qmHandle -S"YOUR BLAH BLAH..." > 3.) Reviewed bounce messages and deleted them with qmHandle upon review > qmail-qstat > qmail-qread > qmHandle -mxxx quick check on mail message as listed with > qmail-qread > qmHandle -dxxx deletes relevant message > 4.) Changed user's password > 5.) qmailctl start I'd do #4 first, but given that qmail is stopped I suppose it doesn't really matter. > It's been under control for the last 6 hours ... Crossing fingers... > Exactly the same scenario played out on Thursday. Hmmm. Makes one wonder how PW was compromised. I haven't actually heard of such a thing, but it wouldn't be impossible for some malware to send credentials to a spammer somewhere. If this happens again for the same user's account, I'd keep their ability to submit disabled until they've cleaned their computer of malware (or preferrably obtained a clean computer). Don't forget to change that password once again after they've got their computer cleaned up. > I'm pondering a script or option to recompile, whereby a specific > user's account will be disabled (be it via vmoduser) when > "sender_was_rejected" or related messages is received from an external > mail server, rather than blocking the static public IP of the entire box. Keep in mind, the blocking of your static public IP address is something that you don't have direct control of. IOW, QMT isn't doing that blocking. The problem here is that account credentials are sometimes compromised. Having things set up so passwords are never sent in clear text is something that should always be done. However, this problem will always be present to some extent, as there is always the human factor. Bottom line, passwords will occasionally fall into the hands of spammers. I'm convinced that the best solution to this problem is to have a throttle on qmail-remote which limits the rate at which emails are sent. This would likely keep QMT's IP from being blacklisted, as spam would be queued up, but would not flood any recipients. It'd be relatively easy to detect when this happens (queue has a lot of messages over a period of time), and the offending account could have submission rights suspended automatically. It'd also be relatively easy to script a process which cleans the queue before all the messages (eventually) are sent out. I've written some specs for such a feature, but haven't begun writing it yet. If some of you would like to sponsor work on this, it could be developed in short order. If anyone's interested in sponsoring this development so that it happens sooner than later, please contact me off list and we'll see what we can do. > Though I can help myself quite well around a console, scripting at > present is slightly out of my reach ... > Your help is none the less appreciated. Thanks Wicus. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
RE: [qmailtoaster] Re: Spamming via valid vpopmail account
I do understand that qmail is not the reason the IP is being blacklisted. In favour of myself and some else referring to this mail list in future, would you mind elaborating on qmail-remote throttling? (until the "offending/spamming user" feature gets implemented) -Original Message- From: Eric Shubert [mailto:e...@shubes.net] Sent: 16 February 2014 07:03 PM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Re: Spamming via valid vpopmail account On 02/16/2014 09:27 AM, Wicus Roets wrote: > Thanks Eric. > > Steps I took upon noticing: > > 1.) qmailctl stop > 2.)qmHandle -S"YOUR BLAH BLAH..." > 3.) Reviewed bounce messages and deleted them with qmHandle upon review > qmail-qstat > qmail-qread > qmHandle -mxxx quick check on mail message as listed with > qmail-qread > qmHandle -dxxx deletes relevant message > 4.) Changed user's password > 5.) qmailctl start I'd do #4 first, but given that qmail is stopped I suppose it doesn't really matter. > It's been under control for the last 6 hours ... Crossing fingers... > Exactly the same scenario played out on Thursday. Hmmm. Makes one wonder how PW was compromised. I haven't actually heard of such a thing, but it wouldn't be impossible for some malware to send credentials to a spammer somewhere. If this happens again for the same user's account, I'd keep their ability to submit disabled until they've cleaned their computer of malware (or preferrably obtained a clean computer). Don't forget to change that password once again after they've got their computer cleaned up. > I'm pondering a script or option to recompile, whereby a specific > user's account will be disabled (be it via vmoduser) when > "sender_was_rejected" or related messages is received from an external > mail server, rather than blocking the static public IP of the entire box. Keep in mind, the blocking of your static public IP address is something that you don't have direct control of. IOW, QMT isn't doing that blocking. The problem here is that account credentials are sometimes compromised. Having things set up so passwords are never sent in clear text is something that should always be done. However, this problem will always be present to some extent, as there is always the human factor. Bottom line, passwords will occasionally fall into the hands of spammers. I'm convinced that the best solution to this problem is to have a throttle on qmail-remote which limits the rate at which emails are sent. This would likely keep QMT's IP from being blacklisted, as spam would be queued up, but would not flood any recipients. It'd be relatively easy to detect when this happens (queue has a lot of messages over a period of time), and the offending account could have submission rights suspended automatically. It'd also be relatively easy to script a process which cleans the queue before all the messages (eventually) are sent out. I've written some specs for such a feature, but haven't begun writing it yet. If some of you would like to sponsor work on this, it could be developed in short order. If anyone's interested in sponsoring this development so that it happens sooner than later, please contact me off list and we'll see what we can do. > Though I can help myself quite well around a console, scripting at > present is slightly out of my reach ... > Your help is none the less appreciated. Thanks Wicus. -- -Eric 'shubes' - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaster.com
RE: [qmailtoaster] Re: Spamming via valid vpopmail account
Thanks Eric. Steps I took upon noticing: 1.) qmailctl stop 2.)qmHandle -S"YOUR BLAH BLAH..." 3.) Reviewed bounce messages and deleted them with qmHandle upon review qmail-qstat qmail-qread qmHandle -mxxx quick check on mail message as listed with qmail-qread qmHandle -dxxx deletes relevant message 4.) Changed user's password 5.) qmailctl start It's been under control for the last 6 hours ... Exactly the same scenario played out on Thursday. I'm pondering a script or option to recompile, whereby a specific user's account will be disabled (be it via vmoduser) when "sender_was_rejected" or related messages is received from an external mail server, rather than blocking the static public IP of the entire box. Though I can help myself quite well around a console, scripting at present is slightly out of my reach ... -Original Message- From: Eric Shubert [mailto:e...@shubes.net] Sent: 16 February 2014 06:11 PM To: qmailtoaster-list@qmailtoaster.com Subject: [qmailtoaster] Re: Spamming via valid vpopmail account There are bit flags associated with each user account which can be set with the /home/vpopmail/bin/vmoduser command. There is no other (gui) way I know of to set these flags. # ./vmoduser vmoduser: usage: [options] email_addr or domain (for each user in domain) options: -v ( display the vpopmail version number ) -n ( don't rebuild the vpasswd.cdb file ) -q quota ( set quota ) -c comment (set the comment/gecos field ) -e encrypted_passwd (set the password field ) -C clear_text_passwd (set the password field ) the following options are bit flags in the gid int field -x ( clear all flags ) -d ( don't allow user to change password ) -p ( disable POP access ) -s ( disable SMTP AUTH access ) -w ( disable webmail [IMAP from localhost*] access ) ( * full list of webmail server IPs in vchkpw.c ) -i ( disable non-webmail IMAP access ) -b ( bounce all mail ) -o ( user is not subject to domain limits ) -r ( disable roaming user/pop-before-smtp ) -a ( grant qmailadmin administrator privileges ) -S ( grant system administrator privileges - access all domains ) -E ( grant expert privileges - edit .qmail files ) -f ( disable spamassassin) -F ( delete spam) -m ( disable maildrop) [The following flags aren't used directly by vpopmail but are] [included for other programs that share the user database.] -u ( set no dialup flag ) -0 ( set V_USER0 flag ) -1 ( set V_USER1 flag ) -2 ( set V_USER2 flag ) -3 ( set V_USER3 flag ) # So to disable a user's ability to submit emails, # /home/vpopmail/bin/vmoduser -s troublesomeu...@mydomain.com should disable their ability to submit. As best I can tell, to enable/unset the flag, you'd need to clear all flags. Let us know if you use these, and how they work. I've never used the flags myself. -- -Eric 'shubes' On 02/16/2014 08:57 AM, Wicus Roets wrote: > You are correct in your second statement, that the particular user was > never at the referred IP. Passwords across the entire virtual domain > has now been changed for the second time. > > This being the second successful spam attack, in two days, with the > same modus operandi, has us quite concerned. > > As an interim option, the CHKUSER_RCPTLIMIT and CHKUSER_WRONGRCPTLIMIT > has been set to 10 and 1 respectively. > > Is there any mechanism to block/disable a user's mail account in such > a scenario than having the mail server's IP blacklisted ? > > > -Original Message- > From: Eric Shubert [mailto:e...@shubes.net] > Sent: 16 February 2014 05:35 PM > To: qmailtoaster-list@qmailtoaster.com > Subject: [qmailtoaster] Re: Spamming via valid vpopmail account > > It appears that either the password for "valid vpopmail account" has > been compromised, or the computer being used by that user has some malware in it. > > The address of origin (46.228.199.219) has no rDNS record: > $ host 46.228.199.219 > Host 219.199.228.46.in-addr.arpa. not found: 3(NXDOMAIN) so that's not > much help. > > If that user was legitimately at that IP address, then the user's > computer is infected. If that's the case, they need to get rid of the > malware on their computer. > > I expect it's more likely that the user was never at the > 46.228.199.219 address. If that's the case (and probably in any case), > you should change the password on that account. You might also advise > the user to change the password on any other accounts which they have > that use the same compromised password, for their own security. > - To unsubscribe, e-mail: qmailtoaster-list-unsubscr...@qmailtoaster.com For additional commands, e-mail: qmailtoaster-list-h...@qmailtoaste
