How to stop Plesk creating FTP accounts and remove existing FTP accounts

[Kroptokin]

Hi

I have noticed that for each new subscription I create Plesk automatically creates an FTP account. Further; I cannot delete this. (It seems the Remove button would allow me to delete additional FTP accounts but not the one added when the subscription was created).

I would like:

1) To delete these system created FTP accounts

2) To prevent it doing this in future. I would like to create subscriptions without FTP accounts.

I'd prefer to do it this way and leave the FTP server running. However; I am wondering about disabling FTP access altogether if I have to. I do use SFTP. I'm afraid my Linux knowledge is so limited I don't know if SFTP uses the FTP server; so if I turned off the ftp server whether that would prevent sftp access?

The motivation for doing this is that while I have 'customers' and subscribers in fact I am the only user and will transfer files to the server by SFTP and then move them around the server logged on via SSH. Since I'm not using FTP it seems sensible not to have all these accounts floating about.

Many thanks

--Justin Wyllie

 

[IgorG]

There is no separate FTP user on Plesk for Linux. There is a hosting system user, which owns the files and folders of the virtual host. Therefore hosting can not be created without creating a system user. And this system user has FTP access.
As possible workaround you can try to use UseFtpUsers option in /etc/proftpd.conf - http://www.proftpd.org/docs/directives/linked/config_ref_UseFtpUsers.html

 

[Kroptokin]

Thanks Igor

That works. On my system the file where the users (who may not have FTP access) is stored is /etc/ftpusers.rpmsave.

I had to restart the server to get this to take effect. I thought about just restarting the FTP server but I don't see it as a service in the Services Management page so couldn't do it that way.

However; I think I may go for the alternative solution. I have installed the Plesk Firewall extension and it also works just to deny FTP from there. (Though I may have to revert to your suggestion if that proves too extreme).

Many thanks

--Justin Wyllie

 

[Faris Raouf]

Be careful there!

Files ending in .rpmsave are backup versions of the actual configuration file being used (usually ending in .conf).
What happens is that the original .conf is replaced with a default one, while the original is renamed .rpmsave

Conversely, when the original file is NOT overwritten (whether it is overwritten or not depends on the specifications of the RPM in question), you will sometimes find a .rpmnew which is the default configuration for the application, with your original .conf file left untouched.

So editing a file with .rpmnew at the end should have absolutely no effect as the application will be looking for its configuration in a .conf file (or similar).
I'm therefore kind of puzzled that it worked for you

Regarding FTP, it is run through xinetd (have a look in /etc/xinetd.d/ ...) as opposed to a stand-alone mode. Depending on the application in question, no restart of the xinetd service is necessarily required for it to reload or reread a configuration file - in some cases it happens each time the application is started/called/used/whatever. But in those situations where a restart is required, all you need to do is a "service xinetd restart" to get it to read the new configuration.

 

[Kroptokin]

The ftpusers.rpmsave file change definitely worked. Maybe the program is looking for a file ftpusers.* ? There is no other ftpusers. anything file. Perhaps I should copy that to ftpusers.conf and make my edits there? I'd try that but....

Worse trouble though. After I run service xinetd retsart I can no longer gain FTP access with the accounts I have permitted (i.e. not put in that file). I get an error "cannot obtain directory listing ... timeout" . It looks like the FTP server has not restarted? How would I tell?

Thanks

--Justin Wyllie

 

[Faris Raouf]

The file should actually be /etc/ftpusers (no .conf or anything) according to the documentation. To my knowledge, it HAS to be that file name. Nothing else.

The link Igor posted says that proftpd will read the contents of /etc/ftpusers and will block any users in that file if the line "UseFtpUsers on" is found in /etc/proftpd.conf
(by default it is there already in most installations)

Check for errors in /var/log/messages and /var/log/secure to see what's happening or not happening when you restart xinetd.

Also use netstat to see what is listening on port 21 (or not)
Also use ps to see what processes are running

 

[Faris Raouf]

Umm...p.s. rather than fiddle around with configuration files that really should not be fiddled with, would it not be better to just close port 21 in the firewall? That will prevent anyone connecting via FTP and won't prevent you using SFTP which uses ssh port 22, although this port should be firewalled. They could still use FileManager in Plesk to upload files if they have full access to the control panel, however, so it isn't an ideal solution.

Incidentally, in /etc/xinetd.d/ftp_psa you'll see a line that says "disable = no". If you change that to "disable = yes" then the FTP server will not start with xinetd and ftp will be effectively disabled. HOWEVER, this file is automatically generated by Plesk, which means it can be recreated at any time (usually when you update Plesk) with all your changes gone, so this isn't a recommended solution and is one reason why Igor didn't suggest it. Plesk will also complain if it doesn't find proftpd running, so I don't know why I even mention it !!

 

[Kroptokin]

OK. You are right. I just tested again and putting a user name in ftpusers.rpmsave made no difference. Putting it in a file called ftpusers works as described by Igor. I must have got confused before. Thanks.

Thanks for the tip about netstat. I found this very useful: netstat -anp

