it-sicherheitsblog.de

Viele Mythen ranken sich um die Sicherheit von Mac OS X. Manche behaupten, ein Mac OS X wäre ein offenes Scheunentor für jede Form von Angreifern. Andere hingegen fühlen sich mit ihrem Mac so sicher wie im sprichwörtlichen Schoß der Mutter. Tatsache ist jedoch, dass ein Mac genauso sicher oder unsicher ist wie jedes andere Windows oder Linux auch. So sind zwar bisher keine sich selbst verbreitenden Schadprogramme für den Mac in freier Wildbahn aufgetreten, das führt aber dazu, dass manch ein Nutzer allzu achtlos Software aus Fremdquellen installiert. Mit einer gehörigen Portion Nachdenken und Vorsicht lassen sich die meisten Risiken umgehen. Trotzdem sollte ein Mac vor Gebrauch gründlich abgesichert werden, um die Risiken zu minimieren. Mit der verlinkten Mac-Sicherheits-Checkliste können Sie schnell prüfen, ob Sie die wichtigsten Sicherheitsmaßnahmen ergriffen haben.

http://www.great-oak.de/unternehmen/veroeffentlichungen

Da eine funktionierende Datensicherung einer der wichtigsten Aspekte einer sicheren IT ist, wollte ich kein Risiko eingehen und habe nach dem Update auf Snow Leopard beim Apple Support angerufen.

Die Ausgangssituation sieht wie folgt aus:
Auf meinem Mac setze ich FileVault zur Verschlüsselung des Homeverzeichnisses ein, gleichzeitig benutze ich Time Machine für ein regelmäßiges Backup. Unter Leopard (Mac OS x 1.5) war es für ein Backup des Homeverzeichnisses notwendig, sich auszuloggen, damit er den verschlüsselten Container des Homeverzeichnisses 1:1 auf das Backupmedium kopieren konnte.

Nachdem ich die ersten 1,40 Euro in der Warteschlange gelassen hatte, wurde ich von einem Applemitarbeiter begrüßt, der sich meines Problems annehmen wollte. Leider hat er erst nach 4 Anläufen verstanden, dass ich nicht Firewall sondern FileVault meine. Das Ganze hat er dann versucht simultan in einen englischen Text zu verwandeln (…while he use Time Machine and also FileVault he ask if he backup the data he have to log out or not for good backup…. mehr konnte ich auf die Schnelle nicht mitschreiben) und mich gebeten noch 5 Minuten in der Warteschlange auf eine Antwort zu warten. Es wurden 9 Minuten, also wieder 1,26 Euro weg.

Die Antwort lautete dann, er habe sich bei seinen Kollegen erkundigt und man müsse sich nicht ausloggen, um ein Backup seines Home-Verzeichnisses zu bekommen. Aber ganz abgesehen davon, sowohl er als auch seine Kollegen würden mir dringend raten, auf FileVault zu verzichten. Auf meine zaghafte Frage nach dem Warum, folgte die Antwort sogleich. Da bei Verlust des Passwortes alle Daten definitiv weg wären sollten höchsten Leute vom BND oder so das einsetzen. Nach dem ich ihn beruhigt hatte, dass ich genau diese Funktion zu schätzen wüsste, entließ er mich mit den weisen Worten, dass ich ja dann das Risiko alleine tragen würde.

Auf Grund dieser umwerfenden Kompetenz habe ich beschlossen die Sache mit dem Backup zu testen. Mit dem ziemlich eindeutigen Ergebnis, dass die Aussage vom Support falsch war! Er sichert zwar die Systemdaten während man eingeloggt ist, das Homeverzeichnis jedoch nicht. Wenn man sich also darauf verlässt, steht man im Schadensfall sehr dumm dar.

Zusammenfassung:

