auditing activity where uid==0
Hi,
Here's my current rule, which is working, but is producing a lot of extra log that I'd like to suppress:
-a entry,always -S execve -F euid=0
I'm wondering if there's a way to limit this to only audit events that happen from a real tty, e.g. a human user. I'm getting lots of extraneous chatter from sshd, automount, and cron, all of which are from tty=(none), but I'm not sure it's possible to filter on tty...
Thanks
Quoted 4 lines · Rich Whitcroft
Here's my current rule, which is working, but is producing a lot of extra log that I'd like to suppress:
-a entry,always -S execve -F euid=0
I assume the intention is to log all programs executed when someone is running as root?
Quoted 2 lines
I'm wondering if there's a way to limit this to only audit events that happen from a real tty, e.g. a human user.
-a entry,always -S execve -F euid=0 -F auid>=500 -F auid!=4294967295
The loginuid is only set for real logins. But if they issue "service httpd restart", then apache has their loginuid, too, and you will start getting apache events.
Quoted 3 lines
I'm getting lots of extraneous chatter from sshd, automount, and cron, all of which are from tty=(none), but I'm not sure it's possible to filter on tty...
The way that we suggest auditing the actions of a root user is by using the tty audit capability. This is a little more specific about what is really happening. For example, someone could start a python shell and start issuing commands. If you audit by execve, then all you see is python start up and then you see nothing else. Also, bash can do networking. Its possible to transfer files using bash primitives that you won't pick up by auditing execve syscalls. Awk is also network aware...
-Steve
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 2 lines
-a entry,always -S execve -F euid=0 -F auid>=500 -F auid!=4294967295
Be aware that this rule does grab the nfsnobody user, which has a uid > 500.
Quoted 4 lines
The loginuid is only set for real logins. But if they issue "service httpd restart", then apache has their loginuid, too, and you will start getting apache events.
Yes, and this is quite painful.
Quoted 4 lines
Quoted 4 lines
I'm getting lots of extraneous chatter from sshd, automount, and cron, all of which are from tty=(none), but I'm not sure it's possible to filter on tty...
It's not as far as I could find, though this would be an awesome feature. Basically, the ability to say, tty!=none.
Quoted 8 lines
The way that we suggest auditing the actions of a root user is by using the tty audit capability. This is a little more specific about what is really happening. For example, someone could start a python shell and start issuing commands. If you audit by execve, then all you see is python start up and then you see nothing else. Also, bash can do networking. Its possible to transfer files using bash primitives that you won't pick up by auditing execve syscalls. Awk is also network aware...
One thing to note about the tty audit capability is that it is a forward processing logger, not an echo logger. This means that it *will* capture passwords that you type in at the command line even if they are not echoed.
You may want to look at something like sudosh or the like which are echo loggers and will not collect anything that is hidden from the terminal.
This presents it's own problems, but at least won't grab sensitive
passwords in general.
Trevor
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
iEYEARECAAYFAksY7boACgkQyjMdFR1108BQxQCeNnLC/430OiNSHVZVhU2GdJ6h BEwAn34K52cRhSZsDQ1PpFbtqP1tnqwa
=7MfW
-----END PGP SIGNATURE-----
Quoted 6 lines · Trevor Vaughan
Quoted 3 lines
Quoted 3 lines
I'm getting lots of extraneous chatter from sshd, automount, and cron, all of which are from tty=(none), but I'm not sure it's possible to filter on tty...
It's not as far as I could find, though this would be an awesome feature. Basically, the ability to say, tty!=none.
This can be easily subverted by an attacker. Open af_unix socket, pass descriptor, do not read it, close stdin - stdout and do evil work, then read socket and use tty input/output again.
Quoted 10 lines
Quoted 7 lines
The way that we suggest auditing the actions of a root user is by using the tty audit capability. This is a little more specific about what is really happening. For example, someone could start a python shell and start issuing commands. If you audit by execve, then all you see is python start up and then you see nothing else. Also, bash can do networking. Its possible to transfer files using bash primitives that you won't pick up by auditing execve syscalls. Awk is also network aware...
One thing to note about the tty audit capability is that it is a forward processing logger, not an echo logger.
I prefer to call it a keystroke logger because it gets all of them.
Quoted 2 lines
This means that it will capture passwords that you type in at the command line even if they are not echoed.
True and they are protected by needing root level access to get at them. Anyone that has root access can install a rootkit to grab passwords just as easily. If the concern is that these could be stored and looked at by anyone with access to the backed up logs, then use gpg to encrypt the files.
Quoted 2 lines
You may want to look at something like sudosh or the like which are echo loggers and will not collect anything that is hidden from the terminal.
Those are easily subverted, though.
Quoted 2 lines
This presents it's own problems, but at least won't grab sensitive
passwords in general.
All protection profiles state that root is trusted. There are at least 20 covert channels I can think of that would let an evil admin get a user's private keys/data or credentials.
-Steve