Kontakt
Einfach Suchbegriff eingeben und Enter drücken
Abbrechen

Am häufigsten gestellte Fragen

Frequently Asked Questions

Neueste FAQ-Einträge

Der einfache Aufruf von "pkg audit" schlägt fehl, weil versucht wird eine Liste der bekannten Sicherheitslücken herunterzuladen und dafür standardmässig ein Pfad benutzt wird, der hier nur read-only verfügbar ist. Diesen Pfad kann man aber beim Aufruf übersteuern.

Mit folgendem Aufruf

 pkg audit -F -f /tmp/audit.txt

wird die Datei mit den Sicherheitslücken abweichend als /tmp/audit.txt gespeichert, wobei Name und Pfad natürlich frei wählbar sind, sofern das Zielverzeichnis existiert und beschreibbar ist.

Der Parameter -F bewirkt, das eine ggf. schon vorhandene Datei ignoriert und die Liste neu geholt wird; sinnvollerweise wirft man die Datei dann nach Gebrauch auch weg.

Hier gibt es zwei Vorgehensmöglichkeiten, die auch kombiniert werden können:

Datei-/Verzeichnis-rechte

Auf dem proServer läuft die Webserver-Software (nginx oder apache) mit der User-Id www, während die PHP-Skripten mit der User-Id proserver ausgeführt werden. Alle Dateien im Webserververzeichnis gehören dem Benutzer proserver. Damit der Webserver direkt auf eine Datei oder ein Verzeichnis zugreifen kann, müssen die entsprechenden Rechte für "alle" gesetzt sein. Wenn eine Datei statt dessen nur Zugriffsrechte für den Eigentümer und ggf. die Gruppe gesetzt hat, ist der Zugriff nur über PHP-skripten, also z.B. das jeweils verwendete CMS möglich.

Beispiel:

In Ihrem Webserververzeichnis haben Sie ein Verzeichnis namens fileadmin/downloads mit Dateien, die nur über ein Download-Script mit Authentifizierung zugreifbar sein sollen. Dann setzen Sie die Dateirechte für das Verzeichnis wie folgt:

[proserver@vproXXXX:~]$ chmod 750 fileadmin/downloads
[proserver@vproXXXX:~]$ ls -ld fileadmin/downloads
drwxr-x---  2 proserver  proserver  2 22 Nov. 11:58 fileadmin/downloads

Webserver-Konfiguration

Apache

Apache erlaubt es, mit Hilfe von .htaccess-Dateien den Zugriff auf Dateien oder Pfade innerhalb der Website zu beschränken. Frameworks wie TYPO3 liefern üblicherweise auch passende Vorlagen mit, die man (ggf. nach Anpassung an die Gegebenheiten der eigenen Website) verwenden kann.

nginx

Der nginx Webserver versteht keine .htaccess-Dateien; Zugriffsbeschränkungen müssen daher in der eigentlichen Webserver-Konfiguration untergebracht werden. Vom TYPO3 Projekt gibt es Vorschläge für eine Musterkonfiguration, welche wir zukünftig bei neu bestellten proServern in der Datei /usr/local/etc/nginx/Includes/typo3.conf mit ausliefern werden. Für bereits bestehende proServer müssten Sie diese Konfiguration selbst in die passende Datei übernehmen; in beiden Fällen sollten Sie jedoch die Konfiguration überprüfen, inwieweit hier für Ihre Website Anpassungen notwendig sind.

Sofern IPv6-Konnektivität besteht, kann eine Verbindung zum proServer2G direkt aufgebaut werden. Andernfalls muss der Zugriff durch einen sogenannten Jumphost getunnelt werden. Dies wird in der Praxis meist durch einen passenden Eintrag in der ~/.ssh/config-Datei des Entwicklers geregelt, ist jedoch auch manuell über entsprechende Aufrufparameter möglich. Für die folgenden Beispiele verwenden wir als Beispiel den vproWXYZ als Host und Nutzernamen.

Beispiel für ssh über Jumphost mit expliziten Parametern:

ssh -J jumping@ssh-jumphost.karlsruhe.punkt.de vproWXYZ@vproWXYZ.proserver.punkt.de

Beispiel für das Hochladen von datei.tar via Jumphost mit expliziten Parametern:

scp -o ProxyJump=jumping@ssh-jumphost.karlsruhe.punkt.de datei.tar.gz vproWXYZ@vproWXYZ.proserver.punkt.de:

In der Regel günstiger ist es, einen Eintrag wie folgt in ~/.ssh/config anzulegen:

Host vproWXYZ
      HostName vproWXYZ.proserver.punkt.de
      User vproWXYZ
      ProxyJump jumping@ssh-jumphost.karlsruhe.punkt.de

Damit reicht dann für den ssh-Zugriff ein einfaches

ssh vproWXYZ

Hintergrund

Der globale Pool an freien IPv4-Adressen, aus dem Provider bei Bedarf weitere Adressen anfordern konnten, ist seit Januar 2011 erschöpft. Der für unsere Region zuständige regionale Pool ist im September 2012 auf einen kritischen Wert geschrumpft; seit dieser Zeit kann jeder registrierte Provider noch einmalig einen Block von ca. 1000 IPv4-Adressen anfordern, weitere IPv4 Adressen sind nicht mehr verfügbar. Einige Provider die noch über unbenutzte IPv4 Adressen verfügen sind bereit diese zu verkaufen; oft wurden diese Adressen aber vorher für Spam und Verbreitung von Schadsoftware benutzt und werden vielerorts ausgefiltert.

Die meisten Internet-Anbieter stehen daher vor der Herausforderung, mit dem vorhandenen Bestand an IPv4 Adressen mehr Dienste als zuvor, also z.B. zusätzliche Websites, anzubieten. Der Ansatz der punkt.de ist es hier, Dienste weitestmöglich auf den Betrieb mit IPv6 zu verlagern, wo Adressen praktisch unbegrenzt zur Verfügung stehen. Die 2. Generation unserer proServer ist ein Ergebnis dieser Bemühungen.

Überblick des Systemaufbaus

Die vpro-Container

Dies sind wie bisher eigenständige virtuelle Maschinen mit der Funktionalität eines kompletten Betriebssystems. Jedoch verfügt die virtuelle Maschine nur noch über eine externe IPv6-Adresse und keine Legacy-IP-Adresse (IPv4-Adresse) mehr.

Die gate64-Container

Dies sind eigenständige virtuelle Maschinen, welche für jeweils mehrere vpro-Container die Verbindung mit dem Legacy-IP-Netz herstellen. Diese gate64-Container verfügen jeweils über eine IPv6- und eine IPv4-Adresse. Ausgehende Verbindungen, also solche die vom vproXXXX aus initiiert werden, sind darüber zu beliebigen Zielen im IPv4 Bereich möglich. Eingehende Verbindungen, also aus dem (IPv4-)Internet auf den vproXXXX sind nur auf den Ports 80 (HTTP) und 443 (HTTPS) möglich.

Der ssh-jumphost

Dies ist ebenfalls eine eigenständige Maschine mit je einer IPv4- und einer IPv6-Adresse. Mit diesem Host als Zwischenstation ist ein ssh/scp-Zugriff auf den vproXXXX auch für diejenigen Entwickler möglich, die nur IPv4 Zugriff auf das Internet haben.

Was sich für den Admin/Entwickler ändert

DNS-Einträge

Jedem vproXXXX-Container ist ein "zuständiger" gate64-Container zugeordnet. Die IPv4-Adresse dieses gate64-Containers teilen wir Ihnen beim Einrichten eines vpro-Containers mit. Für die auf dem vpro gehosteten Websites tragen Sie im DNS jeweils einen AAAA-Record mit der IPv6-Adresse des vproXXXX und einen A-Record mit der IPv4-Adresse des zugeordneten gate64-Containers ein.

Achtung: Im Unterschied zur 1. Generation der proServer ist der AAAA-Record im DNS jetzt zwingend erforderlich, da der gate64-Container über diesen DNS-Eintrag erfährt, auf welchem vproXXXX sich eine darüber angesprochene Website befindet.

Zugriff vom vpro-Container auf Resourcen im IPv4-Internet

Falls der Zugriff auf die externe Resource über einen Hostnamen im DNS erfolgt, ist für den Entwickler nichts weiter zu beachten: Der auf dem vpro verwendete Nameserver liefert für Resourcen, die nur IPv4-Adressen haben eine "synthetische IPv6-Adresse" zurück, welche dann über ein sogenanntes NAT64-Gateway (auf dem zugeordneten gate64-Host) geführt und dort nach IPv4 übersetzt wird. Aus Sicht des proServers erfolgt die Kommunikation also per IPv6, die Übersetzung auf dem gate64 ist für den proServer nicht sichtbar.

