Der Wechsel zu einem neuen Virtual Private Server (VPS) bei einem anderen Provider ist daher eine gute Gelegenheit, nicht nur bestehende Dienste zu migrieren, sondern die technische Basis von Grund auf neu zu planen. Bevor Anwendungen und Workloads folgen, soll zunächst eine solide, sichere und nachvollziehbar dokumentierte Grundlage entstehen.

Ausgangssituation und Zielsetzung

Die bisherige Umgebung war über viele Jahre produktiver Server und zugleich Plattform zum Lernen und Ausprobieren. Entsprechend ist die Architektur mit neuen Technologien, Konzepten und eigenen Anwendungen organisch gewachsen.

Mit dem neuen VPS möchte ich auf einer sauberen Basis starten, bisherige Entscheidungen neu bewerten und moderne Konzepte ausprobieren. Bevor Anwendungen migriert werden, steht daher zunächst eine definierte technische und sicherheitsbezogene Baseline im Mittelpunkt.

Eine besondere Herausforderung wird die Migration eigener, über Jahre gewachsener Software. Einige Abhängigkeiten und Laufzeitumgebungen sind auf aktuellen Betriebssystemen nicht mehr verfügbar. Ziel ist deshalb nicht nur, die Anwendungen wieder lauffähig zu machen, sondern sie zu modernisieren und künftig wartbarer, reproduzierbarer und portabler zu betreiben.

Eine Checkliste als lebendes Dokument

Die folgende Checkliste beschreibt die Themen und Maßnahmen, die ich bei der Bereitstellung und Absicherung eines neuen VPS berücksichtige. Sie ist als lebendes Dokument gedacht und wird mit neuen Erfahrungen, Anforderungen und Erkenntnissen kontinuierlich weiterentwickelt.

Sie stellt keine starre Installationsanleitung dar. Welche Punkte tatsächlich umgesetzt werden, hängt von Einsatzzweck, Schutzbedarf und technischen Rahmenbedingungen ab.

Bewusst verzichte ich auf konkrete Anwendungen und deren Konfiguration. Im Mittelpunkt steht eine allgemeingültige VPS-Basis, die unabhängig von Provider und späteren Workloads auch für zukünftige Systeme als Ausgangspunkt dienen soll.

Grundsystem & Updates

Ein aktuelles und unterstütztes Grundsystem bildet die Basis für einen sicheren und stabilen VPS. Geregelte Updates und eine korrekte Zeitsynchronisation reduzieren bekannte Schwachstellen und schaffen einen definierten Ausgangszustand.

Benutzer & Berechtigungen

Ein restriktives Berechtigungskonzept begrenzt administrative Zugriffe auf das erforderliche Maß. Persönliche Konten und das Least-Privilege-Prinzip verbessern Sicherheit und Nachvollziehbarkeit.

Administration & Management

Administrative Schnittstellen benötigen besonderen Schutz, da sie weitreichenden Zugriff auf das System ermöglichen. Sichere Authentisierung und eine begrenzte Erreichbarkeit reduzieren die damit verbundene Angriffsfläche.

SSH-Zugriff

SSH stellt häufig den primären administrativen Zugang zu einem Linux-VPS dar. Schlüsselbasierte Authentisierung und eine restriktive Konfiguration schützen diesen besonders kritischen Zugang.

Management-Netzwerk

Ein separater Managementpfad trennt administrative Zugriffe von öffentlich erreichbaren Diensten. Gleichzeitig sollte ein unabhängiger Notfallzugang bei Fehlkonfigurationen erhalten bleiben.

Firewalls

Firewalls beschränken die Netzwerkkommunikation auf tatsächlich erforderliche Verbindungen. Mehrere voneinander unabhängige Firewall-Ebenen ermöglichen dabei ein mehrschichtiges Sicherheitskonzept.

Provider-Ebene

Eine vorgelagerte Provider-Firewall kann unerwünschten Verkehr bereits vor dem VPS filtern. Ihre Funktionsweise und das Zusammenspiel mit der lokalen Firewall müssen deshalb bekannt sein.

Host-Ebene

Die lokale Firewall schützt den VPS unabhängig von externen Sicherheitsmechanismen. Sie bildet die unmittelbar am Betriebssystem durchgesetzte Netzwerkzugriffskontrolle.

