17.2 Контроль доступа пользователей (Controlling User Access)

Важнейший аспект безопасности как рабочей Linux-станции, так и Linux-сервера — это внедрение и применение средств управления доступом пользователей, ограничивающих возможности пользователей в системе. Ранее в книге мы рассматривали создание и управление пользователями, группами и правами доступа. Однако существуют дополнительные меры для повышения безопасности. В этой части главы рассматриваются следующие темы:

• Работать от root или нет?
• Реализация политики надёжных паролей
• Настройка ограничений для пользователей
• Отключение входа пользователей
• Аудит файлов

Начнём с обсуждения правильного обращения с учётной записью root.

Работать от root или нет?

Как обсуждалось ранее в книге, каждая Linux-система — будь то рабочая станция или сервер — включает учётную запись суперпользователя (superuser) с именем root. Эта учётная запись имеет полный доступ ко всем аспектам системы и требует крайне осторожного обращения. В этой части мы рассмотрим следующее:

• Правила использования учётной записи root
• Использование su
• Использование sudo

Правильное использование учётной записи root

Одна из типичных ошибок начинающих пользователей Linux — чрезмерное использование учётной записи root. У использования root есть своё место и время. Тем не менее большую часть работы в Linux следует выполнять под учётной записью обычного пользователя. Правило простое: использовать root только тогда, когда это действительно необходимо. Если задачу можно выполнить без root — так и следует поступить.

Почему это важно? Несколькими страницами ранее мы говорили о риске оставить работающую систему без присмотра. Представьте, какой хаос может учинить злоумышленник, обнаружив оставленную без присмотра систему, в которой выполнен вход от имени root! Он сможет получить доступ ко всем данным и скопировать их, внести серьёзные изменения в конфигурацию запущенных демонов и установить вредоносное программное обеспечение любого рода.

Одним словом, система с открытой сессией root представляет серьёзную угрозу безопасности, а оставленная без присмотра — критическую. У каждого пользователя, включая системного администратора (то есть вас!), должна быть стандартная учётная запись для обычной работы.

Если в процессе работы понадобится доступ уровня root, используйте команду su для временного получения привилегий суперпользователя. Рассмотрим, как это делается.

Использование su

К настоящему моменту вы должны хорошо знать, как работает su — в упражнениях книги мы пользовались ею множество раз. Эта команда позволяет сменить учётную запись пользователя в командной строке. Синтаксис: su параметры учётная_запись. Если учётная запись не указана, su переключает на root. Наиболее полезные параметры su:

• – Загружает переменные окружения пользователя. Именно поэтому мы всегда использовали команду su – для переключения на root: она переключает в root и загружает переменные окружения root.
• –c команда Переключает на указанную учётную запись и выполняет заданную команду.
• –m Переключает на указанную учётную запись, сохраняя текущие переменные окружения.

Команда su станет вашим лучшим другом как системного администратора. Однако иногда другим пользователям также требуется доступ уровня root. Предоставить им ограниченный доступ позволяет sudo.

Использование sudo

Предположим, у вас в Linux-системе есть опытный пользователь — программист, менеджер проекта или администратор баз данных. Таким пользователям часто бывают нужны некоторые команды уровня root. Но стоит ли давать им ваш пароль root? Скорее всего, нет. Вы хотите разрешить им выполнять лишь ограниченный набор команд, требующих привилегий root, но не предоставлять полного доступа. Именно для этого предназначен sudo.

Команда sudo позволяет заданному пользователю выполнять команды от имени другой учётной записи. Как и su, это может быть любая учётная запись в системе; однако чаще всего sudo используется для выполнения команд от имени root. sudo использует файл /etc/sudoers, чтобы определить, какой пользователь имеет право выполнять какие команды. В файле используются следующие псевдонимы для описания разрешений:

• User_Alias — задаёт пользователей, которым разрешено выполнять команды.
• Cmnd_Alias — задаёт команды, которые разрешено выполнять.
• Host_Alias — задаёт узлы, на которых разрешено выполнять команды.
• Runas_Alias — задаёт имена пользователей, от имени которых разрешено выполнять команды.