Snow Leopard sichert ein verschlüsseltes Homeverzeichnis nach wie vor nur nach dem Ausloggen und dann als verschlüsselten Container auf das Medium. Der Container lässt sich z.B. unter Leopard einfach in Dateisystem einhängen und nach der Passworteingabe nutzen.

Wie versprochen, heute der zweite Teil zum Website-Backup. Meine Lösung hier ist einfach: die Dateien packen und per FTP wegsichern. Sie müssen das Perl-Skript noch etwas anpassen, also Ihren FTP-Server, Benutzernamen, Passwort und vor das allem das Verzeichnis, das auf dem Webserver gesichert werden soll, eintragen. Fragen, Fehlersichtungen und Anregungen bitte wie immer in den Kommentaren hinterlassen. Bitte haben Sie Verständnis dafür, dass ich keine Gewähr dafür übernehme, dass das Skript und das Backup daraus fehlerfrei funktioniert und nicht z.B. Ihre Daten vernichtet. Wenn Sie es einsetzen, dann auf eigenes Risiko! Und überprüfen Sie bitte auch regelmäßig, ob die gepackten Dateien funktionsfähig sind.
Nachdem Sie das Skript angelegt und gespeichert haben (z.B. vi backup.pl), müssen Sie die Rechte noch auf “ausführbar” setzen. (z.B. chmod 755 backup.pl)

Binden Sie schließlich das Skript als Cron-Job ein (siehe Teil 1) und schon haben ein automatisches Backup.

#!/usr/bin/perl

#Modul FTP einbinden

use Net::FTP;

#Variablen festlegen, die das Datum erzeugen

($day, $month, $year) = (localtime)[3,4,5];

#Namen für das Backup-Verzeichnis festlegen (hier z.B.: backup_09-08-14 )

$backupDir = “backup_$year-$month-$day”;

#Consolen-Befehl tar ausführen und die Datei backup.tar.gz erzeugen. Passen Sie noch den Pfad an, den Sie sichern möchten (z.B. /srv/www/htdocs)

open(CONSOLE, “tar cvzf backup.tar.gz /ihr/zu/sicherndes/Verzeichnis/ |”);

while (<CONSOLE>)

{

#warten bis tar fertig ist

}

#Console schließen

close(CONSOLE);

#FTP-Verbindung auf den Server

$ftp = Net::FTP->new(“ihr-ftp-server.de”, Debug => 1)

or die “Kann nicht mit Host verbinden: $@”;

#Login-Daten auf den FTP-Server

$ftp->login(“Benutzername”, “Passwort”)

or die “Login gescheitert “, $ftp->message;

#Wechseln in den Unterordner “backup”. Der Ordner muss bereits existieren. Sie können ihn auch weglassen oder durch einen beliebigen ersetzen

$ftp->cwd(“/backup”)

or die “Kann das Verzeichnis nicht wechseln “, $ftp->message;

# Erzeugung des Unterordners als aktuelles Backup-Verzeichnis

$ftp->mkdir($backupDir);

#Wechsel ins aktuelle Backup-Verzeichnis

$ftp->cwd($backupDir);

# Binären-Modus für den Upload

$ftp->binary();

#Upload der Backupdatei
$ftp->put(“backup.tar.gz”);
#Und Schluss
$ftp->quit();

Wie die meisten Administratoren aus eigener Erfahrung wissen, bedeutet ein Backup zu besitzen nicht automatisch auch, im Schadensfall die Daten vollständig wieder hergestellt zu bekommen. Besonders im Webserverumfeld tun sich einige schwer mit der Datensicherung.
Hier nun Teil 1 von zwei Teilen zum Thema Website-Sicherung.

Die meisten Websites bestehen heute aus Dateien auf einem Webspace und einer Datenbank. Zuerst geht es an die Sicherung der Datenbank. Dabei ist es der einfachste Weg per phpmyadmin eine Sicherung in Form eines SQL-Dumps anzulegen. Dies führt aber leider häufig zu Problemen wegen Dateigrößenbeschränkungen und Umlautfehlern bei der Rücksicherung. Auch bietet phpmyadmin keine automatisierte regelmäßige Sicherung an.
Besser geht dies mit dem Open Source Tool mysqldumper.

