Das FRITZ!OS speichert die Eventlog-Meldungen in einer Datei /var/.ar7events.
Das ist eine doppelt verkettete Liste von Einträgen, die per se den eigentlichen "Meldungstext" gar nicht enthält. Lediglich die Nummer der entsprechenden Nachricht wird zusammen mit den variablen Teilen (wie z.B. eine konkrete IP-Adresse o.ä.) gespeichert, ebenso der Zeitpunkt des Ereignisses. Der Vorteil dieser Speicherung ist die relativ effiziente Platznutzung. Ein - in Deinem Szenario wichtiger - Nachteil ist es aber, daß das Eventlog normalerweise auf eine Größe von 40.000 Byte beschränkt wird. Da es dann als Ringpuffer benutzt wird, überschreiben also irgendwann neuere Nachrichten nach dem "Füllen" des kompletten Puffers die ältesten. Eine Vergrößerung der Datei funktioniert nicht, die Größe ist wohl irgendwo fest im Code hinterlegt und wird nicht anhand der "realen" Größe der Datei ermittelt, was man leicht selbst testen kann.
Auch der Punkt, daß man die Nachrichten dann nur mit eventsdump wieder in eine für Menschen lesbare Form bringen kann, ist sicherlich zu berücksichtigen ... wenn man mehr protokolliert als auswertet (in Textform, die Suche nach bestimmten Nachrichten anhand ihrer Nummer ist m.E. in diesem Format sogar einfacher, weil man bei der Änderung von Texten nichts anpassen muß) ist das vielleicht nicht unbedingt ein Problem. Mit etwas Geschick kann man - wenn man die Auswertung wirklich in Textform braucht - dem eventsdump der Box in einem chroot-Jail einen beliebigen Ringpuffer zur "Decodierung" unterschieben.
Je nachdem, wie lang man diese Speicherung also treiben will, hat man mehrere Möglichkeiten. Früher habe ich auch die Nachrichten regelmäßig per Web-Interface abgeholt und gespeichert, aber der Aufwand zur Ermittlung dessen, was da "neu" ist, steigt mit der Länge des Eventlogs (und der Anzahl der Boxen) für eine effektive Verarbeitung in Shell-Skripten zu schnell an.
Also bin ich dazu übergegangen, nach dem Start der Box den Ringpuffer auf den USB-Speicher unter einem Namen mit Zeitstempel zu kopieren und von /var aus mit einem Symlink dorthin zu verweisen.
Dieser Symlink stört dann auch nicht beim "ordentlichen" Herunterfahren der Box, wie es ein bind-Mount machen würde und - da die Pufferdatei nicht permanent geöffnet gehalten wird - gibt es auch beim Herunterfahren keine "dirty"-Probleme mit dem FS auf dem Stick. Im Endeffekt protokolliert man sogar mehr als mit einer periodischen Abfrage des Eventlogs (Polling), da eben bis zum dismount für den USB-Speicher weitergeschrieben werden kann.
Dann habe ich (also Schutz gegen amoklaufende Prozesse und das Überschreiben älterer Meldungen) noch ein statisch gelinktes "inotifywait" (es geht auch der inotifyd aus einer Busybox) auf "close-write"-Events für den Ringpuffer angesetzt und erzeuge immer dann eine Sicherheitskopie des aktuellen Puffers, wenn er sich dem "Überlauf" nähert (ab 0x9000 als Offset, also knapp über 90% Füllstand). Wegen der variablen Anteile haben die Einträge keine feste Länge und die "Adresse" für den nächsten Schreibvorgang steht in den ersten 4 Byte (32-Bit-uint-Offset) der Datei. Das kommt allerdings seltener vor, als man denkt ... aber ein "Vollschreiben" des Logs mit "Nutzer xyz, falsches Kennwort" zur Verdeckung eines erfolgreichen Logins wird damit eben auch verhindert.
Leider ist aber aufgrund dieser Arbeitsweise des Eventlogs für einen Angreifer auch die Manipulation des Logs durch "gezieltes Löschen" einzelner Einträge (einfach durch Änderungen der Verkettung) problemlos möglich ... das ist der Pferdefuß an dem gesamten Logging durch AVM, was einem natürlich auch im Rahmen der neuen "Sicherheitsphilosophie" nicht so deutlich gesagt wird. Ein Syslog-Aufruf über das Netzwerk zu einem gesicherten Server ist schwerer zu manipulieren für einen Angreifer und sollte zumindest als Option auch von der Firmware angeboten werden, wenn schon der "lastlog"-Mechanismus durch einfachen Restart der Box auszuhebeln ist.
Auch stört es beim Schreiben von Events die Box überhaupt nicht, wenn die Pufferdatei nicht existiert, dann wird eben eine leere angelegt. Wenn ein Angreifer also auch mit dem eher auffälligen Löschen des gesamten Eventlogs leben kann, reicht es vollkommen aus, die Pufferdatei einfach nur zu löschen.
EDIT: Wenn das jemand nachbauen will und den Patch für das statisch gelinkte inotifywait für den aktuellen Freetz-Trunk haben möchte, hänge ich den gerne noch hier ran.
EDIT2: Von anderer Seite kam die Frage, ob man bei einer 7490 die Dateien nicht auch im NAND-Flash unter /var/media/ftp/logs o.ä. speichern könnte. Das geht natürlich auch ... nur sind sie da eben bei einem Formatieren des yaffs (was bei der Systeminitialisierung automatisch geschieht, wenn der erste Mount-Versuch für das FS fehlschlägt) beim geringsten Fehler auch verschwunden, das würde ich also nur in Ausnahmefällen für sinnvoll halten und eher als "temporären" Speicher ansehen, der ein häufiges Backup an einer anderen Stelle erfordert.
