Malware spreading through jump server and SSH data transfer

Question

Can someone explain to me how jump servers mitigate the risk of malware infection please?

Whilst I understand some of the benefits of having a jump server as an extra layer of defence i.e. authentication, 2FA etc, however, say if a user's workstation or laptop is infected with a malware, and they can access a Jump server over SSH/RDP - can the malware not spread over this SSH session and eventually to the servers behind it? If yes, how is jump server helping here?

On a separate note, how can you disable the transfer or exfiltration of data from the Jump server via SSH/SCP - for both a privileged and non-privileged user who can access the Jump server? Is this even possible? Asking this from an insider threat perspective.

Answer 1

For the first part of your question:

1. If the jump server is configured with password authentication, then the malware has to find a way to get the password in order to initiate a SSH session.

2. If it's key-based authentication, the key is stored encrypted on the file system so it has to guess the passphrase.

3. With kerberos authentication the malware can use the user's ticket to initiate a SSH session with the jump server. But by default SSH tickets are non-forwardable so it won't be able to use the same ticket for another session with a server behind the jump server. So in this scenario with non-forwardable kerberos tickets the jump server prevent the propagation of the malware through SSH.

For the second part:

Secure copy protocol (SCP) is a means of securely transferring computer files between a local host and a remote host or between two remote hosts.

So you can't disable the transfer of data if the connection is authorized.

See this post

Answer 2

It is highly advisable to use two factor authentication in jump servers. The whole purpose of having a jump server is to segregate a "more trusted" set of resources from a "less trusted" set of resources. For example, by virtue of your desktops being exposed to Internet (and potentially phishing via email), they constitute a less trusted zone. The bar to "jump" into the more trusted (say, servers) zone must be higher than for being in the least trusted zone. Now, if your password got compromised or keys got used or you have ticket forwarding, having a second factor will protect against lateral movement. Malware tends to jump around and spread - having a second factor for protocols such as RDP/SSH prevents malware from abusing those management protocols.

Hope that helps.