Schlagwort-Archive: Webserver

SSL-Verschlüsselung von Websites Apache HTTP Server | Linux Ubuntu Server 12.04.2 LTS

Bereits im Eintrag vom 30. April 2013 habe ich ansatzweise erläutert, mit welchen Mitteln eine SSL-Verschlüsselung des Webservers zu realisieren ist. Um dieses Wissen anzuwenden, werden nun jene Schritte erläutert, um eine konkrete Subdomain http://xy.meinedomain.com durch ein SSL-Zertifikat abzusichern. An dieser Stelle wird davon ausgegangen, dass ihr bereits über eine abgeschlossene Installation des Webservers als auch des entsprechenden Dienstes verfügt. Dieser soll nunmehr über die abzusichernde Subdomain aufgerufen werden.

Zunächst nochmals die wichtigsten Links zum Thema:

Wiki.Ubuntuusers.de – Apache SSL

Heise Security SSL für lau

Zertifizierungstelle StartSSL

Ein SSL-Zertifikat kann durch kommerzielle Anbieter (Verisign, RapidSSL etc.) ausgestellt werden, dessen Preisen sich nach Authentifizierungsmethode und Laufzeit richten. Es gibt jedoch auch einen israelischen Anbieter (StartSSL), der ein kostenloses Zertifikat für ein Jahr Laufzeit ausstellt. Dessen Wurzelzertifikat ist bereits in allen gängigen Webbrowsern enthalten ist. Dadurch wird keine Fehlermeldung bei Aufruf der Domain ausgegeben. StartSSL verwendet als Authentifizierungsmethode eine Domainvalidierung. Diese ist Voraussetzung für die Ausstellung eines Zertifikats.

Theorie:

  1. Aktivierung des entsprechenden Apache-Moduls
  2. Änderung des Port-Konfiguration des Apache-Webservers
  3. Generierung eines Schlüsselpaars (öffentlicher und privater Schlüssel)
  4. Auslesen des öffentlichen Schlüssels und Erstellung eines Certificate Signing Request (CSR)
  5. Übermittlung des CSR an die Certificate Authority (CA)
  6. Ausstellen des Zertifikats durch die CA
  7. Speicherung des Zertifikats auf dem Webserver und Auslieferung an die Clients

Praxis:

Alle Arbeiten an der Konfiguration des Webservers sollten im Ordner /etc/apache2 durchgeführt werden.

Einige Befehle für den Apache-Webserver:

sudo service apache2 start
sudo service apache2 stop
sudo service apache2 restart
sudo service apache2 force-reload

1. Schritt: Änderung der Konfiguration ports.conf (/etc/apache2) des Apache-Webservers, so dass dieser auf Anfragen des Ports 443 reagiert (Standard-Port für HTTPS-Verbindungen). Falls der Server über einen SSH-Dienst verfügt, kann die Konfiguration bequem über eine SFTP-Verbindung übertragen und am lokalen Rechner bearbeitet werden. Jedoch ist die Bearbeitung mittels eines SSH-Terminals und einem passenden Editors (z.B. vi) in der Regel komfortabler.

sudo vi /etc/apache2/ports.conf

Die folgenden beiden Argumente sollten nicht auskommentiert, also aktiv sein:

[IfModule mod_ssl.c]
Listen 443
[/IfModule]
[IfModule mod_gnutls.c]
Listen 443
[/IfModule]

Bitte <> anstelle [] verwenden!

2. Schritt: Danach kann das SSL-Modul aktiviert werden.

sudo a2enmod ssl

Über den Befehl sudo a2dismod ssl kann das Modul auch jederzeit wieder deaktiviert werden.

3. Schritt: Nun wird das Schlüsselpaar (öffentlicher und privater Key) generiert:

openssl genrsa -out xy.meinedomain.com.com.key 2048

Anschließend kann das CSR erstellt werden:

openssl req -new -nodes -newkey rsa:2048 -keyout xy.meinedomain.com.key -out xy.meinedomain.com.csr

Dabei werden einige Punkte abgefragt sowie ein Challenge Password gefordert. Dieser Punkt kann mit einer Enter-Bestätigung übersprungen werden. Nach diesem Schritt befinden sich zwei neue Dateien xy.meinedomain.com.key sowie xy.meinedomain.com.csr im Arbeitsordner /etc/apache2. Diese sollten im Anschluss auf den lokalen Rechner gespeichert werden.

3. Schritt: Jetzt wird mit dem Anlegen eines Benutzeraccount bei StartSSL begonnen: Control Panel – Sign-Up. Nachdem alle Angaben gemacht wurden, wird die Validierung der Domain durchgeführt: Validations Wizard – „Type“ Domain Name Validation. Abgeschlossen wird der Vorgang mit der Zusendung und Eingabe des Bestätigungscodes.

4. Schritt: Im Anschluss kann das Zertifikat beantragt werden: Certificates Wizard – „Certificate Target“ WebServer SSL/TLS – Skip „Generate Private Key“ – Submit Certificate Request (CSR). Hier den Inhalt der Datei  xy.meinedomain.com.csr einfügen und übermitteln. Danach den „Top Target Domain“ auswählen und Subdomain festlegen. Damit ist der Prozess abgeschlossen. Mit einem Klick auf „Continue“ wird der Zertifikatinhalt erzeugt. Dieser wird vollständig in eine Textdatei kopiert und mit der Endung .crt abgespeichert.

5. Schritt: Zuletzt müsst ihr noch die Zertifikate „StartComm Root CA (PEM encoded)“ und das „Class 1 Intermediate Server CA“ herunterladen. Nun alle Dateien auf den Server übertragen und  in einem separaten Ordner unter /etc/apache2 abspeichern.

Abschließender Schritt: Abschließend muss ein VirtualHost für den SSL-Zugriff angelegt werden. Falls der abzusichernde Webservice bereits über eine Subdomain erreicht wird, kann auch eine Änderung notwendig sein. In der Regel werden die VirtualHost-Dateien unter /etc/apache2/sites-available unter ihrem Subdomainnamen abgespeichert. Die beispielhafte Konfiguration ist nachfolgend dargestellt:

2013-08-05_190730

 

Durch Ausführen eines Neustarts des Apache-Webservers wird die neue Konfiguration übernommen und der Webservice sollte nun verschlüsselt über die Subdomain aufgerufen werden können.

Dokumentation Server (Rackmontage)

Heute möchte ich mit der Dokumentation zu jenem Server starten, welcher zu einem späteren Zeitpunkt in einem Rechenzentrum seinen Dienst verrichten wird. Um eine gute Übersicht zu erreichen, wurde der Website im Navigationsmenü ein zusätzlicher Eintrag „Colocation-Server“ unter „IT-Technologie“ hinzugefügt. Alle eigenständige Beiträge, welche die Konfiguration oder andere aktuelle Informationen zu diesem Server betreffen, werden als Mitteilungen in einer Kategorie angezeigt.

ROBOCOPY / WebDAV und MS Windows XP – Clients

Mit Referenz zum Artikel „Datensicherung ROBOCOPY & WebDAV“ haben sich einige Änderungen in der Vorgehensweise ergeben. Es hat sich herausgestellt, dass die Speicherung von Daten auf einer WebDAV-Ressource unter Verwendung von Windows-XP-Boardmitteln äußerst schwierig in der Umsetzung ist. Dies ist folgenden Umständen geschuldet:

  • Unterstützung von WebDAV-Ressourcen im Windows-Explorer nicht ausreichend für automatisierten Zugriff
  • (Auto-) Speicherfunktion der Zugangsdaten für die WebDAV-Speicherressource fehlerhaft
  • Umfangreiche Skripte mit „NET USE“ und weiteren Befehlen wären notwendig, um eine fehlerfreie Lösung zu implementieren

