John's Blog: Q and A
March 12, 2017
I get hundreds of questions a month at "support@maxum.com". Most are pretty specific to a particular network or situation, but I've had a few lately that are straightforward and should probably be answered more directly in the Rumpus documentation. So consider these added to the FAQ...
Why is there an "ANONYMOUS" user account listed in my users list? I didn't create it, and am concerned it may be an indication of a security problem.
The Anonymous account is special, and is maintained for a specific purpose in Rumpus.
It's genesis goes back to earlier days of the Internet, when FTP site administrators would share files publicly on their servers. Anonymous FTP basically allows your file sharing server to serve dual purposes: as a method of storing secure information for authenticated users, but also as a way of sharing general information with the public. The concept of "Anonymous FTP" is seldom used any more, as public-facing file sharing is primarily carried out on the Web (and has been for a while).
Rumpus does continue to support Anonymous FTP, though, through the ANONYMOUS user account. For those who don't require a publicly accessible FTP service, just make sure the "Permit Login" privilege is turned off for the ANONYMOUS account. With that privilege disabled, the account is disabled entirely and has no ill effect on server security or operation.
Can we use TeamViewer (or similar) to go over a problem, or can I speak to you on the phone?
Maxum offers technical support via e-mail only, for a few reasons. First, in many cases, the answer to a question is simply a link to an on-line resource in the form of documentation, as a screencast, or on-line article. Providing a pointer to these resources saves me time, sure, but more importantly, the information is generally better presented than I would be able to do on a case by case basis.
On the other hand, the answer to many other questions requires more detailed diagnostics or research on my part. In these cases, e-mail is best because it gives me a chance to take the time needed to fully review what is happening and formulate a good answer.
Communicating via e-mail also avoids scheduling teleconferences, doesn't require that everyone involved be in their office, and provides a written record of the answer or instructions for long-term reference. So, if you need help, send me an e-mail, and be as detailed as possible in your question. Even when a phone call might seem more convenient, I'll always do my best to get back to you promptly via e-mail.
Our Rumpus server was audited by a server security testing service (such as Qualys SSL Labs) and received a poor grade. How can we improve the report card for our server?
First of all, as I've documented in the past, I am not a huge fan of these services. For an overview of the important steps to maintaining a secure server, see the "Server Security" article in the Rumpus package. The steps described there are far more important, I believe, than whether or not your server is susceptible to the types of exploits usually tested for by automated services. For example, don't be lulled into a false sense of security by an "A" security rating when you have a Rumpus user account named "Admin" with a password of "p@ssword".
With that said, Rumpus 8.1 includes important SSL/TLS updates that will improve your scores on these tests, and is an essential upgrade if strong encryption is important for the security of your server. Note that in Rumpus 8.1, Rumpus no longer relies on the OpenSSL build that comes on your Mac server (OpenSSL has always been built into Rumpus for Windows), and the specific version of OpenSSL in use is displayed on the Network Settings window, Secure Services tab.
Also on that tab, you can enable or disable SSLv3, TLSv1, TLSv1.1 and TLS Compression.
When an SSL connection is made, the client and server agree upon the specifics of how the data will be encrypted during the session. There is a "negotiation" that goes on which takes a number of factors into consideration, but the two sides will normally agree on the most secure mechanism supported by both client and server. So, for example, if both client and server support TLSv1.2, that should be the mechanism used.
An older client may only support TLSv1.1, TLSv1 or even SSLv3, in which case the server will "downgrade" the connection so that the two sides can communicate. However, these older protocols have known technical flaws that could allow the data transferred to be sniffed or compromised. (It's worth noting that even SSLv3 connections are far more secure than plain, unencrypted data connections.)
By disabling these older protocols, your server will be inaccessible to these older clients that don't support the more modern versions of SSL/TLS. This increases security of the data by preventing these older clients from connecting and potentially being compromised.
So, disabling SSLv3, TLSv1, TLSv1.1 and compression may limit the compatibility of your server with some (mainly older) clients, but will ultimately increase the security of the service. And it'll definitely improve your security test scores.
