Mailing List Archive

how to properly handle HTTP Virtual hosts
Hi there

We just did a vulnerability scan of a new Internet Web farm we have -
and I did it by scanning a range of Internet IPs - as that was all the
info I had.

Anyway, it didn't find anything of interest - and part of the reason for
that was that these hosts had the "real" Web apps on non-default
Virtualhosts - so scanning the IP lead to default IIS and Apache
webpages instead of the actual apps.

Totally understandable - but it brings up a real issue for us. All our
Nessus servers are on the internal network - and use internal DNS
servers. Our internal DNS is configured to return their *internal* IP
addresses for these hosts - not their Internet IPs (ie NAT is involved).
So if we replace the IP addresses to be scanned with hostnames, we'll
get an internal scan instead of an Internet-scan - which will return
details I'm not interested in.

What we really need to do is to be able to tell nessusd to use a
different set of DNS servers (ie external ones) for some scans and not
for others. A new nessusrc config option sounds in order? :-)

Anyone else have other ideas about how to get around this? Putting
nessusd directly on the Internet isn't an option. These servers have too
much internal work to do to move them around in such fundamental ways.
Even editing /etc/resolv.conf before the scan isn't that doable - other
internal scans could be running at the same time...

--
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

_______________________________________________
Nessus mailing list
Nessus@list.nessus.org
http://mail.nessus.org/mailman/listinfo/nessus
Re: how to properly handle HTTP Virtual hosts [ In reply to ]
wish i could be more help, but when we run into situations like this, we put
a scanner outside of our network and work from that angle. Normally, we keep
a license floating so that we can put it on a fully patched box, put it out
there, scan, then take it down.

I would probably just get another scanner box and point it's
/etc/resolv.conf at the dns servers you want and work from that angle if you
needed it run pretty regularly.

On Tue, Dec 2, 2008 at 12:32 AM, Jason Haar <Jason.Haar@trimble.co.nz>wrote:

> Hi there
>
> We just did a vulnerability scan of a new Internet Web farm we have -
> and I did it by scanning a range of Internet IPs - as that was all the
> info I had.
>
> Anyway, it didn't find anything of interest - and part of the reason for
> that was that these hosts had the "real" Web apps on non-default
> Virtualhosts - so scanning the IP lead to default IIS and Apache
> webpages instead of the actual apps.
>
> Totally understandable - but it brings up a real issue for us. All our
> Nessus servers are on the internal network - and use internal DNS
> servers. Our internal DNS is configured to return their *internal* IP
> addresses for these hosts - not their Internet IPs (ie NAT is involved).
> So if we replace the IP addresses to be scanned with hostnames, we'll
> get an internal scan instead of an Internet-scan - which will return
> details I'm not interested in.
>
> What we really need to do is to be able to tell nessusd to use a
> different set of DNS servers (ie external ones) for some scans and not
> for others. A new nessusrc config option sounds in order? :-)
>
> Anyone else have other ideas about how to get around this? Putting
> nessusd directly on the Internet isn't an option. These servers have too
> much internal work to do to move them around in such fundamental ways.
> Even editing /etc/resolv.conf before the scan isn't that doable - other
> internal scans could be running at the same time...
>
> --
> Cheers
>
> Jason Haar
> Information Security Manager, Trimble Navigation Ltd.
> Phone: +64 3 9635 377 Fax: +64 3 9635 417
> PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
>
> _______________________________________________
> Nessus mailing list
> Nessus@list.nessus.org
> http://mail.nessus.org/mailman/listinfo/nessus
>



--
Doug Nordwall
Unix, Network, and Security Administrator
You mean the vision is subject to low subscription rates?!!? - Scott Stone,
on MMORPGs
Re: how to properly handle HTTP Virtual hosts [ In reply to ]
What about using /etc/hosts? I've done this is different situations where I
wanted to test a new website prior to it going into production, but it
wasn't live in DNS yet. If I didn't use /etc/hosts all the links would have
pointed to the current production server and the test results would be all
mangled together.

Hope that helps.
Steve

On Tue, Dec 2, 2008 at 3:32 AM, Jason Haar <Jason.Haar@trimble.co.nz> wrote:

> Hi there
>
> We just did a vulnerability scan of a new Internet Web farm we have -
> and I did it by scanning a range of Internet IPs - as that was all the
> info I had.
>
> Anyway, it didn't find anything of interest - and part of the reason for
> that was that these hosts had the "real" Web apps on non-default
> Virtualhosts - so scanning the IP lead to default IIS and Apache
> webpages instead of the actual apps.
>
> Totally understandable - but it brings up a real issue for us. All our
> Nessus servers are on the internal network - and use internal DNS
> servers. Our internal DNS is configured to return their *internal* IP
> addresses for these hosts - not their Internet IPs (ie NAT is involved).
> So if we replace the IP addresses to be scanned with hostnames, we'll
> get an internal scan instead of an Internet-scan - which will return
> details I'm not interested in.
>
> What we really need to do is to be able to tell nessusd to use a
> different set of DNS servers (ie external ones) for some scans and not
> for others. A new nessusrc config option sounds in order? :-)
>
> Anyone else have other ideas about how to get around this? Putting
> nessusd directly on the Internet isn't an option. These servers have too
> much internal work to do to move them around in such fundamental ways.
> Even editing /etc/resolv.conf before the scan isn't that doable - other
> internal scans could be running at the same time...
>
> --
> Cheers
>
> Jason Haar
> Information Security Manager, Trimble Navigation Ltd.
> Phone: +64 3 9635 377 Fax: +64 3 9635 417
> PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1
>
> _______________________________________________
> Nessus mailing list
> Nessus@list.nessus.org
> http://mail.nessus.org/mailman/listinfo/nessus
>