66

In an answer to How do you deal with massive port scans?, user tylerl said:

... And you, like a wise IT admin, run all your servers elsewhere on the internet, not inside your corp network, for a whole raft of reasons I won't go into here

As a not-so-wise IT admin, what reasons are these?

topher
  • 821
  • 8
  • 13
  • 17
    So that compromise doesn't threaten your internal network, and so that DDoS/DoS attacks don't threaten your internal network to name two. – AlexH Feb 10 '16 at 10:28
  • Does it mean "run your servers in AWS/Azure/etc"? – pjc50 Feb 10 '16 at 13:44
  • 1
    @pjc50 the outside is a big place, AWS/Azure/etc is only a part of one possible approach – schroeder Feb 10 '16 at 16:25
  • 3
    @AlexH it is more the other way round. Users pick up malware and trojans so there should be security between them and your servers whether they are internal or external users. – JamesRyan Feb 10 '16 at 16:39
  • 2
    @JamesRyan I was of the same thought. Protect your servers from your users. – topher Feb 11 '16 at 07:27

4 Answers4

51

Having all your corporate servers in the same network is a bad idea because if one of the servers is compromised, the attacker can easily spread out to the others. Servers are often configured to be secure on the front end, but when it comes to servers communicating with each other, there are various ways to find vulnerabilities. Also the sensitivity of data is often not the same. While a web server is important for the availability, a database server often contains valuable customer data. Separating these is a good idea in any case.

Specialized hosting providers for specific servers are mostly able to keep their servers more secure as well.

Thanks to the internet, there is no reason not to separate servers, unless your application is so time dependent that for example database servers need to be accessed directly.

AdHominem
  • 3,006
  • 1
  • 17
  • 26
  • 1
    they could still be seperated by VLANs, but why place the web-server outside the network? – JOW Feb 10 '16 at 10:44
  • 2
    VLANs are a way to separate networks logically, they especially help with organizing them. When it comes to security, you need to physically separate networks, as well as servers residing in these. In theory you could have all your servers remotely located and just manage them from your company's network, in practice most companies run at least a few servers on their own, mostly for cost reasons. – AdHominem Feb 10 '16 at 10:51
  • 14
    @JOW What level of support does your corporate network have? Multiple redundant connections? Backup generators? 24/7 monitoring? Experience of dealing with DDoS attacks? If it is missing any of this, you're probably better putting web servers in a dedicated web hosting environment, where they can come under all sorts of attack without even touching your corporate environment. – Matthew Feb 10 '16 at 10:51
  • 1
    @Matthew I agree with you and this answer completely. I just had to comment, so that this view gets explained explicitly. – JOW Feb 10 '16 at 10:56
  • 1
    So, basically it's to avoid a form of privilege escalation? That makes sense. – Mast Feb 11 '16 at 18:56
  • Do you suggest to separate Web and database servers? If the Web server is compromised, how do you restrain the access to the database? It can act as a *trusted* server. – A.L Feb 23 '16 at 16:00
22

There is nothing wrong with running servers inside the corporate network - except that the corporate network should not be one wide, flat network. You should consider segregating assets and users into different "zones" and then write rules that allow the right (and expected) access between those zones. in your model, include "internet zone" and also any direct links to third parties you company may have (e.g. vpn to suppliers)

I would always use firewalls rather than simply splitting the network into VLANs. Firewalls offer better functionality to build rules (or groups of rules) so you can whitelist traffic that you expect to flow between zones.

You can place security controls on intra-zone borders, such as:

  • IPS/IDS reporting to your Soc/SIEM
  • Access control list functionality (supported by some firewall manufacturers) that will allow you to ensure that only authorised users may access a zone, where servers/apps reside. Of course, your DENY log will be useful for the SoC

Organising the zones will be different for every organisation, but commoin examples are:

  • segregating development/testing from production
  • segregating users from production servers
  • segregating high risk or highly sensitive application servers from non sensitive applications servers

There are some risks. Take care not to over do the number of zones and make it too complex. Otherwise the burden of maintaining rules will become a big cost. Consider investing in a firewall product that has a good rules management or even a separate rules management application (e.g. Tuffin SecureTrack + there are others too).

Also be aware that some firewall suppliers have proprietary ways of adding ACLs to rules; these can have a heavy hit on performance of the firewall and you may need larger kit than expected.

Callum Wilson
  • 2,543
  • 11
  • 16
5

Servers usually need to be accessed from the Internet, so your network design must allow connections from the Internet to the network where your servers are. Now if you put the servers in the internal network, that means you have to expose the internal network to the Internet by design.

And there is no reason to put the servers in the company network anyway. Even if the servers are used from the workstations in the company network, they (usually) don't need to establish connections to the workstations.

theDmi
  • 395
  • 2
  • 10
1

Without rehashing what others have already brought out, here are a couple more reasons from a network admin perspective:

  1. Keeping your servers on a separate security zone, subnet and VLAN provides network segmentation. This will reduce unnecessary broadcast traffic to your servers and provide more bandwidth between server-to-server traffic. Network segmentation is an important part of network security and design that I would encourage you to learn more about.

  2. And along similar lines: with a separate security zone, forcing your clients to pass through a hardware firewall to communicate with your servers allows for much more granular control over what traffic is permitted to and from your servers. This can serve for a variety of security purposes and can also help prevent viruses such as worms from even having the ability to exploit a port on your server that is otherwise open and susceptible to attacks. Clients are naturally going to be less secure because your users have the ability, to varying degrees, of doing insecure things on and with them. The servers however, you have full control over.

  3. You could further segment servers into two separate zones. One zone would be for your internal servers that don't necessarily provide any sort of hosting and don't need to be accessed by the outside world. The other zone would be a type of server-DMZ where servers that are accessed by the outside world for whatever their hosting and would have a completely different set of security parameters.

Jack Bahou
  • 153
  • 1
  • 10