 |  |
Chapter 23. Databases and Games
This chapter discusses two categories of protocols that didn't fit in other chapters -- the protocols used to talk to databases and the protocols used to play games remotely.
23.1. Databases
At most sites, much of the site's most security-critical information is stored in databases. At companies, they store inventory and ordering data; at universities, they store student information, including grades; at research institutes, they store personnel information and (usually on different machines) research data. Originally, these databases were protected mostly by restricting access to them, but that's no longer practical. People have become accustomed to mobile, distributed computing, where they can make instant updates to their own information, and that requires giving them the ability to reach databases. In addition, databases are being used for more and more purposes, as a way of storing and sharing information.This means that network access to databases is now critical, particularly for electronic commerce applications where database servers and web servers need to exchange data. We have discussed issues about locating database servers and web servers in Chapter 15, "The World Wide Web". Here, we will discuss the protocols used to provide network access and their security implications.
23.1.1. Locating Database Servers
Most database protocols are deeply insecure and difficult to pass through a firewall. Nonetheless, you are likely to want to let an externally available web server talk to your database servers in order to provide data to your customers (for instance, to enable web-based order tracking). There are fundamentally four options:
- Put the web server and the database on the same perimeter network (possibly even on the same machine). No database traffic will have to pass through the firewall in normal operation. (You will still need to figure out how to load the data onto the perimeter database and restrict access to the database.)
- Put the web server and the database both on the internal network. No database traffic will have to pass through the firewall; on the other hand, HTTP requests will. You are relying on the security of the web server.
- Put the web server on the perimeter network and the database server on the internal network, and use the database's native protocol to connect them. You are relying on your ability to configure the firewall and the database appropriately to secure the protocol; you must let database traffic through.
- Put the web server on the perimeter network and the database server on the internal network, and use a custom-written protocol to connect them. You are relying on your ability to construct a secure protocol that enables the transactions you need.
23.1.1.1. Putting both the web server and the database on the perimeter network
If you choose to put both the web server and the database on the perimeter network, as shown in Figure 23-1, you have two primary concerns. First, you need to be sure that the database contains only data that you are actually willing to have accessed from the Internet. You do not get any significant security benefit from putting the database on the perimeter network if it contains all the private data people could get by breaking into the internal network! Second, in most cases you are still going to need to move and synchronize data between the external database and the internal database, and you will need to develop a secure means of doing it. It will be complicated by the first problem (it's unlikely that the external database will be a simple, straightforward copy of the internal database). In general, it's possible to do this copy with a scheduled job that exports data from the two servers, transfers it across the firewall using a secured remote copy mechanism, sanity-checks it, and imports the appropriate data onto each server.
Figure 23-1. A web server using a database server on a perimeter network
Using a scheduled job to export data provides high performance between the web server and the database. However, it is not appropriate if data is going to need to move frequently between the internal and the external database server; that transfer can be quite slow. It also complicates the procedures for internal users who need to see the external data (for instance, support people answering customer calls about the web site). This method might be appropriate for a web-based catalog listing but is less appropriate for e-commerce applications where orders are going to need to be moved briskly to the internal databases, and order status will need to be frequently updated in the other direction.
23.1.1.2. Putting both the web server and the database on the internal network
If you choose to put the web server and the database both on the internal network, as shown in Figure 23-2, you are allowing external traffic to go to the internal network. This is a highly risky configuration, and we do not recommend it. However, if you are extremely confident about the security of the web server you are using, it may be more secure to pass HTTP through the firewall than to try to pass any of the database communication protocols. In this situation, consider passing connections through a proxy that can verify the HTTP; this will be more secure than using straightforward packet filtering.
Figure 23-2. A web server and a database server on an internal network
23.1.1.3. Using the database's protocols to connect to a perimeter web server
Putting the web server on the perimeter network and then using normal database remote access methods to connect to an internal database, as shown in Figure 23-3, is the most straightforward method of providing web access to the database. In this situation, the web server effectively proxies the request to the database server, so external commands do not arrive directly on the internal network. However, you are still vulnerable to any security problems in the remote access provided by the vendors, and you still need to get the database requests across to the internal network without opening up other vulnerabilities. Depending on the database and the firewall you are using, this can be quite difficult.
Figure 23-3. A web server on a perimeter network using a database server on an internal network
Your internal database will also be vulnerable if the perimeter network is compromised. If any machine is compromised, it may be vulnerable to sniffing attacks; if the web server is compromised, an intruder will have the full power of the remote database access mechanism available (note that any required passwords are likely to be stored on the web server and used automatically).You can reduce this vulnerability by carefully configuring the access that the web server has. You should use all of the access controls that your database server provides to make certain that the web server can do only things that it's supposed to be able to do. Don't use a generic database account that has many permissions. Instead, set up the web server to use a specific database account that can access only necessary data. If at all possible, set it up to use stored procedures so that it does not have access to the arbitrary database commands but can only do predefined operations that are stored as part of the database.
The amount of additional security you can get this way depends a great deal on what the web site is supposed to do. If web users are only able to read data, you may be able to get pretty good protection from the database security. On the other hand, if the web site allows people to order things, cancel their orders, or otherwise modify data, an attacker who compromises the web server is going to be able to really make you suffer, no matter what the database security is like.
23.1.1.4. Using a custom protocol to connect to a perimeter web server
Using a locally designed custom method to connect a perimeter web server to an internal database leaves the architecture the same as the one shown in Figure 23-3; it just changes the protocols used to connect the web server to the database. This configuration provides real-time access to the internal data, while giving you complete control over both the protocol and port numbers and the capabilities accessible by the web server. For instance, if the web server needs to read only data, your program can support only data read queries; even if the web server is compromised, the intruder will not be able to write data into the database. Note that if you add security features such as strong authentication and encryption, your solution may be slower than using the vendor mechanisms.We recommend building your protocol on top of an existing message-passing mechanism, but only if it provides the necessary access controls. It may be tempting to use HTTP, but we recommend against it for a number of reasons. First of all, HTTP is connectionless, which makes it difficult to build something that is transaction based and robust. Second, it means that you will have to run CGI or an equivalent on an internal HTTP server. This then makes it equivalent to an architecture we recommend against.
Building a custom protocol is not always practical. It assumes that you have local programming talent sufficient to write a small but secure client/server application. Creating a secure client/server application is not easy, so implementing the communications yourself may simply introduce different security problems from those you would have been exposed to if you'd used the database vendor's communication package. Implementing it yourself also has long-term maintenance ramifications. Nevertheless, on balance this method has significant advantages.
23.1.2. Open Database Connectivity (ODBC) and Java Database Connectivity (JDBC)
Open Database Connectivity (ODBC) is a Microsoft-developed applications programming interface (API) that allows applications developers to write software that connects to a variety of database servers. ODBC is not a protocol at the network level. Instead, it's a set of libraries that may use other network-level protocols. A program that uses the ODBC API will eventually end up talking to the database server through whatever that server's native communication protocol is. Therefore, knowing that an application uses ODBC tells you nothing useful about what network transactions it will make; you need to know what database driver ODBC is calling, which is determined by what type of database is running on the database server.There is a great deal of confusion about ODBC. If you are on a machine that uses ODBC and you are trying to configure the machine to talk to a database across a network, you will usually go through the process of configuring something called an ODBC driver. This causes many people to believe that the driver is actually part of ODBC and that ODBC controls what options are in it, which is not the case. The ODBC driver is specific to the database you are talking to, not to ODBC; it is the driver that makes ODBC talk to your database, and it is provided by the database vendor. ODBC itself does not control the network communications and has no firewall characteristics. ODBC applications do not have to use the network at all; ODBC may be used to talk to a database running locally on the same machine.
JDBC
is simply the
Java analog to ODBC, a Java API that will connect to any of a variety
of vendor database drivers. Because JDBC is based on Java, which is
designed to be dynamically loaded, it allows clients to dynamically
load the needed drivers, while in ODBC, they have to be explicitly
installed. As usual, this increases convenience at the cost of
security.
If you are asked to allow ODBC or JDBC through a firewall, you should ask what database is being used and research the network characteristics of that particular database. ODBC and JDBC by themselves will not change those characteristics. (Occasionally, databases that offer multiple connection options may not offer ODBC or JDBC drivers for all the options. Again, this is determined by the database developer and is not inherent to ODBC or JDBC.) If you have no further information to work from, assume that people who ask for ODBC really want to use Microsoft SQL Server, since it is the database most closely associated with platforms that run ODBC.
23.1.3. Oracle SQL*Net and Net8
SQL*Net is Oracle's SQL network interface for Oracle7, and Net8 is its successor for Oracle8. Both SQL*Net and Net8 perform complex network manipulations; depending on server and client configurations, connections may use unpredictable port numbers or may be restarted or initiated from the server to the client. This makes most SQL*Net and Net8 implementations extremely difficult to pass through a firewall that is not specially aware of Oracle.SQL*Net and Net8 are both based on Oracle's Transparent Network Substrate (TNS) and will attempt to speak to a server known as a TNS listener. Oracle's network situation is further complicated by the fact that it provides its own naming service, Oracle Names, which has its own server. Some proxying services are provided by Oracle Connection Manager in Oracle8 and the Oracle Multiprotocol Interchange server in Oracle7.
23.1.3.1. Security implications of SQL*Net and Net8
Both the TNS listener and Oracle Names will accept commands on the same port they normally provide service over. You can password-protect commands that are considered dangerous (for instance "start" and "stop") but not commands Oracle considers safe (for instance, "status" or "show" to show variable settings). By default, there is no password protection. Even when password protection is on, passwords may be stored unprotected in server or client configuration files. In addition, there have been reports that at least the Oracle8 TNS listener is quite vulnerable to denial of service attacks from unexpected commands, which may cause it to consume large amounts of CPU resources.Encryption is actually handled by TNS, but Oracle doesn't provide TNS versioning information. In the TNS version built into SQL*Net v1, nothing is encrypted, not even user authentication. Passwords are sent across the network not only reusable but unprotected and in the clear. As of SQL*Net v2, user authentication and TNS listener control passwords are protected but reusable when passed across the network. As of Net8/Oracle8, Oracle Names uses a protected control password as well.
The Oracle Advanced Networking Option (ANO) provides data stream encryption (via 40-bit RC4 or DES internationally, 56-bit RC4 or DES or 128-bit RC4 within the United States) and MD5 message digests. It also provides support for nonreusable passwords. Oracle also has a separate Security Server product that is used to provide an API for explicit data signing and signature verification at the application level -- a normal Oracle application cannot control whether or not the client and server are using Advanced Networking's encryption features. An Oracle server, however, may choose to require encryption and/or checksumming on all connections.
Oracle has had many security problems with their server installations. Most of these problems have involved ways to turn access to the server machine into root access or Oracle administrator access, using Oracle tools. However, some problems (like the denial of service problems previously mentioned) were exploitable from the network.
23.1.3.2. Packet filtering characteristics of SQL*Net and Net8
Oracle uses entirely TCP ports over 1024.[165] These ports can be configured, and there are multiple defaults depending on the version of Oracle you are running. In what appears to be the most common default configuration, the TNS listener is at 1521, the Oracle ultiprotocol Interchange listener is at 1526, Oracle Names is at 1575, and Oracle Connection Manager is at 1600. Client-to-server connections will normally start out going to 1521 or 1600 but may not remain there. It is not at all uncommon for hosts to run multiple TNS listeners at different ports, and Oracle's own documentation also shows alternate defaults (for instance, Oracle Names is often shown at 1521 and the TNS listener at 1526). You will need to know the details of your configuration.[165]People are often confused by the IANA registrations for ports 66 and 140, which have "sql" and "net" in their names but are not used by Oracle. They are historical curiosities left over from previous theories about networked SQL.
| Direction | SourceAddr. | Dest.Addr. | Protocol | SourcePort | Dest.Port | ACKSet | Notes |
|---|---|---|---|---|---|---|---|
| In | Ext | Int | TCP | >1023 |
1575[166]
|
[167]
|
Name lookup, external client to internal server |
| Out | Int | Ext | TCP | 1575[166] | >1023 | Yes | Name response, internal server to external client |
| In | Ext | Int | TCP | >1023 |
1600[168]
|
[167] | Request, external client to internal server (using Connection Manager) |
| Out | Int | Ext | TCP | 1600[168] | >1023 | Yes | Response, internal server to external client (using Connection anager) |
| In | Ext | Int | TCP | >1023 |
1521[169]
|
[167] | Request, external client to internal server (using TNS) |
| Out | Int | Ext | TCP | 1521[169] | >1023 | Yes | Response, internal server to external client (using TNS) |
| In | Ext | Int | TCP | >1023 |
1526[170]
|
[167] | Request, external client to internal server (using Multiprotocol Interchange) |
| Out | Int | Ext | TCP | 1526[170] | >1023 | Yes | Response, internal server to external client (using Multiprotocol Interchange) |
| In | Ext | Int | TCP | >1023 |
>1023[171]
|
[167] | Redirected request, external client to internal server |
| Out | Int | Ext | TCP | >1023[171] | >1023 | Yes | Response to redirected request, internal server to external client |
| Out | Int | Ext | TCP | >1023 | 1575[166] | [167] | Name lookup, internal client to external server |
| In | Ext | Int | TCP | 1575[166] | >1023 | Yes | Name response, external server to internal client |
| Out | Int | Ext | TCP | >1023 | 1600[168] | [167] | Request, internal client to external server (using Connection Manager) |
| In | Ext | Int | TCP | 1600[168] | >1023 | Yes | Response, external server to internal client (using Connection anager) |
| Out | Int | Ext | TCP | >1023 | 1521[169] | [167] | Request, internal client to external server (using TNS) |
| In | Ext | Int | TCP | 1521[169] | >1023 | Yes | Response, external server to internal client (using TNS) |
| Out | Int | Ext | TCP | >1023 | 1526[170] | [167] | Request, internal client to external server (using Multiprotocol Interchange) |
| In | Ext | Int | TCP | 1526[170] | >1023 | Yes | Response, external server to internal client (using Multiprotocol Interchange) |
| Out | Int | Ext | TCP | >1023 | >1023[171] | [167] | Redirected request, internal client to external server |
| In | Ext | Int | TCP | >1023[171] | >1023 | Yes | Response to redirected request, external server to internal client |
[166]1575 is a popular default, but this may be set to any port number.
[167]ACK will not be set on the first packet (establishing connection) but will be set on the rest.
[168]1600 is a popular default, but this may be set to any port number.
[169]1521 is a popular default, but this may be set to any port number.
[170]1526 is a popular default, but this may be set to any port number.
[171]This port is dynamically assigned by the server.
23.1.3.3. Proxying characteristics of SQL*Net and Net8
Oracle has proxy code for SQL*Net, but the company has chosen to make it available to firewall manufacturers, and in binary format for limited operating systems. Therefore, although several commercial firewalls provide proxying support for SQL*Net, it may not be available on all platforms even within a given manufacturer's product line. Also, while the proxy code does know about SQL*Net's port number negotiation, there is no way of knowing how much protocol enforcement it does, and given Oracle's history of being naive about security, it is reasonable to assume that it does not do much.Oracle provides a product called Oracle Connection Manager that will provide proxying, among other things, for SQL*Net and Net8 clients. Oracle Connection Manager provides extremely limited control over what clients can connect; you can accept or deny based on the following:
- Source host or IP address
- Source port
Destination host or IP address
Destination port
Destination database name
23.1.3.4. Network address translation characteristics of SQL*Net and Net8
SQL*Net and Net8 both use embedded IP address and port number information and may start up connections from the server to the client. They will not work through a network address translation system unless it has special facilities for dealing with them. Since Oracle doesn't release protocol details, this means that network address translation for SQL*Net and Net8, like proxying, will have to be provided by Oracle. As of this writing, Oracle has not provided such a module.
23.1.4. Tabular Data Stream (TDS)
TDS is a database protocol used by both Sybase and Microsoft SQL Server, among other products, for network communications. It is a proprietary protocol, owned by Sybase. Sybase offers relatively liberal access to the protocol specification, but their license specifically forbids distribution of information about the protocol specification, so the only people who really know how the protocol works aren't allowed to say.TDS is a straightforward TCP-based protocol, in which the client starts up a single connection to the server. No fixed port is used by TDS, and different implementations default to using different port numbers. In its simplest form, TDS transmits all data, including usernames and passwords, unprotected and in the clear. However, some TDS implementations use encryption to protect all or part of the data. All in all, knowing that a product uses TDS tells you relatively little about its security and firewalling implications, although the information does tend to suggest that it will be relatively straightforward to pass through a firewall (it does not tell you whether or not that would be a good idea, since TDS may be cleartext or encrypted).
23.1.5. Sybase
Sybase takes an open approach to network communications. It supports multiple different protocols, including TDS, IIOP, and HTTP. Security can be provided by running IIOPS or HTTPS. (TDS is discussed in the previous section; IIOP is related to CORBA and is discussed in Chapter 14, "Intermediary Protocols"; HTTP is discussed in Chapter 15, "The World Wide Web".)23.1.5.1. Packet filtering characteristics of Sybase
Sybase can use TDS, HTTP, HTTPS, IIOP, or IIOPS for network communications. All of these by default use TCP connections from the client to the server with both ends at a port above 1023. The port that the server will use is defined when the database server is configured and can be set to any unused port. Sybase defaults to using 7878 for TDS, 8080 for HTTP, 8081 and 8082 for HTTPS, 9000 for IIOP, and 9001 and 9002 for IIOPS. If the server has the necessary privileges and no other web server is already using them, HTTP and HTTPS may be moved to their normal reserved ports (80 and 443, respectively). HTTP and HTTPS are discussed in Chapter 15, "The World Wide Web"; IIOP and IIOPS are discussed in Chapter 14, "Intermediary Protocols".| Direction | SourceAddr. | Dest.Addr. | Protocol | SourcePort | Dest.Port | ACKSet | Notes |
|---|---|---|---|---|---|---|---|
| In | Ext | Int | TCP | >1023 |
7878[172]
|
[173]
|
Request, external client to internal server (using TDS) |
| Out | Int | Ext | TCP | 7878[172] | >1023 | Yes | Response, internal server to external client (using TDS) |
| In | Ext | Int | TCP | >1023 |
8080[174]
|
[173] | Request, external client to internal server (using HTTP) |
| Out | Int | Ext | TCP | 8080[174] | >1023 | Yes | Response, internal server to external client (using HTTP) |
| In | Ext | Int | TCP | >1023 |
8001, 8002[175]
|
[173] | Request, external client to internal server (using HTTPS) |
| Out | Int | Ext | TCP | 8001, 8002[175] | >1023 | Yes | Response, internal server to external client (using HTTPS) |
| In | Ext | Int | TCP | >1023 |
9000[176]
| [173] | Request, external client to internal server (using IIOP) |
| Out | Int | Ext | TCP | 9000[176] | >1023 | Yes | Response, internal server to external client (using IIOP) |
| In | Ext | Int | TCP | >1023 |
9001, 9002[177]
|
[173] | Request, external client to internal server (using IIOPS) |
| Out | Int | Ext | TCP | 9001, 9002[177] | >1023 | Yes | Response, internal server to external client (using IIOPS) |
| Out | Int | Ext | TCP | >1023 | 7878[172] | [173] | Request, internal client to external server (using TDS) |
| In | Ext | Int | TCP | 7878[172] | >1023 | Yes | Response, external server to internal client (using TDS) |
| Out | Int | Ext | TCP | >1023 | 8080[174] | [173] | Request, internal client to external server (using HTTP) |
| In | Ext | Int | TCP | 8080[174] | >1023 | Yes | Response, external server to internal client (using HTTP) |
| Out | Int | Ext | TCP | >1023 | 8001, 8002[175] | [173] | Request, internal client to external server (using HTTPS) |
| In | Ext | Int | TCP | 8001, 8002[175] | >1023 | Yes | Response, external server to internal client (using HTTPS) |
| Out | Int | Ext | TCP | >1023 | 9000[176] | [173] | Request, internal client to external server (using IIOP) |
| In | Ext | Int | TCP | 9000[176] | >1023 | Yes | Response, external server to internal client (using IIOP) |
| Out | Int | Ext | TCP | >1023 | 9001, 9002[177] | [173] | Request, internal client to external server (using IIOPS) |
| In | Ext | Int | TCP | 9001, 9002[177] | >1023 | Yes | Response, external server to internal client (using IIOPS) |
[172]7878 is the default, but this may be set to any port number.
[173]ACK will not be set on the first packet (establishing connection) but will be set on the rest.
[174]8080 is the default, but this may be set to any port number.
[175]8001 and 8002 are the defaults, but this may be set to any port number.
[176]9000 is the default, but this may be set to any port number.
[177]9001 and 9002 are the defaults, but this may be set to any port number.
23.1.5.2. Proxying characteristics of Sybase
HTTP proxies are widespread and can be used with Sybase's HTTP support. In addition, a number of firewall vendors provide TDS proxies. Note that none of these proxies will significantly increase security, so you should carefully protect your databases.
23.1.5.3. Network address translation characteristics of Sybase
Both TDS and HTTP run without problems through network address translation systems, so you should have no difficulty configuring your server to work with a network address translation system.
23.1.6. Microsoft SQL Server
Microsoft's SQL Server, like Sybase, can use TDS for communications (it refers to this as the TCP/IP network library). On TCP/IP networks, it also supports the use of Microsoft RPC either directly (via the Multiprotocol network library) or over SMB (via the Named Pipes network library). See Chapter 14, "Intermediary Protocols", for more information about RPC and SMB.icrosoft SQL offers multiple options for user authentication. If you set it to use SQL authentication over TDS, it passes authentication data over the network in cleartext. If you set it to use Windows NT authentication over TDS, the username and password data is obscured. (It is not clear what this is, but it appears to be reversible encryption rather than challenge-response.) SQL authentication over TDS does not protect username and password data and should never be used in an insecure environment.
You should be careful about what accounts you use for SQL access. They should have the minimum necessary permissions on the SQL database and under Windows NT. They should not be accounts that are used for logins or file sharing under Windows NT.
Note that if a client attempts to use SQL authentication across an insecure network, and the server is set up to use Windows NT authentication, the authentication will fail, but the account will still be compromised. The client will send the cleartext username and password, which can be intercepted, and there is no way for the server to prevent it.
Some versions of Microsoft SQL Server support database replication only over SMB; more recent versions will allow database replication over TDS, but it is less efficient.
23.1.6.1. Packet filtering characteristics of Microsoft SQL Server
icrosoft SQL Server normally uses TCP port 1433 for TDS but can be configured to use any port. Packet filtering characteristics of SMB named pipes and Microsoft RPC are discussed in Chapter 14, "Intermediary Protocols".| Direction | SourceAddr. | Dest.Addr. | Protocol | SourcePort | Dest.Port | ACKSet | Notes |
|---|---|---|---|---|---|---|---|
| In | Ext | Int | TCP | >1023 |
1433[178]
|
[179]
|
Request, external client to internal server |
| Out | Int | Ext | TCP | 1433[178] | >1023 | Yes | Response, internal server to external client |
| Out | Int | Ext | TCP | >1023 | 1433[178] | [179] | Request, internal client to external server |
| In | Ext | Int | TCP | 1433[178] | >1023 | Yes | Response, external server to internal client |
[178]1433 is the default, but this may be set to any port number.
[179]ACK will not be set on the first packet (establishing connection) but will be set on the rest.
23.1.6.2. Proxying characteristics of Microsoft SQL Server
TDS is easy to proxy with generic proxies. You should ensure that clients are using Windows NT domain authentication, not SQL authentication, in order to avoid disclosing username and password information. Proxying characteristics of SMB and Microsoft RPC are discussed in Chapter 14, "Intermediary Protocols".
23.1.6.3. Network address translation and Microsoft SQL Server
TDS works transparently with network address translation, so there should be no problem configuring Microsoft SQL Server to run through a network address translation system. Network address translation characteristics of SMB and Microsoft RPC are discussed in Chapter 14, "Intermediary Protocols".
23.1.6.4. Summary of recommendations for Microsoft SQL Server
|  | |
| 22.7. Mostly Harmless Protocols |  | 23.2. Games |
