Scanning the network

How to scan networks and how to optimize for conditions where there are adverse effects of scanning.

Coda Footprint has two types of Network Scanners

[1] Cloud Scanner - This is hosted on the Internet and is multitenant (shared by all tenants)

[2] Internal Scanner - This is hosted on the customer’s own network or cloud subscription and is single tenant (can only be associated to one tenant)

The Internal Scanner can also be deployed as part of a Super Agent installation where a Footprint agent contains the Network Scan component. This is an integrated VM within the customer’s OS and has exactly the same features and functionalities as the traditional Internal Scanner

The scan has multiple components that happen a different times:

• host discovery - ICMP and SYN probing for active hosts

• dns resolution - DNS forward and reverse resolution for the scan targets

• critical port scanning - Port Scanning for the top 100 ports

• full port scanning - Port Scanning for the entire port list

• advanced scanning (the actual vulnerability scan) - Running active checks against discovered open ports to detect application versions and configuration

In order to perform a successful scan there are some requirements or pre-requisites:

The scanner performs active non-intrusive checks in order to find hosts, services and applications. In order for the scanner to discover those elements it has to have network level (IP level - OSI Layer 3) reachability to the scan targets. This can be routed or switched. As long as the scanner has a working network path it will be able to perform scans. In certain cases it is recommended to whitelist the source IP of the scanner in order for it to be able to perform the scans. This is needed especially in the case of Network Firewalls and Host Firewalls.

Scanning creates some overhead on the network as it would send numerous packets towards the destinations. It is recommended to optimize the overhead as much as possible by placing the Internal Scanners as close to the Scan Targets as possible. This sometimes means deploying extra Virtual Machines.

There are two types of Advanced Scan, one with brute force and one without brute force. If you notice issues during scan times then consider switching off the brute-force enabled slider for the hosts that are reporting problems. This is also valid for Firewall interfaces as some firewalls would block recurrent login attempts.

High Level Scan View

There are multiple zones that you would want to scan in each customer network. Let’s see some examples:

A. Servers

This is the part of the network where different Internal or Sensitive Servers are deployed and should have the highest security level. Access should be restricted to specific rules or sources. Scanning should be performed from an Internal Scanner inside this Security Zone so that it does not pass through the firewall.

For specific Servers it is also recommended to perform Authenticated Scans (Linux) or Agent Based scans (Windows).

B. LAN

This is where all the company assets are interconnected and is composed of workstations, different headless or IOT devices (printers, phones, door locks) and should be scanned periodically. Scanning should also be done from the same security zone so at least an additional Internal Scanner is recommended in this Security Zone.

C. Remote Users

Remote users are working either through specific cloud applications or VPN. They are normally using only end-user devices such as phones and laptops and are not reachable at all times from the company LAN. It is recommended to scan using local agents as those do not require network access but will collect the data and send it back to the console via HTTPS.

D. DMZ

The DMZ and the Public Access areas are where Publicly reachable IP Addresses are found. Either through advertised subnets or Destination NAT on the company Firewall/Router. It is recommended to scan those areas using the Cloud Scanner.

E. WWW

These are the Public Websites hosted in 3rd party locations or as a service. They are reachable from the Internet and should be scanned using the Cloud Scanner

Scan sizing

Scan sizing is the method we recommend following for which we can guarantee that scans should run and finish executing as expected. Generally, we recommend following these even if there are no noticeable issues in the platform.

Adjusting scans could help the overall resource utilization and free up more scanner time for the larger subnets. The scheduler can only be edited once per scanner so you would need to adjust per total scan surface size for each needed scanner on each tenant.

It is also possible to perform some sizing adjustments to the Scan Scheduler. Normally an Internal Scanner is recommended for:

One /24 or 254 IP Addresses scanned for daily frequency. 
If you are scanning /23 or 512 addresses then the frequency should be 48+ hours
If you are scanning /22 or 1024 addresses then the frequency should be 96+ hours or once a week
If you are scanning multiple ranges then multiply as seen fit

The settings above would apply for the cloud scanner as well.

How to decrease scan frequency to accommodate large scan surfaces (/23 and /22 IP ranges):

The above values are targeted for the Advanced scanner tasks with/without brute force.

For the other tasks please keep the following ratio:

Full Perimeter Service Scan - same as Advanced Scanner

Limited Perimeter Service Scan - 1/4 of Advanced Scanner

Perimeter Discovery via Reconnaissance - same as Advanced Scanner or 1/2 of Advanced Scanner

Health & Change Monitoring (TCP) - 1/8 of Advanced Scanner or 1/4

Health & Change Monitoring (UDP) - 1/8 of Advanced Scanner or 1/4

Web Applications Health & Change Monitoring - 1/3 of Advanced Scanner

Web Application Availability Scan - 1/3 of Advanced Scanner

Critical Service Health & Change Monitoring (TCP) - 1/8 of Advanced Scanner or 1/4

Critical Service Health & Change Monitoring (UDP) - 1/4 of Advanced Scanner or 1/2

Example:

If we set Advanced Scanner to 48 hours to accommodate a /23 network target then:

Full Perimeter Service Scan - will be set to 48h

Limited Perimeter Service Scan - will be set to 12h

Perimeter Discovery via Reconnaissance - 48h

Health & Change Monitoring (TCP) - 6h

Health & Change Monitoring (UDP) - 6h

Web Applications Health & Change Monitoring - 16h

Web Application Availability Scan - 16h

Critical Service Health & Change Monitoring (TCP) - 6h

Critical Service Health & Change Monitoring (UDP) - 12h