Yes in Hip 7 was some handling issue with local traffic which resulted in allowed send out packets from localhost which then were dropped when they came back. This was fixed. It may be a different issue here with Hip 8.0. Check if you block the application Internet Explorer itself (first possibility) then you could check if you currently do not use "Include local subnet atomatically" within General - Trusted Networks (second possibility).
If it still fails double check with an allow all rule on top of the ruleset. If everything fails look for Tracemon to collect the stateful firewall output during communication to see what happens to outgoing and incoming packets related to each other. That would be a point to best open an SR for it.
I have tried making a 127.0.0.1 to 127.0.0.1 IN/OUT rule and putting it up top, but it didnt work.
The "Local" address is not typically 127.0.0.1, as the HIPS Firewall records it, but a local non-loopback IP address (or 0.0.0.0). As a workaround for now, create a firewall rule that allows this application traffic, but set:
1. New (Local) - "Any local IP address" <----(new option in HIPS 8.0 Firewall)
2. New (Remote) - 127.0.0.1
It makes no difference if the connection is isolated of not. If i isolate it the 'rule' that is apparently blocking it is '%CAG Group Name%' , if it is not isolated then the rule ''Block All Traffic' Rule blocks it.
I might be wrong but. . .its a bug.
I am not using Trusted Networks, or Trusted Network based rules, and there are no rules to block iexplore.exe or firefox.exe on an application basis, otherwise, the blocking rule triggered would show in Log.
Do you want me to raise a SR .. or, can you raise this internally wiith the HIPS product manager please?
you are correct.It says from 'Local' rather than 127,0.0.1. I have no ideas what HIPS considers 'local' as. I have tried your suggestiong of 'All Local IPs' IN/Out to 127.0.0.1 and it did not make any difference. I put this rule above the CAG, then even IN the CAG
I just ran through some logs with another customer who reported a strikingly similar issue. However once they allowed localhost traffic it was working fine so it very well could be a different issue. I believe opening an SR would get more attention unless we really could reproduce it the same way internally which I had not so far.
Try this: -
1.With HIPS 8.0 firewall enabled from run command. type \\127,0,0.1\c$ (assuming you have this default hidden admin share enabled)
2. authenticate with credentials with local administrative rights.
3. Look at the HIPS 8.0 log.
you should see that it blocks access from 'Local ' to 127.0.0.1 and the share is not shown (This is even with that rule suggested in place)
Now try it with the firewall disabled. . .. it works. . .
let me know your results
1 of 1 people found this helpful
I'm pretty sure this is a bug as well... I have a case open on this with McAfee. Unsure of status at the moment.
Oddly enough I have found that Yahoo Messenger will use localhost as a source instead of the system's actual IP address. Whenever localhost is used, the outgoing traffic is blocked. Whenever the actual IP is used, the traffic is not blocked. I have a basic rule that says allow all TCP/UDP outgoing, so it should work fine.
I also tried adding special 127.0.0.1 rules into my CAG, and it still didn't work. However, as soon as I moved my outgoing TCP/UDP rules outside of the CAG, it worked fine. Appears to be something specific with the CAGs.
This was a policy I had migrated from HIP 7 to HIP 8... used to work fine with 7 but has this bug in 8.
I will also open a case with McAfee
Any updates on this? I have done a recent pilot rollout and experienced the same problems with local/127.0.0.1 traffic blocked. I have now stalled the rollout and will continue using HIPS 7 until this is sorted. Cheers!
I haven't heard anything besides updating all of my policies with a 127.0.0.1 rule outside of any CAGs. This is a ton of work for me so I would rather wait for a proper fix. Guessing it won't be until at least Patch 1, but I haven't heard anything official.