This document provides users with a comprehensive overview of the scanning process.
The Discovery scan sends packages over multiple protocols. If the scanner gets anything back from the target, the target is confirmed to be alive.
- Portscan - Sends packages to approximately 5500 ports (default specified port range) for UDP and TCP protocols to find open ports on the target.
- Fingerprint - This stage uses the ports which were found open in the Portscan stage, to see which services are available on the target.
- Scanning - It collects the information from the target such as, platform, directories, and versions.
- Web scan (optional) - This is applicable only for web applications. It crawls over every link found and collects the scan information.
- Detection - Compares the information collected in the scanning phase with the Outpost24 vulnerability database.
- 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:
- I/O intensive
- Memory intensive
- 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.
ExampleA 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:
- Authentication (if specified)
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
Compliance scan causes more data and load consumption on the system running it.
General recommendation is to not run unsafe scans on production targets.
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.
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.
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 duration (min)
|Data transmitted from the scanner
|Data transmitted from the scanned asset
With infrastructure scan
|Normal scan + SSH auth
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.
To gather precise results, perform several scans of representative for your assets and monitor the consumption in the infrastructure or cloud console.
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.
Required Disk Space for Scanning
The XML api prevents scans from starting if there is not enough disk space left on the HIAB. The default is set to 5GB, meaning that the scan does not start if the HIAB has less than 5GB available disk space left. The default value can be configured by Outpost24 for the customer, if the HIAB has Remote Support enabled.
What happens if the HIAB has less than 5GB disk space?
The scan will not start and the message "Could not start due to low disk space" is displayed in the Scan History under Cause of Error.
Note that there are not any error message other than the Cause of Error message in Scan History.
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.
© 2024 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.
Outpost24® and OUTSCAN™ are trademarks of Outpost24® and its affiliated companies. All other brand names, product names or trademarks belong to their respective owners.