Sophos UTM: Decommissioning of obsolete URL categorization services CFFS. Click here for important info.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 12 replies
  • Subscribers 5 subscribers
  • Views 3064 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Best method for dealing with SMTP attacks

BigO

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?



This thread was automatically locked due to age.
  • 0

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

    PFSense Plus 23.05 64-bit | Intel Xeon 4-core v3 1225 3.20Ghz
    16GB Memory | 500GB SSD HDD | Fiber Conn (awaiting ATT Fiber)
    (Former Sophos UTM Veteran, XG Rookie)

  • 0 in reply to Amodin

    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?

  • 0 in reply to BigO

    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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    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.

  • 0 in reply to BigO

    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. 

    __________________________________________________________________________________________________________________

  • 0 in reply to LuCar Toni

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

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

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    How do you know that? 

    __________________________________________________________________________________________________________________

  • 0 in reply to BAlfson
    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.

  • 0 in reply to LuCar Toni
    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".

  • 0

    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.

Unfiltered HTML