1. Laden Sie sich das Tool von der Website herunter , entpacken Sie es und laden Sie es auf den Webspace.
2. Benennen Sie das Verzeichnis von msdx.x in msd um.
3. Rufen Sie ihre-domain.de/msd auf.
4. Starten Sie nun die Konfiguration, indem Sie die Zugangsdaten für Ihre Datenbank eingeben. Falls Sie mehrere Datenbanken sichern wollen, aktivieren Sie Multidump und markieren Sie die Datenbanken, die Sie sichern wollen.
5. Im Reiter „Allgemein“ können Sie weitere Optimierungen vornehmen, eine genaue Erklärung finden Sie auf der Homepage der Programmier. Um ein Backup zu erstellen, können Sie aber erst mal alles so lassen wie es ist.
6. Sie müssen nun entscheiden, wie Sie sichern möchten. Per E-Mail, per FTP oder einfach nur in eine Datei auf den Server. Bei Variante 1 und  2 rufen Sie den entsprechenden Reiter auf und tragen Ihre  Daten ein. Bei Variante 3 können Sie direkt zum Menüpunkt „Backup“ wechseln.
7. Dort angekommen drücken Sie den Backup-Starten-Knopf und los geht’s.
8. Wenn nun alles fehlerfrei abläuft, gehen Sie wieder zurück zur Konfiguration und auf den Reiter „Cronscript“. Hier wird nun die automatisierte Sicherung konfiguriert. Geben Sie am besten den Pfad zur Konfiguration als absoluten Pfad an.  Sie finden ihn unter „Backup“ im oberen Menüpunkt „Backup Perl“ unten auf der darauf erscheinenden Seite.
9. Um sicher zu gehen, dass Perl und das Backup richtig arbeiten, haben Sie auch dort die Möglichkeit, Perl und die Module zu testen. Wenn es Fehler gibt, empfehle ich Ihnen aber, die Perldateien per SSH auf dem Server manuell auszuführen und dort die Fehlermeldungen zu analysieren. Dann können Sie gleich benötigte Module nachinstallieren. Übrigens: Perl-Module z.B. DBI werden mit: perl -MCPAN -e ‘install DBI’ installiert. Und vergessen Sie nicht, dass das Skript  ausführbar sein muss (chmod 755 crondump.pl ).
10. Nachdem auch das läuft, müssen Sie nur noch dem CRON-Dienst sagen, wann das Skript auszuführen ist. Die erreichen Sie mittels: crontab –e und dann eine neue Zeile anfügen
    * * * * * /pfad-zum-skript
    ersetzen Sie die Sternchen jeweils durch die Zahlen, die Sie brauchen. Sie stehen für Minute, Stunde, Tag, Monat und Wochentag also 30 * * * * jeweils um halb ausführen
15 23 5 * * jeden 5. des Monats um 23:15 ausführen usw.
11. Fertig

Bitte kontrollieren Sie aber regelmäßig, ob das Backup noch läuft und die Dateien auch funktionsfähig sind.

Diesmal in eigener Sache:

Derzeit schreibe ich an einem Buch zum Thema Webserver- und Typo3-Sicherheit. Die Themen reichen von der Hardwareauswahl, über Schutzkonzepte, wie IDS und Firewalls, die Installation und Konfiguration von SSH, FTP, MySQL, Apache bis hin zu reichlich Methoden Typo3 sicher zu betreiben. Des weiteren werden die Rechtesysteme behandelt und Backupmethoden erläutert.
Ich würde mich freuen, weitere Anregungen zu Themen zu bekommen, die in diesem Bereich von Interesse sind. Ich kann zwar nicht versprechen alles zu berücksichtigen, aber soweit es inhaltlich einigermaßen passt und nicht den Rahmen sprengt nehme ich es gerne mit auf.

