Network Segmentation Approaches

Tue May 5 13:58:04 UTC 2015

I'd certainly forget anything with "service provider" in the name.
Different problem, different architecture.

Last time I built this, I built a core network (WAN links, routers, etc)
that enforced anti-spoofing rules, so I knew if I saw an "internal" IP
address (either public assigned to me or RFC1918) on a given device inside
this "core", it came from the network segment it claimed to have come from.

Then I built building-specific firewalls using proper firewalls.  These
might have anywhere from two interfaces (branch office) to thousands of
interfaces (datacenters) with lots of VLANs.  Checkpoint is a good product
for this.  The firewalls' job was to protect the building/segments behind
it, not to protect things "upstream" (towards the core) of it.  There was
obviously an edge firewall.

Users were segmented by job role.  Workstations were typically considered
to be *MORE* secure from a network perspective.  AD servers need to be
contacted by everything in your Windows domain. Most workstations don't.
And your Windows domain, nowadays, probably includes cloud services over
the internet.  So it's hard to say AD servers are "secure" from a purely
"how many open network ports are there?" standpoint.  Servers were likewise
segmented.  I'd consider putting department file servers on the same LAN as
the users, but only if performance required it - otherwise I'd put them on
their own segments too.

The benefit of this in a large organization is that a subdivision could put
a firewall behind one of my anti-spoofing interfaces (so I validate packets
come from them) and run it themselves without ruining everyone else's
security.

I second the thoughts about embedded management stacks.

As for management, I put workstations used by IT management on their own
segment (and give them a "Stand up the infected workstation you're working
on" LAN separate from that segment).  I put servers used for management on
yet another segment.  I've never had a problem with giving those
workstations and servers access to management segments in the wild, but I
trusted my skilled admins I worked with.

Think mesh of connections, not "tiers" or levels or DMZs.  Because you'll
find that super-secure accounting server needs access from some random
vendor across the internet, and stuff like that, such that everything
eventually ends up in the DMZ anyhow (except MAYBE workstations).

You can use separate firewalls for particularly sensitive segments - for
instance, your management stuff might not be behind your main firewall -
that way when Joe User gets a virus and fills the connection table on his
firewall(s), you can still manage things.

One more thing: Guest network access.  When it was needed, I built a
virtual network on top of the "real" Corporate LAN that tunneled this
around.  I terminated it on a DSL modem (which was sufficient for my
needs).  Just about every building with a conference room these days will
need a guest network. It also helps if your employees can use their cell
phones for checking work email and such - do you really want them on your
main LAN?

On Tue, May 5, 2015 at 7:01 AM, Keith Medcalf <kmedcalf at dessus.com> wrote:

>
> It is called the Purdue Enterprise Reference Architecture ...
>
> > -----Original Message-----
> > From: NANOG [mailto:nanog-bounces at nanog.org] On Behalf Of
> > nanog1 at roadrunner.com
> > Sent: Monday, 4 May, 2015 20:56
> > To: nanog at nanog.org
> > Subject: Network Segmentation Approaches
> >
> > Possibly a bit off-topic, but curious how all of you out there segment
> > your networks.  Corporate/business users, dependent services, etc. from
> > critical data and/or processes with remote locations thrown in the mix
> > which could be mini-versions of your primary network.
> >
> > There's quite a bit of literature out there on this, so have been
> > considering an approach with zones based on the types of data or
> > processes within them.  General thoughts:
> >
> > - "Business Zone" - This would be where workstations live,
> >   web browsing occurs, VoIP and authentication services live too.
> >   Probably consider this a somewhat "dirty" zone, but I should
> >   generally be OK letting anything in this zone talk fairly unfettered
> >   to anything else in this zone (for example a business network at my
> >   HQ location should be able to talk unfettered to an equivalent
> >   network at a remote site).
> >
> >   I'd probably have VoIP media servers in this zone, AD, DNS, etc.
> >
> > - Some sort of management zone(z) - Maybe accessible only via jump host
> >   -- this zone gives "control" access into key resources (most likely
> >   IT resouces like network devices, storage devices, etc.).  Should
> >   have sound logging/auditing here to establish access patterns outsid
> >   the norm and perhaps multi-factor authentication (and of course
> >   FW's).
> >
> > - Secure Zone(s) - Important data sets or services can be isolated from
> >   untrusted zones here.  May need separate services (DNS, AD, etc.)
> >
> > - I should think carefully about where I stick stateful FW's --
> >   especially on my internal networks.  Risk of DoS'ing myself is high.
> >
> > Presumably I should never allow *outbound* connectivity from a more
> > secure zone to a less secure zone, and inbound connectivity should be
> > carefully monitored for unusual access patterns.
> >
> > Perhaps some of you have some fairly simple rules of thumb that could
> > be built off of?  I'm especially interested to hear how VoIP/RTP
> > traffic is handled between subnets/remote sites within a "Business
> > Zone".  I'm loathe to put a FW between these segments as it will
> > put VoIP performance at risk (maybe QoS on FW's can be pretty good),
> > but maybe some sort of passive monitoring would make sense.
> >
> > (Yes, I've also read the famous thread on stateful firewalls[1]).
> >
> > Thanks!
> >
> > [1]
> >
> http://markmail.org/thread/fvordsbnuc74fuu2#query:+page:1+mid:fvordsbnuc74
> > fuu2+state:results
>
>
>
>