Почему uid пользователя задается больше 1000
Перейти к содержимому

Почему uid пользователя задается больше 1000

Права, пользователи и прочее в Linux (часть 2)

Права, пользователи и прочее в Linux (часть 2)

В далеком 2011 мы выживали как могли я написал небольшую заметку про атрибуты файлов и директорий и то как их изменять, но вот про основы пользователей и групп так и не написал.. Ну пришло время исправиться, тем более я обещал)

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

Что такое пользователи?

По факту это любой кто использует компьютер. Имя пользователя это как правило его псевдоним, логин, который может состоять из букв Eng алфавита, арабских чисел и нижнего подчеркивания. Использовать можно любое имя кроме root, hal и adm, так как эти имена являются зарезервированными системой именами. Кроме логина в системе может храниться и полное имя реального пользователя, что иногда, при администрировании бывает полезным.

Что имеет каждый пользователь в linux системе?

  1. домашняя папка — для каждого пользователя создается своя домашняя директория в директории /home. Там могут храниться все его личные данные;
  2. командная оболочка — каждый пользователь имеет свою командную оболочку (командный интерпретатор), например /bin/bash, bin/sh и другие. (по умолчанию, как правило, используется /bin/bash)
  3. личный идентификатор (User ID) — каждый пользователь нумеруется, чтобы система могла отслеживать его, ибо она это делает только по uid пользователя
  4. пароль — естественно, каждый пользователь имеет свой пароль, которых храниться в зашифрованном виде (encripted)
  5. группа — и каждый пользователь может находиться в одной или более группе, о них мы поговорим немного подробнее..

Что такое группы?

Чтобы администраторам было проще разделять полномочия между пользователями, в Linux системах существуют группы, поэтому для каждого файла в linux системе определяется не только пользователь но и группа. По факту группы нужны для того, чтобы предоставить одинаковые полномочия на файлы или какие-нибудь действия. И опять же, каждая группа имеет свой уникальный идентификатор — GID (GroupID)

Как узнать, какие пользователи есть в системе?

Информация о пользователях храниться в файле /etc/passwd в виде строк, одна строка — это один пользователь, и эта строка имеет следующий формат:

account:password:UID:GID:GECOS:directory:shell

а расшифровывается она следующим образом:

  • account — логин пользователя
  • password — зашифрованный пароль пользователя
  • UID — id пользователя (uid создается более 1000)
  • GID — id основной группы (gid создается более 100)
  • GECOS — дополнительная информация о пользователе (не обязательно)
  • directory — домашний каталог ($HOME) пользователя
  • shell — командный интерпретатор пользователя (обычно /bin/sh)

Чтобы посмотреть какие пользователи существуют в системе, достаточно набрать следующую команду:

cat /etc/passwd

Ну и никто не запрещает посмотреть активных в данный момент пользователей:

lolosh@lolopc:~$ who leo tty1 2015-07-29 20:07 leo :0 2015-07-26 22:38 (:0)

Создание пользователя

При создании пользователя, нужно выполнить ряд следующих действий:

  1. создается запись в /etc/passwd
  2. создается домашний каталог пользователя (/home/username)
  3. устанавливаются необходимые права
  4. назначается необходимая командная оболочка
  5. модифицируются конфигурационные файлы прочих приложений

Чтобы как то упростить жизнь администраторам, существует специальная утилита useradd. Настройки этой утилиты хранятся в файле /etc/default/useradd, в котором можно изменить применяемые новым пользователям параметры по умолчанию.

Чтобы создать нового пользователя lolosh в группе users и lalki достаточно набрать следующую команду:

useradd -m -g users -G video,lalki -s /bin/bash lolosh

расшифровывается эта команда следующим образом:

useradd -m -g [основная группа] -G [список дополнительных групп] -s [командный интерпретатор] [имя пользователя]

Что означают эти ключи:

  • m — создаёт домашний каталог, вида /home/[имя пользователя]
  • -g — имя или номер основной группы пользователя
  • -G — список дополнительных групп, в которые входит пользователь
  • -s — определяет командную оболочку пользователя.

Подробнее узнать о том, что умеет эта утилита можно почитать в man страницах.

man useradd

