The
Internet provides somewhat of a catch-22 when it comes to its goal and
purpose. On one hand, the Internet is designed to allow anywhere,
anytime access to information, linking systems around the world together
and providing for that information to be freely exchanged. On the other
hand, this type of transparency comes with a great deal of risk,
because it effectively means that any one system can be exposed to every
connected computer, either friendly or malicious, in the world.
Often, this inherent
risk of compromising systems or information through their exposure to
the Internet has led to locking down access to that information with
firewalls. Of course, this limits the capabilities and usefulness of a
free-information exchange system such as what web traffic provides. Many
of the web servers need to be made available to anonymous access by the
general public, which causes the dilemma, as organizations need to
place that information online without putting the servers it is placed
on at undue risk.
Fortunately, the
Forefront Edge line provides for robust and capable tools to secure web
traffic, making it available for remote access but also securing it
against attack and exploit. To understand how it does this, it is first
necessary to examine how web traffic can be exploited.
Understanding Web (HTTP) Exploits
It is an understatement to say
that the computing world was not adequately prepared for the release of
the Code Red virus. The Microsoft Internet Information Services (IIS)
exploit that Code Red took advantage of was already known, and a patch
was made available from Microsoft for several weeks before the release
of the virus. In those days, however, less emphasis was placed on
patching and updating systems on a regular basis, because it was
generally believed that it was best to wait for the bugs to get worked
out of the patches first.
So, what happened is that a
large number of websites were completely unprepared for the huge
onslaught of exploits that occurred with the Code Red virus, which sent
specially formatted HTTP requests to a web server to attempt to take
control of a system. For example, the following URL lists the type of
exploits that were performed:
http://sharepoint.companyabc.com/scripts/..%5c../winnt/system32/cmd.exe?/c+dir+c:\
This one in particular
attempts to launch the command prompt on a web server. Through the
proper manipulation, viruses such as Code Red found the method for
taking over web servers and using them as drones to attack other web
servers.
These types of web-based
attacks were a wakeup call to the broader security community. It became
apparent that packet-layer filter firewalls that could simply open or
close a port were worthless against the threat of an exploit that
packages its traffic over a legitimately allowed port such as HTTP or
HTTPS.
Web-based filtering and
securing, fortunately, is something that the Forefront Edge line does
extremely well, and offers a large number of customization options that
enable administrators to have control over the traffic and security of
the web server.
Securing Encrypted (SSL) Web Traffic
As the
World Wide Web was maturing, organizations realized that if they
encrypted the HTTP packets that were transmitted between a website and a
client, it would make it virtually unreadable to anyone who would
potentially intercept those packets. This led to the adoption of SSL
encryption for HTTP traffic.
Of course, encrypted packets
also create somewhat of a dilemma from an intrusion detection and
analysis perspective, because it is impossible to read the content of
the packet to determine what it is trying to do. Indeed, many HTTP
exploits in the wild today can be transmitted over secure SSL-encrypted
channels. This poses a dangerous situation for organizations that must
secure the traffic against interception but must also proactively
monitor and secure their web servers against attack.
The Forefront Edge line
is uniquely positioned to solve this problem, fortunately, because it
includes the ability to perform end-to-end SSL bridging. By installing
the SSL Certificate from the SharePoint web front-end server on either
the Forefront UAG or Forefront TMG servers, along with a copy of the
private key, the server is able to decrypt the traffic, scan it for
exploits, and then re-encrypt it before sending it to the SharePoint
server. Very few products on the market do this type of end-to-end
encryption of the packets for this level of security other than the two
Forefront Edge line products. Before Forefront UAG or Forefront TMG can
secure SharePoint SSL traffic, however, an SSL Certificate must be
placed on the SharePoint server.
Securing SharePoint Traffic with SSL Encryption
By default, SharePoint is
configured to use Integrated Windows authentication. This form of
authentication works fine if access to the server is over a trusted
internal network, but is not feasible for access over the Internet.
Because of this limitation, a
form of authentication that can be sent across the Internet must be
used. This effectively limits the SharePoint server to using Basic
Authentication, which is supported by most web browsers and devices. The
problem with Basic Authentication, however, is that the username and
password that the user sends is effectively sent in clear text and can
be intercepted and stolen in transit. In addition, documents and other
confidential information are transmitted in clear text, a huge security
issue.
The solution to this problem
is to use what is known as Secure Sockets Layer (SSL) encryption on the
traffic. SSL encryption is performed using Public Key Infrastructure
(PKI) certificates, which work through the principle of shared-key
encryption. PKI SSL certificates are widely used on the Internet today;
any website starting with a https:// uses them, and the entire online
merchant community is dependent upon the security of the system.
For SharePoint, the key is
to install a certificate on the server so that the traffic between the
device and the server is protected from prying eyes. There are
effectively two options to this approach, as follows:
Use a third-party certificate authority—
A common option for many organizations is to purchase a certificate for
SharePoint from a third-party trusted certificate authority (CA), such
as Verisign, Thawte, or others. These CAs are already trusted by a
vast number of devices, so no additional configuration is required. The
downside to this option is that the certificates must be purchased and
the organization doesn’t have as much flexibility to change certificate
options.
Install and use your own CA—
Another common approach is to install and configure Windows Server 2008
R2 Active Directory Certificate Services (AD CS) to create your own CA
within an organization. This gives you the flexibility to create new
certificates, revoke existing ones, and not have to pay immediate costs.
The downside to this approach is that no browsers will trust the
certificate by default, and error messages to that effect will be
encountered on the devices unless the certificates are manually trusted
or forced out to client domain members via Active Directory Group Policy
Objects.
