Я усиливаю сервер и пытаюсь создать ограничительный уровень для потенциального хакера даже с root-доступом к серверу, чтобы причинить вред.
Если пользователь получает root-доступ или пользовательский доступ к оболочке через, скажем, ssh, есть ли другой способ для пользователя получить доступ к системным командам, кроме как через доступные им команды оболочки? Хотя cd
является встроенной командой и не может быть легко удалена, так как оболочка bash сама выполняет эту команду, см .: ( https://unix.stackexchange.com/questions/11454/what- есть-разница-между-встроенной-командой-и-одним-тем-не-) см .: ( https://unix.stackexchange.com/questions/38808/why-is -cd-not-a-program ), если бы ls
и ps
были отключены на сервере, будет ли у злоумышленника другой способ выполнить системные команды?
Предположим, эта безопасная копия (scp) была удалена в системе, и они не могли напрямую загружать полезные данные на сервер через scp, и у них был только доступ к оболочке (не физический доступ).
РЕДАКТИРОВАТЬ: Еще один элемент этого вопроса: используются ли в уязвимостях выполнения произвольного кода команды bash? Итак, будет ли эта процедура усиления системы делать что-нибудь, чтобы предотвратить, скажем, эксплойт Apache, получивший полный доступ root.
Вы можете укрепите свою систему всем, что вам нравится, но если вы предоставите доступ к оболочке, всегда есть выход. Если ls
отключен, echo *
все равно покажет вам, какие файлы и каталоги там есть. Вы никогда не должны предоставлять доступ к вашей системе людям, которым вы не доверяете (до определенного уровня).
Ваш гипотетический потенциальный хакер, вероятно, попытается получить root, а не созданный вами идентификатор пользователя. А ограничение root является еще более сложной задачей, особенно если вы хотите иметь возможность каким-то образом управлять ящиком.
Настройка среды chroot
, вероятно, лучший вариант, но даже это может оказаться довольно сложным. Вам нужны копии всех двоичных файлов, библиотек и т. Д. В вашей среде chroot.
Selinux здесь не поможет. По крайней мере, если вам нужно управлять ящиком в течение более длительного периода.
В конце концов, система должна быть пригодна для обычных пользователей. По крайней мере: это будет причиной для разрешения входа в систему. Там, где я работаю, у нас тоже есть такая «жесткая» система; это совершенно бесполезно. Если мне нужно что-то сделать в / через эту систему, мне нужно обойти «усиление защиты», что не так уж и сложно.
Если вам действительно необходимо, выберите вариант chroot
как единственный жизнеспособный вариант. В противном случае пересмотрите процесс и безопасность вокруг него. Наличие неработающей системы для обычных пользователей никогда не является ответом.
Вы можете изучить создание одноразовых виртуальных систем.