Re: debug ip packet help!

mbalasubramanian · ‎09-07-2003

Hi,

WE have this 1700 router and past 2 weeks it has been showing bursty excessive cpu util >90% with "ip in put " process as culprit

There have been 2 observations

1)This router which is used for internet and a bandwidth of 128k almost always shows almost 95 % input rate on its serial interface..what is INPUT for serialint and what could be causing the same...the output on the same interface always is 30-40% lesser

2)When a debug ip packet was taken..we get SOURCE AS

x.y.z.c, WHICH IS THE SERIAL IP OF THE SAME ROUTER ..now this is confusing since source i would be expecting LAN ip...is something amiss here and the "SYN" flag tops it..

IP: s="x.y.z.c" (FastEthernet0), d=54.110.159.129 (Serial0), g=54.110.159.129, len 48, forward

TCP src=23890, dst=135, seq=493328847, ack=0, win=65535 SYN

could someone help me out here

regards

deilert · ‎09-07-2003

It sounds like you are getting hit with a virus, turn on ip route-cache flow and Ip accounting on your FE , Ibeleive that port 135 is the Nachi virus

see this URL

http://www.cisco.com/en/US/products/sw/voicesw/ps556/products_tech_note09186a00801b143a.shtml

mbalasubramanian · ‎09-07-2003

We had expected the same and have patched,cleaned all the vulnerable systems some time beforeand yet no change , i had presumed that "sh ip nat translations icmp" would expose the worm in my network since its notorious for sending outgoing random pings

What has me worried is that the

"Ip debug packet detail" shows up with source x.y.z.c(fast ethernet0) x.y.z.c being the PUBLIC ip and IP OF THE SERAIL INTERFACE when i was expecting a LAN ip as source..any explaination for the anamoly

High input rate in my serial is another thing that has me stumped

i have replaced the ip with x.y.z.c

1: IP: s=x.y.z.c (FastEthernet0), d=216.52.56.51 (Serial0), g=216.52.56.51, len 40, forward

04:52:41: TCP src=23259, dst=80, seq=345078373, ack=1314229267, win=0 RST

04:52:41: IP: s=x.y.z.c (FastEthernet0), d=54.110.159.129 (Serial0), g=54.110.159.129, len 48, forward

04:52:41: TCP src=23890, dst=135, seq=493328847, ack=0, win=65535 SYN

04:52:41: IP: s=x.y.z.c (FastEthernet0), d=54.110.159.130 (Serial0), g=54.110.159.130, len 48, forward

04:52:41: TCP src=23891, dst=135, seq=493387148, ack=0, win=65535 SYN

04:52:41: IP: s=x.y.z.c (FastEthernet0), d=54.110.159.131 (Serial0), g=54.110.159.131, len 48, forward

04:52:41: TCP src=23892, dst=135, seq=493447329, ack=0, win=65535 SYN

04:52:41: IP: s=x.y.z.c (FastEthernet0), d=54.110.159.132 (Serial0), g=54.110.159.132, len 48, forward

04:52:41: TCP src=23893, dst=135, seq=493511337, ack=0, win=65535 SYN

04:52:41: IP: s=x.y.z.c (FastEthernet0), d=54.110.159.133 (Serial0), g=54.110.159.133, len 48, forward

04:52:41: TCP src=16599, dst=135, seq=493550613, ack=0, win=65535 SYN

04:52:41: IP: s=x.y.z.c (FastEthernet0), d=54.110.159.134 (Serial0), g=54.110.159.134, len 48, forward

04:52:41: TCP src=19306, dst=135, seq=493611580, ack=0, win=65535 SYN

--More-- .100.100.2 (local), d=100.100.100.168 (FastEthernet0), len 60, sending

04:52:55: ICMP type=0, code=0

04:52:55: IP: s=x.y.z.c (FastEthernet0), d=54.110.160.33 (Serial0), g=54.110.160.33, len 48, forward

04:52:55: TCP src=25071, dst=135, seq=504907137, ack=0, win=65535 SYN

04:52:55: IP: s=x.y.z.c (FastEthernet0), d=54.110.160.34 (Serial0), g=54.110.160.34, len 48, forward

04:52:55: TCP src=25072, dst=135, seq=504952232, ack=0, win=65535 SYN

04:52:55: IP: s=x.y.z.c (FastEthernet0), d=54.110.160.35 (Serial0), g=54.110.160.35, len 48, forward

04:52:55: TCP src=25075, dst=135, seq=504995509, ack=0, win=65535 SYN

JBUIST · ‎09-08-2003

You should verify that you do not have the following vunerability. Cisco Security Advisory:Cisco IOS Interface Blocked by IPv4 Packets. The url is listed below which explains in detail how the vunerablity affects your routers.

http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml

hbaerten · ‎09-09-2003

Is the router doing NAT overload using its serial interface address as outside global address?

If so, a logical explanation would seem that the debug ip packet shows the translated source address and the interface the original packet entered on.

Now, looking at the traffic pattern, it seems that someone (employee, hacker) or something (virus, worm, trojan) is doing a port scan.

So I would recommend "show ip nat translations" and see which internal address the connections originate from.

hth

Herbert

mbalasubramanian · ‎09-09-2003

Would that mean i get a source=x.y.z.c serial ip entering thru "Fast ethernet" on debug..wouldnt i be getting lan ip addresses thru f0.(yes i have overloaded serial)

What could explain excessive RX load on my serial interface disproportionate to TX load and

Is it an internal port scan??

Thanks and regards

hbaerten · ‎09-09-2003

I'm not sure, but it seems a logical explanation to me, that NAT occurs before DEBUG, so the debug output shows the translated addresss.

Regarding the RX load, could be the combination of normal traffic and incoming traffic that is a result of the scan (SYN ACK replies, ICMP unreachable replies). Doesn't your debug ip packet show the inbound packets? Could they be dropped by an ACL?

If my assumption about the debug showing the NAT address is correct, then yes the scan originates on your lan and you should check show ip nat translations to see which is the original originating ip address.

hth

Herbert

mbalasubramanian · ‎09-09-2003

Well i would presume debug captures LAN IP on F0 as

NAT happens after routing on a inside to outside packet and debug should tell me exactly that..with source as private ip and on ethernet interface..now im not so sure...can someone throw some light here

I shall check on the NAT translations

THANKS AND REGARDS

hbaerten · ‎09-09-2003

Take a look at http://www.cisco.com/warp/public/556/1.html

in the section "Troubleshoot" there is sample output of debug ip nat and debug ip packet. Notice that for each packet there is first a NAT line followed by an IP line showing the translated address.

regards,

Herbert