3
Appearing in SORBS RBL -- How to block SMTP sending attempts
Question asked by Montague WebWorks - 4/30/2021 at 10:54 AM
Answered
Hello all,

My SM 'bulk' server was recently hacked and we soon appeared on SORBS' RBL. As such, I am thinking of changing my security profile on this server, and am wondering what the best way to do it would be. 

We have a CMS on a server that sends bulk and single emails through my bulk email server. The emails sent are 'from' my generic CMS address, with a 'reply-to' of the customer's email address. There is only one email account on that box, and I just changed the password for that account.

I need to allow for two things:

1. Blacklist the world from being able to send emails from this server, while leaving a whitelist keyhole for my CMS to send via SMTP
2. Allow for SMTP email reception from the world, while blocking any attempts to send email

Since sending an email and receiving an email both use SMTP (right?) I'm having trouble visualizing how I can filter that kind of traffic. I need to allow bounces, which would arrive by SMTP, while still blocking any attempts by anyone to connect and send emails from that server.

Any advice?
Mik MullerMontague WebWorks

9 Replies

Reply to Thread
2
Douglas Foster Replied
Marked As Answer
Ways to get blacklisted:
1) Have a security weakness so that others can use you as an open relay.   This sounds like the most likely cause for your current trouble.   The solution is to plug the security weakness:

System Configuration... Protocols... SMTP In
- Require Auth Match (Domain or Email Address, not NONE)
- Allow Relay for Authenticated Users (on)

Domain Configuration
- Require SMTP Authentication (on)

Then your CMS server is either a whitelisted IP address or uses a username/password to connect.

2) Some blacklists (SpamHaus for certain) will list you simply for having a list with too many bad addresses.  They want you to have a two-step opt-in, where you confirm the email address before using it, as well as having good bounce detection and other list maintenance practices.

3) If your server is actually infected, then you have to actually get the bad guys out of your network by whatever method is necessary.

Elaboration on #1 - Yes, SMTP is used in both directions, but used differently.

Inbound SMTP from the Internet is unauthenticated (no login), since you need to accept connections from anyone.   Messages are only accepted to locally-hosted email addresses.

Inbound SMTP connections from email clients and applications are authenticated (username/password or whitelisted static IP.)    These are allowed to submit messages to both local and remote addresses.   Accepting messages for remote domains is relaying.    Allowing a relay without authentication is an open relay.

Since a lot of reputation assessment is tied to the server submitting a message, open relays are disastrous.   At first, your good reputation allows the attackers bad traffic to be accepted.   Eventually their bad reputation wears off on you and you have a bad reputation even for your innocuous mail.

0
Montague WebWorks Replied
Hah. I had Settings > Protocols: Allow Relay set to Nobody, but had Require Auth Match set to None. It is now set to Email Address. Good call. Domain > Configuration has Require SMTP Authentication set on.

I definitely have to improve the bad email addresses removal, but that's a whole 'nother thing.

The issue with SORBS was that three hacker email addresses were able to hit their honeypot address three times in three days. We changed the password for that account on the box and then asked to be removed from the list. Hopefully between the pw change and fixing the setting, above, will prevent this from happening again.

Thanks for the advice!
Mik MullerMontague WebWorks
0
Montague WebWorks Replied
Update: after some testing, setting Require Auth Match to Email Address stopped the bulk emailing capability cold. I set it back to none and the emails are going through. I'll get with support to see what the best settings are and bring the results back here, in case anyone else ever tries this kind of set up.
Mik MullerMontague WebWorks
0
Kyle Kerst Replied
Employee Post
Mik, those results lead me to believe you've got a compromised account somewhere. When you set it to Email Address that stopped whichever account is being used from generating spoofed messages. I'd recommend checking out this KB article here: 

Kyle Kerst
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Montague WebWorks Replied
Hey Kyle. I think you misunderstand what's happening on this server.

I host many websites, and they all have emailing capabilities (contact form, dynamic forms, bulk emailing ala Constant Contact) that use my bulk email server, using SM latest version, licensed. All websites hit this bulk email server with the same login / password, and send From: a single email address (not the login one, for security sake).

This bulk email server is not a general use email server. There is only one email account that is used by all websites for sending emails.

As a side note, I see continuous login attempts by IPs all over the planet, which I would love to block, if possible, while still allowing the world to send bounces back.

The problem is that all traffic uses SMTP:

o My CMS sending email
o Email servers out there sending bounces
o Hackers trying to send email through my server

I was hoping that by setting Require Auth Match to Email Address I would instantly block all incoming hack attempt traffic, but it actually stopped my CMS from being able to send out legitimate emails.