Netzwerk & DNS

Eine definierte Netzwerk- und DNS-Konfiguration ist Voraussetzung für einen kontrollierbaren Serverbetrieb. Adressierung, Routing, Dienste und Namensauflösung sollten einem dokumentierten Sollzustand entsprechen.

IP-Konfiguration & Dienste

Die Netzwerkkonfiguration bestimmt die grundlegende Erreichbarkeit des Systems. Nur tatsächlich benötigte Netzwerkdienste sollten aktiv und erreichbar sein.

Namensauflösung

DNS stellt die Zuordnung zwischen Namen und Netzwerkadressen her. Eine konsistente Forward- und Reverse-Auflösung erleichtert Betrieb, Administration und Fehleranalyse.

Logging & Benachrichtigungen

Protokollierung schafft Transparenz über Systemzustände und sicherheitsrelevante Ereignisse. Benachrichtigungen ermöglichen eine zeitnahe Reaktion auf Zustände, die administratives Eingreifen erfordern.

Protokollierung

Systemprotokolle bilden eine wesentliche Grundlage für Fehleranalyse und Sicherheitsuntersuchungen. Aufbewahrung, Umfang und Schutz der Daten sollten kontrolliert erfolgen.

Alarmierung

Nicht jedes Ereignis kann regelmäßig manuell geprüft werden. Eine gezielte Alarmierung weist daher auf kritische Fehler, Sicherheitsereignisse oder erforderliche administrative Maßnahmen hin.

System-Hardening

System-Hardening reduziert die Angriffsfläche auf die für den vorgesehenen Betrieb erforderlichen Funktionen. Ergänzende Sicherheitsmechanismen erschweren die Ausnutzung verbleibender Angriffswege.

Angriffsfläche reduzieren

Jeder zusätzliche Dienst, Port oder Softwarebestandteil kann potenzielle Angriffsmöglichkeiten schaffen. Nicht benötigte Komponenten sollten deshalb konsequent vermieden werden.

Betriebssystem

Betriebssystemseitige Sicherheitsmechanismen ergänzen die Absicherung einzelner Dienste. Dazu gehören insbesondere restriktive Systemparameter, Zugriffskontrollen und Integritätsmechanismen.

Protokolle & Kryptografie

Veraltete Protokolle und kryptografische Verfahren können sichere Kommunikation erheblich schwächen. Eine definierte kryptografische Baseline beschränkt den VPS auf angemessen sichere Verfahren.

Backup & Recovery

Backups und Wiederherstellungsverfahren begrenzen die Auswirkungen von Fehlern, Ausfällen und Datenverlust. Entscheidend ist nicht nur die Sicherung, sondern deren nachgewiesene Wiederherstellbarkeit.

Datensicherung

Backups stellen relevante Daten und Konfigurationen unabhängig vom laufenden VPS sicher. Mindestens eine Sicherung sollte deshalb außerhalb des Systems aufbewahrt werden.

Snapshot

Snapshots ermöglichen die schnelle Rückkehr zu einem definierten Systemzustand, beispielsweise nach fehlgeschlagenen Änderungen. Sie ergänzen klassische Backups, ersetzen diese jedoch nicht.

Wiederherstellung & Notfallvorsorge

Ein dokumentiertes Recovery-Verfahren reduziert Ausfallzeiten und Unsicherheiten im Störungsfall. Wiederherstellung und Notfallzugänge sollten daher praktisch getestet werden.

Monitoring & Betriebskontrollen

Der Sicherheitszustand eines VPS verändert sich während seines Lebenszyklus. Automatische Überwachung und regelmäßige Prüfungen helfen, Abweichungen vom definierten Sollzustand frühzeitig zu erkennen.

Kontinuierliche Überwachung

Monitoring überwacht wichtige Systemzustände automatisiert und fortlaufend. Kritische Veränderungen können dadurch erkannt werden, ohne auf eine manuelle Kontrolle warten zu müssen.

Periodische Prüfungen

Nicht alle sicherheitsrelevanten Eigenschaften lassen sich sinnvoll kontinuierlich überwachen. Wiederkehrende Prüfungen ergänzen das Monitoring deshalb um eine umfassendere Bewertung des Systemzustands.

Dokumentation

