Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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.

share|improve this question

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

There are either too many possible answers, or good answers would be too long for this format. Please add details to narrow the answer set or to isolate an issue that can be answered in a few paragraphs.If this question can be reworded to fit the rules in the help center, please edit the question.

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). – richard Feb 7 '14 at 16:32
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.

share|improve this answer
In the last case scenario is better to fix the webserver instead... – Braiam Feb 7 '14 at 18:32
But that's okay because all the users with accounts on the server itself have no passwords, only SSH keys, and password information isn't stored in /etc/passwd anyway, right? – Blacklight Shining Feb 8 '14 at 4:59

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?

share|improve this answer
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
"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.

share|improve this answer
explainfull answer. thank you. – user245711 Feb 7 '14 at 22:08
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.

share|improve this answer
i just wanted to add more security, i have more than one website on my server. – user245711 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.

share|improve this answer
thank you ! It is always good to learn something new ! – user245711 Feb 8 '14 at 9:56

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