useradd(8) Команды управления системой useradd(8) НАЗВАНИЕ useradd - регистрирует нового пользователя или изменяет информацию по умолчанию о новых пользователях СИНТАКСИС useradd [параметры] УЧЁТНАЯ_ЗАПИСЬ useradd -D useradd -D [параметры] ОПИСАНИЕ useradd is a low level utility for adding users. On Debian, administrators should usually use adduser(8) instead. При запуске без параметра -D команда useradd создаёт новую учётную запись пользователя, используя значения из командной строки и системные значения по умолчанию. В зависимости от параметров командной строки, команда useradd обновляет системные файлы, а также может создать домашний каталог нового пользователя и скопировать начальные файлы настроек. По умолчанию, для нового пользователя также создаётся группа (смотрите параметры -g, -N, -U и USERGROUPS_ENAB). ПАРАМЕТРЫ Параметры команды useradd: -b, --base-dir БАЗОВЫЙ_КАТАЛОГ Базовый системный каталог по умолчанию, если другой каталог не указан с помощью параметра -d. Значение БАЗОВЫЙ_КАТАЛОГ объединяется с именем учётной записи для определения домашнего каталога. Если не указан параметр -m, то БАЗОВЫЙ_КАТАЛОГ должен существовать. Если этот параметр не задан, то команда useradd будет использовать базовый каталог, указанный в переменной HOME в файле /etc/default/useradd иначе /home (по умолчанию). -c, --comment КОММЕНТАРИЙ Любая текстовая строка. Обычно, здесь коротко описывается учётная запись, и в настоящее время используется как поле для имени и фамилии пользователя. -d, --home ДОМАШНИЙ_КАТАЛОГ Для создаваемого пользователя будет использован каталог ДОМАШНИЙ_КАТАЛОГ в качестве начального каталога. По умолчанию, это значение получается объединением ИМЕНИ пользователя с БАЗОВЫМ_КАТАЛОГОМ и используется как имя домашнего каталога. Каталог ДОМАШНИЙ_КАТАЛОГ необязательно должен существовать, но не будет создан, если его нет. -D, --defaults Смотрите далее в подразделе «Изменение значений по умолчанию». -e, --expiredate ДАТА_УСТАРЕВАНИЯ Дата, когда учётная запись пользователя будет заблокирована. Дата задаётся в формате ГГГГ-ММ-ДД. Если этот параметр не задан, то команда useradd будет использовать дату устаревания по умолчанию, указанную в переменной EXPIRE в файле /etc/default/useradd, иначе пустую строку (без устаревания, по умолчанию). -f, --inactive ДНЕЙ Если указано значение 0, то учётная запись блокируется сразу после устаревания пароля, а при значении -1 данная возможность не используется. Если этот параметр не задан, то команда useradd будет использовать срок неактивности по умолчанию, указанный в переменной INACTIVE в файле /etc/default/useradd или -1 (по умолчанию). -g, --gid ГРУППА Имя или числовой идентификатор первичной группы пользователя. Группа с таким именем должна существовать. Идентификатор группы должен указывать на уже существующую группу. Если не указан, то поведение useradd зависит от переменной USERGROUPS_ENAB в файле /etc/login.defs. Если значение этой переменной равно yes (или в командной строке указан параметр -U/--user-group), то для пользователя будет создана группа с тем же именем как его имя для входа. Если значение переменной равно no (или в командной строке указан параметр -N/--no-user-group), то useradd установит первичную группу нового пользователя равной значению переменной GROUP из файла /etc/default/useradd, или 100 (по умолчанию). -G, --groups ГРУППА1[,ГРУППА2. [,ГРУППАN]]] Список дополнительных групп, в которых числится пользователь. Перечисление групп осуществляется через запятую, без промежуточных пробелов. На указанные группы действуют те же ограничения, что и для группы указанной в параметре -g. По умолчанию пользователь входит только в начальную группу. -h, --help Показать краткую справку и закончить работу. -k, --skel КАТАЛОГ_ШАБЛОНОВ Каталог с шаблонами, который содержит файлы и каталоги для копирования в домашний каталог пользователя при создании домашнего каталога командой useradd. Этот параметр можно использовать только с параметром -m (или --create-home). Если этот параметр не задан, то каталог шаблонов определяется переменной SKEL из файла /etc/default/useradd, или равен /etc/skel (по умолчанию). Если возможно, выполняется копирование ACL и расширенных атрибутов. -K, --key КЛЮЧ=ЗНАЧЕНИЕ Заменяет значения по умолчанию из файла /etc/login.defs (UID_MIN, UID_MAX, UMASK, PASS_MAX_DAYS и других). Пример: -K PASS_MAX_DAYS=-1 можно использовать при создании системной учётной записи, чтобы выключить устаревание пароля, даже если системная учётная запись вообще не имеет пароля. Можно указывать параметр -K несколько раз, например: -K UID_MIN=100 -K UID_MAX=499 -l, --no-log-init Не добавлять пользователя в базы данных lastlog и faillog. По умолчанию, записи пользователя в базах данных lastlog и faillog сбрасываются во избежание повторного использования записи, оставшейся от ранее удалённого пользователя. For the compatibility with previous Debian's useradd, the -O option is also supported. -m, --create-home Создать домашний каталог пользователя, если он не существует. Файлы и каталоги, содержащиеся в каталоге шаблонов (который можно указать с помощью параметра the -k option), будут скопированы в домашний каталог. По умолчанию, если этот параметр не указан и не задана переменная CREATE_HOME, домашний каталог не создаётся. -M Не создавать домашний каталог пользователя, даже если значение системной переменной в файле /etc/login.defs (CREATE_HOME) равно yes. -N, --no-user-group Не создавать группу с тем же именем как у пользователя, но добавить пользователя в группу, заданную параметром -g или переменной GROUP из файла /etc/default/useradd. Поведение по умолчанию (если не указан параметр -g, -N и -U) определяется переменной USERGROUPS_ENAB из файла /etc/login.defs. -o, --non-unique Разрешить создание учётной записи с уже имеющимся (не уникальным) UID. Этот параметр можно использовать только с параметром -u. -p, --password ПАРОЛЬ Шифрованное значение пароля, которое возвращает функция crypt(3). По умолчанию пароль отключён. Замечание: Этот параметр использовать не рекомендуется, так как пароль (или не шифрованный пароль) будет видим другими пользователям в списке процессов. Вы должны проверить, что пароль соответствует политике системных паролей. -r, --system Создать системную учётную запись. Системные пользователи создаются без информации об устаревании в /etc/shadow, и их числовые идентификаторы выбираются из диапазона SYS_UID_MIN-SYS_UID_MAX, определённого в /etc/login.defs, а не из UID_MIN-UID_MAX (это же касается и части с GID при создании групп). Заметим, что useradd не создаёт домашний каталог для данного пользователя независимо от значения по умолчанию в /etc/login.defs (CREATE_HOME). Если вы хотите создать домашний каталог для системной учётной записи укажите параметр -m. -R, --root КАТ_CHROOT Выполнить изменения в каталоге КАТ_CHROOT и использовать файлы настройки из каталога КАТ_CHROOT. -s, --shell ОБОЛОЧКА Имя регистрационной оболочки пользователя. По умолчанию это поле пусто, что вызывает выбор регистрационной оболочки по умолчанию согласно значению переменной SHELL из файла /etc/default/useradd, или по умолчанию используется пустая строка. -u, --uid UID Числовое значение идентификатора пользователя (ID). Оно должно быть уникальным, если не используется параметр -o. Значение должно быть неотрицательным. По умолчанию используется наименьшее значение ID большее или равное UID_MIN и большее чем у остальных пользователей. Смотрите также описание -r и UID_MAX. -U, --user-group Создать группу с тем же именем что и у пользователя, и добавить пользователя в эту группу. Поведение по умолчанию (если не указан параметр -g, -N и -U) определяется переменной USERGROUPS_ENAB из файла /etc/login.defs. -Z, --selinux-user SEUSER Пользователь SELinux для регистрационной оболочки пользователя. По умолчанию это поле пусто, что заставляет систему выбрать пользователя SELinux по умолчанию. Изменение значений по умолчанию При запуске программы только с параметром -D команда useradd показывает текущие значения по умолчанию. Если программа запускается с параметром -D вместе с другими параметрами, то useradd обновляет значения по умолчанию этих указанных параметров. Изменяемые параметры: -b, --base-dir БАЗОВЫЙ_КАТАЛОГ Начальная часть пути нового домашнего каталога пользователя. Имя пользователя будет добавлено в конец ДОМАШНЕГО_КАТАЛОГА для создания имени нового каталога, если при создании новой учётной записи не указан параметр -d. Этот параметр изменяет переменную HOME в файле /etc/default/useradd. -e, --expiredate ДАТА_УСТАРЕВАНИЯ Дата, когда учётная запись пользователя заблокирована. Этот параметр изменяет переменную EXPIRE в файле /etc/default/useradd. -f, --inactive ДНЕЙ Число дней, которые должны пройти после устаревания пароля, перед тем как учётная запись будет заблокирована. Этот параметр изменяет переменную INACTIVE в файле /etc/default/useradd. -g, --gid ГРУППА Имя группы или ID новой первичной группы пользователя (если используется -N/--no-user-group или когда значение переменной USERGROUPS_ENAB равно no (файл /etc/login.defs). Группа с указанным именем должна существовать, а для числового идентификатора группы должна быть соответствующая запись. Этот параметр изменяет переменную GROUP в файле /etc/default/useradd. -s, --shell ОБОЛОЧКА Имя новой регистрационной командной оболочки пользователя. Этот параметр изменяет переменную SHELL в файле /etc/default/useradd. ЗАМЕЧАНИЯ Системный администратор сам решает, какие файлы нужно положить в каталог /etc/skel/ (или в любой другой каталог шаблонов, указанный в /etc/default/useradd или в командной строке). ПРЕДОСТЕРЕЖЕНИЯ Нельзя добавить пользователя в группу NIS или LDAP. Это необходимо делать на соответствующем сервере. Также, если имя пользователя уже существует во внешней базе данных такой как NIS или LDAP, то useradd не станет создавать учётную запись пользователя. It is usually recommended to only use usernames that begin with a lower case letter or an underscore, followed by lower case letters, digits, underscores, or dashes. They can end with a dollar sign. In regular expression terms: [a-z_][a-z0-9_-]*[$]? On Debian, the only constraints are that usernames must neither start with a dash ('-') nor plus ('+') nor tilde ('~') nor contain a colon (':'), a comma (','), or a whitespace (space: ' ', end of line: '\n', tabulation: '\t', etc.). Note that using a slash ('/') may break the default algorithm for the definition of the user's home directory. Имена пользователей могут быть длиной не более 32 знаков. НАСТРОЙКА На работу этого инструмента влияют следующие переменные настройки из /etc/login.defs: CREATE_HOME (логический) Определяет, должен ли создаваться по умолчанию домашний каталог для новых пользователей. Эта переменная не влияет на системных пользователей и может быть переопределена из командной строки. GID_MAX (число), GID_MIN (число) Диапазон идентификаторов групп, используемый в программах useradd, groupadd или newusers для создания обычных групп. Значение по умолчанию для GID_MIN (соотв. GID_MAX) равно 1000 (соотв. 60000). MAIL_DIR (строка) Почтовый каталог. Данный параметр нужен для управления почтовым ящиком при изменении или удалении учётной записи пользователя. Если параметр не задан, то используется значение указанное при сборке. MAIL_FILE (строка) Определяет расположение почтовых файлов пользователя относительно домашнего каталога. Переменные MAIL_DIR и MAIL_FILE используются командами useradd, usermod и userdel для создания, перемещения или удаления почты пользователя. MAX_MEMBERS_PER_GROUP (число) Максимальное количество членов в записи о группе. При достижения максимума заводится новая запись группы (строка) в /etc/group (с тем же именем, паролем и тем же GID). Значение по умолчанию равно 0, означающее, что ограничения на количество членов в группе нет. Данная возможность (разделение группы) позволяет ограничить длину строк в файле групп. Это полезно для ограничения длины строк групп NIS в 1024 символа. Если вам нужно такое ограничение, укажите значение 25. Замечание: разделение групп поддерживается не всеми инструментами (даже в наборе инструментов Shadow). Вы не должны использовать эту переменную, если вам действительно это ненужно. PASS_MAX_DAYS (число) Максимальное число дней использования пароля. Если пароль старее этого числа, то будет запущена процедура смены пароля. Если значение не задано, то предполагается значение -1 (то есть возможность ограничения не используется). PASS_MIN_DAYS (число) Максимальное число дней между изменениями пароля. Любая смена пароля ранее заданного срока выполнена не будет. Если значение не задано, то предполагается значение -1 (то есть возможность ограничения не используется). PASS_WARN_AGE (число) Число дней за которое начнёт выдаваться предупреждение об устаревании пароля. Нулевое значение означает, что предупреждение выдаётся в день устаревания, при отрицательном значении предупреждение выдаваться не будет. Если значение не задано, выдача предупреждения отключается. SYS_GID_MAX (число), SYS_GID_MIN (число) Диапазон идентификаторов групп, используемый в программах useradd, groupadd или newusers для создания системных групп. Значение по умолчанию для SYS_GID_MIN (соотв.SYS_GID_MAX) равно 101 (соотв. GID_MIN-1). SYS_UID_MAX (число), SYS_UID_MIN (число) Диапазон идентификаторов пользователей, используемый в программах useradd или newusers для создания системных пользователей. Значение по умолчанию для SYS_UID_MIN (соотв. SYS_UID_MAX) равно 101 (соотв. UID_MIN-1). UID_MAX (число), UID_MIN (число) Диапазон идентификаторов пользователей, используемый в программах useradd или newusers для создания обычных пользователей. UMASK (число) Задаёт начальное значение маски доступа для создаваемых файлов. Если не указано, то маска устанавливается в 022. Команды useradd и newusers используют эту маску для установки прав доступа к домашнему каталогу, который они создают. Она также используется командой pam_umask как значение umask по умолчанию. USERGROUPS_ENAB (логический) Если значение равно yes, то userdel удаляет пользовательскую группу, если в ней нет больше членов, а useradd по умолчанию создаёт группу с именем пользователя. ФАЙЛЫ /etc/passwd содержит информацию о пользователях /etc/shadow содержит защищаемую информацию о пользователях /etc/group содержит информацию о группах /etc/gshadow содержит защищаемую информацию о группах /etc/default/useradd значения по умолчанию для создаваемой учётной записи /etc/skel/ каталог, содержащий файлы по умолчанию /etc/login.defs содержит конфигурацию подсистемы теневых паролей ВОЗВРАЩАЕМЫЕ ЗНАЧЕНИЯ Команда useradd завершая работу, возвращает следующие значения: 0 успешное выполнение 1 не удалось изменить файл паролей 2 ошибка в параметрах команды 3 недопустимое значение параметра 4 такой UID уже существует (и не задан параметр -o) 6 указанная группа не существует 9 имя пользователя уже существует 10 не удалось изменить файл групп 12 не удалось создать домашний каталог 14 can't update SELinux user mapping СМОТРИТЕ ТАКЖЕ chfn(1), chsh(1), passwd(1), crypt(3), groupadd(8), groupdel(8), groupmod(8), login.defs(5), newusers(8), userdel(8), usermod(8).

Добавление и изменение дополнительной информации

Для того, чтобы наделить пользователя дополнительной информацией, можно воспользоваться командой chfn. Рассмотрим что мы можем добавить:

chfn [-f ФИО][-о служба сопровождения ИС][-p служебный контакт][-h домашний контакт][-u][-v][логин_пользователя]

Подробнее, о возможностях этой команды читайте man.

chfn(1) Пользовательские команды chfn(1) НАЗВАНИЕ chfn - изменяет информацию о пользователе СИНТАКСИС chfn [параметры] [УЧЁТНАЯ_ЗАПИСЬ] ОПИСАНИЕ Программа chfn изменяет ФИО, рабочий телефон, рабочий номер комнаты, рабочий и домашний номер телефона для учётной записи пользователя. Обычно, эти данные выводятся командой finger(1) и ей подобными программами. Обычный пользователь может изменить только определённые данные собственной учётной записи, разрешённые в файле /etc/login.defs (настройкой по умолчанию пользователю не разрешается менять своё имя и фамилию). Суперпользователь может изменять любые данные любой учётной записи. Кроме того, только суперпользователь может использовать параметр -o для изменения нестандартизованной части данных GECOS. Части поля GECOS не должны содержать двоеточий. За исключением части другая, в них не должно содержаться запятых и знаков равно. Также рекомендуется избегать символов не в кодировке US-ASCII, но это касается только номеров телефонов. Часть другая используется для хранения информации об учётной записи, которая используется другими приложениями. ПАРАМЕТРЫ Параметры команды chfn: -f, --full-nameФИО Изменяет ФИО пользователя. -h, --home-phoneДОМАШНИЙ_ТЕЛЕФОН Изменяет номер домашнего телефона пользователя. -o, --otherДРУГАЯ Изменяет другую информацию GECOS о пользователе. Эта часть используется для хранения информации об учётной записи, используемой другими приложениями, и может изменяться только суперпользователем. -r, --roomНОМЕР_КОМНАТЫ Изменяет номер комнаты пользователя. -R, --root КАТ_CHROOT Выполнить изменения в каталоге КАТ_CHROOT и использовать файлы настройки из каталога КАТ_CHROOT. -u, --help Показать краткую справку и закончить работу. -w, --work-phoneРАБОЧИЙ_ТЕЛЕФОН Изменяет номер рабочего телефона пользователя. Если ни один параметр не указан, то chfn переходит в интерактивный режим, предлагая запустившему пользователю изменить данные своей учётной записи. Вводимое значение заменяет текущее значение записи; если введена пустая строка, то текущее значение остаётся неизменным. Текущее значение показано в скобках [ ]. При вызове без параметров программа chfn изменяет учётную запись запустившего пользователя. НАСТРОЙКА На работу этого инструмента влияют следующие переменные настройки из /etc/login.defs: CHFN_RESTRICT (строка) Этим параметром определяются части поля gecos в файле /etc/passwd, которые могут изменять обычные пользователи с помощью программы chfn. Строка может содержать любую комбинацию букв f, r, w, h для изменения полного имени пользователя, номера комнаты, рабочего и домашнего телефона, соответственно. Для совместимости значение yes эквивалентно rwh и no эквивалентно frwh. Если ничего не задано, то только суперпользователь может выполнять любые изменения. Наиболее ограничительная настройка достигается снятием SUID бита с файла chfn. ФАЙЛЫ /etc/login.defs содержит конфигурацию подсистемы теневых паролей /etc/passwd содержит информацию о пользователях СМОТРИТЕ ТАКЖЕ chsh(1), login.defs(5), passwd(5).

