This section describes in detail the following supported application proxies:
There are two types of HTTP proxy:
HTTP proxy resolves URL requests on behalf of Web clients on your network. This is also known as forward proxy. These requests are cached, if possible, on the proxy server to increase the speed of delivering the same content the next time the same information is requested.
HTTP itself is an application-level protocol used for distributed, collaborative, hypermedia information systems. It is generic and allows systems to be created independently of the data being sent. It is also an object-oriented protocol that can be used for name servers, distributed object management systems, and so on. HTTP servers use HTTP as the primary application protocol, allowing users to access and exchange Web files. The HTTP protocol can also be used for communication between users, proxies, gateways, and other Internet protocols, such as SMTP, NNTP, FTP, and Gopher.
HTTP communication is usually over TCP/IP connections, on default port 80, although other ports can be used.
The proxy server can be configured as an HTTP accelerator to protect an intranet server from the Internet and reduce the load on the public Web servers maintained on the intranet. HTTP acceleration, also known as reverse proxy cache acceleration or Web server acceleration, creates a front-end processor to a Web server. An HTTP accelerator server lies between one or more Web servers and the Internet and represents the Web servers to any clients accessing them. An HTTP accelerator can also be used to create a local mirror site of a remote server.
When the Internet user queries DNS for the Web server address, it returns the address of the requested Web server. The HTTP accelerator listens for HTTP requests on port 80 (or another configured port) and processes all incoming Web requests. Requests for objects that can be cached—static information that does not change often, such as HTML pages and GIF images—are processed by the proxy. Requests for objects that cannot be cached—dynamic information that changes frequently—are processed by the origin Web server on port 80. In general, approximately 90 percent of a typical Web server content is static and 10 percent is dynamic.
You can set up an HTTP accelerator server to retrieve information or references to cachable objects from a Web server and cache the information on a Novell BorderManager server. This reduces loading on the Web server. The HTTP accelerator server forwards only requests and references that are not in the cache to the Web server.
If your site receives requests for a high percentage of objects that can be cached, the HTTP accelerator reduces the Web load. For even greater performance, you can cache objects of a more volatile nature, such as stock quotes, and specify an accuracy delay time to users.
Novell BorderManager reverse proxy can handle more TCP connections than an origin Web server (typically UNIX or Windows NT*).
HTTP acceleration has the following benefits:
Provides caching for Web servers
Reduces the load on the Web servers and speeds them up
Protects Web servers
Protects IP networks in conjunction with the other Novell BorderManager services
In the past few months, we have seen an increase in self-propagating malicious viruses such as Code Red and Nimda, which are designed to inflict maximum damage to computer systems around the world. The methods used by this new breed of viruses demonstrate the growing sophistication of virus and worm attacks.
For example, in the case of Code Red, the worm attempts to connect to a certain TCP port on a randomly chosen host, assuming that a Web server will be found. Upon successful connection to the host, the attacking computer sends an HTTP GET request that attempts to exploit a known vulnerability in Microsoft* Internet Information Server (IIS) Web servers. If the exploit is successful, the worm begins executing on the victim host. Depending on the day of the month, it either attempts to further propagate itself by connecting to other randomly chosen IP addresses, or it launches a packet- flooding "denial of service" attack against a fixed IP address. The ultimate goal of this type of attack is to generate so much illegal traffic to the site that service is denied to the site’s legitimate users.
Although these viruses infect only certain vulnerable Web servers and routers that do not use NetWare, their method of attack can impact the performance of Novell BorderManager Proxy Servers that are used to accelerate these Web servers. To protect against such attacks from the Novell BorderManager Proxy side, there must be some mechanism in place to examine all incoming HTTP requests and reject those that are identified as coming from virus-infected computers. The main problem lies in differentiating between legal and illegal requests and acting accordingly, without adversely affecting the performance of the Novell BorderManager Proxy Server.
To accomplish this, Novell has added a Virus Pattern Recognition and protection enhancement to Novell BorderManager. This enhancement includes features to facilitate its configuration and monitoring.
This section provides an overview of the functionality of the Virus Pattern Recognition feature as a mechanism for protecting Web servers against distributed denial-of-service (DDoS) attacks. The solution involves creating a database of known virus patterns. The Novell BorderManager Proxy Server then compares every incoming request with the existing pattern database, and blocks any request that perfectly matches one of the patterns in the database.
The main goals in the design of this feature were:
To make it easy to add and delete virus request patterns in the database.
To allow the pattern database to be updated "on the fly", without bringing down the Proxy Server.
To provide automatic detection of changes in virus patterns and subsequent updating of the pattern database.
To offer effective console-based monitoring.
To minimize the impact on performance.
In discussing the functionality of this feature, it is helpful to understand the following terminology used to categorize HTTP requests:
Suspect Request: Any request that is suspected to generate from a virus- infected client or server.
Virus Request: Any request that is determined to generate from a virus-affected client or server.
Humble Request: Any request that is valid to the origin Web server (a non-virus request).
There are two types of FTP proxy:
FTP is the standard Internet protocol used for file transfer. FTP proxy is used to proxy FTP requests when users use pure FTP clients, for example, the LAN WorkPlace® software, UNIX, Macintosh, and so on.
FTP proxy has the following benefits:
Centralized access control
Data caching for FTP data files
Ability to resume data file transfer after temporary loss of connection to FTP server
Anonymous users allowed
URL representation of FTP data
Standard FTP requires a user account on the server being accessed. Anonymous FTP does not require a user account and provides access to specific files on the Internet. The username is anonymous or ftp.
You can use proxy servers to control access to authenticated FTP sites. When an FTP proxy server is placed on a firewall, all FTP client requests in the intranet must pass through the FTP proxy server. This helps enforce centralized control over Internet access and scans data that is being sent or retrieved by users within an organization.
The FTP intranet client (or user) must first connect to the FTP proxy server by entering the IP address or name of the proxy server, for example, ftp://novell.com. The user must then enter the following to identify the origin host and connect to the FTP proxy:
USER ProxyUserName$ DestFTPUserName$ DestFTPHostName
PASS UsereDirectoryPassword$ DestFTPPassword
where ProxyUserName is the NDS or eDirectory username, DestFTPUserName is the FTP username on the destination server, DestFTPHostName is the hostname or IP address of the destination FTP server, UsereDirectoryPassword is the user’s eDirectory password, and DestFTPPassword is the user password on the destination server. Only the FTP hostname DestFTPHostName is required. If the DestFTPUserName is missing, it is assumed to be anonymous, and no password is required. The ProxyUserName is required only if FTP authentication is enabled. The proxy makes the final connection to the origin host or server.
Both active and passive FTP modes are supported, and can be enabled or disabled. Active mode (PORT) posts a listener on the intranet and allows clients to make a connection to the intranet machine, a less secure method. Passive mode (PASV) for FTP allows the client to initiate the connection to a remote FTP server. PASV mode is supported to allow the firewall administrator to deny incoming connections above port 1023, if necessary.
FTP reverse proxy, or FTP accelerator, is an application that is placed in front of the FTP server. The FTP accelerator acts as an FTP server to Internet users and protects the FTP servers behind the firewall from outside break-ins. The FTP accelerator scans inbound and outbound data, and with third-party support, can trap any viruses being sent through the system.
The FTP accelerator also caches frequently requested data and FTP files for anonymous users and helps accelerate FTP requests. This process is useful because most FTP requests from the Internet are from anonymous FTP users. Caching shifts the load from FTP servers to the reverse FTP proxy.
Electronic mail is the most fundamental and useful of Internet services. It is also the most vulnerable. To create a secure environment, you must be able to restrict access to outside mail to only a few machines, screen messages for hostile applets or scripts, and avoid other malicious e-mail schemes.
SMTP handles electronic mail exchange between mail servers, accepting mail and sending it directly to the destination mail domains or delivering it to an intermediate relay agent. Post Office Protocol 3 (POP3) is used to handle the user electronic mailboxes on servers.
The Mail proxy server provides secure SMTP mail services for incoming and outgoing mail. SMTP allows intranet users to send mail to the Internet in a secure manner. Similarly, Internet users can send mail through SMTP to intranet users in a secure manner. Incoming mail is scanned for viruses, filtered for junk mail, and controlled using access control lists.
SMTP proxy can perform the following access control and filtering for outgoing and incoming mail:
Enforce access control based on usernames and mail domain names for incoming and outgoing mail.
Hide internal mail domain names and usernames. The Mail proxy can be configured to overwrite the From address so that only the primary mail domain name for an organization is exposed to the Internet.
Filter for Multimedia Internet Mail Extensions (MIME). Mail is scanned and filtered for attachments, including non-ASCII character sets, nontext data, rich text messages (with formatted text), and multipart messages.
Scan and filter incoming e-mail for viruses and junk mail. Unwanted junk mail is scanned using access control lists that combine mail domain filtering and content filtering.
Mail proxy can be used in an organization between the existing intranet mail server and the Internet, or between the intranet and the Internet without an existing intranet mail server. The following e-mail commands are allowed by the Mail proxy: HELO, MAIL, RCPT, DATA, RSET, HELP, NOOP, and QUIT.
Using the RealAudio and RTSP proxies, a RealAudio player communicates with a RealAudio server to play back audio or video as it is downloaded (as opposed to downloading an entire program before hearing it). RealAudio and RTSP eliminate the delays that can occur during download, especially with slower modems. They also support several quality levels and nonaudio features such as HTML pages synchronized with voice.
The RealAudio and RTSP proxies allow players inside the firewall to connect to the specified proxy, which then connects to the requested RealAudio server outside the firewall. The proxies hide any intranet RealAudio servers that should not be visible to the Internet. No caching is performed. You can configure reverse proxy if any RealAudio or RTSP servers should be visible to the Internet. RealAudio proxy requires RealPlayer* 2.0 or later, which can be configured with the hostname and port number used by the proxy.
The RealAudio player and server can use one of the following methods of communication:
TCP Only: In this mode, a single full-duplex TCP connection is used for both control and audio data delivery between the player and the server. The standard TCP connection port on the server is 7070.
Standard UDP: In this mode, the player sets up two network connections with the server. A full-duplex TCP connection is used for control and negotiation. A one-way UDP path from the server to the player is used for audio data delivery.
Robust UDP (optional): In this mode, the player sets up three network connections with the server. A full-duplex TCP connection is used for control and negotiation. A one-way UDP path from the server and the player is used for audio data delivery. A second one-way UDP path from the player to the server is used to request that the server resend lost UDP audio data packets.
DNS is a distributed data system that translates hostnames to IP addresses and vice versa. DNS also stores and accesses other information about hosts.
When enabled, the DNS proxy acts as a DNS server for clients on the intranet. A listener is posted on the DNS port. When a DNS request is received from a client, the DNS proxy checks its local DNS cache and returns a response, if available. If the address is not in the cache, the DNS proxy forwards the request to the configured DNS name servers. The proxy caches only the responses of Internet class and Internet address queries.
The client must have the private IP address of the DNS proxy configured as the address of its DNS server.
On the server, you can set up the IP addresses of the DNS name servers and the domain name in the sys:\etc\resolv.cfg file.
The HTTPS proxy provides the ability to access secure sites using SSL over a persistent IP connection. The browser sends an HTTPS request as an SSL request through the proxy, which then tunnels the request to the origin Web server.
This feature enables a proxy to authenticate through a SOCKS 5 firewall. This release also supports the forwarding of HTTP traffic only.
SOCKS is a circuit-level gateway protocol. With SOCKS, hosts behind a firewall can gain full access to the Internet without full IP support. When SOCKS support is enabled, all requests sent to the Internet are forwarded to a SOCKS 5 server when the proxy is used for caching only.
When the proxy receives a request, it checks its cache. If the requested object is not in the cache, the proxy makes a TCP connection to the SOCKS server and redirects the request from the intranet to the SOCKS server, allowing for more secure Internet access. The SOCKS server then connects to the origin server and retrieves the object. The proxy simply acts as a SOCKS client to the SOCKS server and is used for caching only. Null (no username or password) and username/password authentication are supported.
This release requires that the proxy server and the SOCKS server are both on the same intranet. The reason is that in the username/password combination, SOCKS authentication uses clear text to send the password.
A generic proxy is a circuit-level, pass-through proxy used to serve multiple protocols when an application proxy is not available. A mapping is created between the address and ports, creating a tunnel to the destination host. When the generic proxy server receives a connection request from the intranet, it forwards the request to the mapped address, connects to it, and transfers data between the two connections.
To establish connections using TCP services for which there is no application proxy, a generic TCP proxy should be set up at the proxy server. You can also define a generic UDP proxy. When connecting to the proxy, the user is connected to the internal host. Authentication is available for a generic TCP proxy. A user must be authenticated using access control list rules before connecting to a remote host. Authentication is not available for a generic UDP proxy.
You can apply access control rules to a generic TCP proxy. Access can be allowed or denied based on the following:
The IP address or hostname of the original host
The port number associated with the origin host
The IP address of the source host in the intranet
There are two types of transparent proxies:
A transparent proxy can be implemented for HTTP using either of the following features:
On the server using the HTTP Transparent proxy feature
On the client using the gateway client transparent proxy feature
An HTTP Transparent proxy enables users to use their Web browsers without reconfiguring each browser to point to a proxy. This feature is useful if you have limited time and cannot immediately reconfigure the browsers for all your users. It is also useful when you want to enforce network security and ensure that all client requests pass through a proxy.
The HTTP Transparent proxy intercepts traffic between the client and the origin Web server, and funnels it to a proxy server. Relative URLs are translated to absolute URLs. For HTTP Transparent proxy only, traffic from a configurable list of ports or IP addresses is intercepted. Only the ports or addresses on the list participate in forwarding traffic to the proxy.
To use HTTP Transparent proxy, you must ensure that all HTTP requests are sent through the proxy server. Therefore, the proxy server must be the default router or provide the only access to the Internet.
A transparent proxy can be implemented for Telnet using the Telnet Transparent proxy.
A Telnet Transparent proxy enables users to use their Telnet application without reconfiguring their applications to point to a proxy. This feature is useful when you want to enforce network security and ensure that all client requests pass through a proxy.
The Telnet Transparent proxy intercepts traffic between the client and the origin Telnet server and funnels it to a proxy server. For the Telnet Transparent proxy only, traffic from a configurable list of ports is intercepted. Only the ports on the list participate in forwarding traffic to the proxy.
To use a Telnet Transparent proxy, you must ensure that all Telnet requests are sent through the proxy server. Therefore, the proxy server must be the default router, be in the routing path, or provide the only access to the Internet. IP forwarding must be enabled on the server.