File transfers · 21 / 22 / 990

Partners get in.Scanners don’t.

File transfer servers hold the data attackers want and sit where everyone can find them.

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

Partners need to reach it.So does everyone else.

A transfer server is exposed by design, because partners have to reach it. That makes it a standing target, and the files on it are frequently the most sensitive an organisation moves.

Exposed by design

Partners have to connect, so the server answers the whole internet.

An IP allow-list

It narrows who connects. The service still listens, including to a compromised partner address.

The patch-day race

Managed file transfer flaws have been mass-exploited in the window between disclosure and patching.

The transfers keep running.The listener is gone.

0
Inbound listening ports on a protected host
10
Minutes to deploy and protect a server
0
Partners admitted without a verified identity
How it works

The port is closed.Not hidden.

Step 01
Transfer ports go dark

SSHepherd closes the listening port on the transfer host, so the service cannot be discovered or reached by an unauthorised party.

Step 02
The host dials out

Authorised partners and internal systems connect through the broker, which admits known identities only. The transfer service keeps running; it simply stops answering the open internet.

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.

Transfers continue

Authorised partner and internal transfers run as before.

The patch window stops being a race

An unreachable service cannot be mass-exploited on the day a flaw is disclosed.

Access is per-identity

Partners are admitted individually rather than by IP allow-list.

Every session is evidenced

Transfers are recorded and exportable for audit.

See it

Watch it work.

Harden your SFTP servers: make them invisible to hackers. A recorded demo from Full Armor, the developer of SSHepherd®.

Questions

Common questions.

Can external partners still send us files?

Yes. Authorised partners connect through the broker. The difference is that only known identities can reach the service at all, instead of it answering anyone who scans for it.

Does this work with our existing MFT product?

In most cases yes. SSHepherd closes the port in front of the service rather than replacing it, so the transfer software itself is unchanged.

Is this better than an IP allow-list?

It is a different control and a stronger one. An allow-list still leaves the service listening and reachable from any permitted address, including a compromised one. SSHepherd removes the listener and binds access to an authorised identity.

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.