Category: AlienVault (Page 5 of 7)

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: 192.168.0.38, device_id: 29b1cd29-70ac-11e5-a5e9-000c93c2e358}
config: {location: /var/log/alienvault/devices/192.168.0.38/192.168.0.38.log}

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'
alias ossecdecoder='cd /var/ossec/alienvault/decoders/'
alias ossecrule='cd /var/ossec/alienvault/rules/'
alias avarchivelog='cd /var/ossec/logs/archives/'

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.

AlienVault Logging Setup Part 1

One of the thing about AlienVault is that you would think from the user interface it would be a sort of system to just plug and play and everything is OK.

While it is a far cry ahead from the days of manual configuration, AV still requires a little know-how to get things up to speed, and yes, it does require a little dive into the venerable CLI, so you would need to know a little about some of the engine running under the AV hood.

Let’s start.

One of the first thing that a customer wants when he opens AV, before all the snazzy vulnerable scans and all the network IDS or host IDS comes in, even before SIEM comes in is LOG. Log is to the SIEM what audit is to accounting companies. You just do it.

Strangely, this is not as intuitive as it sounds. Here’s a step by step. We don’t put any screenshots here because we have limited storage capacity on this blog. Yes, we are very frugal. And we like words.

AlienVault Scenario Setup

Because we are slightly lazy, we just want a simple scenario that the VMWare ESXi Box that we are hosting the AV on, to send logs to the AV. Just logs first. Like what it would do when sending to a syslog server. Our Vmware esxi for instance is 192.168.0.10, our AV is 192.168.0.11 (logging interface).

Setup your Esxi.

I know this is out of scope. In most cases, we would just tell our clients, look send your logs from PaloAlto, SonicWall, Juniper, Sophos etc to AlienVault’s logging interface. For Esxi, it is very simple.

1. Start your VMware VSphere client, login > right click on the VMWare host

2. Configuration>Software>Advanced Settings

3. Under Syslog, click on global, under syslog.global.logHost, put in your interface of the AV (192.168.0.11)

4. Click on Security Profile under Software and on the right top, click Properties

5. You are in ‘Firewall Properties’ tab, scroll down under label and find ‘syslog’. Click it. This should enable your syslog traffic to go out to your AV.

You are done. How other systems do it, no idea. But it will probably be more or less straightforward as this.

Initial Testing

If you are like me, and just want to make sure everything is working, setup your own free Syslog server (3CDaemon works nicely) and turn it on, and point your Esxi syslog to your own laptop running the syslog server. If you see stuff coming in, you know Esxi is running ok, and if any roadblock you face down the road, it would be AlienVault’s fault. Now point it back to the AV interface please.

AV Setup to Receive Logs

AV needs to see the logs coming in first. We used the base document found in

https://www.alienvault.com/doc-repo/usm/security-intelligence/AlienVault_Device_Integration_Fortinet_FortiGate.pdf

I know you are not doing fortigate, but the idea here is similar. Get the loggee (that’s what we will call the system sending logs to AV) to send to AV, Set up AV to receive logs, configure log expiration, enable plugin.

The annoying thing is in most cases, everyone starts at the ‘enable plugin’ stage and forgets to set up AV to receive those logs first. You can’t fault them. I attended the training for AlienVault engineer and the training assumed you have magically conjured up AV to receive logs so you could be banging your head for a while on this.

Time to go CLI. I will magically assume you know how to get to AV CLI. Just jailbreak it! It’s just a scary sounding name to get out of the AV menu to CLI. Log into your AV using Putty or your favoured SSH client, and in the menu, select jailbreak system and accept whatever disaster they warn you about.

Once in CLI:

a) Configure your rsyslogd. Go to /etc/rsyslog.d and ls. You don’t see vmware in there do you?

b) Because it’s not. AV doesn’t babysit you. It expects you to know stuff.

c) Check if rsyslog is actually running

ps -ef | grep rsyslog – check if the process is up

netstat -tulpen | grep rsyslog – check if its listening on the right ports – 514?

Extra geek points you can:

VirtualUSMAllInOne:/var/log# logger -t test syslog-test-message
VirtualUSMAllInOne:/var/log# tail /var/log/messages | grep test
Sep 11 18:09:19 VirtualUSMAllInOne test: syslog-test-message

