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

Scriptsammlung isolierter Vhost

Started by	Tim Ritberg <tim@server.invalid>
First post	2022-06-14 11:17 +0200
Last post	2022-06-22 09:24 +0200
Articles	20 on this page of 53 — 6 participants

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

  Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-14 11:17 +0200
    Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-14 14:07 +0200
      Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-14 15:26 +0200
        Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-14 16:57 +0200
          Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-14 19:25 +0200
            Re: Scriptsammlung isolierter Vhost Karl Pflästerer <k@rl.pflaesterer.de> - 2022-06-15 11:18 +0200
              Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-15 12:21 +0200
                Re: Scriptsammlung isolierter Vhost Karl Pflästerer <k@rl.pflaesterer.de> - 2022-06-15 16:58 +0200
                  Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-15 19:05 +0200
                    Re: Scriptsammlung isolierter Vhost Karl Pflästerer <k@rl.pflaesterer.de> - 2022-06-15 19:43 +0200
                      Re: Scriptsammlung isolierter Vhost Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2022-06-15 18:54 +0000
                        Re: Scriptsammlung isolierter Vhost Karl Pflästerer <k@rl.pflaesterer.de> - 2022-06-15 22:39 +0200
                          Re: Scriptsammlung isolierter Vhost Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) - 2022-06-16 13:25 +0000
                        Re: Scriptsammlung isolierter Vhost Laurenz Trossel <me@example.invalid> - 2022-06-15 23:24 +0000
                      Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-15 21:01 +0200
                        Re: Scriptsammlung isolierter Vhost Karl Pflästerer <k@rl.pflaesterer.de> - 2022-06-15 22:28 +0200
                          Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-15 23:08 +0200
                            Re: Scriptsammlung isolierter Vhost Laurenz Trossel <me@example.invalid> - 2022-06-15 21:32 +0000
                              Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-16 00:35 +0200
                                Re: Scriptsammlung isolierter Vhost Laurenz Trossel <me@example.invalid> - 2022-06-15 23:21 +0000
                                  Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-16 10:50 +0200
                                    Re: Scriptsammlung isolierter Vhost Laurenz Trossel <me@example.invalid> - 2022-06-16 18:04 +0000
                                      Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-17 11:01 +0200
                                        Re: Scriptsammlung isolierter Vhost Laurenz Trossel <me@example.invalid> - 2022-06-17 09:50 +0000
                            Re: Scriptsammlung isolierter Vhost Karl Pflästerer <k@rl.pflaesterer.de> - 2022-06-16 23:51 +0200
                              Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-17 09:33 +0200
                            Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 02:46 +0200
                              Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-21 09:45 +0200
                        Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 02:43 +0200
                      Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-16 20:02 +0200
                        Re: Scriptsammlung isolierter Vhost Karl Pflästerer <k@rl.pflaesterer.de> - 2022-06-16 23:40 +0200
                Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 02:40 +0200
            Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 02:39 +0200
              Re: Scriptsammlung isolierter Vhost Thomas Hochstein <thh@thh.name> - 2022-06-21 07:46 +0200
                Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 19:42 +0200
                  Re: Scriptsammlung isolierter Vhost Laurenz Trossel <me@example.invalid> - 2022-06-21 20:01 +0000
                    Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-22 02:25 +0200
                  Re: Scriptsammlung isolierter Vhost Thomas Hochstein <thh@thh.name> - 2022-07-02 14:19 +0200
                    Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-07-02 14:55 +0200
              Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-21 09:49 +0200
                Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 19:49 +0200
                  Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-21 21:18 +0200
                    Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 21:25 +0200
      Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-18 14:49 +0200
      Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-18 14:52 +0200
        Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 02:53 +0200
          Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-21 10:10 +0200
            Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 19:49 +0200
              Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-21 21:05 +0200
                Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-21 21:19 +0200
                  Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-21 21:55 +0200
                    Re: Scriptsammlung isolierter Vhost Arno Welzel <usenet@arnowelzel.de> - 2022-06-22 02:25 +0200
                      Re: Scriptsammlung isolierter Vhost Tim Ritberg <tim@server.invalid> - 2022-06-22 09:24 +0200

Page 1 of 3 [1] 2 3 Next page →

#1422 — Scriptsammlung isolierter Vhost

From	Tim Ritberg <tim@server.invalid>
Date	2022-06-14 11:17 +0200
Subject	Scriptsammlung isolierter Vhost
Message-ID	<t89jng$3e7t$1@tota-refugium.de>

Hi!

Gibt es/hat jemand Scripte, die mir isolierte Apache-Vhosts anlegen?
Also einen Webuser für ein Verzeichnis und für FPM, dazu die passender 
PHP-config und den Vhost?

Nutzt man da am besten das ITK-MPM?

Tim

[toc] | [next] | [standalone]

#1423

