CrowdSec auf der OPNsense ist eine feine Sache und erkennt und blockiert standardmäßig bereits gängige Reconnaissance-Angriffe wie z.B. Port-Scanning. Wer aber NGINX als Reverse Proxy auf der OPNsense einsetzt, der möchte eventuell den Schutz auch auf NGINX ausweiten. Hierzu kann man einfach das NGINX-Szenario aus CrowdSec nachinstallieren, und auf den ersten Blick funktioniert danach auch zunächst alles – aber nur auf den ersten Blick.
Spätestens nach ein paar Tagen wird nämlich bei Betrachtung der Logs auffallen, dass anscheinend keine neuen Angriffe geloggt bzw. geblockt werden – ein Neustart von CrowdSec löst dann das Problem, aber wieder nur vorübergehend. Das mag zunächst verwunderlich wirken, wo doch der CrowdSec Daemon ordnungsgemäß läuft – das Problem ist aber eigentlich recht einfach zu finden. Die Kurzfassung: CrowdSec liest die NGINX logs standardmäßig über Symlinks, also quasi Verweise auf die jeweils aktuellen Log-Dateien ein. OPNsense rotiert diese Logdateien jedoch regelmäßig, was dazu führt, dass CrowdSec sozusagen „die Spur verliert“ und nun eine alte oder nicht mehr existierende Log-Datei einliest. Das passiert deshalb, weil CrowdSec zu Beginn dem Symlink zur eigentlichen Logdatei folgt, aber dann nicht bemerkt, wenn die Logdatei rotiert wird. Um das zu beheben, müssen wir ein paar Konfig-Dateien anpassen bzw. anlegen, aber das ist in wenigen Minuten erledigt.
In Teil 1 dieser Reihe haben wir uns damit beschäftigt, wie ich überhaupt auf die Idee gekommen bin, OPNsense zuhause als Router einzusetzen, welche Vor- und Nachteile das hat und welche Hardwareoptionen es dabei allgemein gibt. In diesem Teil wollen wir uns nun konkret mit der von mir geählten Hardware beschäftigen.
Wie ich zum Ende des letzten Beitrages bereits angeteasert habe, ist der Anlass dieses Beitrags, dass ich meine bestehende Firewall-Lösung mit neuerer und vor allem leistungsfähigerer Hardware ersetze, wodurch ich beide Lösungen miteinander vergleichen kann – konkret in diesem Fall den Fujitsu Futro S920 als günstigen Einstieg in die Welt von OPNsense, und den HP T740 als leistungsfähige Lösung für alle, die Multi-Gigabit oder Features wie IDS/IPS brauchen, oder die vielleicht sogar die Firewall virtualisieren (Proxmox) und zusätzlich noch andere Andwendungen auf dem Rechner ausführen wollen.
Seit einiger Zeit schon verwende ich einen ZyXEL NBG7815 Router („Armor G5“) als Access Point mit OpenWRT, da ich diesen sehr günstig bekommen konnte. Der ZyXEL besitzt zwar einen Qualcomm-SOC (IPQ8074A), wird aber dennoch unterstützt. Natürlich mit der üblichen Einschränkung, dass die proprietäre NSS-Engine des SOCs nicht unterstützt wird, wodurch NAT, Routing, etc. nicht in Hardware beschleunigt werden können – für den Betrieb als Access Point fällt das aber nicht ins Gewicht. Wer den Armor G5 tatsächlich als Router benutzen möchte, dem empfehle ich allerdings den NSS-Build von asvio auf GitHub. Für mich bringt dieser Build hingegen sogar primär Nachteile, da die VLAN-Konfiguration mit NSS nicht bzw. nur mit einem Workaround funktioniert und man natürlich für Updates auf die Maintainer des NSS-Builds angewiesen ist.
Ein weiteres Problem hat das Standard-OpenWRT mit dem Armor G5 noch, und zwar besitzt der Router einen kleinen Lüfter, der von OpenWRT allerdings nicht angesteuert wird. Den Lüfter braucht er auch durchaus, wenn die CPU beansprucht wird. Das ist bei der Verwendung als AP zwar tendenziell wenig der Fall, aber dennoch war mir nicht richtig wohl dabei, dass die CPU sich ohne den Lüfter auch bei geringer Last bei >85 °C einpendelt. Der oben verlinkte NSS-Build löst dieses Problem, indem er den Lüfter ansteuert. Wer aber wie ich lieber beim Standard-OpenWRT bleiben möchte, der kann die Lüftersteuerung auch einfach per Skript implementieren – und genau darum soll es heute gehen.
Schon seit geraumer Zeit betreibe ich in meinem Heimnetz eine OPNsense Firewall. In diesem Beitrag (Teil 1) soll es darum gehen, was eine solche Lösung im Heimnetz nützt, welche Nachteile man evtl. in Kauf nehmen muss und welche Hardware sich zur Umsetzung eignet.
Dies ist als mehrteilige Serie gedacht. In Teil 2 geht es um meine konkrete Umsetzung bzw. die verwendete Hardware und bei Interesse und Zeit könnten auch noch weitere Beiträge folgen. Alle weiteren Beiträge werde ich auch hier verlinken.
Die Vorgeschichte (wie ich auf die Idee kam)
Meine Wohnung besitzt einen mit meinem Vermieter geteilten Kabelanschluss (Vodafone Kabel, ehemals Kabel Deutschland), was in der Theorie schön hohe Internet-Geschwindigkeiten von 500Mbit/s Down und 50Mbit/s Up ermöglicht, weshalb ich von diesem Angebot gerne Gebrauch gemacht habe. Leider hat so ein Kabelanschluss aber auch Nachteile – Kabel ist grundsätzlich ein „Shared Medium“, man teilt sich die Bandbreite also mit den Nachbarn, weshalb die tatsächliche Geschwindigkeit besonders in den Stoßzeiten durchaus auch mal deutlich niedriger liegen kann. Das eigentliche Problem begann aber, als während Corona, als ich den ganzen Tag im Homeoffice bzw. Online-Studium saß, der Kabelanschluss mehrere Wochen am Stück ausfiel. Das war verständlicherweise eher schlecht, weil ich natürlich auf einen funktionierenden Internetanschluss angewiesen war. Als das Ganze sich dann ein halbes Jahr später ein weiteres mal wiederholt hat, ist mir der Geduldsfaden gerissen, und ich habe einen DSL-Anschluss bei der Telekom gebucht.
Der DSL-Anschluss funktionierte zwar viel zuverlässiger als der Kabelanschluss (wobei man fairerweise erwähnen muss, dass ich wahrscheinlich einfach nur Pech hatte: seit dem zweiten längeren Ausfall vor einigen Jahren läuft auch der Kabelanschluss stabil), war aber natürlich deutlich langsamer: nur 200 Mbit/s im Download, nur der Upload war immerhin gleich (50Mbit/s). Also kam ich auf die Idee: „Was, wenn ich die Geschwindigkeit beider Internetleitungen kombinieren kann?“ Man gönnt sich ja auch sonst nichts.
Im Folgenden werde ich nun etwas ausführlicher auf die für mich entscheidenden Vorteile eingehen und anschließend ein kurzes (Zwischen-)Fazit ziehen.
Wenn man über Gran Canaria spricht, kommt den meisten Menschen zuerst Maspalomas, die dortigen Sanddünen und der Massentourismus in den Sinn – aber geht es auch anders? Das wollten wir herausfinden. Unsere Reise fand Ende Februar 2024 statt, und ich denke ich nehme nicht zu viel vorweg wenn ich sage, dass ich diesen Reisezeitpunkt absolut empfehlen kann. Unser Ziel war es, dem grauen nasskalten Winter in Bayern zu entfliehen und dabei nicht zu viel Geld auszugeben, und das haben wir definitiv geschafft.
Unsere Reise begann, wie man das kaum anders erwartet, im kalten, bewölkten und regnerischen München. Trotz anfänglicher Bedenken (aufgrund des eher desaströsen Starts der Fluggesellschaft im vorherigen Jahr) hatte ich den Flug bei Marabu gebucht, einer frisch gegründeten Tochtergesellschaft von Condor, da der Flug mit einigem Abstand der günstigste war. Allerdings hatte Marabu nach ihrem ersten Sommer, in dem sie noch vollständig ohne eigene Flugzeuge geflogen sind (sprich nur Wet-Lease), einige A320 Neos in die Flotte aufgenommen, was die Zuverlässigkeit verbessern sollte – und natürlich ist Februar auch noch weit außerhalb der Hauptsaison, weshalb ich letztendlich doch zuversichtlich war. Durch die Saison bedingt hatte der Flug auch eine interessante Besonderheit: vor dem Anflug auf Gran Canaria erfolgte eine Zwischenlandung auf Fuerteventura, wo einige Passagiere von Bord gingen – das gibt es heutzutage eher selten, erlaubte uns aber, einen schönen Blick auf Fuerteventura von oben zu bekommen. Unterm Strich habe ich die Buchung dann auch nicht bereut – der Flug war pünktlich, verlief ohne besondere Zwischenfälle und die Crew war freundlich.
Heute (nach zugegeben langer Funkstille) mal etwas ganz anderes, das aber gleichzeitig auch einen ziemlich guten Hinweis darauf gibt, was ich so die letzten Jahre gemacht habe 😉
Ich möchte euch heute meine Bachelorarbeit vorstellen, die auf folgenden Titel hört:
„Implementierung und Analyse einer automatisierten Reaktion auf Vorfälle mithilfe des Security Orchestration Automation and Response (Cortex-XSOAR) Tools von Palo Alto Networks“
Wie der Titel nahelegt, beschreibe ich darin die Einbindung des SOAR-Tools „Cortex XSOAR“ von Palo Alto Networks in ein virtuelles Organisationsnetzwerk und den anschließenden Prozess, um einen simulierten Angriff erkennen und automatisch abwehren zu können. Die Arbeit ist komplett auf Englisch geschrieben, sollte aber nicht zu schwer zu verstehen sein. In diesem Artikel werde ich mich allerdings auf eine deutschsprachige Beschreibung beschränken, da ich den Blog jetzt nicht in zwei Sprachen führen möchte und ich ohnehin stark bezweifle, hier ein internationales Publikum anzusprechen. Nichtsdestotrotz habe ich sehr wenig unabhängige Literatur zu SOAR gefunden, daher ist meine Arbeit eventuell für den Einen oder Anderen von Interesse.
Bei dem in der Arbeit simulierten Netzwerkangriff handelt es sich um einen Data-Extraction Angriff. Bei einem solchen Angriff versucht ein böser Akteur Daten aus dem Firmennetzwerk auf ein von ihm kontrolliertes Ziel im Internet zu übertragen. Diese Art von Angriff ist relativ weit verbreitet und kann extrem viel Schaden anrichten – und auch große Unternehmen mit entsprechenden Ressourcen für IT-Sicherheit sind offenkundig nicht sicher. Aktuelle Beispiele, von denen die Tech- und die Spielebranche betroffen war, sind sicherlich die Hacks der Gruppe „Lapsus$“, von denen unter anderem Microsoft, Nvidia und Rockstar Games betroffen waren. Bemerkenswert ist hierbei, dass keine ausgeklügelten Exploits ausgenutzt wurden, sondern die Angriffe primär auf Social Engineering aufbauten, um Zugangsdaten zu erlangen. Diese Zugangsdaten wurden dann verwendet, um die Daten zu entwenden.
Das große Problem bei solchen Angriffen ist, dass sie sich mit den traditionell eingesetzten Werkzeugen der Netzwerksicherheit kaum bis gar nicht verhindern lassen. Eine Firewall wie z.B. die auch in meiner Arbeit eingesetzte Next-Generation Firewall von Palo Alto ist in der Lage, auch komplexe Netzwerkangriffe zu erkennen und zu verhindern, wenn der Angreifer sich jedoch mit gültigen Zugangsdaten im Netzwerk anmelden kann und/oder sich bereits im Inneren des Netzwerks befindet ist sie nahezu machtlos. Ein SIEM-Tool (Security Information and Event Management) wie z.B. Splunk Enterprise kann verwendet werden, um Auffälligkeiten im Netzwerk zu erkennen und Warnungen (Alerts) auszugeben, allerdings müssen diese manuell geprüft und bearbeitet werden, was bei einer entsprechenden Netzwerkgröße kaum noch praktikabel möglich ist.
Genau an dieser Stelle kommen SIEM-Tools (Security Information & Event Management), wie in diesem Fall Cortex-XSOAR, zum Tragen. Sie ermöglichen es, auf Alerts aus einem SIEM-Tool automatisiert zu reagieren. Dafür können die Vorfälle komplett automatisch analysiert, mit zusätzlichen Informationen angereichert und letztlich bearbeitet werden, wodurch beispielsweise ein Datenleck ohne manuelles Zutun geschlossen werden kann – gerade bei diesem Thema ist die Reaktionszeit natürlich auch sehr relevant, denn je länger das Leck besteht, desto mehr Daten können dadurch extrahiert werden.
In der Bachelorarbeit habe ich zunächst ein virtuelles Unternehmensnetzwerk aufgebaut und konfiguriert. Das Netzwerk setzt auf die Next-Generation Firewall von Palo Alto Networks und Splunk Enterprise als SIEM, welches die Netzwerk-Logs direkt von der Firewall bezieht – die Arbeit geht auf die detaillierte Konfiguration ein. Dann habe ich eine Software geschrieben, die einen Data-Extraction Angriff simuliert (zugegeben, meisterhaftes Coding sieht anders aus, aber sie erfüllt ihren Zweck). Wenn der simulierte Angriff ausgeführt wird, erkennt Splunk diesen mittels eines entsprechend konfigurierten Alerts und sendet diesen an Cortex-XSOAR. XSOAR arbeitet den Vorfall anhand eines speziell hierfür erstellten Playbooks ab und unterbindet automatisch mithilfe der Firewall den Angriff. Anschließend informiert es den Netzwerkadministrator, der die getroffenen Maßnahmen auf Knopfdruck rückgängig machen kann, falls es sich um einen autorisierten (aber nicht angemeldeten) Upload gehandelt haben sollte und der wütende Chef gerade am Telefon ist, weshalb das „Internet schon wieder nicht funktioniert“.
Die Arbeit kommt letztlich zu dem Schluss, dass SOAR-Tools das Potenzial haben, die Netzwerk- und Datensicherheit erheblich zu erhöhen, was Unternehmen erheblichen Schäden bewahren kann, sowohl finanziell als auch bei der Reputation.
Bei Interesse könnt ihr die Arbeit hier als PDF herunterladen. Wenn ich dazu komme, würde ich die Arbeit auch gerne noch über die Hochschulbibliothek veröffentlichen, dann würde sie auch auf Google Scholar gelistet – dafür benötige ich aber noch diverse Unterschriften, und man kennt das ja, wie das läuft, mit Dingen die man sich vornimmt 😀
Seit AMD im Jahr 2017 die Ryzen-Prozessoren der ersten Generation auf den Markt gebracht hat, ist im CPU-Markt einiges an Bewegung eingekehrt. So waren 8-Kern CPUs noch vor wenigen Jahren Servern und HEDT-Systemen vorbehalten, heute sind sie jedoch im Mainstream sowohl bei AMD als auch bei Intel weit verbreitet.
Heute stellen wir uns deshalb die Frage, wie gut 8-Kern CPUs aus dem damaligen Server bzw. HEDT-Segment mit diesen neuen Mainstream-Prozessoren mithalten können. Dabei ziehen wir den Intel Xeon E5 1680v2 heran, eine Ivy-Bridge CPU für den Sockel LGA2011. Diese CPU hat im Unterschied zu anderen Xeon-Prozessoren für diesen Sockel einen offenen Multiplikator, lässt sich also frei übertakten, was wir uns selbstverständlich zunutze machen.
Zusammengefasst lässt sich sagen, dass der Xeon in Anbetracht seines Alters eine beachtliche Leistung abliefert, auch wenn er natürlich nicht an die aktuelle Generation der 8-Kern CPUs heranreicht, da ihm hierzu schlicht die nötige IPC bzw. Single-Core-Leistung fehlt. Eine Interessante Alternative für ein AM4-System ist er dadurch nur in Ausnahmefällen, wenn man auch von den restlichen Vorteilen der X79-er Plattform profitiert: der großen Anzahl an PCIe-Lanes, dem Quad-Channel Speicher und der Möglichkeit, ECC-Speicher zu verwenden. Wer jedoch wie ich noch ein gut ausgestattetes LGA2011 System sein Eigen nennt und gerne etwas mehr Leistung möchte, für den ist der 1680v2 die beste (und einzig sinnvolle) Aufrüstmöglichkeit, um aus dem alten System noch das letzte bisschen Potential herauszukitzeln.
Nachdem wir uns im letzten Beitrag den aktuellen Stand von integrierten Grafikeinheiten, kurz iGPUs, in Notebooks angesehen haben, wiederholen wir dies heute bei Desktoprechnern. Dafür ziehen wir auch dieses mal eine AMD Ryzen APU heran, und zwar den Ryzen 3 2200G, einen Quadcore mit 4 Threads und der integrierten Radeon Vega 8 Grafikeinheit. Dem aufmerksamen Leser dürfte auffallen, dass es sich dabei um die selbe Grafikeinheit handelt, die auch schon in dem zuletzt getesteten Notebook verbaut war – allerdings darf man sich im Desktop tendenziell eine etwas höhere Leistung erhoffen, da die APU hier aus einem großzügigeren thermischen Budget schöpfen kann und sich schnellerer RAM verwenden lässt. In diesem Fall verwende ich ein 8GB Dual-Channel Kit von G.Skill mit 2800MHz (von der Verwendung nur eines Moduls im Single-Channel rate ich dringend ab!).
Ein solches System ist durchaus interessant, weil sich mit dieser APU ein komplettes System für unter 300€ zusammenstellen lässt (näheres dazu im Video), welches sich vielseitig einsetzen lässt – aber auch zum spielen? Das versuche ich in diesem Video zu klären.
Zusammengefasst lässt sich feststellen, dass die APU zwar wie erwartet eine etwas höhere Performance abliefert als das zuletzt getestete Gegenstück im Notebook, dennoch würde ich sie für einen Gaming-Desktop nur sehr eingeschränkt empfehlen, da hier die Ansprüche in der Regel schlicht höher sind als bei einem Laptop. Den Hauptverwendungszweck der APU sehe ich eher in Multimedia-Anwendungen, wie zum Beispiel als HTPC im Wohnzimmer, aber auch für normale Arbeitsrechner, in denen eine dedizierte Grafikkarte schlicht unnötige Kosten und/oder Komplexität bedeuten würde. Allein für Gelegenheitsspieler, oder solche, die eher Strategietitel bevorzugen, kann ich die APU darüber hinaus uneingeschränkt empfehlen.
iGPUs, kurz für integrierte Grafikeinheiten, werkeln heutzutage in zunehmend vielen Rechnern, egal ob Desktop oder Notebook. Technisch bieten sie einige Vorteile, wie geringeren Stromverbrauch, einfachere Kühlung und auch geringere Kosten. Für normale Arbeiten wie Surfen oder Office reichen iGPUs in jedem Fall aus, darüber hinaus bieten sie mittlerweile in der Regel ebenfalls hardwarebasierte Videobeschleunigung, und auch Opas 3D-Aquariumbildschirmschoner bringt sie längst nicht mehr ins Schwitzen.
Eine Ausnahme war bis jetzt immer Gaming. Wer beabsichtigte, mehr als Minecraft auf seinem Computer zu spielen, dem war bis jetzt stets nahezulegen, um integrierte Grafiklösungen einen großen Bogen zu machen. In letzter Zeit hat sich hier jedoch einiges getan – erst mischten AMDs Ryzen-basierte APUs mit Vega-Grafikchip den Markt auf, und nun hat auch Intel einen deutlichen Leistungssprung der nächsten IGP-Generation angekündigt. Grund genug, dem Zocken auf intgrierten Grafiklösungen wieder einen Besuch abzustatten? Genau darum soll es in diesem Video gehen.
Das in diesem Video gezeigte Gerät ist ein Acer Swift 3 mit der wunderschön von der Zunge rollenden Modellnummer SF315-41-R4W1. Man kann seine Performance jedoch durchaus exemplarisch für alle Notebooks mit AMD Ryzen™ 5 2500U und der integrierten Radeon™ Vega8 Mobile Grafikeinheit sehen – sofern deren Kühlkonzept sinnvoll umgesetzt ist (hier ist bei manchen Geräten wohl Vorsicht geboten, am besten ihr checkt vor dem Kauf die Reviews speziell dieses Geräts).
Zusammengefasst lässt sich sagen, dass die Performance der iGPU dieses Geräts in etwa doppelt so hoch ist, wie die einer zum Kaufzeitpunkt gleichwertigen Intel-CPU – ein deutlich bemerkbarer Unterschied. Was man jedoch auch nicht verschweigen darf, die Leistung liegt damit immer noch nur knapp unterhalb derer von Einsteiger-Grafikchips für Notebooks. Für ein Gerät, dessen Hauptnutzen Gaming ist, sind sie daher zumindest momentan noch keine gute Wahl. Wer jedoch zwischen der Arbeit mal den einen oder anderen Indie- oder älteren Titel spielen möchte und im Zweifel bereit ist, auch mal Auflösung oder Grafikeinstellungen runterzustellen, der könnte hiermit glücklich werden. Für mich persönlich passt es perfekt.
Momentan steht bereits die nächste Generation der Ryzen-APUs in den Startlöchern. Das bedeutet einerseits, dass Geräte mit dieser Generation günstig im Abverkauf oder auch gebraucht zu haben sind – oder, dass Geräte mit dem Nachfolger (in diesem Fall der Ryzen™ 5 3500U) und damit nochmal ein wenig gesteigerter Performance im Handel sind.
Huch, mich gibt’s ja immer noch! In der Tat. Und da mir sonst gerade nichts kreatives einfällt, nutze ich die Gelegenheit, um (wahrscheinlich) das erste mal einen Post zu erstellen, in dem es nicht um Computer geht. Stattdessen möchte ich heute mal meine erste „Dashcam-Compilation“ präsentiern, denn ja, ich habe mir mittlerweile auch eins von diesen kleinen Dingern zugelegt. Man sieht einfach zu viele komischen Sachen auf der Straße, vor allem aber gibt die Dashcam einem die Möglichkeit, Situationen im Nachhinein ein zweites mal anzusehen, egal ob diese jetzt besonders lustig, gefährlich, oder anderweitig interessant war. Und man kann mehr oder weniger unterhaltsame Compilations daraus basteln, wie hier geschehen.
An dieser Stelle möchte ich noch kurz anmerken, dass mir bewusst ist, das mein Fahrstil auch nicht unbedingt perfekt ist. Daher bin ich konstruktiver Kritik natürlich immer aufgeschlossen.
Die Clips in diesem Video sind alle von mir als Fahrer und aus einem Opel Omega B 2.5 DTI aufgenommen, die verwendete Dashcam ist eine „iTracker Stealthcam-GPS“, welche in 1080p aufnimmt.
