ARP/WHO-HAS blockieren = Gute Idee?

Deleted member 11691 · Apr 11, 2012

Hallo,

ich bekam von OVH eine Nachricht, dass unnötige ARP-Requests von meinen Server weggehen. Das Problem liegt darin, dass eine Bridge (eth0 <-> vmbr0 <-> vmbr0:0) am laufen. Soweit so gut. Ich habe mit den Technikern bei OVH auch schon ca. 8 Stunden am Telefon gesessen, jedoch ohne weiteres Ergebnis. Nun bin ich soweit gekommen, ARP-Requests komplett zu blockieren:
arptables -A INPUT -j DROP
arptables -A OUTPUT -j DROP
arptables -A FORWARD -j DROP
Soweit sogut, das Ganze funktioniert nun wie es soll. Jedoch die Frage an euch: Kann ich das so lassen oder ist das keine gute Idee?

L.G. PCFreund

Deleted member 11691 · Apr 11, 2012

Update: OK, keine gute Idee. Der Server ging offline und musste neugestartet werden. Weiß denn jemand, wie ich o.g. Problem sonst lösen kann?

cia-ug · Apr 11, 2012

Was genau ist denn der Sinn der ganzen Frage? Warum willst Du die Arp Requests unterbinden? Ich sehe keinen Sinn darin ?

Deleted member 11691 · Apr 11, 2012

Deswegen:

Code:

OVH GmbH
Dudweiler Landstraße 5
66123 Saarbrücken
Telefon: +49(0)681 906730 (Ortsnetznummer)
Fax: +49(0)681 876 1827
E-Mail: kundendienst@ovh.de


Guten Tag,

wir haben festgestellt, dass Ihr Server ks22381.kimsufi.com eine unnötig grosse 
Anzahl an Suchanfragen auf dem Netzwerk über seine Failover-IP 188.165.187.142 
durchführt. Dies liegt an einer schlechten Konfiguration der Failover-IP.

Wir haben Sie in einer vorherigen E-Mail gebeten, diese Failover-IP 
zu rekonfigurieren. Da das Problem weiterhin auftritt, erlauben wir uns, 
die Anfrage erneut zu stellen.

Sollte das Problem nicht innerhalb einer Frist von 24 Stunden behoben 
werden, dann sehen wir uns gezwungen, Ihre IP-Adresse zu blockieren.

Sobald Sie die Rekonfiguration durchgeführt haben, können Sie Ihre
Failover-IP dann über Ihren OVH Manager wieder deblockieren.

Dies ist die letzte Warnung vor der Blockierung Ihrer IP!

Bei der Rekonfiguration können Sie folgende Hilfe zu Rate ziehen:
http://hilfe.ovh.de/AdministrationIpAliasHinzufuegen/

Und wenn Sie eine Virtualisierungsdistribution mit Bridging verwenden:
http://hilfe.ovh.de/BridgeClient/

Anbei finden Sie einen Auszug der Anfragen, die von Ihrem Server
verschickt wurden:

-------  AUSZUG DER ANFRAGEN  -------

Wed Apr 11 16:52:50 2012 : arp who-has 188.165.187.140 tell 188.165.187.142
Wed Apr 11 16:52:55 2012 : arp who-has 188.165.187.139 tell 188.165.187.142
Wed Apr 11 16:53:12 2012 : arp who-has 188.165.187.141 tell 188.165.187.142
Wed Apr 11 17:01:51 2012 : arp who-has 188.165.187.141 tell 188.165.187.142
Wed Apr 11 17:09:02 2012 : arp who-has 188.165.187.139 tell 188.165.187.142
Wed Apr 11 17:15:53 2012 : arp who-has 188.165.187.140 tell 188.165.187.142
Wed Apr 11 17:15:53 2012 : arp who-has 188.165.187.141 tell 188.165.187.142
Wed Apr 11 17:19:03 2012 : arp who-has 188.165.187.141 tell 188.165.187.142
Wed Apr 11 17:25:30 2012 : arp who-has 188.165.187.139 tell 188.165.187.142
Wed Apr 11 17:25:30 2012 : arp who-has 188.165.187.140 tell 188.165.187.142


-------   ENDE DES AUSZUGS   -------


Mit freundlichen Grüßen,

Der OVH Kundendienst

Öffnungszeiten:
Mo-Fr 9:00 Uhr bis 20:00 Uhr
Sa 13:30 Uhr bis 17:30 Uhr

Sitz Saarbrücken; Amtsgericht - Registergericht - Saarbrücken, HRB 15369
Geschäftsführer: Henryk Klaba

Weitere Informationen zu OVH und unseren Produkten finden Sie auch unter:
http://forum.ovh.de
http://hilfe.ovh.de
ovh_de@ml.ovh.net (Mailingliste, zum Anmelden leere Mail an
ovh_de-subscribe@ml.ovh.net)

188.165.187.136 = Network
188.165.187.137 = KundenVM (WinXP/Win2k, die dann leider bald nicht mehr erreichbar sein wird, wenn das mit dem ARP-Requests so weitergeht)
188.165.187.138-.141 = Nichts
188.165.187.142 = vmbr0:0 auf dem Hostsystem (Dient als "Gateway", da die VM sonst kein Internet nach außen hat)
188.165.187.143 = Broadcast

Ich habe heute nochmals um 19:45 mit einem Techniker gesprochen (die sind wirklich nett, den Support kann man auch empfehlen), der sagte, er wird sich einen Server auf Proxmox 2.0 aufsetzen und mir dann die laufende und funktionierende Konfiguration des Netzwerkes weitergeben

... Mal sehen, ob er sein Versprechen hält

cia-ug · Apr 12, 2012

Ich verstehe die Aufregung nicht. Die paar Byte.... Die Requests bleiben doch in Deinem Subnetz..
Wünsche Dir viel Glück mit dem Techniker...

Deleted member 11691 · Apr 12, 2012

cia-ug said:
Die paar Byte....

Die Mail ist nur ein kleiner Ausschnitt. Dass sich OVH so weitgehend aufregt ist schon OK, da auch mehrmals am Tag in der Sekunde mehrere hunderte(!) Requests gesendet werden. Ich möchte das Problem schnellstmöglich beheben, da heute um ca. 17:25 dann die IP blockiert wird und danach wieder die IP entsperrt werden muss (das dauert dann wieder...). Wäre also für wirklich jede Hilfe dankbar

Jenstheclown · Apr 12, 2012

PCFreund said:
Soweit sogut, das Ganze funktioniert nun wie es soll. Jedoch die Frage an euch: Kann ich das so lassen oder ist das keine gute Idee?

Du sperrst etwas ohne zu wissen wofür es zuständig ist? Bitte vorher Informieren.

Whistler · Apr 12, 2012

Da offensichtlich Eile geboten ist, würde ich erstmal auf den betreffenden Systemen statische Einträge im ARP-Cache (arp -s) vornehmen.
Das ist verwaltungsmäßig nicht so toll, da man das nach jeder Änderung (und Reboot - aber das läßt sich automatisieren) neu machen muß.
Perspektivisch würde ich die Interfaces mit passenden sysctl-Einträgen zähmen - das hängt aber vom jeweiligen Setup ab.

cia-ug: Das Problem sind vermutlich nicht die paar Bytes, sondern ein niedrig eingestellter Schwellenwert in einem IDS bei OVH, der die Techniker mit Alarmmeldungen nervt.

Deleted member 11691 · Apr 12, 2012

'mal gucken ob

Code:

root@ks22381 ~ # cat /proc/sys/net/ipv4/conf/vmbr0/proxy_arp
0
root@ks22381 ~ # echo 1 > /proc/sys/net/ipv4/conf/vmbr0/proxy_arp
root@ks22381 ~ #

das was bringt

/Edit: Nein, tuts nicht

Code:

root@ks22381 ~ # tcpdump -n | grep "ARP" --line-buffered | egrep "(188.165.187.|91.121.1.147)" --line-buffered
tcpdump: WARNING: eth0: no IPv4 address assigned
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
12:15:06.201540 ARP, Request who-has 188.165.187.141 tell 188.165.187.142, length 28
12:15:06.201552 ARP, Request who-has 188.165.187.140 tell 188.165.187.142, length 28
12:15:06.201559 ARP, Request who-has 188.165.187.139 tell 188.165.187.142, length 28
12:15:06.202099 ARP, Reply 188.165.187.141 is-at 00:00:0c:07:ac:01, length 46
12:15:06.202312 ARP, Reply 188.165.187.140 is-at 00:00:0c:07:ac:01, length 46
12:15:06.202533 ARP, Reply 188.165.187.139 is-at 00:00:0c:07:ac:01, length 46
12:15:06.202604 ARP, Reply 188.165.187.141 is-at 00:00:0c:07:ac:01, length 46
12:15:06.202816 ARP, Reply 188.165.187.140 is-at 00:00:0c:07:ac:01, length 46
12:15:06.202973 ARP, Reply 188.165.187.139 is-at 00:00:0c:07:ac:01, length 46
12:15:06.985475 ARP, Request who-has 91.121.1.251 tell 91.121.1.147, length 28
12:15:24.388542 ARP, Request who-has 188.165.187.138 tell 188.165.187.142, length 28
12:15:24.389128 ARP, Reply 188.165.187.138 is-at 00:00:0c:07:ac:01, length 46
12:15:24.389274 ARP, Reply 188.165.187.138 is-at 00:00:0c:07:ac:01, length 46
12:15:29.877457 ARP, Request who-has 188.165.187.140 tell 188.165.187.142, length 28
12:15:29.878206 ARP, Reply 188.165.187.140 is-at 00:00:0c:07:ac:01, length 46
12:15:30.861604 ARP, Request who-has 188.165.187.139 tell 188.165.187.142, length 28
12:15:30.862224 ARP, Reply 188.165.187.139 is-at 00:00:0c:07:ac:01, length 46
12:15:32.781409 ARP, Request who-has 188.165.187.141 tell 188.165.187.142, length 28
12:15:32.782223 ARP, Reply 188.165.187.141 is-at 00:00:0c:07:ac:01, length 46
12:15:59.075532 ARP, Request who-has 188.165.187.140 tell 188.165.187.142, length 28
12:15:59.076011 ARP, Reply 188.165.187.140 is-at 00:00:0c:07:ac:01, length 46
12:16:06.118485 ARP, Request who-has 91.121.1.251 tell 91.121.1.147, length 28
12:16:32.408458 ARP, Request who-has 188.165.187.139 tell 188.165.187.142, length 28
12:16:32.408605 ARP, Request who-has 188.165.187.141 tell 188.165.187.142, length 28
12:16:32.409066 ARP, Reply 188.165.187.139 is-at 00:00:0c:07:ac:01, length 46
12:16:32.409307 ARP, Reply 188.165.187.141 is-at 00:00:0c:07:ac:01, length 46
12:16:58.876458 ARP, Request who-has 188.165.187.140 tell 188.165.187.142, length 28
12:16:58.877036 ARP, Reply 188.165.187.140 is-at 00:00:0c:07:ac:01, length 46
12:17:06.229624 ARP, Request who-has 91.121.1.251 tell 91.121.1.147, length 28
12:17:21.172471 ARP, Request who-has 188.165.187.139 tell 188.165.187.142, length 28
12:17:21.172483 ARP, Request who-has 188.165.187.141 tell 188.165.187.142, length 28
12:17:21.173070 ARP, Reply 188.165.187.139 is-at 00:00:0c:07:ac:01, length 46
12:17:21.173456 ARP, Reply 188.165.187.141 is-at 00:00:0c:07:ac:01, length 46

Aber warum macht der soooo viele Requests? Die sind doch total unnötig und die Lifetime für den ARP-Request-Cache hab' ich auch schon auf 5 Minuten gestellt

PapaBaer · Apr 12, 2012

Was ist denn die Ursache für die ARP-Requests? Wenn der Server einfach mal so anfängt das ganze Subnetz abzuklappern, wäre ich als Provider auch nicht begeistert. Da kommt doch eingentlich nur nen Portscanner oder sowas in Frage.

Thorsten · Apr 12, 2012

Hallo!

PapaBaer said:
Was ist denn die Ursache für die ARP-Requests?

Die virtuelle Windows XP Maschine?

mfG
Thorsten

mr_brain · Apr 12, 2012

cia-ug said:
Ich verstehe die Aufregung nicht. Die paar Byte.... Die Requests bleiben doch in Deinem Subnetz..

ARP-Requests bleiben eben nicht eigenen Netz. OSI-Layer 2 (Zwischending zwischen Layer 2 und 3). Wird nicht gerouted.

PapaBaer · Apr 12, 2012

Thorsten said:
Die virtuelle Windows XP Maschine?

Bin mit Windows nicht fit genug. Wieso ballert denn Windows XP ARP-Requests an alle einzelnen IPs eines Subnetzes?

Thorsten · Apr 12, 2012

Hallo!

Datei- und Druckerfreigabe aktiviert? Domain-Browser Dienste? Windows sucht ja gern von Haus alle (Un-)möglichen Dienste und Geräte im Netz.

mfG
Thorsten

PapaBaer · Apr 12, 2012

Thorsten said:
Windows sucht ja gern von Haus alle (Un-)möglichen Dienste und Geräte im Netz.

So weit ich das überblicke, werden dafür Broadcasts genutzt. Hier laufen aber systematisch ARP-Requests über eine IP-Range.

Deleted member 11691 · Apr 12, 2012

So, das Problem scheint nun dank dem netten OVH-Techniker (der mir kostenlos für kurze Zeit einen zweiten Server zur Verfügung gestellt hat) behoben zu sein. Folgendes wurde getan:

Code:

auto lo
iface lo inet loopback

#auto eth0
#iface eth0 inet static
#	address 91.121.1.147
#	netmask 255.255.255.0
#	network 91.121.1.0
#	broadcast 91.121.1.255
#	gateway 91.121.1.254

auto eth0
iface eth0 inet manual

auto vmbr0
iface vmbr0 inet static
	address 91.121.1.147
	netmask 255.255.255.0
	network 91.121.1.0
	broadcast 91.121.1.255
	gateway 91.121.1.254
	dns-nameservers 8.8.8.8 8.8.4.4
	dns-search dlserver.eu
	bridge_ports eth0
	bridge_stp off
	bridge_fd 0
	bridge_maxwait 0

#auto vmbr0:0
#iface vmbr0:0 inet static
#	address 188.165.187.142
#	netmask 255.255.255.248
#	network 188.165.187.136
#	broadcast 188.165.187.143

VMAC für die Win2k-Maschine erstellt UND (haben wir vergessen zu tun) dann diese VMAC in Proxmox in die Bridge bzw. den Netzwerkeinstellungen der VM eintragen

Dann haben wir auf der Win2k-Maschine eingestellt:

Adresse: <IP-Adresse der VM>
Netmask: <Netzmaske>
Gateway: <IP-Adresse der VM>

Das ganze funktioniert so wirklich sehr super und es herrschen keine Probleme mehr

ARP/WHO-HAS blockieren = Gute Idee?

Deleted member 11691

Guest

Deleted member 11691

Guest

cia-ug

Guest

Deleted member 11691

Guest

cia-ug

Guest

Deleted member 11691

Guest

Jenstheclown

Guest

Whistler

Well-Known Member

Deleted member 11691

Guest

PapaBaer

Registered User

Thorsten

SSF Facilitymanagement

mr_brain

Registered User

PapaBaer

Registered User

Thorsten

SSF Facilitymanagement

PapaBaer

Registered User

Deleted member 11691

Guest

We value your privacy