From	Arno Welzel <usenet@arnowelzel.de>
Date	2022-06-14 14:07 +0200
Message-ID	<jgrc02FpkphU1@mid.individual.net>
In reply to	#1422

Tim Ritberg:

> Gibt es/hat jemand Scripte, die mir isolierte Apache-Vhosts anlegen?

Ja. Aber die sind nicht Open Source.

> Also einen Webuser für ein Verzeichnis und für FPM, dazu die passender 
> PHP-config und den Vhost?

Das ist ja nicht allzu schwierig. Was genau fehlt Dir denn dazu?

> Nutzt man da am besten das ITK-MPM?

Nein, tut man nicht. Nicht Apache soll mit einem anderen User laufen,
sondern PHP. Und letzteres erreicht man, indem man PHP-FPM nutzt und den
Pool entsprechend konfiguriert, den gewünschten User zu verwenden.

In Apache nutzt man vorzugsweise mpm_worker oder mpm_event und bindet
PHP über proxy_fcgi ein.

-- 
Arno Welzel
https://arnowelzel.de

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

#1424

From	Tim Ritberg <tim@server.invalid>
Date	2022-06-14 15:26 +0200
Message-ID	<t8a29f$3nnt$1@tota-refugium.de>
In reply to	#1423

Am 14.06.22 um 14:07 schrieb Arno Welzel:
> Tim Ritberg:
> 
>> Gibt es/hat jemand Scripte, die mir isolierte Apache-Vhosts anlegen?
> 
> Ja. Aber die sind nicht Open Source.
Woher?

> 
>> Also einen Webuser für ein Verzeichnis und für FPM, dazu die passender
>> PHP-config und den Vhost?
> 
> Das ist ja nicht allzu schwierig. Was genau fehlt Dir denn dazu?
Zeit

> 
>> Nutzt man da am besten das ITK-MPM?
> 
> Nein, tut man nicht. Nicht Apache soll mit einem anderen User laufen,
> sondern PHP. Und letzteres erreicht man, indem man PHP-FPM nutzt und den
> Pool entsprechend konfiguriert, den gewünschten User zu verwenden.
> 
> In Apache nutzt man vorzugsweise mpm_worker oder mpm_event und bindet
> PHP über proxy_fcgi ein.
> 
Ja nee, ja doch!
Also wie sollen sonst jpg und css ausgeliefert werden?

Tim

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

#1425

From	Arno Welzel <usenet@arnowelzel.de>
Date	2022-06-14 16:57 +0200
Message-ID	<jgrlulFr6cnU1@mid.individual.net>
In reply to	#1424

Tim Ritberg:

> 
> Am 14.06.22 um 14:07 schrieb Arno Welzel:
>> Tim Ritberg:
>>
>>> Gibt es/hat jemand Scripte, die mir isolierte Apache-Vhosts anlegen?
>>
>> Ja. Aber die sind nicht Open Source.
> Woher?

Selbst erstellt.

>>> Also einen Webuser für ein Verzeichnis und für FPM, dazu die passender
>>> PHP-config und den Vhost?
>>
>> Das ist ja nicht allzu schwierig. Was genau fehlt Dir denn dazu?
> Zeit

Kann man ggf. mit Geld ausgleichen - bei mir aber erst wieder nach dem
20. Juni 2022 ;-).

Lieferumfang:

Script, was einen User anlegt, die Apache-VHost-Konfiguration und
PHP-FPM-Konfiguration. Allerdings ohne ITK, da sich das in der Praxis
als unbrauchbar für ernsthaften Betrieb mit mehreren hundert Zugriffen
pro Sekunde erwiesen hat.

>>> Nutzt man da am besten das ITK-MPM?
>>
>> Nein, tut man nicht. Nicht Apache soll mit einem anderen User laufen,
>> sondern PHP. Und letzteres erreicht man, indem man PHP-FPM nutzt und den
>> Pool entsprechend konfiguriert, den gewünschten User zu verwenden.
>>
>> In Apache nutzt man vorzugsweise mpm_worker oder mpm_event und bindet
>> PHP über proxy_fcgi ein.
>>
> Ja nee, ja doch!
> Also wie sollen sonst jpg und css ausgeliefert werden?

Indem Apache sie liest und ausliefert. Leserechte genügend dazu vollkommen.

Generell ist ITK einfach nicht zu empfehlen - BTDT. Spätestens wenn man
mehr als ein paar Dutzend Zugriffe pro Sekunde bedienen will, merkt man
das sehr deutlich. Hinzu kommt, dass dieser "Hack" das letzte Mal vor
über 6(!) Jahren aktualisiert wurde: <http://mpm-itk.sesse.net>



-- 
Arno Welzel
https://arnowelzel.de

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

#1426

From	Tim Ritberg <tim@server.invalid>
Date	2022-06-14 19:25 +0200
Message-ID	<t8agak$410v$1@tota-refugium.de>
In reply to	#1425

