I have a server. My server is secure, but let's imagine a good hacker that enter in. He can now look into /etc/passwd and /etc/shadow. I would like to rename that files /etc/passwd to something like /etc/xxanoda.

I thought I can do a link, but for an hacker it will be easy to do ls -l.

It is possible to rename those files and still have a running OS, without compatibility issues, or it is completely useless ? Just for the seek of knowledge.

closed as too broad by mikewhatever, Maythux, Thomas Ward, belacqua, Avinash Raj Feb 8 '14 at 13:07

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    I think it is possible to use a separate authentication server, to hold all the user passwords. The main server will contact the authentication server, when a user tries to log in. The authentication server is kept away from users (no direct internet access). – ctrl-alt-delor Feb 7 '14 at 16:32
  • 9
    Security by obscurity is no security at all. – Doorknob Feb 7 '14 at 22:36
  • This is a terrible, terrible, terrible idea. – Shadur Feb 8 '14 at 10:29

The Filesystem Hierarchy Standard for unix-like systems includes /etc/passwd at a fixed location, and tools are consequently usually hardcoded to look there for it. While in theory you could re-compile all the relevant utilities to look in a new location, any attacker could always just look for strings in those binaries to locate the new file, or use regular expressions to find files with passwd-like contents.

The shadow file should be readable only to root (and possibly to a group called shadow). If an attacker has managed to get root access to your system, they have complete control and whether or not they can read your passwd/shadow files is pretty irrelevant at that point.

There are conceivably a few situations where having files not in expected places might help, eg if you have a badly-configured web server which lets someone request http://myserver/../../etc/passwd, but in general this sort of indirection will require a lot of work for a minimal security benefit.


The best thing that would be is "completely useless" as you put it. (It doesn't provide an additional hurdle for an intruder)

/etc/passwd does contain account names, but anybody who has shell access to the system will be able to find them.

/etc/shadow contains sensitive information (the password hashes) but it is readable for root only. If an intruder managed to get root privileges - well how do you spell disaster?

  • 1
    You should also assume an attacker has full access to every file on your system (and possibly downloaded their own copy) until you know otherwise. – Bert Feb 7 '14 at 17:50
  • 4
    "how do you spell disaster?" probably works better in a context where you don't have to spell disaster to ask it :D – user51157 Feb 7 '14 at 18:50

In modern Unices (and Unix-likes, including Ubuntu), /etc/passwd doesn't contain any secrets. Renaming it would be more trouble than it is worth, given how many utilities would have to be rebuilt to look for it in its new location.

/etc/shadow is another matter, since there are secrets in that file, but renaming it won't help. It's only readable by root, so even if a hacker gets into the system as some other user, that's not enough to get to the file. This is why passwords were taken out of /etc/passwd in the first place: everyone needs to be able to read /etc/passwd, but only root needs to be able to get at the actual passwords, so the passwords were moved to a file that only root could read.

If the hacker does get root, then a rename won't save you. A simple recursive grep could give the hacker a list of files in an /etc/shadow-like format, and then the hacker only has to look through them to find the data he wants. You've delayed him by a few hours at most, and probably less: again, not worth the amount of time it would take to modify and recompile all the utilities that depend on /etc/shadow's location.

  • Besides, if he's got root access, he doesn't /need/ anyone else's password. He can just su into whatever account he wants, or he can change the password of any user on the system. And if he really wants to have the passwords (just in case the users reuse their passwords elsewhere) he can upload a modified login binary or add a pam module that intercepts authentication attempts and relays the username/password combinations to him. – Shadur Feb 8 '14 at 10:32

You cannot just rename these files. A lot of processes and programs will search for them, since this is a standard in Linux systems. What you can do is to securize your server in the proper way.

  • i just wanted to add more security, i have more than one website on my server. – Marco Caggiano Feb 8 '14 at 9:57

While it's probably no use to rename the /etc/passwd and /etc/shadow files, if you want added security you might want to look at PAM (pluggable authentication modules) and NSS (Name Service Switch). Like here.

PAM can be used to add authentication modules that, instead reading their authentication ifnormation from the standard files, read it from an other source, like from ldap or a database. Using it would mean the /etc/shadow can be almost completley eliminated.

NSS complements PAM by making some of the name resolution (like which groups does this user belongs to) independent from the standard files (/etc/passwd, /etc/groups). Using it would mean your passwd file will potentially only contain a fallback option for root, and nothing more. Using SSH keys to validate root login would also eliminate the need to have a root password inside the shadow file (although it might be desired if the SSH connection breaks).

Alternatively if you don't want to authenticate your users via a separate database or ldap host, you can also create your own PAM and NSS modules, which read their data from a non-standard file, although I wouldn't recommend this option.

When you want to try to use them never forget to keep some kind of fallback to a known, working authentication layer, otherwise you can lock yourself out of the system, even with root.

Note that not all applications support PAM (a lot of them do however). NSS however can be used to implement authentication for apps that don't support PAM, and some sites I've read about NSS actually suggest this approach. This however means that the NSS module will supply the (potentially) hashed password to anyone who can access the NSS authentication layer, which is almost always something you want to avoid (it's basically the same as giving non-root read access to the shadow file)! So if you're going this approach always make sure that NSS is only used to provide the user with the basic data (like the contents of /etc/passwd), and PAM is used as the authentication layer.

Not the answer you're looking for? Browse other questions tagged or ask your own question.