NXLog User Guide

19. Hardening NXLog

19.1. Running Under a Non-Root User on Linux

NXLog can be configured to improve security by running under a specified user and group rather than retaining root privileges. The User and Group global directives specify the user and group for the NXLog process to run under. By default on Linux installations, NXLog is configured to run under the nxlog user and nxlog group as shown below.

Running as nxlog:nxlog


  1
2

  User nxlog
Group nxlog

Some operations require privileges that are normally not available to the nxlog user. In this case, the simplest solution is to configure NXLog to retain full root privileges by removing the User and Group directives from the configuration. This is not recommended, however; it is more secure to provide only the required privileges and to avoid running NXLog as root. See the following sections for more information.

19.1.1. Reading From /var/log

By default, the nxlog user will not have access to files in /var/log. If your Linux distribution uses a group other than root for the log files, you can use that group with the Group directive. Otherwise, reconfigure your system logger (Rsyslog for example) to create files with the necessary ownership. See Reading Rsyslog Log Files for more information.

19.1.2. UDP Spoofing and Binding to Ports Below 1024

NXLog requires special privileges if configured to perform UDP source address spoofing (with om_udpspoof) or to bind to a port below 1024 (for example to accept incoming Syslog messages on port 514). Consider the following solutions.

Use built-in capability support

NXLog will automatically set the corresponding Linux capability before dropping root privileges.

Set the capability manually

For binding to ports below 1024, use the CAP_NET_BIND_SERVICE capability. For the UDP source address spoofing, use the CAP_NET_RAW capability.

Example 7. Setting Linux Capabilities

This command sets the CAP_NET_BIND_SERVICE capability for the NXLog executable.

# setcap cap_net_bind_service+ep /opt/nxlog/bin/nxlog

This command sets both the CAP_NET_BIND_SERVICE and the CAP_NET_RAW capabilities.

# setcap cap_net_bind_service,cap_net_raw=+ep /opt/nxlog/bin/nxlog

Verify with this command, or by adding the -v (verify) flag to the setcap command.

# getcap /opt/nxlog/bin/nxlog

19.1.3. Reading the Kernel Log

NXLog requires special privileges to read from the Linux kernel log with the im_kernel module. Consider the following solutions.

Use built-in capability support: NXLog will automatically set the Linux CAP_SYS_ADMIN capability before dropping root privileges.
Set the capability manually: Use the CAP_SYS_ADMIN capability or the CAP_SYSLOG capability (since Linux 2.6.37). See Setting Linux Capabilities.

19.2. Configuring SELinux

To further harden NXLog, SELinux can optionally be used. SELinux improves security by providing mandatory access controls on Linux. This section provides an overview for creating an SELinux policy for NXLog. The resulting policy will provide the permissions necessary for the NXLog deployment to operate as configured, with SELinux enabled on the host.

The process is divided into two parts. First, a base policy is created. Then the policy is deployed and tailored to the specific requirements of the current NXLog configuration.

19.2.1. Base Policy

The base policy file can be generated with the SELinux Policy Generation Tool (which requires a graphical environment) or with the SELinux CLI development utilities.

In either case, the following policy files are generated:

nxlog.te: Base policy information; this file defines all the types and rules for a particular domain.
nxlog.fc: File system information; this file defines he security contexts that are applied to files when the policy is installed.
nxlog.if: Interface information; this file defines the default file context for the system.
nxlog.sh: A helper shell script for compiling and deploying the policy module and fixing the labeling on the system; for use only on the target system.
nxlog_selinux.spec: A specification file that can be used to generate an RPM package from the policy, useful for deploying the policy on another system later. This spec file is generated on RPM-based systems only.

19.2.1.1. Base Policy Using Policy Generation Tool (GUI)

Install the SELinux Policy Generation Tool package.

On Red Hat based systems run the following command:
```
$ sudo yum install rpm-build policycoreutils-gui
```
On Debian based systems run the following command:
```
$ sudo apt-get install policycoreutils-gui
```
Start the SELinux Policy Generation Tool from the system launcher.
In the first screen, select Standard Init Daemon for the policy type, then click Forward.
On the second screen, enter the following details for the application and user role, then click Forward.

