expertenaustausch > comm.software.* > comm.software.webserver

Jan Novak (17.08.2018, 08:39)
Hallo,

ich habe auf meinem apache2 einen Virtualhost mit letsencrypt
Zertifikat. Soweit so gut.
In der conf Datei sieht es unter anderem so aus:

<VirtualHost [öffentliche IP]:443>
...

Ich möchte nun die Konfiguration verallgemeinern und habe daher das hier
versucht:

<VirtualHost *:443>
...

Unterschied jetzt: Es wird nicht das passende Zertifikat dieser Domain
ausgeliefert, sonder ein "beliebiges", obwohl der Rest der Konfiguration
(vor allem der ssl Teil) unverändert blieb.
Wie kann man das lösen?

Jan
Sven Hartge (17.08.2018, 11:03)
Jan Novak <repcom> wrote:

> ich habe auf meinem apache2 einen Virtualhost mit letsencrypt
> Zertifikat. Soweit so gut.
> In der conf Datei sieht es unter anderem so aus:


> <VirtualHost [öffentliche IP]:443>
> ...


> Ich möchte nun die Konfiguration verallgemeinern und habe daher das hier
> versucht:


> <VirtualHost *:443>
> ...


> Unterschied jetzt: Es wird nicht das passende Zertifikat dieser Domain
> ausgeliefert, sonder ein "beliebiges", obwohl der Rest der Konfiguration
> (vor allem der ssl Teil) unverändert blieb.
> Wie kann man das lösen?


"ServerName vhost-name-her" vergessen?

Ohne das funktioniert Name-based Virtualhosts und damit SNI nicht.

Jan Novak (17.08.2018, 12:40)
Am 17.08.18 um 11:03 schrieb Sven Hartge:
> Jan Novak <repcom> wrote:
> "ServerName vhost-name-her" vergessen?
> Ohne das funktioniert Name-based Virtualhosts und damit SNI nicht.


Hallo,

nein, das steht natürlich auch in der conf drin, hier die anonymisierte
conf Datei:

<VirtualHost [IP]:443>
ServerName [domain]
DocumentRoot [dir]
DirectoryIndex index.php
ErrorDocument 500 /index.php
ErrorDocument 400 /index.php
ErrorDocument 401 /index.php
ErrorDocument 402 /index.php
ErrorDocument 403 /index.php
ErrorDocument 404 /index.php

ErrorLog "/cx/logs/system/apache_ssl_error_log"
TransferLog "/cx/logs/system/apache_ssl_access_log"
CustomLog /cx/logs/biotronik/apache.log combined

SSLEngine on
SSLProtocol all -SSLv2
SSLCertificateFile /etc/letsencrypt/live/[]/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/[]/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

Alias /[alias]/ "[dir]"

<Directory "[dir]">
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
RewriteEngine on
RewriteBase /[name]/
RewriteRule (.*) index.php
</Directory>
</VirtualHost>

<VirtualHost *:80>
ServerAlias [2 aliase]
DocumentRoot [dir]
Alias /[name]/ "[dir]"
RewriteEngine on
RewriteCond %{SERVER_PORT} !^443$
RewriteRule ^/(.*) https://%{HTTP_HOST}/$1 [NC,R=301,L]
<Directory "[dir]">
Options Indexes FollowSymLinks
AllowOverride All
Order allow,deny
Allow from all
</Directory>
</VirtualHost>

Jan
Sven Hartge (17.08.2018, 19:17)
Jan Novak <repcom> wrote:
> Am 17.08.18 um 11:03 schrieb Sven Hartge:


> Hallo,


> nein, das steht natürlich auch in der conf drin, hier die anonymisierte
> conf Datei:


> <VirtualHost [IP]:443>
> ServerName [domain]


[...]

Hmmtja.

Was für ein Apache auf welchem OS ist dies denn? In der Verarbeitung von
Namebased-Virtualhosts hat sich nämlich mit der Zeit einiges geändert.
Früher musste man dies explizit einschalten, später ist es der Default.

Außerdem muss man aufpassen, es gibt auch einen signifikanten
Unterscheid zwischen

<Virtualhost [default]:443>

und

<Virtualhost *:443>

Sven Hartge (17.08.2018, 19:24)
Jan Novak <repcom> wrote:

[..]
> Allow from all
> </Directory>
> </VirtualHost>


BTW:

Durch das Rewrite wird Alias gar nicht ausgewertet, weil alles schon
vorher nach .. umgeschrieben wird.

Den HTTP-VHost auf Port 80 kannst du daher deutlich einfacher gestalten:

<VirtualHost *:80>
ServerAlias [2 aliase]
DocumentRoot [dir]
Redirect permanent /
</VirtualHost>

Das Redirect schreibt auch tiefe Pfade korrekt um, aus
wird also