Zu einer vernünftigen IT-Sicherheitsinfrastruktur zählt auch ein Ticketsystem, mit dem Kunden bzw. Mitarbeiter in der Lage sind, Probleme zu melden, ohne großen Aufwand zu haben. Mein Favorit für diese Problemstellung ist das Open Source System OTRS. Damit lassen sich ohne viel Aufwand Tickets verwalten und abarbeiten. Die Installation möchte ich anhand eines Suse 11.1 darstellen.

Zunächst benötigen Sie ein Suse-System; da später alles per Webserver läuft, reicht ein text-basiertes System aus. Stellen Sie zunächst sicher, dass keine unnötigen Dienste laufen.

Installieren Sie nun ssh, Apache2 und Mysql mit Hilfe von yast. Wenn Sie den Apache nicht selber konfigurieren möchten, installieren Sie zusätzlich das Yast-Modul yast2-http-Server. Falls Sie diesen Weg gewählt haben, beenden Sie yast nach der Installation des Modules und starten Sie es neu, um dort unter Network Services den http-Dienst zu konfigurieren. Ohne das Modul beenden Sie yast und konfigurieren Sie den Apache nach Ihren Wünschen per Hand.

Hiernach starten Sie den Mysql-Dienst mit „rcmysql start“ und führen das Script für eine Absicherung des Mysql-Dienstes mit dem Befehl „mysql_secure_installation“ aus. Alternativ können Sie Mysql natürlich auch per Hand einrichten.

Nun wird es Zeit OTRS selbst zu installieren. Sie können die Version 2.2 direkt aus yast heraus installieren oder per „wget http://ftp.otrs.org/pub/otrs/RPMS/suse/10.0/otrs-2.3.4-01.noarch.rpm“ oä. sich die derzeit aktuelle stabile Version 2.3.4 als RPM herunter laden. Nehmen Sie die Version für Suse 10.0 -10.3 aus dem Verzeichnis, Sie läuft einwandfrei unter 11.1. (http://otrs.org/download/)

Bei dem selbst herunter geladenen Paket starten Sie die Installation mit „rpm –i Paketname“.

Zum Abschluss der Installation starten Sie den Apache und Mysql neu mit „rcapach2 restart && rcmysql restart“. Mit höchster Wahrscheinlichkeit startet der Apache nun nicht wieder. Dies liegt an dem Fehlen eines Perl-Moduls namens Apache::Reload, dass in mod_perl 2.0.4 nicht enthalten ist. Entweder verschieben Sie den Einsatz von OTRS, bis mod_perl 2.0.5 erschienen ist (da soll es dann wieder drin sein) oder Sie installieren es mit „cpan Apache::Reload“ selbst. Sollten Sie das erste mal cpan benutzen, müssen Sie einige Fragen beantworten. Ich empfehle Ihnen an der Stelle, auf die Frage „ Wollen Sie so viel wie möglich automatisch machen lassen“ mit yes zu antworten.

Nun können Sie den Apache starten und alles läuft.

Der nächste Schritt ist die Konfiguration von OTRS selbst. Rufen Sie hierzu die Seite Adresseserver/otrs/installer.pl von einem Browser aus auf. Die Menüs sind soweit selbsterklärend; tragen Sie die Werte ein und klicken Sie sich durch. Im Anschluss können Sie sich nun in Ihr System einloggen.

Serveradresse/orts/index.pl

Benutzer: root@localhost

Passwort: root

Sie sollten das Passwort nach dem Login im Adminbereich unter Benutzer ändern. Eine Eigenart von OTRS ist es, dass überall leere Listen angezeigt werden und Sie erst, wenn Sie auf Suchen gehen, die Daten bekommen. Also wundern Sie sich nicht, wenn Sie den Nutzer root nicht auf Anhieb sehen oder eine neue Firma nicht in der Liste erscheint.

