Prevent remote root logins - Security

This is a discussion on Prevent remote root logins - Security ; Hello, How can we prevent the "root" account from remote logging in via SSH and Telnet but still permit root-equivalent personal accounts to log in remotely? Thank you in advance...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 24

Thread: Prevent remote root logins

  1. Prevent remote root logins

    Hello,

    How can we prevent the "root" account from remote logging in via SSH
    and Telnet but still permit root-equivalent personal accounts to log in
    remotely?

    Thank you in advance


  2. Re: Prevent remote root logins

    >How can we prevent the "root" account from remote logging in via SSH
    >and Telnet but still permit root-equivalent personal accounts to log in
    >remotely?


    In file '/etc/ssh/sshd_config', set these two properties:

    PermitRootLogin no
    AllowUsers YOUR-USER

    You won't be able to enter remotely as root in you machine. When you
    want to perform administrative tasks, first enter in your normal
    account and then run the 'su -' or 'sudo' commands.

    Do NOT use telnet at all! In telnet, passwords and data are sent in
    clear and anyone sniffing communications will be able to eavesdrop your
    name and password and any other data you type once logged in (as your
    root password!). In fact, the better thing you could do is deinstalling
    the telnet server!

    greetings,

    juanvi


  3. Re: Prevent remote root logins

    Thank you

    Will it work for personal user accounts that are "root-equivalent"
    (uid=0)?

    Will they be able to log on remotely?

    That is what I'm looking for. I would prefer not to use "su/sudo"
    commands, because that make me disclose root password which should be
    kept secret for critical situations.


  4. Re: Prevent remote root logins

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    boomboom999@yahoo.com wrote:
    > Hello,
    >
    > How can we prevent the "root" account from remote logging in via SSH


    In the sshd_config file, include the line
    PermitRootLogin no

    > and Telnet


    In the /etc/securetty file, make certain that there are no pts/* , ttyS*
    or ttyp* devices listed. Make certain that the only devices listed are
    the physical devices from which you want root to be able to log on to.

    > but still permit root-equivalent personal accounts to log in remotely?


    "root-equivalent personal accounts"? Do you mean "wheel" group (or
    administrator group) personal accounts? Or do you really mean (implied)
    "UID 0, but not 'root' username"? If you mean "UID 0", then you have a
    problem with a misconfigured system; there should only be /one/ UID 0
    account on your system. Anything else is a configuration and operational
    error.

    OTOH, if you mean "unpriviledged personal accounts belonging to the
    group of pre-established administrators (sometimes known as "wheel"),
    who can execute administrative activities as root using the sudo
    command", then no special setup is required. They log on as normal, and
    use sudo as normal to execute their administrative tasks as root.

    > Thank you in advance


    You are welcome.

    - --

    Lew Pitcher, IT Specialist, Corporate Technology Solutions,
    Enterprise Technology Solutions, TD Bank Financial Group

    (Opinions expressed here are my own, not my employer's)
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2.2 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFEOngLagVFX4UWr64RAjRLAKDaEQPEX2XNRRvOm0vZ1o jXlo1/RwCgtU80
    WdIUu8NCYsfBXdCJfgpl0aE=
    =gGiz
    -----END PGP SIGNATURE-----

  5. Re: Prevent remote root logins

    On 10.04.2006, boomboom999@yahoo.com wrote:
    > Thank you
    >
    > Will it work for personal user accounts that are "root-equivalent"
    > (uid=0)?


    Is it consistent with "no direct remote root login" policy?

    > Will they be able to log on remotely?
    >
    > That is what I'm looking for. I would prefer not to use "su/sudo"
    > commands, because that make me disclose root password which should be
    > kept secret for critical situations.


    Eh? sudo discloses password of target user? Have you used sudo before?

    --
    Feel free to correct my English
    Stanislaw Klekot

  6. Re: Prevent remote root logins

    juanvi wrote:
    >>How can we prevent the "root" account from remote logging in via SSH
    >>and Telnet but still permit root-equivalent personal accounts to log in
    >>remotely?

    >
    >
    > In file '/etc/ssh/sshd_config', set these two properties:
    >
    > PermitRootLogin no
    > AllowUsers YOUR-USER
    >
    > You won't be able to enter remotely as root in you machine. When you
    > want to perform administrative tasks, first enter in your normal
    > account and then run the 'su -' or 'sudo' commands.


    Can't you setup accounts in the root group and so those would have
    permission for most of the administrative tasks? (the tasks for
    which affected files are group-writeable?).

    > Do NOT use telnet at all! In telnet, passwords and data are sent in
    > clear and anyone sniffing communications will be able to eavesdrop your
    > name and password and any other data you type once logged in (as your
    > root password!). In fact, the better thing you could do is deinstalling
    > the telnet server!


    Definitely good advice.

    Plus unconditionally block port 23 (with iptables) in either direction,
    from any source to any destination, on all tables. That way, if the
    config files get accidentally changed and the telnet server is enabled,
    it won't matter (that much).

    Carlos
    --

  7. Re: Prevent remote root logins

    Thank you Lew

    Could you explain why having more than one "UID 0" could be a problem?

    Thank you in advance


  8. Re: Prevent remote root logins

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    boomboom999@yahoo.com wrote:
    > Thank you
    >
    > Will it work for personal user accounts that are "root-equivalent"
    > (uid=0)?


    Instead of answering that question, let's clear up a misunderstanding.

    UID 0 is /the/ root account. If you have more than one user defined with
    UID 0, then you /do not/ have "root-equivalent" personal user accounts.
    Instead, you have a multitude of real "root" accounts.

    This in and of itself is a security failure. It doesn't matter how you
    try to contain it, because any one of these accounts can not only
    violate the security containment you are trying to institute, each of
    these accounts can remove the containment, and even institute their own
    containment, to the detriment of every other user ("root equivalent" or
    otherwise) on the system.

    You are trying to lock the front door, but you busted the back wall
    completely open. Not the best security profile you could have used.

    - --

    Lew Pitcher, IT Specialist, Corporate Technology Solutions,
    Enterprise Technology Solutions, TD Bank Financial Group

    (Opinions expressed here are my own, not my employer's)
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2.2 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFEOn+6agVFX4UWr64RAvqJAJ9o/K8WC0ahVeGQyaONKZ+2ZfqOwQCghx6Y
    ZZ8KNyKtyL5x4ovBpt7Wp/M=
    =vVzG
    -----END PGP SIGNATURE-----

  9. Re: Prevent remote root logins

    I am still not convinced.

    Why 3 users with an SU privilege (running shell as root) would be
    better than 3 "root-equivalent" users (UID=0)?

    In the both cases, I need trust these people.
    In the both cases, if I have a malicious or demotivated admin, my
    chances to survive are small


  10. Re: Prevent remote root logins

    boomboom999@yahoo.com writes:

    >Hello,


    >How can we prevent the "root" account from remote logging in via SSH
    >and Telnet but still permit root-equivalent personal accounts to log in
    >remotely?


    telnet should be disabled. Not premitting remote login via root but
    allowing telnet is a bit like putting a big lock on your door, but leaving
    all of your windows open.

    Just prevent root login. I have no idea what "root-equivalent personal
    accounts " are. When you log in as a user, you can always run
    su
    to become root.



    >Thank you in advance



  11. Re: Prevent remote root logins

    boomboom999@yahoo.com writes:

    >Thank you


    >Will it work for personal user accounts that are "root-equivalent"
    >(uid=0)?


    That is a totally stupid idea.
    Have them log in as themselves and then use su to become root.


    >Will they be able to log on remotely?


    >That is what I'm looking for. I would prefer not to use "su/sudo"
    >commands, because that make me disclose root password which should be
    >kept secret for critical situations.


    I am sorry but your aguments are idiotic. If you have a user with uid 0,
    they ARE root. there is no critical situation anymore. They are root with
    absolutely all of the priviledges of root. In fact if do
    whoami it will say root.




  12. Re: Prevent remote root logins

    As I said the arguments are very simple.
    We want imputability and non repudiation, so we want to know who logged
    in at this particular time an made this particular change in the
    system.
    Blocking remote root logins is not our self-objective. We want to
    prevent remote login with generic administrative accounts. That is what
    we want to do. I do not see any security problem when a couple of
    autorized admins log on remotely with their personal accounts created
    with UID 0. Their personal account will be logged and at any time I
    will be able to identify a physical person behind an account.

    Am I wrong?


  13. Re: Prevent remote root logins

    boomboom999@yahoo.com wrote:
    > As I said the arguments are very simple.
    > We want imputability and non repudiation, so we want to know who logged
    > in at this particular time an made this particular change in the
    > system.
    > Blocking remote root logins is not our self-objective. We want to
    > prevent remote login with generic administrative accounts. That is what
    > we want to do. I do not see any security problem when a couple of
    > autorized admins log on remotely with their personal accounts created
    > with UID 0. Their personal account will be logged and at any time I
    > will be able to identify a physical person behind an account.
    >
    > Am I wrong?


    Well, this only works if you have all the logs redirected to a
    physical (external) device, such as a printer, that you hold on
    a secured/trusted location.

    Otherwise, you can't have imputability or non-repudiation; any
    one with root privileges logs in and tampers with the log files.

    If you do trust your users with root privileges, then you don't
    need imputability/non-repud.; and if you don't trust them, then
    your scheme would fail -- in fact, pretty much any scheme would
    fail if you don't really trust a user with root privileges; maybe
    logging to a tamper-proof physical device would allow you to
    move the threshold of trus to an intermediate point, where you
    can trust them only if they know that could be held accountable
    for whatever wrongdoing?

    Carlos
    --

  14. Re: Prevent remote root logins

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    boomboom999@yahoo.com wrote:
    > I am still not convinced.
    >
    > Why 3 users with an SU privilege (running shell as root) would be
    > better than 3 "root-equivalent" users (UID=0)?


    It wouldn't. And no one said it would.

    Don't use su(1) in a case like this. Instead, use sudo(8)

    With sudo(8), the /real/ root user can limit which root priviledges each
    user gets, by limiting the commands that /that/ user can perform using
    sudo. With su(1) or your "root equivalent" (actually, multiple root)
    users, there are no such controls.

    > In the both cases, I need trust these people.
    > In the both cases, if I have a malicious or demotivated admin, my
    > chances to survive are small


    Yes, so don't use those facilities.

    Instead, use sudo(8) or one of the other facilities that gives you audit
    and control over which root abilities these alternate administrators can
    use.


    - --

    Lew Pitcher, IT Specialist, Corporate Technology Solutions,
    Enterprise Technology Solutions, TD Bank Financial Group

    (Opinions expressed here are my own, not my employer's)
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2.2 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFEOpGwagVFX4UWr64RAsQIAKCQnY7CX1eRJmqvqXuV1U OJikVtPACdHpl4
    e3p16vJaO0gLsALwfV77C2s=
    =nztS
    -----END PGP SIGNATURE-----

  15. Re: Prevent remote root logins

    Lew Pitcher wrote:

    > UID 0 is /the/ root account. If you have more than one user defined with
    > UID 0, then you /do not/ have "root-equivalent" personal user accounts.
    > Instead, you have a multitude of real "root" accounts.
    >
    > This in and of itself is a security failure. It doesn't matter how you
    > try to contain it, because any one of these accounts can not only
    > violate the security containment you are trying to institute, each of
    > these accounts can remove the containment, and even institute their own
    > containment, to the detriment of every other user ("root equivalent" or
    > otherwise) on the system.
    >
    > You are trying to lock the front door, but you busted the back wall
    > completely open. Not the best security profile you could have used.


    How is that different from having several persons that know the root
    password?

    What I'm saying is that having multiple accounts that are "real root"
    accounts is no more security failure than having multiple persons
    that know the root password and have access to that one account.

    In fact, having multiple accounts is better in that you can cancel
    either one of them without having to change a password and notify
    all the others -- all this works under the assumption that you do
    have *some* level of trust, and that you can assume that they would
    not tamper with the system, isntall rootkits, etc.; otherwise you
    would not consider either approach -- hell, you wouldn't even
    consider *hiring* those persons.

    Another advantage of the multiple account is that you don't disclose
    the same password to others (maybe you have your own "secret recipe"
    to generate your passwords, and you don't want others to know it, but
    you do want others to have access to root for a particular server).

    Am I missing something?

    Carlos
    --

  16. Re: Prevent remote root logins

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Carlos Moreno wrote:
    > Lew Pitcher wrote:
    >
    >> UID 0 is /the/ root account. If you have more than one user defined with
    >> UID 0, then you /do not/ have "root-equivalent" personal user accounts.
    >> Instead, you have a multitude of real "root" accounts.
    >>
    >> This in and of itself is a security failure. It doesn't matter how you
    >> try to contain it, because any one of these accounts can not only
    >> violate the security containment you are trying to institute, each of
    >> these accounts can remove the containment, and even institute their own
    >> containment, to the detriment of every other user ("root equivalent" or
    >> otherwise) on the system.
    >>
    >> You are trying to lock the front door, but you busted the back wall
    >> completely open. Not the best security profile you could have used.

    >
    > How is that different from having several persons that know the root
    > password?

    [snip]
    > Am I missing something?


    Yup.

    Your points are exactly on target, and if "root equivalent" accounts or
    unpriviledged accounts with users that know the root password (in order
    to use su(1) or log in to the root account directly) were the only way
    to provide administrative privileges to a select community of users,
    then Unix administration would truely be up a creek.

    But... there is a way to give *selected* root privileges to users
    without either making them 'root' (UID 0) or giving them a password to
    root: complete the sudoers(5) file with details on who and what, and
    give the /unprivileged/ users the sudo(8) command.

    The only other way that I know of involves ACLs, which aren't as well
    defined or used in the Linux or Unix environments.

    - --

    Lew Pitcher, IT Specialist, Corporate Technology Solutions,
    Enterprise Technology Solutions, TD Bank Financial Group

    (Opinions expressed here are my own, not my employer's)
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2.2 (MingW32)
    Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

    iD8DBQFEOpdPagVFX4UWr64RAotSAJ9axnQAy+UzGXMQL+pfNk vexsWTfACgpcy2
    gbIleaggP71Ixwi+HFZvPOw=
    =zACs
    -----END PGP SIGNATURE-----

  17. Re: Prevent remote root logins

    On 2006-04-10, boomboom999@yahoo.com wrote:
    > We want imputability and non repudiation, so we want to know who logged
    > in at this particular time an made this particular change in the
    > system.


    If you want this...

    > I do not see any security problem when a couple of
    > autorized admins log on remotely with their personal accounts created
    > with UID 0.


    ....then you can't do this. Because...

    > Their personal account will be logged and at any time I
    > will be able to identify a physical person behind an account.
    >
    > Am I wrong?


    ....yes, you're wrong, because that user can tamper with those logs, or
    modify logging so as not to catch his behaviour. Example: user evilguy,
    uid=0, copies a special syslogd to the box, kills and restarts syslogd
    (perhaps under the guise of wanting to modify logging), modifies his
    history to not keep one at all (wiser) or remove evidence of his
    tampering, and goes on his merry way. His modified syslog might be
    designed not to report any behaviour by any uid=0 users, or not by
    evilguy, or not by any user on a particular tty, or not by evilguy on a
    particular tty at a particular time of day, or whatever. Point is,
    you're cracked, and logging won't help you, because the logs are no
    longer recording the malicious behaviour by your admin, and you have to
    suspect syslogd tampering in the first place in order to find any
    evidence at all that evilguy did it (and if he's *really* good, there
    won't be anything in there he can't plausibly deny).

    In general it's a worse idea to assign uid=0 to users than it is to use
    su, but in your scenario neither will reach your goals; only sudo comes
    close to giving you the desired features.

    --keith

    --
    kkeller-usenet@wombat.san-francisco.ca.us
    (try just my userid to email me)
    AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom
    see X- headers for PGP signature information


  18. Re: Prevent remote root logins

    On 2006-04-10, boomboom999@yahoo.com wrote:

    > Will it work for personal user accounts that are "root-equivalent"
    > (uid=0)?


    You don't want any uid=0 accounts to be directly accessibly remotely.

    > That is what I'm looking for. I would prefer not to use "su/sudo"
    > commands, because that make me disclose root password which should be
    > kept secret for critical situations.


    "sudo" does not require you to use the root password. The root user sets
    up commands that a non-privledged can use via sudo, using their own
    password to authenticate. Such accesses are logged for review.

    --

    John (john@os2.dhs.org)

  19. Re: Prevent remote root logins

    > Eh? sudo discloses password of target user? Have you used sudo before?

    Just to clarify. I had a little discord over passwords and 'sudo',
    confrontation solved after RTFM

    It seems that you can configure 'sudo' to:

    a) ask for the password of the original user (YOUR password)
    b) ask for the password of the target user (ROOT's password)

    See 'man sudo' and '/etc/sudoers'

    The funny thing is that different distributions have different default
    policies. My SuSE desktop asked for the root's password, while my
    partner's UBUNTU asked for his personal password. A matter or taste
    here, I suppose, and a source of discussion about Security.

    juanvi


  20. Re: Prevent remote root logins

    Carlos Moreno wrote:
    > Lew Pitcher wrote:
    > > UID 0 is /the/ root account. If you have more than one user defined with
    > > UID 0, then you /do not/ have "root-equivalent" personal user accounts.
    > > Instead, you have a multitude of real "root" accounts.
    > > This in and of itself is a security failure. It doesn't matter how you
    > > try to contain it, because any one of these accounts can not only
    > > violate the security containment you are trying to institute, each of
    > > these accounts can remove the containment, and even institute their own
    > > containment, to the detriment of every other user ("root equivalent" or
    > > otherwise) on the system.

    > How is that different from having several persons that know the root
    > password?
    > What I'm saying is that having multiple accounts that are "real root"
    > accounts is no more security failure than having multiple persons
    > that know the root password and have access to that one account.
    > Am I missing something?


    Do not have multiple superuser (UID 0) accounts. If one has multiple
    UID 0 accounts, among other problems, one weakens the audit/log trail.
    Rightly or wrongly, the operating system generally presumes that any
    given UID belongs to at most precisely one responsible account, and
    the data gathered in audit logs will commonly reflect that
    presumption. Have administrator(s) log into their own regular
    personal account(s), and then use sudo (or PowerBroker) when necessary
    to access privileged superuser operations.

    > How is that different from having several persons that know the root
    > password?


    You stick the "root" (the one and only superuser account, customarily
    root[1]) password in a highly opaque, well sealed, tamper resistant
    envelope, then lock that up in "break glass in case of emergency"
    container, in front of multiple videotaped video cameras, inside your
    highly secure vault behind your mantrap(s) (okay, so some
    environments may be roughly like that). In any case, you restrict
    access to and knowledge of the root password to bona fide "emergency"
    situations only - and the absolute minimal necessary for certain
    critical maintenance operations (e.g. initial installation). By
    minimizing access to the superuser password, and having only one
    superuser account, one makes it more probable that if/when something
    does go wrong, one has a better chance of tracking things back through
    audit/security logs (you do send those via secure means to a well
    secured remote logging system/device, right?) and determining the
    "person", or at least originating login account and thus responsible
    person, that caused the problem(s). That may not tell you with
    certainty who, but it should at least get you as far as via which
    person's account. Then it's a matter of determining was it
    inappropriate action(s) by the person responsible for the account,
    improper handling of the account's security (e.g. sticky note with
    password on monitor in violation of security policy), or if the
    account was somehow compromised in some other manner. In the case of
    shared root password, you have the worst scenario - there's ambiguity
    as to which person was responsible for the problem. With multiple
    superuser accounts you have a sub-optimal situation, as the audit/log
    information may not uniquely identify the account in many situations
    (e.g. it may tell you the action was done by UID 0, or was done by the
    first login name in the authentication that matches UID 0 - even if it
    wasn't done by that login).

    When in doubt, read some good UNIX (and LINUX and computer and
    general) security books and materials - preferably many of them (most
    of them are pretty good). There are many books on the subject. I've
    read 5 books cover-to-cover which contain both "UNIX" and "Security"
    in their titles, in addition to lots of other security materials.
    There's lot of good (and some not-so-good) information out there to be
    found.

    1. Many operating systems presume the superuser account will be named
    root, and may have at least some problems if it's not named root. At
    least in theory, however (and not necessarily per POSIX or other
    relevant standards), the account could be renamed. Now, for the
    not-so-security-clueful manager that insists upon having the root
    account password, this might be useful ... rename the superuser
    account to janitor (or something like that), and make root a
    non-privileged (non-UID 0, etc.) account ... and then comply with
    not-so-security-clueful manager's request by giving them the password
    to the (now non-privileged) root account. :-) Or better yet,
    substantially upgrade the manager's level of clue.


+ Reply to Thread
Page 1 of 2 1 2 LastLast