S°
Jan Novak (20.08.2018, 14:30)
Am 17.08.18 um 19:17 schrieb Sven Hartge:
> Jan Novak <repcom> wrote:


>>> "ServerName vhost-name-her" vergessen?
>>> Ohne das funktioniert Name-based Virtualhosts und damit SNI nicht.


>> nein, das steht natürlich auch in der conf drin, hier die anonymisierte
>> conf Datei:
>> <VirtualHost [IP]:443>


> Hmmtja.
> Was für ein Apache auf welchem OS ist dies denn? In der Verarbeitung von
> Namebased-Virtualhosts hat sich nämlich mit der Zeit einiges geändert.
> Früher musste man dies explizit einschalten, später ist es der Default.


Hier die Versionen:

apachectl -v
Server version: Apache/2.2.26 (Unix)
Server built: Aug 26 2015 12:27:29

cat /etc/os-release
NAME=openSUSE
VERSION="13.2 (Harlequin)"
VERSION_ID="13.2"
PRETTY_NAME="openSUSE 13.2 (Harlequin) (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:13.2"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://opensuse.org/"
ID_LIKE="suse"

> Außerdem muss man aufpassen, es gibt auch einen signifikanten
> Unterscheid zwischen
> <Virtualhost [default]:443>
> und
> <Virtualhost *:443>


oha... das macht es nicht einfacher...

Jan
Jan Novak (20.08.2018, 14:32)
Am 17.08.18 um 19:24 schrieb Sven Hartge:
[..]
> Das Redirect schreibt auch tiefe Pfade korrekt um, aus
> wird also
>


Ja, vielen Dank. Habe ich umgeschrieben. Dieser Teil stammt noch aus der
prä https Zeit und wurde nicht geändert.

Jan
Sven Hartge (20.08.2018, 14:58)
Jan Novak <repcom> wrote:

> apachectl -v
> Server version: Apache/2.2.26 (Unix)
> Server built: Aug 26 2015 12:27:29


Eh. Bei Apache2.2 muss man Namebased-Virtual-Hosting noch separat
aktivieren, wenn meine Erinnerung nicht falsch liegt.

> cat /etc/os-release
> NAME=openSUSE
> VERSION="13.2 (Harlequin)"


Eine ältere Version hast du nicht mehr? 13.2 ist seit Januar 2017 aus
dem Support und bekommt keine Sicherheits-Updates mehr.



Du bist also anfällig gegenüber so ziemlich jedem Exploit, der derzeit
in Umlauf ist.

Update erst einmal auf was aktuelles, da gibt es dann auch Apache2.4 und
das sollte deine Probleme dann auch lösen.

Sven Hartge (20.08.2018, 14:59)
Sven Hartge <sh-188> wrote:
> Jan Novak <repcom> wrote:


>> apachectl -v
>> Server version: Apache/2.2.26 (Unix)
>> Server built: Aug 26 2015 12:27:29


> Eh. Bei Apache2.2 muss man Namebased-Virtual-Hosting noch separat
> aktivieren, wenn meine Erinnerung nicht falsch liegt.


Ja:

S°
Jan Novak (20.08.2018, 15:13)
Am 20.08.18 um 14:58 schrieb Sven Hartge:
> Jan Novak <repcom> wrote:
> Eh. Bei Apache2.2 muss man Namebased-Virtual-Hosting noch separat
> aktivieren, wenn meine Erinnerung nicht falsch liegt.
> Eine ältere Version hast du nicht mehr? 13.2 ist seit Januar 2017 aus
> dem Support und bekommt keine Sicherheits-Updates mehr.


Das ist mir bekannt ... Eine Umstellung ist aber kurzfristig nicht
möglich (interner Produktionsserver) ...

> Du bist also anfällig gegenüber so ziemlich jedem Exploit, der derzeit
> in Umlauf ist.


