Vreemde ARP-requests

[odysseus]

Ik merkte dat de snelheid van mijn internetverbinding niet zo best was en dus maar even ingelogd op de router. netstat -antp gaf een lijst van processen genaamd 'updatens' (komt van duuc). Deze heb ik allemaal gekild, maar het hielp niet. Vervolgens eens tcpdump -i eth1 gedraaid (die -i omdat je anders een recursive loop krijgt omdat hij de output over telnet verstuurt, weer opvangt, weer verstuurt, etc) en daar zat wat vreemde output tussen:

code:

21:53:33.991146 B arp who-has qn-212-58-172-173.quicknet.nl tell qn-212-58-172-1.quicknet.nl
21:53:33.999571 > qn-212-58-172-147.quicknet.nl.1063 > ns3.net.quicknet.nl.domain: 8392+ PTR? 173.172.58.212.in-addr.arpa. (45)
21:53:34.313599 B arp who-has qn-213-73-178-187.quicknet.nl tell qn-213-73-178-1.quicknet.nl
21:53:34.315294 B arp who-has qn-213-73-178-147.quicknet.nl tell qn-213-73-178-1.quicknet.nl
21:53:34.315570 B arp who-has qn-212-58-173-72.quicknet.nl tell qn-212-58-173-1.quicknet.nl
21:53:34.315840 B arp who-has qn-213-73-189-248.quicknet.nl tell qn-213-73-189-1.quicknet.nl
21:53:34.658429 B arp who-has qn-213-73-215-95.quicknet.nl tell qn-213-73-214-1.quicknet.nl
21:53:34.786135 B arp who-has 217.63.254.210 tell 217.63.254.1
21:53:34.786425 B arp who-has 213.125.255.17 tell 213.125.255.1
21:53:34.787291 B arp who-has 213.125.255.4 tell 213.125.255.1
21:53:34.787782 B arp who-has 217.63.254.203 tell 217.63.254.1
21:53:34.788051 B arp who-has 213.124.159.20 tell 213.124.159.1
21:53:34.788322 B arp who-has 213.124.159.21 tell 213.124.159.1
21:53:34.788717 B arp who-has 213.124.159.19 tell 213.124.159.1
21:53:34.789683 B arp who-has 217.63.254.114 tell 217.63.254.1
21:53:34.789949 B arp who-has 213.125.255.26 tell 213.125.255.1
21:53:34.790219 B arp who-has 213.124.159.2 tell 213.124.159.1
21:53:34.791347 B arp who-has 217.63.254.102 tell 217.63.254.1
21:53:34.791998 B arp who-has 213.125.255.16 tell 213.125.255.1
21:53:34.792685 B arp who-has 217.63.254.227 tell 217.63.254.1
21:53:34.792968 B arp who-has 217.63.254.225 tell 217.63.254.1
21:53:34.793494 B arp who-has 217.63.254.224 tell 217.63.254.1
21:53:34.793899 B arp who-has 217.63.254.222 tell 217.63.254.1
21:53:34.794165 B arp who-has 217.63.254.221 tell 217.63.254.1
21:53:34.794436 B arp who-has 217.63.254.209 tell 217.63.254.1
21:53:34.794708 B arp who-has 217.63.254.208 tell 217.63.254.1
21:53:34.794977 B arp who-has 217.63.254.206 tell 217.63.254.1
21:53:34.795249 B arp who-has 217.63.254.182 tell 217.63.254.1
21:53:34.795520 B arp who-has 217.63.254.178 tell 217.63.254.1
21:53:34.795791 B arp who-has 217.63.254.173 tell 217.63.254.1
21:53:34.796061 B arp who-has 217.63.254.166 tell 217.63.254.1

Dat blijft zo almaar doorgaan...ik heb geen idee welke hosts dat opvragen maar zie datzelfde verkeer niet over mijn interne netwerk gaan (tcpdump op mijn eigen pc laat niets vreemds zien), dus het zit ergens van buiten. Ik heb zelf geen ervaring met ARP, ik zie ze alleen normaal in kleine hoeveelheden langskomen op het interne netwerk. Nu is het echter massaal en ze komen allemaal van buiten...
Bij mijn weten krijg je dit soort requests alleen voor NAT/Masquereading, die zie ik ook voor het eigen netwerk wel eens langskomen. De forward-policy staat op DENY en er zijn alleen rules voor de interne clients (192.168.0.0/24), dus daar ligt het ook niet aan lijkt me.

Iemand een idee of dit normaal is en indien niet wat ik ertegen kan doen?

* odysseus opent bijna nooit topics...moet nu toch een keer

[deadinspace]

Op vrijdag 26 oktober 2001 22:03 schreef odysseus het volgende:

code:

