Record shell activities of all users

R

rajashankaran

Hello team,


How to record all shell/terminal activities done by users on freebsd, i.e all commands entered in freebsd servers by all users.

Thanks
Sankar
 
I am coming at this question from a workplace IT perspective.

All the business systems I have worked on explicitly stated that the system was being monitored.
So make a user account MOTD stating that the system is actively monitored.

This is standard practice herein USA. Nothing at work is private. All company owned work product.
No private email, MITM expected.
You are on a work system. Users should have no privacy expectation from the companies IT systems..
We have to sign documents attesting to such policies. It is a good idea to CYA.

Other countries might have different laws so check with legal.

I am a privacy hawk and under no circumstances would I disclose anything private on the company network.
 
I think what we have here is an XY problem. The OP is asking "how to do XY". It's really hard to answer that question, unless we know what they are really trying to accomplish.

So here are a few questions for the OP. What kind of a system is this? Single-user, or multi-user? If multi-user, are the users guaranteed to be friendly? Are they knowledgeable? Are you expecting them to be dangerous hackers? What important resources (such as valuable secret information) do you expect to be available on this machine? What problem are they trying to solve?

Having said all that: Learn about audit. It is not exactly what you want: It doesn't log shell commands, but for all commands that are not shell-internal, it will log the exec() call for the command being executed.

And look at the source code of bash; it has an option to log all commands (as entered) via syslog, but I don't think it is enabled by default. If you want that, recompile bash and install it. And prevent your users from disabling that option, and from switching to other shells.

Having said that: In reality, if you are worried about security, logging shell commands is the wrong place to start. Because it is easy for a nasty user to quickly create a program (in C, Python, Perl, ...) which does all the nasty things, and then just execute that program once. All you see in your shell command log is that they edited "helloworld.pl" (or .c or .py) and executed it. If you want to know what they really did, you need to enable auditing at finer granularity (like all file operations).
 
Phishfry said:
You are on a work system. Users should have no privacy expectation from the companies IT systems..
Click to expand...
Actually. This may be a European thing though, but you DO have privacy there too. At least down here you can expect some privacy when it comes to email. Mainly because you are allowed to make the occasional personal call using the company's phone system (those are certainly expected to be private), and so those rights are transferred to email too. Pretty much the same thing also applies to files in a person's home directory. You cannot waive those rights with some MOTD, pre-login banner, or signed document. But again, this is probably quite different from the US's legal system.

Phishfry said:
Other countries might have different laws so check with legal.
Click to expand...
Exactly. Definitely check your local laws, privacy or otherwise.

