Best method for dealing with SMTP attacks

So are you more interested in just the logfile or actual traffic, because what you are doing with those is actually affecting traffic.

What I am interested in is the best way to deal with this traffic.

Do I just ignore all of the entries in the logfile and assume that the proxy is simply doing its job and dropping those connection attempts, or do I selectively drop traffic from networks that obviously have a sinister intent?

Is there a "preferred" method on how to deal with this?

Both the DNAT and the Blackhole route achieve the same thing.  I prefer the DNAT with a Network Group named something like "Badguys" so that I just need to add hosts to it instead of creating a new DNAT.

Cheers - Bob

Yes Bob, that is exactly what I have.

But, my question is... Do I really need this?
Other than having a larger SMTP logfile if I don't, does dropping the traffic have any real benefit?
Is it just good enough to let the SMTP proxy do its thing?

The other issue is that network entries have to be added manually to the "Badguys" list, which would need continual monitoring.
That's doable, but only if it is beneficial.

Yes Bob, that is exactly what I have.

But, my question is... Do I really need this?
Other than having a larger SMTP logfile if I don't, does dropping the traffic have any real benefit?
Is it just good enough to let the SMTP proxy do its thing?

The other issue is that network entries have to be added manually to the "Badguys" list, which would need continual monitoring.
That's doable, but only if it is beneficial.

That is one of the reasons, customers move to a Cloud based MX solution. Because they do not want to deal with this kind of spoofed attacks. As long as you cannot figure out, who is actually talking to you, you will have to answer on Port25 and talk to the peer. Cloud based Solutions can do this with different techniques (as they have only one MX, which will sync data in real time, they can actually quite easily detect such attacks. 

Solutions like Sophos Central Email can do this and will scan the emails for you. Afterwards it will send the Email to your Email server. 

Toni, this looks more like a scanner than a spoofer.

BigO, do you see anything related in the Intrusion Prevention log?

Cheers - Bob

How do you know that? 

BAlfson said:

BigO, do you see anything related in the Intrusion Prevention log?

Not anything that stands out to me, but having said that, I am definitely not an expert at deciphering UTM log files.

If the "Allow authenticated relaying" checkbox is checked, the logfile shows auth attempts from those IP addresses, using random names.
With the checkbox unchecked (which it is currently) the logfile just shows "closed by QUIT"

As stated already... the SMTP Proxy seems to be doing its job.
I would just like to know if I should leave it to do its thing and forget about using a Blackhole DNAT rule and not concern myself with the larger logfiles.

It could be as you say Bob, just a scanner, but the question still remains...
Do I simply ignore these entries in the SMTP logfile, or should I be actively dropping traffic from the IP/Networks that generate lots of these entries.

I am pretty sure that I am not the only UTM user that sees these kinds of log entries.
Basically, I am looking for suggestions of a "best practice" approach to this issue.

LuCar Toni said:

That is one of the reasons, customers move to a Cloud based MX solution.

Not a big fan of any cloud based solutions, so that's not really an avenue that I wish to pursue.

My network is relatively simple, with the exception of having my own mail and web servers.
Those will always be a challenge to secure, but I feel pretty comfortable with how the UTM does that, as I have not seen any evidence over the past 15 years (or so) that my severs have been breached.

What do they say... "Ignorance is bliss".

Bob might be attributing to the fact that the requests are so close together in terms of a request or two every second by the same block of IPs, I would have alluded to the same conclusion.  Just a guess, but I could be reading his mind, lol.

Good read!  I just checked one of my favorite tools, ip2location.com, and 5.34.207.182 is identified as a SCANNER, confirming my guess.  According to Central Ops.net, it's located in Kyiv, Ukraine, so, my guess is that the Russian mafia is trying to break into your UTM's SMTP Proxy using an account at spaceshipnetworks.

Cheers - Bob