Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.webserver > #1266 > unrolled thread

Aoache virtualhost SSL Fehler wenn ohne IP

Back to article view | Back to de.comm.software.webserver

Contents

  Aoache virtualhost SSL Fehler wenn ohne IP Jan Novak <repcom@gmail.com> - 2018-08-17 08:39 +0200
    Re: Aoache virtualhost SSL Fehler wenn ohne IP Sven Hartge <sh-188@svenhartge.de> - 2018-08-17 11:03 +0200
      Re: Aoache virtualhost SSL Fehler wenn ohne IP Jan Novak <repcom@gmail.com> - 2018-08-17 12:40 +0200
        Re: Aoache virtualhost SSL Fehler wenn ohne IP Sven Hartge <sh-188@svenhartge.de> - 2018-08-17 19:17 +0200
          Re: Aoache virtualhost SSL Fehler wenn ohne IP Jan Novak <repcom@gmail.com> - 2018-08-20 14:30 +0200
            Re: Aoache virtualhost SSL Fehler wenn ohne IP Sven Hartge <sh-188@svenhartge.de> - 2018-08-20 14:58 +0200
              Re: Aoache virtualhost SSL Fehler wenn ohne IP Sven Hartge <sh-188@svenhartge.de> - 2018-08-20 14:59 +0200
              Re: Aoache virtualhost SSL Fehler wenn ohne IP Jan Novak <repcom@gmail.com> - 2018-08-20 15:13 +0200
                Re: Aoache virtualhost SSL Fehler wenn ohne IP Sven Hartge <sh-188@svenhartge.de> - 2018-08-20 15:50 +0200
                  Re: Aoache virtualhost SSL Fehler wenn ohne IP Jan Novak <repcom@gmail.com> - 2018-08-20 16:03 +0200
                    Re: Aoache virtualhost SSL Fehler wenn ohne IP Sven Hartge <sh-188@svenhartge.de> - 2018-08-20 16:44 +0200
                      Re: Aoache virtualhost SSL Fehler wenn ohne IP Jan Novak <repcom@gmail.com> - 2018-08-22 10:13 +0200
                        Re: Aoache virtualhost SSL Fehler wenn ohne IP Sven Hartge <sh-188@svenhartge.de> - 2018-08-22 13:53 +0200
                          Re: Aoache virtualhost SSL Fehler wenn ohne IP Jan Novak <repcom@gmail.com> - 2018-08-23 13:17 +0200
                            Re: Aoache virtualhost SSL Fehler wenn ohne IP Sven Hartge <sh-188@svenhartge.de> - 2018-08-23 14:17 +0200
                Re: Aoache virtualhost SSL Fehler wenn ohne IP Thomas Gohel <gohel@basicguru.de> - 2018-08-20 17:07 +0200
        Re: Aoache virtualhost SSL Fehler wenn ohne IP Sven Hartge <sh-188@svenhartge.de> - 2018-08-17 19:24 +0200
          Re: Aoache virtualhost SSL Fehler wenn ohne IP Jan Novak <repcom@gmail.com> - 2018-08-20 14:32 +0200
          Re: Aoache virtualhost SSL Fehler wenn ohne IP Jan Novak <repcom@gmail.com> - 2018-09-13 11:08 +0200
            Re: Aoache virtualhost SSL Fehler wenn ohne IP Sven Hartge <sh-189@svenhartge.de> - 2018-09-13 14:42 +0200

#1266 — Aoache virtualhost SSL Fehler wenn ohne IP

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

[toc] | [next] | [standalone]

#1267

Jan Novak <repcom@gmail.com> 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.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#1268

Am 17.08.18 um 11:03 schrieb Sven Hartge:
> Jan Novak <repcom@gmail.com> 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.

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

[toc] | [prev] | [next] | [standalone]

#1269

Jan Novak <repcom@gmail.com> wrote:
> Am 17.08.18 um 11:03 schrieb Sven Hartge:
>> Jan Novak <repcom@gmail.com> 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.

> 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>

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#1271

Am 17.08.18 um 19:17 schrieb Sven Hartge:
> Jan Novak <repcom@gmail.com> 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.

>> 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

[toc] | [prev] | [next] | [standalone]

#1273

Jan Novak <repcom@gmail.com> 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.

https://de.opensuse.org/Produktlebensdauer

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.

S°
-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#1274

Sven Hartge <sh-188@svenhartge.de> wrote:
> Jan Novak <repcom@gmail.com> 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: https://httpd.apache.org/docs/2.2/en/vhosts/name-based.html

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#1275

Am 20.08.18 um 14:58 schrieb Sven Hartge:
> Jan Novak <repcom@gmail.com> 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) ...


> 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

[toc] | [prev] | [next] | [standalone]

#1276

Jan Novak <repcom@gmail.com> wrote:
> Am 20.08.18 um 14:58 schrieb Sven Hartge:
>> Jan Novak <repcom@gmail.com> 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.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#1277

Am 20.08.18 um 15:50 schrieb Sven Hartge:
> Jan Novak <repcom@gmail.com> wrote:
>> Am 20.08.18 um 14:58 schrieb Sven Hartge:
>>> Jan Novak <repcom@gmail.com> 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.

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

[toc] | [prev] | [next] | [standalone]

#1278

Jan Novak <repcom@gmail.com> 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.

https://www.cvedetails.com/product/66/Apache-Http-Server.html?vendor_id=45

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.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#1280

Am 20.08.18 um 16:44 schrieb Sven Hartge:
> Jan Novak <repcom@gmail.com> 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.
> 
> https://www.cvedetails.com/product/66/Apache-Http-Server.html?vendor_id=45

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

Jan

[toc] | [prev] | [next] | [standalone]

#1281

Jan Novak <repcom@gmail.com> wrote:
> Am 20.08.18 um 16:44 schrieb Sven Hartge:
>> Jan Novak <repcom@gmail.com> 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.
>> 
>> https://www.cvedetails.com/product/66/Apache-Http-Server.html?vendor_id=45

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

Dazu kommt natürlich folgendes:

Die Chance, dass jemand einen Fehler findet, behebt und dann auch prüft,
ob dieser Fehler so oder so ähnlich auch in älteren Versionen vorhanden
ist, sinkt natürlich mit der Zeit immer weiter. Auf nahe Null, sobald
die älteren Version nicht mehr offiziell gewartet werden.

Somit besteht eine nicht gerade kleine Chance, dass die Apache2.4-Fehler
auch auf Apache2.2 funktionieren, es sich nur niemand den Aufwand
gemacht hat, das zu verifizieren.

Alles in allem also ein heikles Spiel, vor allem bei Angriffen, die
keinen Log-Eintrag o.ä. hinterlassen aber dennoch funktioniert haben.

Da bekommst du dann gar nicht mit, dass das System dir gar nicht mehr
gehört. Die Aussage "ist bisher nichts passiert" halte ich daher für ein
wenig sehr weit aus dem Fenster gelehnt.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#1282

Am 22.08.18 um 13:53 schrieb Sven Hartge:
>>> https://www.cvedetails.com/product/66/Apache-Http-Server.html?vendor_id=45
> 
>> Sehr interessante Seite (nicht nur zum Apache). Habe ich gleich weiter
>> geleitet :-)
> 
> Dazu kommt natürlich folgendes:
> 
> Die Chance, dass jemand einen Fehler findet, behebt und dann auch prüft,
> ob dieser Fehler so oder so ähnlich auch in älteren Versionen vorhanden
> ist, sinkt natürlich mit der Zeit immer weiter. Auf nahe Null, sobald
> die älteren Version nicht mehr offiziell gewartet werden.

... stimmt unbestreitbar ...

> Die Aussage "ist bisher nichts passiert" halte ich daher für ein
> wenig sehr weit aus dem Fenster gelehnt.

Ich pflichte dir 100%ig bei. Ich kann die Leitung nur darauf hinweisen.

Dennoch sei an zu merken, dass die Software leider nicht einfach so 
umgestellt werden kann, weil der Apache seinerzeit mit eigenen 
Erweiterungen kompiliert wurde und nicht bin-kompatibel zum Repository ist.

Ich hatte dem Unternehmen in einer VM deren Lösung auf Standard Paketen 
der Distribution vorgeführt (mit sehr viel Anpassungen). Leider lief 
alles nur 99%ig ...und somit nicht (in deisem Moment) einsetzbar.
Seis drum, ich habe es schriftlich an die Leitung weiter gegeben. Nun 
heisst es abwarten ...

Jan

[toc] | [prev] | [next] | [standalone]

#1283

