More detailed information about last commands executed than lastcomm

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

More detailed information about last commands executed than lastcomm

Wiesław Kielas-2
Dear misc@,

Is there any way to get information about last commands executed on a
OpenBSD machine? I'm interested in getting the command name along with
arguments passed to it.

From what I gathered so far, lastcomm can't show command arguments - is
there any way/other tool which can do that?

--
regards,

Wiesław Kielas

Reply | Threaded
Open this post in threaded view
|

Re: More detailed information about last commands executed than lastcomm

Jeremie Courreges-Anglas-2
Wiesław Kielas <[hidden email]> writes:

> Dear misc@,
>
> Is there any way to get information about last commands executed on a
> OpenBSD machine? I'm interested in getting the command name along with
> arguments passed to it.
>
> From what I gathered so far, lastcomm can't show command arguments - is
> there any way/other tool which can do that?

Seems like there's nothing in sys/acct.h for storing cli args.

--
jca | PGP: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90  8961 6191 8FBF 06A1 1494

Reply | Threaded
Open this post in threaded view
|

Re: More detailed information about last commands executed than lastcomm

Johan Mellberg
In reply to this post by Wiesław Kielas-2
16 sep 2013 kl. 11:38 skrev Wiesław Kielas <[hidden email]>:

> Dear misc@,
>
> Is there any way to get information about last commands executed on a
> OpenBSD machine? I'm interested in getting the command name along with
> arguments passed to it.
>
> From what I gathered so far, lastcomm can't show command arguments - is
> there any way/other tool which can do that?

history

Might do the trick? But maybe you want  a system-wide audit log / recording? There are (super-expensive) things like Cyber-Ark that does ssh session recording, maybe it could be made to work with local log-in as well.

>
> --
> regards,
>
> Wiesław Kielas

Reply | Threaded
Open this post in threaded view
|

Re: More detailed information about last commands executed than lastcomm

Nick Holland
In reply to this post by Wiesław Kielas-2
On 09/16/13 05:37, Wiesław Kielas wrote:
> Dear misc@,
>
> Is there any way to get information about last commands executed on a
> OpenBSD machine? I'm interested in getting the command name along with
> arguments passed to it.
>
>>From what I gathered so far, lastcomm can't show command arguments - is
> there any way/other tool which can do that?
>

how about "man ksh", then search for HISTFILE ?  Is that what you are after?
This is not on by default.  For a very reasons.

Nick.

Reply | Threaded
Open this post in threaded view
|

Re: More detailed information about last commands executed than lastcomm

Jiri B-2
In reply to this post by Wiesław Kielas-2
On Mon, Sep 16, 2013 at 11:38:18AM +0200, Wies�?aw Kielas wrote:
> Dear misc@,
>
> Is there any way to get information about last commands executed on a
> OpenBSD machine? I'm interested in getting the command name along with
> arguments passed to it.
>
> From what I gathered so far, lastcomm can't show command arguments - is
> there any way/other tool which can do that?

Usual unix process accounting does not take care about commands' args.
Anyway, you probably won't care about what normal users execute, you
probably want that only for admins/root. Then I would propose to build
a server with conserve (console server) which would be used as source
host to ssh/console to destination servers for admins/root. conserve
can save sessions in text form, you could have a filter and send it via
syslog/whatever to central logging server.

j.

Reply | Threaded
Open this post in threaded view
|

Re: More detailed information about last commands executed than lastcomm

Bret S. Lambert-2
On Mon, Sep 16, 2013 at 07:28:21AM -0400, Jiri B wrote:

> On Mon, Sep 16, 2013 at 11:38:18AM +0200, Wies??aw Kielas wrote:
> > Dear misc@,
> >
> > Is there any way to get information about last commands executed on a
> > OpenBSD machine? I'm interested in getting the command name along with
> > arguments passed to it.
> >
> > From what I gathered so far, lastcomm can't show command arguments - is
> > there any way/other tool which can do that?
>
> Usual unix process accounting does not take care about commands' args.
> Anyway, you probably won't care about what normal users execute, you
> probably want that only for admins/root. Then I would propose to build
> a server with conserve (console server) which would be used as source
> host to ssh/console to destination servers for admins/root. conserve
> can save sessions in text form, you could have a filter and send it via
> syslog/whatever to central logging server.
>
> j.
>

Why make shit more difficult than it need be? From the sudo man page:

    sudo also supports logging a command's input and output streams.

Reply | Threaded
Open this post in threaded view
|

Re: More detailed information about last commands executed than lastcomm

Bret S. Lambert-2
On Mon, Sep 16, 2013 at 01:31:58PM +0200, Bret Lambert wrote:

> On Mon, Sep 16, 2013 at 07:28:21AM -0400, Jiri B wrote:
> > On Mon, Sep 16, 2013 at 11:38:18AM +0200, Wies??aw Kielas wrote:
> > > Dear misc@,
> > >
> > > Is there any way to get information about last commands executed on a
> > > OpenBSD machine? I'm interested in getting the command name along with
> > > arguments passed to it.
> > >
> > > From what I gathered so far, lastcomm can't show command arguments - is
> > > there any way/other tool which can do that?
> >
> > Usual unix process accounting does not take care about commands' args.
> > Anyway, you probably won't care about what normal users execute, you
> > probably want that only for admins/root. Then I would propose to build
> > a server with conserve (console server) which would be used as source
> > host to ssh/console to destination servers for admins/root. conserve
> > can save sessions in text form, you could have a filter and send it via
> > syslog/whatever to central logging server.
> >
> > j.
> >
>
> Why make shit more difficult than it need be? From the sudo man page:
>
>     sudo also supports logging a command's input and output streams.

