Databases · 1433 / 3306 / 5432

Close the database.Keep the queries.

A database should never be reachable from the internet. SSHepherd makes certain it is not.

Animation: a port scan of a server protected by SSHepherd finds no answer on 1433 / 3306 / 5432, while an authorised session to the same server stays live through the SSHepherd broker, both ends connecting outbound.
The exposure

Databases shouldn’t face the internet.They do anyway.

Database ports are enumerated constantly, and a reachable instance gives an attacker a great deal before authentication: the engine, the version, and often enough of a banner to select an exploit.

A broad security group

Opened wide during a migration and never narrowed again.

A changed bind address

Switched for troubleshooting, then forgotten.

A replica outside the plan

Stood up beyond the original network design. It only has to happen once.

A firewall decides who may knock.SSHepherd removes the door.

0
Inbound listening ports on a protected host
10
Minutes to deploy and protect a server
0
Connection logic to rewrite
How it works

The port is closed.Not hidden.

Step 01
Database ports go dark

SSHepherd closes the listening port on the database host. There is no socket for a scanner to find, whatever the firewall rules happen to say.

Step 02
The host dials out

Application servers and administrators reach the database over authorised outbound connections through the broker, so legitimate traffic continues while the port stays shut.

Step 03
Verified & watched

Only authorised identities are admitted. Every session can be monitored, recorded and ended on demand.

Developed by Full Armor Corporation. Distributed, deployed and supported across Southeast Asia by Auris.

Attacker scanNo inbound path
Permitted · outboundBlocked · inbound
Protected serversNo inbound listening ports
SSHepherd®Broker
Authorised usersAdmins & vendors
  • Nothing listens inbound
  • Access via broker only
  • Every session monitored
Portless architecture. Servers and users both connect outbound to the SSHepherd® broker, so the protected host never accepts an inbound connection.
What changes

Your team keeps working.Scanners get nothing.

Applications keep connecting

Authorised application traffic continues over the broker; connection logic does not have to be rewritten.

Misconfiguration stops being fatal

An over-broad firewall rule no longer exposes the instance, because there is no listener behind it.

DBA access is identity-bound

Administrative connections are tied to an authorised identity rather than a network location.

Queries are attributable

Sessions are recorded, so administrative access to production data can be evidenced.

See it

Watch it work.

SSHepherd® and MySQL. A recorded demo from Full Armor, the developer of SSHepherd®.

Questions

Common questions.

Will my applications still be able to reach the database?

Yes. Authorised application traffic is carried through the broker over an outbound connection. What is removed is the inbound listening port that anyone could scan.

Which database engines does this cover?

SSHepherd works at the port level, so it covers Microsoft SQL Server, MySQL and PostgreSQL alike, along with other TCP services on the same host.

Does this replace our firewall?

No, it makes the firewall less load-bearing. A firewall decides who may reach a service that is listening; SSHepherd removes the listener, so a mistaken rule no longer results in exposure.

How SSHepherd compares with ZTNA products

Book a demo

See it onyour own servers.

Tell us roughly what you run: how many servers, and whether they are on-premise or in the cloud. We will set up a demo with an engineer and reply within one business day.

We use these details only to reply to your request, usually within one business day.