Задаем или изменяем пароль

Для того, чтобы задать пользователю пароль, достаточно воспользоваться следующей командой:

passwd имя_пользователя

далее программа дважды попросит ввести новый пароль.

Если мы хотим, чтобы пользователь сменил пароль при первом входе, можно воспользоваться следующей командой:

chage -d 0 имя_пользователя

Так же еще можно установить срок годности учетной записи и многое другое, подробно можно почитать man.

chage(1) Пользовательские команды chage(1) НАЗВАНИЕ chage - изменяет информацию об устаревании пароля пользователя СИНТАКСИС chage [параметры] УЧЁТНАЯ_ЗАПИСЬ ОПИСАНИЕ Программа chage изменяет количество дней между датой смены пароля и датой последней смены пароля. Эта информация используется системой для определения момента, когда пользователь должен сменить свой пароль. ПАРАМЕТРЫ Параметры команды chage: -d, --lastday ПОСЛ_ДЕНЬ Установить число дней прошедших с 1 января 1970 года, когда была последняя смена пароля. Дата может быть также указана в виде ГГГГ-ММ-ДД (или в форме согласно региональным настройкам). -E, --expiredate ДАТА_УСТАРЕВАНИЯ Установить дату устаревания учётной записи пользователя, которая задаётся числом дней прошедших с 1 января 1970 года. Дата может быть также задана в виде ГГГГ-ММ-ДД (или в форме согласно региональным настройкам). Пользователь, чья учётная запись была заблокирована, должен обратиться к системному администратору, если хочет в дальнейшем работать с системой. Значение -1 в параметре ДАТА_УСТАРЕВАНИЯ отменяет устаревание учётной записи. -h, --help Показать краткую справку и закончить работу. -I, --inactive ДНЕЙ Установить количество дней неактивности после устаревания пароля перед тем как учётная запись будет заблокирована. В параметре ДНЕЙ задаётся количество дней неактивности. Пользователь, чья учётная запись была заблокирована, должен обратиться к системному администратору, если хочет в дальнейшем работать с системой. Значение -1 в параметре ДНЕЙ отменяет неактивность учётной записи. -l, --list Показать информацию об устаревании учётной записи. -m, --mindays МИН_ДНЕЙ Задать минимальное количество дней между сменами пароля. Нулевое значение этого поля указывает на то, что пользователь может менять свой пароль когда захочет. -M, --maxdays МАКС_ДНЕЙ Установить максимальное количество дней работоспособности пароля. Если сумма значений МАКС_ДНЕЙ и ПОСЛ_ДЕНЬ раньше текущего дня, то пользователю придётся изменить свой пароль перед использованием учётной записи. Для того, чтобы это не было неожиданностью можно воспользоваться параметром -W, который активирует выдачу предупреждения о смене пароля пользователя заранее. Значение -1 в параметре МАКС_ДНЕЙ отменяет проверку пароля. -R, --root КАТ_CHROOT Выполнить изменения в каталоге КАТ_CHROOT и использовать файлы настройки из каталога КАТ_CHROOT. -W, --warndays ПРЕДУП_ДНЕЙ Установить количество дней выдачи предупреждения, перед тем как потребуется смена пароля. Параметр ПРЕДУП_ДНЕЙ считается в днях, в течении которых пользователь будет получать предупреждение об устаревании пароля, перед тем как это случится. Если ни один параметр не указан, то chage переходит в интерактивный режим, предлагая запустившему пользователю изменить значения всех полей своей учётной записи. Вводимое значение заменяет текущее значение поля; если введена пустая строка, то текущее значение остаётся неизменным. Текущее значение показано в скобках [ ]. ЗАМЕЧАНИЕ Программа chage требует наличия файла теневых паролей. Программа chage работает только от суперпользователя, за исключением вызова с параметром -l, который может использоваться непривилегированным пользователем для определения даты устаревания своего пароля. НАСТРОЙКА На работу этого инструмента влияют следующие переменные настройки из /etc/login.defs: ФАЙЛЫ /etc/passwd содержит информацию о пользователях /etc/shadow содержит защищаемую информацию о пользователях ВОЗВРАЩАЕМЫЕ ЗНАЧЕНИЯ Программа chage завершая работу, возвращает следующие значения: 0 успешное выполнение 1 доступ запрещён 2 ошибка в параметрах команды 15 не удалось найти файл теневых паролей СМОТРИТЕ ТАКЖЕ passwd(5), shadow(5).

Удаление пользователя

Удалить пользователя можно следующей командой:

userdel -r имя_пользователя

Обратите внимание, с указанным ключом -r удаляется и его домашняя директория.

Управление группами

Тут так же нет ничего сложного. Чтобы просмотреть список существующих групп, достаточно отобразить файл /etc/group:

cat /etc/group

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

groups имя_пользователя

и более подробным выводом:

id имя_пользователя

Чтобы создать новую группу, введите следующее:

groupadd имя_группы

Для добавления пользователя в эту группу, достаточно ввести:

gpasswd -a имя_пользователя имя_группы

Чтобы убрать из группы пользователя, достаточно ввести

gpasswd -d имя_пользователя имя_группы

Для удаления группы из системы, можно ввести следующее:

groupdel имя_группы

На этом, пожалуй, все. Если есть чем дополнить, то пишите комментарии.

Управление пользователями

url image

Каждый пользователь имеет свой уникальный идентификатор пользователя, UID . Он отличается в зависимости от типа пользователя:

  • администратор — 0
  • обычный пользователь — от 100
  • системный пользователь — от 1 до 100

Чтобы упростить процесс настройки прав для новых пользователей, их объединяют в группы. Каждая группа имеет свой набор прав и ограничений. Любой пользователь, создаваемый или добавляемый в такую группу, автоматически их наследует. Если при добавлении пользователя для него не указать группу, то у него будет своя, индивидуальная группа — с именем пользователя. Один пользователь может одновременно входить в несколько групп.

Информацию о каждом пользователе сервера можно посмотреть в файле /etc/passwd . Пользователи в нём перечислены в следующем формате:

test-user:x:1000:1000::/home/test-user:/bin/bash

говорит о том, что пароль зашифрован (хранится в /etc/shadow )

идентификатор пользователя ( UID ) и идентификатор группы ( GID ), к которой он принадлежит

тут может быть ваша реклама комментарий к пользователю и его контакты. Например, имя сотрудника или название службы. Т.н. GECOS -поле

домашняя папка пользователя

указывает, что пользователь имеет доступ к командной оболочке сервера

Если вам известно имя пользователя и вы хотите узнать о нём побольше, необязательно читать /etc/passwd . Всё то же самое в человекочитаемом виде можно посмотреть с помощью команды pinky -l :

pinky -l test-user

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

В качестве альтернативы можно использовать команду w — она тоже показывает всех авторизованных в текущий момент пользователей, включая создаваемую ими нагрузку на сервер:

Узнать UID пользователя можно с помощью команды id :

id test-user

Для именования пользователей в Linux есть набор стандартных правил:

  • Имя пользователя может содержать только английские буквы [a-z] в верхнем и нижнем регистре, цифры, символ «_» , тире «-» и точку;
  • Имя пользователя может оканчиваться символом «$» ;
  • Имя пользователя не может начинаться с тире, содержать только цифры или состоять из «.» или «..» ;
  • Не рекомендуется использовать точку в начале имени пользователя;
  • Имя пользователя может включать до 32 символов.

Теперь перейдём непосредственно к управлению пользователями.

  • Создание пользователей
  • Изменение данных пользователей
  • Удаление пользователей
  • Группы пользователей
  • Привилегии суперпользователя. Sudo

Создание пользователей

Процесс добавления пользователя состоит из двух шагов: создания пользователя и настройки пароля.

На первом шаге используется команда useradd c набором опций для настройки нового пользователя и его именем (логином):

useradd [как создать] [как назвать]

Эта команда имеет ряд настроек по умолчанию, которые задаются с помощью файлов /etc/default/useradd и /etc/login.defs Увидеть основные можно с помощью команды:

useradd -D

GID группы, в которую пользователь будет добавлен после создания

базовый каталог, в котором будет размещена директория пользователя

указывает время до блокировки пользователя, когда его пароль станет недействителен. Значение «-1» отключает опцию

дата, до которой действителен аккаунт. По умолчанию не установлена — то есть без ограничений

используется для настройки доступа к командной оболочке

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

определяет, нужно ли создать папку для писем этого пользователя в /var/spool/mail/

Все эти настройки применяются, если использовать самый простой вариант команды создания пользователя без параметров:

useradd test-user

Но обычно нам требуется добавить пользователя со специфическими настройками — для этого используется расширенный вариант этой команды. Перечислим основные опции:

создаёт указанную домашнюю директорию, если она ещё не существует

устанавливает /home/test-user в качестве домашней директории

-c «Евграф Шматкунос»

добавляет комментарий. Например, с именем пользователя

указывает группу, в которую попадёт пользователь после создания. Можно использовать с GID или именем группы. Указанная группа должна существовать. Используется в сочетании с ключом -N (отменяет автоматическое создание группы с именем пользователя)

указывает список дополнительных групп пользователя. Они перечисляются через запятую без пробелов

позволяет настроить доступ к shell

создаёт системного пользователя. Используется, когда вам нужно настроить службу на работу из-под конкретного пользователя. По умолчанию данные таких пользователей не вносятся в /etc/shadow , для них не создаётся домашняя папка

позволяет указать свой UID , который будет присвоен новому пользователю. В качестве UID указывается положительное целое число. UID должен быть уникален

