Ali Abbas

Hi there!

Jeremy on “evilrouters.net” issued a post regarding a white-paper published on the GCIH website, the paper is entitled “IOSTrojan: Who really owns your router?“. The pdf is available at this link and is about 26 pages. Being curious as to all things IT, especially in the domains of Networking and Unix, I dived in and read the pdf in its integrality and here is my take

In the major part of this article, the author mainly focus on demonstrating how a tcl script executed could lure the user into being in an ios shell and not tcl shell by parsing and handling most of the IOS commands. While the author makes a good point for anyone not being aware of the tcl script setup, it makes me wonder as to which extend, a scenario as such would take place in a production environment and whether this would qualify as such as a Trojan, since the code process of execution is not hidden from the user’s view, which itself brings me to the following question: “who does run a tcl script on a production network equipment without source reading it?”

Last but not least, yet again another reminder that the weakest link in a deployed environment (whether it be a deployed network or server farms) is the design and maintenance of the security guideline and practices.

Following my blog post on OSPF BDR – DR election, I have received various questions regarding OSPF and thus I decided to write a small excerpt to describe the type of LSAs generated whether it is in a stub area etc…

Before I start, it is important to keep in mind, that LSAs are carried into OSPF packet 4 . Those OSPF packet 4 are referred as LSU (Link-State Update) and carries the router’s LSA (one or more).

Now, they are 11 type of LSAs, however LSA 6 – 8/9/10/11 will not be covered in this post but in another post

LSA-1 – Router Link LSA

By default all routers in an OSPF area will be sending LSA updates of type 1. Those LSA never gets forwarded out of the area and are sent by each member to inform the other members of its links states, adjacencies (stub interfaces etc..) and cost to the area.

LSA-2 – Network Link LSA

Back to my previous post, this LSA is only generated by the DR (Designated Router); it is generated to inform the routers within its area, which routers are all part of the same segment.

LSA-3 – Network Summary Link

This LSA is only generated by the ABR and exchanged between the areas. It allows routing and communication between the areas as the ABR agregates the routes it learns.

LSA-4 – AS External ASBR Summary Link

Sent from an ABR to the routers in its area, it defines the next hop to reach the external routes advertized by the ASBR

LSA-5 – External Link LSA

This LSA is generated by an ASBR. It contains the routes redistributed into the area. When looking at the routing table, you will see that those routes will have an appendix of E1 or E2.

LSA 7 – NSSA External LSA

This LSA is also generated by the ASBR inside a NSSA, it describes the routes that have been distributed into the NSSA. Furthermore, keep in mind that as the LSA leaves the NSSA to the backbone, it is translated as an LSA type 5 (LSA-5). When looking at the routing table, you will see that those routes have an appendix of N1 or N2.*

As a short summary

Standard areas – LSA type { 1 – 2 – 3 – 4 – 5 }

Stub areas – LSA type { 1 – 2 – 3 }

Totally stubby areas – LSA type { 1 – 2 – 3 }

Not-so-stubby areas – LSA type { 5 – 7 }

A 52mn presentation by Allan Packer and Neelakanth Nadgir from Sun Microsystems.

** keep in mind ZFS can only be used in userspace on linux (through fuse) due to license comptability issue (GPL/BSD license)

enjoy!

A while back, I wrote a post on Ethernet Flow Control and IGMP snooping and how using TCP flow control on top of Ethernet Flow Control could easily alienate your network. If you are not familiar with Ethernet Flow Control, then I highly suggest, you go over my post in order to understand what I will be talking about here.

An understanding of the Spanning Tree Protocol is also highly required, which I won’t go in depth in this post.

Small Recap

Ethernet Flow Control makes use of PAUSE frames in order to notify an endpoint host to stop sending packet for an X amount of time; Depending on the bandwidth of the link, the PAUSE frames are sent at a specific interval of time.

100Mbps – each 300ms
1Gbps – each 30ms
10Gpbs – each 3ms

That is to say, sending more PAUSE frame than the appropriate set interval will considerably slow down the network and generate unexpected side effects.

Using PAUSE frame to have a new STP topology converged – DOS

- Target Designated ports

Because PAUSE Frame simply notify the host to stop sending frames; if we were to flood all the Designated ports of a root switch, we would immediately cut all transmission of root BPDU and user frame. This by consequence, will cause all root ports on the other switch to enter into a new STP convergence, since the root bridge has been completely cut off.

- Target Blocking ports

Remember, in the Blocking state, the port still receives BPDU without forwarding frames. Now let’s say we decide to flood all the segments connecting to the blocking ports. What do you think will happen? well, the blocked port no longer receives BPDU and after 20seconds starting transitioning to the listening state, a total of 50 seconds later, a new convergence has taken place, resulting in a redundant link becoming active and thus creating a switching loop/brodcast storm, which will degrade the network and bring it to its knees.

How to prevent an STP DOS

1. Disable Ethernet Flow Control on a port if not needed

2. Set a threesold for Pause Frames sent and received

3. Monitor for STP topology state changes

4. Monitor the traffic for high frequencies of TCN and TC BPDUs

Cheers,

Ali

I am not usually out looking to post comic strips on this blog, but surely enough Dilbert nailed it today.