HTTP - World Wide Web Sessions

The World Wide Web (WWW) is a collection of sites and services, loosely connected by a network of inter-document links. The normal way to access this network is using a graphical browser interface such as Netscape Navigator, Microsoft Internet Explorer or NCSA Mosaic.

From a technical point of view the main vehicle for WWW documents is the HyperText Transfer Protocol (HTTP). This is a lightweight protocol for requesting and receiving information using any encoding mechanism recognized by both the client and server. HTTP is a stateless protocol, that is, the server retains no continuing session information about a client. This has the benefit of allowing great simplicity and extensibility at the expense of some network bandwidth overhead.

The basic HTTP exchange is a simple request-response sequence:

1. A request is sent from an unprivileged port on the client to the server on TCP port 80.

The request may contain either a simple GET action, or a more complex Method description (used, for example, when the client is sending a form that the user has filled in). The request also contains information about the client, such as the browser software in use and a list of the document formats that it can handle.

2. Theresponse packets flow on the reverse path to the request (that is, from port 80 back to the requesting client port).

The response is usually a document encoded using Multi-Purpose Internet Mail Extensions (MIME). The document will be written in one of the formats acceptable to the browser, most commonly the HyperText Markup Language (HTML), a document composition language which allows you to imbed links to other documents and to other graphical and multimedia objects.

WWW hyper-links do not always lead to other HTTP connections. Often they will take you to an anonymous FTP or gopher site. When you select the hyper-link to such a site, the WWW browser software invokes the appropriate service under the covers. So when you plan to provide this service, you should also consider the other related protocols.

As you can see from the previous description, most of the complexity of WWW lies in the higher-layer application code (which is a source for security concern, particularly as the content of Web documents becomes more interactive and as Web browsers become smarter). See Safe Surfing: How to Build a Secure World Wide Web Connection, SG24-4564, for more information.

6.8.1 Possible Scenarios

HTTP is a relatively new protocol. It was developed when firewalls were commonly in use on the Internet, so usually the Web browsers are proxy and SOCKS aware. As always, we aim to break all sessions at the firewall boundary, so a SOCKS or proxy arrangement is best. There is another important

advantage in the use of proxy servers. Some proxy servers also cache Web documents and save the most frequently accessed ones. This is a considerable performance improvement for the users and also helps to reduce network traffic (and hence also costs, when your Internet connection charges are traffic-based).

IBM Firewall includes a Web proxy server, but this is not a caching version. The

reason for this is that placing a complex application server of this kind on the firewall would break the KISS principle.

If you are going to provide a Web server for access by the rest of the world, it should be outside your secure network, ideally in a DMZ. The reason for this is that such servers are, by the nature of the application, likely to be complex and therefore vulnerable to attack. If you can isolate your server by putting it outside your secure network, you are limiting the damage that such break-ins can do.

Many examples of attacks on Web servers have been demonstrated, so you should follow the CERT advisories to check if you are exposed.

Consider the following scenarios:

SOCKSified Client: In this case, clients in the secure network connect to the SOCKS server on the firewall, which relays their sessions into the Internet. One disadvantage of this configuration is that there is no caching of documents, so if multiple users load the same document, it will be retrieved multiple times.

Figure 84. HTTP from Secure Network, Using a SOCKSified Client

This configuration requires two connections. The first is the familiar SOCKS client connection shown in Figure 61 on page 85. The second connection is as follows:

Figure 85. HTTP from SOCKS to Nonsecure Server The equivalent filter definitions are as follows:

# Connection from the client to the Socks Server

permit s.s.s.s sm.sm.sm.sm s.s.s.1 0xffffffff tcp gt 1023 eq 1080 secure local inbound permit s.s.s.1 0xffffffff s.s.s.s sm.sm.sm.sm tcp/ack eq 1080 gt 1023 secure local outbound

# Connection from Firewall to the Server in the Nonsecure Network

permit n.n.n.1 0xffffffff 0 0 tcp gt 1023 eq 80 nonsecure local outbound permit 0 0 n.n.n.1 0xffffffff tcp/ack eq 80 gt 1023 nonsecure local inbound

Socksified Proxy: This extends the SOCKS configuration by placing a proxy server in the secure network. Clients connect to the proxy, which serves documents from cache if it is available or establishes a connection across the SOCKS relay, if not. The proxy server has to have SOCKS support built in for this configuration to work correctly. Many proxy servers provide this facility, including the IBM Internet Connection family.

Figure 86. HTTP from Secure Network, Using a Socksified HTTP Proxy

The filtering rules for this case are the same as for the Socksified Client, except that instead of allowing connections from every client in the secure network, you can restrict them to the proxy server only. You could also restrict access to the SOCKS server so thatonly the proxy server can use it for HTTP. To do this, you would put the following lines in the sockd.conf file:

# Restrict socksified HTTP Connections (port 80) only to HTTP Proxy permit p.p.p.p 255.255.255.255 eq 80

deny 0.0.0.0 0.0.0.0 eq 80

Using the IBM Firewall HTTP Proxy Server in Place of SOCKS: The two

previous examples (“SOCKSified Client” on page 108 and “Socksified Proxy” on page 109) both use the SOCKS server to relay sessions through the firewall. In each case you could replace it with the HTTP proxy server that comes as part of IBM Firewall by simply using rules that permit access to the proxy port (usually tcp/8080), in place of the SOCKS port (tcp/1080).

Proxy in the Secure Network with IP Forwarding Enabled in the Firewall: This has the disadvantage that you must enable IP forwarding in the firewall, but it is relatively secure because the filter rules are very restrictive (just one host and outbound connection only).

Figure 87. HTTP from Secure Network, HTTP Proxy with IP Forwarding Enabled

Proxy Outside the Secure Network: This case is also a good solution, especially if you are using a DMZ configuration. You can put the proxy server in the DMZ for caching. Ideally you should only allow your users to access the proxy using SOCKS.

The clients request a document using SOCKS from the proxy that is outside the secure network. The proxy does the caching, and you don't have to allow routing in the firewall, so you can run a dual-homed configuration.

In this case, you will need your Web browsers to support concurrent SOCKS and HTTP proxy. You can accomplish this if your client TCP/IP implementation has built-in SOCKS support (for example, in Warp V4) by specifying a proxy in the browser configuration menu, and then use the SOCKS runtime from the TCP/IP configuration options (that is, not the browser SOCKS option).

Figure 88. HTTP Proxy in the Nonsecure Network (Preferably Using DMZ)

In this kind of configuration it is very important to treat the proxy server in the DMZ as part of your firewall. It should be monitored closely for any sign of attack. If a cracker were to manage to take control of it he could use it to set up

a Web Spoof. This means that the attacker has control over all communications to anywhere in the Web. He can choose to simply act as a relay, recording passwords and information as it flows past, or he could intervene and insert his own messages or malicious executables into the pages that your users retrieve.