When I look at my SMTP live log I see continual attempts to access my mail server.The SMTP proxy seems to be doing its job, but I am interesting in knowing the best method for minimizing the amount of entries that get recorded in the logfile.
2022:05:28-11:19:44 firewall exim-in[31398]: 2022-05-28 11:19:44 SMTP connection from (localhost) [5.34.207.150]:20624 closed by QUIT 2022:05:28-11:19:44 firewall exim-in[31414]: 2022-05-28 11:19:44 SMTP connection from (localhost) [5.34.207.182]:51714 closed by QUIT 2022:05:28-11:19:46 firewall exim-in[5027]: 2022-05-28 11:19:46 SMTP connection from [5.34.207.150]:43732 (TCP/IP connection count = 6) 2022:05:28-11:19:46 firewall exim-in[31424]: 2022-05-28 11:19:46 SMTP connection from [5.34.207.150]:43732 closed by QUIT 2022:05:28-11:19:47 firewall exim-in[5027]: 2022-05-28 11:19:47 SMTP connection from [5.34.207.150]:12380 (TCP/IP connection count = 6) 2022:05:28-11:19:47 firewall exim-in[5027]: 2022-05-28 11:19:47 SMTP connection from [5.34.207.182]:56972 (TCP/IP connection count = 7) 2022:05:28-11:19:47 firewall exim-in[31419]: 2022-05-28 11:19:47 SMTP connection from (localhost) [5.34.207.182]:22078 closed by QUIT 2022:05:28-11:19:48 firewall exim-in[31411]: 2022-05-28 11:19:48 SMTP connection from (User) [87.246.7.213]:42120 closed by QUIT 2022:05:28-11:19:49 firewall exim-in[31421]: 2022-05-28 11:19:49 SMTP connection from (localhost) [5.34.207.150]:50418 closed by QUIT 2022:05:28-11:19:50 firewall exim-in[5027]: 2022-05-28 11:19:50 SMTP connection from [5.34.207.182]:27336 (TCP/IP connection count = 5) 2022:05:28-11:19:50 firewall exim-in[31405]: 2022-05-28 11:19:50 SMTP connection from (localhost) [5.34.207.150]:35496 closed by QUIT 2022:05:28-11:19:51 firewall exim-in[31426]: 2022-05-28 11:19:51 SMTP connection from (localhost) [5.34.207.182]:56972 closed by QUIT 2022:05:28-11:19:52 firewall exim-in[31431]: 2022-05-28 11:19:52 SMTP connection from (localhost) [5.34.207.182]:27336 closed by QUIT 2022:05:28-11:19:52 firewall exim-in[5027]: 2022-05-28 11:19:52 SMTP connection from [87.246.7.213]:53630 (TCP/IP connection count = 4) 2022:05:28-11:19:53 firewall exim-in[31376]: 2022-05-28 11:19:53 SMTP connection from (User) [212.70.149.72]:44572 lost D=31s 2022:05:28-11:19:53 firewall exim-in[5027]: 2022-05-28 11:19:53 SMTP connection from [5.34.207.182]:62214 (TCP/IP connection count = 3) 2022:05:28-11:19:55 firewall exim-in[5027]: 2022-05-28 11:19:55 SMTP connection from [5.34.207.150]:27272 (TCP/IP connection count = 4) 2022:05:28-11:19:56 firewall exim-in[31425]: 2022-05-28 11:19:56 SMTP connection from (localhost) [5.34.207.150]:12380 closed by QUIT 2022:05:28-11:19:56 firewall exim-in[31440]: 2022-05-28 11:19:56 SMTP connection from (localhost) [5.34.207.182]:62214 closed by QUIT 2022:05:28-11:19:56 firewall exim-in[5027]: 2022-05-28 11:19:56 SMTP connection from [5.34.207.182]:32588 (TCP/IP connection count = 5) 2022:05:28-11:19:58 firewall exim-in[31439]: 2022-05-28 11:19:58 SMTP connection from (User) [87.246.7.213]:53630 closed by QUIT 2022:05:28-11:19:58 firewall exim-in[5027]: 2022-05-28 11:19:58 SMTP connection from [5.34.207.150]:53746 (TCP/IP connection count = 4) 2022:05:28-11:19:59 firewall exim-in[31446]: 2022-05-28 11:19:59 SMTP connection from (localhost) [5.34.207.182]:32588 closed by QUIT 2022:05:28-11:19:59 firewall exim-in[31444]: 2022-05-28 11:19:59 SMTP connection from (localhost) [5.34.207.150]:27272 closed by QUIT 2022:05:28-11:19:59 firewall exim-in[5027]: 2022-05-28 11:19:59 SMTP connection from [5.34.207.182]:2970 (TCP/IP connection count = 3)
I have tried 2 different methods, both of which seem to work.
1. Create a blackhole entry for each network in Static Routing
2. Create a DNAT blackhole
Definitions & Users > Network Definition Create a Network - xxx.xxx.xxx/24 for IPs identified in SMTP log Create a Group, which includes all of the above attacker networks Create a Host named Blackhole (240.0.0.1)Network Protection > NAT > NAT New NAT Rule > DNAT For traffic from: Group created above Using service: ANY Going to: WAN (Address) Change the destination to: Blackhole host created above
Are there better ways to do this?
So are you more interested in just the logfile or actual traffic, because what you are doing with those is actually affecting traffic.
UTM - 9.711 | Intel Xeon 4-core v3 1225 3.20Ghz 16GB Memory | 500GB SATA HDD | GB Ethernet x5
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.
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?
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".
I am currently in the process of upgrading my network from a Server 2003 environment to a Server 2019 environment.
This will also include an upgrade of my UTM hardware and a clean install of the UTM.My goal is to have a "best practices" configuration of the UTM for 2022.
I have an IT background, but I would not profess to being a firewall expert, so that is why I am asking questions and seeking advice on areas I am not 100% sure about.