Welcome to Nextron System's Manual for the ASGARD Management
Center v3.
Note
If you are still using an older version of the Management Center,
please click here
to see the older version of the documentation.
ASGARD Management Center is the central management platform for THOR
scans. It manages distributed THOR scans on thousands of systems,
collects and forwards scan results.
Furthermore, ASGARD can control and execute complex response tasks,
if needed. It features built-in response playbooks for quarantining
endpoints, creating and collecting triage packs, opening a remote
command line and other actions incident response specialists will
find useful.
In this chapter we will go over the requirements
needed to get your Management Center up and running.
Please follow the following steps carefully and don't
skip anything, as you might encounter problems during or
after the installation.
ASGARD Management Center is the central management platform for THOR scans.
It manages distributed THOR scans on thousands of systems, collects and
forwards scan results.
The ASGARD Management Center can control and execute complex response tasks
if needed. It features built-in response playbooks for quarantining endpoints
creating and collecting triage packs, opening live remote command prompts and
other actions incident response specialists will find useful.
ASGARD additionally provides an easy to use interface for creating custom
multi-step response playbooks, which can execute any command on your endpoints
and collect the respective outputs.
ASGARD Management Center is available as a virtual appliance and also as a
hardware appliance. Both are based on Debian Bullseye and require a setup procedure
in order to generate customized agent installers and cryptographic keys.
This document describes all functions and steps for the setup and operation of
the ASGARD Management Center. It will describe how to add systems for scanning
and performing individual or group scanning with separate parameters.
There are a few things to consider before you start with the installation.
The communication between ASGARD and the ASGARD agent is unidirectional.
The ASGARD agent polls the in a given time frame and ask for tasks to
execute. There is no active triggering from ASGARD to the ASGARD agent –
we have designed it that way, because we believe that opening a port on
all connected endpoints should and can be avoided.
In environments with up to 500 endpoints, the default polling interval
is around 20 seconds. In larger environments the polling interval increases
automatically up to one minute for 2.000 endpoints and 10 minutes for
configurations with 25.000 endpoints connected to a single ASGARD.
For this reason larger environments are not as responsive as small environments
when it comes to opening remote shells or executing urgent response
tasks. It may take up to 10 minutes for the shell to open or results of a
THOR scan to show up. Once a task is running, like the remote console for
example, the connection becomes almost instant.
Most environments contain endpoints which need faster polling between the
agent and your ASGARD Management Center. For this reason we implemented a
FastPoll mode which can be set individually on a per host basis. For
more information, please see Asset Overview.
ASGARD supports using a standard http proxy for the entire Agent to
ASGARD communication. In order to use a proxy, the ASGARD agent must
be repacked after installation. For details, see Creating Custom Agent Installer.
ASGARDs hardware requirements depend on the number of connected
endpoints and also on the intended use. For example, you should
consider using more disk space if you are planning to use Bifrost
or ASGARD's evidence collection feature extensively.
The ASGARD Agent, which needs to be installed on endpoints, is a lightweight
service which is used to establish as secure connection with your Management
Center. Memory usage of the agent is around 50 MB, which makes it very unobtrusive.
THOR uses up to 1 GB of RAM additionally when scanning is in progress. This
value will vary depending on the operating system THOR is running on. We
observed lower RAM usage on unix systems all together, whereas Windows
endpoints generally use more RAM.
The agent will use up to 50 MB of hard disk. Together with THOR and its
temporary files it uses a maximum of 200 MB in total.
Please note that some response actions, such as collecting triage packs
or collecting the system's RAM, require additional disk space.
There are no requirements pertaining to the CPU as scans can be scheduled
in a way that THOR reduces its own process priority. This limits the CPU
usage to a configurable percentage, with the tradeoff being prolonged
scan times. There are multiple ways to facilitate THOR scans to your
environment, which you can find in our separate
THOR Manual.
Supported operating systems are the ones
supported by THOR.
Not supported are the operating systems with limited or special THOR support.
ASGARD and other systems which will have to communicate with each other,
need the following ports opened within the network. For a detailed and up
to date list of our update and licensing servers, please visit https://www.nextron-systems.com/hosts/.
The ASGARD systems are configured to retrieve updates from the
following remote systems via HTTPS on port 443/tcp:
Product
Remote Systems
ASGARD packages
update-301.nextron-systems.com
THOR updates
update1.nextron-systems.com
THOR updates
update2.nextron-systems.com
All proxy systems should be configured to allow access to these URLs
without TLS/SSL interception. (ASGARD uses client-side SSL certificates
for authentication). It is possible to configure a proxy server, username
and password during the setup process of the ASGARD platform. Only
BASIC authentication is supported (no NTLM authentication support).
ASGARD needs to be able to resolve internal and external IP addresses.
Warning
Please make sure that you install your ASGARD with a domainname
(see Network Configuration). If you do not set the
Domain Name and install the ASGARD package, your clients won't be able
to connect to your ASGARD.
All components you install should have a proper domain name configured
to avoid issues further during the configuration.
The Nextron Universal Installer requires Internet access during the
setup. The installation process will fail if required packages cannot be
loaded from https://update-301.nextron-systems.com
The installation and update processes do not accept an unknown but valid
SSL/TLS certificate presented by an intercepting entity and therefore
don't support SSL/TLS interception.
Since our products are usually used in possibly compromised
environments, the integrity of our software and update packages has
highest priority.
We recommend excluding certain folders and binaries from Antivirus scanning.
The exclusions will not only prevent Antivirus engines from removing the
agents and scanner executables but also increase scan speed, since their
real-time engines won't check every file that the scanner has opened for
analysis. This can improve the scan speed by up to 30% and also reduces
the system's CPU load.
We recommend using this list - include all sub folders:
Folder Exclusions including Subfolders
Windows
%SYSTEMROOT%\System32\asgard2-agent\
%SYSTEMROOT%\Temp\asgard2-agent\
Linux
/usr/sbin/asgard2-agent-service
/var/lib/asgard2-agent/
/var/tmp/asgard2-agent/
macOS
/var/lib/asgard2-agent/
/var/tmp/asgard2-agent/
Note
If you have obfuscated the agent name, replace asgard2-agent with your custom agent name.
If you have to create a more specific list that can use wildcards, use
the following list (and replace [random] with the wildcard). If you have
the choice, the broader approach above should be preferred.
Using the more specific list, we've experienced problems with some
AV solutions that even trigger on certain keywords in filenames. They
don't kill the excluded executable but block write access to disk if
certain keywords like bloodhound or mimikatz appear in filenames.
In these cases, the executable exclusions are not enough and you should
use the recommended list of two folders and all sub folders (see above).
McAfee needs Exclusions set in multiple locations. In addition to the
general recommendation, customers with McAfee EDR need to set the following exclusions.
You can do a quick hash check to verify that the download was not corrupted.
We recommend to verify the downloaded ISO's signature as this is the cryptographically sound method.
The hash and signature file are both part of the ZIP archive you download
from our portal server.
use@unix:~/temp$ wgethttps://www.nextron-systems.com/certs/codesign.pem
use@unix:~/temp$ openssldgst-sha256-verifycodesign.pem-signaturenextron-universal-installer.iso.signextron-universal-installer.iso
Verified OK
or in Powershell
PS C:\temp\nextron-universal-installer>Invoke-WebRequest-Urihttps://www.nextron-systems.com/certs/codesign.pem-OutFilecodesign.pemPS C:\temp\nextron-universal-installer>"C:\Program Files\OpenSSL-Win64\bin\openssl.exe"dgst-sha256-verifycodesign.pem-signaturenextron-universal-installer.iso.signextron-universal-installer.isoVerified OK
Note
If openssl is not present on your system you can easily install
it using winget: wingetinstallopenssl.
In this chapter we will show an example installation with
VMware ESXi and the provided ISO image to install the
Management Center. Please pay good attention to the setup
during the Debian Installer, since this contains important
steps which might break your installation!
Important
ASGARD products require a FQDN, which needs to be resolvable
from all onboarded assets. If assets cannot resolve the FQDN
specified during installation, a connection will not be possible.
Create a new VM with your virtualization software. In this case,
we will use VMWare ESX managed through a VMWare VCenter.
The new VM must be configured with a Linux base system and Debian
GNU/Linux 12 (64 bits) as target version. It is recommended to
upload the ASGARD or Master ASGARD ISO to an accessible data
store and mount the same to your newly created VM.
Please make sure to select a suitable v-switch or physical interface that
reflects the IP address scheme you are planning to use for the new ASGARD.
Only use one Hard Disk for the installation.
The installation Process is started by clicking on ASGARD Graphical install.
The installer then loads the additional components from the ISO and lets you select location and language.
Warning
Please make sure to select the correct Country, as this will also set your local timezone!
If DHCP is available, network parameters will be configured automatically.
Without DHCP, ASGARD drops into the manual network configuration dialogue.
Without DHCP, ASGARD proceeds with the manual network configuration dialogue.
ASGARD needs to be able to resolve internal and external IP addresses.
Important
Important: Make sure that the combination of hostname and domain
creates an FQDN that can be resolved from the endpoints on which you
intend to install the ASGARD agents. If you've configured a FQDN (hostname +
domain) that cannot be resolved on the clients, no agent will be able
to find and reconnect to the ASGARD server.
This is especially important since your Management Center will create
some certificates during the installation, which will not contain an
IP Address as its Subject Alternative Name (SAN), but only the FQDN!
You will not be able to connect your ASGARD Management Center with
your Analysis Cockpit via IP Address.
ASGARD is intended to be installed with only one disk.
Do not configure your server with multiple disks.
The system won't configure additional disks. Make sure
that your disk has the recommended size. See
Hardware Requirements
for more information.
Finally, write your configuration to the disk by selecting "Yes" and clicking "Continue".
If you are using a proxy to access the internet, enter the proxy details in the next step.
Please note, Internetconnectivityisrequired for the next step – the installation of the ASGARD service.
The base installation is now complete. In the next step we will install the ASGARD service.
For this step Internetconnectivityisrequired.
The Nextron Universal Installer is a web based installer
which will guide you through the installation of our
ASGARD products. The Nextron Universal Installer will install
one of the following products on your server (this manual
focuses on the ASGARDManagementCenter):
Hint
if you want to install the Master ASGARD, please use
the correct license and product (MasterASGARD)
in the Nextron Universal Installer.
ASGARD Management Center; alternatively if your license permits:
ASGARD Broker
ASGARD Gatekeeper
ASGARD Lobby
Master ASGARD
ASGARD Analysis Cockpit; alternatively:
Elasticsearch Cluster Node for ASGARD Analysis Cockpit
ASGARD Security Center, in the following variants:
ASGARD Security Center (Backend Only)
ASGARD Security Center (Frontend Only)
ASGARD Security Center (All-in-one, unrecommended)
Note
You can only install one product on one server, since the
products are not designed to coexist on the same server.
The exception being the ASGARD Security Center (All-in-one).
The installation takes roughly between 5-15 minutes, depending
on your internet connection and the server you are installing
the product on.
If you encounter problems during your installation, please see
Diagnostic Pack for further instructions.
After the ISO installer is finished with the setup,
you will be greeted at the console login prompt with
the following message:
Follow the instructions and navigate to the webpage
displayed on your console. You will most likely get
a browser warning when you connect the first time to
the page. This is due to the page using a self signed
certificate, since it will only be used to install the
ASGARD Management Center. You can safely ignore this
warning and proceed to the page.
You will be greeted with a small introduction as to what
the Nextron Universal Installer is and what it does. After
you click Next, you will be presented with the landing
page of the Nextron Universal Installer.
Enter the Installation Code from the terminal and click
Next. The Installer will now guide you through the
installation.
The Nextron Universal Installer will try to connect to our
update server in order to download all the necessary packages
once the installation starts. Make sure you can reach the
update servers (see Internet Access during Installation).
Please configure your proxy settings if you are behind a
proxy (see Proxy and NTP Settings).
The Nextron Universal Installer will prompt you to verify the
FQDN which you configured during the installation of the base
system (see Network Configuration). This
is needed in order for your ASGARD Agents to communicate via
a HTTPs connection with the ASGARD Management Center. The Agents
will use the FQDN to connect to the ASGARD Management Center and
also verify the Common Name of the certificate to verify its
authenticity. If there is a mismatch the Agents will not be able
to connect to the ASGARD Management Center.
If the displayed FQDN is not correct, you can change it by
clicking on the ViewFQDNChangeInstructions button.
This will open a dialog with instructions on how to change
the FQDN of your server. Once you have changed the FQDN,
you can continue with the installation.
If you are in a time critical engagement and need to proceed
with the installation, you can just confirm the displayed (and
technically invalid) FQDN and change it later (before you deploy
your Agents). To do this, see
Regenerate ASGARD Server Certificate Agent Communication
If you need to configure a proxy or change the NTP settings
of your system, you can do so by clicking on the Settings
button in the left menu of the Nextron Universal Installer.
If you configured a proxy during the ISO installation, those
settings will be carried over into the Universal Installer.
The settings will also be carried over into your ASGARD
Management Center. The same goes for NTP.
In case of errors or problems during the installation, you can
download a diagnostic pack by navigating to the Diagnostics
tab in the left menu of the Nextron Universal Installer. Click
on the DownloadDiagnosticPack button to download the
diagnostic pack. You can then send the diagnostic pack to our
support team for further analysis.
The initial system status page provides a summary of the
most important system components.
It also includes the current resource consumption (disk,
CPU and memory) and lists the currently installed Management
Center software version, along with available versions of THOR.
The connection status to the update servers, Master ASGARD
and Cockpit are shown as well as multiple graphs which show asset
connections and asset streams.
Note
The THOR version numbers may be missing in a new installation.
THOR is not included in the installed packages and has to be
downloaded first. The download is starting automatically after
the installation, not later than one hour after installation.
The diagnostics sub menu shows the periodically performed checks
and their status. Clicking the magnifying glass icon shows details
of the performed check. If a check failed it gives a detailed error
message and hints on which steps typically help in resolving the issue.
The indicator on the top right always shows if any of those checks
failed by showing a warning or error (i.e. yellow or red icon). You
can click the icon to view the diagnostics page as a pop-up.
The logs section shows the latest and most relevant logs.
Complete logs can be found at /var/lib/asgard-management-center/log.
You can also download the selected log type directly.
In order to register a new endpoint to the ASGARD Management Center,
download and install the ASGARD Agent on the system you want to register.
The ASGARD Agent can be directly downloaded from the Management Center
login screen through the button DownloadAgentInstallers. A list
of available agents for various operating systems appears.
Hint
You can disable the downloading of agents on the login screen. Please
see Advanced Settings.
After the installation, the endpoints will connect to your Management
Center, register automatically and appear in the Asset Management Section
in the tab AssetRequests. Please allow two or three minutes for systems to show
up. The agents use the FQDN to connect to your Management Center, so ensure that
your endpoints can resolve and reach the Management Center via FQDN.
Note
Full administrative privileges are required for the ASGARD agent
and THOR to operate properly.
In the requests tab, select the agents you want to allow on your Management
Center to manage and click AcceptAssetRequests. After that, the
endpoint shows up in the assets overview and is now ready to be managed and scanned.
A registered agent will poll the Management Center at a given
interval between 10 seconds and 10 Minutes – depending on the number of
connected endpoints (see Performance Tuning for
details). If your Management Center has scheduled a task for the endpoint (for example:
run THOR scan) it will be executed directly after the poll.
Since the Agent Installer for Windows is a normal .exe file and not a
.msi file, you need to write your own scripts to deploy the agent via
your management system of choice. We have written an example script in
PowerShell, which should work for most of the tools. Please see the section
Installing ASGARD Agent via Powershell Script and
Deploy ASGARD Agents via SCCM.
Alternatively, if you want to deploy the ASGARD Agent manually, you can
just execute the installer by hand.
You will be able to deploy your agents via most of the common linux tools,
just make sure that the installer is being installed with administrative
privileges.
Starting with macOS Big Sur (v11.0), Apple requires software developers
to notarize applications.
Due to the nature of the asgard2-agent installer, which is generated
during installation time on your Management Center, and making it unique
for each Management Center installation, it iss currently not possible
to notarize the installer.
This document aims to describe possible workarounds, intended to be a
reference for IT administrators or IT packaging teams to bypass Apple
verifications and install the personalized asgard2-agents on macOS
Big Sur (or newer) workstations.
Warning
Executing any of the workarounds described in this document puts your
system at risk for a short period of time. This document will deactivate
global security mechanisms of the operating system, which are intended to
protect the integrity of the system. Please make sure to follow the below
steps carefully and enable those security mechanisms after you are done.
Please always keep in mind to check your system after performing any of
the described actions, to ensure that all security mechanisms are in
place and are re-activated after performing the described actions.
Please follow the below steps to install the ASGARD Agent on macOS.
Open a new terminal session
Deactivate macOS Gatekeeper
sudospctl--master-disable
Close the terminal and open a new terminal session
Since macOS Ventura (v13.0) the ASGARD Agent needs full disk access
to function properly. After you have deployed the ASGARD Agent, you need
to grant the service the required access permissions. Please keep in mind
that administrative privileges on the machine are needed to perform this
change.
To do this, navigate on your Mac to SystemSettings > Privacy&Security > FullDiskAccess:
You need to enable the asgard2-agent-service slider:
Note
There is no workaround to this step, since it is an integral
part of the security design of Apple devices. If you are having trouble
with THOR scans via ASGARD on macOS, please check if the FullDiskAccess permission for the ASGARD agent was granted. Since macOS Mojave
(v10.14), you need to grant the same permissions to removable volumes,
if you plan on scanning those.
The following listings contain commands to uninstall ASGARD Agents on endpoints.
Note
The commands contain names used by the default installer packages.
If you have generated custom installer packages with a custom service
and binary name, you have to adjust the commands accordingly.
You need administrative privileges to remove the ASGARD Agent from Windows.
Open a command prompt with administrative privileges and run the following commands:
In the Assets view you can see all the connected ASGARD
agents. New assets will be placed under AssetRequests and need a
manual approval before being able to connect to your ASGARD (for auto
accept see Advanced Settings).
If the DuplicateAssets view is visible, you should try to remediate
the issues in a timely manner, since this might cause unwanted side
effects on the duplicate hosts.
Warning
Assets in the DuplicateAssets view indicate that one or more
agents are running on multiple endpoints. This might be caused by
cloning a system with an already installed ASGARD Agent. Undesirable
side effects of duplicate assets are alternating hostnames and tasks
that fail immediately.
Management of all endpoints registered with ASGARD can be performed
in Asset Management. The assets will be presented as a table with an
individual ASGARD ID, their IP addresses and host names.
By clicking the control buttons in the Actions column, you can start
a new scan, run a response playbook, open a command line or switch
the endpoints ping rate to a few seconds instead of a maximum of 10 minutes.
Available Actions (left to right): Run Scan, Run Task,
Connect To Remote Console, Show Timeline, Enable/Disable Fast Poll Mode
Note
The internal ping between the ASGARD agent and ASGARD is based on HTTPS not ICMP
Depending on the user's role some of the control buttons may be disabled
The RunScan button might be greyed out in new installations - this is
because ASGARD did not download the THOR packages yet. You can either wait for a
few minutes, or see the chapter Updates of THOR and THOR Signatures,
to trigger a download manually.
Users can select various columns and adjust their view according to their
needs by clicking the gear wheel in the top right corner of any table.
You can toggle visibility of columns by clicking the icon next to the name.
You can also drag and drop the columns to change the order in the table view.
Labels are used to group assets. These groups can then be used in scans or tasks.
You can add multiple labels to an asset or a group of assets. This is done by
selecting the particular assets in the left column, typing the label name
(e.g. New_Label) and clicking the blue AddLabels button.
Note
Don't use labels with white space characters as it could cause issues in
syncs with your Analysis Cockpit, exports/imports or other underlying legacy
functions.
In order to remove labels, select your assets, click the yellow RemoveLabels
button and type the name of the label you want to remove for these assets.
The asset management section has extensive filtering capabilities, e.g.
it is easy to select only Linux endpoints that have been online today
and have a particular label assigned.
The import function allows you to add or remove labels on assets based on columns in
the previously generated CSV formatted file.
The import function processes the values in the columns AddLabels... and RemoveLabels...
only. In order to change labels, use the already exported list, add values in these
columns and re-import it by using the ApplyLabelsfromCSV button.
Separate multiple labels with comma. Leading or ending white space characters
will be stripped from the labels.
You can search for Assets in your Management Center with the ASGARDSearchQuery.
This allows you to write more complex queries to search for assets. Additionally,
this helps you to be more flexible with your scan/response tasks, since you can
just specify a query and not set labels for all assets first. A good example of
this might be if you want to scan a specific subnet every week, and a new
agent is being deployed in this subnet. You don't have to think of all the
labels or troubleshoot why scans are not being deployed. One example you
could achieve this with is the following query:
system="linux"andinterfaces="172.16.50.0/24"
This would run the task on all linux systems in the subnet 172.16.50.0/24.
The following operators are available:
Operator
Example
Equals
hostname = "win10-dev"
Equals
cpu_count = 1
Contains
hostname contains "win"
Begins With
hostname begins with "win"
Ends With
hostname ends with "dev"
Numerical Comparison
total_memory >= 4 GB
Numerical Comparison
last_seen < 3 days ago (assets that have not been seen since 3 days)
Numerical Comparison
last_seen > 1 hour ago (assets that have been seen in the last hour)
Numerical Comparison
last_scan_completed < 2022-08-17 (assets that have not been scanned since 2022-08-17)
Numerical Comparison
last_scan_completed < 2022-08-17 15:00:00 (assets that have not been scanned since 2022-08-17 15:00:00)
Numerical Comparison
last_scan_completed is never
Boolean
is_domain_controller is true
Boolean
nextping is true (shows all assets with Fast Poll enabled)
Not
not hostname contains "win"
Not
not hostname ends with "dev"
And
hostname contains "win" and not hostname ends with "dev"
Or
hostname begins with "dev" or hostname ends with "dev"
Nested
hostname ends with "dev" and (hostname contains "win" or hostname contains "lin")
Set / Not Set
labels is set (assets that have at least one label)
Set / Not Set
labels is not set (assets that have no labels)
Regular Expression
hostname matches "^[a-z0-9]{(0,6)}$"
Pattern
Use _ to match any single character and % to match an arbitrary number of characters, including zero characters.
Pattern
arch like "a__64" (matches amd64 and arm64, but not aarch64)
Pattern
arch like "%64" (all 64 bit systems, e.g. amd64, arm64, aarch64 or ppc64)
IP Range
interfaces = "172.28.30.0/24"
You can create simple or complex queries this way. You can group/separate queries with brackets:
The following keys for the asset query are available:
Key
Column Name
arch
Arch
client
Agent Version
client_sc
Service Controller Version
first_seen
First Seen
fqdn
FQDN
hostname
Hostname
id
ID
interfaces
Network Interfaces
is_domain_controller
DC
labels
Labels
last_scan_completed
Last Scan Completed
last_seen_agent
Last Seen Agent
last_seen
Last Seen
last_seen_sc
Last Seen Service Controller
nextping
Fast Poll
ping_interval
Poll Interval
system
OS
total_memory
Total Memory
uptime
Uptime
version
OS Version
Hint
You can see which query-name a field has by enabling the column in your asset view
and clicking into the query text field:
The ASGARD Search Query is the preferred tool to manage scans and assets.
If you are using the Analysis Cockpit and need to labels, you can still use
them.
You can move an asset from one Management Center to another via the Maintenance
Module of the Response Control. To do this, navigate to Assets and select the
assets you want to migrate. Alternatively you can navigate to ResponseControl
and add a new task. You can now click the AddTask button to open the Task Menu.
Choose the Maintenance module and then the MoveassettoanotherASGARD Type.
You have to upload an agent installer from the ASGARD you want to migrate the asset to.
Note
The target OS or Arch of the installer doesn't matter, we will only use the installers
configuration data for the migration.
The task will fail if the migrated asset is unable to communicate with the new Management
Center. In this case, the asset will remain on the Management Center which issued the
migration task. Only the asset will be migrated (it shows up as a brand new asset on
your new Management Center), no scan or response tasks and also no logs will be migrated.
Deleting assets will remove the assets from the ActiveOnly asset view and will
invalidate the authentication for those assets.
To delete an asset, go to the Assets View and mark the assets you want
to delete. Click the DeleteAssets Button on the top right corner. Confirm that
you want to delete the assets.
To see all the deleted assets, change your view from ActiveOnly to DeletedOnly.
Warning
Deleted assets can no longer communicate with the ASGARD. Please use with caution.
This cannot be undone, you have to manually fix the asset.
The Scan Control in your Management Center allows you to run different kind of
scans on one or multiple assets. Additionally, you can create ScanTemplates
to use with new scans, so all your default options won't need to be configured
for every new scan. You can also use ScanTemplates to only allow certain
users to execute new scans with them. False-PositiveFilters can be set to
exclude certain files from scan results, or even whole directories.
Your Management Center will also take care of THOR scans which stopped (e.g.
the asset rebooted or lost connection to your Management Center during a scan), so that
a scan will not fail if the asset is temporarily offline.
Warning
When creating a scan job, the Management Center offers almost all possible scan
options that can be used with THOR. Please consider their use with care as there
are options that may lead to incompatibilities, failing scans, or errors.
Scan templates are the most convenient way to make use of THOR's rich set of
scan options. It is possible to define scan parameters for THOR 10 and store
them in different templates for later use in single scans and grouped scans.
The scan templates are also very helpful if you want to automate scanning via
the API, as you don't have to specify all the options, but rather only the
template. This also means you don't have to change your API request, but only
the template.
Imagine you want to use dedicated scan options for different system groups (e.g.
Linux Servers, Domain Controllers, Workstations, etc.) and make sure to use exactly
the same set of scan options every time you scan a particular group of systems.
With your Management Center you can now add a scan template for every group.
A popular use case for scan templates is providing additional resource control – for
example telling THOR to set the lowest process priority for itself and never
use more than 50% of CPU.
Please keep in mind, that we have already optimized THOR to use the most relevant
scan options for a particular system (based on type, numbers of CPUs, and system
resources) and a comprehensive resource control is enabled by default.
For more details please refer to the THOR manual.
Only use the scan templates if you want to deviate from the default.
Scan templates are protected from being modified by users without the
ManageScanTemplates-permission, and can also be restricted from being used
by users in case the flag ForceScanTemplate is set for this user.
(See section Restrictions for details).
By clicking the ImportScanTemplate button you can import a previously
exported scan template.
In order to create a scan template, navigate to ScanControl > ScanTemplates
and click the AddScanTemplate button. The AddScanTemplate dialogue appears.
The current THOR scanner version is chosen for you by default but can be changed if needed.
After choosing or changing a scanner you will find the most frequently used options on
the top of this page in the "Favorite Flags" category. View all THOR options by
clicking on the other categories or quickly search for known flags in the search bar.
By clicking on the star symbols you can also edit your personal favorites.
By checking the "Default" box, you can make this scan template the default template
for every new scan. There can only be one default template at a time and selecting
the box will uncheck a previous default, if set.
Checking the "Restricted" flag will make the template restricted, meaning only a
restricted set of users can use the template for scans. The set of users consists
of all users who do not have the "Force Scan Template" restriction set (by default
those are all users who are not a member of the group "Operator Level 1").
A single scan or standalone scan is a scan task which is
assigned directly to one or more assets. This is meant to
be used as a one time scan for a handful of assets.
The creation of a scan is performed within the Assets view. There is a
button for each asset to create a new scan and to show all past scans. You
can also assign a single scan to multiple assets. To do this, select your
assets and click the AddScan button in the top right corner.
Click on the "THOR" button in the Action column in the Asset Management view.
A group scan is a scan task which is assigned to one or
more asset condition. Those conditions can either be labels
or the ASGARD Search Query. This is meant to be used if you want to
scan a large group of assets with one scan configuration.
As with the single scans, various parameters can be set. Aside from the already
mentioned parameters, the following parameters can be set:
Parameter
Value
Description
Freely selectable name for the group scan.
Scan Target
Here you can define which assets will be assigned the group scan.
You can either use the Simple target option, which uses labels,
or you can use the Advanced target options, which makes use of
labels or the ASGARD Search Query. Leaving this option empty will scan all assets.
Limit
ASGARD will not send additional scans to the agents when the client
limit is reached. Therefore you need to set a limit higher than the
number of hosts you want to scan or enter 0 for no limit. If
you are using MASTER ASGARD, this limit is applied on each single selected ASGARD.
Rate
The number of scans per minute that are issued by ASGARD. This is
where the network load can be controlled. Additionally, it is recommended
to use this parameter in virtualized and oversubscribed environments in
order to limit the number of parallel scans on your endpoints.
Expires
After this time frame, no scan orders will be issued to the connected agents.
Scheduled Start
Select a date for a scheduled start of the scan.
After the group scan has been Saved or SavedandStarted, you will
automatically be forwarded to the list of grouped scans.
In addition, information can be found about the chosen scanner, the chosen parameters,
the start and completion times and the affected assets (defined by labels).
Additional columns can be added by clicking on "Column Visibility".
The Status field can have the following values:
Status
Value
Paused
The group scan has not yet started. Either click play or wait
for the scheduled start date (the job will start in a 5 minute window around the scheduled time).
Active
Scan is started, ASGARD will issue scans with the given parameters.
Inactive
No additional scan jobs are being issued. All single scans that are currently running will continue to do so.
Completed
The group scan is completed. No further scan jobs will be issued.
A group scan can be started by clicking on the "play" button in the
"Actions" column of a group scan. Subsequently, the scan will be listed as "Started".
Further information about a group scan can be observed from the detail
side bar of the group scan. Click the arrow in the left column of
the group scan you are interested in and the details section will appear
on the right side of the window.
Aside from information about the group scan in the "Details" tab, there
is a graph that shows the number of assets started and how many assets
have already completed the scan in the "Charts" tab. In the "Tasks"
tab you get information about the scanned assets.
The Scheduled Group Scan section shows all scans that are to run on a
frequent basis along with their periodicity. All group scans that have
been started through the scheduler will show up on top of the Group Scan
section the moment they are started. New scheduled tasks can be created
by clicking the AddScheduledGroupScan button.
To configure Syslog Forwarding of logs, you can set the --syslog flag
during scans. You have multiple options as to where you can send the logs.
The --syslog value is constructed of the following arguments. Please
keep in mind that the fields need to be in the correct order. Values are
separated with the colon sign :
Pos.
Field
Description
Possible Values
1
Server
The receiving server, %asgard-host% is the ASGARD which issued the Scan for the Agent
FQDN or IP of remote host
2
Port
optional - the listening port on the remote system, default is 514
The syslog listener on the Management Center
is running on port UDP/514.
Examples:
cribl.local:6514
172.16.20.10:514:SYSLOGKV:TCP
rsyslog-forwarder.dom.int:514:JSON:TCP
arcsight.dom.int:514:CEF:UDP
If you choose to use the --syslog flag, please make sure that the
necessary ports are allowed within your network/firewall. If you decide
to forward your logs via ASGARD to a SIEM, please have a look at
Rsyslog Forwarding.
Note
If Syslog Forwarding is selected for a new THOR Scan, the default
target will be set to %asgard-host%, which is your Management
Center. Syslog Forwarding is optional and you do not lose any
functionality if you are not using it (in most cases). If you
want to forward logs in real-time from your Management Center to
a SIEM (for example), you do however have to enable Syslog Forwarding.
Depending on your configuration it may take between 10 seconds and 10
minutes for the remote console to open. Please note that all actions
within the remote console are recorded and can be audited. All consoles
open with root or system privileges.
In order to replay a remote console session, navigate to ResponseControl,
expand the task that represents your session by clicking the arrow to the left
in the tasks row. Select the ConsoleLog tab and click the play button in
the bottom row.
ASGARD users can only see their own remote console session. Only users with
the ViewRemoteConsoleLog permission are able to replay all sessions from
all users.
Note
The permission ViewRemoteConsoleLog requires the ResponseControl
permission.
In addition to controlling THOR scans, the Management Center contains
extensive response functions. Through your Management Center, you can
start or stop processes, modify and delete files or registry entries,
quarantine endpoints, collect triage packages and execute literally
any command on connected systems. All with one click and executed on
one or multiple endpoints at once.
It is also possible to download specific suspicious files. You can transfer
a suspicious file to the ASGARD Management Center and further analyze
offline.
To execute a predefined response action one or more endpoints, navigate
to the Assets view and either click the "play" button in the Actions
Column, or selected multiple assets and press the "Add Task" button in
the top right corner. This will lead you to a dialogue where you can
select the desired action.
In this example, we collect the ASGARD Agent Logs.
ASGARD ships with pre-defined playbooks for the following tasks:
Collect ASGARD Agent Log
Create and Collect Aurora Agent Diagnostics Pack (Windows only)
Collect full triage pack (Windows only)
Isolate endpoint (Windows only)
Collect system memory
Collect file / directory
Collect directory
Collect Aurora diagnostics pack
Execute command and collect stdout and stderr
Warning
The collection of memory can set the systems under high load and
impacts the systems response times during the transmission of
collected files. Consider all settings carefully! Also be aware
that memory dumps may fail due to kernel incompatibilities or
conflicting security mechanisms. Memory dumps have been successfully
tested on all supported Windows operating systems with various patch
levels. The memory collection on Linux systems depends on kernel
settings and loaded modules, thus we cannot guarantee a successful
collection. Additionally, memory dumps require temporary free
disk space on the system drive and consume a significant amount
of disk space on ASGARD as well. The ASGARD agent checks if there
is enough memory on the system drive and adds a 50% safety buffer.
If there is not enough free disk space, the memory dump will fail.
This view should look already familiar, since it is similar to the
Group Scan view. You can select the targets by either specifying
one or more labels or by making use of the ASGARD Search Query.
You can do create the following type of Playbook Steps:
Run Command Line on Endsystem
Upload File to ASGARD Management Center
Download File from ASGARD Management Center
This allows you to download files from the Management Center
to your endpoint and vice versa. This way you can directly
collect evidence from your endpoints.
If you need custom files for your playbook (scripts, configurations, binaries, etc.)
you can do so by selecting UploadNewFile when setting the type to DownloadFilefromASGARDManagementCenter during the creation of the playbook step. Alternatively
you upload (and manage) new files at ResponseControl > PlaybookFiles.
You can have up to 16 steps in each playbook, which are executed sequentially.
If you execute a command the stdout and stderr can be reported back as
well if you wish to do so.
You can change the Proxy Settings on your Assets via the Response Control.
To do this, select the asset(s) and click AddTask in the top right corner.
Next, set the Module to Maintenance and the Maintenance Type to
Configuretheasset'sproxy. You can now set your proxy. Multiple proxies
can be set, though only one FQDN/IP-Address per field can be set.
Service Control is ASGARD's way of deploying real-time services on endpoints.
Currently there only exist the Aurora service. To use Aurora, the service
controller has to be installed on an asset.
To install the ASGARD Service Controller on an asset, you need to install the ASGARD Agent
first. If you already have installed the ASGARD Agent and accepted the asset in your Management
Center, you can use the "Install ASGARD Service Controller" playbook to deploy the service
controller on an asset. Optionally you can manually download and execute the asgard2-service-controller
installer from the ASGARD downloads page.
If an ASGARD update comes with a new service controller version, you need to update
the service controller on the already rolled-out assets. You can do this using an
"Update Agent" task. You can do that by either selecting one or multiple assets in the
Assets view, or by creating a (scheduled) Group Task.
Under ServiceControl > Aurora > AssetView(Deployed) the overview
of all assets with installed Aurora is shown. Clicking on the entry opens a
drop-down menu with details and additional information.
You can als see an overview of all assets without Aurora installed under
ServiceControl > Aurora > AssetView(NotDeployed) and install
Aurora using the DeployAurora button. Those are all the assets which
have the service controller installed, but the Aurora deployment was not done
yet.
To change the Aurora configuration of an asset, navigate to ServiceControl
> Aurora > AssetView(Deployed), select the asset's checkbox and choose
> ChangeAuroraConfiguration. Then choose the desired service configuration
> by clicking AssignandRestart.
If you want to enable or disable the Aurora service on an or more assets,
select them with the checkbox and use the Enable or Disable button.
Alternatively you can use the play or stop action icon on a single asset to
achieve the same.
Go to ServiceControl > Aurora > Configurations > AddConfiguration,
enter a name and add the rulesets that should apply for this service configuration.
No rulesets is a viable option, if you only want to use the non-sigma matching modules.
You don't need to edit any other option as sane defaults are given.
If Aurora uses too much CPU cycles, the most common reason is a heavy event
producer on the system (e.g. anti virus or communication software). In order
to analyze the issue and define process exclusions, go to ServiceControl >
Aurora > ProcessExclusions
An overview over the top event producing processes is given on the bottom
of the section. Another possibility is to download a
Aurora Diagnostics Pack
and look in the status.txt at the event statistics by process.
If needed, false positives can be globally defined on all Aurora agents
at ServiceControl > Aurora > FalsePositiveFilters. It is
recommended to filter false positives at ServiceControl > Sigma >
Rules and filter the false positives on a rule level using the "edit false
positive" action (funnel icon). For more details see
False Positive Tuning of Sigma Rules. If this is
not possible, because you need a quick fix and multiple rules are affected,
the global false positive filter can help.
If you want to enable the blocking capabilities of Aurora, we suggest
to enable our included responses:
See the overview at ServiceControl > Aurora > Configurations.
The EffectiveRulesandResponse row shows how many responses are active.
By default no responses are active. See How to activate Responses.
Do not directly activate the responses in production environments. Monitor
your environment for at least a month with simulated responses to verify
that no false positive matches occur.
In larger environments use different configurations and rulesets for different
environments. As an example you can test changes to the configuration in a
test environment, before adapting the changes for the production environment.
You can test the response functionality by entering the command
More tests are available from the
Function Tests section of the Aurora manual.
Those tests only generate detection events but no responses. If your ASGARD Management
Center is connected to an Analysis Cockpit, you can see the detection events at Events >
AuroraEvents or in the Windows EventLog of the asset.
Sigma is a generic and open signature format that allows you to
describe relevant log events in a straightforward manner. The rule
format is very flexible, easy to write and applicable to any type
of log file. The main purpose of this project is to provide a
structured form in which researchers or analysts can describe their
once developed detection methods and make them shareable with others.
Sigma is for log files what Snort is for network traffic and
YARA is for files.
Rulesets are used to group rules to manageable units. As an asset
can only have one service configuration, rulesets are used to determine
which rules are used in which service configuration. There exist default
rulesets for high and critical Sigma rules. If you want to create a
custom ruleset go to ServiceControl > Sigma > Rulesets > CreateRuleset.
If you have chosen that new Sigma rules should be added automatically
to the new ruleset, they will be added now. If you didn't set any Sigma
levels to automatically add to this rule, you now need to add the desired
rules manually by going to ServiceControl > Sigma > Rules.
Choose the rules that should be added to this ruleset by selecting the
checkboxes and then AddtoRuleset. A rule can be assigned to multiple
rulesets.
You need to commit and push your changes after editing a ruleset.
ASGARD has to restart the service controller to read new configurations.
In order to prevent multiple restarts in the case of an admin performing
several configuration changes in succession, the admin has to initiate
the reloading of the new configuration by going to ServiceControl >
Sigma > Rulesets and performing the Compile ruleset action
(gear wheels). The need for compiling is indicated in the Uncompiled Changes
column.
It is not advised to enable all available rules on an asset. We suggest
to start with all "critical" and then advance to all "high" rules. We
already provide a default ruleset for those two levels for you to use.
"Medium" rules should not be enabled in bulk, and "low"/"informational"
at all . Single medium rules, which increase an organization's detection
coverage and do not trigger a bigger number of false positives, can be added
to the active configuration, but should be tested rule by rule.
In order to easily add rules to a ruleset you can use the column filters
to select the desired rules and add the bulk to a ruleset. As an example
you can add all rules of level "critical" to a ruleset:
Or you can just search the title or description field of the rules. You can also search
the rule itself using the "Rule" column. (the "Rule" column is not shown by default and
has to be added using the gear wheel button).
Not every environment is the same. It is expected that some rules will trigger false
positive matches in your environment. You have
multiple options to tackle that issue.
If it is a general false positive, probably not only occurring in your environment,
consider reporting it at as a Github issue
or e-mail to us at rules@nextron-systems.com. We
will take care of the tuning for you and your peers.
If the false positive is specific to your environment, you can tune single Sigma rules
at ServiceControl > Sigma > Rules, filter for the rule in question and
choose the "Edit false positive filters of this rule" action. Here you can do simple
rule tunings on your own. By clicking the AddFalsePositiveFilter button you can
add single lines that filter the event for false positives (i.e. they are OR-connected
meaning: "Do not match the event if any of those lines matches). They are applied on top
of the rule logic and persist automatic rule updates.
Example of the false positive tuning of a Sigma rule
To see the resulting rule you can click the "Show Preview" button or look at the
"Compiled Rule" row in the rule's drop down menu.
If you want to review the tuned rules: To filter for all rules containing a custom
false positive tuning, you have to add the "Filters" column to your view (gear wheels
icon) and show all non-empty rows by using the NOT- column filter.
If the rule is adding too much noise and tuning is not sensible, you can remove the
rule from the ruleset for a subset of your machines (maybe you need to define and use
a separate ruleset for that use-case) or you can disable the rule altogether. This
is done using the Disablethisrule action of the rule. Disabling the rule affects the rule in all rulesets.
After tuning a rule, the rulesets using that rule have to be re-compiled at ServiceControl > Sigma > Rulesets.
Custom rules can be added using the sigma format complying with the
specification. You can
upload single files or a ZIP compressed archive. This can be done at
ServiceControl > Sigma > Rules > UploadRules.
If new rules or rule updates are provides by the Aurora signatures, the updates
have to be applied by the user manually in order to be affecting Aurora agents
managed by ASGARD. An indicator is shown in the WebUI and the rules changes can
be reviewed and applied at ServiceControl > Sigma > RuleUpdates.
Clicking on the Update button in the "Update Available" column opens a diff
view in which the changes are shown and where the user can apply or discard the
changes. If you do not need to review each single change, you can apply all
changes using the UpdateAllRules button.
Analogous the updates of response actions can be viewed and applied at
ServiceControl > Sigma > ResponseUpdates.
As a fail safe and for administration purposes, responses are generally
only simulated if not explicitly set to active.
This has to be done on different levels:
Service configuration level
Ruleset configuration level (on updates)
Ruleset rule level
If on one level a rule is simulated, it will not execute the response
actions but only generate a log line that describes the action that
would have been performed. You can see an overview of the state of all
responses in the ServiceControl > Aurora > Configurations menu.
indicates whether responses are activated on configuration level. Edit the configuration to change it.
indicates how many rules are only simulated in that ruleset (or in sum).
indicates how many rules have active responses in that ruleset (or in sum)
To change the status of a response in the ruleset click the ruleset link.
You can view all simulated or all active responses. Use the checkbox and
the button in the upper right to switch the response status of the rules
between active and simulated.
The default response mode of a ruleset is important for the
behavior of response updates. It can be seen at ServiceControl >
Sigma > Rulesets in the DefaultResponseMode column.
If "Simulation" is selected, response actions of new and updated rules
will be put in simulation mode. If "Active" is selected, new rules will
automatically be put in active mode and updated rules will not change
their current response mode. We advise to leave the default response
mode in "Simulation" mode.
The menu IOCManagement gives you the opportunity to easily integrate custom signatures into your scans.
In order to create your own custom IOC Group, navigate to IOCManagement > IOCs
and click AddIOCGroup in the upper right corner. Select a name and optionally a description for your IOC Group.
To add IOCs to this group, use the ShowandeditIOCsinthisIOCgroup
action. A side pane opens where you can click the ImportIOCs button
to import your own signatures in any of THOR's IOC formats as files (e.g.
files for keyword IOCs, YARA files and SIGMA files). Refer to the
THOR manual (custom signatures)
for a complete list and file formats. Browse to the file you want
to add and click upload. This adds your IOC file to the default ruleset.
However, you can also click the AddIOC(s) button to add some IOCs
interactively. Select the type, score and description, enter some values
and click the AddIOC button.
You can add those IOC Groups to IOC Rulesets which can be created in
the IOCManagement > IOCRulesets tab by clicking the AddRuleset
button in the upper right corner. Select name and description and click the
AddRuleset button.
After that, click on an entry in the table to expand it. There you
get information about all IOC Groups which have been added to this
ruleset. Additionally you can add or remove selected IOC Groups in
IOCManagement:IOCs by clicking one of the three buttons shown below.
Anytime you add, remove or change IOCs within one of your IOC Groups,
you have to recompile the IOC Ruleset. To do this, navigate to the
IOCRulesets page and click the "geard" icon in the Ruleset's row
Those rulesets can be selected in the "IOC Rulesets" field while
creating a new scan job. If a ruleset is selected, the scan will
include all custom IOCs included in IOC Groups which have been
added to this ruleset. You can also select more than one ruleset.
The THOR scan would be performed with the default settings and the
custom ruleset, the default signatures would not be applied.
In order to use MISP events and their IOCs for scanning, you
need to link your ASGARD with a MISP first. Please see
Link MISP for reference.
ASGARD provides an easy to use interface for integrating IOCs from
a connected MISP into THOR scans. In order to add rules from a MISP,
navigate to IOCManagement > MISP > MISPEvents, select
the IOCs and add them to the desired ruleset by using the button in
the upper right corner.
There is no default ruleset for MISP. You must create at least one
ruleset (see tab "MISP Rulesets") before you can add MISP rules.
To create a new ruleset, click AddMISPRuleset in the
IOCManagement > MISP > MISPRulesets tab. Select a name
and the type of IOCs you want to use in this ruleset. By default, all
types are selected, but there may be reasons for deselecting certain
categories. For example, filename IOCs tend to cause false positives
and may be deselected for that reason. The picture below shows the
dialogue for adding a MISP ruleset. Enable AutoCompile in order
to automatically compile new MISP events into the ruleset, when they arrive.
Since not all the information and attributes in a MISP event are
relevant to ASGARD and the THOR scanner, we provide a list of
attributes which will be used by ASGARD:
hostname
ip-dst
domain
domain-ip>hostname
domain-ip>ip-dst
domain-ip>domain
filename
filepath
file>filename
file>filepath
file>md5
file>sha1
file>sha256
md5
sha1
sha256
yara
yara>yara
sigma
Warning
Only attributes with the flag IDS set to true will be used
by ASGARD. Please make sure that the flag is set if you are
intending to use certain events/attributes.
If Bifrost is used with your THOR scans, all collected samples show up here.
You will need the "ResponseControl" permission in order to view or download
the samples. See section Roles and
Rights for details.
The Downloads section lets you create and download a full
THOR package including scanner, custom IOCs and MISP rulesets
along with a valid license for a specific host. This package can
then be used for systems that cannot be equipped with an ASGARD
agent for some reason. For example, this can be used on air gapped
networks. Copy the package to a flash drive or CD ROM and use it
where needed.
You can choose to disable the download token altogether using
DisableDownloadToken. If disabled, anyone with network
access can download and issue licenses, which may lead to
unwanted exhaustion of the ASGARD license pool. You can reset
the download token by disabling and then re-enabling it using NewDownloadToken.
Download THOR package and license workstation named 'WIN-CLI-DE-1234'
While selecting different options in the form, the download link changes.
After you have generated a download token and have selected the
correct scanner, operating system and target hostname (not FQDN),
you can copy the download link and use it to retrieve a full
scanner package including a license file for that host. These download
links can be sent to administrators or team members that don't have
access to ASGARD management center. Remember that the recipients of
that link still need to be able to reach ASGARD's web server port
(443/tcp). The token can be used to download THOR or a THOR license
without an ASGARD account. Attention: If you disable the token,
anybody can download THOR from this ASGARD or can generate licenses.
Note
The scanner package will not contain a license file if you don't
set a hostname in the TargetHostname field. If you have an
Incident Response license, you must provide it separately.
You can generate download links without an included license by
leaving the hostname field empty. A valid license (e.g. "Incident Response")
must be placed in the program folder after the download and extraction.
By including the hostname in the form, a license will be generated
and included in the download package You can copy the final download
link and send it to anyone, who can use this link to download a
package and run scans on a host with that name.
You or the recipient can change the name in that URL to make it
usable on other systems.
Note that you may have to adjust the type field to get the correct
license type (client for workstations, server for servers) and
the THOR version (win, linux, osx) to generate a correct URL.
By default, the generated download link is protected with a
token that makes it impossible to download a package or
generate a license without knowing that token. This token
is specific to every ASGARD instance.
You can use that URL in Bash or PowerShell scripts to automate
scans on systems without an installed ASGARD agent.
ASGARD requires an Issuer-License in order to scan systems.
The Issuer-License contains the number of asset-, server- and
workstation systems that can be scanned with ASGARD Management
Center as well as the Aurora service licenses.
ASGARD will automatically issue a valid single-license for a
particular system during its initial THOR scan.
The screenshot below shows the licensing section of an ASGARD.
In addition, ASGARD can create single-licenses that can be used
for agent-less scanning. In this case the license is generated
and downloaded through the Web frontend.
The following systems require a workstation license in order to be scanned:
Windows 7 / 8 / 10 / 11
Mac OS
The following systems require a server license in order to be scanned:
All Microsoft Windows server systems
All Linux systems
The licenses are hostname based except for asset licenses. Asset
licenses are issued for each accepted asset as soon as a response
action is performed (playbook or remote console access).
ASGARD will search for ASGARD updates on a daily basis. Available
updates will automatically be shown in the section Updates.
As soon as an ASGARD update is available, a button Upgradefrom...to...
appears. Clicking this button will start the update process. The
ASGARD service will be restarted and the user will be forced to
re-login. Generally update MASTER ASGARD before the connected ASGARDs.
By default, ASGARD will search for signature updates and THOR
updates on an hourly basis. These updates will be set to active
automatically. Therefore, a triggered scan will always employ the
current THOR version and current signature version. You may disable
or modify the automatic THOR and Signature updates by deleting or
modifying the entries in this section.
It is possible to intentionally scan with an old scanner version by
clicking on the pencil icon and selecting the respective version
from the drop-down menu.
Please be aware, that this is a global setting and will affect all scans!
You can trigger a Manual Check and download new THOR packages by clicking
ManuallyCheckforUpdates. This can also be used in new ASGARD
installations, as sometimes it takes a while until ASGARD does this automatically.
Editing a user account does not require a password although
the fields are shown in the dialogue. An initial password
has to be provided for user creation, though.
Access the user roles in Settings > Roles.
You can download a list of all users in CSV format.
By default, ASGARD ships with the following pre-configured
user roles. The pre-configured roles can be modified or
deleted. The ASGARD role model is fully configurable.
In order to configure LDAP, navigate to Settings > LDAP.
In the left column you can test and configure the LDAP connection itself.
In the right column, the mapping of LDAP groups to ASGARD groups
(and its associated permissions) is defined.
First check if your LDAP server is reachable by ASGARD by clicking "Test Connection".
Then check the bind user you want to use for ASGARD. Read
permissions on the bind user are sufficient. To find out
the distinguished name you can use an LDAP browser or query
using the PowerShell AD module command Get-ADUser<username>.
Next configure the LDAP filters used to identify the groups and
users and their preferred attributes in your LDAP structure.
A default for LDAP and AD in a flat structure is given in the
"Use recommended filters" drop-down menu, but you can
adapt it to your liking. The test button shows you if a login
with that user would be successful and which groups ASGARD identified
and could be used for a mapping to ASGARD groups.
If you need to adapt the recommended configuration or want to customize it,
we recommend an LDAP browser such as ADExplorer
from Sysinternals to browse your LDAP structure. As an example you could
use your organization's e-mail address as a user login name if you change the "User Filter"
to (&(objectClass=user)(objectCategory=user)(userPrincipalName=%s))
Note
You need to save the configuration by clicking UpdateLDAPConfig.
Using the test buttons only uses the data in the forms, but does not
save it, so that you can use it for testing purposes anytime,
without changing your working configuration.
After the LDAP configuration is set up, you need to provide role mapping from LDAP groups to ASGARD groups.
This is done in the right column by using the AddLDAPRole feature.
Rsyslog forwarding can be configured in Settings > System >
Rsyslog. To add a forwarding configuration for local log
sources, click AddRsyslogForwarding.
The following log sources can be forwarded individually:
Everything related to the ASGARD service, processes, task and scan jobs
ASGARD Audit Log
Detailed audit log of all user activity within the system
Agent Log
All ASGARD agent activities
THOR Log
THOR scan results
Thor Log (Realtime)
The THOR (Realtime) logs are the same logs as THOR logs,
except that they are collected via udp syslog instead of
https. To forward THOR logs in realtime, you have to
configure your scans to forward syslog to ASGARD, see
Syslog Forwarding). Make
sure the necessary firewall rules are in place to allow
the asset to communicate with the ASGARD.
In order to achieve the best possible compatibility with the
most common browsers, we recommend using the system's FQDN
in both fields CommonName AND Hostnames.
Please note that generating a CSR on the command line is not supported.
The generated CSR can be used to generate a TLS Certificate.
Subsequently, this TLS Certificate can be uploaded in the Settings > TLS section.
The individual ASGARD services can be managed in Settings >
System > Services. The services can be stopped or restarted
with the respective buttons in the Actions column.
You can add or delete NTP servers by adding/changing the values
in the text fields. After you are done with your changes, click
SaveandRestartNTP to save your changes.
Bifrost allows you to automatically upload suspicious files to your
ASGARD during a THOR scan. If an Analysis Cockpit is connected,
these files get automatically forwarded to the Analysis Cockpit
in order to drop them into a connected Sandbox system. However,
the collected files will stay on ASGARD for the amount of time
specified in Retentiontime (0 days represent an indefinite amount of time).
The collected files can be downloaded in the EvidenceCollection
section. All files are zip archived and password protected with the password infected.
In order to automatically collect suspicious files, you have to
create a scan with Bifrost enabled. Check the SendSuspiciousFilestoASGARD
option to send samples to the system set as bifrost2Server. Use the placeholder
%asgard-host% to use the hostname of you ASGARD instance as the Bifrost server.
In order to connect to an Analysis Cockpit, enter the
respective hostname of the Analysis Cockpit (use the same
FQDN used during installation of the Analysis Cockpit) in
the field FQDN, enter the one-time code, choose the
type and click UpdateAnalysisCockpit.
ASGARD must be able to connect to the Analysis Cockpit
on port 443/TCP for a successful integration. Once connected,
the Cockpit will show up in ASGARDs SystemStatus > Overview
section together with the other connectivity tests.
Please wait up to five minutes for the status to
change on ASGARD's system status page. It will change from Notlinked to Online.
In order to control your ASGARD with a MASTER ASGARD,
you must generate a One-Time Code and use it in the "Add ASGARD"
dialogue within the MASTER ASGARD frontend.
In order to connect to a MISP with your ASGARD Management Center,
navigate to Settings > MISP. Insert the MISP's address,
along with the API Key and click TestandLinkMISP.
The MISP connectivity status is shown in the Overview section.
Please allow five minutes for the connection status to indicate the
correct status, and also MISP rules to be downloaded and shown in
IOCManagement > MISP > MISPEvents.
The Advanced tab lets you specify additional global settings.
The session timeout for web-based UI can be configured. Default
is one hour. If ShowAdvancedTasks is set, ASGARD will
show system maintenance jobs (e.g. update ASGARD Agent on endpoints)
within the response control section.
Inactive assets can be hidden in the Asset Management Section
by setting a suitable threshold for HideinactiveAssets.
We are currently using the Time-basedOne-timePassword(TOTP)
algorithm for two factor authentication. We recommend
one of the following mobile apps for 2FA:
To enable Two Factor Authentication, click UseTwoFactorAuthentication
in your User Settings and follow the instructions on the screen.
After clicking the button, you will be presented with a QR
code for your authenticator app of your choice.
Alternatively, you can use the secret key. You will need
to verify the 6-digit token and click ValidateTwoFactorAuthentication
to enable 2FA.
Note
You will be logged out of your current session if the validation was successful.
To generate an API Key, navigate to UserSettings > APIKey.
This page allows you to set an API key. If an API key was previously set,
a new key will be generated. You will only be able to see your new API key
once after it has been generated.
Note
Currently an API key always has the access rights of the
user context in which it has been generated. If you want to create a
restricted API key, add a new restricted user and generate an API key
in the new user's context.
Warning
The API key has the same rights as your user. Do not use your
API key as token for license generation and license / THOR download.
Instead, use the download token from the Downloads menu
(Download Links).
The Master ASGARD is a single central management console that can control
all of your ASGARD systems. It is meant to centrally manage controlled
scans on all your ASGARD systems. MASTER ASGARD also provides one central
point of management for your Response Playbooks, Evidence Collection
and IOC Management. A special license for this is needed.
Note
Please note that the Master ASGARD is a completely separate system from
your existing Management Center. This means a new server/vm and a special
license are required.
Master ASGARD is a single central management console that can control
all of your ASGARD systems. It is meant to centrally manage controlled
scans on all your ASGARD systems. Master ASGARD also provides one central
point of management for your Response Playbooks, Evidence Collection
and IOC Management. A special license for this is needed.
Once you connect your ASGARD Management Centers to your Master ASGARD,
the licensing sections on connected ASGARD Management Centers become inactive.
The local ASGARD license will be replaced with the Master ASGARD license.
Every ASGARD can issue scanning licenses to assets as long as the
total number of scanned servers and workstations does not exceed the
number of systems in the Master license.
The setup procedure for Master ASGARD is identical to the setup procedure for
ASGARD Management Center, see Setup Guide. The only
difference is that you need to provide a Master ASGARD license file.
In Master ASGARD go to ConnectedASGARDs, click the AddASGARD
button in the upper right corner, and use the hostname and one-time token to
connect that ASGARD system. You can use a description to provide more
information on that ASGARD server, e.g. DMZ1 or RegionEMEA-HQ1.
You don't have to provide a port in the hostname field. Don't use a
URL like https://, just the FQDN. Remember that Master ASGARD
must be able to reach ASGARD v2 systems on port 5443/tcp and ASGARD
v1 systems on port 9443/tcp. Also make sure that the Master ASGARD
system is able to resolve the FQDN of the ASGARD system.
Scan Control in Master ASGARD looks the same as in an ASGARD server.
The only difference is that you can select an ASGARD Server or "All ASGARDs" to run the scans on.
On Master ASGARD you can manage IOCs exactly like on ASGARD. The only
limitation is that IOCs in Master ASGARD and ASGARD are isolated. That
means if you want to use the IOCs from Master ASGARD, you need to initiate
the scan from Master ASGARD and if you want to use the IOCs from ASGARD,
you need to initiate the scan from ASGARD. In general we suggest to
manage IOCs in Master ASGARD for maximum flexibility.
Service Control lists the asset with an installed service controller.
An asset is either managed by Master ASGARD or its connected ASGARD, not
by both. If an asset is managed by Master ASGARD it can still be viewed
by the connected ASGARD (and vice versa). If Master ASGARD or ASGARD
edits a configuration of an asset it will take over the "leadership"
over this asset, no matter by which it was managed beforehand.
The Downloads section of Master ASGARD allows to generate and
download Agent Installers on all your connected ASGARDs. This
allows for a central management of the Installers.
Example: Download Section in ASGARD but managed by Master ASGARD
The view in your connected ASGARD Management Centers however
will be different:
ASGARD THOR and Signatures Update view when connected to a Master ASGARD
It is possible to set a certain THOR and Signatures version for each
connected ASGARD. However, if automatic updates are configured, this
setting has only effect until a new version gets downloaded.
Customers use this feature in cases where they want to test a certain
THOR version before using it in production. In this use case the ASGARD
system that runs the test scans is set to automatic updates, while the
ASGARD systems in production use versions that administrators set manually
after successful test runs.
Master ASGARD offers no central user and role management for all connected
ASGARD servers. Since Master ASGARD and ASGARD allow to use LDAP for
authentication, we believe that complex and centralized user management
should be based on LDAP.
It is not possible to link a Master ASGARD with an Analysis Cockpit and
transmit all scan logs via Master ASGARD to a single Analysis Cockpit
instance. Each ASGARD has to deliver its logs separately to a connected
Analysis Cockpit.
ASGARD is rotating logs automatically at a set time interval. It is
important to keep in mind how long logs will be stored on the system
before they get purged. All logs will be rotated and zipped into one
file monthly, for up to 14 months.
To get a better understanding of how the log rotation is handled,
you can inspect /etc/logrotate.d/asgard-management-center.
ASGARD will store all logs under /var/lib/asgard-management-center/log.
This does not include the Scan Logs, as those are handled separately.
If you require a longer retention period, please copy the oldest log
packages to another directory or to a dedicated log server. Do not
modify the built-in rotation settings as this might interfere with ASGARD updates!
Log
Name
Audit
asgard-audit.log
ASGARD Management Center
asgard.log
ASGARD Agent and Service Controller
agent.log
ASGARD Agent Access
agent-access.log
THOR via Syslog
scan.log
THOR via Syslog (Scan Start, Licensing, Completion only)
subscan.log
Aurora
aurora-service.log
If you want to forward those logs automatically to a dedicated server,
you can set up Rsyslog Forwarding. Forwarded
logs will still reside on ASGARD.
The following files are safe to delete. They are not needed for ASGARD to operate.
/var/lib/asgard-management-center/log/*.gz
They are only kept on the system if needed for further processing.
E.g. saving/sending the log files to another system. If you do not
need or plan to use those, they can be deleted. If you are unsure
make a copy to another system before deleting them.
/var/lib/asgard-management-center/downloads/* (except current day)
The files in this folder are only generated for temporary downloading
files from the UI and are not needed after the download has finished.
The directory has a sub structure of year/month/day. It is save to
delete any files older than the current day.
If you use Bifrost, the collected files are not deleted by default.
If dated files are no longer needed, you can define a retention
period at Settings > Bifrost.
The listed files are the results of THOR scans (scan-results), Tasks
except Scans (generic-results) and the sessions of remote consoles (remote-console).
They are not needed for ASGARD to function, but the data is viewed and
available for download in ASGARD. This means deleting these files will
not break ASGARD, but you lose the information provided by the files.
If you need the disk space and cannot increase the disk, we suggest to
delete these files older than a given date, that you no longer need.
This can be done with a find-remove combination using the command line:
Where <directory> is one of scan-results/*.gz, generic-results/* or remote-console/protocol/*
and <days> the number of days you want to keep. Files and folders older than <days> days will be deleted.
This chapter contains advanced configuiration options, which
can be helpful in different scenarios. Please have a look if
some options could be helpful for your environment.
The ASGARD agents poll the Management Server server frequently for new tasks to execute.
The default polling interval depends on the number of connected endpoints. In
larger environments the polling interval increases dynamically up to 10 minutes
for a configuration with 25.000 endpoints connected to a single ASGARD.
Additionally, ASGARD is configured to serve a maximum of 100 concurrent asset
connections and 25 concurrent asset streams. Asset connections are short polls
from the agent such as answering the question "do you have a new task for me?".
Asset streams are intense polls such as downloading THOR to the agent or
uploading scan results back to ASGARD.
Requests that exceed the limits will receive an answer from ASGARD to repeat the
request after N seconds, where N is calculated based on the current load.
This factory preset behavior insures your ASGARD stays stable and responsive even if your
ASGARD's system resources are limited. Furthermore, you most likely can't overload your
network or firewalls with high numbers of requests or downloads.
In order to modify ASGARDs performance settings edit /etc/asgard-management-center/asgard.conf
and restart the ASGARD service.
The default values are:
Value
Description
LoadConnMax=100
Max. concurrent „Busy Connections"
LoadStreamMax=25
Max. concurrent „Busy Streams"
PingRateMin=10
Polling Rate with 0 connected Assets (seconds)
PingRateMax=600
Polling Rate with 25000 connected Assets (seconds)
PingRateFast=5
Polling Rate for Assets in Fast Ping Mode (seconds)
These values should work fine in most scenarios – regardless of the size
of the installation. However, you may want to decrease PingRateMax
in order to achieve a better responsiveness of your ASGARD infrastructure.
While temporary stream overloads are quite normal, connection overloads
should not happen. If they do, either adjust your PingRateMax, your LoadConnMax or both.
ASGARD will indicate an overload with the "Connection Overload line"
and the "Stream Overload line" within the graphs in the overview
section (see picture below). If an ASGARD is in an overload situation
it will postpone connections and streams but will not lose or drop
tasks or be harmed in any way. ASGARD will recover to normal load automatically.
Stream overloads can happen temporarily (e.g. if you schedule a grouped
scan or grouped task with an unlimited rate). The picture below
shows such a normal overload situation that was caused by starting
a grouped scan with an unlimited rate. This is the expected behavior.
ASGARD will manage the load automatically and postpone streams until
the load has returned to normal.
The "Busy Streams" line indicates the number of streams currently active.
s you might have guessed, the picture above was taken on an ASGARD in
default configuration where the number of concurrent streams is set
to the default value of 25.
ASGARD will store all logs under /var/lib/asgard-management-center/log
All logs in this directory will be rotated and automatically cleared
after 14 months, please see Log Rotation and Retention for more information.
Please copy the oldest log packages to another directory or to a dedicated
log server in case you require longer retention periods.
Do not modify the built-in rotation settings as this might
interfere with ASGARD updates!
ASGARD will store all scan logs under /var/lib/asgard-management-center/scan-results
All Scans will generate two files, thor-<ID>.txt.gz and thor-report-<ID>.html.gz.
The first file will be the raw THOR Scan Log(s) and the second file will be
the HTML Report(s). The numeric value in the file name is the Scan-ID, which
can be found in the the Scan Control view. Please make sure to enable the ID
column, since it is not enabled in the default view.
For Scans which were started with the --json flag, log files are
additionally placed in the scan-results directory and are named thor-<ID>.json.gz.
Please keep in mind, those JSON log files are not being transferred to
any connected Analysis Cockpit.
When ASGARD has a new agent version available you can see an indicator
on the Update menu item as well as on the sub menu Update > Agents.
There are two tasks to perform, updating the agents on your assets and
updating the agent installer for all future asset deployments.
If this is the first agent update performed on this ASGARD you might need
to enable the UpdateAgent module under Settings > Advanced > ShowAdvancedTasks.
Then you need to run the UpdateAgent module. You can do this on a per
asset basis by running a playbook from AssetManagement or create a
NewGroupTask from ResponseControl, which is the preferred way.
You can roll-out the update in batches by providing labels for each stage
or not select any label to perform the update on all assets.
The UpdateAgent module is not shown by default under (Group)
Tasks. To show the group task or single tasks (also inside the group task)
you need to select the UpdateAgent module from the Module
column. You may need to select the Module column from Columnvisibility
first, if not shown.
You need to update the agent installer as well, so that newly added
assets will directly use the current agent version. This is a manual
task you have to perform once a new version is available. Navigate
to Downloads > AgentInstallers and click RepackOutdatedAgentInstallers. Please note that this process might take a while
to finish.
ASGARD supports creation of custom installers. Custom installers can be
configured in a way so that agents show up with a preset label or with a
preset proxy configuration.
Go to Downloads > AgentInstallers > AddAgentInstaller.
Edit the properties of the desired installer and generate the installer
by clicking AddAgentInstallers. The installers are available at the
downloads page besides the default installers, so best use an affix as distinction.
If a new version of the agent installer is available, you will see a notice
that agent installers need repacking. You can press the RepackOutdatedAgentInstallers button and wait for the process to finish. This guarantees
that newly downloaded installers use the newest version.
All of our ASGARD servers come with predefined backup and restore scripts.
You can use them to keep a backup available in case something stops working.
Warning
If you are using a Management Center and Analysis Cockpit together, it
is advised to create the backups at the same time. This avoids
potential data inconsistencies across the two platforms. You can
do this via a cronjob on both systems or with an automation tool like
Ansible, Terraform, etc.
The same should be kept in mind when restoring your backups. You should
always restore the backups on all servers, to avoid getting problems
in the future.
We create a script which can be used to generate a backup of
all configurations, assets, tags, user accounts, tasks etc., except:
Log files (ASGARD, THOR)
Playbook results (collected evidence)
Quarantined samples (Bifrost)
nextron@asgard:~$ sudo/usr/share/asgard-management-center/scripts/backup.sh
Writing backup to '/var/lib/asgard-management-center/backups/20240209-1110.tar'tar: Removing leading `/' from member namestar: Removing leading `/' from hard link targetsRemoving old backups (keeping the 5 most recent files)...done.
If you want to transfer the backup to a different system, make sure to copy the
.tar file to the home directory of the nextron user and change the permissions:
nextron@asgard:~$ sudocp/var/lib/asgard-management-center/backups/20240209-1110.tar/home/nextron
nextron@asgard:~$ sudochownnextron:nextron/home/nextron/20240209-1110.tar
nextron@asgard:~$ ls-l
total 205560-rw-r--r-- 1 nextron nextron 210493440 Feb 9 11:17 20240209-1110.tar
After this is done, you can use scp or any other available tool to
transfer the backup file to a different system.
Hint
Our recommendation is to run the backup as a cronjob during a time, when
no tasks are running or are scheduled to run. The reason for this is that
our sample script will stop the ASGARD service before the backup to avoid any
inconsistency with the data.
Here is an example script and cronjob entry to create backups on a schedule:
1#!/bin/bash 2BACKUPDIR="/var/lib/asgard-management-center/backups" 3NEWDIR="/home/nextron/backups" 4date
5 6echo"checking for destination folder" 7if![-d"$NEWDIR"];then 8mkdir$NEWDIR 9chown-Rnextron:$NEWDIR10fi1112echo"stopping asgard-management-center.service"13if!systemctlstopasgard-management-center.service;then14echo"could not stop asgard-management-center.service, exiting script"15exit116fi1718sleep319echo"running backup script"20/usr/share/asgard-management-center/scripts/backup.sh
2122sleep323echo"starting asgard-management-center.service"24if!systemctlstartasgard-management-center.service;then25echo"could not start asgard-management-center.service, needs manual debugging"26exit127fi2829echo"moving backup files to destination"30mv$BACKUPDIR/*.tar$NEWDIR31chown-Rnextron:$NEWDIR3233echo"backup created successfully"34echo""35echo""36exit0
The following crontab entry could be created to run the script every day at 2am.
You can edit the crontab of the root user with the following commands:
nextron@asgard:~$ sudosu
[sudo] password for nextron:root@asgard:~# crontab-e
Please keep in mind that the backup.sh script is only keeping 5
backups in place. If you want to change this, you have to change the value
GENERATIONS in the file /usr/share/asgard-management-center/scripts/backup.sh
to a different value.
You can use the restore.sh script to restore a backup.
nextron@asgard:~$ sudo/usr/share/asgard-management-center/scripts/restore.sh
Usage: /usr/share/asgard-management-center/scripts/restore.sh <BACKUPFILE>nextron@asgard:~$ sudo/usr/share/asgard-management-center/scripts/restore.sh/var/lib/asgard-management-center/backups/20240209-1110.tar
Stopping services... Removed "/etc/systemd/system/multi-user.target.wants/asgard-management-center.service".done.etc/asgard-management-center/etc/asgard-management-center/broker.confetc/asgard-management-center/server_cert_ext.cnf.inetc/asgard-management-center/rsyslog-thor.conf.20240208142245.bak...1+0 records in1+0 records out24 bytes copied, 0.000126177 s, 190 kB/sStarting services... Created symlink /etc/systemd/system/multi-user.target.wants/asgard-management-center.service → /lib/systemd/system/asgard-management-center.service.done.
Note
The version of the ASGARD were the backup will be restored should
be the same as the version which was present while the backup was
created. If you need an older version of ASGARD, please contact our
support team.
The diagnostic package is an archive generated on ASGARD server to help
Nextron support engineers with the debugging of your problem. It contains
the system configuration and log data of an ASGARD instance.
You can generate a Diagnostic Package in SystemsStatus > Logs >
DiagnosticsPackage.
The package can have a size that cannot be shared via Email. In this case you can either
ask us for an upload link (secure file sharing) or
remove big log files from the package (e.g. the file /var/lib/asgard-management-center/log/agent-access.log
is often responsible for 97% of the package size)
Edit the file asgard2-agent.yaml and set the value of write_log
to true. The file can be found in C:\Windows\System32\asgard2-agent\
or /var/lib/asgard2-agent/ for Windows and Linux/macOS, respectively.
write_log: true
After making these changes, restart the ASGARD service. You can then
find log entries and possible error messages in the file asgard2-agent.log
in the same directory as the configuration file.
Note: The value is set to false by default, because the agent
doesn't rotate or compress these logs. Leaving that value on true
could cause that file to grow very big and use a significant amount
of disk space. We recommend resetting it after the debugging session.
If Aurora does not behave like it should, e.g. using more resources
than you expected, you can create a diagnostics pack for our support
to help in troubleshooting the issue. This can be conveniently done
using the playbook [Default]CreateandCollectAuroraAgentDiagnosticsPack(Windows).
It can be run from AssetManagement > ResponseAction (Play button)
or from ResponseControl > Tasks > AddTask or if needed
as a group task. The resulting diagnostics.zip can be downloaded
from the third step in the PlaybookResult tab of the expanded task.
If you are seeing the DuplicateAssets view in your AssetManagement,
you need to fix the issue to avoid unwanted behavior of this asset. To
fix the issue, you need to uninstall the current ASGARD agent, delete the
configuration files, and redeploy a fresh copy.
To install the ASGARD Service Controller, please follow the
instructions in Service Controller Installation.
You need to wait a few minutes until the asset is connected to your ASGARD
before you continue with this step. Please note that you might need to accept the AssetRequest.
Using a web proxy with TLS/SSL interception will break the installation routine and shows this error:
Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification.
Solution: Disable TLS/SSL interception for our update servers.
update-301.nextron-systems.com
Used for THOR updates:
update1.nextron-systems.com
update2.nextron-systems.com
We do not support setups in which the CA of the intercepting proxy
is used on our ASGARD appliances.
The most common error is to define a simple hostname instead of a valid
FQDN during installation. This happens if no domain name
has been set during the setup step Network Configuration
(Domainname).
This leads to a variety of different problems.
The most important problem is that ASGARD Agents that install on endpoints
will never be able to resolve and connect to the ASGARD server.
The FQDN is set at installation time and is composed by the hostname
and the domain name. The ASGARD Agents require a resolvable FQDN to
correctly operate and connect to the ASGARD Server.
One of the processes which are executed at installation time include
the integration of the FQDN - which should be set during installation - into
the ASGARD agents. If we incorrectly set the FQDN or leave any of those
values empty, the agents will fail to connect to ASGARD.
With this fix we will set a new FQDN for the ASGARD Management Center, recreate
the internal certificates, and rebuild the agents.
Warning
The used FQDN in this manual is just an example. Please use the
FQDN of your domain. make sure the FQDN is resolvable via your DNS
server.
To set a valid FQDN for your ASGARD Management Center server, follow the steps below.
We are assuming that your local DNS server already has an A-Record assigned, so your
clients can resolve the new hostname/FQDN of your ASGARD Management Center.
Connect via SSH to the ASGARD Management Center:
user@somehost:~$ sshnextron@asgard-mc.example.org
Edit the hosts file. Please be careful with the changes in this file,
as this might make your system unusable!
nextron@asgard-mc:~$ sudoedit/etc/hosts
[sudo] password for nextron:
You need to change the following line (do not change the IP-Address!):
1127.0.0.1 localhost
2172.16.0.20 asgard-mc
34# The following lines are desirable for IPv6 capable hosts
5::1 localhost ip6-localhost ip6-loopback
6ff02::1 ip6-allnodes
7ff02::2 ip6-allrouters
To this (values are examples, please change accordingly!)
1127.0.0.1 localhost
2172.16.0.20 asgard-mc.example.org asgard-mc
34# The following lines are desirable for IPv6 capable hosts
5::1 localhost ip6-localhost ip6-loopback
6ff02::1 ip6-allnodes
7ff02::2 ip6-allrouters
Note
If you did not set a static IP-Address for your ASGARD Management Center
server, your IP-Address in the second line of the file might be 127.0.1.1.
This is due to your server using DHCP. It is advised that you are using a
static IP-Address. To change this, please see Changing the IP-Address.
You can verify if the changes worked. Run the following commands and see the difference
in the output:
If the first command shows the FQDN and the second one the hostname without domain,
your changes were set up correctly and you can continue to the next step.
We need to recreate the TLS certificate to make the Agent to ASGARD communication
possible again. Create a new file which will contain the script with the fix.
In this example we'll use nano as the text editor. Make sure that the system has
a valid FQDN.
nextron@asgard-mc:~$ nanofix-fqdn.sh
Insert the following content into the text editor:
1#!/bin/bash2exportFQDN=$(hostname--fqdn)34sed"s/\$FQDN/${FQDN}/"/etc/asgard-management-center/server_cert_ext.cnf.in>/etc/asgard-management-center/server_cert_ext.cnf
5opensslreq-new-nodes-subj"/O=Nextron Systems GmbH/CN=${FQDN}"-key/etc/asgard-management-center/client-service.key-out/etc/asgard-management-center/client-service.csr
6opensslx509-req-in/etc/asgard-management-center/client-service.csr-CA/etc/asgard-management-center/ca.pem-CAkey/etc/asgard-management-center/ca.key-CAcreateserial-days36500-out/etc/asgard-management-center/client-service.pem-extfile/etc/asgard-management-center/server_cert_ext.cnf
7systemctlrestartasgard-management-center.service
8asgard-agent-repacker-host$FQDN
After changing the variables to the desired values, save the file.
In nano this can be done in by pressing CTRL+X and confirming the changes with y.
Give the created script execution permissions and execute it:
You should now be able to reach the ASGARD Server via the new FQDN.
Navigate to https://<YOUR-FQDN>:8443, which reflects the FQDN we set earlier.
At this point you have to install the ASGARD agents on your endpoints again.
Remember to review the network requirements section to ensure all needed ports
are open to the ASGARD Management Center from your endpoints.
See Network Requirements
In some cases THOR fails to complete its scan and ASGARD reports the following error.
ASGARD noticed that the THOR scan failed
could not remove temp directory: remove C:\Windows\Temp\asgard2-agent\12fa35a6762a\thor\signatures\sigma\windows\file_event_win_webshell_creation_detect.yms:
The process cannot access the file because it is being used by another process. exit status 1
(scan result does not exist)
The most likely reason for this error is an Antivirus interaction. The Antivirus killed
the THOR process and still holds a handle to one of the signature files. The "THOR Launcher"
can only report that the process was terminated and that it isn't able to remove all files
because the Antivirus process still has that open handle on the file.
ASGARD ships with a self-signed certificate for its web interface
that expires after 182 days. If you do not use your own CA
infrastructure and want to renew the certificate or want to revert
from a broken state, you can recreate a self-signed certificate.
To do so log in using SSH and execute:
nextron@asgard:~$ sudoopensslreq-new-newkeyrsa:4096-days182-nodes-x509-subj"/O=Nextron Systems GmbH/CN=$(hostname--fqdn)"-keyout/etc/asgard-management-center/server.key-out/etc/asgard-management-center/server.pem
You need to restart ASGARD in order for the changes to take effect.
If you've lost the password of the local admin user (Web GUI) but
still have access the system via SSH, you can reset it via command
line using the following command.
nextron@asgard:~$ sudomysqlasgard-management-center-e"UPDATE users SET password = 'YmIc6P_6jdbeEL0HY4xIcpYstmM' WHERE name = 'admin';"
This resets the password to admin. You should then change that password immediately.
If you or another user lost their second factor (2FA) to log into the ASGARD Web UI,
you have to reset the users MFA Settings. If you cannot access the Web UI, use
the Command Line method.
There are two possible ways to reset TwoFactorAuthentication for a specific user.
We recommend to use the first option via the WebUI.
Log into ASGARDs Web UI as a user with administrative privileges.
Navigate to Settings > Authentication > Users and edit the user
you want to reset 2FA for. On the bottom of the modal you will see that
the 2FA option is enabled. Disable the option and click EditUser
(Leave everything else as it is; do not fill in a new password if not
necessary).
After you edited the user, the TwoFactorAuthentication will be disabled
and the user can log into ASGARD without 2FA.
This method needs SSH access to the Management Center.
Log into your ASGARD via SSH. You can reset the users MFA Settings with
the following command (in this example we assume that the user is called john):
nextron@asgard:~$ sudomysqlasgard-management-center--execute"UPDATE users SET tfa_valid = 0 WHERE name = 'john';"
Warning
This will disable the 2FA settings directly in the database. Please make sure
the command and especially the username is correct.
If you don't know the exact username for a user, you can use the following command
to get all the usernames and the 2FA status from ASGARD (if tfa_valid has a value
of 1, this means the user has Two Factor Authentication enabled).
nextron@asgard:~$ sudomysqlasgard-management-center--execute"select name,tfa_valid from users;"+----------+-----------+| name | tfa_valid |+----------+-----------+| admin | 1 || john | 0 || rickroll | 1 |+----------+-----------+
This command will also allow you to verify if the UPDATE command was successful (tfa_valid should be 0).
In some cases the timezone during the installation of the server
image might not be correct. To see if you have this problem in your
current installation, please log into your server and execute the following command:
nextron@asgard:~$ timedatectl
Local time: Mon 2022-10-24 09:52:03 BST Universal time: Mon 2022-10-24 08:52:03 UTC RTC time: Mon 2022-10-24 08:52:04 Time zone: Europe/London (BST, +0100)System clock synchronized: no NTP service: inactive RTC in local TZ: no
If you see that the Time zone is incorrect, follow the next steps to correct it.
List all the timezones with timedatectllist-timezones. If you want
to search for a specific Country/City, you can use grep, e.g. timedatectllist-timezones|grepPrague.
Now that you have the correct timezone you can set it the following way:
nextron@asgard:~$ sudotimedatectlset-timezoneEurope/Prague
nextron@asgard:~$ timedatectl
Local time: Mon 2022-10-24 10:56:45 CEST Universal time: Mon 2022-10-24 08:56:45 UTC RTC time: Mon 2022-10-24 08:56:46 Time zone: Europe/Prague (CEST, +0200)System clock synchronized: no NTP service: inactive RTC in local TZ: no
Please reboot the system after the changes have been made.
Warning
This might cause problems with existing Scheduled Scans!
In some environments, Aurora might generate a high amount of False
Positives. This should never be the case, since Aurora should only
alert on very few and mostly important findings. Most likely a rule
is matching on the environment and generates too many false positives.
To circumvent this, you can disable the rule and set a filter later on.
For Tuning, please see False Positive Tuning of Sigma Rules.
This bug will prevent you from generating a new CSR in the TLS
Section of the Settings. The error message will look like this:
Error - could not generate csr
Could not read private key
Introduced Version
Fixed Version
<= 3.0.11
3.0.12
This bug will only occur if you upgraded your ASGARD Management
Center from version 2.x to 3.x. The issue is caused by the
controller.key file not being present in the /etc/asgard-management-center
directory. If you installed a fresh ASGARD Management Center 3.x,
with the new web based installer, this issue will not occur.
To work around this issue, you can run the following command:
nextron@asgard:~$ sudo-uasgard-management-centerln-s/etc/asgard-management-center/server.key/etc/asgard-management-center/controller.key
[sudo] password for nextron:
This will create a symbolic link from the server.key to the
controller.key file. After that, you should be able to
generate a new CSR in the TLS Section of the Settings.
AMC#007: curl: (58) could not load PEM client certificate
This bug only affects the asgard-updater helper tool,
which is used to update your ASGARD Management Center
from version 2.x to 3.x
Introduced Version
Fixed Version
<= 1.0.20
1.0.21
There is a bug in older versions of the asgard-updater
tool which is used to update your ASGARD Management Center
from version 2.x to 3.x. When using start-asgard-update,
you might encounter the below error in rare cases.
curl: (58) could not load PEM client certificate, OpenSSL error error:0909006C:PEM routines:get_name:no start line, (no key found, wrong pass phrase, or wrong file format?)
This error will appear if the following conditions are met:
the directory /etc/nextron/asgard2 contains multiple licenses files (.lic)
one of the licenses is older than April 2023
one of the old licenses is the last in an alphabetical order (based on the MD5 Hash)
Remove the old license files (you might need to change
to default license view to "All Licenses" in your Management
Center). You can compare the MD5 value of the license
with the filename of all licenses in the /etc/nextron/asgard2
directory and delete expired or old licenses.
AMC#006: THOR License not valid yet (timezone difference)
Introduced Version
Fixed Version
<= 2.16.3
N/A
There is currently a bug in the ASGARD Management Center which
can can cause problems during THOR license generation. This happens
if the following conditions are given:
An asset which is located in a different timezone to your ASGARD Management
Center
The difference between the two timezones is greater than 8 hours.
If this is the case for a few assets of yours, you will encounter
the following error in your THOR scan:
The current workaround is to avoid issuing THOR licenses on your
ASGARD Management Center during a specific time window. We take
the time difference between your asset and your Management Center
and subtract 8 hours. The resulting time is the time window,
beginning at 00:00 AM local time of your Management Center, from
which you should avoid issuing licenses. Below are two examples:
ASGARD Management Center timezone: UTC +11
Asset timezone: UTC -3
This results in a time difference of 14 hours. We subtract 8 hours
from that and are left with 6 hours. That means you should avoid
issuing new licenses during the following time:
00:00 AM until 06:00 AM of the ASGARD Management Center local time.
If you have the following scenario, you will not encounter the problem:
ASGARD Management Center timezone: UTC +2
Asset timezone: UTC -3
The timezone difference is smaller than 8.
AMC#005: Edge Browser with translation, "removeChild" error
Introduced Version
Fixed Version
N/A
N/A
Microsoft's Edge Browser is changing DOM objects on web pages, when
the translator is activated. This leads to the following error on
some of our pages:
Due to a bug in the installer of our ASGARD Agent, there is a possibility that
the configuration file (asgard2-agent.yaml) gets renamed but not replaced
by a more current version. This usually happens if the agent installer is being
run a second time, after the agent is already installed. In some rare cases this
can also happen when the agent is being updated via your ASGARD. All together,
this leaves the agent in an undesirable state, which will cause no tasks/jobs
to be executed due to the missing config file (task will be in Pending state
or return an error).
You will find errors in the agent log (C:\Windows\System32\asgard2-agent\log\agent.log)
and also observe that the installer directory only contains asgard2-agent.yaml.old
and not the correct asgard2-agent.yaml config file.
2023/03/29 23:34:26 ASGARD_THOR: Error: could not load config: open C:\Windows\System32\asgard2-agent\asgard2-agent.yaml: The system cannot find the file specified.
2023/03/29 23:34:26 ASGARD_AGENT: Error: task 1350 done with error: exit status 1
Another indicator is the asgard2-agent-install.log file located at
C:\Windows\System32\asgard2-agent\. This almost always means the installer
was executed multiple times. See the two highlighted lines below, a normal install
would only contain the first line. Re-running the installer will produce lines 2
and 3, which indicate that the agent might be in the faulty state.
12023/03/30 16:13:14 installer arguments: asgard2-agent.exe -install
22023/03/30 16:13:14 could not open dst file C:\Windows\System32\asgard2-agent\asgard2-agent-service.exe: open C:\Windows\System32\asgard2-agent\asgard2-agent-service.exe: The process cannot access the file because it is being used by another process.
32023/03/30 16:13:14 could not copy files from executable path . to install path C:\Windows\System32\asgard2-agent: open C:\Windows\System32\asgard2-agent\asgard2-agent-service.exe: The process cannot access the file because it is being used by another process.
To get the agent up and running again, you need to rename the config file to its
original name and restart the asgard2-agent service. We wrote a little batch script
you can use, alternatively you can write your own and deploy it. Administrative
rights on the endpoint are needed.
1@ECHO OFF
2 3IFEXIST"C:\Windows\System32\asgard2-agent\asgard2-agent.yaml"GOTOnoFix 4IFEXIST"C:\Windows\System32\asgard2-agent\asgard2-agent.yaml.old"GOTOfixConfig 5 6:noFix 7echo config file exists, nothing to do
8GOTOcommonExit 910:fixConfig11echo stopping asgard2-agent service
12sc stop asgard2-agent
13timeout /t 5
1415echo config file in renamed state, fixing
16copy"C:\Windows\System32\asgard2-agent\asgard2-agent.yaml.old""C:\Windows\System32\asgard2-agent\asgard2-agent.yaml"17timeout /t 2
1819echo starting asgard2-agent service
20sc start asgard2-agent
21timeout /t 5
2223echo service should be in state RUNNING
24sc query asgard2-agent | findstr STATE
2526GOTOcommonExit2728:commonExit29exit
Hint
If you are seeing a second asset with the same hostname in your ASGARD, the issue was
most likely caused by re-installing the agent over an already installed agent. Try to
avoid running the installer a second time on systems which already have an agent installed.
You can find information when the installer was being run in the installer log
C:\Windows\System32\asgard2-agent\asgard2-agent-install.log.
When debugging GRPC connectivity issues between your components (for example Management
Center to Analysis Cockpit), you might encounter an error similar to the following one:
There is no workaround for this type of error. The error usually occurs because
one of the following things are preventing proper communication between your
components:
Firewall is using TLS Inspection
Proxy is using TLS Inspection
DNS Issues
Note
Your components expect specific certificates from each other when communicating.
If a device is trying to inspect TLS traffic, the certificate will change and
you receive the above error.
To help you figuring out what is causing the problem, you can try the following.
You can use openssl on your source system to see which certificate is presented
by the destination host (change the host and port values as needed).
nextron@asgard2:~$ openssls_client-hostcockpit3.domain.local-port7443CONNECTED(00000005)depth=0 O = Nextron Systems GmbH, CN = cockpit3.domain.localverify error:num=20:unable to get local issuer certificateverify return:1depth=0 O = Nextron Systems GmbH, CN = cockpit3.domain.localverify error:num=21:unable to verify the first certificateverify return:1write W BLOCK---Certificate chain 0 s:O = Nextron Systems GmbH, CN = cockpit3.domain.local i:O = Nextron Systems GmbH, CN = Analysis Cockpit 3---Server certificate-----BEGIN CERTIFICATE-----
The marked lines show you the certificate which is presented by the destination
host. If this certificate is different from the one you installed, then the problem
might be a device trying to do TLS Inspection.
We are currently working on improving the presented error message, to give
a better understanding what might be the issue at hand.
In some edge cases within restricted endpoint configurations,
you can encounter a problem which causes some agents to send
a lot of asset requests. This is mostly caused by hardened systems,
where the asgard agent is not able to write to its own configuration
file. One example is SELinux prohibiting write access to the needed
YAML file.
The asgard-agent process needs write access to the configuration file.
Make sure the following condition is present to avoid multiple asset
requests from the same endpoint:
Process
File
Permissions
/var/lib/asgard2-agent/asgard2-agent
/var/lib/asgard2-agent/asgard2-agent.yaml
Read/Write
Make sure to disable AutomaticallyacceptallAssetRequests in
the Advanced Settings Settings in the meantime, to
avoid cleaning up after the changes to the endpoints have been made.
This chapter contains random scripts and tips for various
tasks you might encounter. Please keep in mind that we
want to provide guidance with the scripts in this chapter,
and you should still try to understand what they do and
modify them accordingly to your needs.
You can find a simple script to install the ASGARD Agent via
Powershell. Place the installer and script in the same folder.
Change the script as needed.
1# Setting vars 2$scriptpath=$MyInvocation.MyCommand.Path 3$dir=Split-Path$scriptpath 4$installer="asgard2-agent-windows-amd64.exe" 5$servicename="asgard2-agent" 6 7# Checking if ASGARD Agent is already installed 8if(Get-Service-Name$servicename-ErrorActionSilentlyContinue){ 9Write-Host"ASGARD Agent already installed, exiting"10exit011}else{12Write-Host"ASGARD Agent not found, trying to install..."1314# Install ASGARD Agent15Start-Process-Wait-FilePath"$dir\$installer"-WorkingDirectory$dir-WindowStyleHidden-PassThru1617# Timeout just to make sure the service is up and running18Timeout/T151920# Checking service to see if agent was installed21if(Get-Service-Name$servicename-ErrorActionSilentlyContinue){22Write-Host"Installed ASGARD Agent successfully"23exit024}else{25$Host.UI.WriteErrorLine("Could not install ASGARD Agent")26exit127}28}
To deploy the ASGARD Agent (or any other .exe installer) via SCCM, you
have to write a Powershell script with a few conditions to mark an
installation correctly as successful or failed.
1# Get current directory 2$scriptpath=$MyInvocation.MyCommand.Path 3$dir=Split-Path$scriptpath 4 5# Run the installer 6$installer="asgard2-agent-windows-amd64.exe" 7Start-Process-Wait-FilePath"$dir\$installer"-WorkingDirectory$dir-WindowStyleHidden-PassThru 8 9# Timeout just to make sure the service is up and running10Timeout/T151112# If the service exists, the script writes console output and exits with code 013# If the service does not exist, the script writes an error output and exits with code 114# See https://learn.microsoft.com/en-us/mem/configmgr/apps/deploy-use/create-applications#about-custom-script-detection-methods1516$servicename="asgard2-agent"17if(Get-Service-Name$servicename-ErrorActionSilentlyContinue){18Write-Host"ASGARD Agent installed"19exit020}else{21$Host.UI.WriteErrorLine("ASGARD Agent not installed")22exit123}
Warning
This is just an example script which should work with SCCM.
If you encounter any problems, refer to the link provided
above for additional information.
SCCM Applications can also use a script to detect the Deployment.
You can use this part of the script to detect if the installation was successful:
1$servicename="asgard2-agent"2if(Get-Service-Name$servicename-ErrorActionSilentlyContinue){3Write-Host"ASGARD Agent installed"4exit05}else{6$Host.UI.WriteErrorLine("ASGARD Agent not installed")7exit18}
The ASGARD Agent folder has in a normal installation specific
permissions set. The ASGARD Agent checks regularly
for broken permissions and tries to fix them. If for some reason this
process fails, you have to check and change the permissions manually.
2023/03/31 12:02:35 ASGARD_THOR: Error: failed to repair permissions: set security info: Access is denied.
To do this we wrote a little PowerShell script which can help you with
this process. Please test the script before you deploy it in your
environment. To do this, you can leave the -WhatIf flag to see what
the script would do if the permissions are broken. If you are content
with the potential changes, remove the -WhatIf arguments. The script
needs administrative permissions.
1$asgardAgent="C:\Windows\System32\asgard2-agent" 2$asgardAgentTemp="C:\Windows\Temp\asgard2-agent" 3 4if(Get-Item-Path$asgardAgent|Get-Acl|where {$_.Access.IsInherited-eq$false}){ 5Write-Host"ASGARD Agent folder permission broken. Trying to fix: $asgardAgent" 6# Set the new Access Rule to inherit permissions 7$newAcl=Get-Acl-Path$asgardAgent 8$newAcl.SetAccessRuleProtection($false,$true) 9Set-Acl$asgardAgent-AclObject$newAcl-WhatIf10}11if(Get-Item-Path$asgardAgentTemp|Get-Acl|where {$_.Access.IsInherited-eq$false}){12Write-Host"ASGARD Agent folder permission broken. Trying to fix: $asgardAgentTemp"13# Set the new Access Rule to inherit permissions14$newAcl=Get-Acl-Path$asgardAgentTemp15$newAcl.SetAccessRuleProtection($false,$true)16Set-Acl$asgardAgentTemp-AclObject$newAcl-WhatIf17}18get-childitem-path$asgardAgent-Recurse-Depth1|Get-Acl|where {$_.Access.IsInherited-eq$false}|%{19$fullPath=Convert-Path$_.Path20Write-Host"ASGARD Agent folder permission broken. Trying to fix: $fullPath"21# Set the new Access Rule to inherit permissions22$newAcl=Get-Acl-Path$_.Path23$newAcl.SetAccessRuleProtection($false,$true)24Set-Acl$_.Path-AclObject$newAcl-WhatIf25}
Tip
After you changed the permissions of the asgard2-agent folder,
the agent might correct the permissions again and set them accordingly.
Only use this script if the agent is showing errors that permissions
can not be set.
If you want to implement the ASGARD Agent into your Golden Image, you
can do this by following the steps in this section. Make sure to download
the right Agent Installer package from your ASGARD.
You have two options to deploy an Agent on your Golden Image, with the
first one being the easier method.
Before continuing, make sure the host can't reach your ASGARD.
In this method we make sure that the host system, which is being prepared
for the Golden Image, is either offline or can't reach the ASGARD. Go ahead
and install your ASGARD agent as you do normally. Once the installation is
done, you can stop the asgard2-agent service.
You ASGARD Agent should be ready now. You have to make sure that the Agent
is not communicating with your ASGARD during the whole process. If the agent
is for some reason communicating with the ASGARD and creating an Asset
Request, make sure that you stop the asgard2-agent service again and
inspect the following file:
The file should not contain the marked lines in the next example. If both lines
exist, make sure you delete them and save the file. Make also sure to deny the
Asset Request in your ASGARD to avoid confusion:
Your Golden Image will not work if the two lines in the asgard2-agent.yaml
file exist, it instead will create a DuplicateAsset. So make sure that
they are not present when you are creating the Golden Image!
If for some reason you can not prevent your host, which is being used for
the Golden Image, to communicate with your ASGARD, then follow the next
steps. Go ahead and install your ASGARD agent as you do normally. Once the
installation is done, you can stop the asgard2-agent service.
Once the service is stopped, we have to alter the configuration file of the
agent. This is necessary because your agent will have communicated with your
ASGARD by now, thus having generated an token, which should be unique.
If you would create your Golden Image now, you would have the
systems, installed with the Golden Image, appear as DuplicateAsset (see
Duplicate Assets Remediation).
Open the asgard2-agent.yaml file and delete the marked lines in our example.
After you deleted the two lines and saved the file, your host is ready. Make
sure those two lines are not present, as well as your asgard2-agent service
is still not running. We delete the token because it is unique to ASGARD.
If two agents are presenting the same token, they will be flagged as duplicate
assets. The registered value tells the agent if it has to send a new asset
request or not. Once it is set to true it would not send a new request.
Hint
Make sure to deny the Asset Request, which we just created while installing
the agent on our host, in ASGARD. This is to avoid confusion down the road.
Install TLS certificates on ASGARD and MASTER ASGARD
There are several methods to sign the ASGARD generated CSR
request. This section describes the two most common procedures.
Use Case 1 - CSR Signing with a Microsoft Based CA
Open the Certificate Authority snap-in within Windows Server
certsrv – Microsoft Certification Authority Main Page
Right click your CA >> All Tasks >> Submit new request
Please take into consideration that it could take a few minutes
until the ASGARD Service is restarted successfully.
After the service has been successfully restarted, the installed
certificate will be used by your Management Center.
Use Case 2 - CSR Signing with an OpenSSL Based CA
Warning
In order to avoid security warnings [1] on some browsers, the CA signing
process needs to ensure to copy all Subject Alternative Name (SAN) from the CSR to the signed Certificate.
There are two ways of doing this while singing the CSR via openssl.
The first method of including all extensions from the CSR to the new certificate,
is via the openssl.cnf file, by uncommenting the copy_extensions attribute.
The location of the openssl.cnf file depends on your system. On our test system, this
file was located at /etc/pki/tls/openssl.cnf.
Warning
Please make sure to comment the line out again once you are done with singing
your CSR.
Example:
80####################################################################
81 [ CA_default ]
82 83 dir = ./demoCA # Where everything is kept
84 certs = $dir/certs # Where the issued certs are kept
85 crl_dir = $dir/crl # Where the issued crl are kept
86 database = $dir/index.txt # database index file.
87 #unique_subject = no # Set to 'no' to allow creation of
88 # several certs with same subject.
89 new_certs_dir = $dir/newcerts # default place for new certs.
90 91 certificate = $dir/cacert.pem # The CA certificate
92 serial = $dir/serial # The current serial number
93 crlnumber = $dir/crlnumber # the current crl number
94 # must be commented out to leave a V1 CRL
95 crl = $dir/crl.pem # The current CRL
96 private_key = $dir/private/cakey.pem # The private key
97 98 x509_extensions = usr_cert # The extensions to add to the cert
99100 # Comment out the following two lines for the "traditional"
101 # (and highly broken) format.
102 name_opt = ca_default # Subject Name options
103 cert_opt = ca_default # Certificate field options
104105 # Extension copying option: use with caution.
106 copy_extensions = copy
107108 [...]
The second method of including all extensions from the CSR to the new certificate,
is via an extension file (for example asgard-test01.ext) containing all your subjectAltName entries.
This tells openssl to use a extension for signing the CSR. In our case the extension contains a list of
subjectAltName values.
To do this, place a file with your subjectAltName entries in the same folder of your CSR. The contents of this file
look something like the following example. Values after subjectAltName= should be equal to the
values of your CSR:
root@ca:~# catasgard-test01.ext
subjectAltName = DNS:asgard-test01.nextron, IP Address:172.28.28.101
The content should be identical to the values you set in your CSR. You can
inspect those with the following command:
root@ca:~# opensslreq-inasgard-test01.csr-noout-text[31/146]Certificate Request: Data: Version: 1 (0x0) Subject: C = DE, ST = Hesse, O = Nextron, OU = Security IT, CN = asgard-test01.nextron Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (4096 bit) Modulus: 00:cb:74:c9:ed:4e:4d:db:39:7b:e0:dc:bb:55:d6: [...] c2:9f:69 Exponent: 65537 (0x10001) Attributes: Requested Extensions: X509v3 Subject Alternative Name: DNS:asgard-test01.nextron, IP Address:172.28.28.101
Prepare the CA certificate, CA private key and the certificate signing request (and optionally your extension
file, if you chose method 2).
Execute/adapt the following command depending on the method you chose before:
First method:
root@ca:~# opensslca-certcacert.pem-keyfilecakey.pem-inasgard-test01.csr-outasgard-test01.crt-days3650Using configuration from /etc/pki/tls/openssl.confEnter pass phrase for cakey.pem:
root@ca:~# opensslca-certcacert.pem-keyfilecakey.pem-inasgard-test01.csr-outasgard-test01.crt-days3650-extfileasgard-test01.ext
Using configuration from /etc/pki/tls/openssl.confEnter pass phrase for cakey.pem:Check that the request matches the signatureSignature okCertificate Details: Serial Number: 1 (0x1) Validity Not Before: Feb 23 09:58:10 2023 GMT Not After : Feb 20 09:58:10 2033 GMT Subject: countryName = DE stateOrProvinceName = Hesse organizationName = Nextron organizationalUnitName = Security IT commonName = asgard-test01.nextron X509v3 extensions: X509v3 Subject Alternative Name: DNS:asgard-test01.nextron IP Address:172.28.28.101Certificate is to be certified until Feb 20 09:58:10 2033 GMT (3650 days)
This Chapter contains instructions on how to upgrade your running
Management Center version 2.17.2 to the newest version 3.
We developed an update program which helps you through the upgrade
by automating the process as much as possible.
Note
If you are using the BrokerNetwork functionality, please
consider updating the components as well. You can find the
instructions in the BrokerNetworkManual in the section
Major Updates.
Warning
Due to a bug in our updater tool, a small chance exists that
the upgrade will encounter an error. Make sure you have the
latest version of the updater tool installed. For more information,
please perform the steps in Management Center Upgrade
carefully to install the latest version of the updater.
To prepare for your upgrade, we compiled a list of tasks you
should follow:
Task
Description
Snapshot of your Management Center
For disaster recovery
Management Center running version 2.17.2
Prerequisite for the Major Upgrade
Connection to our new update servers
New update server infrastructure
For details regarding some of the above tasks, see the next section
in this manual.
With the new version of your Management Center, we also
made changes to our update servers. Please make sure
that all your components can reach the following servers:
Server
Port
Description
update3.nextron-systems.com
tcp/443
Old update server
update-301.nextron-systems.com
tcp/443
New update Server
The old update server is needed to fetch the updater and
other prerequisites. The new update server is needed to upgrade
your servers to Debian 12 and also to install any new packages,
which are needed for your Management Center v3.
To start your upgrade, connect to your Management Center via
SSH. We will utilize asgard-updater to perform the
upgrade. First we need to check if a newer version of the
asgard-updater is available. If you get the highlighted
output, you have already the newest version installed (the
version might differ from the output here):
nextron@asgard:~$ sudoaptupdate
nextron@asgard:~$ sudoaptinstallasgard-updater
Reading package lists... DoneBuilding dependency treeReading state information... Doneasgard-updater is already the newest version (1.0.15).0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
You can now run the asgard-updater with the following command:
nextron@asgard:~$ start-asgard-update
The server running your Management Center will now restart
multiple times. It is important to not interrupt the upgrade
process and let the server do all the tasks. You can, however,
see if any errors occurred during the upgrade or just observe
at what stage the upgrade is.
Run the following command to see the status of your upgrade:
Since the upgrade is downloading many packages of the debian
base system, the process will take a while. The web interface
of your Management Center might be available throughout the
upgrade, but we still advise to use it until the upgrade is
finished.
The update is finished if you are seeing the following lines:
Upgraded operating system from Debian 10 to Debian 12
Switched update server
Changed update server from update3.nextron-systems.com to update-301.nextron-systems.com. Please adjust your firewall to allow connections to the new server.
Time service transition
Switched from ntp to timesyncd for time synchronization.
UI Enhancements
A fresh, improved look and feel that makes the UI more intuitive and easier to use.
