Protecting more than one server

Yesterday I published a quick blog which looked at what we could do an out of the box Windows server to monitor file integrity and audit/alert upon actions such as modify or deletes. This is however rather clunks and not really for business use, so next stop the open source world! Today we are going to look at OSSEC! Now before some people go mad about security and open source…. OSSEC is used in Alien Vault’s solution, is compliant with PCI and is used worldwide by loads of organisations and universities etc. Open source tools and security go hand in hand, stop with your crazy talk! Now we’ve got that rant over with let’s get onto the fun business!

OSSEC is an open source host intrusion detection solution which we can use to upgrade our auditing and alerting solution to be more feature rich and provide a centralised solution, for more info on OSSEC please visit their website –

Compliance!= Security but you need have both

PCI DSS requires that you monitor and alert on the integrity of critical files in relation to your card data environment (CDE), which is great because good practise security means you should be doing that anyway! So here we can improve our security posture and be compliant (at least with one requirement in the PCI standard).

Yo ho, h oho a GUI life for me

This isn’t for the faint hearted, no it’s not a very complex scenario in the grand scheme of thing but if you are used to packaged products where the world is a wizard this isn’t that experience.

We are going to need a bigger ship!

We are moving into the realms of dealing with more than one server and as such we will need a monitoring service. In OSSEC we have two main components:

  • The Server
  • The Agent

Wait… it’s 2018 going on 2019 and you are peddling technology that uses VM’s and needs more compute, memory, storage, patching, maintaining etc. etc. This is very true… but worry not, we are going to look at cloud options in a later post, for now we are just exploring a blinky box option (you could host this in IaaS if you so desire, the options are almost unlimited!). However, because I’m short on time I’m going to use the pre-compiled virtual machine OSSEC have created (in OVA format)

A quick download (~2.6GB) and we have an OVA ready to import into your favourite hypervisor technology, it took my about 10 minutes on a 70MBps connection…

While this was downloading I downloaded the agent for Windows:

Installing the Agent

Click NEXT

Click NEXT

Now we need to enter our server details and private key.

Now if you install this in your production environment this way, please remove 9000 internet points from your account! Automate this using a transform or I will hunt you down and shame you! (ok so I won’t do that but please automate the deployment, we aren’t in the 90s anymore).

Server Deployment

We’ve imported our OVA into our virtualisation solution and ensured we have bridged networking

We can see here that the VM is built on the GNU LINUX CentOS 7 Platform.

The VM automatically logs in:

Running ip -a gives us the IP address

Please note the following account config:

“The default password for all accounts on the system is _0ssec_. The username from the WebUI is user, and for phpMyAdmin it is root” –

Once online we can see the status of the services using:

sudo /var/ossec/bin/ossec-control status

We now need to extract an agent key. The command to do this is as follows:

(See for more details)

sudo /var/ossec/bin/manage_agents

We need to add an agent so choose A

We now need to provide a name:

We are going to use the name “demo”

The ID for the agent us pre-generated so if we want to use this just press ENTER

Finally this is confirmed

Next we need to extract the key

We provide the ID (002) and press ENTER


Back the Agent

We’ve now got the key! So, we copy and paste this into the agent install wizard as so:

And click SAVE

We now have the server and agent deployed. However we can see the Status of the agent is Stopped.

Click MANAGE then select START OSSEC and you will see the following:

Click Ok.

I’m running Glasswire on this machine so we can see here the agent is communicating to the server:

This is more than a two minute job!

The server component has two web interfaces, a Kibana dashboard for visuliation at the following URL (change the IP/HOSTNAME to match your environment)

From here you can click on DASHBOARD

Now you can click on OSSEC Dashboard:

We can see here logs from the OSSEC server. (as you can see this is a SS before the agent was communicating)

For managing Elasticsearch we have the Cerebro console:

Enter the Node address:

Click Connect

We can now see a view on the Elasticsearch status.

Clicking on nodes will give us some service performance and capacity stats:

Agent Configuration

The agent installation by default is to the following location:

C:\Program Files (x86)\ossec-agent

Here we can see a few key files:

Ossec.conf – this contrains the configuration

Ossec.log – the agent log file

Looking at the log file we can see it is monitoring a number of items in the registry by default (amongst other areas)

Monitor all the things!

Now that we have the server and agent deployed you may be wondering, what about the configuration. That’s a very good point.

On the OSSEC server the installation is in the following path: /var/ossec

In this folder we have a number of files including a range of configuration files.

If we CAT the ossec.conf file we can see the configuration:

cat ossec.conf

<!– OSSEC example config –>




<email_to>[email protected]</email_to>


<email_from>[email protected].</email_from>


























































<!– <include>policy_rules.xml</include> –>















<!– Frequency that syscheck is executed — default every 20 hours –>



<!– Directories to check (perform all possible verifications) –>

<directories check_all=”yes”>/etc,/usr/bin,/usr/sbin</directories>

<directories check_all=”yes”>/bin,/sbin,/boot</directories>

<!– Files/directories to ignore –>







<!– Check the file, but never compute the diff –>








































<!– Active Response Config –>


<!– This response is going to execute the host-deny

– command for every event that fires a rule with

– level (severity) >= 6.

– The IP is going to be blocked for 600 seconds.








<!– Firewall Drop response. Block the IP for

– 600 seconds on the firewall (iptables,

– ipfilter, etc).







<!– Files to monitor (localfiles) –>






























Ok so this is a long config file, but I wanted you to see how much can be configured out of the box, let alone with custom configurations.

Email Alerting

To configure email alerting, we need to log onto the server (either via console or SSH etc.) and edit the configuration file:

sudo nano /var/ossec/etc/ossec-server.conf

If you install OSSEC from scratch you can configure this on install, however since I used the OVA for this demo we are going to need to edit the file to include an SMTP server, email from/to and enable email notifications. I’m not able to demo this at this second as I’m not working in a lab with an SMTP service, however this looks fairly simple to configure (remember to allow connections from the SMTP service from the management server IP etc.)

Monitoring web.config

To monitor a specific file, we need to use the SYSCHECK feature of OSSEC.

I’ve not got time at the minute to run through all the details but if you read the info from the URL above it should give you a good idea on what is required.


So that’s all we have time for tonight, in part 2 I’m going to look at how we tie this all together. Hopefully that’s shown that without hefty license fees you can setup a centralised solution. Now remember, the OSSEC toolset does far more than just file integrity monitoring (as you probably saw from the contents of the config and the OSSEC website)

The installation/OVA deployment here hasn’t been hardened and there’s a lot more to consider for production deployments, however hopefully this helps people realise that deploying security capabilities that are scalable is easily achievable with the right understanding of the tool landscape and if you understand your technology architectures. Stay tuned for more defensive security tips at Threat Week! See you for part 2 in the near future!

Leave a Reply