This document is intended to identify network-related operations performed by the CAM software. The intention is to allow network administrators and users of the software to identify situations that could be misinterpreted as a network attack scenario when they are normal operations of the software.
Ping Operations
The appliance performs ping operations against each potential IP address that it wishes to scan. A successful ping result is not required to ensure subsequent scanning.
The execution of this ping is a normal operation for the CloudSphere product.
Port Scan Operations
The appliance uses both netcat and nmap calls to establish if:
- Specific ports are open for traffic
- Perform basic network scanner to discover hosts and services on a target machine by sending packets and analyzing the responses. This approach is used to identify the underlying operating system.
scanprobe DNS Resolution succeeded for X.X.X.X
scanprobe PortScan successful
scanprobe Scan Failure event created: ScanFailureEvent[system]:{ts=1680614743519,loc=ProbePlugin:179,msg={"TCP Ping":"","ICMP Ping":""}}
scanprobe Setting unix.openports to [22]
scanprobe Open Ports:[22], OS Detected:Unknown
PortScan OS Detection using Nmap full output:
Starting Nmap 7.80 ( https://nmap.org ) at 2023-04-04 15:25 CESTNmap scan report for X.X.X.X
Host is up (0.00044s latency).
PORT STATE SERVICE
22/tcp open ssh
135/tcp filtered msrpc
PortScan OS Detection using Nmap, output line - Nmap done: 1 IP address (1 host up) scanned in 5.61 seconds
PortScan OS Detection using Nmap, output line - OS detection performed. Please report any incorrect results at https://nmap.org/submit/ .
PortScan OS Detection using Nmap, output line - No exact OS matches for host (test conditions non-ideal).
PortScan OS Detection using Nmap, output line - Aggressive OS guesses: Linux 2.6.32 (93%), Linux 2.6.32 or 3.10 (91%), Linux 4.4 (91%), Linux 2.6.32 - 2.6.35 (90%), Linux 2.6.32 - 2.6.39 (89%), Linux 4.0 (88%), Linux 3.10 - 4.11 (87%), Linux 3.11 - 4.1 (87%), Linux 3.2 - 3.8 (87%), Linux 3.2 - 4.9 (87%)
PortScan OS Detection using Nmap, output line - OS CPE: cpe:/o:linux:linux_kernel:2.6.32 cpe:/o:linux:linux_kernel:3.10 cpe:/o:linux:linux_kernel:4.4 cpe:/a:synology:diskstation_manager:5.2
PortScan OS Detection using Nmap, output line - Running (JUST GUESSING): Linux 2.6.X|3.X|4.X (93%), Synology DiskStation Manager 5.X (85%)
PortScan OS Detection using Nmap, output line - Device type: general purpose|storage-misc
PortScan OS Detection using Nmap, output line - Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
PortScan OS Detection using Nmap, output line - 135/tcp filtered msrpc
PortScan OS Detection using Nmap, output line - 22/tcp open ssh
PortScan OS Detection using Nmap, output line - PORT STATE SERVICE
PortScan OS Detection using Nmap, output line - Host is up (0.00044s latency).
PortScan OS Detection using Nmap, output line - Nmap scan report for xxx (X.X.X.X)
PortScan OS Detection using Nmap, output line - Starting Nmap 7.80 ( https://nmap.org ) at 2023-04-04 15:25 CEST
PortScan Command : [bash, -c, /usr/bin/nmap -O -Pn -p T:22,135 X.X.X.X]
NetCatPortScan netcat: [bash, -c, /usr/bin/nc -z -vv -n -w5 X.X.X.X 3389]
NetCatPortScan netcat: [bash, -c, /usr/bin/nc -z -vv -n -w5 X.X.X.X 443]
The appliance does not perform scanning across thousands of ports but uses a limited set of ports to establish the information that it requires. The following is a set of significant ports used across the targets (those which are in bold are involved in the netcat and nmap operations):
Ports | Description |
135, 137, 138, 139, 445, 3389 |
Windows Server Discovery |
443, 9443 | Application Discovery |
22 | Unix Discovery |
In order to reduce the possibility that these operations are not identified as a port scan attack, it is recommended that any appliance IP is whitelisted in the firewall software to allow incoming traffic to the target machine (without the generation of false positives)
The execution of this scan is a normal operation for the CloudSphere product.
Scripting (Metrics Collection)
Part of the functionality of the CAM software is to provide right-sizing information that can be used to ensure deployments are placed in appropriately sized cloud instances. Metrics collection is used to establish the current usage (memory, CPU usage, etc.) Metrics collection requires ongoing collection operations that are executed periodically on the target machine.
The collection of these metrics is performed by creating scripts (VBS scripts on Windows, Shell scripts on *NIX) on the target machine that are executed once (and continue to run). The generated metrics are periodically forwarded to the appliance for collection and storage on the SAAS platform. The running scripts have a specified Time-To-Live (TTL) of 14 days, after which they no longer perform collection services. A re-scan of the target machine will restart a terminated metrics collection process.
The scripts and associated support tools are created in a temporary folder on the target:
- Windows: c:\WINDOWS\temp\perfmetrics\tools
- *Nix: /var/tmp/perfmetrics/tools
The metrics collection will attempt to ensure that “reach back” to the appliance is possible by making a curl connection to <appliance-ip>:8080. Assuming that this connection is open, metrics traffic will then be transferred to the appliance.
The execution of the script is a normal operation for the CloudSphere product.
Cloud Instance Interrogation (Magic IP)
The appliance requests that metadata that is available for all cloud-based instances by interrogating a “magic” IP address http://169.254.169.254. This retrieval request is executed on both cloud and on-premise targets. However, only cloud instances ever return information for this request.
Each cloud instance that is launched has an instance identity document that provides information about the instance itself. The instance identity document is used to validate the attributes of the instance and is retrievable on the specified IP.
The instance identity document is generated when the instance is stopped and started, restarted, or launched. The instance identity document is exposed (in plaintext JSON format) through the Instance Metadata Service (IMDS). The IPv4 address 169.254.169.254 is a link-local address and is valid only from the instance.
All cloud providers support this functionality. See associated documentation:
The execution of this query is a normal operation for the CloudSphere product.