record sessions when 'root' login via ssh or on console ?


how to record sessions when 'root' logs-in via ssh or on console
directly ?

most of the machines are virtualized, accessing servers directly via
console does not require to be physically present in the datacenter,
how can PAM helps in this case ?

Regards,
MS


--
sharfuddin
------------------------------------------------------------------------
sharfuddin's Profile: https://forums.netiq.com/member.php?userid=1016
View this thread: https://forums.netiq.com/showthread.php?t=56422

  • On 08/11/2016 06:34 AM, sharfuddin wrote:
    >
    > how to record sessions when 'root' logs-in via ssh or on console
    > directly ?


    Basic security practice 101: Users always login with their non-root
    accounts. Disable the 'root' account, even, or perhaps slightly better,
    give it a 100-characer password that is printed on paper and locked in a
    vault that cannot be accessed without a couple people's direct help.

    > most of the machines are virtualized, accessing servers directly via
    > console does not require to be physically present in the datacenter,
    > how can PAM helps in this case ?


    The idea behind things like Privileged Account (User) Manager (PAM/PUM) is
    that it helps you manage privileged users. Ideally those privileged users
    know their own passwords, and can do privileged things thanks to PAM when
    needed, and PAM will monitor their entire sessions as you would like,
    including if they use something like 'su' or 'sudo' to change to another
    user, even 'root', but logging in directly as 'root' should be used for
    emergencies only or, even if you do monitor the session entirely, you have
    no idea who is actually doing that stuff. I have never heard of a
    compelling reason to leave the root password known by anybody after either
    implementing PAM properly, or at least implementing 'sudo' properly (and
    losing the ability to record sessions, of course, since that's a PAM/PUM
    feature).

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...
  • To capture direct ssh logins, as root, for example or any other direct ssh login would require Integrating Command Control to User Environments with usrun, pcksh or cpcksh. A NPAM Agent would need to be running on the server as well. There are various approaches described here that can help capture these sessions and even control what's available for them as well.

  • tdharris;270529 Wrote:
    > To capture direct ssh logins, as root, for example or any other direct
    > ssh login would require 'Integrating Command Control to User
    > Environments'
    > (http://tinyurl.com/h3bbk85)
    > with usrun, pcksh or cpcksh. A NPAM Agent would need to be running on
    > the server as well. There are various approaches described here that can
    > help capture these sessions and even control what's available for them
    > as well.
    >
    >
    > --
    > tdharris
    >


    sorry didn't get you. I know these special shells provide
    auditing/reporting/monitoring and privileges, but what I don't know and
    neither the documents discus is how to "record direct(via ssh or from
    console) root login"

    Regards,


    --
    sharfuddin
    ------------------------------------------------------------------------
    sharfuddin's Profile: https://forums.netiq.com/member.php?userid=1016
    View this thread: https://forums.netiq.com/showthread.php?t=56422

  • On 08/18/2016 06:04 AM, sharfuddin wrote:
    >
    > sorry didn't get you. I know these special shells provide
    > auditing/reporting/monitoring and privileges, but what I don't know and
    > neither the documents discus is how to "record direct(via ssh or from
    > console) root login"


    If 'root' were to use a login shell provided by PAM/PUM, then those could
    be audited, but doing this is still dumb because:

    1. You have no way to tell who logged in as 'root', other than by IP
    address, which is not reliable most of the time.
    2. If you have a problem with PAM, you may lose access to your box as
    'root', which is pretty terrible.
    3. Giving users the 'root' password (or equivalent) often means they can
    find another way in. Don't do it!

    --
    Good luck.

    If you find this post helpful and are logged into the web interface,
    show your appreciation and click on the star below...
  • There is an approach to monitor direct-ssh connections on Linux where local users can use their native / default / preferred shell. This is only possible if an agent is running on the server. Like mentioned previously though, I think it might be a better approach to have users use their normal user credentials and receive privileged access to these accounts; however, here is a recently written document that explains a cpcksh approach that has been used by some: TID 7017938.