SSHepherd Documentation
< All Topics
Print

FAQ

What is SSHepherd?

SSHepherd is a new, patented cybersecurity software product which provides secure access to RDP, SSH, and TCP/IP applications while their ports are completely turned off so that they cannot be discovered.  It also records RDP and SSH session activity for auditing and compliance with the ability to terminate rogue behavior.

What are the SSHepherd components?

SSHepherd is comprised of 3 components – 1) the Control App, 2) the Administrator Console (C3 Server), and 3) the Agent.

1) The SSHepherd Control App is both a GUI and a command line interface (CLI) that administrators and end users run to authenticate and establish the secure tunnel and run the native RDP, SSH protocols or to initiate a tunnel to run a TCP/IP application.  User/Group/Host permissions are assigned and granted in the Administrator Console.

2) The SSHepherd C3 Server & Administrator Console (C3 – Command and Control Console) is where Users/Groups/Hosts are managed and session recordings can be viewed. 

3) The SSHepherd Agent controls and automates the process of starting and stopping the SSH and RDP sessions. When a session is requested, the agent generates a variation of a port forwarding session, establishing a secure reverse tunnel and starting the session over a TLS encrypted outbound tunnel. The agent also has a built in session kill switch for immediate termination of rogue sessions.

How does SSHepherd protect against Internal threats?

SSHepherd protects against internal threats by limiting ingress, monitoring, recording, and storing all SSH and RDP sessions and providing the ability to terminate sessions manually or automatically based on unwanted behavior (ex., attempting to change pwd or copy data externally). Even an authorized SSHepherd user (who has gone rogue) is contained because of SSHepherd’s Role-Based Access Controls (RBAC) and their session activity is monitored, recorded, and can be remotely terminated.

How does SSHepherd protect against External threats?

SSHepherd protects against external threats by allowing you to turn off sshd (OpenSSH daemon), RDP and TCP/IP applications so that there are no open ports or services listening for inbound connections. As a result, there is nothing for the hackers/bots to scan. The server looks like a dead box. Yet, authorized SSHepherd users can still access the machine and use SSH (as well as DevOps and key management tools, etc.) and RDP as they normally do.

Does the SSHepherd Server become the new attack vector?

Potentially yes, however, even if a hacker were able to exploited it, they would not be able to initiate a session to any of the Linux or Windows machines.  Using a tool like Wireshark, the traffic on port 443 (default but configurable) appears as normal encrypted HTTPS traffic in and out of the C3 server.  The C3 server looks and acts like a hardened web server.  It is purpose built for light management duties and to act as an ingress/routing server only.  Additionally, the enterprise attack surface is greatly reduced from many Linux/Windows hosts to 1 host server. 

What happens if someone does a NMAP scan on a server that SSHepherd is protecting? Will port scanning see an open SSH port when SSHepherd has started sshd?

No. NMAP and other port scanners will still not see any open, listening ports. SSHepherd does not open any inbound listening ports so SSH and RDP are still not visible to port scans, even when there is an active SSHepherd session.

Can SSHepherd prevent unwanted lateral movement…jumping from one server to another?

Yes. SSHepherd prevents lateral movement because users only have access to what has been assigned to them in the SSHepherd Administrator Console. Attacks are reduced by limiting the point of ingress coupled with an additional layer of Role-Based Access Controls (RBAC).

If there are SSH keys or RDP creds out in the wild, will they be able to connect to my servers when SSHepherd is installed?

No, because once SSHepherd is installed, connections can only be initiated by SSHepherd from authorized users/hosts and ingress/egress is limited.

Does SSHepherd protect Linux and Windows endpoints that are on-premise and in the cloud?

Yes, SSHepherd works with both on-premise and cloud endpoints.

Does SSHepherd fully support the SSH and RDP commands?

Yes, all the SSH, RDP capabilities are supported because SSHepherd’s Control App launches native SSH and RDP.

Can I use SSHepherd with my existing key management and automated workflows (SSH.com, Venafi, Okta Advance Server Access, MFA, Chef, Puppet, Ansible, Saltstack)?

Yes, SSHepherd fully supports SSH Keys and key management, SSH tools, and automation.

Does SSHepherd support automated scripts?  If yes, what would I need to do?

Yes, existing scripts are supported.  They will need to have one line added to call SSHepherd’s CLI controls.

For DevOps, can SSHepherd be used as part of an automated process as servers are spun up into the cloud?

Yes, the servers can be spun up with SSH, RDP ports turned off and only the registered SSHepherd users/admins (or tools) can connect to them.