Am 14.06.22 um 16:57 schrieb Arno Welzel:
>> Ja nee, ja doch!
>> Also wie sollen sonst jpg und css ausgeliefert werden?
> 
> Indem Apache sie liest und ausliefert. Leserechte genügend dazu vollkommen.
Nicht gut. Würde bedeuten, www-data kann bei einem Angriff auf alle 
Vhosts zugreifen kann.


> 
> Generell ist ITK einfach nicht zu empfehlen - BTDT. Spätestens wenn man
> mehr als ein paar Dutzend Zugriffe pro Sekunde bedienen will, merkt man
> das sehr deutlich. Hinzu kommt, dass dieser "Hack" das letzte Mal vor
> über 6(!) Jahren aktualisiert wurde: <http://mpm-itk.sesse.net>
Das ist jetzt aber wirklich schlecht. s.o.

Tim

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

#1427

From	Karl Pflästerer <k@rl.pflaesterer.de>
Date	2022-06-15 11:18 +0200
Message-ID	<m14k0m9tdw.fsf@mbp.pflaesterer.de>
In reply to	#1426

Tim Ritberg <tim@server.invalid> writes:

> Am 14.06.22 um 16:57 schrieb Arno Welzel:
>>> Ja nee, ja doch!
>>> Also wie sollen sonst jpg und css ausgeliefert werden?
>> Indem Apache sie liest und ausliefert. Leserechte genügend dazu vollkommen.
> Nicht gut. Würde bedeuten, www-data kann bei einem Angriff auf alle Vhosts
> zugreifen kann.

Wie meinst du das?
jeder VHost hat ein einen DocumentRoot. Wenn du nicht zu sehr mit Alias,
Symlinks mod_rewrite spielst gibt es da auch keine Lücken.
www_data darf nur lesen nicht schreiben.
Also an welche Art von Angriff denkst du?

Ich erstelle hier auch VHosts und fpm_config automatisiert. Ist kein
Hexenwerk. Unter Ubuntu/Debian gibt es /etc/php/8.0/fpm/pool.d/
In dieses Verzeichnis kommen per Ansible Symlinks auf die Pool Confifs
jedes einzelnen Webprozesses. Deploymnet per Ansible hier ist so, das
geschaut wird, welche Pool Configs existieren und je Pool Conig kommt
ein Symlink in pool.d. Anscjließned startet Ansible den Fpm Daemin neu.
In der Pool Config stehen die Adressen der Unix Domain Sockets über die
der datentransfer läuft. jeder Apche VHost hat einen eigenen Pool mit
eigenem Socket.

Das ist hier ganz praktisch, weil das Deployment der Webserver Config
nicht mit Root Rechten erfolgen muss. Die Erstellung der Symlinks
allerdings schon.

Ein ähnliches Vorgehen gibt es auch für Nginx und fpm.

>
>
>> Generell ist ITK einfach nicht zu empfehlen - BTDT. Spätestens wenn man
>> mehr als ein paar Dutzend Zugriffe pro Sekunde bedienen will, merkt man
>> das sehr deutlich. Hinzu kommt, dass dieser "Hack" das letzte Mal vor
>> über 6(!) Jahren aktualisiert wurde: <http://mpm-itk.sesse.net>
> Das ist jetzt aber wirklich schlecht. s.o.
>
> Tim

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

#1428

From	Tim Ritberg <tim@server.invalid>
Date	2022-06-15 12:21 +0200
Message-ID	<t8cbrd$4rq6$1@tota-refugium.de>
In reply to	#1427

Am 15.06.22 um 11:18 schrieb Karl Pflästerer:
> Tim Ritberg <tim@server.invalid> writes:
> 
>> Am 14.06.22 um 16:57 schrieb Arno Welzel:
>>>> Ja nee, ja doch!
>>>> Also wie sollen sonst jpg und css ausgeliefert werden?
>>> Indem Apache sie liest und ausliefert. Leserechte genügend dazu vollkommen.
>> Nicht gut. Würde bedeuten, www-data kann bei einem Angriff auf alle Vhosts
>> zugreifen kann.
> 
> Wie meinst du das?
> jeder VHost hat ein einen DocumentRoot. Wenn du nicht zu sehr mit Alias,
> Symlinks mod_rewrite spielst gibt es da auch keine Lücken.
> www_data darf nur lesen nicht schreiben.
> Also an welche Art von Angriff denkst du?
Durchhangeln auf andere Vhost. www-data kann ja an alle Installationen.
Bei ITK ist das nicht möglich, weil die "Apache-childs" mit 
verschiedenen Usern laufen. Da müsste man schon in den Elternprozess 
(root) ausbrechen.

