Aurora Vulnerability Management Scanner functionality

The Aurora Vulnerability Management Scanner (Aurora VM Scanner) uses OpenVAS technology to detect vulnerabilities in your environment. This information explains how the scanner operates.

Scanner impact

The scanner can scan all device types on a network, including networking gear like switches and routers, printers, cameras, phones. Make sure that your network can support additional load from scanners.

The scanner performs lightweight Nmap scans that only send Internet Control Message Protocol (ICMP) and synchronize (SYN) packets for port scanning. The scanner also performs lightweight OpenVAS scans that typically send and receive <400 kB/sec of bandwidth. Depending on the hosts that are scanned and what services they are running, occasional bursts of bandwidth to ~1 MB/sec might occur.

Scanning certain devices can cause unintended behavior, such as network performance issues, increased traffic volume, unusual device reporting, and excessive device logging. We recommend testing against certain devices to check performance impacts before adopting widespread scanning.

We recommend that you avoid scanning these devices:
  • Printers, especially large scale printers
  • Medical devices
  • Internet-of-Things (IOT) devices
  • Scanners
  • Voice over Internet Protocol (VoIP) phones
  • SQL Server
  • Uninterruptible Power Supplies (UPSs)
  • Mainframes
  • Small network appliances
  • ATMs
  • HVAC systems
  • ESXi servers
    Note: Scanning these servers might lock you out and force you to restart their management service.
  • Legacy hardware lacks the CPU overhead and memory management required to process aggressive or continuous vulnerability scans, for example, end-of-life routers, factory sensors, and older programmable logic controllers (PLCs)

To exclude devices from being scanned, see Configure scan exclusions.

If you are concerned about network load, take these actions to reduce the impact on your network:
  • Don't run the scanner during production hours.
  • Set the scanner to only ping targets for discovery. For more information, see Enable or disable Only ping the target mode.
  • Run the scans locally, not across a WAN or firewall.
  • If your firewall supports it, limit the number of new connections from the scanner allowed through the firewall.

Scanner targets

You can define the targets that you want the scanner to scan.

You should only configure scanning for private internal IP addresses. Do not add anything outside of the ranges listed on the American Registry for Internet Numbers (ARIN).

Arctic Wolf recommends that you slowly add networks to your scan schedules and break larger networks into smaller sections. The scanner supports scanning subnet ranges up to /16, but scanning larger subnet ranges might not complete in a reasonable timeframe.

Scan schedules

You can schedule IVA scans to run monthly, weekly, daily, or continuously. This frequency is configurable for each network or host.

Note: For more information about scan schedules, see Scan schedules.

Continuous scanning enables continuous visibility, immediate discovers new devices and vulnerabilities that enter your network, maximizes use of the scanner, and minimizes the time between scans for a single target.

We recommend that you scan each host on the network at least every 10-14 days. You might require more scanners based on your network size and complexity.

You can configure scans based on your preference, including location. You might prefer to perform workstation scanning during the day and server scanning overnight. Scans always run in the order that they are listed in the Unified Portal. For more information, see Scan schedules.
Tip: We suggest starting scans when a member of your team is available to add devices to your denylist or turn off scanning if a host reacts poorly to being scanned. Scanning schedules should help prevent devices from going offline or prevent scanners from overwhelming devices with HTTP requests during business hours.

Scan frequency and length

The scan frequency for a host depends on multiple factors, including:

  • The uptime of the host.
  • The number of hosts in the scan.
  • Host uptime on the network.
  • The scanner hardware.
  • Network vulnerability tests (NVTs) that the scan runs against the host.
Note: After four hours of scanning a single asset, scans time out and quit scanning that asset.
This table provides estimates for how long it takes to scan a number of hosts:
Note:
  • These estimates assume that each scan takes 16 minutes per device.
  • Scanner performance varies based on your environment. If you are using a vScanner, the allocated resources can also affect scanner performance. This table only provides estimates.
  • You can deploy multiple vScanners and subnets to increase the amount of results returned at a time.
Total hosts Minutes to scan Hours to scan
1 16 0.3
2 16 0.3
4 16 0.3
8 32 0.5
16 48 0.8
32 96 1.6
64 176 2.9
128 352 5.9
256 688 11.5
512 1376 22.9
1024 2736 45.6

Host identification scan frequency

Scanners start a new host identification scan five minutes after the previous host identification scan completes. Precise timing depends on how long it takes for the scan to complete.

For example, if host identification scans take one minute to complete, the scans would run every six minutes (5 + 1 minutes). If it is a complex network and the host identification scan takes 15 minutes complete, the scans would run every 20 minutes (5 + 15 minutes).

Scanner tests

During tests, the scanner determines if a vulnerability exists, and then drops the connection to that host or service.

