2
Re: spam relay through phpmailer triggering DDOS
Question asked by Hemen Shah - December 22, 2015 at 4:43 AM
Unanswered
Hi,
 
i have one PHP based website which is getting infected with some scripts due to which it starts relay of spam mails triggering SMTP DDOS attack (50 mails in 10 mins block for 60 mins)
 
with this all web based forms gets stuck and doesnt function, logs starts throwing error "421 Server is busy try again later" also here our own mail IP gets added to SMTP block
 
How can this be prevented.
 
 

8 Replies

Reply to Thread
0
Scarab Replied
December 23, 2015 at 4:20 PM
You *COULD* add the IP of the website to your SECURITY > WHITELIST or alternately the SECURITY > ANTISPAM ADMINISTRATION > BYPASS GATEWAYS. This would prevent it from getting blocked by your Abuse Detection Rules.
 
*HOWEVER* it sounds like the Abuse Detection is doing it's job, which is ultimately what you want. It is protecting the reputation of your Outgoing Mail Server by blocking abuse from rogue scripts trying to send through it. If the website is continuously being infected by uploaded scripts I would resolve it by making sure that their web app is using SMTP Authentication and then set the php.ini (or user.ini depending on your server's PHP configuration) to have a line that reads as such:

[PHP]
[mail function]
sendmail_from = unauthorized@mydomainname.com
 
I would then add the IP Address to my Whitelist and then go to SECURITY > ADVANCED SETTINGS > SMTP Blocking and add an entry for unauthorized@mydomainname.com.

That way, their PHP web application can send email just fine without worry because it is using SMTP Authentication and the IP Address will never be blocked because it Whitelisted, however any rogue scripts that are uploaded or created through vulnerabilities will not be able to abuse the PHP sendmail function routing through your Smartermail Server because they will automatically be blocked based on the FROM: address of unauthorized@.
0
Bruce Barnes Replied
December 23, 2015 at 8:42 PM
You want to be VERY careful about whitelisting any server's IP address:  especially a server which is running PHP!
 
I share this thought because about four years ago I was contracted to resolve a spamming issue on a server in Stockholm Sweden.  The ISP was running both SmarterMail and IIS - with about 160 websites running, and many of them were running PHP.  The owner of the small ISP was extremely careful with his security and passwords, and there were multiple levels of encryption and VPNs to connect - overall excellent security.
 
There were no SMTP bypasses.  There were no white listed IP addresses in SmarterMail.
 
We used every available tool to monitor the networks - working for almost 3 days, to vet the source of the more than 500,000 spam messages per hour which were being generated - and none of them were SMTP authenticated, with everything going through SmarterMail.  The customer was running an early version of SmarterMail 7.X, so the log reporting was not nearly as good as it is in SmarterMail 14.X.  That meant we were limited to Microsoft logs, IIS logs (which were mostly useless in this case), and monitoring - using every available tool and resource then available.

Long story short:  The ISP owner's daughter had a hair salon.  It had been built in PHP, and, with the exception of new hours, had not really been updated in several years.

It turns out that the owner's daughter's website was the weak link, but, because he had some large business sites hosted on the server, he was unwilling to allow me to just turn off IIS to see if that stopped the problems.
 
In sheer frustration, I finally disabled IIS and the spam stopped - cold.
 
I then disabled all of the websites, individually, and restarted IIS, and there was still no spam.
 
So, I enabled the websites, one at a time, and, withing seconds of re-enabling his daughter's hair salon website, which was written in PHP, the spam started flowing again.
 
Now I had a clue to work with and we were able to find out where someone had gone into the actual SmarterMail configuration files and white listed all of the websites using a text editor.  These edits were not showing up in the SmarterMail interface, so there was no reason to think anything was white listed in SmarterMail.
 
We found the edit, removed the white listed sites, and had his web  development team redo the e-mail sending capabilities of each of the sites to enforce full SMTP authentication.

Problem resolved.  Spam ended, but not before close to 10 million spam messages had attempted to flow through the ISPs SmarterMail system.

While whitelisting may be tempting -- it's a "quick and dirty fix," it's never a good idea.  The better solution is to re-code the website(s) in question, and run proper SMTP authentication on all contact forms, newsletter sign up sheets.

There's another reason to use proper SMTP authentication, too:  Many large ISPs, taking the lead of YAHOO!, have begun to look for an indication in the e-mail header that indicates that the message was properly SMTP authenticated.
 
SmarterMail 14.X provides this vehicle in the form of an "X-SmarterMail-Authenticated-As" message header record.
 
In the example below, with some of the data obfuscated to protect the identity of the server from which it was sent, you can see how that "X-SmarterMail-Authenticated-As" is inserted in the header.
 
============================================
Return-Path: <bbarnes@REDACTED.com>
Received: from mail.REDACTED.fr (mail.REDACTED.fr [XXX.XXX.XXX.XXX]) by securemail.chicagonettech.com with SMTP
          (version=TLS\Tls12
          cipher=Aes256 bits=256);
   Wed, 23 Dec 2015 09:15:55 -0600
X-SmarterMail-Authenticated-As: bbarnes@REDACTEDe.com
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;
        d=oREDACTED.com; s=secure;
        h=x-originating-ip:content-type:mime-version:message-id:reply-to
          :date:subject:to:from;
        bh=dZbbdqC5O9v5ky+70B8bz8mufj6A5oY4o02bWtOZJw0=;
        b=muAaGXwNOfP4mQ73oNR4l/TYDVRBxTYbm1+sOwNYGV/2wjEhU3dKQcgBI//jNxVlT
          AQLOV/lGWGnyD8Y2GDQtDq2U2IoZqz5xdlU7jzWZTqzZN8kUgtXn3/pyb4o7n0U3v
          4WCxWAcMJhXYUB8gQ9wsUCh6rjTmlU7qjEViJvZdA=