That said, shell history is kind of finicky. Users can clear it. It may provide good information after the fact (when you're investigating a breach or some other violation) but you cannot rely on it. I've seen some set ups that used ttysnoop(8) on Linux systems. On FreeBSD you could do the same with watch(8).

Enabling auditing is really the way to go though. But this produces a TON of logging data. That may be a bit overkill for certain situations. You have to have something in place to analyze all that audit logging or else it'll just be a lot of useless data.
 
In order to comply with PCI audits, all user command activities on the server must be logged and kept for six months. To log user command activities on our Linux servers, we use the trap command. We are now trying to achieve the same in FreeBSD. Every user in FreeBSD has a local account and is trusted.
 
rajashankaran said:
In order to comply with PCI audits, all user command activities on the server must be logged and kept for six months.
Click to expand...
Under which legislation? In which state is the server located? Are services to "FreeBSD users" commercially provided to international customers?
Do you mind to disclose the company you are working for?

International FreeBSD users do have legal rights. I do not want to help those not respecting user's rights.
 
SirDice said:
Enabling auditing is really the way to go though. But this produces a TON of logging data. That may be a bit overkill for certain situations. You have to have something in place to analyze all that audit logging or else it'll just be a lot of useless data.
Click to expand...
Far simpler and less resource heavy than full auditing is good old-fashioned process accounting, realised by enabling accounting in rc.conf - which just runs accton(8) on boot - then occasionally and/or periodically running lastcomm(1) to view and search processes, users, terminals used etc, sa(8) to print desired statistics, ac(8) for connect time accounting, etc.

We ran such accounting from '98 to ~'06 on a small rural community server with 3 x 33.6k dialups and 1 dialout 56kbps modem, paying our then national carrier 25c/MB (yes, $250/GB!) for internet traffic, so charging users for time and data was critical to informing our bespoke billing programs, and for monitoring security.

Noting that process and time accounting do not reveal user command lines, just what is executed and resources used - so might not assist this OP - but are lightweight and simple to test for usefulness.
 
getopt said:
International FreeBSD users do have legal rights. I do not want to help those not respecting user's rights.
Click to expand...
I suspect you may have to argue about that with the present government of India, rather than those obliged to work within oppressive laws.
 
smithi said:
I suspect you may have to argue about that with the present government of India
Click to expand...
I intentionally avoided to name a state that is posing to the public as the "largest democracy" on earth.

My heart belongs to the suppressed not so to the vicarious agents or those making a fortune out of it.
 
rajashankaran said:
In order to comply with PCI audits, all user command activities on the server must be logged and kept for six months. To log user command activities on our Linux servers, we use the trap command. We are now trying to achieve the same in FreeBSD. Every user in FreeBSD has a local account and is trusted.
Click to expand...
Ah finally, the OP tells us what their real goal is: They are in the financial industry, the system being discussed here processes card payments (for example credit cards), and they are preparing for an audit under PCI rules.

This immediately means that a lot of the chatter about "rights" and "laws" becomes completely irrelevant. The only users of this system (in the sense of login user = UID) are likely employees and contractors working on the payment system. I very much doubt that this is a general use system (where people log in, read their mail, compile arbitrary code), but it is likely dedicated to processing payments.

But it also means that advice from random strangers on the internet is not what the OP needs. They need to read and understand the PCI rules. On the web, you can find guides for how to configure Linux systems for PCI compliance; the OP can probably go through those and take the exact equivalent steps on FreeBSD. I've gone through computer security audits, and they probably need to talk to the auditor (which is actually either an audit government agency or company) about what plans and documents are required.

On the specific question: The answer ultimately has to come from reading the PCI DSS standard, but it seems plausible that enabling either process accounting (which logs all external, but not builtin commands) or file operation accounting (which logs the effect of all commands on files) will satisfy the requirements. A quick look at a compliance guide (search for IBM Payment Card Industry DSS compliance) does not say anything about shell command logging.

And finally, the sh and bash shells (on both Linux and FreeBSD) have a trap command, but it is not for logging of all commands, but for handling signals. If the claims that they use it for that purpose in the PCI compliance framework on Linux, then I'm very confused.
 
I’m guessing they’re referring to something like this for logging bash: https://confluence.atlassian.com/co...nd-line-audit-logging-in-linux-956166545.html

This uses bash’s trap DEBUG to do logging. So long as you’re trying to log user actions and they aren’t trying to avoid it, I suppose this works to some level; it can easily be reset/disabled, and doesn’t track what other applications or shells do. (Not all actions on a system flow through a shell…)

You could certainly choose to do something similar on FreeBSD (install bash, set that as root’s shell, configure default trap DEBUG in the initialization scripts… but there are parts of that which are in general avoided (using a non-base-system shell for root, for one), and it’s certainly not a logging method to capture malicious use, but it could at least log unintentional actions made in good faith.

As I started with way back in this thread, audit(4) is more designed for capturing bad faith actors, but it has its own limitations. If they are already root on your system, however, it can’t stop them from working around it.

So you really need to define what types of things (malicious? accidents? access attempts? shell command histories?) you are trying to capture; I’m it familiar with PCI, but if it is like most security standards, it is frustratingly vague about what exactly is required/expected, providing a lucrative consulting opportunity for those involved in its creation.

See also accton(8) (and associated /etc/rc.d/accounting) and security(7) for further reading.
 
I don't know of any other shell that can do this but enable the SYSLOG option of shells/bash. The downside is that your users must all use bash. Kinda draconian but it's the only tool I know of.

An example of this is Broadcom's Layer 7 product. Originally written by a Vancouver, BC company called Layer 7, bought by CA, which in turn was purchased by Broadcom. Typical corporate stuff.

Layer 7 is an API gateway (Layer 7 firewall). The shell is bash and all commands are logged to syslog.

If your syslog is configured correctly, you can send that to a syslog collection machine.

Other than that you're looking at history and $PS1 hacks, any of which can be circumvented by the user.

If you're willing to do that with FreeBSD's Bourne or C shell, you'd need to patch it like the bash patch.
 
cy@ said:
I don't know of any other shell that can do this but enable the SYSLOG option of shells/bash. The downside is that your users must all use bash. Kinda draconian but it's the only tool I know of.
Click to expand...

If you're not familiar, he's describing building and installing shells/bash from the ports tree with the SYSLOG option enabled.

(And again, really only useful for users intending to be logged -- and still only actual commands run via bash.)
 
Mentioned in that Atlassian document:
As an alternative you may consider Snoopy:

Snoopy is a small library that logs all program executions on your Linux/BSD system.
Click to expand...

security/snoopy

snoopy is merely a shared library that is used as a wrapper to the execve()
function provided by libc as to log every call to syslog (authpriv).
Click to expand...
Looks like this hooks in at a lower level, making it indifferent to the shell being used. Probably won't log builtin(1) commands though. But it might still be worth checking out.
 
You must log in or register to reply here.
Back
Top