Sicherheit

6. Bremer IT-Sicherheitstag

IT-Sicherheit – Auf dem Stand der Technik

Das Gesetz zur Erhöhung der Sicherheit informationstechnischer Systeme (ITSiG) und die Folgen

 Die Sicherheit von Informationen sowie der Schutz von Daten gewinnen immer mehr an Wichtigkeit. Das Gesetz zur Erhöhung der Sicherheit informationstechnischer Systeme (ITSiG) schreibt Betreibern von kritischen Infrastrukturen (KTITIS) sowie jedem Unternehmen, das eine Website unterhält vor, angemessene organisatorische und technische Vorkehrungen nach dem „Stand der Technik” (SdT) zum Schutz ihrer informationstechnischer Systemen hinsichtlich Verfügbarkeit, Integrität, Authentizität und Vertraulichkeit zu treffen. Dies stellt Unternehmen vor neue Herausforderungen und führt bei vielen, auf Grund des vom Gesetzgeber unbestimmten Rechtsbegriffs „Stands der Technik“, zu Unklarheit und Unsicherheit.
Auf dem 6. Bremer IT-Sicherheitstag geben Ihnen unsere Spezialisten Orientierung. Sie beleuchten das ITSiG, präzisieren anhand ausgewählter Szenarien den “Stand der Technik” und liefern Anregungen für die Umsetzung in der Praxis.

Neue Zertifikate nach Bekanntwerden der Heartbleed Lücke

Veröffentlicht am von Matthias Wulkow

heartbleedNach Bekanntwerden der Heartbleed Sicherheitslücke hat SaaS Web schnellstmöglich reagiert und alle Zertifikate erneuert. Leider handelt sich bei der Lücke um eine bereits seit 2 Jahren existierende Fehlfunktion, die vermutlich systematisch ausgenutzt wurde, um verschlüsselte Datenverbindungen auszuspionieren. Der Aufwand dafür ist nicht gerade gering, sodass auszugehen ist, dass eher größere Organisationen wie Spionage- und Nachrichtendienste diese Lücke ausnutzten.

Weitere Informationen zu dem Heartbleed Bug finden Sie u. a. hier: Heise Artikel und FAZ Artikel.

WordPress: Auf der sicheren Seite mit SaaS Web

Veröffentlicht am von Matthias Wulkow

WordPress LogoEine im Juni erschienene Studie zur Sicherheit der meistgenutzten Content Management Systemen stellt fest, dass 80% der Einbrüche auf WordPress Systeme auf das Konto der PlugIns zu buchen ist, hauptsächlich aufgrund veralteter Versionen. Lediglich 20% sind auf das Core zurückzuführen. Aktuell berichtet Heise über großangelegte Phishingversuche auf WordPress Installationen.

SaaS Hosting mit SaaS Web: SaaS Web bietet den Rundum Service für das gehostete CMS: Monitoring, Backups und Updates/Upgrades. So braucht sich der Kunde keine Gedanken zu machen, ist aber dennoch gut bedient! Ein weiterer Vorteil für den Kunden liegt auf der Hand: mehr Zeit für das Wesentliche!

Populäre Content Management Systeme vs. Sicherheit (WordPress, TYPO3, …)

Veröffentlicht am von Matthias Wulkow

BSI-LogoDie Sicherheit der meistgenutzten Web-CMS auf dem Prüfstand.

Die untersuchten Content Management Systeme sind: Drupal, Joomla!, Plone, TYPO3 und WordPress. Die Ergebnisse sind in den verschiedenen Angriffsmethoden unterteilt wie z. B. SQL Injection oder XSS (Cross-Site-Scripting).

Darstellung_Schwachstellentypen

Allgemein geht aus der Studie hervor, dass die Anwendungen recht sicher und die Update-Prozesse der Hersteller gut sind. Die Autoren empfehlen schließlich die Standardkonfiguration der eingesezten CMS anzupassen (z. B. Admin-Login ändern) und automatisiert Updates einzuspielen.

Hier können Sie die gesamte Studie runterladen.

SaaS Web setzt nun auf Dedicated Private Cloud Infrastruktur

Veröffentlicht am von Matthias Wulkow

SaaS Web LogoSchon immer hat SaaS Web Skarlierbarkeit und hohe Erreichbarkeit mittels Virtaulisierung als Fokus gehabt.

Jetzt geht es eine Stufe nach oben: die Infrastruktur wird nach und nach auf VMware vSphere umgezogen und damit eine eigene Dedicated Private Cloud geschaffen. Die Außenanbindung beträgt 10 Gbit/s (redundant ausgelegt). Die Datastores sind ebenfalls redundant gehostet.

