Re: Vulnerability Assessment of VLAN

[Christophe Vandeplas <christophe () vandeplas com>]

On Thu, Jan 13, 2011 at 6:12 PM, Curt Purdy <infosysec () gmail com> wrote:
> Cannot answer #1, but would be interested if there is anything
> analogous to dsniff on a switched network for VLANs.

To answer #1: The current state of static-VLANs is that you can trust
it's separation to "almost physical". The only risk is human error,
and firmware bugs of the switch of course.

However many corporations use i) dynamic configuration of VLANs (with
Cisco phones for example) or ii) simply configure access-ports
(connected to a computer) using a trunk with the default VLAN being
the lan and a tagged vlan being a VoIP network. Any computer sending
either the right CDP handshake for (i) or configure their computer to
read out the tagged vlan for (ii) can access whatever he wants. So
this must never be considered as a "secure separation", more a
"functional separation".


> As for #2, the type and brand of firewall makes a lot of difference,

I don't really agree, the methodology should be the same.
You should really read the "Guidelines on Firewalls and Firewall
Policy" (NIST 800-41).
link: http://csrc.nist.gov/publications/nistpubs/800-41-Rev1/sp800-41-rev1.pdf

> If you are talking about auditing and not pen-testing, look for old,
> no longer used ACLs. Of the hundreds of lines, many are useless, and
> may do more harm than good. I have seen holes intentionally stuck in
> the middle of lists that no one ever saw because it was a rat's nest.

A good start is to first enumerate the functional flows, these will be
the base of your audit.

Then check out the visibility of the different vectors (outside ->
inside/dmz, inside-> outside) and map it to what should be open.

And last but not least, and together with the functional enumeration
usually the most time consuming, reading out what has been configured
in the rulebase of the firewall.
The most common mistakes I have seen are objects in objects (in
objects in objects), sometimes resulting in an "allow any to any".
What is also important is the readability of the rulebase. A rulebase
that is not readable is also a risk as an admin doesn't know what is
or isn't allowed. Things that help readability are consolidation using
objects (like web-servers containing all the IPs of the webservers in
the DMZ), but also grouping/section-titles.

If you're into auditing also make sure you read the latest version of
the OSSTMM (http://www.isecom.org/osstmm/)
Pete (and ISECOM) took a hell of a time to write/release the document,
but it's a very good methodology for any auditor.

Hope this helps.

Christophe

------------------------------------------------------------------------
This list is sponsored by: Information Assurance Certification Review Board

Prove to peers and potential employers without a doubt that you can actually do a proper penetration test. IACRB CPT 
and CEPT certs require a full practical examination in order to become certified. 

http://www.iacertification.org
------------------------------------------------------------------------