Schlagwort-Archiv: Security

Mehr Sicherheit durch mod_security

Mod_Security ist eine Software Firewall, welche kontrolliert, welche Eingaben auf einem Apache gemacht und was für Daten übermittelt werden. Diese werden dann mit einer Handvoll Regeln verglichen, wodurch schädliche Abfragen erkannt und geblockt werden.

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?

Mehr Sicherheit durch OpenVPN

Sicherheit wird ein immer wichtigeres Thema in der IT. Klar war es auch schon vor Jahren wichtig, jedoch bei weitem nicht so stark diskutiert, wie es das heute ist.
Das Problem von IT-Sicherheit: Auch das stärkste Glied ist nur so stark wie das Schwächste!
Es bringt mir also die beste Verschlüsselung nichts, wenn mein Gegenüber diese nicht auch verarbeiten und entschlüsseln kann. Oder ein Client kann noch so gut gesichert, gepatcht und geschützt sein, wenn das angeschlossene Netzwerk unverschlüsselt und für jeden Lesbar ist. Und damit möchte ich auch gleich übergehen zum Thema VPN.

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.

Weiterlesen

Schlechter Code für Opensource

Das Prinzip von Opensource ist altbekannt. Der Code einer Software ist offen verfügbar, und jeder der will, kann Änderungen daran hinzufügen und wieder einchecken.

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?!

Gedanken zur Passwortverwaltung

Soeben habe ich einen Artikel zum Thema Passwort Cracking für das IT-Sicherheitsmagazin Hakin9 fertiggestellt. Dieser wird voraussichtlich in der nächsten Ausgabe zu lesen sein.

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):

Wie sieht euer Passwort-Management aus?

Ergebnisse

Loading ... Loading ...

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