> 
> Ich erstelle hier auch VHosts und fpm_config automatisiert. Ist kein
> Hexenwerk. Unter Ubuntu/Debian gibt es /etc/php/8.0/fpm/pool.d/
> In dieses Verzeichnis kommen per Ansible Symlinks auf die Pool Confifs
> jedes einzelnen Webprozesses. Deploymnet per Ansible hier ist so, das
> geschaut wird, welche Pool Configs existieren und je Pool Conig kommt
> ein Symlink in pool.d. Anscjließned startet Ansible den Fpm Daemin neu.
> In der Pool Config stehen die Adressen der Unix Domain Sockets über die
> der datentransfer läuft. jeder Apche VHost hat einen eigenen Pool mit
> eigenem Socket.
Bash wäre mir lieber.

Tim

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

#1429

From	Karl Pflästerer <k@rl.pflaesterer.de>
Date	2022-06-15 16:58 +0200
Message-ID	<m1zgie7z3t.fsf@mbp.pflaesterer.de>
In reply to	#1428

Tim Ritberg <tim@server.invalid> writes:

> Am 15.06.22 um 11:18 schrieb Karl Pflästerer:
>> Tim Ritberg <tim@server.invalid> writes:
>> 
>>> Am 14.06.22 um 16:57 schrieb Arno Welzel:
>>>>> Ja nee, ja doch!
>>>>> Also wie sollen sonst jpg und css ausgeliefert werden?
>>>> Indem Apache sie liest und ausliefert. Leserechte genügend dazu vollkommen.
>>> Nicht gut. Würde bedeuten, www-data kann bei einem Angriff auf alle Vhosts
>>> zugreifen kann.
>> Wie meinst du das?
>> jeder VHost hat ein einen DocumentRoot. Wenn du nicht zu sehr mit Alias,
>> Symlinks mod_rewrite spielst gibt es da auch keine Lücken.
>> www_data darf nur lesen nicht schreiben.
>> Also an welche Art von Angriff denkst du?
> Durchhangeln auf andere Vhost. www-data kann ja an alle Installationen.
> Bei ITK ist das nicht möglich, weil die "Apache-childs" mit verschiedenen
> Usern laufen. Da müsste man schon in den Elternprozess (root) ausbrechen.

Und wie soll das gehen?

VHost 1
<VirtualHost *:443>
ServerName vhost1
DocumeentRoot /opt/www/vhost1
<Directory "/opt/www/vhost1">
    AllowOverride None
    Require all granted
</Directory>
</VirtualHost>


VHost 2
<VirtualHost *:443>
ServerName vhost2
DocumeentRoot /opt/www/vhost2
<Directory "/opt/www/vhost2">
    AllowOverride None
    Require all granted
</Directory>
</VirtualHost>


In der httpd.conf hast du
<Directory />
    AllowOverride none
    Require all denied
</Directory>


Wie kann sich jetzt "durchhangeln"?  Wenn du davon ausgehst, dass man
auf VHost1 eine Webshell hochladen und ausführen konnte, kommt es auf
die Nutzerrechte der anderen Installationen eher weniger an. Schaden ist
auch so schon da.
Umn zu wissen, was du verhindern willst, fehlt die konkrete Beschreibung
des Angriffs.




>
>> Ich erstelle hier auch VHosts und fpm_config automatisiert. Ist kein
>> Hexenwerk. Unter Ubuntu/Debian gibt es /etc/php/8.0/fpm/pool.d/
>> In dieses Verzeichnis kommen per Ansible Symlinks auf die Pool Confifs
>> jedes einzelnen Webprozesses. Deploymnet per Ansible hier ist so, das
>> geschaut wird, welche Pool Configs existieren und je Pool Conig kommt
>> ein Symlink in pool.d. Anscjließned startet Ansible den Fpm Daemin neu.
>> In der Pool Config stehen die Adressen der Unix Domain Sockets über die
>> der datentransfer läuft. jeder Apche VHost hat einen eigenen Pool mit
>> eigenem Socket.
> Bash wäre mir lieber.

Hält dich doch niemand von ab. Wenn es nur ein oder 2 Server sind, die
du betreust, ist das problemlos machbar.
Wenn du etwas Spieltrieb hast, nimmst du m4 für die Templates. Ansonsten
geht zur Not auch bash und sed. Hängt halt sehr davon ab, wie du
arbeitest



  KP

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

#1430

From	Tim Ritberg <tim@server.invalid>
Date	2022-06-15 19:05 +0200
Message-ID	<t8d3hb$5bg5$1@tota-refugium.de>
In reply to	#1429

Am 15.06.22 um 16:58 schrieb Karl Pflästerer:

> 
> 
> Wie kann sich jetzt "durchhangeln"?  Wenn du davon ausgehst, dass man
> auf VHost1 eine Webshell hochladen und ausführen konnte, kommt es auf
> die Nutzerrechte der anderen Installationen eher weniger an. Schaden ist
> auch so schon da.
> Umn zu wissen, was du verhindern willst, fehlt die konkrete Beschreibung
> des Angriffs.
Ich meinte einen Angriff auf den Prozess httpd (apache2).


> 
> Hält dich doch niemand von ab. Wenn es nur ein oder 2 Server sind, die
> du betreust, ist das problemlos machbar.
> Wenn du etwas Spieltrieb hast, nimmst du m4 für die Templates. Ansonsten
> geht zur Not auch bash und sed. Hängt halt sehr davon ab, wie du
> arbeitest
m4...da fällt mir sendmail ein. Aber richtig hatte ich damit nie zutun.

Tim

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

#1431

From	Karl Pflästerer <k@rl.pflaesterer.de>
Date	2022-06-15 19:43 +0200
Message-ID	<m1v8t1961d.fsf@mbp.pflaesterer.de>
In reply to	#1430

Tim Ritberg <tim@server.invalid> writes:

> Am 15.06.22 um 16:58 schrieb Karl Pflästerer:
>
>> 
>> Wie kann sich jetzt "durchhangeln"?  Wenn du davon ausgehst, dass man
>> auf VHost1 eine Webshell hochladen und ausführen konnte, kommt es auf
>> die Nutzerrechte der anderen Installationen eher weniger an. Schaden ist
>> auch so schon da.
>> Umn zu wissen, was du verhindern willst, fehlt die konkrete Beschreibung
>> des Angriffs.
> Ich meinte einen Angriff auf den Prozess httpd (apache2).

Und wie genau?

>
>> Hält dich doch niemand von ab. Wenn es nur ein oder 2 Server sind, die
>> du betreust, ist das problemlos machbar.
>> Wenn du etwas Spieltrieb hast, nimmst du m4 für die Templates. Ansonsten
>> geht zur Not auch bash und sed. Hängt halt sehr davon ab, wie du
>> arbeitest
> m4...da fällt mir sendmail ein. Aber richtig hatte ich damit nie zutun.


Das einzige Programm mit turing vollständiger Config Sprache :-)
Wie gesagt, würde ich nehmen, wenn ich auch Spaß dabei haben wollte.

Wenn nicht ist ein kleines Perl/Python Skript besser

ZB in Perl:

#!/usr/bin/perl

use strict;
use warnings;
my $base = '/path/to/dir';
my $dst_base = $base . 'devel/';
my $templatefile = $ARGV[0] || $base . 'vhost-devel-template.conf';
(my $ntemplate = $templatefile) =~ s/template/%s/;
$ntemplate = $dst_base . (split /\//, $ntemplate)[-1];
my @names = map { m/_devel-([^\/]+)/ }  < '/path/to/dir/_devel*' >;

open my $fh, '<', $templatefile or die "$templatefile $!";

my $template = do { local ($/); <$fh> };
close $fh;

for my $name (@names) {
  open my $fh, '>', sprintf($ntemplate, $name) or die sprintf($ntemplate.$!, $name);
  my $text = $template;
  $text =~ s/{NAME}/\U$name/g;
  $text =~ s/{name}/\L$name/g;
  print $fh $text;
  close $fh;
}


Das erstellt VHost dateien für Entwickler. Die Namen sind aus
Verzeichnisnamen ermittelbar. Je Name werden Platzhalter im Tempalte
ersetzt. Wenn du mehr Platzhalter benötigst einfach noch ein paar s///,
Zeilen rein. Platzhalter ist {name} und {NAME} um den gleichen wert
definiert groß- oder kleingeschrieben auszugeben. Das gleiche gibt es
auch als Python Variante. 


  KP

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

#1432

From	Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich)
Date	2022-06-15 18:54 +0000
Message-ID	<1t62aa29d9i1a75c8n3e8%sfroehli@Froehlich.Priv.at>
In reply to	#1431

