Daniels Blog
4Aug/120

Out of The Box USB Soundkarte für Linux – Logilink (UA0078) Soundkarte 7.1

Für ganze 6 Euro ist mir diese kleine, praktische USB-Soundkarte in die Hände gefallen. Sie besitzt eine Micbuchse, eine Speakerbuchse und einen Lautstärkeregler. Mit ihrer Hilfe kann man jedem Rechner sofort eine Soundkarte spendieren. Praktisch zum Beispiel temporär auf Servern um VoiP zu nutzen, oder um Sound auf einem Rechner zu haben, dessen Soundkarte Probleme macht.

Der Klang ist natürlich nicht berauschend, aber das echte Plug and Play ist problemlos.

Sie läuft direkt Out Of The Box nach dem Einstecken unter Ubuntu 12.04. Im Pulseaudiomixer taucht sie als "Audio Adapter Analog Stereo" auf und kann dort geregelt werden.

#/var/log/syslog

Aug  4 18:55:22 ww kernel: [ 4629.448058] usb 5-2: new full-speed USB device number 7 using ohci_hcd
Aug  4 18:55:22 ww mtp-probe: checking bus 5, device 7: "/sys/devices/pci0000:00/0000:00:13.0/usb5/5-2"
Aug  4 18:55:22 ww mtp-probe: bus: 5, device: 7 was not an MTP device
Aug  4 18:55:22 ww kernel: [ 4629.638832] input: C-Media USB Headphone Set   as /devices/pci0000:00/0000:00:13.0/usb5/5-2/5-2:1.3/input/input16
Aug  4 18:55:22 ww kernel: [ 4629.639006] generic-usb 0003:0D8C:000C.0009: input,hidraw2: USB HID v1.00 Device [C-Media USB Headphone Set  ] on usb-0000:00:13.0-2/input3

26Apr/128

Android Kontakte und Kalender ohne Google syncen mit Horde 4

Ich wollte meine persönlichen Daten nie Google geben und habe deswegen unter Android bisher auf das Syncen von Kalender und Adressbuch verzichtet. Als Notlösung habe ich regelmässige Backups mit My Backup Pro angefertigt. Schön war das allerdings nicht. Da ich inzwischen auch ein Android-Tablet besitze wurde syncen noch wichtiger. Zum Glück lässt sich das inzwischen komplett mit Open Source Software bewerkstelligen, falls die Android-Geräte "Microsoft Active Sync" unterstützen. Mit dieser Sync-Methode kann man seinen Androiden normalerweise an ein Exchange-Konto anbinden. Die kostenlose Groupware Horde bietet seit Version 4 allerdings auch einen kompatiblen ActiveSync-Server an. Damit steht der Android Synchronisation über mehrere Devices mit dem eigenen Server nichts mehr im Wege.

Grundvoraussetung ist ein eigener Linux-Server mit Apache und MySQL.

Zunächst muss Horde 4 installiert werden:

# Die Paketierung von Horde 4 läuft über PEAR
apt-get install pear

# PEAR auf den neuesten Stand bringen
pear upgrade pear

# Den Horde-Channel dem lokalen Pear bekannt machen
pear channel-discover pear.horde.org

# Horde Installationsverzeichnis konfigurieren
pear install horde/horde_role
pear run-scripts horde/horde_role

# Hier wird nach einem Installationsverzeichnis für Horde 4 gefragt.
# In meinem Beispiel ist es /var/www/horde4

# Horde installieren
pear install -a -B horde/webmail

# Horde Konfiguration umbenennen, um Horde zu aktivieren
cd /var/www/horde4/config
cp ./conf.php.dist ./conf.php

# Dem Webserver Rechte auf alle Horde-Files geben
chown -R www-data /var/www/horde4

Datenbank für Horde in MySQL anlegen:

Horde benötigt eine Datenbank in MySQL. In meinem Beispiel habe ich für Horde mit PHPMyAdmin den Benutzer "horde4" und die Datenbank "horde4" angelegt.

