Secure Management Through Firewalls
Jim Doble, CISSP
Tavve Software Co.
Tavve Software Co.
One Copley Parkway
Suite 480
Morrisville, NC 27560
+1 919-460-1789
http://www.tavve.com
Copyright © 2009 Tavve Software Co
Copyright © 2009 Tavve Software Co
Secure Management Through Firewalls
Executive Summary
Firewall-based network partitioning is a well established and sometimes mandated security
practice, but creates a dilemma for management professionals seeking to provide a centralized,
comprehensive, and unified infrastructure for managing network devices and servers across the
enterprise. Centralized management applications typically rely on the ability to communicate with
devices and servers across the enterprise using ubiquitous management protocols, such as
ICMP and SNMP, but security professionals typically resist creating firewall rules to allow
management protocols, and rightly so, because these protocols were defined years ago and
typically lack the security mechanisms required in today’s threat environment. So how can
companies leverage their existing management infrastructure across the entirety of their firewallpartitioned network, without compromising security?
This white paper will:
1. Explore security concerns associated with managing firewall-partitioned networks.
2. Evaluate solutions for managing firewall-partitioned networks.
3. Demonstrate how Tavve’s ZoneRanger appliance can be used as a management proxy
firewall to extend the reach of management applications, without compromising security.
Introduction
Ongoing evolution of enterprise security and management practice has resulted in a tension
between the two:
•
Security practitioners deploy firewalls in order to control and limit flow of information
between network “zones of trust”. Management protocols such as ICMP and SNMP are
typically prevented from passing through the firewall, because they are old, and relatively
insecure.
•
Management practitioners rely on the flow of management information between centrally
deployed management applications and the network infrastructure devices and servers
distributed throughout the network. Firewalls present an obstacle, blocking the flow of
information necessary for management.
If firewalls are configured to allow the flow of management protocols, security is reduced. If
management protocols are blocked, the ability to provide centralized, unified management is
severely compromised. What is needed is a solution that resolves this tension, enabling
centralized management while not compromising on security.
The use of firewalls to partition networks based on “zones of trust” is a well established and
sometimes mandated security practice. Notwithstanding the sensational headlines and startling
statements associated with groups such as the Jericho Forum, firewalls do not appear to be
going away any time soon. At the same time that some talk about “de-perimeterizing the
network”, we have industry standards, such as the Payment Card Industry Data Security
Standard (PCI DSS) mandating the use of firewalls (i.e. separating the portion of the enterprise
network that deals with credit card information from the portion that does not).
Firewalls essentially serve to block undesirable, unexpected, or inherently high-risk traffic from
passing between network zones that are trusted to different degrees. For example, many
companies deploy their internet-facing servers and infrastructure within a “demilitarized zone” or
Copyright © 2009 Tavve Software Co
1
DMZ, with a firewall separating this zone from the rest of the corporate network. The rationale is
that the internet-facing servers are subjected to less controlled and therefore more dangerous
traffic, and have a higher risk of compromise. Deploying these servers in the DMZ, reduces the
likelihood that compromise will spread further into the corporate network. Similar arguments have
been used to suggest that groups of computers handling human resources, accounting, or other
sensitive information be deployed within their own firewall-protected zones. As a result, the trend
is toward highly partitioned enterprise networks, as illustrated in Figure 1.
Figure 1: Enterprise Network Partitioning
Internal firewall-based network partitioning creates a problem for management professionals
seeking to provide a centralized, comprehensive, and unified infrastructure for configuring,
monitoring, and controlling network devices and servers across the whole enterprise.
Management practice tends to rely heavily on a suite of sophisticated management applications,
which serve to automate the wide variety of tasks required to manage devices: monitoring status,
collecting events and statistics, modifying configurations, and much more. These applications
typically use ubiquitous management protocols, such as ICMP and SNMP, to monitor and control
the devices they are managing. In order to manage the whole enterprise, a centralized
management application deployed in one zone must be able to communicate with all managed
devices, regardless of their network location. If the management application and the device to be
managed are deployed in different zones, the internal firewall becomes an obstacle, blocking the
flow of information between management applications and the devices they are managing, and
defeating the goal of centralized management.
The reason why security personnel prefer to block management protocols is that many of them
are relatively old, having been defined in the days when the Internet was new, and security was
not a significant concern or consideration. As an example, the ICMP protocol, which is neither
encrypted not authenticated, defines an ICMP Redirect packet that can be used to instruct a host
to send traffic destined for a given IP address range to a different gateway address. Who, at the
time, would have imagined that this message could be used to facilitate malicious traffic sniffing
and man-in-the-middle attacks? Initial versions of SNMP that are still in common use are not
encrypted, and are weakly authenticated using “community strings”. It is trivial for an attacker to
sniff the SNMP traffic, obtain the community string, then start sending its own SNMP Get and Set
Copyright © 2009 Tavve Software Co
requests to obtain detailed device information, or worse, change configuration settings. In the
eyes of a security practitioner, today’s management protocols simply pose too great a risk.
So here is where we are: departments responsible for management have invested heavily in
centralized management applications and infrastructure and need to leverage that investment
across the entire enterprise; departments responsible for security are equally attached to their
firewalls, and do not want to open them up to any traffic that might be perceived as a threat.
Something has got to give.
When confronted with this dilemma, enterprises have historically employed a variety of less than
ideal approaches to more or less work around the issue. The prevalent approaches are discussed
in the following section.
Workaround Approaches
The various approaches that have historically been used to work around the problem of
managing through firewalls can be summarized as follows:
1. Ad-hoc Management
In some companies, where the security department has sufficient clout, all traditional
management protocols will be blocked at the firewall, as shown in Figure 2.
Figure 2. Management Protocols Blocked at the Firewall
In such cases, the department responsible for management will frequently resort to ad-hoc
management of devices located in network zones that cannot be reached from the
centralized management applications:
•
Unreachable network zones are treated as a “special case” with respect to
management.
•
Device status can be periodically monitored via SSH or Telnet.
•
Device configuration changes are applied manually.
The fundamental characteristic of ad-hoc management is that devices in unreachable zones
are managed differently, with different tools and/or procedures, which essentially defeats the
goal of unified, centralized management. If the ad-hoc procedures used to manage these
devices are not as strong or rigorous as those used in the reachable portion of the network,
there is an increased risk that outages and/or performance degradation in the unreachable
zones may go undetected for significant periods of time, potentially resulting in negative
financial impact to the business.
Copyright © 2009 Tavve Software Co
2. Define Firewall Rules
If you ask a management application vendor how to extend the reach of their application
beyond a firewall, they will typically recommend that you define firewall rules so that the
required management protocols are able to pass through the firewall, between management
application servers and managed devices.
Figure 3. Management Protocols Allowed by the Firewall
While this sounds simple enough in the context of a single application, the reality, in the
typical enterprise, is far from simple. First of all, each management application may use
multiple protocols, each of which defines its own ports. As a result, multiple rules are needed
just to allow a single management application server to communicate with a single managed
device, as shown in the following figure.
Figure 4. Multiple Ports
On top of that, considering that most enterprises will have hundreds of devices in
unreachable zones that need to be managed, and will typically use multiple management
applications to manage these devices, the number of firewall rules required can become quite
large, as illustrated in the following figure.
Copyright © 2009 Tavve Software Co
Figure 5. Multiple Ports, Multiple Applications, Multiple Devices
There are a number of problems that arise when defining a large number of firewall rules.
First of all, the initial effort to define the rules is large. The more rules you have, the more
likely it is that someone will make a mistake. Remember that complexity is the enemy of
security. The administrative overhead to maintain these rules over time will also be
significant. Due to the associated security impact, some companies require approval by
standing committees for any firewall configuration changes. As a result, the cost of making
necessary ongoing changes will be high, and the time required to complete the approval
process will lead to delayed projects and a perception that the IT department is unresponsive
to business needs.
The other problem with allowing management protocols to pass through the firewall is that
the management protocols themselves lack essential security mechanisms. Many of these
protocols were defined in the early days of the Internet, when the kinds of security threats we
face today simply had not been imagined, and as a result security was not viewed as a high
priority. A high-level security analysis of several commonly used management protocols, as
shown in Table 1, illustrates this point.
ICMP
SNMP v1 / v2c
SNMP v3
Syslog
NetFlow
SFlow
TFTP
FTP
HTTP
HTTPS
Telnet
SSH
Authentication
Encryption
Easy to Spoof
None
Simplistic
Good
None
None
None
None
In the Clear
In the Clear
Good
In the Clear
Good
None
None
Good
None
None
None
None
None
None
Good
None
Good
Yes
Yes
No
Yes
Yes
Yes
Yes
No
No
No
No
No
Table 1. Security Analysis of Common Management Protocols
Copyright © 2009 Tavve Software Co
If management protocols had little power and were essentially harmless, their lack of security
mechanisms would be less of a concern. Unfortunately, management protocols are in fact
very powerful, and can be used by a hacker to obtain valuable information about a network,
modify device configurations, manipulate the flow of traffic through the network, and open the
door to a wide range of follow-on attacks. The fundamental problem here is that the security
mechanisms provided by management protocols are not commensurate with their power.
They are like power tools without the safety guards. As a result, even if the administrative
effort required to configure the firewalls to allow management protocols can be justified, in
doing so, the overall security of the enterprise network is diminished.
3. Management VPN
A management Virtual Private Network (VPN) can also be used to extend the reach of a
management application into a firewall-partitioned network zone. The simplest form of this
approach is to install a VPN client on each management application server, and a VPN
server in the unreachable network zone as illustrated in the following figure.
Figure 6. Management VPN
The VPN client within each management application server can be configured to intercept
traffic destined for managed devices in the unreachable network zone and relays this traffic
via an encrypted link to the VPN server, which relays the traffic to the managed devices.
Similarly, the VPN server is configured to route traffic originated by the managed devices to
the VPN clients associated with the intended management application servers.
A management VPN can significantly reduce the number of firewall rules that need to be
configured:
•
There is no need to configure rules for multiple ports; only the port used for
communications between VPN client and the VPN server is required.
•
There is no need to configure rules for each managed device; by providing a rule for
a given VPN server, management applications are able to effectively reach all
managed devices that are reachable by that VPN server.
While a management VPN can simplify firewall configuration, the same security concerns
remain that were described for the Define Firewall Rules approach, because the VPN allows
fundamentally insecure management protocols to pass between the network zones. The VPN
server will typically be a general-purpose network device that is not aware of the nature and
behavior of management protocols. In the absence of more specific additional configuration,
a VPN server will typically pass any network traffic on any port, whether or not that traffic is
related to management, which is considerably less secure than defining firewall rules. Some
VPN solutions may allow you to configure access control rules limiting the ports that can be
Copyright © 2009 Tavve Software Co
accessed for given managed devices, but at that point you are effectively doing the
equivalent work of defining firewall rules without providing any added security benefit.
4. Application-Specific Probes or Agents
Another strategy that management application vendors can use to extend the reach of their
application through firewalls is to provide probes or agents that can be deployed in the
unreachable network zone, and can communicate back to the centralized management
application server using a secure encrypted link, as shown in the following figure.
Figure 7. Application-Specific Probes or Agents
Even though this approach still requires configuration of firewall rules to allow the probes and
agents to communicate with the centralized management application servers, the number of
rules that need to be configured is significantly reduced (one port per pair of communicating
entities as opposed to multiple ports), and by using a secure encrypted link, the associated
security risk is minimized.
The problem with this approach is that management application vendors typically develop
their own probe or agent that only works with their own application. As a result, if you are
using multiple management applications – as most companies do – you will end up having to
deploy multiple probes or agents in each network zone, one for each management
application that you use, as illustrated in the following figure.
Copyright © 2009 Tavve Software Co
Figure 8. Multiple Application-Specific Probes or Agents
As the number of probes and agents you need to deploy increases, your costs go up, and the
complexity of your management environment increases as well. In addition, the probes and
agents provided by different management application vendors will provide different levels of
security, and you will need to evaluate each one independently, in order to ensure that your
needs are met. Some may provide a good degree of security, while others may be weak in
this area, because it is not their primary area of expertise, or perhaps because their product
is relatively new to the market. In a highly secure environment, you may need to perform
penetration testing for each different probe or agent, and as the number of probes and agents
increases, the cost/time to perform this testing will increase as well.
5. Management Application Replication
Another approach that can be used to manage multiple firewall-partitioned network zones is
to install and operate a separate instance of each required management application within
each network zone, as illustrated in the following figure.
Figure 9. Management Application Replication
The advantage of this approach is that all network zones are fully managed without needing
to open up the firewalls to allow management traffic. The primary disadvantage is that it
defeats the ultimate management goal, which is to provide a single unified view of the entire
enterprise network.
Copyright © 2009 Tavve Software Co
This approach can also be very expensive, depending on the licensing arrangement that you
have with your management application vendors. If you have paid a fixed price for a
corporate licenses, the additional costs may be manageable, but if you are paying on a perinstance basis, this approach can rapidly become cost prohibitive, especially as the number
of network zones increases. Even if the software costs are manageable, you will need to
deploy and maintain additional servers in each network zone, on which to install and run your
management application instances.
If you are deploying management application instances in a high-risk network zone, such as
a DMZ, you will want those applications to be hardened for security, which is not a typical
management application requirement, and often is not within the application vendor’s area of
expertise. Otherwise you run the risk that your management application servers may be
compromised, either to deny service to or tamper with the management application (e.g. to
provide cover for an ongoing attack), or to be used as a vantage point for subsequent attacks
on other devices and systems (e.g. if the network infrastructure devices are locked down via
access control lists, to only allow commands from the management application servers, if an
attacker can compromise the management application server they then have management
access to the infrastructure devices).
6. Management Proxy Firewall
A management proxy firewall extends the reach of management applications into a firewallpartitioned network zone with a minimum of firewall rules and with significantly enhanced
security. The typical approach for deploying a management proxy firewall is similar to that for
a Management VPN. A client is installed on each of the management servers, and one or
more proxy firewall appliances are deployed in each unreachable network zone, as illustrated
in the following figure.
Figure 10. Management Proxy Firewall
The client within each management application server intercepts traffic destined for managed
devices in the unreachable network zone and relays this traffic via an encrypted link to the
proxy firewall, which relays the traffic to the managed devices. Similarly, the proxy firewall is
configured to route traffic originated by the managed devices to the clients associated with
the intended management application servers.
The management proxy firewall approach is also comparable to a management VPN in terms
of firewall rule reduction:
•
There is no need to configure rules for multiple ports; only the port used for
communications between client and the proxy firewall appliance is required.
Copyright © 2009 Tavve Software Co
•
There is no need to configure rules for each managed device; by providing a rule for
a proxy firewall appliance, management applications are able to effectively reach all
managed devices that are reachable by that appliance.
1
The distinguishing characteristic of a management proxy firewall is that it operates at the
application protocol layer and is aware of the ports, message formats and transaction
patterns associated with specific management protocols. A management proxy firewall will
only relay traffic that involves the expected participants, that uses the expected ports, and
that looks and behaves like valid management traffic, resulting in a significantly reduced
attack surface.
Conceptually, a management proxy firewall breaks down the traffic passed between
management applications and managed devices by port and protocol, and includes specific
validation modules for commonly-used management protocols, as illustrated in the following
figure.
Figure 11. Management Proxy Firewall Conceptual Architecture
In a more practical implementation, the client and the proxy firewall appliance may share the
responsibility for protocol validation, so that invalid traffic can be discarded at the point where
the traffic is received, as illustrated in the following figure.
1
A proxy firewall is sometimes referred to as an application layer firewall (see
http://en.wikipedia.org/wiki/Application_layer_firewall) because it deals with protocols at the
application layer.
Copyright © 2009 Tavve Software Co
Figure 12. Management Proxy Firewall Practical Architecture
A management proxy firewall may also serve to isolate the lower layer transport protocols
(e.g. IP, TCP, UDP) on the management application side from those on the managed device
side, because each transport protocol can effectively be terminated at the local point of
contact (i.e. client or proxy firewall). For example, when providing a proxy for a TCP-based
protocol such as SSH, rather than simply relaying IP datagrams or TCP segments, the
TCP/IP transport can be implemented as two TCP connections, one between the
management application and the client, and one between the proxy firewall and the managed
device. The header content of each datagram and segment sent by the client or proxy firewall
will be created by the sending client or proxy firewall. This approach effectively protects
against a wide variety of transport layer attacks, including fingerprinting attacks that would
typically be used to identify management application server software versions, in order to
identify known vulnerabilities.
In summary, there are a variety of approaches that can be used to manage devices in firewallpartitioned networks. The Management Proxy Firewall approach is recommended, because it
provides a “best of all worlds” solution, extending the reach of centralized management
applications throughout the entire enterprise network, simplifying firewall configuration, and
providing enhanced security. The remainder of this paper will describe Tavve’s ZoneRanger,
which has been developed to meet the market need for a security-hardened, commercial
management proxy firewall.
ZoneRanger – A Commercial Management Proxy Firewall
Introduction to ZoneRanger
Tavve’s ZoneRanger is a commercial Management Proxy Firewall and can extend the reach of
management applications throughout firewall-partitioned networks, while minimizing firewall rules
Copyright © 2009 Tavve Software Co
and mitigating associated security threats. ZoneRanger provides proxy and forwarding services
for a wide variety of management protocols, including the following:
•
ICMP Echo Request (a.k.a. “ping”) Proxy
•
SNMP Get/Set Request Proxy
•
Telnet/SSH Proxy
•
HTTP/HTTPS Proxy
•
FTP/TFTP Proxy
•
SNMP Trap Forwarding
•
Syslog Forwarding
•
NetFlow/sFlow Forwarding
•
TACACS+ Proxy
•
RADIUS Proxy
•
NTP Proxy
A minimal ZoneRanger installation consists of two components:
1. The Ranger Gateway software, typically installed on the management application server.
2. The ZoneRanger appliance, typically deployed in an unreachable network zone, such as
a DMZ.
Figure 13. Minimal ZoneRanger Installation
Note that the Ranger Gateway software acts as the “client” and the ZoneRanger acts as the
“proxy firewall” as previously described in the Management Proxy Firewall approach. The Ranger
Gateway intercepts traffic destined for managed devices in the unreachable network zone and
relays this traffic via an encrypted link to the ZoneRanger, which relays the traffic to the managed
devices. Similarly, the ZoneRanger is configured to forward traffic originated by the managed
devices to the Ranger Gateways associated with the intended management application servers.
In order to facilitate integration with a wide variety of management applications, Ranger Gateway
and ZoneRanger provide transparent proxy services. That is, management applications are able
to use the same device addresses and protocols to communicate with managed devices beyond
the firewall that they would use in the absence of the firewall, and no special management
Copyright © 2009 Tavve Software Co
application configuration is required. As a result, the management application can remain
completely unaware that a proxy service is being used.
As an example, consider the network illustrated in the following figure:
Figure 14. Network Example
Assume that a management application such as HP NNM or CA eHealth is installed on the
management application server. In order to perform an SNMP Get Request, the management
application will send a normal SNMP Get Request message to the target device address (e.g.
10.1.10.20). The Ranger Gateway will intercept this request, perform validation, then will forward
the request in an internal format to a ZoneRanger that is able to communicate with the target
device. The ZoneRanger will rebuild the request and send it to the target device. Note that the
source address in the rebuilt request will be the IP address of the ZoneRanger (e.g. 10.1.10.6),
so that when the device replies, the reply will be routed back to the ZoneRanger. When the
ZoneRanger receives the reply, it is validated, matched with a known outstanding request, and
relayed back to the requesting Ranger Gateway in an internal format. The Ranger Gateway
rebuilds the reply and forwards it to the management application. Note that the source address in
the reply will be the IP address of the target device (e.g. 10.1.10.20).
The message flow for this example is illustrated in the following figure:
Figure 15. SNMP Proxy Message Flow
In the case of management protocol traffic originated by managed devices, the existence of the
proxy is semi-transparent. That is, the managed device can use the same protocols that it would
normally use, but must be configured to direct management traffic towards the ZoneRanger, as
opposed to sending it to the management application. One advantage of this approach, in the
case where the ZoneRanger is deployed in a network zone of low trust, is that the ZoneRanger
serves to hide the IP addresses of the management applications from the managed devices.
From the perspective of the managed devices, they are being managed by the ZoneRanger.
Copyright © 2009 Tavve Software Co
As an example, consider the case where a managed device sends a Syslog message to the
ZoneRanger. The destination address, in this case, must be the ZoneRanger’s IP address (e.g.
10.1.10.6). When the ZoneRanger receives the Syslog message, it will validate the message,
then will consult its configured forwarding rules to determine where the message should be
forwarded. The ZoneRanger will forward the message to any indicated Ranger Gateways, along
with a list of addresses (based on matching forwarding rules) to which the message should be
forwarded. The Ranger Gateway will forward the message to the specified recipients, using the
original managed device’s IP address (e.g. 10.1.10.20) as the source address, so that it looks to
the receiving management application as if the message had been sent directly from the
managed device.
The message flow for this example is illustrated in the following figure:
Figure 16. Syslog Forwarding Message Flow
Deploying ZoneRanger
In a typical large enterprise, there will be multiple management applications and multiple DMZs,
or other firewall-partitioned networks. In order to accommodate this requirement, each
ZoneRanger is able to work with multiple Ranger Gateway instances, and each Ranger Gateway
instance can work with multiple ZoneRangers, as illustrated in the following figure.
Figure 17. Large Enterprise Configuration
Copyright © 2009 Tavve Software Co
In this configuration, two ZoneRangers are deployed in each firewall-partitioned network highavailability, and a Ranger Gateway instance is installed on each management application server.
In general, each Ranger Gateway instance will have an SSL connection to each of the
ZoneRangers, enabling the corresponding management application to reach into each of the
firewall-partitioned networks where the ZoneRanger pairs have been deployed.
ZoneRangers are frequently deployed in redundant pairs in order to provide high availability, so
that if one of the ZoneRangers becomes unavailable, the other ZoneRanger in the pair will be
able to proxy the necessary management traffic. The mechanisms provided by ZoneRanger in
order to support high availability are illustrated in the following figure.
Figure 18. High Availability Mechanisms
As shown in the figure, the Ranger Gateway is configured with a table indicating which
ZoneRangers are able to reach specific managed devices or subnets. The table shown indicates
that either ZR-1 or ZR-2 can be used to proxy traffic to devices in the 10.1.1.0/24 subnet. The
Ranger Gateway monitors the status of all associated ZoneRangers on an ongoing basis, so that
it can divert traffic away from any ZoneRangers that may be unavailable. If, for example, the
management application sends an SNMP Get request to 10.1.1.20, the Ranger Gateway will
intercept the request, consult its configuration table to identify the list of ZoneRanger candidates
(ZR-1 or ZR-2), eliminate any ZoneRangers that are currently unavailable from the list, then
select one of the remaining ZoneRangers to proxy the request.
In cases where the management protocol transaction is initiated by the managed device, such as
SNMP trap forwarding, the managed device can be configured to send the trap to the virtual IP
address associated with the pool (e.g. 10.1.1.60). Assuming that ZR-1 is currently active with
respect to the virtual IP address, the trap will be received by ZR-1, which will forward the trap on
to one or more Ranger Gateways based on configured rules. If ZR-1 were to become unavailable,
ZR-2 would detect this condition and become the new owner.
Note that each ZoneRanger also has its own individual IP address. As an alternative to the virtual
IP mechanism, a managed device can also be configured to send each trap to two or more
ZoneRangers. Each ZoneRanger will forward the trap to one or more Ranger Gateways based on
Copyright © 2009 Tavve Software Co
configured rules, and each Ranger Gateway will detect and remove the duplicates before
forwarding traps on to the management application.
A pool of ZoneRangers (e.g. three or more) can be deployed in a firewall-partitioned network
zone in order to provide a combination of high capacity and high availability, where the size of the
pool is based on the management traffic load. When the load increases, additional ZoneRangers
can be added to the pool in order to handle the additional traffic. Each Ranger Gateway instance
is responsible for distributing management traffic transactions evenly across each pool of
ZoneRangers. When a management application initiates a management protocol transaction, the
Ranger Gateway will intercept the initial request, and will select an available ZoneRanger to proxy
the request. The Ranger Gateway keeps track of ZoneRanger status and transaction history, and
will attempt to balance the transaction load across the set of available ZoneRangers in the pool.
The load balancing function provided by the Ranger Gateway is illustrated in the following figure.
Figure 19. Load Balancing
Note that the load balancing algorithm is based on the same configuration table that is used for
high availability. In fact, the ZoneRanger selection algorithm in the Ranger Gateway essentially
addresses both high availability and load balancing requirements by seeking to balance the load
across the set of available ZoneRangers. The rule of thumb in sizing a ZoneRanger pool is to
determine the number of ZoneRangers necessary to handle the anticipated load, assuming that
all of them are available, then add one, to handle the case where one of the ZoneRangers
becomes unavailable. For example, if four ZoneRangers are needed to handle the management
protocol transaction load, a pool of five is recommended, so that if any one of the ZoneRangers
becomes unavailable, the Ranger Gateway will detect this condition and will spread the load
across the remaining four.
ZoneRanger Interfaces
Each ZoneRanger appliance has two network interface cards (NICs), and can be configured for
single-NIC or dual-NIC operation. In a single-NIC configuration, traffic between the ZoneRanger
and the Ranger Gateway, and traffic between the ZoneRanger and the managed devices shares
a single interface, as shown in the following figure.
Copyright © 2009 Tavve Software Co
Figure 20. Single-NIC Configuration
The single-NIC configuration is preferred in situations where the traffic flowing through the firewall
is a combination of both management and non-management traffic. The single-NIC configuration
allows non-management traffic to be routed directly to the intended devices, bypassing the
ZoneRanger, so that the ZoneRanger does not become a bottleneck.
In the dual-NIC configuration, traffic between the Ranger Gateway and the ZoneRanger is carried
over the first interface, and traffic between the ZoneRanger and the managed devices is carried
over the second interface, as illustrated in the following figure.
Figure 21. Dual-NIC Configuration
The dual-NIC configuration works well in cases where there is a separate management network,
dedicated to management traffic. Note that the dual-NIC configuration also serves to enhance
security, by providing an additional layer of isolation between the corporate network and the
managed devices.
Deploying Ranger Gateway
The simplest approach for deploying the Ranger Gateway is to install an instance of the Ranger
Gateway software on each management application server. Within each server, traffic originated
by the management application and destined for managed devices that are located in firewallpartitioned networks will be intercepted by the Ranger Gateway, and relayed to available
ZoneRangers that are able to communicate with the intended managed device.
Copyright © 2009 Tavve Software Co
There may be cases where it is preferable to deploy shared stand-alone Ranger Gateway
servers, making use of the Ranger Gateway Virtual Interface (RGVI) mechanism, as illustrated in
the following figure.
Figure 22. Shared Ranger Gateway Servers
The RGVI mechanism requires a relatively thin RGVI Client to be installed on each management
application server. The RGVI Client intercepts traffic originated by the management application
destined for managed devices that reside in a firewall-partitioned network, and forwards
intercepted traffic to a Ranger Gateway server, which relays the traffic to available ZoneRangers
that are able to communicate with the intended managed device. Responses received by the
ZoneRanger are passed back to the Ranger Gateway, which forwards them to the original RGVI
client, which forwards them to the requesting management application. Note that Ranger
Gateway servers are typically deployed in pairs in order to provide high availability.
Even though the RGVI mechanism still requires software to be installed on each management
application server, it should be noted that the RGVI Client has a much smaller memory and
processing footprint than the Ranger Gateway software. As a result, the potential for impact to the
management application is minimized. Another advantage of sharing Ranger Gateway servers is
the potential to reduce the number of firewall rules that must be defined to allow communication
between Ranger Gateways and ZoneRangers, because the overall number of Ranger Gateway
instances is reduced. In addition, by consolidating Ranger Gateway configuration and control is
into a small number of dedicated servers, overall configuration effort is reduced, and access to
the Ranger Gateway can easily be restricted to authorized users.
The primary disadvantage of sharing dedicated Ranger Gateway servers is the additional cost to
purchase and operate the dedicated servers. In some organizations these costs will outweigh the
advantages. In other organizations, the reverse may be true.
Conclusions
Firewall-based network partitioning creates a dilemma for centralized management. The preferred
strategy to resolve this dilemma is to deploy a management proxy firewall, in order to extend the
reach of centralized management applications throughout the entire enterprise network, while
simplifying firewall configuration, and providing enhanced security. Tavve’s ZoneRanger
appliance provides a mature, commercial-grade, feature-rich management proxy firewall solution,
complete with high availability features and a scalable architecture.
Copyright © 2009 Tavve Software Co