Strange SFTP problem...

[Dan_EZPZ]

Hey folks,

I have SSH disabled for a reseller, but they can still login to SFTP. Furthermore it is not jailed correctly and they can browse the whole server apart from other users directories.

For example, they can browse /etc but cannot open files. This is causing alot of support tickets from clients worried about server security.

Surely if SSH is disabled, then SFTP should be disabled too? Secondly, shouldn't the user just be jailed to their own home directory and not even be able to browse anywhere else?

Dan

[mealto]

When Jailed Shell has been disabled, SSH is not allowed but sure enough, SFTP still is. And the user can go up in the directory all the way to the root level. Is there a way to jail SFTP sessions to only the account level like in normal FTP?

[cPanelDavidG]

When Jailed Shell has been disabled, SSH is not allowed but sure enough, SFTP still is. And the user can go up in the directory all the way to the root level. Is there a way to jail SFTP sessions to only the account level like in normal FTP?

SFTP relies on shell access.

Being able to see (but not modify) files outside your directory is an artifact of using a Unix-based system. If you wish for your users not to use this, you may encourage them to use FTPS instead of SFTP.

[Dan_EZPZ]

That doesn't help my problem.

I have SSH disabled for users, its not even set to jailed, but they can still login to SFTP?

I don't want to allow SFTP at all, asking them not to use it is not a fix.

[mealto]

That doesn't help my problem.

I have SSH disabled for users, its not even set to jailed, but they can still login to SFTP?

I don't want to allow SFTP at all, asking them not to use it is not a fix.

I can verify this. When we SSH in, the server returns a warning that SSH is not enabled for this account but using the same user ID + PW works for SFTP. Is this a glitch? But if the users cannot alter other files outside of home as David mentioned, maybe that is still ok since it would be similar to FTP'ing in?

[sparek-3]

SFTP support was added to the /usr/local/cpanel/bin/noshell shell some time back, maybe in cPanel 11's initial release.

The noshell shell still does not allow a shell prompt, it just allows the SFTP subsystem to work.

I don't know of a way to change this. The noshell shell is maintained by cPanel. You can switch a user's shell to /bin/false and then they will not have SSH access or SFTP access.

I believe this was added to noshell because a lot of users wanted to offer SFTP without SSH access.

I would recommend using FTPeS. There needs to be a more secure FTP protocol that does not rely on SSH. This SFTP solution will not work if you firewall off SSH access on your server. FTPeS will encrypt the login information when a user logs in so that it is not sent in plain text. However files themselves are not encrypted when they are transferred.

[Dan_EZPZ]

You can switch a user's shell to /bin/false and then they will not have SSH access or SFTP access.

How do you do this?

[sparek-3]

From root's shell type:

usermod -s /bin/false username

Where username is the username you want to change.

Never use root as the username in this example. If you do, this will lock you out of your server.

You may want to make sure that /bin/false actually exists on the server first, though I think it is present in almost all Linux distributions (BSDs I'm not too sure about).

ls -al /bin/false

[Dan_EZPZ]

Thanks - that seems to have done it.

However, it'd be good to have cPanel fix this issue...

[mealto]

I would recommend using FTPeS. There needs to be a more secure FTP protocol that does not rely on SSH. This SFTP solution will not work if you firewall off SSH access on your server. FTPeS will encrypt the login information when a user logs in so that it is not sent in plain text. However files themselves are not encrypted when they are transferred.

Sparek, looks like your solution works. How would one reverse it in the future?

Also, the reason for turning off FTP is to make it so FTP hack attempts have no chance of guessing the right combo's since no FTP service is running. In theory, no FTP hack attempts will succeed.

1. What would login encryption protect against? Password sniffing?

2. So would FTPeS offer the same protection as going with SFTP instead of normal FTP in the above scenario?

[sparek-3]

You should be able to use the WHM's shell enable/disable to enable or disable shell for an account.

You can use usermod to specify a shell. The argument after -s just gives the full path to the shell you want that username to have. So using:

usermod -s /usr/local/cpanel/bin/noshell username

will give username the noshell shell (which still provides SFTP).

If FTP is disabled and only SFTP is used, then users could still bruteforce against SFTP to guess passwords. A lot of firewalls or log monitors will detect SSH brute force attempts, but you can also find one that does FTP log brute force monitoring (chirpy's CSF comes to mind).

SFTP encrypts the entire connection. If you send a plain text file via SFTP then sniffers on the network will not be able to read that text. FTPeS (FTP over explicit TLS) will only encrypt the FTP connection where the FTP server prompts for the FTP username and password. Sniffers would not be able to read that information. But if you upload an HTML file via FTPeS then sniffers on the network could still read that text as it pass across the wire.

SFTP is more secure. I won't doubt that. The main problem I have with SFTP is that it relies on SSH. There should be a secure means for transferring files that does not rely on the SSH protocol. The issue with SFTP comes about when a hosting companies firewalls off SSH access on their servers. This is something that I do, so that regardless of what shell a particular user has, the SSH port is closed off except for a very few IPs. I can't give SFTP access to an account without whitelisting their IP or IP range.

Generally, you don't have to worry about sniffers finding anything potentially dangerous across an FTP transaction. If you are uploading a PHP script that contains a MySQL username and password combination or password to some area of your website, then potentially a sniffer could read this over FTP or FTPeS and attain that information. However if you are just uploading an HTML page that says Hello World in big bold letters, it really doesn't matter if sniffers read that or not.

[mealto]

I see. Thanks for sharing your experience in this area. It is always helpful to hear from others who are practicing things on a day to day basis.

We are considering disabling FTP entirely since 99% of our brute force detection have been users tracking to hack FTP. So does it sound right that for a server that only has a few users logging in, we can safely disable FTP in WHM, change the default SSH port to something else and run SFTP exclusively? This should, in theory, lessen the liability of FTP or SFTP hacks gaining access correct?

[sparek-3]

If you are getting hit by brute force attacks then generally this goes back to having weak passwords. I would go to the source of the problem and insure that users are using strong passwords. If you only have a handful of users on the server then I might consider changing the passwords for all of the accounts and enabling the Password Strength option in the Security Center in the WHM. Pick a value that is high enough to insure that users pick a strong password. Then as users contact you concerning their account passwords, make sure that they know that they need to log into their control panel and update their password. With the Password Strength enabled, this will insure that they use a strong(er) password.

If you don't have any brute force detection system in place for SSH, then you will still be susceptible to brute forcing attempts with SFTP. Albeit, if you run SSH on a non-standard port, this becomes less unlikely, but you could also just as easily change the port for regular FTP.

If you do switch to an SFTP only set up, you can further improve security by implementing a public/private key only access to SSH. This way in order for users to access SSH or SFTP they would have to have the right private key to match up with the public key on their account. This would more than likely eliminate any successful brute force attempts on your server whether it be with SSH or SFTP, even if the passphrase is weak. However, it won't exclude you from a cPanel based brute force attack.

All in all, if you are comfortable with leaving the SSH port open (even if it is non-standard) and if you believe that your users can understand how to use SFTP, then you are probably alright switching to only SFTP. The more users you have on the server the more problematic switching to SFTP only can be.