Blacklisting range of IP addresses

[rbstern]

The biggest spam problem I have that Magicspam doesn't address is spam coming from large groups of Class B or Class C addresses before they end up in someone's anti-spam list.

For example, in a period of 45 minutes, one of my users received spam from the following IP addresses:

198.23.145.214
198.23.145.198
198.23.145.220
198.23.145.209
198.23.145.215
198.23.145.221
198.23.145.208
198.23.145.199
198.23.145.204
198.23.145.205
198.23.145.222
198.23.145.216

Obviously, some malware problem in that LAN, or a single device forging it's IP address within that class C address space.

When I see that in the logs and its still occuring, I have two choices:

1) Manually blacklist 255 IP addresses in Magicspam.
2) Add a firewall rule to block 198.23.145.0/24 (or, in the case of spam from a class B address space, /16).

Obviously, it's not practical to do the first, so I do the second.

I'd much rather be able to to block 198.23.145.0/24 with a blacklist entry in Magicspam, but the IP masking is not supported.

Any chance that a future version will allow IP black listing (and white listing) with masking?

[magicspam]

Hello!

Thank you for your post and for your question. Currently there is no feature to blacklist ranges of IP addresses. However, we do see how this could be a valuable feature! We have created the appropriate feature request development ticket and submitted it to our development team for review.

You mentioned that this pain stemmed from the fact that you were receiving spam from IP addresses which were not yet on blocklists. This would be where our Spam rules come in! These rules use SMTP Best Practice rule enforcement to block spammers (who often do not following Best Practices or RFC's). We suggest using at least our default rule set and then experimenting with some of the other rules to try and stop the offending messages.

Thanks!

-- MagicSpam Support Team --

[rbstern]

Thanks for the supportive reply.

I'm already using all of your best practice rules defaults, as well as "Block Mail Servers reported as Spam Source". Unfortunately, too much legitimate email would fail the "Confirm Server Identification Resolves (HELO)".

Here's a log excerpt from this morning showing the nature of these attacks (with my client's email address changed). Happens once or twice a day during EST business hours.

Code: Select all

Date/Time	Type	MUA	IP Address	Host Name	HELO	From	Recipient
5/1/2013 9:54	HAM	no	193.142.111.7	[193.142.111.7]	ring.bumphighnumber.com	billie_owsley@bumphighnumber.com	myuser@myclient.com
5/1/2013 9:59	HAM	no	193.142.111.29	[193.142.111.29]	frt.performbignumber.com	archie_trujillo@performbignumber.com	myuser@myclient.com
5/1/2013 10:01	HAM	no	193.142.111.18	[193.142.111.18]	linn.strengthenablething.com	ann_bearden@strengthenablething.com	myuser@myclient.com
5/1/2013 10:02	HAM	no	193.142.111.6	[193.142.111.6]	scot.bumphighnumber.com	billie_owsley@bumphighnumber.com	myuser@myclient.com
5/1/2013 10:02	HAM	no	193.142.111.19	[193.142.111.19]	far.strengthenablething.com	angela_mojica@strengthenablething.com	myuser@myclient.com
5/1/2013 10:05	HAM	no	193.142.111.13	[193.142.111.13]	eol.instructfewproblem.net	brian_richardson@instructfewproblem.net	myuser@myclient.com
5/1/2013 10:07	HAM	no	193.142.111.38	[193.142.111.38]	scot.backimportantgovernment.com	adam_gray@backimportantgovernment.com	myuser@myclient.com
5/1/2013 10:10	HAM	no	193.142.111.15	[193.142.111.15]	car.strengthenablething.com	brian_richardson@strengthenablething.com	myuser@myclient.com
5/1/2013 10:11	HAM	no	193.142.111.22	[193.142.111.22]	mxe.ignorenewday.net	brianna_erhardt@ignorenewday.net	myuser@myclient.com
5/1/2013 10:16	HAM	no	193.142.111.25	[193.142.111.25]	scot.performbignumber.com	cecil_stokes@performbignumber.com	myuser@myclient.com
5/1/2013 10:17	HAM	no	193.142.111.31	[193.142.111.31]	pel.careownman.com	birdie_paz@careownman.com	myuser@myclient.com
5/1/2013 10:19	HAM	no	193.142.111.33	[193.142.111.33]	kor.careownman.com	barbara_beeman@careownman.com	myuser@myclient.com
5/1/2013 10:19	HAM	no	193.142.111.26	[193.142.111.26]	ring.performbignumber.com	ben_rasmussen@performbignumber.com	myuser@myclient.com
5/1/2013 10:20	HAM	no	193.142.111.21	[193.142.111.21]	tal.ignorenewday.net	andrew_kelly@ignorenewday.net	myuser@myclient.com

[/size]
As previously described, each time this attack occurs, it comes from a new class C address space, not yet listed in anti-spam databases. Really tough to stop.

Any suggestions welcome, and again, thanks for your positive response to my suggestion about the IP network masking.

[magicspam]

Hello rbstern,

This range which you reported is interesting because some of the IP addresses should have been picked up by the check_ip_reverse_dns rule for having no PTR record. The entire range appears to be listed on MIPSpace and some entries are on PSBL on RATS-NOPTR. Might we suggest trying out the MIPSpace blocklist? Many of our customers are very happy with the performance of this list and (from this example at least) it appears as though it could really help.

It is unfortunate that the spam attacks occur just before these subnets become listed and we definitely appreciate how the ability to blacklist a range would help out.


Something else which you might want to try is using a content filter in behind MagicSpam. MagicSpam only blocks messages based on IP reputation (block lists) and by requiring SMTP best practices compliance (Spam rules) - it does not perform any content scanning itself. Many of our customers have had great success with filters such as Spam Assassin and you might want to look into bolstering your anti-spam by using such a layered approach.


In closing, we recommend enabling MIPSpace to block these messages and if that doesn't work out for you we suggest adding a content filter to your system to pick up the fringe cases.


Thank you!

-- MagicSpam Support Team --

[rbstern]

Thanks once again for the comprehensive reply.

My MagicSpam instance has all of the IP Reputation lists enabled except UCE Protect 1 and 2, so the addresses in question might have been added after the spam to my client, or something about my MagicSpam implementation is not working.

All of the best practice rules are enabled, with the exception of: Confirm Server Identification Resolves (HELO) and Valid FROM domain.

Based on what you see in that list, why are my users getting spam that you believe sholuld be stopped by MagicSpam?

[magicspam]

Hello rbstern,

Thank you for your reply. After reviewing the information you gave us we think there maybe a problem with your reverse DNS lookups.

For example:

Code: Select all

5/1/2013 10:19   HAM   no   193.142.111.33   [193.142.111.33]   kor.careownman.com   barbara_beeman@careownman.com   myuser@myclient.com

The column after the connecting IP address should be the results of the PTR lookup on that IP address, but the result given is not what we would expect (no PTR record).


As this could require further investigation, we would like help you troubleshoot this problem via email. Please send an email with your MagicSpam license key to support@magicspam.com and we can continue with this.


Thanks,

-- MagicSpam Support Team --

[rbstern]

Email sent.

Thank you.