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:
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 Total lines  TotalEvents: 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.
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!
Hi, Need some help with regards to NXLOGS to get logs from an IIS server. We are using below settings in our Nxlog.conf file. These settings as you can see are pretty standard. However when i check on our AIO server or sensor, the log messages are coming out to be empty. All fields have N/A in them as if there is an issue with parsing the iis log file. Also, the timestamp in the syslog output which we are getting is in UTC. The IIS server on which nxlog is setup is in EST .
How can we change the config in nxlog.conf so that it shows timezone as EST ? Hope i am clear.
#define ROOT C:\Program Files\nxlog
define ROOT C:\Program Files (x86)\nxlog
# Create the parse rule for IIS logs. You can copy these from the header of the IIS log file.
Fields $date, $time, $s-ip, $cs-method, $cs-uri-stem, $cs-uri-query, $s-port, $cs-username, $c-ip, $csUser-Agent, $cs-Referer, $sc-status, $sc-substatus, $sc-win32-status, $time-taken
FieldTypes string, string, string, string, string, string, integer, string, string, string, string, integer, integer, integer, integer
Delimiter ‘ ‘
#Drop info legend lines
Exec if $raw_event =~ /^#/ drop();\
$EventTime = parsedate($date + ” ” + $time);\
Path IIS_Log => out
Device log file uder /var/log/alienvault/devices/:
Jun 23 16:04:11 SERVERNAME MSWinEventLog 1 N/A 134 Thu Jun 23 16:04:11 2016 N/A N/A N/A N/A N/A N/A N/A N/A N/A
Jun 23 16:04:11 SERVERNAME MSWinEventLog 1 N/A 135 Thu Jun 23 16:04:11 2016 N/A N/A N/A N/A N/A N/A N/A N/A N/A
Jun 23 16:04:11 SERVERNAME MSWinEventLog 1 N/A 136 Thu Jun 23 16:04:11 2016 N/A N/A N/A N/A N/A N/A N/A N/A N/A
Jun 23 16:04:13 SERVERNAME MSWinEventLog 1 N/A 137 Thu Jun 23 16:04:13 2016 N/A N/A N/A N/A N/A N/A N/A N/A N/A
Jun 23 16:04:14 SERVERNAME MSWinEventLog 1 N/A 138 Thu Jun 23 16:04:14 2016 N/A N/A N/A N/A N/A N/A N/A N/A N/A
sorry it is such a late response on this, this was spammed for some reason. Please drop us an email on email@example.com and we will get it attended to!
Do you know why the plugin “nxlog” that came out of the box from AlienVault does not work? I followed you manual by using the plugin “syslog” and it works. But if we already have the nxlog plugin why does it not work?
I hope you can answer this doubt.
I believe the nxlog plugin that comes out of the box from Alienvault is for Windows log (https://www.alienvault.com/documentation/usm-appliance/supported-plugins/configuring-nxlog.htm). So technically, it is reading windows log and normalizing it based on events as per the website. Remember, Windows doesn’t have any native syslog in built so NXLog or Snare will do the trick.
When you say it ‘does not work’, how do you mean? Are you receiving logs in the first place and secondly, can you check your agent.log to see if the plugin is properly normalising?
I have got stuck when I want OSSIM to analyse or display the IIS log data sent from the NXLog.
I am running OSSIM server using VirtualBox on top of the Windows, and I managed to forward the IIS log to OSSIM Server using the NXLog. I can see that the data is stored in /var/log/iis-nxlog.log.
However, I can’t figure it out how to display the iis-nxlog.log or analyse it in OSSIM (UI) SIEM, Dashboard or Alert. Actually, I can’t find anything that is relevant to IIS in OSSIM UI.
Can you please help?
Getting logs to Alienvault is half the job done so you are almost there. The next thing to do is to set up a plugin to read the logs. We will hazard a guess that either the log location is not identified, or a plugin hasn’t been enabled. Please drop us an email on firstname.lastname@example.org and we will get it attended to!