Er, I meant to copy

 sudo can log both successful and unsuccessful attempts

I blame the lack of something in my something system.

Reply | Threaded
Open this post in threaded view
|

Re: More detailed information about last commands executed than lastcomm

Jiri B-2
On Mon, Sep 16, 2013 at 01:33:33PM +0200, Bret Lambert wrote:
> On Mon, Sep 16, 2013 at 01:31:58PM +0200, Bret Lambert wrote:
> > On Mon, Sep 16, 2013 at 07:28:21AM -0400, Jiri B wrote:
> > > Usual unix process accounting does not take care about commands' args.
> > > Anyway, you probably won't care about what normal users execute, you
> > > probably want that only for admins/root. Then I would propose to build
> > > a server with conserve (console server) which would be used as source
> > > host to ssh/console to destination servers for admins/root. conserve
> > > can save sessions in text form, you could have a filter and send it via
> > > syslog/whatever to central logging server.

> > Why make shit more difficult than it need be? From the sudo man page:
> >
> >     sudo also supports logging a command's input and output streams.
>
> Er, I meant to copy
>
>  sudo can log both successful and unsuccessful attempts
>
> I blame the lack of something in my something system.

Yes it would be better to use sudo but some env are setup to allow direct
login to root :/

j.

Reply | Threaded
Open this post in threaded view
|

Re: More detailed information about last commands executed than lastcomm

Bret S. Lambert-2
On Mon, Sep 16, 2013 at 07:48:14AM -0400, Jiri B wrote:

> On Mon, Sep 16, 2013 at 01:33:33PM +0200, Bret Lambert wrote:
> > On Mon, Sep 16, 2013 at 01:31:58PM +0200, Bret Lambert wrote:
> > > On Mon, Sep 16, 2013 at 07:28:21AM -0400, Jiri B wrote:
> > > > Usual unix process accounting does not take care about commands' args.
> > > > Anyway, you probably won't care about what normal users execute, you
> > > > probably want that only for admins/root. Then I would propose to build
> > > > a server with conserve (console server) which would be used as source
> > > > host to ssh/console to destination servers for admins/root. conserve
> > > > can save sessions in text form, you could have a filter and send it via
> > > > syslog/whatever to central logging server.
>
> > > Why make shit more difficult than it need be? From the sudo man page:
> > >
> > >     sudo also supports logging a command's input and output streams.
> >
> > Er, I meant to copy
> >
> >  sudo can log both successful and unsuccessful attempts
> >
> > I blame the lack of something in my something system.
>
> Yes it would be better to use sudo but some env are setup to allow direct
> login to root :/

And the fact that they can do this via sudo should serve as an impetus
for those admins to stop Doing it Wrong(tm).

I understand that there are exceptions to the "best practices dictate
root-level access through sudo", but the original email that started
this thread seems to indicate that there's a need to keep tabs on some
henchmen/underlings/poorly-trained monkies. That screams "don't give
them direct root logins", to me.

Reply | Threaded
Open this post in threaded view
|

Re: More detailed information about last commands executed than lastcomm

Wiesław Kielas-2
* Bret Lambert <[hidden email]> [16.09.2013. @13:57:46 +0200]:

> On Mon, Sep 16, 2013 at 07:48:14AM -0400, Jiri B wrote:
> > On Mon, Sep 16, 2013 at 01:33:33PM +0200, Bret Lambert wrote:
> > > On Mon, Sep 16, 2013 at 01:31:58PM +0200, Bret Lambert wrote:
> > > > On Mon, Sep 16, 2013 at 07:28:21AM -0400, Jiri B wrote:
> > > > > Usual unix process accounting does not take care about commands' args.
> > > > > Anyway, you probably won't care about what normal users execute, you
> > > > > probably want that only for admins/root. Then I would propose to build
> > > > > a server with conserve (console server) which would be used as source
> > > > > host to ssh/console to destination servers for admins/root. conserve
> > > > > can save sessions in text form, you could have a filter and send it via
> > > > > syslog/whatever to central logging server.
> >
> > > > Why make shit more difficult than it need be? From the sudo man page:
> > > >
> > > >     sudo also supports logging a command's input and output streams.
> > >
> > > Er, I meant to copy
> > >
> > >  sudo can log both successful and unsuccessful attempts
> > >
> > > I blame the lack of something in my something system.
> >
> > Yes it would be better to use sudo but some env are setup to allow direct
> > login to root :/
>
> And the fact that they can do this via sudo should serve as an impetus
> for those admins to stop Doing it Wrong(tm).
>
> I understand that there are exceptions to the "best practices dictate
> root-level access through sudo", but the original email that started
> this thread seems to indicate that there's a need to keep tabs on some
> henchmen/underlings/poorly-trained monkies. That screams "don't give
> them direct root logins", to me.

Yes, I was looking for a way to keep track of commands run by different
users on the machine, and I was aware that various shells have a
HISTFILE. Sorry for not clarifying my intentions in my original post ;-)

I will probably turn sudo command logging and turn off root logins,
since it seems the most straightforward solution.

Thanks for all the replies ;-)

--
regards,

Wiesław Kielas