Erfolgt der Zugriff über IPv4-Adressliterale (also direkt eine numerische IPv4-Adresse), so muss ein solches Literal auf die zugehörige IPv6-Adresse umgeschrieben werden. Dies geht durch das Voranstellen des Präfix 64:ff9b::/96. So würde beispielsweise aus der IPv4-Adresse 192.0.2.3 die "synthetische" IPv6-Adresse [64:ff9b::192.0.2.3], das Ergebnis wird dann wie ein IPv6 Adressliteral verwendet. Um das Zielsystem anzupingen, würde man also

ping6 64:ff9b::192.0.2.3

aufrufen.

Einschränkungen

Es gibt einige betriebliche Einschränkungen dadurch, dass aus dem IPv4-Internet eingehende Verbindungen nur über Port 80 und 443 (sowie 22/ssh via Jumphost) möglich sind.

  • Websites können nur auf port 80 (HTTP) und 443 (HTTPS) liegen. Diese Einschränkung gilt nicht für interne Adressen auf dem vpro oder private Verbindungsstrecken zwischen mehreren vpro-Containern, und natürlich auch nicht für Verbindungen über IPv6.
  • Mailversand vom vpro ist möglich, zu IPv4-Zielen erfolgt er über das NAT64 Gateway. Mailempfang aus dem Internet geht auf dem vpro aber nur per IPv6 oder über einen vorgelagerten Dual-Stack Mailserver.

Falls diese Einschränkungen ein Problem für Ihre Anwendung darstellen, sprechen Sie uns bitte an. Gemeinsam werden wir eine Lösung finden.

Auf jedem neu erstellten proServer finden sich zwei Benutzer, für die die bei der Bestellung angegebenen public-keys hinterlegt wurden.

Zum einen der Benutzer vproXXXX. Dieser kann sudo ohne Passwort aufrufen und dient der Anpassung des Servers selbst und dessen Konfigurationsdateien. Dieser Benutzer ist nicht dafür vorgesehen, dass über diesen deployed oder für die Anwendung notwendige Komponenten mittels npm nachinstalliert werden.

Für diesen Zweck gibt es den Benutzer proserver. Dieser darf kein sudo und ist damit auf sein Home-Verzeichnis unter /var/www beschränkt. Jedoch wird PHP als dieser Benutzer ausgeführt, womit eine einfache Administration Ihrer Anwendung gewährleistet wird.

Des weiteren findet sich noch der Benutzer www auf dem System. Nginx / Apache laufen  als dieser Benutzer auf dem proServer. www ist in keiner weiteren Gruppe und  hat auch keine erweiterten Rechte. Falls die Dateien Ihrer Anwendung nicht global lesbar sind, sondern nur für den Besitzer selbst und die Gruppe der Datei, so muss der Benutzer www noch in der Datei /etc/group in die Gruppe proserver aufgenommen werden.

Login als Benutzer vproXXXX:

ssh vproXXXX@vproXXXX.proserver.punkt.de

Installation der Neos-Distribution über composer als Benutzer proserver:

sudo -u proserver composer create-project --no-dev neos/neos-base-distribution /var/www/neos

Cache-Warmup durchführen:

sudo -u proserver sh -c "cd /var/www/neos/ && ./flow neos.flow:cache:warmup"

Nginx-Konfiguration für Neos einbinden:

sudo sed -i conf 's/welcome/neos/' /usr/local/etc/nginx/vhosts/ssl.conf
sudo service nginx reload

Schließlich den NEOS-Installationsprozess über die URL des Servers aufrufen.

Das geforderte MySQL/MariaDB-root-Passwort wird ausgegeben mit:

sudo cat /usr/local/etc/mysql-password

Ja, ein proServer kann in den Auslieferungszustand versetzt werden - mit einer Einschränkung: Wir entwicklen die proServer-Plattform fortwährend weiter. Es ist daher möglich, dass sich an den ausgelieferten Basis-Konfigurationen Änderungen ergeben haben.

Wir arbeiten mit Hochdruck daran, auch auf hosting.punkt.de Domainkäufe möglich zu machen. Derzeit können Sie Domains über das Pluspunkthosting-Interface beziehen.

Zum Pluspunkthosting:

Derzeit liefern wir alle proServer mit den Einstellungen für die Let's Encrypt Staging-Server aus, da für die Domain punkt.de das Kontingent an Zertifikaten für Subdomains aufgebraucht ist.

