"command risk" option works perfectly with PKCSH shell but it does not apply when connecting via ssh-relay option(via myaccess page).
ssh-relay option has no advantage without "command risk" option, because via "ssh-relay option" user can reset password(root user) and do(damage) whatever he/she wants without any restriction.
by: Muhammad S. | over a year ago | Other
Comments
Applying "Command Risk" option is 2 step process on a high level. First - The Final command needs to be found out from a sequence of Keystrokes being issued to provide final command and then Second - Apply the Risk.
Next, important Factor is the presence of Agent.
For example, to block ‘ifconfig’ command on an agent and subsequently apply the Command Risk, we depend on Command Audits which are fetched from the hooked system calls; whereas the SSH Relay is an agent-less solution where we would not have any control over the commands and may not even have the complete list of key strokes of the commands.
The SSH Relay just gives us the key strokes in the order which they are typed in and those key strokes can be either of the following.
1. ‘ifconfig’ – when user types All the characters to form the command.
2. ‘ifc<tab>’ – when user uses the Tab Completion to execute the command.
3. ‘<UP><UP>’ – when user used the Arrow keys to go to the command in his history to execute the command.
4. ‘<Ctrl+R>if’ – when user takes the help of Reverse Search in his History to fetch the command.
The command could be in a different Shell Script too. These are because The Linux Shell provides multiple ways to execute the command.
We need the exact command to control the command and to apply the Command Risk. But it would be really complex to figure out the final command just out of the provided key strokes.
So, being said that we are looking into other possible ways to fetch the exact final command by just not relying on the Key Strokes to provide a more deterministic solution.
Currently, this is not targeted for any specific release, but based on the outcome of the research, will be scoped accordingly.
Hi thanks for the details. Hope to have a solution ready asap.
So I am confused - what is the actual idea for the desired enhancement?
Just to add my own two cents, I have trouble with this statement:
"ssh-relay option has no advantage without "command risk" option, because via "ssh-relay option" user can reset password(root user) and do(damage) whatever he/she wants without any restriction"
1) Customers are aware of the risks of giving out administrator or root control over systems. What they are missing is previous authorization to enter and an audit trace to understand who was "root" when damage was done. SSH-Relay provides that out of the box.
2) If customer is worried that user can change password and do damage, it is simpler to educate them on principles of least privilege and configure an admin user with no rights to change the password and harden the system (if anything, this idea could change to provide a set of hardening scripts just as other competitors deploy GPO's on Windows systems with the same effect).
3) Unless there is an agent installed, it would be very hard to audit commands as Joy points out in his message. I would even question if others can do this without an agent installed.
Cheers,
Jean-Paul