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
Reverse proxy it
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
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
![](https://www.mintsecurity.fi/wp-content/uploads/2019/02/webarch-1.png)
![](https://www.mintsecurity.fi/wp-content/uploads/2019/02/webarch-2.png)
![](https://www.mintsecurity.fi/wp-content/uploads/2019/02/webarch-3.png)
![](https://www.mintsecurity.fi/wp-content/uploads/2019/02/webarch-4.png)
![](https://www.mintsecurity.fi/wp-content/uploads/2019/02/webarch-5.png)
Conclusion
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.