Name

A custom name for the role (for example, nxlog)

Executable

The path to the NXLog executable (for example, /opt/nxlog/bin/nxlog)

Init script

The path of the NXLog system init script (for example, /etc/rc.d/init.d/nxlog)
On the third screen, enter the TCP and UDP used by the NXLog deployment, then click Forward. If the ports are unknown or not yet determined, then leave these fields blank; they can be customized later.
On the fourth screen, select the appropriate application traits for NXLog, then click Forward. The default configuration requires only the Interacts with the terminal trait. For collecting Syslog messages or creating files in /tmp, include the appropriate traits.
On the fifth screen, specify all the arbitrary files and directories that the NXLog installation should have access to, then click Forward. The default configuration requires only the NXLog system directory, /opt/nxlog. Include the paths of any custom log files that NXLog needs to access.
Additional SELinux configuration values can be set on the sixth screen. None of these are required for NXLog. Click Forward to continue.
The policy files are generated on the final screen. Click Save to write the policy to disk.

19.2.1.2. Base Policy Using sepolicy (CLI)

Install the SELinux Policy Core Policy Devel Utilities package.

On Red Hat based systems run the following command:
```
$ sudo yum install rpm-build policycoreutils-devel
```
On Debian based systems run the following command:
```
$ sudo apt-get install policycoreutils-dev selinux-policy-default
```
The base policy can be generated with the following command.
```
$ sepolicy generate -n nxlog --init /opt/nxlog/bin/nxlog -w /opt/nxlog
```
Note
Additional managed directories can be added to the policy by passing to the -w parameter the full directory paths separated by spaces (for example, -w /opt/nxlog /var/log).
The policy files are generated when the command exits successfully; the policy is written to the current working directory.

19.2.2. Deploying and Customizing the Policy

In this section, the base policy generated in the previous section will be applied and then customized with appropriate rules for NXLog operation as configured. To accomplish this, SELinux will be set to permissive mode and then the audit2allow tool will be used to generate additional SELinux rules based on the resulting audit logs.

Warning

When set to permissive mode, SELinux generates alerts rather than actively blocking actions as it does in enforcing mode. Because this reduces system security, it is recommended that this be done in a test environment.

Make sure that NXLog is correctly configured with all required functionality.
Stop the NXLog service.
Transfer the files containing your SELinux base policy to the target system. All the files should be in the same directory.

Apply the SELinux base policy by executing the policy script. This script will compile the policy module, set the appropriate security flags on the directories specified, and install the policy.

$ sudo ./nxlog.sh

Note

You may see the error message libsemanage.add_user: user system_u not in password file. This is caused by a bug in the selinux-policy RPM or selinux-policy-default DEB package and does not affect the policy at all. It has been fixed in later releases.

You may see the error message InvalidRBACRuleType: a is not a valid RBAC rule type. This is from a bug in the policycoreutils package. It only affects man page generation, which is not generated in this case. This has been fixed in later releases.

Verify that the new policy is installed.
```
$ sudo semodule -l | grep nxlog
```
Set SELinux to permissive mode. All events which would have been prevented by SELinux will now be permitted and logged to /var/log/audit/audit.log (including events not related to NXLog).
```
$ sudo setenforce 0
```
Start and then stop the NXLog service. Any actions taken by NXLog that are not permitted by the policy will result in events logged by the Audit system. Run audit2allow -a -l -w to view all policy violations (with descriptions) since the last policy reload.
```
$ sudo systemctl start nxlog
$ sudo systemctl stop nxlog
```
Example 8. Audit Logs
If NXLog has been configured to listen on TCP port 1514, but the appropriate rules are not specified in the current SELinux policy, then various audit events will be generated when the NXLog process initializes and binds to that port. These events can be viewed from the Audit log file directly, with ausearch, or with audit2allow (as shown below).
$ sudo audit2allow -a -l -w type=AVC msg=audit(1524239322.612:473): avc: denied { listen } for pid=5697 comm="nxlog" lport=1514 scontext=system_u:system_r:nxlog_t:s0 tcontext=system_u:system_r:nxlog_t:s0 tclass=tcp_socket Was caused by: Missing type enforcement (TE) allow rule. You can use audit2allow to generate a loadable module to allow this access.
Additional log messages will be generated for any other file or network action not permitted by the SELinux policy. These actions would all be denied by SELinux when set to enforcing mode.

