EXPLOITING VLANS
| | ||
| | ||
| | ||
EXPLOITING VLANS
Virtual LAN (VLAN) technology is available to create logically separate LANs on the same switch. VLANs can be static (assigned on a port basis) or dynamic (usually assigned on a MAC address basis). A single VLAN can span multiple switches; switch ports that carry traffic from more than one VLAN are called trunk ports . Trunking protocols, such as 802.1q or Cisco Inter Switch Link (ISL), tag packets, which travel between the trunk ports to distinguish data that belongs to different VLANs. However, these packets still pass through the same physical pipe or trunk.
VLANs are created for functionality or organizational purposefor example, to split traffic that belongs to different corporate departments. However, far too many also consider VLANs to be a security feature to be incorporated into their security policy and secure network design. This is a mistake that we are going to explore in this section.
Attacks against VLANs are aimed at being able to traverse them in terms of both traffic sending and reception , despite their virtual separation. While some reports claim that under heavy traffic load on some switches data leaks between the VLANs do occur, such an approach would be too unreliable as an attack. The same cannot be said about more specific VLAN exploitation, which can be divided into the following:
-
Trunking protocols (802.1q and ISL) abuse
-
Dynamic Trunking Protocol (DTP) abuse
-
Virtual Trunking Protocol (VTP) exploitation
-
Common spanning tree (CST) abuse
-
Other attacks
The ultimate in VLAN attacking is, of course, an ability to add, delete, and modify VLANs at a whim.
DTP Abuse
| Attack |
|
By default, trunk ports have access to all VLANs, and this presents a security issue. If an attacker can turn a port into a trunk (by default, all switch ports are nontrunking), then all your VLANs are belong to us!
A particular problem is taking over the "native" VLAN 1, which carries management protocols such as CDP and VTP. This VLAN cannot be deleted. The VLAN 1 802.1q frame tag VLAN identification number is 81 00 00 01.
DTP is a Cisco proprietary protocol (using a Cisco reserved destination MAC 01.00.0c.cc.cc.cc, SNAP number 0x2004) that is present to make the network administrator's life easier by managing trunk negotiation. As in many cases, along with the convenience of use comes a vulnerability. DTP negotiates what is called a common trunking mode between ports on two interconnected switches and needs only a simple initial one-time configuration by a network administrator. A trunking mode on Cisco Catalyst switches can be
-
On, or permanent trunking mode The choice between 802.1q and ISL has to be entered manually.
-
Off, or permanent nontrunking mode No trunk creation is possible.
-
Desirable Trunk creation is wanted; if the other end is configured to on, desirable, or auto mode, a trunk link would be established. Unlike the on mode, the choice between 802.1q and ISL is negotiated automatically.
-
Auto, also called negotiate Trunking will be successfully negotiated, if the other end is configured to on, or desirable mode.
-
Nonnegotiate This mode is used when the other end doesn't speak DTP, since in nonnegotiate mode, DTP frames are not sent. The other end should be manually configured for trunking (on or nonnegotiate mode).
Here comes a problem: By default, Cisco Catalyst switch ports are configured as auto. Hence, no trunk link would be created between two ports in this mode. However, DTP doesn't offer any authentication means, and nothing stops an attacker from sending DTP frames pretending to be a switch port in on or desirable mode. In practical terms, this attack is implemented in Yersiniaset the interface you want to use and its parameters as previously described in the STP section (just use dtp instead of stp in commands entered) and execute run dtp attack 1 . Check that the attack is running:
yersinia# show attacks No. Protocol Attack --- -------- ------ 0 DTP enabling trunking
In an ncurses GUI ( yersinia -I ), press F5 , then x , then number 1 , then letter L (to be sure) and watch the DTP frames being sent every 30 seconds.
Congratulations! You may have just opened a trunk link! Start sniffing the bypassing data to verify the success of your attack.
802.1q and ISL Exploitation
Even though 802.1q is an IEEE standard and not a Cisco proprietary protocol, it is far more commonly used on modern switched LANs; here we concentrate mainly on 802.1q- related attacks. 802.1q embeds its data within the Layer 2 frame; this is referred to as internal tagging . In an Ethernet frame, a 4 byte 802.1q tag is added right after the source address field (Figure 12-6).
Figure 12-6: 802.1q-tagged Ethernet frame
The first 2 bytes signify the 802.1q tag (Tag Protocol Identifier, or TPID) and have a constant value of 0x8100. Two bytes that remain are a Tug Control Information (TCI) field. A TCI is split into a 3-bit 802.1p priority field that serves a Layer 2 quality of service (QoS) purpose (eight traffic prioritization levels), a Canonical Format Indicator (CFI) bit showing whether the MAC address is in canonical format, and 12 remaining bits of VLAN Identifier (VID). It is the VID that separates the traffic between VLANs by assigning each VLAN a unique number. The 12-bit range gives us 4095 possible VLANs, with VLANs 0, 1, and 4095 being reserved. It is important to know that 802.1q introduces the concept of a native VLAN on a trunk. A native VLAN (VLAN 1 by default) carries frames without tags. If a user station without 802.1q support is plugged into a trunk port, it will be able to understand only frames passing through the native VLAN.
Unlike 802.1q, Cisco ISL (Figure 12-7) encapsulates the whole Layer 2 frame between an additional header (26 bytes) and a trailer (4 bytes).
Figure 12-7: Cisco ISL encapsulated Ethernet frame
The ISL header consists of the following fields:
-
DA Destination 40-bit multicast address (01.00.c0.00.00)
-
TYPE Indicates the frame type, such as Ethernet, Token Ring, fiber distributed data interface (FDDI), or ATM frame being encapsulated into the ISL
-
USER Usually set to zero
-
SA Source MAC address
-
LENGTH 16-bit length, excluding the fields mentioned above and the trailer
-
SNAP 3-byte SNAP field set to 0xAAAA03
-
HSA 0x00000C value
-
VLAN ID 15 bit, more VLANs than 802.1q
-
BPDU 1-bit set for all BPDUs that are encapsulated by ISL
-
INDX 16-bit index field that indicates the port index of the source of the packet as it exits the switch
-
RES 16-bit reserved field, all zeroes for Ethernet
The ISL trailer is a traditional 32-bit cyclic redundancy check (CRC) checksum (a frame length divided by a prime number). An Ethernet frame will be enlarged by 4 bytes when 802.1q is in use and by a whole 30 bytes in the case of ISL. If the original frame was already of the maximum allowable size , the resultant frame will be larger than the Ethernet standard allows. These frames are referred to as baby giants and may get dropped as invalid by the attacking station's network card. Be sure to adjust your maximum transmission unit (MTU) with the ifconfig or ip command when attacking, taking these values into account.
Double Tagging VLAN Hopping
| Attack |
|
So how do we hop VLANs? The first and most basic VLAN hopping attack is to become a trunk via DTP and then push tagged or encapsulated frames into the corresponding VLANs. This attack is completely defeated on modern Catalyst switches so it is of historical interest only. However, other means of VLAN hopping would still work, since they exploit standard-defined behavior of the involved devices. Thus, the vulnerability is the standard's, rather than switch's fault, and this kind of a fault is unlikely to be fixed soon. Above all, we are referring to what is called the double 802.1q encapsulation attack (its correct name should be double 802.1q tagging attack ). Basically, we tag malicious data with two 802.1q tags and send the packet out. The first tag will get stripped off by the switch to which we are connected, and the packet will get forwarded to the next switch. However, a remaining tag contains a different VLAN to which the packet will be sent. Thus, data is pushed from the VLAN stated in the first tag onto the VLAN stated in the second one (Figure 12-8).
Figure 12-8: Double-tag VLAN hopping attack
In this form, the attack is unidirectional, although we will return to bypassing this limitation later in the section. In practice, sending double-802.1q tagged packets is implemented in Yersiniafor example, yersinia -I followed by F 6 => d => x => 1 . Don't forget to set all the required parameters of the packet to send, if the testing situation is different from the one described by the default Yersinia settings. In a client/server mode, use this:
yersinia# set dot1q double yes yersinia# set dot1q interface eth0 >skip other specific variables settings> yersinia# run dot1q attack 1
Two conditions must be met for this attack to succeed. First, it will work only if the trunk link has the same native VLAN as the attacker. Thus, you have more chances to succeed if you convert your link to the switch into a trunk via the DTP attack, although it is not always necessary. Then, of course, you will not be able to push any data to a host on a different VLAN but connected to the same switch, because a switch performs untagging only once. The attacker and the attacked must be connected to the different switches, as shown in Figure 12-8. Since ISL does not support the concept of native VLANs, it is secure against double-encapsulation attacks.
Private VLAN Hopping
| Attack |
|
A more exotic VLAN hopping attack, which would work with ISL just as well, is a hopping attack against private VLANs, or PVLANs. PVLANs provide isolation within VLANs, so that you can split hosts within the same network segment if you don't want these hosts to communicate with each other directly. PVLANs provide a good counter-measure against ARP spoofing attacks. Nevertheless, their use also opens the possibility of an attack that we describe here.
The attack is based upon a basic fact: a switch, as a Layer 2 device, does not care much about IP addresses, and a router, as a Layer 3 device, does not filter MAC addresses unless explicitly configured to do so. All hosts separated via PVLANs still have a common gateway through which they communicate with outside networks, such as the Internet. If we send a packet with valid source MAC and IP addresses, but replace the target MAC address with the one of a gateway router, the switch would happily forward such a packet to the router, which will then look at the IP and direct the packet to the target. Of course, the source MAC of the packet will be replaced by the one of the router and the attack is, again, unidirectional.
While at the moment of writing no common tool can be used to implement this attack, a brilliant Global Information Assurance Certification (GIAC) practical work by Steve A. Rouiller ( http://www.giac.org/practical/GSEC/Steve_A_Rouiller_GSEC.pdf ) has an example of libnet-based code (see Appendix A5 on the site) for launching a typical PVLAN hopping attack. This example can be easily modified to meet your specific pentesting needs before the compilation. Steve's work also contains libnet-based code samples for practically all VLAN-related attacks we describe here and is a must for any-one seriously interested in VLAN exploitation. It's a pity that practical write-ups are not required to pass the GIAC certification anymore!
Making Unidirectional Attacks Bidirectional
| Attack |
|
You may rightfully ask: What good is an attack that allows the attacker to push traffic in a single direction only? The standard answer is that it still allows an attacker to launch DoS attacks; however, this answer is not highly satisfactory. While DoS can be quite destructive, it is not something a skillful cracker would seek. There must be ways to bypass this limitation. When writing this chapter, we looked into it and learned that it is quite easy to do. WEPWedgie, a tool for Wired Equivalent Privacy (WEP) traffic injection by Anton Rager, solves the problem of unidirectional communication by bouncing packets from the target to a third external host under the attacker's control. We can do exactly the same here. Consider Figure 12-9, which demonstrates this approach in relation to the PVLAN hopping attack we have just described.
Figure 12-9: Making use of a PVLAN hopping attack
Attacker A opens a shell on an external host D under his control, which could be somewhere on the Internet. Then, packets with a source IP of D, destination IP of B, and destination MAC of a gateway router C are sent to the victim machine B. When B finally receives the packets, it will send the replies to D, where it would be captured by the attacker's sniffer. An example could be portscanning by generating spoofed TCP SYNs at A and picking reply SYN-ACKs and ACK-RSTs at D. If B is successfully exploited, the cracker would be able to communicate with it by establishing a reverse connection from B to D.
While here we describe an enhancement to the PVLAN hopping, exactly the same method can be successfully applied to a double 802.1q tagging attack. The main limitation in both cases is that an attacker has to be sure that the target has a route to an external sniffing host and that no egress filtering rules would block the communication along this route. In other words, the attacker must perform his reconnaissance well.
VTP Exploitation
| Attack |
|
VTP is a yet another Cisco proprietary protocol designed to make the network administrator's life easier by enabling centralized administration of VLANs. VTP data propagates inside 802.1q or ISL frames on VLAN 1. These frames are sent to the destination MAC address 01.00.0C.CC.CC.CC with a Logical Link Control (LLC) code AAAA and a type of 2004 in the SNAP header.
To use VTP, switches have to be added to a VTP domain as VTP servers, clients , or transparent devices. When a new VLAN is configured on a VTP server, it will be automatically distributed among all switches in the VTP domain. Switches configured as transparent will propagate VTP information without altering their own VLAN assignments. On a network with dozens of operational Catalyst switches, this is very useful. At the same time, if an attacker can insert a rogue VTP server into the domain, she would have complete control over the VTP domain VLANs. To stop it, VTP implements MD5-based frame authentication. Unfortunately, in our experience, many system administrators don't turn it on. But even so, an attacker can crack the MD5 hash if a guessable password is in use.
Apart from the absence or bypass of MD5 authentication, two other conditions must be fulfilled by the attacker when injecting VTP frames into the domain:
-
The attacker must turn her port into a trunk (DTP attack).
-
The VTP configuration revision number must be higher than the number in previous VTP advertisements to reflect the most recent update.
Of course, these frames must also have a valid VTP domain name. DTP also advertises the VTP domain name and without knowing it you won't be able to establish necessary trunking.
A VTP frame injection attack is automated in Yersinia. In the ncurses GUI, press F7 and set the injected frame parameters. Don't forget about a high revision number; sniff some existing VTP frames, and put the number above the one in the last frame. Then press x and select the attack you need. The choice is to send a custom VTP packet, delete all or a single VLAN, or add a custom VLAN to the domain. In a client/server mode, use the set vtp command to define the parameters of your frames and execute run vtp attack <attack number> .
To gain access to all traffic on the switch, delete all VLANs. To gain access to traffic on a specific VLAN, delete that VLAN. Of course, you will still need to apply classical methods of sniffing a switched network to sniff and modify the traffic you can now access, so have your ARP spoofing and CAM table flooding tools ready. How about adding an additional VLAN and further segmenting the network? This could also come in handyfor example, to cut off IDS/IPS sensors and consoles or deny the system administrator access to the part of the network under the attacker's control. Of course, it can also be used for a DoS attack.
VLAN Query Protocol (VQP) Attacks
| Attack |
|
Sometimes you may encounter dynamic VLANs. The most common reason for deploying dynamic VLANs is mobile users with laptops that may connect to different ports on different switches but still need to remain on the same VLAN. The assignment of hosts to dynamic VLANs is usually based upon the hosts' MAC addresses, although it is also possible to assign hosts to dynamic VLANS via Windows NT or Novell usernames, if a Cisco User Registration Tool (URT) is available. Nowadays, URT is very rarely used, since it became superseded by standard-defined 802.1x-based authentication methods.
The VLAN-per-host assignment is done by a VLAN Management Policy Server (VMPS), a service running on a higher end Catalyst switch. The VMPS grabs MAC-to-VLAN mapping information from the VMPS database via Trivial File Transfer Protocol (TFTP) or Remote Copy Protocol (RCP) and distributes it to VMPS client switches to which the end-user workstations are connected. The whole process of VLAN assignment by VMPS takes six steps (shown in Figure 12-10) and employs the proprietary VLAN Query Protocol (VQP) that uses UDP port 1589.
As shown in Figure 12-10, first the connecting user station sends a packet to the VMPS client switch (1). From this packet, the switch learns the station's MAC address (2). Then the client switch sends a VQP request to the VMPS server (3). This request contains the VMPS client switch IP, connecting station's MAC, client switch port number, and VTP domain. Upon receiving the VQP request, the VMPS server pulls the database file from the VMPS database and parses it to find whether the connecting station is listed (4). Then a VQP response is sent back to the client switch (5), and on the basis of this response a decision considering the connecting station is taken (6). This decision depends on the settings of the database file. A typical VMPS database file contains the following entries:
Figure 12-10: Dynamic VLAN assignment
vmps domain Switchblock1 vmps mode open vmps fallback default_unsecure vmps no-domain-req deny ! vmps-mac-addrs! ! address 0001.0435.0823 vlan-name DepartmentA address 0234.0924.D721 vlan-name DepartmentB address 0030.8A20.E624 vlan-name DepartmentC
The VMPS domain name is the same as the VTP domain name. The next line defines what to do with the stations without a matching entry in the database. By default, it is set to open , which means that a connecting station without a valid entry would be assigned to a fallback VLAN, defined in the next line of the configuration file. This VLAN could be unroutable or be a guest VLAN with a connection to the Internet and no routes to the internal corporate LAN. If open is replaced by closed , the switch port of an illicit station will be suspended and no connection is possible. Thus, closed is a more secure setting. It is also a good practice to keep the vmps no-domain-req deny line in place to deny dynamic VLAN connection to all hosts without a domain name. The line vmps-mac-addrs opens the actual VLAN-to-MAC mapping part of the database file, with a few examples of its entries shown.
How do we attack dynamic VLANs? For an unconnected attacker, the chances of connecting are slim, unless the following occurs:
-
The line vmps fallback default is left with a default in it by an inexperienced network administrator. These settings will drop connecting hosts without a matching MAC address onto the default VLAN, which is VLAN 1. Oops!
-
An attacker can somehow find a valid MAC address to spoof via social engineering or plain old bruteforce (connecting with different MAC addresses until successful). Trying out various known multicast MAC addresses is suggested. Knowing the make of legitimate client's network cards cuts away the Organizationally Unique Identifier (OUI) of MAC addresses to guess and greatly simplifies bruteforcing.
When an internal attacker is already connected to one of the static VLANs and wants to get onto the dynamic one, the situation is entirely different. First of all, neither VQP nor TFTP or RCP traffic is encrypted. If an attacker is able to sniff it, he would know valid MAC addresses to which to connect. It would be also possible to spoof or corrupt VQP responses or impersonate a TFTP or RCP server and supply a fake database file to the VMPS server. The fact that all listed protocols work over UDP only helps. Alternatively, an attacker can launch a filename dictionary attack against the TFTP or RCP server (for example, using our Cisco Torch) to grab the database file and possibly replace it. The default name of this file requested by the VMPS server is vmps-config-database.1 . Often, it stays unchanged. To get onto the same VLAN with the VMPS server and database (commonly VLAN 1), using the methods described earlier in this chapter could be necessary.
Lateral Means of Bypassing VLAN Segmentation
| Attack |
|
It is possible to tap into traffic belonging to a different VLAN without exploiting protocols directly relevant to VLAN's existence. An example of such an instance includes becoming the STP root bridge when CST is in use. CST provides a single spanning tree per a whole Layer 2 topology, regardless of the number of deployed VLANs. Thus, traffic from all VLANs will have to pass through the root bridge, where it can be intercepted and modified.
We have already reviewed in detail the rogue root bridge insertion attack; this particular case is no different, apart from the fact that the attacker has more luck on her side. Another rather effective attack is the traditional ARP poisoning attack with a twist: 802.1q tagging of the packets sent. This attack is implemented in the Yersinia 802.1q mode as attack number 2 (sending 802.1Q ARP poisoning ). It requires three additional parameters: the IP of a target to poison , the source IP of ARPs, and the number of the VLAN on which the target is positioned. The parameters are asked for when you use the ncurses GUI when the attack is launched; if using the client/server mode, set these parameters using the commands set dot1q iparp , set dot1q ipdest , and set dot1q ipsource . Of course, this attack is against a single host on a different VLAN and you have to know its IP address beforehand.
Another attack, which is far less likely to succeed, is trying to push multicast traffic onto a different VLAN. This attack is of a limited usefor example, blind searching for a vulnerable multicast application by injecting in an exploit capable of establishing a reverse connection to an external host (see Figure 12-9). Since we have never encountered such successful attacks in the real world, we are not going to dwell on it here.
Countermeasures Against VLAN-Related Attacks
| Countermeasures | Unlike STP exploitation, VLAN attacks comprise a whole array of methods using different Layer 2 protocols. Thus, there is no silver bullet to use to stop all attacks at once, and every attacking approach has a specific countermeasure. |
A countermeasure that comes closest to being universal is to turn off DTP:
CatOS_switch>(enable)set trunk <module/port> off IOS_switch(config)#interface fastethernet <module/port> IOS_switch(config-if)#switchport mode access
To verify that no DTP is running, execute these commands:
CatOS_switch>(enable)show trunk [modulemodule/port]
or
IOS_switch#show interface <type> <number> switchport
Many VLAN attacks require that the attacker set up a trunk link to the switch. If DTP is not running and the connected port is in a permanent nontrunking state, these attacks become impossible to execute. Thus, DTP should be disabled on all end-user ports. It is also advisable to put all unused ports onto a separate, unroutable VLAN. This will force potential local attackers to unplug legitimate hosts to connect to the network, which is not going to go unnoticed.
Since the double 802.1q tagging attack requires that an attacker have the same native VLAN with the trunk link, putting all legitimate trunk ports onto a separate, dedicated VLAN will sort it out. Also, prune VLANs when possible (via VTP or manually) so that they do not spread to switches where they are not expected to be used. In particular, that applies to VLAN 1, which should not leak to end users or even network servers at all.
In general, don't use VLAN 1 for anything, even the switch management traffic, spare for VTP and CDP. Pick up a separate VLAN for the management traffic instead. While VTP pruning of VLAN 1 is supposed to be impossible, a method is available for restricting the extent of this VLAN. A specific feature called VLAN 1 disable on trunk is available on Catalyst 4000, 5000, and 6000 series switches since CatOS version 5.4(x). This feature allows a network administrator to prune VLAN 1 from a trunk the way you would remove any other VLAN. Despite such pruning, the control and management traffic such as VTP, CDP, and DTP will still pass through the trunk, but all user traffic will be blocked. No specific command is used for the VLAN 1 disable on trunk feature; VLAN 1 is removed the traditional way:
CatOS_switch>(enable)set trunk 2/1 desirable Port(s) 2/1 trunk mode set to desirable. CatOS_switch>(enable)clear trunk 2/1 1 Removing Vlan(s) 1 from allowed list. Port 2/1 allowed vlans modified to 2-1005.
As to the VTP itself, avoid using this management protocol where feasible . The easiest way to disable VTP data propagation is setting all switches to the transparent mode (you can also turn VTP off on CatOS-based switches):
CatOS_switch>(enable)set vtp mode transparent off IOS_switch(config)#vtp mode transparent
If running VTP is necessary due to the amount of switches deployed on a LAN, never forget to set a VTP password with the CatOS_switch>(enable)set vtp <passwd> or IOS_switch(config)#vtp password <password> command, while following common strong password criteria. The VTP password must be configured on all switches in the VTP domain, and it needs to be the same on all those switches. The password is carried in all summary-advertisement VTP frames as a 16-byte MD5 word.
Where possible, use VTP version 3 instead of 1 or 2. While the main difference between the first and second versions of the protocol is the support of Token Ring VLANs by VTPv2, VTPv3 introduces password hiding in the switch configuration file. Instead of showing the plaintext password when the show running / show startup-config command or its equivalent is executed, a VTPv3-enabled switch will demonstrate a hexadecimal secret key that is generated from the plaintext password. Thus, if an attacker takes over one of the switches, he won't have a password to control the whole VTP domain, even though he can reset and change the VTP password on that particular switch, kicking it out of the VTP domain and causing a DoS. To set a hidden VTPv3 password, use the CatOS_switch>(enable)set vtp passwd <password> hidden command. Other useful security enhancements to VTPv3 are also available; you can find more about them at http://www.cisco.com/en/US/products/hw/switches/ps708/products_configuration_guide_chapter09186a008019f048.html#wp1043515.
To block the PVLAN hopping attack the easiest way, the involved router, rather than the switch, will have to be reconfigured. The configuration needed is a simple access list restricting the traffic flow between hosts on the LAN:
Router(config)#access-list no_hop deny ip <localsubnet> <lsubnetmask> \ <localsubnet> <localsubmask> log-input Router(config)#access-list no_hop permit ip any any Router(config)#interface eth0/0 Router(config-f)#ip access-group no_hop in
The same configuration can be performed using VLAN access lists (VACLs) on some switchesfor example, Cisco Catalyst 6000 series running CatOS 5.3 or later. To configure a needed VACL on a CatOS switch, try out settings similar to these:
CatOS_switch<(enable)set vlan 6 CatOS_switch>(enable)set security acl ip no_hop deny ip <localsubnet> \ <lsubnetmask> <localsubnet> <localsubmask> log CatOS_switch>(enable)set security acl ip no_hop permit ip any CatOS_switch<(enable)commit security acl no_hop CatOS_switch>(enable)set security acl map no_hop 6
On the IOS switch, the configuration may look like this:
IOS_switch(config)#vlan 6 IOS_switch(config)#access-list 150 deny ip <localsubnet> <lsubnetmask> \ <localsubnet< <localsubmask> log-input IOS_switch(config)#access-list 150 permit ip any any IOS_switch(config)#vlan access-map no_hop IOS_switch(config)#match ip address 150 IOS_switch(config)#action forward IOS_switch(config)#vlan filter no_hop vlan-list 6
To snoop on possible local attackers without any impact on legitimate traffic passing through the switch, you can mirror suspicious traffic to a selected port employing a VACL Capture feature. Its configuration on a CatOS switch mirroring defined traffic to port 24 of the first module would look like this:
CatOS_switch>(enable)set vlan 6 CatOS_switch>(enable)set security acl ip no_hop deny ip <localsubnet> \ <lsubnetmask> <localsubnet> <localsubmask> capture CatOS_switch>(enable)set security acl ip no_hop permit ip any CatOS_switch>(enable)commit security acl no_hop CatOS_switch>(enable)set security acl map no_hop 6 CatOS_switch>(enable)set security acl capture-ports 1/24
Here's its equivalent in IOS:
IOS_switch(config)#vlan 6 IOS_switch(config)#access-list 150 deny ip <localsubnet> <lsubnetmask> \ <localsubnet> <localsubmask> log-input IOS_switch(config)#access-list 150 permit ip any any IOS_switch(config)#vlan access-map no_hop IOS_switch(config)#match ip address 150 IOS_switch(config)#action forward capture IOS_switch(config)#vlan filter no_hop vlan-list 6 IOS_switch(config)#int fastethernet 1/24 switchport capture
Our next stop is VMPS/VQP attacks, and it will be a very brief stop. In a nutshell , this model is somewhat obsolete. We strongly suggest using 802.1x for port-based user authentication instead. In the next section, we will briefly review an attack against Extensible Authentication Protocol-Lightweight Extensible Authentication Protocol (EAP-LEAP), a Cisco-specific implementation of 802.1x. Refer to that section to see a recommended Cisco solution for authenticating connecting users in a secure way.
As to STP-based VLAN penetration, we have already reviewed the methods of protecting your STP domain against the cracker nuisance. An additional recommendation here is not to use CST at all and assign a single STP tree per VLAN. To do that, Cisco offers proprietary Per-VLAN Spanning Tree (PVST) and Per-VLAN Spanning Tree + (PVST+). The difference between them is that PVST uses Cisco ISL, and PVST+ uses IEEE 802.1q trunking. Both allow Layer 2 load balancing via forwarding some VLANs on one trunk and other VLANs on a different one without a risk of causing Spanning Tree loops . Such configuration offers strong resilience against possible LAN flooding attacks. (Think you can't bring a 100BaseT Ethernet LAN down with a flood? Try out Linux kernel packet generator!) The latest development in the PVST field is Rapid-PVST+, which combines Rapid STP and PVST+ technologies. Rapid-PVST+ is a default STP version on CatOS switches since code train 8.1(1). It is enabled like so:
CatOS_switch>(enable)set spantree mode rapid-pvst+
The final issue to deal with is gratuitous ARP (GARP) spoofing. Since it is a common attack on switched VLANs, many countermeasures are available to keep it from installing arpwatch and configuring static ARP cache entries on end-user stations to running Ettercap plug-ins to discover ARP poisoners on LAN. However, here we are interested in Cisco-specific means of defeating GARP spoofing. One such method is configuring PVLANs and securing them against a hopping attack, as described previously. However, you may not want to break up communication between the hosts on a LAN unless you're operating in a highly secure environment or in other special cases, such as administering server farms. A less disrupting and more elegant solution is to apply ARP inspection, available on many recent CatOS and IOS versions. ARP inspection intercepts all ARP requests and responses and verifies for valid MAC-to-IP bindings before the switch ARP cache is updated or the packet is forwarded to the appropriate destination. All invalid ARP packets are dropped cold. To configure ARP inspection, first permit the explicit MAC-to-IP binding, and then deny any other ARP packets for the same IP. Finally, permit all other ARP packets. An example of ARP inspection configuration on a CatOS switch is shown here:
CatOS_switch>(enable)set security acl ip <ACL name> permit arp-inspection \host <IP> <MAC> CatOS_switch>(enable)set security acl ip <ACL name> deny arp-inspection \host <IP> any log CatOS_switch>(enable)set security acl ip <ACL name> permit arp-inspection any any CatOS_switch>(enable) set security acl ip <ACL name> permit ip any any CatOS_switch>(enable) commit security acl <ACL name>
As you can see, on CatOS switches, ARP inspection is basically an extension of VACLs. The settings on IOS switches are based on ARP access lists:
IOS_switch(config)#arp access-list <ACL-name> IOS_switch(config)#permit ip host <sender IP> mac host <sender MAC> [log] IOS_switch(config)#ip arp inspection filter <ACL-name> vlan <vlan range> static IOS_switch(config)#interface <interface id> IOS_switch(config-if)#no ip arp inspection trust
The first configuration line defines the ACL, the second is the actual ACL, the third one applies it to a VLAN and drops spoofed packets with a static option, and the last two lines set a selected interface as untrusted. All untrusted interfaces apply ARP inspection to bypassing traffic.
You can also configure ARP inspection on a Firewall Services Module (FWSM) for Catalyst 6500 switches and 7600 series routers. This is actually quite easy. First create static ARP entries, and then turn ARP inspection on:
FWSM/cat6500(config)#arp <interface name> <ip address> <mac address> FWSM/cat6500(config)#arp-inspection <interface name> enable [flood no-flood]
The default flood option will flood spoofed packets out of all switch ports. The no-flood option, which would drop such packets, is recommended.
Finally, you can limit the rate of incoming ARP packets to counter possible DoSs caused by malicious ARP floods. Excess ARP packets will be dropped and can optionally cause the offended switch port to shut down. An example of ARP rate limiting on a CatOS switch is shown here:
CatOS_switch>(enable)set port arp-inspection 1/1 drop-threshold 20 \shutdown-threshold 40 Drop Threshold=20, Shutdown Threshold=40 set on port 1/1.
This command will set an inspection limit of 20 packets per second and a port shutdown threshold of 40 packets per second for port 1/1. On the IOS switch, a syntax would be like this:
IOS_switch(config)#interface 1/1 IOS_switch(config-if)#ip arp inspection limit rate 40 IOS_switch(config-if)#errdisable recovery cause arp-inspection interval 60
In this case, the switch will disable port 1/1 after the threshold of 40 packets per second is exceeded. The third line defines interface recovery from the disabled state after 60 seconds have passed.
While configuring and maintaining ARP inspection on a switch can be cumbersome and time-consuming , it is nevertheless more efficient and manageable than setting static ARP entries on users workstations. Besides, this process can be automated via scripting, and a network administrator does not have to run around the campus bothering users and endlessly typing arp -s .
| | ||
| | ||
| | ||
EAN: 2147483647
Pages: 117