Die neue Hosting Plattform soll eine deutlich höhere Sicherheit bieten, sowohl in Bezug auf die Erreichbarkeit bei Lastspitzen als auch nach Ausfällen. Die Erreichbarkeit beträgt nun 99,99% im Jahresdurchschnitt.

Die gewonnene Flexibilität ist enorm, das System kann innerhalb weniger Minuten um das 100-fache an Kapazität erweitert werden (CPU/RAM/Storage); So können auch populäre/medienwirksame Webprojekte mühelos bedient werden.

Wie kann man automatisch verschlüsselte MySQL-Dumps erzeugen?

Veröffentlicht am von

Jeder weiß, dass Backups wichtig sind — sei es ein Systemausfall oder man möchte einfach auf einen älteren Stand zurückgreifen, weil man einen Fehler gemacht hat.
Oft werden die Sicherungen durch Cron-Jobs erledigt. In den meisten Fällen jedoch wird ein einfacher Mysql-Dump erzeugt, ohne den Inhalt zu verschlüsseln.
In diesem Artikel beschreibe ich, wie man mit Hilfe von GPG Backups erstellen kann, ohne ein festgelegtes Passwort zu verwenden. Da es mehrere DB-Admins geben kann, die die Backups zurückspielen können, sollte jeder Admin, der berechtigt ist, mit seinem eigenen Passphrase das Backup wieder zurückspielen können.

#!/bin/bash

BACKUP_DIR=/var/backup/auto/mysql
DATE=$(date -I)
TARGET_DIR=$BACKUP_DIR/$DATE
mkdir -p $TARGET_DIR

DATABASES=$(mysql -uadmin -B -s -e“show databases;“)

for db in $DATABASES; do
TARGET=$TARGET_DIR/$db.sql.gz.gpg
echo -n dumping $db to $TARGET …
mysqldump -uadmin $db | gzip | gpg -rCAFEBABE -rAFFE4711 -rAFFEFACE -e – > $TARGET
if [ $PIPESTATUS -eq 0 ]; then echo OK; else echo ERROR; fi
done

Die Variable BACKUP_DIR gibt an, wo die Backups abgelegt werden sollen. Darunter wird ein Verzeichnis mit dem Datum in Form von JJJJ.MM.TT (date -I) angelegt, in dem die Dumps einzelner Datenbanken landen. Wer mehr als ein Backup pro Tag erzeugen will, kann dann diesen Befehl anpassen.

Beispielausgabe:

…
dumping mysql to /var/backup/auto/mysql/2012-04-06/mysql.sql.gz.gpg …OK
dumping test to /var/backup/auto/mysql/2012-04-06/test.sql.gz.gpg …OK
…

Was man bei diesem Script anpassen muss, sind die KEY/IDs der Empfänger, also wer die Daten später entschlüsseln darf. In diesem Beispiel sind drei Empfänger angegeben:

gpg -rCAFEBABE -rAFFE4711 -rAFFEFACE

Jeder Empfänger hat die Möglichkeit die Backupdateien zu entschlüsseln. GPG ermittelt den Key für den „Entschlüssler“ automatisch:

gpg -d mysql/2012-04-06/test.sql.gz.gpg | gunzip | head -n 5

You need a passphrase to unlock the secret key for
user: „XZY“
2048-bit ELG-E key, ID AFFEFACE, created…
Enter passphrase:

gpg: encrypted with 2048-bit RSA key, ID CAFEBABE…
gpg: encrypted with 2048-bit ELG-E key, ID AFFE4711…
gpg: encrypted with 2048-bit ELG-E key, ID AFFEFACE…

Die eigentliche Ausgabe erscheint dann in STDOUT:

-- MySQL dump 10.13 Distrib 5.1.56, for redhat-linux-gnu (x86_64)
--
-- Host: localhost Database: test
-- ------------------------------------------------------
-- Server version 5.1.56

Wer noch nicht viel mit GnuPG und MySQL-CLI zu tun hatte, sollte noch folgende Punkte beachten, bevor man das Beispiel ausführt:
– Keys aller Empfänger sollten vorher signiert/trusted sein, damit das Backup-Script nicht in den Interaktiv-Modus gerät
– Das Passwort für den Datenbankzugriff ist standardmäßig in der Datei ~/.my.cnf in der [client]-Sektion definiert

Viel Spaß beim Testen und Einbauen
C.