[Frage] Volkssport "Curling"?

[PeterPawn]

Wer hier nach der olympischen Sportart sucht, ist schon mal falsch und braucht gar nicht erst weiterlesen.

Ansonsten habe ich gerade - eher versehentlich - einen Download bei AVM (von "update.avm.de") mit einer alten und inzwischen ungültigen URL versucht und dabei ist mir dann ein - bisher zumindest für mich unbekanntes - Verhalten des AVM-Servers aufgefallen.

Nach einem "file not found"-Fehler (alles, was im FTP mit Error-Code 550 bestraft wird) kann ich nämlich für eine gewisse Zeit (genau habe ich das nicht ausgetestet) erst einmal keine weitere Verbindung herstellen ... der AVM-Server antwortet ganz einfach nicht mehr. Man sieht im Netzwerk-Mitschnitt halt die SYN-Pakete, auf die keinerlei Antwort erfolgt. Das sieht schon sehr nach einer "drop"-Regel aus ... zumal TCP ja selbst die SYN-Pakete mehrfach wiederholt und auf keines eine Antwort kommt (was gegen Lastprobleme spricht).

Im DNS ist unter "update.avm.de" auch nur eine einzelne IPv4-Adresse verzeichnet (die .73) - nicht wie bei den anderen Adressen, wo der Download entweder über HTTPS erfolgt (bei den Labor-Versionen) oder über "download.avm.de" geht - dahinter liegen inzwischen sechs unterschiedliche IPv4-Adressen.

Das sieht entweder nach einer heftigen Überlastung des AVM-Servers aus oder nach einer bewußt eingerichteten Sperre - denn ich habe das bisher auch nur als Problem feststellen können, wenn zuvor der Versuch stattfand, eine nicht existierende Datei zu übertragen. Beim gezielten Zugriff auf eine existierende Datei (und "nicht gesperrter" IP-Adresse) hatte ich jedenfalls bei vielen Versuchen nicht einen einzigen Fehler - für mich ein sehr deutliches Zeichen, daß hier der Versuch des Downloads einer nicht existierenden Datei "bestraft" wird.

Allerdings würde ich es auch mehr als nachvollziehbar finden, wenn AVM hier tatsächlich solchen "Hasch-Mich"-Spielen mit dem Server einen Riegel vorschiebt ... das, was als Penetration-Test ja noch angehen mag, ist als "systematisches und regelmäßiges Vorgehen" (und das möglichst noch von mehreren Leuten, denn wenn ich mir die Liste der "Erster"-Rufer hier so ansehe, ist das ja kein Einzelner) eher "unfriendly behavior" im Internet und geht - zumindest beim massiven Einsatz - ja fast in Richtung DoS-Attacken.

Nun bin ich zwar auch der Ansicht, daß jeder, der einen Service im Internet bereitstellt, auch für dessen "Härtung" verantwortlich ist und mein Mitleid mit denjenigen, die das versäumt haben oder immer noch nicht für notwendig erachten, hält sich in sehr eng umrissenen Grenzen ... aber hier könnte AVM ja tatsächlich (erfolgreich) eingeschritten sein und vielleicht hilft ja meine Beobachtung (wenn sie denn von anderen nachempfunden werden kann) auch dabei, dieses Vorgehen wieder einzudämmen.

Wenn hier jemand irgendwelche Skripte unbeaufsichtigt laufen läßt und AVM tatsächlich eine progressive Sperre von IP-Adressen eingerichtet hat, von denen solche sinnlosen Requests erfolgen, dann wird man mit solchem "Curling" nicht nur falsche Ergebnisse erhalten (wenn das eigene Skript das "timeout" nicht als solches richtig erkennt und daraus ein "file not found" macht), sondern sich auch Probleme beim späteren Download dabei gefundener Dateien einhandeln, wenn AVM einen erst einmal "auf dem Kieker" hat.

Solche Aktionen sind auf dem richtigen Server dank "iptables" und "ipset" kein Hexenwerk (und "bread & butter" für einen Netzwerk-Admin) und wohl jeder mit einem eigenen Server, hat schon mal etwas von "fail2ban" o.ä. gehört ... im Prinzip läßt sich das aber auch mit einer Exit-Routine am FTP-Server und wenigen "iptables"-Statements erreichen (notfalls kann man sogar die TCP-Pakete mit FTP-Antworten in einer "iptables"-Chain auf diesen Fehlercode "550" checken) - bei HTTP(S)-basierten Zugriffen geht das dann mit einer passend "customize"-ten Fehlerseite, die über einen Skript-Prozessor ausgeliefert wird, der den abfragenden Host in die Blacklist einträgt.