Received: by mail.REDACTED.fr via HTTP;
          Wed, 23 Dec 2015 16:15:40 +0100
From: "Bruce Barnes - SmarterMail Consultant" <bbarnes@oREDACTED.com>
To: <mailtest@unlocktheinbox.com>
Subject: MailTest REDACTED.COM 201512230914 CST - GMT -0600 | 201512231614 GMT +0100
Date: Wed, 23 Dec 2015 16:15:40 +0100
Reply-To: bbarnes@REDACTED.com
Message-ID: <e8a0967936814d66876ebccf30006031@REDACTED.com>
MIME-Version: 1.0
Content-Type: multipart/related; boundary=ae61246c6a8a48f3aad6b30afc8a7bc3
X-Originating-IP: [173.165.112.149]
X-Rcpt-To: <bbarnes@chicagonettech.com>
X-SmarterMail-Spam: SPF_Pass, DK_None, DKIM_Pass
X-SmarterMail-TotalSpamWeight: 5
============================================
 
In the header record shown above, the use of SMTP authentication has not only allowed SmarterMail to insert the X-SmarterMail-Authenticated-As: bbarnes@REDACTEDe.com, but is further enhanced by the fact that SmarterMail 14.4 now fully supports TLS 1.2, the highest possible level of data encryption.
 
When coupled with SPF, rDNS, and DKIM, this also enables DMARC, which, along with the valid use of SMTP AUTHENTICATION, for every message sent via SmarterMail, or any other e-mail server, will help to ensure that your e-mail server does not, because of the use of whitelisting, become an open relay or source of spam.

For more information on how to ensure your e-mail delivery, please see my document at: Why Am I Having Problems Getting My E-Mail Delivered?
 
Bruce Barnes
ChicagoNetTech Inc

Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
0
Hemen Shah Replied
December 23, 2015 at 11:15 PM
Hi,
I would not prefer to whitelist any IP, as the IP getting blocked is shared and used by many sites incase if i whitelist it and any other type of spam or similar to this from other domain can create havoc
 
I need solution to block mails through phpmailer for specific domain, i was able to identify one unknown script on that php site which i deleted and mails stopped, but after a day again this kind of script comes in some other folder of the site, so there is issus with the site which is getting investigated but i need to find solution to stop such mails if occurs in future with some other domain etc.
 
Due to volume of relay this script creates it immediately triggers DDOS and all web forms gets stuck as they get server busy error 421
 
should SMTP AUTHENTICATION BYPASS must have 127.0.0.1 or mx IP  ? if i remove 127.0.0.1 this then does it mean all webforms where smtp is not authenticated will be stopped, if so then this might help and force customers to recode their webforms.
 
In smtp log it says IP IN AUTH BYPASS
 
Thanks
2
Scarab Replied
December 29, 2015 at 1:17 PM
SMTP Authentication Bypass should not have any entries unless they are absolutely, positively necessary. It sounds like you are running Smartermail on the same server as your Web Server? In such a case you do not need 127.0.0.1 as that is allowing *ALL* mail received from that local machine to be sent by Smartermail without authentication. Removing that IP would require all mail sent from your hosted websites (whether web forms or phpmailer scripts, whatever) to use SMTP Authentication. Once removed from SMTP Authentication Bypass you should be able to safely add 127.0.0.1 to your Whitelist to avoid it blocking itself when a site keeps trying to send email without SMTP Authentication (although note that Whitelisting will prevent you from doing Outgoing SMTP Antispam Checking on those emails).
0
Hemen Shah Replied
January 2, 2016 at 12:32 AM
Have removed all 127.0.0.1 from smtp authentication bypass so now everyone by default has to authenticate web based forms, is it safe to add MX IP to whitelist now so that when ddos triggered it doesnt add own IP to SMTP block
 
 
0
Hemen Shah Replied
January 5, 2016 at 1:28 PM
Have removed all 127.0.0.1 from smtp authentication bypass so now everyone by default has to authenticate web based forms, is it safe to add 127.0.0.1 to whitelist now so that when ddos triggers it doesnt add own IP to SMTP block
0
Bruce Barnes Replied
January 5, 2016 at 9:36 PM
You can do whatever you want to with the 127.0.0.1 IP address, but we do not allow any SMTP authentication bypass - not even 127.0.0.1.  We actually worked on client's e-mail server that was sending out 500,000 spam messages, PER HOUR, using SMTP BYPASS, in SmarterMail, from a PHP mailer on a website which was compromised.   The client hosted websites on the same server that SmarterMail was running on and the PHP had been compromised by a user's FTP account.
 
All of our hosted websites must use a complete username and password to authenticate. 

This is a very easy process, whether you are running Cold Fusion, C++, or customer ASP.NET software.  All of them now support the TLS encryption protocol as well.
Bruce Barnes
ChicagoNetTech Inc

Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting
0
Bruce Barnes Replied
January 6, 2016 at 6:56 AM
No. Find out why you are triggering internal dDOS attacks and fix the problem in your code.
Bruce Barnes
ChicagoNetTech Inc

Phone: (224) 444-0169

E-Mail and DNS Security Specialist
Network Security Specialist

Customer Service Portal: https://portal.chicagonettech.com
Website: https://www.ChicagoNetTech.com
Security Blog: http://networkbastion.blogspot.com/

Web and E-Mail Hosting, E-Mail Security and Consulting

Reply to Thread