Nxlog Download For Linux ##VERIFIED##
Juven Richter
By default, NXLog runs as user nxlog and does not have permission to read files in /var/log.The simplest solution for this is to run NXLog as root by omitting the User option, but it is more secure to provide the necessary permissions explicitly.
Run NXLog under a user or group that has permission to read the log files.Either use a user or group directly with the User or Group option in nxlog.conf or add the nxlog user to a group that has permission.For example, on Debian/Ubuntu add the nxlog user to the adm group by running usermod -a -G adm nxlog.
The im_linuxaudit module can be used to collect Audit System logs directly from the kernel without using auditd or temporary log files.Audit logs can also be collected from file with im_file, or over the network by using im_tcp in conjunction with audisp-remote (a plugin for the audit event dispatcher daemon, audispd, that performs remote logging).See Linux Audit System for more details.
Optional: To change the NXLog user and group for the installation, set the NXLOG_USER and NXLOG_GROUP environment variables.During installation, a new user and a new group will be created based on these environment variables.They will be used for User and Group directives in nxlog.conf, and for the ownership of some directories under /opt/nxlog.Specifying an already existing user or group is not supported.The created user and group will be deleted on NXLog removal.
Configure NXLog by editing /opt/nxlog/etc/nxlog.conf.General information about configuring NXLog can be found in Configuration.For more details about configuring NXLog to collect logs on Linux, see the GNU/Linux summary.
According to the vendor documentation, FIM is only available in the NXLog Enterprise Edition. In addition, NXLog must have permission to read the files you want to monitor. You can run NXLog as root, or make sure the nxlog user or group has permission to read the files.
The other option would be, if possible, to use nxlog on that DHCP server where you would not only be sending the DHCP log data to IDR, but could also be sending it to whichever syslog server you need to. Here is the link for nxlog:
@eoliveira Good question. What @SDavis is suggesting is to run Nxlog somewhere in your organization, and then have it split the logs out to two destinations: InsightIDR and your remote syslog server. Most people just install it onto their InsightIDR Collector (s) for simplicity, but you can install it wherever you like. Below is an example of how the nxlog.conf would look if you are collecting Windows DHCP logs and have installed Nxlog onto a Windows host. As you can see, you just grab your logs and send to two Outputs. If you want to install it onto a Linux host instead, that also rather easy; we have some examples of this in our Docs, or you can use this blog that I wrote as a guide: Audit Log Monitoring in Our SIEM Solution, InsightIDR Rapid7 Blog Skip down to the part about installing Nxlog onto a Linux host.
No worries! Honestly nothing comes to mind. I will say that using nxlog is more difficult to initially set up than simply configuring a DHCP Event Source in IDR. I also see @teresa_copple1 is posting as well, she is THE nxlog guru!
LogPoint provides a special version of NXlog Enterprise on the Helpcenter - -us/articles/360016329557-Nxlog-Enterprise-v5-1-6133, and this version includes the IM_FIM module for file integrity monitoring. The LogPoint bundle includes both the Windows version as well as a version for Ubuntu, and IM_FIM works on both. The NXlog documentation for IM_FIM on Linux is here: -user-guide/fim.html#fim_linux
It's a bit off-topic but I have a kinda unusual use case. I want to get the events out of windows box and store it on a linux machine (in this particular case it's windows VM and I want to export the events to the hypervisor).
Of course for linux it's easiest to receive syslog messages but as we all know, Windows doesn't have built-in syslog server and you can't easily get the events with built-in windows tools to push through syslog channel.
The basic steps shown in the graphic below highlight how to download and install NXLog, modify the default nxlog.conf file to ingest the raw logs and output in Rapid7 UEF, then simply send and verify successful ingestion into InsightIDR.
I installed NXLog CE to the default location on the same system that has the logs I need to collect, C:\Program Files (x86)\nxlog. This folder contains a subfolder called conf that has the NXLog configuration file, nxlog.conf. Although the NXLog install created a default nxlog.conf, I now need to edit it to manipulate my logs. I start by making a copy of the nxlog.conf as a backup.
When NXLog starts, it will create a diagnostic log for itself called nxlog.log. I chose to write the nxlog.log file to C:\Program Files (x86)\nxlog\data, its typical location (this is a setting in nxlog.conf).
NXLog uses nxlog.conf to understand how to read in logs, manipulate them, and forward them to a receiving device. We need to edit nxlog.conf to input and convert logs into UEF, and forward them to the InsightIDR collector.
Before we test, we need to add directives by defining all the NXLog extensions being used in nxlog.conf. So far, our nxlog.conf defines one extension for syslog, which allows up to output logs as syslog. We will need two extensions in the nxlog.json file: one for syslog, and one for JSON. As our final logs should be in JSON, we should add in a for outputting using syslog, xm_json. I am not yet using the xm_json extension, but I know I must as my final logs are required to be in JSON format.
We need to add in an extension for kvp and modify my section to run the kvp module. After some testing to determine which options work with my input, I discover that my logs have tabs separating the key value pairs. Now, nxlog.conf looks like this:
Do you see the kvp2 module being used in the else statement? I test this and verify that indeed, I have the input being written out in kvp format. Now I can start deleting fields for real! I add in the delete ($field) procedure and test it. Here is nxlog.conf now:
Now that the logs appear to be in the proper UEF format, I will add it into InsightIDR. Earlier, we chose forwarding the logs from NXLog via syslog over UDP port 10010, and that is defined in nxlog.conf. Now I just need to log in to InsightIDR and add this event source.
Unfortunately, this does not take Daylight Savings Time into consideration. Programmatically resolving this issue is beyond this introductory document. Therefore, I can either live with this or manually adjust nxlog.conf twice per year.
df19127ead