Eine aktuelle Dokumentation macht Konfiguration und Sollzustand des VPS nachvollziehbar und reproduzierbar. Sie unterstützt Administration, Fehleranalyse, Sicherheitsprüfungen und Wiederherstellung.

Abschluss & Abnahme

Die abschließende Abnahme validiert die Basiskonfiguration als Gesamtsystem. Der erfolgreich geprüfte und dokumentierte Zustand bildet anschließend die Referenz für den weiteren Betrieb.

Der Beitrag Linux VPS Installation – Praxisorientierte Checkliste erschien zuerst auf Maximilian Krieg.

Symptom

Bei der Installation, Aktualisierung und Deinstallation von Paketen über apt-get werden konstant die folgenden Fehlermeldungen geworfen.

locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory

Problem

Während meiner Recherche bin ich auf unterschiedlichste Begründungen gestoßen, deren Ursachen jedoch nicht eindeutig auf das von mir betriebene System zutreffen. Lasse ich mir die Locale mittels locale ausgeben, erhalte ich folgende Ausgabe.

# locale
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
LANG=en_US.UTF-8
LANGUAGE=
LC_CTYPE="en_US.UTF-8"
LC_NUMERIC=de_DE.UTF-8
LC_TIME=de_DE.UTF-8
LC_COLLATE="en_US.UTF-8"
LC_MONETARY=de_DE.UTF-8
LC_MESSAGES="en_US.UTF-8"
LC_PAPER=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_ADDRESS=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_ALL=

An dieser Stelle ist auffällig, dass sowohl deutsche und englische Parameter gesetzt sind. Für eine qualifizierte Fehlerdiagnose fehlen mir fundierte Kenntnisse bezüglich Linux. Versuche ich die Locale mittels update-locale LANG=de_DE.UTF-8 zu setzen, erhalte ich erneut die vorherigen Fehlermeldungen. An diesem Punkt schlussfolgere ich für mein Problem, dass die deutsche Locale in irgendeiner Form fehlerhaft ist.

Lösungsstrategie

Locales generieren

In einem Beitrag wird zu der Problematik einer fehlerhaften Locale empfohlen, sie neu zu generieren und im Anschluss zu rekonfigurieren.

# sudo locale-gen de_DE.UTF-8
Generating locales...
  de_DE.UTF-8... up-to-date
Generation complete.

# sudo dpkg-reconfigure locales
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
        LANGUAGE = (unset),
        LC_ALL = (unset),
        LC_PAPER = "de_DE.UTF-8",
        LC_ADDRESS = "de_DE.UTF-8",
        LC_MONETARY = "de_DE.UTF-8",
        LC_NUMERIC = "de_DE.UTF-8",
        LC_TELEPHONE = "de_DE.UTF-8",
        LC_IDENTIFICATION = "de_DE.UTF-8",
        LC_MEASUREMENT = "de_DE.UTF-8",
        LC_TIME = "de_DE.UTF-8",
        LC_NAME = "de_DE.UTF-8",
        LANG = "en_US.UTF-8"
    are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
locale: Cannot set LC_CTYPE to default locale: No such file or directory
locale: Cannot set LC_MESSAGES to default locale: No such file or directory
locale: Cannot set LC_ALL to default locale: No such file or directory
Generating locales...
  de_DE.UTF-8... up-to-date
Generation complete.

Auch während der Rekonfiguration sind die Fehlermeldungen präsent. Eine erneute Durchführung des Befehls dpkg-reconfigure bewirkt keine Änderung an der Ausgabe bzw. Problematik. An dieser Stelle bin ich am Überlegen, ob das Problem generell im Zusammenhang mit der deutschen Locale begraben liegt. Als Alternativlösung versuche ich mir stattdessen die englische Locale zu erzeugen und im Anschluss dpkg-reconfigure durchzuführen.

# sudo locale-gen en_US.UTF-8
Generating locales...
  en_US.UTF-8... done
Generation complete.

# sudo dpkg-reconfigure locales
Generating locales...
  de_DE.UTF-8... done
  en_US.UTF-8... up-to-date
Generation complete.

Die Rekonfiguration verläuft erfolgreich. Ich versuche zunächst die deutsche Locale zu setzen und überprüfe danach die Einstellungen.

# update-locale LANG=de_DE.UTF-8

# locale
LANG=de_DE.UTF-8
LANGUAGE=
LC_CTYPE="de_DE.UTF-8"
LC_NUMERIC="de_DE.UTF-8"
LC_TIME="de_DE.UTF-8"
LC_COLLATE="de_DE.UTF-8"
LC_MONETARY="de_DE.UTF-8"
LC_MESSAGES="de_DE.UTF-8"
LC_PAPER="de_DE.UTF-8"
LC_NAME="de_DE.UTF-8"
LC_ADDRESS="de_DE.UTF-8"
LC_TELEPHONE="de_DE.UTF-8"
LC_MEASUREMENT="de_DE.UTF-8"
LC_IDENTIFICATION="de_DE.UTF-8"
LC_ALL=

Die Ausgabe von locale stimmt nun mit meinen Erwartungen überein und es werden keine Fehlermeldungen mehr ausgegeben. Das Problem scheint somit vorerst gelöst zu sein.

Der Beitrag Deutsche Locale in Ubuntu nicht richtig gesetzt erschien zuerst auf Maximilian Krieg.

Symptom

Nachdem ich meine Ubuntu-VM einige Zeit als Desktop-Alternative eingesetzt habe, treten neuerdings Fehlermeldungen beim Update über apt auf. Die Pakete können zwar korrekt aktualisiert werden, aber mich stört die Fehlermeldung. Die Fehler werden am Ende des apt-get update ausgegeben.

# sudo apt-get update

[...]

Reading package lists... Done
W: GPG error: http://archive.ubuntu.com trusty Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
W: GPG error: http://security.ubuntu.com trusty-security Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
W: GPG error: http://archive.ubuntu.com trusty-updates Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32
W: GPG error: http://archive.canonical.com trusty Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 40976EAF437D05B5 NO_PUBKEY 3B4FE6ACC0B21F32

Problem

Digitale Signaturen werden eingesetzt, um die Integrität und Authentizität einer Datei zu gewährleisten. Die Signatur ist somit der Nachweis, dass der Quellcode einer Anwendung seit dem Packen nicht mehr modifiziert wurde. Die Signatur wird mihilfe des Privaten Schlüssels (Private Key) erzeugt und kann mit dem Öffentlichen Schlüssel überprüft werden. Es fehlen also Öffentlichen Schlüssel in unserem Schlüsselring (Keyring), die wir importieren müssen, um diese Fehlermeldung zu beheben.

Lösungsstrategie

Importieren der Public Keys

Wir notieren uns aus der vorherigen Ausgabe die fehlenden Schlüssel 3B4FE6ACC0B21F32 und 40976EAF437D05B5. Dann importieren wir sie über die Keyserver von Ubuntu.

# sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 40976EAF437D05B5                                                              
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.ZeMCP4ClOD --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv-keys 40976EAF437D05B5
gpg: requesting key 437D05B5 from hkp server keyserver.ubuntu.com
gpg: key 437D05B5: public key "Ubuntu Archive Automatic Signing Key <ftpmaster@ubuntu.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1

# sudo apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 3B4FE6ACC0B21F32
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.zgIABcbm74 --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv-keys 3B4FE6ACC0B21F32
gpg: requesting key C0B21F32 from hkp server keyserver.ubuntu.com
gpg: key C0B21F32: public key "Ubuntu Archive Automatic Signing Key (2012) <ftpmaster@ubuntu.com>" imported
gpg: Total number processed: 1
gpg:               imported: 1  (RSA: 1)

Sollte man nur einen der beiden Schlüssel importieren, wird weiterhin eine Fehlermeldung ausgegeben. Der Import beider Schlüssel ist daher erforderlich.

# sudo apt-get update

[...]

W: There is no public key available for the following key IDs:
3B4FE6ACC0B21F32

Verifizierung des Imports

Wir überprüfen den korrekten Import der beiden Schlüssel, indem wir unsere Paketlisten und Pakete nochmals aktualisieren.

# sudo apt-get update && sudo apt-get upgrade

Wir erhalten jetzt keine Fehlermeldung mehr.

Der Beitrag Fehlende Public Keys beim Update von Ubuntu-Paketen erschien zuerst auf Maximilian Krieg.

Die Umgebung

