Назад | Перейти на главную страницу

Аудит активности пользователей при использовании сертификатов SSH

В последнее время я много читаю на Сертификаты SSH и мне нравятся его преимущества.

Прежде чем вкладывать время в создание собственного POC, я хотел знать, как (если вообще) можно было бы проводить аудит активности пользователей при использовании сертификатов SSH. Насколько я понимаю, открытые ключи конечных пользователей будут подписаны ЦС с одним или несколькими конкретными участниками (например, root), что позволит пользователю использовать ssh для хоста в качестве этого принципала. Когда пользователь входит в систему на удаленном хосте, журнал авторизации записывает имя пользователя в качестве идентификатора, поэтому мы знаем, кто вошел в систему как основной «корень». Однако, как только пользователь входит в систему, как мы можем контролировать его активность с помощью таких инструментов, как auditd (или любые альтернативы), и привязать ее к конкретному пользователю, а не, скажем, к основному «root»?

Пример статьи о настройке аутентификации на основе сертификата SSH, на которую я ссылаюсь: Вот

Сертификаты SSH - хорошая идея, особенно если есть хорошая настройка CA.

Поскольку у меня нет такой настройки, я могу просто предоставить некоторые подробности об auditd в средах LDAP / sudo. Интересные значения здесь - это AUID. Этот идентификатор устанавливается только один раз при входе пользователя в систему и наследуется все другие команды выполнены. Даже после успешного sudo это установлено на правильное значение.

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-understanding_audit_log_files

Например, посмотрите этот демонстрационный журнал из ssh за которым следует sudo выполнение некоторых ls команды.

Перед sudo как обычный пользователь

type=SYSCALL msg=audit(1578248454.617:38779): arch=c000003e syscall=59 success=yes exit=0 a0=561f7a660c60 a1=561f7a687970 a2=561f7a650dc0 a3=8 items=2 ppid=335333 pid=335427 auid=1000 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=pts4 ses=5 comm="ls" exe="/usr/bin/ls" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key="execve_rule"ARCH=x86_64 SYSCALL=execve AUID="hargut" UID="hargut" GID="hargut" EUID="hargut" SUID="hargut" FSUID="hargut" EGID="hargut" SGID="hargut" FSGID="hargut"
type=EXECVE msg=audit(1578248454.617:38779): argc=2 a0="ls" a1="--color=auto"
type=CWD msg=audit(1578248454.617:38779): cwd="/home/hargut"
type=PATH msg=audit(1578248454.617:38779): item=0 name="/usr/bin/ls" inode=1311269 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID="root" OGID="root"
type=PATH msg=audit(1578248454.617:38779): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=1311092 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID="root" OGID="root"
type=PROCTITLE msg=audit(1578248454.617:38779): proctitle=6C73002D2D636F6C6F723D6175746F

после переключения с sudo su

type=SYSCALL msg=audit(1578248552.217:38816): arch=c000003e syscall=59 success=yes exit=0 a0=559f01994380 a1=559f019869c0 a2=559f01984000 a3=8 items=2 ppid=335442 pid=335478 auid=1000 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts4 ses=5 comm="ls" exe="/usr/bin/ls" subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)ARCH=x86_64 SYSCALL=execve AUID="hargut" UID="root" GID="root" EUID="root" SUID="root" FSUID="root" EGID="root" SGID="root" FSGID="root"
type=EXECVE msg=audit(1578248552.217:38816): argc=3 a0="ls" a1="--color=auto" a2="hello"
type=CWD msg=audit(1578248552.217:38816): cwd="/home/hargut"
type=PATH msg=audit(1578248552.217:38816): item=0 name="/bin/ls" inode=1311269 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:bin_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID="root" OGID="root"
type=PATH msg=audit(1578248552.217:38816): item=1 name="/lib64/ld-linux-x86-64.so.2" inode=1311092 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:ld_so_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0OUID="root" OGID="root"
type=PROCTITLE msg=audit(1578248552.217:38816): proctitle=6C73002D2D636F6C6F723D6175746F0068656C6C6F

Вышеуказанные значения отслеживаются следующим правилом аудита:

-a exit,always -F arch=b64 -S execve -k execve_rule

Чтобы полностью покрыть систему и все execve syscalls необходимо добавить дополнительное правило для arch=b32.

Важно то, что журналы аудита часто содержат несколько строк, которые принадлежат друг другу. Обычно большинство execve записи будут иметь 5-6 строк для каждого исполнения. В этом случае эти строки могут быть сопоставлены идентификатором аудита, например 1578248454.617:38779 или 1578248552.217:38816. Хорошо видно, что UID и GID для второго звонка 0 что означает эффективно root, по-прежнему AUID установлен на 1000 который соответствует идентификатору пользователя в системе.

https://linux.die.net/man/8/auditd.conf

В auditd.conf вариант log_format = ENRICHED будет полезно преобразовать id в имена. Это доступно из auditd> 2.6.

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