Quantcast
Channel: Ivanti User Community : All Content - Patch Manager
Viewing all articles
Browse latest Browse all 1121

Using a Core Server to Download Patches for Other Cores with Limited Internet Access (Dark Core)

$
0
0

Scenario

Customer uses IP filtering to prevent workstations and servers from downloading files from non-trusted sites.  This is to both prevent unapproved software installs and to prevent viruses from being downloaded and/or communicating with a Command and Control Server.

 

Even normally benevolant websites like Microsoft may be blocked to prevent unapproved software from being installed or untested patches from being applied.

Challenge: How to Get Patches to Clients?

With the IP filters in place, clients and servers can't get to Microsoft or other sources to download files.

Even the LANDESK Product Core Server has limited access to prevent unapproved software or patch access.

 

Environment

1 core server (named "Test LANDESK Core in diagram below) that has full access to the intenet so it can download patches from the various vendor websites (Microsoft, Apple, Adobe, Google, etc).  This core is used for testing new patches and has a small number of test clients connected to it for testing purposes.  Because it is not in production it is allowed greater access to the internet.

 

The second core, "Production LANDESK Core Server", only has access to LANDESK.com and can't download patches directly from the vendors.  This is the core that client systems connect to for Patch Management.

 

This is not a true “air-gap” dark core, as the prod core can “see” patch.landesk.com to pull the XML patch vulnerability content, but not the patches.

 

In contrast, the test core has access to the patch defintions and patches from the vendors, but does not have the “detected vulnerabilities” data that is on the production core.

 

patchDownload.jpg

 

Overview of Solution

By first copying detected definitions from the Production core to a custom group on the Test Core, we can target which patches need to be downloaded.  Then only the needed patches can be copied to the production core.

 

This greatly reduces the number of patches and the diskspace used for storing the patches when compared to the size of downloading all patches.

 

Preparation

Before starting it is important to only scan devices for vulnerabilities that are current.  Scanning for replaced definitions will cause unneeded patches to be downloaded.

 

Please see this document that outlines how to disable replaced rules: http://community.landesk.com/support/docs/DOC-24633

 

Setup on Production Core

  1. On Production core - Select all “Detected Vulnerabilities” and export as .ldms file

detectedVul.jpg

Exporting.png.jpg

Exporting.png

2. Copy exported .ldms file to test core.  Create new public custom group, in this example "Exported Product Vulnerabilities".  Import the .ldms file into this new group using “Insert items into selected group or owner”.

 

customGroup.jpgImport.jpg

MidOpt.jpg

3. Select all vulnerabilities in this this custom group and “Download associated patches…”.  Select “Show all associated patches”.  You can chose to download all patches, any that have already been downloaded will be automatically skipped by the downloader.

selectAll.jpg

Download.png

4. Copy patch files from the test core server ldlogon\patch folder to the production server ldlogon\patch folder.

 

This can be automated by using Content Replication.  See this doc: http://community.landesk.com/support/docs/DOC-20779

 

Special thanks to LANDESK SE, John Wycoff, for his help on this document.


Viewing all articles
Browse latest Browse all 1121

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>