Month: October 2015

Alienvault Update: Setting Up Logging

I know we sort of touched on this a few weeks back, but due to the new updates, we will need to revisit this again.

First of all, AlienVault can collect logs in a variety of ways:

a) Device sends logs = this is a classic syslog server set up. Previously we had to go through the rustic rsyslog set up etc in order to get the systems to talk to us. Not anymore. With the new updates, AV sets up easier, faster and less typing needed.

b) AV collects logs = there are several ways AV does that. One is through database plugins, where AV talks direct to the database and gets information from tables. Another way is through Windows Management Istrumentation (WMI), Security device event exchange (SDEE for CISCO).

c) AV collects through HIDS (where you install host intrusion agent for windows and LINUX)

We are going to explore the normal ways which is through a) and c). The B) method is a little advanced and we’ll look at it separately.

For basic logging, get your device to first send logs over to AV.

You will find it hard to believe, but this can be fantastically difficult, especially if your client is not up to par in terms of technicality. One example is that they are not even knowledgeable of their own network. Usually we do just a packet inspection on our interface and if I don’t see stuff coming in from your device, I handoff to you.

Except we don’t.

In PKF Avant Edge, we take responsibility even when it’s clearly NOT our responsibility. It’s silly but unfortunately it’s in our DNA to solve problems even if its not ours.

We have some experience where we troubleshoot for our clients up to firewall policies to be enabled, routing to be enabled etc. if I get 1RM everytime I hear a client say, “No firewall, no ACL! There is no filtering, problem is on your side”, I will be a millionaire. No kidding. It helps that our background is in NOC (network operations centre), so we don’t get bullied too often by network admins.

Once AV receives the logs, all we need to do is to go to ASSET -> Detail and in the tab ‘Plugins’, click on it and select the plugin to enable. Once done, your system is being monitored automatically. There should be a ‘receiving’ under the plugin. To be sure, you can go to command line and type avdevicelog (assuming you’ve put in the alias as suggested in previous post) and you should see a folder with the IP addresses of the systems you are receiving logs in. Go to the folder and just tail -f the file there.

If you see ‘No’ under the receiving data, don’t worry. AV sometimes gets confused as well. Just check the actual logs if it’s in there. Furthermore, go to avagentlog and cat agent.log | grep <pluginid>. You should see quite a fair bit of things here. For instance:

Oct 14 08:48:52 VirtualUSMAllInOne ossim-agent: Alienvault-Agent[INFO]: Plugin[1686] Total lines [14457] TotalEvents:[14457] EPS: [0.00] elapsed [10.01] seconds

This shows that Alienvault is seeing a total lines 14,457 and processing these as events. It means its working.

For an idea where its mapping, go to /etc/ossim/agent and more config.yml. You should see the device-log file mapping for example

– /etc/ossim/agent/plugins/vmware-esxi.cfg:
DEFAULT: {device:, device_id: 29b1cd29-70ac-11e5-a5e9-000c93c2e358}
config: {location: /var/log/alienvault/devices/}

If you see logs coming in but no events, remember – Logs become events become alarms.

That probably would mean your plugin isn’t interpreting the logs properly, and it’s time to dive into creating a plugin or modifying a plugin.

We recommend to copy the plugin and create a new plugin altogether.

For instance, when our Juniper logs had additional dates in there due to an intermediate logger, we created a new plugin, but used the old Juniper plugin and just changed the regex to handle the new fields and it worked terrifically.

Remember a new plugin also requires a new corresponding SQL file, which are found in avsql (if you use the alias we suggested).

Writing plugins is another article. For now, you have successfully set AV up to receive logs, create events and create alarms. No need to set up rsyslog command line anymore and no need to enable those plugins through the alienvault-setup menu. Just go asset->Details->Plugins and you are good to go!

AlienVault Update and Some Tricks

It’s been a while since we updated on AV, and that’s because we’ve been busy with some POCs and Installations.

Since the last post, quite a lot has changed about AV – and all to make it a lot easier to set it up. Before we go into a detail post on it, here are some extra tricks in creating some helpful shortcuts:

Create in /etc/bash.bashrc

alias avsql='cd /usr/share/doc/ossim-mysql/contrib/plugins'
 alias avplugins='cd /etc/ossim/agent/plugins'
 alias avdevicelog='cd /var/log/alienvault/devices'
 alias avagentlog='cd /var/log/alienvault/agent'
 alias avhidslog='cd /var/ossec/logs/alerts/'
 alias ossimlog='cd /var/ossim/logs/'
 alias configyml='more /etc/ossim/agent/config.yml'


Each of these basically will have a lot of use, and you will be going back and forth if you are implementing AV or troubleshooting it – so its best we set these aliases early.

What these mean is that instead of typing cd etc etc, we just type in avsql, avplugins etc to go to their respective directories.

AVSQL = this leads to the sql directory for the plugins, where you will need to go when you implement a plugin and put in the cfg and sql file..

AVPLUGINS = this is where you need to go for the cfg file for the plugin

AVDEVICELOG = very useful directory. Basically any log devices (devices sending logs to AV), will appear here. This is big move away from the traditional rsyslog setup whereby we need to go through all the crazy set up = over here, we just enable the plugin on the asset detail page -> Plugins and voila, it’s auto set up for you. I must say, this is well done, AV for making it less painful.

AVAGENTLOG = this is for troubleshooting the HIDS or even plugins. Agent.log should show whether your plugins are working or not. Just cat agent.log | grep <pluginid> for an idea whether the plugin is correctly loading.

Now, this is a quick one, but the new version 5.2 is out already and it really solves some issues.

Here is a snapshot!

  • Underlying OS upgrade
  • AlienVault USM and OSSIM v5.2 include an update to the underlying operating system to improve general performance, stability, and reliability. The AlienVault OS is based on Debian, which will update from Debian 6 ‘Squeeze’ to Debian 8 ‘Jessie’. All libraries, kernel, and software will be updated; therefore the update option is only available from the AlienVault Setup menu (both online and offline), not from the web interface. Note: Please read the instructions prior to upgrading

Improvements for USM only: 

  • Rapid report delivery
    • Updates to existing reports will now be delivered separately from platform updates. The new reporting framework will allow for more frequent updates and improvements to report used to prove compliance and measure security status.
  • Reporting improvements
    • Simplified user interface in reports list and report module list
    • Enhanced visual design of PDF and HTML report output
    • Ability to “print” pages in the UI for customers so that customers can share information with other team members without giving them access to the system
  • Audit-ready compliance reports
    • Based on feedback from auditors and compliance experts, AlienVault delivers over 30 new audit-ready reports for PCI-DSS 3.1 and HIPAA to answer the most common questions from auditors.
  • OTX reports
    • Identify emerging threats targeting you environment by reporting on events that contain suspicious IP addresses from the OTX IP Reputation database and report on events generated from IOC’s that have been identified in OTX pulses.

© 2020 PKF AvantEdge

Theme by Anders NorenUp ↑