Time for a re-think of DA's install security defaults

[IT_Architect]

The insecure E-mail access problem has triggered other thoughts concerning the security defaults within DA. Over the past few years, the workplace moved from one's place of employment, to wherever one finds himself. A company's "technical" support people aren't often that technical. They are on call even when they are on vacation, while traveling, or at training to add E-mails, and check things out in the control panel. The reason for the rapid rise in the number of web sites that use Drupal and WordPress is so that these people and business owners themselves can manage the content of their own sites. It's not at all uncommon for these people to work on these items while "on the road". Secure control panel access during install has been the norm for other control panels for quite some time. All modern web development environments and operating systems support secure options for web site maintenance.

The purpose of a control panel is to make the server easier to manage servers. When a change in the way people work dictates we the need to implement something manually as a matter of course when setting up a server, it indicates it's time for that to become part of the core install. It would be better to start out secure and have the hosters loosen it up areas, than to start out loose, and rely on hosters to remember and have the knowledge to tighten them up. It's common for us to keep up on patches to guard against obscure security breaches that require substantial technical knowledge to exploit. We should all the more go after the huge and obvious ones, that require little technical knowledge to exploit, especially since they are the easiest ones to fix. We've recognized the world has changed, and our need to change with it.

In summary, I'm thankful of all of the features that DA has added and refined. Things like Brute Force Monitor, Daily E-mail Limits per DirectAdmin User, RBL blocking, and on and on. I love it. However, this is an area where kid who doesn't know much can download a packet sniffer to cause untold damage. I'm suggesting that we not make it quite that simple for people to compromise our server's security.

 

[DirectAdmin Support]

Hello,

Thanks for the mentioned guide to enable the changes.

We can open up discussion regarding changes to the defaults, and possible custombuild options to turn them on or off.

1) The main issue I would see if they're on by default is that many people won't know how to turn on the feature, causing more work for an Admin.
Although they'll be much more secure by enabling these features, it may not be desirable for the Admin to have such issue.

2) Since these options will make a server more secure, I'm all for giving an option to enable them.
Perhaps variables in the options.conf will be sufficient?

3) As for the issue of the default settings for these values, I'll leave that open for debate.
We'll need to balance the possible undesired effects from enabling them, to the undesired effects from not enabling them.
At this time, I'd be leaning towards on by default, but like many other features, we'd likely implement #2, off by default, and after people have been using them for long enough, we'd set them on by default.

Suggestions and thoughts are welcome.

John

 

[IT_Architect]

1. Just to have the means out of the box for an admin to enforce the secure communications makes the details pale in significance.

2. I have no problem with them being in the options file. To have them in the control panel is a nice touch, but perhaps the admin can make up an options file and simply copy it to the server, so there is nothing to remember to configure when he does an install.

3. For a new install, my vote would be for making secure communications the default. My logic is that if I'm going to open something up, I would want to be forced to be cognizant that I'm doing so, rather than an oversight. The workplace has been redefined. I've learned the hard way my only options are to adjust to the new reality, or get beat into submission by it. First it will be E-mail, then web developer access. From an admin's perspective, if I cut the dog's tail off inch at a time, I incur support issues at every step to help users change their client software. Loosening up from an secure install seems to be the trend, and it fits where things are going.

4. For existing, I can secure the control panel, web mail, and phpMyAdmin with no user impact. I plan to force E-mail and secure web developer access at the same time if I can come up with a way to secure that soon. I would like to see a discussion about the best way or most industry accepted way of implementing that as well.

Thank you for your consideration.

 

[nobaloney]

The problem with enforcing development secure access is, as I see it, that when doing so you also end up enabling ssh for all users, which in general we don't want to do.

Am I wrong?

Has anyone thought up a way to do it?

Jeff

 

[IT_Architect]

The problem with enforcing development secure access is, as I see it, that when doing so you also end up enabling ssh for all users, which in general we don't want to do. Am I wrong? Has anyone thought up a way to do it? Jeff

An SSH controlled by the FTP daemon. http://www.directadmin.com/forum/showthread.php?t=30607&page=1 Is that not good? WebDAV + RUID would be another. The only thing I haven't heard is people being able to get drive mapping to work with it. http://www.directadmin.com/forum/showthread.php?t=28155&page=2&highlight=WebDAV I'd like to know people's thoughts on this subject as well.

 

[nobaloney]

Might work, I'm not sure. I'd need to test it. Not sure I like it enough to test it, because it would mean all users would need to switch to it. Which could cause a support nightmare.

How do others think about this?

Jeff

 

[IT_Architect]

it would mean all users would need to switch to it. Which could cause a support nightmare.Jeff

For me, I would force all users to use it to avoid the security nightmare. By default, you could have both available from the same daemon by moving secure to say 21000. Personally, I don't see this any different than unsecured E-mail. Anybody working with Google, Yahoo, and Microsoft have been forced to use it for a long time. My fingers crossed approach just doesn't work in a work-from-anywhere world, and I might as well face up to it now before it costs me any more. Spamming is nothing compared to defacing or tearing out someone's web site, and no doubt the customer will hold me responsible, as he should, for making it possible. Then my defense is what, that I knew they were at risk, and I didn't take steps to prevent it? It's not something I look forward to, but I also don't see it as optional. Not for me, and quite frankly, not for anyone anymore. It's depending on a clientele of businesses that only do business within their 4 walls, and there aren't many of them anymore.

 

[IT_Architect]

My thoughts are:
1. Defaul to secure control panel access. It's already the defacto standard.
2. Default to secure E-mail. It has been the required by larger E-mail hosters for some time, and no shock to users or techs.
3. User controlled file access is what requires thought and effort.
- There is still a need for read-only public_ftp to distribute software, brochures, etc. (anonymous ftp)
- Web site maintenance needs to secure. The potential for damage is great. Web development environments have had built in support for it for years.
- SFTP is frequently a requirement for exchanging files between customers and vendors due to confidentiality agreements, and to protect the integrity of the files exchanged. Consider what a malicious change to a CAD file could cost.
- I would recommend making the default secure any time credentials used. (ftp virtual users) The DA admin could elect to disable the secure access requirement for virtual users, but it would require a conscious decision to accept the risks.
- A lot of business happens at the coffee shop and public hot spots. People need to have a secure way to work. Most are unaware of their risk because they can't imagine we would provide them a service that allows anybody to have easy access to their user name and password.
- Implementing SFTP requires DA's assistance because it requires adding some additional entries during their maintenance of the virtual users.

 

[nobaloney]

- Web site maintenance needs to secure. The potential for damage is great. Web development environments have had built in support for it for years.

I'm not an expert in website maintenance and I don't use these products. Others of us, as server administrators, may be in the same situation. Please, if you can, suggest specific secure access methods which won't require us to turn ssh access on for all users, but will work for site development software.

Is it possible to minimize shell access yet allow updates by using a default shell which doesn't allow direct login but will still allow secure file uploads? If so, do you know of one?

Thanks.

Jeff

 

[IT_Architect]

I'm not an expert in website maintenance and I don't use these products. Others of us, as server administrators, may be in the same situation. Please, if you can, suggest specific secure access methods which won't require us to turn ssh access on for all users, but will work for site development software. Is it possible to minimize shell access yet allow updates by using a default shell which doesn't allow direct login but will still allow secure file uploads? If so, do you know of one? Thanks. Jeff

The Technologies:
- WebDAV is what most users would prefer. All major operating systems see WebDAV shares natively as a type of filesystem, and thus maintain files is a simple drag-and-drop affair using the operating system's native commands and graphical file managers. It relies on the operating system for security. However, I'm having a problem envisioning using it is in a shared hosting environment. I can see it working down to the user level, but that doesn't give is the granularity of virtual users we require, and now have with ftp users.
- FTPS is simply FTP over TLS. The problem with that is, due to the odd nature of FTP opening random data ports, the only thing that ends up ecrypted is the control channel, meaning it's not secure, and a waste of effort to implement, no matter how easy it is to do.
- SFTP is a network protocol that provides file access, file transfer, and file management functionality, and is an extension of SSH version 2. It is supported all web development programs, all well known FTP clients support it. This would work fine in a shared hosting environment.
- mod_sftp for ProFTPd supports the SFTP and SCP file transfer protocols of SSH, but it does NOT support shell access, which is a good thing.
- SSH itself doesn't provide any authentication and security. That is performed by sshd and administered by DirectAdmin.
- FTP itself doesn't provide any authentication and security. That is done by ProFTPd and administered by DirectAdmin. The virtual user security coordination is already in place for FTP users. ProFTPd simultaneously handles SFTP. I don't intend to minimize the work involved since SFTP is unrelated to FTP, but there are examples of on this forum of people implementing it manually, and it appears what is missing is for DA to add a check box to enable SFTP, and to leverage the virtual user information to maintain the SFTP as they currently do with FTP.

Proposed Strategy:
- There are 3 types of FTP users our customers have;
1. anonymous, for their publicly distributed files
2. Customers and vendors with whom they exchange files
3. Web developers
- For number 1, anonymous FTP is separate from the FTP virtual users we define in DA. It should continued to use FTP.
- For number 2, secure access is often a contractual requirement, and always makes sense. I already mentioned the incredible expense that a maliciously modified CAD file could cause, and the certain recovery of damages suit that would follow. For us to get pulled into something like that on the basis is negligence doesn't require a lot of imagination. It has more potential than your credit card information published on hack site. This should be SFTP by default.
- Number 3 requires no elaboration as to what will happen when a hacker gains web developer access. This should be SFTP by default.
- What I'm proposing is that the default be SFTP for the user and virtual FTP users, with the ability for the admin to disable that requirement in order to duplicate the same behavior we currently have.

Technicalities:
- FTP by default listens on 21, uses 20 for data, and has a default ephemeral port range of 49152–65535, and of course completely insecure.
- SSH by default runs on port 22. If we were to implement mod_sftp for ProFTPd at its default, both sshd and ProFTPd would be on the same port.
- The default port for most SFTP clients is 22, so I believe it makes the most sense to move sshd. My reasoning is that it is common practice already to move sshd off the standard SSH port, and individuals given shell access are technical users. 220 and 2200 are taken, but 22000 is not, and it's outside of the default FTP ephemeral range.

Managing the Change
Managing the change is probably bigger in my mind than it actually is. You haven't been able to get unencrypted E-mail from any major E-mail provider in years. Users are as accustomed to secure E-mail. For SFTP, many corporate users are using FileZilla because it just works without requiring a degree in computer mysteries, it maintains their locations and credentials, and it's free.

Summary:
I consider myself lucky that it was a non-technical E-mail user that resulted in a server getting blocked. In that short time I had people using that account from Mexico, Brazil, Australia, and China. After changing the password, they tried for 3 days to get variations to the original password to work. Tracking down sources of spam from hacked e-mail accounts, vulnerable PHP forms, and writing corrective action responses will ruin a whole day, and put you in the dog house with web hosting customers. However, 2 has the potential to change your life, and 3 has the potential to get you top rankings in Google searches for security breaches for both your web hosting company and DA. The only way to top our current risk is to go back to Telnet for remote console. I believe it is safe to say most of you guys have more hosting customers than I, and it happened to me. Forcing secure access is not something I want to do. However, the work place has been redefined without our permission, and so must our security methods to maintain our risks at responsible levels.

 

[DirectAdmin Support]

Thanks for this information.

Looking at mod_sftp, it doesn't look very difficult to implement into the current proftpd setup.
As for using port 22 for sftp to replace sshd, we'd leave up to the server admin to decide.. but we'd still need a default port for it, other than 22.
23? Nobody uses telnet anyway.

We could offer an option to set the sftp port during the config (to 22 if desired) but the changing of the sshd port would be out of the scope of what custombuild should be doing (in case a firewall doesn't have the new port open).
Basically, we don't want to make it easy to lock yourself out.

WebDAV was looked at in the past, but dropped because apache runs as apache, which didn't work out.
With mod_ruid2 with custombuild 2.0, there may be a possible revival, but I'm still opposed to using apache as a primary uploader (perhaps Frontpage ruined it for me)

John

 

[IT_Architect]

...but we'd still need a default port for it....23? Nobody uses telnet anyway.

That's an AWESOME idea. Put ProFTPd SFTP on 22 because every SFTP and SCP client in the world expects it to be there, and put sshd on 23 since SSH is Telnet's secure replacement, and a lot of the time people have to tell you where they hid the SSH port anyway.

...We could offer an option to set the sftp port during the config (to 22 if desired) but the changing of the sshd port would be out of the scope of what custombuild should be doing (in case a firewall doesn't have the new port open). Basically, we don't want to make it easy to lock yourself out.

I agree 100%.

...WebDAV was looked at in the past, but dropped because apache runs as apache, which didn't work out. With mod_ruid2 with custombuild 2.0,

I used to see this as WebDAV as being the goal, and mod_ruid2 as being a module needed to get there. Now I see mod_ruid2 as the only clean way to provide security to the Apache modules stack without compromising its performance, reliability, and flexibility, and WebDAV as a footnote.

there may be a possible revival, but I'm still opposed to using apache as a primary uploader (perhaps Frontpage ruined it for me)

The nice aspect of WebDAV is it is secure, fast, and doesn't need a client, because it's built into every OS. You simply map a drive. However, there is no expectation on the part of developers to find WebDAV in a shared hosting environment, Windows or ?NIX, while SFTP is the expectation. There are reasons for that. WebDAV runs at the OS user level. From our customer's perspective, they would have to give a web developer, perhaps someone they don't even know, their credentials. You would have the same problem with customers and vendors exchanging files, and no way to give each customer's customer or vendor their own private area. In a shared hosting environment, the only one that could practically use it is a user who maintains his own web site. cPanel 11 added it and call it "Web Disks", and it's not on by default. SFTP solves all of the problems. WebDAV can much more elegantly solve one of the problems.

I'd wager you'll add WebDAV after you get SFTP and mod_ruid2 in place only because it would be so simple to do at that point. LOL! However, the only real duck in the pond having a way for people to work from anywhere without getting their credentials scammed, and the only technology that can fulfill the requirement for our customers, their secure ftp sites, and when they work with their web developers, is SFTP. The fact that it's easy to implement is simply a bonus.

Thanks!

 

[Richard G]

Looking at mod_sftp, it doesn't look very difficult to implement into the current proftpd setup.

Don't forget pure-ftpd which we also have in Directadmin

That's an AWESOME idea. Put ProFTPd SFTP on 22 because every SFTP and SCP client in the world expects it to be there, and put sshd on 23 since SSH is Telnet's secure replacement, and a lot of the time people have to tell you where they hid the SSH port anyway.

An awesome bad idea imho because SSH is by every client in the world expected to be on port 22.
Next to that, numerous portscans, probes and whatever is being done at port 22. This is why we for example move our ssh to another port. A telnet server is not being used if everything is oke, but telnet clients are. But those don't use port 23 as far as I know.
However I find it a bad idea to move to a port which is commonly still reserved as telnet port (isn't that in some RFC?). Next to that, some times we have to put it back to port 22 as some support peaple (f.e. those from softaculous) don't seem to be able to enter when it's on port 50.000 or so.
Look at this:
http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xml

Why not use port 26, because it's an unassigned port fot those special things? Or leave it where it is. If scp is expecting it on port 22, surely SSH is expecting it there years longer.

By the way, we don't want any of our users have SSH access. We do have mod_ruid running.
We shouldn't change standards by default just for security reasons. Let the admin decide.

 

[IT_Architect]

An awesome bad idea imho because SSH is by every client in the world expected to be on port 22.

SFTP is SSH. That's why it's the default port for SFTP in clients. SFTP and SCP are part of the protocol. We were talking about where to have sshd listen, which supports the full protocol, including terminal operations. Since Telnet/23 was SSH's secure predecessor for terminal operations, I thought it was a pretty cool idea. Half the guys are going to move it into the stratosphere somewhere anyway. DA just needs a good default.

...still reserved as telnet port (isn't that in some RFC?)

It's in the IANA port list. 26 may be unassigned, but the bottom 1024 are known as the "well known" ports and unassigned and are kinda reserved. The list is simply a coordination point to bring order from chaos so you don't build a product that is commonly used for something else. People that use SSH are technical people anyway, so moving it from port 22 won't throw off anybody. People who use SFTP usually are not tech savy.

We do have mod_ruid running. We shouldn't change standards by default just for security reasons. Let the admin decide.

I don't understand all of that, but we're talking defaults for install, not changes custombuild would make.

 

[DirectAdmin Support]

Just in case I wasn't clear, custombuild will not touch /etc/ssh/sshd_config. If sshd is already on 22, DA won't touch that.
I was referring to 23 as the default mod_sftp port.. or 26.. doesn't matter.

If the admin would like sshd on some other port, that's totally fine, but up to the admin, for them to do manually themselves. (can be done before the DA install, or whenever they'd like).

However, we can have custombuild look at the /etc/ssh/sshd_config port value... if it's set to something other than 22, then we could set mod_sftp 22.
If 22 is being used by sshd, then it would have to default to something else (eg: 23, or 26, etc..)

John

 

[IT_Architect]

Perfect! When can we test? LOL!

 

[Richard G]

but the bottom 1024 are known as the "well known" ports and unassigned and are kinda reserved.

That's not different for port 22 and 23 as far as the well know goes. Unassigned is not used, just reserved. Like 23 would be when telnet would not be used anymore.

I don't understand all of that, but we're talking defaults for install, not changes custombuild would make.

I'm also talking about defaults for install. That's why I'm saying that for several idea's, it's better to see if it can be done a better way. For example let the admin decide how to put it by configuring it in custombuilds options.conf and keep the default installation default as all OS systems do, so with SSH on port 22 and not on the telnet port 23.
The idea of more security is good, but not the idea of changing by default a worldwide used port (port 22) for other purposes.

was referring to 23 as the default mod_sftp port

Yes, but IT_Architect was referring to port 23 as default SSH port as far as I could read. If it's for mod_sftp well... in that case port 23 of 26 would be fine. But keep of the standard much used ports like 20, 21, and 22.

However, we can have custombuild look at the /etc/ssh/sshd_config port value... if it's set to something other than 22, then we could set mod_sftp 22.
If 22 is being used by sshd, then it would have to default to something else (eg: 23, or 26, etc..)

That might also be a good idea. Hopefully this can be done with pure-ftpd too.

 

[ditto]

John, please don't do this. It will be a mess. We already offer shell access to all clients (its "safe" with SAG and suPHP etc), and is using default port 22. So clients use real SFTP on port 22.

We don't like any "fake" SFTP on the extra FTP accounts that can be created, and we don't want to tell clients that for main account shell and SFTP is on port 22, but on all other ftp accounts clients create, SFTP is on eg: port 23 - that is confusing for them and hard to remember - a mess!

It would be much better to use ftp over tls for those extra ftp accounts, or the absolute best would be if you implement it so that all extra ftp accounts can be ssh enabled, then we would be able to offer shell and real sftp on any extra ssh/ftp user accounts created, not only on the main default account.

Conclusion: I don't want "fake" SFTP. I don't want SFTP on a non-standard port. I don't want to confuse my clients with SSH and SFTP for main account on port 22, but SFTP on all extra accounts on PORT 23!

If DirectAdmin could implement option to enable SSH for all ftp only accounts (not only on main default user account), that would be great! Then we could offer clients real SSH/SFTP on all the accounts they create.

 

[DirectAdmin Support]

Don't worry ditto, if it's implemented, it will all be options in the custombuild option.conf. You won't need to change anything if you don't want to.

From IT_Architect's comment:

- FTPS is simply FTP over TLS. The problem with that is, due to the odd nature of FTP opening random data ports, the only thing that ends up ecrypted is the control channel, meaning it's not secure, and a waste of effort to implement, no matter how easy it is to do.

With FTPS, we know that the control channel (username/password) is secure.. However, I'm curious about your comment that the data channel not being secure. From a few quick googles, I wasn't able to find anything that says the data channel cannot be secured, only that it's optionally secured. Are you able to elaborate on this for us?

On a side-note, I've already got sftp working with proftpd on a test box. It does need a few weird proftpd.conf changes (setting "Port 0", adding Port 21 into a 0.0.0.0 VH) to make it bind to all IPs, but nothing drastic.
Worst case, I'll just write up a how-to guide.

John

 

[DirectAdmin Support]

I've added this how-to guide for anyone who wishes to try out mod_sftp. No changes have been made to custombuild yet... and we'll decide on that later.
For now, people can test out sftp to see what they think.

Note that the implementation I used does not change proftpd on 21, that will remain unaffected.
It uses sftp on port 23, which can be changed in the /etc/proftpd.sftp.conf, as desired.

http://help.directadmin.com/item.php?id=439

John