Я пытаюсь составить политику безопасности для набора серверов Linux. В моей организации 8 человек, которым требуется доступ корневого уровня через SSH.
В прошлой компании мое решение заключалось в том, чтобы разрешить только ключи RSA и дать каждому пользователю свой собственный ключ.
Чтобы предоставить привилегии root, я установил UID равным 0. Это избавило от необходимости настраивать sudo или su, которые в любом случае кажутся просто sudo su - или sudo / bin / bash. Это также позволило мне сделать следующее.
Я исправил Bash, чтобы записать возвращаемое значение getlogin () и команду в syslog. Затем у меня был журнал всего, что работает на серверах, и имена пользователей, привязанные к пользователям. Если бы я использовал su или sudo, я бы просто получил root-права.
Я нахожусь в новом состоянии прямо сейчас в новой компании и задаюсь вопросом, есть ли у кого-нибудь политика, которую они используют и нравится.
Мы используем sudo, настроенный для разрешения команд из группы. Чтобы предотвратить использование sudo -i или sudo bash, я установил псевдоним, включающий все известные оболочки, которые я запрещаю использовать! в определении того, что может делать группа. Таким образом, все команды, выполняемые с помощью sudo, записываются в системный журнал. Единственная оболочка, которую я установил и разрешил, это корень, который регистрирует все, что из него было сделано.
Cmnd_Alias SHELLS= /bin/sh, /bin/ksh, /bin/bash, /bin/zsh, /bin/csh, /bin/tcsh, /bin/login, /bin/su
%admin ALL = (ALL) ALL, !SHELLS
Очевидно, что ничто не может помешать админу
cp /bin/bash /tmp/shell
sudo /tmp/shell
чтобы обойти эту безопасность, но все же вы даете им права root, вы все равно должны им доверять ...
У меня нет никаких рекомендаций, чтобы дать вам, когда дело доходит до входа в систему или привилегий, так как я не понимаю, зачем вам это нужно. Либо вы доверяете своим администраторам и даете им доступ, либо нет - и получаете новых администраторов.
Имея root-доступ, мне часто нравится подход Пауски. Я часто устанавливаю sudo all для администраторов, что позволяет им sudo su а также запускать через него команды. .bash_history все еще входит в сферу охвата, что позволяет пересмотреть, если вопрос возникнет в будущем.
Решение skinp - это скорее административная политика, чем что-либо еще, как указывали другие, это небезопасное решение. Требование, чтобы все команды root выполнялись через sudo, в наши дни является обычной политикой.
В зависимости от ваших требований я часто использую что-то вроде rootsh для централизованной вырубки. В прошлом оболочка имела проблемы с функциональностью, что мешало ей всегда быть идеальной. Мне нравится ваше решение для исправления bash.
Выдавать UID 0 для учетных записей пользователей абсолютно беспорядочно. Система подвержена риску простых ошибок и, скорее всего, нарушит системные соглашения. Я бы во всех случаях не одобрял этого.
Если у вас есть бизнес-обоснование, требующее, чтобы персонал, не являющийся ИТ-специалистом или не являющийся администратором, имел полный root-доступ, предоставляя им доступ к rootsh или ведение журнала из sudo является абсолютным требованием.
В конечном итоге любой, у кого есть доступ к привилегиям root, скорее всего, получит легкий вектор атаки. Контрольный журнал - это действительно лучшая практика, но введение дополнительных ограничений мало влияет на безопасность, в то же время затрудняя администраторам выполнение своей работы.