указывает дату, до которой аккаунт будет активен. Дата задаётся в формате YYYY-MM-DD

указывает количество дней до блокировки пользователя, когда его пароль станет недействителен

В итоге получится вот такая сборная солянка из настроек:

useradd -m -u 666 -d /home/users/test-user -c "Тестовый пользователь" -e 2060-01-01 -s /bin/bash test-user

В примере мы создаём тестового пользователя test-user с идентификатором 666 , домашней папкой в /home/users/test-user , комментарием «Тестовый пользователь» и доступом к командной оболочке. Учётная запись будет действительна до конца света по Ньютону.

Более подробную информацию о доступных опциях для useradd можно увидеть с помощью команды man useradd .

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

passwd test-user

Система предложит ввести и подтвердить пароль. На этом процесс создания пользователя можно считать завершённым.

Изменение данных пользователей

Смена настроек для активного пользователя может привести к сбою системы. Поэтому перед изменением данных важно убедиться, что в текущий момент редактируемый пользователь не авторизован, под ним отсутствуют запущенные процессы, редактируемые файлы. Посмотреть список запущенных процессов пользователя user можно следующим образом:

pgrep -l -u user

Проверить, авторизован ли пользователь, можно с помощью уже известной команды:

pinky user

Отредактировать данные существующего пользователя можно с помощью команды usermod . По структуре она похожа на предыдущую команду:

usermod [что поменять] [для какого пользователя]

Набор параметров расширен дополнительными опциями:

создаёт новую директорию, указанную в качестве домашней (если её не существует), и переносит туда данные из старой

меняет домашнюю директорию пользователя на /home/users/new-test-user

меняет комментарий к пользователю

добавляет пользователя в дополнительные группы

меняет командную оболочку пользователя

изменяет UID пользователя

меняет дату, до которой аккаунт будет активен

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

меняет имя пользователя на new-test-user

блокирует аккаунт пользователя. Для этого в файле /etc/shadow перед хэшем пароля пользователя ставится символ «!»

снимает блокировку с аккаунта (удаляет символ «!» из пароля в /etc/shadow )

То есть если мы захотим отредактировать данные пользователя test-user , созданного в примере выше, это будет выглядеть так:

usermod -l new-test-user -m -d /home/new-test-user -c "Чак Норрис" -u 100500 -e 3000-01-01 -f -1 test-user

В примере мы меняем логин — имя пользователя на new-test-user , изменяем домашнюю папку на /home/new-test-user с копированием файлов, меняем комментарий, UID пользователя, срок жизни аккаунта и отменяем блокировку в случае устаревания пароля.

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

Удаление пользователей

Как и в случае с редактированием, перед удалением пользователя нужно убедиться, что под ним отсутствуют активные процессы, не редактируются файлы. Иначе существует риск сбоя системы. В программу встроен механизм защиты, поэтому она не позволит удалить пользователя, если он авторизован или под ним работают какие-то службы.

Для удаления пользователей используется команда userdel . Её структура аналогична предыдущим:

userdel [что удаляем] [кого удаляем]

Основных параметра два:

удаляет папки пользователя: домашнюю директорию, почтовую очередь

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

После удаления пользователей важно вручную проверить, что на сервере не осталось файлов или директорий, принадлежащих удалённому пользователю.

Группы пользователей

Информация о группах хранится в файле /etc/group . Работа с группами пользователей куда проще.

Группы применяются для делегирования прав доступа на определённые файлы, папки, скрипты сразу нескольким пользователям. Живой пример: работа с FTP-сервером. Вы выбираете какую-то директорию для работы с файлами, создаёте группу пользователей и присваиваете ей выбранную папку. Теперь вам не нужно отдельно настраивать права каждому новому пользователю — достаточно добавить его в эту группу, и он автоматически получит доступ к FTP-каталогу.

Создание

Для создания групп используется команда groupadd :

groupadd new-group

Из параметров можно выделить следующие:

если группа с указанным именем или GID уже существует, опция прерывает выполнение команды без соответствующей ошибки

позволяет назначить свой GID для создаваемой группы

создаёт системную группу

Устанавливает для группы пароль p@ssw0rd . Пароль запрашивается системой при попытке входа в группу с помощью команды newgrp .

Не рекомендуется к использованию из-за проблем с безопасностью. Настроенный таким образом пароль можно увидеть в истории команд.

Редактирование

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

меняет GID группы на 100500

меняет имя группы на another-name

Например, если нам нужно изменить имя группы test-group на имя named-group , команда будет выглядеть так:

groupmod -n named-group test-group

Удаление

Нельзя удалить группу, если она указана в качестве основной для какого-то существующего пользователя. Сначала нужно предварительно удалить этого пользователя из группы.

Само удаление группы выполняется одной командой:

groupdel test-group

Как и в случае удаления пользователей, нужно вручную проверить, что на сервере не осталось данных, принадлежащих удалённой группе.

Управление пользователями в группе

Базовым инструментом для управления группами является утилита gpasswd . Она имеет несколько параметров, но с одной особенностью — в отличие от предыдущих примеров, здесь большинство параметров (кроме -A и -M ) не сочетаются. То есть в команде может быть только один параметр за раз.

Структура команды проста:

gpasswd [что сделать] [в какой группе]

Рассмотрим опции команды подробнее:

Добавляет пользователя new-user в группу

Удаляет пользователя bad-user из группы

Доступна для использования привилегированным пользователям (с правами root). Назначает список пользователей-администраторов группы

Доступна для использования привилегированным пользователям. Назначает список участников группы

Отключает пароль группы. После этого только члены группы смогут использовать команду newgrp для подключения к группе

Отключает внешний доступ к группе. После этого только члены группы смогут использовать команду newgrp для подключения к группе

То есть если нам потребуется добавить пользователя в новую группу, достаточно будет использовать следующую команду:

gpasswd -a new-user test-group

Также для добавления пользователей в новую группу используется описанная выше команда usermod . Следующий пример добавляет пользователя test-user в группу new-group :

usermod -a -G new-group test-user

Или, если нужно указать группу new-group в качестве основной группы пользователя test-user :

usermod -g new-group test-user

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

newgrp new-group

Эта команда позволяет переключить группу пользователя в рамках текущей сессии, а также автоматически добавляет запрошенную группу в список групп пользователя.

Привилегии суперпользователя. Sudo

Итак, мы знаем, что на сервере есть три типа пользователей: администраторы (корневой пользователь root ), локальные пользователи (люди, которым мы предоставляем учётные записи для работы с сервером) и системные пользователи (сущности, от имени которых запускаются те или иные процессы). То есть реально для управления системой используются только первые два типа пользователей. Их основное различие — в объёме прав доступа.

По умолчанию после установки операционной системы на сервере присутствует только один пользователь — администратор root . Он имеет полные права доступа ко всем процессам и данным сервера.

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

Тем не менее, основная часть работы с конечными данными на сервере происходит именно под локальным пользователем — например, загрузка и изменение файлов сайтов. Если вы загрузите на сервер файл под root -ом, файл будет принадлежать ему, а не пользователю, в папку которого загружен. Соответственно, потом это может привести к ошибкам, если вручную не изменить владельца загруженного файла.

Когда вы полностью настроите ваш сервер, работа под root -ом вообще может стать опасной. Случайная ошибка в команде на удаление папки может запросто скосить все ваши труды по разворачиванию системы. Да и в целом сам факт наличия пользователя root на сервере при неправильном подходе к безопасности может стать фатальным — если злоумышленник получит к нему доступ, он получит неограниченный контроль над всем содержимым сервера.

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

  • повышается уровень внешней безопасности (отсутствие root отсекает часть автоматических попыток взлома);
  • ограничивается объём административных прав — повышение привилегий используется для конкретных рабочих операций и действует ограниченное время.

Для делегирования прав суперпользователя локальные пользователи добавляются в специальную группу. Способ настройки отличается в зависимости от используемой операционной системы:

    Ubuntu и Debian: Для предоставления прав пользователи добавляются в группу sudo :

usermod -a -G sudo test-user
usermod -a -G wheel test-user

Можно делегировать права пользователям по отдельности — через файл /etc/sudoers Для работы с ним нужно вызвать специальный редактор:

visudo

В этом файле можно тонко настроить объём делегируемых прав — вплоть до списка команд, которые пользователям разрешено вызывать от имени администратора.

Проверить, может ли пользователь использовать sudo , можно с помощью команды:

sudo -l -U test-user

В примере пользователь test-user может выполнять через sudo любые команды ( ALL:ALL — символизирует, что команды могут исполняться от имени любых пользователей и групп, третий аргумент символизирует список доступных команд — в примере ALL , не ограничен)

Чтобы выполнить ту или иную команду с правами суперпользователя, перед ней вызывается команда sudo :

sudo groupadd newgroup

Для подтверждения система запросит ввести пароль текущего пользователя (символы при вводе пароля не отображаются — введите пароль «вслепую» или скопируйте и вставьте кликом правой кнопки мыши). После ввода команда будет отправлена на исполнение. Также в течение пяти следующих минут (по умолчанию) вы сможете запускать команды от имени суперпользователя без использования sudo и повторного ввода пароля.

Количество времени, которое действуют права суперпользователя после вызова sudo , можно изменить через настройки в /etc/sudoers . Запрос пароля можно отключить там же.

Если вам нужно выполнить сразу несколько операций с повышенными привилегиями, можно временно войти в режим суперпользователя:

sudo -s

С управлением пользователями разобрались, идём дальше. Как было сказано выше, чтобы локальный пользователь мог начать работу на сервере, администратор ( root или пользователь c привилегиями sudo ) должен настроить права доступа к файлам и папкам, которые понадобятся этому пользователю. Рассмотрим этот вопрос подробнее.

Все, что вам нужно знать о UID в Linux

Все, что вам нужно знать о UID в Linux

Эта статья по основам Linux научит вас всему важному, связанному с UID в Linux.

Что такое UID в Linux?

UID обозначает идентификатор пользователя. UID — это номер, назначенный каждому пользователю Linux. Это представление пользователя в ядре Linux.

UID используется для идентификации пользователя в системе и для определения того, к каким системным ресурсам пользователь может получить доступ. Вот почему идентификатор пользователя должен быть уникальным.

Вы можете найти UID в файле /etc/passwd. Это тот же файл, который можно использовать для составления списка всех пользователей в системе Linux.

Используйте команду Linux для просмотра текстового файла, и вы увидите различную информацию о пользователях, присутствующих в вашей системе.

root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin andreyex:x:1000:1000:Andrey. /home/helder:/bin/bash davmail:x:127:65534::/var/lib/davmail:/usr/sbin/nologin statd:x:128:65534::/var/lib/nfs:/usr/sbin/nologin

Третье поле здесь представляет идентификатор пользователя или UID.

