Unnecessary services reachable from the internet

Most security attention goes to the application, because that is the part deliberately exposed to the internet. The most serious findings regularly sit next to that application: a database, an admin port or a monitoring interface that ended up there unnoticed. This article covers how that happens, and why those services are so attractive.

Which services end up exposed unintentionally?

We speak of unnecessary services on the internet when ports are reachable that only serve a purpose internally. In practice it concerns a recognisable set: databases, caches, message queues, search indexes, admin interfaces, monitoring dashboards, container management ports and management protocols for the server itself.

It is almost never a deliberate choice. It arises because a service binds to all network interfaces by default rather than only the local one, because a firewall rule was opened temporarily and never reverted, because a new server was deployed without the same restrictions as the previous one, or because a test setup ended up in production.

What makes these services dangerous is that they were not designed to be exposed to the internet. In their default settings they assume that whoever can reach them belongs there. Often that means no authentication, or authentication with credentials everyone knows. Think of a building with a well-secured front door and, beside it, an open hatch to the cellar because nobody expected anyone to walk on that side.

How are those services found?

Vulnerable:

A scan from the outside against an application’s server reveals more than expected:

443/tcp   open  https        application (intended)
22/tcp    open  ssh          OpenSSH 8.2
3306/tcp  open  mysql        MySQL 8.0.28
6379/tcp  open  redis        Redis 6.2.6
9200/tcp  open  http         Elasticsearch 7.10.2
2375/tcp  open  http         Docker Engine API

Only the first belongs there. The rest is incidental, and the severity varies widely. The database is a target for an attack on its credentials. The cache in its default form runs without authentication, which amounts to free access to everything it holds, often sessions and tokens. The search index in its default configuration reveals its full contents to anyone who asks. And the container management port is the most serious: it allows containers to be started on the host, which effectively amounts to executing code with high privileges.

Finding this requires no particular interest in you. The full internet address range is scanned continuously and the results are searchable. A port that opens appears in those overviews shortly after.

Safe:

# The service listens only on the local interface
bind 127.0.0.1
protected-mode yes
requirepass <long, random secret>

# And the firewall denies by default, permits by exception
ufw default deny incoming
ufw allow 443/tcp
ufw allow from 10.0.4.0/24 to any port 22
ufw enable

The two measures complement each other deliberately. A service listening only on the local interface is unreachable even if a firewall rule is wrong. And a firewall that denies by default also protects the service that turns out to be bound to all interfaces again after an upgrade.

What is the impact of unnecessarily exposed services?

The severity runs from medium to critical, depending on the service. With a monitoring dashboard it stays at information about your infrastructure. With a database or cache without authentication it is a full data breach. With a container management port it is takeover of the server.

What characterises this category is that the attack is automated and not aimed at you. There is continuous scanning for open ports with known characteristics, and whatever responds gets tried. Your size or visibility does not matter; reachability does.

On top of that, these services fall outside regular management. The application is tested, patched and monitored. A database that is accidentally reachable appears in no overview: there is no logging to your central system, no alerting on failed logins, and nobody tracking the version. An attacker can therefore be active there for a long time without being noticed.

How do you detect unnecessarily exposed services?

The basis is an external scan across the full port range of every address belonging to the organisation. That is deliberately from the outside: the question is not which ports should be open according to the configuration, but which actually answer.

For every service found, the product and version are then determined, along with whether authentication is required and whether the default credentials still work. Whether the service carries a known vulnerability is checked too. Completeness of the address range matters: besides the known servers it concerns test environments, systems at suppliers, and cloud resources created outside regular management. IPv6 gets attention as well, because it is regularly forgotten in firewall rules while the service does listen on it. AssistSec starts a test with this inventory as standard, because what is found here is often decisive for the rest of the investigation.

How do you prevent unnecessarily exposed services?

• Have services needed only internally listen solely on the local interface or on an internal network.
• Use a firewall that denies by default and permits only by exception.
• Expose management protocols through a VPN or bastion, never directly from the internet.
• Change default credentials and enable authentication on services that do not require it by default.
• Include IPv6 in your firewall rules; it is regularly forgotten.
• Keep an overview of all addresses and ports belonging to your organisation.
• Scan periodically from the outside rather than trusting the intended configuration.
• Clean up temporary exposures actively and record an end date when creating them.
• Include test and acceptance environments and supplier resources in the overview as well.