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 allen Admins recht einfach eine ordentlich robusten Webserver zu betreiben.

Header

In der Grundeinstellung posaunt der Nginx stets seine Versionsnummer raus. Das ist für Angreifer die einfachste Einladung und muss abgestellt werden. Mit der Option “server_tokens”, kann die Ausgabe gesteuert werden. Stellt daher den Servertoken auf “off”, damit wird der Header des Dienstes auf die Ausgabe “Nginx” reduziert. Die Version des Nginx kann man dennoch über Tools ermitteln, es erschwert nur die Erkennung und reduziert “DriveBy”-Angriffe.

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.

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.

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.