re: switch recommendations

On Sat, 27 Aug 2005, [iso-8859-1] dhull wrote:

> I'm with you on this. OpenBSD rules!
>
> I should mention that I don't know much about VLAN's. Having said that I still stand by my previous statement. "Most networks don't need them."

And I stand by mine, most of this size or greater *should* be using them.

> It may add a layer of security but it's also one more thing you have to manage. A simple DMZ solution is 2 OpenBSD firewalls with a DMZ in the middle.

Huh? At no point did anyone say that VLANs were a substitute for firewalls --
they're not. They're simply a way to segment and manage traffic with less
hardware, and they can make managing security easier.

> INET<----->[Firewall #1]<----->[SWITCH]<----->[Firewall #2]<----->[LAN]
> |
> |
> |
> [DMZ]
>
> For me it comes down to two things. How much security will it give me? How much management do I have to do to get that security?

I'm going to assume that you meant the DMZ to plug into the switch, not
downstream of firewall #2, which is how it's showing up on my reader.

> In this case were talking about a 48 port switch. Lets say we have 40 workstations. That leaves us with a few extra ports for servers etc... Lets say they have one file server that they all have access to. No amount of VLAN's is going to prevent someone on the inside from hacking the server and accessing data they shouldn't have access to.

Yes and no. You're assuming a *very* simplistic network topology, and one
that wouldn't fly in most enterprises with significant data assets. If
someone has access to a server and hacks it, yes, you can assume everything on
that server is compromised. That's common sense. But what if different
departments have their own servers? Restricting access by network topology
reduces your level of exposure, and therefore, your level of risk (does
shipping really need access to accounting's data?). How about removing
privileged services from client-side exposure altogether by putting
them on a private backbone (whether it be database traffic, net backups, etc.,
or even console access to the servers).

> This is just my take on VLAN's. If someone can give me a reason for using VLAN's on a network with 40 workstations let me know. Again, I don't no a lot about VLAN's.

Simple: VLANs provide performance/traffic management by isolating broadcast
domains. Isolating broadcast domains also provide security by preventing
information leakage from broadcast traffic. Isolating broadcast domains
requires a non-flat network topology, and that requires either more hardware
or VLANS. That's four reasons: performance, security, and financial, and
administration.

As you couple traffic between VLANs (such as bridging the traffic between the
internal LAN & the Internet, the DMZ, whatever) it *should* go through a
firewall, only instead of having to manage *two* switches (as in your example
above) there's only one physical switch to manage. It also allows you to
isolate your backend servers from public exposure (by using a VLAN as a
private backbone to handle traffic between, say, a frontend application server
on the DMZ and a database server it pulls data from).

Real security is much, much more than just simple firewalls between networks,
it's also about network topology (and about fifty other things). VLANs are
one way to accomplish this more cost effectively since it demands less
physical hardware and less points to manage.

As others have pointed out, this does require a *good* implementation of
VLANs. But, with a good implementation it can be an invaluable aid,
especially for those on a budget.

        --Arthur Corliss
          Bolverk's Lair -- http://arthur.corlissfamily.org/
          Digital Mages -- http://www.digitalmages.com/
          "Live Free or Die, the Only Way to Live" -- NH State Motto
---------
To unsubscribe, send email to <aklug-request@aklug.org>
with 'unsubscribe' in the message body.
Received on Sat Aug 27 23:54:04 2005