Tuesday, 29 September 2009


DOS and DDOS.... !

DOS or distributed denial-of-service attack is an attempt to make Computer or Any network resource unavailable to its intended users

To block and DoS attack, it is best to block the traffic as close to the source that is generating the attack As a solution we normally create ACL if the Port and IP address of attacking device is Known to us.

However Cisco PIX or ASA TCP Intercept feature can help protect resources from DoS attacks. This enables us to configure the maximum number simultanious allowed connectiones for the specific Resource and Limit the number of embryonic connections to any critical server.

Howvere Embryonic connections are connections that have not completed the TCP three-way handshake. whihc is also the type of a DOS attack

Here are some common types of DOS attack

  • ICMP Flood
  • SYN Flood
  • Tear Drop Attack
  • Distributed Denial of Service Attack (hardest to block)
A wide range of programs are used to launch DoS-attacks well it is considered as the easeast to launch and difficult to block.

If the embryonic connection limit is reached, the PIX Firewall responds to every SYN packet sent to the server with a SYN+ACK, and does not pass the SYN packet to the internal server.If the PIX/ ASA does not get an ACK back from the server, it aggressively times out that embryonic connection. threshold is defined as son as it is reached Firewall dont alow any trrafic to pass through

Cisco ASA uses the embryonic limit to trigger TCP Intercept, which protects inside systems from a DoS attack perpetrated by flooding an interface with TCP SYN packets

The PIX/ASA also supports TCP normalization where you specify criteria that identify abnormal packets, which the security appliance drops when they are detected. This feature uses Modular Policy Framework, so that implementing TCP normalization consists of

  • Identifying traffic
  • Specifying the TCP normalization criteria
  • Activating TCP normalization on an interface.

Thursday, 3 September 2009

Unidirectional Link

Unidirectional Link Detection Protocol

Hi guys I have an interesting issue this week. I just Move My core Switch from one Location to another and for no apparent reason some users within the network reported connection issues to hosts , Half of the newtork went down and then all of a sudden connection restored but quickly lost again.

Remember the network was having 2 x Core and then two distribution switches and all the access switches had a resiliance connectivity and are running STP, HSRP, VTP. I was able to access one of the core switches and connectivity to other core was intermitent A very quick trip to the distribution point andconsole cable connection into the core switches revealed the issue.

The two switches 6500 has 2 x 1Gb EtherChannel configured on either end, connected by fibre connections. One side of the connection reported that both links were active in the Etherchannel. The other side had one link as down and the logs showing that the connection had left the EtherChannel.

The exact reason for this is still unknown but this type of issue occurs, where one side sees the link as up but the other sees it as down, is called a unidrectional Link failure. To solve the matter immediately , I shut down the faulty link at the end replace GBIC . As soon as this was done
everything returned back to normal operations and timed out pings came back to replies.

This highlighted an issue with the Etherchannel configuration on the switches however.

I have an advise from network forums to use a mode of desirable on either side of an Etherchannel connection, rather than forcing the Etherchannel up. The on mode forces a port to join an Etherchannel without any sort of Etherchannel protocol negotiation taking place. Using the desirable keyword instead of the on keyword means that the switch uses the Port Aggregation Protocol (PAgP). When using PAgP the switch learns of partner interfaces on other switches that support PAgP and dynamically groups its interfaces into an Etherchannel.

In the situation I mentioned above this happened when an interfaces from the etherchannel stopped seeing PAgP packet (when we were moving our core Switch) . and it is quiet possible for one switch to move the interface into stand-alone mode and pass traffic across a broken link, as it was still seeing this link as up. In order to help in these type of sitations Cisco developed the Unidirectional Link Dection protocol.

UDLD is a Layer 2 (L2) protocol that works with the Layer 1 (L1) mechanisms to determine the physical status of a link. At Layer 1, auto-negotiation takes care of physical signaling and fault detection. UDLD performs tasks that auto-negotiation cannot perform, such as detecting the identities of neighbors and shutting down misconnected ports. When you enable both auto-negotiation and UDLD, Layer 1 and Layer 2 detections work together to prevent physical and logical unidirectional connections and the malfunctioning of other protocols.

By enabling UDLD in aggressive mode when a port on a bidirectional link that has a UDLD neighbor relationship established stops receiving UDLD packets, UDLD tries to reestablish the connection with the neighbor. After eight failed retries, the port is disabled, whihc avoids loops in the newtork inorder to prevent spanning tree loops, nonaggressive UDLD is fast enough to shut down a unidirectional link before a blocking port transitions to the forwarding state (with default spanning tree parameters).

here are commands to enable UDLD

SWA(config)#int fas0/1
SWA(config-if)#udld port

To configure aggressive mode only one more keyword is required

SWA(config-if)#int fas0/1
SWA(config-if)#udld port aggressive

IN cisco 6500 series switch periodically transmits UDLD packets to neighbor devices, If the packets are echoed back within a specific time frame and they are lacking a specific acknowledgment (echo), the link is flagged as unidirectional and the LAN port is shut down. Devices on both ends of the link must support UDLD in order for the protocol to successfully identify and disable unidirectional links. By Default UDLD is locally disabled on copper LAN ports