Proxy Deployment Strategies

Proxy Deployment Strategies
Dr.MohitBansal Profile Pic
Dr.MohitBansal,Canada,Teacher
Published Date:26-10-2017
Your Website URL(Optional)
Comment
Proxy Deployment Strategies and Challenges A proxy exerts its power and control on a network as an intelligent security device through its ability to perform deep trafc a fi nalysis in the context of an applica - tion and its users. One measure of the effectiveness of the proxy is its ability to intercept application trafc w fi ithout interrupting the application or causing any side effects. An application being affected by a proxy can exhibit symptoms such as being unresponsive to user commands, engaging in transactions with sporadic data flows and unpredictable response times, and sometimes ceasing to function completely. Another metric that gauges the effectiveness of a proxy is its level of stealthiness while the proxy is active. When a proxy is stealthy, it can avoid being detected by both the application and its user. After its successful incursion into a network, as part of its continued assail- ment, a sophisticated malicious application performs middle‐box detection to avoid being discovered by the security proxies. Once a malicious application detects the presence of a proxy, it begins executing countermeasures such as changing its encryption methods, altering its communication patterns, mas- querading as another victim, or sending a notic fi ation to its command‐and‐ control server seeking further instructions. The proxy must hide itself from such applications so it can continue to surveil, pursue, and ultimately apprehend the malicious source. The strategic physical placement of the proxy in the network determines the amount of network activity that may be subjected to proxy examina- tion. The types of deployments demand that the proxy perform supporting 3738 Chapter 2 ■ network functions that are commonly found in a bridge or in a router. In this chapter we will discuss the various challenges of deploying a security proxy and describe the solutions that can either solve or alleviate these deployment issues. Den fi itions of Proxy Types: Transparent Proxy and Explicit Proxy A proxy’s visibility to a user or to an application defines whether the proxy is a transparent proxy or an explicit proxy. The following example illustrates the char- acteristics of a transparent proxy. When Bob communicates with Alice through a peer‐to‐peer (P2P) application, such as an instant messaging (IM) application, once a transparent proxy intercepts this IM session, that transparent proxy masquerades as Bob when it speaks to Alice, and it masquerades as Alice when it speaks to Bob, all without either Bob or Alice knowing such an impersonation is taking place during that session. Also, no explicit cong fi uration change is necessary in either Bob or Alice’s IM application settings. The goal of the trans- parent proxy is to be as invisible as possible to both the client and the peers that the client communicates with. The application protocol operates normally and is completely unaware it is exchanging packets with a proxy. In this example, Bob and Alice did not give explicit consent to the interception of their session. Unlike a transparent proxy, a user is aware of the presence of an explicit proxy. The application is explicitly cong fi ured to transmit certain types of trafc t fi o the proxy for processing. For example, in the Firefox web browser, under the Advanced ➢ Network menu, various proxy cong fi uration settings are available in the Connection Settings panel that specify how to access external networks through various proxies. As shown in Figure 2-1, the SSL proxy setting contains the IP address of the SSL proxy. When the user enters a URL that requires HTTPS transport, the browser will forward this request to the cong fi ured proxy. In the case of an explicit proxy, because a user has chosen to communicate through a proxy, the user gives explicit consent for the interception. As shown in the Firefox Connection Settings panel, each explicit proxy is specie fi d by an IP address and a port number, which means the following: ■ An explicit proxy does not masquerade as the client or the server. ■ An explicit proxy can be physically situated anywhere on the network as long as there is a routing path between the client and the explicit proxy, as depicted in Figure 2-2. ■ Multiple explicit proxies can co‐exist in the same infrastructure, each offering a different set of proxy services. Also, each proxy can be located on separate network segments. In Figure 2-2, the SSL proxy is directly connected on the same physical network segment as client A and client B. Chapter 2 ■ Proxy Deployment Strategies and Challenges 39 The SOCKS proxy is one routing hop away from both clients, as is the HTTP proxy. Client A and client B can request proxy service from any of these explicit proxies. ■ The IP address combined with the port number identifies the service access point where the proxy performs the connection interception. In this example the SSL proxy is located at IP address 10.9.45.3, and it is listening on port 443 for incoming interception requests to service. ■ Because the explicit proxy can be located anywhere on the network, the proxy must use a source IP address that is different from the client’s IP address when the proxy connects to the originally intended destination after intercepting the client‐side request. We will discuss the types of source IP addresses that can be set for a proxy‐initiated connection in more detail in a later section titled “Challenges of Transparent Interception”. Figure 2-1: Configuring Proxy Settings in the Firefox Browser If the client sends its request to the proxy or if the application connects explicitly to the proxy, how does the proxy know what the original intended destination is for a given transaction? An application protocol needs to contain enough destination information in its protocol requests in order for the explicit proxy to function properly. For example, for an HTTP transaction the web browser will issue a full URL in its HTTP request if the “HTTP proxy” setting is defined in the browser, as in GET http://www.mywebsite.com/index.html HTTP/1.0.R e q u e s t f r o m C l i e n t B 40 Chapter 2 ■ Proxy Deployment Strategies and Challenges Intranet SSL Proxy SOCKS Proxy A Internet B HTTP Proxy Clients/Users Explicit Proxy Figure 2-2: Explicit Proxy Deployment Even when the browser sends the partial URL, as in GET /index.html HTTP /1.0, the HTTP protocol specic fi ation provides the Host field in the HTTP request header that specifies the original intended destination and can include an optional destination port number. The destination can be a server name that is expressed as a fully qualie fi d domain name (FQDN) or by an IP address. The proxy extracts the destination from the Host field when it makes the outbound connection on behalf of the client. As this example illustrates, implementing an explicit proxy is possible only if an application protocol understands the concept of a proxy and provides a level of protocol support for operating with a proxy. However, the majority of application protocols are designed to run independently, without any proxy intervention. A transparent proxy is most likely the best method of deployment to intercept and process trafc f fi rom these types of applications or protocols. For the remainder of this book, we will use the terms intercepted, proxied, and terminated trafc i fi nterchangeably to describe trafc t fi hat is intercepted and processed by a proxy, either transpar - ently or explicitly. R R e e q q u u e e s s t t f f r r o o m m C C l l i i e e n n t t A A Chapter 2 ■ Proxy Deployment Strategies and Challenges 41 Inline Deployment of Transparent Proxy: Physical Inline and Virtual Inline Transparent inline deployment offers the most flexibility to a proxy with respect to security policy enforcement, for the simple reason that the more traffic that is accessible to the proxy, the more traffic can be subjected to proxy examination and subjugated under policy control. The inline deploy- ment can be categorized as either physically inline or virtually inline. All trafc fi on a network segment traverses the transparent proxy when that proxy is deployed physically inline. With virtual inline deployment, a cong fi urable option is available to send either a selected subset or all of the network trafc fi to a transparent proxy. Because network operations are commonly separate from security opera- tions, network administrators, not being security engineers, are typically reluctant to deploy a proxy inline. The main reason is because network management is mostly concerned with optimal network resource assign- ment and utilization and maximization of network performance and uptime; ultimately network management is about attaining and maintaining the best end user experience. On the other hand, security operations generally focus on risk assessment, threat and vulnerability identification, and asset protec - tion. Oftentimes security operations are viewed as a hindrance to network performance and an inconvenience for end users. Therefore, in addition to providing security capabilities and solutions, a proxy must strive to achieve scalability and stability, and equally as important from a network operation perspective, a proxy must minimize its effects on network traffic and “not break any applications”. Physical Inline Deployment With physical inline deployment, a proxy is physically situated in a network as a bump in the wire, as shown in Figure 2-3. A transparent proxy typically installs in it a bypass network adapter for each network segment that it is attached to. A bypass network adapter, called a bypass card for short, is a special network device with built‐in hardware circuitry that can be programmed to behave like a piece of wire after losing power or after the proxy stops activity (possibly due to a software crash) for a predetermined period of time from the software perspective. In the case of either hardware or software failure, this fail‐to‐wire feature is crucial to assure operational continuity in a production network. The network users must not be affected by the proxy outage or else lost productiv- ity could be costly. At a minimum, the bypass card has two physical ports. It is this pair of ports that are connected by the special circuitry to become a wire during a system failure or loss of power.42 Chapter 2 ■ Proxy Deployment Strategies and Challenges Intranet Internet LAN WAN Port Port Proxy Router Clients/Users Figure 2-3: Physical Inline Deployment The transparent proxy must provide various networking capabilities that are crucial to its normal operation with this physical inline deployment scenario. One of these networking capabilities is that the proxy must operate as a transparent learning bridge. As a bridge, all of the network interfaces run in the promiscuous mode to enable the proxy to receive all packets. Under normal conditions the bypass card operates as a regular network interface, and the proxy treats each port as a separate bridge port. The promiscuous mode of operation implies the transparent proxy must make the right decision on whether to intercept specic fi trafc fl fi ows. Consider the case where a transparent proxy intercepts a connection when both of its source and destination end points reside on the same physical network segment. Both the proxy and the destination will respond to the con- nection request, but the source will connect to the one that responds first. The communication will incur an unnecessary delay if the proxy responds first. Because the security policies implemented in the proxy are designed to provi- sion trafc t fi hat takes place between entities that reside on different networks, the involvement of the proxy is unproductive and provides no security benet fi s in this scenario. With the learning bridge, the proxy compares the bridge ports where the source and the destination are known to reside on. Matching bridge ports indicate that the source and the destination end points are located on the same network segment, and as such the proxy will not perform interception. The proxy translates policies such as “do not intercept any trafc f fi rom the CEO” or “do not intercept any banking transactions on the enterprise network” into explicit trafc b fi ypass policies. The proxy must bridge any trafc t fi hat it does Chapter 2 ■ Proxy Deployment Strategies and Challenges 43 not intercept due to explicit bypass or because the trafc d fi oes not match any interception rules. Therefore, the proxy must learn the MAC addresses on all of the bridge ports and perform all the necessary bridging functions. Another network capability designed into the proxy is the routing function. A sophisticated proxy can participate in the interior gateway protocol (IGP) by listening to the routing protocol exchanges. The proxy can extract the current routing infrastructure from the routing protocol exchanges and build a dynamic routing tree from routing protocols such as Open Shortest Path First (OSPF) or Routing Information Protocol version 2 (RIPv2). Doing so reduces the con- g fi uration requirement in the proxy and enables the proxy to enforce security policies without impacting existing trafc e fi ngineering practices. In addition, a proxy with routing capability can implement and enforce policy-based routing (PBR) for intercepted trafc fi . One of the main challenges of physical inline deployment is performance and scalability. Unlike a switch or a router that processes L2 or L3 headers, a proxy performs much more complex operations such as TCP connection termination and L7 request parsing. Because an intelligent proxy needs to examine payload information beyond L4 headers, the so‐called fast‐path processing commonly found in traditional networking devices is not applicable to a proxy. Fast‐path processing refers to hardware‐assisted packet processing that relies on extract- ing bytes from packet headers, possibly from various offsets, and applying fixed logic to the packet based on pattern matching or value comparison. In other words, the proxy performs all of the networking functions in the software, including bridging and routing functions. For high‐speed gigabit networks that are now common in large and small organizations, the proxy becomes a potential bottleneck: the higher the number of protocols and applications the proxy is capable of intercepting, the lower the network throughput that is achieved through the proxy. Virtual Inline Deployment With virtual inline deployment, a trafc fi redirector such as a router, a switch, or a load balancer sends the selected trafc t fi o the proxy as illustrated in Figure 2-4. We will discuss trafc r fi edirection shortly. The proxy returns the trafc fi , proxied or unmodie fi d, to the trafc r fi edirector, which then forwards the trafc t fi owards the intended recipients, again according to either routing or trafc r fi edirection policies. As such, with virtual inline deployment the proxy can be physically located anywhere in the network, as long as the trafc r fi edirector can reach the proxy through normal routing. An interesting characteristic of the virtual inline deployment scenario is that the proxy is physically placed out of the main network paths, as shown in Figure 2-4. There are two main advantages to this approach: increased scal- ability and improved reliability. Virtual inline deployment resolves the proxy WCCP or PBR redirection 44 Chapter 2 ■ Proxy Deployment Strategies and Challenges scalability challenge by redirecting to the proxy only trafc t fi hat is intended for interception, while performing bridging and routing functions for the remaining trafc t fi ypes on separate appliances, in most cases regular routers and switches. The second main advantage of virtual inline deployment is a reduction in the intrusiveness of introducing a proxy into the network. The administrator can gradually increase the number of applications for redirection to the proxy, according to the operational performance metrics of transparency, accuracy, and reliability of the interception obtained on the existing redirected trafc fi . This approach improves the overall network reliability and user experience, while enabling the administrator to discover the breaking points for the proxy in terms of performance or reliability with the mixture of applications and protocols. This method of redirecting more trafc i fi ncrementally also allows the administrator to enhance and calibrate the policies being enforced by the proxy with minimal user impacts. Another advantage of virtual inline deployment is that this approach does not require a network redesign and is more flexible in introducing additional supplemental solutions that collaborate with the proxy, such as a content inspection solution or a sandboxing solution. Intranet Proxy LAN WAN Internet Clients/Users Router Figure 2-4: Virtual Inline Deployment Traffic Redirection Methods: WCCP and PBR In practice, there are two main methods of trafc r fi edirection for implementing virtual inline proxy deployment: through Web Cache Communication Protocol (WCCP) or policy-based routing (PBR). WCCP is a Cisco proprietary protocol that was designed for trafc r fi edirection, with built‐in load‐balancing and fault Chapter 2 ■ Proxy Deployment Strategies and Challenges 45 tolerance. The router that implements the WCCP protocol is called a WCCP router. The WCCP protocol exchange facilitates the automatic detection of a router or a proxy failure and enables a rediscovery and recovery process to take place automatically in order to resume normal operations quickly. A service group is established between one or more routers that perform the trafc r fi edirection and one or more devices that receive and process the redirected trafc fi . The service group specie fi s the types of trafc t fi o be redirected and helps the proxy to dif - ferentiate regular trafc fi from redirected trafc fi . Trafc fi selection can be based on source and destination IP addresses, source and destination ports, and the protocol type. The proxy describes the details of the service group to the WCCP router in a specic W fi CCP protocol packet. When the WCCP router redirects the trafc t fi o a proxy, the trafc c fi an be encap - sulated in a GRE tunnel or by means of an L2 destination MAC address rewrite. The WCCP protocol allows the WCCP router and the proxy to negotiate which redirection method to use. The advantage of using a GRE tunnel for encapsu- lating redirected trafc i fi s that the WCCP router can be multiple routing hops away from the proxy. This is because the GRE packets are transmitted over IP packets, and the source and destination IP addresses can reside on different IP networks. The disadvantage of using a GRE tunnel is the possible overhead of packet fragmentation and reassembly. Adding a GRE header to the redirection packet may exceed the MTU, thus requiring packet fragmentation at the WCCP router and reassembly at the receiving proxy. Redirecting trafc b fi y rewriting the L2 destination MAC address is simpler to deploy but requires the WCCP router and the proxy to be connected to the same physical network segment. Because WCCP is a proprietary protocol, its implementation is vendor‐specic fi , and each new release may create incompatibility with the existing third‐party software that implements WCCP. PBR is a popular alternative to WCCP. PBR works similarly to WCCP L2 redirection, but it is even simpler to operate because PBR does not rely on a separate control protocol to negotiate a trafc r fi edirec - tion method. Once the physical network connectivity is established between the router and the proxy and the trafc s fi election or matching rules are defined in the router, simply cong fi uring and installing the appropriate routing rules into the router enables PBR into action. There are several drawbacks with PBR. For example, it lacks automatic load balancing capability when multiple proxies are present. Also, although PBR can be used to redirect trafc fi to a proxy that is located multiple routing hops away, the routers along the path must be cong fi - ured to perform the same redirection in order for this scenario to work. This is because PBR rewrites the destination MAC address of each packet to that of the redirection target. Therefore, each router on the path to the proxy must be explicitly cong fi ured with its respective next‐hop router for the trafc t fi ypes to be redirected. Another challenge with PBR is its difc fi ulty in implementing an external bypass and failover solution. When a proxy becomes unresponsive due to either a software or hardware malfunction, a bypass mechanism also exists with virtual inline deployment; 46 Chapter 2 ■ Proxy Deployment Strategies and Challenges this bypass mechanism is called an external bypass. In the case of WCCP, the WCCP protocol enables the router to detect a non‐responsive proxy. Assuming a single proxy is present in the service group, the WCCP router will consequently cease redirecting trafc fi to that unresponsive proxy until that proxy resumes participation in the WCCP protocol exchange. Trafc t fi hat was meant for redirec - tion is simply routed according to exiting network routing policies during the proxy downtime. This bypass mechanism is initiated by the WCCP router and is performed automatically, and the physical bypass is external to the proxy. Obviously, the router will redirect the trafc t fi o an alternative proxy if another proxy is present in the service group. In PBR the detection of a non‐responsive proxy is not an active process like that in WCCP. With PBR the routing paths are fixed. Although redundancy or failover may be an option, such a feature is implementation‐dependent. For example, if the device implementing PBR is a Cisco router, then the automatic failover mechanism requires the deployment of a Cisco Discovery Protocol (CDP) to detect a failed proxy and then redirect trafc t fi o an alternative one. In this case, the proxy must also implement the CDP in order to allow for the detection mechanism to work. As such, an external bypass may not be possible with PBR due to additional feature requirements. LAN Port and WAN Port There are typically two network interfaces (or more precisely two physical ports) installed in the proxy. These network interfaces can be either physical interfaces or virtual interfaces. A VLAN is a type of virtual interface. Referring back to Figure 2-3, with the physical inline deployment scenario there is a pair of physi- cal ports belonging to a single special bypass network adapter, which connects the proxy on the physical link as a bump in the wire. A common practice is to connect one port towards the internal segments of the network and mark it as the LAN port and to connect the other port towards the network egress point and to mark it as the WAN port. In practice, the LAN port, also known as the inside port, has security and interception policies that are quite different from those designated for the WAN port, also known as the outside port. We will use the terms LAN port and inside port interchangeably. We will also use the terms WAN port and outside port interchangeably. As we show in Figure 2-4, for a virtual inline deployment the proxy can be deployed using a single physical network interface that has a single physical port, which is allowable because a physical bypass is not a requirement. In this case multiple VLANs will be cong fi ured over this physical interface such that one VLAN interface is designated as the LAN port while another VLAN interface is designated as the WAN port. This cong fi uration is mandatory for the WCCP and PBR redirection methods because the proxy must cong fi ure and enforce security policies differently for each port. www.allitebooks.com Chapter 2 ■ Proxy Deployment Strategies and Challenges 47 Forward Proxy and Reverse Proxy The designations of LAN port and WAN port affect another categorization of proxies: forward proxy and reverse proxy. For a forward proxy, trafc i fi ntercep - tion takes place on the inside port but not on the outside port, while for a reverse proxy, trafc i fi nterception takes place on the outside port but not on the inside port. We need to give definitions for forward proxy and reverse proxy before we can explain the reasons and the types of policies that are set on the inside and outside ports. Figure 2-5 illustrates the concepts of forward and reverse proxies. Forward Proxy Intranet Egress Router Proxy Internet Outbound Requests Clients/Users Reverse Proxy Intranet Ingress Router Proxy Internet Inbound Requests Servers Figure 2-5: Forward Proxy versus Reverse Proxy48 Chapter 2 ■ Proxy Deployment Strategies and Challenges A forward proxy is deployed closest to the clients and users who actively seek access to network contents and resources and request services from servers that are located on either the intranet or the Internet. A forward proxy examines externally bound connection requests that are initiated from clients that are internal to the intranet. The goals of the forward proxy may include enforcing an organization’s use policies, conducting content filtering, and providing access logging that tracks users and resources to meet compliance requirements. A reverse proxy is deployed on the server side, which intercepts all incom- ing requests coming from the Internet. A reverse proxy is typically deployed in front of a group of servers, commonly known as a server farm, and offers various protections for the server or the server farm. For example, the reverse proxy protects server identities by exposing a single service access point to the outside world. Once the reverse proxy intercepts each request, the proxy performs rigorous validation on the request against known attacks. Once the request passes the validation phase, the proxy then distributes the request to a server based on some precong fi ured load‐balancing algorithms, thus reducing the chance of overloading a specic s fi erver. With a reverse proxy the servers do not have to individually implement various security features against threats such as cross‐site scripting and SQL injection. The reverse proxy can also centralize the authentication implementation. Challenges of Transparent Interception A transparent proxy may not have any IP address assigned to any of its inter- faces if it is deployed physically inline as a bump in the wire or virtually inline through L2 redirection. So, what IP address would the proxy use after it inter- cepts a transaction and initiates a connection to the original destination? There are two main approaches to assigning a source IP address for a proxy‐initi- ated outbound connection. The first approach is to cong fi ure one or more IP addresses, called virtual IP addresses, into an address pool that is maintained by the proxy. The proxy may choose an address from this pool when initiating a connection on behalf of an intercepted transaction. These IP addresses are routable towards the proxy because ultimately the proxy must be able to receive the return trafc t fi hat is destined to these IP addresses. There are several issues associated with this source IP address assignment solution. The original cli- ent IP address is hidden once the proxy intercepts the trafc fi ; only the proxy’s addresses are visible. One issue is that the server may reject proxy‐originated requests if the server utilizes IP address‐based authentication. In its simplest form, address authentication refers to a server that uses a client’s IP address as a form of authentication. A good example is a banking website that keeps track of a client’s IP address once the client passes various security challenges interactively for the first time. When the client accesses the same service using Chapter 2 ■ Proxy Deployment Strategies and Challenges 49 a different IP address, the banking site will reissue those security challenges to revalidate the client’s authenticity. In a more restricted environment, the client is prohibited from accessing a service unless the client is using a designated workstation that is locked to a specic I fi P address. In such cases the proxy will break the service and prevent the client from ever successfully establishing a connection with the server. Another issue with using a virtual IP address is that the presence of a proxy may negatively impact IP address‐based network bandwidth management solutions. As shown in Figure 2-6, a network appliance that enforces IP address‐ based QoS policies will become ineffective because the client IP addresses will have been replaced by the proxy’s address. As depicted in the figure, the band - width management appliance has a QoS policy defined for each of the clients to restrict bandwidth usage. Because the proxy sets the source IP address for all server‐bound packets to one of its virtual IP addresses, none of the QoS policies will match any of the client trafc fi . Therefore, all of the clients will have unrestricted bandwidth utilization, and the proxy essentially has defeated the QoS management objectives. Dedicated Bandwidth IP A Proxy Management Device QoS Request with Source IP A Request with a Single Source IP X Interception IP B Request with Source IP B Bandwidth Allocation Request with Source IP C IP A 128 kbps IP B 256 kbps IP C IP C 128 kbps Figure 2-6: Transparent Interception with Virtual IP Negates QoS Policies Therefore, a proxy may spoof the client IP address. Called IP spoon fi g , this is another source address assignment solution to solve the problems associated with virtual IP addresses. With IP spoofing the proxy uses the source IP address of packets from the original request as the source IP address for its outbound connection after it intercepts the client connection. This method comes with its own set of deployment challenges. For example, all of the routing paths to the client IP address must pass through the proxy. Consider the example depicted in Figure 2-7. The server responds to the proxy’s request by sending the trafc fi to the client’s IP address. In this case the return trafc i fi s routed through a path that does not traverse the proxy, but instead reaches the client directly ( ). This ③ No enforcement No rules matching in the QoS appliance QoS Policies50 Chapter 2 ■ Proxy Deployment Strategies and Challenges is an instance of asymmetric routing where the routing path taken in one direc- tion is different from the routing path taken in the reverse direction. Because the client does not have a connection state for this particular trafc fl fi ow, the client resets the connection and causes the overall transaction to fail ( ). The ④ server‐returned trafc c fi an also reach the client directly when the proxy fails and its bypass adapter activates into the fail‐to‐wire mode. Response Response 3 Proxy Server Response Reset 4 Internet 1 2 Client Client Request Request Server Request Figure 2-7: Asymmetric Routing Breaks Interception One of the key challenges of virtual inline deployment is to ensure that both the forward direction trafc a fi nd the return trafc t fi raverse the proxy, especially when the proxy is using the client’s IP address as the source IP for its trafc fi . A common error found in the WCCP deployment is that the return trafc i fi s not redirected to the proxy, thus creating asymmetric flows for intercepted connections. Now, what happens if the client actually has a connection state that matches the returned trafc fi ? A packet storm may ensue for a TCP‐based transaction. This issue occurs more often than many believe. Consider the scenario depicted in Figure 2-8. The server is communicating with the client directly after the proxy has failed. From the server perspective, it is transmitting the TCP packets in sequence (①). From the client perspective, although the incoming connection is valid and is in the established state, the data packet received is not in the expected sequence number range. In this example the client is expecting a TCP packet with sequence number 10 but instead receives a packet with sequence number 25 (②). From the client’s perspective there is a missing TCP segment. In this case the client’s TCP implementation transmits a TCP ACK packet specify- ing the sequence number of the next expected data packet. The server’s TCP Path 2 Path 1 ResponsePacket stor m ensues Failed to wire Chapter 2 ■ Proxy Deployment Strategies and Challenges 51 implementation receives the client TCP ACK packet and treats it as a duplicate ACK packet, because the sequence number the client is asking for is in the past; that is, the data that the client is asking for has already been fully acknowledged and is no longer available ( ). The server retransmits the TCP packets, and the ③ client responds exactly the same way as before ( ). Because the server contin- ④ ues to receive valid TCP ACK packets, it does not terminate the connection, even though it views the packets as duplicates. Similarly, the client keeps the connection open. At this point this ping‐pong exchange with the exact same sequence of packets from the client and server repeats indefinitely and causes a rapid packet storm on the network. Proxy Server Client 10.1.1.1:80 1 192.103.1.100:2100 TCP SEQ = 25 ACK = 15 2 3 192.103.1.100:2100 10.1.1.1:80 TCP SEQ = 20 10.1.1.1:80 4 ACK = 10 192.103.1.100:2100 TCP SEQ = 25 ACK = 15 Figure 2-8: Packet Storm Caused by Failed‐to‐Wire Due to Proxy Failure To solve the aforementioned packet storm problem, the proxy implements a source port selection process as a solution to reduce the chance of a collision in the client’s connection space when the proxy performs transparent interception Missing 15 bytes, request retransmission Duplicate ACK, packets before SEQ 25 has been acknowledged Repeat the same sequence of packet exchange52 Chapter 2 ■ Proxy Deployment Strategies and Challenges with client IP spoofing. The TCP port space is a 16‐bit value for a total of 65,536 unique port numbers. However, out of this 64K port space, ■ port range 0 to 1023 are well‐known ports or reserved system ports; ■ port range 1024 to 49151 are registered ports that are assigned by IANA to entities based on official port assignment requests; and ■ port range 49152 to 65535 are dynamic ports, also called ephemeral ports; these ports can be used by any application for any purpose. When the proxy initiates an outbound connection that is associated with an intercepted transaction, the destination IP address and the destination port remain the same as the original client’s connection. The proxy picks a source port out of the ephemeral port range containing 16,384 unique port numbers. This concept is illustrated in Figure 2-9. Proxy Internet Client-Originated Conncetion Proxy-Initiated Conncetion Client Server Source IP : Source Port Source IP : Source Port 10.1.1.2 : 50000 10.1.1.2 : 62000 Destination IP : Destination Port Destination IP : Destination Port 192.103.68.1 : 80 192.103.68.1 : 80 Figure 2-9: Connection with Proxy IP Address Spoofing For a specic d fi estination, when applying client IP spoofing for outgoing con - nections, the proxy needs to pick a source port that is different from the original client‐selected port, but the port that is chosen must also not collide with other connections the proxy has already initiated on behalf of that client. In addition, the proxy needs to choose a port such that the selection does not collide with existing connections to that destination, which are not intercepted by the proxy but are managed by the client. In a typical large‐enterprise network with thou- sands of users, the connections‐per‐second (CPS) rate is in the range of 100,000 to 180,000. The source port could deplete rapidly even if the interception rate is just 10 percent of the CPS rate. The packet storm problem caused by transparent interception with client IP spoofing is an NP‐complete problem; in other words, no solution solves this problem completely. Instead, the proxy implements vari- ous strategies to reduce the possibility of such a problem occurring. Source port is now different With client IP spoo ng Chapter 2 ■ Proxy Deployment Strategies and Challenges 53 Directionality of Connections A transparent proxy may process a connection in a specic w fi ay depending on the directionality of the TCP o fl w; for example, a policy may state, “intercept all trafc t fi hat is destined for IP address 100.1.2.3”. The directionality of a TCP flow is defined by which end point transmitted the initial TCP SYN packet. The proxy cannot identify the directionality of a flow unless it has seen the SYN packet. Now consider the scenario where some failure has occurred within the proxy and it has begun operating in the bypass mode. The proxy does not perform any interception and does not keep any connection states while it is in the fail‐to‐ wire mode. Clients continue to make service requests and initiate connections to destinations and servers on the Internet during the proxy outage period. At a later time after the proxy resumes its normal operation, any connection that has 100.1.2.3 as either the source or the destination IP address may match an interception policy; however, because the proxy did not process the SYN packet, it cannot resolve the ambiguity in directionality. Therefore, the proxy resets any such connection to force the client to reestablish that connection so that the proxy can then execute and apply the policy against those transactions appropriately. This conservative method of resetting a transaction to resolve ambiguity also applies when the policy changes, a topic that we discuss in detail in Chapter 3. Consider another example where the proxy enforces the following policies: ■ All traffic that is destined to TCP port 443 will be intercepted. ■ All trafc c fi oming from IP address 100.1.2.3 will be bypassed. When the proxy receives a flow with source IP address 100.1.2.3 and source TCP port 443, the proxy does not know how to process this flow unless it knows the directionality of the connection. That is because this flow can match either policy, depending on the flow direction. If the initial TCP SYN packet has 100.1.2.3 as the destination address, then the flow matches the TCP port 443 interception policy; in this case the proxy will have intercepted that connection. However, if 100.1.2.3 transmits the TCP SYN packet, then the flow will match the bypass policy, and in that case the proxy will have bypassed that connection. This ambiguity cannot be resolved unless the proxy knows the flow direction; as such, the proxy will reset the connection for reasons explained previously. Similarly, this flow directionality issue also affects interface‐based interception rules. As discussed earlier, a proxy acting as a forward proxy performs trafc fi interception on the LAN port but not on the WAN port. If the proxy does not know the flow direction, it cannot apply the interface‐based policies correctly. Maintaining Traffic Paths When a transparent proxy does not have an IP address assigned to any of its interfaces, there will not be any routing configuration in the proxy. So 54 Chapter 2 ■ Proxy Deployment Strategies and Challenges how does the proxy know on which interface to respond to the client request and on which interface to transmit the server‐bound connection? There are situations where even when the proxy has IP addresses assigned and with a populated routing table, the proxy may still need to circumvent its own routing lookup and instead utilize the information contained in the client request to make transmission decisions. Consider the example illustrated in Figure 2-10. Router-1 Router-2 Load Balancer Client Request Request Request Proxy Figure 2-10: Use Source MAC to Take the Same Path Towards the Client The client request first reaches a load balancer. The load balancer then distributes the traffic among three different routers. In this case the client request is forwarded through Router‐2 to reach the proxy. If the proxy has a single default route installed and that route points to Router‐1 as its default gateway, then the proxy’s response to the client is transmitted through Router‐1. Taking the path through Router‐1 to reach the client negates the benet fi s brought by the load balancer. When responding to the client request, instead of performing a route lookup on the client, the proxy extracts the source MAC address from the client’s request packet and uses that MAC address as the destination MAC address for the response packet. Doing so ensures the response packets will traverse Router‐2 and reach the client through the same path as the incoming request packet because the source MAC address from the client’s request packet belongs to the router interface that forwarded the client packet to the proxy. The proxy may take a similar approach when transmitting a server‐bound connection after intercepting the client request. Consider the example illustrated in Figure 2-11. Use the client request header to transmit trafc through Router-2 Proxy’s routing table points to Router-1 for reaching the client Chapter 2 ■ Proxy Deployment Strategies and Challenges 55 Router-1 Request Network-1 Router-2 Proxy Network-2 Client 12 Client Request Router-3 3 Internet Request Figure 2-11: Use Destination MAC to Reach the Correct Next‐Hop Router In this example the client and the proxy are cong fi ured with different default gateways. Assume the client is connecting to a server that resides in Network‐1. The client request traverses Router‐1 without proxy interception. However, after the proxy intercepts the request, because Router‐3 is configured in the proxy as its default gateway, the outbound request is sent to Router‐3 (②). When Router‐3 receives the request and performs a route lookup, Router‐3 then forwards that request to Router‐1 to reach the intended destination (③). In this case the request takes an extra routing segment unnecessarily. This routing overhead applies to all packets that are part of the proxy‐initiated connection. One solution is to configure multiple specific routes into the proxy. A better solution is to utilize the information provided in the client’s request. The client knows its request to Network‐1 should be sent through Router‐1. This knowledge is reflected in the client request packet’s L2 packet header, which contains Router‐1’s L2 MAC address as the packet destina- tion. Instead of performing a route lookup, the proxy can simply construct the outbound packets with the same destination MAC address as that of the original client request packet. Doing so allows the proxy‐initiated packets to traverse the same path as that of the client’s request packets without the interception. The proxy can extract the destination IP address from the client request packet when it initiates a server‐bound connection after interception. However, the proxy may perform DNS resolution if the hostname is known and uses its own DNS result instead of trusting the IP address from the client. This allows the proxy to offer an extra layer of validation against security issues such as pharm- ing or DNS cache poisoning at the client end. Both pharming and DNS cache poisoning are discussed in detail in Chapter 4. Another reason for the proxy to Proxy’s default router56 Chapter 2 ■ Proxy Deployment Strategies and Challenges replace the original destination IP address is for load‐balancing purposes. The proxy may have knowledge about the client‐provided IP address as being one of many IP addresses that are assigned to a server. Because the proxy intercepts all client traffic to this server, the proxy has a better knowledge of the number of requests that have been submitted to each server IP address. Therefore, the proxy may replace the original destination IP address with one that the proxy believes is a better alternative. Avoiding Interception There are conditions under which the transparent proxy will not perform interception. Static bypass policy consists of one or more rules that have been cong fi ured into the proxy at the start of its operation, which instructs the proxy to avoid intercepting certain types of trafc a fi nd instead to simply bridge or forward that trafc u fi nmodie fi d. For example, an enterprise must legally protect employee privacy if the employee’s action does not violate corporate policies. An employee may conduct an online banking transaction during lunch hour. In this case the proxy is cong fi ured to bypass all banking sites during lunchtime. Another example is where a corporate attorney at a large enterprise is permanently exempt from being examined by a proxy. Legal material exchanged between the attorney and outside entities may be extremely sensitive, and therefore any network trafc t fi hat originates from or is destined to that attorney will never be stored or examined by any network- ing devices, including a proxy. While processing an intercepted transaction, a proxy may decide to bypass such types of transactions in the future. For example, a user request to a des- tination may not match any banking sites, but the proxy may conclude the request constitutes a financial transaction after having analyzed the exchanged content. In this case, the proxy will install a bypass rule at runtime to avoid the interception of similar trafc i fi n the future; this preemptive bypass action is termed a dynamic bypass. A proxy typically has multiple interfaces installed in it. An interface that is dedicated to management trafc fi —such as connections that are established to access the web‐based management console, or for receiving SNMP trafc f fi or device management—will not be cong fi ured to intercept trafc fi . Interception will be disabled on an interface if it is known that intercepting inbound con- nections provides no security benet fi s. Each organization has a network infrastructure design that must satisfy legal conformance and regulatory compliance requirements. The complexity of the network interconnect varies from enterprise to enterprise. An intelli- gent proxy must incorporate design logic that can recognize the traffic source and make an interception decision accordingly. One of the more challenging

Advise: Why You Wasting Money in Costly SEO Tools, Use World's Best Free SEO Tool Ubersuggest.