Home > Articles > Security > Network Security

Inside Network Perimeter Security: Proxy Firewalls

This chapter describes the basics of proxy firewalls and how they may fit into your security architecture. Although proxies are not as popular as they once were, they can still offer value when deployed appropriately. This chapter will help you to understand how proxies work, what their strengths and weaknesses are, and when you may want to use them.
This chapter is from the book

In this chapter, we introduce you to proxy techniques and how they have been used to create proxy firewalls. Proxy firewalls serve a role similar to stateful firewalls. Both are designed to allow or deny access between networks based on a policy. The method they use to accomplish this is very different, though. As described in the last chapter, with a stateful firewall, network connections flow through the firewall if they are accepted by the policy. This type of firewall acts like a router, passing packets through that are deemed acceptable. In contrast, a proxy firewall acts as a go-between for every network conversation. Connections do not flow through a proxy. Instead, computers communicating through a proxy establish a connection to the proxy instead of their ultimate destination. The proxy then initiates a new network connection on behalf of the request. This provides significant security benefits because it prevents any direct connections between systems on either side of the firewall.

Proxy firewalls are often implemented as a set of small, trusted programs that each support a particular application protocol. Each proxy agent has in-depth knowledge of the protocol it is proxying, allowing it to perform very complete security analysis for the supported protocol. This provides better security control than is possible with a standard stateful firewall. However, you only receive this benefit for the protocols included with the proxy firewall. If you must allow the use of a protocol that your proxy firewall does not specifically support, you are reduced to using a generic proxy. Generic proxies do not have any in-depth knowledge of the protocols they proxy, so they can only provide basic security checks based on the information contained within the headers of the packets (IP address, port, and so on).

This chapter describes the basics of proxy firewalls and how they may fit into your security architecture. Although proxies are not as popular as they once were, they can still offer value when deployed appropriately. This chapter will help you to understand how proxies work, what their strengths and weaknesses are, and when you may want to use them.

Fundamentals of Proxying

A proxy acts on behalf of the client or user to provide access to a network service, and it shields each side from a direct peer-to-peer connection. Clients needing to communicate with a destination server first establish a connection to the proxy server. The proxy then establishes a connection to the destination server on the client's behalf. The proxy server sends data it receives from the client to the destination server and forwards data it receives from the destination server to the client. In the process of performing this role, the proxy server can examine the requests to ensure they are valid and allowed by the policy.

The proxy server is both a server and a client. It is a server to the client and a client to the destination server. One way to keep this straight is to call the listening end of the proxy the listener and the initiating side of the proxy the initiator. This leaves the terms client and server for the endpoints.

Another important issue is whether the proxy is transparent to the client. Originally, all proxy servers required clients to be aware of them. This meant that a client's software would need to include specific code to properly use a proxy, and the client would need to be configured to send its requests to the proxy. Client software that was not proxy aware could not communicate through the proxy.

Two approaches were used to overcome this software burden. First, an industry standard proxy protocol was developed. Called SOCKS, it allows client software developers to easily add proxy support to their products. We'll be covering SOCKS in more detail later in this chapter. The second approach was the development of transparent proxies. These products intercept connection requests by masquerading on the fly as the destination server being requested by the client. The transparent proxy then goes on to make the request to the destination server for the client. Using this method, the client is fooled into thinking that it is communicating directly with the server, while the proxy is actually handling the communications.

The following is an example of how a typical request from an internal client to an external server would be handled by a transparent proxy firewall:

  1. The client requests an Internet service, such as HTTP, FTP, or Telnet.

  2. The client computer starts by attempting to set up a session between the client and the server. Assuming the Internet service being requested is TCP based, this begins with the client sending out a SYN packet sourced from the client's IP address and destined to the server's IP address.

  3. The proxy firewall intercepts the connection request and, if allowed by policy, replies with a SYN-ACK packet sourced from the destination server's IP address. It is important to mention that this does require the proxy to be on the network path between the client and the server.

  4. Upon receipt of the proxy's SYN-ACK packet, the client finishes the three-way handshake by sending out the final ACK packet, again destined to the server's IP address. At this point, the client thinks it has a valid TCP connection to the external server. In reality, it only has a connection to the proxy.

  5. The proxy is now responsible for establishing a connection to the external server. It accomplishes this by sending out a SYN packet sourced from its own IP address and destined to the external server. Upon receipt of the server's SYN-ACK packet, it replies with an ACK packet to establish the connection to the external server. At this point, the proxy has two valid TCP connections for the session: one between itself and the client, and the other between itself and the server.

  6. Requests received over the client-proxy connection will be analyzed for correctness and policy compliance. If they are acceptable, the proxy will make a corresponding request using its proxy-server connection. Replies received over the proxy-server connection will also be analyzed for correctness and policy compliance and then, if acceptable, forwarded to the client over the proxy-client connection. This will continue until either side of the conversation terminates the connection.

