2

There is currently a debate in my office on the best location to place a vulnerability scanner (a distributed scanner - Rapid7 Nexpose, using scan engines) within a data center.

I see two options:

  • Place the virtual appliance in a secured VLAN, open ip any from the appliance to all IP addresses in the DC so we can ensure all UDP and TCP can be scanned.
  • Give the virtual appliance a virtual interface for each VLAN in the data center

I like the second option, as I do not have to traverse a firewall, as I know that firewalls can sometimes mess with vulnerability scanner. However, is there any reason why the first option would not work? Our network team is leaning towards it and I want to make sure that would be acceptable.

Edit: This scan is internal, only to production systems in our data center.

appsecguy
  • 435
  • 4
  • 12
  • I would recommend avoiding external scans and do authenticated scans instead. Then just allow SSH access from the server to your devices. I've used this scanner and a lot of the remote checks are quite inaccurate, or at least were a year ago or so. – theterribletrivium Oct 23 '14 at 02:26
  • To clarify - this is actually a scan only of internal systems within our production data center – appsecguy Oct 23 '14 at 15:12
  • Sorry, when I say external I should have said remote. If you use the remote checks you'll spend a lot of time chasing down false positives. The authenticated scans using SSH keys actually go onto the systems and scan with a user account. The results are more accurate and valuable in my opinion. – theterribletrivium Oct 23 '14 at 15:53

3 Answers3

1

The question is which "view" you want on the network from the vulnerability scanner's Point of view.

If you want to include the firewall security in your vulnerability assessment, you should Place the scanner with no access to internet, but on "WAN" side of security boundary in the firewall. Thus, your vulnerability scanner would then alert you if you accidentally misconfigure your firewall to expose a vulnerability on the internet. Thus, all your servers and firewall will simply consider your vulnerability scanner as something coming from the internet. Blocking internet access at all for the vulnerability scanner (in both directions) is important so not your vulnerability scanner gets hacked and taken over to perform vulnerability Scans on hosts not belongning to your network.

Another view is for example if you simply want a assessment that Everything is so securely setup that you can completely remove the firewall from the equation, then you put the vulnerability scanner on the inside, on the LAN side.

A third use of a vulnerability scanner is for example bridging it with a wireless access Point, so you get a view of the network as of the hacker would connect with a wireless client.

So theres no correct answer on your question. Depending on what you want to see, you should let the vulnerability scanner either traverse the firewall (without any exceptions) or the vulnerability scanner should have full access.

A vulnerability scanner is a measurement tool, and you Place it of course where you want to measure the security. If I want to know the outside temp, I put the termometer on the outside. If I want to know the inside temp, I put the termometer on the inside. Here the isolation in the wall could be the "firewall".

Same here with your vulnerability scanner. To put it short - Place it logically in your network exactly where you want to measure the security.

sebastian nielsen
  • 8,779
  • 1
  • 19
  • 33
1

Place the virtual appliance in a secured VLAN, open ip any from the appliance to all IP addresses in the DC so we can ensure all UDP and TCP can be scanned.

Give the virtual appliance a virtual interface for each VLAN in the data center

Maybe I am missing something. Both your suggestions have you placing this in some form of internal IP Space (not visible to some degree outside of your enterprise). Based on your comment (both mention being on a vlan), your best bet, is to just throw it into ANY VLAN won't matter, virtual interfaces would be a waste considering you could just trunk the port that scanner is on to all other VLANs.

Now Sebastian answered this in a manner that I'd of similarly answered it had you said: "Place it outside of my internal network" (outside of my normal IP space) I would have stated to place it INSIDE of your infrastructure. And there is a clear cut reason for this.

Internal placement - with credentialed scanning will give you the most bang for your buck, and most effective view of what is vulnerable. NOT placing it outside of your perimeter. For starters, most hackers aren't going to scan your infrastructure with Nessus, Nexpose, even say Metasploit, Core Impact, Canvas, etc.. MOST HACKERS meaning the well experienced one. These scans, exploit attempts are noisy, too time consuming, and the vast majority will be blocked by firewalls etc. Which means you too will have a limited view of what actually is vulnerable. Competent attackers are often going to use a client side attack (pdf file, USB key, word document, dropper(malware))

Internal assessments give you a concise view of what would be vulnerable if a hacker managed to get through your firewall (highly unlikely). The approach/thought process when doing this kind of assessment is as follows: Run your vuln scan: output = what an attacker can target. This is more realistic than what most companies are testing with say the PCI/DSS fiasco of running Qualys against an egress IP.

The next assessment would be a CREDENTIALED assessment. For these scans, I tune whatever tool to tell me: "alright I have user John Smith, who shouldn't have much access to things he doesn't need to see/know/touch... What could he do (or someone who stole his credentials)? Could he escalate locally, on any particular machine, and so forth.

I am a big fan of performing red team penetration tester under the premise that "I got past your door (firewall)... Now what?" This will give you better IMMEDIATE guidance on what to lock down, isolate, mitigate, issue corrective controls for.

Community
  • 1
munkeyoto
  • 8,682
  • 16
  • 31
  • Quick question regarding credentialed scanning. People are leery, rightfully so, about having a set of credentials with such broad access (even if we restrict to one set of AD credentials per domain, or one *nix account per location), it does mean that there will be an account that is very privileged floating around with access to many systems. – appsecguy Oct 23 '14 at 15:29
  • The solution to this is to have the account when in use set up to be used, then disabled (not removed). The credentials need to be minimal (not admin, defeats the purpose of determining whether someone can escalate). Further, a strong password, can protect against say a possible bruteforce/guess attempt: e.g. (u) johntest (p) $3Curity.T3$ter.2014 (then disable when not in use) – munkeyoto Oct 23 '14 at 15:55
  • No, I didnt say you should Place it outside of network. What I said is that you carfully consider the placement of the scanner depending on which info you want. If you decide that "the firewall is our main security, I dont care if theres lots of vulnerable services at the inside provided that the firewall/IPS eat up all these attacks", then you should Place the scanner outside, else the scanner gives false positives. But then, it can be as you say, the network must be secure "from the inside" too, and then its a good idea to have the vuln. scanner on the inside. – sebastian nielsen Oct 23 '14 at 16:30
  • A great idea could be also, if the vulnerability scanner can do the same scan on different networks, then you could put one probe outside your firewall on the WAN side, one probe inside your network, and one probe for example on the wireless section, and one probe in DMZ. Then you will get very good data where you can compare the reports side-by-side and see exactly where a vulnerability appears and if the vulnerability is being blocked by firewall or not and so on. – sebastian nielsen Oct 23 '14 at 16:33
1

I vote for option # 1, and I have first hand experience with this.

I'm seeing a lot of misinformation and/or bad advice in some of these comments and answers.

The scanner should:

  • have admin level access to the assets.
  • have access to assets on all ports/protocols.
  • be whitelisted on IPS/IDS sensors and other security devices.

The main purpose of a vulnerability scanner is to find the vulnerability at the source so you can fix it before an attacker can find it and exploit it.

If you're not granting the scanner admin level access to your assets and you're allowing an IPS to interfere then you're doing yourself a disservice.

k1DBLITZ
  • 3,933
  • 14
  • 20