Use the helper script --update option to add additional rules to the policy based on logged policy violations with the nxlog context. Review the suggested changes and press y to update the policy. If no changes are required, the script will exit zero.

$ sudo ./nxlog.sh --update

Example 9. Updating the Policy

The script will offer to add any required rules. The following output corresponds to the example in the previous step.

$ sudo ./nxlog.sh --update
Found avc's to update policy with

require {
    type nxlog_rw_t;
    type nxlog_t;
    class capability dac_override;
    class tcp_socket { bind create listen setopt };
    class file execute;
    class capability2 block_suspend;
}

#============= nxlog_t ==============
allow nxlog_t nxlog_rw_t:file execute;
allow nxlog_t self:capability dac_override;
allow nxlog_t self:capability2 block_suspend;
allow nxlog_t self:tcp_socket { bind create listen setopt };
corenet_tcp_bind_generic_node(nxlog_t)
corenet_tcp_bind_unreserved_ports(nxlog_t)
Do you want these changes added to policy [y/n]?

Set the SELinux policy to enforcing mode. This can be set permanently in /etc/selinux/config.
```
$ sudo setenforce 1
```
Reboot the system.

19.3. Running Under a Custom Account on Windows

On Windows, the NXLog installer sets up the NXLog service to run under the local system account. This procedure describes how to configure a system service for NXLog that runs under a dedicated svc-nxlog user account. This approach can improve security by limiting the privileges that NXLog requires to run.

Note	In enterprise environments managed by Group Policy, the dedicated user account and its permissions must be managed by the domain administrator.

Create a new user account. Open the Computer Management console (compmgmt.msc), right-click on Local Users and Groups › Users, and select New User… from the context menu.
Enter the svc-nxlog user name, description, and password; enable the Password never expires check box; and click Create.
Open the Services console (services.msc), right-click the nxlog service, and select Properties.
Under the Log On tab, select the This Account radio button, click Browse…, select the svc-nxlog user account, and enter the password. Then click OK. Windows will warn you that the service must be restarted.
Open the Local Security Settings console (secpol.msc) and select Local Policies › User Rights Assignment in the left pane.
Right-click the Log on as a service policy and click Properties.
Click Add User or Group… and select the new user. The new user should appear in the list. Click OK.
Add the new user to the the Manage auditing and security log policy also.
In Windows Explorer, browse to the NXLog installation directory (by default, C:\Program Files (x86)\nxlog on 64-bit systems), right-click, and select Properties. Under the Security tab, select the new user from the Group or user names list. Check Allow for the following permissions, and then click OK.
- Modify
- Read & Execute
- List Folder Contents
- Read
- Write
In the Services console (services.msc), right-click the nxlog service and select Restart.

Check the NXLog log files for start-up errors. Successful startup should look like this:

nxlog.log

2016-11-16 16:53:10 INFO nxlog-4.6.4661 started
2016-11-16 16:53:10 INFO connecting to 192.168.40.43
2016-11-16 16:53:12 INFO successfully connected to 192.168.40.43:1514
2016-11-16 16:53:12 INFO successfully connected to agent manager at 192.168.40.43:4041 in SSL mode

Note

On some Windows systems, this procedure may result in the following access denied error when attempting to access the Windows EventLog:

WARNING ignoring source as it cannot be subscribed to (error code: 5)

In this case, wevtutil can be used to set ACLs on the Windows EventLog. For more details, see the Giving Non Administrators permission to read Event Logs Windows 2003 and Windows 2008 TechNet article.