Re: Renaming root account

From: Craig Edwards (brain_at_winbot.co.uk)
Date: 03/03/05

  • Next message: Alec Berryman: "Re: Renaming root account"
    Date: Thu, 03 Mar 2005 08:53:54 +0000
    To: estover@nativenerds.com
    
    

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

    Thanks Ed,

    My system already has securelevel 2 set and immutable flags on most of
    its core system files in /sbin and /bin, etc. Basically i am aware of
    the fact that other systems (for example windows) let you change the
    administrative user's username to enhance security that little bit more.
    Security through obscurity on its own is not a good method of securing a
    network but when combined with other systems, it can be an advantage.

    Currently i also utilize samhain and make regular (nightly) backups to a
    windows machine behind a second router (which is a security aspect many
    people will overlook!). I run nightly virus scans from my /etc/periodic
    and update the signatures automatically, as i have lost a redhat linux
    machine before due to a cracker dropping the RST.b trojan/virus onto it,
    and this would locate such a problem and allow me to reformat the
    machine faster. The machine is being used as my internet gateway for my
    small network and also as a collaberative centre for a group of users
    who work on my programming projects. These users are trusted of course
    but the more users you add to a system the more chance there is of it
    being compromised as there is more to keep track of and more to audit,
    so the more layers of security you can use, the better.

    Thanks for your time,
    Craig

    Ed Stover wrote:
    > This response is a bit off of what you asked but I will just toss this
    > out there.
    > I generally protect my machines from the root user but utilizing
    > chflags and kernel secure levels. That way if an attacker were to gain
    > root access they wouldn't be able to change files... On my firewalls I
    > modify rc.conf to boot to secure level 2 ,then I lock
    > down /bin /sbin /etc /usr/local/etc with chflags schg while still in
    > secure level 0 then reboot. Upon the restart you have a very secure
    > machine that is protected from root user. In secure level two, even root
    > cannot change those files flagged immutable. The only way to change
    > those files would be to have physical access to the machine and modify
    > rc.conf in single user mode and then reboot change the flags back from
    > immutable and then modify the files. That is a bit too secure to be
    > user friendly. I am just a getRdun type of person, you could lock down
    > certain files and leave the five passwd files alone so users could
    > change their passwords but generally attackers try to add themselves an
    > account right away. What application would you be using the server for?
    > Most H4X0RZ attacks I have seen where they have gained shell access are
    > stumped when it comes to file flags and kernel secure levels.
    > On Thu, 2005-03-03 at 08:03 +0000, Craig Edwards wrote:
    >
    > Hi everyone,
    >
    > One quick question: Is it safe and/or sensible to rename the root
    > account, so that the only uid 0 user on a system is something different
    > to root? I can see how this would be effective against external
    > attackers who have no knowledge of the internals of the system as they
    > would spend pointless hours trying to crack a user which doesnt exist,
    > however to internal users they could always just cat /etc/passwd and see
    > that root has been renamed. So firstly, is this possible, and security
    > wise is it of any real use? Can anyone think of any apps it would break
    > that assume that the uid 0 user is called root and don't just address
    > the user by its uid?
    >
    > Thanks,
    > Craig Edwards
    >
    _______________________________________________
    freebsd-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-security
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"

    - --
    WinBot IRC client developer: http://www.winbot.co.uk
    ChatSpike - The users network: http://www.chatspike.net
    InspIRCd - Modular IRC server: http://www.inspircd.org
    Online RPG Developer: http://www.ssod.org
    - --
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.2.5 (MingW32)

    iD8DBQFCJtCi0k42Wxli/BARAuzfAJ4yOV0OTXmrwa0PYTp2BPTU4pMWsQCfYX29
    kPWaZ4Oz/q0Bf8xg4D6HoHo=
    =RZT4
    -----END PGP SIGNATURE-----
    _______________________________________________
    freebsd-security@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-security
    To unsubscribe, send any mail to "freebsd-security-unsubscribe@freebsd.org"


  • Next message: Alec Berryman: "Re: Renaming root account"

    Relevant Pages

    • Re: Screensaver takes too much time to fade-out...
      ... If you are serious about making your machine secure, ... learn a thing or two about security. ... These logs are mailed to the root user at 3am. ... Setup dovecot and use a local email client to fetch it. ...
      (Fedora)
    • Re: Screensaver takes too much time to fade-out...
      ... If you are serious about making your machine secure, ... These logs are mailed to the root user at 3am. ... Setup dovecot and use a local email client to fetch it. ...
      (Fedora)
    • Re: how to make Unix box secure
      ... > Suppose the person knows the root passwd and su to root. ... There are myriad things you can do to make your Solaris boxes secure, ... fail to consider the consequences of a physical breach of security. ...
      (comp.unix.solaris)
    • Re: Compile problem
      ... It turned out after looking at the man pages for ld.so.1 the security ... Secure processes have some restrictions applied to the ... The default trusted directory known to the runtime linker is ... root, it has no problem finding the gcc library. ...
      (comp.mail.sendmail)
    • Re: Encrypted file system without initial password:
      ... > This was not a question about potential root exploits. ... These settings can then be password-protected in the BIOS ... >> software-based security measure would be useless. ... the system should be fairly secure. ...
      (comp.os.linux.security)