A few good technical practices when publishing services on the internet

A few good technical practices when publishing services on the internet

17.10.2017
00:51
hardening, secdevops

Thomas

The author works at and owns Mint Security, a mean and lean security company founded in 2015. No fuzz (literally - we do not fuzz, there are companies better equipped to do that).

Introduction

This post is not a technical silver bullet. Nor is it the absolute truth. As a starting point though it is good. It adheres to common sense, is based on risk analysis – and provides good valuefor the effort. It can easily be adopted as a company standard, and of course automated in a true devops fashion. This post is meant as a basic starting point for a relatively simple web-based end-user solution. It is meant as a guideline as why to avoid “default”.

In the end this pretty much suites 95% of all services published on the internet :). So let’s get started.

Secure Architecture

The first thing is to minimize your potential attack surfaces and vulnerable spots. If we analyze the situation, we can conclude that the less logic and complexity we have in the front line, the less vulnerable we are. Translated to plain English? Don’t connect your appservers directly to the internet. Appservers are a bitch to harden, even more so to assess whether or not the hardening is up to par. That is why you use proxies in one or the other way.

Reverse proxy it

A proxy can be a cheap NGINX, a cheap but a bit more robust apache or a commercial hardware-based solution (FYI, Gartner calls the latter ones Application Delivery Controllers – http://blogs.gartner.com/andrew-lerner/2015/10/07/application-delivery-controller-magic-quadrant-2015/).

Firewall it

Now our Architecture contains a proxy and an appserver. Let’s make it even more secure and add a host-based firewall (like iptables) to protect all of your servers. Many cloud-providers already provision their servers with a default of deny all. That is a good starting point.

For the proxy, block everything except “443 from anywhere” (this is where your users will connect)
For the appserver, allow only the appserver-port (like 8443 for Tomcat) to be accessed from the proxy.
If you are running a database, allow only the JDBC/ODBC -port to be accessed from the appserver

If you have the possibility, use a hardware firewall and true network segregation between the proxy and “the rest”. If not, iptables as described above is sufficient and most of the times provides good enough valuefor the effort. In the cloud, many times, iptables is your only option.

Hardening

You want to hide your implementation. It is very important to publish services using neutral ports. So, SSL/tls is always 443. Not appserver specific ports that will tell potential hackers about your appserver of choice.

Run your servers as non-root. Always. So, installing an appserver and running it directly on 443 is rarely an option. That’s another reason why you need a proxy.

If you do not fully (I mean fully) trust your network, please also harden your appservers – even if you are protecting them using a firewall:

Change the default ports
Delete default and example applications
Kill unused listeners

Shutdown admintools – or restrict them to localhost + administrative workstations

If you are using apache or NGINX as a proxy, go ahead and harden those too. You can close down 90% of the unnecessary (and potentially vulnerable) stuff easily.

Please note that hardening and managing the OS and SSH – although very important – is outside of the scope of this post.

SSL/TLS

Get your configuration right

Configure your SSL/tls right. Once you get the tech-stuff right (ciphersuites etc), make sure you can actually manage your configurations. Again, the proxy-based solution will be a lot easier here. First of all, it was built to do a few things right – and do it easily. Terminating SSL/tls is one of those. Yes, you can manage your SSL/tls configurations in any appserver, but the operational instructions to handle this will be a lot longer and more complicated. Also, segregation of duties might play a part here.

Operational instructions

Write down operational instructions on how you manage the certificates. You will thank yourself in 1 year when it is renewal time.

Or automate it.

Be compatible - not stupid

Don’t forget compatibility, but don’t be afraid to be modern. For public services, favor standards.

Use SSL/tls that is secure AND compatible with most NEW browsers (do NOT weaken SSL/tls configurations in favor for compatibility with browsers from the yesteryears)
Use CA’s that are supported and well-known
Do not use self signed certificates or a private CA
Use standard ports (avoid firewall-issues)

A picture tells more than a thousand words

So true. So let’s have a look at what I have just written. We will start from just “plain bad” (we call this scenario Sad mac – Happy black hat) to “actually pretty good value” (we call this scenario Happy mac – Sad black hat).

Conclusion

It is quite simple to run services on the internet in a much more secure manner than”default”. Is this the only way? No, of course not. Is this a good place to start? Yes.

Default is bad, OK?

If you are not automating this, it will be easy to write the documentation needed. You need instructions and documentation for at least the following topics:

Install and harden the proxy
Install and harden the appserver
Request, install and renew the certificates
Configure iptables (or alike)

Where do we go next? Yes, there is more. Ips/ids to start with. Ddos-protection? Sure. But here’s the catch – adding more components really require another round of risk assessments – otherwise you will be mostly spending, and less and less adding value.

Thomas

The author works at and owns Mint Security, a mean and lean security company founded in 2015. No fuzz (literally - we do not fuzz, there are companies better equipped to do that).