ARP question

Rick Sewill rsewill at cableone.net
Thu Jun 21 15:21:07 UTC 2007


On Thu, 2007-06-21 at 08:50 -0500, Rick Sewill wrote:
> On Thu, 2007-06-21 at 11:33 +0200, Manuel Arostegui Ramirez wrote:
> > On Thursday 21 June 2007 11:17:26 Rick Sewill wrote:
> > > On Thu, 2007-06-21 at 08:15 +0200, Manuel Arostegui Ramirez wrote:
> > > > El Jueves, 21 de Junio de 2007 03:34, Rick Sewill escribió:
> > > > > I suspect these ARP requests are caused by botnets, on the Internet,
> > > > > scanning IP address ranges for PCs to compromise.  There is a steady
> > > > > bombardment of Microsoft Messenger Service, NetrSendMessage requests to
> > > > > UDP port 1026, coming to my IP address.  Lucky for me, Fedora discards
> > > > > the message and no response is generated.  The botnets do not give up.
> > > >
> > > > Maybe I'm not understanding what you mean there but....how can botnets
> > > > make ARP questions through the internet?
> > > > As far as I know ARP requests are only made in LANs and it's impossible
> > > > for its to pass a router and reach the Internet.
> > >
> > > You are correct.  ARP requests are used on a broadcast interface to
> > > discover the association between an IP address and a MAC address.  ARP
> > > requests are not passed on by a router.  Let me explain.
> > >
> > > First, I wish to tell what I am currently seeing on my internet
> > > connection.  Next, I will guess, why I am seeing what I see.
> > >
> > > It is 3:10 a.m., my time.  One would expect my connection to the cable
> > > company to be relatively quiet.  I just ran wireshark for 41 seconds.
> > > I got 1871 ARP requests, 1870 were from the Cable company, and one was
> > > from a device with a Motorola (OID) MAC address.
> > >
> > > I also got 31 regular IP packets, of which 5 were TCP and 26 were UDP.
> > > Of the UDP packets.
> > >
> > > I originated one TCP packet.  The other 4 came to me.
> > >
> > > Sixteen of the UDP packets were unicast to me, to my port 6881, which is
> > > weird.  UDP port 6881 is a bittorrent port.  I admit to seeding Fedora
> > > 7, but that was a few days ago.  Iptables, by default, discards all
> > > packets I receive on port 6881, unless I explicitly open ports.
> > >
> > > The other ten UDP packets were DHCP offers, and DHCP acks, directed to
> > > the 255.255.255.255 broadcast address.
> > >
> > > The sender of all the DHCP packets, and the 1870 ARP requests, that I
> > > saw, had the same ethernet MAC source address.
> > >
> > > I did not see any NetrSendMessage during that 41 second interval.  The
> > > NetrSendMessage messages are UDP packets destined to port 1026.  I had
> > > seen the NetrSendMessage yesterday afternoon.  I never have a Windows
> > > machine connected to that interface so there is no reason a packet
> > > specific to a Microsoft protocol should come to that interface.
> > >
> > > I am guessing botnets are sending these IP packets, on UDP port 6881,
> > > and UDP port 1026, to every IP address in a range of IP addresses.
> > >
> > > In the case of the cable companies, I believe they treat the cable like
> > > it is a broadcast interface.  I believe they ARP for that IP address to
> > > get the MAC address for that machine.  I get these ARP requests because
> > > they are broadcast to me and to everyone with whom I share the cable.
> > >
> > > I actually don't see the logic to cable companies doing this.
> > >
> > > Cable companies should know the MAC address associated with my IP
> > > address.  Either the cable company assigned my IP address, in the case
> > > of a dynamic IP address, or the cable company statically configured my
> > > IP address, in the case of certain business accounts.  I pay a flat rate
> > > which means the cable company does not need to know if my machine is on
> > > or off as far as billing is concerned.  I am allowed a finite number of
> > > IP addresses, three, so the cable company has to know the number of
> > > devices connected to my cable modem.
> > >
> > > The telephone companies should do a better job.  I do not believe the
> > > telephone companies treat their wire as a broadcast interface.  I have
> > > not had the opportunity to hook a network sniffer up to a telephone
> > > company wire to see what they do.
> > >
> > > If the cable company is spewing forth all that traffic, without any
> > > prompting from botnets, and without any prompting from me, one might
> > > think the cable company software were in need of repair.
> > >
> > 
> > Nice explanation, now it's much more clear :-)
> > I forgot you were using a Cable connection, therefore all of the above is 
> > reasonable, since they treat all their users as a part of a huge LAN.
> > I agree with you that that's not the best way to magane all their clients, 
> > specially if we think about security...
> > It's the same in Spain, I was using a Cable connection (I will not give names) 
> > very common here and it was such a laugh if we talk about security...
> > It was almost just a big LAN, no more...sad but true, though...
> > 
> > On the other hand...can you complain about that to your Cable ISP?
> > 
> 
> <personal off-topic ranting>
> I fear complaints, to cable companies, would fall upon deaf ears.  
> When I visited a friend, in Vermont, his cable ISP did the same thing.
> 
> The cable company might listen if there were reasonable competition.  
> In theory, the telephone companies should provide that competition.
> I fear reality is different.  To add insult to the matter, they oppose
> municipal WIFI, complaining it is unfair competition.
> 
> I hear about the much higher bandwidth, at a cheaper price, in other
> countries, and become jealous.  I hear about the Internet2 performance
> and become envious.  I begin to question, if competition, will solve
> this problem.
> 
> I wonder how cable companies can speak of capping service when, much of
> the time, 98% of the bandwidth is attributable to their overhead.

In my personal, ranting, I find I left an incorrect impression.  

It is true, 98% of the bandwidth was attributable to their overhead.
This does not mean my cable line is being used at 98% capacity.

The actual bandwidth is between 20 and 60 kilobits per second as
measured by iptraf, between me and the cable head-end.  In my case,
given I am paying for a 3 megabit downstream connection, irregardless of
what I actually get, that would translate to 1% to 2% of my downstream
connection.  The cable company would amortize that overhead over all the
customers served by that "lan" segment.

Doing a tcpdump over a 40 second period, and running the captured output
through the following commands,
grep "who-has" tcpdump.log > tcpd1.log
cut -d " " --complement -f 1 tcpd1.log > tcpd2.log
sort tcpd2.log > tcpd3.log
cat tcpd3.log | wc
showed 826 arp packets, this morning, while
cat tcpd3.log | uniq | wc showed 417 unique packets.
cat tcpd3.log | uniq -c | less
showed one IP address was sought 46 times, one IP address sought 28
times.  Most IP addresses were sought once or twice.  No other IP
address was sought more than nine times.
The actual numbers were as follows:
 cat tcpd3.log | uniq -c | cut -b 1-8 | sort | uniq -c
    271       1 
     70       2 
      1      28 
     27       3 
     18       4 
      1      46 
      9       5 
      8       6 
      5       7 
      3       8 
      4       9 

I would have expected a more uniform distribution where every IP address
was sought once or twice, over the forty second period.

I suspect the router, at their end, has too small of an ARP table, but
this is only speculation.

I understand, from the cable companies point of view, why the bandwidth
I cause, would have much greater overhead for them, than the overhead
they are generating on that cable "lan" segment.  

My bandwidth causes them to route traffic through their network, usually
to the back-bone.  Their ARP requests are limited to that cable "lan"
segment leaving most of their network undisturbed.

Forgive my rant.  Time for me to shut up.  Time to let this thread die.

> 
> I wonder how many CPU cycles are lost, discarding ARP requests, when a
> computer is connected directly to the cable modem.  This suggests having
> a firewall/NAT box between your computer and the cable modem serves a
> secondary purpose, of shielding your computer from this overhead.
> 
> It would be sad if the industry solution had the ethernet NIC card
> manufacturers building chips that examined, and discarded, unwanted ARP
> requests.
> 
> The chip would need the logic to recognize the ARP request.  The host
> driver would need to provide the chip with the MAC address/IP address
> associations that should not be discarded, but should be passed to the
> host.
> 
> I wonder if the idea of making the ethernet NIC chip discard unwanted
> ARP requests is patentable.  It should not be patentable.  Given the
> problem, this workaround is an obvious, hopefully temporary, solution.
> 
> </personal off-topic ranting>
> 
> My ethernet NIC card, for the interface to the cable modem, is a D-Link
> DFE-538TX+.  It uses the via-rhine.c driver.  Looking at the suggested
> driver from D-Link, for Linux, and looking at any D-Link documentation,
> I am permitted to download, for the chip, does not suggest I can program
> the chip to discard unwanted ARP requests.  
> 
> I did a quick search of the via-rhine.c driver, and did not find the
> strings, "arp", or "resolution", and I would have expected one or both
> of these strings in a comment should the via-rhine.c driver have any
> support for programming the chip with the needed information, for
> discarding unwanted ARP requests.
> 
> I think further discussion of cable Internet behavior belongs in a
> different forum unless we discuss ways to make Linux/Fedora perform
> better, and faster, in the face of this behavior.
> 
> It would be interesting to instrument the path and see how much overhead
> actually exists, for a Fedora box, connected directly to a cable modem.
> The overhead should not be that much, per packet, but over time, would
> add up to a reasonable amount of CPU cycles.
> 
> > Cheers
> > -- 
> > Manuel Arostegui Ramirez.
> > 
> > Electronic Mail is not secure, may not be read every day, and should not
> > be used for urgent or sensitive issues.
> > 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20070621/db2fc193/attachment-0001.sig>


More information about the fedora-list mailing list