Purpose

This article instructs administrators on how to forward failed login attempts from the Citrix App Layering web console to a SIEM / Syslog log collector like Splunk.

Audience

For system administrators responsible for managing the Citrix App Layering appliance, particularly those concerned with auditing logon failures, this article will provide a detailed walkthrough on leveraging the Linux shell and SSH capabilities to accomplish this task. This method is especially valuable given that AppLayering itself does not natively support direct log monitoring or alerting on such events.

Reference Configuration

Our reference configuration would be a Citrix App Layering appliance (formerly ELM) with LDAP configured for logons. This entails the following requirements.

Citrix App Layering appliance
App Layering root account
LDAP configured within the appliance

Limitations of App Layering Appliance

App Layering does not natively have a way to forward logs, so administrators of this appliance are left looking for other ways to make this happen. Given that the appliance is built upon CentOS 7.9, the native tools provided in the operating system can be used to facilitate this requirement. Logs generated from the appliance are stored in flat files that can be accessed through many different methods. However, for the sake of simplicity, we will cover a quick way to forward logs.

Disclaimer

As we are making changes to the underlying appliance OS, it is possible an upgrade might revert the settings we’ll make. So, as a good practice, post-appliance upgrades would be prudent to validate that the logging configuration is still functioning and the configurations are in place. It is also possible that the ability to achieve the desired outcome is added to the appliance in the future natively. At this time, the configurations outlined below should ideally be removed.

Configuration Steps

Step 1

To begin, access the App Layering console and then generate some login failure attempts using any web browser.

Step 2

Log into the appliance using the root account and confirm that the login attempts are being recorded inside the /var/log/Unidesk/web.log file. As seen in the picture below, this grep command will return all the single lines that contain the username and the IP address (removed).

# grep -i “Attempted login” /var/log/Unidesk/web.log

Step 3

The web.log file contains attempted logins, among other information related to the console. Now it is time to use rsyslog, which comes with CentOS. The directives provided can either be appended into “/etc/rsyslog.conf” or “/etc/rsyslog.d/10-weblogin.conf.” The rsyslog.d directory adds any .conf file into the main rsyslog.conf file, so the base filename can be anything. The text editor vi is my go-to. However, any text editor installed on CentOS can be used if that is the preferred way.

Here, I will be using the legacy syntax for rsyslog. This is the simplest version of what can be done with Syslog to poll through the /var/log/Unidesk/web.log file for any occurrence of “Attempted login” and send it out to the listening server using UDP (designated with @@).

Step 4

With the use of a state file, this would prevent sending out duplicate data. The state file can be seen in /var/lib/rsyslog/ for troubleshooting purposes.

$ModLoad imfile

$InputFileName /var/log/Unidesk/web.log

$InputFileTag login:

$InputFileStateFile statefile-web.log

$InputFileSeverity error

$InputFileFacility local7

$InputRunFileMonitor

:msg, contains, “Attempted login” @@<server>:514

Step 5

Once the config file looks as expected, restart the rsyslog service and verify that the logs are seen remotely. Verify that the service is running after a restart and there were not any typos in the directives strong enough to make the service fail to load.

# systemctl restart rsyslog

# systemctl status rsyslog

Step 6

When troubleshooting, tcpdump can be a quick way to verify that traffic is being sent out. The bad udp checksum can be ignored, however, verifying that the exact facility.error and message content are being sent can speed up diagnosing any blocks along the path to the log server.

Step 7

As seen below, Events are now being stored persistently in Splunk and in this case being stored in a new index (that was created outside of this article).

Conclusion

This use of rsyslog is straightforward and quite simple however, the ability to load additional modules and transform this single line into a JSON format is available if additional information is required. Rsyslog is a standard and powerful logging utility installed by default with CentOS that would otherwise not be able to fulfill any request for login failure attempts otherwise on this appliance natively.

Michael Wieloch

Michael is a multi-disciplinary consultant with expertise in digital workspaces, networking, security, virtualization, DevOps, and Linux. When not engineering systems or building ZFS clusters, he enjoys cruising the streets on his motorcycle.