Blog

tags: software deutsch opensource apache howto vserver


18.Aug.2017 16:08 - last update: 28.May.2018 08:34

mein Projekt vServer - 1 - Apache

So langsam läuft der neue vServer stabil und offenbar auch sicher. Bislang konnte ich noch keine Anomalien feststellen. Da ich im Moment gerade mal keine Lust mehr hab an diversen .conf Dateien rumzuschrauben, fang ich endlich mal meine kleine Dokumentation dazu an.

Auf meinem vServer läuft ein Debian 9 auf 64bit mit 4 virtuellen CPUs und 12GB RAM. Also halbwegs viel Power für eine Handvoll kleiner Musikerseiten. Zur Installation des gewählten Betriebssystems will ich an dieser Stelle nicht viele Worte verlieren, da das IMHO im Netz bereits ausreichend beschrieben wurde. Kommen wir also zur Sache!

Ich arbeite hier ausschließlich als root. Falls jemand sudo bevorzugt, der stelle vor jedes Kommando eben jenes sudo! Mir persönlich ist das zuviel Tipperei...
Außerdem bevorzuge ich aptitude über apt-get bzw apt. Das ist zwar mehr Tipperei, aber aptitude scheint über eine bessere Auflösung der Abhängigkeiten zu verfügen. Der geneigte Leser möge hier bitte das Paketverwaltungsprogramm seiner Wahl benutzen! ?

Apache

Installiert wird der Apache mit folgendem unscheinbaren Einzeiler:

aptitude install apache2

Optional kann man sich auch die Dokumentation dazu mit installieren: (in meinen Augen überflüssig, da das auch nur die Kopie der Onlinedokumentation ist.)

aptitude install apache2 apache2-doc

Und schon sitzt der Indianer friedlich rauchend in seinem Wigwam und wartet auf eingehende Anfragen. Jetzt braucht er allerdings auch Antworten (sprich Webseiten). Für den Anfang ist eine Standardseite installiert (/var/www/index.html, die die ordnungsgemäße Funktion des Apachen bescheinigt. Gibt man jetzt im Browser die IP des vServers ein, so kann man diese bestaunen.

/etc/apache2/apache2.conf

Die Hauptkonfigurationsdatei des HTTPservers (Apache) liegt im Verzeichnis /etc/apache2/apache2.conf. Diese kann man eigentlich erstmal in Ruhe lassen. Nur die folgende Einstellung empfehle ich zu überdenken: (Zeile 170)

<Directory /var/www/>
	Options Indexes FollowSymLinks
	AllowOverride None
	Require all granted
</Directory>

In meinem Falle habe ich das geändert zu:

<Directory /var/www/vhosts>
	Options Indexes MultiViews
	AllowOverride All
	Require all granted
</Directory>

Dies bewirkt, das die auszuliefernden Webseiten nicht im Verzeichnis /var/www, sondern in /var/www/vhosts gesucht werden. So kann man das Verzeichnis /var/www/ noch für andere Dinge nutzen, z.Bsp. für .htpasswd Dateien, ohne daß diese Gefahr laufen ausgeliefert zu werden.
AllowOverride None blockiert die Möglichkeit, daß .htaccess Dateien überhaupt erst gelesen und geachtet werden. (Siehe dazu auch Thomas' Kommentare)

Außerdem sollte man darauf achten, daß die folgenden Zeilen in dieser Form auftauchen: (bei mir ab Zeile 191)

#
# The following lines prevent .htaccess and .htpasswd files from being
# viewed by Web clients.
#
<FilesMatch "^\.ht">
	Require all denied
</FilesMatch>

weitere confs

Die weiterhin wichtigsten Verzeichnisse und darin enthaltenen Configs sind:

  • /etc/apache2/sites-available
  • /etc/apache2/mods-available
  • /etc/apache2/conf-available
Dort liegen die verfügbaren Webseiten, Module und Konfigurationen. Diese können mittels a2ensite, a2enmod und a2enconf bzw a2dissite, a2dismod und a2disconf aktiviert bzw deaktiviert werden (enable / disable).

Gibt man einen dieser Befehle ohne weitere Spezifikation ein, so erscheint eine Liste der verfügbaren Optionen und man wird gefragt welche Option denn nun die gewünschte wäre. Praktisches kleines Tool!

Module

Wichtig erschienen mir folgende Module: (die anderen waren schon aktiv)

  • ssl
  • rewrite
  • security2
rewrite ermöglicht Umleitungen z.Bsp. von http nach https, die anderen sollten halbwegs selbsterklärend sein... Falls nicht, hilft die Suchmaschine des Vertrauens sicher gerne weiter! ?

Daraus ergibt sich: mit dem Befehl

a2enmod ssl
läßt sich das SSL-Modul vom Apachen aktivieren und mit
a2dismod ssl
läßt es sich wieder deaktivieren.
Mit
aptitude search libapache2-mod
kann man eventuell noch fehlende Module finden, z.Bsp. PHP (doch dazu mehr in einem nächsten Artikel).

Eine Webseite aktivieren

Hier fängt alles mit der Webseite selbst an. Diese muß nun an Ort und Stelle kopiert werden. In unserem Falle nach /var/www/vhosts/example.com. Anschließend muß eine Konfigurationsdatei in /etc/apache2/sites-available erstellt werden. Am Besten nach dem Muster example.com.conf. Als Vorlage kann man die vorinstallierte Datei 000-default.conf nehmen:

cp /etc/apache2/sites-available/000-default.conf /etc/apache2/sites-available/example.com.conf
Diese Datei muß nun noch angepaßt werden! Ich lasse mal einfach alle auskommentierten Zeilen weg und zeige hier, wie so eine Datei aussehen könnte. Ich denke die wichtigen Stellen sieht man selbst!

<VirtualHost *:80>
	ServerName example.com
	ServerAlias www.example.com
	ServerAdmin webmaster@example.com
	DocumentRoot /var/www/vhosts/example.com
	ErrorLog ${APACHE_LOG_DIR}/error.log
	CustomLog ${APACHE_LOG_DIR}/access.log combined
</VirtualHost>

Jetzt noch ein beherztes

a2ensite example.com
um die Seite zu aktivieren, gefolgt von einem
systemctl restart apache2
um den Apache mit der neuen Konfiguration neu zu starten, und schon wäre die Seite "example.com" online - zumindest per http! Wie das mit der Verschlüsselung von statten geht wird in einem anderen Artikel folgen.

Fazit:

So ein Indianer ist relativ schnell und einfach eingerichtet, so daß er auf Anfrage eine Webseite ausliefert. Zum Thema Sicherheit desselben habe ich schon mal einen Artikel geschrieben. Weiterhin verweise ich hier nur noch mal auf die .htaccess Firewall 5G und ein Update zur Version 6G.


Na denn, ich freue mich auf eure Kommentare und werde sicherlich hier und da noch entsprechend nachbessern... ☮

Jruß,
chris




comments

1) Thomas

18.Aug.2017 17:30

AllowOverride All aktiviert die Möglichkeit, daß .htaccess Dateien überhaupt erst gelesen und geachtet werden.


das ist falsch.

AllowOverride All sollte man auf keinen Fall verwenden, sondern lieber die benötigten Optionen aufzählen, die man benötigt. FollowSymLinks ist auch extrem ungut.

2) chris_blues

