This tutorial tries to show the first common steps you could perform if you’re new to ossim and just finished installation, without knowing what to do next.
The tutorial will cover:
- Policies
- Initial Inventory
- Scans
- Scheduled scans
- What to do next
Many topics we’ll cover on this tutorial can be extended checking the documentation wiki.
BREAK
Asset definition: the quick way
Ok, first we should populate our asset database a bit. I’m pretty sure I know my home network/testing environment pretty well, but this could change on a larger scale network or an unknown environment.
The first thing I’ll do is to ask the administrator (that is, myself) about the networks we’ve got and which are directly or indirectly seen by ossim.
The answer is two networks:
- Public/internal network, connected to the gateway. It’s a class C network in the 192.168.1.x range.
- Private/internal network, the one served by my AP. It’s a class C network too but since dhcp assigns addresses starting at 10.0.1.2 and I’ve got only a couple of hosts I’ll choose a smaller network (/28)
Networks
So let’s start by adding those networks with a default priority and rrd profile, without nessus scanning activated:
(Image removed, broken link, I’m very sorry. DK.)
Networks are very important and you should define as many as you’ve got, even if ossim is not directly connected to them. This is because hosts defined in DB or belonging to a network are being treated differently and more information for them is being used (Passive OS and Service information only gets saved for defined hosts/hosts belonging to defined networks).
Network groups
Network groups are being used to aggregate information in case you’ve got many networks. In my case it’s ridiculous, but we’ve got customers with hundreds of networks where they couldn’t live without this feature :-)
You can group by any criteria you want, either division, building, network ranges, whatever:
(Image removed, broken link, I’m very sorry. DK.)
In this case we’re raising the threshold a bit since aggregated networks are supposed to raise more events than individual hosts / networks. 100 may be too low, but it’s a matter of practice / experience and varies for each environment.
Group information is specially useful for risk related panels, such as aggregated risk and riskmeter, preventing your pages from growing too much. Individual networks will be highlighted if their compromise or attack gets over their threshold:
(Image removed, broken link, I’m very sorry. DK.)
Hint: If you click on the colored area of the risk graph you’ll be redirected to the hosts involved in that risk peak. If you click on the host you’ll get redirected to the event listing that has created that risk situation.
(Image removed, broken link, I’m very sorry. DK.)
Netscan
So, next we would like to define a couple of hosts in order to personalize their asset information and to run reports and scans on them, and not on the entire network.
Hosts can be inserted manually as we’ll see on the next point, but it’s much easier to let ossim scan them using nmap and give some default data for all of them to be inventoried. Again my example is a bit short on hosts (only two), but think about a bunch of class C networks and the work you could save.
So we get to tools->netscan, select our private network and voila:
(Image removed, broken link, I’m very sorry. DK.)
Note: depending on the size of your network this may take a while, and an php timeout would make this page unusable. You might want to increase php’s max data size and session expiration.
Hosts
Since I don’t really want to wait for a scan on my other class C network I’ll insert them manually, as seen on the next images.
(Image removed, broken link, I’m very sorry. DK.)
As an added benefit, you’ll be able to see all the collected information about each host you define here:
(Image removed, broken link, I’m very sorry. DK.)
Groups
Now we’ll do our first nessus scan. Let’s scan only the workstations, leaving the gateways untouched. We could enable them one by one, yes, but again that can get tiring for many hosts. The ideal solution is to create groups (you can create as many as you wish, having hosts in different groups too) so you can later on apply separate scan types and schedules on them.
Let’s create a simple one, as said, only workstations: (we’ll use it later)
(Image removed, broken link, I’m very sorry. DK.)
OCS Inventory
Having extended inventory information from your hosts is also useful. See the old tutorial on OCS for more information on how to setup OCS. Hint: execute the installer as part of your logon scripts on a domain, that way you’ll get a lightning fast inventory of your whole network.
Nessus Scan
Using the group we created before, we’ll check how vulnerable my workstations are.
(Image removed, broken link, I’m very sorry. DK.)
Unf, 8. That’s not much, but taking into account that each vulnerability can have a level ranging from 0 to 10, I should look at the reports by clicking on the host.
Aaah, almost forgot it. Since my vulnerability_incident_threshold at configuration->main is set to “0″, every vulnerability with level 0 or higher will create a new incident too, as we can see here:
(Image removed, broken link, I’m very sorry. DK.)
Note: Vulnerability incidents are able to handle false positives too. If you close it and tag it as false positive, it won’t be opened on the next scan. But be warned, if you close it and it’s not tagged, it will get opened again next time. That way you’ll can happily close the incident when your sysadmin says he’s patched the hole, knowing that if he has lied he’ll have that incident on the table next month again :-)
(Image removed, broken link, I’m very sorry. DK.)
Hint: you can check to see if the scan is actually working by grepping on the agent, since the information shown during scan ain’t very verbose.
Hint2: Nessus scan is distributed, that is, ossim tries to find the sensor associated to the target in order to scan from there.
ossim:~# ps ax | grep nessus
2536 ? Ss 0:00 nessusd: waiting for incoming connections
6600 ? S 0:00 /usr/bin/nessus -c /usr/share/ossim/www/vulnmeter/tmp/.nessusrc
-x -T nsr -q 10.0.1.50 1241
/usr/share/ossim/www/vulnmeter/tmp/sensors/10.0.1.50.targets.txt
/usr/share/ossim/www/vulnmeter/tmp/sensors/10.0.1.50.temp_res.nsr
6606 ? Ss 0:03 nessusd: serving 10.0.1.50
6614 ? S 0:00 nessusd: testing 10.0.1.3
6615 ? S 0:00 nessusd: testing 192.168.1.33
6618 ? S 0:00 nessusd: testing 192.168.1.33 (/var/lib/nessus/plugins/nessus_tcp_scanner.nes)
6619 ? S 0:00 nessusd: testing 10.0.1.3 (/var/lib/nessus/plugins/nessus_tcp_scanner.nes)
6625 pts/0 R+
Schedule scans
Finally, let’s leave a scan scheduled to execute once a month:
(Image removed, broken link, I’m very sorry. DK.)
Final words
That’s all for today, it may shed a bit of light on some easy to use, basic features of ossim. If you followed these steps you can be pretty sure that you’ll start getting more and more useful information out of the system.
Check the monitors, reports and dashboards and you’ll see how your asset information starts to affect all the indicators.
(Image removed, broken link, I’m very sorry. DK.)
The next thing I’d recommend is checking out the tools at “Tools->Downloads” and install ossec and ocs, in order to get even more information out of your network’s hosts.
(Image removed, broken link, I’m very sorry. DK.)