1. Installieren Sie Ubuntu mit der Standardinstallation (hier ist Version 9.04 zum Einsatz gekommen).
2. Öffnen Sie unter System/Systemverwaltung den Synaptics-Paketmanager und suchen Sie nach „Nepenthes“. Installieren Sie das Paket und die zusätzlich benötigten Bibliotheken (Sie müssen nur bestätigen).
3. Öffnen Sie ein Terminalfenster und testen Sie mit „sudo nepenthes“, ob alles gut gelaufen ist. Sie werden eine Menge Text sehen und einige rote Fehlermeldungen. Mit diesen beschäftigen wir uns im Folgenden.
4. Brechen Sie den Prozess mit STRG-C ab. Dies ist leider nicht immer ganz erfolgreich, deshalb überprüfen Sie mit „sudo ps ax | grep nepen“, ob es funktioniert hat. Als Ergebnis sollten Sie nur eine Zeile sehen in der grep nepen vorkommt. Sollte noch eine zweite Zeile da sein, in der Nepenthes ausgeschrieben steht, benutzen sie den Befehl „sudo kill Nummer“, wobei Nummer die Zahl ist, die vor der Zeile in der Nepenthes steht zu sehen ist. Nun ist der Prozess definitiv beendet und Sie können mit der Konfiguration beginnen.
5. Hierzu öffnen Sie mit einem Texteditor Ihrer Wahl die Datei /etc/nepenthes/nepenthes.conf und schreiben die Zeile bind_address im Block socketmanager statt der 0.0.0.0 die IP-Adresse Ihrers Rechners. (Falls Sie sie noch nicht kennen, der Befehl „ifconfig“ zeigt Ihnen alle Adressen an, die Sie verwenden) Wichtig ist, dass Sie die Datei als mit root-Rechten bearbeiten. Also z.B. mit „sudo vi nepenthes.conf“
6. Nun läuft ihr Honeypot mit den Standardeinstellungen.

Nachfolgend erkläre ich Ihnen noch einige Modulkonfigurationsdateien.

Nepenthes.conf

In dieser Datei wird geregelt welche Module geladen werden sollen und wo welche speziellen Konfigurationen zu finden sind. Die Module haben alle als Endung ein .so und deren Konfigurationsdateien finden Sie im Ordner /etc/nepenthes.

Log-download.conf

Hier legen Sie fest in welchem Ordner die Logfile über protokollierte Downloads und Downloadversuche geschrieben werden sollen.

Submit-file.conf

Konfiguriert den Speicherplatz für entgegenommene Dateien

Vuln-*Dienstename*

Definiert die einzelnen offenen Ports, die simuliert werden sollen.

Wie immer gibt es die Anleitung auch als PDF.

http://www.great-oak.de/fileadmin/greatoak2008/pdf/nepenthes-installation-great-oak.pdf

un gibt es hier auch eine Anleitung um eine Verbindung zwischen einem Lancom-Router und der kostenlosen VPN-Software von Shrew Soft herzustellen, da es anscheinend diverse Probleme dabei gibt. Sie beschreibt, wie die Shrew Soft Software konfiguriert wird. Die Konfiguration des Lancom Routers entnehmen die bitte der IPSecuritas-Anleitung.

Die Anleitung für Shrew Soft finden Sie hier:

http://www.great-oak.de/fileadmin/greatoak2008/pdf/Anleitung-VPN-Lancom-1611-zu-Shrew-Soft.pdf

Die Landesbeauftragte für Datenschutz und Informationsfreiheit in NRW, Bettina Sokol, weist in Form eines Auskunftsersuchens eine Kommune mit touristischem Internetportal darauf hin, dass die Benutzung von Google Analytics bei der derzeitigen Rechtslage zu unterlassen ist.

