Nachi-A worm consumed all of router's memory?

Discussion in 'Cisco' started by duder, Dec 9, 2003.

  1. duder

    duder Guest

    Last night, I ran into an interesting problem with one of our
    customers.

    They had a PC infected with the Nachi-A worm that was mass ICMP
    flooding to the 10.0.0.0/8 network. It was also (to a lesser degree)
    flooding to Ports 80 and 135. The PC was hanging off of ethernet0/0
    on a 26xx router. The 10.0.0.0/8 network had two equal cost paths
    going out and the router was load balancing across the paths. The
    router was running Fast Switching. Also, the bandwidth on both
    outbound links was totally saturated and the router was dropping
    outbond packets. This was causing the ISDN back up to periodically
    come up.


    The router, and the router's upstream neighbor (a 7200) had been
    suffering for a week or so from memory allocation errors and at least
    one spontaneous reload. This was very puzzling since other sites were
    running virtually identical configurations.

    Then I found this wonderful newsgroup message:

    ************************************
    >Subject: Regarding Case Number V44290
    >
    >Hello xxxxx, I've done some testing here with Nmap. I was able to create a
    >test bed that can cause problems & symptoms similar to those you reported.
    >But in summary, the router is functioning normally & depending on the
    >network topology the behavior you experienced would be expected.
    >
    > >From show processor memory, the ip input process is the process that

    >maintains the ip fast switching cache. This fast switching cache is used
    >when forwarding packets to avoid interrupting the cpu for repetitive route
    >table lookups. The key issue is the behavior of the fast cache and the way
    >it gets built.
    >
    >There are a number of scenarios that will cause the fast cache to install an
    >entry that essentially looks like a host route. For instance, with only 1
    >path to a destination, we will install an entry into the fast cache that
    >covers the entire network. Example: 100.0.0.0/8. However, when multiple
    >equal cost paths to a destination exist, we will install an entry into the
    >fast cache for each destination. Example: 100.0.0.1/32, 100.1.1.1/32,
    >100.2.2.2/32...and so on. This helps ensure load balancing. Additionally,
    >depending on whether routes are directly connected, and/or subnetted, or the
    >next hop of a static route, the results can vary.
    >
    >When running Nmap & scanning every address in a class A ip network, if
    >conditions warrant the installation of a /32 entry into the fast cache this
    >would allow the fast cache to consume a tremendous amount of memory and in
    >that scenario all available dram could be consumed. This creates additional
    >problems because there isn't enough memory to support other features on the
    >router.
    >
    >Since Nmap isn't a normal application ran on networks, this issue isn't a
    >concern in most networking environments. However, if this is a major concern
    >you could run CEF (Cisco Express Forwarding). The behavior I just explained
    >does not occur when running CEF. But you will need to run 12.0 on the Cat5
    >RSM. Other workarounds such as disabling fast switching (no ip route-cache)
    >or using max-paths 1 aren't really feasible. CEF is the better solution.
    >
    >Thanks,

    *********************************************************

    Sure enough, I put an access-list up blocking the infected PC at the
    ethernet port and presto.... No more memory allocation errors, no
    more bouncing ISDN line. The router and it's 7200 neighbor have been
    running clean for almost 24 hours.

    Comments?


    duder
     
    duder, Dec 9, 2003
    #1
    1. Advertising

  2. duder

    shope Guest

    <duder> wrote in message news:...
    > Last night, I ran into an interesting problem with one of our
    > customers.
    >
    > They had a PC infected with the Nachi-A worm that was mass ICMP
    > flooding to the 10.0.0.0/8 network. It was also (to a lesser degree)
    > flooding to Ports 80 and 135. The PC was hanging off of ethernet0/0
    > on a 26xx router. The 10.0.0.0/8 network had two equal cost paths
    > going out and the router was load balancing across the paths. The
    > router was running Fast Switching. Also, the bandwidth on both
    > outbound links was totally saturated and the router was dropping
    > outbond packets. This was causing the ISDN back up to periodically
    > come up.
    >
    >
    > The router, and the router's upstream neighbor (a 7200) had been
    > suffering for a week or so from memory allocation errors and at least
    > one spontaneous reload. This was very puzzling since other sites were
    > running virtually identical configurations.
    >
    > Then I found this wonderful newsgroup message:
    >
    > ************************************
    > >Subject: Regarding Case Number V44290
    > >
    > >Hello xxxxx, I've done some testing here with Nmap. I was able to create

    a
    > >test bed that can cause problems & symptoms similar to those you

    reported.
    > >But in summary, the router is functioning normally & depending on the
    > >network topology the behavior you experienced would be expected.
    > >
    > > >From show processor memory, the ip input process is the process that

    > >maintains the ip fast switching cache. This fast switching cache is used
    > >when forwarding packets to avoid interrupting the cpu for repetitive

    route
    > >table lookups. The key issue is the behavior of the fast cache and the

    way
    > >it gets built.
    > >
    > >There are a number of scenarios that will cause the fast cache to install

    an
    > >entry that essentially looks like a host route. For instance, with only 1
    > >path to a destination, we will install an entry into the fast cache that
    > >covers the entire network. Example: 100.0.0.0/8. However, when multiple
    > >equal cost paths to a destination exist, we will install an entry into

    the
    > >fast cache for each destination. Example: 100.0.0.1/32, 100.1.1.1/32,
    > >100.2.2.2/32...and so on. This helps ensure load balancing. Additionally,
    > >depending on whether routes are directly connected, and/or subnetted, or

    the
    > >next hop of a static route, the results can vary.
    > >
    > >When running Nmap & scanning every address in a class A ip network, if
    > >conditions warrant the installation of a /32 entry into the fast cache

    this
    > >would allow the fast cache to consume a tremendous amount of memory and

    in
    > >that scenario all available dram could be consumed. This creates

    additional
    > >problems because there isn't enough memory to support other features on

    the
    > >router.
    > >
    > >Since Nmap isn't a normal application ran on networks, this issue isn't a
    > >concern in most networking environments. However, if this is a major

    concern
    > >you could run CEF (Cisco Express Forwarding). The behavior I just

    explained
    > >does not occur when running CEF. But you will need to run 12.0 on the

    Cat5
    > >RSM. Other workarounds such as disabling fast switching (no ip

    route-cache)
    > >or using max-paths 1 aren't really feasible. CEF is the better solution.
    > >
    > >Thanks,

    > *********************************************************
    >
    > Sure enough, I put an access-list up blocking the infected PC at the
    > ethernet port and presto.... No more memory allocation errors, no
    > more bouncing ISDN line. The router and it's 7200 neighbor have been
    > running clean for almost 24 hours.
    >
    > Comments?


    Seen this elsewhere - it really seems to hurt 7500 series boxes, but all
    routers can suffer (had it on Nortel 8600s as well, until the recent code
    upgrades limited ARP table sizes and CPU load).

    HP managed to generate ARP scans with a laserjet management tool several
    years ago - had exactly the same effect - i suppose that counts as malice
    replicating poor programming....

    BTW - you may want to check your ISDN rules / floating routes - if packets
    to random addresses bring up ISDN then you have a large telephone bill
    waiting to happen.
    >
    >
    > duder

    --
    Regards

    Stephen Hope - remove xx from email to reply
     
    shope, Dec 12, 2003
    #2
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Lord Shaolin
    Replies:
    6
    Views:
    2,586
    John Tate
    Aug 20, 2003
  2. Blake McNeill
    Replies:
    0
    Views:
    445
    Blake McNeill
    Nov 18, 2003
  3. NACHI-B : WHITE WORM ?

    , Feb 13, 2004, in forum: Computer Security
    Replies:
    3
    Views:
    538
  4. Replies:
    2
    Views:
    434
  5. ~misfit~

    worm/nachi

    ~misfit~, Sep 19, 2003, in forum: NZ Computing
    Replies:
    28
    Views:
    816
    Matt B
    Sep 23, 2003
Loading...

Share This Page