If you have keystroke logging enabled on the agents than you will get all activity run even if they nexec into a shell on the box.
There’s nothing insecure about nsh here – the problem might be w/ granting nsh access in general to your users. you may not want them to have nsh access to the systems. you can block down nsh access a couple of ways:
1 – look at the ‘command’ authorizations in rbac and restrict what nsh and even nexec/shell commands can be run
2 – in 8.1 there’s a NSH_Proxy.Connect authorization. If you setup a nsh proxy, and then restrict communication so all nsh traffic must come from the appservers/nsh proxy, you can grant that connect access to only roles you want to have nsh access.
3 – would be a combination of 1 and 2.
The suggestions you've made to mitigate the risks sound very useful. However at this stage I'm interested in documenting the lack of logging and ability to cache credentials at the moment.
If I grant them permissions to specific nsh commands, since that then blocks any non-granted commands, are there impacts to what is available via the UI? I would expect that external commands in a blpackage would be affected, but what about other file deploy and config file modifications?
What lack of logging?
And what is the issue w/ credential cachine ?
My understanding is that there is no logging when you enter other shells such a Korn shell.
In terms of caching administrative credentials, this is not a ideal situation for security reasons as it may breach organisations security policies so should be strictly controlled.
1 of 1 people found this helpful
If you have the keystroke logs enabled on the agent, then you will get keystrokes sent to the target even if you nexec a shell.
The creds are cached in the context of the workstation, so the security posture of the workstation should be sufficient to protect the credentials. If it’s not, then I think you have larger problems than bladelogic caching credentials.
The session credentials have a lifetime, so you can change that to your liking.
Look at it this way – you log into your desktop and use your AD credentials as long as you are logged in. your credentials are effectively cached for the lifetime of your session, so you can access network shares, applications that authenticate w/ Kerberos tickets, etc. it’s much the same as that. how are those kinds of applications secured in your environment? Must the user enter a passwd everytime they try to access a network share on the domain?
I would go the nsh proxy route. Don’t limit the command authorizations, but allow only certain role to use nsh via the nsh proxy.