[EMAIL PROTECTED] wrote: > > Thanks Priscilla. I figure it was some sort of spoofing which > is what I > ended up reporting last night. The traffic on the edge router > is under > controll. I was able to narrow down which VLAN on the switch > it was coming > in on. There is someone going onsite this morning and we are > going to work > on narrawing down the actual culprit PC. It should not be > difficult to spot > by looking at the LED on the switch (I hope). The attack seems > to come in > spurts but when it comes, I see anywhere from about 3000-15000 > packets per > second that last about 10 seconds. The weird thing is that > when I remove > the access-list that is currently filtering the 127 address, > the attack last > much longer. It is almost like it knows that the access-list > has been > removed.
That is weird. You would have to put a sniffer on it to see if there's an explanation. > Since the traffic that I am filtering is not related > to ICMP then > I know that I am not sending out any Unreachable message back > to the source. You could still be sending Unreachable or some other ICMP messages. ICMP messages can go out in response to any packet. They don't just go out in response to ICMP packets, if that's what you meant by your comment. In fact, there's a good chance you are sending Type 3, Code 13 ICMP messages (Administratively Prohibited) when you have the access list enabled. Of course, they would be sent back to 127.x.x.x, so they might not work, though?! :-) So that woudn't explain the host backing off... I wanted to mention one more thing. In my previous message I was concerned about all the packets that were 1-32 bytes. I said those would be illegal Ethernet runts. I'm guessing that Ethernet isn't actually relevant here, though. I bet the Ethernet header has been stripped off by this point. Also any padding that Ethernet added to make it a legal length has been stripped off. The info reported by "show ip cache flow" is probably from IP's point of view. In that case a packet that was 32 bytes long would be legitimate. It could be a 20-byte IP header and a 12 byte ICMP message, in fact. You might want to find out what they are. I stick to my original overall comment that having 75% of your packets being that small is weird. Does anyone know for sure if "show ip cache flow" reports packet sizes after the data-link-layer header has been stripped?? I couldn't find an answer on Cisco's site. Good luck finding the culprit! Let us know how it goes. Thanks. Priscilla > > > > > > Thanks, > > Mario Puras > SoluNet Technical Support > Mailto: [EMAIL PROTECTED] > Direct: (321) 309-1410 > 888.449.5766 (USA) / 888.SOLUNET (Canada) > > > > -----Original Message----- > From: Priscilla Oppenheimer [mailto:[EMAIL PROTECTED]] > Sent: Thursday, December 26, 2002 10:57 PM > To: [EMAIL PROTECTED] > Subject: RE: Possible Attack???? [7:59813] > > > Sending with a source address of 127.x.x.x is often used in IP > spoofing. You > should try to find out which station is doing this. It could be > compromised. > Of course, it will be hard to find, but if the packets haven't > crossed a > router, the MAC address will have a clue. The first six bytes > of the MAC > address are a vendor code. Of course, if all your equipment is > from one > vendor, that doesn't help much! > > The destination address of 108.122.0.0 is strange also. I > looked it up in > the ARIN Whois database and it says it's part of a range > reserved by IANA. > I'm not sure why it's reserved, but it seems like a suspicious > address to > use. > > So, you're doing the right thing to filter out these packets. > > But you said the problem remained. The other thing I noticed > that's strange > is probably unrelated to a possible attack. > > Why are 75% of your packets in the 1-32 byte range? Those are > illegal runt > frames on Ethernet. Could you have a duplex mismatch problem?? > You should > check the output of show int Fa0/1. > > Good luck! > > Priscilla > > [EMAIL PROTECTED] wrote: > > > > Hi all. I was wondering if someone can share some light on a > > wierd issues > > that I am seeing. This perhaps maybe an attack from an > > internal or infected > > host within the network or simply a malfunctioning NIC. > > Basically, I have a > > Cisco 3662 with 2 Satellite links. I noticed that the main > WAN > > link > > (1.544mb) was bursting outbound to sometimes 20mb. I noticed > a > > lot of > > output drops and the links started to flap and as a result BGP > > sessions > > starting going down causing huge problems. Once I was able to > > get the BGP > > under control, I enabled Netflow on the inbound interface > > (FE0/1) to see > > what type of traffic could be causing this issue and this is > > when I noticed > > the below: > > > > > > Here is the output of the Netflow: > > > > cisco_3600_one#show ip cache flow > > IP packet size distribution (4096357 total packets): > > 1-32 64 96 128 160 192 224 256 288 320 352 > 384 > > 416 448 > > 480 > > .753 .167 .017 .005 .001 .002 .001 .001 .001 .001 .000 .000 > > .000 .000 > > .000 > > > > 512 544 576 1024 1536 2048 2560 3072 3584 4096 4608 > > .000 .001 .008 .005 .027 .000 .000 .000 .000 .000 .000 > > > > IP Flow Switching Cache, 278544 bytes > > 978 active, 3118 inactive, 121929 added > > 2503952 ager polls, 0 flow alloc failures > > last clearing of statistics never > > Protocol Total Flows Packets Bytes Packets > > Active(Sec) > > Idle(Sec) > > -------- Flows /Sec /Flow /Pkt /Sec > > /Flow /Flow > > TCP-Telnet 41 0.0 50 40 0.0 > > 31.3 14.4 > > TCP-FTP 87 0.0 7 65 0.0 > > 17.0 12.1 > > TCP-FTPD 27 0.0 135 211 0.0 > > 83.0 3.5 > > TCP-WWW 43121 0.3 8 335 2.8 > > 3.6 2.7 > > TCP-SMTP 1137 0.0 6 173 0.0 > > 9.8 9.7 > > TCP-BGP 1 0.0 673 68 0.0 > > 1796.8 3.6 > > TCP-Frag 2 0.0 1 40 0.0 > > 0.0 15.5 > > TCP-other 33285 0.2 14 246 3.7 > > 24.0 10.3 > > UDP-DNS 6005 0.0 1 73 0.0 > > 1.3 15.4 > > UDP-NTP 10 0.0 1 76 0.0 > > 0.0 15.4 > > UDP-other 13772 0.1 6 78 0.7 > > 1.2 15.5 > > ICMP 2904 0.0 3 72 0.0 > > 19.1 15.4 > > IP-other 20559 0.1 148 20 24.5 > > 6.8 15.4 > > Total: 120951 0.9 33 76 32.2 > > 9.9 9.4 > > > > > > . > > . > > . > > SrcIf SrcIPaddress DstIf DstIPaddress Pr > > SrcP DstP > > Pkts > > Fa0/1 127.0.0.124 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 285 > > Fa0/1 127.0.0.125 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 38 > > Fa0/1 127.0.0.122 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 35 > > Fa0/1 127.0.0.123 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 296 > > Fa0/1 127.0.0.120 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 33 > > Fa0/1 127.0.0.121 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 36 > > Fa0/1 127.0.0.118 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 52 > > Fa0/1 127.0.0.116 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 189 > > Fa0/1 127.0.0.117 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 277 > > Fa0/1 127.0.0.114 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 32 > > Fa0/1 127.0.0.115 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 215 > > Fa0/1 127.0.0.112 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 177 > > Fa0/1 127.0.0.113 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 80 > > Fa0/1 127.0.0.110 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 234 > > Fa0/1 127.0.0.111 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 279 > > Fa0/1 127.0.0.108 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 171 > > Fa0/1 127.0.0.109 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 139 > > Fa0/1 127.0.0.106 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 151 > > Fa0/1 127.0.0.107 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 57 > > Fa0/1 127.0.0.104 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 67 > > Fa0/1 127.0.0.105 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 34 > > Fa0/1 127.0.0.102 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 272 > > Fa0/1 127.0.0.103 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 144 > > Fa0/1 127.0.0.100 Se1/2.500 108.122.0.0 00 > > 0000 0000 > > 88 > > . > > . > > . > > . > > > > > > The list goes on and on showing 127.x.x.x. If you notice that > > the incoming > > interface is my Fast Ethernet interface but the incoming > source > > address is a > > 127.x.x.x. It is going out my WAN link (the same one that has > > been peaking > > to ~20MB) destined to a boggus Network. The protocol is > boggus > > as well. > > > > > > I enabled an access-list to block this 127.x.x.x address > > inbound from my FE > > interface and that has seem to take care of the spikes but the > > problem is > > still present. Anyone have any ideas what this could be????? > > > > > > > > > > Thanks, > > > > Mario Puras > > SoluNet Technical Support > > Mailto: [EMAIL PROTECTED] > > Direct: (321) 309-1410 > > 888.449.5766 (USA) / 888.SOLUNET (Canada) > > Message Posted at: http://www.groupstudy.com/form/read.php?f=7&i=59843&t=59813 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
