Firewall Wizards mailing list archives

Re: Isolating internal servers behind firewalls


From: D Sharp <drsharp () pacbell net>
Date: Tue, 11 Sep 2007 10:11:52 -0700

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 
changes.

Summary:

    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 
above?

Yours,
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 () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards

 


_______________________________________________
firewall-wizards mailing list
firewall-wizards () listserv icsalabs com
https://listserv.icsalabs.com/mailman/listinfo/firewall-wizards


Current thread: