Audit: anonymous ftp and /etc/shadow - is this a risk?

Hello all-

My brain is misfiring and I need to ask for some advice. We are conducting on audit on some HP-UX 11.i servers and found one server, deemed a public ftp server, to have anoymous ftp. But we also found that the admins have enabled shadowed passwords. Now my first thought is that they need to disable ftp post-haste, but am I wrong on this? Can /etc/shadow be compromised and lead to the compromise of /etc/passwd? I think so, but again my brain is misfiring right now.

Also - as stated before, I believe they should have ftp turned off, even if they have imposed disk quota limits and move to ssh. The reason I ask this is because... they do not have ssh deployed everywhere and I have preached til I was coarse - so I was looking for some advice there as well.

Thanks in advance.

genXer.

I can only tell you that you must have a compelling business case and critical functional need to have an anonymous FTP server running. You must also have gone through a strict, lockstep configuration of the site. Even then, you are running a huge risk to activate an open FTP service. There are other, more secure solutions to the file transfer problem.

You are correct, genXer.

Thanks rapier57. I have been searching though and wanted to inform management, one way or another, that even with /etc/shadow enabled, having anon ftp could still lead to a compromise - though I am not sure how without causing some VanDamage, so without stating how, am I correct that /etc/shadow could be compromised leading to the compromise of /etc/passwd via anon ftp - or have I been huffing the wrong paint again?

Thanks again.

I am a little confused here...

I think the relevant question would be:
What permissions are the child processes of ftpd (or in.ftpd) running under?
What is the current permission on /etc/shadow ?
Does the ftpd run in a chroot environment ?

If you answerd: < root (ftp), 500 root:root, and yes, you should be ok, at least from the perspective of a direct accessing of /etc/shadow. That doesn't mean that there couldn't be other potential ways to cause problems, but the way I understand your question is that you are most concerned with the person using FTP to obain the hashes in the shadow and then cracking them to access the system...

Why not bypass all this and simply use SCP??? If the FTP service is there strictly for the use of admins, then there is no reason why they can't use SCP or SFTP.

Anonymous FTP servers are a no no here. Anything that negotiates connections in cleartext ain't gonna fly. There is also the obvious issue with FTP servers becomming warehouses for undesired apps and such.

Neb brings up many good points. If you are auditing the box, you need to consider everything that it's doing from a high level all the way down to the permission structure. However, you first have to do a complete risk assessment before you can run around deciding what a tolerable level of risk is defined as.

Anyway, my 2 cents.

Quote:

---

If you answerd: < root (ftp), 500 root:root, and yes, you should be ok, at least from the perspective of a direct accessing of /etc/shadow. That doesn't mean that there couldn't be other potential ways to cause problems, but the way I understand your question is that you are most concerned with the person using FTP to obain the hashes in the shadow and then cracking them to access the system...

---

Yes - I would answer how you did on your questions - I am just trying to understand the risk - what is the risk, and yes to state another way "but the way I understand your question is that you are most concerned with the person using FTP to obain the hashes in the shadow and then cracking them to access the system..." I want to confirm or disconfirm the belief I have that anon ftp should be disabled and we should move to scp, as TH13 suggests:

Quote:

---

Why not bypass all this and simply use SCP??? If the FTP service is there strictly for the use of admins, then there is no reason why they can't use SCP or SFTP.

---

TH13 - Risk assessments - yep I know that - believe it or not, we have to work to convince certain IT AND Audit managers that risk assessments are needed to understand the level of acceptable risks for a the organization at all levels - even down to the permissions of files/directories and what services should be enabled or not. Your and nebulus200's statements confirms exactly what we have been preaching. For this audit - I am unfortunately having to go with a general risk assessment; however, I do have our policies and standards, which we do normally anyway, that I am also utilizing to audit this entity.

Thanks to you both for your advice - I appreciate the feedback.

Have you tried vsftpd
http://vsftpd.beasts.org/

Quote:

---

Have you tried vsftpd
http://vsftpd.beasts.org/

---

Not before but just did - looks interesting, we will check out and see if they could use it or scp.

Thanks!