Ffdus: Bitte keine Portscans auf /16


#1

Ich bitte dringend darum, das lokales Netz nicht mit Pings (oder anderen Dingen, you name it) zu durchsuchen.
Allein die daraus resultierenden Arp-Requests auf ein /16 (10.155.0.0-10.155.255.254 = 64k requests) sind unschön. Und wenn dann die negative TTL abgelaufen ist und der Nächste das gleiche tut, dann geht’s wieder von vorn los.

Falls sich jemand mit den folgenden MACs angesprochen fühlen sollte,
90:b6:86:51:14:37, e0:db:10:b5:3e:44, 28:27:bf:63:f6:eb, 9f:ba:d6:83:83, 34:14:5f:2b:6b:7d
bitte per PM melden.
(Ich gehe bis zum Beweis des Gegenteils davon aus, dass es sich um “Android-Scriptkiddie-Apps” handelt, Denkbar wäre auch eine legitime Anwendung, die so Neighbor-Discovery versucht… da wäre ich für konstruktive Ratschläge dankbar.)

P.S. wer im lokalen Netz forschen möchte, ich hätte da diverse Vorschläge, was sich dort produktiv tun lässt zum Monitoring der Netzperformance und viele anderer Dinge. Das mit der Bitte um PM ist also durchaus ernst gemeint. Falls also jemand Langeweile oder schlicht Interesse an der Funktionsweise eines Layer2-Meshes verspüren sollte.


#2

Wer wirklich die Geräte im Netz finden will sollte einen Multicast-Ping verwenden:

ping6 -n2 ff02::1%interface

Gluon-Router blocken das meistens.

Wäre ein sehr grosszügiges rate-limit der ARP-Anfragen auf dem Client-Netz sinnvoll oder gegen das PPA?


#3

Da jetzt wieder mal seit Tagen einige Experten/Apps da irgendwas tun, was das Netz (Wifimesh) nachhaltig “ins Rote” treibt, läuft auf den Supernodes jetzt regelmäßig folgendes Script:

Was tut es? Es sperrt jene nodes vom DHCPv4 und von der Nutzung des Internet-Gateways aus, die binnen zufälliger 120 Sekunden mehr als 20 ARP-Requests (“who-has”) absetzen.

Falls jemand eine ernsthafte Anwendung benennen kann, die das tun muss und trotzdem Internetzugang benötigt, dann bin ich für Vorschläge offen.
(Und ja, die Nodes unseren Backbones sind davon nicht betroffen)

P.S: Im lokalen Mesh können diese Clients nach wie vor immernoch alles tun, sogar über die Supernodes hinweg.
Sie bekommen halt nur kein IPv4 mehr, weder DHCP, noch Internet-Zugang. (Falls also jemand etwas wegen PPA ansprechen wollen sollte.)


#4

Schick, solche Fälle hatten wir auch schon, waren soweit wir es festgestellt haben Rogue Android Devices.

Das Skript blockt ja dauerhaft, im Sinne von False Positives oder Rehabilitation wäre es noch wünschenswert wenn der Block nach ein einiger Zeit wieder verschwindet.


#5

naja, so dauerhaft wie derzeit Security-fixes per Kernalupdate bei Ubuntu kommen und die Hosts dann nach Reboot schreien…
Sprich: der Durchschnitt dürfte bei etwa einer Woche liegen…

Wer selbst schauen möchte, ob in der eigenen Domain “Potential” ist:

  timeout 120 tcpdump 'arp' -e -i bat0 -n -p -t 2>&1 |grep who-has |cut -d" " -f1-11|sort|uniq >$TFILE

Client-Interface “bat0” natürlich entsprechend anpassen ggf.


#6

exakt so funktioniert zumindest auf Debian 8 der Befehl nicht… ich habe ihn dann ohne das timeout benutzt und manuell wieder abgebrochen.
zudem meinst du vermutlich “sort -u” statt “sort | uniq” oder aber “sort | uniq -c | sort”
verbessern könnte man das zudem, indem man noch “grep -v EUREGATEWAY-10.x.y.z-IP” macht


#7

Die Gatewayprüfung kommt in meinem Schritt weiter unten. (Das Script geht davon aus, auf dem Gateway zu laufen und dass alle Backbone-Systeme die gleichen 2 Bytes-Prefix als MAC haben)


#9

Hinweis: auf den Knoten läuft seit der Firmware-Release vom 01.07.2017 ein Backport eines Gluon2017.1.1-PR

Das limitiert die Arp-Requests pro Knoten (nicht: pro client) auf 20/Sekunde. Wenn diese Schwelle überschritten wird, dann gibt es für mindestens eine Minute nur noch 1 ARP/s.

Und ja, diese Grenzen sind vergleichsweise generös, wenn man das Nutzungsverhalten eines normalen Nodes anschaut.
Mehr als nach dem IP-Gateway und dem DNS fragen die Clients (leider!) nicht. Gibt halt keine sinnvollen lokalen services.
Und auch die Nodes schauen nur rückwärts nach dem Mapserver, dem FW-Server und dem NTP-Dienst.