The goal of this document is to act as a guide on not only how to perform a vulnerability scan but also what to do when a scan doesn't work correctly.
- 2017.3 agent and MAP Agent (2016.x and 2017.1)
- Clients will need access to their own patch repository. This requirement can vary according to the OS flavor. Some examples and notes and below:
- Red Hat versions will require a support agreement
- CentOS is free but access (ports, resolution, firewall, etc) will need to be allowed.
- Some versions of Linux can make use of a "satellite server" which is a local repository of patches so each client can get the needed patches locally instead of going to the internet.
- Clients will need an Ivanti EPM agent installed
- A "landesk" user will need to be created and added to the /etc/sudoers file. The user needs to be called "landesk" as well. A lot of what the agent does runs under restricted permissions but there are a few cases that may require elevated permissions.
- Case for elevated permissions:
- Inventory. Slightly more inventory information is available if "landesk" is given root privileges.
- Vulnerability Remediation. Remediation almost always requires a package which requires root privileges.
- Software Distribution. Elevated privileges are required to install software.
- NOTE: It is highly recommended to use the command "visudo" to edit the /etc/sudoers file. The command visudo will check the file for validity when saving and help prevent typos and other errors.
- Entries needed for the "landesk" user in the /etc/sudoers file
- Case for elevated permissions:
- Vulnerabilities need to be downloaded to the core server before a client machine will show vulnerable. For a detailed walk-through see: How to detect and remediate Linux vulnerabilities
- An agent needs to be installed on the client
- A vulnerability scan needs to be performed.
- Example command: /opt/landesk/bin/vulscan -V255
- This command increases the verbosity of the logging on the scan
- This command can be executed from the console by right-clicking on a machine, however, Agent Status (Discovery) needs to be functional. See the communication information in the troubleshooting section below
- A repair task for a specific vulnerability needs to be configured and executed
- A policy supported push is the most common type to use
- If the push doesn't succeed (for whatever reason) then a policy scan will need to be invoked on the client: /opt/landesk/bin/policy
- You can right-click on a specific machine, select Security and Patch, then select Security and Patch Information. This will display all of the detected and installed information.
- A second vulnerability scan may need to be performed. This is to report the vulnerability is no longer present
- Note: Kernel patches may still show vulnerable if the affected older kernel files are not removed from the machine
Additional Note: You can see what a machine is vulnerable for by right-clicking and selecting "Security and Patch Information".
Troubleshooting, Help, and Logs:
- How to troubleshoot Linux and Unix
- Gather Logs Utility: This is a utility that's included with the agent. The utility will gather logs and other important agent configuration information and compile it into a tar ball to send to Support.
- Command to tell what ivanti or landesk processes are running on a Linux machine: "ps -ef | grep landesk"
- See the screen shot below. In this case only CBA and the grep command (when running the command above) are currently in memory
- How to search for a vulnerability using "vi" (Linux editor)
- Edit the vulnerability.log: vi /opt/landesk/log/vulnerability.log
- Enter command mode by holding down the shift and colon keys. You should see a colon at the bottom of the screen: SHIFT and :
3. Search for the vulnerability by package name. You can find the name in the properties of the vulnerability. You can search by prefacing the name with a "/"
Note: In this case I searched using the first part of the full name but the full name can be used
Note: The cursor moves to the targeted line in the file. Repeat the steps to find the next line.
In most cases the requested package and installed package are compared and the results are displayed.
- Linux clients (just like windows) are affected by common communication problems between the core and client.
- DNS resolution forward and reverse between the core and client
- Firewalls and ports. The Linux agent doesn't add exceptions to the firewall. This needs to be done manually according to what firewall is in use.
- Firewalls cause a large majority of Agent Status and Discovery issues (icons in the console)
- The "cba" client as shown above in this section, needs to be running to receive instructions from the core server
- Analyze the vulnerability definition on the core server.
- Find a vulnerability in the console.
- Right-click and select properties.
- Click on a specific vulnerability name and select properties again. Analyze all of the information.
Example: This screen shot shows what platforms the vulnerability affects. This information is usually correct but if it's not, log a case with support to get the content corrected. Other settings should be verified too when troubleshooting.
- Analyze the update log for the particular version of Linux that you are working with.
- Log location for most logs: /var/log
- Update and utility will vary by Linux flavor. Some examples are below but these examples may vary by version as well. Search the internet for patch logs related to a specific build
- Red Hat = Yum (var/log/yum.log). Up2date was used in older versions.
- Ubuntu = Read the history.log located in /var/log/apt
- SUSE = /var/log/zypp/history
- At the time of this writing Linux clients cannot communicate through a Cloud Services Appliance (CSA). This feature is on the road map to be added in a future release. No date is currently available.
- Linux Kernel Vulnerabilities
- Issue: Some Linux kernel vulnerabilities may continue to show in the All Detected section of the Security and Patch Information window. The reason for this is that older kernel files still reside on the client. If these files are used then the client will be vulnerable again. An enhancement is planned to add detection for the currently running kernel. This enhancement will be in the future and no date is currently available.
- Fix: Remove the older vulnerable kernel files
- Additional Note: HOW you remove the older kernel files will depend on the flavor and version of Linux. The following command may help in displaying older kernels still on the machine. "rpm -q kernel". Please research with the distribution you are working with to find the proper method. As noted above the vulnerability scanner is making calls to the OS for vulnerabilities. It then compares vulnerability content based on what it finds.
- The "History" portion of the Security and Patch Information window does not work at this time and will display an error (see screen shot below).
- The error is "Certificate based authentication failed" and "Client did not submit a certificate"
- This error is due to the client-certificate based security feature. Linux clients don't currently use this feature but plan to in the future.