18.Aug.2017 17:31

Hm, wie würdest du denn so einen AllowOverride setzen?

Was ist an FollowSymLinks so problematisch? Abgesehen davon, wenn man keine symlinks nach /usr oder irgendwohin setzt? Symlinks sind doch ne tolle Sache...

3) Thomas

18.Aug.2017 17:43

z.B.
AllowOverride AuthConfig Limit FileInfo Indexes Options

bzw. je nachdem was du brauchst und nicht mehr als nötig erlauben. Mit "All" kann man quasi alles via .htaccess überschreiben und das will man nicht. "All" macht man in der Regel nur aus Faulheit.

Naja, so kann man z.b. einfach einen symlink auf eine beliebige Datei im Systembaum setzen. Stimmen dann die Rechte nicht hat man Pech. Eventuell lieber SymLinksIfOwnerMatch, bzw. würde ich zum Thema Apache absichern einfach noch ein bisschen googlen, da gibt es einiges was man beachten sollte.

Man muss es dem ersten Otto der Deinen Webserver hackt ja nicht zu einfach machen ;-)

4) chris_blues

18.Aug.2017 17:49

Ah verstehe. Naja, da müßte ich aber erstmal noch ein bißchen forschen, um da eine gute Vorlage zu ersinnen.

Ok, dann werd ich mal den FollowSymLinks rausnehmen... Leute in die Traufe schicken, ist ne blöde Sache. ☢ (Verstehe nur nicht, warum das in der default so drin steht, wenn das so risikoreich ist ? )

5) Tux.

18.Aug.2017 19:06

Schade, schon wieder Linux.

6) chris_blues

18.Aug.2017 20:00

Ach, ich hab vor ner Weile openBSD probiert und habs wieder aufgegeben. Ist schon mächtig anders! Klar gibts auch viele Ähnlichkeiten, aber vieles hab ich einfach nicht hinbekommen... Das wär mal wieder so'n langfristiges Projekt, wenn ich viel Zeit hab. Da gibts wieder mal viel zu lesen! ?

7) Julius

21.Aug.2017 18:35

Moin!

Statt domain.de sollte man als Beispiel-Domain eine der dafür Vorgesehenen und Reservierten nutzen. (Auch in den Kommantar-Eingabefeldern, wie ich gerade sehe...)

Julius

8) chris_blues

21.Aug.2017 23:00

Hast ja recht... ?

post a comment








😀😁😂😃😄😅😆😇😈😉😊😋😌😍😎😏😐😑😒😓😔😕😖😗😘😙😚😛😜😝😞😟😠😡😢😣😤😥😦😧😨😩😪😫😬😭😮😯😰😱😲😳😴😵😶😷🙁🙂🙃🙄🙅🙆🙇🙈🙉🙊🙋🙌🙍🙎🤐🤑🤒🤓🤔🤕🤖🤗🤘🤠🤡🤢🤣🤤🤥🤦🤧👍𝄞🌍🌹🍻🍾

privacy declaration

Your IP-address, useragent-string etc are not stored by this blog-software. Still, it is possible that the hoster of this website may store data like this. But that is beyond the scope of this blog-software. Check out this website's privacy declaration to find out more about that!

This blog-software generally doesn't store any information about you. Only if you post a comment, some data will have to be stored. You don't have to input any personal information here. Except for the comment itself, all fields are optional!
If you don't want to tells us your name, that's fine. It will be shown as 'anonymous'.
If you want to receive notifications on following comments, naturally you'll have to give us your email address. It will be stored and not be shared with anybody. If you don't want to be notified, just leave the notifications field empty.
If you want your name to be linked to your website, you'll have to give us your site's address. Otherwise leave this field empty.

This data will be stored in case you decide to post a comment here:

  • time and date of your post
  • your name (if supplied)
  • your email (if supplied)
  • your website (if supplied)
  • your comment
  • some technical information unrelated to you, like which blogpost this comment belongs to and a unique id for this comment