being bombarded by subnet
Charles Chear
I am an @home cable subscriber. Just recently (today and yesterday),
I've noticed that my modem traffic lights just wouldn't stop
flickering. I run a webserver, but I rarely recieve traffic like that.
So I turn on tcpdump and started logging. This is just a sample of
what I found:
03:50:45.016779 arp who-has cn199198-a.wall1.pa.home.com tell
65.9.96.1
03:50:45.034292 proxy1.oaks1.pa.home.com.domain > beef.1286: 29767*
1/2/2 (183)
03:50:45.038684 arp who-has cn239275-a.wall1.pa.home.com tell
65.9.96.1
03:50:45.046594 arp who-has cn853722-a.wall1.pa.home.com tell
24.180.182.1
03:50:45.105566 arp who-has cn20953-a.wall1.pa.home.com tell
24.40.36.129
03:50:45.157442 arp who-has cn177336-a.wall1.pa.home.com tell
65.9.96.1
03:50:45.158264 beef.1286 > proxy1.oaks1.pa.home.com.domain: 29768+
(41)
03:50:45.188762 proxy1.oaks1.pa.home.com.domain > beef.1286: 29768*
1/2/2 (179)
03:50:45.310764 arp who-has cn977747-a.wall1.pa.home.com tell
65.14.130.1
03:50:45.362506 arp who-has cn269587-a.wall1.pa.home.com tell
65.14.130.1
03:50:45.363333 beef.1286 > proxy1.oaks1.pa.home.com.domain: 29769+
(44)
03:50:45.455622 proxy1.oaks1.pa.home.com.domain > beef.1286: 29769*
1/2/2 (184)
03:50:45.461046 arp who-has cn766857-a.wall1.pa.home.com tell
65.2.69.1
03:50:45.841089 arp who-has cn240908-a.wall1.pa.home.com tell
24.180.182.1
03:50:45.841926 beef.1286 > proxy1.oaks1.pa.home.com.domain: 29770+
(44)
03:50:45.861385 proxy1.oaks1.pa.home.com.domain > beef.1286: 29770*
1/2/2 (162)
03:50:45.921475 arp who-has 24.252.109.201 tell 24.252.109.129
03:50:46.204721 arp who-has cn783524-a.wall1.pa.home.com tell
65.2.69.1
03:50:46.657553 arp who-has 65.14.130.230 tell 65.14.130.1
03:50:47.168588 arp who-has cn75505-a.wall1.pa.home.com tell
65.14.130.1
03:50:47.186171 arp who-has cn187960-a.wall1.pa.home.com tell
65.14.130.1
03:50:47.350895 arp who-has cn852171-a.wall1.pa.home.com tell
65.2.69.1
03:50:47.355368 arp who-has cn123823-a.wall1.pa.home.com tell
24.180.182.1
*.wall1.pa.home.com is a hostname of my locality. I was wondering if
any other people were experiencing the same thing... or could tell why
this is happening.
Noone
totally unique attack that appears to have started yesterday..
"Charles Chear" <p...@privacyx.com> wrote in message
news:4a174f07.01080...@posting.google.com...
Jonnie Santos
flickering all the time - not sure what's going on. It usually only
flickered when I was accessing the net. Even when both machines (Winbox and
a Mac) are powered off, the data light continues to flicker...
"Charles Chear" <p...@privacyx.com> wrote in message
news:4a174f07.01080...@posting.google.com...
Daniel C
are thousands of ARP requests. I called @home tech support and they said it
is the code red virus. I doubt it. The mac address that it is coming from,
indicates that it is some of CISCO product.
I don't know much about networks, but it seems like some kind of denial of
service attack on CISCO routers.
- Daniel C
"Charles Chear" <p...@privacyx.com> wrote in message
news:4a174f07.01080...@posting.google.com...
Al C
You are seeing a sideeffect of CodeRed and a system design flaw I
reported in 02/01.
There's a very good reason to be concerned about the ARP traffic.
This is a security flaw. These are ARP requests that can be used to tell
the @home backend how to route the traffic. You can steal any IP address
by setting your PC to it (or doing something a tad more advanced). When
the query comes to you again, you will own the address and new packets
will come to you.
In fact this allows anyone to pretend to be anyone else. All they
require is an ARP packet to gain access to the address.
Without any tech knowledge, all you have to do is sniff the
network, watch the progression of ARP broadcasts and setup your computer
to be at the right address when they get to you. Very easy to do when
you are receiving 1000 request every five minutes. If you look at the
traffic you will see repetitive requests for the same IP. Set your PC to
one of the addresses listed. On the next request, you will be assigned
that IP by the backend and begin to receive packets destined for it.
Simply use another connection or a friend to verify that you are
receiving the traffic someone else should be getting.
Open ARP assignments should NOT be allowed on a publicly distributed
network. ARP is not normally routed traffic.
@home is claiming they are doing the ARP traffic to fight CodeRed, The
ARP storms are likely NOT the result of @home trying to fix
anything. My feeling is that the backend eqpt is ARPing to try and find
PCs so that it can deliver traffic. It is doing so in such high volume
because CodeRed is randomly scanning addresses that are not up and
running. When they cannot be located the backend systems ARP to try and
locate the missing host.
CodeRed in itself is not compromising the network, the ARP-based design
is doing so. Anytime anyone disconnects their PC, they are open to the
possibility that traffic intended for their machine could end up going
to another @home user who as stolen their IP (perhaps accidentally).
Whether that is important to anyone or not I guess depends on the nature
of the data.
Look here for more:
http://groups.google.com/groups?q=%2Barp+%2Bsb3100&hl=en&safe=off&rnum=2&selm=3AC51F7A.79C236E5%40home.takeoutthispart.com
http://cablemodem.homestead.com
AT&T's last response (on 5/19) to me on this (reported 2/01) was:
"I sincerely apologize for any problems this may have caused. We are
still looking into this matter. No clear indication has been given
about this yet."
Other threads here has said that Microsoft is not to blame for this.
This
is ridiculous. The constant design initiative from MS is to integrated
every product into every other product and to enable what are know to be
compromising features by default (e.g. macro and shell script
processing).
@home, Motorola, and Microsoft are all to blame for various aspects of
these problems. Microsoft has addressed the CodeRed vulnerability.
Motorola has stuck it's head in the sand. @home is just lying to its
customers.
--
Alan Capesius, MCSE
http://cablemodem.homestead.com
Kip Patterson
other machines on the net. If it sends a message to an IP on your subnet that
is unoccupied, then the router, Cisco most likely, sends an ARP broadcast
looking for a machine with that IP. This is the source of the ARP broadcast you
are receiving.
Just out of curiosity, I tried to connect to a number of the IP's that are
showing up in my Zone Alarm log. Some won't connect, most have no default page,
but I was able to bring up three. One of these had been defaced.
A lot of folks need to take their servers down. I suspect that the ISP's will
be out there hot and heavy in the days to come shutting folks down.
Kip Patterson
Daniel C
EtherPeek for Windows
ftp://ftp.wildpackets.com/public/demos/epwdemo.exe
This program will show the contents of the ARP requests that are causing the
blinking light on your modem.
I downloaded about 8 programs. This is the only one that I found that
decoded ARP. It is 7.3 megabytes. Let me know if you know of a better
packet sniffer.
- Daniel C.
"Kip Patterson" <ripa...@columbus.rr.com> wrote in message
news:3B6DFAB4...@columbus.rr.com...
Daniel C
program that seems better:
http://download.cnet.com/downloads/0-10101-100-6648690.html?tag=st.dl.10001-
103-1.lst-7-7.6648690
http://www.network-spy.com/netspy.exe
Only 600K download versus 7.3 megs.
- Daniel C.
"Daniel C" <Dani...@nospam.home.com> wrote in message
news:SKnb7.88396$Cy.13...@news1.rdc1.az.home.com...
Noone
gateway..
"Daniel C" <Dani...@nospam.home.com> wrote in message
news:SKnb7.88396$Cy.13...@news1.rdc1.az.home.com...
Noone
netspy, and it has the ability to run for 5 minutes and capture up to 250
packets vs 30 SECONDS worth of use for netspy..
"Daniel C" <Dani...@nospam.home.com> wrote in message
news:E_nb7.88454$Cy.13...@news1.rdc1.az.home.com...
Joe Funk
your thinking on the ARP-discovery thing due to code red. This basically
tells me it is most likely not a misconfiguration of some sort that is now
causing ARP requests to be passed all over (my original idea as I don't
trust @home) that were always going on. In fact, if I you understand
correctly, this is part and parcel a combination of that "internet slowdown"
that accompanies the code red propagation as well as @home's poor network
design. The latter part being that although you might not easily eliminate
collision domains on coax bus-type or cable networks on a host by host basis
(they have to share the wire or 'contend' for access), you can to a lesser
degree do so by at least creating smaller segments that are there own
collision domains.
Joe Funk
"Al C" <a...@tech-world.takethispartout.com> wrote in message
news:3B6DE5C5...@tech-world.takethispartout.com...
Robin Walker
Al C <a...@tech-world.takethispartout.com> wrote:
>There's a very good reason to be concerned about the ARP traffic.
>This is a security flaw. These are ARP requests that can be used to tell
>the @home backend how to route the traffic. You can steal any IP address
>by setting your PC to it (or doing something a tad more advanced). When
>the query comes to you again, you will own the address and new packets
>will come to you.
>
>In fact this allows anyone to pretend to be anyone else. All they
>require is an ARP packet to gain access to the address.
Any attempt to do this could be noticed by the head end straight away,
as there would be a mismatch between the apparent IP address of the
source, and the MAC address that the head end knows is allocated to
that IP address (the UBR, or head end, is a DHCP Relay Agent). My
cable operator automatically disconnects any customer trying to spoof
an IP address other than their own.
However, the ARP traffic you are all seeing, although it appears to
be coming from the UBR, is just as likely to be coming from other
customers on the same sub-net.
Because a cable network has spilt downstream and upstream (unlike a
true ethernet), all traffic which is broadcast appears to come from
the UBR. Any customer who transmits a broadcast sends the packet
on the upstream to the UBR, and the UBR then reflects the broadcast
on the downstream. Thus all broadcasts appear to come from the UBR,
and you probably cannot tell whether the ARP originated on the local
cable network, or whether it came from the outseide world via the UBR.
Cable networks differ: on my one, a packet sniffer can see the ARP
requests, but it never sees an ARP response.
--
--
Robin Walker, (Junior Bursar), Queens' College, Cambridge, CB3 9ET, UK
rd...@cam.ac.uk http://www.quns.cam.ac.uk/ Tel:+44 1223 335528 Fax:335566
Joe Funk
that they are not. In my analysis of the MAC level broadcasts (ARP
requests) that I am being hit with the Source IP is first of all almost
always a x.x.x.1 address, with a few exceptions, secondly they are all over
IP wise. The mask supplied by the ISP is 255.255.255.0 for a class A, but
beyond all that, some are from addresses with even the first octet being a
different value. The SMS version of MS network monitor is a pretty decent
analysis tool as far as detail goes.
"Robin Walker" <rd...@cus.cam.ac.uk> wrote in message
news:9kln7d$h9j$1...@pegasus.csx.cam.ac.uk...
Kimberly Murphy-Smith
<ripa...@columbus.rr.com> wrote:
>The Code Red virus, having infected a Microsoft IIS, proceeds to try to infect
>other machines on the net. If it sends a message to an IP on your subnet that
>is unoccupied, then the router, Cisco most likely, sends an ARP broadcast
>looking for a machine with that IP. This is the source of the ARP broadcast you
>are receiving.
>
>Just out of curiosity, I tried to connect to a number of the IP's that are
>showing up in my Zone Alarm log. Some won't connect, most have no default page,
>but I was able to bring up three. One of these had been defaced.
I'm glad you suggested this, as I just tried to connect to one of the
systems ZA blocked. Sure enough, it was a server running IIS. (I got
a 403 error saying "Too many connections to Internet Information
Services".)
>A lot of folks need to take their servers down. I suspect that the ISP's will
>be out there hot and heavy in the days to come shutting folks down.
What do the rest of us poor well-behaved @home users do in the
meantime? I'm getting tired of getting flooded by someone who was
stupid enough to not apply the right patches even though they were
warned about a thousand times over the past week to do so. Any way to
put pressure on @home to shut down the offending IPs and not allow
their modems to reconnect?
Kimberly Murphy-Smith -- kamu...@ix.netcom.com
http://members.aol.com/kimmurphy/
Kimberly's Barbie Page: http://psarchives.webjump.com/barbies/index.html
Kip Patterson
Kimberly Murphy-Smith wrote:
I haven't a clue. Surely they can and have figured out on their own what is going
on.
You could look up some of the addresses and call their op center and ask them to deal
with it. I have found them to be cooperative in the past.
Kip Patterson
ken
> What do the rest of us poor well-behaved @home users do in the
> meantime? I'm getting tired of getting flooded by someone who was
> stupid enough to not apply the right patches even though they were
> warned about a thousand times over the past week to do so. Any way to
> put pressure on @home to shut down the offending IPs and not allow
> their modems to reconnect?
If you are a mediaone customer at least, their answer seems to be
blocking *all* inbound port-80 packets, no matter how well-behaved
you've been. Can't say that I blame them (I logged 898 code-red
worm [and variants] attacks in my apache log before 2am this morning,
when the cutoff occurred), but it is kind of annoying nonetheless.
Al C
clients, but in thinking about it I would have to say it's the back
office eqpt.
Reason I think so is that I have been able to successfully obtain an
address by configuring my NT box for one of the open addresses. The next
ARP gives me data intended for that address from an outside source. In
my case, I grabbed an open IP and had a friend using telocity ping thru
to me on both my original and my new address. I was able to see both
sets of data.
What I wasn't able to test was whether or not the original user would
get his data connection back when he reconnected or whether I would
continue to get his data. (I didn't stay configured for more than five
minutes).
@Home is statically addressed here, and do not use DHCP, so this issue
is more critical for us. In those areas where DHCP is used, I would
imagine that the hosts bouncing in and out would result in an
every-changing list of infected IIS installations.
My circuit is running fine thru all this code red stuff anyhow. My
ongoing battle with disappearing TCPIP routes (fixed by clearing the ARP
cache) continues, but that's another story.
me
code red attacks?
thanks for any info
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
imperio
broadcasts come from the ubr.
Joe Funk <osrt...@sdoitjf.com> wrote in message
news:a2ub7.76284$EP6.18...@news1.rdc2.pa.home.com...