Advisory: Sophos Endpoint - "Your connection isn't private." We're aware of a certificate issue and are actively working to resolve it. Please see: KB-000045954 for the latest updates.

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

ATP Alerts Tor Exit Nodes

Hi All,

I wonder if anyone can help me clarify the following, we start receiving standard ATP alerts for the past month as per bellow, usually im able to investigate this alerts and they either are DNS recursive queries performed by out forwarders on Spam domain emails  received and rejected by the SMTP proxy, or Web sessions hijack attempts trying to redirect traffic to malicious domains, but recently i been baffled by a a recurrent alert as bellow where im not able to make much sense, i parsed the logs for our SMTP proxy that shows traffic to a Tor node from what i can only assume being SMTP connections rejected by the UTM  does anyone have any idea on this ?

2021:10:27-12:50:55 srvutm-1 exim-in[8916]: 2021-10-27 12:50:55 SMTP connection from []:31034 (TCP/IP connection count = 4)
2021:10:27-12:50:57 srvutm-1 exim-in[23862]: 2021-10-27 12:50:57 TLS error on connection from []:31034 SSL_accept: TCP connection closed by peer
2021:10:27-12:50:57 srvutm-1 exim-in[8916]: 2021-10-27 12:50:57 SMTP connection from []:32560 (TCP/IP connection count = 4)
2021:10:27-12:51:01 srvutm-1 exim-in[23909]: 2021-10-27 12:51:01 TLS error on connection from []:32560 SSL_accept: TCP connection closed by peer
2021:10:27-17:12:32 srvutm-1 exim-in[8916]: 2021-10-27 17:12:32 SMTP connection from []:14154 (TCP/IP connection count = 2)
2021:10:27-17:12:33 srvutm-1 exim-in[5631]: 2021-10-27 17:12:33 TLS error on connection from []:14154 SSL_accept: TCP connection closed by peer
2021:10:29-03:34:26 srvutm-1 exim-in[6731]: 2021-10-29 03:34:26 SMTP connection from []:22392 (TCP/IP connection count = 1)
2021:10:29-03:34:28 srvutm-1 exim-in[18207]: 2021-10-29 03:34:28 TLS error on connection from []:22392 SSL_accept: TCP connection closed by peer

A threat has been detected in your network The source IP/host listed below was found to communicate with a potentially malicious site outside your company.

Advanced Threat ProtectionDetails
Total Events: 2
User/Host Threat Name Destination Events Origin
1 C2/Generic-A 
2 C2/Generic-A 

This thread was automatically locked due to age.
  • Thanks Balfson i already had a rule to drop any traffic from this range, the challenge is to have an up to date list of Tor Nodes object that would dynamically update, maybe an idea for Sophos perhaps ?

    This recent activity could be or not related to the bellow also, but it is worth a read

  • Thank you! 

    In that case I have to create a network definition for every subnet that I want to block and put them all into one network group, correct?

  • Hi all,

    sitting in Germany I have that very same phenomenon here on our SG 330 HA-Cluster. I found this thread while searching on how to find DNS request in the log files. I was assuming that DNS requests that are sent to the UTM are logged in the firewall log but I don't see any incoming DNS request for the f3netze domain. What I found is that the IPs are doing some kind of slow port scanning from external on our NATted IPs so I added those to my blackhole DNAT rule about two weeks ago that I already had configured for other IPs before. But still we have that ATP message from time to time. Today I have set up a port mirror for the UTM incoming interfaces and duplicate the traffics to a Linux machine running tshark with a filter on port 53 and domain like f3netze. I hope through this to find the source IP of the requesting machine once this happens again. I'll keep you updated when I find sth.

  • Hallo,

    Did you check 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
  • Hi Bob,

    yes, I checked that but the related IPs do not show up there. Is there any chance that the firewall is generating the DNS requests by itself? Is there any scenario that would lead the firewall to do this?


  • Hi,

    update from my side: I created the blackhole DNAT, but we received ATP alerts last night again. 

    I was expecting that any traffic would get blocked eventhough these are just DNS requests..


  • Hello ,

    after long searches we have found the answer to what triggers the process


    When you check your smtp Proxy log you will find the IP Adress of the Tor Exits.
    So what is happening?

    The UTM receives a external smtp request.
    The Firewall does its Job and checks the IP (Halo,etc)
    For this it does a DNS request.
    Due there is not separate DNS Server Configuration for ,it uses the normal DNS forwarders configured in your DNS Settings.
    That are normally your internal DNS Servers.
    So Firewall asks your DNS Server.
    That is the first entry you will see in the DNS LOG at your DNS Server.
    DNS Server says it is no internal address.
    DNS Server ask Firewall
    Firewall logs it as ATP and Blocks it.

    Firewall gets no result and will ask your second DNS Server.
    and the Story repeats

    Most important is ... It is not from your internal networks.
    Maybe now we can find a solution together how we can get rid of this misbehavior of the SMPT Proxy

  • What I'm seeing in my logs it that the UTM itself is triggering the dns querys to the caching resolver it then in turn flags with the ATP.

    The remaining question for me is the cause, which triggers the UTM to query that.

    I guess this was figured out earlier already. But I still don't really see a way around the fact, that the exim needs to do the dns lookups to work.

    My understanding is that you couldn't even add an exception to the dns facing interface because the UTM is "only" the cause and the DNS Servers request/response is triggering the ATP.

    Only a threat expection would help in my point of view, but this is only workaround and my lease to false negatives due to the exceptions.

    The real solution I'd see in this case would be a logic flagging the dns response (e.g. based on source, query id, port) to the utm and not triggering the ATP alert even if it would have hit and then trigger the ATP once a connection would be made to the flagged destination.

  • Hallo Marius, your first post here - welcome to the UTM Community!

    This is an interesting problem!

    How is your DNS configured compared to DNS best practice?

    Cheers - Bob

    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Only difference to the "best practices" is that we use DMZ caching DNS servers as forwarders in step 2.

    If you'd use an opendns the communication to the DNS forwarder would through and uplink interface, maybe that's something that is different, but this is not an option for us at the moment, because this would limit us in implementing security measures within DNS.