Skip to main content

Vulnerability Scanning

What Is vulnerability scanning

Vulnerability scanning is the second level of countermeasures in a defence in depth after a firewall. Even with a firewall blocking some malicious traffic a server providing online services must be connected to the internet and must interact with traffic from the internet. Unfortunately, a percentage of that traffic is malicious and will attempt to find a means to gain unauthorised access to the server. What these hackers are looking for are ways to exploit of out-of-date software containing bugs or server mis-configurations of the software that interacts with the internet traffic.

Memset Vulnerability Scanning does exactly the hackers are doing, we audit the server by probing all open network ports to determine exactly what programs are accepting network connections and compare how they are configured and what versions they are against all know bugs and known mis-configuration issues. Memset has the advantage in that we can perform thousands of highly detailed checks and compares them to an exhaustive database of know issues for an extremely detailed analysis and threat report of the server. A hacker must perform their scan stealthily and only for a limited number of cases as they cannot make their presence known.

An example of the sort of information that is collected and analysed is the header information that is often provided by a webserver. Webservers can, and should, be configured to not provide any information regarding what they are and their version, however, sometimes through mis-configuration they do. The following is provided by a well known website:

Connecting to microsoft.com (microsoft.com)|134.170.185.46|:80... connected.
HTTP request sent, awaiting response... 
  HTTP/1.1 200 OK
  Cache-Control: private
  Content-Length: 96638
  Content-Type: text/html
  Server: Microsoft-IIS/8.5
  P3P: CP="ALL IND DSP COR ADM CONo CUR CUSo IVAo IVDo PSA PSD TAI TELo OUR SAMo CNT COM INT NAV ONL PHY PRE PUR UNI"
  CorrelationId: 492bf382-a61d-4cd6-8cae-76fb114208f3
  X-AspNet-Version: 4.0.30319
  X-Powered-By: ASP.NET
  Access-Control-Allow-Headers: Content-Type
  Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
  Access-Control-Allow-Credentials: true
  X-Powered-By: ARR/2.5
  X-Powered-By: ASP.NET
  Date: Tue, 08 Jul 2014 21:54:19 GMT
Length: 96638 (94K) [text/html]

Although there is a lot of information in this response the webserver has disclosed that it is running Microsoft IIS 8.5 and employing ASP 4.0.30319. Should a vulnerability be discovered in either of those versions this information can be used by a hacker to target the server. Memset proactively scans for this sort of information disclosure and will flag it as an issue as soon as it is discovered.

What will happen after a scan is performed?

Memset will perform the vulnerability scan once per month, it usually takes around 10 to 15 minutes to complete the scan depending on how busy the server being analysed is. Once the scan is completed a report is automatically created. The report is detailed and lengthy as it will contain, in addition to critical problems, many minor issues and suggestions that can be followed to create an ideal deployment. It will be emailed out as soon as it is created to the admin contact for the Memset account.

If the server has Memset Managed Support the report will also be placed into the to the Memset engineering team's ticketing queue and reviewed shortly afterwards. Please allow a few days for the report to be reviewed it will get looked at by an engineer and cannot be missed or forgotten about.

Any critical issues flagged in the report will be fixed by the Memset engineering team. If the issue can be resolved without operationally affecting the server e.g. upgrading the version of openssl after the heartbleed issue, then the work will be carried out and the Admin Contact notified of the work afterwards. However, should the needed work affect or have the potential to affect the normal running of the server e.g. upgrading the php or mysql, then the engineer will be in touch before making any changes explaining the issue at hand, the needed work and the possible ramifications of the work before making any changes. Only once confirmation is received will the engineer proceed.

Last updated 18 July 2019, 08:08 GMT