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. 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. >
Attachment:
signature.asc
Description: This is a digitally signed message part
