Monday, October 31, 2011

Examples of ovaldi checks: sysctl variables

After I described how to compile ovaldi on CentOS and a simple test to verify it is working, in this post I'm going to describe how to use ovaldi to check the values of sysctl variables. More precisely, I'm going to check that IPv4 forwarding is turned off. The general idea behind this example is to give you a starting example on which you can build more complicated checks. Note that there is even more general idea. Namely, you can create your own security benchmarks that can check if certain security criteria are met, and if not, you can be alarmed by automatic monitoring process that is based on ovaldi.

In the text that follows I'm referencing the following file. That is a simple and complete file that will check the value of net.ipv4.ip_foward sysctl variable. After you've downloaded this file, and assuming that you have your environment properly configured (see posts I referenced at the beginning) then you can run ovaldi to do the check:
ovaldi -m -o sysctl-test.xml -a /opt/oval/share/ovaldi/xml
ovaldi will create the usual output files after running this command: ovaldi.log, results.xml, results.html and system-characteristics.xml. Each one of them you can open in a brower. You should open them and check their content. system-characteristics.xml is interesting because there you can find what information was collected about the system. Those values can be checked for in oval definitions XML file. Note that ovaldi collects only referenced data, not everything it could possibly collect.

Let us now dissect a bit oval definitions file, sysctl-test.xml. The basic structure of this file is:
<oval_definitions ...>
Basically, what oval definition does is to define a series of test, each one describing what expected state of certain object is. Test themselves can be combined in many different ways using AND and OR operators and nesting.

In our simple example object whose state we are interested in is ip_forwarding variable. So, if you look into XML file, inside element, you'll find that we define object of interest:
<sysctl_test id="oval:hr.sistemnet.oval:tst:1"
   comment="forwarding is disabled"
   check="at least one"
  <object object_ref="oval:hr.sistemnet.oval:obj:1" />
  <state state_ref="oval:hr.sistemnet.oval:ste:1" />
xmlns attribute is important. I had some problems with undefined element until I got that one correctly. In other words, all the objects, their state and tests are defined in XML documents in /opt/oval/share/ovaldi/xml directories. But, when using those be certain to correctly define namespace where they are defined, or otherwise ovaldi will complain that you are using unknown test, objects and/or states.

This particular test reference object that has to be checked and the state in which this object has to be. Object itself is defined in <objects> element as follows:
<sysctl_object id="oval:hr.sistemnet.oval:obj:1" version="1"
As you can see, within name element you specify which sysctl variable you wish to check. The second part of the test is the state in which object has to be. We want our object to have value 0, meaning forwarding is disabled. That check is performed using the following within states element:
<sysctl_state id="oval:hr.sistemnet.oval:ste:1"  version="1"
Obviously, you just place desired value within value element.

So, we saw that test consists of an object that has to be in particular state. The test itself is referenced in definition element (which is placed within definitions element). For that purpose you are using criterion element:
<criteria operator="AND">
    <criterion test_ref="oval:hr.sistemnet.oval:tst:1" comment="forwarding is disabled" />
As you can probably guess, multiple criterions can be specified and in this case they will be bound with AND operator. You can nest criteria and criterion elements to get very complex tests.

No comments:

About Me

scientist, consultant, security specialist, networking guy, system administrator, philosopher ;)

Blog Archive