Heute musste ich mir eine Windows VM installieren knirsch. Da ich den Windows Lizenzschlüssel des Rechners bis dato nicht benötigte, ich nutze nur noch Linux, wollte ich die nicht genutzte Windows Lizenz für die VM nutzen. Der Lizenzschlüssel ist allerdings nur im BIOS hinterlegt worden und nicht mehr als Aufkleber beigelegt. Nach einiger Suche habe ich nur eine sinnvolle Lösung für das Auslesen unter Linux gefunden, die ich euch natürlich nicht vorenthalten möchte.

Nichts scheint ominöser zu sein als der Umgang mit Zertifikaten. Ich erlebe im täglichen Umgang mit Zertifikaten, dass zu viele Administratoren daran verzweifeln, dabei sind Zertifikate sehr einfach aufgebaut und folgen einer simplen Struktur.

Ich möchte in dem Artikel nicht auf jedes Detail eingehen, es gibt auch Ecken an denen man berechtigterweise Verzweifelt. Den Bereich möchte ich mir und euch in diesem Beitrag ersparen. Der folgende Rundumschlag sollte aber jedem den Umgang mit X.509 Zertifikaten verdeutlichen und ein zwei Tipps mit auf den Weg geben, die den Umgang erleichtern und die Implementierung etwas sicherer gestalten können.

PHP hat in den letzten Jahren eine deutliche Wandlung vollzogen, um den Anforderungen an eine moderne Infrastrukturen mit gehen zu können. Früher lief PHP vornehmlich als Apache Modul und war damit an die Leistungsfähigkeit des Apaches gebunden. PHP ist nun, seit einigen Jahren, durch FPM stark skalierbar und lässt sich völlig unabhängig von einem bestimmten Webserver einsetzen.

Ich stelle euch in diesem Artikel den Aufbau des FPM 7.0 vor. Ich habe für den Umstieg vom Apache-PHP Modul auf php-fpm viele Artikel gelesen, keiner der von mir gefundenen Artikel war so rund, das ich schnell und eindeutig verstanden hatte, wie der Aufbau und die Funktion war. Daher war es mir wichtig diesen Artikel zu schreiben, damit für euch der Ein/Umstieg schnell, einfach und nachvollziehbar ist.

Ein Traum wird wahr. Eine eigene Firewall, ein eigenes IDS mit einer zentralen Adblock Liste, mit eigenem WLAN, VLANs und und und… Die Liste lässt sich fast endlos erweitern. In diesem Artikel möchte ich euch meine Schritte zum Aufbau des APU 1D4 mit IPFire vorstellen.

Mit der APU Plattform hat mir der Hersteller PC Engines ein günstige Alternative zu den ganzen Plaste-Routern angeboten, welches ich gerne in Anspruch nehmen möchte. Ich denke, dass es viele Paranoiker und Bastler gibt, die sich ihr eigenes Netzwerk aufbauen möchten, ohne auf closed source oder ähnlichem zurück greifen zu müssen.

Viele Webserver und deren Webapplikation laufen ohne tiefgreifendere Konfigurationen. Dabei verpasst man die Chance sich und seine Besucher besser vor Angriffen zu schützen. Nur wenige Einstellungen erwarten eine wirklich tief gehende Kenntnis über deren Funktion und ermöglicht somit den meisten Admins recht einfach eine ordentlich robusten Webserver zu betreiben.

Die Konfigurationen sind in den Distributionen leider alle unterschiedlich strukturiert d.h. man sollte seinen Apache schon etwas kennen gelernt haben. Letztlich hat man eine Apache-Konfiguration, die z.B. bei Debian/Ubuntu unter /etc/apache2/apache2.conf liegt und unter RedHat/CentOS unter /etc/httpd/conf.d/httpd.conf. Dort sollten nur Apache relevante Einstellungen erfolgen, keine Modulkonfigurationen! Die Modulkonfigurationen wie z.B. TLS, Caching, FCGI usw. erfolgen in der Regel in den eigenen Konfigurationen. Doch nicht alle nötigen Einstellungen sind zwingen in diesen Dateien zu erfolgen, sondern können auch in einer VirtualHost speziell für eine (Sub)Domain hinterlegt werden. Wie ihr seht müsst ihr etwas flexibel sein und die jeweilige Konfiguration in eurem System suchen bzw. explizit dort setzen wo ihr sie benötigt.

Lynis ist eine weitere Entwicklung von Michael Boelen, der unter anderem auch für den beliebten Rootkit Hunter (rkhunter) bekannt ist. Lynis analysiert das Betriebssystem auf bekannte Dienste und testet deren Einstellungen auf typische Verfehlungen. Am Ende jedes Scans erhält man ein Ergebnis der Analyse und einen Gesamtwert als sogenannten Härtegrad. Lynis ist bei mir unter Debian, Ubuntu und RedHat/CentOS im Einsatz und funktioniert dort tadellos. Die Installation ist sehr einfach, der Scan ist sehr schnell.

Wer einen Linux Server betreibt und bei seinem Provider keine vorgeschaltetet Firewall erhält, hat es in der Regel recht schwer Attacken auf den SSH-Port zu unterbinden. Mit dem Dienst Knock ist es möglich Ports nach außen zu sperren und erst bei einem korrekten Anklopfen einer vorher festgelegten Port-Sequenz, wird der Port für die anklopfenden freigeschaltet.

Die Verwendung von Knock macht den versteckten Dienst nicht sicherer, da die Anklopfsequenz mitgeschnitten werden könnte, allerdings bleiben standard Bruteforce-Attacken aus den Logdateien und ernsthafte Attacken werden einfacher zu erkennen. Ein deutlich größerer Sicherheitsgewinn ist da schon eher, dass der Header des SSH-Ports nicht mehr adhoc lesbar ist, da dieser schon viel über die verwendet Distribution und über deren Patchlevel verrät.

Kontakt

homepage@cais.de

Quellenangaben für die verwendeten Bilder und Grafiken

Fotolia – 40120448 – alphaspirit
Fotolia – 41572179 – Anton Balazh
Fotolia – 40726761 – vege
Fotolia – 39053413 – freshidea
Fotolia – 34471268 – Pavel Ignatov
Fotolia – 41283468 – F.Schmidt
Fotolia – 42024043 – Mopic
Fotolia – 83008674 – GKSD
Apache Software Foundation
OpenSSH
IPFire
PHP.net
Nginx
Microsoft
TomTom
Purism

Content-Managment-System

https://gohugo.io/

Template based on

https://github.com/vimux/mainroad/

Create_swap

draft: false title: “Create Swapfile” date: 2021-10-08T00:04:25+02:00 description: “Create an swapfile” #thumbnail: “img/wafe.png” # Optional, thumbnail disable_comments: false # Optional, disable Disqus comments if true authorbox: false # Optional, enable authorbox for specific post toc: false # Optional, enable Table of Contents for specific post toc_sidebar: true # Optional, enable Table of Contents for specific post mathjax: false # Optional, enable MathJax for specific post categories:

• “Linux”
• “Misc” tags:
• “RAM”
• “Linux”

---

Create file with 1Gbyte