This document compares the following remote access options: FTP, AFP volume, SMB/CIFS volume, WebDAV, Xinet WebNative, HELIOS WebShare and SSH FTP. There are more file transfer solutions available but this security document focuses on the listed solutions.
How WebShare secure authentication works
Authentication
Authentication means the login process, the table explains how the login password data is transferred over the network.
| Service | Password Transfer | Comment | ||||
 |
FTP | Cleartext | ||||
 |
AFP volume | Crypted | With random number for server | |||
|
SMB/CIFS volume | Crypted | With random number for server | |||
|
WebDAV | Crypted | ||||
|
Xinet WebNative | Cleartext | Cleartext as base64 in every packet to the server until the browser quits | |||
|
HELIOS WebShare | Crypted | With random number for server | |||
|
SSH FTP | Crypted | Public/private keys | |||
When password data is transferred in cleartext or base64, a simple "tcpdump" command within the same network will show the ASCII password. In case of an Apache Basic "htpasswd" authentication, the browser will include the cleartext password in every HTTP request throughout the session, which means that somebody can spy out passwords anytime within the same network. More information can be found at:
http://www.lists.aldigital.co.uk/apache-ssl/msg00146.html
http://httpd.apache.org/docs/howto/auth.html#basic
By default secure passwords are used via SSH FTP, AFP or SMB/CIFS volumes and HELIOS WebShare.
HELIOS WebShare uses JavaScript to encrypt passwords. Password encryption is the only place where JavaScript is used by WebShare. If JavaScript is unavailable, the login password is not encrypted.
How WebShare secure authentication works
During the WebShare login, the server sends a random number with the login page to the client. A JavaScript running in the browser computes an MD-5 hash code, using the clear text password and the random number. The same calculation is done on the server, logging in is only permitted if the received client MD-5 hash is identical with the server MD-5 hash.
The random number ensures that the transfered MD-5 hash is different with every login and cannot be reused a second time. There is no way to capture a valid password on the Internet, Intranet or on the WebShare WebObjects Server.
The WebShare authentication is even better than HTTPS-encrypted HTML forms because anyone can setup an HTTPS server with a valid certificate, to capture the clear text forms after the HTTPS decryption is done.
File access security
The following table explains how the access to server data is secured.
| Service | Security used | Comment | ||||
|
FTP | Enforced file system security by host | UserID/permissions of the login user is used | |||
|
AFP via Apple File Server |
Weak security by File Server | Apple AFP server always runs as "root"! | |||
|
AFP via HELIOS EtherShare |
Enforced file system security by host | UserID/permissions of the login user is used | |||
|
SMB/CIFS volume | Enforced file system security by host | UserID/permissions of the login user is used | |||
|
WebDAV | Custom security by HTTP Server | ||||
|
Xinet WebNative | Weak security by WebNative CGI-programs | All WebNative applications always run as "root" (Administrator) | |||
|
HELIOS WebShare | Enforced file system security by host | WebShare File Server runs under the UserID/permissions of the login user | |||
"Weak security", used by WebNative CGI-programs and the Apple AFP server is unsecure because it bypasses the operating system file security and process security. Custom auditing of different users is impossible because all activities are done as user "root" (Administrator).
HELIOS WebShare uses the host file system and process security. The optional "Always allow reading" or "Always allow read/write" option bypasses the host security and is not recommended.
Note: This option can only be turned on via an extra preference!
File Server security
Direct File Server access from the Internet should be avoided. The following services require the main file servers (hosts) to be directly connected to the Internet: (E.g. via the HTTP, FTP, or AFP TCP/IP communication / TCP/IP ports)
- FTP
- AFP volume-SMB/CIFS volume
- WebDAV
- Xinet WebNative
- SSH FTP
All Web CGI-based solutions, e.g. Xinet WebNative, which calls CGI-applications for each request, put enormous traffic on the main server. This simple example script simulates external HTTP requests, similar to when a user frequently clicks "update", and will completely slowdown every CGI-based server solution:
Bash shell script using the "wget" or "curl" command
while true do curl --stderr - "http://www.samplehost.com/..." > /dev/null done # end of script
Why a firewall is not sufficient for security
When a firewall is configured, the first procedure is to open ports to allow access for required services. That means that for the services listed above, that require direct file server access from the Internet, the relevant HTTP, FTP, AFP, or SMB TCP/IP communication ports must be opened up! This allows direct access from the Internet, and makes the file server vulnerable to a broad range of attacks - whether from captured passwords, exploits of protocol vulnerabilities, viruses on remote VPN clients, etc. With WebShare, even if attacks are passed through the firewall, the two-tier server architecture isolates the file server, and breaks the chain of communication, so that malicious code cannot get through.
Solutions that isolate the file server from the Internet network
Only the HELIOS WebShare File Server does not use any direct Internet communication. A separate WebShare WebObjects Server runs the WebShare Java application. All Internet communication will only be handled by the dedicated WebShare Java application. There is no direct access or packet tunneling to the main file server when using HELIOS WebShare.
This means that a Denial of Service attack will bring down all file servers except for HELIOS WebShare, which handles all the Internet traffic on a dedicated WebShare WebObjects Server without affecting the main file server.
Why a proxy server can leave your internal network vulnerable
A Proxy Server can have two primary purposes:
- Enhance Web performance by caching pages, and
- Allow direct Internet access from behind a firewall
Note that a proxy server merely redirects Internet traffic through your firewall; while it can block other traffic, the traffic that it does pass through is unmodified, and hence leaves your client workstations vulnerable, e.g. to web browser exploits.
The two-tier WebShare architecture does not redirect or tunnel Internet data. Instead, the WebShare WebObjects server handles all Web traffic, and uses a completely different protocol (the private HELIOS filing protocol), to communicate with the WebShare File Server.
WebShare file transfers vs. VPNs
Remote file sharing and file management is often accomplished via a VPN (Virtual Private Network). However, there are many problems with VPNs. File sharing via VPNs is slow due to WAN bandwidth limits and packet delays, and due to the heavy network traffic caused by Windows or Mac user interfaces. A simple click (e.g. on an "Open File" dialog) can easily generate several thousand network file packets. By extending the network, VPNs also extend susceptibility to the "weakest link" problem - if one remote user is compromised, a virus or other intruder is into the network.
HELIOS WebShare, on the other hand, uses a two-tier server architecture, so that files can be managed and transferred without allowing direct access. This is not a proxy server or similar solution that merely reroutes packets. Instead, WebShare allows remote users, using any web browser, to transfer and manage files on a host server, in a much faster and more secure manner.
Data transfer security
The transferred data is not encrypted when using FTP, AFP, SMB/CIFS, WEBDAV, Xinet WebNative and HELIOS WebShare. This means spying out the content of the data being transferred is very easy using the "tcpdump" command. However, reassembling the downloaded archive into a valid archive, e.g. a Zip or StuffIt archive is very complex and cannot be done using standard tools. However, it is possible with specialized tools and a deep knowledge of networking protocols and file formats. Only SSH FTP or HTTPS encryption crypts all data being transferred. Optional HTTPS/SSL data stream encryption can be used for Xinet WebNative and HELIOS WebShare, this is possible via the Apache SSL support. All default installations of these products are installed without HTTPS support. The disadvantage of HTTPS is that this causes a major slowdown of downloads and of the Web server, due to its intensive encryption of every packet. Because the WebShare WebObjects server is separate from the WebShare file server, use of HTTPS will not slow down applications and local users on the file server. In the case of Xinet WebNative, all server users and applications are slowed by use of HTTPS.
File system browsing security
FTP, AFP, SMB/CIFS, WebDAV, Xinet WebNative, HELIOS WebShare and SSH FTP allow for browsing files and directories.
The disadvantage for remote AFP and SMB/CIFS volumes is:
- Users can browse within the complete volume; users cannot be restricted to specified folders only.
The disadvantage for FTP and SSH FTP is:
- Users can browse the complete server without being restricted to a specified folder
- Some FTP servers allow specifying a "chroot" directory for FTP users. ("chroot" only supports one folder)
Only Xinet WebNative and HELIOS WebShare allow specifying folders which should be accessible for a given user or group.
Conclusion
Due to its two-tier server design, HELIOS WebShare is the only Internet remote file access method that excels in extremely secure data transfers, while being easy to install, administer and use. In addition, it is one of today's fastest real time Internet remote file access applications, as can be seen here.
Glossary
AFP
AFP is the acronym for Apple File Protocol and means in this context mounting/using AFP volumes via the "Chooser" (Mac OS 9), or via the "Connect to Server" dialog (Mac OS X).
SMB/CIFS
SMB/CIFS is the standard protocol for Windows server volumes to be accessed over the network by Windows clients.
This document is subject to change. Last updated January 28, 2004
All trademarks used in this document belong to their respective owners.