Exchange 2003/2007, Spam, postfix, Debian, DNS

Mittels Webdav ist es möglich, Dateien auf einen Webserver zu schreiben. Diese Option nutzen einige Programme/Add-Ons wie Thunderbird Lightning und Reminderfox z.B. um eine Synchronisierung ihrer Daten zwischen verschiedenen Computer zu ermöglichen.Aktivieren lässt sich Webdav relativ leicht. Vorraussetzung ist, dass bereits ein Webserver installiert ist und auch mind. eine Domain existiert.

Als erstes müssen die Module für Webdav aktiviert werden:

a2enmod dav_fs

a2enmod dav

Nun wird das Verzeichniss erstellt, über welches per Webdav Dateien ausgetauscht werden:

mkdir /var/kunden/webs/cscholz/o-o-s.de/webdav

chown www-data:www-data /var/kunden/webs/cscholz/o-o-s.de/webdav

Je nachdem welche Authentifizierungsmethode man verwenden möchte, sind jetzt zwei Unterschiedliche Konfigurationswege notwendig. Einmal kann die Basic Authentifizierung oder Digest verwendet werden. Bei Digest gibt es einen Part “AuthName”, der zum Beispiel von ReminderFox nicht richtig ausgewertet/angegeben werden kann, dementsprechend arbeitet ReminderFox leider nicht mit der Digest Authentifizierung zusammen.

Digest-Authentifizierung

a2enmod auth_digest

htdigest -c /etc/apache/webdav-digest webdav-example username

Nun muss in der Domain Konfiguration ein Abschnitt für die Webdav Konfiguration eingerichtet werden.

<Location /webdav>
DAV On
Options +Indexes
AuthType Digest
AuthName "webdav-example"
AuthUserFile /etc/apache2/webdav-digest
Require valid-user
</Location>

+Index macht finde ich Sinn, damit man per Browser zumindest den Inhalt des Verzeichnisses sehen kann.

Basic Authentifizierung

htpasswd -c /etc/apache2/webdav cscholz

Nun muss in der Domain Konfiguration ein Abschnitt für die Webdav Konfiguration eingerichtet werden.

<Location /webdav>
DAV on
Options +Indexes
AuthType Basic
AuthName DAV
AuthUserFile /etc/apache2/webdav
Require valid-user
</Location>

Testen, egal mit welcher Authentifizierung

Abschließend sollte die Apache2 Konfiguration getestet werden,

apache2ctl configtest

bevor der apache2 Server neu gestartet wird.

/etc/init.d/apache2 restart

Testen des Webdav Zugriffs per Shell

Es ist auch möglich, den Zugriff per Shell zu testen.

aptitude install cadaver

Authentication required for DAV on server `o-o-s.de':
Username: cscholz
Password:
dav:/webdav/>

Man kann einen Webserver nicht nur mittels DDos Attacken lahm legen, sondern auch durch die Entgegengesetzte Methode. Der Angreifer baut nach und nach Verbindungen zum Zielserver auf und sendet genau so oft Daten, dass die Verbindungen nicht in einen Timeout laufen. Nach und nach ist es so möglich, mit relativ wenig Ressourcen die verfügbaren Verbindungen des Zielservers zu binden.

Für genau dieses Problem gibt es ein Module für Apache2 namens qos. Mit ihm lassen sich aber einer gewissen Verbindungsnutzung Verbindungen beenden über die zu wenig Traffic läuft. Durch das freigeben der Verbindungen ist der Server wieder für echte Anfragen verfügbar.

Das Modul ist leider nicht von Hause aus dabei, daher muss es nachträglich compiliert werden.

apt-get install apache2-threaded-dev gcc
cd /usr/src
wget http://downloads.sourceforge.net/project/mod-qos/9.17/mod_qos-9.17.tar.gz
tar zxvf mod_qos-*.tar.gz
cd mod_qos-*/apache2
apxs2 -i -c mod_qos.c
cd /etc/apache2/mods-available/
wget http://o-o-s.de/wp-content/uploads/2010/05/qos.conf
echo "LoadModule qos_module /usr/lib/apache2/modules/mod_qos.so" > qos.load
a2enmod qos
/etc/init.d/apache2 restart

Der Schutz eines Webservers hängt schon seit langem nicht mehr nur von einem funktionierenden klassischem Paketfilter ab. Auf Webservern laufen im Zeitalter des Web 2.0 immer mehr dynamische Inhalte, die doch hin und wieder den ein oder anderen Bug enthalten. Netzwerk- (OSI-Schicht 3) und Transsportschicht (OSI-Schicht 4) Firewalls helfen hier nicht mehr weiter, da diese Verbindungsspezifische Kriterien anlegen um den Zugriff auf ein System zu erlauben oder zu verweigern. Genau an dieser Stelle greif ModSecurity ein. ModSecurity ist eine Web Application Firewall (WAF) die den Datenstrom auf der HTTP Ebene (OSI-Schicht 7) analysiert und somit die Anfragen des Clients sowie die Antworten des Servers Inhaltstechnisch überwachen kann.

Somit ist es möglich ein System mittels ModSecurity vor bekannten Schwachstellen einer Webapplikation zu schützen noch bevor der Patch dafür erschienen ist. Mithilfe von ModSecurity kann ebenfalls sichergestellt werden, dass bestimmte Dateien des Betriebssystems das System niemals per HTTP (Apache2) verlassen. Hier ein Beispiel dafür.

ModSecurity wurde ursprünglich von Ivan Ristic entwickelt. Inzwischen treibt jedoch das Unternehmen Breach Security die Entwicklung vorran. Die aktuelle Version 2.5.11 ist nur noch für Apacke 2.x verfügbar.

ModSecurity unterscheidet bei einer HTTP(s) Anfrage 5 verschiedene Phasen in denen der Datenstrom untersucht werden kann.

1. REQUEST_HEADERS
   Frühest mögliche Filterung, noch bevor der Webserver den Zugriff anhand von Zugriffskontrollen erlaubt oder geblockt hat.
2. REQUEST_BODY
   ermöglicht die vollständige Überprüfung der Clientanfrage
3. RESPONSE_HEADERS
   Filterung der Serverantwort
4. RESPONSE_BODY
   Vollständige Prüfung der gesamten Serverantwort
5. LOGGING
   Zugriff auf Logging Informationen bevor Apache diese in seinen Log-Dateien vermerkt.

Eine detallierte Beschreibung der Konfigurationsparameter von ModSecurity finden Sie hier.

Installation

Da ModSecurity leiter nicht in den stable Repositories von Debian enthalten ist gibt es nur die Möglichkeit die Version selber zu kompilieren oder auf im Internet vorhandene Pakete zurück zu greifen. Wer jedoch bereits sid einsetzt, findet die Pakete libapache-mod-security mod-security-common jedoch in seinen Repositories.

wget http://etc.inittab.org/~agi/debian/libapache-mod-security2/mod-security-common_2.5.9-1_all.deb

wget http://etc.inittab.org/~agi/debian/libapache-mod-security2/libapache-mod-security_2.5.9-1_i386.deb

dpkg -i libapache-mod-security_2.5.9-1_i386.deb mod-security-common_2.5.9-1_all.deb

Weiterlesen