Data Center Security

Hi All,

We are in process of implementing IPS policy on Unix Servers. These server have different application running. We have already applied sym_unix_protection_sbp policy in disbaled mode (policy will log any event and sent to the DCS Server but won't block any violation).

I would like to know what is the best way to go about the whitelisting of the applicatio/processes using sym_unix_protection_sbp so that any running application won't get affacted.

Appriciate is someone can share any document, menthod to do whitelistig that can be used for the same.

Thanks in advance !!!

The best way to do this is to lock down (no access) the DEFAULT sandboxes.and create seperate, new sandboxes for the different apps that are running on your system.  That way, when any "unknown" processes that run on the machine get assigned to the default sandboxes, they will not be able to do anything.  

In the Unix policy, the default sandboxes are:

Default Daemon Options (daemon_stdpriv_ps)

Default Interactive Program Options (int_stdpriv_ps)

If you set these default sandbox rules to deny all (*) in the different sections, then you have essentially created a whitelist policy.  Anything assigned to the default sandboxes will not have access to any system resources.

At this time, there is not a Unix Whitelisting policy that I know about that will assign unknown processes to the deny_ps.(like in the Windows Whitelisting policy)

Hi Chuck,

Thanks for your input.

May I know how to exclude the events showing under int_nopriv_ps. There are certain events showing pset as int_nopriv_ps, appriciate if you can help me to understand more about these events and how to define exlusion for such events in Unix base prevention policy.

Attached are the sample events with int_nopriv_ps.

Thanks in advance !!!

Attachment(s)

Process Assignments.xlsx   41 KB 1 version

There are several ways that processes can end up in the nopriv_ps.

To find out, you need to trace the lineage of the process back to its root -- who is its parent, grandparent . . . etc.

Once you figure out where the process spawned from, you will know what sandbox you need to edit.

One I recently came across that was a bugger was stuff running in the inetd_ps sandbox.  Any child that is spawned from a process that runs in the inetd_ps is automatically sent to the nopriv_ps.  In the inetd sandbox,you will see at the top of the general section "Specify in the list below programs to route to Daemon Stdpriv" and that is where you tell it what child process to assign to Daemon StdPriv.

This may or not be what you are running into, but I recently came across that.and it may help.

But like I said, tracing the processes back to their root is the way to go.  To do this, make sure you have process assignment logging enabled globally, roll over the logs on the agent (to make sure there is room and the log wont roll over in the midlle of a reboot), then reboot the system. 

After the system boots, grab a Get Agent Info, and open up the SISIDSEventsXXXX.csv file and filter by type PPST (process assignment) and find the columns with the pset/sandbox, PID and the Parent PID.  Then locate the process in question that was assigned to the nopriv_ps.  Then find its parent PID, and move to that PID, and repeat until you find the process that is NOT assigned to nopriv_ps, and that is the sandbox where you need to make changes.

Another thing I have seen are processes assigned to nopriv_ps is if you have any of the checkboxes in the default sandboxes check that say "Do not allow X to start"  For instance the mysql_ps has that function.

Hi Chuck,

Based on our deployment of policies during our Windows Implementation, we initially whitelisted the processes under the int_nopriv_ps and svc_nopriv_ps using a custom sandbox. We categorized each processes and applications per custom sandboxes. Not allowing these processes resulted to denied/blocked events. Once the custom sandbox has been defined, the network and file accesses will start to be logged on that custom sandbox. That is the time that we configure the policy by adding the events logged on that custom sandbox.

Now, the policies on unix deplyoment has changed. There is an application rule in policy wherein we can put the nopriv events. My question now is, should we whitelist all of nopriv events under the application rule just like the 6.0 windows policies (deny_ps) or create a custom sandbox per process/application?

Thanks in advance !!!