1 |
On 09/11/2018 06:51 AM, wiicontroller@×××××.com wrote: |
2 |
> If by “all” activity, the customer means all activity, pam_tty_audit is |
3 |
> the only solution I have heard of that fits the bill: |
4 |
> |
5 |
> https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sec-configuring_pam_for_auditing |
6 |
|
7 |
I'm not familiar with pam_tty_audit, and I didn't see / find ssh in the |
8 |
linked page. Does pam_tty_audit capture content from SSH sessions? |
9 |
What about ssh remote command execution? |
10 |
|
11 |
I can conceptually see how it could if it hooks low enough into the tty |
12 |
layer. |
13 |
|
14 |
> If by “all” activity, the customer means, “We want want a Serious |
15 |
> Business Stamp,” I recommend getting creative with your shell's |
16 |
> $HISTFILE, given that 98% of your activity occurs there. |
17 |
|
18 |
I discourage this. |
19 |
|
20 |
1) Depending on how it's done, it can break history across sessions. |
21 |
2) The $HISTFILE is inherently user writable. Which means that the |
22 |
user can modify it. |
23 |
3) The $HISTFILE is a convenience. |
24 |
4) The $HISTFILE is NOT an audit log. |
25 |
5) Depending on how the shell is configured, commands can bypass the |
26 |
$HISTFILE. |
27 |
6) The $HISTFILE does nothing for people putting commands in a script |
28 |
and then running the script. — I had someone do exactly this at my |
29 |
last job. |
30 |
|
31 |
I *HIGHLY* recommend running as much as you can through sudo. Sudo |
32 |
events do end up in syslog on every system I've used. |
33 |
|
34 |
|
35 |
|
36 |
-- |
37 |
Grant. . . . |
38 |
unix || die |