Обратите внимание, что в большинстве дистрибутивов Linux UID 1-500 обычно зарезервирован для системных пользователей. В Ubuntu и Fedora UID для новых пользователей начинаются с 1000.

Например, если вы используете команду useradd или adduser для создания нового пользователя, он получит следующий доступный номер после 1000 в качестве своего UID.

Корневой пользователь
В Linux UID — 0 и GID — 0 зарезервированы для пользователя root.

Как найти UID пользователя в Linux?

Вы всегда можете положиться на файл /etc/passwd, чтобы получить UID пользователя. Это не единственный способ получить информацию UID в Linux.

Команда id в Linux отобразит UID, GID и группы, к которым принадлежит ваш текущий пользователь:

id uid=1000(andreyex) gid=1000(andreyex) groups=1000(andreyex),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),116(lpadmin),126(sambashare),127(kvm)

Вы также можете указать имена пользователей с помощью команды id, чтобы получить UID любого пользователя Linux:

id standard uid=1001(standard) gid=1001(standard) groups=1001(standard)

Как изменить UID пользователя в Linux?

Предположим, у вас было несколько пользователей в вашей системе Linux. Вы должны были удалить пользователя, потому что он/она покинул организацию. Теперь вы хотите, чтобы его UID был занят другим пользователем, уже находящимся в системе.

Вы можете изменить UID, изменив пользователя с помощью команды usermod следующим образом:

usermod -u 1004 user_2

Вы должны иметь привилегию суперпользователя для выполнения вышеуказанной команды.

Вы помните концепцию прав доступа и владения файлами в Linux? Право собственности на файл определяется UID пользователя-владельца.

Когда вы обновляете UID пользователя, что происходит с файлами, принадлежащими этому пользователю? В то время как все файлы в домашнем каталоге user_2 изменят свой связанный UID, вам придется вручную обновить связанный UID других файлов вне домашний каталог.

Что вы можете сделать, это вручную обновить владельца файлов, связанных со старым UID пользователя_2.

find / -user old_uid_of_user_2 -exec chown -h user_2 <> \;

Вот и все. Мы надеемся, что теперь у вас есть лучшее представление об UID в Linux. Не стесняйтесь задавать свои вопросы, если таковые имеются.

Как профессиональный пользователь Linux, если вы думаете, что мы пропустили какое-то важное понятие об UID, пожалуйста, дайте мне знать в разделе комментариев.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.

Настройка auditd для обнаружения и расследования инцидентов информационной безопасности

Одной из важных составляющих информационной безопасности инфраструктуры компании является SIEM — система управлением событиями и информацией безопасности. Такую систему можно условно поделить на 2 основные части — подсистему сбора событий и подсистему анализа полученных событий. Правильная настройка первой поможет обнаружить вторжение на ранних этапах проникновения, облегчит написание событий тревоги (алертов), а если вас всё-таки взломали, то позволит разобраться, как и почему это произошло, какие действия выполняли злоумышленники. Основным инструментом для сбора системных событий в линукс-системах является auditd. На основе этого инструмента созданы и другие, например, auditbeat, go-audit, которые дополняют основной функционал auditd. Поэтому, разобравшись с основными принципами работы базового инструмента, вам не составит труда воспользоваться и всеми остальными.

  • Краткое знакомство с инструментом: общее описание auditd, плюсы и минусы, синтаксис;
  • Принципы написания правил: практические советы по специфике инструмента, которые позволят делать меньше ошибок при работе с ним;
  • Как тестировать правила: порядок действий, который позволит внедрить наборы правил в инфраструктуру любого размера;
  • Алгоритм тестирования правил: упорядоченный список действий для проверки отдельно каждого правила и фильтров к нему;
  • Модель угроз: как рассматривать систему с точки зрения атакующего, чтобы ничего не забыть;
  • Пример: применяем полученные знания на практике.

Общее описание auditd

auditd (сокращение от Linux Audit Daemon) — нативный инструмент предназначенный для мониторинга событий операционной системы и записи их в журналы событий, разрабатываемый и поддерживаемый компанией RedHat. Был создан для тесного взаимодействия с ядром операционной системы — во время своей работы наблюдает за системными вызовами и может записывать события — чтение, запись, выполнение, изменение прав — связанные с файлами ОС. Таким образом, с его помощью можно отслеживать практически любые события, происходящие в операционной системе.

Плюсы auditd:
— работает на низком уровне мониторинга — отслеживает системные вызовы и действия с файлами;
— имеет неплохой набор утилит в комплекте для удобства работы;
— постоянно развивается и обновляется;
— бесплатен и легко устанавливается.

Минусы auditd:
— большинство событий, возникающих при атаках характерных для конкретного приложения, практически невозможно отслеживать поскольку на уровне системных вызовов и работе с файлами трудно отличить взлом от нормальной работы приложения. Такие события лучше отслеживать на уровне самих приложений;
— auditd может замедлять работу ОС. Это связанно с тем, что подсистеме аудита необходимо проводить анализ системных вызовов;
— не слишком гибок в настройке правил;
— на данный момент это не лучший инструмент для работы с контейнерами.

Файлы конфигурации и синтаксис

Рассмотрим основные примеры настроек и параметров, которые будут использоваться далее. Более полное руководство по auditd вы можете найти здесь. Основную информацию можно найти в мануалах к auditd и его инструментам.