I really am a beginner with Linux so this is all very useful. Thank you.

You have also given me another idea. Block all FTP access with the Firewall and allow my one user who wants to upload files himself to do so via his control panel. (I'm not planning to share control panels but this is a trusted user).

So. Anyway. Now I have all these options and have to make up my mind.

I take your point about blocking port 22. I guess I could block it for all except my IP. I'm on one which is assigned and changes from time to time but probably not that often.

Part of my confusion is that using the method of putting users in the ftpusers file seems to confuse my FTP client. Once it gets bounced off once it gets a bit moody and then won't work at all even when that user is now allowed again on the server. Until I reboot Windows. This totally confused me. The FTP client in the windows command prompt was not effected in this way.

Thanks for the info about ftp_psa. As you say it is not wise to edit files Plesk may change. My policy is to go 100% the 'Plesk way' (-:

Thanks again for all your help.

 

[Faris Raouf]

SSH port 22 might be considered the most dangerous port to leave unprotected. If the bad guys get in that way, especially as root, your server is toast.

Some options to consider if you don't have a static IP (and indeed if you DO have a static IP):
1) Change the port number to something else
2) Use keys instead of passwords. This is HIGHLY recommended. Puttygen (part of the putty package) lets you create a key very easily. Make sure your key has a password.
3) Disable direct logins as root. Basically you need to create an ordinary user who is allowed to login via ssh (ideally using a key). Once logged in as this user you can su - to root. The root user cannot login directly at all. You disable direct root logins in /etc/ssh/sshd.conf

But please be careful with all this! You can lock yourself out of your server if you aren't careful :-(


Combining 2 and 3, the bad guys would need the following to do significant damage:
a) Your SSH key
b) the password to that key
c) The username that uses that key
d) the root password

But if you can get your ISP to give you a static IP then by firewalling everybody except you out AND doing steps 2 and 3 and maybe 1, you are going to have a very secure SSH port.

Unfortunately, more often than not the main threat to a server's security will be the scripts you run (e.g. joomla, wordpress, whatever). If there's a vulnerability in something and the bad guys make use of it, again you are toast - or at least a little overdone anyway, depending on the vulnerability, the setup of the server and a mission and one other things

 

[Kroptokin]

Faris

Ok. I have generated a private/public key pair and am now logging in with my passphrase for an account 'x'. (And have prevented root ssh login by editing sshd_config).

But how do I disable ssh authentication with the password for account 'x'? It is still possible to authenticate this way.

And, sorry to trouble you for a theory class as well, but could you give me a really simple overview of what is happening when I authenticate with the private/public key method? My initial guess is something like: the passphrase has been signed with my private key. This is sent to the server. The server decrpyts this using the public key. That produces my passphrase. That is then tested against what I enter at the prompt? Or am I way off?


Thanks again. This is really appreciated.


--Justin

 

[Faris Raouf]

Trying to understand public key authentication will make your head explode. I do not recommend it. It is painful.

There are actually two things to change in /etc/ssh/sshd_config

Change:
PermitRootLogin yes
to
PermitRootLogin no

This will prevent direct root logins.

Next, change:
PasswordAuthentication yes
to
PasswordAuthentication no

This will prevent plain text passwords (e.g. for your non-root user) from working.

You need to restart sshd (service sshd restart) to have these changes come into effect.

TIP: Login, switch to root. Keep that ssh session open. Then make your changes, restart sshd and try logging in with a new session, keeping your first one open. In theiry, if you do something wrong and lock yourself out, your first session will remain open, allowing you to revert your changes.

But we are seriously just scratching the surface in terms of security. Your system is more likely going to be compromised via a vulnerability in a php script.
You might want to investigate a security product like http://www.atomicorp.com/products/asl.html

Regarding the key thing, I think basically the password/phase actually protects the private key, that's all. So if that private key gets into the wrong hands it will do no good without the password. It is not the password/phrase that is transferred or used to authenticate but rather the key.
It is usually recommended that you change your keys every few years.

 

[Kroptokin]

Thanks

I'm just about to take the plunge. Only have one account which has SSH access. That is not root. And it uses keys instead of passwords.

Only thing is I realise that once I've done this, if I lose the private key. That's it. No more SSH access. Ever.

How do people normally deal with this? I suppose people end up storing encrypted versions of their private key on various storage locations. I'm just wondering..

