Print
this page and associated reference material
Client-side firewall and/or proxy configuration
for CollabWorx RTC services
This document describes required firewall and/or
proxy settings that are necessary for corporate users separated
from Internet by a firewall to use CollabWorx Real-time conferencing
services. This memo focuses on the client side.
Network diagram highlighting necessary network
elements is included later
in this section.
A frequently asked question in the context of
on-line collaboration is: why cannot collaboration services use
only HTTP/HTTPS protocols? The answer is the same as to the question:
"why don't we travel to moon on a bike?": A bike is as good for
space travel as HTTP protocol is suitable to implement high-performance,
real-time collaboration. The vendors advertising their collaboration
services as only using HTTP are in reality admitting to mediocrity
and inadequacy of their solutions. It is not possible to encapsulate
all protocols into HTTP/S and expect rich functionality, stability,
scalability, and performance of a real-time communication
application. The popular trend to block all connections
on the firewall and constrain corporate connectivity to HTTP/S
(AKA "port 80 dogma") is equivalent to invalidating the entire
body of work by IETF,
ITU,
and W3C
on Internet protocols.
CollabWorx RTC does not support HTTP-only
communication and there are no plans to introduce such a solution.
This article's main goal is to help network administrators required
to support real-time communication and collaboration services
to correctly assess security impact of such services and to soothe
their fears that on-line RTC may destabilize or expose their networks.
We want to demonstrate that such fears are unfounded and that
the problems can be elegantly and efficiently solved while maintaining
desired security and control over the network.
Firewall-friendly solutions from CollabWorx
Traditional conferencing solution based
on H.323 and T.120 standards are very difficult to implement securely.
These protocols have been designed when network security was an
afterthought. As a result, they require multiple TCP ports and
nearly a full range of dynamically assigned UDP ports. This is
indeed undesirable.
In security context, UDP transport is more
difficult to handle than TCP. The difference lies in how connections
are initiated. With TCP a connection initiated from within
firewall to an outside server (outgoing connection) supports
bi-directional traffic. This means that it is not necessary to
let outsiders to establish connection to corporate network (incoming
connections) to be able to receive e.g. audio and video streams
from them. With connectionless UDP transport the firewall must
make a packet-by-packet decision to admit A/V streams without
necessarily knowing if such streams have been actually requested
by an internal user. For this reason UDP is treated with considerable
mistrust by network security administrators. This is unfortunate
since elimination of UDP implies elimination of multicast service,
but it seems that, at present, security considerations are prevailing.
CollabWorx RTC products support three network
topologies for data-intensive applications such as audio/video
conferencing: multicast, UDP-based P2P unicast, and a central
retransmitter ("reflector") topology using TCP transport. Given
firewall interaction considerations, multicast and UDP P2P topology
is applicable to Intranet situations. Most Internet-based deployments
opt for the TCP-based reflector network topology.
Using TCP reflector solution is firewall
friendly. As per the network
diagram (see below), the CollabWorx real-time messaging servers
should be collocated with corporate web servers in the so-called
Demilitarized Zone (DMZ). This segment of the network must allow
connections across Internet firewall to all services hosted in
DMZ. The port numbers of the CollabWorx services are shown in
the diagram. Please, note that any particular implementation may
be using as few as two or three of the TCP ports in the indicated
range, although massive deployments may use nearly all of the
ports. It is important to understand that the port range used
by CollabWorx has been carefully and deliberately selected. First,
it conforms to the IANA
recommendation of port selection for private applications.
Second, there are no "well-known" Trojan horses in this range.
Please, consult this
document for detailed explanation of the port selection range.
With reflector topology for data intensive
applications CollabWorx clients communicate via a set of messaging
engines residing in the data center of the service provider (in-house
or an ASP). CollabWorx client software only needs to make outgoing
TCP connections via corporate firewall to establish service access.
No incoming connections are necessary. CollabWorx software works
with both NATed
and Internet IP addresses on corporate Intranets with no special
steps to be taken.
Firewalls and Proxies
Click
for a large image
In general, two solutions are available to
enable connectivity to messaging servers:
- Firewall administrators can open necessary
outgoing TCP connections on the corporate firewall. It is recommended
that the rules controlling this connectivity are limited only
to necessary (actually used) ports and to the known IP addresses
of machines running CollabWorx messaging servers. A little more
relaxed approach is to allow a range of ports and a domain name
to which messaging servers belong. Neither of these methods
introduces any significant security risk for the corporate network,
or opens access to undesirable services that the corporation
would rather eliminate from the Internet menu available to its
employees.
This solution is illustrated on the diagram
by connectivity pattern of client machines labeled as "CollabWorx
client not using SOCKS".
- Proxy servers are incorporated into
firewall infrastructure.
Corporations commonly use HTTP/S proxy servers to control and
monitor access to the Web by their employees. SOCKS
proxies are available to support similar functionality for
arbitrary protocol. SOCKS proxy default port is TCP 1080. A
firewall with integrated SOCKS proxy should block all outgoing
connection except connection to arbitrary TCP ports originating
from the machine running SOCKS proxy server. More often than
not SOCKS proxy is a part of the HTTP/S proxy.
This solution is illustrated on the diagram
by connectivity pattern of client machines labeled as "CollabWorx
client using SOCKS".
To use HTTP/S proxy, the browsers
used by all company employees must be instructed to do so. The
configuration GUI used to set up HTTP proxy usually also allows
users to configure SOCKS proxy. The application that intent
to use SOCKS protocol need to be SOCKS aware. Most of the CollabWorx
applications are; those that yet have not been SOCKS-enabled
may use a small utility known as SOCKSCap.
Installation of this utility allows the user to select any of
the network applications and direct it to use SOCKSCap wrapper.
Which of the above solutions is better?
It depends. Both solutions (if properly implemented) help to maintain
very high network security. Solution 1 is better for overall system
performance and helps keeping audio and video conferencing delays
at minimum and media quality at maximum. It is also cheaper as
proxy server software needs to be purchased and maintained. For
organizations placing high value on traffic monitoring and management
proxy servers offer these capabilities and are hence recommended.
Security impact
How is implementation of the
firewall solutions described above impacting network security?
In both cases the impact is minimal.
Solution 1 is, in
principle, slightly less secure. General impact is low since
no ports for incoming connections are being open, i.e., no additional
access initiated outside of the corporate network to assets inside
the firewall is created. Blockage of outgoing ports serves two
general purposes (1) it limits number of ways corporate users
have to transfer out privileged documents in uncontrolled fashion;
(2) it prevents corporate users from accessing undesirable services,
such as entertainment sites, especially those serving multimedia
contents. This practice is aimed at limiting both employees' distraction
and unwanted network traffic. Note that none of these is strictly
security related, although access to certain consumer-grade IM
systems opens a way for users to transfer files bypassing the
rules a corporation might have on permissible e-mail attachments.
In the context of CollabWorx
software this loss of security is mitigated as follows:
- CollabWorx Secure Instant Messenger
(SIM) does not support, per design, file transfer capability.
SIM has been designed from ground up as a business tool and
it eliminates all the factors that make consumer grade instant
messengers a security threat and a distractive factor. For detailed
discussion of these issues please consult SIM
whitepaper.
- Port numbers used by CollabWorx software
are not used and, according to IANA
recommendations, should not be by any other applications.
Hence, by opening the ports used by our software the corporation
is very unlikely to enable access to any unwanted applications
that might distract the employees or increase unauthorized network
traffic. This cannot be entirely ruled out however. If this
is an important concern we recommend implementation of proxy
servers (solution
2).
- CollabWorx messaging servers do not
serve any persistent data - they are merely route and distribute
messages.
- CollabWorx secure
messaging and authentication servers are independent and
usually not collocated. Enabling access to the ports allowing
communication with messaging servers is not sufficient to gain
access. The users must also obtain credentials from the authentication
server. CollabWorx authentication server (SafePerimeter) is
a Web service accessible via HTTPS on standard TCP port 443.
This means that in spite of opening necessary outgoing ports
only the authorized users will be able to connect to RTC services.
- One of the popular methods of attacking
network security is to spoof the servers. With respect to CollabWorx
there are following obstacles to do so: (1) there is no public
domain software with equivalent functionality. Spoofing party
would have to obtain original software and corresponding license
(CW servers are IP-locked); (2) The servers communicate with
authentication server to complete authorization process. All
accesses to authentication servers are logged so that all rogue
requests for confirmation will be immediately detected and denied.
CW clients will not complete authentication cycle without receiving
server confirmation in a proprietary format and including information
that can only be received from authentication server. (3) Attacks
via substituting a reverse-engineered messaging server will
fail without the server also obtaining a digital certificate
attesting to its legitimacy. Such certificates are unforgeable
and would have to be stolen from CollabWorx.
- Limiting access via firewall to specific
IP addresses known to be associated with a legitimate CollabWorx
service reduces the risk to astronomically small.
Hence, a scenario enabling hijacking
of the CollabWorx services would necessarily involve (1) hijacking
of the DNS server pointing to CollabWorx messaging servers; (2)
theft and installation of the server software as well as certificates
and software licenses, or (3) reverse engineering of proprietary
aspects of CollabWorx meeting setup protocols; (4) theft of the
data used to authenticate users of CW services and independent
theft or hijacking of the CollabWorx authentication and authorization
server. If the CW service setup does not involve DNS names of
the servers but rather uses IP addresses, no attack scenario other
than a physical seizure of the data center is conceivable. This,
of course, remains to be a Hollywood-class event so far.
The drawback of the solution
1 is that the corporation might want to monitor and manage
access even to a legitimate service. Installation of proxy servers
provides this functionality. All security mechanisms of solution
1 are still in force as proxy servers may be set up to cooperate
with firewall as described above. Proxy servers permit tightening
up of the firewall rules by only permitting outgoing connections
from the machines running proxy server software. Proxy servers
can also be used to log all connections, selectively disable user
access, or implement time restrictions.
Need help?
CollabWorx provides professional
and consulting services for all your network configuration
and security needs related to all types of collaborative applications.
Print
this page and associated reference material
