External Vulnerability Scan of DMZ

Question

We currently have an internal and external vulnerability scanner setup in my organization. This morning our external scanner was going through a new external DDoS protection service instead of directly at our public IP space. (We firewall off anyone except the DDoS provider.) I thought this peculiar as I would just target our direct IP and make a firewall exemption for the external vulnerability scanner IPs.

I was then informed that the external scanner has no exemptions and goes through the same security measures that a visitor would. My brain says that an external scanner should be looking at the core applications and not the security measures. The internal scanner does scan the DMZ from the internal side.

What is the normal approach to deploying an external vulnerability scanner. Should it scan as if it were a visitor or should it scan as if there were no security controls? (Take into consideration that we do have an internal scanner, which does scan DMZ targets.)

Answer 1

I guess it depends on circumstances.

My worry with what you have described above would be that if you're not directly hitting your public IP space (relying on your firewall set up to drop anything not coming from your DDoS protection service), you're trusting that no vulnerabilities or mis-configurations exist within your firewall.

The set up you describe is assuming that any attacks would be coming through the route visitors take which is by no means certain. You want to assume that attacks will be coming at you via all possible means.

If the external vulnerability scan is designed to test your DDoS protection service, well ok but I'd also make sure to scan the public IP range as well. I'd also question the wisdom of running a vulnerability scan against a 3d party service, though there might be some mileage in this to confirm things like which TLS cipersuites are supported and so on.

To answer the question directly; I'd want an external vulnerability scan to hit all of my external attack surface. From what you've said it sounds like you're missing some external attack surface to me.

Answer 2

I'm going to explain the rationale of my answer in an agony aunt format, partially because it largely depends on the purpose of the vulnerability scanning. My answer is at the bottom.

Definitions:

• IPS / anti-DDOS - for the purposes of this question, I'm assuming this is a 3rd party service that proxies requests from the public to your underlying systems (e.g. CloudFlare or Incapsula). However, many of these concepts would apply to an IPS you had running on your own perimeter network. IPS = Intrusion Prevention System.

• Underlying systems - these are the systems that you actually own and control, assumed to be on your perimeter network.

I want to evaluate how effective my IPS or anti-DDOS service is at preventing vulnerability scans

What an odd request!? Well in this situation you should consider running your vulnerability scan through your IPS/anti-DDOS service. Your findings from such an exercise will tell you roughly what an attacker would see if they ran the same scan.

I want to evaluate how effective my IPS or anti-DDOS service is at preventing the exploitation of vulnerabilities on my underlying systems

Due to their very nature, a vulnerability scan is unlikely to help you with this. Vulnerability scans need to operate at a reasonable speed for efficiency (they typically have to check A LOT of vulnerabilities to be thorough), and IPS/anti-DDOS services are designed to stop network patterns that look like this (i.e. automated). They might not find many, but it doesn't mean that there are no vulnerabilities that could be exploited by a human.

You might want to consider having a penetration tester try to exploit known vulnerabilities. It makes sense to have a benchmark of vulnerabilities that you know exist on the underlying systems.

I want to detect vulnerabilities that might be present on my underlying systems

Firstly, this is a very good idea, because these are the systems that you actually own and control, and have some responsibility over with regards to security.

We've established that vulnerability scanning through a functioning anti-DDOS and/or IPS is a bad idea if this is your end goal. There's a good chance that the scanner will be blocked where a human attacker might succeed.

However, vulnerability scanning is still a very efficient way of detecting issues, so we don't want to throw it out. If you whitelist the scanner's IP address in the IPS / anti-DDOS service, it should be able to scan uninterrupted. Alternatively, you could allow direct access to this IP through the firewall (although the rules should mimic what users can see through the anti-DDOS system). You may want to consider only activating these rules at scheduled scan times.