Horde über den Webbrowser konfigurieren:

Horde kann nun über den Webbrowser konfiguriert werden. Dazu öffnet man im Browser http://www.meinserver.de/horde4 . Da noch nicht konfiguriert wurde, welche Authentifizierung Horde nutzt, wird man direkt als Administrator der Installation eingeloggt.

Datenbank konfigurieren:
(Administration -> Konfiguration -> Horde -> Database)

Hier die Daten zur angelegten MySQL Datenbank eintragen:

Horde Authentifizierung konfigurieren:

Horde benötigt ein Backend um den Benutzernamen und das Passwort zu überprüfen. Horde bietet dafür viele verschiedene Möglichkeiten an. Der Einfachheit halber kann man hier das Password-File benutzen (/etc/passwd). Der User muss dann nur im lokalen System angelegt werden:

adduser horde_user

(Administration -> Konfiguration -> Horde -> Authentication)

Datenbanktabellen für Horde anlegen:

Horde konnte bisher die eigenen Datenbanktabellen in MySQL noch nicht anlegen, da wir ihm eben erst die MySQL-Benutzerdaten mitgeteilt haben. Um die Tabellen anzulegen besucht man die Hauptseite der Konfiguration und wählt "Alle DB-Schemata aktualisieren", bis das Ganze so aussieht:

(Administration -> Konfiguration)

Ab sofort sollte man sich in Horde mit dem Benutzer "horde_user" und dem beim adduser-Kommando gewählten Passwort einloggen können.

Apache konfigurieren

Damit Android an Horde syncen kann, muss noch ein Alias in die Apache-Konfiguration eingetragen werden:

#/etc/apache2/httpd.conf
Alias /Microsoft-Server-ActiveSync /var/www/horde4/rpc.php

Das ist notwendig, da Active-Sync Clients automatisiert die URL /Microsoft-Server-ActiveSync aufrufen, wenn sie mit ihrem Server connecten. Horde händelt die Synchronisation allerdings über die Datei rpc.php

Danach muss Apache seine Konfiguration neu laden lassen:

/etc/init.d apache2 reload

Wenn alles geklappt hat, sollte man nun auf seinem Androiden Sync-Konten einrichten können:

Mit diesem Setup Synce ich erfolgreich zwischen Horde, einem Sony Ericsson Xperia Mini Pro und einem Samsung Galaxy Tab.

Fallstricke:

  • Ich hatte zunächst mit doppelten Kontakten und Kalendereinträgen zu kämpfen. Am Besten exportiert man zunächst alle Kontakte und den Kalender aus dem Handy und importiert sie in Horde. Danach löscht man alle Daten auf dem Handy und lässt sie von Horde wieder in das angelegte Active-Sync-Konto auf dem handy schieben. Horde bietet viele verschiedene Möglichkeiten an Daten zu importieren. (Organisieren -> Kalender -> Import/Export) und (Organisieren -> Adressbuch -> Import/Export). Den Kalender bekommt man zum Beispiel aus Android gut mit der App "iCal Import/Export" heraus. Mein SONY bot für den Export der Kontakte selbst die Möglichkeit an, diese in ein VCard-File zu exportieren. Aber auch hier gibt es sicher eine geeignete Lösung bei Google Play.
  • Die Horde Authentifizierung per /etc/passwd sollte wie oben beschrieben funktionieren. Ich habe sie allerdings nur der Einfachheit halber für dieses Howto gewählt und nicht getestet, da ich selbst Horde an meinem IMAP-Server authentifiziere.
  • Als ich angefangen habe die Syncerei zu testen, funktionierte es zuerst nur mit meinem Tablet und nicht mit dem Handy. Nach 1 Stunde frickeln war der Fehler gefunden: Android synct nicht, wenn der interne Speicher zu voll ist. Nachdem ich ein paar Apps auf die SD-Karte verschoben hatte, ging es sofort.
15Jun/118

12 Maßnahmen um einen Linux root LAMP Apache MySQL PHP Webserver abzusichern


Die Hacking-Frequenz ist in den letzten Monaten stark angestiegen. Besonders viele Daten werden abgegriffen durch Hacks auf Webserver. Sogar der SONY-PSN-Hack nutzte Schwachstellen in einem ungepatchten Apache-Webserver. Deshalb sammele ich hier Maßnahmen, die den eigenen Server etwas sicherer gegen Angriffe von außen machen können. Natürlich bieten auch diese keinen 100%igen Schutz, aber es ist besser, den bösen Buben das Spiel ein wenig schwieriger zu machen. Einige der Maßnahmen benötigen nur einen minimalen Installations- und Wartungsaufwand. Andere benötigen viel Zeit und Kenntnisse von PHP um zu greifen. Man sollte immer auf das Kosten-Nutzen-Verhältnis bei der Auswahl der Sicherheitsmaßnahmen achten. Es macht keinen Sinn, eine kleine, private Website so abzusichern wie die Federal Reserve Bank. Allerdings können wenige gezielte Änderungen am System bereits ein großes Mehr an Sicherheit bedeuten. Und das sollte man sich schon gönnen, bevor es zu spät ist....

Alle Tipps und Codesnips beziehen sich auf eine aktuelle Debian-Kiste.

1. Die Firewall - erst einmal alles verbieten

Die meisten Linux-Distributionen öffnen in ihren Standardinstallationen keine Ports nach außen, die nicht unbedingt notwendig sind. Diese Situation kann man jedoch schnell selbst ändern, wenn man am Server
herumspielt und Dinge ausprobiert. Plötzlich lauscht auch der Mediaserver im Internet oder die Datenbank
nimmt Verbindungen aus dem Internet entgegen. Deshalb ist es nicht verkehrt sich selbst zu disziplinieren und eine sehr restriktive Firewall aufzusetzen, die grundsätzlich erst einmal alle Verbindungen von außen verbietet und nur (selbst) ausgewählte Verbindungen gestattet. Zum Glück ist das mit iptables schnell erledigt. Auf diese Art und Weise kann man nicht mehr aus versehen Dienste der Welt zugänglich machen, die dort nichts zu suchen haben. Man bezahlt leider mit etwas Komfort - die Firewall muss jedes Mal angepasst werden, wenn man neue Dienste anbieten möchte. Trotzdem ist der Aufwand klein und der Nutzen groß.

#!/bin/bash
# Bestehende Tables löschen
iptables -F

# Alle eingehenden Verbindungen verbieten
iptables -P INPUT DROP
iptables -P FORWARD DROP

# Alle ausgehenden erlauben
iptables -P OUTPUT ACCEPT

# SSH erlauben
iptables -A INPUT -j ACCEPT -p tcp --dport 22

# HTTP erlauben
iptables -A INPUT -j ACCEPT -p tcp --dport 80

# Weiteren Dienst (UDP) erlauben, zum Beispiel Gameserver
iptables -A INPUT -j ACCEPT -p udp --dport 4534

# Alles von Localhost erlauben. (Damit der Server selbst ungehindert auf seine Dienste zugreifen kann,
# zum Beispiel PHP auf die lokale Datenbank
iptables -A INPUT -j ACCEPT -s 127.0.0.1

# Bereits aufgebaute Verbindungen werden an jedem Port akzeptiert
# (Damit Antworten auf Anfragen, die vom Server kommen immer zurückkommen können)
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Dieses kleine Grundgerüst kann man einfach weiter ausbauen und eigene Dienste hinzufügen. Bei Arbeiten an der Firewall sollte man immer für den Fall vorsorgen, dass man sich selbst aussperrt. Besonders bei Remote-Servern, auf die man keinen physischen Zugriff hat, ist es sehr ärgerlich, durch eine mißglückte Firewallregel den eigenen Zugriff zu verlieren. Um diesem Problem aus dem Weg zu gehen, kann man bei Arbeiten an der Firewall einfach temporär einen Cronjob starten lassen, der die Firewall alle paar Minuten zurücksetzt oder den Server neu startet. Sind die Regeln später getestet und geliebt, kann der Cronjob wieder deaktiviert werden und die neuen Regeln bleiben permanent aktiv.

Um herauszufinden, welche Dienste gerade auf dem eigenen Server herumlauschen, kann man netstat benutzen:

#Für TCP-Sockets:
netstat -lpn | grep tcp

#Analog für UDP:
netstat -lpn | grep udp

Um zu testen ob die Firewall wirklich funktioniert, kann man den eigenen Server von einem anderen Rechner aus portscannen. Hat alles geklappt, sollten im Ergebnis nur die selbst geöffneten Ports auftauchen:

#Für TCP:
nmap -p1-65535 meinserver.de
#Für UDP:
nmap -sU -p1-65535 meinserver.de

2. SSH Logins verbieten

Am eigenen root-Server hat man uneingeschränkten SSH-Zugriff. Das ist recht praktisch, da man von jedem SSH-Client aus mal eben auf den Server kann um an ihm zu arbeiten. Der Nachteil davon ist, dass das natürlich auch jeder andere kann, der unglücklicher Weise irgendwie an das eigene Passwort gelangt ist. Es ist viel sicherer SSH-Logins nur mit einer gültigen Schlüsseldatei zu erlauben. Dafür wird der öffentliche Schlüssel des Clients auf den Server kopiert und interaktive Logins per Passworteingabe werden deaktiviert.

# Auf dem Client einen öffentlichen Schlüssel erstellen
# Wird bei der Generierung ein Passwort angegeben, benötigt man zum
# einloggen später die Schlüsseldatei UND das Passwort. Ansonsten wird
# nur der Schlüssel benötigt.

ssh-keygen -t rsa

# Den erstellten Schlüssel danach auf den Server kopieren

ssh-copy-id -i ~/.ssh/id_rsa.pub root@meinserver.de

# Danach auf dem Server /etc/ssh/sshd_config anpassen
.
.
PasswordAuthentication no
.
.

# Danach SSh neu starten
/etc/init.d/ssh restart

Auch hier sollte man Vorkehrungen treffen, um sich nicht selbst auszusperren, falls etwas nicht funktioniert.
Der Public Key auf einem USB-Stick mit dem dazugehörigen Passwort im eigenen Kopf macht es sehr viel schwerer für böse Buben eine Shell zu erhalten.

3. SSH Bruteforcing verhindern mit denyhosts

Falls Tipp 2 nicht praktikabel ist und man den Komfort von passwortgestützten Logins nicht aufgeben will, kann man zumindest das automatisierte Passwortraten von Angreifern auf dem Server verhindern. Sehr viele Bots im Internet machen den ganzen Tag nichts anderes als nach SSH-Servern zu suchen und bei Ihnen verschiedenste Passwörter durchzuprobieren. Mit einem halbwegs sicheren Passwort ist das kein großes Problem, trotzdem gibt es ein besseres Gefühl, wenn nicht einmal das möglich ist. Außerdem schützt man so auch seine User, falls auf dem Server auch Useraccounts bestehen. Hier kann man sich nicht darauf verlassen, dass die Benutzer sichere Passwörter verwenden. denyhosts überprüft ständig Logins auf dem ssh und sperrt Benutzer für eine gewisse Zeit, die ihr Passwort wiederholt falsch angegeben haben. Die IP's dieser Nutzer landen temporär in /etc/hosts.deny, so dass für sie kein Zugriff mehr möglich ist. Damit wird SSH-Bruteforcing zu einer sehr langwierigen und wenig erfolgversprechenden Aufgabe.

apt-get install denyhosts

# denyhosts funktioniert direkt nach der Installation. Man kann es
# in der Datei /etc/denyhosts.conf feintunen

4. Blacklisten benutzen, um bekannte Problem-IPs auszusperren

Im Internet werden verschiedene Blacklisten gepflegt, die eine große Anzahl von kriminellen/gehackten/spammenden/betrügerischen Servern auflisten. Diese IP-Listen können direkt in die Firewall eingetragen werden, so dass von diesen bekanntermaßen nicht vertrauenswürdigen Rechnern überhaupt keine Verbindung mehr zum eigenen Server möglich ist. So kann man das Spamaufkommen auf dem eigenen Server drastisch verringern und auch das eine oder andere Script-Kiddie aussperren, weil sein Russland-Proxy plötzlich nicht mehr funktioniert. Wie man das macht habe ich bereits in einem anderen Blog-Artikel am Beispiel der Blacklist von Infiltrated.net beschrieben.

5. Kein FTP benutzen für die Arbeit am Server

FTP ist ein Relikt aus besseren Zeiten in denen das Internet noch ein kleines vertrauenswürdiges Dörfchen war. Viele Admins von Webseiten nutzen nach wie vor FTP um Dateien zum Server zu übertragen oder um an der eigenen Website zu arbeiten. Das ist leider sehr unsicher, da FTP alle Daten ungesichert übertragt. Passwörter und Daten können an jedem Hop zwischen Server und Client ohne Probleme mitgelesen werden. Viel sicherer geht es mit sshfs. Hiermit kann man sich per SSH ein Verzeichnis des Remote-Servers in sein lokales Dateisystem mounten. Man kann danach auf dem Server so arbeiten, als sei er auf dem lokalen Rechner. Alle Dateizugriffe auf Dateien auf dem Server sind komplett transparant, man kann also auch mit dem lokalen Grafikprogramm ein Bild auf dem Server direkt öffnen, bearbeiten und wieder speichern. Mehr Komfort und mehr Sicherheit ohne großen Aufwand.

#sshfs installieren
apt-get install sshfs

#mountpoint im lokalen Dateisystem anlegen
mkdir /media/meinserver

#Server ins lokale Dateisystem mounten
sshfs www-data@mein-server.de:/var/www /media/meinserver

#Nun ist das Verzeichnis /var/www auf meinserver lokal unter /media/meinserver verfügbar

6. Updates installieren

Ein super abgesichertes System hilft nichts, wenn das System selbst fehlerhaft ist und eine bekannte Sicherheitslücke ausgenutzt werden kann. Meist werden diese Sicherheitslücken schnell geschlossen, oft vergessen Admins jedoch regelmäßige Updates des Systems zu machen. Ob man automatische Updates auf Linux-Servern aktivieren sollte oder nicht ist ein strittiges Thema. Einige würden es niemals tun, da es natürlich mit viel Pech auch sein kann, dass die Updates das System unbrauchbar machen. Dies ist mir in über 10 Jahren Arbeit an Debian-Systemen allerdings niemals passiert und ich schätze den Nutzen von zeitnahen und regelmässigen Updates viel höher ein, als die daraus entstehende Gefahr.

#Diese Zeile in der /etc/crontab aktualisiert das System täglich um 6 Uhr morgens
0 6 * * *       root    apt-get update && apt-get -y upgrade

Diese Quick-and-dirty Methode funktionierte bei mir bisher immer gut. Vor kurzem habe ich gelesen, dass im Debian Repository auch das Paket unattended-upgrades existiert, das die Aufgabe wohl etwas eleganter löst, ich habe es allerdings bisher nicht getestet.

Auch bei diesen vollautomtischen Systemupdates ist man nicht komplett aus dem Schneider. Falls ein Kernel-Update ausgeliefert wurde, muss man das System trotzdem noch per Hand neu booten, da ansonsten die Änderungen nicht aktiv werden.

Benutzt man fremden PHP-Code auf dem Server, wie zum Beispiel ein Open-Source CMS oder ein Forum, ist es natürlich absolut notwendig auch diesen Code mit neuen Versionen aktuell zu halten. Da Debian mit seinen Updates Änderungen an diesen Applikationen in der Regeln nicht abdeckt, ist hier Handarbeit nötig. Am besten liest man die Mailinglisten der entsprechenden Produkte mit um immer auf dem Laufenden zu sein.

7. PHP einsperren mit open_basedir

Viele Hacks basieren darauf, dass eine Sicherheitslücke im PHP-Code ausgenutzt wird, um auf Dateien im Dateisystem zuzugreifen, die nicht zur Website gehören, sondern zum System selbst. Deshalb sollte man PHP einsperren, so dass es nur in explizit erlaubten Verzeichnissen lesen und schreiben darf. Dafür bietet die php.ini die Konfigurationsoption open_basedir. PHP hat nach setzten der Option nur noch Zugriff auf die dort erlaubten Verzeichnisse. Dateien wie /etc/passwd werden unerreichbar. Hostet man auf einem Server mehrere Webseiten sollte man open_basedir in der jeweiligen VirtualHost-Konfiguration pro Seite setzen.

# Global per php.ini:
# /etc/php5/apache2/php.ini
open_basedir = /var/www/:/tmp/

# Per Site in der VirtualHost Config:
php_value open_basedir /var/www/site/:/tmp/

Wichtig ist zu prüfen ob wirklich alle Orte eingetragen wurden, auf die die Skripte normalerweise Zugriff haben müssen, ansonsten kann es sein, dass man auch legitime Funktionen der PHP-Applikation behindert.

8. Für Websites einen eigenen MySQL-Benutzer anlegen

Benutzt die eigene PHP-Applikation MySQL, sollte man unbedingt für die Apllikation einen eigenen MySQL-Benutzer anlegen und auf keinen Fall den MySQL-root-Benutzer für Zugriffe nutzen. Außerdem sollte man die Rechte des Benutzers so weit einschränken, dass wirklich nur noch Operationen erlaubt sind, die das PHP-Skript benötigt. CREATE TABLE und DROP TABLE werden zum Beispiel häufig bei SQL-Injections genutzt und werden in den meisten PHP-Applikationen nie benötigt. Hostet man mehrere Websites mit mehreren Datenbanken auf einem Server, sollte man für alle Datenbanken eigene Benutzer anlegen. So hat ein Angreifer nach einem erfolgreichen Angriff nur Zugriff auf eine der Datenbanken und nicht direkt auf alle. Wenn man nicht die Kommandozeile bemühen möchte, um die MySQL-Useraccounts zu verwalten, funktioniert das Usermanagement auch recht einfach mit PHPmyAdmin unter der Registerkarte "Rechte".

9. PHP Fehlermeldungen abschalten

PHP-Fehlermeldungen können einem Angreifer viel über den eigenen Server verraten: Verzeichnisstrukturen, Datenbankstrukturen, Konfigurationsfehler, etc. Außerdem sehen sie für den Benutzer sehr unprofessionell aus. Aus diesem Grund sollte man sie auf einem Live-Webserver grundsätzlich abschalten, da man sie ohnehin weiterhin in den Logs sehen kann.

# Global per php.ini:
# /etc/php5/apache2/php.ini
display_errors = Off

# Per Site in der VirtualHost Config:
php_flag display_errors Off

# Fehlermeldungen trotzdem lesen:
cat /var/log/apache2/error.log | grep PHP

10. Angriffsfläche für SQL-Injections einschränken mit modSecurity

SQL-injections sind die wohl am häufigsten genutzte Angriffsmethode auf Webserver. Der Zugriff erfolgt direkt über die Webapplikation und es genügt ein Browser um sie durchzuführen. Dabei werden über vom User übermittelte Variablen geschickt SQL-Abfragen eingebaut, die mit den Rechten des Datenbankbenutzers alles an der eigenen Datenbank nach belieben auslesen, löschen oder bearbeiten können. Ein wirklicher echter Schutz gegen SQL-Injections besteht nur, wenn der PHP-Code der Site im Hinblick auf diese Angriffe geschrieben wurde. Jede Variable aus Benutzereingaben, die in eine SQL-Abfrage gelangen könnte, muss geprüft und escaped werden. PHP bietet dafür die Funktion real_mysql_escape_string().

Ist man nicht sicher, ob der Code sauber ist, kann mod_security für den Apache helfen eine große Menge dieser Angriffe trotzdem abzuwehren. mod_security überprüft ständig alle Requests an den Webserver und reagiert auf vorgefertigte Muster mit denen viele SQL-Injection-Angriffe abgewehrt werden können. Leider funktioniert auch mod_security nur gut mit manuellem Aufwand. Oft blockt mod_security nach einer frischen Installation auch gewünschte (normale) Funktionen des eigenen PHP-Codes, so dass einem nichts anderes übrig bleibt, als die komplette Applikation nach der Installation einmal durchzutesten. Nur so findet man heraus, ob mod_security nicht eventuell auch gewünscht Funktionen blockt. Ist das der Fall, muss die Filterliste angepasst werden, so dass die false-positives verschwinden.

Die Konfiguration von mod_security ist etwas komplizierter und würde den Umfang dieses Artikels sprengen, es gibt aber massenweise gute Tutorials zu mod_security im Internet.

11. Ausweiskontrolle - Der Apache sagt nicht mehr, wer er ist
Dies ist keine wirklich wirkungsvolle Methode gegen einen Hack, sie macht es automatisierten Skripten, die nach Server-Versionen suchen aber etwas schwerer. Normalerweise zeigt der Apache auf Seiten mit Fehlermeldungen (z.B. 404 Not Found) seine Serversignatur.

Apache/2.2.16 (Debian) Server at www.daniel-ritter.de Port 80

So erhalten potentielle Angreifer zumindest schon einmal Informationen über den eigesetzten Webserver und den Versionsstand. Die Serversignatur ist schnell ausgeschaltet:

#/etc/apache2/conf.d/security
ServerSignature Off

12. Nicht benutze Apache-Module deaktivieren

Per default hat der Apache einige Module geladen, die fast nie benötigt werden. Unter Debian findet man die geladenen Module
als Softlinks in /etc/apache2/mods-enabled.

Fast immer entfernt werden können:

mod_cgi

Dient dem ausführen von CGI-Skripten. Diese Technik stammt noch aus den Urzeiten des Web und war der Vorvater der modernen Skriptsprachen um dynamische Webseiten zu ermöglichen. mod_cgi ist auf 99% der PHP-Websites unnötig und bei einer fehlerhaften Apache-Config eine potentielle Sicherheitslücke

a2dismod cgi

mod_status

Ermöglicht es Browsern Statusinformationen über den Apache auszulesen. Es wird so gut wie nie für "normale" Sites genutzt, bietet Angreifern aber Statusinformationen über den Apache.

a2dismod status

mod_autoindex

mod_autoindex sorgt dafür, dass Verzeichnisse auf dem Webserver aufgelistet werden können, wenn es keine gültige Index-Seite in dem entsprechenden Verzeichnis gibt. Falls diese Funktionalität nicht erwünscht ist, sollte man sie abschalten, da durch sie ganze Verzeichnisbäume auf dem Webserver nach aussen sichtbar werden können.

a2dismod autoindex
22Mai/100

Linux auf der PS3 – Ich habe aufgegeben :(

Nach fast einem Monat Warterei auf eine Lösung habe ich die "Anti-Linux"-Firmware installiert. Ich wollte wieder online zocken. Trotzdem kotzt es mich an.