When operating the Mageni Platform a considerable amount of data can be transmitted by the target systems. The available scan results are also being analyzed, filtered and processed by the Appliance.
The speed of a scan depends on many parameters This section points out the most important settings and makes some recommendations.
Selecting a Port List for a Scan
Which port list being configured for a target and as such for the tasks and the scans has a big impact, for one on the discovery performance and on the other hand regarding the scan duration.
One needs to weigh up between those two aspects when planning the vulnerability testing.
TCP and UDP Ports
Ports are the connection points of network communication whereby each port of the one system connects with the port port on another system.
Every system has 65535 TCP ports and 65535 UDP ports. To be precise there is one more namely the special port 0. In a connection between two ports data transmission occurs in both directions for UDP only in one direction. Due to the fact that data received by UDP are not necessarily confirmed, the testing of UDP ports usually takes longer.
Ports 0 to 1023 need to be highlighted as so called privileged or system ports and usually can not be opened by user applications.
At the IANA (Internet Assigned Numbers Authority) standard protocol ports can be reserved that then are assigned a protocol name like port 80 for http or port 443 for https.
At IANA over 5000 ports are registered. However it is absolutely possible for software to use one of these ports for different purposes if the port is not being used on the respective system.
From analysis, in which all ports of all systems of all internet accessible systems were analyzed, lists of the most used ports were created. Those do not necessarily reflect the IANA list because there is no obligation to register a specific service type for a respective port.
Typically desktop systems have fewer ports open than servers. Active network components such as routers, printers and IP phones in general have only very few ports open, namely only those they require for their actual task and for their maintenance.
Choosing Wisely the Port List
The choice of the port list always needs to be weighed up between discovery performance and scan duration.
The duration of a scan is mostly determined by the amount of ports to be tested and the network configuration. For example, starting with a certain amount of ports to be tested, throttling by the network elements or the tested systems could occur.
For the discovery performance it is obvious that services that are not bound to ports on the list, are not being tested for vulnerabilities. Additionally malicious applications that are bound to such ports won’t be discovered of course. The malicious application mostly open ports that are usually not being used and are far form the system ports.
Other criteria are the defence mechanisms that are being activated by often exhaustive port scans and initiate counter measures or alerts. Even with normal scans firewalls can simulate that all 65535 ports are active and as such slow down the actual scan of those ports that are being scanned for nothing, with so called time outs.
Also to remember that for every port that is being queried the service behind it reacts at least with one log entry. For organizational reasons some services possibly should be scanned or at at least at a specific time only.
The following table outlines which port list could be most meaningful for which task.
|Scan Profile||Port List|
|Initial Suspicion, Penetration Test, High Security, First scan of unknown systems in limited numbers||
|Background test of an environment with known or defined environment (servers) in large numbers or with high frequency||
|First scan of unknown systems in large numbers or with high frequency||
The final decision needs to be made by the person(s) responsible for the scans. There should be at least documentation of the targets or problem to justify the selection of the ports.
On the one hand one can play it safe, meaning always scan all ports, will not achieve the desired outcome because all systems simply can not be scanned in time or because it will interrupt business operations.
On the other hand super fast, meaning only scan all privileged ports, will seem inadequate for unknown systems with high security requirements if during a later incident a vulnerability is being discovered that was rather easy to be identified. Examples for this are database services.
Also to be remembered, some systems do not use a static port allocation rather than constantly changing them even during operation. This, of course, makes it more difficult for a specific port list.
In some situations with port throttling scanning all TCP and UDP ports can take 24 hours or more for a single system. Since the scans are being performed in parallel two systems will of course only take marginally more time than a single system. However the parallelizing has its limits due to system resources or network performance.
However all IANA TCP ports do usually take no more than a couple of minutes.
Since some counter measures can increase the duration of a scan there is the option to prevent throttling by making configuration changes on the defense system.
All in all at the end one will learn over time network ranges to be scanned and how they will react to scans and routine tasks can be optimized in that regard.
In suspected cases of a compromise or highest security breaches a fully inclusive scan is unavoidable.
For port scans the basic principle that no total security exists is also true. This means that even when All TCP and All UDP are being used the pre set timeout of the port testing can be too short to coax a hidden malicious application into a response.
Or especially with a large amount of ports it comes directly down to defense through infrastructure. Less could sometimes even mean more.
If an initial suspicion exists an experienced penetration tester who combines the use of the actual scan tools with experience and professionally related intuition and has a good command of detailed parameterization should be consulted.
The scan configuration has an impact on the scan duration as well. Mageni offers four different scan configurations for vulnerability scans:
Full and fast
Full and fast ultimate
Full and very deep
Full and very deep ultimate
Both the Full and fast and Full and fast ultimate scan configurations optimize their process using already found information. This allows for the optimization of many NVTs and in doubt do not need to be tested. The two other scan configurations ignore already discovered information and therefore will execute all NVTs. This includes those NVTs as well that are not useful based on previously discovered information.
During the progress of a scan a progress bar is being created. This progress bar should reflect the progress of the scan in percent. In most cases this is a rough estimate since it is difficult for Mageni to project how the systems or services that haven’t been scanned yet behave compared to the already scanned systems and services.
This can be understood best when looking at an example. Assumed is a network 188.8.131.52/24 with 5 hosts: 192.168.0.250-254. A scan is being configured for this network. The scan will be performed in sequence. Due to the fact that the IP addresses at the beginning of the network are not being used the scan will run very quickly and reaches 95%. Then however, systems are being discovered that use many services. The scan will slow down respectively and since all these services are being tested. The progress bar only jumps very little. To adjust for this behaviour in the scanner dialog the Order for target hosts can be adjusted. The setting Random makes sense.