Scanning from an internal perspective may be valid also. Ideally, you want assurance at multiple layers, and ideally one of these would be scanning through any network devices that do no interfere with the scanning, such as your perimeter firewall. This may not be possible without using the external IP address, at which point it may be no different from your external scan.

Bear in mind that it is possible some detected issues would have been mitigated by the anti-DDOS / IPS service. In this case, see the I want to evaluate how effective my IPS or anti-DDOS service is at preventing the exploitation of vulnerabilities on my underlying systems section.

A penetration tester might give you more scope for testing through an IPS / anti-DDOS, but it still might not be the most efficient method for them to identify vulnerabilities.

I want to make sure that my firewall really is blocking everything except for the anti-DDOS service

Run external port scans against your underlying systems, where the scanner does not have any special firewall exceptions. Vulnerability scans usually start off with port scans, so they should suffice.

If you do identify additional services that are Internet-facing, and they can't simply be filtered off (i.e. they are required) then there's no good reason why you shouldn't be subjecting them to vulnerability scans as well.

---

References

• SecureState / Is Your Scanning Vendor Cheating?
• Requirement 13 of PCI ASV Scanning Procedures
• Trustwave / How Should WAFs Handle Authorized Vulnerability Scanning Traffic? (Similar concepts, and IPS is referenced)

---

TL;DR

Vulnerability scanning isn't necessarily a good test of real world attacks, but it's still very useful to administrators. IPSs and anti-DDOS services may interfere with results, preventing detection where vulnerabilities can still be exploited by a human.

In terms of priorities, depending on the resources you have, here's what I'd focus on (in order):

1. Vulnerability scans of your own underlying network. Allow your vulnerability scanner the same access as the anti-DDOS service, or whitelist on the anti-DDOS service.

2. Determine how effective your IPS / anti-DDOS service is at mitigating any of the vulnerabilities discovered during priority 1. Best use a penetration tester. Alternatively, don't bother and just fix everything regardless.

Penetration testing is really outside the scope of this question, but since we've identified that vulnerability scanning isn't really a good way to simulate real attacks, I think it should be mentioned as an additional way to gain assurance. It can provide some of the realism that you might be trying to achieve by running scans through anti-DDOS.

Answer 3

There's trade-offs between the two approaches. If you have the resources, choose both approaches. If you have limited capabilities, my first choice would still be doing the scan through the anti DDOS provider.

Scanning through the anti-DDOS provider:

A security scanner is essentially a test, and test environments should be as similar as possible to the real world to be accurate.

Real world environments are complex and change without notice. If you were to do what you're describing you're assuming the special rule is always going to be applicable. What happens when the IP changes? What happens when you put an offsite site in? People put these changes in and don't just automatically think of all the disparate ways it can affect the rest of the system and what hard coded rules are in place somewhere.

Going through the normal rules that a visitor means that the external scanner sees things exactly the way everyone else does. If your DDOS provider has some strange vulnerability on their network, the scan will pick it up.

Putting in a special rule for the external scanner means traffic might be routed differently, or have some other oddness occurring because you put in an exception. It all sounds essentially equivalent until something you hadn't thought of comes up.

Scanning your IP directly will reveal things hidden by the anti-DDOS provider.

In real world operations, things happen. We all like to think that operations go like every other day, but extraordinary circumstances can change things drastically and suddenly and put you in a situation you didn't plan for.

Providers go down, providers change their rules without telling you, etc. You might suddenly need to eliminate the anti-DDOS provider because you suspect it's causing some problem. Then your test is suddenly invalid because the environment is different and you might suddenly realize you're vulnerable to something you didn't even know about. What now?

Ideally both scans should reveal the exact same thing. If so, great. If not, you may need to investigate further and find out why. If you have to choose one approach I'd recommend the first approach because it covers a far greater number of scenarios, and better simulates the "real world".

Answer 4

I cannot speak for business best practices, but with my personal server vulnerabilities, an external test is just that, external. The scanner is testing for problems possible from the outside, so a visitor's method of access sounds exactly right.