Overview
This article covers the concepts and the architecture of GFI LanGuard and the general approach to advanced troubleshooting. After reviewing this article, you will get a high-level view of GFI LanGuard components and building blocks, an understanding of the main operations, and important data flows.
Introduction
High-Level View on GFI LanGuard
On the top level, any LanGuard installation is made up of two main parts – the UI Interface (Lanss) and the Scanning Engine (Agent). Essential components that are deployed with the Scanning Engine are:
- Attendant Service - Windows Service is responsible for managing all the modules/plugins
- LNSSCommunicator - DCOM engine being used for communications and to enumerate required information
The Scanning Engine also (can be) deployed as an Agent on the remote computers. The following diagrams show a representation of the various components of GFI LanGuard:
Another optional component, a web console that unifies multiple GFI LanGuard installations for reporting purposes, can be deployed separately or along with GFI LanGuard's main installation - Central Management Service (CMS). CMS has its own set of files, database, and is not involved in the LanGuard server operations or activities. Refer to LanGuard Services and Components for more information about the services installed and the LanGuard components.
Note: Both agentless and agent scans are using the same Scanning Engine, just installed on the server (agentless) or a target computer (agent). And no, the agentless scan of the target computer with an agent installed would not try to delegate the operation to the remote agent.
Logging
Many advanced troubleshooting cases require logs analysis to find errors or anomalies, and on the diagram above you can find the name of the debug log file below each component. LanGuard is using a GFI logger, which is writing text logs in the .csv files split by module, date, and size.
Still, most debug log files contain information for more than one module. Moreover, LanGuard is multithreaded, which allows it to support scanning multiple machines at the same time. Therefore it is important to identify the module and thread that is giving the problem, after that it would be much easier to find lines specifically for that module/thread.
Usually, logs are gathered using the GFI Troubleshooter, which provides details about the environment, program configuration, and process execution.
The logs are located in a subfolder of the data directory, %Data%\GFI\LanGuard 12\DebugLogs\. For example, Agent debug logs:
Description
This section describes the main LanGuard operations and User activities, process flows, and components involved. In order to not overload one article, the information will be split into separate articles and referenced wherever appropriate.
Configuration
Make sure to understand the correct network settings and security permissions required for LanGuard to perform operations on remote computers. The root cause of many issues is often the wrong configuration somewhere on the road. During the troubleshooting session pay attention to:
Lanss operations and activities
The Lanss main operations/activities and the components involved are demonstrated in this diagram:
Scanning
Regardless of whether it is a Manual/Interactive or an Agent scan, ie where the load is being handled, the actual scanning process follows the same pattern. Refer to LanGuard Scanning Process Workflow for a more in-depth and precise understanding of how scans work.
Remediation
Similar to Scanning, the actual Remediation (Deployment) process always follows the same steps. Refer to LanGuard Remediation Process Workflow and Troubleshooting Guidelines for a more in-depth and precise understanding of how remediation works, various components and modules involved, logs to follow, and troubleshooting guidelines.
Agent Deployment
The LanGuard Agent deployment works in the same way as normal patch deployment (Remediation) except that the installation file is called LanGuard12Agent.msi and the command executed by the PatchAgent differs. Just refer to the process and logging described in LanGuard Remediation Process Workflow and Troubleshooting Guidelines.
Linux and macOS Operations
Unlike Windows operations, Linux scanning and patching by LanGuard are agentless and based on SSH scripting. This article describes the processes involved and troubleshooting guidelines.
Program Updates
On a surface, Program Updates enable GFI LanGuard to detect the latest vulnerabilities and maintain its scanning performance. But there's more to this - practically all LanGuard components and modules are updated through the same Program Update procedure.
Essentially this means, that the Program Updates issue can be the root cause for problems down the road, make sure to understand the Program Updates Workflow and Troubleshooting Guidelines.
Installation / Upgrade / Migration
The installation of the GFI LanGuard is pretty straightforward, as long as all the system requirements are met. If one day there would be a case requiring advanced troubleshooting, triage it with the installation logs and Windows event logs.
Upgrade and Migration are more challenging, refer to Upgrading GFI LanGuard to the Latest Software Version article and GFI LanGuard Migration to a New Server
Agent Communications
During LanGuard operations, Server with Agents interactions, as well as communications between components and modules are happening all the time, in various ways. Refer to LanGuard Agent Communications Workflow and Diagnostic for a better understanding of what components are involved and how they communicate.
Apache Logging
The Apache error and access logs under %Data%\GFI\LanGuard 12\DebugLogs\Httpd allow us to follow requests and their HTTP result codes, as well as review an error.log file.
Databases
For information about databases and the Scan Results' Database structure refer to this article. It might be useful to know, that LanGuard historically does not use Stored procedures and functions, it builds full queries based on templates in the resources.
READ COMMITTED isolation level is being used for Lanss and CMS databases. In the case of deadlock, the preference is to repeat the query.