7 Replies Latest reply on May 20, 2009 3:26 AM by SergeM

    HIPS blocking localhost !?

    SergeM
      Hi,

      Users have been reporting unusual errors lately, so I went and checked HIPS logs (using HIPS 7.0.0.976 and VSE 8.5.0.781).

      In the logs, I see a lot of blocked connections to and from 127.0.0.1 (aka localhost).

      In particular, I see connection attempts "from LMS.exe source: 127.0.0.1 to localhost:16992". I was able to trace this particular connection to Intel® Active Management Technology (Intel® AMT) which seems legit.

      On another system where we had an test webserver, connections through the network are accepted, but http://127.0.0.1/index.html is blocked.

      Now this happens on systems where I haven't touched the FW Rules (or HIPS settings in general) in a long while. So I'm wondering whether something might have changed in the way HIPS is handling localhost.

      Do I (we) now need to explicitly declare localhost (127.0.0.1) as a trusted address ?
      Is there something else ?

      any ideas ?
      Serge
        • 1. RE: HIPS blocking localhost !?
          I am not really surprised by this behaviour, sounds 'normal' to me.




          Just an idea though, does your hosts file in c:\Windows\system32/drivers/etc have an entry for:


           

          127.0.0.1 localhost




          If it doesnt. . . .it should



          On another system where we had an test webserver, connections through the network are accepted, but http://127.0.0.1/index.html is blocked.

          But specifying the local machines network IP address and trying to access index.html works?

          J






          • 2. RE: HIPS blocking localhost !?
            SergeM


            localhost is defined on every machine.
            However it seems that 127.0.0.1 is not considered "safe" by HIPS. How is this "normal" ? It's the first time I see that localhost is not safe (trusted)...

            As for your other question : yes.
            Assuming the machine's IP is 192.168.25.14 and has a webserver installed. From a browser on the server, typing

            http://192.168.25.14/index.html works

            http://127.0.0.1/index.html does not work.

            Now, when you install Apache (e.g. WAMP) on a system it uses 127.0.0.1 as a test

            With this (faulty?) behaviour, the tests always fail.
            • 3. RE: HIPS blocking localhost !?
              the NDIS firewall drive sits on the system at a very low level in software, so i guess it does not know about 127.0.0.1 passing the NDIS network card/driver , as only ''include local subnet automatically' is included in the Trusted Networks by default.

              Even so, you will still need to create rules allowing traffic flow to 'trusted networks'. Adding subnets to the Trusted Networks list is only a way of 'tagging' subnets for use within the firewall rules policy (you choose Trusted under the Address as opposed to Any,Range, Domain etc or the other options) , it does not mean that they are automatically excluded from all firewall rules, you may have already known this. :)

              regards

              J
              • 4. Add 127.0.0.1 to TN to fix McAfee bug!
                SergeM
                Hi,

                Thanks for your answer, I disagree on more than one point.

                Fact is, we have rules that have been working for over 5 years(*). I've been using HIPS for a year and the rules worked fine. Since I patched HIPS, those rules don't work any more.
                I investigate and find that all of a sudden HIPS behaves as if localhost is not to be trusted, and I have all my users complaining that "nothing works any more".

                Why do I have to patch rules that were fine because HIPS changes? Additional, this blocks most of Windows' internal mechanism as processes access several services through calls to localhost that are now blocked!

                Second, we consider here that "include local subnet automatically" may be the most dangerous thing to do. We use HIPS mostly on laptops. Those travel and are not always in our network (hence the necessity for a local FW). So, the local network essentially is not to be trusted (for laptops or mobile PCs)!

                But 127.0.0.1 should IMHO always be trusted... it's the one thing that oughta be trusted by default

                Serge


                (*) we were using Mcafee Desktop FW and adapted our rules in the meantime.
                • 5. RE: Add 127.0.0.1 to TN to fix McAfee bug!
                  That does sound strange, if it has been working previously, i did not realise that, i thought it was only a new application that was causing it.



                  I do agree with the concerns about Trusted Networks, i myself have also chosen not to use them for that reason. CAG and CAG rules work best, as criteria can be defined by more that just subnets, which is only what trusted networks provide. The only reason i mentinoed Trusted networks is because you mentinoed trusted address's in your first post, so i was assuming you may have tried experimenting with Trusted Networks.


                  Not sure what else to suggest.

                  regards

                  J
                  • 6. RE: Add 127.0.0.1 to TN to fix McAfee bug!
                    JeffGerard
                    Localhost traffic being blocked is as designed in Patch 4 for HIPS7.

                    From PatchReadme.html:

                     

                    Known Issues
                    Issue: Inbound traffic to Localhost (127.0.0.1) is blocked after upgrading to Patch 4.

                    Workaround: Create new firewall rules as needed to allow this traffic.



                    In the past it was not "normal" behaviour but now it is.
                    • 7. Thanks !
                      SergeM
                      Thank you Jeff,

                      I'd been looking for that info and couldn't find it (I did read the readme, but this somehow kept evading me :confused:).

                      So now I know where it comes from. (Wish I knew why McAfee did this).

                      It seems to disrupt quite a lot of IPC here.

                      Serge :cool: