Not sure if this will help, but you could enable ip accounting on the uplink interface to the switch. Watch for the address that is pouring out the most requests. Then use sho ip arp x.x.x.x to find the mac address. From there you could go to the switch and do a show cam dynamic or if IOS version, show mac-address-table with the mac address found with the most requests. This would hunt down the culprit machine without a person walking to each individual machine.
Cheers, -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Sam Sneed Sent: December 27, 2002 1:04 PM To: [EMAIL PROTECTED] Subject: Re: Possible Attack???? [7:59813] Do you run SNMP and mrtg on theswitch? You can than graphically see which host has been pouring out all the traffic with ease. wrote in message [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > 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. 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. > > > > > > 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=59873&t=59813 -------------------------------------------------- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]