-1

I am hardening a server and attempting to build a restrictive layer to a potential hacker even with root access to the server to do harm.

If a user gains root or user access to the shell via say ssh, is there any other way for a user to access system commands other than via the shell commands available to them? Although cd is a built-in command and could not be removed easily since the bash shell does that command itself see:(https://unix.stackexchange.com/questions/11454/what-is-the-difference-between-a-builtin-command-and-one-that-is-not) see:(https://unix.stackexchange.com/questions/38808/why-is-cd-not-a-program), If ls and ps were disabled on the server, would a intruder have another way to issue system commands?

Assuming that secure copy (scp) was uninstalled on the system and they could not directly upload a payload to the server via scp, and they only had shell access (not physical access).

EDIT: Another element to this question is do arbitrary code execution vulnerabilities typically use bash commands. So, is would this system hardening procedure do anything to prevent say an Apache exploit that gained full root access.

I'm Root James
  • 202
  • 1
  • 12
  • 2
    If someone gained shell access as root to a server, there are many ways to do harm. I would consider this a total compromise without any real level of protection left to you. `ls` and `ps` are nice programs, but an attacker can do much more damage with `vi`, `cat`, `kill`, `systemctl` or countless other programs. – Sven Aug 02 '18 at 14:54
  • 3
    There's always SELinux. That can save your bacon when nothing else will. – Michael Hampton Aug 02 '18 at 14:59
  • I am also building a list of other commands to remove/encrypt so doing damage with vi, cat, kill, etc. would not be within the scope of the thread I'm curious about here. For purposes of this question, ALL shell commands would be encrypted except for the script and password that would decrypt them into their expected locations. – I'm Root James Aug 02 '18 at 15:07
  • @MichaelHampton SELinux is an option for Red Hat & variants. Not much help in Debian/Ubuntu/Gentoo/... Also, root can usually change SELinux policies so if root is compromised you're still hosed. – doneal24 Aug 02 '18 at 16:50
  • 1
    @Super-cluser You can still do a lot of damage with echo and /lib/ld-linux.so. I agree with Sven that if root is compromised then the server is totally compromised. No way around this. – doneal24 Aug 02 '18 at 16:55
  • 1
    @DougO'Neal You can lock out root from changing SELinux policies. It's not even all that hard. Though you do have to have some other user who _can_ change the policies, of course... But of course that applies to the legitimate root user. If root is compromised through a zero-day or something, then SELinux will keep it contained. – Michael Hampton Aug 02 '18 at 18:41
  • Is there any risk in taking away all the permissions to "other" on the whole file system except the development user account (sudoer) and demand sudo for everything? – I'm Root James Aug 02 '18 at 22:27
  • Assuming there is at least one executable and root-writable file anywhere in the file system, an attacker should be able to use `echo` to replace its contents with whatever executable they please. – Harry Johnston Aug 03 '18 at 05:43
  • a read only file system with mayeb even no spot to write temp files to might help, especially if you have an selinux limited root acc. btw: why go for a full bash? chroot it somewhere where no binaries are atually installed. see. f.e. chrlogin – Dennis Nolte Aug 03 '18 at 07:50

1 Answers1

0

You can harden your system all that you like, but if you give shell access, there is always a way around. Is ls is disabled, echo * will still show you what files and directories are there. You should never give people that you do not trust (up to a level of course) shell access to your system.

Your hypothetical potential hacker will probably go try to get root and not the userID that you created. And limiting root is even more challenging, especially if you want to be able to manage the box somehow.

Setting-up a chroot environment is probably your best bet, but even that may prove rather difficult. You need copies of all the binaries, libraries etc. in your chroot environment.

Selinux is not any help here. At least not if you need to manage the box for a longer period.

In the end, the system still has to be usable for regular users. At least: that would be the reason to allow a login. Where I work, we also have such a 'hardened' system; it is utterly useless. If I need to do anything on/via this system, I need to circumvent the 'hardening', which is not all that difficult.

If you really must, go for the chroot option as the only viable option. Otherwise, rethink the process and security around it. Having an unworkable system for regular users is never the answer.

You may look at creating disposable virtual systems.

Ljm Dullaart
  • 151
  • 4