Log4Net: Log-Dateien gegen Manipulation schützen

Wer kennt es nicht? Die Software läuft auf einmal nicht mehr und man sucht sich nen Wolf. Es wurde nichts geändert, aber es läuft einfach nicht mehr. "Die Software hat bugs!", "Das Programm ist abgekackt!",..... Nach Ewigkeiten kommt dann heraus, dass "die Putzfrau" an Parametern oder der Hardware manipuliert hat 😉
Um diesen Diskussionen aus dem Weg zu gehen, wird die Konfigarationsdatei signiert und kann deswegen nicht mehr so einfach über einen Editor verändert werden. Jede Parameter-Änderung und jedes kritische Hardware-Event wird gelogt.
Um die Sache rund zu machen, wünsche ich mir noch eine Signierung der Logeinträge, damit "böse" Einträge nicht einfach verschwinden können.

Ich bin bestimmt nicht der erste mit solcher Paranoia, konnte aber bisher keine passende Lösung finden.
😁

einfach verschlüsseln, wenn nicht mit dem Editor gelesen werden muss.

Ich als Putzfrau würde ja das Logfile löschen, wenn ich schon was "versaue".

schnelleHelga

Es muss weiterhin lesbar sein.
Es ist nicht immer die Putzfrau, manchmal gehen auch so mal "ein paar Bytes verloren". 😁
Ich hab keine Lust auf Diskussionen und Schuldzuweisungen. Wenn "Bytes verloren gehen", dann gibs nen Alarm und es wird die Hardware (oder der Bediener) ausgetauscht 8)

Genauso machen wie bei der Konfiguration?

Es gibt Appender die die Logdaten zu einer anderen Kiste verschicken. Vllt ist es ja was für dich.

Es gibt Appender die die Logdaten zu einer anderen Kiste verschicken. Vllt ist es ja was für dich.

Ich habe beim Anwender meistens keine andere Kiste und das Programm darf nicht nach Hause telefonieren

Genauso machen wie bei der Konfiguration?

Damit merke ich, dass die Datei angefasst wurde, aber nicht wo.
Ich könnte mir das Format so vorstellen:
<Datum> <Logging-Nachricht> <Prüfsumme aus: Datum&Nachricht&Prüfsumme der letzten Zeile>
Damit kann man auch genau sehen, welche Einträge fehlen 😁

Sobald Du auf der lokalen Kisten loggen musst hast Du eigentlich keine zuverlässige Möglichkeit Dich bzw. Deine Software davor zu schützen.
Auch die Prüfsumme bringt Dir ja effektiv recht wenig. Du weisst dann auch nur, dass etwas fehlt aber nicht was.

eventuell hilft ja ein zweites Logfile mit Schlüssel und eingeschränkten Schreibrechten? WER was gemacht hat bekommst du so aber auch nicht mit.

Je nach Anwendung kann man sich auch eine Architektur überlegen, bei der schon im Kern ein Protokoll verankert ist, z.B. Event Sourcing. Damit kannst du dann natürlich keine Hardware Fehler sichern, aber kritische Geschäftsoperationen sind immer nachvollziehbar.

Für normale Logs fände ich das aber ein bisschen übertrieben, aber das ist ja auch deine Entscheidung 😉

Es ist nicht immer die Putzfrau, manchmal gehen auch so mal "ein paar Bytes verloren". großes Grinsen

Eigentlich ist da die Frage, wo da "ein paar Bytes" verloren gehen.
Wenn du nicht sagen kannst, dass die Log-Daten zuverlässig vom Programm in die Datei eingefügt werden, kannst du es insgesamt vergessen.
-> Wer sagt dir denn, ob es "die Putzfrau" war oder einfach ein Schreibfehler gewesen ist.

Falls aber sicher ist, dass die einmal erfassten Daten in der Datei landen, kannst du schon eine gewisse Sicherheit einbauen:

1. Die Log-Datei wird auf jeden Fall alle x Sekunden mit einem Eintrag befüllt -> falls etwas fehlt, weißt du auch genau wo.
2. Checksumme für jeden Eintrag -> du weißt, ob manipuliert wurde oder nicht.
3. Eine clevere Prüfsumme über die Datei, aus der man zurückrechnen kann, ob manipuliert wurde und wo.

Was halt noch ne Möglichkeit wäre, ist den Log doppelt anzulegen: Unverschlüsselt und in einem anderen Ornder nochmal verschlüsselt für dich zur Sicherheit.
Aber da liegen die Nachteile ja offensichtlich auf der Hand ... . 😁

Ich würde Dir einen ganz anderen Tip geben.
Beschäftige Dich mit Event Tracing für Windows / Semantic Logging.
Da kann keiner so einfach die Logs lesen, da die binär erstellt werden.
Der große Vorteil gegenüber log4net ist vor allem die Performance. So loggt das Framework selber sehr viel auch auf diese Weise, z.B. jede Aktion des Garbage Collector. Nachteil ist, daß Du einen Listener oder Perfview zum Speichern brauchst.