Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #192656 > unrolled thread

SSH session audit

Started byme@risca.eu
First post2018-02-19 14:10 +0100
Last post2018-02-19 22:40 +0100
Articles 10 — 6 participants

Back to article view | Back to linux.debian.user


Contents

  SSH session audit me@risca.eu - 2018-02-19 14:10 +0100
    Re: SSH session audit Eero Volotinen <eero.volotinen@iki.fi> - 2018-02-19 14:20 +0100
      Re: SSH session audit me@risca.eu - 2018-02-19 14:40 +0100
        Re: SSH session audit Eero Volotinen <eero.volotinen@iki.fi> - 2018-02-19 14:50 +0100
    Re: SSH session audit Steve Kemp <steve@steve.org.uk> - 2018-02-19 14:50 +0100
    Re: SSH session audit john doe <johndoe65534@mail.com> - 2018-02-19 17:00 +0100
      Re: SSH session audit me@risca.eu - 2018-02-19 17:30 +0100
        Re: SSH session audit Eero Volotinen <eero.volotinen@iki.fi> - 2018-02-19 17:40 +0100
        Re: SSH session audit Roberto C. Sánchez <roberto@debian.org> - 2018-02-19 17:40 +0100
    Re: SSH session audit David Christensen <dpchrist@holgerdanske.com> - 2018-02-19 22:40 +0100

#192656 — SSH session audit

Fromme@risca.eu
Date2018-02-19 14:10 +0100
SubjectSSH session audit
Message-ID<vkTmG-3qb-15@gated-at.bofh.it>
Hi,

I'm co-managing a server with a friend of mine offering ourself some 
basic service (like emails, file sharing, etc). At this time each of us 
can freely login on the server via ssh (we trust each others) for the 
daily administrative tasks.

I would like to improve the current set up by adding a layer of 
certification and proofing of the ssh session, because if you know that 
you are recorded you'll be enforce to behave better. For this scope I've 
found many different possible solution, but quite complex to be 
implemented (like ssh proxy that records the session [1]), or too basic 
(like using /usr/bin/script). So far none of those that I've found 
satisfy me.

About that I remember that some time ago (maybe one or two years ago) I 
read a post on planet debian about such a method for session audit. It 
was suggesting as an easy to run solution for external consultant: the 
recording and encrypting of the remote session was performed without 
requiring any proxy, letting to store the session data on a dumb 
external host. From what I could remember I think that the idea was 
something like recording the session with script like utilities 
(launched at session login), then periodically encrypting it with gpg 
and publishing on a local folder or on a remote resource. This way the 
owner of the system could reliably access the session log, and the 
remote person could always prove what he did at during the ssh session.

Do you know about that solution? Or could you suggest something similar?

Thank you,

risca.

[1] ssh proxy solutions: ssh-bastion, KeyBox

[toc] | [next] | [standalone]


#192658

FromEero Volotinen <eero.volotinen@iki.fi>
Date2018-02-19 14:20 +0100
Message-ID<vkTwm-3uw-13@gated-at.bofh.it>
In reply to#192656

[Multipart message — attachments visible in raw view] — view raw

Commercial solution: https://www.ssh.com/products/cryptoauditor/

Eero

On Mon, Feb 19, 2018 at 2:51 PM, <me@risca.eu> wrote:

> Hi,
>
> I'm co-managing a server with a friend of mine offering ourself some basic
> service (like emails, file sharing, etc). At this time each of us can
> freely login on the server via ssh (we trust each others) for the daily
> administrative tasks.
>
> I would like to improve the current set up by adding a layer of
> certification and proofing of the ssh session, because if you know that you
> are recorded you'll be enforce to behave better. For this scope I've found
> many different possible solution, but quite complex to be implemented (like
> ssh proxy that records the session [1]), or too basic (like using
> /usr/bin/script). So far none of those that I've found satisfy me.
>
> About that I remember that some time ago (maybe one or two years ago) I
> read a post on planet debian about such a method for session audit. It was
> suggesting as an easy to run solution for external consultant: the
> recording and encrypting of the remote session was performed without
> requiring any proxy, letting to store the session data on a dumb external
> host. From what I could remember I think that the idea was something like
> recording the session with script like utilities (launched at session
> login), then periodically encrypting it with gpg and publishing on a local
> folder or on a remote resource. This way the owner of the system could
> reliably access the session log, and the remote person could always prove
> what he did at during the ssh session.
>
> Do you know about that solution? Or could you suggest something similar?
>
> Thank you,
>
> risca.
>
> [1] ssh proxy solutions: ssh-bastion, KeyBox
>
>

