Is it good practice to disable firewall rules for vulnerability scanners?



  • 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?



  • 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.



Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2