A security researcher has discovered a method of hacking Cisco routers with only basic knowledge about the targeted device.
Although researchers have found various vulnerabilities in Cisco routers, exploits mostly have been focused on hacks of specific IOS router configurations, which require targeted and skilled attacks. But Felix "FX" Lindner, a researcher with Recurity Labs, demonstrated last week at the 25th Chaos Communication Congress in Berlin a technique that lets an attacker execute code remotely on Cisco routers, regardless of their configuration.
"The bottom line is that before, all IOS exploits had to know the exact IOS image running on the target to get code execution. This is approximately a 1 to 100,000 chance, [and] a professional attacker doesn't risk his 0-day exploit when the odds are stacked against him like that," Linder says. "I [demonstrated] that at least on one group of Cisco routers, there is a way to execute code without knowing the IOS image version [they are] running."
Lindner says his exploit method is independent of a router vulnerability, and applies only to stack-buffer overflow bugs. He was able to execute memory writes and to disable CPU caches on Cisco routers running on the PowerPC CPU. Lindner hasn't yet tested his technique on larger, more expensive Cisco routers, but plans to do so eventually.
Security researcher Dan Kaminsky says FX's hack disproves conventional wisdom in enterprises that routers are at low risk of attack, and that patching them is riskier than an attack due to the potential network outages that patching can incur.
The research also broke the barrier of one exploit, one router: "Three-and-a-half years ago it was international news that one guy got one exploit working on one Cisco router," he says. "Today, it's now clear that it's possible, given a flaw in IOS, to reliably exploit many versions of many routers.
"Something we thought was difficult, for no good reason, is now shown to be so very simple after all," Kaminsky says.
Lindner says his research shows that detection of Cisco IOS attacks should be focused on the payload of an exploit, such as a backdoor program, rather than on the exploit itself.
To protect against a widespread router attack, Cisco should encourage users to run more standard versions of IOS, as well as make IOS more modular to simplify patching for its customers with customized versions, Kaminsky says.
The bottom line is that enterprises need to change their tune when it comes to their IOS patching policy. When a remote-code execution bug is discovered in one of their routers, they should treat it like any other system vulnerability, Kaminsky says. "They should treat it as equivalent to a vulnerability against sensitive servers or domain controllers, and act accordingly," he says. And that may require working closely with Cisco on just how to do that, he adds.
Ref:- Presentation
Showing posts with label Cisco Attack. Show all posts
Showing posts with label Cisco Attack. Show all posts
4/22/08
Layer 2 Attacks
The OSI stack was conceived so that different layers are able to function independently (with only the knowledge of their mutual interfaces). This allows for flexibility in that developments for a given layer of the protocol stack do not impact other layers so long as the standard interface between the layers is maintained.
Unfortunately this also means that if one layer is hacked, communication may be compromised without the other layers being aware of the problem (as shown in Below Figure).
OSI Stack Structure
What Are the Possible Attacks in a VLAN-Based Network?
The majority of attacks at L2 exploit the inability of a device to track the attacker who can therefore perform undetected malicious actions on the forwarding path to alter it and then exploit the change.
These are the most talked-about L2 attacks and incidentally also the ones that @stake documented in its findings [1]:
•MAC Flooding Attack
•802.1Q and ISL Tagging Attack
•Double-Encapsulated 802.1Q/Nested VLAN Attack
•ARP Attacks
•Private VLAN Attack
•Multicast Brute Force Attack
•Spanning-Tree Attack
•Random Frame Stress Attack
A description of each of these threats follows.
MAC Flooding Attack
This is not properly a network "attack" but more a limitation of the way all switches and bridges work. They possess a finite hardware learning table to store the source addresses of all received packets: when this table becomes full, the traffic that is directed to addresses that cannot be learned anymore will be permanently flooded. Packet flooding however is constrained within the VLAN of origin, therefore no VLAN hopping is permitted.
This corner case behavior can be exploited by a malicious user that wants to turn the switch he or she is connected to into a dumb pseudo-hub and sniff all the flooded traffic. Several programs are available to perform this task: for example macof, part of the dsniff suite [4]. This weakness can then be exploited to perform an actual attack, like the ARP poisoning attack (see ARP Attacks for more details on the subject).
On non intelligent switches this problem arises because a sender's L2 identity is not checked, therefore the sender is allowed to impersonate an unlimited number of devices simply by counterfeiting packets.
Cisco's switches support a variety of features whose only goal is to identify and control the identities of connected devices. The security principle on which they are based is very simple: authentication and accountability are critical for all untrusted devices.
In particular, Port Security, 802.1x, and Dynamic VLANs are three features that can be used to constrain the connectivity of a device based on its user's login ID and based on the device's own MAC layer identification.
With Port Security, for instance, preventing any MAC flooding attack becomes as simple as limiting the number of MAC addresses that can be used by a single port: the identification of the traffic of a device is thereby directly tied to its port of origin.
ISL is a Cisco proprietary technology and is in a sense a compact form of the extended packet header used inside the device: since every packet always gets a tag, there is no risk of identity loss and therefore of security weaknesses.
On the other hand, the IEEE committee that defined 802.1Q decided that because of backward compatibility it was desirable to support the so-called native VLAN, that is to say, a VLAN that is not associated explicitly to any tag on an 802.1Q link. This VLAN is implicitly used for all the untagged traffic received on an 802.1Q capable port.
This scenario is to be considered a misconfiguration, since the 802.1Q standard does not necessarily force the users to use the native VLAN in these cases. As a matter of fact, the proper configuration that should always be used is to clear the native VLAN from all 802.1Q trunks (alternatively, setting them to 802.1q-all-tagged mode achieves the exact same result). In cases where the native VLAN cannot be cleared, then always pick an unused VLAN as native VLAN of all the trunks; don't use this VLAN for any other purpose. Protocols like STP, DTP, and UDLD should be the only rightful users of the native VLAN and their traffic should be completely isolated from any data packet.
Therefore, it is absolutely normal for two hosts in an Isolated VLAN to fail to communicate with each other through direct L2 communication and instead to succeed to talk to each other by using the router as a packet relay.
In @stake's results, this type of attack proved ineffective against Cisco Catalyst switches because they correctly contained all the frames within their appropriate broadcast domain (no surprise here: after all, in all Catalyst switches broadcasts are just special cases of multicasts).
Spanning-Tree Attack
Another attack that tries to leverage a possible switch weakness (for example, bug) is the STP attack. All of the Cisco Catalyst switches tested by @stake support this protocol. By default, STP is turned on and every port on the switch both speaks and listens for STP messages. @stake tried to see if Cisco PVST (Per VLAN Spanning Tree) would fail open across1 multiple VLANs under specific conditions. The attack consisted in sniffing for STP frames on the wire to get the ID of the port STP was transmitting on. Next, the attacker would begin sending out STP Configuration/Topology Change Acknowledgement BPDUs announcing that he was the new root bridge with a much lower priority.
Random Frame Stress Attack
This last test can have many incarnations but in general it consists in a brute force attack that randomly varies several fields of a packet while keeping only the source and destination addresses constant. After repetitive testing by @stake's engineers, no packets were found to have successfully hopped VLANs.
Private VLANs can be used in this context to better isolate hosts at L2 and shield them from unwanted malicious traffic from untrustworthy devices. Communities of mutually-trusting hosts can be created so as to partition a L2 network into subdomains where only friendly devices are allowed to communicate with each other.
Unfortunately this also means that if one layer is hacked, communication may be compromised without the other layers being aware of the problem (as shown in Below Figure).
OSI Stack StructureThe Data Link layer is as vulnerable as any other layer and can be subjected to a variety of attacks which the switch must be configured to protect against.
What Are the Possible Attacks in a VLAN-Based Network?
The majority of attacks at L2 exploit the inability of a device to track the attacker who can therefore perform undetected malicious actions on the forwarding path to alter it and then exploit the change.
These are the most talked-about L2 attacks and incidentally also the ones that @stake documented in its findings [1]:
•MAC Flooding Attack
•802.1Q and ISL Tagging Attack
•Double-Encapsulated 802.1Q/Nested VLAN Attack
•ARP Attacks
•Private VLAN Attack
•Multicast Brute Force Attack
•Spanning-Tree Attack
•Random Frame Stress Attack
A description of each of these threats follows.
MAC Flooding Attack
This is not properly a network "attack" but more a limitation of the way all switches and bridges work. They possess a finite hardware learning table to store the source addresses of all received packets: when this table becomes full, the traffic that is directed to addresses that cannot be learned anymore will be permanently flooded. Packet flooding however is constrained within the VLAN of origin, therefore no VLAN hopping is permitted.
This corner case behavior can be exploited by a malicious user that wants to turn the switch he or she is connected to into a dumb pseudo-hub and sniff all the flooded traffic. Several programs are available to perform this task: for example macof, part of the dsniff suite [4]. This weakness can then be exploited to perform an actual attack, like the ARP poisoning attack (see ARP Attacks for more details on the subject).
On non intelligent switches this problem arises because a sender's L2 identity is not checked, therefore the sender is allowed to impersonate an unlimited number of devices simply by counterfeiting packets.
Cisco's switches support a variety of features whose only goal is to identify and control the identities of connected devices. The security principle on which they are based is very simple: authentication and accountability are critical for all untrusted devices.
In particular, Port Security, 802.1x, and Dynamic VLANs are three features that can be used to constrain the connectivity of a device based on its user's login ID and based on the device's own MAC layer identification.
With Port Security, for instance, preventing any MAC flooding attack becomes as simple as limiting the number of MAC addresses that can be used by a single port: the identification of the traffic of a device is thereby directly tied to its port of origin.
802.1Q and ISL Tagging Attack
Tagging attacks are malicious schemes that allow a user on a VLAN to get unauthorized access to another VLAN. For example, if a switch port were configured as DTP auto and were to receive a fake DTP packet, it might become a trunk port and it might start accepting traffic destined for any VLAN. Therefore, a malicious user could start communicating with other VLANs through that compromised port.
Tagging attacks are malicious schemes that allow a user on a VLAN to get unauthorized access to another VLAN. For example, if a switch port were configured as DTP auto and were to receive a fake DTP packet, it might become a trunk port and it might start accepting traffic destined for any VLAN. Therefore, a malicious user could start communicating with other VLANs through that compromised port.
Sometimes, even when simply receiving regular packets, a switch port may behave like a full-fledged trunk port (for example, accept packets for VLANs different from the native), even if it is not supposed to. This is commonly referred to as "VLAN leaking"
While the first attack can be prevented very easily by setting DTP to off on all non trusted ports (again the principle of trust at work...), the second attack can usually be addressed by following simple configuration guidelines (such as the one suggested in the next section) or with software upgrades. Fortunately, Cisco Catalyst 2950, Catalyst 3550, Catalyst 4000, and Catalyst 6000 series switches don't need any such upgrade, since their software and hardware have been designed to always enforce proper traffic classification and isolation on all their ports .
Double-Encapsulated 802.1Q/Nested VLAN Attack
While internal to a switch, VLAN numbers and identification are carried in a special extended format that allows the forwarding path to maintain VLAN isolation from end to end without any loss of information. Instead, outside of a switch, the tagging rules are dictated by standards such as ISL or 802.1Q.
While internal to a switch, VLAN numbers and identification are carried in a special extended format that allows the forwarding path to maintain VLAN isolation from end to end without any loss of information. Instead, outside of a switch, the tagging rules are dictated by standards such as ISL or 802.1Q.
ISL is a Cisco proprietary technology and is in a sense a compact form of the extended packet header used inside the device: since every packet always gets a tag, there is no risk of identity loss and therefore of security weaknesses.
On the other hand, the IEEE committee that defined 802.1Q decided that because of backward compatibility it was desirable to support the so-called native VLAN, that is to say, a VLAN that is not associated explicitly to any tag on an 802.1Q link. This VLAN is implicitly used for all the untagged traffic received on an 802.1Q capable port.
This capability is desirable because it allows 802.1Q capable ports to talk to old 802.3 ports directly by sending and receiving untagged traffic. However, in all other cases, it may be very detrimental because packets associated with the native VLAN lose their tags, for example, their identity enforcement, as well as their Class of Service (802.1p bits) when transmitted over an 802.1Q link.
For these sole reasons—loss of means of identification and loss of classification—the use of the native VLAN should be avoided. There is a more subtle reason, though.
When double-encapsulated 802.1Q packets are injected into the network from a device whose VLAN happens to be the native VLAN of a trunk, the VLAN identification of those packets cannot be preserved from end to end since the 802.1Q trunk would always modify the packets by stripping their outer tag. After the external tag is removed, the internal tag permanently becomes the packet's only VLAN identifier. Therefore, by double-encapsulating packets with two different tags, traffic can be made to hop across VLANs.
This scenario is to be considered a misconfiguration, since the 802.1Q standard does not necessarily force the users to use the native VLAN in these cases. As a matter of fact, the proper configuration that should always be used is to clear the native VLAN from all 802.1Q trunks (alternatively, setting them to 802.1q-all-tagged mode achieves the exact same result). In cases where the native VLAN cannot be cleared, then always pick an unused VLAN as native VLAN of all the trunks; don't use this VLAN for any other purpose. Protocols like STP, DTP, and UDLD should be the only rightful users of the native VLAN and their traffic should be completely isolated from any data packet.
ARP Attacks
The ARP protocol is quite an old technology. The ARP RFC is from a time when everyone in a network was supposed to be "friendly" and therefore there was no security built into the ARP function. As a consequence, anyone can claim to be the owner of any IP address they like. To be more precise, anyone can claim that his or her MAC address is associated to any IP address within a specific subnet. This is possible because ARP requests or replies carry the information about the L2 identity (MAC address) and the L3 identity (IP address) of a device and there is no verification mechanism of the correctness of these identities.
The ARP protocol is quite an old technology. The ARP RFC is from a time when everyone in a network was supposed to be "friendly" and therefore there was no security built into the ARP function. As a consequence, anyone can claim to be the owner of any IP address they like. To be more precise, anyone can claim that his or her MAC address is associated to any IP address within a specific subnet. This is possible because ARP requests or replies carry the information about the L2 identity (MAC address) and the L3 identity (IP address) of a device and there is no verification mechanism of the correctness of these identities.
Again, this is another case where lack of a precise and reliable means of identification of a device leads to a serious security vulnerability. Also, this is a perfect example of why by compromising a lower level in the OSI stack it's possible to directly affect an upper level without the upper layer being aware of the problem. (ARP is a unique specimen of protocol living and breathing in the L2 world but logically residing at the boundary between the Data Link and the Network layer in the OSI stack.)
The ARP attacks that @stake performed were targeted to fool a switch into forwarding packets to a device in a different VLAN by sending ARP packets containing appropriately forged identities. However, in all Cisco devices VLANs are orthogonal to and therefore independent from MAC addresses: so by changing a device's identity in an ARP packet, it's not possible to affect the way it communicates with other devices across VLANs. As a matter of fact, as the report states, any VLAN hopping attempt was thwarted.
On the other hand, within the same VLAN, the so-called ARP poisoning or ARP spoofing attacks are a very effective way to fool end stations or routers into learning counterfeited device identities: this can allow a malicious user to pose as intermediary and perform a Man-In-the-Middle (MiM) attack.
The MiM attack is performed by impersonating another device (for example, the default gateway) in the ARP packets sent to the attacked device: these packets are not verified by the receiver and therefore they "poison" its ARP table with forged information.
This type of attack can be prevented either by blocking the direct communication at L2 between the attacker and the attacked device or by embedding more intelligence into the network so that it can check the forwarded ARP packets for identity correctness. The former countermeasure can be achieved with Cisco Catalyst Private VLANs or Private VLAN Edge features. The latter can be achieved by using a new feature called ARP Inspection, available first in CatOS 7.5 on the Cisco Catalyst 6500 Supervisor Engine II and a little later also in the Cisco IOS Software for the Cisco Catalyst switches.
Private VLAN Attack
"Private VLAN attack" is actually a misnomer because it corresponds not to a vulnerability but rather to the expected behavior of the feature. Private VLANs is a L2 feature and therefore it is supposed to isolate traffic only at L2. On the other hand, a router is a Layer 3 (L3) device and when it's attached to a Private VLAN promiscuous port it is supposed to forward L3 traffic received on that port to whatever destination it is meant to, even if it's in the same subnet as the source (@stake refers to this behavior as Layer 2 Proxy).
"Private VLAN attack" is actually a misnomer because it corresponds not to a vulnerability but rather to the expected behavior of the feature. Private VLANs is a L2 feature and therefore it is supposed to isolate traffic only at L2. On the other hand, a router is a Layer 3 (L3) device and when it's attached to a Private VLAN promiscuous port it is supposed to forward L3 traffic received on that port to whatever destination it is meant to, even if it's in the same subnet as the source (@stake refers to this behavior as Layer 2 Proxy).
Therefore, it is absolutely normal for two hosts in an Isolated VLAN to fail to communicate with each other through direct L2 communication and instead to succeed to talk to each other by using the router as a packet relay.
As with regular routed traffic, packets relayed through L2 Proxy can be filtered, if desired, through the configuration of an appropriate ACL on the forwarding device.
Here is a simple example of output Cisco IOS ACL to block the relayed traffic:
deny subnet/mask subnet/mask
permit any subnet/mask
deny any any
deny subnet/mask subnet/mask
permit any subnet/mask
deny any any
Multicast Brute Force Attack
This attack tries to exploit switches' potential vulnerabilities (read: bugs) against a storm of L2 multicast frames. @stake's test was designed to ascertain what happens when a L2 switch receives lots of L2 multicast frames in rapid succession. The correct behavior should be to constrain the traffic to its VLAN of origin, the failure behavior would be to leak frames to other VLANs.
This attack tries to exploit switches' potential vulnerabilities (read: bugs) against a storm of L2 multicast frames. @stake's test was designed to ascertain what happens when a L2 switch receives lots of L2 multicast frames in rapid succession. The correct behavior should be to constrain the traffic to its VLAN of origin, the failure behavior would be to leak frames to other VLANs.
In @stake's results, this type of attack proved ineffective against Cisco Catalyst switches because they correctly contained all the frames within their appropriate broadcast domain (no surprise here: after all, in all Catalyst switches broadcasts are just special cases of multicasts).
Spanning-Tree Attack
Another attack that tries to leverage a possible switch weakness (for example, bug) is the STP attack. All of the Cisco Catalyst switches tested by @stake support this protocol. By default, STP is turned on and every port on the switch both speaks and listens for STP messages. @stake tried to see if Cisco PVST (Per VLAN Spanning Tree) would fail open across1 multiple VLANs under specific conditions. The attack consisted in sniffing for STP frames on the wire to get the ID of the port STP was transmitting on. Next, the attacker would begin sending out STP Configuration/Topology Change Acknowledgement BPDUs announcing that he was the new root bridge with a much lower priority.
During this procedure broadcast traffic was injected by the testers to discover any possible VLAN leaks, but none were found. This is an indication of the robustness of STP's implementations on Cisco switches.
Random Frame Stress Attack
This last test can have many incarnations but in general it consists in a brute force attack that randomly varies several fields of a packet while keeping only the source and destination addresses constant. After repetitive testing by @stake's engineers, no packets were found to have successfully hopped VLANs.
Private VLANs can be used in this context to better isolate hosts at L2 and shield them from unwanted malicious traffic from untrustworthy devices. Communities of mutually-trusting hosts can be created so as to partition a L2 network into subdomains where only friendly devices are allowed to communicate with each other.
4/7/08
Dynamic Host Configuration Protocol (DHCP) Snooping
The DHCP Snooping feature provides network protection from rogue DHCP servers. It creates a logical firewall between untrusted hosts and DHCP servers. The switch builds and maintains a DHCP snooping table (also called DHCP binding database), shown in below Figure. In addition, the switch uses this table to identify and filter untrusted messages from the network. The switch maintains a DHCP binding database that keeps track of DHCP addresses that are assigned to ports, as well as filtering DHCP messages from untrusted ports. For incoming
packets received on untrusted ports, packets are dropped if the source MAC address does not match MAC in the binding table entry.
Below Figure illustrates the DHCP Snooping feature in action, showing how the intruder is blocked on the untrusted port when it tries to intervene by injecting a bogus DHCP response packet to a legitimate conversation between the DHCP client and server.
The DHCP Snooping feature can be configured for switches and VLANs. When enabled on a switch, the interface acts as a Layer 2 bridge, intercepting and safeguarding DHCP messages going to a Layer 2 VLAN. When enabled on a VLAN, the switch acts as a Layer 2 bridge within a VLAN domain.
For DHCP Snooping to function correctly, all DHCP servers connected to the switch must be configured as trusted interfaces. A trusted interface can be configured by using the ip dhcp snooping trust interface configuration command. All other DHCP clients connected to the switch and other ports receiving traffic from outside the network or firewall should be configured as untrusted by using the no ip dhcp snooping trust interface configuration command.
To configure the DHCP Snooping feature, first enable DHCP Snooping on a particular VLAN by using the ip dhcp snooping vlan [vlan-id] command in global configuration mode. (Repeat this command for multiple VLANs.)
Next, enable DHCP Snooping globally by using the ip dhcp snooping command from the global configuration mode. Both options must be set to enable DHCP snooping.
In Example below, the DHCP server is connected to the FastEthernet0/1 interface and is configured as a trusted port with a rate limit of 100 packets per second. The rate limit command ensures that a DHCP flood will not overwhelm the DHCP server. DHCP Snooping is enabled on VLAN 5 and globally activated.
Example: DHCP Snooping Configuration
Switch(config)# interface Fastethernet0/1
Switch(config-if)# ip dhcp snooping trust
Switch(config-if)# ip dhcp snooping limit rate 100
Switch(config-if)# exit
Switch(config)# ip dhcp snooping vlan 5
Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping information option
packets received on untrusted ports, packets are dropped if the source MAC address does not match MAC in the binding table entry.
Below Figure illustrates the DHCP Snooping feature in action, showing how the intruder is blocked on the untrusted port when it tries to intervene by injecting a bogus DHCP response packet to a legitimate conversation between the DHCP client and server.
The DHCP Snooping feature can be configured for switches and VLANs. When enabled on a switch, the interface acts as a Layer 2 bridge, intercepting and safeguarding DHCP messages going to a Layer 2 VLAN. When enabled on a VLAN, the switch acts as a Layer 2 bridge within a VLAN domain.
For DHCP Snooping to function correctly, all DHCP servers connected to the switch must be configured as trusted interfaces. A trusted interface can be configured by using the ip dhcp snooping trust interface configuration command. All other DHCP clients connected to the switch and other ports receiving traffic from outside the network or firewall should be configured as untrusted by using the no ip dhcp snooping trust interface configuration command.
To configure the DHCP Snooping feature, first enable DHCP Snooping on a particular VLAN by using the ip dhcp snooping vlan [vlan-id] command in global configuration mode. (Repeat this command for multiple VLANs.)
Next, enable DHCP Snooping globally by using the ip dhcp snooping command from the global configuration mode. Both options must be set to enable DHCP snooping.
In Example below, the DHCP server is connected to the FastEthernet0/1 interface and is configured as a trusted port with a rate limit of 100 packets per second. The rate limit command ensures that a DHCP flood will not overwhelm the DHCP server. DHCP Snooping is enabled on VLAN 5 and globally activated.
Example: DHCP Snooping Configuration
Switch(config)# interface Fastethernet0/1
Switch(config-if)# ip dhcp snooping trust
Switch(config-if)# ip dhcp snooping limit rate 100
Switch(config-if)# exit
Switch(config)# ip dhcp snooping vlan 5
Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping information option
Use the show ip dhcp snooping command to display DHCP snooping settings. Use the show ip dhcp snooping binding command to display binding entries corresponding to untrusted ports.
3/27/08
DNS Redirection
This attack is exactly the same as the default gateway redirection, but instead of sending back a bogus default gateway the rouge DHCP sends back a bogus DNS server. This then allows the attacker to quietly redirect just certain requests. For example, you think your accessing your bank WWW site, but the attacker is using their own DNS server to redirect you to a fake WWW site that they have set to capture your details.
Mitigation
The mitigation strategy is exactly the same as for the default gateway redirect. Stop rogue DHCP responses getting onto your network, and you won't get your details stolen by this attack.
Mitigation
The mitigation strategy is exactly the same as for the default gateway redirect. Stop rogue DHCP responses getting onto your network, and you won't get your details stolen by this attack.
Man in the Middle Attacks by defualt Gateway Redirect
This is also a simple attack. The attacker either disables the primary DHCP server using a denial of service attack then operates their own DHCP server, or they simply setup a faster DHCP than the one already on the network. When a client sends out a DHCP request it accepts the response from whichever DHCP responds first.
If the attacker wants to see all the traffic you are sending out of your local subnet, then they simply respond to your DHCP request, and specify there own machine as the default gateway. The attacker's machine then forwards on any traffic to the real default gateway. Now the attacker can see everything your sending (perfect for username and password theft, identify theft, or capturing other sensitive information).
Mitigation
Cisco have a technology to overcome this called DHCP snooping. What happens is you tell the switch which port(s) have a DHCP server plugged in. The switch then only allows that port to respond to DHCP queries. Simple. This feature is available on layer 3 switches such as the Cisco 3560, but note that the EMI feature set is often required. A limited form of DHCP snooping is available on layer 2 switches, but it can only limit the rate at which DHCP packets are sent.
First, enable the feature globally.
ip dhcp snooping vlan 1
no ip dhcp snooping information optionip
dhcp snooping
Then tell the switch to trust ports that have a DHCP server plugged into them.
interface FastEthernet x/y
ip dhcp snooping trust
That's the basic config done
If the attacker wants to see all the traffic you are sending out of your local subnet, then they simply respond to your DHCP request, and specify there own machine as the default gateway. The attacker's machine then forwards on any traffic to the real default gateway. Now the attacker can see everything your sending (perfect for username and password theft, identify theft, or capturing other sensitive information).
Mitigation
Cisco have a technology to overcome this called DHCP snooping. What happens is you tell the switch which port(s) have a DHCP server plugged in. The switch then only allows that port to respond to DHCP queries. Simple. This feature is available on layer 3 switches such as the Cisco 3560, but note that the EMI feature set is often required. A limited form of DHCP snooping is available on layer 2 switches, but it can only limit the rate at which DHCP packets are sent.
First, enable the feature globally.
ip dhcp snooping vlan 1
no ip dhcp snooping information optionip
dhcp snooping
Then tell the switch to trust ports that have a DHCP server plugged into them.
interface FastEthernet x/y
ip dhcp snooping trust
That's the basic config done
DHCP Address Starvation with MAC flooding
This is perhaps the simplest and fastest attack. DHCP servers have a limited number of addresses that they can give out. DHCP scopes commonly have less than 200 addresses that they give out to hosts (the rest of the space is often reserved for static IP devices, such as servers, printers, etc). So to stop the DHCP server from working all an attacker has to do is send DHCP requests using random MAC addresses. It keeps sending requests until the DHCP server stops responding. Of course, the DHCP has no idea what's going on, so it keeps responding to all the requests it sees coming in. It has no idea it is being attacked. This attack usually take less than 10s to complete, and uses a very small amount of bandwidth. As long as the attack uses forged MAC addresses (and the common tools for doing this attack do this) it is very difficult for the Windows administrator to track down, since all of the information they have available to them is forged.
Mitigation
Mitigation of this attack is very simple with a Cisco switch, using a feature called port security. What port security does is limit the number of MAC addresses a client machine can use. So if you enable the feature on every port that can connect to a workstation, and a workstation tries to send a packet with a MAC address different to that of a packet it has sent in the same session, the switch will shut the port down stopping the attack dead. Port security is supported on Cisco 2950's and above. The switch clears the MAC address associated with a port when the link goes down (such as the workstation being turned off, or unplugged). So it works happily with ports shared by different machines (as long as only one machine at a time is plugged into the port).
interface FastEthernet x/y
switchport port-security
Mitigation
Mitigation of this attack is very simple with a Cisco switch, using a feature called port security. What port security does is limit the number of MAC addresses a client machine can use. So if you enable the feature on every port that can connect to a workstation, and a workstation tries to send a packet with a MAC address different to that of a packet it has sent in the same session, the switch will shut the port down stopping the attack dead. Port security is supported on Cisco 2950's and above. The switch clears the MAC address associated with a port when the link goes down (such as the workstation being turned off, or unplugged). So it works happily with ports shared by different machines (as long as only one machine at a time is plugged into the port).
interface FastEthernet x/y
switchport port-security
-
AIX Environment Procedures The best way to approach this portion of the checklist is to do a comprehensive physical inventory of the server...
-
Address Resolution Protocol (ARP) provides IP-to-MAC (32-bit IP address into a 48-bit Ethernet address) resolution. ARP operates at Layer 2 ...