This content has been marked as final. Show 7 replies
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:
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?
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://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.
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. :)
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
(*) we were using Mcafee Desktop FW and adapted our rules in the meantime.
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.
Localhost traffic being blocked is as designed in Patch 4 for HIPS7.
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.
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.