Network Segmentation Approaches

Mailman List Mirror (Read Only)
1

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:fvordsbnuc74fuu2+state:results

2

I break them up by function and (when necessary) by the topology
enforced by geography. The first rule in every firewall is of
course "deny all" and subsequent rulesets permit only the traffic
that is necessary. Determing what's necessary is done via a number
of tools: tcpdump, ntop, argus, nmap, etc. When possible, rate-limiting
is imposed based on a multiplier of observed maxima. Performance
tuning is done after functionality and is usually pretty limited:
modern efficient firewalls (e.g., pf/OpenBSD) can shovel a lot of
traffic even on modest hardware.

---rsk

3

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:

It depends on the users and tasks on the network.. Different
segmentation strategies / tradeoffs get selected by people dependent
upon what there is to be protected, Or where needed to control
broadcast domain size, and value tradeoffs.

Segmenting certain systems, or segmenting certain data, Or more
likely both are called for to mitigate selected risks: both
security risks, as well as network risks, Or to facilitate certain
networks being moved independently to maintain continuity after DR.

- "Business Zone" - This would be where workstations live,
but I should [....]
  generally be OK letting anything in this zone talk fairly unfettered
  to anything else in this zone

Since you imply all workstations would live on the same zone as each
other, instead of being isolated or placed into job-role-specific
access segments, then what you have here is a non-segmented network;
that is:

It sounds like this begins to look like your generic "non-segmented"
zone "with small numbers of exceptions" strategy; you wind up with a
few huge business zones which tend to become larger and larger over
time -- are really still at highest risk, then a small number of tiny
exception zones such as 'PCI Card Environment' zone, which are okay,
until some users inevitably develop a requirement to connect
workstations from the massive insecure zone to the tiny zone.

Workstations talking to other workstations directly is an example of
one of the higher risk things, that is probably not necessary, but
remains unrestricted by having one single large 'Business' segment.

A stronger segmentation model would be that workstations don't get to
talk to other workstations directly; only to remote devices servicing
data that the user of a given workstation is authorized to be using,
with every flow being validated by a security device.

  I'd probably have VoIP media servers in this zone, AD, DNS, etc.

AD + DNS are definitely applications that should be at a high
integrity protection level compared to generic segment from security
standpoint; Especially if higher-security zones are dependent on
those services.

An AD group policy configuration change can cause arbitrary code
execution on a domain-joined server in any segment attached to a
domain using that AD server.

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.

Never? No internet access?
Never say never, but there should be policies established based on
needs / requirements and dependent on the characteristics of a zone
and the assumed risk level of other zones.

An example for some high risk zone might be that outbound connections
to A, B, and C only through a designated application-layer proxy
itself residing in a security service zone.

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),

The ideal scenario is to have segments dedicated to primary VoIP use,
so VoIP traffic should stay in-segment, except if interconnecting to
a provider, and the firewalls do not necessarily have to be stateful
firewalls; if VoIP traffic leaves a segment, some may use a simple
packet filter or application-aware proxy designed to maintain the
performance.

If the security requirements of the org implementing the network are
met, then very specific firewall devices can be used for certain
zones that are the most suitable for that zone's traffic.

4

Add "management zone" or "infrastructure zone":

Consider setting up a separate zone or zones (via VLAN) for devices with embedded TCP/IP stacks. I have worked in several shops using switched power units from APC, SynAccess, and TrippLite, and find that the TCP/IP stacks in those units are a bit fragile when confronted with a lot of traffic, even when the traffic is not addressed to the embedded devices.

Separately, an ISP discovered that a consumer-grade NAS has the same problem.

These should be on a separate subnet anyway, with unfettered access from the outside disallowed at the edge. To access the infrastructure equipment, you would use VPN to bypass your edge router access lists. If you have a lot of inside equipment not under your direct control, consider locking them out of the infrastructure subnet, too.

Needless to day, watch the load you direct at these embedded devices. My current day job installed Solar Winds to monitor everything. The probes from the software knocked out the SNMP access to all too many of the PDU devices on the network.

5

It is called the Purdue Enterprise Reference Architecture ...

6

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?

7

> Possibly a bit off-topic, but curious how all of you out there segment
> your networks. [snip]

I break them up by function and (when necessary) by the topology
enforced by geography. The first rule in every firewall is of
course "deny all" and subsequent rulesets permit only the traffic
that is necessary.

The first rule of every firewall should be to enforce BCP 38 out bound.

Deny all really isn't needed with modern machines but that is a matter of
policy.

8

The firewalls I've worked with don't log denies if they are due to an implicit deny-all at the end of the policy. I always put one in at the end to make sure that the attempt is logged.

Gene

9

Consider setting up a separate zone or zones (via VLAN) for devices
with embedded TCP/IP stacks. I have worked in several shops using
switched power units from APC, SynAccess, and TrippLite, and find that
the TCP/IP stacks in those units are a bit fragile when confronted
with a lot of traffic, even when the traffic is not addressed to the
embedded devices.

Yes! This.

I used to have my PDUs/term serves/switches all on one VLAN. As growth occurred, they get broken out to dedicated VLANs. With that, the amount of false positives from Zenoss went way down (frequently port 80 would report down, then clear). I still get some alerts, but far less frequently.

10

this is really a form of: "A subnet should contain all things of a
like purpose/use."

that way you don't have to compromise and say: "Well... tcp/443 is OK
for ABC units but deadly for XYZ ones! block to the 6 of 12 XYZ and
permit to all ABC... wait, can you bounce off an ABC and still kill an
XYZ? crap... pwned."

segregation by function/purpose... best bet you can get.