Defensive Policy Creation: Use Cases


Defensive Policy Creation

For all of the following examples, policy configuration can be accessed in the following way.  


From the menu bar, select “Rulesets.”



Click on the policy to which the rule will be added.



Select “Rule Configuration”. From the dropdown menu, select either “Add Alert Rule” or “Add File Integrity Rule[a][b]” depending on which one you will be adding.

Now set up the rules according to the guidelines below.  Note that text of the actual alert filers and/File Integrity Monitoring (FIM) rules are provided for cutting and pasting.


Changes in a Directory

The following is a basic Alert Rule to monitor changes in a specific directory.  If your users SSH into instances and you’re interested in seeing activity on directories where keys/root keys are stored, this alert will warn you if files are altered or accessed.

The Alert Title below reminds the user that the alert will fire anytime a FIM rule is triggered.  Not only will it alert the user, but it will put the name of the file into the alert title for clarification.


Alert Name: {{rule_name}}:{{filename}}

Alert Filter: event_type=”file”

Click on “More Alert Options” to continue to configure the alert.  Be sure to select the check box next to “Enable this Alert Rule” before clicking on “Create Rule”.



Sudo to Root and Jumphosting

 The following is an alert to notify if a sudo to root command is executed.




Alert Name: Sudo Commands Run by a User

Alert Filter: (command = “sudo”) and user  != “root” and type “start”


If you’re using a jumphost to facilitate access to your systems, you need to specify the agent ID of the jumphost for the alert to fire when the sudo to root command is being run specifically on that instance.  Configure the Alert Filter as follows.


Alert Title: Jumphost Sudo to Root

Alert Filter: (command = “sudo”) and user != “root” and type =”start” and agent=”<insert jumphost agent id here>”


Web Server Configuration File Changes

You may wish to create a file integrity rule that will look for web server configuration file changes.  The following rule will monitor access to the config files, as well as whether or not the content of those files has been changed.  Apache is used as the example here, but any web server can be monitored.



Root Kits

You may want to monitor your system for evidence of any dynamically loaded code since this might be evidence of a root kit.  

Suggestion: this could be a standard policy to begin with.  However, it may create a lot of noise due to the individual system (loading kernel modules a lot, perhaps), but suppression can be used.

The following alert rule can be configured to monitor for activities that may indicate the presence of a rootkit.



Kernel Module Activity

 You may also want to be made aware when there is activity on the kernel module since they can be utilized to install a root kit and hide an eventual attack.



Alert Title: Kernel Module Activity Detected

Alert Filter: (command = “insmod” or command = “rmod”) and type =”start” and syscall=”execve” and arguments !=null


Is Curl Hiding Something?

Sometimes if  curl or wget is run from a box, it lets us know that someone is downloading something.  If you want to find out what is being downloaded and why, configure the following alert rule.


 Alert Title: Curl Downloading Something

Alert Filter: exe = “usr/bin/curl)”


Click on “More Alert Options” to complete the alert rule set up.  Be sure to select “Enable this Rule” and choose “host” from the event type.



Forbidden Conversation Between Boxes

 You may want to be alerted in the case where you have a known database server that only talks to one other instance and suddenly, it is seen talking to an unknown/new instance.  If the destination ID is unknown, an alert will be generated using the following configuration.



From this example, be sure to properly enumerate both the source and destination ips properly when configuring the alert filter.

Alert Title: Unfamiliar Destination IP

Alert Filter: src_ip like ‘000.000.00’ AND dst_ip like ‘000.000.00’


Escalation of Privileges in EC2

Misconfigured IAM profiles can be used to elevate AWS user privileges.  If an attacker can get the keys, they can escalate privileges and take any number of detrimental actions functioning as root.  These AWS access keys are typically found in the following files:


~/.boto (Python)

~/.fog (Ruby)

Irrespective of where they are held, we can set up an alert to let us know when changes on these directories are found.  The following example shows all three files, but you can configure the FIM rule according to where your keys are stored.



Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request



Article is closed for comments.