On Wed, 15 Jun 2022 19:43:10 Karl Pflästerer wrote:
> #!/usr/bin/perl
> 
> use strict;
> use warnings;
> my $base = '/path/to/dir';
> my $dst_base = $base . 'devel/';
> my $templatefile = $ARGV[0] || $base . 'vhost-devel-template.conf';
> (my $ntemplate = $templatefile) =~ s/template/%s/;
> $ntemplate = $dst_base . (split /\//, $ntemplate)[-1];
> my @names = map { m/_devel-([^\/]+)/ }  < '/path/to/dir/_devel*' >;
> 
> open my $fh, '<', $templatefile or die "$templatefile $!";
> 
> my $template = do { local ($/); <$fh> };
> close $fh;
> 
> for my $name (@names) {
>   open my $fh, '>', sprintf($ntemplate, $name) or die sprintf($ntemplate.$!, $name);
>   my $text = $template;
>   $text =~ s/{NAME}/\U$name/g;
>   $text =~ s/{name}/\L$name/g;
>   print $fh $text;
>   close $fh;
> }

> Das erstellt VHost dateien für Entwickler.

Das erinnert mich daran, dass ich irgendwann in den 90ern einmal
eine umfangreichere Apachekonfiguration erstellt habe, die (via
mod_perl) den Code *innerhalb* der Konfiguration stehen hatte.

Im Grund genommen lief das ähnich wie von Dir skizziert, nur
brauchte man nicht als Zwischenschritt Config-Dateien zu erstellen,
die anschließend eingebunden wurde, sondern die Konfiguration
generierte sich gewissermaßen on-the-fly selbst.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Schmusen mit Stefan - reizvoll werden mit Eleganz.
(Sloganizer)

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

#1435

From	Karl Pflästerer <k@rl.pflaesterer.de>
Date	2022-06-15 22:39 +0200
Message-ID	<m1mted8xv8.fsf@mbp.pflaesterer.de>
In reply to	#1432

Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) writes:

> On Wed, 15 Jun 2022 19:43:10 Karl Pflästerer wrote:
>> #!/usr/bin/perl
>> 
>> use strict;
>> use warnings;
>> my $base = '/path/to/dir';
>> my $dst_base = $base . 'devel/';
>> my $templatefile = $ARGV[0] || $base . 'vhost-devel-template.conf';
>> (my $ntemplate = $templatefile) =~ s/template/%s/;
>> $ntemplate = $dst_base . (split /\//, $ntemplate)[-1];
>> my @names = map { m/_devel-([^\/]+)/ }  < '/path/to/dir/_devel*' >;
>> 
>> open my $fh, '<', $templatefile or die "$templatefile $!";
>> 
>> my $template = do { local ($/); <$fh> };
>> close $fh;
>> 
>> for my $name (@names) {
>>   open my $fh, '>', sprintf($ntemplate, $name) or die sprintf($ntemplate.$!, $name);
>>   my $text = $template;
>>   $text =~ s/{NAME}/\U$name/g;
>>   $text =~ s/{name}/\L$name/g;
>>   print $fh $text;
>>   close $fh;
>> }
>  
>> Das erstellt VHost dateien für Entwickler.
>
> Das erinnert mich daran, dass ich irgendwann in den 90ern einmal
> eine umfangreichere Apachekonfiguration erstellt habe, die (via
> mod_perl) den Code *innerhalb* der Konfiguration stehen hatte.

So was hatte ich früher auch mal (noch Apsche 1.3.xx und mod perl 1)
Fand es aber übersichtlicher die Configs mit Präprozessor automatisch zu
erstellen und dann die ganze Logik in Apache Handler zu packen. mod_perl
war super aber bis es mit Apache 2.4 kompatibel war, dauerte es zu
lange.
Heute nutze ich mod_lua wo es sinnvoll ist. Logik im Server zu haben.
Ohne mod_perl ist Apache deutlich stabiler. Lua hat einen Bruchteil der
Größe von Perl.
Die mod_perl Adaption ging gefühlt seit Apache 2 sehr zurück. Das Tolle
von mod_perl (die enge Integration mit Apache, der Zugriff auf alle
handler Phasen, die man sonst nur mit C erreichte), war auch das Problem
als ide interne Apache API sich von 1.3 zu Apache 2 so massiv ämderte.
Die man power fehlte zeitnah mod_perl weiter zu entwicklen.

> Im Grund genommen lief das ähnich wie von Dir skizziert, nur
> brauchte man nicht als Zwischenschritt Config-Dateien zu erstellen,
> die anschließend eingebunden wurde, sondern die Konfiguration
> generierte sich gewissermaßen on-the-fly selbst.

Ich hatte ziemlich viel mit mod_perl gemacht; den dynamischen Config
Teil fanf ich nie so überzeugend verglchen damit, die Config Dateien
zuvor aus templates zu erstellen (sofern zur Compile Zeit die notwendige
Information bekannt ist).

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

#1442

From	Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich)
Date	2022-06-16 13:25 +0000
Message-ID	<bt62ab2e0ci1db2dfn3e8%sfroehli@Froehlich.Priv.at>
In reply to	#1435

On Wed, 15 Jun 2022 22:39:39 Karl Pflästerer wrote:
> Stefan+Usenet@Froehlich.Priv.at (Stefan Froehlich) writes:
>> Das erinnert mich daran, dass ich irgendwann in den 90ern einmal
>> eine umfangreichere Apachekonfiguration erstellt habe, die (via
>> mod_perl) den Code *innerhalb* der Konfiguration stehen hatte.

