This is the final part of our foray into NXLog and Alienvault.
To recap: You have enabled Rsyslog over TCP, you have forwarded NXlog IIS FTP logs over to Alienvault, you have created an initial plugin to identify unsuccessful logins and done the CFG and SQL files and wrote into the ossim-db.
You need to do one more thing:
Alienvault-reconfig
The command reconfigures the whole system, to ensure that the plugin is properly used.
Once done, you can do the following:
Cat /var/log/alienvault/agent/agent.log | grep 10000
Now finally you might be able to see something like
Apr 4 11:30:18 VirtualUSMAllInOne ossim-agent: Alienvault-Agent[INFO]: Plugin[10000] Total lines [138] TotalEvents:[22] EPS: [0.00] elapsed [10.01] seconds
Which means out of 138 lines in the log, Alienvault was able to parse 22 into events. Which makes sense since you only set up one policy – Unsuccessful Logins.
The best practice is simply to have a generic ‘Catch All’ policy at the end of the plugin which is extremely general and will catch everything else. With the methods in the previous article, hopefully you will be able to grasp this cryptic skill of plugins creation. Go ahead and try it.
If you head over to GUI, Go to Configuration->Threat Intelligence->Data Source->Data Source Groups.
Now create a new group and call it ‘EVERYTHINGISAWESOME’. Or something you like.
Now, lets add Data Source. Select the new data source you created, 10000.
Now head to Analysis->SIEM.
Filter Data Source Groups to the group you just created.
AWESOME! You can see UNSUCCESSFUL LOGIN and finally there is a source and destination IP and no longer 0.0.0.0
Go ahead and click on it and feel the warm, fuzzy feeling of success flow over you.
There’s one last thing you will need to do before we wrap this up in a ribbon.
Custom Directives.
You see, at the end, all the stuff you see in SIEM is useful only if you are eyeballing it. And in general, most people would rather eyeball the latest episode of the Walking Dead as opposed to eyeballing a SIEM. Heck, some people I know would rather eyeball a tulip growing than watching logs in a SIEM. That’s where Alarms come in. Alienvault has a very simple philosophy on alarms: if the Priority of the event, the Asset Value and the Reliability of that event is high enough, we are gonna throw out an Alarm. An Alarm is something that you should be somewhat…alarmed about.
So back to our unsuccessful login. In theory, if someone did one unsuccessful login, you would chalk it up to a typo. Two in a row, within 1 seconds, well, maybe he’s in a hurry. 5 in a row within 5 seconds, he’s going to look suspicious, but hey, he could be someone from senior management. Or the marketing director who thinks the DVD drive is a cupholder. 10 in a row within 10 seconds? OK, I’m just going to throw up an alarm and let the security guys know about this fellow.
How does it work?
Without going into too much intricacies of the Alienvault engine, it’s basically down to directives. And after wading through the swamp called custom plugins, you will find this a lot easier as it’s mostly done on the GUI.
First of all, obviously, make sure your custom plugin works.
Then, head to Configuration->Threat Intelligence and click on Directives.
You will see ‘User Contributed’ as empty. You can either create one from scratch or clone an existing one. I recommend the latter. Alienvault ships with around 2,000 directives in built and I would just feel bad to neglect the existing ones….I am sure the Alienvault engineers will be happier if you used theirs. They worked hard on these directives.
OK – for this case, I specifically want to know if someone is trying to bruteforce my extremely sensitive FTP server (I know, you are asking why I am using FTP and not SFTP, and my answer is: ILLUSTRATION.). So the first thing I do is, look, there is a convenient directive group called ‘Bruteforce Attack’. You already have over a hundred directives drawn out for you. Click on it.
Take your pick in any of the directives shown. For me, I chose
AV Bruteforce attack, FTP authentication attack against DST_IP
Click on the “Clone” icon next to it.
You will find there’s one directive now under ‘User Contributed’.
You need to modify it somewhat.
A brief understanding will be useful here. This directive is basically saying:
a) If there is ONE occurrence of unsuccessful login from any IP to any destination that uses this data source, set the reliability to 4. Now, depending on your priority (usually it’s 3) and your asset value (usually it’s 2), this won’t throw an Alarm. The alarm works by
(Reliability X Priority X Asset Value) >= 25
So if you set your asset value as 5, then even one single wrong login will light up your Alarm panel.
b) So back to the rule – if there is 3 occurences of wrong login from the same source and same destination, we are going to raise the reliability up a little. But notice the timeout value – The timeout value defines how many seconds the plugin will wait to receive a response from the destination to which the request was sent. So if we don’t get a response within the timeout period the rule expires and the directive process defined in the rule is discarded.
c) Change the data source to the one that you created, in this case IIS_FTP and in the popup, select UNSUCCESSFUL LOGINS (in our case, the SID is 1). Everything else, we just took it from the original directive.
d) Restart the server. This doesn’t actually restart the whole Alienvault, just the correlation machine, so don’t worry that your SIEM is going to go down.
The final test is to just try to login into your FTP server with wrong passwords repeatedly.
Now head over to your Analysis->Alarms
You will see
AV Bruteforce attack, IIS FTP authentication attack against Host-192-168-0-35
Click on the details and scroll down and you will see the corresponding events and the correlation level of each event. You will see right at the bottom, after the first four attempts, an alarm was raised and the correlation level was raised. Then it goes through the next set of rules – after 10 attempts again, an alarm was raised and correlation level was raised.
Using policies (not covered here, else this article will be the size of War and Peace) – we can then decide what we want to do with this alarm – open a ticket, execute a script, send an email or trigger an SMS etc.
That’s about it. So we’ve covered getting NXLog all the way to Alienvault, Alienvault interpreting it through a plugin you created, and then using these new custom events to trigger an alarm using a directive you modified.
Welcome to the Alien Nation!