Für das Praktikum setze ich eine VM mit folgender Konfiguration ein:

• VM-Version: Workstation 8.0
• RAM: 2 GB
• CPU: 1 Prozessor mit 2 Kernen
• HDD: 20 GB
• OS: lubuntu 14.04 x64 (Link)

Vorbereitung

Werkzeuge und Compiler installieren

sudo apt-get install build-essential

Eclipse für C and C++ installieren

sudo apt-get install eclipse eclipse-cdt g++

Anforderungen von Thrift installieren

sudo apt-get install libboost-dev libboost-test-dev libboost-program-options-dev libevent-dev automake libtool flex bison pkg-config g++ libssl-dev libglib2.0-dev 

Git installieren

sudo apt-get install git

Thrift kopieren

git clone https://git-wip-us.apache.org/repos/asf/thrift.git thrift

Installation

Wechsle das Verzeichnis

cd thrift

Erzeuge die Konfigurationsskripte

./bootstrap.sh

Konfiguriere Thrift

./configure

Baue Thrift

make

Installiere Thrift

sudo make install

Kopiere libthrift.so

sudo cp /usr/local/lib/libthrift-1.0.0-dev.so /usr/lib/

Das Grundgerüst

Erzeugen der Thrift-Datei

1. Erstelle eine Datei namens VS3.thrift
2. Definiere darin Variablen, Konstanten, Strukturen und Dienste

service VS3 {
 void ping()
}

Erzeugen der Sourcen

thrift -r --gen cpp VS3.thrift

Wechsle das Verzeichnis

cd gen-cpp/

Diese Dateien sollten nun vorhanden sein

1. VS3.cpp
2. VS3.h
3. VS3_constants.cpp
4. VS3_constants.h
5. VS3_types.cpp
6. VS3_types.h
7. VS3_server.skeleton.cpp

Kopieren der Serverdatei

cp VS3_server.skeleton.cpp VS3_server.cpp

Erzeugen des Makefile

GEN_SRC := VS3.cpp VS3_constants.cpp VS3_types.cpp
GEN_OBJ := $(patsubst %.cpp,%.o, $(GEN_SRC))

THRIFT_DIR := /usr/local/include/thrift
BOOST_DIR := /usr/local/include

INC := -I$(THRIFT_DIR) -I$(BOOST_DIR)

.PHONY: all clean

all: VS3_server VS3_client

%.o: %.cpp
	$(CXX) -Wall -DHAVE_INTTYPES_H -DHAVE_NETINET_IN_H $(INC) -c $< -o $@

VS3_server: VS3_server.o $(GEN_OBJ)
	$(CXX) $^ -o $@ -L/usr/local/lib -lthrift 

VS3_client: VS3_client.o $(GEN_OBJ)
	$(CXX) $^ -o $@ -L/usr/local/lib -lthrift 

clean:
	$(RM) *.o VS3_server VS3_client

Client implementieren

1. Erstelle eine Datei namens VS3_client.cpp
2. Implementiere die Client-Funktionen

#include "VS3.h"

#include <thrift/protocol/TBinaryProtocol.h>
#include <thrift/transport/TSocket.h>
#include <thrift/transport/TTransportUtils.h>

using namespace std;

using namespace apache::thrift;
using namespace apache::thrift::protocol;
using namespace apache::thrift::transport;

using boost::shared_ptr;

int main() 
{
	try
	{
		shared_ptr<TSocket> socket(new TSocket("localhost", 9090));
		shared_ptr<TTransport> transport(new  TBufferedTransport(socket));
		shared_ptr<TProtocol> protocol(new  TBinaryProtocol(transport));
		VS3Client client(protocol);
		transport->open();

		// Funktionen
		client.ping();

		transport->close();

		// Funktionen
		cout << "Hallo Welt";
	}

	catch(TException &tx) 
	{
		cout << "error calling server: " << tx.what() << endl;
	}
		
	return 0;
}

Baue Client und Server

make

Start Client und Server

./VS3_server
./VS3_client

Quellen

• http://thrift.apache.org/download
• http://thrift.apache.org/docs/install/ubuntu
• http://thrift.apache.org/docs/BuildingFromSource

Der Beitrag Programmieren mit Thrift (Praktikum) erschien zuerst auf Maximilian Krieg.