jahaa, das ist gruselig, wenn ich daran denke ... :-(

> Update erst einmal auf was aktuelles, da gibt es dann auch Apache2.4 und
> das sollte deine Probleme dann auch lösen.


Ich werde nochmal Druck an oberster Stelle machen.

Jan
Sven Hartge (20.08.2018, 15:50)
Jan Novak <repcom> wrote:
> Am 20.08.18 um 14:58 schrieb Sven Hartge:
>> Jan Novak <repcom> wrote:


>>> apachectl -v
>>> Server version: Apache/2.2.26 (Unix)
>>> Server built: Aug 26 2015 12:27:29


>> Eh. Bei Apache2.2 muss man Namebased-Virtual-Hosting noch separat
>> aktivieren, wenn meine Erinnerung nicht falsch liegt.


>>> cat /etc/os-release
>>> NAME=openSUSE
>>> VERSION="13.2 (Harlequin)"


>> Eine ältere Version hast du nicht mehr? 13.2 ist seit Januar 2017 aus
>> dem Support und bekommt keine Sicherheits-Updates mehr.


> Das ist mir bekannt ... Eine Umstellung ist aber kurzfristig nicht
> möglich (interner Produktionsserver) ...


"Kurzfristig?" Das Projekt zur Umstellung hätte vor 2 Jahren
abgeschlossen sein müssen. (Ja, ich kenne deine Schmerzen an der
Stelle.)

Setze das Ding wenigstens hinter eine Firewall und eine RFC1918-IP um
und packe einen modernen Apache oder Nginx als Proxy davor.

Das federt dann wenigstens die gröbsten Probleme ab, die man sich aus
dem Internet so einfängt.

Jan Novak (20.08.2018, 16:03)
Am 20.08.18 um 15:50 schrieb Sven Hartge:
> Jan Novak <repcom> wrote:
> "Kurzfristig?" Das Projekt zur Umstellung hätte vor 2 Jahren
> abgeschlossen sein müssen. (Ja, ich kenne deine Schmerzen an der
> Stelle.)
> Setze das Ding wenigstens hinter eine Firewall und eine RFC1918-IP um
> und packe einen modernen Apache oder Nginx als Proxy davor.


Daran hatte ich auch schon gedacht ... das werde ich mal in einer
ruhigen Minute in einer VM testen.

> Das federt dann wenigstens die gröbsten Probleme ab, die man sich aus
> dem Internet so einfängt.


Hatte gerade ein Gespräch in der Kaffeküche mit einem Chef, der mich
fragte, welche "exploits" denn für den Apache 2.2.x bekannt seien und ob
das real wirklich so ein grosses Problem sein könnte, da es hier in den
letzten 5 Jahren (ich bin erst seit 8 Monaten hier), keine bekannten und
erfolgreichen Angriffe gab (Angriffe gibt es nachweislich und
wissentlich den ganzen Tag, das ist auch der Chefetage bekannt).
Ich konnte ihm dazu zwar keine Antwort geben, jedoch ist auch in der
Chefetage die Sensibilität gestiegen.

Jan
Sven Hartge (20.08.2018, 16:44)
Jan Novak <repcom> wrote:
> Am 20.08.18 um 15:50 schrieb Sven Hartge:


>> Das federt dann wenigstens die gröbsten Probleme ab, die man sich aus
>> dem Internet so einfängt.


> Hatte gerade ein Gespräch in der Kaffeküche mit einem Chef, der mich
> fragte, welche "exploits" denn für den Apache 2.2.x bekannt seien und
> ob das real wirklich so ein grosses Problem sein könnte, da es hier in
> den letzten 5 Jahren (ich bin erst seit 8 Monaten hier), keine
> bekannten und erfolgreichen Angriffe gab (Angriffe gibt es
> nachweislich und wissentlich den ganzen Tag, das ist auch der
> Chefetage bekannt).


Ah, super Argumentation. "Bisher ist nichts passiert, also wird auch in
Zukunft nichts passieren, was soll schon so schlimm sein?" Wenn das ein
Consulting Job wäre, wäre dies der Moment in der ich die Fortführung des
Vertrages ablehnen würde.



Die Frage ist ja nicht, ob der der Apache2 direkt angreifbar ist. Für
das verwendete OpenSSL, gegen das der Apache2 linkt sind definitiv
Angriffe bekannt.

Und je nachdem, in was die Seiten geschrieben sind, die der Apache2
ausliefert kommen noch weitere Lücken hinzu.

Dazu kommt noch, dass IIRC OpenSSL in OpenSUSE 13.2 nichts höheres wie
TLSv1 kann und das soll nach Wünschen der Browser-Hersteller und der
IETF spätestens im nächsten Jahr verbannt werden.

Thomas Gohel (20.08.2018, 17:07)
Hallo Jan,

> Das ist mir bekannt ... Eine Umstellung ist aber kurzfristig nicht
> möglich (interner Produktionsserver) ...


Wo soll da jetzt ein größeres Problem sein, zumal die beiden Apache-
Versionen (2.2 & 2.4) nahezu kompatibel sind, jedenfalls wenn man in
dem 2.4'er Zweig das Kompatibilitätsmodul einbindet.

Tschau,

--------------
/ h o m a s
Jan Novak (22.08.2018, 10:13)
Am 20.08.18 um 16:44 schrieb Sven Hartge:
> Jan Novak <repcom> wrote:
> Ah, super Argumentation. "Bisher ist nichts passiert, also wird auch in
> Zukunft nichts passieren, was soll schon so schlimm sein?" Wenn das ein
> Consulting Job wäre, wäre dies der Moment in der ich die Fortführung des
> Vertrages ablehnen würde.
>


Sehr interessante Seite (nicht nur zum Apache). Habe ich gleich weiter
geleitet :-)

Jan

Ähnliche Themen