Internal network segmentation using firewalling

[ggarlington]

Recently an external auditor suggested we should segment the internal network including all enterprise applications, desktop population, internal e-mail, remote access, and the wan using firewalls. Is anyone doing this? If so why?

[paddyxdoyle]

Personally i think this would be difficult to achieve and in the end not worth it.

The main issues arise when clients need to talk to Exchange and other Microsoft Servers.

In a nutshell, the PC communicates with the server on tcp 135, the server then tells the PC which ports it wants the PC to use from then on which can be any port above >1023. Most firewalls will see this as a new connection and drop it as its not part of the original connection thus breaking your original connection.

I think the PIX can deal with this and perhaps checkpoint but with the PIX only if the Server is on the outside interface (plz correct me if this has changed)

The same issues arise with server to server replication so without major planning, or changes to the way your servers communicate (registry hacks etc) you could end up having to punch massive holes in your firewall rule base.

I have heard about vaulting, creating VLANS based on application type with the relevant access-lists. So certain kinds of servers can be placed into certain VLANs. However again, if you are in a Windows environment you would have to start forcing the servers to communicate with each other and clients on fixed ports which (as mentioned) involves registry changes and not always an option if you have 200+ servers.

To implement this kind of internal firewalling would take a great deal of work.

Might be better looking at NIDS and HIDS solutions

Thanks

Paddy

[anonymousp]

Don't balk on internal network segmentation. Its all doable, and it will pay off. With regard to the Exchange issue, note that RPC communications on Windows servers can be configured to use restricted port ranges via policy. Restricting the RPC port range dramatically simplifies creation of firewall rules.

The toughest questions involve the performance hit users will take. Chances are even a large Outlook/Exchange community isn't going to be impacted.

IIRC, Most virus/worm outbreaks occur on the inside of a network. Internal Firewalling can be a great tool to reduce the impact of potential outbreaks.

[jboyer]

I am currently working in a large (130+ sites) network that does this to some extent. All VLANs and WAN sites pass through ACLs that have been more reactionary then proactive. Things are added to ACLs when a new threat is identified. A more formal "denied unless explicitly permitted" policy would take much work but it would be better. And potentially ROI with reduced bandwidth consumption.

Consider this implementation in conjunction with any QOS implementations since the first phase of both projects would be to identify business applications and prioritizing them. 2 birds/1 stone.

[tim.metzinger]

There are several hurdles I usually encounter when trying to segment "internal" networks.

The first is a technical issue - the need to divide what may currently be a single subnet into multiple subnets to create the appropriate zones, and the ip address space, DNS, and system reconfiguration that comes along with it. This can be done with plenty of patience, but only if the second hurdle is dealt with first.

The second hurdle is a protein problem - making the business case that there's a benefit to doing all the work, either in increased performance, reduced liability or risk, or the ability to better manage and control future security incidents. This can be a hard sell because the conventional wisdom is that your existing internal network is trusted, and if it can't be trusted because of worm/virus threats, then you (as the security administrator) aren't doing a good job of protecting it. Frankly, most organizations are still guilty of NOT building good defenses (both technical and policy) against external threats and it's that failure which causes the "internal" threat to occur.

The only performance issue (specifying a firewall capable of handling the load) I'm aware of when segmenting this way can be the small but unavoidable overhead of latency in routing and filtering - if you have an app that won't work well through a router, then you need to think hard about segmenting it.

Finally, remember that an IT security auditor is generally not happy until you're not happy, and it's common for audits to suggest best practices that may or may not be good choices for you - it remains your responsibility to do the cost-benefit work and justify implementing (or not) the recommended change. I've been very fortunate in that my organizations are oriented towards risk management and not risk avoidance, and we've been able to choose not to implement some suggestions and successfully defend the decision.