Homepage Portal Server Business Reporting Additional Functions Opportunities Company Email a Colleague Privacy Policy Disclaimer
SECURITY


  General Portal Security

The iWebGate Portal Server encourages users to communicate using high encryption for all communications (*1). While network services are offered on both encrypted and unencrypted ports, administrators and users alike are encouraged to establish secured communications to the portal server.

Certificate management is made extremely easy in the iWebGate Portal Server Management Interface allowing administrators to create self-signed Certificates and Certificate Signing Requests (CSR) with the click of a mouse. There is no need to install and configure complicated Certificate Authority services in order to quickly secure the iWebGate Portal Server as these services are included pre-bundled. The portal server currently supports encryption on the following protocols:
  • FTPS;
  • HTTPS;
  • IMAPS (*2);
  • POP3S.
Security of the portal server is enhanced through strict session management and session authentication routines that ensure that sessions are not able to be hijacked by a third party or be resumed once the session has been disconnected or times out.

These processes minimise the risk of security breaches however it is highly recommended that users of the portal server are fully aware of the impact of leaving sessions unattended or logged in when not in use. Best practice is to ensure that users disconnected sessions when finished and to set a short expiry time in the portal server session management settings.

  Remote Access Security Enhancement

One of the primary reasons behind the development of the portal server was to tighten and simplify the typical processes used to provide remote connection to a host especially in the office environment. It is important to remember that security for remote access to servers and PCs is not the sole responsibility of the portal server. However, using existing remote connection protocols and infrastructure in combination with the portal server only enhances the overall security of the workplace network resources and machines that need to be accessed remotely.

The portal server currently supports remote connection protocols such as RDP, RDPv6 and VNC. Each of these protocols support encryption (*3) and it is highly recommended to ensure that the proper encryption settings are in place when using such services.

Secure deployment of connections (unlike encrypted communications) has historically been the major barrier to the deployment of remote access to internal systems as many consumers consider this to be the least secure aspect of any kind of remote access. Secure VPN connections has been one method commonly employed, however these can be expensive and often difficult to administrator and maintain and can prove to be unreliable.

The iWebGate Portal Server deploys native remote access connections in a controlled and secure manner. The portal server provides a secure ‘bridged connection’ between the client (Client) and the host to which the connection is ultimately required (Server).

This ensures that servers and computers can remain behind a corporate firewall and are not exposed directly to public networks (such as the Internet).

All connections must be initiated through a request from within the portal server itself which then accepts the incoming connection on behalf of the Server. At this stage the portal establishes the authenticity of the incoming connection by ensuring the following:
  • Confirms a valid connection request exists in the portal ;
  • Connection origin matches the request origin;
  • Connection request is received within time constraints of the initial request;
  • Confirms the Server is accepting connections at the time of the request before bridging occurs.
These strict requirements ensures that only valid connection requests are served and attempts to gain unauthorised access to Servers is blocked immediately at the portal, not at the Server itself.


Unlike some remote access service providers, the iWebGate Portal Server does not:
  • Reside on a third-party network. Services remain in-house and under the direct control of local administrators;


  • Maintain connections-in-waiting (continued Server connections to the third party waiting for a Client connections). Inevitably, the longer a connection is maintained, the greater the chance that it may be compromised. The iWebGate Portal Server handles connections as requested reducing the connection time and potential for attack;


  • Restrict the user to only one connection protocol. Users of the iWebGate Portal Server have the facility to use remote access utilising more than one protocol over the same network port eliminating the need to expose a port for each protocol.

  Security Maintenance

As with any network and the resources connected to it, maintaining security is an ongoing process. The iWebGate Portal Server itself is not a firewall and therefore administrators should ensure that the security of the appliance is maintained. This can be achieved through the following practices:
  • Ensure the portal server appliance remains securely behind a firewall either on the internal network or inside a demilitarised zone (DMZ). Portal servers should never be exposed ‘directly’ to a public network;


  • Ensure portal certificates are maintained and any signed certificates in use remain current. Private keys should never be exposed or provided to any person other than those people entrusted with their maintenance;


  • Ensure automatic updates are enabled and checks are performed regularly. This ensures that the portal software applies any security updates as and when they become available;


  • Ensure snapshot backups are done on a regular basis in case the portal needs to be restored to a previous point in time;


  • Physical security of the portal server is maintained. Where possible, the portal server should be housed in a clean and secure environment to ensure optimal performance.



References (*):
  1. Wherever possible some communications, such as SMTP remain clear text for compatibility reasons.
  2. IMAPS and POP3S currently only support encryption on the data channel.
  3. RDP & RDPv6 provide in-built encryption. VNC supports strong encryption: see http://www.realvnc.com


Overview
Setup
Security
Brochure