0

I have been reading a lot lately on SSH Certificates and i love the advantages it brings.

Before investing time in building my own POC, i wanted to know how (if at all) would it be possible to audit user activity when using SSH Certificates. Per my understanding, end users's public keys will be signed by the CA, with one or more specific Principals (e.g. root), allowing the user to ssh to a host as that principal. When the user logs into the remote host, the authlog captures the username as the ID, so we know who logged in as the principal "root". However, once the user logs in, how can we audit his activity using tools like auditd (or any alternatives) and tie it to the specific user, instead of to, say, principal "root"?

An example article i am referring to on setting up SSH Certificate based auth is here

cybervedaa
  • 161
  • 1
  • 1
  • 5
  • 3
    Once your users are granted access to the **root** account, it is difficult to distinguish them. It would be easier to give every person a different account and configure **sudo** to grant them administrative access. **sudo** by default logs every command executed. – Piotr P. Karwasz Jan 04 '20 at 18:13
  • ...but note that some people (like me!) quickly tire of prefixing every command with `sudo` and will just run either `sudo -i` or `sudo bash` to get a root shell, at which point it stops logging individual commands. (The commands likely will still end up in root's shell history file, but they're no longer tagged with who the actual user running them was.) But `sudo` is still generally the correct answer to this sort of use case, regardless. – Dave Sherohman Jan 06 '20 at 08:10

1 Answers1

2

SSH certificates are a good idea, especially in case there is a good CA setup in place.

As I've no setup like this around I can just provide some details on auditd in LDAP/sudo environments. The interesting values here is the AUID. This id is just set once at login of a user, and is inherited by all other commands executed. Even after a successful sudo this is set to the correct value.

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

For example see this demo log from a ssh followed by a sudo executing some ls commands.

Before sudo as regular user

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

after switching with 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

The above values have been tracked by the following audit rule:

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

To fully cover a system and all execve syscalls it would be necessary to add an additional rule for arch=b32.

Important is that audit logs often contain several lines which belong together. So typically most execve entries will have 5-6 lines for each execution. These lines can be correlated by the audit-id in this case e.g. 1578248454.617:38779 or 1578248552.217:38816. It is clearly visible that UID and GID for the second call are 0 which means effectively root, still AUID is set to 1000 which matches the userid on the system.

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

The auditd.conf option log_format = ENRICHED will be helpful to resolve id's to names. This is available from auditd > 2.6.

The statement that authlog captures the correct user leads me to the assumption that that this will work the same way with CA based authentication. Please let me know, once verified, if this assumption is true.

hargut
  • 3,908
  • 7
  • 10