SME Server:Documentation:Administration Manual:Chapter11

From SME Server


Security

Remote Access

If you're an advanced user, the SME Server provides several different ways to access the underlying operating system, either from a computer on your internal network or from a computer outside your site on the Internet. Additionally, you have the ability to access your computer network securely from a remote computer. All of these operations are configured from the screen shown below in the server manager.

Each of these remote access methods is described below.

Remote-access-1.png Remote-access-2.png


VPN

(awaiting full integration)


Remote Management

To allow access to the /server-manager from remote networks add allowed IP addresses to the Remote Management section.

To allow a single computer (or network of computers behind a firewall) add its IP and the netmask.

223.102.19.24   255.255.255.255
SSH

If you need to connect directly to your server and login from a remote system belonging to you, we strongly encourage you to use ssh. In addition to UNIX and Linux systems, ssh client software is now also available for Windows and Macintosh systems. (See the section below.)


Information.png Tip:
Configuring SSH access as public will result in lots of script based login attempts which consume bandwidth, CPU and generate log noise. A new iptables rule which blocks repeated connection attempts to the configured sshd port.

It is set to reject connections when there have been 3 or more requests in the previous 15 minutes. By design only IP outside your local network will blocked if too many attempts are done. See AutoBlock_SSH


If you do not have any reason to allow remote access, we suggest you set this to No access.

SSH (secure shell) provides a secure, encrypted way to login to a remote machine across a network or to copy files from a local machine to a server. Many people do not realize that many programs such as telnet and ftp transmit your password in plain, unencrypted text across your network or the Internet. ssh and its companion program scp provide a secure way to login or copy files. The ssh protocol was originally invented by SSH Communications Security which sells commercial ssh servers, clients, and other related products. The protocol itself has two versions - SSH1 and SSH2 - both of which are supported by most clients and servers today. For more information about SSH Communications Security and its commercial products, visit http://www.ssh.com/.

OpenSSH, included with the SME Server, is a free version of the ssh tools and protocol. The server provides the ssh client programs as well as an ssh server daemon and supports both the SSH1 and SSH2 protocols. For more information about OpenSSH, visit http://www.openssh.com/.

Once ssh is enabled, you should be able to connect to your server simply by launching the ssh client on your remote system and ensuring that it is pointed to the external domain name or IP address for your server. In the default configuration, you should next be prompted for your user name. After you enter admin and your administrative password, you will be in the server console. From here you can change the server configuration, access the server manager through a text browser or perform other server console tasks.

If you do enable ssh access, you have additional configuration options:

  • Allow administrative command line access over ssh - This allows someone to connect to your server and login as "root" with the administrative password. The user would then have full access to the underlying operating system. This can be useful if someone is providing remote support for your system. In most cases we recommend setting this to No.
  • Allow ssh using standard passwords - If you choose Yes (the default), users will be able to connect to the server using a standard user name and password. This may be a concern from a security point of view, in that someone wishing to break into your system could connect to your ssh server and repeatedly enter user names and passwords in an attempt to find a valid combination. A more secure way to allow ssh access is called RSA Authentication and involves the copying of an ssh key from the client to the server. See the User Manual for details
  • TCP Port for secure shell access - Change the port the ssh client connects to the server, choose a random free port eg. 822. This provides some protection from casual attacks on the usual port of 22 and reduce log noise, but will not deter a serious attacker.


Important.png Note:
By default, only two user names can be used to login remotely to the server: admin (to access the server console) and root (to use the Linux shell). Regular users are not permitted to login to the server itself. If you give another user the ability to login remotely to the server, you will need to access the underlying Linux operating system and manually change the user's shell.


  • SSH clients

A number of different free software programs provide ssh clients for use in a Windows, Macintosh or Linux environment. Several are extensions of existing telnet programs that include ssh functionality. A list of known clients can be found online at https://www.ssh.com/ssh/client, PuTTY being the most popular for Windows as it meets most requirements and is regularly updated. Linux workstations normally have direct ssh capability.

