Document Version: 1.2

Date: 2019-09-09


Copyright

© 2021 Outpost24® All rights reserved. This document may only be redistributed unedited and unaltered. This document may be cited and referenced only if clearly crediting Outpost24® and this document as the source. Any other reproduction and redistribution in print or electronically is strictly prohibited without explicit permission.

Trademark

Outpost24® and OUTSCAN™ are trademarks of Outpost24® in Sweden and other countries.


Purpose

This document provides users with a comprehensive overview of the scanning process. 

Scan Types

Discovery Scan

The Discovery scan sends packages over multiple protocols. If the scanner gets anything back from the target, the target is confirmed to be alive.

Infrastructure Scan

Scan Stages

  1. Portscan - Sends packages to approximately 5500 ports (default specified port range) for UDP and TCP protocols to find open ports on the target.
  2. Fingerprint - This stage uses the ports which were found open in the Portscan stage, to see which services are available on the target.
  3. Scanning - It collects the information from the target such as, platform, directories, and versions.
  4. Web scan (optional) - This is applicable only for web applications. It crawls over every link found and collects the scan information.
  5. Detection - Compares the information collected in the scanning phase with the Outpost24 vulnerability database.
  6. Report - Reports all findings found during the scan. 

Authenticated Scan using SMB or SSH

When a SSH authenticated scan is performed, various Linux/Unix based commands are executed in the target. When a SMB authenticated scan is performed, various powershell commands are executed in the target. 

These commands can be categorised into the following:

  1. I/O intensive
  2. Memory intensive
  3. CPU intensive

Any of the above mentioned commands can result in a CPU/memory spike on the target. Depending on the configuration of the target (concerning CPU and memory), the impact load on the target varies.

Example

A target with 4 CPUs handles CPU intensive commands better than a target with 1 CPU.

Web Application Scan

The engine always starts with these steps:

  1. Initialization
  2. Authentication (if specified)
  3. Crawling

Upon completion of the above stages, several actions are carried out such as: 

  • Pattern testing
  • Component detection
  • Passive XSS testing  

If fuzzing has been enabled for the scan, additional actions such as time-based fuzzing, fuzzing parameters are carried out. 

Refer to Scale Scanning Process for more information.

Secure Channel Communication

The traffic is sent over HTTPS and is thus encrypted with certificates.

Impact on the End Device


Note

Compliance scan causes more data and load consumption on the system running it.

General recommendation is to not run unsafe scans on production targets. 

Traffic Level

The traffic level depends on a number of variables. Two examples are listed below.

  • If a scanner updates via the scheduler, then it can take up to several hundred megabytes.
  • For regular syncs, it depends on how much the scanner found when a scan is run.

Refer to Schedulers and Scanners, to understand scheduler and scanner communication.

Bandwidth Consumption

The bandwidth consumption of scans is a broad spectrum that ranges from a few kB to several GB.

Even a single host depends on multiple factors such as:

  • Number of open ports, a lot of open ports = more bandwidth.
  • Type of listening services, a lot of open HTTP ports = more bandwidth as scanning of HTTP services requires several extra steps like crawling and testing of the input parameters.
  • Size of responses, larger responses = more bandwidth.
  • Latency, a lot of timeouts = more bandwidth, failed connection attempts will be repeated several times.
  • Configured authentication, authenticated scan = more bandwidth.
  • Passive/active type of scan, active scan = more bandwidth.
  • Scanned stack layers, web app layer = more bandwidth.

The scanning components are highly adaptive to the scanned assets which makes it difficult to define boundaries of a single scan.

Study case

In the example below, a scan of 1 server were performed with the following properties:

  • 1 SSH port
  • 2 web ports
  • Hosted in AWS
  • Scanned from Outpost24 SaaS platform




Scan typeScan duration (min)Data transmitted from the scannerData transmitted from the scanned assetComment
Appsec Scale

Passive scan

59 kB1.2 MB

Regular scan

880 kB16.2 MB

With infrastructure scan

212.79 MB21.8 MB
Netsec (Outscan)
Port scan416 kB48 kB
Normal scan191.6 MB5.2 MB36 findings
Normal scan + SSH auth261.7 MB5.7 MB75 findings

Note

It is difficult to predict how a host or network behaves during the scan. The numbers above are based on a single study case with minimal setup, and not representative enough to make any calculations based on them.

Tip

To gather precise results, perform several scans of representative for your assets and monitor the consumption in the infrastructure or cloud console.

Memory Consumption

Memory is unlikely to be severely affected. It mainly depends on type of the scan and state of the target. Few short spikes in CPU/disk usage are expected when scanning components perform CPU/disk heavy operations.

Frequently Asked Questions

How to modify settings to scan less ports, to reduce impact/time?

The portscan speed and number of ports to scan can be modified in Scan Policy settings under Portscan tab. 


Can we finely tune scanning policy to focus on critical findings?

Yes. You can enable only specific Vulnerability Checks under Maintaining Scanning Policy to focus on the most critical findings information.


Can we tune crawling to minimize its impact on the scan duration?

Yes. Modify depth setting in Appsec to lower the scan duration.