![[prev]](left.gif)
![[up]](up.gif)
![[next]](right.gif)
Previous: 2 Attacks on ``Classical IP over ATM Networks''
Up: Securing 'Classical IP over ATM Networks'
Next: 4 Conclusions
In ATM networks the control on
access![[*]](foot_motif.gif)
to the network is shared between
hosts and switches. On the other hand
in ``legacy LANs'' like Ethernet the access to the network is only
controlled by the nodes themselves (CSMA/CD). This fundamental
difference between ATM and ``legacy LANs'' can be used for securing
the networks against malicious attacks by providing a controlled
access to network resources.
A major part of securing an ATM network relies on the ATM switch. It can be used for filtering certain addresses and to support monitoring of the network. The next sections will show how an ATM network can be secured against the attacks described before.
An ATMARP server can be installed on a host in the LIS or on an ATM switch. From the security point of view installing an ATMARP server on a host is preferable for multiple reasons. The access to the ATMARP server on a host can be controlled more easily than on an ATM switch. As an ATMARP server on a host is implemented in software, it is easier to expand the ATMARP server with security enhancements for access control and auditing. ATMARP server on ATM switches depend on the firmware of the switch and are therefore difficult to expand. Moreover even though it is convenient to use the ATMARP server of the switch for multiple LISs, this makes it impossible to restrict the access according to the security policy of one LIS.
In the second step the ATMARP server is configured with static ARP entries for every node in the LIS. Each entry consists of the tuple <ATM address, IP address>. This renders the described attack of malicious registration of an address of another node impossible, as static entries cannot be overwritten.
To gain additional security the ATMARP server should be configured to reject registration requests for unknown tuples of <ATM address, IP address>. This can be achieved by turning off the dynamic learning of new <ATM address, IP address> tuples. By these simple measures hostile registration of ARP entries can be prevented.
It has to be noted however that adding new nodes to this network will require manual configuration of the ARP entry.
Attempts to register new ARP entries can be identified as either attacks or newly installed machines and should be audited. Also queries for unregistered ARP entries should be audited as this can be an attempt to scan the address-space for possible victims.
or by restricting the signaling of new SVCs with access
control list. The configuration of PVCs between all hosts of the same
subnetwork yields a very secure configuration, but is hard to
administer as adding a host will require the configuration of PVCs to
every host in the same subnet. The definition of access lists on
the other hand is more flexible and efficient as only few simple rules
can restrict the creation of new SVCs. Even adding and removing hosts
may not require reconfiguration if the subnets are identified in the
access control lists by the use of wildcards.
The following sections describes the secure separation of two subnets - an internal and an external subnet - using access control lists on the signaling protocol. The firewall has two ATM interfaces: one ``fwext'' with the external network and one ``fwint'' with the internal network (see fig. 4).
Figure 4:
Firewall in an ATM Environment
As the filters on the switch rely on ATM addresses only, both the internal and the external network may have complex topologies (e.g. multiple interconnected switches). It is sufficient to configure the filters on the switch that is connected to the firewall. Figure 4 shows a simplified setup with only one switch.
The following restrictions have to be imposed by the ATM switch:
With this configuration all communication between the internal and the external network must cross the firewall.
The advantages of filter rules in ATM switches are described with the following example. The example network consist of three hosts on the internal network (``int1-3''), three hosts on the external network (``ext1-3''), one firewall with two interfaces (``fwint'' and ``fwext'') and one ATM switch (``atmsw'').
Symbolic names are easier to comprehend and therefore reduce the risks of misconfigurations:
atm template-alias fwint
4700918100000000e0f7df1901080020827e6100
atm template-alias fwext
4700918100000000e0f7df1901080020827c5100
atm template-alias int1
4700918100000000e0f7df1901080020827b8100
atm template-alias int2
4700918100000000e0f7df1901080020825ca100
atm template-alias int3
4700918100000000e0f7df190108002082a9f100
atm template-alias atmsw
4700918100000000e0f7df1901f9f9f9f9f9f900
atm template-alias ext1
4700918100000000e0f7df1901080020827be100
atm template-alias ext2
4700918100000000e0f7df190108002082564100
atm template-alias ext3
4700918100000000e0f7df19010800208254d100
In this example we choose to explicitly list all hosts in the filter rules. For larger networks wildcards should be used to select groups of hosts with just one rule.
The keywords permit and deny can be used to describe which
hosts are allowed to use the signaling protocol to open a connection:
# internal hosts are allowed to reach # other internal hosts atm filter-set inHosts permit fwint atm filter-set inHosts permit int1 atm filter-set inHosts permit int2 atm filter-set inHosts permit int3 atm filter-set inHosts permit atmsw atm filter-set inHosts deny default # Hosts not listed (external hosts) # are not allowed to reach internal hosts atm filter-set exHosts deny fwint atm filter-set exHosts deny int1 atm filter-set exHosts deny int2 atm filter-set exHosts deny int3 atm filter-set exHosts deny atmsw atm filter-set exHosts permit default atm filter-exp intern inHosts atm filter-exp extern exHosts
Unknown hosts will be treated like external hosts and cannot reach internal hosts. As only internal ATM addresses are necessary for the configuration the solution is applicable to both LANs and WANs.
If the ATMARP server has been configured as internal host, the address filters are sufficient to prevent an external attacker from directly connecting to the ATMARP server (see section 3.1). The combination of a secure ATMARP server and the use of address filters on switches to direct the access to the network through a firewall is a good choice for defending against the denial of service attacks discussed in sections 2.2 and 2.5.
The filters must be applied to the interfaces. On an
interface connected to an internal host the following commands must be
applied:
atm access-group intern in atm access-group intern out
On all external interfaces these two commands must be applied:
atm access-group extern in atm access-group extern out
The above configuration separates the ATM network into two virtual networks the internal and the external network. This concept can be extended to separate multiple virtual networks. To which network a host belongs is simply a matter of configuration. A host may therefore belong to a virtual network depending on its communication and security requirements rather than depending on its physical location.
This feature of ATM networks makes it easier to structure networks depending on security requirements. If all these subnets are connected by one or multiple central firewalls, this concept will allow for very secure networks in the future.
Figure 5:
Bandwidth
Allocation for SVC between two External Hosts
There are two solutions that can address this problem. Both solutions require a careful configuration of the switch.
Modern switches support the configuration of bandwidth resources for different traffic classes. Thus it may be possible to configure the ``fwext'' interface of the switch (figure 5) so that only a certain amount of bandwidth is available for CBR or VBR traffic. In essence this will not prevent the described attack but will reduce the impact, as the administrator can make sure that there is always enough bandwidth available for connections to the Internet.
Another way to make sure that the internal network is always able to connect to the Internet is to configure a permanent virtual connection between switch and the Internet access point (router or switch). Typical switches provide a way to assign quality of service to PVCs. This is sufficient to allocate a certain amount of bandwidth to the PVC so that an attacker can only compete for the remaining bandwidth.
The main drawback of both solutions is that the administrator must have access to all intermediate switches in order to configure either a PVC to the Internet access point or limit the available bandwidth for demanding traffic classes (CBR/VBR). This may be impossible if the switches belong to different administration domains. Moreover the access to all the intermediate switches must be restricted to prevent reconfiguration by an attacker.
Since there is still the chance that malicious routing information is propagated by other switches over a NNI link the switch is still vulnerable. One (interim) solution to this problem is the use of the `Interim Inter-switch Signaling Protocol' (IISP) instead of P-NNI at the NNI interface unless the authentication has been addressed by the P-NNI designers. The IISP only supports statically configured routes, thus making it impossible to insert malicious information by sending messages to the switch. The major drawback of this solution is the burden of managing the static routing tables for fast scaling networks. IISP networks are also very error prone. If an intermediate switch goes offline all static routes through this switch are no longer usable.
A switch may also support the configuration of static ATM addresses at individual ports. This can prevent the registration of additional (unexpected) addresses at a switch port. This also makes sure that a workstation will only be able to register with a predefined address that matches a desired filter rule on the switch (see section 3.2).
Carsten Benecke, Uwe Ellermann / DFN-FWL