Firewall (pfSense) und Big Data (splunk>)!?

SierraX

Well-Known Member
Hi,
ich hab mir zu Ostern ein virtuelles Testnetzwerk aufgebaut und das ganze durch eine virtuelle pfSense appliance von dem physischen Netz getrennt. Das ganze läuft auf einer VM Ware Fusion Pro 8 Version aber das nur so am Rande.
Am Dienstag dann bin ich dann auch dazu gekommen, einen Standalone Splunk Server in dem Testnetzwerk ein zu richten.
Der FreeBSD Splunk Universal Forwarder liess sich auch relativ problemlos installieren, da es nicht in den FreeBSD Repositories drin ist (bei der Frequenz der Änderungen vielleicht auch gut so), musste man es eben von der Webseite runterladen und "von Hand" installieren mit pkg installieren.
z.Z. fliessen nur die Splunk internen Diagnose Daten rein... das sieht dann etwa so wie in dem Screenshot aus:
Bildschirmfoto%202016-03-31%20um%2020.22.06.png

Mein Frage nach dieser kleinen Vorstellung: Ich bin noch nicht zum suchen gekommen, kann mir vorstellen das ich alles auch so finden kann wann ich lang genug lese...
Kann mir ein pfSense Profi hier, eine schnelle Übersicht geben, welche Logdateien über die Firewall Funktionen interessant sein könnten, und wo die liegen? Auf die schnelle hab ich nämlich nur die vorgefertigten Logbetrachter auf dem CLI (was schon das lieferte was ich mir vorstelle) und ein paar für mich uninteressantere auf der WebGUI gesehen.


Vereinfacht: es ist ein System, das Klartextdaten jeder Art sammeln und speichern kann. Und diese dann auch durchsuchbar macht. Diese Suchen können dann eben für Statistiken und Alarmierungen hergenommen werden. Als Beispiel: Eine Firewall liefert die log-datei über die Durchsetzung der Regeln an den Splunk server... und man sucht nach den ip-adressen, die die letzte 15 Minuten geblockt wurden... durch die Häufung einer IP Adresse könnte man z.B. auf einen automatisierten Angriff schliessen... Datendurchsätze sind auch immer wieder interessant.
 
Status -> System logs -> Settings -> Enable Remote Logging Send log messages to remote syslog server

Warum nicht das Splunk via Netz mit Syslog Meldungen füttern?


Remote Syslog Contents Everything

System events
Firewall events
DHCP service events
Portal Auth events
VPN (PPTP, IPsec, OpenVPN) events
Gateway Monitor events
Server Load Balancer events
Wireless events
 
Der erste Impuls wenn man ein OS vor sich hat, für den es einen eigenen Splunk Universal Forwarder gibt, ist diesen auch zu verwenden... als ich mir derletzt die Struktur von der filter.log angeschaut habe, kams mir eh ein wenig komisch vor... kann es sein, dass die Logs in sich selbst rollen? Die meisten Logs haben die gleiche Grösse von 544K und head und tail liegen recht nah beieinander... nicht gerade das beste um es mit einem einem Logsammler einzusammeln der am Anfang überprüft ob das CRC Salt der ersten Zeilen sich verändert hat.
Da ist die Syslog variante wohl die bessere Wahl... muss mir eh für die Arbeit nochmal Syslog-NG angucken...
 
hi

sorry , ich für mich bleibe bei ossec , funktionat deutlich besser als splunk ...

holger
 
@mark05 was erst einmal zu beweisen wäre... davon abgesehen, das splunk ein analyse tool für jegliche art von strukturierten und unstrukturierten Daten ist und ossec so wie ich das auf die Schnelle sehe ein reines IDS. Freie alternative zu Splunk die aber noch etwas hinter her sein soll wäre z.B. fluentd...
 
Hi

weiterlesen , OSSEC ist ein HIDS , und analysiert das logging ............ ist im überigen bestandteig vom AlienVault USM.


holger
 
Der "Ersatz" fuer Splunk liegt eher bei Logstash/Elasticsearch (und dann Kibana oder Grafana fuer's Eye-Candy). OSSEC ist da ganz wo anders.
 
Nach überfliegen der ersten Seite zu logstash muss ich sagen, das ich es mir auf alle Fälle mal genauer anschauen sollte...
Als zertifizierter Splunk Admin kann ich bisher nur sagen, wenn es wirklich bloss die vorgefertigten Patterns sind... müsste splunk sich warm anziehen...
Die Skalierbarkeit ist die grosse stärke von Splunk... Ich hab im Rahmen eines Kundenauftrags ein Splunk Multi-Site Cluster aufgebaut mit Indexing Clustern und StandAlone Indexern in 3 Ländern... abgefragt von Search Heads in München... daran muss eine Alternativ sich dann erst einmal messen lassen.
 
Aber zuerst an dem geplanten Bedarf :-)
TCO spielt dann auch noch eine nicht ganz unwichtige Rolle
 
Hi,

würde für pfsense auch eher den Remote Syslog Ansatz verfolgen. In dem Kontext ist vielleicht das Filter Log Format für Dich interessant: https://doc.pfsense.org/index.php/Filter_Log_Format_for_pfSense_2.2

Zu splunk: Aus aktuellem beruflichen Anlass war ich unlängst auf einem splunk Event. Ich bin der Ansicht, dass die Lösung zwar viel kann, aber (für meinen Einsatzzweck) unverschämt teuer ist. Wir gehen jetzt den Weg: Logstash als Kollektoren -> Kafka Cluster als Message Queue -> Graylog Indexer+WebGUI -> Elasticsearch Storage. Hochverfügbar ausgelegt und horizontal massiv skalierbar.

Gruß
 
Schau mal wegen Logstash noch nach den "Beats" (Go statt Java).

Graylog als WUI? Kenn ich nur Kibana (ab 4 sehr grottig) oder was wir nun reinnehmen: Grafana.
 
@double-p: Kibana macht hübsche bunte Bildchen, aber bildet User Management in keiner Form ab. Es gibt zwar das kostenpflichtige Shield, welches sich als Auth-Proxy vor Elasticsearch parkt - dadurch wird Kibana aber nicht "User-aware". Das Web-Interface von Graylog ist da deutlich weiter und bietet ein rollenbasiertes Userkonzept, weshalb wir uns dafür entschieden haben - die Auswertungsfunktionalität steht Kibana kaum nach.

Beats kommt auf Servern zum Einsatz, um Events aus div. Logfiles an die Logstash Kollektoren weiterzuleiten. Alles andere (Netzwerk-Infrastruktur) funkt per udp-syslog.

Gruß
 
Hi,
würde für pfsense auch eher den Remote Syslog Ansatz verfolgen. In dem Kontext ist vielleicht das Filter Log Format für Dich interessant: https://doc.pfsense.org/index.php/Filter_Log_Format_for_pfSense_2.2
https://doc.pfsense.org/index.php/Filter_Log_Format_for_pfSense_2.2
erstmal Sorry für die Vernachlässigung des Threats und danke für den Link.

Zu splunk: Aus aktuellem beruflichen Anlass war ich unlängst auf einem splunk Event. Ich bin der Ansicht, dass die Lösung zwar viel kann, aber (für meinen Einsatzzweck) unverschämt teuer ist. Wir gehen jetzt den Weg: Logstash als Kollektoren -> Kafka Cluster als Message Queue -> Graylog Indexer+WebGUI -> Elasticsearch Storage. Hochverfügbar ausgelegt und horizontal massiv skalierbar.
Gruß
Wie schon erwähnt... bei mir ist es auch aus beruflichen Gründen das ich wegen splunk schaue. Es sollte hier jetzt auch nicht zu Werbung für oder gegen splunk ausarten. BigData ist z.Z. ein Buzzword um das sich verdammt viele Anbieter reissen und was ich bisher mitbekommen habe schauen grosse Kunden eher nach "aus einem Guss" und "hab ich einen Ansprechpartner" und nicht so wirklich nach den Techniken dahinter bzw. welche Nachteile könnte die verwendete Lösung haben. Hatte bevor ich diesen Job angetreten habe auch noch nie was von Splunk gehört gehabt und BigData war einfach nur ein Wort für "viele Daten"
 
Zurück
Oben