Basically what you did was to get the logger to send a test message to itself and then check the message logs if the message was there. It is, so rsyslog is working nicely!

Now to configure your vmware-esxi.conf. We followed the above fortigate config

Vi vmware-esxi.conf and in your vi

if ($fromhost-ip == ‘192.168.0.10’) then /var/log/vmware-esxi.log

I am assuming you are a Vi person. If you are nano person or something else, then, that’s your cuppa.

I have a few problems with the above line, because it basically it means I am logging everything that’s coming from my vmware. I need to filter those annoying debug messages. So below does it

if $fromhost-ip == ‘192.168.0.10’ and $syslogseverity <= ‘6’ then -/var/log/vmware-esxi.log
if $fromhost-ip == ‘192.168.0.10’ then ~
& ~

Actually I copied this from somewhere else (https://www.alienvault.com/forums/discussion/2111/vmware-plugin-series) and I don’t know why line 2 is even there.

Basically the first line says anything coming from my loggee, with severity of informational and below (filter out debug), then put it into the vmware-esxi.log. The dash sign in front is just telling rsyslogd not to sync operation after writing out each line. According to the MAN: “You may prefix each entry with the minus “-” sign to omit syncing the file after every logging. Note that you might lose information if the system crashes right behind a write attempt. Nevertheless this might give you back some performance, especially if you run programs that use logging in a very verbose manner.”

However, recent times, there doesn’t seem to be any relevance to the dash anymore and is just there out of habit.

Line 2 = no idea because it just says, to discard (tilde ~) everything filtered out by line 1 (debug messages). The last line does the same. The ampersand & is just there for connecting the two lines.

OK so anyway, you have your configuration set up and filtering.

Go ahead and restart

/etc/init.d/rsyslog restart

Remember to configure a log rotation for yourself

vi /etc/logrotate.d/vmware-esxi

/var/log/vmware-esxi.log
{
rotate 4 # save 4 days of logs
daily # rotate files daily
missingok
notifempty
compress
delaycompress
sharedscripts
postrotate
invoke-rc.d rsyslog reload > /dev/null
endscript
}

I didn’t bother to find out what all these meant, I just took the AlienVault document as gospel truth.

You look pretty set up.

Now go to /var/log and see if vmware-esxi.log is there.

If it’s not,

touch vmware-esxi.log

tail -f vmware-esxi.log

This basically creates the file manually and do a ‘tail’, to see if any new lines have been appended to it.

Now go to your Esxi box and try to log in, you should be able to see some activity on that tail of yours.

Amazingly you have not even touched AlienVault yet. But you have gotten logs from the loggee into the logger so go ahead and grab your coffee. That’s a good start. We’ll look into what AlienVault can do better than other syslog servers in the next post.

AlienVault Troubleshooting: NFSEN cannot start

One of the issues we faced was that our NFSEN suddenly barfed when restarted. This is highly annoying because everytime we reconfigure AlienVault, it has to hang at NFSEN service restart because it couldn’t get it up. I don’t know why.

Eventhough we don’t use netflow much in our environment, it was still a pain for us so we tried to troubleshoot it and finally resolved it.

The issue was when we click on Environment>Netflow we saw these errors

ERROR: nfsend connect() error: Connection refused!

ERROR: nfsend – connection failed!!

NFSEN

Obviously this was irritating. Under Configuration>Deployment>Sensors, we clicked on our AIO and scroll to the bottom, we saw that the netflow collection configuration was not running.

I think it could be because we didn’t set any interface to be ‘monitoring’. We went ahead and set it using the alienvault-setup menu and assigned eth1 to be monitoring. Strangely we couldn’t assign it in the GUI under Configuration>Deployment>AIO>Sensor Configuration and Detection. We only had option for Eth0 (our management) and ETH5 (our logging interface).

Anyway, once we set an interface to monitoring we still couldn’t start nfsen through the GUI or even through the command line under /etc/init.d/nfsen start/stop.

It kept giving this error

Use of uninitialized value $pid in scalar chomp at /usr/bin/nfsend line 765.
Use of uninitialized value $pid in kill at /usr/bin/nfsend line 767.
Use of uninitialized value $pid in concatenation (.) or string at /usr/bin/nfsen

Which made as much sense as greek.

In any case, at least it gave a clue that /usr/bin/nfsend might be complaining because nfsen wasn’t up in the first place. So we went ahead and
VirtualUSMAllInOne:/usr/bin# ./nfsen start
Starting nfcapd:(564D89B81691003B6E98F73F9FFA258C)[25330]
Starting nfsend.

This apparently didn’t through any errors and nfsend seems started! Do a ps -ef and grep nfsen and you have a nice PID allocated.

VirtualUSMAllInOne:/usr/bin# ps -ef | grep nfs
www-data 25330 1 0 23:12 ? 00:00:00 /usr/bin/nfcapd -w -D -p 555 -u www-data -g www data -B 200000 -S 7 -P /var/nfsen/run/p555.pid -I 564D89B81691003B6E98F73F9FFA258C -l /var/cache/nfdump/flows//live/564D89B81691003B6E98F73F9FFA258C
www-data 25332 1 0 23:12 ? 00:00:00 /usr/bin/perl -w /usr/bin/nfsend
www-data 25333 25332 0 23:12 ? 00:00:00 /usr/bin/nfsend-comm
root 25339 22649 0 23:12 pts/0 00:00:00 grep –color=auto nfs

So we stopped it again but this time with the init.d script.

VirtualUSMAllInOne:/usr/bin# /etc/init.d/nfsen stop
Stopping Nfsen: nfsenShutdown nfcapd: (564D89B81691003B6E98F73F9FFA258C)[25330]. .
Shutdown nfsend:[25332]..

And started it again using the init.d script

VirtualUSMAllInOne:/usr/bin# /etc/init.d/nfsen start
Starting Nfsen: nfsenStarting nfcapd:(564D89B81691003B6E98F73F9FFA258C)[26383]
Starting nfsend.

Now we checked back our netflow on the gui and it works.

I don’t know if anyone else is facing this or has an explanation to this, but it might or might not have anything to do with our interface not being set to monitoring. You can try this out if you are facing this issue.

 

OSSIM Part 2: Typical Setup

From the previous post, you have successfully installed OSSIM into a VM running ESXi 5.1. Congratulations.

Go ahead and access the web IP address of the OSSIM (you do remember it, don’t you??!)

You are greeted with the same screen as AlienVault – setting the admin account. You should never lose the root password, the admin password can be reset.

Once that is done, relogin again with the new admin password and go through the wizard.

Let’s start with the interface. Go ahead and configure one for Logging and the other for monitoring (no IP). Assign another IP to it. For now, we didn’t do any scanning or other setup, the whole idea was just to see what OSSIM is offering.

In case you messed up and only set up 2 network interfaces, don’t worry. Just add a new network interface into the VM and power up the OSSIM again.

You would want to reconfigure it to have that new interface so go to configuration and wait for your OSSIM to load up. The annoying thing about AlienVault is that the Getting Started Wizard is literally ‘Getting Started’. You don’t have a way to invoke that wizard again so you generally have to reconfigure your network devices the hard way. There are two ways:

SSH into your OSSIM and run alienvault-setup if not already in the setup menu. Go to Configure Sensor > Configure Network Monitoring and select the new ETH as your network monitor. Then you need to apply changes and wait for OSSIM to rebuild

Second option is GUI>Configuration>Deployment>Click on the OSSIM installation

On the top right, click on Sensor configuration and then on ‘Detection’. You will see listening interfaces there. Go ahead and select the NIC to add to listening interfaces. You don’t need an IP address for monitoring. Apply Changes.

It’s just annoying, and we really wish OSSIM would just allow us to run the getting started wizard again.

If you need to set up a logging and monitoring role, you just need to go to the alienvault-setup, setup the network interfaces under system preferences and give it an IP. Immediately gets a logging and monitoring role. There shouldn’t be more than one interface per subnet. The question here is, can your management interface also be the logging interface. Yes of course, but it’s best not to.

Now, again, we wish OSSIM would be a little more clear on this. They already have an awesome GUI, but you would think running the wizard again would be a simple thing to do. Nope, it’s not. You have one shot at it.

So now, you have an interface to manage, to log and to monitor.Go ahead and have a look at it under the deployment components.

Once this is done, you are basically good to go to start OSSIM!

« Older posts Newer posts »

© 2024 PKF AvantEdge

Up ↑