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.
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.
Endlich ist es fertig – das Video zu meinem PC-Build. Dank 4-facher Videogeschwindigkeit, etwas Videoschnitt sowie Nachkommentierung ist daraus ein ganz sehenswertes knapp 14-Minütiges Video geworden, wie ich finde. Und an der Geschwindigkeit kann ich ja vielleicht in Zukunft noch arbeiten (solange diese nicht auf Kosten der Sorgfalt geht, versteht sich.) Alles in allem bin ich irgendwo doch erstaunt, dass er so ohne Probleme sofort lief ;D
Während ich noch immer auf die Garantieabwicklung von meinem Headset warte (und deswegen das PC-Build Video nicht nachkommentieren kann), habe ich hier mal etwas anderes für euch. Es handelt sich dabei um ein altes Tower-Serversystem mit zwei Intel Pentium 2 Prozessoren. Das gute Stück hat viele Jahre im Dauerbetrieb (24/7) seinen Dienst als Dateiserver verrichtet, allerdings mit einem externen, über SCSI angebundenen RAID-5 System. Das habe ich auch noch herumstehen, allerdings muss ich mir das mal extra ansehen. Die letzten Jahre stand es dann ungenutzt an diversen Lagerorten herum, vor einiger Zeit hatte ich es auch schon einmal kurz getestet, hatte aber keine Zeit mich damit weiter zu beschäftigen. Seitdem hat es seinen Standort bereits mehrmals gewechselt, ich war mir deswegen nicht sicher, ob es überhaupt noch anspringen würde – aber seht selbst.