Eine länger andauernde "Sperre" von AVM für die eigene IP-Adresse, dürfte nur für diejenigen nicht relevant sein, die entweder die Adresse tatsächlich regelmäßig wechseln können (und wollen - was bei All-IP-Anschlüssen, über die parallel telefoniert wird, schon mal nicht so klug bzw. jederzeit ohne weiteres möglich ist) oder solches "Curling" tatsächlich von irgendwelchen Servern im Internet betreiben, auf denen nie ein solcher Download erfolgen soll.

Aber auch dann muß das verwendete Skript eben "smart" oder "sophisticated" genug sein, um tatsächlich zwischen den verschiedenen "Fehlerzuständen" zu unterscheiden ... ansonsten verschwendet man vollkommen unnütz Ressourcen und wird einen "Treffer" auch eher nur durch Zufall erzielen.

So ein kleines bißchen fühle ich mich auch dafür verantwortlich, daß so etwas überhaupt möglich ist - wenn man die Pfade auch noch "erraten" müßte, wäre das sicherlich noch sinnfreier und daran, daß das nun nicht so ist, hat vielleicht auch "juis_check" einen kleinen Anteil mit dem "Public"-Parameter.

Das ist auch ein Grund, warum ich eher zur Vernunft aufrufen würde (das habe ich auch bei der Beschreibung von "juis_check" schon getan) und solches "Curling" für ziemlichen Blödsinn halte ... bei mir hätte das mit so einer Sperre auch nicht so lange gebraucht (selbst wenn ich nicht weiß, seit wann das bei AVM so ist und ob meine Beobachtung überhaupt stimmt und nicht wieder ein Stromausfall in Frankfurt die Ursache ist).

 

[Wishbringer]

Nur ein kleiner weiterer Gedanke:

Normalerweise sind in Deutschland und Umgebung die ipv4-Adressen dynamisch und werden regelmäßig erneuert.
Ein IP-Bann ist daher sinnfrei.

AVM betreibt aber einen weiteren Dienst namens myfritz.
Dort existiert eine wunderbare Verknüpfung zwischen dynamischer IP und feststehendem Account inkl. Fritzbox.
Bei den Abfragen nichtexistenter Dateien ist es AVM (zumindest theoretisch) möglich, einen Abgleich zwischen temporär gebannter IP und zeitgleich existierender myfritz-Verknüpfung herzustellen.

Darüber hinaus noch, ob die abgefragte Firmware tatsächlich mit der in myfritz hinterlegten Hardware übereinstimmt.
Es könnte theoretisch sogar eine Verknüfung zur Seriennummer der Box erstellt werden oder der hinterlegten Email-Adresse.

So kann AVM also durchaus ganz genau wissen, wer die ganzen "unfriendly behavior" Abfragen laufen läßt.

BigData läßt grüßen.

 

[TSMusik]

Normalerweise sind in Deutschland und Umgebung die ipv4-Adressen dynamisch und werden regelmäßig erneuert.

Außer bei DOCSIS-Anschlüssen, wo die IP mit der MAC verknüpft ist und damit in aller Regel bleibt, und DSL-Anschlüssen ohne täglicher Zwangstrennung.

Und gerade für die DOCSIS-Boxen gibt es (bisher) öffentlich nur Release-Versionen und keine Labor/Beta. -> Volkssportpotential

Man könnte das Verhalten seitens AVM auch eindämmen, indem man die DOCSIS-Boxen weniger vernachlässigt und auch für diese offizielle Labor-Versionen anbietet. Immerhin wird die 6590 in der Produkt-Übersicht der Boxen ganz oben als Top-Modell geführt. Vom positiven Einfluss gefundener = hoffentlich behobener Fehler vor einem Release-Rollout mal ganz abgesehen.

 

[tomsoyer]

Außer bei DOCSIS-Anschlüssen, wo die IP mit der MAC verknüpft ist und damit in aller Regel bleibt, und DSL-Anschlüssen ohne täglicher Zwangstrennung.

Ich denke auch daher weigern sich die Hersteller (KDG, Unitymedia und ggf. andere) ebay-Boxen zu Konfektionieren, oder? Wäre meiner Meinung nach kein großer Aufwand, oder ?

 

[Dann halt nicht mehr]

Alternativ könnte AVM auch einfach mal den internen Server vom Updateserver trennen und dafür sorgen, dass interne Versionen nicht von außerhalb erreichbar sind.
Schöner wäre allerdings ein "Expert-Labor", wo User
1. die Infos zu neuen Boxversionen abonnieren können,
2. Downloads jeweils nur aus ihrer Box heraus anstoßen können,
3. bei jeder Installation der Hinweis kommt, dass es sich um ungetestete und
von den Providern noch nicht freigegebene Firmware handelt

Ich zweifele daran, dass die Pings und Scriptabfragen die AVM-Server auf Dauer in die Knie zwingen können. Dafür sind das hier im IPPF einfach zu wenige User.

 

[fesc]

Außer bei DOCSIS-Anschlüssen, wo die IP mit der MAC Adresse verknüpft

Das halte ich für ein Gerücht, aufgrund welcher technischen Grundlage soll denn bei DOCSIS die IP mit der MAC Adresse verknuepft sein?
Abgesehen davon dass ich es falsifizieren kann, ich jedenfalls bekomme (leider) regelmaessig eine neue adresse wenn ich reboote.

 

[TSMusik]

aufgrund welcher technischen Grundlage

Aufgrund der DOCSIS-IFS, nach der bei der IP-Provisionierung die MAC der RF-Schnittstelle als Hardware-Adresse nebst Client-Identifier beim DHCPDISCOVER und DHCPREQUEST verpflichtend zum CMTS und von dort an den DHCP-Server weitergeschickt werden muss.

Ich habe seit einem Jahr 6590 immer die gleiche öffentliche IPv4, auch nach fast 100 Reboots und teils mehrtägigen Offline-Zeiten mit Stromunterbrechung.

Auch davor, als ich noch ein Provider-Modem hatte und dahinter meinen eigenen Router, habe ich durch Ändern der WAN-MAC am Router eine neue IPv4 bekommen und durch Zurückändern selbiger wieder die alte IPv4 von davor.

-> Solange die Lease-Zeiten und die IP-Pools groß genug sind, gibt es keinen Grund, eine frische IP zuzuweisen.

 

[robert_s]

Ich habe seit einem Jahr 6590 immer die gleiche öffentliche IPv4, auch nach fast 100 Reboots und teils mehrtägigen Offline-Zeiten mit Stromunterbrechung.

Du hast nicht zufällig einen Business-Tarif mit der Option feste IP-Adresse...?

Mit einem VFKD-Privatkundentarif bekommt meine 6590 jedenfalls bei jedem Reboot eine andere IPv4-Adresse zugewiesen. Damit ist Deine Annahme, bei DOCSIS gäbe es eine inhärente feste IP-Adresse, schon mal widerlegt.

Ansonsten musst Du eben mal schreiben, bei welchem KNB mit welchem Tarif Du zu einer festen IPv4-Adresse gekommen bist.

 

[robert_s]

Das ist auch ein Grund, warum ich eher zur Vernunft aufrufen würde (das habe ich auch bei der Beschreibung von "juis_check" schon getan) und solches "Curling" für ziemlichen Blödsinn halte ...

Das kommt darauf an, was die Zielsetzung ist. Wenn jemand im Sinn gehabt hätte, damit längerfristig "versteckte" Inhouse-Firmwares zu bekommen, dann wäre es eine doch recht offensichtliche Dummheit, hier groß auszuposaunen, dass man so etwas macht. Dann muss man klugerweise schon diskret sein.

Aber vielleicht war ja auch das Ziel, AVM dazu zu bewegen, dem Spuk mit den geleakten Inhouse-Firmwares endlich mal einen Riegel vorzuschieben, indem man es ganz bewusst übertreibt. Dann hätte das "Curling" seinen Zweck schon ein wenig erfüllt.

 

[TSMusik]

Du hast nicht zufällig einen Business-Tarif mit der Option feste IP-Adresse...?

Nein, stinknormaler 0815-Consumer-Anschluss von cablesurf (2er 120/6). Die IP ist auch nicht fest, sondern pseudo-dynamisch.

Ich schreibe ja nicht, dass die IP unbedingt fest an die MAC gekoppelt ist (sie wird nur darauf basierend vergeben, solange nicht zwischenzeitlich von wem anders benötigt), sondern nur, dass sie nicht wie von Wishbringer in #2 geschrieben in Deutschland normalerweise dynamisch ist und regelmäßig erneuert wird und dass das bei DOCSIS- und DSL-Anschlüssen ohne Zwangstrennung durchaus häufiger vorkommt, dass eine IP länger einem Anschluss zugewiesen ist, ein IP-Bann seitens AVM also doch nicht ganz so sinnfrei ist.

 

[PeterPawn]

Ein IP-Bann ist daher sinnfrei.

Es kommt auch darauf an, was man unter einem "IP-Bann" versteht.

Wie ich schon schrieb, gibt es mit "ipset" sogar die Möglichkeit, Einträge mit genau spezifizierter Lebensdauer für eine IPv4-Adresse zu erzeugen ... um das Löschen eines solchen Eintrags muß man sich gar nicht mehr selbst kümmern, der verfällt automatisch.

Wenn ich von "progressivem Blocken" schrieb, dann hatte ich dabei einen Mechanismus vor Augen, der (a) eine solche Sperre mit fester Zeit einrichtet und (b) diese Zeit (bis zu einem Limit) verlängert, wenn ein gesperrter Eintrag bereits vorhanden ist.

Daß es (auch für AVM) nicht sinnvoll ist, irgendwelche Blacklists auf lange Sicht zu betreiben, versteht sich von alleine ... der Zusammenhang zum MyFRITZ!-Service ist mir hier nicht hinreichend belegt, weil auch hier der Kunde eben entscheidet, ob er diesen Service benutzt oder nicht - da ist der zusätzliche DynDNS-Service, der vermutlich mit "argo" verbunden ist, viel eher ein Kandidat für solches "Merken" (auch wenn ich das dort ebenfalls nicht vermute).

Schon die Tatsache, daß eben Anschlüsse mit dynamischer IP-Adresse bei einem Provider sich die Pools teilen, macht die Unsinnigkeit "ewiger" Sperren deutlich ... und trotzdem behindert so ein Blacklisting (ich habe bisher auch noch nichts gelesen, ob andere das ebenfalls nachvollziehen können, was ich für mich konstatiert habe) die erwähnten "Suchen" nach irgendwelchen Dateien.

Schon die Notwendigkeit, sich eine neue IPv4 zu besorgen (wenn man die Sperre nicht aussitzen will - und nochmal: Ich habe die nur für "update.avm.de" feststellen können - und das ist m.W. nur der Server mit den Labor-Versionen, wenn man bereits "eingestiegen" ist in die Labor-Reihe.), bremst solche Brute-Force-Versuche deutlich aus ... von den anderen Nachteilen am All-IP-Anschluß mal ganz zu schweigen.

So einfach, wie es früher bei den Sperren irgendwelcher Download-Services war, ist es heute lange nicht mehr ... ein Wechsel der IP-Adresse hat inzwischen eben an anderen Stellen auch wieder Nachteile. Das geht bei zeitweiliger Nichterreichbarkeit der Telefonie los (sofern der Provider keinen zweiten PVC verwendet), weil sich eben auch die SIP-Accounts erst wieder anmelden müssen und auch da dürften die Provider dann irgendwann mal stinkig werden, wenn jemand alle 2 Sekunden Nummern unter neuer IP registriert - wenn es denn überhaupt so schnell geht mit dem (automatischen) Wechsel der IP für's "Curling". Schon wenn es AVM gelingt, das Intervall zwischen zwei "Versuchen" desselben "Curlers" auf 5 Sekunden zu verlängern, limitiert das die stündlich möglichen Abfragen auf: 60 x 60 / 5 = 720 Requests - das ist praktisch "nichts" mehr, wenn sich das auf einen Wertebereich von 1500 "Build-Nummern" verteilt und dann möglichst auch noch auf mehrere Modelle.

