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

    Hi,

    just letting you know that we are currently facing the exact same issue,

    We previously thought this may be caused by someone in our network using the Tor Browser to avoid our webfilter (=> because the destination IP is a Tor exit node), but we couldn't confirm this. 

    One thing to mention: From my understanding it is not the traffic itself that is getting detected as suspicious, but the destination IP itself is.

    https://cleantalk.org/blacklists/185.220.100.254

    Even if we just ping that external IP, we receive an ATP alert from the UTMs.

    Our UTMs only show our internal DNS servers as the cause, which doesn't help.

    We have enabled DNS logging on our DNS servers, and usually when the UTM finds something suspicious, I can find the source IP in those DNS logs - but not this time.

    I went through a lot of logfiles - could you please check your UTM's IPS logfiles? Ours shows "ICMP flood detected" action="ICMP flood" where the destination IP is our mailserver's WAN interface. - But I'm not sure if this is related.

    Sorry I can't help you, but you are not alone with this problem.

    Best regards

Reply
  • 0

    Hi,

    just letting you know that we are currently facing the exact same issue,

    We previously thought this may be caused by someone in our network using the Tor Browser to avoid our webfilter (=> because the destination IP is a Tor exit node), but we couldn't confirm this. 

    One thing to mention: From my understanding it is not the traffic itself that is getting detected as suspicious, but the destination IP itself is.

    https://cleantalk.org/blacklists/185.220.100.254

    Even if we just ping that external IP, we receive an ATP alert from the UTMs.

    Our UTMs only show our internal DNS servers as the cause, which doesn't help.

    We have enabled DNS logging on our DNS servers, and usually when the UTM finds something suspicious, I can find the source IP in those DNS logs - but not this time.

    I went through a lot of logfiles - could you please check your UTM's IPS logfiles? Ours shows "ICMP flood detected" action="ICMP flood" where the destination IP is our mailserver's WAN interface. - But I'm not sure if this is related.

    Sorry I can't help you, but you are not alone with this problem.

    Best regards

Children
  • 0 in reply to HNNG

    We are getting those connection drops, too for the same destination subnet.
    Whats a bit strange is the fact that the source IP belongs to our internal Sophos SUM which manages our customer's firewalls.

    Regards,

    Kevin

    Sophos CE/CA (XG, UTM, Central Endpoint)
    Gold Partner

  • 0 in reply to HNNG

    Thanks for your input, i do believe that this are random probing and vuln scans being performed by hosts in the Tor subnet looking for potential ports or services exposed, this happens on a daily basis and most of Network admins are not aware as Firewalls or edge protection devices rebuke this probing attempts as we expect them to do, due to the ATP triggering an alert is what put us on alert mode but as long the UTM drops traffic , and all our external services or ports are not exposed i believe we are fine.

    The only thing wrong here is that traffic originating from the Tor shouldn't be allowed to use public DNS resolvers or Tor Dns should be restricted to their own Dns subnet and not touch the open common Dns resolvers 

  • 0 in reply to COMODDORE

    It's confusing when you don't just copy the full log lines here.

    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

    Balfson, i never had to dissect the ATP full log lines, so not to sure how to fetch.  Does it requires SSH ? If so what are the inputs 

  • 0 in reply to COMODDORE

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
Unfiltered HTML