3 Replies Latest reply on Sep 19, 2017 9:32 AM by d_aloy

    TOR and TOR-Variant Rule Objects?

    pcoates

      Hey Everyone,

       

      According to McAfee Corporate KB - FAQs for Network Security Platform KB75269  there should be existing TOR and TOR-Variant Rule objects in the NSP that can be used in the Firewall Policies:

       

      How do I block TOR and TOR-variants?

      McAfee recommends using Firewall policy to create Access Rules to define aspects/objects for blocking, allowing, or non-inspection. Under the Existing Rule objects, there are several TOR and TOR-Variant applications already defined. You can create your own Application Group with these and any OTHER P2P applications you do not want to allow.

       

      Use that application group, along with your source/destination settings to stop the majority of TOR connections and variants.

       

      However I've checked in my 8.3 deployment (Manager 8.3.7.52 and Sensor 8.3.3.27) and there are no TOR related rule objects anywhere to be found.

       

      Does anyone have any insight on this?

       

      Cheers,

       

      Pete

        • 1. Re: TOR and TOR-Variant Rule Objects?
          d_aloy

          Hi Pete

           

          You are right. That KB article is outdated and should be updated with the correct info as the 'Tor' app that used to be available on the product does not longer exist, hence you can't create advanced fw rules by using the app.

           

          On the current sigset, I believe the only tor-related signatures are " P2P: Tor Privoxy Tunnel detected" and "HTTP: Mozilla Firefox Tor user de-anonymization vulnerability"

           

          The P2P one could potentially indicate TOR traffic on the network, while the second one could indicate potential TOR clients.

           

          The problem with blocking TOR is that the TOR connection once established looks like TCP/443 traffic, so HTTPS/TLS/SSL. The best option to block the traffic would be to block the TOR exit nodes, but this would require to maintain an ACL type list (either on the fw or you could create a UDS/SNORT rule), but again, this would require regular review and updating as new nodes appear and old ones disappear.

           

          As other application aware security solutions out there, I do not see a reason why McAfee could not re-add the TOR app, since I'm quite sure they have the people and resources to keep the app up-to-date with the correct IP addresses and potentially other IOCs, and this app could be regularly updated with the sigset releases.

          And it would make our life much easier too

           

          Just my two cents though...

           

          HTH.

          Regards

          David

          • 2. Re: TOR and TOR-Variant Rule Objects?
            pcoates

            Thanks David,

             

            I figured it was from an older release but only have an 8.3 running at the moment.

             

            Once we start talking about blocking exit and entry nodes I'd generally recommend another gateway networking device or Web Gateway device before utilizing the IPS, something we can automate list control/updates. The McAfee Web Gateway has a maintained list for "Tor Entry Point IP Ranges", most likely collected and parsed from dan.me or somewhere similar. This would be my go to if I have it available, essentially maintenance free. Endpoint control is the key factor with TOR in my opinion after doing what you can at the gateway, since it's so easy to obfuscate the TOR connection with most of the popular clients.

             

            I've asked an SE to submit a request to have the FAQ updated if someone doesn't see this post first.

             

            Thanks for the Reply!

             

            Pete

            • 3. Re: TOR and TOR-Variant Rule Objects?
              d_aloy

              Hi Pete

               

              Glad we could help. As previously mentioned, many other security devices have such lists to block TOR or other elements (IP, URLs, domains..etc). Since NSP previously had the capability, it would be nice to have it back... so we can enforce at the IPS... I don't manage the gateways ... so I wouldn't trust them!

               

              Cheers

              David