Re: VLAN's & DMZ's

From: Michael Pelletier (mjpelletier_at_mjpelletier.com)
Date: 04/06/05 

Date: Tue, 05 Apr 2005 22:41:01 -0700

Steve Clark [MSFT] wrote:

> VLANS are *not* security constructs: they are management constructs.
> Somewhere about 1996 people saw that they could put ACL's on them and thus
> they started treating them as if they were security boundaries.
>
> Ettercap renders all that rot practically meaningless.
>
> However, it is considered to be best practice to implement VLANS of the
> same
> security posture on the same switch. i.e., you don't have a highly secure
> VLAN and a less secure VLAN on the same switch, because the lowest common
> denominator is the security posture on that device. (in this case, less
> secure)
>
> Also, physical isolation implies that there will be no communications
> between the two conencted networks/devices. The US does this for DoD
> networks by having a separate, highly secure classified network (SIPRNET)
> and an internet connected (and therefore vulnerable) network called
> NIPRNET. These networks are physically separated.

Yes, this is true. Also the DOE and Air Force segment by security
levels...not that I would know or anything ;-)

> If you want the maximum amount of logical isolation, use packet filters on
> the network edge, along with layer 7 aware firewalls. Use IPsec transport
> mode to protect hosts on the inside and use L2TP/IPsec for VPN
> connectivity.
>
> That's about as strong of a DiD approach on a network as current
> technology
> provides. Beyond this, you start talking about extreme physical security,
> and other methods...

There is more but, for what he is doing probably overkill...

>
>
>
> "roberto" <no_trash@respond-to-group-not-me.com> wrote in message
> news:CSA4e.3352$Nn.2163@tornado.rdc-kc.rr.com...
>>I understand that it is considered a less than 'best practice' to use a
>>few ports in a VLAN-able switch matrix to "logically" isolate a DMZ from
>>the
>>private network. The better practice is to "physically" isolate the DMZ
>>by putting it on a completely separate piece of switch hardware not
>>related to
>>the VLAN-able devices. I've reviewed some white papers but none have been
>>terribly specific about this. There is a comment recommending the better
>>practice in my GSEC study material but no references beyond a year 2000
>>document alluding to VLAN Hopping. Can any of you point me to a good
>>source or two that document good rationale for the better practice? It
>>looks and sounds perfectly logical to me - but that may not be forceful
>>enough in this work environment.
>>
>> Thanks.
>>
>> roberto
>>

Michael 

-- 
"Microsoft isn't evil, they just make really crappy operating systems." -
Linus Torvald

Relevant Pages

  • RE: network security, network in general PODcast?
    ... Cause I'm not a security expert neither and I can argu with him on the Call for help show sometime. ... Objet : Re: network security, network in general PODcast? ... practice to master. ... SensePost willl be at Black Hat Vegas in July. ...
    (Security-Basics)
  • Re: VLANs & DMZs
    ... VLANS are *not* security constructs: ... it is considered to be best practice to implement VLANS of the same ... VLAN and a less secure VLAN on the same switch, ... and an internet connected network called NIPRNET. ...
    (comp.security.misc)
  • Re: VLANs & DMZs
    ... VLANS are *not* security constructs: ... it is considered to be best practice to implement VLANS of the same ... VLAN and a less secure VLAN on the same switch, ... and an internet connected network called NIPRNET. ...
    (comp.security.firewalls)
  • Re: VLANs & DMZs
    ... VLANS are *not* security constructs: ... it is considered to be best practice to implement VLANS of the same ... VLAN and a less secure VLAN on the same switch, ... and an internet connected network called NIPRNET. ...
    (microsoft.public.win2000.security)
  • Re: VLANs & DMZs
    ... > they started treating them as if they were security boundaries. ... it is considered to be best practice to implement VLANS of the ... > networks by having a separate, highly secure classified network ...
    (microsoft.public.win2000.security)