4

I've been asked to ensure that our vulnerability scanning tools (like Qualys, Nexpose) are able to reach all of our AWS EC2 instances, on all ports and protocols.

Today they are limited by the current security groups (which generally allow either no traffic, or well-defined protocols such as HTTPS). We could implement a new security group scope to the CIDR range in which the vulnerability scanning engines reside, allowing the range unfettered access.

I don't believe this is a good idea. Is there any official, written guidance (by a well-respected authority) making the case one way or the other, for disabling network, port and protocol filtering to allow vulnerability scanners full access?

schroeder
  • 123,438
  • 55
  • 284
  • 319
An Anonymous AWS User
  • 41
  • 1

4 Answers4

1

The nature of a firewall gives you the expectation to allow traffic necessary to the function of the network. You don't need someone in authority saying that it's ok.

The principle is that you allow only the necessary traffic through (Principle of Least Privilege). That means, if your scanner is necessary, then you need to allow it. In administration and security, sometimes the "least" privilege/access required is the "highest" privilege/access possible. This is normal and expected. There isn't going to be an official document saying if a certain level of privilege/access is ok or not. That's a risk assessment that needs to be made in context.

It sounds like you are concerned about the risks of the business requirement in this case. There are things you could do to lower the risks.

What's interesting in your description is that you are not putting any controls in at all; "unfettered".

If the CIDR range is limited to just the scanners, then that's fine. You could allow just the specific IPs. If you scan on a schedule, you can also add time windows to allow the traffic. You can also limit the port access to the ports that you want (and have a risk-based need) to scan.

schroeder
  • 123,438
  • 55
  • 284
  • 319
  • OP is seeking official documentation about whether allowing vulnerability scanners privileged access is acceptable. While no reference was made, your input is valuable as a SECSE moderator and experienced security professional. Consider trimming/consolidating this post into a comment or update with references OP is requesting. – phbits Jun 17 '21 at 23:14
  • @phbits lol, yes, I know the OP is looking for official sources. My answer is that none likely exist and none are necessary. And no, the question is not whether scanners need privileged access; just access. – schroeder Jun 18 '21 at 06:49
  • Having references to official guidance is helpful at times for that is why we often cite RFCs. The level of access a vulnerability scanner is granted greatly impacts the results (e.g. external, internal, authenticated, etc.). I would consider an `allow all` firewall rule a level of privileged access. :) – phbits Jun 18 '21 at 17:37
1

With questions like this, where there is unlikely to be formal specific best practice guidance, it often helps to look at the underlying security goal, how it can be achieved, and the pros/cons of using a specific method to achieve it.

Here the question is around vulnerability scanning of hosts, the goal is likely to detect mis-configuration of the hosts (e.g. unsecured services running) or the presence of malicious software which has been installed on them.

There are generally speaking, two ways to achieve this goal. The first is to use a black box vulnerability scanner which runs over the network to target the in-scope systems.

The second is to use a credentialed vulnerability scan to review the configuration of the in-scope systems.

From an accuracy perspective, the credentialed scan is likely to produce superior results, as it can review program versions and things like listening ports without risking interception or modification by any network or host firewalls. The downside of a credentialed is that there's a requirement to provide the scanning tools with valid credentials for each host, so there's an overhead in maintaining and securely managing those credentials.

Using an unauthenticated network scan does not have this requirement, but may lose some accuracy and does require complete network level access in order to assess the visible services running on the in-scope systems. In terms of the risk of allowing that access, assuming a correctly scoped rule, you would only be at risk if the source system(s) are compromised or if an attacker can spoof their IP address AND there is an exploitable vulnerability on the target systems.

All of this is to say two things.

  1. If the goal here is to provide the best assessment of system vulnerabilities and configuration, I would recommend authenticated scanning, which won't require major modification to network access (generally it requires SSH for Linux hosts and a couple of management ports for windows hosts)

  2. If authenticated scanning is not possible, then typically network scanners do require full network level access to in-scope systems, but a correctly scoped firewall rule shouldn't introduce significant additional risk to your environment.

Rory McCune
  • 60,923
  • 14
  • 136
  • 217
-1

In most on-premises environments, the network was built over years (or maybe decades) and nobody knew/knows which ports are open on which machine, and whether those ports may at some point in the future become open. Given these limitations, folks had no choice but to run comprehensive scans against every machine on the network on a periodic basis to detect these open/closed ports.

With AWS, all elements of the VPC are defined via software, and can be described/evaluated on a real-time basis. Tools like AWS Inspector can detect reachable ports without sending packets over the wire, but rather evaluating your VPC configuration.

Similarly tools like AWS Config can alert, and automatically remediate, any issues regarding open ports on a machine.

Given that, we can now evaluate if a port is open and reachable, and automatically alert/remediate if ports suddenly were misconfigured to be opened (instead of closed), without ever running a network scan -- I'd invest my efforts on them to achieve the same effect, rather than opening up ALL ports on ALL machines to a CIDR range.

