Be careful, Docker might be exposing ports to the world

Recently, I noticed logs for one of my web services had strange entries that looked like a bot trying to perform scripted attacks on an application endpoint. I was surprised, because all the endpoints that were exposed over the public Internet were protected by some form of authentication, or were locked down to specific IP addresses—or so I thought.

I had re-architected the service using Docker in the past year, and in the process of doing so, I changed the way the application ran—instead of having one server per process, I ran a group of processes on one server, and routed traffic to them using DNS names (one per process) and Nginx to proxy the traffic.

In this new setup, I built a custom firewall using iptables rules (since I had to control for a number of legacy services that I have yet to route through Docker—someday it will all be in Kubernetes), installed Docker, and set up a Docker Compose file (one per server) that ran all the processes in containers, using ports like 1234, 1235, etc.

The Docker Compose port declaration for each service looked like this:

Restrict access to the Apache Solr admin interface

I've helped many people set up or fix a botched install of Apache Solr on their VPSes and web servers. Most of the time, I've noticed that people leave the administrative frontend to Solr wide open for anybody on the internet to access, by just accessing This is very dangerous, as not only can anyone browse and query your search indexes, they can even add, delete, or change your search cores, and see sensitive system information that can be used to gain further access!

Solr Dashboard
The Apache Solr admin dashboard