> So was hatte ich früher auch mal (noch Apsche 1.3.xx und mod perl
> 1) Fand es aber übersichtlicher die Configs mit Präprozessor
> automatisch zu erstellen und dann die ganze Logik in Apache
> Handler zu packen. mod_perl war super aber bis es mit Apache 2.4
> kompatibel war, dauerte es zu lange.

Ich würde das heute auch nicht mehr so machen - zumal, weil ich für
den Inhalt aller vhosts auf meinem Server selber verantwortlich bin
und daher deren Konfiguration dort am besten aufgehoben ist. In der
Praxis habe ich ein <Macro>, mit dem sich >90% der Fälle abbilden
lassen, damit reicht mir je vhost ein Einzeiler.

Wäre ich, so wie damals, lediglich für den friktionsfreien Betrieb
vom Apache zuständig, würde ich vielleicht immer noch die Logik
direkt in die Konfiguration packen, weil mir so am schwersten jemand
etwas kaputtmachen kann. Das war damals vielleicht nicht sehr
elegant, aber unglaublich effizient - ich musste das Teil über viele
Monate hinweg so gut wie nicht mehr angreifen.

Und da ich den Anwendungsfall hier nicht im Detail kenne... besser
man weiss, welche Optionen überhaupt zur Verfügung stehen.

Servus,
   Stefan

-- 
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich
Offizieller Erstbesucher(TM) von mmeike

Egal ob Kanzler oder Kuli: Stefan - drei mal täglich!
(Sloganizer)

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

#1440

From	Laurenz Trossel <me@example.invalid>
Date	2022-06-15 23:24 +0000
Message-ID	<t8dpnu$8pv$1@gioia.aioe.org>
In reply to	#1432

On 2022-06-15, Stefan Froehlich <Stefan+Usenet@Froehlich.Priv.at> wrote:

> Das erinnert mich daran, dass ich irgendwann in den 90ern einmal
> eine umfangreichere Apachekonfiguration erstellt habe, die (via
> mod_perl) den Code *innerhalb* der Konfiguration stehen hatte.

https://www.varnish-software.com/developers/tutorials/varnish-configuration-language-vcl/

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

#1433

From	Tim Ritberg <tim@server.invalid>
Date	2022-06-15 21:01 +0200
Message-ID	<t8dab4$5gb1$1@tota-refugium.de>
In reply to	#1431

Am 15.06.22 um 19:43 schrieb Karl Pflästerer:
> Tim Ritberg <tim@server.invalid> writes:
> 
>> Am 15.06.22 um 16:58 schrieb Karl Pflästerer:
>>
>>>
>>> Wie kann sich jetzt "durchhangeln"?  Wenn du davon ausgehst, dass man
>>> auf VHost1 eine Webshell hochladen und ausführen konnte, kommt es auf
>>> die Nutzerrechte der anderen Installationen eher weniger an. Schaden ist
>>> auch so schon da.
>>> Umn zu wissen, was du verhindern willst, fehlt die konkrete Beschreibung
>>> des Angriffs.
>> Ich meinte einen Angriff auf den Prozess httpd (apache2).
> 
> Und wie genau?

Man nennt es "bug".

https://www.zdnet.com/article/apache-web-server-bug-grants-root-access-on-shared-hosting-environments/

Tim

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

#1434

From	Karl Pflästerer <k@rl.pflaesterer.de>
Date	2022-06-15 22:28 +0200
Message-ID	<m1r13p8yd1.fsf@mbp.pflaesterer.de>
In reply to	#1433

Tim Ritberg <tim@server.invalid> writes:

> Am 15.06.22 um 19:43 schrieb Karl Pflästerer:
>> Tim Ritberg <tim@server.invalid> writes:
>> 
>>> Am 15.06.22 um 16:58 schrieb Karl Pflästerer:
>>>
>>>>
>>>> Wie kann sich jetzt "durchhangeln"?  Wenn du davon ausgehst, dass man
>>>> auf VHost1 eine Webshell hochladen und ausführen konnte, kommt es auf
>>>> die Nutzerrechte der anderen Installationen eher weniger an. Schaden ist
>>>> auch so schon da.
>>>> Umn zu wissen, was du verhindern willst, fehlt die konkrete Beschreibung
>>>> des Angriffs.
>>> Ich meinte einen Angriff auf den Prozess httpd (apache2).
>> Und wie genau?
>
> Man nennt es "bug".
>
> https://www.zdnet.com/article/apache-web-server-bug-grants-root-access-on-shared-hosting-environments/

Ja und? Du verwendest lieber eine alte nicht mehr gewartete Apache
Extension (letzte Version 2016) als Apache mit aktuell betreuten
Modulen, bei denen man eher davon ausgehen kann, das Bugs gefunden und
behoben werden? Verstehe ich nicht.
Geteilte VHosts würde ich immer nur bei VHosts machen, die unter einer
gemeinsamen Kontrolle stehen. Bei "feindlichen" Auftritten muss die
Trennung strikter sein (mit zB Docker Container kein so großer
Overhead). Mit chroot kann auch weit kommen, wenn man Prozesse trenne
will.

  KP

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

