Различия
Здесь показаны различия между двумя версиями данной страницы.
| Предыдущая версия справа и слева Предыдущая версия Следующая версия | Предыдущая версия | ||
|
wiki:руководство_по_ubuntu_server:безопасность:user_management [2012/06/16 21:47] [Политика паролей] |
wiki:руководство_по_ubuntu_server:безопасность:user_management [2012/06/16 22:47] (текущий) [Иные соображения безопасности] |
||
|---|---|---|---|
| Строка 131: | Строка 131: | ||
| ====Иные соображения безопасности==== | ====Иные соображения безопасности==== | ||
| - | Many applications use alternate authentication mechanisms that can be easily overlooked by even experienced system administrators. Therefore, it is important to understand and control how users authenticate and gain access to services and applications on your server. | + | Многие приложения используют альтернативные механизмы аутентификации, которые могут быть запросто пропущены даже опытными системными администраторами. Поэтому важно понимать и контролировать как пользователи авторизуются и получают доступ к сервисам и приложениям на вашем сервере. |
| - | ===SSH Access by Disabled Users=== | + | ===Доступ по SSH заблокированными пользователями=== |
| - | Simply disabling/locking a user account will not prevent a user from logging into your server remotely if they have previously set up RSA public key authentication. They will still be able to gain shell access to the server, without the need for any password. Remember to check the users home directory for files that will allow for this type of authenticated SSH access. e.g. /home/username/.ssh/authorized_keys. | + | Обычное отключение/блокирование не исключает удаленного подключения пользователя к серверу, если ему предварительно была установлена аутентификация по открытому ключу RSA. Такие пользователи будут получать доступ к консольной оболочке (shell) на сервере без необходимости ввода какого-либо пароля. Не забывайте проверять пользовательские домашние каталоги на файлы, которые позволяют подобный тип авторизации по SSH, например, /home/username/.ssh/authorized_keys. |
| - | Remove or rename the directory .ssh/ in the user's home folder to prevent further SSH authentication capabilities. | + | Удаление или переименование каталога .ssh/ в домашнем каталоге пользователя предотвратит дальнейшую способность аутентификации по SSH. |
| - | Be sure to check for any established SSH connections by the disabled user, as it is possible they may have existing inbound or outbound connections. Kill any that are found. | + | Убедитесь что проверили любые установленные SSH соединения заблокированных пользователей, поскольку могут остаться входящие или исходящие соединения. Убейте все, которые найдете. |
| - | Restrict SSH access to only user accounts that should have it. For example, you may create a group called "sshlogin" and add the group name as the value associated with the AllowGroups variable located in the file /etc/ssh/sshd_config. | + | Ограничьте SSH доступ только для учетных записей пользователей, которым они требуются. Например, вы можете создать группу с названием %%"sshlogin"%% и добавить имя группы в качестве значения для переменной AllowGroups, находящейся в файле /etc/ssh/sshd_config. |
| - | + | <code>AllowGroups sshlogin</code> | |
| - | AllowGroups sshlogin | + | |
| - | + | ||
| - | Then add your permitted SSH users to the group "sshlogin", and restart the SSH service. | + | |
| + | Затем добавьте ваших пользователей, которым разрешен SSH доступ, в группу %%"sshlogin"%% и перестартуйте SSH сервис. | ||
| + | <code> | ||
| sudo adduser username sshlogin | sudo adduser username sshlogin | ||
| sudo service ssh restart | sudo service ssh restart | ||
| + | </code> | ||
| - | ===External User Database Authentication=== | + | ===Аутентификация по внешней базе данных=== |
| - | Most enterprise networks require centralized authentication and access controls for all system resources. If you have configured your server to authenticate users against external databases, be sure to disable the user accounts both externally and locally, this way you ensure that local fallback authentication is not possible. | + | Большинство корпоративных сетей требуют централизованной аутентификации и контроля доступа для всех системных ресурсов. Если вы настроили свой сервер для аутентификации пользователей по внешней базе данных, убедитесь, что вы отключаете учетные записи как внешние, так и локальные, таким образом вы будете уверены что откат на локальную аутентификацию невозможен. |
| ---- | ---- | ||
