Re: [PLUG] Follow-up: PLUG West "Echo [Terminal] 23: Watching Terminals

Re: [PLUG] Follow-up: PLUG West "Echo [Terminal] 23: Watching Terminals for Fun and Profit"

On Wed, Sep 19, 2018 at 2:26 PM, Walt Mankowski <waltman@pobox.com> wrote:

Also it seems like it might be tied to a specific terminal size for
playback, which would limit its effectiveness as something more than a
demo.

Walt

On Wed, Sep 19, 2018 at 12:00:19PM -0400, JP Vossen wrote:
> Something else to keep in mind is that Charles' solution can be applied
> without prior preparation, which on one hand is really cool, but on the
> other...how likely is it? If you want this, you probably want it already
> and before anything happens and/or for general auditing.
>
> I did find this one that uses LD_PRELOAD tricks to "Log every executed
> command to syslog."
> * https://github.com/a2o/snoopy
> ** https://github.com/a2o/snoopy/blob/master/doc/INSTALL.md
> * https://debian-administration.org/article/88/Monitoring_user_activity_via_snoopy
>
> And this is a cool `snoopy` output format from $WORK (all 1 line):
> message_format = "[user:%{username} date:%{datetime} uid:%{uid} sid:%{sid}
> tty:%{tty} cwd:%{cwd} filename:%{filename}]: %{cmdline}"
>
>
> On 09/19/2018 10:57 AM, K.S. Bhaskar wrote:
> > Charles developed the code as a proof-of-concept for a demo. But if
> > people on the list think it is likely to be useful, we can have him
> > spend some time to make a more production-grade tool, either in C or in
> > Go (using a Go API to YottaDB that we are developing). So let me take a
> > poll of the group: would you use a tool like the one he demonstrated if
> > it existed as production grade code? It will be FOSS (AGPL v3 is the
> > license we use) and available from Gitlab.
> >
> > Regards
> > – Bhaskar
> >
> > On Tue, Sep 18, 2018 at 5:26 PM, JP Vossen <jp@jpsdomain.org
> > <mailto:jp@jpsdomain.org>> wrote:
> >
> > Thanks to Charles Hathaway for the PLUG West "Echo [Terminal] 23:
> > Watching Terminals for Fun and Profit" preso. It looks like the
> > demo/PoC code is at
> > https://gitlab.com/charles.hathaway/terminal_record
> > <https://gitlab.com/charles.hathaway/terminal_record> and the
> > general idea is:
> > strace -p <PID> -e write,read -xx -s 4096 | termrec <OPTIONS>
> > -xx = output in hex, -s is size
> >
> > Following up on that, but nothing below works after the fact, it all
> > needs to be done before:
> > 1. Someone at work found a bash auditing tool, but it's complicated
> > to install. Unfortunately, that's *ALL* the details I have right now.
> > 2. Similarly, as I understand it Linux `auditd` can be used to log
> > shell commands (but probably not the output). I've never actually
> > done it, but more details below.
> > 3. I've used this, but it's quick & very dirty and I really don't
> > like it:
> > export PROMPT_COMMAND='logger -p local1.notice -t
> > "LinuxAuditLog[$$]" "SSH: $SSH_CONNECTION USER: $USER PATH: $PWD
> > COMMAND: $(fc -ln -1)"'
> >
> > Linux Command line logging:
> > Use Bash itself (I'd forgotten this one, and you'll almost certainly
> > have to re-compile your own):
> > * http://www.bashcookbook.com/bashinfo/source/bash-4.1/NEWS
> > <http://www.bashcookbook.com/bashinfo/source/bash-4.1/NEWS>
> > ** l. There is a new configuration option (in config-top.h) that
> > forces bash to forward all history entries to syslog.
> >
> > "use auditd"...
> > * https://www.scip.ch/en/?labs.20150604
> > <https://www.scip.ch/en/?labs.20150604>
> > ** rootsh (http://linux.die.net/man/1/rootsh
> > <http://linux.die.net/man/1/rootsh>)
> > *** "rootsh is a logging wrapper for shells. It starts a shell with
> > logging of input/output. You can run rootsh as a standalone
> > application if you only want to log your own user’s session. If you
> > call rootsh with additional commands, these will be passed to the
> > shell."
> > *
> > https://serverfault.com/questions/470755/log-all-commands-run-by-admins-on-production-servers
> > <https://serverfault.com/questions/470755/log-all-commands-run-by-admins-on-production-servers>
> > *
> > https://www.tecmint.com/configure-pam-to-audit-logging-shell-tty-user-activity/
> > <https://www.tecmint.com/configure-pam-to-audit-logging-shell-tty-user-activity/>
> > *
> > https://www.digitalocean.com/community/tutorials/how-to-use-the-linux-auditing-system-on-centos-7
> > <https://www.digitalocean.com/community/tutorials/how-to-use-the-linux-auditing-system-on-centos-7>
> >
> >
> > Charles and I also had a brief discussion about testing in Bash but
> > we got interrupted and never finished, and I'm not sure I really
> > understand the question. But maybe this will be interesting:
> >
> > https://github.com/kward/shunit2 <https://github.com/kward/shunit2>
> > "shUnit2 is a xUnit unit test framework for Bourne based shell
> > scripts, and it is designed to work in a similar manner to JUnit,
> > PyUnit, etc.. If you have ever had the desire to write a unit test
> > for a shell script, shUnit2 can do the job."
> >
> > Otherwise, I think I've used the Perl testing framework as a kind of
> > wrapper for some testing, and I've written really primitive tests in
> > bash itself for something else. IIRC that was mostly just a pile of
> > `grep`s in a function with "[ OK ]" or "[NOTOK]" output.
> >
> > We can start a new thread for this with more details if needed.
>
>
> Later,
> JP
> -- -------------------------------------------------------------------
> JP Vossen, CISSP | http://www.jpsdomain.org/ | http://bashcookbook.com/
> ___________________________________________________________________________
> Philadelphia Linux Users Group -- http://www.phillylinux.org
> Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
> General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug

___________________________________________________________________________
Philadelphia Linux Users Group -- http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug