10 WebShare security

10.1 Security considerations

10.1.1 WebShare Web Server

HELIOS WebShare’s security is provided by a two-tier server application. The WebShare Web Server handles the web user interface on a separate server to ensure that the main file server is not accessible from the internet. In addition, SSL encryption is supported.

Port

Incoming HTTP port is 2009.

JavaScript

During the login process, the password is sent in encrypted form (RSA), as long as JavaScript is activated in the browser. If JavaScript is active, the browser will display Crypted RSA 1024 bit adjacent to the Password field (Fig. 6.2). If it is not, the word will be Cleartext and the password is sent without any encryption to the WebShare server.

Note:: With the Enforce RSA Crypted Passwords option in the “Server Preferences” window (see Fig. 4.3 in 4.1 “Server Preferences”) encrypted user logins are enforced.

10.1.2 WebShare File Server

The server file system security will be enforced according to the user credentials. Sharepoint based security allows further restrictions per user, e.g. browse, preview, download, upload and file management.

Ports

Port 2010-2015

10.1.3 Server setup

We highly recommend to use a two-tier server setup which is comprised of a dedicated WebShare Web Server with two network adapters as illustrated in 3.1 “Different setups”. The benefit of this setup is:

Only one HTTP port (default: 2009) is available from the internet
HTTP traffic is handled on a dedicated server (HTTP attacks will not slow down the file server)
The dedicated WebShare Web Server does not store any data (in case an unauthorized person is able to log in, they will not find any data)
It is easier to secure the dedicated server with only one incoming TCP/IP port
It is easier to use the latest OS updates on this dedicated server

10.1.4 Firewalls

We highly recommend to secure all TCP/IP ports of the WebShare Web Server and allow only incoming HTTP connections on port 2009 (WebShare HTTP default). This can be done via a hardware firewall on an internet router or via a software firewall on the WebShare Web Server.

10.1.5 Access from the WebShare Web Server to the WebShare File Server

The WebShare Web Server preference WSAllowedHostNames (7.6 “Preferences”) allows limiting the WebShare Web Server access to a given list of WebShare File Servers. We recommend to specify the hosts which are allowed by the WebShare Web Server to avoid that an unauthorized person routes this HTTP traffic via your WebShare Web Server to their WebShare File Server. Though this is not a security problem, there should be no reason to allow others to use your WebShare Web Server.

10.1.6 Symbolic links within sharepoints

By default, WebShare hides all symbolic link files for security reasons. Irrespective of this, it can happen that a directory includes a symbolic link to some files outside of a sharepoint. When a user duplicates this directory, all references to symbolic links are resolved and copied into the duplicated directory. Therefore, the files will not be symbolic links anymore and can be accessed.

10.1.7 Action scripts

WebShare allows running custom scripts, which are stored in the “var/settings/WebShare/Actions” directory. All sample actions were developed as “Perl” scripts. “shell” or other programs are allowed but we recommend “Perl” to ensure server cross-platform compatibility, and avoid quoting problems of special characters in file names/arguments. Please note that action scripts running with the host user ID (or equivalent permissions) can access data outside a sharepoint. For security reasons, you may want to control the action script availability to individual users by limiting the action script access permissions. This can be done using the file system permissions (UNIX “chmod” or Windows ACLs to set e.g. access for user only, access for group only). Action scripts calling host programs (via system, pipe open, shell, etc.) can be dangerous if the file names contain special characters (e.g. < or > or `). Consult an operating system or “Perl” scripting specialist to verify custom scripts.

10.1.8 Allow all Read or Read/Write access in sharepoints

The optional preference to bypass host permissions AllRead and AllReadWrite should not be used unless you are aware that the access to files is not protected by the host OS anymore. By default, these two preferences are turned off and can only be turned on via a special WebShare file preference.

10.1.9 “wsaddshare” and “wslogin” scripts

The optional “wsaddshare” script allows limiting the sharepoint administration to a few specific path names (e.g. only “/data” and “/webshare” are allowed). Set up a list of allowed path names via “wsaddshare” to ensure that the WebShare Administrator cannot publish the entire server.

The “wslogin” script allows additional auditing of user logins, e.g. verifying the remote address or limiting the login to specific hours/days.

10.1.10 No content security

By default, WebShare uses crypted passwords, nobody can spy these passwords because WebShare uses a random number which is different for each HTTP login. The complete content, e.g. file browsers, image previews and uploads/downloads, is sent over the internet without encryption in a default installation. internet providers, local users, etc. can use network monitoring tools to spy your activities. To avoid this, complete encryption via HTTPS can be enabled according to the instructions given in 7.4 “HTTP/SSL support”.

10.1.11 Switching WebShare to port 80 on the WebShare Web Server

This chapter provides more information about how to setup WebShare to use the default HTTP port and how to run WebShare in parallel with the existing web server on the same machine, using port 80 for the HTTP communication.

Some customers will not allow any other port than the default HTTP port 80. Changing the WebShare port to 80 offers more compatibility to other users behind their own proxy servers and firewalls.

By default WebShare accepts incoming HTTP connections from all IP addresses/network interfaces on port 2009. When the WOPort preference is changed to port 80 this may conflict with the existing web server (e.g. Apache) on the same host. The workaround is to setup a second IP address (alias) on the same interface and configure WebShare to use the second IP address on port 80. The DNS/Hosts configuration must be updated with the second IP address, e.g. “webshare.<yourdomain>.com” mapping to the second IP address. This can be done via:

# ifconfig eth0:0 192.168.1.6 up

This is the command for a Linux platform using the network interface “eth0” assigning the additional IP address. The command or syntax may vary on different server platforms, so check your options in the “ifconfig” or “ip” documentation. The IP address has to be valid within your internet network range/class.

The first step is to tell WebShare to listen only on the new interface instead of all interfaces.

Specify the WebShare Web Server preference WOHost. The new name must resolve to the new alias IP address:

# prefvalue -k Programs/websharewoa/WOHost -t str
  "webshare.yourdomain.com"

Then set the WOPort preference and then stop and restart the WebShare Web Server:

# prefvalue -k Programs/websharewoa/WOPort -t int 80 

# srvutil stop websharewoa 
# srvutil start websharewoa

HELIOS Manuals September 29, 2020