Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #192656 > unrolled thread
| Started by | me@risca.eu |
|---|---|
| First post | 2018-02-19 14:10 +0100 |
| Last post | 2018-02-19 22:40 +0100 |
| Articles | 10 — 6 participants |
Back to article view | Back to linux.debian.user
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
| From | me@risca.eu |
|---|---|
| Date | 2018-02-19 14:10 +0100 |
| Subject | SSH 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]
| From | Eero Volotinen <eero.volotinen@iki.fi> |
|---|---|
| Date | 2018-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]
| From | me@risca.eu |
|---|---|
| Date | 2018-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]
| From | Eero Volotinen <eero.volotinen@iki.fi> |
|---|---|
| Date | 2018-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]
| From | Steve Kemp <steve@steve.org.uk> |
|---|---|
| Date | 2018-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]
| From | john doe <johndoe65534@mail.com> |
|---|---|
| Date | 2018-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]
| From | me@risca.eu |
|---|---|
| Date | 2018-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]
| From | Eero Volotinen <eero.volotinen@iki.fi> |
|---|---|
| Date | 2018-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]
| From | Roberto C. Sánchez <roberto@debian.org> |
|---|---|
| Date | 2018-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]
| From | David Christensen <dpchrist@holgerdanske.com> |
|---|---|
| Date | 2018-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