#1436

From	Tim Ritberg <tim@server.invalid>
Date	2022-06-15 23:08 +0200
Message-ID	<t8dho3$5kl1$1@tota-refugium.de>
In reply to	#1434

Am 15.06.22 um 22:28 schrieb Karl Pflästerer:
>> Man nennt es "bug".
>>
>> https://www.zdnet.com/article/apache-web-server-bug-grants-root-access-on-shared-hosting-environments/
> 
> Ja und? Du verwendest lieber eine alte nicht mehr gewartete Apache
> Extension (letzte Version 2016) als Apache mit aktuell betreuten
> Modulen, bei denen man eher davon ausgehen kann, das Bugs gefunden und
> behoben werden? Verstehe ich nicht.
Ich merks. Scheint heut nicht dein Tag zu sein.

> Geteilte VHosts würde ich immer nur bei VHosts machen, die unter einer
> gemeinsamen Kontrolle stehen. Bei "feindlichen" Auftritten muss die
> Trennung strikter sein (mit zB Docker Container kein so großer
> Overhead). Mit chroot kann auch weit kommen, wenn man Prozesse trenne
> will.
Feindlich hin oder her, Security per Design, alles mit www-data laufen 
zu lassen ist dumm.
Der Ansatz von ITK ist gar nicht schlecht. Ob das Releasedatum eine 
Rolle spielt, weiss ich nicht. Jedenfalls hat Debian einen Maintainer dafür.

Tim

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

#1437

From	Laurenz Trossel <me@example.invalid>
Date	2022-06-15 21:32 +0000
Message-ID	<t8dj5l$4c0$1@gioia.aioe.org>
In reply to	#1436

On 2022-06-15, Tim Ritberg <tim@server.invalid> wrote:

> Feindlich hin oder her, Security per Design, alles mit www-data laufen 
> zu lassen ist dumm.
> Der Ansatz von ITK ist gar nicht schlecht. Ob das Releasedatum eine 
> Rolle spielt, weiss ich nicht. Jedenfalls hat Debian einen Maintainer dafür.

Dir ist aber schon aufgefallen, daß im ITK-Modell das kritische Parsen der 
Requests als root passiert? Damit hat jeder Bug in diesem Teil die 
Möglichkeit, das gesamte System zu übernehmen.

Wenn du die vhosts so weit isolieren willst, dann steck jeden in einen 
eigenen Container und setze einen Proxy davor. Alles andere ist Gebastel.

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

#1438

From	Tim Ritberg <tim@server.invalid>
Date	2022-06-16 00:35 +0200
Message-ID	<t8dmsc$5nbb$1@tota-refugium.de>
In reply to	#1437

Am 15.06.22 um 23:32 schrieb Laurenz Trossel:
> Dir ist aber schon aufgefallen, daß im ITK-Modell das kritische Parsen der
> Requests als root passiert? Damit hat jeder Bug in diesem Teil die
> Möglichkeit, das gesamte System zu übernehmen.
Na dann ein anderes Modul mit User-Change. Leider gibts  mod_privileges 
nur für Solaris.
mpm-peruser ist uralt und mod_unixd scheint es für Debian gar nicht zu 
geben. Komisch...

Tim

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

#1439

From	Laurenz Trossel <me@example.invalid>
Date	2022-06-15 23:21 +0000
Message-ID	<t8dphu$797$1@gioia.aioe.org>
In reply to	#1438

On 2022-06-15, Tim Ritberg <tim@server.invalid> wrote:

> Na dann ein anderes Modul mit User-Change. Leider gibts  mod_privileges 
> nur für Solaris.
> mpm-peruser ist uralt und mod_unixd scheint es für Debian gar nicht zu 
> geben. Komisch...

Praktisch jeder user-change erfordert einen Weg über Code, der mit 
root-Rechten agiert. Du erwartest etwas von Apache, für das es nicht 
ausgelegt ist.

Du kannst jedem vhost einen eigenen httpd-Prozess geben. Das hilft im Falle 
eines Bugs auch nur begrenzt, wenn alle im selben System laufen. Wer Code 
ausführen kann, kann auch uid 0 erreichen.

Warum willst du lieber mit exotischem Snakeoil hantieren anstatt zu 
containern?

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

Page 1 of 3 [1] 2 3 Next page →

csiph-web

Scriptsammlung isolierter Vhost

Contents

#1422 — Scriptsammlung isolierter Vhost

#1423

#1424

#1425

#1426

#1427

#1428

#1429

#1430

#1431

#1432

#1435

#1442

#1440

#1433

#1434

#1436

#1437

#1438

#1439