Syslog-Server für alle Clients?

Registriert
Jan. 2023
Beiträge
4
Guten Tag liebe CB Gemeinde,

ich bräuchte Hilfe bei einem Fall, den ich zurzeit bearbeiten muss.
Und zwar soll ein Syslog Server eingerichtet werden, dieser soll von der Cloud aus arbeiten oder in die Cloud speichern.
Logs, die gespeichert werden, stellen sich aus Windows Server und Windows Clients Logs zusammen.

Ist es sinnvoll bzw. möglich von der Bandbreite her, dass jeder Client (150-200) seine Eventlogs einmal die Woche an eine zentrale Stelle sendet?
Möglichkeit um Massen-Scripts abzuschicken ist vorhanden.

Lieber über PowerShell Scripts realisieren oder bekannte Syslog Server hierfür benutzen?

Ich wäre glücklich über jeden Input, den ich hierzu kriegen kann ;)

Beste Grüße
 
Was genau ist das Ziel, also warum sollen die Logs in "die Cloud"? Für einige Anbieter gibt es spezielle Applikationen, die man dann auch einfacher steuern kann. Du wirst nämlich vermutlich filtern wollen, was alles gespeichert wird, bzw. die Logs einfach als Textdatei in den Äther pusten ist oft wenig sinnvoll, wenn man hinterher was wiederfinden will.
 
Du kannst die Daten eigentlich in Echtzeit verschicken (Monitoring), ansonsten wäre der Versand 1x die Woche ja nur eine Art Archivierung. Ich hatte mal Kiwi Syslog Server im Einsatz (Java), bin aber wegen der ganze Java Sicherheitslücken nicht angetan gewesen.

Wie bereits von Anderen erwähnt wäre das Ziel, was du verfolgst, interessant zu wissen.
 
Sorry, dass ich mich zu ungenau ausgedrückt habe.

Ziel ist, dass jeder Benutzer und Server Log-Dateien an einen zentralen Punkt schickt.
Das bei Ransomware befall die Log-Dateien an einen Forensiker gehen können.

Cloud Anbindung wäre cool, da bei Verschlüsselung die Daten noch sicherer sind.
Optional würde auch ein Cold-Storage funktionieren.

Jetzt habe ich bisher 2 Möglichkeiten ausgearbeitet (Nehmt es mir nicht böse falls ich falsch denke oder Falschinformationen verbreite, ich bin ein Anfänger :()

1. Möglichkeit =
1x mal täglich/wöchentlich PowerShell Skript laufen lassen und alles an Logs einsammeln

2. Möglichkeit =
syslog-ng hosten und Logs mit Loganalyzer durchsuchen

Wenn ich erstmal wüsste, ob mein Vorhaben so erstmal möglich ist, würde ich mir Gedanken zum Ordnen der gespeicherten Logs machen ^^

Danke für den Input, gerne mehr
 
Ggf. Traffickosten bei CLoud im Auge behalten.
Je nach Logging/Modul/Kunde usw. kommt bei uns manchmal schon 2-4GB an Logs/h raus.

Da Logs nur Text sind, lässt sich das gut komprimieren, wir gehen aktuell her und zippen Logs, schicken sie an das ziel und entpacken sie dort, so lässt sich der Traffic für den man bei Cloud (je nach cloudanbieter wie Azure oder IBM Cloud) ja teuer bezahlt, reduzieren.
 
Hmm, bei Benutzerlogs kann das ggf. schon kritisch werden, da die Benutzer darauf hingewiesen werden müssen, dass sämtliche ihrer Aktionen geloggt und gespeichert werden. Das ist nicht immer ganz einfach je nach Firma.

Bezüglich Cloud Anbindung: Bloß weil das Ding in der Cloud steht, heißt es nicht, dass die Daten nicht auch verschlüsselt werden können. Irgendwie muss das ja dahin kommen, das heißt es wird einen Weg geben der offen sein muss.

Was eine Option wäre, soetwas wie Graylog in einer virtuellen Maschine aufsetzen und diese quasi nur noch für den Empfang der Logs und freizuschalten und erst im Fehlerfall andere Ports öffnen um daran zu kommen. Dann könnten deine Clients/Server auch 24/7 die Daten dahin senden. Dann hättest du noch eine nette WebGUI alá Splunk um deine Daten besser einzugrenzen.

Alternativ wie du schon geschrieben hast: rsyslog aufsetzen, lograte anmachen und dann ist das auch ok.

Allerdings wird es so oder so lustig diese Ganzen Daten zu analysieren im Fehlerfall. Denn nach was genau möchtest du denn ausschau halten? Die meinsten Verschlüsselungstrojaner ruhen eine Ganze Zeit bevor sie aktiv werden.
 
PythonNewbie12 schrieb:
Ziel ist, dass jeder Benutzer und Server Log-Dateien an einen zentralen Punkt schickt.
Das bei Ransomware befall die Log-Dateien an einen Forensiker gehen können.
Kann man machen. Ich kenne aber niemanden, der das händisch macht. Stichwort hierzu ist SIEM. Vergiss nicht, auch die Logs von Firewalls, Routern, Backup, AV-Software, Hypervisoren, etc. mit reinzunehmen. Nur die Eventlogs sind nicht ausreichend. Das angedachte Intervall auch nicht. Was bringen im Schadensfall eine Woche alte Logfiles?
 
  • Gefällt mir
Reaktionen: snaxilian und Conqi
Eine andere Möglichkeit wäre auch, erstmal eine Firma zu finden, die die Forensik überhaupt übernehmen würde, und die zu fragen, in welcher Form sie die Logs am liebsten hätten.

Ein SIEM wäre eine Lösung, aber wenn man selbst mit den Logs nicht arbeiten wird, ggf. auch überflüssig.

Die Frequenz der Sicherung muss aber definitiv höher als wöchentlich sein, da stimme ich voll zu. Im Zweifelsfall erfolgen Angriff und Verschlüsselung innerhalb von Stunden oder sogar nur Minuten.
 
Evil E-Lex schrieb:
Kann man machen. Ich kenne aber niemanden, der das händisch macht
Wir hatten das in der alten Firma per rsyslog gemacht. Ist im Detail dann aber auch nicht ganz trivial. Es gibt eine Pulle und eine push Semantik. Wir hatten das ganz für rund 1000 Server betrieben. Die Server hatten in Gruppen von ca 200 Servern einen push an jeweils einen Container mit rsyslog gemacht, die die Daten gepuffert haben. Im Anschluss hatten dann zwei Systeme per Pull von den Containern alle Daten geholt. Diese Server waren nur aus dem Admin netzt per SSH für die Admin User zugänglich. Und alle Ports geschlossen bis auf den für SSH und rsyslog.

Der Traffic ist selbst beim gleichzeitigen Booten von 1000 Rechnern "überschaubar". Mehr als nen GBit/s sieht man da nicht.

Das nette an der pull Semantik ist das es über hashes geht. Sprich wenn der pull Server mal kurz überlastet ist, nen Aussetzer hat oder sonst was, dann holt er das auch wieder auf so lange die Aggregationsserver/Container die Daten noch haben. Man kann also auch die Logserver mal erboten etc.

Zudem kann man über Monitoring auch schnell sehen wenn keine neuen Daten ankommen, das auffällig ist.

Platztechnisch kommt man mit zwei NVMe über Monate hin. Auch was Performance anbelangt.

Bis das ganze aber wirklich wuppt braucht es ne ganze Zeit. Rsyslog hat ne blöde Beschränkung für den remote Teil. Nach einigen dutzend/hundert TB ist aus die Maus. Da bleibt das einfach stehen.... ist leider auch der aggregierte Wert über alle logfiles in dem directory. Für lange retention Times muss man also leider etwas selber skripten. Die logfiles einfach nach Datum in Unterordner sortieren geht ganz einfach.

100GB+ dann aber nach etwas zu durchsuchen ist dann schon zäh. Ist es mit Kibana, also ELK aber auch nicht wirklich.

Ich kann also sagen ja, das sollte alles überhaupt kein Thema sein. Aber über die Granularität würde ich mir wirklich Gedanken machen. Alles andere als "live" sehe ich als disfunktional an. Wenn man wegen Performance und Sicherheit einen Aggregationslayer hat, dann sollte der per push die Daten sofort bekommen und der eigentliche Logserver maximal ein oder zwei Minuten brauchen um auch den schlimmsten logspam zu verdauen der durch ein gleichzeitiges Booten aller Systeme Auftritt.

Dann hat man nämlich ein robustes System das auch im schlimmsten Fall wirklich etwas hilft. Braucht aber in jedem Fall jemanden, der zumindest einmal die Woche drüber schaut ob noch alles sauber tut.

Wobei wenn man an SIEM denkt sollte eh kontinuierlich geschaut werden was los ist auf dem System.
 
  • Gefällt mir
Reaktionen: Evil E-Lex
Zurück
Oben