Thread Info
Options
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

    Hi and welcome to the UTM Community!

    What do you see in the  Advanced Threat Protection log at 2021-10-27 12:50?

    Cheers - Bob

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

      Hi Balfson

      The ATP reports the standard, a threat has been detected as per bellow

      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.

      Details about the alert:

      Threat name....: C2/Generic-A
      Details........: www.sophos.com/.../C2~Generic-A.aspx
      Time...........: 2021-10-27 12:50
      Traffic blocked: yes

      1
      192.168.7.250
      185.220.100.254
      C2/Generic-A
      AFCd
      2021-10-27 12:50:49
      1
      7.14
      1
      7.14
      2
      192.168.7.250
      185.220.100.254
      C2/Generic-A
      AFCd
      2021-10-27 12:50:49
      1
      7.14
      1
      7.14

      The traffic then points to our  DNS forwarder: ( AFCd UDP C2/Generic-A 192.168.7.250 →1.1.1.1)  after parsing the logs from our internal DNS server i can see the requests from our UTM to the Exit node going through our external DNS forwarders, but no idea to what is causing the UTM to contact the Node, my idea initially was based on a DNS query on an Spam email received by the SMTP proxy but not entirely sure... 


      07FC PACKET 000000B9471601E0 UDP Rcv 192.168.7.254 c213 Q [0001 D NOERROR] A (10)tor-exit-3(4)zbau(7)f3netze(2)de(0)

      07FC PACKET 000000B946134120 UDP Snd 1.1.1.1 0735 Q [0001 D NOERROR] A (10)tor-exit-3(4)zbau(7)f3netze(2)de(0)

       0678 PACKET 000000B946134120 UDP Snd 1.0.0.1 0735 Q [0001 D NOERROR] A (10)tor-exit-3(4)zbau(7)f3netze(2)de(0)

      • 0 in reply to COMODDORE

        May we see the relevant log lines from the ATP 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

          Balfson,

          This are the most up to date logs of a fresh incident, as per the SMTP proxy the utm is rejecting a connection from a tor node, that im trying to decipher why the constant attempt connections, as we have no internal hosts using mail servers 

          SMTP PROXY
          2021:11:07-06:43:35 srvutm-1 exim-in[6731]: 2021-11-07 06:43:35 SMTP connection from [185.220.100.243]:4524 (TCP/IP connection count = 2)
          2021:11:07-06:43:50 srvutm-1 exim-in[4881]: 2021-11-07 06:43:50 SMTP connection from tor-exit-16.zbau.f3netze.de [185.220.100.243]:4524 lost D=14s


          ATP
          192.168.200.104 C2/Generic-A 185.220.100.243 192.168.7.250 C2/Generic-A 185.220.100.243
          192.168.200.103 C2/Generic-A 185.220.100.243
          192.168.200.113 C2/Generic-A 185.220.100.243
          192.168.200.104 C2/Generic-A 185.220.100.243
          192.168.7.250 C2/Generic-A 185.220.100.243
          192.168.200.103 C2/Generic-A 185.220.100.243 192.168.200.113 C2/Generic-A 185.220.100.243


          ATP LIVE LOG

          06:43:40 AFCd UDP C2/Generic-A
          192.168.200.103
          →
          1.0.0.1
          drop
          06:43:40 AFCd UDP C2/Generic-A
          192.168.200.113
          →
          1.1.1.1
          drop
          06:43:42 AFCd UDP C2/Generic-A
          192.168.7.250
          →
          1.0.0.1
          drop
          06:43:43 AFCd UDP C2/Generic-A
          192.168.200.104
          →
          1.0.0.1
          drop
          06:43:47 AFCd UDP C2/Generic-A
          192.168.200.103
          →
          1.1.1.1
          drop
          06:43:48 AFCd UDP C2/Generic-A
          192.168.7.250
          →
          1.1.1.1
          drop
          06:43:49 AFCd UDP C2/Generic-A
          192.168.200.104
          →
          1.1.1.1
          drop
          06:43:51 AFCd UDP C2/Generic-A
          192.168.200.103
          →
          1.0.0.1
          drop
          06:43:52 AFCd UDP C2/Generic-A
          192.168.7.250
          →
          1.0.0.1
          drop
          06:43:52 AFCd UDP C2/Generic-A
          192.168.200.104
          →
          1.0.0.1
          drop

      • 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

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

                We've got the same issue and we have no clue what's the source of this dns request for this tor network. I hope we all can find together a possible answer. 

                • +1

                  Hi all,  

                  we got pretty much the same, since noone is really sharing the logs here you go.  

                  I first got the threat protection alerts, there pop up every now and then ever since and look like this:  

                  2021:11:04-04:50:46 afcd[16680]:   id  =  "2022"     severity  =  "warn"     sys  =  "SecureNet"     sub  =  "packetfilter"     name  =  "Packet dropped (ATP)"     srcip  =  "<dns-resolverip-2>"     dstip  =  "176.97.158.104"     fwrule  =  "63001"     proto  =  "17"     threatname  =  "C2/Generic-A"     status  =  "1"     host  =  "185.220.100.254"     url  =  "-"     action  =  "drop"  
                  2021:11:04-04:50:46 afcd[16680]:   id  =  "2022"     severity  =  "warn"     sys  =  "SecureNet"     sub  =  "packetfilter"     name  =  "Packet dropped (ATP)"     srcip  =  "<dns-resolverip-1>"     dstip  =  "5.189.135.105"     fwrule  =  "63001"     proto  =  "17"     threatname  =  "C2/Generic-A"     status  =  "1"     host  =  "185.220.100.254"     url  =  "-"     action  =  "drop"  
                  2021:11:04-04:50:47 afcd[16680]:   id  =  "2022"     severity  =  "warn"     sys  =  "SecureNet"     sub  =  "packetfilter"     name  =  "Packet dropped (ATP)"     srcip  =  "<dns-resolverip-2>"     dstip  =  "5.189.135.105"     fwrule  =  "63001"     proto  =  "17"     threatname  =  "C2/Generic-A"     status  =  "1"     host  =  "185.220.100.254"     url  =  "-"     action  =  "drop"  
                  2021:11:04-04:50:48 afcd[16680]:   id  =  "2022"     severity  =  "warn"     sys  =  "SecureNet"     sub  =  "packetfilter"     name  =  "Packet dropped (ATP)"     srcip  =  "<dns-resolverip-2>"     dstip  =  "192.174.68.104"     fwrule  =  "63001"     proto  =  "17"     threatname  =  "C2/Generic-A"     status  =  "1"     host  =  "185.220.100.254"     url  =  "-"     action  =  "drop"  
                  2021:11:04-04:50:48 afcd[16680]:   id  =  "2022"     severity  =  "warn"     sys  =  "SecureNet"     sub  =  "packetfilter"     name  =  "Packet dropped (ATP)"     srcip  =  "<dns-resolverip-1>"     dstip  =  "176.97.158.104"     fwrule  =  "63001"     proto  =  "17"     threatname  =  "C2/Generic-A"     status  =  "1"     host  =  "185.220.100.254"     url  =  "-"     action  =  "drop"  
                  2021:11:04-04:50:50 afcd[16680]:   id  =  "2022"     severity  =  "warn"     sys  =  "SecureNet"     sub  =  "packetfilter"     name  =  "Packet dropped (ATP)"     srcip  =  "<dns-resolverip-2>"     dstip  =  "176.97.158.104"     fwrule  =  "63001"     proto  =  "17"     threatname  =  "C2/Generic-A"     status  =  "1"     host  =  "185.220.100.254"     url  =  "-"     action  =  "drop"  
                  2021:11:04-04:50:50 afcd[16680]:   id  =  "2022"     severity  =  "warn"     sys  =  "SecureNet"     sub  =  "packetfilter"     name  =  "Packet dropped (ATP)"     srcip  =  "<dns-resolverip-1>"     dstip  =  "192.174.68.104"     fwrule  =  "63001"     proto  =  "17"     threatname  =  "C2/Generic-A"     status  =  "1"     host  =  "185.220.100.254"     url  =  "-"     action  =  "drop"  
                  2021:11:04-04:50:51 afcd[16680]:   id  =  "2022"     severity  =  "warn"     sys  =  "SecureNet"     sub  =  "packetfilter"     name  =  "Packet dropped (ATP)"     srcip  =  "<dns-resolverip-2>"     dstip  =  "5.189.135.105"     fwrule  =  "63001"     proto  =  "17"     threatname  =  "C2/Generic-A"     status  =  "1"     host  =  "185.220.100.254"     url  =  "-"     action  =  "drop"  
                  2021:11:04-04:50:53 afcd[16680]:   id  =  "2022"     severity  =  "warn"     sys  =  "SecureNet"     sub  =  "packetfilter"     name  =  "Packet dropped (ATP)"     srcip  =  "<dns-resolverip-2>"     dstip  =  "176.97.158.104"     fwrule  =  "63001"     proto  =  "17"     threatname  =  "C2/Generic-A"     status  =  "1"     host  =  "185.220.100.254"     url  =  "-"     action  =  "drop"  
                  2021:11:04-04:50:53 afcd[16680]:   id  =  "2022"     severity  =  "warn"     sys  =  "SecureNet"     sub  =  "packetfilter"     name  =  "Packet dropped (ATP)"     srcip  =  "<dns-resolverip-1>"     dstip  =  "176.97.158.104"     fwrule  =  "63001"     proto  =  "17"     threatname  =  "C2/Generic-A"     status  =  "1"     host  =  "185.220.100.254"     url  =  "-"     action  =  "drop"  

                  I can also find these IPs or hosts in case of the atp in the smtp.log with a connection to zbau.f3netze.de (which is incidently a big rack of tor exit nodes   ;D):  

                  smtp.log:2021:11:04-00:49:20 exim-in[18376]: 2021-11-04 00:49:20 TLS error on connection from tor-exit-1.zbau.f3netze.de [185.220.100.252]:6794 SSL_accept: TCP connection closed by peer  
                  smtp.log:2021:11:04-00:49:21 exim-in[18391]: 2021-11-04 00:49:21 TLS error on connection from tor-exit-1.zbau.f3netze.de [185.220.100.252]:32658 SSL_accept: TCP connection closed by peer  
                  smtp.log:2021:11:04-00:49:22 exim-in[18393]: 2021-11-04 00:49:22 TLS error on connection from tor-exit-1.zbau.f3netze.de [185.220.100.252]:20700 SSL_accept: TCP connection closed by peer  
                  smtp.log:2021:11:04-00:49:35 exim-in[18411]: 2021-11-04 00:49:35 TLS error on connection from tor-exit-15.zbau.f3netze.de [185.220.100.242]:27916 SSL_accept: TCP connection closed by peer  
                  smtp.log:2021:11:04-00:49:36 exim-in[18415]: 2021-11-04 00:49:36 TLS error on connection from tor-exit-41.for-privacy.net [185.220.101.41]:6746 SSL_accept: TCP connection closed by peer  
                  smtp.log:2021:11:04-00:49:38 exim-in[18420]: 2021-11-04 00:49:38 TLS error on connection from tor-exit-41.for-privacy.net [185.220.101.41]:16614 SSL_accept: TCP connection closed by peer  
                  smtp.log:2021:11:04-01:57:53 exim-in[28532]: 2021-11-04 01:57:53 SMTP connection from tor-exit-57.for-privacy.net [185.220.101.57]:32132 lost   D  =9s  
                  smtp.log:2021:11:04-02:07:06 exim-in[29956]: 2021-11-04 02:07:06 SMTP connection from tor-exit-3.zbau.f3netze.de (example.com) [185.220.100.254]:16350 lost   D  =14s  
                  smtp.log:2021:11:04-02:07:19 exim-in[30050]: 2021-11-04 02:07:19 TLS error on connection from tor-exit-52.for-privacy.net [185.220.101.52]:21002 SSL_accept: TCP connection closed by peer  
                  smtp.log:2021:11:04-02:07:30 exim-in[30064]: 2021-11-04 02:07:30 TLS error on connection from tor-exit-39.for-privacy.net [185.220.101.39]:3820 SSL_accept: TCP connection closed by peer  
                  smtp.log:2021:11:04-04:49:30 exim-in[22125]: 2021-11-04 04:49:30 SMTP connection from tor-exit-4.zbau.f3netze.de [185.220.100.255]:31086 lost   D  =9s  
                  smtp.log:2021:11:04-04:50:45 exim-in[22329]: 2021-11-04 04:50:45 TLS error on connection from tor-exit-3.zbau.f3netze.de [185.220.100.254]:23528 SSL_accept: TCP connection closed by peer  
                  smtp.log:2021:11:04-04:50:49 exim-in[22357]: 2021-11-04 04:50:49 TLS error on connection from tor-exit-61.for-privacy.net [185.220.101.61]:12074 SSL_accept: TCP connection closed by peer  
                  smtp.log:2021:11:04-04:50:49 exim-in[22360]: 2021-11-04 04:50:49 TLS error on connection from tor-exit-61.for-privacy.net [185.220.101.61]:22906 SSL_accept: TCP connection closed by peer  

                  Checking the dns-resolver log I see that the queries (which are probably the trigger for the atp) are coming from the same dmz network as our resolvers are in.  

                  More precicly the IP of the UTM.  

                  query.log:04-Nov-2021 00:49:34.459 queries: info: client <utm-ip-in-same-dmz>  #43912 (tor-exit-15.zbau.f3netze.de): query: tor-exit-15.zbau.f3netze.de IN AAAA +E(0)DV (<dns-resolverip-1>)  
                  query.log:04-Nov-2021 00:49:34.478 queries: info: client <utm-ip-in-same-dmz>  #27468 (tor-exit-15.zbau.f3netze.de): query: tor-exit-15.zbau.f3netze.de IN A +E(0)DV (<dns-resolverip-1>)  
                  query.log:04-Nov-2021 00:49:36.084 queries: info: client <utm-ip-in-same-dmz>  #29089 (tor-exit-41.for-privacy.net): query: tor-exit-41.for-privacy.net IN AAAA +E(0)DV (<dns-resolverip-1>)  
                  query.log:04-Nov-2021 00:49:36.101 queries: info: client <utm-ip-in-same-dmz>  #31538 (tor-exit-41.for-privacy.net): query: tor-exit-41.for-privacy.net IN A +E(0)DV (<dns-resolverip-1>)  
                  query.log:04-Nov-2021 02:06:51.686 queries: info: client <utm-ip-in-same-dmz>  #31999 (tor-exit-3.zbau.f3netze.de): query: tor-exit-3.zbau.f3netze.de IN AAAA +E(0)DV (<dns-resolverip-1>)  
                  query.log:04-Nov-2021 02:06:51.708 queries: info: client <utm-ip-in-same-dmz>  #42153 (tor-exit-3.zbau.f3netze.de): query: tor-exit-3.zbau.f3netze.de IN A +E(0)DV (<dns-resolverip-1>)  
                  query.log:04-Nov-2021 02:06:54.145 queries: info: client <utm-ip-in-same-dmz>  #30893 (tor-exit-3.zbau.f3netze.de): query: tor-exit-3.zbau.f3netze.de IN A +E(0)DV (<dns-resolverip-1>)  
                  query.log:04-Nov-2021 02:07:18.885 queries: info: client <utm-ip-in-same-dmz>  #42093 (tor-exit-52.for-privacy.net): query: tor-exit-52.for-privacy.net IN AAAA +E(0)DV (<dns-resolverip-1>)  
                  query.log:04-Nov-2021 02:07:18.893 queries: info: client <utm-ip-in-same-dmz>  #27836 (tor-exit-52.for-privacy.net): query: tor-exit-52.for-privacy.net IN A +E(0)DV (<dns-resolverip-1>)  
                  query.log:04-Nov-2021 02:07:29.849 queries: info: client <utm-ip-in-same-dmz>  #41313 (tor-exit-39.for-privacy.net): query: tor-exit-39.for-privacy.net IN AAAA +E(0)DV (<dns-resolverip-1>)  
                  query.log:04-Nov-2021 02:07:29.865 queries: info: client <utm-ip-in-same-dmz>  #40659 (tor-exit-39.for-privacy.net): query: tor-exit-39.for-privacy.net IN A +E(0)DV (<dns-resolverip-1>)  
                  query.log:04-Nov-2021 04:50:44.560 queries: info: client <utm-ip-in-same-dmz>  #41455 (tor-exit-3.zbau.f3netze.de): query: tor-exit-3.zbau.f3netze.de IN A +E(0)DV (<dns-resolverip-1>)  
                  query.log:04-Nov-2021 04:50:48.579 queries: info: client <utm-ip-in-same-dmz>  #36116 (tor-exit-61.for-privacy.net): query: tor-exit-61.for-privacy.net IN AAAA +E(0)DV (<dns-resolverip-1>)  
                  query.log:04-Nov-2021 04:50:48.594 queries: info: client <utm-ip-in-same-dmz>  #40565 (tor-exit-61.for-privacy.net): query: tor-exit-61.for-privacy.net IN A +E(0)DV (<dns-resolverip-1>)  

                  Hope that helps.  

                  Best,  

                    Marius  

                  • +1 in reply to Marius Galm

                    Thank you for your summary, your logfiles are completely the same as ours. I hope that someone can check that and give us a plausible answer for this case.

                    • 0 in reply to R2D2-BipBop

                      Interesting that you are all in Northern Europe.  Instead of a bad pattern, this feels more like you all have a PC that's infected with the same malware.  Can anyone identify a device creating these requests and run Malwarebytes, CureIT, etc. to see what's the cause?

                      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

                        It seems like you don't understand our problem: We can't find any infected clients in our networks.

                        All logfiles just show the nameservers as the source of the traffic.

                        Besides I'm absolutely sure that it is no malware.

                        Check this link:

                        https://www.abuseipdb.com/check/185.220.100.254

                        It seems like a (worldwide) bruteforce attack.

                        I just want to know why our internal dns servers are answering to those requests (=> thus creating the ATP alerts).

                        The only possible reason I could think of is that out Sophos UTMs are relaying DNS requests to our internal nameservers (which doesn't cause any harm but would explain the ATP alerts).

                        • 0 in reply to BAlfson

                          Of course it seems like we all are coming from North Europe, mostly Germany, because the tor network is f3netze.de and this is a german domain. But that doesn't mean anything.

                          Like HNNG said, we checked all our clients and server, we also have Sophos Intercept X with EDR on all hosts and there is no detection alert. The time stamp when the ATP is detected is not during our regular work time. It is sometime at night and sometimes during our work time.x

                          • 0 in reply to BAlfson

                            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.

                            What I saw (see logs above) was the exim / snmp working on getting a connection to the f3netze.de or for-privacy.net servers probably to send or relay a mail to.

                            2021:11:10-17:42:27 bart-1 afcd[15872]: id="2022" severity="warn" sys="SecureNet" sub="packetfilter" name="Packet dropped (ATP)" srcip="<dns-resolver>" dstip="5.189.135.105" fwrule="63001" proto="17" threatname="C2/Generic-A" status="1" host ="185.220.100.254" url="-" action="drop"

                            This, for example, is resolving to the mail server:

                            105.135.189.5.in-addr.arpa.   21600  IN PTR mail.f3netze.de.  

                            Now why does the UTM connect to a destination IP of 5.189.135.105 but the host field in the atp it showing the Tor exit nodes IP?  This is true to most of the lines in the apt.   

                            104.158.97.176.in-addr.arpa.   1800  IN PTR b.xnameserver.de.
                            104.158.97.176.in-addr.arpa.   1800  IN PTR ns2.inwx.es.
                            104.158.97.176.in-addr.arpa.   1800  IN PTR ns2.inwx.ch.
                            104.158.97.176.in-addr.arpa.   1800  IN PTR ns2.inwx.de.
                            104.158.97.176.in-addr.arpa.   1800  IN PTR ns.domrobot.net.
                            104.158.97.176.in-addr.arpa.   1800  IN PTR ns2.anycastdns.ch.

                            same again

                            104.68.174.192.in-addr.arpa.   1800  IN PTR a.xnameserver.de.
                            104.68.174.192.in-addr.arpa.   1800  IN PTR ns.inwx.es.
                            104.68.174.192.in-addr.arpa.   1800  IN PTR ns1.anycastdns.ch.
                            104.68.174.192.in-addr.arpa.   1800  IN PTR ns.inwx.de.
                            104.68.174.192.in-addr.arpa.   1800  IN PTR ns.domrobot.com.
                            104.68.174.192.in-addr.arpa.   1800  IN PTR ns.inwx.ch.


                            This is probably really only spam in the end, but the question remaining for me is how to block these.
                            Obviously the request/mails are coming from the tor network and most like this various end hosts we see for the 185.220.100.x are just the "real world" IPs of the exit nodes.
                            What could we setup up as an exception to prevent the notifcation spam for these specific hosts we are now aware of but can't do anything against.

                            Best

                             - M

                        • 0

                          So, how did you guys handle this?

                          Did you guys just block the traffic to that subnet?

                          As I wrote a few days ago I'm sure it is nothing in our network but since we still receive ATP alerts from time to time, I just want to make sure what you guys did.

                          br

                          • 0 in reply to HNNG

                            Blocking traffic to Tor Nodes is almost impossible considering the number of Nodes \ IP subnets available and the need of keeping an up to date list of Existing nodes.

                            I had a look through the forum and other articles to try and find an way of doing this but so far it seems not possible, if anyone knows an effective way please share  

                            • 0 in reply to COMODDORE

                              It's not all tors doing this, just some bad guy at a few tors.  You can block this traffic by creating a blackhole DNAT:

                                        DNAT : {group of offending subnets} -> Any -> {Group of external IPs} : to {blackhole}

                              See #2 in Rulz (last updated 2021-02-16).  For example f3netze.de + for-privacy.net is 185.220.100.0/23.  Instead of the "Any" service you might be able to just use SMTP, but I suspect any traffic from a tor will be blocked and trigger an ATP alert.

                              Then again, if this is the SMTP Proxy trying to resolve an FQDN related to emails from other sources, it would be necessary to block or blacklist those sender domains.

                              Was anyone successful?

                              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

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

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

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

                                          • 0

                                            Have got the same "problem" for a while now. exactly the same as all described. every now and then we get ATP messages heading to our DNS servers, showing dns requests to tor-exit servers.

                                            Only thing I want to add, within the DNS server log there are a couple of "tor-exit"-server entries, not only germans.

                                            • 0 in reply to Marc P1

                                              This is very similar to the problem people have when the UTM asks an internal DNS server to resolve an external FQDN and the internal server sends the same request back through the UTM to an external name server - ATP is triggered.  Following DNS best practice might resolve this.

                                              Cheers - Bob

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

                                              Hi again,

                                              has anyone here of the people who receive the ATP alerts found an actual way to get rid of these specific ATP alerts? We still receive the alerts multiple times per week. Still from the same subnet. From my understanding there is exactly nothing to do against these dns requests. We have put the subnet into a blackhole NAT as suggested by BAlfson. Still no change and the alerts are getting quite annoying at this point. Like; someone from the subnet just has to ping us and we receive an alert. There has to be a solution for this. Or do you guys all just live with it at this point?

                                              regards

                                              • +1 in reply to HNNG

                                                still receiving these messages as well. But we didn´t do something so far. This week or next, we´ll change the DNS settings as the forwarders are pointing to internal DNS´s at the moment. 
                                                We assume this will solve the problem.

                                                Seems like these messages are generate, because a SMTP request is coming from tor, UTM checks it and forwards a dns request to internal, to verify. DNS Servers can not verify itself, so it asks its forwarders (ISP dns´s) and thats the point when the ATP message is raised.

                                                When the UTM´s forwarders are the ISPs directly, this alert shouldn´t be raisedanymore.

                                                At least this is what we think/hope/believe and our sophos partner as well. Support is still not helpfull.

                                                • 0 in reply to HNNG

                                                  ´Hey,

                                                  my way to work around it was to treat these as false positive and put these handful of host onto the threat exception list:

                                                  Advanced Threat Protection > Threat Exceptions:
                                                  185.220.100.254
                                                  185.220.100.243
                                                  185.220.100.244
                                                  185.220.101.35

                                                  I can live with that, especially because I fear that, after a while, I won't look at the alerts anymore discarding them as "again only a dns tor issue again".

                                                  Cheers,
                                                      Marius
                                                Unfiltered HTML