(And I take the point about WordPress etc. There are some basics you can do here in terms of defending against obvious attacks e.g. on the admin logon page which you prompted me to think about. All this makes me reflect that the point is: who are you defending against? Are you trying to prevent a casual attacker who's read up on some WordPress vulnerabilities or has downloaded some hacker program - or are you trying to defend against an organisation with the resources and reach of the NSA or GCHQ - or somewhere in between. Your security has to be good enough to stop the kind of attacker you intend to stop I suppose).

 

[Faris Raouf]

Make lots of copies of your key. Keep a copy on a USB stick. Keep a copy on your phone. Keep a copy on CD. On floppy. As long as it is protected by a passphrase, even if you lose track of a copy it won't do any real harm, especially if you don't keep a text file next to it saying "this is for server xyz"

You would still be able to login to the server with a keyboard/monitor attached to it (or a serial console). Your data centre will surely do that in an emergency, and edit sshd_conf for you, giving you back the normal password access.

But as for who's going to attack -- the situation is very, very serious these days. The bad guys use botnets consisting of millions of compromised PCs to execute brute force attacks and scan for and automatically compromise insecure installations. It isn't script kiddies you need to be afraid of - it is the crime syndicates who successfully make millions by compromising websites or servers and injecting drive-by download banking/keylogging Trojans and other malware into the pages being served.

Using a non-admin username for the admin in a WP site is great and will prevent 99% of those brute-force admin attacks. But one slip of a finger somewhere and insecure code can be released allowing a site or server to be compromised without the admin credentials. Remember that the vulnerability can be in a plug-in or a theme. In fact there was a serious vulnerability in one of the most commonly-used WP cache plugin very recently, if I remember correctly? And there was an issue with a version of TinyMCE which was used in a number of plugins. These are things that the bad guys scan for, day and night, using their botnets and other compromised servers. Keeping your installed code up to date as quickly as possible after an update is issues will prevent 99% of those attacks.

But you still have those 1% of attacks (or whatever the real figure might be -- I'm making the numbers up) so you cannot be too vigilant. It is a pain in the neck. Far worse than dealing with spam, I can tell you. If a spam message gets through (sent from the same botnets too), it is just annoying. If a site is compromised, it can be disastrous.

Yes, I'm probably erring on the side of caution and being dramatic. But that's my default mode of operation and so far it has kept our systems mostly safe. But the only really safe server is one that's not plugged in

 

[Kroptokin]

Hi

Thanks. I have taken some of these steps. And investigating whether my phone company will give me a static IP.

I take your point that attacks can be sophisticated and automated.

As far as packages go I will keep WordPress up to date. I had a client with Joomla 1.5 on my old server. I didn't move that onto my new server!

One thought: if I allowed FTP access would it not be possible for someone (myself or anyone who had obtained the FTP password) to logon via FTP and replace the authorized_keys file which exists under the home directory for the account with a new public key - to which, obviously, they would have the matching private key?

Thanks again

 

[Faris Raouf]

Your FTP users won't have shell access unless you specifically enabled shell access in Plesk for the account in question, which would be a bad thing to do. And no shell = no key file. Besides this, ftp should be limited to /var/www/vhosts/domain.tld/ -- I've just tested and I can't get any further up the directory tree than that with a normal FTP user.

 

[Kroptokin]

Thanks Faris.

Point taken that the ftp users won't have shell access.

I also like you tested the FTP and found that I could not get any further up the directory tree than /var/www/vhosts/domain.tld

However; my authorised_keys file is under this in .ssh/authorised_keys. The home folder for this user (cd ~ ) is /var/www/vhosts/domain.tld and the .ssh directory is under that.

It doesn't matter as I have turned off FTP access completely. I think I'm probably splitting hairs at this point.

Thanks for all your help.

 

[Faris Raouf]

OK, that's interesting.

This is going to be down to enabling Shell access via Plesk as opposed to at the command line. And yes, in this situation, if the user has FTP access then they can change the key (assuming it is owned by the user) so that would be bad!

For a normal user, keys would be placed in /home/<username>/.ssh
When I say "normal", I mean one created via "useradd" at the command line.

If you look at /etc/passwd you'll see the username, gtoups, path to their home directory and the shell they are allowed to use.
e.g.
username:x:123:123:username:/home/username:/bin/bash

And when you allow shell access within Plesk, because Plesk tries to limit what such users have access to, the path will be /var/www/vhosts/domain.tld/ where you'll find copies of certain binaries that the user is allowed access to, I think.

I'm a little vague on this I'm afraid as we never allow shell access to a Plesk user. But I'm reasonably sure I'm at least mostly right ;-)

 

[Kroptokin]

Thanks again Faris

However I have the same problem with a user created with useradd.

I created a user 'test'.

Then I create an authorized_keys file under /home/test/.ssh/authorized_keys

However; same problem. When I ftp in as 'test' I arrive in /home/test. In theory then I could ftp over-write the file /home/test/.ssh/authorized_keys with a new one (with a new public key for which I have the private key).

It looks like the answer is to train ProFTPD to make something other than the user's home directory the 'root'. On another server I had a typical user had a home directory /home/user but if I FTP'ed in with that user I would arrive under /var/www/vhosts/user/ (or something like that).

So it must be possible.


--Justin

 

[Faris Raouf]

OMG...right...that's awful. I didn't expect a user added in that way would automatically get FTP access. But it is "obvious" now that I think about it, and we then go back to what Igor said right at the start, with that ftpusers file

I have to admit I'm in a bit of shock here.

 

[Faris Raouf]

p.s. the home directory (as seen in /etc/passwd) is there the ftp root seems to go, so yes, you can change it.
(except that's won't help at all, because the ssh key has to go there...oh dear. It is nearly 3am my time. I'm going to go to bed. Hopefully when I wake up I will make sense instead of talking nonsense).