Web server being accessed internally and externally

IT_Magician
Building a reputation

Web server being accessed internally and externally

Hey Meraki Community,

 

We have a Meraki MX67 and behind it is a new IIS web server going up. The vendor isn't using an SSL certificate and has asked us to make this available via port 80. Because the web server has to be accessed externally AND from within the office it is on the private VLAN to allow communication.

 

What is the best way to secure this from a networking/Meraki standpoint?

 

Thanks,

 

BA

8 Replies 8
IT_Magician
Building a reputation

Want to clarify, this server is running IIS & SQL Database for a new custom built CRM

DarrenOC
Kind of a big deal
Kind of a big deal

Where in the network is the web server connected? Directly to the MX or a switch further downstream?

Darren OConnor | doconnor@resalire.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
IT_Magician
Building a reputation

MX67 to switch network. From switch network into ESXi host running many VMs, one of them is the new IIS?SQL database. All servers are on the same network and domain.

DarrenOC
Kind of a big deal
Kind of a big deal

Sorry, L3 switch, type, assume Meraki?  I presume you’re more concerned around the machine being exposed externally?

 

On the MX layer 3 rules specify which external IPs and ports can access the internal host.

 

If you’re using a Layer 3 switch and you need to tie down internal access then use ACLs to specify which IPs can access the server.

Darren OConnor | doconnor@resalire.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
IT_Magician
Building a reputation

Yes, we are 100% meraki across the board, including switches. Good idea on Layer 3 rules. The switches are only layer 2.

 

So you are saying, use Layer 3 firewall rules to limit it as much as possible to only what it needs? My main concern is a threat coming in where a malicious attacker gains access into the network through the web server and finds a way to hop over to another system. Is that a silly concern?

DarrenOC
Kind of a big deal
Kind of a big deal

Not a silly concern at all.  Only way around blocking users who’ve exploited the server from moving sideways around your network is to physically segregate it all. Which I’m assuming the budget won’t allow?

 

 

Darren OConnor | doconnor@resalire.co.uk
https://www.linkedin.com/in/darrenoconnor/

I'm not an employee of Cisco/Meraki. My posts are based on Meraki best practice and what has worked for me in the field.
BrandonS
Kind of a big deal

There is a good Meraki doc that describes the recommended way to do this:

https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Creating_a_DMZ_with_the_MX_Security...

 

It sounds like this matches your scenario pretty well.

- Ex community all-star (⌐⊙_⊙)
KarstenI
Kind of a big deal
Kind of a big deal

IMO, a DMZ is always needed when a system is accessed from the internet. Based on the customer requirements I sometimes place the Webserver into the DMZ. More often, a reverse-proxy is placed in a DMZ and that system sends the requests to the server on the local LAN. I do this if the customer wants to have the server in his internal network for whatever reasons.

For the really security-aware customers (well, most of them are not) both the reverse-proxy and the server is placed in separate DMZs.

For the reverse-proxy, I personally like to use a Linux-box with NGINX. But that is only a personal preference.

 

EDIT: I would also place the Webserver and the Database in different DMZs.

If you found this post helpful, please give it Kudos. If my answer solves your problem, please click Accept as Solution so others can benefit from it.
Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.
Labels