[toc] | [prev] | [next] | [standalone]


#192661

Fromme@risca.eu
Date2018-02-19 14:40 +0100
Message-ID<vkTPH-3AI-1@gated-at.bofh.it>
In reply to#192658
On 2018-02-19 14:11, Eero Volotinen wrote:
> Commercial solution: https://www.ssh.com/products/cryptoauditor/

Thanks for the option and sorry if I hadn't specified in my previous: 
commercial solution are against the TOS of the project. We have the 
requirement, commitment and wish to be 100% free-software.

On 2018-02-19 14:22, Steve Kemp wrote:
>> Do you know about that solution? Or could you suggest something 
>> similar?
>   You could install "snoopy", which will log all command-executed to
>  syslog.  Then configure your syslog to forward logs to a remote host.
>   It is not fool-proof, but requires no setup for a user..

Nice to know. It could be improved by moving the logs outside but would 
required additional work (and who will be the one in charge of managing 
it?). I had a quick view of it but probably it has problem with 
interactive programs like editors (I think you'd get only a "vim 
file.txt").

Anyway, I also remember about the post that I read, that was such a 
clever and easy solution to feel like the obvious way of doing it. It 
was easy to run and very reliable thanks to asymmetric encryption via 
gpg.

[toc] | [prev] | [next] | [standalone]


#192664

FromEero Volotinen <eero.volotinen@iki.fi>
Date2018-02-19 14:50 +0100
Message-ID<vkTZn-3DR-3@gated-at.bofh.it>
In reply to#192661

[Multipart message — attachments visible in raw view] — view raw

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/security_guide/sec-configuring_pam_for_auditing

pam audit might work, test it :)

--
Eero

On Mon, Feb 19, 2018 at 3:29 PM, <me@risca.eu> wrote:

> On 2018-02-19 14:11, Eero Volotinen wrote:
>
>> Commercial solution: https://www.ssh.com/products/cryptoauditor/
>>
>
> Thanks for the option and sorry if I hadn't specified in my previous:
> commercial solution are against the TOS of the project. We have the
> requirement, commitment and wish to be 100% free-software.
>
> On 2018-02-19 14:22, Steve Kemp wrote:
>
>> Do you know about that solution? Or could you suggest something similar?
>>>
>>   You could install "snoopy", which will log all command-executed to
>>  syslog.  Then configure your syslog to forward logs to a remote host.
>>   It is not fool-proof, but requires no setup for a user..
>>
>
> Nice to know. It could be improved by moving the logs outside but would
> required additional work (and who will be the one in charge of managing
> it?). I had a quick view of it but probably it has problem with interactive
> programs like editors (I think you'd get only a "vim file.txt").
>
> Anyway, I also remember about the post that I read, that was such a clever
> and easy solution to feel like the obvious way of doing it. It was easy to
> run and very reliable thanks to asymmetric encryption via gpg.
>

[toc] | [prev] | [next] | [standalone]


#192665

FromSteve Kemp <steve@steve.org.uk>
Date2018-02-19 14:50 +0100
Message-ID<vkTZn-3DR-9@gated-at.bofh.it>
In reply to#192656
> Do you know about that solution? Or could you suggest something similar?

  You could install "snoopy", which will log all command-executed to
 syslog.  Then configure your syslog to forward logs to a remote host.

  It is not fool-proof, but requires no setup for a user..

Steve
-- 
https://www.steve.org.uk/

[toc] | [prev] | [next] | [standalone]


#192682

Fromjohn doe <johndoe65534@mail.com>
Date2018-02-19 17:00 +0100
Message-ID<vkW1b-4U1-3@gated-at.bofh.it>
In reply to#192656
On 2/19/2018 1:51 PM, me@risca.eu wrote:
> Hi,
> 
> I'm co-managing a server with a friend of mine offering ourself some 
> basic service (like emails, file sharing, etc). At this time each of us 
> can freely login on the server via ssh (we trust each others) for the 
> daily administrative tasks.
> 
> I would like to improve the current set up by adding a layer of 
> certification and proofing of the ssh session, because if you know that 
> you are recorded you'll be enforce to behave better. For this scope I've 
> found many different possible solution, but quite complex to be 
> implemented (like ssh proxy that records the session [1]), or too basic 
> (like using /usr/bin/script). So far none of those that I've found 
> satisfy me.
> 
> About that I remember that some time ago (maybe one or two years ago) I 
> read a post on planet debian about such a method for session audit. It 
> was suggesting as an easy to run solution for external consultant: the 
> recording and encrypting of the remote session was performed without 
> requiring any proxy, letting to store the session data on a dumb 
> external host. From what I could remember I think that the idea was 
> something like recording the session with script like utilities 
> (launched at session login), then periodically encrypting it with gpg 
> and publishing on a local folder or on a remote resource. This way the 
> owner of the system could reliably access the session log, and the 
> remote person could always prove what he did at during the ssh session.
> 
> Do you know about that solution? Or could you suggest something similar?
> 
> Thank you,
> 
> risca.
> 
> [1] ssh proxy solutions: ssh-bastion, KeyBox
> 

Isn't pam enough?:

https://linux.die.net/man/8/pam

No need to install anything and it's quite versatile.

-- 
John Doe

[toc] | [prev] | [next] | [standalone]


#192684

Fromme@risca.eu
Date2018-02-19 17:30 +0100
Message-ID<vkWue-5kM-13@gated-at.bofh.it>
In reply to#192682
On 2018-02-19 16:52, john doe wrote:
> Isn't pam enough?:
> https://linux.die.net/man/8/pam
> 
> No need to install anything and it's quite versatile.

Yes, this is in line with the other suggested options such as snoopy or 
pam_tty_audit. It could work as audit system, but it seems to me as a 
solution for more structured and corporate environment.
In the described case I would like a solution that store record the 
session in a safe way, immutable and trustable, therefore encrypting all 
(only the owners have to be able to read it) and hosted on a read only 
resource (the user who logins should not be able to delete it) and 
provable (signed).
I think that with pam there is the risk that a user with full access 
right could easily delete all the logs. Or that the log could be altered 
after.

[toc] | [prev] | [next] | [standalone]


#192687

FromEero Volotinen <eero.volotinen@iki.fi>
Date2018-02-19 17:40 +0100
Message-ID<vkWDU-5pu-15@gated-at.bofh.it>
In reply to#192684

[Multipart message — attachments visible in raw view] — view raw

Well. It's normal way to stream logs to centralized log server via rsyslog
or ossec..

Eero

19.2.2018 18.25 <me@risca.eu> kirjoitti:

> On 2018-02-19 16:52, john doe wrote:
>
>> Isn't pam enough?:
>> https://linux.die.net/man/8/pam
>>
>> No need to install anything and it's quite versatile.
>>
>
> Yes, this is in line with the other suggested options such as snoopy or
> pam_tty_audit. It could work as audit system, but it seems to me as a
> solution for more structured and corporate environment.
> In the described case I would like a solution that store record the
> session in a safe way, immutable and trustable, therefore encrypting all
> (only the owners have to be able to read it) and hosted on a read only
> resource (the user who logins should not be able to delete it) and provable
> (signed).
> I think that with pam there is the risk that a user with full access right
> could easily delete all the logs. Or that the log could be altered after.
>
>

[toc] | [prev] | [next] | [standalone]


#192688

FromRoberto C. Sánchez <roberto@debian.org>
Date2018-02-19 17:40 +0100
Message-ID<vkWDU-5pu-19@gated-at.bofh.it>
In reply to#192684
On Mon, Feb 19, 2018 at 05:21:13PM +0100, me@risca.eu wrote:
> On 2018-02-19 16:52, john doe wrote:
> > Isn't pam enough?:
> > https://linux.die.net/man/8/pam
> > 
> > No need to install anything and it's quite versatile.
> 
> Yes, this is in line with the other suggested options such as snoopy or
> pam_tty_audit. It could work as audit system, but it seems to me as a
> solution for more structured and corporate environment.

OK.

> In the described case I would like a solution that store record the session
> in a safe way, immutable and trustable, therefore encrypting all (only the
> owners have to be able to read it) and hosted on a read only resource (the
> user who logins should not be able to delete it) and provable (signed).
> I think that with pam there is the risk that a user with full access right
> could easily delete all the logs. Or that the log could be altered after.
> 

You say that the PAM solution sounds too structured and corporate then
go on to describe a highly structured system that would be very
appropriate for a corporate environment.

The truth is that if you try to roll your own solution then you are
likely to make some sort of mistake and introduce a vulnerability. Even
if you think PAM is "too structured" you are better off using that than
making a mistake in your custom implementation and leaving a whole.

Another aspect is that in your initial post you say that you trust your
partner, but everything you have described since is specifically aimed
creating a solution resistant to an *untrusted* party. You seem to be
contradicting yourself on this point.

You might want to consider a whitelist of commands accessible via sudo.
Each access of sudo is logged by the system and if you do not permit the
user modify system logs, then that may meet your requirements.

Regards,

-Roberto

-- 
Roberto C. Sánchez

[toc] | [prev] | [next] | [standalone]


#192731

FromDavid Christensen <dpchrist@holgerdanske.com>
Date2018-02-19 22:40 +0100
Message-ID<vl1kd-8rM-7@gated-at.bofh.it>
In reply to#192656
On 02/19/18 04:51, me@risca.eu wrote:
> Hi,
> 
> I'm co-managing a server with a friend of mine offering ourself some
>  basic service (like emails, file sharing, etc). At this time each of
> us can freely login on the server via ssh (we trust each others) for
> the daily administrative tasks.
> 
> I would like to improve the current set up by adding a layer of 
> certification and proofing of the ssh session, because if you know
> that you are recorded you'll be enforce to behave better. For this
> scope I've found many different possible solution, but quite complex
> to be implemented (like ssh proxy that records the session [1]), or
> too basic (like using /usr/bin/script). So far none of those that
> I've found satisfy me.
> 
> About that I remember that some time ago (maybe one or two years ago)
> I read a post on planet debian about such a method for session audit.
> It was suggesting as an easy to run solution for external consultant:
> the recording and encrypting of the remote session was performed
> without requiring any proxy, letting to store the session data on a
> dumb external host. From what I could remember I think that the idea
> was something like recording the session with script like utilities 
> (launched at session login), then periodically encrypting it with gpg
>  and publishing on a local folder or on a remote resource. This way
> the owner of the system could reliably access the session log, and
> the remote person could always prove what he did at during the ssh
> session.

That does not sound secure.  See the Byzantine Generals' Problem:

     https://en.wikipedia.org/wiki/Byzantine_fault_tolerance


> Do you know about that solution? Or could you suggest something
> similar?
> 
> Thank you,
> 
> risca.
> 
> [1] ssh proxy solutions: ssh-bastion, KeyBox


On 02/19/18 08:34, Roberto C. Sánchez wrote:
> You might want to consider a whitelist of commands accessible via
> sudo. Each access of sudo is logged by the system and if you do not
> permit the user modify system logs, then that may meet your
> requirements.

+1 for sudo (no comment on the rest).  This book is good:

     https://www.michaelwlucas.com/tools/sudo


David

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.user


csiph-web