Host identification tests

Host identification tests use open-source Nmap technology to test if a specific host is connected to the network and responding to basic network connectivity checks.

The scanner uses host identification tests to create a host profile for each scan target to map vulnerability reports to specific hosts. These are the tests performed:
  • Address Resolution Protocol (ARP) scan
  • Internet Control Message Protocol (ICMP) echo
  • ICMP timestamp
    Note: For more information about ICMP echo requests and the Only ping the target toggle, see Enable or disable Only ping the target toggle.
  • Transmission Control Protocol (TCP) acknowledge (ACK) on port 80
  • TCP synchronize (SYN) on port 443

Service detection tests

Service detection tests send TCP SYN packets to detect what services are responding on which ports.

Service version tests

Service version tests connect to a service on the host and determine the version of the service that is running, if possible. Vulnerabilities for that specific version are checked against a database of known vulnerabilities and matches are reported.

Active exploit tests

Active exploit tests connect to a service, wait for a response, and then use that response to send a specifically-crafted packet to determine if a particular vulnerability is exploitable.

Default credential tests

Default credential tests connect to a service, and then attempt to sign in using a dictionary of default credentials credentials for that service.

Network vulnerability tests

The scanner also runs a variety of other network vulnerability tests (NVTs).

NVTs that the scanner runs include:
  • Remote version detection — The scanner connects to host services and collects self-reported version information, to verify if hosts are using versions with known vulnerabilities.
    Note:
    • These NVTs might miss self-applied patches without version numbers.
    • When services are locked down or otherwise configured not to self-report versions, the scanner might not detect these vulnerabilities.
  • Crafted packet and response check — The scanner sends a specific series of packets that test if a vulnerability exists based on the response from the host.
  • Credentialed detection — If configured, the scanner connects using customer-supplied credentials to obtain a list of installed software, and then the version check NVTs run against that list. For more information about credentialed scanning, see Configure credentialed scanning.
    Tip: This detection can find vulnerabilities that are not remotely exploitable, such as an Adobe Acrobat vulnerability.
  • Weak or default password checking — Services that have a sign-in prompt, like SSH or web pages, or services that collect credentials as part of protocol, like SMB, are tested against default or weak passwords. For example, password.
    CAUTION: These scans can negatively impact services with lockout policies. Arctic Wolf cannot disable these types of scans on those devices, as this may inadvertently disable all scheduled scans.

Scanner checks

Using your defined schedules, the scanner obtains a list of targets to look for.

Using the list of targets and the data from the denylist, the scanner attempts to determine if relevant machines are online by sending out Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP), and Transmission Control Protocol (TCP) packets, and then monitoring for responses.
Note: Detection is based on your environment and configuration. If your configuration is uncommon or significantly different from industry standards, the Aurora Vulnerability Management Scanner (Aurora VM Scanner) may not detect some vulnerabilities found by other tools.
During a scan, the scanner:
  • Analyzes HTTP headers for security misconfiguration
  • Analyzes robots.txt for interesting URLs. For example, /admin or other restricted pages
  • Attempts to find interesting files or functionality. For example, restriction or permission concerns
  • Checks if known vulnerabilities are affecting server software
  • Checks mail servers for SMTP problems, including mail relay
  • Checks whether a client access file exists, and then determines if it contains a wildcard entry. For example, clientaccesspolicy.xml or crossdomain.xml
  • Crawls websites
  • Discovers server configuration problems. For example, directory listing
  • Finds administrative pages
  • Fingerprints web server software
  • Checks for:
    • Cross-site scripting
    • Information disclosure issues
    • Local file inclusion and remote file inclusion
    • Operating system (OS) command injection
    • Outdated JavaScript libraries
    • The security of HTTP cookies
    • Sensitive files, like archives, backups, certificates, or key stores, based on hostname and some common words
    • SQL injection
    • The SSL certificate of the server

Scanner workflow

The Risk Scanner operates in stages when determining which hosts to scan next.

During this process, the Risk Scanner:
  • Builds a list of active hosts based on the most recently completed Nmap scan.
  • Uses the OpenVAS history to sort the list of active hosts according to the least recently scanned interval, with the least recently scanned host at the top of the list, and the most recently scanned host at the bottom.
  • Determines if each host is eligible to be scanned based on whether the current time falls within the applicable scan schedule window.
  • Determines the system capacity to manage simultaneous scans based on the current CPU load. It begins with one scan and increases by one additional scan every cycle until all CPU resources are used. If the CPU load exceeds the threshold, the number of simultaneous scans is reduced by one for the next scan cycle.
  • Runs the new scan, starting with the least recently scanned host that is available to be scanned at that moment. Then, the scanner polls for the next least recently scanned host until the scanning capacity is reached.