If you absolutely have to use sudo on the Bastion Host force it to OTP only. And make sure you can easily match incoming to outgoing. Also make sure you log outgoing connections. If you are forced to use one, send logs to a safer one-way storage encrypted and put tampering triggers everywhere you can in the Bastion Host. In another it let them hijack an admin's password by reading his sudo. In one case it basically hid where the attack came from (compromised logs and all). Both times it practically gave the attackers the highest access. Twice I've seen Bastion Hosts compromised. The user/root boundary can be a lot thinner than people expect, so I get why you'd want to point out that reliance on the attacker not escalating should be met with an evaluation of that boundary, but I think it may be understating the boundary to unconditionally not trust a host based firewall, or to say that getting onto the bastion itself is enough to disable the firewall when it does indeed require escalation. You can harden your kernel, you can execute user's shells in constrained environments like docker containers or restricted shells, leverage sandboxing technologies like apparmor or selinux, etc. There's also a lot you can do to harden that boundary. The linked article doesn't discuss anything that would make that harder, although perhaps practices like staying patched and minimizing attack surface are somewhat assumed (they do bring up choosing your OS based on minimizing attack surface for example). I think it's probably reasonable when performing your incident response or even threat modeling to assume the attacker has or could escalate privileges. You can still connect using the SSH command, using proxy command in OpenSSH, but no public IP or bastion host is required. Other than those two complains, it's good recommendations.Ī final recommendation: If you use AWS though, consider using Session Manager instead of SSH and drop the bastion host. Users do not need sudo/root privileges on a jump host. None of the accounts need any privileges other than the most basic. Create all the accounts you need to provide individual accounts for the staff that need to access the bastion host, you will need that as things like HIPAA require named accounts for auditing. Limiting the number of users is weird, and not recommended. I do agree that you should only allow SSH from a few known IPs. It's better than nothing, but consider using a firewall that's managed on a via a separate management network. There's a few weird things, but it's mostly okay.ĭo not trust the firewall on the bastion host, if an attack can get into the bastion host, they can disable the firewall, so it cannot be used to limit egress.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |