Document Managed by Network Architecture
Overview
A firewall is a device placed at the perimeter of an administrative domain that enforces an access policy for traffic entering and leaving that domain. The role of a firewall in a security paradigm is to segment a trusted or secure domain from an untrusted or insecure domain, and to selectively pass traffic based on desired connection characteristics. One reason to install a firewall is to reduce the number of services exposed by a network of hosts, and limiting the exposure of possible misconfigurations or security vulnerabilities to untrusted parties.
While a firewall can be an excellent addition to a network's security model, it should not be considered a panacea for network security. Rather, a firewall should be regarded as a powerful tool, a component of an overall strategy, one that provides for a more secure environment by safeguarding against many unknowns. Other elements in a good security design may include intrusion detection systems, local network scans, regular security audits, timely review of log data, and maintaining system patch levels, all of which fall outside the scope of this document. Collectively, these tools, along with a thorough understanding of the network's structure and functions can go a long way towards protecting against casual and concerted attacks.
When properly installed and implemented, a firewall can be a powerful tool to aid in the defense of the network, and may provide a network administrator with a great deal of flexibility in design. On the other hand, firewalls can be rendered useless by poor design, and by default, have some inherent deficiencies. For example, firewalls may not provide strong protection for services which have been exposed, either intentionally or by improper configuration, to the outside, and may allow third parties to exploit vulnerabilities in those services and gain access to that infrastructure. Additionally, firewalls can not protect networks against attacks from hosts within the network. Once a host on the inside is compromised from the outside, the network as a whole is exposed.
For example, consider a medium-scale departmental LAN that provides web, email, and telnet services. In such a case, the LAN administrator would have to specifically configure the firewall to permit hosts outside the LAN to connect to the departmental web, email, and telnet services. These services would be completely unprotected by the firewall. Any bugs or security related problems with the exposed services could still exploited by an attacker. Any services that would not be permitted through the firewall (for example: print servers, file servers, databases) would have an improved level of security due to the firewall.
The LAN Administrator will also need to consider the following when implementing a firewall:
- Port address translation (PAT) vs. network address translation (NAT)
- Static routes
- Coordinated versus Uncoordinated address space
- Public vs. Private address space
- DNS issues
Recent improvements to the RUNet design allow greater flexibility for a department to serve its own computing needs. Departments are still subject to certain architectural restrictions. These restrictions are generally intended to ensure the robustness of the campus network, as well as to assure consistency across implementations.
- No two networks connected to the OIT network infrastructure through different
OIT routers, or different ports on one OIT router, may exchange IP data through
any means other than the OIT router(s).
This rule prohibits any group from setting up a local router or firewall that
routes between networks if those networks are also connected to OIT managed routers.
This does not prohibit routing between multiple networks on a firewall or any
other device if those networks are not also connected to a OIT managed router.
- Customer managed equipment may not participate in dynamic routing processes
on the RUNet backbone.
The intent of this restriction is to maintain network reliability and ensure the
integrity of the information propagated by the routing process. Routing devices
on the RUNet backbone participate in a trusted dynamic routing process. OIT will
neither provide nor accept route advertisements from customer maintained equipment,
but instead will rely on static routing configured in coordination with the customer
to ensure reachability of the customer's network(s).
- Customer managed equipment may only be attached to RUNet at the edge of the network beyond all equipment managed by the OIT Telecommunications Division Network Operations Group. Equipment such as a firewall may not be installed between the backbone and a department or building router managed by OIT; it may not be deployed between switches managed by OIT. This ensures that OIT staff have access to and responsibility for all devices on the network up to the first customer device and that OIT has no responsibility for equipment after the first customer device. No customer device will have direct access to the RUNet backbone. All traffic from the customer must flow through a OIT managed policy control point that may enforce university policy on customer traffic.
A Firewall placed on RUNet infrastructure should conform to the following layout:
In the configuration above, the firewall's two interfaces are both connected to switches on the same building access network. The systems protected by the firewall must also be connected to switches on the same building access network as the firewall. Because VLANs may span several physical devices, they need not be on the same switch or within the same ER or TC. The external interface of the firewall must be connected to one of the buildings regular production routing VLANs.
The primary RUNet design is based on using VLANs attached to routers, but also allows for VLANs that will not be routed. Such networks are isolated from the routed infrastructure and the rest of RUNet, and are analogous to networks on stand-alone switches. This property will ensure that the systems protected by the firewall, in routed or non-routed private address space, will not be able to reach the outside world directly, but will be able to communicate with one another. The internal firewall interface as well as the systems to be protected by the firewall should be connected to the same non-routing VLAN. In this configuration, all access to networks outside of the protected VLAN must occur via the firewall.
With this deployment there is no need to purchase an additional internal switch, rewire the systems from the RUNet switch to the internal switch, or leave a RUNet switch virtually empty after the rewiring has been done. These are advantages for both OIT Telecommunications and local system administration teams.
This architecture is also efficient and scalable as it allows for data jacks anywhere within the building access network to be quickly connected behind the firewall by changing the VLAN assignment of the corresponding switch ports. Multiple special purpose non-routing VLANs can be requested, allowing a firewall with multiple interfaces to be installed for separate networks that have different functions or policies enforced by different firewall rule sets. This may be applicable in a building that has lab/office clients as well as open data jacks or wireless access. On the lab/office subnet the firewall may not be needed for authentication purposes because login screens are already in place or the system's users are trusted; it may also allow more services to pass through. On the open data jack/wireless network it may be desirable to force authentication and logging of users are on the network (user name, time, MAC address, public/private IP assigned, etc.) and to restrict access to specific services or ports. Firewalls can also be used to NAT private IPs and route public IPs at the same time, a hybrid setup that allows a single firewall to handle the requirements of several disparate networks. This physical architecture does not differ from that depicted above.
Unlike the standard RUNet networks, classic (legacy) networks will each have their own unique issues which will need to be addressed and will have to be handled on a case-by-case basis. Adherence to the layout above is recommended in any case.
Logically, the firewall configuration above will behave as if it were physically configured like this:
In this configuration, the firewall operates like a router. It acts to segment a LAN and selectively pass traffic based on IP layer information. Unlike a router, the firewall is specialized to also act upon protocol and port number information contained in the IP packet, and may retain state for each transaction in order to allow return traffic to pass. From a logical perspective, the firewall acts as if it is connected between a switch attached to the University network and another switch serving the hosts it protects. Information must flow through the firewall on its way out of the protected LAN, and return traffic must also flow through the firewall before reaching the protected networks.
Data traversing from the inside of this network to the outside world would begin at the systems behind the firewall. These systems would send data towards the outside world, that is, onto the non-routing VLAN where the firewall is the only pathway out, or, in cases where the firewall was assigned as the gateway, directly to the firewall itself. The firewall then adds the communication to a table of active conversations and performs NAT/PAT (if in use), or simply forwards the data to the outside world via its external interface that exists on a routed VLAN.
Data traversing from the outside world to this network will either have as a destination address a host protected by the firewall or, in the case of NAT/PAT, an address configured on the firewall. After receiving the data the firewall will send it to the non-routed VLAN, perhaps after performing NAT/PAT translations using the table it maintains, where the host will then receive that data.
Private and Public Address Space
A firewalled LAN can be placed on either public or private address space. RU divides this space into two categories - coordinated space and uncoordinated space. Coordinated addresses are those addresses that are allocated and supported by OIT/TD. Uncoordinated addresses are those addresses that can be freely used by anyone at the university without the need to request the space be uniquely assigned to them.
Coordinated address space is address space guaranteed to be unique within Rutgers University's network. Coordinated space consists of address space assigned to Rutgers and a portion of private address space as defined by RFC 1918. The private addresses included in coordinated space can be routed within the University but not to or from the Internet. Coordinated address space is managed and allocated by hostmaster. It is recommended to use coordinated IPs within a departmental firewall.
Public address space is one option for a firewalled LAN. This is a form of coordinated address space and it must be requested from hostmaster. The size of the request must reflect actual needs. Coordinated Public address space has the benefits of being regulated and managed, easily routable in the event of a firewall failure, and supported by a variety of network tools and services (such as DNS).
When using coordinated private address space, network administrators have the option to either have their address space routed within Rutgers or not. If routing is not used initially, network administrators will still have the option to later configure routing within RUNet. This may be beneficial if the firewall is later removed and a routing device is added. Since this private space is unique, it allows the hosts and IPs to be added into the Rutgers DNS servers, removing any need for an internally managed DNS server.
TD has specifically set aside the 192.168.0.0/16 address space for use in an uncoordinated manner. This address space is not uniquely assigned within Rutgers University, nor will it ever be routed. Networks using uncoordinated address space may have to replicate services (i.e., DNS and DHCP) already provided by Rutgers University, depending on their specific needs. Those needs, as well as the issues involved in duplication of any required services, must be taken into consideration when deciding on a firewall design.
The need to use uncoordinated space is fairly rare, and while not disallowed, it is not recommended. It should be used in fairly limited environments, for example in open access labs or for users connected via wireless access points or open ports. By using uncoordinated space, and often merely by using PAT or NAT, a greater number of responsibilities may fall upon the shoulders of the local network administrator, see http://oit.rutgers.edu/host-acct-req.html.
For those unfamiliar with the terminology, NAT (Network Address Translation) is an Internet standard that enables a local-area network (LAN) to use one set of IP addresses for internal traffic and a second set of addresses for external traffic. When using NAT, a coordinated address space identical in size to the address space behind the firewall must be requested. A NAT box located where the LAN meets RUNet makes all necessary IP address translations. The benefit of NAT is that it provides a way of hiding internal IP addresses from the outside world.
Another common form of NAT is PAT (Port Address Translation, less commonly known as Network Address Port Translation.) PAT extends the notion of translation one step further by also translating TCP and UDP port numbers. This allows a number of hosts to share a single external IP address. The individual conversation streams from each host are tracked by the firewall and a single external address can support several thousand connections from potentially hundreds of hosts. This is a major benefit if an organization is running low on routable IPs. When using PAT, only a small (/30) coordinated address space must be requested to provide a routable address for the Firewall.
There is an expectation that the network administrator can specifically identify any host or hosts involved in an abuse incident. Hosts behind an address translation system like a firewall must still abide by http://OIT.rutgers.edu/host-acct-req.html.
NAT/PAT can also present a variety of technological implementation problems for the network administrator. Voice over Internet protocol (VoIP), Microsoft NetMeeting and other streaming media applications are examples of technologies NAT may affect. When an inside user tries to set up a session, it will fail because the user's working internal IP address is imbedded within the application's data. It will not be translated by the NAT firewall on its way out. Other applications using fixed IP addresses, DNS for example, may stop working with NAT. Hosts that need to be reachable from outside the local network will have both an internal and external address, thus complicating DNS issues further. IPsec VPN security applications are known to not work well with NAT. This is because remote access clients typically encrypt the packet before sending it to a NAT device (new standards are being developed allow IPsec VPNs to function with NAT). One should consult with the application's developer/vendor when considering the implementation of a network address translation scheme.
From a logical standpoint, virtually all firewall implementations will look similar to the logical layout presented above. In such an implementation, the firewall device acts like a router, and must be configured to pass IP traffic between its interfaces. If one of the design goals of the implementation is to retain routing transparency for hosts connected to a trusted network, then static routing must be used to ensure the reachability of the trusted network by remote hosts.
In LAN environments, the firewall will communicate with the network backbone on its untrusted network interface, and with the secured LAN or LANs on the trusted network interfaces. The backbone router must have knowledge of the networks located beyond the firewall and, since the networks are not directly connected to the backbone router, the router must be configured with a static route for each network beyond the firewall. The static routes will use the firewall's untrusted network interface as the next hop in the path to the destination networks. The router will also advertise those networks to the rest of the backbone, ensuring that the firewalled networks are reachable from the rest of the network.
In general terms, the firewall must be configured to act as a router between the hosts on the trusted networks, and the untrusted backbone. The firewall must be configured with a default route via the backbone router's interface. Depending on the firewall device used in the implementation, the firewall may also need to be configured with routing information for each of the connected trusted networks.
Finally, hosts on the trusted networks must be configured with default routes. The firewall must have an IP address on each of the network segments to which it is attached, and hosts on those segments must use that IP address as their default route. Thus, when a host on a trusted segment forwards a packet to the backbone, it sends the packet to the firewall, which evaluates the packets against the security policy then sends the packet to the backbone router. When packets return to the host, the backbone router sends the packets to the firewall, which evaluates the packets against the security policy and forwards the packets to the trusted host.
When working with multiple trusted networks, it is the responsibility of the network administrator to make certain that the implementation complies with the policies outlined above. Networks connected to a firewall as a trusted network may not also be connected to a backbone router interface. The intent of the rule is to eliminate the potential for routing loops on the network backbone, and serves to ensure a single, controlled entry point onto the trusted network.