21:53:34.786135 B arp who-has 217.63.254.210 tell 217.63.254.1

code:

marcelm@something marcelm$ host 217.63.254.1
217.63.254.1 does not exist, try again

Bij mijn weten krijg je dit soort requests alleen voor NAT/Masquereading, die zie ik ook voor het eigen netwerk wel eens langskomen.

ARP is het protocol voor vertaling van IP-adressen naar MAC-adressen (en rARP is voor het tegenovergestelde). Het is vooral belangrijk voor routers en switches (die moeten weten welk IP-adres waarheen moet), en wat ARP-gebrabbel komt afaik op elk netwerk wel voor.

Iemand een idee of dit normaal is en indien niet wat ik ertegen kan doen?

Nee, het is niet normaal dat iemand zoveel arp-requests tegen je gateway maakt, maar het is waarschijnlijk een kwestie van pure brakkigheid of verkeerde configuratie, of een DoS (Windows kon niet goed tegen bepaalde ARP-requests iirc... dan kostte elke ARP-request een paar seconden ofzo, waardoor je een winbak helemaal stil kon krijgen) misschien.
Ik zou zeggen: houdt het een beetje in de gaten (om hoeveel k/s gaat het eigenlijk?), en probeer er eens iets aan te doen als het blijft...
Het IP dat de requests maakt (althans, tell <IP> betekent normaal gesproken dat <IP> de request heeft gemaakt en dat die dus ook het antwoord wil hebben) bestaat alvast niet (toch DoS?), dus daarmee naar je provider stappen heeft wrs niet heel veel nut...

* odysseus opent bijna nooit topics...moet nu toch een keer

achut

[jeroen|IA]

Die arp requests op zich zijn niet zo bijzonder, wat wel opvallend is is dat het er zoveel zijn. Ik heb in het verleden ook vrij regelmatig last gehad van ineens supertraag wordende netwerkverbindingen met chello, en als ik dan ging tcpdumpen kreeg ik dezelfde output als jij hierboven liet zien. Wat dan opvalt is dat de gateway gewoon arp requests voor een heel subnet gaat doen, vaak meerdere keren achter elkaar. Ik vermoed dus dat het te maken heeft met eoa vies tooltje waarmee je de arp tabel van een router overhoop kunt schoppen.

[odysseus]

Ok, ben nu al iets verder. Die requests zijn in ieder geval niet tijdelijk geweest: ik zag vanmorgen (toen die router niet eens aanstond) al een berg verkeer aankomen, de lampjes van het kabelmodem knipperden aan een stuk door terwijl ze normaal misschien om de seconde eens knipperen als de router uitstaat. Na het booten eerst mijn arp-tabel eens bekeken:

code:

[root@hub mail]# arp
Address          HWtype  HWaddress       Flags Mask     Iface
guus              ether   00:00:E8:D8:39:A5   C            eth0
qn-212-58-172-1.quickne ether   00:E0:52:B5:4C:00   C              eth1
midas            ether   00:20:AF:AB:9E:14   C             eth0
odysseus            ether   00:20:18:80:B0:95   C              eth0
You have new mail in /var/spool/mail/root
[root@hub mail]#

Een kleine vergelijking met het LDP-document op http://www.linuxdoc.org/LDP/nag2/x-087-2-iface.verify.arp.html laat zien dat zij alleen de lokale interfaces in de lijst hebben staan en dat ik dus nog een extra entry heb die op mijn eth1 zit, waar ook alle requests vandaan komen. Het zou natuurlijk ook kunnen dat de tabel van die webpagina gedraaid is op een pc zonder directe internetverbinding, dus dit zou best normaal kunnen zijn (kan helaas niet vergelijken met andere hosts).
Vervolgens heb ik ook nog even het programma arpwatch gestart. Er komen nu onophoudelijk requests binnen die het programma beschrijft als 'new station', wat volgens de manpage betekent dat het station nog niet eerder gezien is (duh... ). Aangezien het nogal random IP's zijn (wel allemaal beginnend met 213 of 217) en de requests vragen naar eveneens random IP's die wel steeds op hetzelfde subnet liggen als het IP van de vrager ga ik er maar vanuit dat het een soort DoS is. Weinig tegen te doen op dit moment denk ik, maar ik zou toch in ieder geval willen proberen om de replies uit te schakelen...dat vreet alleen maar bandbreedte en data. Is arp een apart protocol wat je kunt blocken met ipchains? Dus met iets als 'ipchains -A input -i eth0 -p arp -j DROP' of zo? Waarschijnlijk zullen de requests dan nog wel doorgaan (deden ze immers ook toen de router uitstond), maar niet geschoten is altijd mis en het scheelt in ieder geval weer de load en traffic van een reply...

* odysseus is not amused

[deadinspace]

Op Saturday 27 October 2001 13:35 schreef odysseus het volgende:

code:

[root@hub mail]# arp
Address          HWtype  HWaddress       Flags Mask     Iface
guus              ether   00:00:E8:D8:39:A5   C            eth0
qn-212-58-172-1.quickne ether   00:E0:52:B5:4C:00   C              eth1
midas            ether   00:20:AF:AB:9E:14   C             eth0
odysseus            ether   00:20:18:80:B0:95   C              eth0
You have new mail in /var/spool/mail/root
[root@hub mail]#

Een kleine vergelijking met het LDP-document op http://www.linuxdoc.org/LDP/nag2/x-087-2-iface.verify.arp.html laat zien dat zij alleen de lokale interfaces in de lijst hebben staan en dat ik dus nog een extra entry heb die op mijn eth1 zit, waar ook alle requests vandaan komen. Het zou natuurlijk ook kunnen dat de tabel van die webpagina gedraaid is op een pc zonder directe internetverbinding, dus dit zou best normaal kunnen zijn (kan helaas niet vergelijken met andere hosts).

Dat er 1 eth1 in je arp-tabel staat is heel normaal; Alle compus op hetzelfde fysieke netwerk (en subnet dus) die met jouw computer gepraat hebben, staan in je arp-tabel. Zo weet je kernel meteen naar welk ethernet-adres een packet moet als het IP in de arp-tabel staat.
Die entry in je arp-tabel is je eerste router van je provider dan. Zie ook mijn arp-tabel:

code:

root@anything marcelm# arp
Address          HWtype  HWaddress       Flags Mask     Iface
nothing.nowhere    ether   00:D0:59:01:F0:85   C               eth0
something.nowhere    ether   00:01:02:9F:CC:7A   C             eth0
d100193.upc-d.chello.nl ether   00:00:77:92:76:68   C              eth1
root@anything marcelm#

Aangezien het nogal random IP's zijn (wel allemaal beginnend met 213 of 217) en de requests vragen naar eveneens random IP's die wel steeds op hetzelfde subnet liggen als het IP van de vrager ga ik er maar vanuit dat het een soort DoS is. Weinig tegen te doen op dit moment denk ik...

Lijkt idd nogal op een DoS jah... misschien toch maar eens bij provider aankloppen?

Is arp een apart protocol wat je kunt blocken met ipchains? Dus met iets als 'ipchains -A input -i eth0 -p arp -j DROP' of zo?

Ik gok van wel, maar ik ben geen ipchains-held.

De load van een reply zal overigens wel meevallen... ff een waarde opzoeken in een kernelstruct. De traffic is veel erger, omdat je upload waarschijnlijk veel lager is dan je download.

[jeroen|IA]

Je zou arp moeten kunnen uitzetten voor het interface dat aan je provider hangt volgens mij. De enige entry die ooit in je tabel komt te staan is zoals gezegd de router van je provider, dus die zou je ook als static entry in de lijst kunnen laten zetten bij booten. Onder linux kun je vervolgens met ifconfig arp uitzetten voor dat interface (logisch of fysiek, dat maakt niet uit), en daarmee zou jouw onvrijwillige bijdrage aan de DoS in ieder geval afgelopen moeten zijn. Of je onder Windows ook arp uit kunt zetten weet ik niet.

Hmm kleine toevoeging: volgens mij kan het toch niet, omdat de uitwisseling van mac adressen natuurlijk twee kanten op werkt. De router moet natuurlijk ook jouw mac adres kunnen opvragen...

[odysseus]

Ben nog weer wat verder...heb gister even op IRC rondgevraagd (bij gebrek aan GoT ) en het lijkt erop dat het vrij normaal verkeer moet zijn. ARP is een broadcast-protocol, dus als een host wil weten welk MAC-adres een andere host heeft dan stuurt hij zo'n request. Als een van de hosts die de request opvangt het weet, dan stuurt hij de gevraagde waarde terug naar de host die achter 'tell' genoemd wordt. Dat maakt het wel leuk: aan de ene kant is dit verkeer dus niet erg (ik zal er nooit op antwoorden, want hoe zou mijn router moeten weten wat het MAC-adres van een niet-bestaande host is?), aan de andere kant ga je je toch afvragen waarom zoveel mensen (of een iemand, die zijn ip-adres spooft) vragen naar niet-bestaande hosts...
Overigens gaan de requests (of ze nu normaal zijn of niet) nog steeds door. Ik zag net een speciale:

14:43:41.655002 B arp who-has 213.125.255.26 tell 213.125.255.1

Deze vraagt dus om een heel subnet of zo...lijkt me onlogisch: als ARP bedoeld is om het fysieke adres van een host te weten te komen dan zou dit een lijst moeten teruggeven of zo...en dan is het returnadres ook nog eens een compleet net (weer x.x.255.x). Welke host krijgt dan antwoord? Vreemd gedoe allemaal...
Overigens was het volgens die mensen op IRC (in #linux op Undernet, vrij deskundig kanaal) dus vrij normaal verkeer, terwijl ik me afvraag waarom er in hemelsnaam zoveel verkeer van niet-bestaande hosts langskomen en niet een enkele voor een host die ik wel gewoon kan pingen...

* odysseus bedankt in ieder geval iedereen voor zijn input tot nog toe om dit raadsel (voor mij althans ) op te lossen...

[picobyte]

Zouden het misschien ezels of morpheusers zijn
Die pollen ook diverse hosts om te zien of ze alweer online zijn

[The Third Man]

Het kunnen toch best de mensen van je eigen ISP zijn? Ik denk dat ze alleen maar logs aan het maken zijn met welke MAC's welke IP-adressen gebruikt worden; ze sturen een broadcast rond en arpen vervolgens iedereen die op de broadcast geantwoord heeft.

Wat mij namelijk opvalt is dat steeds het requesting IP-address eindigt met .1. Dat wil dus haast wel zeggen dat dat de router van de ISP is (de eigenaar van het subnet) die steeds het eerste adres van elk subnet heeft (of eigenlijk hoort te hebben). In het geval van een DoS zou het requesting IP-adres steeds wel iets anders zijn of in ieder geval eindigend op een ander nummer.

[Egbert]

Op Sunday 28 October 2001 13:51 schreef odysseus het volgende:
[...]
Deze vraagt dus om een heel subnet of zo...lijkt me onlogisch: als ARP bedoeld is om het fysieke adres van een host te weten te komen dan zou dit een lijst moeten teruggeven of zo...en dan is het returnadres ook nog eens een compleet net (weer x.x.255.x). Welke host krijgt dan antwoord? Vreemd gedoe allemaal...
[...]

Dat daar 255 staat wil niet zeggen dat het een heel subnet is hoor.
Ook is xxx.xxx.xxx.1 niet per s een router. Ik kan me goed voorstellen dat er gewoon een of andere portscanner actief is?
Zo'n ding loopt een hele series ip-adressen langs, en moet dus voor elk adres een arp-request doen. Als ie in hetzelfde subnet zit zullen die arp-request als afzender het ip van de portscanner hebben, anders het ip van de router. (die jist de niet bestaande ip-adressen gaat opvragen via arp, omdat ie de wel bestaande adressen allang gecached heeft)

[The Third Man]

Nee, een .1 adres hoeft ook geen router te zijn, maar het lijkt me wel logisch, omdtat het andere adres ook eindigt op 1.

Maar een ARP kan toch niet worden doorgesluisd door een router? Op die manier zou het hele internet wel plat liggen van arp-requestjes die van Costa Rica tot Japan reizen. Het zou mij logischer lijken als een arp alleen in hetzelfde subnet als de requester is uit te voeren.

Het lijkt mij ook een portscan simpelweg voor de provider om logs bij te kunnen houden.

[Egbert]

Op Sunday 28 October 2001 19:06 schreef Mnemonic het volgende:
[...]

Maar een ARP kan toch niet worden doorgesluisd door een router? Op die manier zou het hele internet wel plat liggen van arp-requestjes die van Costa Rica tot Japan reizen. Het zou mij logischer lijken als een arp alleen in hetzelfde subnet als de requester is uit te voeren.

[...]

Ze worden ook niet doorgesluisd. Alleen bij het eindpunt van een route worden arp-requests uitgevoerd voor het ip dat benaderd wordt:

portscanner scant ip-range X door er ping-packets heen te sturen.
IP-range X komt niet overeen met het subnet waarin de portscanner zit, dus moeten de ping-packets naar de router.
Portscanner doet een (1) arp request om achter mac-adres van de router te komen.
Alle ping-pakketjes worden naar router gestuurd.
Router kijkt waar ze heen moeten, komt er achter dat hij ook al niet die IP-range X direct kan bereiken en stuurt het door naar volgende router..
(paar routers verder...)
Router komet er achter dat ie ook in het subnet zit van IP-range X. Nu kan die router elk ping-packet naar de uiteindelijk host sturen. Daarvoor heeft die router wel de mac-adressen van die hosts nodig. Alle bestaande hosts/ip-adressen heeft ie toevallig al gecached, dus daarvoor hoeft ie geen arp-requests meer te doen. Voor de overige ip-adressen/hosts doet ie dat wel.
En _die_ arp requests ziet <topicstarter> dus. Afkomstig van de router, vragend naar mac-adressen van niet bestaande/gebruikte ips in het subnet.