Critical System Protection

How do I profile applications? I have setup several applications/services in the 'Profile Lists' section of an IPS policy (copied from sym_unix_protection_sbp).  But nothing gets logged in the profile section of the event Monitor. Are there additional steps that need to happen?

Hi Tim,

The process you explained above should profile the process. I would check for a few items:

1. Make sure your path name is correct as well as any arguments required for the service startup. If not known use wildcard at the end of the path. I.e. /path/to/service.exe*

2. Make sure the process is not already confined in a BCD pset map. How can one find this out? There is an undocumented commend in the sisipsconfig tool (windows and Unix).

sisipsconfig -pset

or Nix

sh sisipsconfig.sh -pset

This will provide you a complete list of every process on the machine and where CSP's IPS has assigned the process . In 5.2 release the IPS driver was modulized, so it will start with the caller DLL. The listing will indicate if a proc is sent to a specific pset with correlating BCD or a generized bucket (safe_priv, std_priv, etc...)

Make sure the process is not already in a specifically controlled pset/BCD, this may be interfering with the profiler.

3. Lastly, try one process at a time in the profiler list, not multiple.

Very useful thanks. But you mention that the process may already be in a specific pset/BCD and that may interfere. If so, how do I change which process set the application/process/service is a member of? Would this not change automatically when you add it to be profiled (profile_ps)?

I was able to get this working in a test environment for one executable I added to the system. I simply adjusted the prevention Configuration to log ANY event type. Looks like it may not have been logging the right event types out of the box. Either way I still need to test in our production environment for processes already assigned.  Will keep working on it as I still need to be able to profile any process. Thanks.

FYI be careful when cutting and pasting from word into the forum under plain text mode as it may include sensitive data about your machine. (Caught myself once, switch to plain text view before saving to make sure meta-data isnt copied over)

Good that you got it working and it seemed to be event type related.

My comment above is for strictly controlled processes sent to "relaxed" settings. But let’s dig into how the pset mapping logic works and hopefully I may be able to correct myself.

For this discussion let’s focus on the Unix PBR (process binding rule).

PBR as a top level explanation is the hierarchical rule set which when any process is spawned the IPS driver runs down the PBR “tree” to find an appropriate Process set (PS) which includes PSET Map macros (jump points). PS's  have a binded BCD (behavior control description) that controls the behavior of the process. So the PBR is an inheritance based rule logic where if specific circumstance exist for the process (i.e. a psetmap matches the process path, or user some defined option is check) then the associated BCD is applied.

Since we are looking at a top-down view of the PBR there are specific macros in each process set that control each individual process set. For  example under each *_ps in the PBR there is usually a set "grouped" of psetmap Macros. Think of psetmap macros as the "extra" sifting the process set (PS) performs before actually assigning the process to the *_PS container.

Such as this:


The above example performs the following:

1. Pset map checks if the process is set to fullpriv (therefore its defenitly in the fullpriv_ps)

2. pset map checks to see if the process is in the profile list (profile_ps) indicated by the administrator via and console option parameter values

3->* runs through other various checks to see if it actually belongs somewhere else in the tree (such as in a template policy, strictly controlled login daemons PS, etc... = otherwise known as "jump points')

So in this example if you have purposesly sent a process to full priv (manually) than the profiler may have issues picking up the process.

After reviewing the rest of the tree. Only processes manually sent to a specific area -  daemon full priv, will affect the profiling of the process because it is picked up in the PBR tree first (even in daemon_safepriv_ps the psetmacro is daemon_FULLPRIV first THEN profile_ps).

As you can see above after the PBR runs down the tree it eventually comes to profile_ps, which would be the catchall for the processes entering the profiler.

So to correct myself if the daemon (process) is in daemon_fullpriv, then the profiler will have issues. Any other process should profile as designed.

Hope this helps and isn't to techical. Let me know if you would like me to run down the Windows PBR.

 

Yes, I kicked myself as soon as I pasted from word and replied. I know better! :-)

As I mentioned before I had to change the logging parameters to log ANY event Type. Specifying only certain Profile events did not work. So I created a new prevention config and apply it to the server I need to profile against. Works great now. Though this is more info than I needed (for this issue) I appreciate your insight as I need to understand how IPS works all together. I had to read it several times and will continue to review and test how all this works.  Thanks again for all the help, might need it again soon.

Thanks Tim,

When I get some time I will run down the Windows PBR, its a bit more complicated as the SYSTEM "service"  - PID 8 - actually makes all the normal kernel level actions as would be found in *nix's actual kernel.

If you have any other questions with odd parts of the product feel free to shoot them on (or anything further on the PBR rundown).

The cut and paste FYI above should be directed at anyone using this forum - specifically the admins of this forum , I see this as a somewhat bad design. Can this forum be configured so it will not pick up meta data when copying. I can also use the forum to insert iFrames... we should all know how bad that can be.....