schroeder
  • 123,438
  • 55
  • 284
  • 319
keithRozario
  • 3,571
  • 2
  • 12
  • 24
  • While all this might be true, and even a good alternative, some companies require a 3rd-party scanner to be used. Which means the question stands. – schroeder Jun 15 '21 at 14:27
  • The question is about whether it's good practice, I think it isn't based on my points above, but happy to be proven otherwise. – keithRozario Jun 17 '21 at 10:32
  • 1
    You are reframing the question. Please make sure that answers address the question. You are providing an alternate approach that would make the question moot. But as I said, not every company can avoid the situation in the question. So the question stands. – schroeder Jun 17 '21 at 12:15
  • Vulnerability scanners don't just determine what ports are open. They also inspect the service to determine vulnerabilities. So, although port access might be defined in VPC code, that does not tell anyone whether the service running on an open port has a vulnerability. So, no, this answer misses the question ***entirely*** and offers an alternate approach that applies only to one aspect of the goal. – schroeder Jun 17 '21 at 12:20
  • OP is seeking official documentation about whether allowing vulnerability scanners privileged access is acceptable. This post provides a useful alternative while not addressing the OP ask. – phbits Jun 17 '21 at 23:20
-2

The Information Security Office at the University of California, Berkeley advocates Authenticated Scans and will mandate it when sensitive data is involved. While this is more involved than an allow all firewall rule, the principles are the same.

The additional details provided by an authenticated scan allows resource proprietors and resource custodians to better mitigate risks on covered data and reduce the likelihood of successful attacks against covered devices.

Under Additional Resources is a reference to NIST Patch and Vulnerability Management Program Guidelines which states:

Network scanners are generally ineffective at gathering accurate information on hosts using personal firewalls, unless the personal firewalls are configured to permit the network scanning activity.

ref: SP 800-40 Version 2.0 Section 2.9.1

schroeder
  • 123,438
  • 55
  • 284
  • 319
phbits
  • 1,002
  • 2
  • 5
  • 12
  • 1
    No, the principles of authenticated scans and open firewall ports are not the same. They are completely different concepts for different goals and results. – schroeder Jun 18 '21 at 06:56
  • The 2005 NIST document you quote is no longer official since it was superseded in 2013 and the newer version doesn't include the section. The document is not mentioning "best practice" for opening all ports, but a functional concern for firewalls. This supports my claim that there is no need for an official authority to permit a firewall configuration. It is merely a functional consideration. – schroeder Jun 18 '21 at 06:59
  • This answer does not address if opening ***all*** ports to a whole CIDR range is best practice. – schroeder Jun 18 '21 at 07:00
  • @schroeder, thanks for the feedback! I've updated my answer with my response as it was too long for a comment. :) – phbits Jun 18 '21 at 17:30
  • @schroeder, I believe you're being overly critical. The principle of Authenticated Scans and an `allow all` firewall rule are the same in that the vulnerability scanner is being granted privileged access to the target host. – phbits Jun 21 '21 at 15:03
  • I completely agree with you that each technique is different and aimed at addressing different aspects of vulnerability scanning which ties into NIST 800-115: `This publication focuses on explaining how these different technical techniques can be performed, and does not specify which techniques should be used for which circumstances—thus providing organizations with the flexibility to choose the techniques that best meet their requirements.` – phbits Jun 21 '21 at 15:03
  • Yes, I understand the NIST document has been "superseded" though one shouldn't be so quick to dismiss the content as it is still relevant. Consider an HTTPS service being restricted to a specific set of IP addresses. If the vulnerability scanner cannot query that service, the organization will not have a way to audit `SSL/TLS` is properly configured. As previously mentioned, the testing technique should be determined by the business. – phbits Jun 21 '21 at 15:03
  • For OP, the organization chose to use vulnerability scanning with full network access and is seeking official guidance "making the case one way or the other". The reference to `800-40` addresses this as does my HTTPS example. – phbits Jun 21 '21 at 15:03
  • Allowing traffic from a CIDR block really depends. My concern would be how large is it? If it represents a large number of addresses frequently recycled in the cloud and used by other cloud customers, I would strongly advise against it. Whereas static addresses used only by the vulnerability scanner and having acceptable change management procedures would have a much more acceptable level of risk. – phbits Jun 21 '21 at 15:04
  • 1. Access to ports is not "privileged access". 2. Then therefore your NIST 800-115 quote is not "best practice" 3. I'm not being quick. The ask is for official guidance. To omit the fact that the guidance you quote has been superseded is to mislead. 4. All these words you have said reinforces my main comment: you have not provided best practice, but merely recognition of functional realities, but you are posing them as "best practice". – schroeder Jun 21 '21 at 16:10
  • You also fail to mention the issue of opening *all* ports to a CIDR range. This is the core of the question. Your answer doesn't address that core at all. – schroeder Jun 21 '21 at 16:11