Tag: setup

Deployment of Alienvault in Practice Part 2

avlogo

So now you have a server instance of Alienvault in your network and you need to get your sensors up and running.

While a majority of small deployment can do with an All-In-One, there are reasons why you might need a separate server/sensor config. Remote sites for instance; where you want the sensor located onsite to perform log normalization, vulnerability assessments, availability etc. The sensor does quite a fair bit of work as well – and on top of that, it balances out the EPS. Remember, the AIO has a limit on EPS, so if you are looking at anything beyond 1,000 EPS, you are going to struggle to keep up with the events without a sensor.

Deploying a sensor is straightforward.

First, it’s important to understand a sensor does not have a GUI frontend, so all config is done on the Alienvault Setup Menu or CLI. This doesn’t make it any more difficult – in fact the hardest part of it is to include in the License Key in the menu – since we can’t cut and paste, so you need to make sure you do it correctly.

Second, you should always have a server instance before you go around setting up the sensor.

In the Alienvault Setup, go to Configure Sensor->Configure Alienvault Server IP. Now this should be your server IP. Some have asked should it be the management IP or the Logging IP. It should be the management IP, unless of course your management IP is not reachable, in that case, the only reachable IP is the logging IP of your server.

So go ahead and do the same for your framework IP address as well. Apply all changes and you are set.

Head back to the server, and go to the UI

Configuration->Deployment->Sensors

You will see the following message

Warning: The following sensors are being reported by as enabled by the server, but aren’t configured

Don’t worry about this, just click on Insert and you are done. It’s that straightforward. You will see the sensor listed, with the context it’s under, version and the status should have a checkbox next to t.

The final part is to get the Logger up and running.

Opposite from the sensor, the Logger is setup via the UI.

What’s important to understand here is that the flow is Sensor -> Server -> Logger.

So the logger is actually the end of the flow where all your logs are forensically stored and archived and validated. As far the server is concerned, it sees the Logger as a Parent.

ON THE LOGGER

Head over to the Logger UI (having already set it up as you did the server initially with IP Addresses, Licenses etc)

Go to Configuration->Deployment-> Servers and use “Add Server”

Again go ahead and use the IP address you have been using to define your server during your sensor config.

Once you have added the server and saved, head back to the Server screen and click on your logger instance (which should be there by default already)

Now select “NO” for everything except “LOG” in the form.

That’s it. You shouldn’t be type in the REMOTE USER and all that as this is done later in the Server.

ON THE SERVER

Now, back to the Server UI. Go to the same Configuration->Deployment->Servers.

It sometimes can get confusing here as the UI is the same, so make sure you name your Logger and Server appropriately!

On the server, you should see both the SERVER and LOGGER under the UI.

Modify the LOGGER (remember, you are on the SERVER UI, NOT THE LOGGER UI).

You won’t be able to change anything in there but you can set the Remote Admin and password to log into the Logger. Use the admin credentials (not the root) and let the URL populate itself by clicking on it.

Set “Remote Logger”

Finally, go back to the server screen and click on the SERVER -> Modify

You can now opt to set up Log to NO. Under that, in the Forward Servers option, click Add Server and go ahead add in your Logger.

Save and Apply all changes.

Click on Server Hierarchy and we have a nice primitive depiction of the Server pointing to the Logger. Well Done!

Now –  a note: If you are using an AIO UA as a server instance, you can set up the Log to YES in the AIO. That means you are logging in both locations.

In your logger, interface you will see that you have two different color boxes, depicting which Logger it is sent to.

If for some reason you want to say, OK, for asset 1 – 20 send to AIO, and for Asset 21 – 100, send to the Logger, you can disable the forwarding we set up above, and do it via policies. The great thing about Alienvault is that it allows that granular flexibility to control where your AIO wants to forward (or not forward) logs to.

We will explore Policy Setup in the future.

For now, enjoy your three piece band – Sensor, Server and Logger!

 

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!

© 2024 PKF AvantEdge

Up ↑