Рис. 17-3. Редактирование /etc/sudoers с помощью visudo.

Для редактирования файла /etc/sudoers необходимо выполнить команду visudo от имени root. Файл открывается в редакторе по умолчанию (обычно vi). Изменения записываются во временный файл /etc/sudoers.tmp до их сохранения. Это показано на рис. 17-3.

На большинстве дистрибутивов файл sudoers по умолчанию настроен так, что пользователи должны вводить пароль root при использовании sudo. Очевидно, такая конфигурация не имеет смысла: если пользователь уже знает пароль root, зачем настраивать sudo? Эта конфигурация задана следующими строками в sudoers:

# In the default (unconfigured) configuration, sudo asks for the root password.
# This allows use of an ordinary user account for administration of a freshly
# installed system. When configuring sudo, delete the two
# following lines:
Defaults targetpw   # ask for the password of the target user i.e. root
ALL     ALL=(ALL) ALL   # WARNING! Only use this together with 'Defaults targetpw'!

Чтобы устранить эту проблему, закомментируйте указанные строки в файле sudoers. После этого можно приступить к настройке. Сначала используйте User_Alias для определения псевдонима, содержащего учётные записи пользователей (через запятую), которым разрешено выполнять команды. Синтаксис:

User_Alias псевдоним = пользователи

Например, для создания псевдонима PWRUSRS, включающего пользователей tux, rtracy и ksanders:

User_Alias PWRUSRS = student, ksanders, rtracy

Совет

Все имена псевдонимов должны начинаться с заглавной буквы!

Далее используйте Cmnd_Alias для определения псевдонима команд (с полными путями), которые смогут выполнять эти пользователи. Несколько команд разделяются запятыми. Например, если ваши пользователи — программисты, которым нужно завершать процессы, определите псевдоним KILLPROCS:

Cmnd_Alias KILLPROCS = /bin/kill, /usr/bin/killall

Затем используйте Host_Alias, чтобы указать системы, на которых разрешено выполнять команды. Например, чтобы разрешить выполнение на системе WS1:

Host_Alias MYHSTS = openSUSE

Наконец, необходимо объединить все псевдонимы, определив точные правила доступа. Синтаксис:

User_Alias Host_Alias = (пользователь) Cmnd_Alias

Используя ранее определённые псевдонимы, разрешите указанным пользователям выполнять указанные команды на указанных узлах от имени root:

PWRUSRS          MYHSTS = (root) KILLPROCS

Для выхода из редактора нажмите Esc и введите :exit. Утилита visudo проверит синтаксис и сообщит об ошибках. После этого пользователи, указанные в файле, смогут выполнять заданные команды от имени root, вводя sudo команда в командной строке. Например, пользователь rtracy сможет завершить процесс vmware-toolbox (принадлежащий root), выполнив sudo killall vmware-toolbox. После ввода собственного пароля rtracy процесс будет завершён.

Помимо правильного использования учётной записи root, необходимо реализовать политику надёжных паролей.

Реализация политики надёжных паролей

Ещё одна серьёзная уязвимость — использование слабых паролей. Слабый пароль — это тот, который можно легко угадать или взломать. Примеры:

• Ваша фамилия
• Имя супруга
• Девичья фамилия матери
• Имя ребёнка
• Дата рождения
• Кличка домашнего животного
• Любое слово из словаря
• Слово «password» в качестве пароля
• Однобуквенные пароли
• Пустые пароли

Вы были бы удивлены, как часто пользователи используют подобные пароли. Недопустимо! Необходимо обучать пользователей применять надёжные пароли. Надёжный пароль содержит:

• Шесть или более символов (чем длиннее, тем лучше!)
• Комбинацию цифр и букв
• Буквы верхнего и нижнего регистра
• Слова, не встречающиеся в словарях
• (Опционально) Небуквенно-цифровые символы, например знаки пунктуации

Например, пароль M3n0v3l273 является достаточно надёжным, поскольку отвечает перечисленным требованиям. Утилиты управления паролями, поставляемые с большинством дистрибутивов Linux, по умолчанию проверяют пароли на соответствие критериям надёжности. Например, при попытке задать слабый пароль командой passwd система предложит выбрать более надёжный:

openSUSE:~ # passwd ksanders
New Password:BAD PASSWORD: it is WAY too short
BAD PASSWORD: is too simple
Retype new password:

Помимо надёжных паролей, следует настроить устаревание паролей (password aging): принудительную смену пароля по истечении определённого срока. Зачем это нужно? Чем дольше пользователь использует один пароль, тем выше вероятность его компрометации. Периодическая ротация паролей лишает злоумышленников возможности долго использовать перехваченные данные. Допустимый срок действия пароля варьируется от организации к организации: у организаций с высокими требованиями к безопасности — 30 дней или менее, у менее требовательных — 60 или даже 90 дней.

Настройка устаревания паролей выполняется командой chage. Синтаксис: chage параметр пользователь. Доступны следующие параметры:

• –m дней — минимальное количество дней между сменами пароля.
• –M дней — максимальное количество дней между сменами пароля.
• –W дней — количество дней для предупреждения об истечении срока пароля.

Рис. 17-4. Использование chage для настройки устаревания паролей.

Например, на рис. 17-4 для пользователя ksanders командой chage установлены: минимальный срок пароля — 5 дней, максимальный — 90 дней, период предупреждения — 7 дней.

Кроме того, Linux-системы не должны хранить пароли в файле /etc/passwd. Многие процессы обращаются к этому файлу при выполнении различных задач, поэтому хранение паролей в нём открывает серьёзную брешь в безопасности. Большинство специалистов понимают недопустимость такой конфигурации, и вам редко придётся с ней сталкиваться. Тем не менее если вы обнаружите подобную систему, воспользуйтесь командой pwconv для переноса паролей из /etc/passwd в /etc/shadow.

Необходимо также обучать пользователей элементарной гигиене паролей. Одна из наиболее распространённых ошибок — записывать пароль на стикере и приклеивать его на рабочем столе. Я видел системные пароли, написанные прямо на мониторе или клавиатуре. Знаю, что это звучит дико, но встречается снова и снова. Некоторые пользователи прячут стикер под клавиатурой или в ящике стола — это тоже значительный риск. Злоумышленнику достаточно подсмотреть, куда пользователь прячет пароль, и задача для него значительно упрощается.

Подобная «культура стикеров» — ещё один повод для жёсткого контроля физического доступа. Злоумышленник может легко получить корпоративную информацию, увидев пароль на виду. Отследить источник такой утечки бывает очень сложно.

Наконец, необходимо обучать пользователей противодействию попыткам социальной инженерии (social engineering). Это один из наиболее простых и эффективных инструментов злоумышленника. Социальная инженерия эксплуатирует человеческие слабости, а не технические уязвимости системы. Типичная схема такова.

Злоумышленник звонит сотруднику организации, представляясь другим сотрудником. Он объясняет, что он «Фёдор» из отдела продаж, находится в командировке у клиента и забыл пароль. Ему очень нужен важный файл с сервера, и он просит воспользоваться паролем сотрудника «всего один раз».

Большинство сотрудников хотят помогать коллегам и охотно называют свой пароль, открывая злоумышленнику доступ к системе. Иногда попытки менее прямолинейны: злоумышленник роется в мусоре компании в поисках стикеров с паролями. Случаются и более агрессивные атаки: выяснив имя высокого руководителя, злоумышленник звонит сотруднику, представляется этим руководителем и требует сообщить пароль под угрозой увольнения.

Не менее серьёзная угроза — фишинговые письма (phishing emails), которые наводнили организации в последние годы. Такие письма оформляются под официальные сообщения от банка, сайта социальной сети или интернет-магазина и убеждают пользователя перейти по ссылке на вредоносный сайт, где у него похищают конфиденциальные данные.

Фишинг — это низкотехнологичная, но очень распространённая атака, поскольку она крайне эффективна. Она становится успешной, если хотя бы несколько сотрудников откроют письмо и последуют инструкциям.