Once SSHepherd establishes a SSH, RDP connection, can you wrap other protocols or ports within it?

Yes, once a SSHepherd session is established, port forwarding is fully supported for other services and applications.

Does SSHepherd work for any device that uses SSH, RDP?

Any supported Linux/Windows OS and device that allows you to install a lightweight package. 

Can I integrate my IAM and/or PAM products with SSHepherd?

Yes, SSHepherd provides a full set of REST APIs for third party integration with Identity Management and Privileged Access solutions.

Can SSHepherd be persistent or is it one-time only?

Both.  You can choose to keep the SSHepherd tunnel open for a persistent connection or terminate it when a session ends.

Is there a need for SSHepherd if my servers are behind the perimeter (VPN and Firewall)?

VPNs and Firewalls are a necessary part of your perimeter security but as we’ve learned, this is not always adequate. Through a variety of techniques including phishing attacks, firewall misconfigurations/CVE’s, purchasing stolen keys, etc., hackers are able to circumvent your perimeter security measures. Most ransomware attacks occur inside the perimeter and many of the largest data breaches in the last decade happened inside the perimeter.

Leveraging the full capability of SSHepherd by removing the attack surface, managing the point of ingress/egress, auditing, monitoring and recording all sessions and remote session kill capabilities whether on premise or in the cloud is critical to securing your most valuable digital assets, even when the bad actor is already inside.

How much of my Attack Surface will be reduced by using SSHepherd?

For as much as you use RDP, SSH, and TCP/IP applications that you protect with SSHepherd.

Can’t I just move the ports so that the bad guys don’t find them?

No, Nmap and other port scanning tools will still find the open, listening ports.

How is SSHepherd different from a Load Balancer with WAF?

The biggest difference is that with a load balancer with WAF, the ports are still open and listening so hackers have something to go after with a brute force attack.  SSHepherd removes this attack surface completely. Secondly, a load balancer/WAF doesn’t provide session auditing with kill switch capabilities in the case of risky or unauthorized behavior inside a session.

How can SSHepherd help with “Alert Fatigue” in my SOC?

By removing the SSH, RDP and Application open ports, failed access attempts from things like Brute Force Attacks will no longer be an issue as there is no more open port for attackers to run their attacks against thus reducing the number of alerts generated requiring investigation.

Will this impact the alert logs to my SIEM?

Yes, the alert logs for those ports will be eliminated because the ports are closed.

Is SSHepherd a component of a Zero Trust initiative?

Yes, the Zero Trust Framework says to assume that the adversaries are already inside your network.  SSHepherd adheres to this Zero Trust framework of authenticating, verifying, and granting access to only the resources that the user needs and the SOC 2 mandates of auditing and safeguarding activity.

Does SSHepherd help if we have a phishing exploit?

Yes, because once the adversary is inside, they will not be able to find your critical servers that are being protected by SSHepherd.  Furthermore, they will not be able to move laterally (i.e., jump) from server to server because SSHepherd contains their movement using its RBAC controls.

How much memory and disk space do the various SSHepherd components consume?

  • For the SSH Tunnel, SSHepherd Control App uses 32MB of memory and SSHepherd Agent uses 50MB.
  • For the RDP Tunnel, SSHepherd Control App uses 60MB of memory and SSHepherd Agent uses 1.5GB (ffmpeg recording).
  • The Control App install package for Windows is 51MB, the Linux packages are between 40-50MB, and the MacOS package is 130MB.
  • The Agent install package for Windows is 50MB and the Linux packages are between 12MB-18MB.

Where does the SSHepherd C3 Server need to be located?

The SSHepherd C3 Server can be either on-premise or in the cloud.

Can SSHepherd be scaled?

Yes, SSHepherd was designed for scalability as a stateless Kubernetes package to support 1000s or 10s of thousands of remote devices.

Can SSHepherd be configured for High Availability (HA)?

Yes, SSHepherd is run as a stateless Kubernetes package for scalability and high availability. The specifics depend on your choice of deployment.

What flavors of Linux does SSHepherd support?

SSHepherd supports Red Hat, Oracle, CentOS, Suse, Ubuntu, Kali, Alpine and most Debian and Fedora based distros are supported today. FullArmor is always open to customer feedback and we are willing to accommodate requests for other Linux distributions.

When SSHepherd initiates a session, can someone use the same port from another machine?

No, because there is no listening port. All requests must be marshalled through SSHepherd and be initiated by an authorized user. As a result, lateral movement is also prevented.

In This Article