Hiermit stellt Frau Sokol, genau wie in ihrem Datenschutzbericht 2009, klar, dass ihre Behörde die IP-Adresse eines Internetseitenbesuchers ganz eindeutig als personenbezogenes Datum einordnet. Dies hat somit als logische Konsequenz, dass für das Erheben und Auswerten von Besucherdaten und deren Übermittlung ins außereuropäische Ausland eine freiwillige und ordentlich dokumentierte Einwilligung notwendig ist. (§ 12 und 13 TMG)
Da dies aber bei einem Einsatz von Google Analytics nicht möglich ist (Die Daten werden schon erhoben, bevor ein Nutzer überhaupt etwas sieht) lässt sich hieraus die Rechtswidrigkeit eines Einsatzes von Google Analytics herleiten. Zu diesem Thema gibt es auch zwei bekannte Urteile, zum einen vom AG und LG Berlin, dass alle IPs personenbezogen definiert und eines vom AG München, was dynamische als nicht personenbezogen definiert, sich aber über statisches IP ausschweigt. Zudem hat das AG München leider versäumt zu begründen, warum sie dies so sehen.

Bei der derzeitigen Rechtslage sollte jeder Verantwortliche einer Website auf den Einsatz von Analytics verzichten.

Weitere Informationen zu dem Thema zusammengefasst unter:
http://www.it-sicherheitsblog.de/wp-content/googleanalytics.pdf

Am Wochenende, beim Lesen diverser Zeitungen und Zeitschriften, fielen mir die Stellenanzeigen ins Auge. Viele Stellenanzeigen stellen meiner Ansicht nach schon ein Sicherheitsrisiko für die betreffenden Unternehmen dar. Zum einen kann man beim Studium der Stellenanzeigen auf der Website des Unternehmens bereits viel über den internen Aufbau lernen und erfährt auch, als welche Person man sich bei einem Angriff am besten ausgeben (Ich bin der neue Marketingsassistent, leider habe ich noch keine Zugangsdaten, darf ich mal kurz ihren PC benutzen) bzw. an wen man sich wenden kann. (Ach Herr Meier, sie sind also der neue Vertriebler, ich bin Herr XYZ vom Rechenzentrum. Ich arbeite auch erst seit zwei Wochen hier *Smalltalk* und muss mal kurz ihren PC fertig einrichten. Bitte geben Sie mir doch kurz ihre Zugangsdaten, dann muss ich nicht erst ins Büro laufen und sie mir raussuchen. Wenn das der Arbeitsteilungsleiter sieht hält er mich gleich für vergesslich oä.)

Aber die Gefahren stecken auch noch in anderen Informationen in der Stellenanzeige. So kann ein potenzieller Angreifer häufig erfahren, welche Hard- und Software zum Einsatz kommt (Kenntnisse in Lexware FO, Suse Linux, MS IIS, LANCOM-Geräte (z.B. 1611+) wünschenswert).

Beim intensiven Studium der Anzeigen erfährt der Angreifer vieles, was er auch auf anderem Wege hätte herausfinden können, völlig gefahrlos und zusammengefasst.
Mein Vorschlag wäre, auch wenn man gerne seinen Traumkandidaten exakt definieren möchte, formulieren Sie ihre Beschreibungen allgemeiner. Schreiben Sie Kenntnisse im Umgang mit Linuxsystemen und gängigen Webservern wünschenswert oder statt “Wir möchten in Zukunft verstärkt auf IT-Sicherheit setzen und suchen deshalb einen IT-Sicherheitsexperten” lieber “Zur Verstärkung unseres IT-Teams suchen wir einen IT-Sicherheitsexperten”. So erfährt niemand welche Soft- oder Hardware Sie genau einsetzen und auch nicht, dass das Thema IT-Sicherheit bisher eine untergeordnete Rolle bei Ihnen gespielt hat. Und generell sollten Sie definieren, welche Informationen das Unternehmen verlassen dürfen und welche nicht. Dies ist dann auch bei Stellenanzeigen einzuhalten.