Thread Info
  • State Suggested Answer
  • +3 person also asked this people also asked this
  • Locked Locked
  • Replies 42 replies
  • Answers 1 answer
  • Subscribers 13 subscribers
  • Views 15840 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

ATP Alerts Tor Exit Nodes

COMODDORE

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 [185.220.100.254]: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 tor-exit-3.zbau.f3netze.de [185.220.100.254]: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 [185.220.100.254]: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 tor-exit-3.zbau.f3netze.de [185.220.100.254]: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 [185.220.100.254]: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 tor-exit-3.zbau.f3netze.de [185.220.100.254]: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 [185.220.100.254]: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 tor-exit-3.zbau.f3netze.de [185.220.100.254]: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 192.168.7.250 C2/Generic-A 185.220.100.254 
2 192.168.7.250 C2/Generic-A 185.220.100.254 



This thread was automatically locked due to age.
Parents
  • 0 
    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



Reply
  • 0 
    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



Children
  • 0 in reply to Christoph Lingen
    Marius Galm said:

    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.

  • 0 in reply to Marius Galm

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

    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.

    Cheers,
        Marius

  • 0 in reply to Marius Galm

    Not sure I "see" that, Marius.  Are your DNS servers in a DMZ and can they reach the outside world without the traffic passing through the UTM?  Also, confirm they don't have the UTM listed as one of their forwarders.

    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

    No forwarders at all configured on the DNS servers, they are resolving using recursion and the root servers.

    The traffic is passing the UTM but not using it's internal resolver.

Unfiltered HTML