SECURING BIZTALK SERVER 535
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Color profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
Chapter 13
Securing BizTalk Server
535
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:38 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
536 BizTalk Server: The Complete Reference
izTalk Server is an enterprise-level product that facilitates the integration of
B business partners through the processing and transport of commercial data.
Obviously, it is vital that you secure the systems on which the software will run,
the networks to which they are connected, and the documents that will be exchanged.
Failure to do so could compromise confidential data, mission-critical corporate systems,
trading partnerships, and, indeed, entire businesses.
Implementing security best-practices requires knowledge of fundamental concepts
such as network design, firewall configuration, public key infrastructure (PKI), and
server administration. To further secure BizTalk Server deployments, it is crucial to
recognize weaknesses that may be exposed by the product and to use the security tools
and features provided by BizTalk Server and the underlying operating system. You
may also need to protect the actual data that is the currency of electronic business
transactions, to avoid legal or ethical repercussions.
Security Concepts
You must grasp certain fundamental security concepts to understand how to protect a
BizTalk Server installation. Some of these concepts are specific to Windows 2000 and
Microsoft Internet Information Services (IIS), while others are more generic, applying
to different platforms and different scenarios. BizTalk Server is able to take advantage
of many security features built into Windows 2000, but security is more than just the
setting of properties or the installation of software. Security is often an attitude—a
good administrator or developer should be always thinking of potential trouble spots
that could compromise a network or application, and take steps for prevention rather
than cure. If you are already familiar with the basic concepts discussed here, you can
skip ahead to the next section, “Enterprise Security”.
Disclaimer! Security is an issue not to be taken lightly, and there is rarely only one way
to secure an installation. Although this chapter recommends many courses of action you
can take to secure BizTalk Server, you should ensure that you—and your administration
team—are completely familiar with security concepts in general before implementing
any specific recommendations in a production environment.
Authentication
One fundamental idea is that of authentication—a user’s (or application’s) ability to
prove its identity to gain access to a computer, program, or document. Windows 2000
does not allow anything to happen unless the appropriate security credentials have been
passed to the operating system and they have been verified by the security provider.
This authentication may be used to allow a user to open a file on a network share or to
allow a piece of software to execute. Even the operating system needs a user account,
and many system services impersonate this account to have unfettered access to the
computer and its resources.
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:38 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
Chapter 13: Securing BizTalk Server 537
In a domain-centric network such as that provided by Windows 2000, it can be
relatively straightforward to secure those resources, because nobody can gain access
without providing a specific user account and password that is checked against a
central security accounts management (SAM) database. However, when the network
expands to take advantage of the Internet, it is typically impossible to provide unique
identities to every user who may attempt to access a host. As a set of Internet services,
IIS has a variety of ways to authenticate users who access those services, providing
graduated levels of security. These include Basic Authentication, Windows Integrated
Authentication, Digest Authentication, and Client Certificates. However, I’ll first discuss
how Windows handles authentication.
Windows Authentication
Everything that happens on Windows 2000 happens in what is termed a security context.
When a user logs on and double-clicks an icon on their desktop, they are doing so in
the security context of the user account whose details were provided during that logon.
Basically, an encrypted version of the password supplied is compared to a similarly
encrypted password stored in the SAM database. If they match, it is reasonable to assume
that it is that particular user logging on, as it should not be possible for another user to
provide the same password.
Of course, this only holds if the users have been properly educated about strong passwords
and security, rather than simply picking their spouse’s first name or their date of birth.
A successful authentication causes an access token to be generated, which the user
will proffer whenever they need to perform a task, such as deleting a file or sending a
document to a printer. In Windows 2000 with Active Directory installed, the Kerberos
protocol can make these exchanges even more secure by incorporating public key
infrastructure (PKI) methods such as those discussed later in this chapter.
As mentioned, the same is true for all programs that wish to interact with the operating
system. Most applications will run by virtue of the fact that they are instantiated by a
logged-on user (the interactive user), so they will run in the security context of that user.
However, there are also numerous Windows services that must run in the background
even when a user is not logged on. This is true of all Windows 2000 computers, although
it is most important for those acting as servers. In such cases, the services must be
configured to run in the security context of a particular user account. For obvious
DEPLOYING BIZTALK
reasons, this is called a service account.
To illustrate this idea, open a Command Prompt and type the command set. This
SERVER
will show a list of environment variables including username, which should show the
name of the user currently logged on. Now type the following, substituting a time that
is about one or two minutes ahead of the current time on your system:
at 12:00 /interactive "cmd"
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:38 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
538 BizTalk Server: The Complete Reference
This will cause a new Command Prompt window to appear at the designated time. The
interactive switch means that the window will interact with the desktop. If you type set
into this new Command Prompt window, you will notice that the environment variables
displayed are different, as shown. This is because the new window was instantiated by
the “at” command, which means that it was created by the Task Scheduler service. By
default, this service runs in the context of the Local System account, which effectively
represents the operating system itself. If you’re feeling brave, you could try logging on
as a user with limited privileges, running the preceding command, and then trying to
perform an administrative task in the new window.
Service Accounts
The BizTalk Messaging Service and the Microsoft SQL Server service are examples of
services that may need to run in the background when no user is logged on. For this
reason, during the installation of these products, you will be asked to select a user
account under whose security context the services will execute. In many cases, the
Local System account is sufficient; but although this account has many powerful
administrative privileges, they are all confined to the local machine and have no
rights to do anything across a network.
For example, the BizTalk Messaging Service does not need to perform any actions
on other computers in the network apart from the SQL Server computers on which the
Messaging Management, Shared Queue, and Document Tracking databases reside.
However, BizTalk Server is configured to use SQL Server authentication rather than
Windows authentication to access those databases, so the fact that the service is
running under the Local System account will not cause any problems. Sometimes,
however, it is necessary for the Microsoft SQL Server service to communicate with
other SQL Server computers. An example was given in Chapter 10 where two SQL
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:38 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
Chapter 13: Securing BizTalk Server 539
Server computers were linked to allow the archival of data from one system to a database
on the other. If the first SQL Server service is configured to log on as the Local System
account, it will not have permission to store information in the remote database. This
can be circumvented using the sp_addLinkedSrvLogin stored procedure to configure
the credentials the first system uses to communicate with the second. In fact, best practices
often recommend using a domain user account for the Microsoft SQL Server service
instead of the Local System account.
One specific right that the Local System account does have is the right to log on
locally. This means that it will log onto Windows as needed to execute certain services.
This does not happen interactively, however, so the services appear to run with nobody
logged on. Of course, those services will need to interact with Windows at a fundamental
level, so another right that’s required is the right to act as part of the operating system.
However, as mentioned in Chapter 3, if you decide to use a specific account other than
Local System for the BizTalk Messaging Service, the account you choose will automatically
be given those rights.
Rights and permissions are two different things. Although the account you choose will
be assigned certain rights automatically, it will not be assigned access permissions to
files, folders, and Registry keys. You will have to configure these permissions manually
using Windows Explorer and RegEdt32. Rights may also be configured manually
through the local, group, or domain policy in effect.
Windows services are not the only programs that may need to run with no user
logged on interactively. BizTalk Server makes use of numerous COM+ applications, such
as the BizTalk Server Interchange application and the XLANG Scheduler application. By
default, these are configured to run in the security context of the interactive user. This
means that if there is no interactive user—that is, nobody is physically logged on at the
computer—the application cannot run. Later in this chapter, we will see how to configure
those applications to run in the background using a specially created account, and also
how to further secure those applications using roles.
Permissions
Regardless of who or what is logged onto a machine, Windows provides a way to protect
files, folders, printers, and Registry keys from unauthorized access. These concepts are so
fundamental to all administrators that I will assume you are already familiar with them
DEPLOYING BIZTALK
and only summarize the main points of file and folder permissions here.
First, folders may be shared out to provide access to remote users, and permissions
SERVER
may be set to determine the level of access that individual users, or groups of users,
should have on that folder when they connect to it across a network. These are called
share-level permissions, and we can either grant or deny full control, change, or read
access to each account. Second, there are NT File System (NTFS) permissions. These
operate on a much more granular level, applicable to each individual file within a
folder as well as to the folder itself. There are many more options to choose from,
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:38 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
540 BizTalk Server: The Complete Reference
including read attributes, delete subfolders and files, take ownership, and so on. These
permissions apply to both local and remote users, so they can be used to further restrict
access to accounts that have been granted share-level permissions or to restrict users
who access files locally. The set of permissions assigned to users or groups for a particular
resource gives us something called a discretionary access control list (DACL). Later in this
chapter, we will see how these permissions help to secure the web sites created by
BizTalk Server.
IIS Authentication
The Internet poses a tremendous security risk if your systems need to be accessible
from the outside or if they need to access external resources. Internet Information Services
(IIS) provide a number of authentication methods to satisfy different scenarios. For
example, if a web site is meant to be available to the general public to provide information
or services, it would not be feasible to create an individual user account for every person
who might come to the site. However, Windows 2000 will not allow anybody to access
resources on a web server unless some kind of security context is available. For this
reason, a special user account called IUSR_Computername is created by the installation
of IIS, where Computername is the name of the server. Whenever anonymous users connect
to the server, they are actually doing so using the security context of that account, so
file and folder permissions should be set to allow or disallow access to that account as
appropriate.
In a business environment, however, it would be undesirable to allow anonymous
users to access potentially sensitive information or to have access to certain systems. For
example, if you have an Active Server Page (ASP) application that will accept purchase
orders sent to be submitted to BizTalk Server, you will probably want to ensure that
only your business partners can access that page. Therefore, you will probably use
NTFS permissions to secure the page and ask users attempting to access it to prove
who they are before allowing them to continue. IIS provides a number of methods by
which users can authenticate, as shown next, but only two methods are generally
available for use in an Internet scenario where different browsers, proxy servers, and
firewalls are in use—Basic Authentication and Client Certificates, the latter being
configured on the Directory Security tab of the Web Site Properties dialog box under
Secure communications.
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:39 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
Chapter 13: Securing BizTalk Server 541
Basic Authentication is a means of querying the requesting user for a valid user name
and password to access a particular resource. An HTTP header is sent from the web server
to the client specifying that Basic Authentication is required. The client then sends the
credentials supplied by the user under Base-64 encoding. This encoding is not secure,
however, because an intercepting party can obtain utilities to decode the data and easily
determine the user name and password. As a result, Basic Authentication is often
combined with Secure Sockets Layer (SSL) technology, which uses a secure version of
HTTP called HTTPS in conjunction with a digital certificate to encrypt the data so it cannot
be decoded by an intercepting party. The digital certificate also proves the identity of the
web server, as certified by a trusted third party. HTTPS, SSL, and digital certificates will be
covered in more detail later in this section.
Another feature that SSL provides is the ability for clients to authenticate themselves
using a digital certificate. Client Certificate authentication with SSL is even more secure
than Basic Authentication with SSL, because it is considerably less likely that unscrupulous
users could obtain a legitimate user’s Client Certificate, than it is that they could obtain
or guess that user’s user name and password. IIS also provides the facility for these Client
Certificates to be mapped to actual Windows 2000 user accounts in a one-to-one or
many-to-one fashion. In the latter case, IIS might be configured such that all users who DEPLOYING BIZTALK
SERVER
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:39 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
542 BizTalk Server: The Complete Reference
access the site with a Client Certificate where the e-mail address ends with @bushwhack.ltd
are authenticated by mapping them to a Windows 2000 user account called bushwhack.
Later in the chapter, we will see how BizTalk Server can be configured to use a Client
Certificate when it transports outbound documents using HTTPS.
Public Key Infrastructure
If you have ever used any of the terms “digital certificate”, “digital signature”, “private
key”, or “certificate authority”, you may not have realized it, but you were talking
about the accepted standard for providing secure communications called the public
key infrastructure (PKI). PKI has become widely accepted across multiple platforms
and disciplines because of the features it provides—authentication, authorization,
confidentiality, integrity, and nonrepudiation.
As we have seen, authentication is the process by which an entity such as a user or
an application successfully proves its identity to a system. Authorization is the process
by which that system then provides the entity with permission to perform some task,
such as read a file or run a program. Confidentiality is the process by which the secure
transmission of data is assured such that the data cannot be read by an unauthorized
third party. Even without confidentiality there can be integrity, such that if a document
can be intercepted and read, it cannot be altered without such tampering being detectable.
Finally, nonrepudiation ensures that the sender of a document cannot later deny that
they sent that document.
Digital Certificates
So, you may ask, how does PKI provide all these things? The answer: through digital
certificates. A digital certificate is an electronic document that acts like its real-world
counterpart, in that it proves something within agreed boundaries. For example, if you
go into a doctor’s office and you see a degree certificate hanging on the wall, you may
be unsure whether it’s an authentic degree. However, if you examine the official wax
seal on the degree and see that it has been awarded by a recognized academic institution,
then you will probably put aside your suspicions and get undressed. In the same way,
digital certificates are only useful if they are signed by a mutually trusted third party
called a Certificate Authority (CA).
So, you inquire further, what are public keys, and where do they come into it? To
answer this, I must first explain something about encryption techniques. To encrypt a
message, we can apply a mathematical rule—or algorithm—to the message to jumble it up.
Using the same algorithm, however, there may be multiple ways to encrypt the data. For
example, if I were trying to encrypt the message “this is a secret”, I could select an
algorithm whereby each character was replaced with a letter that is offset from it in the
alphabet. So if I decided to offset each letter by three, as shown in the following illustration,
I would end up with the encrypted message “wklv lv d vhfuhw”. In this case, I would say
that the key is three. If this message were intercepted in its encrypted form, a human being
might take a few minutes to figure it out, even if they knew the algorithm, because they
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:39 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
Chapter 13: Securing BizTalk Server 543
would not know by how many letters each character was offset and would have to try each
possibility. It wouldn’t take long for them to crack the code, however, because there are
only 25 possible values for the key. (If I were to offset each character by 26, the message
would be unchanged.) To create a code that even computers find difficult to break, I need a
more complicated algorithm and a greater range of possible key values. Because computers
deal in binary numbers, the key is described by the number of bits it contains, which gives
us the term key length.
In this fashion, encryption techniques used through the ages typically involved an
algorithm and a key. As in the simple example just given, the key to encrypt the data is
also used to decrypt the data—the algorithm is simply reversed. Therefore, the process
is called symmetric encryption. However, the problem arises when I want to let people
know what key I’m using to encrypt my data, so that they can readily decrypt it. If I
send it to them in an e-mail, the e-mail could be intercepted, and other parties could
know my key. Even if I were to try to encrypt the e-mail, I would need another key to
do that, and again, I would have to let the recipient of the e-mail know what that key
was. This is called the key distribution problem, and a solution for the problem was not
discovered until the 1960s.
To get around this quandary, a mathematical algorithm is constructed that requires
two keys. If the first key encrypts the data, then only the second key can decrypt it, and
vice versa. Also, even if you have one of the keys, it would be mathematically impossible
(or at least extremely difficult) to determine the value of the second key, as they are
not mathematical inverses of each other. So, one key is always kept secret and never
divulged—the private key—whereas the second key may be freely distributed to all and
sundry without fear that it could be used to determine the first. This second key is called
the public key. The ability to encrypt information with one key and decrypt it with another
DEPLOYING BIZTALK
provides two basic ideas in PKI—digital signatures and digital envelopes.
Digital Signatures
SERVER
Suppose I want to send a document to a trading partner, and I encrypt it using my
private key. If the trading partner has a copy of my public key, they can decrypt the
information, as illustrated. However, if you’ve been paying attention, you’ll realize that
everyone else in the world could do the same—by definition, my public key is made
available to anyone who wants it. That doesn’t sound very secure! Well, it’s not, but the
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:40 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
544 BizTalk Server: The Complete Reference
purpose of such encryption is not to protect the data, but rather to prove who sent it. If
the trading partner (and everyone else) is able to decrypt the data using my public key,
then that proves that it could only have been encrypted using my private key. And
because I never, ever, ever give my private key to anyone else, the document must have
come from me. Just as my written signature authenticates my checks for the bank, this
digital signature authenticates my documents for any trading partners who receive them.
In actuality, the process is a little more complicated. To digitally sign a document,
the body of the document is first passed through a well-known, irreversible encryption
algorithm. This creates a fixed-length binary version of the document called a hash. This
hash is then encrypted using the private key, and the hash and a copy of the public key
are added to the end of the original message. When somebody receives this document,
they can decrypt the hash using the attached public key and then use the same well-
known, irreversible algorithm on the body of the message. If the two hash values
match, not only does that prove that the document came from the owner of the public
key, but it also proves that the body of the document could not have been tampered
with during transmission, because the same hash should never be generated for two
different documents.
Digital Envelopes
So what happens when we do want to encrypt data such that only a particular recipient
can decrypt it? In this case, we can use the recipient’s public key to encrypt the data, as
illustrated. Again, although it would be possible for everybody in the world to do the
same thing, we all know that only the owner of the corresponding private key will be
able to decrypt the data. For this reason, encrypting documents is even easier, because
we don’t have to have any keys of our own; we simply use the readily available public
key of the party to whom we’re sending the document. Just as we place confidential
letters into sealed envelopes before dropping them in the mail, we can use a digital
envelope to seal a document and protect it from unauthorized eyes.
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:40 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
Chapter 13: Securing BizTalk Server 545
Certificate Authorities
At this stage, you may have recognized one potential flaw in all of this. If I receive a
digitally signed document from somebody and it contains a public key that successfully
decrypts the hash value, how can I be sure the public key actually belongs to them?
Similarly, if I’m about to encrypt my credit card details to send to an e-commerce web
site, how can I be sure that the public key I’m using to perform the encryption actually
belongs to www.buycoolstuffsecurely.com, rather than www.dodgyblokesinbalaclavas.
com? I’d also want to take a close look at that doctor’s degree to make sure the name on
the certificate was actually the name of the person in front of whom I was about to get
naked. Obviously, there needs to be somebody higher up the chain whom everybody
trusts and who guarantees the authenticity of these public keys. This is done by a
Certificate Authority (CA), who ensures the veracity of public keys by incorporating
them into digital certificates. The CA then digitally signs each certificate using their own
private key so that we can examine it and see that it was issued by somebody we trust.
Because there are different types of digital certificate that will be used in different
scenarios, there are also different types of CA. At the top (or bottom, depending on how
you look at it), there is a root CA. The root CA has to be explicitly trusted, because when you
receive a digital certificate belonging to a root CA, it has also been signed by the root CA.
By definition, there is no greater authority, so root CA certificates are self-signed. Root
CAs rarely sign certificates for companies or individuals. Instead, they sign certificates for
intermediate CAs, who may exist at multiple levels down until you reach a CA to whom
you might apply for your own digital certificate. The certificate you receive will be signed
by that low-level intermediate CA, and that signature will contain the digital certificate of
the CA who in turn authorized the lower CA to grant certificates. This will continue up
to the next intermediate CA, and so on, until there is a certificate signed by the root CA,
whom we explicitly trust. Therefore, you can always examine the certificate chain leading
back to the root CA.
One other thing that CAs provide is a Certificate Revocation List (CRL). This is a
list of certificates that have been invalidated for some reason—perhaps because the
private key was compromised, or because the certificate was being used improperly.
This list allows an individual or a system to check digital certificates received for the
purposes of authentication or encryption, and to ensure the validity of those certificates.
Secure Sockets Layer
There are many applications of PKI, but perhaps the most common is Secure Sockets
DEPLOYING BIZTALK
Layer (SSL), a technology originally developed by Netscape, and now in global use
as the de facto method of securing data transmission with a web server. Contrary to
SERVER
popular belief, SSL is not just a simple matter of encrypting information with a web
server’s public key and sending it off—there is a little bit more going on in the
background. However, I don’t want to go into too much detail; I’m discussing it
here more as an example of PKI in use.
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:40 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
546 BizTalk Server: The Complete Reference
If a client (such as a browser) wishes to engage in secure data transmission with a
web server, the client and server will first have to establish a secure connection. The
following steps take place in sequence, as shown in Figure 13-1.
1. The user will initiate a connection by browsing to a URL that uses the https://
prefix instead of http://. This indicates to the server that the client wishes to use
SSL. HTTPS uses port 443 for this communication, rather than the standard port
80 used by HTTP.
2. When the server receives a request on this port, it responds by sending its
digital certificate. The common name specified on this certificate must be the
same as the fully qualified domain name (FQDN) of the web site, for example,
www.bushwhack.ltd.
3. The client compares the name on the certificate to the name of the site, examines
the date on the certificate to check that it has not expired, and examines the
digital signature on the certificate to ensure that it belongs to a trusted CA. If
all is in order, the client generates a unique key, which it encrypts using the
public key from the server certificate.
4. The server may then request a Client Certificate for authentication purposes,
although this is not required.
5. If requested, the client will send an appropriate Client Certificate to provide
authentication.
6. The server checks the credentials on the Client Certificate, and if all is in order,
sends its response to the original request, encrypting the information with the
unique key generated by the client.
7. The client decrypts the response from the server. All subsequent requests and
responses will also be encrypted using the session key.
Figure 13-1. The Secure Sockets Layer handshaking process
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:41 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
Chapter 13: Securing BizTalk Server 547
One of the most important things to note here is that the actual information sent by
the server is not encrypted using a public key from the client. Likewise, any information
sent by the client to the server is not encrypted using the server’s public key. Instead,
symmetric encryption is used, where the client and server use the same key for encryption
and decryption. Earlier, I said that this presented difficulties in terms of key distribution,
but using the server’s public key to encrypt the session key overcomes that problem.
Symmetric encryption is used for two main reasons. First, although it would be
possible for the client to encrypt confidential information (such as credit card numbers
or passwords) using the server’s public key, the server would not be able to encrypt
information for the client (such as a bank account balance) unless the client also had a
public key. Unfortunately, not all Internet users have a digital certificate of their own,
although this might become a reality in the future. Second, using public-private key
encryption entails huge overheads in terms of data transfer and processing power,
whereas symmetric key encryption is much more efficient, and thus, less demanding
on the server and the connection.
Network Security
It is sometimes said that the only surefire way to completely secure a computer system
from intrusion is to make sure it’s not connected to any other computers and to lock it
away in a bank vault. Unfortunately, such a computer system would be little use to
anybody unless its job were just to crunch numbers for years on end. In the real world,
there are too many advantages afforded by networking computers together to succumb
to paranoia. However, when you’re considering connecting your corporate network to
the Internet, a little paranoia is no bad thing.
Perhaps the most dangerous thing about connecting a network to the Internet is the
possibility of intrusion by malicious individuals intent on stealing data, causing damage,
denying legitimate service, or simply being mischievous. To avoid such attacks, it is vital
to protect the network from intrusion by deploying one or more systems whose job is to
detect and prevent unauthorized access. Installing and configuring these firewall systems
is a mandatory exercise for any enterprise administrator.
However, you will still want some systems on your network to be accessible from the
outside world in varying degrees. These could include public web servers, FTP servers,
SMTP servers, DNS servers, and Message Queuing servers. You will still want to protect
these systems from attack using a firewall, but you will also need to ensure that these
DEPLOYING BIZTALK
systems are not used as a base to launch attacks at the corporate network, so a second
firewall is typically placed in between. The area between the external and internal firewalls
SERVER
is protected from the Internet while also kept separate from the corporate network, and is
thus called a demilitarized zone (DMZ). Figure 13-2 shows a typical arrangement.
Keeping your network safe is not just about preventing access from outside. For a
variety of reasons, you will often want to restrict access to the Internet from inside. For
example, you may wish to prevent employees from surfing the web during office hours
or from browsing to unsavory sites. Ensuring that all requests to the Internet go through
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:41 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete
Complete
Reference
Reference
/ BizTalk
/ BizTalk
ServerServer:
2000: TCR / Lowe et al / 3498-4 / Chapter 13
548 BizTalk Server 2000: The Complete Reference
Figure 13-2. A typical firewall arrangement
a broker can provide this functionality, so systems that forward requests to the Internet
on behalf of the original requestor are called proxy servers. Using proxy servers can also
have other desirable effects, such as hiding internal network addresses or optimizing
the retrieval of frequently requested content.
Firewalls
To protect a network from unauthorized external access, we use firewalls. These may
be actual computer systems running firewall software such as Microsoft Internet Security
and Acceleration (ISA) Server, or they may be hardware devices such as switches or
routers. An external firewall is the first point of defense for all computers within a
network, whether they should be accessible to the outside world or not. They provide
protection by filtering requests that arrive at the network, examining the Internet
Protocol (IP) addresses of the source and destination, the ports being accessed, and
even the contents of the network packets.
Firewalls filter requests based on source IP address for a number of reasons. There
may be certain IP addresses that are explicitly rejected because they come from undesirable
domains, but a more likely scenario is that only certain ranges of addresses might be
allowed, because they come from recognized business partners or systems, while all
other addresses are rejected. This would be the case for an extranet, where access
should only be provided to certain groups rather than to all, or for an intranet, where
only recognized addresses belonging to the company are allowed in.
Firewalls also filter requests based on destination IP address. For example, requests
to the IP addresses of the outward-facing web servers and the external DNS server might
be the only ones allowed by the firewall. This would help to prevent direct access to
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:43 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
Chapter 13: Securing BizTalk Server 549
other systems on the network if a malicious user were able to find out the IP addresses
of those systems.
Because there are many different types of requests that can be sent to a network, a
firewall has to be able to distinguish between those that should be allowed and those
that should be rejected. One way in which a firewall can do this is to look at the source
and destination ports of the request and response. For example, when a request is sent
to a web server, that request is usually sent over Transmission Control Protocol (TCP)
port 80. The HTTP service that runs on the web server is designed to listen for, and respond
to, requests that arrive on that port. Therefore, a firewall could reasonably assume that
a request from the Internet to the IP address of an outward-facing web server on port 80
is a legitimate request. Similarly, a firewall could assume that a request from the
Internet to the IP address of an outward-facing DNS server on port 53 is a legitimate
request. However, if the firewall detected a request to the web server on port 23, that
would indicate that somebody was trying to use Telnet to gain administrative access to
the server, so that request should be blocked. A firewall will typically be configured to
disallow access on all ports except those that have been explicitly opened. That way, if
for some reason the firewall fails, it will fail closed rather than open.
Finally, the third way that firewalls can protect a network is to actually examine the
contents of packets traveling to the network, and to deny malformed or malicious requests.
One problem that’s becoming increasingly prevalent on the Internet is the so-called
denial of service (DOS) attack. In a DOS attack, the perpetrator is not trying to gain root
access to a server or to sniff confidential data. Instead, he or she is simply trying to kick
the system so hard that it falls over, and thus prevents legitimate users from accessing
the service. One way in which DOS attacks can be mounted is by sending malformed
TCP packets to a server. For example, during the initial handshaking phase between a
client and a server, the client sends a packet to which the server must respond. When
the server gets an acknowledgement from the client that its response was received, the
session can begin in earnest. However, a deliberately engineered packet from the client
can hold a false return address such that the server’s response is sent to a phantom
host, and the server never receives an acknowledgement. The TCP protocol demands
that the server should wait a certain amount of time for an acknowledgement to arrive,
setting aside resources for the session to follow. If enough such malformed packets are
sent to a server in quick succession, all resources are used up and the server crashes.
This is a slightly simplistic version of events, but firewalls can detect and trap these
types of malformed requests to prevent DOS attacks.
DEPLOYING BIZTALK
Demilitarized Zones
SERVER
As discussed, firewalls can protect a network from intrusion, while still allowing legitimate
access. However, a single firewall between the Internet and a corporate network sits as a
single obstacle to a malicious user and can therefore serve as a single point of failure. With
a single firewall, the question arises—where should you place your web servers? Should
they exist behind the firewall as part of the corporate network, or in front of the firewall,
where they will be more easily accessible, but also more prone to attack? Not only that, but
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:43 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
550 BizTalk Server: The Complete Reference
the increasing popularity of dynamic, data-driven web applications for e-commerce and
e-business presents another problem. For example, if your e-commerce web site stores
product information and customer order details in a database, where should that database
be positioned—in the same network as the web servers for ease of access, or on the
corporate network where the most protection can be afforded?
A more robust, and more common, scenario is to use two (or even three) firewalls.
One firewall sits in front of the entire network, while the second sits in front of the
corporate network. In between lies a separate physical subnet—or virtual local area
network (VLAN)—called a demilitarized zone (DMZ), where publicly accessible servers
should sit. Because the DMZ is neither directly connected to the Internet (the external
firewall is in the way) nor directly connected to the corporate network (the internal firewall
is in the way), this provides much greater protection and avoids having a single point
of failure.
Figure 13-3 shows where different servers might typically be placed in an enterprise
scenario. For example, the web server is in the DMZ because it should be accessible to
the public. Other servers in the DMZ might include a message queuing server, where
applications could drop messages to be retrieved asynchronously; an SMTP server, where
incoming mail could be delivered; and a DNS server, so that external clients can discover
the IP addresses of the outbound-facing servers.
Behind the second firewall, either on the corporate network or separated from it by
a third firewall, lie the infrastructure servers. For example, a Microsoft Exchange Server
could retrieve e-mails relayed by the SMTP server in the DMZ, without the Exchange
server having to be externally visible. Similarly, the web server in the DMZ could submit
documents to an internal BizTalk Server or store data in an internal SQL Server. In
Figure 13-3. Placement of servers in a demilitarized zone
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:44 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
Chapter 13: Securing BizTalk Server 551
general, as Figure 13-3 shows, the external firewall only allows Internet clients to have
access to servers in the DMZ, and the internal firewall only allows access to the servers
on the corporate network if the request is coming from one of the computers in the
DMZ. There is never a direct route from the Internet to the corporate network. Later in
this chapter, we will discuss the placement of BizTalk Server and related servers in a
network that uses a DMZ.
Proxy Servers
Another type of host that can provide protection between the Internet and a corporate
network is a proxy server. As the name suggests, this server makes requests to the Internet
on behalf of clients on the corporate network. As a result, its main goal is to provide
outbound security rather than inbound security, although some products, such as
Microsoft ISA Server, combine firewall and proxy server features. There are a number
of reasons to use a proxy server in an enterprise—to restrict Internet access, to provide
network address translation (NAT), and to provide content caching. Figure 13-4 shows the
typical placement of a proxy server within a network. Later in this chapter, we will see
how the presence of a proxy server on a network requires some extra configuration for
BizTalk Server.
First, the proxy server can act as a filter for outbound requests for Internet content.
For example, the proxy server may be configured to only allow access to the Internet
outside of office hours or during lunch hour. Similarly, individual computers or groups
of computers can be allowed or denied access. In Figure 13-3, the computer with IP
address 10.0.0.102 can access the Internet, but the others can’t. Another restriction
might be to prevent clients from accessing dubious content, so that users attempting to
browse to www.dodgyandprobablyillegal.com are presented with a friendly warning
about conscientious Internet use.
Second, the proxy server can hide the internal network addresses from the outside
world, by virtue of the fact that it is the only host that ever makes a direct connection to
DEPLOYING BIZTALK
SERVER
Figure 13-4. The placement of a proxy server on a network
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:45 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
552 BizTalk Server: The Complete Reference
the Internet. In Figure 13-4, for example, the internal hosts are configured with specially
reserved IP addresses that are only supposed to be used on an internal network. However,
whenever any of those clients makes a request to the Internet, the only IP address that
the destination web server will see is that of the proxy server—131.107.2.1. Strictly
speaking, this is a type of network address translation (NAT), and it is a way to provide
Internet access to many internal clients without having to buy many expensive IP
addresses.
The third feature that proxy servers provide is content caching. Because the proxy
server is the only computer actually connected to the Internet, it makes sense for the
server to cache frequently requested content. Thus, when a client makes a request for
something that’s already in the cache, it can be returned across the local area network
in a fraction of the time it would take to retrieve it from the Internet. Of course, content
on the Web changes all the time, so some proxy servers automatically update their
cache on an ongoing basis so that they will have the most up-to-date content.
Enterprise Security
As discussed earlier in this part of the book, deploying BizTalk Server in the enterprise
requires more than simply installing the product on a single machine. There may be
multiple computers running BizTalk Server in a server group, at least one SQL Server
installation hosting the databases used by BizTalk Server, and possibly web servers,
message queuing servers, FTP servers, SMTP relay servers, and Microsoft Exchange
servers. Although these systems will all need to communicate with each other to a
certain extent, it is highly unlikely that all of them should be directly accessible from
the Internet. The placement of each server in relation to existing firewalls and proxy
servers is extremely important, and depending on the services that BizTalk Server will
require, each firewall may need particular port or IP address-filtering configurations.
Network Considerations
Best practices dictate that you place outward-facing web servers, SMTP servers, and so on,
in a demilitarized zone (DMZ) between two firewalls. The external firewall will allow
Internet traffic to reach these servers, but the internal firewall will only allow requests that
originate within the DMZ to pass through. Therefore, we will usually place infrastructure
servers such as those running Microsoft SQL Server and Microsoft Exchange Server on the
corporate network behind the internal firewall for their protection. However, we also know
that BizTalk Server will usually need to communicate with both Internet clients and
back-end systems, so where should it go—behind the external or internal firewall?
Server Placement
BizTalk Server will undoubtedly serve as an invaluable part of your e-business
infrastructure, and the last thing you would want is a denial of service (DOS) attack
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:45 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
Chapter 13: Securing BizTalk Server 553
to bring it down, or a cracked password to compromise your business data. For this
primary reason, you usually will not place BizTalk Server in the DMZ—you will
instead position it behind the internal firewall. There are also plenty of practical and
logistical reasons why you would not want to locate BizTalk Server in the DMZ. For
example, if your BizTalk servers are used for EAI, it would be desirable to keep them
close to the internal application systems with which they will communicate. Similarly,
performance will be degraded if BizTalk Server has to communicate with SQL Server
through an internal firewall.
You may not be completely convinced, however. Although we’ve mentioned it already
in passing, Chapter 16 will fully discuss how BizTalk Server can accept submitted
documents using DCOM, through the Submit and SubmitSync methods of the Interchange
object. This may lead you to think that having your trading partners submit their purchase
orders through a COM interface is a good thing, and hence you should position your
BizTalk servers behind the outer firewall. However, it is inadvisable to allow external
trading partners to submit documents directly to BizTalk Server in this way—not just
because of the security implications, but also because of the tight coupling of applications
it implies. If your BizTalk Server were not available for any reason, the submission
attempt would fail.
Another potential security risk of locating BizTalk Server in the DMZ is that the
BizTalk Server WebDAV Repository and Document Tracking web sites would be
directly accessible from the Internet. Although the NTFS permissions on the WebDAV
Repository do not admit the Internet Guest account, all recognized local users have
access to the physical directory, and directory browsing is enabled for the virtual
directory. Similarly, although the Document Tracking web site is only accessible to
members of the BizTalk Server Report Users group, one captured user account would
lay all of your business data bare.
Another potential security problem with the Document Tracking database is that the
user account—dta_ui_login—created to provide access for the client interface has a
blank password. You should rectify this through SQL Server Enterprise Manager and
reflect the change in the file connection.vb located in the \Program Files\Microsoft
BizTalk Server\BizTalk Tracking\VBScripts directory.
There can be exceptions. If you have a small enterprise, and BizTalk Server will
only be used in B2B scenarios rather than for EAI, you may decide to place BizTalk
DEPLOYING BIZTALK
Server in the DMZ. This will ease restrictions on trading partners to submit documents
to BizTalk Server, although this should still be done asynchronously using HTTP, FTP,
SERVER
SMTP, or a message queue, rather than using the COM interface. Also, you will need
to configure the internal firewall to allow BizTalk Server to communicate with certain
internal systems such as SQL Server, as discussed later in this section. Even for small
enterprises, though, I would not recommend placing BizTalk Server in the DMZ.
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:45 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
554 BizTalk Server: The Complete Reference
HTTP Submission
To allow trading partners to submit documents to BizTalk Server using HTTP, it is
recommended to use an Active Server Page (ASP) running on IIS within the DMZ. This
ASP should then post the document to a Message Queuing server either in the DMZ or
behind the second firewall, as shown next. This is preferable to having an ASP submit
the document programmatically using the Interchange object, because this would fail
if the BizTalk server were unavailable. Once dropped into a private message queue,
BizTalk Messaging can then retrieve the document asynchronously using a Message
Queuing receive function, and BizTalk Orchestration can retrieve the document using
a Message Queuing implementation shape.
To enable clustered BizTalk servers to perform transactional reads from a single private
message queue, BizTalk Server Service Pack 1 must be installed. Otherwise, the private
message queue must exist on the BizTalk server itself, and only that server will be able to
host the receive function. For load balancing without Service Pack 1, a custom “fan-out”
component can be used to distribute messages to local private message queues, with
Windows Management Instrumentation (WMI) determining the load on each
BizTalk server.
SMTP Submission
To allow trading partners to submit documents to BizTalk Server using SMTP, you
should place an SMTP relay server (such as that provided by IIS) in the DMZ. This
relay server can then be configured to forward e-mails to a computer running
Microsoft Exchange Server on the corporate network. This provides greater security
than placing the Exchange server itself in the DMZ. As documents arrive to a specially
configured inbox on the Exchange server, a script can submit them programmatically,
or else to a message queue as with HTTP.
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:46 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
Chapter 13: Securing BizTalk Server 555
FTP Submission
To allow trading partners to submit documents to BizTalk Server using FTP, it will be
necessary to deploy one or more FTP servers (for example, using IIS) in the DMZ. These
servers should host virtual directories that map to a physical location such as a shared
network folder, as illustrated next. Because it is a security risk to have shared network
folders in the DMZ, Internet Protocol Security (IPSec) can be used to encrypt data
traveling from the FTP servers to a shared folder behind the internal firewall. A File
receive function can then be configured to retrieve posted documents and submit them
to BizTalk Server.
For more information on IPSec, add the IP Security Policy Management snap-in to a
Microsoft Management Console and consult the help file.
Firewall Considerations
Depending on where you choose to locate BizTalk Server, you will need to configure one
or both of the internal and external firewalls in your enterprise to enable communication
between the various systems. Your BizTalk Server installation will need to interact with
Microsoft SQL Server, and your deployment may also require communication between
BizTalk Server, IIS, Exchange Server, and others. Configuring the firewalls that comprise
the DMZ will involve setting up port filters and potentially IP filters.
IP Address Restrictions
DEPLOYING BIZTALK
If you choose to place BizTalk Server behind the internal firewall as recommended, the
standard IP address filters created for your external and internal firewalls should suffice.
SERVER
As mentioned, hosts on the Internet should only be able to access hosts within the DMZ,
and only those systems in the DMZ should have access to the internal infrastructure
servers such as Exchange Server, SQL Server, and BizTalk Server. For outbound
communication, you will also need to determine whether BizTalk Server needs to
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:47 AMColor profile: Generic CMYK printer profile
Composite Default screen Complete Reference / BizTalk Server: TCR / Lowe et al / 3498-4 / Chapter 13
556 BizTalk Server: The Complete Reference
access the Internet directly. For example, in a B2B scenario, messaging ports may be
configured to send documents to trading partners using HTTP or SMTP. In such cases,
the internal and external firewalls should be chained and configured to allow the BizTalk
Server external access by IP address. A cluster of BizTalk servers in a server group will
obviously mean that each IP address should be allowed out through the firewalls.
Port Restrictions
As discussed, firewalls are generally configured so that all ports are closed except those
that explicitly need to be opened. Because there are various ways in which BizTalk Server
can accept and transmit documents, it is important to consider which ports your particular
scenario requires. BizTalk Server will always need to communicate with SQL Server,
however, so TCP inbound port 1433 will need to be opened on the internal firewall if
BizTalk Server is located in the DMZ. If BizTalk Server is behind the internal firewall
(as recommended), this configuration will not be necessary.
In a high-security enterprise environment, it is common for administrators to change
the default port used by SQL Server. If this is the case, you will need to ensure that the
correct port is open.
Inbound/Outbound HTTP If your trading partners will be submitting documents to
a web server in your DMZ, then port 80 inbound will need to be open on the external
firewall. If you have a digital certificate installed on your web servers, you can use
HTTPS instead, which will require port 443 inbound open on the external firewall. If
your BizTalk servers are located behind the internal firewall, then the ports you open
on that firewall will depend on how the web servers submit the documents to BizTalk
Server. If an ASP will drop the documents into a private message queue, then port 1801
inbound will need to be opened on the internal firewall. If DCOM will be used, then
you should use DCOMCNFG to select the port range that will be used and open those
ports on the internal firewall, although again, this is not recommended. As discussed,
BizTalk Server can also send documents out using HTTP or HTTPS, so ports 80 or 443
outbound would also need to be opened on both firewalls to allow this.
To use DCOM through a firewall, you must open TCP port 135 inbound, as well as the
range of ports configured for the component. Port 135 is required by the DCOM Service
Control Manager to determine the port through which the remote procedure call (RPC)
should pass.
Inbound/Outbound SMTP If your trading partners will be sending documents
using SMTP, they should arrive at an SMTP relay server in your DMZ, which will then
forward the e-mails to an Exchange server on the corporate network. In this case, port
25 inbound should be opened on both firewalls. Because the Exchange server is located
on the same network as BizTalk Server, there will be no need to open any further ports
on the internal firewall, regardless of whether the Exchange server submits documents
P:\010Comp\CompRef8\498-4\ch13.vp
Monday, October 22, 2001 9:41:47 AMYou can also read
