I've got a Splunk forwarder installed on a server. This server is also logging its commands via auditd.
When I do something like sudo su -
, auditd captures the output, but doesn't expose passwords. An example:
type=USER_AUTH msg=audit(1469642237.076:4664554): user pid=29165 uid=565 auid=565 ses=225532 msg='op=PAM:authentication acct="ME" exe="/usr/bin/sudo" hostname=? addr=? terminal=/dev/pts/14 res=failed'
However, the Splunk forwarder gives much more information, including the password you type on the command line. This is a pretty straight forward install of the forwarder - no fancy stuff going on. How can I use the Splunk forwarder without exposing users' passwords, like auditd does?
Thanks in advance.
The forwarder likely isn't collecting the password itself, instead it's reading log files. I'd check what log files the forwarder is configured to read, and manually check for passwords in those. Then configure whatever's writing those log files to not log passwords.
The problem ended up being this line added to /etc/pam.d/sshd
session required pam_tty_audit.so enable=*
Removing that line fixed the issue.
When I see passwords, I have:
host = MYHOST source = auditd sourcetype = auditd
When I don't see passwords, I have:
host = MYHOST source = /var/log/audit/audit.log sourcetype = linux_audit
gregcain, keep in mind please that there is a Splunk app called Linux Auditd
I wonder whether this app handles the data streaming as well...
I am aware of that splunk app, but we don't have it installed.
The forwarder likely isn't collecting the password itself, instead it's reading log files. I'd check what log files the forwarder is configured to read, and manually check for passwords in those. Then configure whatever's writing those log files to not log passwords.
\o/ would have been weird for the forwarder to make up correct passwords... take a very good look at your auditd, afaik TTY-logging doesn't log sudo passwords.
Hi,
If there is any configuration changes, if it doesn't log sudo passwords.
Ah, I see. Let me guess - you also find events for sourcetype=linux_audit type=TTY
, but the data field is a bunch of hex code? (please don't post that hex uncensored!)
If so, your linux_audit also contains passwords - just as hex-encoded ascii. As a corollary, your /var/log/audit/audit.log also contains virtually-plaintext passwords.
The difference between the two? The rlog.sh script you mentioned pipes the events through ausearch which decodes the hex-encoded ascii back into actual ascii.
Hey, you're exactly right. So the finger is pointed directly at the auditd on MYHOST.
This appears to be the intended behavior of the rlog.sh script, so I expect it's auditd that's mis-configured.
Thanks again for your help. I'm off to fix auditd.
Following the configuration from the article doesn't help in bypassing password via auditd.
is it possible to do it??
hi,
I did re-configure the auditd, by removing the log_passwd from the /etc/pam.d/system-auth. Still from "ausearch -i" displays the plain text password.
How it be avoided, kindly suggest.
Thanks for this. It was exactly what I needed. This forum, and redhat support, came in with a virtual tie for the solution. Kudos.
Let's rerun that race with an actually splunk-related question and see how the wrongly-coloured-hat people do 😄
What does an event with a password look like? (password censored, of course)
type=TTY msg=audit(07/27/2016 11:05:22.357:4664859) : tty pid=31096 uid=ME auid=ME ses=225532 major=136 minor=14 comm=ssh data="sudo su -",,"PASSWORD",,"PASSWORD",,"PASSWORD",,,,"PASSWORD",,"cd /var/log",,"ls -l",,"ls -l btmp",,"mkdi",,,,,"touch btmp",,"chown 6000",,,,,"root:utmp btmp",,"chmod 600 btmp",,"ls -l btmp",,"lastb",,"su - alkjadfkljasd",,"lasb",,"tb",,"lastb",,"exit",,<^D>
host = MYHOST source = auditd sourcetype = auditd
source = auditd sourcetype = auditd
suggests there are two ways the forwarder is ingesting the audit logs - the file is fine, but it's getting the info from somewhere else as well.
What inputs have you deployed onto the forwarder besides the file monitors listed above?
Under data inputs >> scripts, I have one script with a sourcetype of auditd. It is part of the Splunk Add-on for Unix and Linux, and lives under /opt/splunk/etc/apps/Splunk_TA_nix/bin/rlog.sh.
That script has a SEEK_FILE that looks interesting, but it doesn't exist.
If there is no log file with that information, where is the forwarder reading it from?
Check its input configuration with splunk list monitor
on the command line. Any information the forwarder is forwarding must have been read from such a file. (plus other types of input such as scripts, network, etc)
This is what I've got:
splunk list monitor
Monitored Directories:
[No directories monitored.]
Monitored Files:
/etc
/Library/Logs
/opt/secret-directory/aide/reports/ro/
/var/adm
/var/log