Applications with no front end server

Question

We are bringing up a server that will be exposed to the Internet from a vendor who's application has no official vendor front end server.

Although this web application server will pull data from internal sql resources, I'm concerned there is a chance this server could be compromised.

When I asked them about the security of this, they said if I wanted I could simply put a reverse proxy like NGINX in front of it.

We already have load balancers that I'm planning on using. Is it acceptable to simply put this server behind load balancers which basically are reverse proxies to begin with, or should one do load balancers and nginx (ie a double reverse proxy?)

The application server is a web product that will serve up on ports 80 and 443. Technically, the ssl will live on the balancer.

This got me thinking too, our modern day exchange mail servers webmail does not have an official Microsoft front end either for webmail. Microsoft doesn't make such a product.

Is the days of DMZ over in favor of other multi layer security offerings?

Answer 1

Use of the DMZ is a strategy to 'fence off' the application from the wider network, but doesn't address vulnerabilities within the application or its execution environment.

You could certainly quarantine the application server in a DMZ as part of your security controls. As @Julian Knight says a reverse proxy can mitigate certain attacks.

Regarding introducing 'another' reverse proxy (NGINX) into the architecture, ask 'what additional security or functional capabilities does that provide?'. Just duplicating the capabilities already provided by your existing reverse proxies will just impact performance and maintainability, and potentially introduce additional security issues if you've misconfigured anything. Not to mention the cost of running the additional service / servers. A cheeky question to ask your application vendor would be 'Do you guarantee that my application will be secure if I introduce NGINX into the architecture? :)'.

I think it is important to look at the security of the application itself. Has it been independently security tested? Are there any known vulnerabilities? There are many vulnerabilities that a reverse proxy won't protect you against... injection attacks for example.

In addition to implementing appropriate security controls within the application and its execution environment, a Web Application Firewall (WAF) is a type of reverse proxy that can prevent some common attacks on web applications (e.g SQL / Command injection). It would be worth checking if your existing proxies have this capability.

But of course, first look at the business context of the application and the impact of various successful attacks. This should guide how much effort should be placed on protecting the application.

Answer 2

Using NGINX or other load balancers will help somewhat with the application security. It protects from app server security vulnerabilities and assists resistance from DDOS attacks.

In addition, offloading SSL to the proxy layer may help overall performance as well as again mitigating against any possible flaws in the app servers SSL (TLS hopefully) implementation. Being a common server with lots of open development tends to mean that security issues are found and fixed more rapidly in web/proxy servers than app servers.

The main thing is that something like NGINX can be configured with security in mind and provide an additional, well supported external layer.

In terms of network design, your front-end web servers will operate in a DMZ and so be segregated from back-end app and database servers via a firewall. You might choose to also put the app servers in the DMZ as well or even to have an inner and outer DMZ if you needed additional security though you will also need to consider performance issues.

Whether or not you need additional infrastructure as well as the load balancing function will also depend on factors we aren't aware of. Things like the performance of the app servers, number of client connections, available bandwidth, available and performance of (virtual) servers and so on.

As for your example of Exchange. Exchange is specifically designed to be scaled out using many commodity servers. However, it is most commonly deployed behind several layers of protection including and edge transport layer, virus/spam management, intrusion protection and data loss prevention. As most of those require content inspection, it is also common to offload SSL/TLS to the perimeter as well.

Detailed design is dependent on the value of the data, the exposure of the data, volume, type and several other factors as well as the organisations appetite for risk and whether you are operating in a regulated industry. As we don't know any of that, we cannot comment on those specifics.

The DMZ isn't dead but may be more nuanced.