Jan Novak <repcom@gmail.com> wrote:

> Dennoch sei an zu merken, dass die Software leider nicht einfach so 
> umgestellt werden kann, weil der Apache seinerzeit mit eigenen 
> Erweiterungen kompiliert wurde und nicht bin-kompatibel zum Repository ist.

Ja, dann sind die Schmerzen, wenn man sich selbst in einen Wall-Garden
einmauert.

Wie schon vorgeschlagen wäre mein erster Schritt, das System in eine DMZ
zu sperren, einen Proxy davor zu schalten, damit Angriffe auf das
HTTP-Protokoll und SSL erst einmal abgeblockt oder zumindest deutlich
erschwert werden.

Das ermöglicht dann auch eine einfachere Migration auf ein neues System,
welches man dann erst einmal abgesichert intern aufsetzen kann und
dann einfach den Proxy umbiegt, sobald man es produktiv nehmen will.
(Und wenn dann doch etwas nicht funktioniert, dann schaltet man den
Proxy auf das alte System zurück und keinem fällt etwas auf.)

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#1279

Hallo Jan,

>>> 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) ...

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
-- 
Permanent Online Filter fuer: User ohne Realnamen im From:-Feld, Full-
quotes (zitieren  des originalen  Postings unter der eigenen Antwort),
Visitenkarten, HTML-Postings, Invalid- und ungueltige Email-Adressen

[toc] | [prev] | [next] | [standalone]

#1270

Jan Novak <repcom@gmail.com> wrote:

> <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>

BTW:

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

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

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

Das Redirect schreibt auch tiefe Pfade korrekt um, aus
http://hostname.hier/foo/bar/baz wird also
https://hostname.hier/foo/bar/baz

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [next] | [standalone]

#1272

Am 17.08.18 um 19:24 schrieb Sven Hartge:
> Jan Novak <repcom@gmail.com> wrote:
> 
>> <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>
> 
> BTW:
> 
> Durch das Rewrite wird Alias gar nicht ausgewertet, weil alles schon
> vorher nach https://... umgeschrieben wird.
> 
> Den HTTP-VHost auf Port 80 kannst du daher deutlich einfacher gestalten:
> 
> <VirtualHost *:80>
>    ServerAlias [2 aliase]
>    DocumentRoot [dir]
>    Redirect permanent / https://hostname.hier/
> </VirtualHost>
> 
> Das Redirect schreibt auch tiefe Pfade korrekt um, aus
> http://hostname.hier/foo/bar/baz wird also
> https://hostname.hier/foo/bar/baz

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

Jan

[toc] | [prev] | [next] | [standalone]

#1284

Am 17.08.18 um 19:24 schrieb Sven Hartge:
> Jan Novak <repcom@gmail.com> wrote:
> 
>> <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>
> 
> BTW:
> 
> Durch das Rewrite wird Alias gar nicht ausgewertet, weil alles schon
> vorher nach https://... umgeschrieben wird.
> 
> Den HTTP-VHost auf Port 80 kannst du daher deutlich einfacher gestalten:
> 
> <VirtualHost *:80>
>    ServerAlias [2 aliase]
>    DocumentRoot [dir]
>    Redirect permanent / https://hostname.hier/
> </VirtualHost>

Brauche ich tatsächlich auch DocumentRoot ?

jan

[toc] | [prev] | [next] | [standalone]

#1285

Jan Novak <repcom@gmail.com> wrote:
> Am 17.08.18 um 19:24 schrieb Sven Hartge:

>> Den HTTP-VHost auf Port 80 kannst du daher deutlich einfacher gestalten:
>> 
>> <VirtualHost *:80>
>>    ServerAlias [2 aliase]
>>    DocumentRoot [dir]
>>    Redirect permanent / https://hostname.hier/
>> </VirtualHost>

> Brauche ich tatsächlich auch DocumentRoot ?

Wenn du es nicht angibst, dann wird das aus der globalen Konfiguration
genommen.

Ich habe dafür immer ein Dummy-Verzeichnis nach der Methode
"/srv/www/dummy", welches einfach eine leere index.html enthält, das ich
dort angebe, um nicht ausversehen durch einen Fehler doch Dinge
freizugeben.

S°

-- 
Sigmentation fault. Core dumped.

[toc] | [prev] | [standalone]

Back to top | Article view | de.comm.software.webserver

csiph-web