Skip navigation
McAfee Secure sites help keep you safe from identity theft, credit card fraud, spyware, spam, viruses and online scams
3500 Views 9 Replies Latest reply: Dec 19, 2012 7:41 AM by ron.sokol RSS
hbss_admin Apprentice 88 posts since
Aug 6, 2010
Currently Being Moderated

Mar 19, 2012 4:30 PM

Exceptions to HIPS signatures sometimes don't seem to be applying

I've found that fairly often HIPS will block some processes from running even though there is an exception created to allow a certain activity to happen. And sometimes, even an exception that was working correctly will suddenly start blocking a process that was supposed to be allowed. In another case, I had a set of Exchange Clusters that keep getting blocked by a signature that had an exception created for it so I had HIPS automatically create an exception, and it still kept blocking the process

 

Can anyone tell me why?

 

Anticipating in advance some of the standard questions, I *am* checking the IPS rules policies applied to the specific OU this system resides in.  The systems are successfully checking in to the ePO server and apparently getting policy updates.

 

The exception rule is fairly broad; "all users" are allowed to run a specific authorized process, no advanced details are specified. In most cases the rule was created automatically by HIPS ('Create exception'), and edited to make it relevant to a broader set of users/hostnames.

 

Just speculating out loud, a couple of things come to mind that I wondered if it was relevant or not.

 

For one, I stuck with the default "Exception name" field when creating exceptions. If multiple exceptions were created based on the same signature, would having duplicate exception names maybe cause HIPS to scan just the first exception and skip the second exception? (I noticed in many cases, when the exceptions wouldn't successfully apply there were multiple but separate exceptions to that particular HIPS signature).

 

Another thing I wondered about, even though a machine appears to be successfully communicating with the ePO server, how can you tell for sure that it's actually receiving and applying any policy changes?

 

PG

  • masten Apprentice 38 posts since
    Mar 3, 2010

    I would start by looking into the HipShield.log which contains detailed information about triggered signatures and would probably give more clues to why your exception is not working.

     

    By default, on Windows 7, the HipShield.log is located under C:\ProgramData\McAfee\Host Intrusion Prevention

     

    /Magnus

  • Kary Tankink McAfee Employee 655 posts since
    Mar 3, 2010

    You might need to open a Service Request to have this reviewed further.  With HIPS debug logging enabled, we can compare the exception and violation together to ensure that match properly.

     

     

     

    For one, I stuck with the default "Exception name" field when creating exceptions. If multiple exceptions were created based on the same signature, would having duplicate exception names maybe cause HIPS to scan just the first exception and skip the second exception? (I noticed in many cases, when the exceptions wouldn't successfully apply there were multiple but separate exceptions to that particular HIPS signature).

     

     

     


    When adding IPS Exceptions via an event, the Exception name will carry over to the event, but once you edit the Exception, you can change the name.  Exceptions with duplicate names is not known to cause any issues that I've seen.

     

     

     

    Another thing I wondered about, even though a machine appears to be successfully communicating with the ePO server, how can you tell for sure that it's actually receiving and applying any policy changes?

    Since the HIPS Client UI doesn't have much configuration to display, the method I've used (for basic checking) is firewall rule changes.  Those are displayed visibly in the HIPS Client UI console.

  • damageinc Apprentice 51 posts since
    Nov 22, 2011

    This is interesting, because we have this EXACT same issue.  Some random signature will suddenly start firing on some process we've already allowed via exception.  Then, the only solution is to re-save the IPS Rules policy, perhaps with the original exception re-created, in a flurry to try to prevent the possible outage or user impact that the block was causing.

     

    It is very frustrating.  This has happened a couple of times in the last year.  In both cases, we've opened support tickets, but it required us to submit various log files and MERs, but by the time we could collect those logs, we had already fixed the issue through the standard "re-save the policy" trick, so our logs were pretty much useless.  Makes no sense at all.

     

    In one case, nothing happened policy-wise that would have even caused systems to refresh their policies, and in another case, it strangely corresponded to a HIPS content update that was pushed out to clients, but the offending signatures were not ones that were changed in the content update.

     

    I suppose I'm glad that this is now a semi-documented issue, and that this is not just happening to us, so we have somewhere to point when we're asked for an explanation when this happens again.

  • Kary Tankink McAfee Employee 655 posts since
    Mar 3, 2010

    hbss_admin wrote:

     

    Kary Tankink - do you know if it might be possible that if there's a large number of exceptions in a policy that it might start reaching a limit where it starts to get unreliable? i.e. if the number of exceptions created in a policy starts to get large, say more than 100 or so, does the policy start to gag or something?


    I don't have any specific information/solutions about this, but if you are having issues like this, I would definitely get McAfee Support involved. In regards to a large number of exceptions, I would recommend following best practices on policy management (if you already aren't doing so).   The IPS Rules and Trusted Application policy are multi-slot policies, so instead of trying to run with a single large policy, instead use smaller policies to manage exceptions.

     

    See page 38, section FAQ — Multiple-instance policies for details on how multi-slotting policies work within Host IPS.

     

    PD22894 - Host Intrusion Prevention 8.0 for ePO 4.5 Product Guide

  • ron.sokol Apprentice 72 posts since
    Nov 17, 2009

    Any updates on this, HBSS?  Similar issue here.

  • greatscott Champion 283 posts since
    Jul 18, 2011

    There is likely a deeper root to the issue, but sometimes when clicking "create exception" on an event, versus trying to create a manual exception will ease the issue. Some people may be having these same symptoms described in this thread, but may not have the same root problem.

  • ron.sokol Apprentice 72 posts since
    Nov 17, 2009

    Thanks for updating - our issue is HIPS 8, similar intermittent issue impacting hosts tagged for a policy deployment with assignment rules.   In our case traced to faulty ePO extension for HIPS.  Updated, and OK.  Only additional item was that policy assignment rules had to be 're-saved' before the issue was corrected.

More Like This

  • Retrieving data ...

Bookmarked By (0)

Legend

  • Correct Answers - 5 points
  • Helpful Answers - 3 points