Audit and record non-interactive ssh sessions
I'm looking for a way to audit user commands while in a non-interactive sessions. For example when a user runs 'ssh
any help would be greatly appreciated!
Responses
Guru
6827 points
Josh,
I don't have an immediate answer for the audit question for rhel 6 or 7, however.... Check the work of Shawn Wells of redhat (swells), an example (that may or may not be an immediate help) is at http://people.redhat.com/swells/scap-security-guide/RHEL/7/output/table-rhel7-cces.html.
Do you have root ssh enabled and not denied? My /etc/shadow is not readable by non-root users (and is set to 000),
This goes to the Red Hat Security guide, and in particular, the paragraphs for denying root login for RHEL 6 and 7:
- For RHEL 6, Consider 2.3 through 2.4 of this link.
- For RHEL 7, Consider 4.2 through 4.3 of this link.
Also, have you considered using aide?
Guru
6435 points
What do your audit rules look like? In general, you should be able to configure the audit service to capture exactly that kind of stuff (you can look at the STIG and/or SCAP guidance for examples).
I'm in the middle of writing a bunch of STIG-enforcement policies for our enterprise CM system, so the STIG contents are really fresh in mind. Looks like, while Section 2.7.4 talks about auditd configuration for the types of events your looking for are enumerated, the specific rules for the files listed in your original post aren't explicitly enumerated. That said, I do have them enumerated in another hardening tool I've been working on. I'll have to give it a look and verify that it's actually working as expected (don't have access to my development system, here, but I can post up what I find if there's anything of merit when I do get back to my dev-system).
Guru
6827 points
Josh,
Of course there are other ways to do this - and most certainly see Tom's bits above and the ideas he has there are certainly worth exploring. this is just one idea, and not all-inclusive by any means...
As a test on my workstation, I did the following:
- Added a file system audit rule against /etc/shadow that creates records for reads, writes, executes & appends against the shadow file.
auditctl -w /etc/shadow -k shadow-file -p rwxa
Restart auditd, add a blank line to /etc/shadow, ls the file and then check it:
service auditd restart
/bin/cp /etc/shadow /etc/shadow.justincase.datestamp
echo "" >> /etc/shadow
/bin/ls /etc/shadow
- Check to see who changed or accessed a file
ausearch -f /etc/shadow | egrep 'uid|vi
and if you have the actual UID, put it there where the UID is
ausearch -f /etc/shadow | egrep '2001|vi'
or just do a typical search first or redirect to a file
ausearch -f /etc/shadow | less
ausearch -f /etc/shadow > /path/to/myfile.txt
I was able to see that I edited the file (even while logged in as root), even did an ls against it. I was even able to detect that I did a cat command against the file: (as root below)
cat /etc/shadow
ausearch -f /etc/shadow | egrep '2001|vi|cat'
node=testvictim2.local.somewhere type=SYSCALL msg=audit(1419975765.501:3485): arch=c000003e syscall=2 success=yes exit=3 a0=71811400 a1=0 a3=5 items=1 ppid=18936 pid=20257 auid=2001 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts42 ses=1 comm="cat" exe="/bin/cat" key="CFG_shadow"
Cool. Don't need to VPN to my dev-host to check its rules and verify functionality.
Other good thing: Linux's auditd is a lot easier to get "proof" out of than Solaris's BSM was (though, now it makes me want to see whether auditd traces file changes via sudo/su back to the original login user the way Solaris's BSM+RBAC did).
Guru
6827 points
Josh,
At least on my system, I was able to determine that I started or stopped auditd by checking the /var/log/audit/audit.log after doing a 'service auditd restart'
# service auditd restart
<typical functioning output>
# grep -i auditd /var/log/audit/audit.log | egrep --color -i 'start' ;date
node=testvictim2.local.somewhere type=EVECVE msg=audit(1419977439.379:30099): argc=3 a0="bin/bash" a1="/etc/init.d/auditd" a2="restart"
node=testvictim2.local.somewhere type=DAEMON_START msg=audit(1419977441.509:280): auditd start, vers=2.2 format=raw kernel=[latest] auid=2001 pid=20404 res=success
I also tried
service auditd stop
service auditd start
and then I did a grep for "stop" and found in the output the stopping of auditd within audit.log
Later in the output, it did tattle on me for the service auditd stop and service auditd start
Guru
6827 points
Sure Josh, and I did a test just from a different workstation to 'testvictim2' (where I have my audit rules set), and the audit.log file picked up/tattled on me when I did "ls", "cat" commands or whatever against /etc/shadow (even if I was denied because I was a non-root user), with commands such as below
[me@testvictim3] $ ssh -q testvicim2 '/bin/cat /etc/passwd'
[me@testvictim3] $ ssh -q testvicim2 '/bin/ls /etc/passwd'
The cat received a 'permission denied', however the audit.log tattled on me anyway.
UPDATE: I remembered I have some highly configured /etc/audit/audit.rules and /etc/audit/auditd.conf files. I can't share these configs, but can perhaps find a resource for this later - I suspect that's partially what Tom was referring to.
Guru
6435 points
Yeah: between what the STIGs, SCAP profiles, CIS hardening-guides, NIST 800-53 and USGCB documents describe or recommend, you end up with a fairly lengthy audit config. Tie the whole mess to an inline script via rsyslog or syslog-ng, and you can even have the tattling email you a message, set an alert on your SNMP consoles or otherwise make red lights go off all over the damned place. =)
Guru
6435 points
Oh... The audit configs that Red Hat PS did for a STIG project contain many of them:
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.