Различия
Здесь показаны различия между двумя версиями данной страницы.
| Предыдущая версия справа и слева Предыдущая версия Следующая версия | Предыдущая версия | ||
|
wiki:руководство_по_ubuntu_server:безопасность:user_management [2012/06/16 19:05] [Безопасность профиля пользователя] |
wiki:руководство_по_ubuntu_server:безопасность:user_management [2012/06/16 22:47] (текущий) [Иные соображения безопасности] |
||
|---|---|---|---|
| Строка 67: | Строка 67: | ||
| Когда создается новый пользователь, утилита adduser создает, соответственно, новый именной каталог **/home/username**. Профиль по умолчанию формируется по содержимому, находящемуся в каталоге /etc/skel, который включает все основы для формирования профилей. | Когда создается новый пользователь, утилита adduser создает, соответственно, новый именной каталог **/home/username**. Профиль по умолчанию формируется по содержимому, находящемуся в каталоге /etc/skel, который включает все основы для формирования профилей. | ||
| + | Если ваш сервер является домашним для множества пользователей, вы должны уделять пристальное внимание правам доступа на пользовательские домашние каталоги для поддержания конфиденциальности. По умолчанию пользовательские домашние каталоги создаются с правами чтения/выполнения для всех. Это означает, что все пользователи просматривать и получать доступ к содержимому других домашних каталогов. Это может не подходить для вашего окружения. | ||
| - | If your server will be home to multiple users, you should pay close attention to the user home directory permissions to ensure confidentiality. By default, user home directories in Ubuntu are created with world read/execute permissions. This means that all users can browse and access the contents of other users home directories. This may not be suitable for your environment. | + | 1. Для проверки прав доступа на домашние каталоги существующих пользователей используйте такой синтаксис: |
| + | <code>ls -ld /home/username</code> | ||
| + | Следующий вывод показывает, что каталог /home/username имеет доступ на чтение для всех: | ||
| + | <code>drwxr-xr-x 2 username username 4096 2007-10-02 20:03 username</code> | ||
| + | 2. Вы можете удалить права чтения для всех, используя следующий синтаксис: | ||
| + | <code>sudo chmod 0750 /home/username</code> | ||
| + | <note>Некоторые склоняются к тенденции использовать опцию рекурсии (-R) без разбора, которая изменяет все дочерние каталоги и файлы, хотя это необязательно и может приводить к иным нежелательным последствиям. Родительский каталог сам по себе запретит неавторизованный доступ к любому своему содержимому.</note> | ||
| - | To verify your current users home directory permissions, use the following syntax: | + | Более эффективный подход к данному вопросу будет в изменении глобальных прав доступа по умолчанию для **adduser** при создании домашних каталогов. Просто отредактируйте файл /etc/adduser.conf, изменив переменную DIR_MODE на что-то более подходящее, после чего все новые домашние каталоги будут получать корректные права доступа. |
| - | + | <code>DIR_MODE=0750</code> | |
| - | ls -ld /home/username | + | 3. После исправления прав доступа к каталогам, используя любую из ранее упоминавшихся методик, проверьте результаты используя следующую команду: |
| - | + | <code>ls -ld /home/username</code> | |
| - | The following output shows that the directory /home/username has world readable permissions: | + | Результат ниже показывет, что права на чтение для всех удалены: |
| - | + | <code>drwxr-x--- 2 username username 4096 2007-10-02 20:03 username</code> | |
| - | drwxr-xr-x 2 username username 4096 2007-10-02 20:03 username | + | |
| - | + | ||
| - | You can remove the world readable permissions using the following syntax: | + | |
| - | + | ||
| - | sudo chmod 0750 /home/username | + | |
| - | + | ||
| - | Some people tend to use the recursive option (-R) indiscriminately which modifies all child folders and files, but this is not necessary, and may yield other undesirable results. The parent directory alone is sufficient for preventing unauthorized access to anything below the parent. | + | |
| - | + | ||
| - | A much more efficient approach to the matter would be to modify the adduser global default permissions when creating user home folders. Simply edit the file /etc/adduser.conf and modify the DIR_MODE variable to something appropriate, so that all new home directories will receive the correct permissions. | + | |
| - | + | ||
| - | DIR_MODE=0750 | + | |
| - | + | ||
| - | After correcting the directory permissions using any of the previously mentioned techniques, verify the results using the following syntax: | + | |
| - | + | ||
| - | ls -ld /home/username | + | |
| - | + | ||
| - | The results below show that world readable permissions have been removed: | + | |
| - | + | ||
| - | drwxr-x--- 2 username username 4096 2007-10-02 20:03 username | + | |
| ====Политика паролей==== | ====Политика паролей==== | ||
| - | A strong password policy is one of the most important aspects of your security posture. Many successful security breaches involve simple brute force and dictionary attacks against weak passwords. If you intend to offer any form of remote access involving your local password system, make sure you adequately address minimum password complexity requirements, maximum password lifetimes, and frequent audits of your authentication systems. | + | Строгая политика паролей - один из наиболее важных аспектов вашего подхода к безопасности. Много удачных прорывов безопасности использовали для атак простейший взлом (brute force) и подбор паролей по словарю против слабых паролей. Если вы намереваетесь использовать любую форму удаленного доступа с использованием вашей локальной системы паролей, убедитесь, что вы назначили адекватные минимальные требования к паролю, максимальное время жизни пароля и часто проверяете вашу систему аутентификации. |
| - | ===Minimum Password Length=== | + | ===Минимальная длина пароля=== |
| - | By default, Ubuntu requires a minimum password length of 6 characters, as well as some basic entropy checks. These values are controlled in the file /etc/pam.d/common-password, which is outlined below. | + | По умолчанию Ubuntu требует минимальную длину пароля в 6 символов, также как и некоторые основные проверки на разброс значений. Эти параметры управляются файлом /etc/pam.d/common-password и приведены ниже: |
| + | <code>password [success=2 default=ignore] pam_unix.so obscure sha512</code> | ||
| + | Если вы хотите установить минимальную длину в 8 символов, измените соответствующую переменную на min=8. Изменения приведены ниже: | ||
| + | <code>password [success=2 default=ignore] pam_unix.so obscure sha512 min=8</code> | ||
| + | <note>Базовые проверки на качество и минимальную длину пароля не применяются к администратору, использующего команды уровня sudo для настройки нового пользователя.</note> | ||
| - | password [success=2 default=ignore] pam_unix.so obscure sha512 | + | ===Время жизни пароля=== |
| - | If you would like to adjust the minimum length to 8 characters, change the appropriate variable to min=8. The modification is outlined below. | + | При создании учетных записей пользователей вы должны создать политику минимального и максимального времени жизни пароля чтобы заставлять пользователей менять их пароли по истечении определенного времени. |
| - | + | ||
| - | password [success=2 default=ignore] pam_unix.so obscure sha512 min=8 | + | |
| - | + | ||
| - | Basic password entropy checks and minimum length rules do not apply to the administrator using sudo level commands to setup a new user. | + | |
| - | + | ||
| - | ===Password Expiration=== | + | |
| - | + | ||
| - | When creating user accounts, you should make it a policy to have a minimum and maximum password age forcing users to change their passwords when they expire. | + | |
| - | + | ||
| - | To easily view the current status of a user account, use the following syntax: | + | |
| - | + | ||
| - | sudo chage -l username | + | |
| - | + | ||
| - | The output below shows interesting facts about the user account, namely that there are no policies applied: | + | |
| + | 1. Для простого просмотра текущего статуса учетной записи пользователя используйте следующий синтаксис: | ||
| + | <code>sudo chage -l username</code> | ||
| + | Вывод, приведенный ниже, показывает интересные факты об учетной записи пользователя, а именно что нет никаких примененных политик: | ||
| + | <code> | ||
| Last password change : Jan 20, 2008 | Last password change : Jan 20, 2008 | ||
| Password expires : never | Password expires : never | ||
| Строка 129: | Строка 111: | ||
| Maximum number of days between password change : 99999 | Maximum number of days between password change : 99999 | ||
| Number of days of warning before password expires : 7 | Number of days of warning before password expires : 7 | ||
| - | + | </code> | |
| - | To set any of these values, simply use the following syntax, and follow the interactive prompts: | + | 2. Для установки этих значений просто используйте следующую команду и следуйте интерактивным подсказкам: |
| - | + | <code>sudo chage username</code> | |
| - | sudo chage username | + | Далее также пример того, как можно вручную изменить явную дату истечения действия пароля (-E) на 01/31/2008 (американский вариант даты - прим. пер.), минимальный срок действия пароля (-m) на 5 дней, максимальный срок действия (-M) на 90 дней, период бездействия (-I) на 5 дней после истечения срока пароля и период предупреждений (-W) на 14 дней до истечения срока пароля. |
| - | + | <code>sudo chage -E 01/31/2011 -m 5 -M 90 -I 30 -W 14 username</code> | |
| - | The following is also an example of how you can manually change the explicit expiration date (-E) to 01/31/2008, minimum password age (-m) of 5 days, maximum password age (-M) of 90 days, inactivity period (-I) of 5 days after password expiration, and a warning time period (-W) of 14 days before password expiration. | + | 3. Для проверки изменений используйте ту же команду, что и упоминалась выше: |
| - | + | <code>sudo chage -l username</code> | |
| - | sudo chage -E 01/31/2011 -m 5 -M 90 -I 30 -W 14 username | + | Вывод команды ниже показывает новые политики, которые применяются к учетной записи: |
| - | + | <code> | |
| - | To verify changes, use the same syntax as mentioned previously: | + | |
| - | + | ||
| - | sudo chage -l username | + | |
| - | + | ||
| - | The output below shows the new policies that have been established for the account: | + | |
| Last password change : Jan 20, 2008 | Last password change : Jan 20, 2008 | ||
| Password expires : Apr 19, 2008 | Password expires : Apr 19, 2008 | ||
| Строка 151: | Строка 127: | ||
| Maximum number of days between password change : 90 | Maximum number of days between password change : 90 | ||
| Number of days of warning before password expires : 14 | Number of days of warning before password expires : 14 | ||
| + | </code> | ||
| ====Иные соображения безопасности==== | ====Иные соображения безопасности==== | ||
| - | 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=== | + | |
| - | + | ||
| - | 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. | + | |
| - | Remove or rename the directory .ssh/ in the user's home folder to prevent further SSH authentication capabilities. | + | ===Доступ по 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. | + | Обычное отключение/блокирование не исключает удаленного подключения пользователя к серверу, если ему предварительно была установлена аутентификация по открытому ключу RSA. Такие пользователи будут получать доступ к консольной оболочке (shell) на сервере без необходимости ввода какого-либо пароля. Не забывайте проверять пользовательские домашние каталоги на файлы, которые позволяют подобный тип авторизации по SSH, например, /home/username/.ssh/authorized_keys. |
| - | 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/ в домашнем каталоге пользователя предотвратит дальнейшую способность аутентификации по SSH. |
| - | AllowGroups sshlogin | + | Убедитесь что проверили любые установленные SSH соединения заблокированных пользователей, поскольку могут остаться входящие или исходящие соединения. Убейте все, которые найдете. |
| - | Then add your permitted SSH users to the group "sshlogin", and restart the SSH service. | + | Ограничьте SSH доступ только для учетных записей пользователей, которым они требуются. Например, вы можете создать группу с названием %%"sshlogin"%% и добавить имя группы в качестве значения для переменной AllowGroups, находящейся в файле /etc/ssh/sshd_config. |
| + | <code>AllowGroups sshlogin</code> | ||
| + | Затем добавьте ваших пользователей, которым разрешен 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. | + | Большинство корпоративных сетей требуют централизованной аутентификации и контроля доступа для всех системных ресурсов. Если вы настроили свой сервер для аутентификации пользователей по внешней базе данных, убедитесь, что вы отключаете учетные записи как внешние, так и локальные, таким образом вы будете уверены что откат на локальную аутентификацию невозможен. |
| ---- | ---- | ||