Файлы конфигурации хранятся в /etc/audit/. Правила желательно хранить в /etc/audit/rules.d/*.rules, по умолчанию доступ к этой директории только у root’а. Обратите внимание на то, что файл с правилами в этой директории должен иметь название *.rules, иначе auditd не прочитает его без явного указания. Если вы решили хранить правила в другом месте, то владелец файла должен быть root. Помимо этого рекомендую выставить группу файла root и права 600, чтобы никто кроме root’а не мог работать с файлом конфигурации auditd, т.к. зная что логируется, атакующий может избежать обнаружения. То же самое касается и файлов с правилами для других инструментов.

Правила для логирования можно добавлять следующими способами:
— записать его в файл(ы) /etc/audit/rules.d/.rules и перезапустить сервис;
— записать в файл по произвольному пути и указать его явно: auditctl -R ;
— добавить правило утилитой auditctl [-A,-a] .

Синтаксис

Подробное описание синтаксиса на русском языке можно посмотреть здесь.

-D — удалить все правила. Обычно используется в начале файла, чтобы избежать неожиданностей;
-a [list,action],[action,list] — добавляет правило в конец списка правил. Списки и действия рассмотрим далее.

Основные варианты списков:
exit — Добавить правило к списку, отвечающему за точки выхода из системных вызовов. Этот список применяется, когда необходимо создать событие для аудита, привязанное к точкам выхода из системных вызовов.
exclude — Добавить правило к списку, отвечающего за фильтрацию событий определенного типа. Этот список используется, чтобы отфильтровывать ненужные события. Например, если вы не хотите видеть avc сообщения, вы должны использовать этот список. Тип сообщения задается в поле msgtype.

Варианты действий:
always — установить контекст аудита. Всегда заполнять его во время входа в системный вызов и всегда генерировать запись во время выхода из системного вызова;
never — аудит не будет генерировать никаких записей. Это может быть использовано для подавления генерации событий. Обычно необходимо подавлять генерацию вверху списка, а не внизу, т.к. событие инициируется на первом совпавшем правиле.

-A list,action — добавить правило в начало списка. Например, для удобство чтения правило находится ниже, чем должно быть по логике настроек, тогда можно использовать этот параметр.

-F [n=v | n!=v | nv | n=v | n&v | n&=v] — задать поле сравнения для правила. Атрибуты поля следующие: объект, операция, значение. Вы можете задать до 64 полей сравнения в одной команде. Каждое новое поле должно начинаться с -F. Аудит будет генерировать запись, если произошло совпадение по всем полями сравнения. Допустимо использование одного из следующих 8 операторов: равно, не равно, меньше, больше, меньше либо равно, больше либо равно, битовая маска (n&v) и битовая проверка (n&=v). Битовая проверка выполняет операцию «and» над значениями и проверяет, равны ли они. Битовая маска просто выполняет операцию «and». Поля, оперирующие с идентификатором пользователя, могут также работать с именем пользователя — программа автоматически получит идентификатор пользователя из его имени. То же самое можно сказать и про имя группы.

Поля сравнения и их описание:

  • a0, a1, a2, a3 — первые 4 аргумента системного вызова соответственно;
  • arch — так как система ориентируется на номера (не названия) системных вызовов, а для многих системных вызовов номера отличаются для 32 и 64 разрядных систем, то необходимо указывать для какой архитектуры мы пишем правило;
  • auid — ID пользователя, с которым он вошёл в систему. Системные сервисы, как правило, имеют auid=-1 (или 4294967295);
  • dir — директория, за которой необходимо наблюдать. Будут залогированы и все события связанные с файлами и поддиректориями в указанной директории рекурсивно;
  • euid — действительный идентификатор пользователя;
  • exe — полный путь к исполняемому файлу. Может использоваться только с exit;
  • exit — значение, возвращаемое системным вызовом при выходе;
  • key — установка поля для фильтра. Добавляет поле с заданным именем в событие, что облегчает поиск событий в журналах;
  • msgtype — тип события. Весь список событий можно посмотреть здесь;
  • path — полный путь к файлу, за которым необходимо следить, может использоваться только с exit;
  • perm — то же, что и параметр -p, будет рассмотрен ниже;
  • success — если значение, возвращаемое системным вызовом, больше либо равно 0, данный объект будет равен «true/yes», иначе «false/no». При создании правила используйте 1 вместо «true/yes» и 0 вместо «false/no»;
  • uid — идентификатор пользователя;

Вместо числовых идентификаторов пользователей можно указывать имена (www-data, mail, irc), таким образом вам не придется учитывать их числовые различия на разных серверах.

-p — [r|w|x|a] — описывает разрешение доступа файла за которым нужно следить: чтение, запись, выполнение или изменение прав доступа соответственно;
-w — устанавливает наблюдение за директорией (рекурсивно) или файлом;
-W — исключает наблюдение за указанной директорией или файлом.

Стоит упомянуть про встроенные инструменты анализа полученных событий: ausearch, aureport. С их помощью удобно тестировать правила «на месте». Много интересных примеров правил можно посмотреть здесь.

Общие принципы написания правил

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

Чтобы избежать случаев, когда атакующий может узнать, какие его действия анализируются, нужно установить мониторинг за файлом с правилами логирования таким образом, чтобы при чтении этого файла любым пользователем возникало событие, а также перечислить команды, позволяющие узнать правила без чтения файлов конфигурации такие как audictl -l .
На основе этих событий можно сделать алерты. Если логи передаются по сети, то, помимо установки наблюдения за доступом к правилам, необходимо настроить шифрование данных.

В независимости от того, какой подход будет выбран вами между ними есть много общего и, не смотря на то что в примерах далее почти вся логика будет настраиваться на источнике событий, фильтры/правила можно писать как на стороне источника событий, так и в подсистеме анализа событий (или даже на промежуточном этапе).

При написании правил auditd необходимо учитывать следующее:

  1. Для каждого события отрабатывает лишь то подходящее правило, которое встретилось первым. Поэтому сначала пишутся фильтры и только потом правила. То же самое касается и выбора между несколькими правилами — выше размещать стоит то правило, которое важнее учитывать.
  2. Писать правила лучше от частного к общему. Допустим, вы хотите журналировать действия в директории /etc/. Чтобы потом в логах не искать прикладными утилитами (grep, sed или средствами SIEM) все события, связанные, например, с ssh, sudoers, passwd и т.д., сначала указываете правила для мониторинга конкретных директорий/файлов в /etc/ и только после этого размещаете правило для самой директории /etc/.
  3. В auditd есть преднастроенные правила и иногда возникают ситуации, когда они срабатывают и наши правила не учитываются. Поэтому каждое правило лучше предварительно тестировать отдельно.
  4. Если вы хотите написать правила с целью выявления конкретного случая (атаки, ситуации), то лучше определить общее звено и написать правило для него. Так, например, для обнаружения запуска интерактивных шеллов можно использовать обращения к /dev/tty, /dev/pts/. Чем лучше вы понимаете как работает ваша операционная система, тем лучше. Используя такой подход, злоумышленнику станет тяжелее избежать обнаружения.
  5. Для одного и того же действия с точки зрения пользователя может существовать несколько системных вызовов. Так для открытия файла могут использоваться: open, openat, creat, open_by_handle_at. Об этом стоит помнить, при создании правил на базе выборочных системных вызовов.
  6. Если вы написали правило и видите множество ложных срабатываний, то, возможно, вместо написания множества фильтров, следует выбрать другой подход к определению события логирования.

Как тестировать правила

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

  1. Проверка тестируемого правила на одном сервере. Чем ближе по составу установленного ПО сервер приближен к «боевой» среде, тем лучше. На этом этапе необходимо во-первых смоделировать условия, для которых написано правило, а во-вторых протестировать все возможные варианты поведения сервиса/приложения/пользователя, которые могут вызвать ложные срабатывания.
  2. Проверка тестируемого правила в составе имеющихся других правил. На этом этапе проводим тесты и убеждаемся в том, что всё по-прежнему работает как задумано: другие правила могут перекрывать новое и наоборот.
  3. Проверка нового набора правил на группе серверов. Снова, чем ближе к будущей инфраструктуре будут сервера по составу ПО, тем лучше. При необходимости этот этап можно повторять, увеличивая количество серверов.
  4. Применение правил на всей инфраструктуре. Если по предыдущим пунктам вы убедились в «безопасности» нового набора, то можно применять его на всей инфраструктуре.

Если у вас большое количество серверов, то всегда стоит помнить о том, что какой-то участок вашей инфраструктуры может сработать не так как ожидалось и породить большое количество событий, поэтому пути решения возможных проблем лучше обдумать сразу.

Алгоритм тестирования правил

Для каждого правила в частности будем использовать следующий алгоритм:

  1. Пробуем определить события для отслеживания по формуле: AA — SA = IE где AA — attacker’s actions — набор действий атакующего, SA — service actions — набор действий сервиса в ходе его обычной деятельности, IE — incident events — события инцидента. Положительный результат (события инцидента) в формуле и будет основной целью для нас. Каждый набор действий состоит из системных вызовов и обращений к файлам. Эта формула может быть особенно полезна в случае с обнаружением инцидентов. Если явно выявить события инцидента не получается, то можно определить события, которые помогут при расследовании инцидента: обращения к важным файлам, выполнение команд и пр. На мой взгляд — хорошее правило то, для которого не нужно писать много фильтров и порождает события, по которым с высокой вероятностью можно сказать, что произошёл инцидент.
  2. Пишем правило(а) для набора действий определенных в пункте 1.
  3. Применяем правила: помимо событий которые мы хотим отслеживать, могут попадаться и другие события, о которых мы не знаем. Поэтому здесь необходимо создать как можно больше возможных вариантов легитимного поведения сервиса или событий, чтобы выявить действия сервиса, которые могут вызывать события по нашему правилу.
  4. Пишем фильтры: если мы нашли такие события (п.3) то стоит подумать — можем ли мы от них избавиться. Писать фильтры желательно максимально точно, чтобы не «зацепить» лишних событий. В статье будет предложен вариант с написанием фильтров на хостах-источниках событий.
  5. Моделируем ситуацию: создаём ситуацию, для которой написали правило и убеждаемся, что создаются необходимые события.

Модель угроз

Модель угроз для определения отслеживаемых событий, на мой взгляд, стоит рассматривать аналогично классическому: для обнаружения инцидента определяем все возможные способы взлома (вся информация, которая попадает на сервер), для расследования — вся информация, за которой мы хотим наблюдать. На этом этапе будет полезно устроить мозговой штурм среди коллег с целью составления способов взлома и/или проникновения на сервер в случае с обнаружением инцидента, а также наблюдаемых ресурсов для расследования. Затем можно в каждой из подгрупп провести ранжирование по важности отслеживаемых событий, после чего приступать к написанию правил. Подробную моделирование угроз выполнять не будем, т.к. это отдельная большая тема. Рассмотрим подгруппы подробнее.

Обнаружение инцидентов
С точки зрения логирования будем считать инцидентом ситуацию, при которой у атакующего появилась возможность выполнения команд и/или чтения файлов операционной системы. Для написания правил по обнаружению инцидентов, необходимо понять, каким образом он может вообще возникнуть. Поскольку для взлома сервера на него должны каким-то образом попасть данные от атакующего по сети, то в первую очередь необходимо определить пути попадания такой информации. Это любые сервисы, которые устанавливают соединения наружу и/или принимают входящие соединения. Причем чем раньше мы сможем установить факт компрометации сервера, тем, очевидно, лучше. Основные способы выполнения команд на сервере:
— выполнение уже имеющихся исполняемых файлов (файлы директорий /bin/, /usr/bin/ и т.д.) — самый популярный способ. Например, атакующий получил доступ к командной оболочке напрямую или через имитацию шелла;
— выполнение команд через запись в файлы. Пример — планировщик задач cron. Если вы используете файлы, содержимое которых может быть выполнено как команды системой, то за ними необходим контроль;
— выполнение команд напрямую через системные вызовы — такой способ может применяться, например, в ходе «бинарных» атак: переполнения стека, кучи и т.д.

Что касается файлов, то наша задача определить те, что используется сервисом в обычной деятельности точно исключить такие события, поскольку в случае взлома сервиса, определить аномалию по отношению к таким файлам очень сложно.

Помимо вышеперечисленного, будем опираться на этапы проведения атаки:

  1. Сканирование сервера.
    Злоумышленник производит обнаружение открытых портов на сервере извне.
  2. Атака сервера, эксплуатация.
    На этом этапе злоумышленник каким-либо образом получает возможность чтения файлов, выполнению команд или системных вызовов на сервере. В этот условный этап будем относить все действия атакующего вплоть до момента выполнения любой первой команды и/или чтения первого файла, когда ему необходимо понять, что он смог добиться успеха в проведении атаки.
  3. Взаимодействие с сервером, постэксплуатация.
    Вслед за взломом злоумышленник может попытаться закрепиться на сервере (оставить файл с шеллом, получить ssh-ключ и т.д.), найти информацию для продвижения вглубь инфраструктуры (поиск паролей, токенов в файлах, базах данных и т.д.).

Вы можете воспользоваться как уже имеющимися вариантами, например, mitre, так и использовать свой подход.

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

Пример

Обнаружение инцидентов

Основное отличие при работе по обнаружению инцидентов от расследования — стремление к созданию таких правил, события которых будут означать возникновение инцидента. Кратко: если возникло событие по правилу инцидента, то возник и сам инцидент.

В качестве примера возьмём сервер на котором есть http-сервис и ssh. Для каждого сервиса каждый этап взлома проведем через наш алгоритм. Проведём каждый сервис по этапам атаки через алгоритм, для каждого этапа будем применять формулу. Правила для расследования инцидентов рассмотрим отдельно позже, поскольку они подходят практически для любых видов сервисов. Все примеры ниже приведены на виртуальной ОС ubuntu 18.04, веб-сервер apache.

Будет полезен скрипт для автоматизации наших действий:

#!/bin/bash killall -9 /sbin/auditd 2>/dev/null; \ systemctl stop auditd; \ systemctl stop apache2; \ sleep 2; \ rm /var/log/audit/audit.log*; \ systemctl start auditd; \ systemctl start apache2; \ auditctl -R /home/ubuntu/auditd/apache.rules > /dev/null 2>&1; \ auditctl -l; \ wc -l /var/log/audit/audit.log

Для быстрого завершения сначала убиваем процессы auditd, останавливаем сервисы auditd и apache2 (иногда без перезапуска apache2 правила по какой-то причине не применяются), удаляем все журналы логов, чтобы в поиске не выдавались старые результаты, запускаем сервисы, читаем правила из файла /home/ubuntu/auditd/apache.rules, проверяем список примененных правил, чтобы убедиться в что они работают и проверяем количество записей в файле лога аудита.

В первой строке -D используется для очистки существующих правил, которые мы могли забыть, чтобы избежать неожиданного поведения.

HTTP-Сервис

HTTP. Сканирование сервиса

  1. На уровне системных вызовов мы можем определить лишь то сканирование, которое используют вызов connect, потому что тогда наш сервер использует accept во время установления соединения. В большинстве случаев мы не можем отличить соединение злоумышленника, поскольку такое соединение ни чем не отличается от обычных пользователей. Однако, если у вас такой веб-сервер находится внутри инфраструктуры и есть ограниченное количество сетевых устройств, которые могут к нему подключаться, то такое правило может иметь смысл в случае определения белого списка сетевых устройств устанавливающих соединение.
  2. Правило для auditd будет выглядеть следующим образом:

-a exit,always -S accept -S accept4 -F exe=/usr/sbin/apache2 -k accept
nc -z localhost 80
$ ausearch -k apache_accept -i ---- type=PROCTITLE msg=audit(12.08.2021 16:05:29.654:395) : proctitle=/usr/sbin/apache2 -k start type=SOCKADDR msg=audit(12.08.2021 16:05:29.654:395) : saddr= < fam=inet6 laddr=::ffff:127.0.0.1 lport=37112 >type=SYSCALL msg=audit(12.08.2021 16:05:29.654:395) : arch=x86_64 syscall=accept4 success=yes exit=11 a0=0x4 a1=0x7ffd4ca5c800 a2=0x7ffd4ca5c7e0 a3=0x80000 items=0 ppid=5041 pid=5050 auid=unset uid=www-data gid=www-data euid=www-data suid=www-data fsuid=www-data egid=www-data sgid=www-data fsgid=www-data tty=(none) ses=unset comm=apache2 exe=/usr/sbin/apache2 key=apache_accept

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

HTTP. Атака сервиса

  1. На данном этапе злоумышленник каким-либо образом получил возможность читать файлы ОС или выполнять команды. Можем предположить, что действия атакующего будут затрагивать файлы в директориях /bin/, /usr/bin/, часто пытаются прочитать файл /etc/passwd как в ходе автоматизированной так и при ручной атаках. Действия веб-сервера в большинстве случаев находится в директории /var/www/. Таким образом, возникает идея логировать действия для пользователя www-data везде, кроме директории /var/www.
  2. Далее пишем правила для наших предположений:

-a never,exit -F dir=/var/www/ -F uid=www-data -w / -F uid=www-data -k apache_alert

После этого загружаем через браузер этот файл, останавливаем и запускаем службу: Логи

---- time->Thu Aug 12 20:35:45 2021 type=PROCTITLE msg=audit(1628789745.294:566): proctitle=2F7573722F7362696E2F61706163686532002D6B007374617274 type=PATH msg=audit(1628789745.294:566): item=0 name="/usr/share/zoneinfo/Africa" inode=2359764 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(1628789745.294:566): cwd="/var/www/html" type=SYSCALL msg=audit(1628789745.294:566): arch=c000003e syscall=257 success=yes exit=12 a0=ffffff9c a1=5555bf2ae6a0 a2=90800 a3=0 items=1 ppid=6496 pid=6505 auid=4294967295 uid=33 gid=33 euid=33 suid=33 fsuid=33 egid=33 sgid=33 fsgid=33 tty=(none) ses=4294967295 comm="apache2" exe="/usr/sbin/apache2" key="apache_alert" ---- time->Thu Aug 12 20:35:45 2021 type=PROCTITLE msg=audit(1628789745.294:567): proctitle=2F7573722F7362696E2F61706163686532002D6B007374617274 type=PATH msg=audit(1628789745.294:567): item=0 name="/usr/share/zoneinfo/America" inode=2359765 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(1628789745.294:567): cwd="/var/www/html" type=SYSCALL msg=audit(1628789745.294:567): arch=c000003e syscall=257 success=yes exit=12 a0=ffffff9c a1=5555bf2a5fa0 a2=90800 a3=0 items=1 ppid=6496 pid=6505 auid=4294967295 uid=33 gid=33 euid=33 suid=33 fsuid=33 egid=33 sgid=33 fsgid=33 tty=(none) ses=4294967295 comm="apache2" exe="/usr/sbin/apache2" key="apache_alert" ---- time->Thu Aug 12 20:35:45 2021 type=PROCTITLE msg=audit(1628789745.294:568): proctitle=2F7573722F7362696E2F61706163686532002D6B007374617274 type=PATH msg=audit(1628789745.294:568): item=0 name="/usr/share/zoneinfo/America/Argentina" inode=2359837 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(1628789745.294:568): cwd="/var/www/html" type=SYSCALL msg=audit(1628789745.294:568): arch=c000003e syscall=257 success=yes exit=12 a0=ffffff9c a1=5555bf2a7b50 a2=90800 a3=0 items=1 ppid=6496 pid=6505 auid=4294967295 uid=33 gid=33 euid=33 suid=33 fsuid=33 egid=33 sgid=33 fsgid=33 tty=(none) ses=4294967295 comm="apache2" exe="/usr/sbin/apache2" key="apache_alert" ---- time->Thu Aug 12 20:35:45 2021 type=PROCTITLE msg=audit(1628789745.294:569): proctitle=2F7573722F7362696E2F61706163686532002D6B007374617274 type=PATH msg=audit(1628789745.294:569): item=0 name="/usr/share/zoneinfo/America/Indiana" inode=2359838 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(1628789745.294:569): cwd="/var/www/html" type=SYSCALL msg=audit(1628789745.294:569): arch=c000003e syscall=257 success=yes exit=12 a0=ffffff9c a1=5555bf2a5790 a2=90800 a3=0 items=1 ppid=6496 pid=6505 auid=4294967295 uid=33 gid=33 euid=33 suid=33 fsuid=33 egid=33 sgid=33 fsgid=33 tty=(none) ses=4294967295 comm="apache2" exe="/usr/sbin/apache2" key="apache_alert" ---- time->Thu Aug 12 20:35:45 2021 type=PROCTITLE msg=audit(1628789745.294:570): proctitle=2F7573722F7362696E2F61706163686532002D6B007374617274 type=PATH msg=audit(1628789745.294:570): item=0 name="/usr/share/zoneinfo/America/Kentucky" inode=2359839 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(1628789745.294:570): cwd="/var/www/html" type=SYSCALL msg=audit(1628789745.294:570): arch=c000003e syscall=257 success=yes exit=12 a0=ffffff9c a1=5555bf2adea0 a2=90800 a3=0 items=1 ppid=6496 pid=6505 auid=4294967295 uid=33 gid=33 euid=33 suid=33 fsuid=33 egid=33 sgid=33 fsgid=33 tty=(none) ses=4294967295 comm="apache2" exe="/usr/sbin/apache2" key="apache_alert" ---- time->Thu Aug 12 20:35:45 2021 type=PROCTITLE msg=audit(1628789745.294:571): proctitle=2F7573722F7362696E2F61706163686532002D6B007374617274 type=PATH msg=audit(1628789745.294:571): item=0 name="/usr/share/zoneinfo/America/North_Dakota" inode=2359840 dev=08:01 mode=040755 ouid=0 ogid=0 rdev=00:00 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(1628789745.294:571): cwd="/var/www/html" type=SYSCALL msg=audit(1628789745.294:571): arch=c000003e syscall=257 success=yes exit=12 a0=ffffff9c a1=5555bf2ade20 a2=90800 a3=0 items=1 ppid=6496 pid=6505 auid=4294967295 uid=33 gid=33 euid=33 suid=33 fsuid=33 egid=33 sgid=33 fsgid=33 tty=(none) ses=4294967295 comm="apache2" exe="/usr/sbin/apache2" key="apache_alert" . 
-a never,exit -F dir=/usr/share/zoneinfo/ -F uid=www-data

И еще один shell.php который имитирует простейший веб-шелл:

"; $cmd = ($_REQUEST['cmd']); system($cmd); echo "

"; die; >?>
Получим через браузер сначала read_file.php и выполним поиск по логам:

$ ausearch -k apache_alert -i ---- type=PROCTITLE msg=audit(12.08.2021 23:12:08.373:688) : proctitle=/usr/sbin/apache2 -k start type=PATH msg=audit(12.08.2021 23:12:08.373:688) : item=0 name=/etc/passwd inode=264156 dev=08:01 mode=file,644 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(12.08.2021 23:12:08.373:688) : cwd=/var/www/html type=SYSCALL msg=audit(12.08.2021 23:12:08.373:688) : arch=x86_64 syscall=openat success=yes exit=12 a0=0xffffff9c a1=0x7ffea2903630 a2=O_RDONLY a3=0x0 items=1 ppid=3410 pid=3419 auid=unset uid=www-data gid=www-data euid=www-data suid=www-data fsuid=www-data egid=www-data sgid=www-data fsgid=www-data tty=(none) ses=unset comm=apache2 exe=/usr/sbin/apache2 key=apache_alert 

После этого в браузере выполним запрос:
http://192.168.0.101/shell.php?cmd=ls И выполнив поиск по логам, увидим, что добавились события:

---- type=PROCTITLE msg=audit(12.08.2021 23:14:57.566:707) : proctitle=sh -c ls type=PATH msg=audit(12.08.2021 23:14:57.566:707) : item=0 name=/etc/ld.so.cache inode=265858 dev=08:01 mode=file,644 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(12.08.2021 23:14:57.566:707) : cwd=/var/www/html type=SYSCALL msg=audit(12.08.2021 23:14:57.566:707) : arch=x86_64 syscall=openat success=yes exit=3 a0=0xffffff9c a1=0x7feec9ccbea8 a2=O_RDONLY|O_CLOEXEC a3=0x0 items=1 ppid=3422 pid=3433 auid=unset uid=www-data gid=www-data euid=www-data suid=www-data fsuid=www-data egid=www-data sgid=www-data fsgid=www-data tty=(none) ses=unset comm=sh exe=/bin/dash key=apache_alert ---- type=PROCTITLE msg=audit(12.08.2021 23:14:57.562:706) : proctitle=sh -c ls type=PATH msg=audit(12.08.2021 23:14:57.562:706) : item=1 name=/lib64/ld-linux-x86-64.so.2 inode=3156086 dev=08:01 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=PATH msg=audit(12.08.2021 23:14:57.562:706) : item=0 name=/bin/sh inode=1966114 dev=08:01 mode=file,755 ouid=root ogid=root rdev=00:00 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(12.08.2021 23:14:57.562:706) : cwd=/var/www/html type=EXECVE msg=audit(12.08.2021 23:14:57.562:706) : argc=3 a0=sh a1=-c a2=ls type=SYSCALL msg=audit(12.08.2021 23:14:57.562:706) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x7f5978e1de1a a1=0x7ffea29045e0 a2=0x7ffea29073d8 a3=0x1 items=2 ppid=3422 pid=3433 auid=unset uid=www-data gid=www-data euid=www-data suid=www-data fsuid=www-data egid=www-data sgid=www-data fsgid=www-data tty=(none) ses=unset comm=sh exe=/bin/dash key=apache_alert . 

Результат: такими правилами мы обнаружим любое обращение к файлам, которые не используются веб-сервером в рамках привычной своей деятельности и могут являться целью злоумышленника. В приведенном примере использовался веб-сервер без каких-либо приложений, фильтров может быть больше, однако, если вам удастся подобным образом написать правила, то многие наиболее критичные виды веб-уязвимостей (RCE, LFI, SSTI, XXE и т.д.) при выполнении команд в системе или чтении файлов могут быть обнаружены в момент их реализации.
В случае, если исключений слишком много. можно пойти другим путем и написать правила для наблюдения только за наиболее важными директориями в системе. Например:

# dirs from PATH var -w /bin -F uid=www-data -k apache_alert -w /usr/local/sbin -F uid=www-data -k apache_alert -w /usr/local/bin -F uid=www-data -k apache_alert -w /usr/sbin -F uid=www-data -k apache_alert -w /usr/bin -F uid=www-data -k apache_alert -w /sbin -F uid=www-data -k apache_alert -w /etc -F uid=www-data -k apache_alert

Таким образом при обращении пользователя веб-сервера к исполняемым файлам системы будут созданы соответствующие события.

HTTP. Постэксплуатация

Поскольку на предыдущем шаге мы установили наблюдение за почти всеми возможными . непокрытое поле для злоумышленника остаётся только в директории /var/www/. Можем предположить, что он может попытаться записать новый файл с функционалом для веб-приложения или изменить существующий для реализации новой логики. Если у вас приложение не создаёт динамических страниц, то для обнаружения изменений в существующих файлах веб-приложения можно написать следующие правила:

-w /var/www/ -p wa -F uid=www-data -k apache_file_change

Тогда для всех случаев когда файлы открываются для записи или изменения прав веб-сервером будут записаны события. Это правило необходимо разместить над фильтрами. Итоговый набор правил может выглядеть так:

-D -w /var/www/ -p wa -F uid=www-data -k apache_file_change -a never,exit -F dir=/usr/share/zoneinfo/ -F uid=www-data -a never,exit -F dir=/var/www/ -F uid=www-data -w / -F uid=www-data -k apache_alert
SSH сервис

Немного забегая вперёд, стоит отметить, что правила по обнаружению инцидентов возникающих через ssh-сервис очень схожи с правилами по расследованию инцидентов, поэтому многие правила из этого раздела можно использовать и при расследовании инцидентов. Это связано со спецификой самого ssh-сервиса.

SSH. Сканирование сервиса

Данный этап идентичен с этапом для HTTP-сервиса, поэтому его пропускаем.

SSH. Атака сервиса

Учитывая назначение сервиса, объеденим атаку и постэскплуатацию — поскольку взлом самого сервиса маловероятен, сфокусируемся на случае, когда злоумышленник получил доступ к сервису «популярным» способом — узнал пароль или ключ.

    Определим действия. Рассматривать атакую перебор учетных данных сервиса не будем, т.к. есть более удобные инструменты для отслеживания таких атак, однако стоит отметить, что по умолчанию в журналы аудиты попадают все события связанные с попытками логина и аутентификации. Пример неудачной попытки ввода учетных данных:

time->Fri Aug 13 14:45:27 2021 type=USER_LOGIN msg=audit(1628855127.918:860): pid=8622 uid=0 auid=4294967295 ses=4294967295 msg='op=login acct=28756E6B6E6F776E207573657229 exe="/usr/sbin/sshd" hostname=? addr=192.168.0.104 terminal=sshd res=failed' ---- time->Fri Aug 13 14:45:27 2021 type=USER_LOGIN msg=audit(1628855127.918:861): pid=8622 uid=0 auid=4294967295 ses=4294967295 msg='op=login acct=28696E76616C6964207573657229 exe="/usr/sbin/sshd" hostname=? addr=192.168.0.104 terminal=sshd res=failed' ---- time->Fri Aug 13 14:45:30 2021 type=USER_AUTH msg=audit(1628855130.974:862): pid=8622 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication acct="testy" exe="/usr/sbin/sshd" hostname=192.168.0.104 addr=192.168.0.104 terminal=ssh res=failed' ---- time->Fri Aug 13 14:45:30 2021 type=USER_LOGIN msg=audit(1628855130.974:863): pid=8622 uid=0 auid=4294967295 ses=4294967295 msg='op=login acct=28696E76616C6964207573657229 exe="/usr/sbin/sshd" hostname=? addr=192.168.0.104 terminal=sshd res=failed'
$ ls /usr/share/doc/auditd/examples/rules 10-base-config.rules 12-cont-fail.rules 21-no32bit.rules 30-nispom.rules.gz 31-privileged.rules 41-containers.rules 70-einval.rules README-rules 10-no-audit.rules 12-ignore-error.rules 22-ignore-chrony.rules 30-pci-dss-v31.rules.gz 32-power-abuse.rules 42-injection.rules 71-networking.rules 11-loginuid.rules 20-dont-audit.rules 23-ignore-filesystems.rules 30-stig.rules.gz 40-local.rules 43-module-load.rules 99-finalize.rules

Для каждого события будем добавлять строку «susp_», по этому ключу можно будет найти любые подозрительные действия в системе, а также удобно настраивать поиск в подсистеме анализа.
Начнём с логирования действий над самим инструментом:

-w /etc/audit/ -p wa -k susp_auditconfig -w /etc/audisp/ -p wa -k susp_audispconfig -w /sbin/auditctl -p x -k susp_audittools -w /sbin/auditd -p x -k susp_audittools -w /usr/sbin/augenrules -p x -k susp_audittools -w /var/log/audit/ -k susp_auditlog

Запись или изменение прав файлов планировщика задач:

-w /etc/cron -p wa -k cron_change -w /etc/crontab -p wa -k cron_change -w /etc/cron.allow -p wa -k cron_change -w /etc/cron.d -p wa -k cron_change -w /etc/cron.deny -p wa -k cron_change -w /etc/cron.daily -p wa -k cron_change -w /etc/cron.hourly -p wa -k cron_change -w /etc/cron.monthly -p wa -k cron_change -w /etc/cron.weekly -p wa -k cron_change -w /etc/anacrontab -p wa -k cron_change -w /var/spool/cron -p wa -k cron_change -w /var/spool/cron/crontabs/root -p wa -k cron_change

Интересным кажется вариант с логированием выполнения команды sudo всеми пользователями, кроме того (тех), кому такие права не выданы:

-w /usr/bin/sudo -F auid!= -k susp_sudo

Важно наблюдать за работой сетевых утилит:

-w /sbin/iptables -p x -k susp_netutil -w /sbin/ip6tables -p x -k susp_netutil -w /sbin/ifconfig -p x -k susp_netutil -w /usr/sbin/arptables -p x -k susp_netutil -w /usr/sbin/ebtables -p x -k susp_netutil -w /sbin/xtables-nft-multi -p x -k susp_netutil -w /usr/sbin/nft -p x -k susp_netutil

Особый интерес представляют события, связанные с различными нарушениями доступа пользователей: при чтении, записи, изменении файлов:

## File Access ### Unauthorized Access (unsuccessful) -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k file_access -a always,exit -F arch=b32 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k file_access -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EACCES -F auid>=1000 -F auid!=-1 -k file_access -a always,exit -F arch=b64 -S creat -S open -S openat -S open_by_handle_at -S truncate -S ftruncate -F exit=-EPERM -F auid>=1000 -F auid!=-1 -k file_access ### Unsuccessful Creation -a always,exit -F arch=b32 -S creat,link,mknod,mkdir,symlink,mknodat,linkat,symlinkat -F exit=-EACCES -k file_creation -a always,exit -F arch=b64 -S mkdir,creat,link,symlink,mknod,mknodat,linkat,symlinkat -F exit=-EACCES -k file_creation -a always,exit -F arch=b32 -S link,mkdir,symlink,mkdirat -F exit=-EPERM -k file_creation -a always,exit -F arch=b64 -S mkdir,link,symlink,mkdirat -F exit=-EPERM -k file_creation ### Unsuccessful Modification -a always,exit -F arch=b32 -S rename -S renameat -S truncate -S chmod -S setxattr -S lsetxattr -S removexattr -S lremovexattr -F exit=-EACCES -k file_modification -a always,exit -F arch=b64 -S rename -S renameat -S truncate -S chmod -S setxattr -S lsetxattr -S removexattr -S lremovexattr -F exit=-EACCES -k file_modification -a always,exit -F arch=b32 -S rename -S renameat -S truncate -S chmod -S setxattr -S lsetxattr -S removexattr -S lremovexattr -F exit=-EPERM -k file_modification -a always,exit -F arch=b64 -S rename -S renameat -S truncate -S chmod -S setxattr -S lsetxattr -S removexattr -S lremovexattr -F exit=-EPERM -k file_modification

Обратите внимание, что правила написаны для системных вызовов разных архитектур отдельно.
Как показала практика, у таких правил часто возникают ложные срабатывания, в таким случае их можно изменить, добавив срабатывание только на пользовательские действия. После опции -S необходимо добавить:

-F auid>=1000 -F auid!=-1

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

Расследование инцидентов

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

  • группы пользователей ОС и их идентификаторы (uid, euid, auid и др.): можно разбить пользователей на сервисных (uid 1-999) и остальных;
  • результаты выполнения команд: можно создать правила, которые будут записывать события по нарушению доступа к файлам: записи, чтения, выполнения, создания или системных вызовов;

При создании правил, используя условную классификацию по подсистемам, для каждой подсистемы необходимо определить файлы, за которыми необходимо наблюдение, системные вызовы и утилиты (исполняемые файлы). Для удобства составления правил ОС можно разбить на подсистемы по функциональному назначению, например:

  • работа с ядром ОС;
  • планировщик задач cron;
  • работа с сетью и сетевыми настройками;
  • операции с диском и файловой системой;
  • подсистема управления пользователями ОС;
  • подсистема установки/обновления ПО;
  • файлы конфигурации пользователей ОС;

Рассмотрим несколько примеров.

Подсистема логирования

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

## Auditd configuration ### Modifications to audit configuration that occur while the audit collection functions are operating -w /etc/audit/ -p wa -k auditconfig -w /etc/libaudit.conf -p wa -k auditconfig -w /etc/audisp/ -p wa -k audispconfig ## Monitor for use of audit management tools -w /sbin/auditctl -p x -k audittools -w /sbin/auditd -p x -k audittools ## Read and changing permissions alert -w /var/log/ -p ra -k log_alert

Устанавливаем наблюдение за файлами конфигурации auditd, его модулей, исполняемых файлов и логами.

Подсистема управления пользователями

## User, group, password databases -w /etc/group -p wa -k etcgroup -w /etc/passwd -p wa -k etcpasswd -w /etc/gshadow -k etcgroup -w /etc/shadow -k etcpasswd -w /etc/security/opasswd -k opasswd -w /etc/adduser.conf -k adduserconf ## Sudoers file changes -w /etc/sudoers -p wa -k actions ## Passwd -w /usr/bin/passwd -p x -k passwd_modification -w /usr/bin/gpasswd -p x -k gpasswd_modification ## Tools to change group identifiers -w /usr/sbin/groupadd -p x -k group_modification -w /usr/sbin/groupmod -p x -k group_modification -w /usr/sbin/addgroup -p x -k group_modification -w /usr/sbin/useradd -p x -k user_modification -w /usr/sbin/usermod -p x -k user_modification -w /usr/sbin/adduser -p x -k user_modification ## Login configuration and information -w /etc/login.defs -p wa -k login -w /etc/securetty -p wa -k login -w /var/log/faillog -p wa -k login -w /var/log/lastlog -p wa -k login -w /var/log/tallylog -p wa -k login

Выше перечислены основные команды, файлы логов и конфигурации по управлению пользователями ОС.

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

Заключение

По итогу можно сделать выводы:
1. Для ряда случаев можно настроить auditd, что позволит практически моментально выявить проникновение в систему — как в приведенном примере с apache;
2. В остальном — работа требует глубокого погружения и проработки.

На мой взгляд auditd — мощный инструмент, который, при грамотной настройке, может стать отличным дополнением в обеспечении информационной безопасности инфраструктуры.

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *