Sending bash history to syslog
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
2
down vote
favorite
Bash version 4.N has apparently the ability to write command-history to syslog, but I can't find information about how to configure this.
I have read several pages which offer hacks using the PROMPT_COMMAND
, and trap, and I know that there's a patch available, but this should be unnecessary, as it is now built in.
I know I can use auditd
to capture commands, but I'd like to use the bash/syslog combination.
Can anyone advise, please?
bash command-history syslog
 |Â
show 3 more comments
up vote
2
down vote
favorite
Bash version 4.N has apparently the ability to write command-history to syslog, but I can't find information about how to configure this.
I have read several pages which offer hacks using the PROMPT_COMMAND
, and trap, and I know that there's a patch available, but this should be unnecessary, as it is now built in.
I know I can use auditd
to capture commands, but I'd like to use the bash/syslog combination.
Can anyone advise, please?
bash command-history syslog
see also unix.stackexchange.com/questions/422897/â¦
â Rui F Ribeiro
Jul 19 at 4:32
1
Except that having read that page, I explicitly want to avoid the use of auditd and the bash hackery suggested there. Nothing wrong with hackery in general, but I'd like something a little harder to subvert.
â Graham Nicholls
Jul 19 at 4:38
The no frills way to subvert both is using another shell-
â Rui F Ribeiro
Jul 19 at 5:28
Assuming that another shell is installed and available.
â Graham Nicholls
Jul 19 at 22:53
You do not need special privileges to copy/install/compile an alternate shell.
â Rui F Ribeiro
Jul 19 at 22:55
 |Â
show 3 more comments
up vote
2
down vote
favorite
up vote
2
down vote
favorite
Bash version 4.N has apparently the ability to write command-history to syslog, but I can't find information about how to configure this.
I have read several pages which offer hacks using the PROMPT_COMMAND
, and trap, and I know that there's a patch available, but this should be unnecessary, as it is now built in.
I know I can use auditd
to capture commands, but I'd like to use the bash/syslog combination.
Can anyone advise, please?
bash command-history syslog
Bash version 4.N has apparently the ability to write command-history to syslog, but I can't find information about how to configure this.
I have read several pages which offer hacks using the PROMPT_COMMAND
, and trap, and I know that there's a patch available, but this should be unnecessary, as it is now built in.
I know I can use auditd
to capture commands, but I'd like to use the bash/syslog combination.
Can anyone advise, please?
bash command-history syslog
edited Jul 20 at 4:46
ñÃÂsýù÷
14.6k82261
14.6k82261
asked Jul 18 at 23:06
Graham Nicholls
15310
15310
see also unix.stackexchange.com/questions/422897/â¦
â Rui F Ribeiro
Jul 19 at 4:32
1
Except that having read that page, I explicitly want to avoid the use of auditd and the bash hackery suggested there. Nothing wrong with hackery in general, but I'd like something a little harder to subvert.
â Graham Nicholls
Jul 19 at 4:38
The no frills way to subvert both is using another shell-
â Rui F Ribeiro
Jul 19 at 5:28
Assuming that another shell is installed and available.
â Graham Nicholls
Jul 19 at 22:53
You do not need special privileges to copy/install/compile an alternate shell.
â Rui F Ribeiro
Jul 19 at 22:55
 |Â
show 3 more comments
see also unix.stackexchange.com/questions/422897/â¦
â Rui F Ribeiro
Jul 19 at 4:32
1
Except that having read that page, I explicitly want to avoid the use of auditd and the bash hackery suggested there. Nothing wrong with hackery in general, but I'd like something a little harder to subvert.
â Graham Nicholls
Jul 19 at 4:38
The no frills way to subvert both is using another shell-
â Rui F Ribeiro
Jul 19 at 5:28
Assuming that another shell is installed and available.
â Graham Nicholls
Jul 19 at 22:53
You do not need special privileges to copy/install/compile an alternate shell.
â Rui F Ribeiro
Jul 19 at 22:55
see also unix.stackexchange.com/questions/422897/â¦
â Rui F Ribeiro
Jul 19 at 4:32
see also unix.stackexchange.com/questions/422897/â¦
â Rui F Ribeiro
Jul 19 at 4:32
1
1
Except that having read that page, I explicitly want to avoid the use of auditd and the bash hackery suggested there. Nothing wrong with hackery in general, but I'd like something a little harder to subvert.
â Graham Nicholls
Jul 19 at 4:38
Except that having read that page, I explicitly want to avoid the use of auditd and the bash hackery suggested there. Nothing wrong with hackery in general, but I'd like something a little harder to subvert.
â Graham Nicholls
Jul 19 at 4:38
The no frills way to subvert both is using another shell-
â Rui F Ribeiro
Jul 19 at 5:28
The no frills way to subvert both is using another shell-
â Rui F Ribeiro
Jul 19 at 5:28
Assuming that another shell is installed and available.
â Graham Nicholls
Jul 19 at 22:53
Assuming that another shell is installed and available.
â Graham Nicholls
Jul 19 at 22:53
You do not need special privileges to copy/install/compile an alternate shell.
â Rui F Ribeiro
Jul 19 at 22:55
You do not need special privileges to copy/install/compile an alternate shell.
â Rui F Ribeiro
Jul 19 at 22:55
 |Â
show 3 more comments
1 Answer
1
active
oldest
votes
up vote
5
down vote
accepted
This approach seems to be what you're looking for. This article discusses it, titled: Improving Bash Forensics Capabilities.
Excerpt:
While discussing with him about this topic, I realized that there are some ways to fine tune the history of commands to improve forensics investigations. In 2009, I also wrote a blog post about Bash which gave some ideas to send a Bash command history to a remote Syslog server. I checked my web logs and this blog post remains popular with more than 1000 visits for the last 30 days! Note that my blog post is outdated: Since the version 4.1, Bash supports Syslog natively but in most distribution, it is not enabled. To use this feature, you need to recompile your shell.
I found this not very convenient but the good point is that it cannot be disabled by the user (except if he switches his shell to another shell or another Bash binary). You just have to define "SYSLOG_HISTORY" in config-top.h:
$ vi config-top.h
#define SYSLOG_HISTORY
#if defined (SYSLOG_HISTORY)
# define SYSLOG_FACILITY LOG_USER
# define SYSLOG_LEVEL LOG_INFO
#endif
./configure
make install
So it would seem that though the feature is available in Bash 4.1+ it's likely not compiled by default with the Bash in most of the popular distros.
I haven't found a method for seeing what options a given Bash was compiled with, so to answer that question, you'll likely need to look to the upstream .spec
file used when building the Bash RPM, for example, on Redhat distros, the same approach can be used for Debian based distros as well.
As confirmation I looked in the Bash .spec
file for the Bash included with CentOS 7.2.1511 and it does not have this enabled:
$ grep configure bash.spec
%configure --with-bash-malloc=no --with-afs
- Use the configure macro instead of calling ./configure directly
Rolling your own RPM
Here are the steps that I used to build my own Bash using the gist of what the above details spelled out.
download & install source
To start I downloaded a source RPM (SRPM) of Bash that's available for CentOS 7.x. After downloading it I installed it into my rpmbuild
directory:
$ rpmdev-setuptree
$ rpm -ivh bash-4.2.46-20.el7_2.src.rpm
patch
This will unpack files into rpmbuild/SPEC
& rpmbuild/SOURCES
. Now we're going to make a copy of the contents of the unpacked Bash tar.gz
file using these steps:
$ cd rpmbuild/SOURCES
$ tar zxf bash-4.2.tar.gz
$ cp -prf bash-4.2 bash-4.2-orig
$ cd bash-4.2
Edit rpmbuild/SOURCES/bash-4.2/config-top.h
and make it look like this:
/* Define if you want each line saved to the history list in bashhist.c:
bash_add_history() to be sent to syslog(). */
#define SYSLOG_HISTORY
#if defined (SYSLOG_HISTORY)
# define SYSLOG_FACILITY LOG_LOCAL1
# define SYSLOG_LEVEL LOG_DEBUG
#endif
Edit rpmbuild/SOURCES/bash-4.2/bashhist.c
and make bash_syslog_history
function look like this:
void
bash_syslog_history (line)
const char *line;
SYSLOG_LEVEL, "HISTORY: PID=%d UID=%d USER=%s CMD=%s", getpid(), current_user.uid, current_user.user_name, line);
else
strncpy (trunc, line, SYSLOG_MAXLEN);
trunc[SYSLOG_MAXLEN - 1] = '';
syslog (SYSLOG_FACILITY
Now generate a .patch
file which includes our changes to these 2 files:
$ cd $HOME/rpmbuild/SOURCES
$ diff -Npru bash-4.2-orig bash-4.2 > bash_history_rsyslog.patch
Add these lines to $HOME/rpmbuid/SPEC/bash.spec
. Put these lines into the appropriate places in the SPEC file:
# history syslog
Patch144: bash_history_rsyslog.patch
...
...
%patch144 -p1 -b .history_rsyslog
build
Now build it:
$ cd $HOME/rpmbuild/SPEC
$ rpmbuild -ba bash.spec
The tail end of this build will look like this:
...
Processing files: bash-debuginfo-4.2.46-20.el7.centos.x86_64
Provides: bash-debuginfo = 4.2.46-20.el7.centos bash-debuginfo(x86-64) = 4.2.46-20.el7.centos
Requires(rpmlib): rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/vagrant/rpmbuild/BUILDROOT/bash-4.2.46-20.el7.centos.x86_64
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-4.2.46-20.el7.centos.x86_64.rpm
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-doc-4.2.46-20.el7.centos.x86_64.rpm
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-debuginfo-4.2.46-20.el7.centos.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.nGworU
+ umask 022
+ cd /home/vagrant/rpmbuild/BUILD
+ cd bash-4.2
+ rm -rf /home/vagrant/rpmbuild/BUILDROOT/bash-4.2.46-20.el7.centos.x86_64
+ exit 0
install
Once complete, we can install the resulting RPM:
$ sudo rpm -ivh --force $HOME/rpmbuild/RPMS/x86_64/bash-4.2.46-20.el7.centos.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:bash-4.2.46-20.el7.centos ################################# [100%]
configure rsyslog
Now modify rsyslog's /etc/rsyslog.conf
config:
$ sudo vim /etc/rsyslog.conf
...
...
$ModLoad imudp
$UDPServerRun 514â¨
$ModLoad imtcp
$InputTCPServerRun 514
...
...
#### GLOBAL DIRECTIVES ####
$template IpTemplate,"/var/log/bash-log/%FROMHOST-IP%.log"
*.* ?IpTemplate
& ~
...
...
Then restart Rsyslog:
$ sudo systemctl restart rsyslog
test & confirm
Now run a new instance of Bash as root, and run a couple of commands:
$ sudo -Es
$ ls
And tail the log file, /var/log/bash-log/127.0.0.1.log
:
$ tail /var/log/bash-log/127.0.0.1.log
2018-07-19T23:23:37.568131-04:00 centos7 bash: HISTORY: PID=12511 UID=1000 USER=vagrant CMD=sudo -Es
2018-07-19T23:23:37.573825-04:00 centos7 sudo: vagrant : TTY=pts/0 ; PWD=/home/vagrant/rpmbuild/SOURCES ; USER=root ; COMMAND=/bin/bash
2018-07-19T23:23:37.589258-04:00 centos7 systemd-logind: Got message type=signal sender=org.freedesktop.DBus destination=n/a object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwnerChanged cookie=4454 reply_cookie=0 error=n/a
2018-07-19T23:23:37.590633-04:00 centos7 dbus[588]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
2018-07-19T23:23:37.590806-04:00 centos7 dbus-daemon: dbus[588]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
2018-07-19T23:23:37.592160-04:00 centos7 dbus[588]: [system] Activated service 'org.freedesktop.problems' failed: Failed to execute program /lib64/dbus-1/dbus-daemon-launch-helper: Success
2018-07-19T23:23:37.592311-04:00 centos7 dbus-daemon: dbus[588]: [system] Activated service 'org.freedesktop.problems' failed: Failed to execute program /lib64/dbus-1/dbus-daemon-launch-helper: Success
2018-07-19T23:23:37.602174-04:00 centos7 systemd-logind: Got message type=signal sender=org.freedesktop.DBus destination=n/a object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwnerChanged cookie=4455 reply_cookie=0 error=n/a
2018-07-19T23:23:38.520300-04:00 centos7 bash: HISTORY: PID=12585 UID=0 USER=root CMD=ls
2018-07-19T23:23:49.210406-04:00 centos7 bash: HISTORY: PID=12585 UID=0 USER=root CMD=tail /var/log/bash-log/127.0.0.1.log
Notice the CMD=...
lines in this log? These are the commands we just ran, a ls
& tail
.
Prebuilt?
To help people out with this I've taken the liberty to build the Bash RPM with the modifications made in Copr.
- https://copr.fedorainfracloud.org/coprs/slmingol/bash/
1
Pretty neat. For bash I have another trick, but it more noticeable to the end user. Left it on the comments of the OP question. I usually try to avoid compile stuff, but this one seems worth it.
â Rui F Ribeiro
Jul 19 at 4:34
Interestingly, although I've recompiled bash with the #define SYSLOG_HISTORY line uncommented, it doesn't seem to write to syslog.
â Graham Nicholls
Jul 19 at 22:57
@slm: The facility is LOG_USER (which resolves to "user"), and the level is INFO, but even with user.* being sent to /var/log/user.log, command history is not written there. Other stuff is, so rsylog deals with USER facility messages. I've done a make install, logged out and back in and checked $BASH_VERSION, which does reflect the newly-compiled (4.4.18) bash. I'll investigate some more over the weekend. I wonder if there's a variable... Are comments the worst UI I've ever used? Quite possibly.
â Graham Nicholls
Jul 19 at 23:07
@GrahamNicholls - comments are fine, I'll look some more as well, was going to build a Bash RPM with the mod as well and see if it works for me as well.
â slmâ¦
Jul 20 at 0:08
1
@slm I hate the comment format, tbh, I don't much like SE as a whole. Answers like yours change that opinion, though. I was being dim and assuming that a make install was putting the new binary over the top of /bin/bash - dim of me really. Thanks for all the info, research, and an incredible wealth of detail.
â Graham Nicholls
Jul 21 at 11:25
 |Â
show 2 more comments
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
accepted
This approach seems to be what you're looking for. This article discusses it, titled: Improving Bash Forensics Capabilities.
Excerpt:
While discussing with him about this topic, I realized that there are some ways to fine tune the history of commands to improve forensics investigations. In 2009, I also wrote a blog post about Bash which gave some ideas to send a Bash command history to a remote Syslog server. I checked my web logs and this blog post remains popular with more than 1000 visits for the last 30 days! Note that my blog post is outdated: Since the version 4.1, Bash supports Syslog natively but in most distribution, it is not enabled. To use this feature, you need to recompile your shell.
I found this not very convenient but the good point is that it cannot be disabled by the user (except if he switches his shell to another shell or another Bash binary). You just have to define "SYSLOG_HISTORY" in config-top.h:
$ vi config-top.h
#define SYSLOG_HISTORY
#if defined (SYSLOG_HISTORY)
# define SYSLOG_FACILITY LOG_USER
# define SYSLOG_LEVEL LOG_INFO
#endif
./configure
make install
So it would seem that though the feature is available in Bash 4.1+ it's likely not compiled by default with the Bash in most of the popular distros.
I haven't found a method for seeing what options a given Bash was compiled with, so to answer that question, you'll likely need to look to the upstream .spec
file used when building the Bash RPM, for example, on Redhat distros, the same approach can be used for Debian based distros as well.
As confirmation I looked in the Bash .spec
file for the Bash included with CentOS 7.2.1511 and it does not have this enabled:
$ grep configure bash.spec
%configure --with-bash-malloc=no --with-afs
- Use the configure macro instead of calling ./configure directly
Rolling your own RPM
Here are the steps that I used to build my own Bash using the gist of what the above details spelled out.
download & install source
To start I downloaded a source RPM (SRPM) of Bash that's available for CentOS 7.x. After downloading it I installed it into my rpmbuild
directory:
$ rpmdev-setuptree
$ rpm -ivh bash-4.2.46-20.el7_2.src.rpm
patch
This will unpack files into rpmbuild/SPEC
& rpmbuild/SOURCES
. Now we're going to make a copy of the contents of the unpacked Bash tar.gz
file using these steps:
$ cd rpmbuild/SOURCES
$ tar zxf bash-4.2.tar.gz
$ cp -prf bash-4.2 bash-4.2-orig
$ cd bash-4.2
Edit rpmbuild/SOURCES/bash-4.2/config-top.h
and make it look like this:
/* Define if you want each line saved to the history list in bashhist.c:
bash_add_history() to be sent to syslog(). */
#define SYSLOG_HISTORY
#if defined (SYSLOG_HISTORY)
# define SYSLOG_FACILITY LOG_LOCAL1
# define SYSLOG_LEVEL LOG_DEBUG
#endif
Edit rpmbuild/SOURCES/bash-4.2/bashhist.c
and make bash_syslog_history
function look like this:
void
bash_syslog_history (line)
const char *line;
SYSLOG_LEVEL, "HISTORY: PID=%d UID=%d USER=%s CMD=%s", getpid(), current_user.uid, current_user.user_name, line);
else
strncpy (trunc, line, SYSLOG_MAXLEN);
trunc[SYSLOG_MAXLEN - 1] = '';
syslog (SYSLOG_FACILITY
Now generate a .patch
file which includes our changes to these 2 files:
$ cd $HOME/rpmbuild/SOURCES
$ diff -Npru bash-4.2-orig bash-4.2 > bash_history_rsyslog.patch
Add these lines to $HOME/rpmbuid/SPEC/bash.spec
. Put these lines into the appropriate places in the SPEC file:
# history syslog
Patch144: bash_history_rsyslog.patch
...
...
%patch144 -p1 -b .history_rsyslog
build
Now build it:
$ cd $HOME/rpmbuild/SPEC
$ rpmbuild -ba bash.spec
The tail end of this build will look like this:
...
Processing files: bash-debuginfo-4.2.46-20.el7.centos.x86_64
Provides: bash-debuginfo = 4.2.46-20.el7.centos bash-debuginfo(x86-64) = 4.2.46-20.el7.centos
Requires(rpmlib): rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/vagrant/rpmbuild/BUILDROOT/bash-4.2.46-20.el7.centos.x86_64
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-4.2.46-20.el7.centos.x86_64.rpm
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-doc-4.2.46-20.el7.centos.x86_64.rpm
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-debuginfo-4.2.46-20.el7.centos.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.nGworU
+ umask 022
+ cd /home/vagrant/rpmbuild/BUILD
+ cd bash-4.2
+ rm -rf /home/vagrant/rpmbuild/BUILDROOT/bash-4.2.46-20.el7.centos.x86_64
+ exit 0
install
Once complete, we can install the resulting RPM:
$ sudo rpm -ivh --force $HOME/rpmbuild/RPMS/x86_64/bash-4.2.46-20.el7.centos.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:bash-4.2.46-20.el7.centos ################################# [100%]
configure rsyslog
Now modify rsyslog's /etc/rsyslog.conf
config:
$ sudo vim /etc/rsyslog.conf
...
...
$ModLoad imudp
$UDPServerRun 514â¨
$ModLoad imtcp
$InputTCPServerRun 514
...
...
#### GLOBAL DIRECTIVES ####
$template IpTemplate,"/var/log/bash-log/%FROMHOST-IP%.log"
*.* ?IpTemplate
& ~
...
...
Then restart Rsyslog:
$ sudo systemctl restart rsyslog
test & confirm
Now run a new instance of Bash as root, and run a couple of commands:
$ sudo -Es
$ ls
And tail the log file, /var/log/bash-log/127.0.0.1.log
:
$ tail /var/log/bash-log/127.0.0.1.log
2018-07-19T23:23:37.568131-04:00 centos7 bash: HISTORY: PID=12511 UID=1000 USER=vagrant CMD=sudo -Es
2018-07-19T23:23:37.573825-04:00 centos7 sudo: vagrant : TTY=pts/0 ; PWD=/home/vagrant/rpmbuild/SOURCES ; USER=root ; COMMAND=/bin/bash
2018-07-19T23:23:37.589258-04:00 centos7 systemd-logind: Got message type=signal sender=org.freedesktop.DBus destination=n/a object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwnerChanged cookie=4454 reply_cookie=0 error=n/a
2018-07-19T23:23:37.590633-04:00 centos7 dbus[588]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
2018-07-19T23:23:37.590806-04:00 centos7 dbus-daemon: dbus[588]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
2018-07-19T23:23:37.592160-04:00 centos7 dbus[588]: [system] Activated service 'org.freedesktop.problems' failed: Failed to execute program /lib64/dbus-1/dbus-daemon-launch-helper: Success
2018-07-19T23:23:37.592311-04:00 centos7 dbus-daemon: dbus[588]: [system] Activated service 'org.freedesktop.problems' failed: Failed to execute program /lib64/dbus-1/dbus-daemon-launch-helper: Success
2018-07-19T23:23:37.602174-04:00 centos7 systemd-logind: Got message type=signal sender=org.freedesktop.DBus destination=n/a object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwnerChanged cookie=4455 reply_cookie=0 error=n/a
2018-07-19T23:23:38.520300-04:00 centos7 bash: HISTORY: PID=12585 UID=0 USER=root CMD=ls
2018-07-19T23:23:49.210406-04:00 centos7 bash: HISTORY: PID=12585 UID=0 USER=root CMD=tail /var/log/bash-log/127.0.0.1.log
Notice the CMD=...
lines in this log? These are the commands we just ran, a ls
& tail
.
Prebuilt?
To help people out with this I've taken the liberty to build the Bash RPM with the modifications made in Copr.
- https://copr.fedorainfracloud.org/coprs/slmingol/bash/
1
Pretty neat. For bash I have another trick, but it more noticeable to the end user. Left it on the comments of the OP question. I usually try to avoid compile stuff, but this one seems worth it.
â Rui F Ribeiro
Jul 19 at 4:34
Interestingly, although I've recompiled bash with the #define SYSLOG_HISTORY line uncommented, it doesn't seem to write to syslog.
â Graham Nicholls
Jul 19 at 22:57
@slm: The facility is LOG_USER (which resolves to "user"), and the level is INFO, but even with user.* being sent to /var/log/user.log, command history is not written there. Other stuff is, so rsylog deals with USER facility messages. I've done a make install, logged out and back in and checked $BASH_VERSION, which does reflect the newly-compiled (4.4.18) bash. I'll investigate some more over the weekend. I wonder if there's a variable... Are comments the worst UI I've ever used? Quite possibly.
â Graham Nicholls
Jul 19 at 23:07
@GrahamNicholls - comments are fine, I'll look some more as well, was going to build a Bash RPM with the mod as well and see if it works for me as well.
â slmâ¦
Jul 20 at 0:08
1
@slm I hate the comment format, tbh, I don't much like SE as a whole. Answers like yours change that opinion, though. I was being dim and assuming that a make install was putting the new binary over the top of /bin/bash - dim of me really. Thanks for all the info, research, and an incredible wealth of detail.
â Graham Nicholls
Jul 21 at 11:25
 |Â
show 2 more comments
up vote
5
down vote
accepted
This approach seems to be what you're looking for. This article discusses it, titled: Improving Bash Forensics Capabilities.
Excerpt:
While discussing with him about this topic, I realized that there are some ways to fine tune the history of commands to improve forensics investigations. In 2009, I also wrote a blog post about Bash which gave some ideas to send a Bash command history to a remote Syslog server. I checked my web logs and this blog post remains popular with more than 1000 visits for the last 30 days! Note that my blog post is outdated: Since the version 4.1, Bash supports Syslog natively but in most distribution, it is not enabled. To use this feature, you need to recompile your shell.
I found this not very convenient but the good point is that it cannot be disabled by the user (except if he switches his shell to another shell or another Bash binary). You just have to define "SYSLOG_HISTORY" in config-top.h:
$ vi config-top.h
#define SYSLOG_HISTORY
#if defined (SYSLOG_HISTORY)
# define SYSLOG_FACILITY LOG_USER
# define SYSLOG_LEVEL LOG_INFO
#endif
./configure
make install
So it would seem that though the feature is available in Bash 4.1+ it's likely not compiled by default with the Bash in most of the popular distros.
I haven't found a method for seeing what options a given Bash was compiled with, so to answer that question, you'll likely need to look to the upstream .spec
file used when building the Bash RPM, for example, on Redhat distros, the same approach can be used for Debian based distros as well.
As confirmation I looked in the Bash .spec
file for the Bash included with CentOS 7.2.1511 and it does not have this enabled:
$ grep configure bash.spec
%configure --with-bash-malloc=no --with-afs
- Use the configure macro instead of calling ./configure directly
Rolling your own RPM
Here are the steps that I used to build my own Bash using the gist of what the above details spelled out.
download & install source
To start I downloaded a source RPM (SRPM) of Bash that's available for CentOS 7.x. After downloading it I installed it into my rpmbuild
directory:
$ rpmdev-setuptree
$ rpm -ivh bash-4.2.46-20.el7_2.src.rpm
patch
This will unpack files into rpmbuild/SPEC
& rpmbuild/SOURCES
. Now we're going to make a copy of the contents of the unpacked Bash tar.gz
file using these steps:
$ cd rpmbuild/SOURCES
$ tar zxf bash-4.2.tar.gz
$ cp -prf bash-4.2 bash-4.2-orig
$ cd bash-4.2
Edit rpmbuild/SOURCES/bash-4.2/config-top.h
and make it look like this:
/* Define if you want each line saved to the history list in bashhist.c:
bash_add_history() to be sent to syslog(). */
#define SYSLOG_HISTORY
#if defined (SYSLOG_HISTORY)
# define SYSLOG_FACILITY LOG_LOCAL1
# define SYSLOG_LEVEL LOG_DEBUG
#endif
Edit rpmbuild/SOURCES/bash-4.2/bashhist.c
and make bash_syslog_history
function look like this:
void
bash_syslog_history (line)
const char *line;
SYSLOG_LEVEL, "HISTORY: PID=%d UID=%d USER=%s CMD=%s", getpid(), current_user.uid, current_user.user_name, line);
else
strncpy (trunc, line, SYSLOG_MAXLEN);
trunc[SYSLOG_MAXLEN - 1] = '';
syslog (SYSLOG_FACILITY
Now generate a .patch
file which includes our changes to these 2 files:
$ cd $HOME/rpmbuild/SOURCES
$ diff -Npru bash-4.2-orig bash-4.2 > bash_history_rsyslog.patch
Add these lines to $HOME/rpmbuid/SPEC/bash.spec
. Put these lines into the appropriate places in the SPEC file:
# history syslog
Patch144: bash_history_rsyslog.patch
...
...
%patch144 -p1 -b .history_rsyslog
build
Now build it:
$ cd $HOME/rpmbuild/SPEC
$ rpmbuild -ba bash.spec
The tail end of this build will look like this:
...
Processing files: bash-debuginfo-4.2.46-20.el7.centos.x86_64
Provides: bash-debuginfo = 4.2.46-20.el7.centos bash-debuginfo(x86-64) = 4.2.46-20.el7.centos
Requires(rpmlib): rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/vagrant/rpmbuild/BUILDROOT/bash-4.2.46-20.el7.centos.x86_64
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-4.2.46-20.el7.centos.x86_64.rpm
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-doc-4.2.46-20.el7.centos.x86_64.rpm
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-debuginfo-4.2.46-20.el7.centos.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.nGworU
+ umask 022
+ cd /home/vagrant/rpmbuild/BUILD
+ cd bash-4.2
+ rm -rf /home/vagrant/rpmbuild/BUILDROOT/bash-4.2.46-20.el7.centos.x86_64
+ exit 0
install
Once complete, we can install the resulting RPM:
$ sudo rpm -ivh --force $HOME/rpmbuild/RPMS/x86_64/bash-4.2.46-20.el7.centos.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:bash-4.2.46-20.el7.centos ################################# [100%]
configure rsyslog
Now modify rsyslog's /etc/rsyslog.conf
config:
$ sudo vim /etc/rsyslog.conf
...
...
$ModLoad imudp
$UDPServerRun 514â¨
$ModLoad imtcp
$InputTCPServerRun 514
...
...
#### GLOBAL DIRECTIVES ####
$template IpTemplate,"/var/log/bash-log/%FROMHOST-IP%.log"
*.* ?IpTemplate
& ~
...
...
Then restart Rsyslog:
$ sudo systemctl restart rsyslog
test & confirm
Now run a new instance of Bash as root, and run a couple of commands:
$ sudo -Es
$ ls
And tail the log file, /var/log/bash-log/127.0.0.1.log
:
$ tail /var/log/bash-log/127.0.0.1.log
2018-07-19T23:23:37.568131-04:00 centos7 bash: HISTORY: PID=12511 UID=1000 USER=vagrant CMD=sudo -Es
2018-07-19T23:23:37.573825-04:00 centos7 sudo: vagrant : TTY=pts/0 ; PWD=/home/vagrant/rpmbuild/SOURCES ; USER=root ; COMMAND=/bin/bash
2018-07-19T23:23:37.589258-04:00 centos7 systemd-logind: Got message type=signal sender=org.freedesktop.DBus destination=n/a object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwnerChanged cookie=4454 reply_cookie=0 error=n/a
2018-07-19T23:23:37.590633-04:00 centos7 dbus[588]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
2018-07-19T23:23:37.590806-04:00 centos7 dbus-daemon: dbus[588]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
2018-07-19T23:23:37.592160-04:00 centos7 dbus[588]: [system] Activated service 'org.freedesktop.problems' failed: Failed to execute program /lib64/dbus-1/dbus-daemon-launch-helper: Success
2018-07-19T23:23:37.592311-04:00 centos7 dbus-daemon: dbus[588]: [system] Activated service 'org.freedesktop.problems' failed: Failed to execute program /lib64/dbus-1/dbus-daemon-launch-helper: Success
2018-07-19T23:23:37.602174-04:00 centos7 systemd-logind: Got message type=signal sender=org.freedesktop.DBus destination=n/a object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwnerChanged cookie=4455 reply_cookie=0 error=n/a
2018-07-19T23:23:38.520300-04:00 centos7 bash: HISTORY: PID=12585 UID=0 USER=root CMD=ls
2018-07-19T23:23:49.210406-04:00 centos7 bash: HISTORY: PID=12585 UID=0 USER=root CMD=tail /var/log/bash-log/127.0.0.1.log
Notice the CMD=...
lines in this log? These are the commands we just ran, a ls
& tail
.
Prebuilt?
To help people out with this I've taken the liberty to build the Bash RPM with the modifications made in Copr.
- https://copr.fedorainfracloud.org/coprs/slmingol/bash/
1
Pretty neat. For bash I have another trick, but it more noticeable to the end user. Left it on the comments of the OP question. I usually try to avoid compile stuff, but this one seems worth it.
â Rui F Ribeiro
Jul 19 at 4:34
Interestingly, although I've recompiled bash with the #define SYSLOG_HISTORY line uncommented, it doesn't seem to write to syslog.
â Graham Nicholls
Jul 19 at 22:57
@slm: The facility is LOG_USER (which resolves to "user"), and the level is INFO, but even with user.* being sent to /var/log/user.log, command history is not written there. Other stuff is, so rsylog deals with USER facility messages. I've done a make install, logged out and back in and checked $BASH_VERSION, which does reflect the newly-compiled (4.4.18) bash. I'll investigate some more over the weekend. I wonder if there's a variable... Are comments the worst UI I've ever used? Quite possibly.
â Graham Nicholls
Jul 19 at 23:07
@GrahamNicholls - comments are fine, I'll look some more as well, was going to build a Bash RPM with the mod as well and see if it works for me as well.
â slmâ¦
Jul 20 at 0:08
1
@slm I hate the comment format, tbh, I don't much like SE as a whole. Answers like yours change that opinion, though. I was being dim and assuming that a make install was putting the new binary over the top of /bin/bash - dim of me really. Thanks for all the info, research, and an incredible wealth of detail.
â Graham Nicholls
Jul 21 at 11:25
 |Â
show 2 more comments
up vote
5
down vote
accepted
up vote
5
down vote
accepted
This approach seems to be what you're looking for. This article discusses it, titled: Improving Bash Forensics Capabilities.
Excerpt:
While discussing with him about this topic, I realized that there are some ways to fine tune the history of commands to improve forensics investigations. In 2009, I also wrote a blog post about Bash which gave some ideas to send a Bash command history to a remote Syslog server. I checked my web logs and this blog post remains popular with more than 1000 visits for the last 30 days! Note that my blog post is outdated: Since the version 4.1, Bash supports Syslog natively but in most distribution, it is not enabled. To use this feature, you need to recompile your shell.
I found this not very convenient but the good point is that it cannot be disabled by the user (except if he switches his shell to another shell or another Bash binary). You just have to define "SYSLOG_HISTORY" in config-top.h:
$ vi config-top.h
#define SYSLOG_HISTORY
#if defined (SYSLOG_HISTORY)
# define SYSLOG_FACILITY LOG_USER
# define SYSLOG_LEVEL LOG_INFO
#endif
./configure
make install
So it would seem that though the feature is available in Bash 4.1+ it's likely not compiled by default with the Bash in most of the popular distros.
I haven't found a method for seeing what options a given Bash was compiled with, so to answer that question, you'll likely need to look to the upstream .spec
file used when building the Bash RPM, for example, on Redhat distros, the same approach can be used for Debian based distros as well.
As confirmation I looked in the Bash .spec
file for the Bash included with CentOS 7.2.1511 and it does not have this enabled:
$ grep configure bash.spec
%configure --with-bash-malloc=no --with-afs
- Use the configure macro instead of calling ./configure directly
Rolling your own RPM
Here are the steps that I used to build my own Bash using the gist of what the above details spelled out.
download & install source
To start I downloaded a source RPM (SRPM) of Bash that's available for CentOS 7.x. After downloading it I installed it into my rpmbuild
directory:
$ rpmdev-setuptree
$ rpm -ivh bash-4.2.46-20.el7_2.src.rpm
patch
This will unpack files into rpmbuild/SPEC
& rpmbuild/SOURCES
. Now we're going to make a copy of the contents of the unpacked Bash tar.gz
file using these steps:
$ cd rpmbuild/SOURCES
$ tar zxf bash-4.2.tar.gz
$ cp -prf bash-4.2 bash-4.2-orig
$ cd bash-4.2
Edit rpmbuild/SOURCES/bash-4.2/config-top.h
and make it look like this:
/* Define if you want each line saved to the history list in bashhist.c:
bash_add_history() to be sent to syslog(). */
#define SYSLOG_HISTORY
#if defined (SYSLOG_HISTORY)
# define SYSLOG_FACILITY LOG_LOCAL1
# define SYSLOG_LEVEL LOG_DEBUG
#endif
Edit rpmbuild/SOURCES/bash-4.2/bashhist.c
and make bash_syslog_history
function look like this:
void
bash_syslog_history (line)
const char *line;
SYSLOG_LEVEL, "HISTORY: PID=%d UID=%d USER=%s CMD=%s", getpid(), current_user.uid, current_user.user_name, line);
else
strncpy (trunc, line, SYSLOG_MAXLEN);
trunc[SYSLOG_MAXLEN - 1] = '';
syslog (SYSLOG_FACILITY
Now generate a .patch
file which includes our changes to these 2 files:
$ cd $HOME/rpmbuild/SOURCES
$ diff -Npru bash-4.2-orig bash-4.2 > bash_history_rsyslog.patch
Add these lines to $HOME/rpmbuid/SPEC/bash.spec
. Put these lines into the appropriate places in the SPEC file:
# history syslog
Patch144: bash_history_rsyslog.patch
...
...
%patch144 -p1 -b .history_rsyslog
build
Now build it:
$ cd $HOME/rpmbuild/SPEC
$ rpmbuild -ba bash.spec
The tail end of this build will look like this:
...
Processing files: bash-debuginfo-4.2.46-20.el7.centos.x86_64
Provides: bash-debuginfo = 4.2.46-20.el7.centos bash-debuginfo(x86-64) = 4.2.46-20.el7.centos
Requires(rpmlib): rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/vagrant/rpmbuild/BUILDROOT/bash-4.2.46-20.el7.centos.x86_64
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-4.2.46-20.el7.centos.x86_64.rpm
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-doc-4.2.46-20.el7.centos.x86_64.rpm
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-debuginfo-4.2.46-20.el7.centos.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.nGworU
+ umask 022
+ cd /home/vagrant/rpmbuild/BUILD
+ cd bash-4.2
+ rm -rf /home/vagrant/rpmbuild/BUILDROOT/bash-4.2.46-20.el7.centos.x86_64
+ exit 0
install
Once complete, we can install the resulting RPM:
$ sudo rpm -ivh --force $HOME/rpmbuild/RPMS/x86_64/bash-4.2.46-20.el7.centos.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:bash-4.2.46-20.el7.centos ################################# [100%]
configure rsyslog
Now modify rsyslog's /etc/rsyslog.conf
config:
$ sudo vim /etc/rsyslog.conf
...
...
$ModLoad imudp
$UDPServerRun 514â¨
$ModLoad imtcp
$InputTCPServerRun 514
...
...
#### GLOBAL DIRECTIVES ####
$template IpTemplate,"/var/log/bash-log/%FROMHOST-IP%.log"
*.* ?IpTemplate
& ~
...
...
Then restart Rsyslog:
$ sudo systemctl restart rsyslog
test & confirm
Now run a new instance of Bash as root, and run a couple of commands:
$ sudo -Es
$ ls
And tail the log file, /var/log/bash-log/127.0.0.1.log
:
$ tail /var/log/bash-log/127.0.0.1.log
2018-07-19T23:23:37.568131-04:00 centos7 bash: HISTORY: PID=12511 UID=1000 USER=vagrant CMD=sudo -Es
2018-07-19T23:23:37.573825-04:00 centos7 sudo: vagrant : TTY=pts/0 ; PWD=/home/vagrant/rpmbuild/SOURCES ; USER=root ; COMMAND=/bin/bash
2018-07-19T23:23:37.589258-04:00 centos7 systemd-logind: Got message type=signal sender=org.freedesktop.DBus destination=n/a object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwnerChanged cookie=4454 reply_cookie=0 error=n/a
2018-07-19T23:23:37.590633-04:00 centos7 dbus[588]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
2018-07-19T23:23:37.590806-04:00 centos7 dbus-daemon: dbus[588]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
2018-07-19T23:23:37.592160-04:00 centos7 dbus[588]: [system] Activated service 'org.freedesktop.problems' failed: Failed to execute program /lib64/dbus-1/dbus-daemon-launch-helper: Success
2018-07-19T23:23:37.592311-04:00 centos7 dbus-daemon: dbus[588]: [system] Activated service 'org.freedesktop.problems' failed: Failed to execute program /lib64/dbus-1/dbus-daemon-launch-helper: Success
2018-07-19T23:23:37.602174-04:00 centos7 systemd-logind: Got message type=signal sender=org.freedesktop.DBus destination=n/a object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwnerChanged cookie=4455 reply_cookie=0 error=n/a
2018-07-19T23:23:38.520300-04:00 centos7 bash: HISTORY: PID=12585 UID=0 USER=root CMD=ls
2018-07-19T23:23:49.210406-04:00 centos7 bash: HISTORY: PID=12585 UID=0 USER=root CMD=tail /var/log/bash-log/127.0.0.1.log
Notice the CMD=...
lines in this log? These are the commands we just ran, a ls
& tail
.
Prebuilt?
To help people out with this I've taken the liberty to build the Bash RPM with the modifications made in Copr.
- https://copr.fedorainfracloud.org/coprs/slmingol/bash/
This approach seems to be what you're looking for. This article discusses it, titled: Improving Bash Forensics Capabilities.
Excerpt:
While discussing with him about this topic, I realized that there are some ways to fine tune the history of commands to improve forensics investigations. In 2009, I also wrote a blog post about Bash which gave some ideas to send a Bash command history to a remote Syslog server. I checked my web logs and this blog post remains popular with more than 1000 visits for the last 30 days! Note that my blog post is outdated: Since the version 4.1, Bash supports Syslog natively but in most distribution, it is not enabled. To use this feature, you need to recompile your shell.
I found this not very convenient but the good point is that it cannot be disabled by the user (except if he switches his shell to another shell or another Bash binary). You just have to define "SYSLOG_HISTORY" in config-top.h:
$ vi config-top.h
#define SYSLOG_HISTORY
#if defined (SYSLOG_HISTORY)
# define SYSLOG_FACILITY LOG_USER
# define SYSLOG_LEVEL LOG_INFO
#endif
./configure
make install
So it would seem that though the feature is available in Bash 4.1+ it's likely not compiled by default with the Bash in most of the popular distros.
I haven't found a method for seeing what options a given Bash was compiled with, so to answer that question, you'll likely need to look to the upstream .spec
file used when building the Bash RPM, for example, on Redhat distros, the same approach can be used for Debian based distros as well.
As confirmation I looked in the Bash .spec
file for the Bash included with CentOS 7.2.1511 and it does not have this enabled:
$ grep configure bash.spec
%configure --with-bash-malloc=no --with-afs
- Use the configure macro instead of calling ./configure directly
Rolling your own RPM
Here are the steps that I used to build my own Bash using the gist of what the above details spelled out.
download & install source
To start I downloaded a source RPM (SRPM) of Bash that's available for CentOS 7.x. After downloading it I installed it into my rpmbuild
directory:
$ rpmdev-setuptree
$ rpm -ivh bash-4.2.46-20.el7_2.src.rpm
patch
This will unpack files into rpmbuild/SPEC
& rpmbuild/SOURCES
. Now we're going to make a copy of the contents of the unpacked Bash tar.gz
file using these steps:
$ cd rpmbuild/SOURCES
$ tar zxf bash-4.2.tar.gz
$ cp -prf bash-4.2 bash-4.2-orig
$ cd bash-4.2
Edit rpmbuild/SOURCES/bash-4.2/config-top.h
and make it look like this:
/* Define if you want each line saved to the history list in bashhist.c:
bash_add_history() to be sent to syslog(). */
#define SYSLOG_HISTORY
#if defined (SYSLOG_HISTORY)
# define SYSLOG_FACILITY LOG_LOCAL1
# define SYSLOG_LEVEL LOG_DEBUG
#endif
Edit rpmbuild/SOURCES/bash-4.2/bashhist.c
and make bash_syslog_history
function look like this:
void
bash_syslog_history (line)
const char *line;
SYSLOG_LEVEL, "HISTORY: PID=%d UID=%d USER=%s CMD=%s", getpid(), current_user.uid, current_user.user_name, line);
else
strncpy (trunc, line, SYSLOG_MAXLEN);
trunc[SYSLOG_MAXLEN - 1] = '';
syslog (SYSLOG_FACILITY
Now generate a .patch
file which includes our changes to these 2 files:
$ cd $HOME/rpmbuild/SOURCES
$ diff -Npru bash-4.2-orig bash-4.2 > bash_history_rsyslog.patch
Add these lines to $HOME/rpmbuid/SPEC/bash.spec
. Put these lines into the appropriate places in the SPEC file:
# history syslog
Patch144: bash_history_rsyslog.patch
...
...
%patch144 -p1 -b .history_rsyslog
build
Now build it:
$ cd $HOME/rpmbuild/SPEC
$ rpmbuild -ba bash.spec
The tail end of this build will look like this:
...
Processing files: bash-debuginfo-4.2.46-20.el7.centos.x86_64
Provides: bash-debuginfo = 4.2.46-20.el7.centos bash-debuginfo(x86-64) = 4.2.46-20.el7.centos
Requires(rpmlib): rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/vagrant/rpmbuild/BUILDROOT/bash-4.2.46-20.el7.centos.x86_64
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-4.2.46-20.el7.centos.x86_64.rpm
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-doc-4.2.46-20.el7.centos.x86_64.rpm
Wrote: /home/vagrant/rpmbuild/RPMS/x86_64/bash-debuginfo-4.2.46-20.el7.centos.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.nGworU
+ umask 022
+ cd /home/vagrant/rpmbuild/BUILD
+ cd bash-4.2
+ rm -rf /home/vagrant/rpmbuild/BUILDROOT/bash-4.2.46-20.el7.centos.x86_64
+ exit 0
install
Once complete, we can install the resulting RPM:
$ sudo rpm -ivh --force $HOME/rpmbuild/RPMS/x86_64/bash-4.2.46-20.el7.centos.x86_64.rpm
Preparing... ################################# [100%]
Updating / installing...
1:bash-4.2.46-20.el7.centos ################################# [100%]
configure rsyslog
Now modify rsyslog's /etc/rsyslog.conf
config:
$ sudo vim /etc/rsyslog.conf
...
...
$ModLoad imudp
$UDPServerRun 514â¨
$ModLoad imtcp
$InputTCPServerRun 514
...
...
#### GLOBAL DIRECTIVES ####
$template IpTemplate,"/var/log/bash-log/%FROMHOST-IP%.log"
*.* ?IpTemplate
& ~
...
...
Then restart Rsyslog:
$ sudo systemctl restart rsyslog
test & confirm
Now run a new instance of Bash as root, and run a couple of commands:
$ sudo -Es
$ ls
And tail the log file, /var/log/bash-log/127.0.0.1.log
:
$ tail /var/log/bash-log/127.0.0.1.log
2018-07-19T23:23:37.568131-04:00 centos7 bash: HISTORY: PID=12511 UID=1000 USER=vagrant CMD=sudo -Es
2018-07-19T23:23:37.573825-04:00 centos7 sudo: vagrant : TTY=pts/0 ; PWD=/home/vagrant/rpmbuild/SOURCES ; USER=root ; COMMAND=/bin/bash
2018-07-19T23:23:37.589258-04:00 centos7 systemd-logind: Got message type=signal sender=org.freedesktop.DBus destination=n/a object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwnerChanged cookie=4454 reply_cookie=0 error=n/a
2018-07-19T23:23:37.590633-04:00 centos7 dbus[588]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
2018-07-19T23:23:37.590806-04:00 centos7 dbus-daemon: dbus[588]: [system] Activating service name='org.freedesktop.problems' (using servicehelper)
2018-07-19T23:23:37.592160-04:00 centos7 dbus[588]: [system] Activated service 'org.freedesktop.problems' failed: Failed to execute program /lib64/dbus-1/dbus-daemon-launch-helper: Success
2018-07-19T23:23:37.592311-04:00 centos7 dbus-daemon: dbus[588]: [system] Activated service 'org.freedesktop.problems' failed: Failed to execute program /lib64/dbus-1/dbus-daemon-launch-helper: Success
2018-07-19T23:23:37.602174-04:00 centos7 systemd-logind: Got message type=signal sender=org.freedesktop.DBus destination=n/a object=/org/freedesktop/DBus interface=org.freedesktop.DBus member=NameOwnerChanged cookie=4455 reply_cookie=0 error=n/a
2018-07-19T23:23:38.520300-04:00 centos7 bash: HISTORY: PID=12585 UID=0 USER=root CMD=ls
2018-07-19T23:23:49.210406-04:00 centos7 bash: HISTORY: PID=12585 UID=0 USER=root CMD=tail /var/log/bash-log/127.0.0.1.log
Notice the CMD=...
lines in this log? These are the commands we just ran, a ls
& tail
.
Prebuilt?
To help people out with this I've taken the liberty to build the Bash RPM with the modifications made in Copr.
- https://copr.fedorainfracloud.org/coprs/slmingol/bash/
edited Jul 20 at 14:34
answered Jul 18 at 23:32
slmâ¦
232k65479649
232k65479649
1
Pretty neat. For bash I have another trick, but it more noticeable to the end user. Left it on the comments of the OP question. I usually try to avoid compile stuff, but this one seems worth it.
â Rui F Ribeiro
Jul 19 at 4:34
Interestingly, although I've recompiled bash with the #define SYSLOG_HISTORY line uncommented, it doesn't seem to write to syslog.
â Graham Nicholls
Jul 19 at 22:57
@slm: The facility is LOG_USER (which resolves to "user"), and the level is INFO, but even with user.* being sent to /var/log/user.log, command history is not written there. Other stuff is, so rsylog deals with USER facility messages. I've done a make install, logged out and back in and checked $BASH_VERSION, which does reflect the newly-compiled (4.4.18) bash. I'll investigate some more over the weekend. I wonder if there's a variable... Are comments the worst UI I've ever used? Quite possibly.
â Graham Nicholls
Jul 19 at 23:07
@GrahamNicholls - comments are fine, I'll look some more as well, was going to build a Bash RPM with the mod as well and see if it works for me as well.
â slmâ¦
Jul 20 at 0:08
1
@slm I hate the comment format, tbh, I don't much like SE as a whole. Answers like yours change that opinion, though. I was being dim and assuming that a make install was putting the new binary over the top of /bin/bash - dim of me really. Thanks for all the info, research, and an incredible wealth of detail.
â Graham Nicholls
Jul 21 at 11:25
 |Â
show 2 more comments
1
Pretty neat. For bash I have another trick, but it more noticeable to the end user. Left it on the comments of the OP question. I usually try to avoid compile stuff, but this one seems worth it.
â Rui F Ribeiro
Jul 19 at 4:34
Interestingly, although I've recompiled bash with the #define SYSLOG_HISTORY line uncommented, it doesn't seem to write to syslog.
â Graham Nicholls
Jul 19 at 22:57
@slm: The facility is LOG_USER (which resolves to "user"), and the level is INFO, but even with user.* being sent to /var/log/user.log, command history is not written there. Other stuff is, so rsylog deals with USER facility messages. I've done a make install, logged out and back in and checked $BASH_VERSION, which does reflect the newly-compiled (4.4.18) bash. I'll investigate some more over the weekend. I wonder if there's a variable... Are comments the worst UI I've ever used? Quite possibly.
â Graham Nicholls
Jul 19 at 23:07
@GrahamNicholls - comments are fine, I'll look some more as well, was going to build a Bash RPM with the mod as well and see if it works for me as well.
â slmâ¦
Jul 20 at 0:08
1
@slm I hate the comment format, tbh, I don't much like SE as a whole. Answers like yours change that opinion, though. I was being dim and assuming that a make install was putting the new binary over the top of /bin/bash - dim of me really. Thanks for all the info, research, and an incredible wealth of detail.
â Graham Nicholls
Jul 21 at 11:25
1
1
Pretty neat. For bash I have another trick, but it more noticeable to the end user. Left it on the comments of the OP question. I usually try to avoid compile stuff, but this one seems worth it.
â Rui F Ribeiro
Jul 19 at 4:34
Pretty neat. For bash I have another trick, but it more noticeable to the end user. Left it on the comments of the OP question. I usually try to avoid compile stuff, but this one seems worth it.
â Rui F Ribeiro
Jul 19 at 4:34
Interestingly, although I've recompiled bash with the #define SYSLOG_HISTORY line uncommented, it doesn't seem to write to syslog.
â Graham Nicholls
Jul 19 at 22:57
Interestingly, although I've recompiled bash with the #define SYSLOG_HISTORY line uncommented, it doesn't seem to write to syslog.
â Graham Nicholls
Jul 19 at 22:57
@slm: The facility is LOG_USER (which resolves to "user"), and the level is INFO, but even with user.* being sent to /var/log/user.log, command history is not written there. Other stuff is, so rsylog deals with USER facility messages. I've done a make install, logged out and back in and checked $BASH_VERSION, which does reflect the newly-compiled (4.4.18) bash. I'll investigate some more over the weekend. I wonder if there's a variable... Are comments the worst UI I've ever used? Quite possibly.
â Graham Nicholls
Jul 19 at 23:07
@slm: The facility is LOG_USER (which resolves to "user"), and the level is INFO, but even with user.* being sent to /var/log/user.log, command history is not written there. Other stuff is, so rsylog deals with USER facility messages. I've done a make install, logged out and back in and checked $BASH_VERSION, which does reflect the newly-compiled (4.4.18) bash. I'll investigate some more over the weekend. I wonder if there's a variable... Are comments the worst UI I've ever used? Quite possibly.
â Graham Nicholls
Jul 19 at 23:07
@GrahamNicholls - comments are fine, I'll look some more as well, was going to build a Bash RPM with the mod as well and see if it works for me as well.
â slmâ¦
Jul 20 at 0:08
@GrahamNicholls - comments are fine, I'll look some more as well, was going to build a Bash RPM with the mod as well and see if it works for me as well.
â slmâ¦
Jul 20 at 0:08
1
1
@slm I hate the comment format, tbh, I don't much like SE as a whole. Answers like yours change that opinion, though. I was being dim and assuming that a make install was putting the new binary over the top of /bin/bash - dim of me really. Thanks for all the info, research, and an incredible wealth of detail.
â Graham Nicholls
Jul 21 at 11:25
@slm I hate the comment format, tbh, I don't much like SE as a whole. Answers like yours change that opinion, though. I was being dim and assuming that a make install was putting the new binary over the top of /bin/bash - dim of me really. Thanks for all the info, research, and an incredible wealth of detail.
â Graham Nicholls
Jul 21 at 11:25
 |Â
show 2 more comments
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f457107%2fsending-bash-history-to-syslog%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
see also unix.stackexchange.com/questions/422897/â¦
â Rui F Ribeiro
Jul 19 at 4:32
1
Except that having read that page, I explicitly want to avoid the use of auditd and the bash hackery suggested there. Nothing wrong with hackery in general, but I'd like something a little harder to subvert.
â Graham Nicholls
Jul 19 at 4:38
The no frills way to subvert both is using another shell-
â Rui F Ribeiro
Jul 19 at 5:28
Assuming that another shell is installed and available.
â Graham Nicholls
Jul 19 at 22:53
You do not need special privileges to copy/install/compile an alternate shell.
â Rui F Ribeiro
Jul 19 at 22:55