Um die Let's Encrypt Live-Server zu verwenden muss in /usr/local/etc/dehydrated/config die CA auf https://acme-v01.api.letsencrypt.org/directory geändert werden.

Die gewünschten Domains werden in die Datei domains.txt eingetragen. Dabei müssen alle Domains, für die ein einzelnes (Multidomain-)Zertifikat beantragt werden soll, in eine Zeile geschrieben und nur durch ein Leerzeichen getrennt werden. Wildcardzertifikate sind derzeit noch nicht möglich.

$ cat /var/www/letsencrypt/domains.txt

example.org www.example.org
example.com www.example.com wiki.example.com

Um die Beantragung eines SSL Zertifikats mit Let's Encrypt durchzuführen muss der DNS Eintrag dieser Domain bereits auf den proServer zeigen.

Anschließend muss noch ein Cronjob aktiviert werden:

$ sudo crontab -u root -e

# Dehydrated Cronjob
PATH=/bin:/usr/bin:/usr/local/bin
@weekly /usr/local/bin/dehydrated -c -g

Jetzt müssen nur noch die Zertifikate beantragt und die entsprechenden Domains in die Webserver Konfiguration eingetragen werden:

$ sudo dehydrated -c

Fertig. Die neu generierten Zertifikate befinden sich nun unter dem Pfad /usr/local/etc/ssl/certs/<domainname>/

Weitere Informationen zu dem von uns eingesetzten Tool gib es auf Github oder auf letsencrypt.org.

SSH-Schlüsselpaar erstellen

Diese Anleitung bezieht sich auf unixoide Betriebssysteme wie zB. Linux und OS X (macOS)

Im ersten Schritt wechseln wir in das Home-Verzeichnis des eigenen Users und rufen den SSH-Schlüsselgenerator so auf.

Die Optionen -t rsa und -b 4096 sorgen dafür, das ein Schlüsselpaar mit der RSA und 4096 bit erstellt wird.

$ cd ~
$ ssh-keygen -t rsa -b 4096

Bevor das eigentliche Schlüsselpaar generiert wird, fragt das Programm ein paar Dinge ab.

Generating public/private rsa key pair.

Enter file in which to save the key (/Users/yourname/.ssh/id_rsa):

Hier kann man einen anderen Speicherort und Dateinamen für sein Schlüsselpaar angeben. Dies ist in den meisten Fällen nicht notwenig.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

Nun kann man sich entscheiden, ob man sein Schlüsselpaar mit einem zusätzlichen Passwort sichern möchte. Dieses muss bei Verwendung des Schlüsselpaares eingegeben werden.

Wenn man kein Passwort haben möchte, gibt man nichts ein und drückt zweimal [Enter].

Your identification has been saved in /Users/yourname/.ssh/id_rsa.

Your public key has been saved in /Users/yourname/.ssh/id_rsa.pub.

The key fingerprint is:

SHA256:IF5HF7KJHhn5qnP23nQGngPXAlgELeFvrtGtP5UQaXo
yourname@computername.local

The key's randomart image is:
+---[RSA 4096]----+
|  oB= **o.       |
| .+=.oEB+o       |
|..+.*+Boo        |
|.. =.=oo         |
|  . = .oS        |
|   o o.o         |
|  .   + o        |
|... .o o         |
|oo ..oo          |
+----[SHA256]——+

Das Schlüsselpaaar wurde erstellt und im eigenen Home-Verzeichnis in den Ordner .ssh abgelegt.

Das Paar besteht aus einem öffentlichen (id_rsa.pub) und einem privaten Schlüssel (id_rsa).

WICHTIG: Derprivate Teil des Schlüsselpaares sollte niemals in fremde Hände gelangen. Ein Verschicken, z.B. in einer E-mail kann dazu führen, dass Ihre Schlüssel abgefangen und für illegale Aktivitäten benutzt wird.

$ls ~/.ssh
id_rsa		id_rsa.pub

SSH-Schlüsselpaar auf einen Server übertragen

Jetzt muss der öffentliche Schlüssel nur noch auf den Server:

cat ~/.ssh/id_rsa.pub | ssh vpro0000@vpro0000.proserver.punkt.de "cat >>  ~/.ssh/authorized_keys"

Dies funktioniert natürlich erst wenn man bereits Zugang zu einem Server hat. Also wenn man z.B. einen zweiten Schlüssel dort ablegen will.