Re: [fw-wiz] Isolating internal servers behind firewalls

Dan Lynch wrote:

Greetings list,

I'm looking for opinions on internal enterprise network firewalling. Our
environment is almost exclusively Microsoft Active Directory-based.
There are general purpose file servers, AD domain controllers, SMS
servers, Exchange servers, and MS-SQL-based datase app servers. In all
about 80+ servers for over 2500 users on about 2000 client machines, all
running Windows XP.

Currently we are pushing 4500 desktops and 350+ servers. In house
developers and offshore.
Just a few UNIX servers.

How prevalent is it to segregate internal use servers away from internal
clients behind firewalls? What benefits might we gain from the practice?
What threats are we protected from?

My perspective, yes have done this and wil continue to.
The benefits should be aligned or justified by known risks. Thus you
should have the support of your risk group/IT auditors.
The threats you are protected from have more to do with how you
implement the filters to achieve the risk reduction.

MS Windows and other vendors have made this extermely difficult. Its not
just port 139 or 445. Its Oracle OEM with poor port documentation, or
VMware with its vague port documentation.

Don't know if this will ever happen again, but the Symantec port attack
provides some insight:
Hit by a single corporate laptop from remote (the AV was not up to
date) which infected all the non network filtered servers and many desktops.
The only non-infected Windows servers left, were those in
non-production behind a firewall, where we only allowed them to pull
their AV updates, no pushes. And no file shares to production.
In the cleanup, the Windows group identified the blocking of push
capability as a hinderance to their speed to recovery. They felt that
they would have to spend to much time using remote desktop into the each
server to trigger the AV updates and verifying the updates. But then
the AV software does support scheduled pulls for AV updates.

Maybe your company needs the meltdown of its Windows infrastucture to
help your argument.
But be sure you can capture the likely root cause, otherwise you will
likely face the "you can't prove that implementing LAN segmentation
would prevent anything".

On the other hand, the server team counters that

- troubleshooting problems becomes more difficult

I found this comes down to, we need help debugging possible server
problems, but don't want to ask others for help.

- firewall restrictions on which workstations can perform administration
makes general maintenance inconvenient, esp. in an emergency

This can be identified and made part of the DR recovery.
Or this is really that you have not assisted them with defining where
administration can be performed and or how it can be identified/tracked.

- the threats we're countering are exceedingly rare

I guess this is the "Black Swan" issue. Its difficult for me (server
admins) to quantify, so just accept the risk.
But then the server admins are not the "Risk" group, nor are they the
likely 'data owners'.

- a broken (or hacked) firewall config breaks all access to servers if
consolidated behind firewalls

I am having to deal with the following at present:
a: Filters slow the deployment process of servers on the network.
IE. we now have VMware and can deploy in hours, yet filters take days to
develope. Windows group wants 'all standard' Windows ports opened across
enterprise to provide them with agility/speed.
b: Windows group has deployed a chassis mangement server. But wants
to use that mangement software to manage all printers, and query network
devices. So they would like all 'standard' ports opened throughout the
enterprise, so that new devices under management do not require firewall


Can segmenting/filtering network level provide a greater level of
risk reduction?

It depends.
If you don't have a written policy on restricting access to
what is needed, then you have not justified to the company this is needed.
If you don't get buy in from managment level above server
adminstration, then its just a inter-departmental argument or agreement.
If you don't review every port request for risk, and deny
those that are risky, then you are just tracking the traffic good/bad.
Do you intend to expend the resources it takes to ensure the

Duncan Sharp

Any and all thoughts are appreciated.

Dan Lynch, CISSP
Information Technology Analyst
County of Placer
Auburn, CA
firewall-wizards mailing list

firewall-wizards mailing list