When an IP address is SMPT blacklisted via Web Service, it takes too long to stop threat

Problem reported by Lyle Hancock - 9/4/2015 at 2:32 PM

Resolved

We use MXRouter to do our spam filtering and take countermeasure against numerous types of hacking and abuse. MXRouter tails SmarterMail's log files to detect unauthorized login attempts among other abuses. In turn, it will blacklist a failed login via SmarterMail's web service.

The problem is when MXRouter SMTP blacklists an IP address via web services, it can take a long time before SmarterMail actually blocks the IP address, affording the perpetrator numerous more attempts as can be seen in the screenshot below. The "**** Added IP address..." message is generated after MXRouter confirms that the IP address was successfully added to SmarterMail's blacklist. Manual inspection confirms it was added too.

Not being able to stop a hacking attempt quickly seems a security vulnerability, particularly if there is a coordinated bot attack where literally thousands of login attempts will be accepted despite the IP addresses were blacklisted on the first detected attempt.

Is there any setting in SmarterMail that will make it more responsive to an IP address being blacklisted?

11 Replies

Reply to Thread

SmarterUser Replied

9/4/2015 at 11:23 PM

Why not just configure SMTP Blocking rules?

Lyle Hancock Replied

9/4/2015 at 11:50 PM

SmarterMail lacks the adaptability in its rules to take effective advanced countermeasure and containment in certain scenarios. We've used MXRouter for a number of years with a now discontinued product with excellent detection, assessment, countermeasure, and containment. Since switching to SmarterMail, it seems the web service interface is way too slow to be a viable. Hence my asking if there is a way to tune the interface to be more responsive?

Thanks for any insight.

SmarterUser Replied

9/5/2015 at 4:45 AM

Can't help with that. You said you were trying to blacklist based on unauthorized login attempts, which the SMTP blocks do nicely, as long as you don't bounce the server. Not sure what "countermeasures and containment" you might want beyond blacklisting the IP.

Lyle Hancock Replied

9/5/2015 at 10:34 AM

Thanks SmarterUser for your kind reply.

Actually, we do use SmarterMail’s SMTP and other protocol blocking rules but, as I mentioned, they are not adaptive enough to rely upon them as a comprehensive countermeasure mechanism unless I’m overlooking something obvious.

By countermeasure and containment, ideally we want to give our legitimate e-mail users a reasonable number of chances at a failed login then put them on timeout for 10 to 15 minutes. However, if we detect a brute force hack, then we want to change the rule so that any single login failure will result in the IP address being immediately permanently blacklisted. If it is a coordinated bot attack we would want all 1000+ IP addresses immediately blacklisted and not given a second chance at a login. Additionally, if the attack is against one or more valid e-mail accounts we would want the accounts under attack to be disabled for the duration of the attack so that even if a correct password is permuted, the login will still fail - the attacker would not know they guessed a correct password.

I’m guessing SmarterMail uses a thread based timer to scan the blocking list for changes. It seems like it is on a 10 second thread sleep cycle. Perhaps there’s a configuration setting to decrease the sleep period to check the list more frequently. If so, that would be a good solution. Even better is I might learn out how to implement the above paragraph through SmartMail rules alone.

Bruce Barnes Replied

9/5/2015 at 7:35 PM

RE: "Web interface way too slow" Server operating system, SmarterMail version, number of users, server configuration, bandwidth availability, and what other applications are running on the server on which SmarterMail is installed .

Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 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

Lyle Hancock Replied

9/5/2015 at 8:59 PM

• Windows Server 2012 R2, HP Proliant DL360 G7 4 core CPU, rack mount in data center, 8 GB memory w/ 1TB RAID mirrored, 7,200 RPM
• Server is dedicated to SmarterMail - the only other application running on the server is MXRouter (our security management agent), IIS, SNMP V2C for NOC monitoring, backup software runs at 3am, and the usual Windows server services.
• Physical machine (not VM)
• Cisco series 2900 Router touches WAN
• Cisco SG500 series 48P K9 switch (48 port)
• ~40 users (mostly in-house with a few VAR and OEM accounts)
• SmarterMail Enterprise Version 14
• LAN Bandwidth: Gigabit LAN - Ethernet CAT 6 cabled.
• WAN Bandwidth 1Gbit up / 1Gbit down under SLA.
• Average CPU load < 4%

The plan is to add an ArTrac G5 Trouble Ticketing and CIS/Inventory management suite to it in the near future for internal use.

Bruce Barnes Replied

9/5/2015 at 9:13 PM

I would ditch the SNMP protocol - downright dangerous from a security perspective. Also, test your ACTUAL bandwidth on speedtest.comcast.net - FROM THE SERVER DESKTOP, UNDER FULL LOAD, to several of the testing points, to see actual speed of your circuit - never trust claims or SLAs. Is SmarterMail setup under IIS 8 / SSL? Is SmarterMail webserver DISABLED? Is anything else running under IIS?

Lyle Hancock Replied

9/6/2015 at 7:13 AM

Thank you Bruce!

The SNMP is for our NOC to make sure the services on the machine are up. Monitoring is 24/7 by our own staff and TMN/OSS. Thus, can't disable SNMP. The probe is internal to the LAN and cannot be reached by the WAN. Our security is high and tested often as we answer to regulatory bodies (the reason why this was an important issue for me).

I checked the Smartermail Web Service and was surprised to find it running. I imagine it got started back up with our recent upgrade from Ver. 13 to 14 and we didn’t catch it. *Note made for future upgrades. I disabled it and that seems to have solved the problem.

Thanks very much!!! How do I mark the issue as resolved?

Lyle Hancock Replied

9/6/2015 at 7:28 AM

I forgot... yes - everything is SSL and backhauled between centers highly encrypted with redundant paths and disaster tolerance (geographically isolated failover) for mission critical systems. Running IIS 8 at latest security updates. WAN bandwidth and latency is monitored 24/7. Likewise for all LAN sub-nets. Running IPFIX (or NetFlow) on key interfaces to ensure proper QoS and spot irregular traffic. We try to keep it well oiled.