Abgesehen davon, sind mit dem Wechsel der IP-Adresse bei einer FRITZ!Box eben auch noch jede Menge zusätzlicher Aktivitäten verbunden (z.B. DynDNS-Updates, die auch erst mit einer (einstellbaren) Verzögerung erfolgen) ... das macht - gerade bei einer FRITZ!Box - die Option des automatischen Wechsels der Adresse sehr unattraktiv - das mag für irgendwelche "Feeder" (wie z.B. FRITZ!Load) noch etwas anderes sein, aber da kennt man die URIs der Dateien auch und so ein Download braucht eine gewisse Zeit; das ist kein Vergleich mit der notwendigen "update frequency" bei solchen Suchen nach unbekannten Dateinamen.

Zur "festen" IP-Adresse ... ich suche seit Monaten verzweifelt nach einer Möglichkeit, mein IPv6-Präfix bei VF/KD mal zu wechseln. Zwar klappt es mit der Erneuerung einer IPv4-Adresse tatsächlich (allerdings auch problemlos mit der Verlängerung einer solchen Lease über sehr, sehr lange Zeiträume, was für "privacy" auch einigermaßen tödlich ist), aber für den IPv6-Präfix habe ich noch keine Möglichkeit gefunden - und die "Stilllegung" über einen längeren Zeitraum ist definitiv keine Option. Ich sehe auch nicht so richtig, was hier zu "widerlegen" wäre ... welche IP-Adresse der DHCP-Server dem startenden DOCSIS-Modem zuteilt, ist Sache des Providers und unterschiedliche Provider können das durchaus auch unterschiedlich handhaben. Ein "hier ist das anders" ist also als "Beweis" nicht wirklich tauglich, höchstens als anderslautender Erfahrungsbericht.

Aber vielleicht war ja auch das Ziel, AVM dazu zu bewegen, dem Spuk mit den geleakten Inhouse-Firmware endlich mal einen Riegel vorzuschieben, indem man es ganz bewusst übertreibt.

Das wäre dann - zumindest meines Wissens - immer noch der falsche Ansatz ... denn damit wird ja nur die systematische Suche nach unbekannten Dateinamen ausgehebelt und nicht der Download einer tatsächlich vorhandenen Version bzw. auch nicht die Abfrage des JUIS nach solchen Dateien. Wenn AVM hier wirklich würde einschreiten wollen ... die Erweiterung der Bedingungen für die "Ausgabe" einer Inhouse-Version um die Prüfung der MAC-Adresse (aka "Serial") gegen eine Liste bekannter Werte, dürfte nur eine Fingerübung sein und auch die automatische Generierung von echten Benutzernamen/Kennwörtern für den Download vom FTP-Server (mit begrenzter Life-Time) ist nur ein eher geringer Aufwand.

Daß AVM dagegen bisher nicht vorgeht (ich sehe das auch nicht als "Spuk"), ist für mich eher ein Zeichen dafür, daß man gar nicht sooo unfroh darüber ist. Was hat man denn zu verlieren als Hersteller? Nichts ... man gewinnt aber eine breitere Basis an Testern mit weiteren "Umgebungen", die man nicht mehr selbst im Labor nachstellen muß. Aus einer - wie auch immer gearteten - "Verantwortung" ist man auch weitgehend raus, denn schließlich handelt es sich gar nicht um "offiziell" verfügbare Versionen - hier kann man (im Gegensatz zu den annoncierten Labor-Versionen) sogar einräumen, daß AVM dafür keine OpenSource-Pakete zur Verfügung stellen muß (auf Anfrage), um nicht ständig gegen die Lizenzbestimmungen der GPL zu verstoßen.

Auch die deutlich geringere Frequenz an "Labor-Versionen" spricht in meinen Augen dafür ... vergleicht man das mit den letzten Erfahrungen (06.5x, 06.8x und 06.9x), hat AVM offenbar von der "continuous delivery"-Strategie wieder Abstand genommen, wo eben regelmäßig der aktuelle Stand auch als "offizielle" Labor-Version veröffentlicht wurde - selbst bei bekannten Problemen. Die paar zusätzlichen Funktionen, die in einer "Inhouse-Version" enthalten sind (vom Shell-Zugang bis zum Lua-Debugging), könnten sich die (interessierten) Kunden auch problemlos wieder selbst einbauen ... auch hier "vergibt" sich der Hersteller also nichts - zumal die Ansicht "selbst Schuld, was nimmst Du auch so eine Version" beim Auftreten von Problemen ja problemlos nachvollziehbar ist. Am Ende sind die Benutzer solcher Versionen (egal, ob sie nun an AVM berichten oder nur hier im IPPF) also eher ein Gewinn für AVM - auch wenn man das vermutlich nie zugeben würde.

Ich kann jedenfalls nicht erkennen, wo AVM hier echte Nachteile entstehen würden (aus der "Verbreitung" von Inhouse-Versionen - beim "Curling" sehe ich die eben durchaus) - abgesehen davon, hätte man das dann wohl tatsächlich bereits auf andere Weise unterbunden.

Ich zweifele daran, dass die Pings und Scriptabfragen die AVM-Server auf Dauer in die Knie zwingen können. Dafür sind das hier im IPPF einfach zu wenige User.

Ich glaube auch nicht daran, daß durch solche Abfragen tatsächlich der Betrieb des Servers gestört wird ... aber das Leben des Admins durchaus. Man stelle sich nur einmal dessen Lage vor, wenn er nach einem Problem in den Log-Dateien eines Servers suchen soll und dort laufen pro Sekunde mehrere Fehlermeldungen auf, weil mehrere Leute (und dann auch noch über gut angebundene Hosts) auf der Suche nach unbekannten Dateinamen sind. Mal ganz abgesehen davon, daß solche Fehlversuche dann entweder Log-Dateien überproportional anschwellen lassen oder - wenn deren Größe per se limitiert wird - die tatsächlich interessanten und wichtigen Einträge irgendwann verdrängen.

Ich habe auch absichtlich nur davon geschrieben, daß es fast in Richtung DoS-Attacken geht ... es ist durchaus übliche Praxis, die Anzahl der möglichen, gleichzeitigen Verbindungen für einen FTP-Server zu limitieren (das hängt u.a. auch damit zusammen, daß für passive Transfers eine zusätzliche Port-Range bereitgestellt werden muß, die dann in Firewalls (für den Server) entsprechend freizuschalten ist) und bei - mal als Hausnummer - 50 zugelassenen Clients, blockieren 5 solche "Curler" schon mal 10% der verfügbaren Verbindungen - und das ja auch nicht nur für eine kurze Zeit. Solche Skript-Dateien machen ja nur dann Sinn, wenn sie immer wieder von vorne beginnen ... der Verwender hat ja keine Ahnung, ob nicht unmittelbar nach seinem Zugriffsversuch nun doch die Datei veröffentlicht wurde, deren Nummer er gerade noch vergeblich abgefragt hat.

 

[fesc]

Aufgrund der DOCSIS-IFS, nach der bei der IP-Provisionierung die MAC der RF-Schnittstelle als Hardware-Adresse nebst Client-Identifier beim DHCPDISCOVER und DHCPREQUEST verpflichtend zum CMTS und von dort an den DHCP-Server weitergeschickt werden muss.

Aber ob und wie der DHCP server das beachtet hat nichts mehr mit DOCSIS zu tun.

 

[fesc]

Aus aktuellem Anlass: curling kann gefählich werden, zumindest wenn man in Kanada wohnt:

https://www.heise.de/newsticker/meldung/Kanadier-droht-Haft-weil-er-zaehlen-kann-4029250.html

zum heulen ...

 

[Dann halt nicht mehr]

Eine ähnlich gelagerte Aktion mit sehr vielen Repressionen hat den Hacker und Miterfinder des RSS-Standards Aaron Swartz seinerzeit viel Ärger gebracht und letztendlich in Depressionen und Tod getrieben. :-(

 

[Ohrenschmalz]

Ein traceroute sagt mir, das sich eine "sec.avm.de" um alles kümmert, was bei "update.avm.de" aufschlägt. Den kriegt man also nicht so einfach in die Knie...

 

[SnoopyDog]

Wenn hier jemand irgendwelche Skripte unbeaufsichtigt laufen läßt

Es haben hier schon Leute offen zugegeben, daß sie genau das tun (was ich reichlich dumm finde)...

 

[Dann halt nicht mehr]

Ich vermute, die "sec.avm.de" schaut nur danach, wo die Anfrage her kommt. Curle ich über meine heimische Fritz!Box, läuft alles Problemlos. Curle ich über Mobilfunk, ist nach ca. 100 Anfragen Schluss und die Anfragen werden auf eine pro 15 Sekunden beschränkt.