So, the question is, can I blacklist the world from using my bulk email server as a transmission point, while still allowing the world to send me bounces? Again, both use SMTP.

Perhaps you could add a new security feature that black/white list IPs for logging in purposes, and also black/white list IPs for general email reception.

That would stop hacking cold, while still allowing for bounces to be delivered.

The only other thing I can think of is setting up another bulk email server, just for sending emails, and blacklist the planet while whitelisting my CMS. I could then have this other bulk email server just for receiving bounces, and have the one email account Disabled (allow mail), which we can use the APIs to Enable and Disable as we automatically check for the bounce emails.

BTW, the link you sent is for version 15, and the steps did not match how 17 works. Build 7776 (Apr 16, 2021)
Mik MullerMontague WebWorks
0
Kyle Kerst Replied
Employee Post
Mik - Ultimately there are a few issues here - and I think we're mixing areas that aren't related. In this scenario turning on Require Auth Match: Email Address would definitely break your web forms since they're authenticating with one address and sending another. This setting will have no impact on hackers attempting to guess passwords, as they're not actually getting far enough to be checked by this security setting, and are simply trying bad passwords to guess accounts on your server. 

These are best handled by tweaking the rules found in Settings>Security>IDS Rules so that the Brute-Force by Protocol rules catch and temporarily blacklist these attackers. 

Lastly, as I noted on your ticket you can definitely blacklist a range of IPs that covers the entirety of the internet, then whitelist only the servers and clients you want to be able to connect regardless of the blacklist entry. This will prevent inbound/outbound SMTP access from anyone and everyone aside from the IPs you've whitelisted explicitly. 

On the KB article I sent you, these instructions should be more or less the same. Ultimately you'll want to head into reports and then down to Message Traffic where you can set the Mode to Domains. This will allow you to further drill down into each domain's message traffic and see how is sending (on average) more than usual. That being said though, I don't think this will help in that case as you're sending all of your contact forms via a single account. 

All in all I recommend adjusting your IDS settings to catch these password hack attempts and blacklist them for long periods of time. I usually set these (in production) to the following: 

Because most email clients will stop attempting to log on after a few failures, these rule changes should not catch the legitimate password failures and should only be applied to users who are deliberately failing authentication to guess passwords. I hope this helps!
Kyle Kerst
Technical Support Specialist
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
1
Montague WebWorks Replied
Hey Kyle,

Thanks for explaining how the Auth by Email works. Makes perfect sense.

Not going to use the Blacklists on SMTP as I need to allow incoming emails from servers out there just for the purposes of delivering bounces.  If ST is able to split up SMTP security by login-for-sending vs. hand-off-for-delivery that would be helpful, as I could blacklist the world and whitelist my web servers for sending, and leave delivery open for returning bounced emails.

Thanks also for reminding me about the IDS Rules. These are the two I have for SMTP (below). I figure my web servers have the un/pw saved and will never get it wrong, so I can keep the thresholds very low.


One last question, just to confirm. If I want to block the world for POP but allow one of my web servers POP access (to retrieve the bounced emails), I could blacklist 0.0.0.0 - 255.255.255.255 and whitelist just the one IP for my web server, correct? I wouldn't have to blacklist 0.0.0.0 - my server's IP -1, and my server's IP +1 - 255.255.255.255

And on the same thought, I should probably blacklist the world for IMAP, right? That won't prevent me from logging in via the web interface, correct?

Thanks
Mik MullerMontague WebWorks
2
Douglas Foster Replied
For best results, you need to have an incoming gateway which receives traffic from the world using unauthenticated SMTP, which is separate from the mail server that handles authenticated SMTP from  your users. 

The incoming gateway box can be configured with an IDS rule to block after 1 login failure, since no login should ever be attempted.   This is discussed on a previous topic that I started.   I have been converting the temporary IDS blocks into permanent ones.   Between the two, I currently have 5500 blocked IPv4 addresses.   Others have said that the attackers move on, so they have the IDS rule block for a few days but they don't worry about making blocks permanent.

An incoming gateway also simplifies spam filtering, because unathenticated users need identity assessment (spf, dmarc, and local policy) while authenticated users do not.   So the spam configuration is different.

SmarterMail Free is one option for the incoming gateway, but certainly not the only one.   SmarterTools will treat it as fully supported when it is used in conjunction with your licensed server.
1
Montague WebWorks Replied
I'm good for now. Can't imaging setting up yet another email server. Would love it if SM split up security, blacklist and whitelist settings for these two types of SMTP: authenticated (for sending) and non-authenticated (for receiving). That would be amazing. Also, a sharing of blacklists across SM customers, and server-level content filters, used only for authentic spam.
Mik MullerMontague WebWorks

Reply to Thread