Re: Worms, Air Gaps and Responsibility

[Chris Pugrud <chris () pugrud net>]

I've been doing a lot of research over the last several months about how to
isolate desktop and laptop systems from servers using switches and the firewall
filtering capabilities of VLAN routers (layer 3 switches).  I'm working that
research into publishable form, but I can answer more specifically to what you
are suggesting and hopefully get some feedback from the community at the same
time.

Cisco offers "Private VLAN" capabilities in their layer 2 switches.  Within a
VLAN you can designate ports as private or public.  Private ports are fully
isolated from all other private ports in the VLAN.  Private ports can only talk
to public ports and vice versa.  If the only public port is the router for the
VLAN, the effect is that every system in the VLAN has effectively been assigned
to an individual, personal VLAN.  Filtering rules applied to that VLAN affect
all the systems equally.  This is much easier to manage and deploy than other
methods that suggest placing every system in it's own subnet and VLAN.

It has often been observed that client systems, desktops and laptops, only need
to talk to servers and never to each other, in most environments, as you
mentioned.

If all of the client systems are isolated in private VLANs, and the VLANs are
isolated from each other with filtering rules at the VLAN router, the only
systems that clients can talk to are the servers and external gateways.  This
effectively reduces the primary security perimeter to the servers.  If the
servers are well protected and current in their AV signatures, the organization
is fairly well protected from viruses.  There is still a huge vulnerability if
one of the servers should become infected.  Because the servers can talk to all
of the clients, if a server becomes infected, go back to square one.

Ideally an IDS would detect the virus attack, notify the administrators, and,
possibly, shut down the port that is the source of the attack (I won't start up
the automated defenses thread again).  On a secondary level this also stops the
curious insider from browsing the HR desktop file share and publishing the
internal salary list.

Many years ago I used to be very active on this list (chrisp () steldyn com), and
I am very glad to see that the list has retained it's technical focus and
professional expertise.

chris
---
Chris Pugrud
chris () pugrud net

--- Rogan Dawes <discard () dawes za net> wrote:
> I agree that it is a good idea to separate user networks from server 
> networks (in the general case) and user networks from production 
> networks specifically. In most cases, I think that air gaps are a bit of 
> overkill. Using a firewall and defined interfaces that can be adequately 
> secured (e.g. by not using MS file sharing :-) is sufficient in many cases.
>
> On a related note, I've been thinking quite a lot about having switches 
> perform firewall tasks. I see no reason why it should not be possible to 
> classify ports into groups such as "server" and "desktop" (at a 
> minimum), and apply appropriate filtering rules between the groups.
>
> e.g. desktops may only talk to servers, not to each other.
> As a benefit, it would even prevent attacks against the local segment, 
> as well as the rest of the network.
>
> Thoughts?
>
> I realise that this could end up causing a lot of work for network 
> admins (analogous to locking MAC addresses to ports, perhaps), but with 
> the right tools, it should be manageable.
>
> Rogan

_______________________________________________
firewall-wizards mailing list
firewall-wizards () honor icsalabs com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards