Unter Debian und Ubuntu heisst das benötigte Paket libapache-mod-security:

apt-get install libapache-mod-security -y

Nach dem Installieren aus den Paketquellen wird eine Datei unter /etc/apache2/conf.d/modsecurity2.conf angelegt und mit folgendem Inhalt ergänzt:

<ifmodule mod_security2.c>
Include conf.d/modsecurity/*.conf
</ifmodule>

Danach werden die nötigen Ordner erstellt und verlinkt:

sudo mkdir /var/log/apache2/mod_security
sudo ln -s /var/log/apache2/mod_security/ /etc/apache2/logs

Und die aktuellsten Regeln heruntergeladen:

sudo mkdir /etc/apache2/conf.d/modsecurity
cd /etc/apache2/conf.d/modsecurity
sudo wget http://www.modsecurity.org/download/modsecurity-core-rules_2.5-1.6.1.tar.gz
sudo tar xzvf modsecurity-core-rules_2.5-1.6.1.tar.gz
rm -f CHANGELOG LICENSE README modsecurity-core-rules_2.5-1.6.1.tar.gz

Nun noch das Modul aktivieren und Apache neustarten:

sudo a2enmod mod-security
sudo /etc/init.d/apache2 restart

Und von nun an wird der Apache durch Mod_Security geschützt.
Prüfen kann man das ganz einfach! Es muss eine Datei erstellt werden, mit folgendem Inhalt:

<?
        $secret_file = $_GET['secret_file'];
        include ($secret_file);
?>

Nun ruft man die Datei auf unter http://localhost/index.php?secret_file=/etc/passwd. Erhält man anstelle der /etc/passwd Datei die folgende Ausgabe, so arbeitet mod_security richtig:

Method Not Implemented
GET to /index.php not supported.

Doch Vorsicht: mod_security ist nicht überall geeignet. So hat zum Beispiel auch mein Hoster das eingesetzt, und musste es für meinen Blog deaktivieren, dass ich all die Code-Schnipsel posten kann

Wer von euch hatte denn schon mal wirkliche Angriffe auf seinem Webserver? Konntet ihr standhalten oder seid ihr eingebrochen? Und in welcher Art lief der Angriff ab?

Das könnte dich auch interessieren:

1. Mehr Sicherheit durch OpenVPN Sicherheit wird ein immer wichtigeres Thema in der IT. Klar...
2. OpenSUSE mit ASP.NET-Unterstützung Für einen Kunden habe ich letzthin ein OpenSUSE installiert. Neben...

Mittels VPN lässt sich eine verschlüsselte Verbindung zwischen zwei Parteien aufbauen. Sehr zu empfehlen in öffentlichen WLANs und anderen frei zugänglichen Netzwerken.
Zur Verfügung stehen Site-to-Site, Site-to-End und End-to-End:

Die Installation von OpenVPN ist eigentlich denkbar einfach. Ich verwende dazu einen Debian- und einen Fedora-Client.

Beginnen wir mit Debian bei der Installation:

apt-get install openvpn

Nun legen wir einen neuen Key an, mit dem sich beide Seiten authentifizieren können:

openvpn --genkey --secret /etc/openvpn/static.key

Diesen muss natürlich auch noch auf dem Client übertragen werden:

scp static.key client:/etc/openvpn/

Nun legen wir eine Konfigurationsdatei an für Debian, welches die Rolle des Servers übernehmen wird:

root@server:/etc/openvpn# cat tun0.conf
dev tun0
ifconfig 10.9.8.1 10.9.8.2
secret static.key

Auch auf dem Client muss eine Konfigration eingerichtet werden:

root@client openvpn# cat tun0.conf
remote 10.128.101.26
dev tun0
ifconfig 10.9.8.2 10.9.8.1
secret static.key

Wenn man nun einen Blick in ifconfig wirft, so sieht man, dass ein neues Interface dazugekommen ist. Auf dem Server sieht das dann so aus:

root@server:/etc/openvpn# ifconfig tun0
tun0      Link encap:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet Adresse:10.9.8.1  P-z-P:10.9.8.2  Maske:255.255.255.255
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1500  Metrik:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:100
          RX bytes:168 (168.0 B)  TX bytes:168 (168.0 B)

Auf dem Client wiederum so:

root@client openvpn# ifconfig tun0
tun0      Link encap:UNSPEC  Hardware Adresse 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet Adresse:10.9.8.2  P-z-P:10.9.8.1  Maske:255.255.255.255
          UP PUNKTZUPUNKT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          Kollisionen:0 Sendewarteschlangenlänge:100
          RX bytes:168 (168.0 b)  TX bytes:168 (168.0 b)

Will man nun prüfen, dass alles läuft, so kann man die jeweilige Gegenseite pingen. Sind die Tunnel korrekt aufgebaut, so geht das ohne Probleme.

Das könnte dich auch interessieren:

1. Dynamic Host Configuration Protocol Ein anderer Bestandteil von LPIC 201 ist DHCP. Doch bevor...

Und hier liegt das grösste Problem: Wenn nun jemand böse Absichten hat, so kann er seinen Schadcode gut getarnt dem Projektteam vorlegen und darauf hoffen, das dieser aufgenommen wird.
Kommt der Schadcode durch, so hätte ein Angreifer jederzeit Zugriff auf Daten oder andere Informationen. In einem kleinen, unbekannten Projekt ist das zwar schrecklich, die Konsequenten sind aber nicht weiter verheerend.
Doch was nun, wenn es anstelle von einer unbedeutenden Software ein verbreitetes Projekt wie WordPress, Ubuntu, Typo3 oder Nagios betroffen ist… Somit hätte ein Angreifer Zugriff zu tausenden und abertausenden Systeme, Server oder Webseiten und Webappliaktionen! Nicht auszumalen, wie verheerend die Konsequenten wären…

Und, man glaub es kaum, ganz so abwegig ist das ganze nicht! Heute wurde in der OpenBSD-Nachrichtenliste ein erschreckendes eMail veröffentlicht:

Long time no talk. If you will recall, a while back I was the CTO at
NETSEC and arranged funding and donations for the OpenBSD Crypto
Framework. At that same time I also did some consulting for the FBI,
for their GSA Technical Support Center, which was a cryptologic
reverse engineering project aimed at backdooring and implementing key
escrow mechanisms for smart card and other hardware-based computing
technologies.

My NDA with the FBI has recently expired, and I wanted to make you
aware of the fact that the FBI implemented a number of backdoors and
side channel key leaking mechanisms into the OCF, for the express
purpose of monitoring the site to site VPN encryption system
implemented by EOUSA, the parent organization to the FBI. Jason
Wright and several other developers were responsible for those
backdoors, and you would be well advised to review any and all code
commits by Wright as well as the other developers he worked with
originating from NETSEC.

This is also probably the reason why you lost your DARPA funding, they
more than likely caught wind of the fact that those backdoors were
present and didn’t want to create any derivative products based upon
the same.

This is also why several inside FBI folks have been recently
advocating the use of OpenBSD for VPN and firewalling implementations
in virtualized environments, for example Scott Lowe is a well
respected author in virtualization circles who also happens top be on
the FBI payroll, and who has also recently published several tutorials
for the use of OpenBSD VMs in enterprise VMware vSphere deployments.

Das eMail von Gregory Perry beschreibt sein Geständnis, wie er vor 10 Jahren Geld von der US-Regierung, genauer dem FBI angenommen hatte und dafür mehrere Backdoor in OpenBSD mit einprogrammiert hatte…

Glücklicherweise sind die Auswirkungen laut Gregory Perry nach 10 Jahren nicht mehr ganz so verheerend:

Since we had the first IPSEC stack available for free, large parts of
the code are now found in many other projects/products. Over 10
years, the IPSEC code has gone through many changes and fixes, so it
is unclear what the true impact of these allegations are.

Wenn die US-Regierung für OpenBSD Geld springen liess, in wie vielen anderen Opensource-Projekten haben die denn sonst noch mitgemischt?!

Dabei habe ich mir mal wieder einige Gedanken über mein eigenes Passwort-Management Gedanken gemacht, und gemerkt, dass ich mich selbst nicht an alle Empfehlungen wie regelmässiges Ändern von Passwörtern, unterschiedliche Passwörter für unterschiedliche Konten und Dienste und ähnliches halte.

Nun wollte ich mal in die Runde fragen wie ihr denn das so handhabt?

Benutzt ihr ein Tool wie zum Beispiel den Schlüsselbund von Gnome? Oder ist bei eurem Benutzerpasswort ein Ablaufdatum gesetzt? Ändert ihr eure Passwörter überhaupt noch?

Wählt folgend die Optionen aus, welche euren Passwortalltag am besten beschreiben (mehrere Antworten möglich):

Und wer noch mehr zu sagen hat, der kann alles auch in einem Kommentar beschreiben.

Hier eine kurze Kostprobe:

Nun gilt es für den Angreifer darauf zu warten, bis das Opfer den A-Record von gmail.com abfragt. Sehen wir nun in unserem mitgehörten Traffic eine solche Anfrage, so muss das Antwortpaket soweit verändert werden, dass anstatt die tatsächliche IP-Adresse nun die IP-Adresse zu unserer präparierten Seite übermittelt wird.
Das Opfer selbst empfängt und akzeptiert das so, weil es selbst von der Veränderung nichts mitbekommt. Alle Anfragen, welche das Opfer von nun an an Gmail macht, werden nicht an Gmail selbst, sondern an unsere präparierte Seite gesandt, womit unser Vorhaben erfüllt wäre.

Wer meinen Artikel komplett lesen möchte, der kann sich das Magazin als PDF auf der Webseite herunterladen.

Und auch in den nächsten paar Ausgaben wird es nicht abklingen. So wurde ich für die Dezember-Ausgabe bereits für einen Artikel zum Thema “Passwort Cracking” angefragt, an welchem ich zur Zeit schreibe.
Ihr könnt euch also freuen

Die aufgebaute Session wird dabei im Normalfall anhand einer ID überprüft. Wenn nun aber ein Angreifer diese ID weiss, so kann er problemlos die bereits autorisierte Session übernehmen und darin interagieren.

Die meisten werden das Problem nun bereits erkannt haben; geht diese Autorisierung ohne Verschlüsselung von statten, so kann jeder der im gleichen Netzwerk sitzt und “hinhört”, die Session-ID abfangen und für seine eigenen Zwecke missbrauchen.

Auf der Toorcon 12 hatte Eric Butler einen Vortrag gehalten, worin er sein Firefox-Plugin firesheep vorstellt. Dieses hat zum Zweck, im aktuellen Netzwerk nach Session-IDs von Facebook, Twitter und anderen unverschlüsselten Webdiensten Ausschau zu halten und diese bei einem Treffer zu speichern.
Ganz nett dabei, die gefundenen Session werden direkt mit dem Anzeigebild vom jeweiligen Dienst ergänzt und können mit einem Doppelklick übernommen werden.

Eric möchte damit aufzeigen, wie gefährlich es ist, wenn man unverschlüsselte Seiten ansurft und bewirken, dass die Betreiber von Webdiensten ihre Webseiten endlich auf SSL umstellen.

Wie das Plugin im Detail funktioniert, kann in seiner Präsentation nachgelesen werden.

Das Plugin gibt es zur Zeit für Mac und Windows, eine Linux-Version ist laut dem Autor in Arbeit. Damit das Plugin auch problemlos läuft muss vorher aber noch Winpcap installiert werden.

Bereits im Frühling des letzten Jahres habe ich am SCSII teilgenommen und mich an den teils einfachen, teils schwierigeren Wargames versucht. Auch die vereinzelten Vorträge zwischendurch waren sehr informativ.

So war für mich klar, ich werde auch am SCSIII teilnehmen und habe es schon fix in meine Agenda eingetragen.

Vor kurzem bin ich nun über die offizielle Seite der Veranstaltung gestolpert und habe da ein bisschen rumgestöbert. Die gesamte Konferenz wurde nun von einem Wochenende auf 4 Tage erweitert und alles wurde im grossen Rahmen aufgezogen.

Nun aber, ich wollte zuerst meinen Augen nicht trauen, habe ich gelesen, der Eintritt an die Konferenz kostet nun 740.- SFr. Was im Gegensatz zu den 20.- SFr. für letzte Jahr eine unglaubliche Steigerung ist!

Und für mich persönlich ist das auch ein Grund, weshalb ich am SCSIII nicht dabei sein werde, da ich es mir schlicht und einfach nicht mehr leisten kann will. Klar geht nun alles 4 Tage, es gibt mehr Speaker und alles wurde in einem grösseren Rahmen aufgezogen. Doch das wäre ja überhaupt nicht nötig! Und überhaupt, rechtfertigt das nie eine Preissteigerung von schlappen 3700%…

Ich finde es sehr schade, dass man auch den Swiss Cyber Storm von einer einfachen, informativen und lehrreichen Veranstaltung zu einer kommerziellen, gewinnorientierten Nobelkonferenz verkommen lies!

Wer den Artikel lesen möchte, kann diesen hier herunterladen.

This codelab shows how web application vulnerabilities can be exploited and how to defend against these attacks. The best way to learn things is by doing, so you’ll get a chance to do some real penetration testing, actually exploiting a real application.

Für alle die, welche dem Englisch nicht so mächtig sind: Jarlsberg ist eine Webapplikation von Google zum Thema Web Application Security. Basierend auf Python wird jedem Benutzer in einer eigenen Session eine Webseite präsentiert voll mit Sicherheitslücken von XSS über DOS bis hin zu XSRF und Path Traversal.

Neben dieser Webseite gibt es auch noch eine sehr ausführliche und gut erklärte Dokumentation zu jedem Exploit mit einer Erklärung wie man diesen auch beheben könnte (verfasst in Englisch).
Nachdem ich die Dokumentation nun mal komplett durchgearbeitet habe, muss ich sagen, es lohnt sich wirklich die 5 Seiten komplett zu lesen!
Jedoch muss ich auch sagen, in meinen Augen sind ein paar der vorgestellten Exploits ein wenig Realitätsfremd, da man z.B bei einem Pentest nur sehr wenig direkten Zugang zum Sourcecode hat.

Nichts desto trotz, wer es selbst mal ausprobieren will, und das kann ich wirklich jedem empfehlen, der klickt nun hier:

Doch interessanter als das Protokoll ist was man damit machen kann
Ist in einem Netzwerk ARP freigegeben (was auch häufig der Fall ist), so kann man dies in Kombination mit einem Switch zu einer Man-in-the-Middle-Attacke verwenden.

Doch von vorne! Es gibt zwei “Probleme”:
Problem 1…
Der Client führt eine Cache, wo er eine IP- einer MAC-Adresse zuordnet. Dies wird verwendet, dass nicht vor dem Versenden eines Datenpaketes jedes mal zuerst noch eine neue Abfrage der MAC-Adresse gemacht werden muss.
Dieser Cache kann aber von einem anderen Client mit den nötigen Mitteln verändert werden. D.h. ich als Angreifer kann den Cache des Opfers so verändern, dass der IP-Adresse eines z.B. gerade eben besuchten Servers nicht mehr die tatsächliche MAC-Adresse des Servers, sondern eine beliebige zugeordnet wird.

Das alleine wäre ja noch nicht so schlimm, wäre da nicht noch Problem 2…
Hier kommt dann der Switch ins Spiel. Ein Switch hat gegenüber einem Hub einen grossen Unterschied. Ein Hub sendet den Traffic von einem Port einfach an alle anderen aktiven Ports, in der Hoffnung, dass nur derjenige den Traffic liest, welcher ihn auch angefragt hat.
Der Switch hingegen; damit der Traffic nicht jedes mal an alle Ports versandt werden muss, führt eine Zuordnungsliste, wo festgelegt wird, welches Gerät (anhand der MAC-Adresse) an welchem Port angeschlossen ist.

Auch Problem 2 wäre alleine kein Problem, doch zusammen!!
Ein Angreifer manipuliert den Cache eines Clients nun so, das die IP-Adresse des Server nicht mehr der MAC-Adresse des Server, sondern der des Angreifers zugeordnet ist.
Da der Client davon nichts mitbekommt, nimmt er die MAC-Adresse des Angreifers aus seinem Cache, in der Meinung es wäre die Adresse des Servers und schickt diese mit seinem Datenpaket zum Switch.
Der Switch nun liest die MAC-Adresse aus und erkennt die MAC-Adresse des Angreifers. Beim Vergleich mit seiner Zuordnungsliste wird das ganze Paket nun nicht mehr an den Switchport des Servers, sondern an den des Angreifers versandt.
Macht der Angreifer das gleiche nun auch noch mit dem Server, so kann er jeden Traffic zwischen einem Client und einem Server mitlesen und beliebig manipulieren.

Man sagt ja, in der Theorie ist es meistens einfacher, als in der Praxis. Das Problem von ARP Spoofing ist aber, dass dies hier nicht stimmt!!
Mit nur wenigen Klicks und einem Paket aus den Ubuntu Paketquellen lässt sich mittels ARP Spoofing eine komplette Man-in-the-Middle-Attacke durchführen.
Wie genau – das soll jeder alleine herausfinden, doch das Paket dsniff könnte helfen