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

    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 

    us-cert.cisa.gov/.../aa21-321a

  • 0 in reply to BAlfson

    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?

  • 0

    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.

  • 0 in reply to astiadmin

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

    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?

    Cheers
    Daniel

  • 0 in reply to BAlfson

    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..

    br

  • 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



  • 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

Unfiltered HTML