Чтобы распознать фишинговое письмо, необходимо знать его ключевые признаки. Оно может выглядеть убедительно, но имеет характерные черты. Например, адрес отправителя не совпадает с доменом организации, от имени которой якобы отправлено письмо. Кроме того, письмо нагнетает срочность: сообщает о заморозке банковского счёта, краже карты или даже угрожает арестом. Ключевой признак — гиперссылки в письме ведут на сайты, не имеющие отношения к указанной организации. Наведя курсор на ссылку (не нажимая), можно увидеть, куда она ведёт. Если адрес не совпадает с URL организации — это, скорее всего, попытка мошенничества.

Лучший способ противодействия социальной инженерии — обучение пользователей. Учите их не записывать пароли. Учите не выбрасывать конфиденциальные документы в мусор — уничтожать их! Рассказывайте о схемах телефонной социальной инженерии и способах противодействия. В большинстве организаций сотрудникам рекомендуют переводить любые звонки с просьбой назвать пароль на службу поддержки — после чего звонящий, как правило, вешает трубку. Обучайте пользователей распознавать фишинговые письма и правильно реагировать на них.

Настройка ограничений для пользователей

В Linux-системе можно ограничивать количество сеансов входа, время использования процессора и объём используемой памяти. Это можно сделать двумя способами:

• С помощью pam_limits для ограничения доступа к ресурсам
• С помощью ulimit для ограничения доступа к ресурсам

Использование pam_limits для ограничения ресурсов

Ограничить доступ пользователей к ресурсам Linux-системы позволяет модуль PAM (Pluggable Authentication Modules) pam_limits, настраиваемый через файл /etc/security/limits.conf. Этот файл содержит ограничения ресурсов в следующем синтаксисе:

домен        тип        ресурс        значение

Параметры:

• домен (domain) — объект, к которому применяется ограничение. Допустимые значения:
  • пользователь — конкретный пользователь Linux
  • @имя_группы — конкретная группа Linux
  • * — все пользователи
• тип (type) — жёсткое или мягкое ограничение. Жёсткую квоту превысить невозможно. Мягкую можно временно превысить.
• ресурс (item) — ограничиваемый ресурс (см. таблицу 17-1).
• значение (value) — числовое значение ограничения.

Ресурс	Описание
core	Ограничивает размер файлов core dump (в КБ)
data	Ограничивает область данных программы в RAM (в КБ)
fsize	Ограничивает размер файлов, создаваемых пользователем (в КБ)
nofile	Ограничивает количество одновременно открытых файлов
stack	Ограничивает размер стека (в КБ)
cpu	Ограничивает время CPU одного процесса (в минутах)
nproc	Ограничивает количество одновременных процессов пользователя
maxlogins	Задаёт максимальное число одновременных сеансов входа
priority	Задаёт приоритет выполнения процессов пользователя
locks	Задаёт максимальное число блокируемых файлов
nice	Задаёт максимальный приоритет nice, до которого пользователь может повысить процесс

Таблица 17-1. Настройка ограничений ресурсов.

Например, чтобы установить для пользователя rtracy мягкое ограничение CPU в 15 минут, откройте файл /etc/security/limits.conf и добавьте:

rtracy         soft            cpu      15

Это ограничение полезно, если пользователь запускает ресурсоёмкие программы, поглощающие время процессора. Аналогично, можно ограничить rtracy максимум двумя одновременными сеансами входа:

rtracy         hard            maxlogins         2

После достижения этого предела дальнейшие входы под rtracy будут запрещены.

Использование ulimit для ограничения ресурсов

Ограничить доступ к системным ресурсам можно также командой ulimit. Однако имейте в виду: ограничения ulimit применяются только к программам, запущенным из командной строки. Синтаксис: ulimit параметры ограничение. Доступны следующие параметры:

• –c — максимальный размер файлов core dump в блоках. При значении 0 дампы ядра отключаются.
• –f — максимальный размер (в блоках) файлов, создаваемых оболочкой.
• –n — максимальное количество открытых файловых дескрипторов.
• –t — максимальное время CPU (в секундах) для одного процесса.
• –u — максимальное количество процессов для одного пользователя.
• –d — максимальный размер (в КБ) сегмента данных процесса в RAM.
• –m — максимальный резидентный размер (в КБ) процесса в RAM.
• –s — максимальный размер стека (в КБ).
• –H — задаёт жёсткое ограничение ресурса.
• –S — задаёт мягкое ограничение ресурса.