A commercial ssh client is available from SSH Communications Security at: http://www.ssh.com/products/ssh/download.html. Note that the client is free for evaluation, academic and certain non-commercial uses.

Do note that the SSH protocol also supports SFTP (an alternate secure FTP) and SCP (secure copy). WinSCP is one example of a Windows client that supports both for GUI Files transfer via the shell.

FTPs

Another way to upload or download files to and from your server is to enable a protocol called FTP, or "file transfer protocol". This screen enables you to set your policy for FTP. Note that allowing liberal FTP access to your server does reduce your security. You have two options that you can set here.

FTP is now FTPs by default, or FTP over TLS, and this setting is forced. If for any reason you want or need to be less secure than that, then please check the wiki on how to do so. Plain FTP does not use encryption and so is trivially cracked, we strongly recommend you use the default FTPs.

FTP user account access: Private FTP access allows only people on your internal network to write files to your server. Public FTP access allows users both inside and outside your local network to read or write files on your server, provided they have an account and password. If, for example, you want to be able to update your web site from home using FTP, you would choose the "Public" setting. We strongly recommend you leave this as Private unless you have a specific reason to do so.

FTP access limits: This allows you to set an overall site-wide policy for FTP access. The setting you choose here will override all other FTP settings on your server . For example, if you choose "Disable public FTP access" here and then later configure an i-bay to allow public FTP access from the Internet, such access will be forbidden. Note that one of the choices here allows you to completely disable any use of FTP.


Local networks

Your SME Server provides services to machines on the local network and it gives machines on that network special privileges and access. For example, only machines connected to the local network can access the mail server on your server to send mail. When you configured your server, you provided it with sufficient information to deduce its own local network. Machines on the network are automatically identified by the server as being eligible for these privileges and access.

If your company only has one network that is being serviced by the server, you do not need to add any information here.

Some advanced users may wish to extend privileges to more than one network of computers. If you would like your server to identify one or more additional networks for those privileges, you will be asked to enter those network IDs and the subnet mask for each network here.

Local-networks.png


Important.png Note:
Depending on the architecture of your network infrastructure, the instructions for configuring the client machines on that additional network may be different than the instructions outlined in the chapter in this user guide. If you have questions regarding adding another network, you may wish to contact Contribs.org and visit the forums.


Port forwarding

Your SME Server provides the ability to forward its ports to other machines.

Port-forwarding.png

You can use the panel shown above to modify your firewall rules so as to open a specific port (or range of ports) on this server and forward it to another port on another host. Doing so will permit incoming traffic to directly access a private host on your LAN.


Warning.png Warning:
Misuse of this feature can seriously compromise the security of your network. Do not use this feature lightly, or without fully understanding the implications of your actions.


Proxy settings

Your SME Server has a transparent HTTP and SMTP proxy.

HTTP Proxy

The server's HTTP proxy works to reduce overall uplink usage by caching recently-visited pages. It is transparent to web browsers using this server as their gateway.

SMTP Proxy

The server's transparent SMTP proxy works to reduce virus traffic from infected client hosts by forcing all outgoing SMTP traffic through this server. If you wish to use an alternate SMTP server, and this server is your gateway to it, disable this proxy.

- Disabled. Clients behind SME Server are allowed to connect to any SMTP server anywhere in the world (that allow them to).

- Blocked. This forces all SMTP traffic to go through the server and be authenticated. All attempts to connect to any SMTP Server other than the SME Server will be blocked and treated as if there is no SMTP server on the other end. (This is the new default)

- Enabled. Any attempt to connect to an SMTP Server other than the SME Server will be redirected to the SME Server. If someone attempts to connect to an external smtp server (gmail for example) it will be redirected to the sme server. If they then have it set to authenticate to that external server instead of passing the user/pass to the external server it will pass it to the sme server and fail. (This is the old default)

Note: The server (by default) now requires email clients (other than webmail) to authenticate and will not allow auth to occur over an unsecure link. If for example you are using thunderbird then you must set the authentication method to normal password. Leave the connection security at starttls or ssl/tls.

Proxy-settings.png