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:
- Re: Isolating internal servers behind firewalls, (continued)
- Re: Isolating internal servers behind firewalls ArkanoiD (Sep 10)
- Re: Isolating internal servers behind firewalls Marcus J. Ranum (Sep 10)
- Re: Isolating internal servers behind firewalls dlang (Sep 10)
- Re: Isolating internal servers behind firewalls L Cubed (Sep 10)
- Re: Isolating internal servers behind firewalls ArkanoiD (Sep 10)
- Re: Isolating internal servers behind firewalls Bill Royds (Sep 10)
- Re: Isolating internal servers behind firewalls Marcin Antkiewicz (Sep 10)
- Re: Isolating internal servers behind firewalls jason (Sep 10)
- Re: Isolating internal servers behind firewalls K K (Sep 10)
- Re: Isolating internal servers behind firewalls sai (Sep 10)
- Re: Isolating internal servers behind firewalls Timothy Shea (Sep 10)
- Re: Isolating internal servers behind firewalls D Sharp (Sep 11)
- Re: Isolating internal servers behind firewalls Behm, Jeffrey L. (Sep 12)
- Re: Isolating internal servers behind firewalls D Sharp (Sep 13)
- Issue with replacing SonicWall VPN with Cisco ASA VPN devices Behm, Jeffrey L. (Sep 25)
- Re: Issue with replacing SonicWall VPN with Cisco ASA VPN devices Brett Cunningham (Sep 26)
- Re: Issue with replacing SonicWall VPN with Cisco ASA VPN devices Michael Cox (Sep 26)
- Re: Issue with replacing SonicWall VPN with Cisco ASA VPN devices Robby Cauwerts (Sep 26)
- Re: Issue with replacing SonicWall VPN with Cisco ASA VPN devices Michael Cox (Sep 26)
- Re: Issue with replacing SonicWall VPN with Cisco ASA VPNdevices Behm, Jeffrey L. (Sep 26)
- Re: Issue with replacing SonicWall VPN with Cisco ASA VPN devices Brett Cunningham (Sep 26)
- Re: Issue with replacing SonicWall VPN with Cisco ASA VPN devices Joe S (Sep 26)
- Re: Isolating internal servers behind firewalls Behm, Jeffrey L. (Sep 12)