Aus diesem Grund habe ich mit dem Anwender folgende Lösung erarbeitet:

  1. Fortsetzung der Nutzung des Windows-XP-Betriebssystems (BS)
  2. In naher Zukunft Update der IT auf das Windows-7-BS
  3. Installation und Nutzung der Software eines Drittanbieters
Jedoch möchte ich noch kurz die Gelegenheit nutzen, auf die vielen Funktionen zu verweisen, welche ROBOCOPY bietet. Der Artikel bei WinTotal gibt dazu eine kleine Einführung und Anwendungsbeispiele:

http://www.wintotal.de/artikel/artikel-2007/91.html

Datensicherung ROBOCOPY & WebDAV

Neben dem Vorbereiten und Hochladen der bereits angekündigten Anleitungen zur Konfiguration des Webservers möchte ich mich heute noch kurz mit zwei weiteren Überlegungen befassen. Diese haben sich durch zwei Probleme aus der letzten Woche ergeben und haben daher Priorität.

Zunächst geht es darum, die Datensicherung eines Anwenders zu ändern. Im Moment verwendet der Anwender eine externe Festplatte an seiner FritzBox als Datenspeicherort für alle Client-PC`s. Die FritzBox bietet hierzu eine NAS (Network Attached Storage)-Funktionalität. Dadurch wird gemeinsame Arbeit an den Dokumenten durch ein Netzlaufwerk ermöglicht. Datensicherheit wird bei dieser Lösung dadurch sichergestellt, dass die Daten aus dem gemeinsamen Ordner mit dem Strato „HiDrive“-Cloudspeicher synchronisiert werden. Auch dafür bietet das Menü der FritzBox eine entsprechende Funktion.

Das Problem bei dieser Lösung liegt darin, dass die Daten zwar an zwei Orten bereitgehalten werden und dadurch auf teure RAID-NAS verzichtet werden kann, jedoch ist die Performance des System leider nicht gegeben. Mitunter vergehen einige Minuten, bis das Netzlaufwerk angesprochen werden kann. Dadurch ergeben sich starke negative Einflüsse auf den Arbeitsablauf, welche nicht länger hingenommen werden können.

Analyse

Nach einem Gespräch mit den betroffenen Personen stellte sich heraus, dass ein gemeinsamer Zugriff auf die Dateien nur gelegentlich erforderlich ist. Hauptsächlich sei es wichtig, die Dokumente neben der lokalen Speicherung an einen weiteren Ort bereitzuhalten. Mein erster Gedanke, die Verwendung der Strato „HiDrive“-Software zum Abgleich eines lokalen Ordners mit der Datencloud wurde als unpraktikabel verworfen, da die Software bereits einmal im Einsatz war und durch zahlreiche Fehler negativ aufgefallen war. Somit musste ein neuer Lösungsansatz her…

Anforderungen

  • Daten sollen vom Nutzer lokal abgespeichert werden
  • Abgleich zwischen lokalen Speicherort und Cloudspeicher soll automatisch erfolgen
  • Auf die Daten im Cloudspeicher sollen weitere Nutzer zugreifen können

Lösungsansatz

  • Lokale Speicherung der Daten durch die Nutzer
  • ROBOCOPY um Dateien auf eine bereitgestellte Ressource zu sichern
  • Sicherung auf WebDAV-Ressource (Strato „HiDrive“ oder eigener Webserver)
  • Bereitstellung eines Interface um Zugriff auf die Dateien für andere Nutzer zu gewährleisten

Umsetzung

  • Programmierung eines Skriptes unter Verwendung der  ROBOCOPY-Befehle
  • Bereitstellung einer WebDAV-Ressource auf einem Microsoft Windows Server 2008 R2 mit IIS 7

Konzept

So kann die Umsetzung aussehen, wenn anstelle des Strato „HiDrive“-Speichers ein eigener Webserver verwendet wird.

Da ich die Umsetzung auf dieser Basis beschreiben werde, wird sich die Liste der Anleitungen für den Webserver erweitern.

Im nächsten Post geht es aber erstmal um die Programmierung der ROBOCOPY-Skripte.

Wofuer kann ein Webserver genutzt werden?

Wie bereits angekündigt, werden sich die nächsten Anleitungen mit allerlei Fragen rund um das Thema „Webserver“ beschäftigen. Um einen ersten Eindruck zu bekommen, welche Aufgaben mit Hilfe eines eigenen Webservers erledigt werden können, habe ich ein kleine Übersicht der Funktionen meines Servers erstellt. Dies gibt auch einen Ausblick auf den Fokus der Anleitungen, da es zunächst um die Einrichtung einer Basis für web-basierte Dienste gehen wird. Für jene Zwecke ist der IIS7-Webserver als Standardkomponente im Windows Web Server 2008-BS integriert. Um diesen auf die Anforderungen der dynamischen Inhalte vorzubereiten, sind einige zusätzliche Installationen notwendig. Die Installationsbeschreibung jener Komponenten schließt sich an die Vorbereitungsarbeiten an. Darüber hinaus sollten zusätzliche Schnittstellen für den Dateitransfer geschaffen werden. Mit Abschluss dieser vorbereitenden Maßnahmen geht es an die Installation und Konfiguration der eigentlichen Anwendungen.

Spannend wird mit Sicherheit die Konfiguration des OpenERP-Systems, da ich mir von diesem eine grossen Nutzen verspreche und hoffentlich ein guter Transfer in andere Bereiche möglich ist.

 

Auswahl Virtueller Server

Bevor mit der Konfiguration und Einrichtung eines Webservers begonnen werden kann, muss vom Anwender zunächst ein passendes Produkt ausgewählt werden. War vor einigen Jahr das Angebot noch überschaubar, gibt es heute ein Vielzahl von Auswahlmöglichkeiten. Aus diesem Grund sollen die nun folgenden Absätze die Entscheidung vereinfachen.

Am Anfang der Auswahl sollte die Entscheidung über das Betriebssystem (BS) stehen. Zum Einsatz kommen mehrheitlich Linux-Distributionen, wobei dabei auf eine breite Palette von anwendungsspezifischen Varianten gewählt werden kann. Neben linux-basierten Webservern behauptet sich außerdem solche auf Microsoft Windows-Basis, wobei die Version 2003/2003 R2 und 2008/2008 R2 die weiteste Verbreitung besitzen. Für die linux-basierten Systeme sprechen die geringen Lizenzkosten und die vielen Möglichkeiten zur spezifischen Anpassung. Auch der gute Support durch eine Vielzahl freier Distributionen als auch kommerzieller Anbieter sprechen für dieses BS. Für die Windows-Lösung sprechen der professionelle Support und die geringe Umgewöhnung. Auch die Integration in die bestehende IT-Ausstattung kann ein ausschlaggebendes Kriterium für die Wahl sein.

1. Wahl des Betriebssystems

  • Microsoft Windows Server 2003/2008
  • Linux-Distribution

Begründung meiner Entscheidung: Wahl von Microsoft Windows Web Server 2008 als Betriebssystem, da ich als Windows-Nutzer nicht auf eine grafische Oberfläche nicht verzichten wollte und die Anwendung „Air Video Server“ für die Bereitstellung von Videomaterial an iOS-Endgeräte zum Zeitpunkt der Entscheidung (11/2011) nur für Microsoft-BS verfügbar war. Darüber hinaus war die gute Remotedesktop-Funktionalität und dessen Integration in andere Windows-BS simpel und einfach ist.

Mit der Wahl des BS verkleinert sich die Auswahl der möglichen Anbieter. Um hier eine weitere Filterung vorzunehmen, sollte an diesem Punkte eine Entscheidung über die Performance des Webserver getroffen werden. Angeboten werden heute in der Regel drei Typen:

2. Wahl des Servertyps

  • Root-Server
  • vServer
  • Managed Server
  • Colocation

Bei Root-Servern handelt es sich um physikalisch vorhandene Server, welche vom Anwender bei entsprechenden Anbietern auf bestimmte Zeit gemietet werden kann. Dabei wird der komplette Rechner überlassen, d.h. es steht zu jedem Zeitpunkt die Leistung zur Verfügung, welche die gewählte Hardware bereitstellen kann. vServer unterschieden sich von Root-Servern dahingegen, dass durch Installation von virtuellen Clients eine höhere Auslastung nach dem Leistungsbedarfsprinzip erreicht wird. Dem Anwender wird dabei garantiert, dass er eine bestimmte Grundleistung zur Verfügung gestellt bekommt, sich die Gesamtrechenleistung aber mit anderen Kunden teilen muss. Ähnlich verhält es sich bei Managed Servern, welche eine Variante der vServer darstellen. Bei diesen kann der Anwender flexibel zusätzliche Kapazitäten hinzubuchen, wenn die georderte Leistung nicht ausreichen sollte. Unter „Colocation“ wird die Möglichkeit verstanden, den eigene Server in den Räumen des Anbieters unterzubringen. Dabei stellt der Hoster die Infrastruktur zur Verfügung (Strom- und Netzwerkanbindung) und garantiert für die Ausfallsicherheit seitens der Räumlichkeiten (Notstrom, Brandüberwachung usw.), jedoch nicht für die Serverhardware.

Begründung meiner Entscheidung: Wichtig war mir eine kostengünstige Variante mit großem (Festplatten-) Speicherangebot.  Zum Zeitpunkt meiner Entscheidung gab es ein Aktion bei Strato, welche als Anstieg in den Betrieb eines eigenen Webservers eine vServer mit 50GB-Festplatte zum Preis von 10 €/Monat. Dieser Preis ist bis zum heutigen Tag gültig. Je nach gewünschter Hardwarekonfiguration gibt es eine Vielzahl von Anbietern, wobei ein wichtiges Kriterium mit Sicherheit auch die Vertragslaufzeit ist (Strato = 1 Monat).

Wie bereits aus der Begründung für die Auswahl des Servertyps hervorgeht, ist eine genaue Spezifizierung hinsichtlich der Leistungsdaten notwendig, um eine Entscheidung treffen zu können. Aus diesem Grund sollten ein paar Leitfragen vorab grob beantwortet werden:

  1. Sollen auf dem Server hauptsächlich rechenintensive Datenbankanwendungen mit eher geringen Festplattenspeicheranforderungen ausgeführt werden? Wenn ja, dann ist eine starke Prozessorleistung und ein großer Arbeitsspeicher notwendig.
  2. Sind die Anforderungen hinsichtlich der Rechenleistung eher gering und soll dafür ein große Menge an Daten gespeichert werden? Wenn ja, so ist eine hohe Festplattenkapazität erforderlich.
  3. Mit wie vielen Nutzern ist zu rechnen?
  4. Werden Leistungsspitzen nur vereinzelt auftreten oder ist mit einer durchgehend hohen Anforderung zu rechnen?

Jeder Anwender wird an dieser Stelle andere Anforderungen definieren, weshalb es ratsam ist, einen individuellen Fragenkatalog zusammenzustellen.

3. Spezifizierung der Leistungsanforderungen

4. Auswahl

Für professionelle Projekte ist sicherlich die Wahl eines Root-Servers ratsam, im privaten Gebrauch sollte ein vServer vorerst ausreichen.

Warum Strato Windows vServer S?

  • geringe monatliche Kosten
  • im Vergleich großer Festplattenspeicher
  • keine Setup-Gebühren
  • kurze Vertragslaufzeiten
  • Skalierung nach oben möglich