The pandemic-induced lockdowns forced companies and employees to embrace Work From Home as the new normal. Remote working is not a new phenomenon. Various tools, like SSH or telnet, have been in the arsenal of server administrators for the remote administration of critical infrastructure resources such as servers, routers, cloud infrastructure, virtual machines, or operating systems.
Over the years, SSH became the de facto tool for remote server administration with its high reliability and security features. SSH is a highly potential tool both for the administrator and the hacker alike. It requires excellent professional competency and technical insight to tweak SSH to keep attackers away and stop them from performing malicious activities.
Work From Home: Implementation Challenges
Unsurprisingly, SSH and various other tools that rely on SSH protocol are the most widely used solutions for making WFH a reality worldwide. In an office environment, the system administrator has absolute control over the security and user-level operations. So they can easily manage the remote access or user activities. Security and comfort never go hand-in-hand, not just in computing but everywhere in life. People bear the constraining inconvenience of seatbelts not because of the safety; instead, it’s an attempt to avoid penalties. Working from their personal computer is an irresistible option for employees. But such an opaque system with no administrative control is a nightmare for the system admins.
Let’s see few issues we are facing while allowing remote working for employees.
- Poorly managed ssh clients.
In an office environment, the security team takes care of all security threats by implementing proper access control measures, timely software updates, and other vulnerability resolution steps. When it comes to personal computing, comfort and convenience take the primary role, putting security on the back burner. For instance, if the firewall keeps alerting about your favorite application, the majority would choose to disable the firewall instead of resolving the vulnerability. You don’t have the privileges to download, execute, install, or transfer files on your office computer. But on your personal computer, you make the decisions. Third-party application installations with scant consideration for security can convert your device into a breeding ground of viruses and trojans. When a user makes SSH connections from such vulnerable devices, the risk of security compromises is very high.
2. Irresponsible Users
Companies try to make WFH easier for the employees by enabling auto-login to their systems through SAML or key-based authentication. It relieves the user from the worries of remembering the passwords and typing them correctly. Except for some companies that require a VPN to access their internal network, the connection establishment is instantaneous and straightforward. The potential risks of such automated logins are many. If the certs are not adequately secured, anyone can steal them and use them to gain unauthorized access. Since there are no other authentication checks, such access can be catastrophic. There are strict access control measures and monitoring systems in an office environment. But in the WFH setup, the possibility of login sharing and impersonation stands high. Sometimes people may keep their sessions open even after their work hours. Such idle active connections can be dangerous if the system is compromised or others can access it.
3. Access Management Issues
Setting up a role-based Access control that creates access and authentication rules based on teams, job profiles, software platforms, or competency levels is possible in an office environment. But in the WFH environment, people work from different locations and even timezones, making such centralized management quite tricky.
For instance, a team member might have configured multiple ssh keys on different devices. In the event of his termination or resignation, the admin has no way to confirm whether he retains any keys or not. As a preventive measure, he changes the login credentials of servers or systems he has access. Imagine the volume of work involved in doing this on hundreds of production servers to remove one employee. What if another one resigns the next day? Sharing the new password through google forms or excel sheets is much more vulnerable than using a well-structured MIS for the same. Similarly, timely updates about team change or access change may not communicate efficiently in a WFH mode, leading to operational and data security issues.
4. Security Compliance
As part of protecting customer data and avoiding fraud, critical industries such as Finance, insurance, or health care insist on some mandatory security compliance on the servers that store customer data. For instance, the credit card industry requires all servers that allow card-based payment to be Payment Card Industry Data Security Standard (PCI DSS) compliant. Getting your server PCI Compliance involves a set of stringent security checks, such as application vulnerability management, firewall configurations, and access logs. It puts the server admin in a problematic situation. If he tweaks the servers according to the security compliance guidelines, it can affect employees’ productivity. But a compromise on the security aspects can be fatal to the organization.
As an alternative, SSH Jump servers or SSH bastion servers, an intermediary host that accepts connection requests from the end user and establishes a secure connection with the destination server without any performance issue, has become the favorite option for System admins worldwide.
What is an SSH Jump Server / SSH Bastion host?
A SSH jump server is a security-hardened linux server via which we can access all the other servers . ie, when a user wants to connect with the destination servers, he should login to the Jump server first. From there he can access/ssh to remote servers. Server administrators can restrict SSH access to the server only from the jump server, eliminating the risks of accepting connection requests from ssh clients from random locations. These SSH Bastion servers make life much easier for the employees and give great relief for the admins regarding the security elements.
$ssh user@jumpserver From the gateway server, we can access the remote servers either via password authentication or key based authentication. The password less automatic login feature makes the client happy and improves his productivity levels. If the employee is terminated or resigned, the admin can secure the entire system by disabling his ssh access to the jump server alone. He no longer needs to worry about the copies of ssh certs on the employee’s home computer.
Limitations of Open SSH Jump servers / Bastion Servers
Even though SSH jump servers address some of the crucial worries of system administration, it also has some limitations. The open SSH jump server keeps SSH certs, often in plain text format, of remote servers to enable password less login for the users. If someone hacks the ssh bastion server, he gets easy access to the remote servers and can unleash his vicious mind for any level of malicious activities.
Since the ssh bastion hosts are responsible only for authentication, the activity logs on the remote server are inaccessible for the mandatory security audit to achieve security compliance.
Since the jump servers use key-based authentication only for the SSH user, they need to keep the root password ready for performing “su” operations. Similarly, we can’t use jump servers to configure autologin to web applications such as WHM, Plesk, or DC portal, that requires root login. Such situations necessitate the user to share or store the root password in different locations, often insecure browser extensions, and is a significant security concern.
A jump server follows the same procedures as any standard Linux server for adding or removing users and configuring access restrictions. Due to the complexity of the process, some admins may not be enthusiastic about making these changes regularly. It leaves the server in a precarious situation of unauthorized user access and privilege escalation.
Changing passwords at regular intervals is a good security policy. But in a jump server setup, when you change the password or cert of a remote server, the admin has to update the entries in the jump server manually.
Like other Linux servers, jump servers are also prone to hardware failures, software issues, or network outages. If your ssh bastion host lacks proper redundancy or failover systems, an unfortunate event of it’s failure will make you clueless and helpless.
In short, jump servers are not a silver bullet for all the problems a system admin experiences while making WFH a working reality. Here comes the necessity of a secure SSH jump server Ezeelogin
Ezeelogin – The easiest, safest and secure way of SSH management
Ezeelogin helps to converts your existing linux server to a secure SSH Jump Server for the easy access and management of the remote servers, routers, switches etc. Ezeelogin features help you to meet various security complainces like PCI DSS, HIPPA, and many more. the safest and most potent tool for remotely managing Linux servers, VPS, Virtual instances, and many other digital entities.
Important characteristics of Ezeelogin:
• Easy Installation: You only need to download and execute the installation script. It takes care of the dependencies and is highly customizable to suit your personal preferences.
• Self-managed / Self-hosted Servers: You can convert any of your VPS or servers as Ezeelogin Jumpserver. The customer is the sole authority in managing the server.
• No agent software requirement: Ezeelogin doesn’t require any agent software on the remote server for its functioning.
•Two Factor Authentication- 2FA – Typical jump servers rely on the ssh protocol and permit the login if the user name and password are correct. Such a system lacks any measures to confirm the identity of the user. Anyone can get into the server if he can access the credentials either by sharing or stealing. Here, in addition to password, the user must confirm his identity by entering the authentication token received on his 2FA device or application. At the moment, Ezeelogin supports google authentication, Yubikey, Duo and Access Keyword.
• Security Compliance: Ezeelogin features such as SSH session recording, audit log etc. make it easier for you to achieve various security complainces like HIPPA, PCI-DSS, etc.
• Seamless Migration: You can easily migrate the existing ssh bastion server and its users to another server and transfer the license to the new IP without complexities or downtime.
• Continuous Availability: Ezeelogin’s HA cluster features helps to avoid bastion server downtime. Even if the ezeelogin installed SSH bastion server fails, you can instantly route the connections through slave server.
• Web GUI of SSH Jump Server: User friendly web interface make it very easy for the users to perform the operations like server and user management.
• Integrate with LDAP : Easily map your LDAP users and user groups to ezeelogin.
• Access Control : Completely manage and restrict user’s access to remote servers, restrict the user’s actions on each servers etc.
• Command Guard : Sometimes, we need to allow our employees to execute only few commands or restrict them from executing dangerous commands on remote servers etc. Command guard feature allows to achieve this.
There are many more features that helps the organizations to safely grand remote working facilities for their employees. Other big headaches for the organizations are how to meet different cyber security complainces when they allow remote server administration or remote working facilities for their staffs. Let’s see how to achieve this using ezeelogin bastion server.
How to meet Security complainces using Ezeelogin when the employees works remotely?
- Detailed Logs and Reporting of employee activity in SSH
- Record SSH Sessions of your employees
- Integrate Google 2FA, DUO Security, Yubikey in SSH
- SSH Password and Key management for staff
- LDAP and SAML Authentication in SSH
- Integrate Okta, Onelogin authentication for SSH server access
- Privileged Access Management on Linux servers in SSH
- Role Based Access Control of staff in SSH
References