Параметр –a позволяет просмотреть текущие значения всех ограничений ресурсов, как показано на рис. 17-5.

Рис. 17-5. Просмотр текущих ограничений ресурсов с помощью ulimit.

Для установки ограничений используйте ulimit. Например, для установки мягкого ограничения в 50 процессов введите ulimit –S –u 50. После этого пользователь сможет иметь не более 50 одновременных процессов оболочки.

Отключение входа пользователей

Время от времени может потребоваться полностью запретить все входы в Linux-систему. Например, возникла серьёзная проблема, требующая решения в изоляции. Для этого сначала нужно завершить сеансы всех текущих пользователей. Команда w выводит список всех вошедших пользователей. На рис. 17-6, например, в системе активны два пользователя: ksanders и rtracy.

Рис. 17-6. Список вошедших пользователей.

Зная имена вошедших пользователей, их можно принудительно выгнать командой pkill –KILL –u имя_пользователя. На рис. 17-7 команда pkill использована для принудительного завершения сеанса ksanders.

Рис. 17-7. Принудительное завершение сеанса пользователя.

После этого можно заблокировать все последующие входы. Это делается очень просто: создайте файл nologin в каталоге /etc. Пока этот файл существует, никто, кроме root, не сможет войти в систему. Любой текст в файле nologin будет выведен пользователю при попытке войти. На рис. 17-8 в файл /etc/nologin введена строка «The system is currently unavailable for login.», и именно это сообщение видит пользователь при попытке входа.

Рис. 17-8. Сообщение об отказе входа из /etc/nologin.

Это поведение определяется файлом /etc/pam.d/login:

openSUSE:~ # cat /etc/pam.d/login
#%PAM-1.0
auth      requisite      pam_nologin.so
auth      [user_unknown=ignore success=ok ignore=ignore auth_err=die
default=bad]pam_securetty.so
auth      include        common-auth
account include          common-account
password include         common-password
session required         pam_loginuid.so
session include          common-session
session required         pam_lastlog.so nowtmp
session optional         pam_mail.so standard
session optional         pam_ck_connector.so

Строка auth requisite pam_nologin.so предписывает PAM проверить наличие файла nologin в /etc. Если файл существует, PAM запрещает вход обычным пользователям. По завершении работ входы можно снова разрешить, удалив или переименовав файл. Например, переименовать его можно командой mv /etc/nologin /etc/nologin.bak.

Аудит файлов

Помимо блокировки входа, ещё одна задача обеспечения безопасности — аудит файлов с установленными правами SUID root. Как вы узнали в главе 11, SUID (Set User ID) — это специальное право доступа. При запуске исполняемого файла с установленным SUID процесс получает доступ к системе от имени владельца файла, а не от имени пользователя, который его запустил. Это серьёзная проблема, если файл принадлежит root: любой пользователь, запустив такой файл, получит привилегии root. Аналогичная проблема существует для файлов, принадлежащих группе root с установленным правом SGID.

Следует знать, что небольшое количество файлов, принадлежащих root, действительно нуждается в этих правах. Однако другие файлы root/root с установленными SUID/SGID представляют уязвимость: именно такие файлы часто используются в эксплойтах. Файл с установленным SUID при выводе командой ls выглядит следующим образом:

-rwSr-xr-x

Файл с установленным SGID выглядит так:

-rw-r-Sr-x

Рекомендуется периодически проводить аудит — искать файлы root с установленными этими правами. Любые файлы, выходящие за рамки минимально необходимого набора, следует тщательно проверять на предмет причастности к эксплойтам. Найти файлы с установленными правами SUID можно следующей командой от имени root:

find / -type f -perm -u=s -ls

Пример вывода:

openSUSE:/etc # find / -type f -perm -u=s –ls
 36406   32 -rwsr-xr-x   1 root     root        31848 Sep 5  2009 /bin/su
 30659   36 -rwsr-xr-x   1 root     root        35796 May 3  2007 /bin/ping
 84596   20 -rwsr-xr-x   1 root     audio       20252 Jun 16 2006 /bin/eject
 85643 324 -rwsr-xr-x    1 root     root       330420 Sep 5  2009 /bin/mount
 30661   36 -rwsr-xr-x   1 root     root        35716 May 3  2007 /bin/ping6
 85644 120 -rwsr-xr-x    1 root     root       121111 Sep 5  2009 /bin/umount

Параметр –perm указывает find искать файлы с заданным правом доступа: в данном случае — правом S, назначенным владельцу. Для поиска файлов с установленным SGID используется аналогичная команда:

find / -type f -perm -g=s -ls

Пример вывода:

openSUSE:~ # find / -type f -perm -g=s –ls
 94451   12 -rwxr-sr-x   1 root     tty    10588 May 18 2007 /opt/gnome/lib/vte/gnome-pty-helper
  85710    12 -rwxr-sr-x       1 root       tty          10404 Sep 5  2009 /usr/bin/wall
  5867     12 -rwxr-sr-x       1 root       shadow        8800 Jun 16 2006 /usr/bin/vlock
  85713    12 -rwxr-sr-x       1 root       tty           9024 Sep 5  2009 /usr/bin/write
  93913    12 -rwxr-sr-x       1 root       maildrop     11300 Sep 5  2009 /usr/sbin/postdrop
  93919    12 -rwxr-sr-x       1 root       maildrop     11668 Sep 5  2009 /usr/sbin/postqueue
  26192     8 -rwxr-sr-x       1 root       tty           7288 Jun 16 2006 /usr/sbin/utempter
  35720    24 -rwxr-sr-x       1 root       shadow       20672 Sep 5  2009 /sbin/unix_chkpwd

Упражнение 17-1. Управление доступом пользователей

В этом упражнении вы настроите ограничения по времени действия паролей пользователей и сконфигурируете sudo, чтобы позволить обычному пользователю завершать процессы от имени root. Используйте виртуальную машину из комплекта книги; запустите снимок 17-1 для корректно настроенной среды.

Выполните следующее:

1. Загрузите Linux-систему и войдите как пользователь student с паролем student.
2. Откройте терминальный сеанс.
3. Переключитесь на учётную запись root командой su – с паролем student.
4. Настройте ограничения по времени действия пароля:
   • а. Просмотрите файл /etc/passwd утилитой cat или less. Определите пользователя, для которого хотите настроить ограничения.
   • б. Установите минимальный срок пароля 3 дня, максимальный — 60 дней, предупреждение за 7 дней до истечения: chage –m 3 –M 60 –W 7 имя_пользователя.
5. Настройте sudo, чтобы пользователь мог завершать процессы от имени root:
   • а. Определите пользователя, которому хотите предоставить возможность завершать процессы как root.
   • б. От имени root выполните visudo. Откроется файл /etc/sudoers в редакторе vi.
   • в. Нажмите Insert.
   • г. Прокрутите до следующих строк и закомментируйте их, добавив символ # в начало каждой:

     Defaults targetpw   # ask for the password of the target user i.e. root
     ALL     ALL=(ALL) ALL   # WARNING! Only use this together with 'Defaults targetpw'!
     

   • д. Добавьте в конец файла sudoers:

     User_Alias PWRUSRS = ваш_пользователь
     Cmnd_Alias KILLPROCS = /bin/kill, /usr/bin/killall
     Host_Alias MYHSTS = openSUSE
     PWRUSRS MYHSTS = (root) KILLPROCS
     

   • е. Нажмите Esc, затем введите :exit для сохранения изменений.
   • ж. Запустите top от имени root.
   • з. Откройте новый терминальный сеанс и (от имени вашего обычного пользователя) выполните ps –elf | grep top. Вы должны увидеть процесс top, принадлежащий root.
   • и. Завершите этот процесс от имени обычного пользователя: sudo killall top.
   • к. При запросе введите пароль вашего пользователя.
   • л. Снова выполните ps –elf | grep top. Процесс top root должен быть завершён.

Теперь, когда пользователи надёжно защищены, рассмотрим, как защититься от сетевых атак.