A traditional, nontransparent proxy would similarly handle the request. However, there would be no need for the IP address manipulations required by the transparent proxy. Instead, the client would know about the proxy and would be able to send the request directly to the proxy server's IP address. In addition, because the client is proxy aware, if there are any special proxy functions for the client to choose from, the client can include this information in the request.

Proxy firewalls are often implemented as dual-homed bastion hosts running a set of proxy agents. Each agent supports one or more Internet protocols. The degree to which each agent understands the protocols it proxies determines how effective the agent can be in managing the connection. A generic agent that supports standard TCP protocols will likely only be able to restrict connections based on the TCP and IP headers (for example, IP address, port, TCP state). This functionality is similar to packet filter firewalls. However, if the protocol to be proxied is not standard, or if additional security functionality is desired, more sophisticated agents are required.

A good protocol to use as an example is the File Transfer Protocol (FTP). Remember from Chapter 2, "Packet Filtering," that FTP does not act like a standard TCP protocol. Instead, FTP uses two different TCP connections to enable file transfer. One (the command channel) is used to send instructions to the FTP server, the other (the data channel) is used to transfer files (see Figure 4.1). This makes it impossible to support FTP with a generic proxy. Unless the proxy agent was aware that this second TCP connection was needed, it would not be able to accept the second connection, blocking the FTP protocol from transferring files.

Figure

Figure 4.1 FTP requires two TCP connections to transfer files across a network.

An agent specifically programmed to support FTP would be able to monitor the individual FTP commands being issued over the command channel. It would be able to watch for the command used to transfer a file and then begin listening for the TCP connection used to transfer the file. In addition, by being protocol aware, the agent has the ability to watch the FTP commands to detect suspicious activity.

FTP was created during the early days of the Internet, when security was not something the designers emphasized. The FTP protocol contains several, well-known security flaws that have been repeatedly exploited. Even today, it is not uncommon to locate FTP servers that are not properly protected. One classic flaw is related to how the data channel is set up between a client and a server.

When the client wants to request a file from the server, one option it has is to send a PORT command. PORT is used to configure the server to establish a TCP connection initiated from the server to the client. The format for the PORT command is as follows:

PORT h1, h2, h3, h4, p1, p2

The values h1 through h4 form an IP address (h1.h2.h3.h4). p1 and p2 are used to specify the destination port using the following formula:

  • 256 * p1 + p2

For example, if the client is at IP address 192.168.5.12, it might issue the command

PORT 192, 168, 5, 12, 4, 1

which would tell the server to transfer requested files to IP address 192.168.5.12 using TCP port 1025. To actually cause the connection to be established, the client uses the RETR command to request a file. At this point, the server will initiate the TCP session to the client on TCP port 1025 and transfer the file across the resulting connection.

The vulnerability is introduced because the client can provide any IP address and port to the PORT command. In some circumstances, this can allow an attacker to bypass firewall restrictions. We will use the network shown in Figure 4.2 to illustrate this attack. This network is composed of a screened subnet that contains a web server and an FTP server. To allow customers to upload files to the company, the FTP server is set up to allow anonymous connections. The web server is running a Telnet service to allow administrators to access the system from the internal network. Unfortunately, the Telnet service is susceptible to an invalid input attack that would allow anyone who connects to the service access to the computer without authentication. The good news is that the stateful inspection firewall is blocking all inbound network connections from the Internet except packets destined to TCP port 80 on the web server and TCP port 21 on the FTP server. This would prevent attackers from establishing a connection to the Telnet service running at TCP port 23 on the web server. On the surface it seems that even with the vulnerable Telnet service, the firewall has effectively kept the network secure. This is just an illusion, though, as the FTP server can be leveraged to reach the web server.

Figure

Figure 4.2 Even though the firewall blocks non-HTTP access to the web server, the FTP PORT command may allow attackers to access the web server's Telnet service.

The following steps would allow the attacker to bypass the firewall and attack the vulnerable web server:

  1. Use a normal FTP connection to upload a file to the anonymous FTP server. This file needs to contain the exploit commands necessary to attack the web server.

  2. Using the established FTP command channel, send the command PORT 192,168,5,7,0,23. This will tell the FTP server that the next file request should be sent to the web server using port 23 (for example, Telnet).

  3. Again using the FTP command channel, send the RETR command specifying the name of the file transferred during step 1. This will cause the FTP server to initiate a TCP connection to the web server on port 23, then transfer the contents of the file over the connection.

Assuming the file contains the commands or data necessary to exploit the web server's Telnet service, the attacker will have successfully bypassed the firewall, gaining control of the web server.

A sufficiently sophisticated FTP proxy agent would have had little difficulty blocking this attack at step 2. When the agent receives the PORT command from the client, it could compare the parameters of the command to see if the IP address matches the IP address of the client. If it does not, the connection could be terminated and an alert generated. This is one example of how protocol-aware proxy agents can prevent vulnerabilities that would be difficult or impossible to eliminate using packet-filtering techniques.

Modern proxy firewalls provide proxy agents for a large set of Internet protocols. You can expect the core Internet protocols, such as HTTP, FTP, SMTP, DNS, and ICMP, to be supported by just about all the products. When selecting a proxy firewall, though, you should look carefully at the set of protocols your network will need to pass through the proxy. If a critical protocol is missing from the product you are considering, you may be able fall back to a generic proxy and live with the reduction in security enforcement. If the protocol you are trying to support is nonstandard (such as FTP), you may need to choose between the protocol and the firewall.

InformIT Promotional Mailings & Special Offers

I would like to receive exclusive offers and hear about products from InformIT and its family of brands. I can unsubscribe at any time.

Overview


Pearson Education, Inc., 221 River Street, Hoboken, New Jersey 07030, (Pearson) presents this site to provide information about products and services that can be purchased through this site.

This privacy notice provides an overview of our commitment to privacy and describes how we collect, protect, use and share personal information collected through this site. Please note that other Pearson websites and online products and services have their own separate privacy policies.

Collection and Use of Information


To conduct business and deliver products and services, Pearson collects and uses personal information in several ways in connection with this site, including:

Questions and Inquiries

For inquiries and questions, we collect the inquiry or question, together with name, contact details (email address, phone number and mailing address) and any other additional information voluntarily submitted to us through a Contact Us form or an email. We use this information to address the inquiry and respond to the question.

Online Store

For orders and purchases placed through our online store on this site, we collect order details, name, institution name and address (if applicable), email address, phone number, shipping and billing addresses, credit/debit card information, shipping options and any instructions. We use this information to complete transactions, fulfill orders, communicate with individuals placing orders or visiting the online store, and for related purposes.

Surveys

Pearson may offer opportunities to provide feedback or participate in surveys, including surveys evaluating Pearson products, services or sites. Participation is voluntary. Pearson collects information requested in the survey questions and uses the information to evaluate, support, maintain and improve products, services or sites, develop new products and services, conduct educational research and for other purposes specified in the survey.

Contests and Drawings

Occasionally, we may sponsor a contest or drawing. Participation is optional. Pearson collects name, contact information and other information specified on the entry form for the contest or drawing to conduct the contest or drawing. Pearson may collect additional personal information from the winners of a contest or drawing in order to award the prize and for tax reporting purposes, as required by law.

Newsletters

If you have elected to receive email newsletters or promotional mailings and special offers but want to unsubscribe, simply email information@informit.com.

Service Announcements

On rare occasions it is necessary to send out a strictly service related announcement. For instance, if our service is temporarily suspended for maintenance we might send users an email. Generally, users may not opt-out of these communications, though they can deactivate their account information. However, these communications are not promotional in nature.

Customer Service

We communicate with users on a regular basis to provide requested services and in regard to issues relating to their account we reply via email or phone in accordance with the users' wishes when a user submits their information through our Contact Us form.

Other Collection and Use of Information


Application and System Logs

Pearson automatically collects log data to help ensure the delivery, availability and security of this site. Log data may include technical information about how a user or visitor connected to this site, such as browser type, type of computer/device, operating system, internet service provider and IP address. We use this information for support purposes and to monitor the health of the site, identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents and appropriately scale computing resources.

Web Analytics

Pearson may use third party web trend analytical services, including Google Analytics, to collect visitor information, such as IP addresses, browser types, referring pages, pages visited and time spent on a particular site. While these analytical services collect and report information on an anonymous basis, they may use cookies to gather web trend information. The information gathered may enable Pearson (but not the third party web trend services) to link information with application and system log data. Pearson uses this information for system administration and to identify problems, improve service, detect unauthorized access and fraudulent activity, prevent and respond to security incidents, appropriately scale computing resources and otherwise support and deliver this site and its services.

Cookies and Related Technologies

This site uses cookies and similar technologies to personalize content, measure traffic patterns, control security, track use and access of information on this site, and provide interest-based messages and advertising. Users can manage and block the use of cookies through their browser. Disabling or blocking certain cookies may limit the functionality of this site.

Do Not Track

This site currently does not respond to Do Not Track signals.

Security


Pearson uses appropriate physical, administrative and technical security measures to protect personal information from unauthorized access, use and disclosure.

Children


This site is not directed to children under the age of 13.

Marketing


Pearson may send or direct marketing communications to users, provided that

  • Pearson will not use personal information collected or processed as a K-12 school service provider for the purpose of directed or targeted advertising.
  • Such marketing is consistent with applicable law and Pearson's legal obligations.
  • Pearson will not knowingly direct or send marketing communications to an individual who has expressed a preference not to receive marketing.
  • Where required by applicable law, express or implied consent to marketing exists and has not been withdrawn.

Pearson may provide personal information to a third party service provider on a restricted basis to provide marketing solely on behalf of Pearson or an affiliate or customer for whom Pearson is a service provider. Marketing preferences may be changed at any time.

Correcting/Updating Personal Information


If a user's personally identifiable information changes (such as your postal address or email address), we provide a way to correct or update that user's personal data provided to us. This can be done on the Account page. If a user no longer desires our service and desires to delete his or her account, please contact us at customer-service@informit.com and we will process the deletion of a user's account.

Choice/Opt-out


Users can always make an informed choice as to whether they should proceed with certain services offered by InformIT. If you choose to remove yourself from our mailing list(s) simply visit the following page and uncheck any communication you no longer want to receive: www.informit.com/u.aspx.

Sale of Personal Information


Pearson does not rent or sell personal information in exchange for any payment of money.

While Pearson does not sell personal information, as defined in Nevada law, Nevada residents may email a request for no sale of their personal information to NevadaDesignatedRequest@pearson.com.

Supplemental Privacy Statement for California Residents


California residents should read our Supplemental privacy statement for California residents in conjunction with this Privacy Notice. The Supplemental privacy statement for California residents explains Pearson's commitment to comply with California law and applies to personal information of California residents collected in connection with this site and the Services.

Sharing and Disclosure


Pearson may disclose personal information, as follows:

  • As required by law.
  • With the consent of the individual (or their parent, if the individual is a minor)
  • In response to a subpoena, court order or legal process, to the extent permitted or required by law
  • To protect the security and safety of individuals, data, assets and systems, consistent with applicable law
  • In connection the sale, joint venture or other transfer of some or all of its company or assets, subject to the provisions of this Privacy Notice
  • To investigate or address actual or suspected fraud or other illegal activities
  • To exercise its legal rights, including enforcement of the Terms of Use for this site or another contract
  • To affiliated Pearson companies and other companies and organizations who perform work for Pearson and are obligated to protect the privacy of personal information consistent with this Privacy Notice
  • To a school, organization, company or government agency, where Pearson collects or processes the personal information in a school setting or on behalf of such organization, company or government agency.

Links


This web site contains links to other sites. Please be aware that we are not responsible for the privacy practices of such other sites. We encourage our users to be aware when they leave our site and to read the privacy statements of each and every web site that collects Personal Information. This privacy statement applies solely to information collected by this web site.

Requests and Contact


Please contact us about this Privacy Notice or if you have any requests or questions relating to the privacy of your personal information.

Changes to this Privacy Notice


We may revise this Privacy Notice through an updated posting. We will identify the effective date of the revision in the posting. Often, updates are made to provide greater clarity or to comply with changes in regulatory requirements. If the updates involve material changes to the collection, protection, use or disclosure of Personal Information, Pearson will provide notice of the change through a conspicuous notice on this site or other appropriate way. Continued use of the site after the effective date of a posted revision evidences acceptance. Please contact us if you have questions or concerns about the Privacy Notice or any objection to any revisions.

Last Update: November 17, 2020