Website-Hiding

[Abakus]

Ich weiß nicht ob es diesen Begriff schon gibt, aber ich taufe es mal "Website-Hiding"

Die Situation am Beispiel:

Als Twitch-Streamer im Bereich Linux und Server muss man oft sicherheitskritische Tätigkeiten erledigen.
Es wäre für den Streamer eine Hilfe wenn er etwas Zeit bekommen würde, um bei einen Fehler - wie zum Beispiel ein versehentliches 'leaken' eines Passwortes - reagieren zu können. Eine Variante ist das "verstecken" eines Servers, so das der mögliche Angreifer zwar eine Passwort-Information bekommen hat, aber damit nicht sofort Schaden anrichten kann, weil er nicht genau weiß "wo" der Server zu finden ist.

Die Aufgabe:
Gegeben sei ein professioneller root-Server bei einem Provider im Internet. Auf diesem läuft ein Web-Server-Dienst. Hier existieren mehrere virtuelle Sub-Domänen.
Wenn der Twitch-Streamer zum Beispiel in seinem Browser diesen Webserver anwählt, kann der Twitch-Zuschauer diese URL erkennen, und mit genügend negativer Energie Schaden anrichten.
Meine Idee war nun, ob es vielleicht möglich wäre diese URL unkenntlich zu machen. Oder eine Fake-URL anzuzeigen. Könnte es nicht möglich sein, auf dem lokalen Computer einen Web-Server zu installieren, und so zu konfigurieren, dass der Stream-Zuschauer in der Browser-Adressleiste, nur die lokale URL sieht, während im Hintergrund der lokale Webserver (z.B. als reverse-proxy eingerichtet, und mit Rewrite-Regeln) die Verbindung zum entfernen Web-Server übernimmt.
Und so kann der Twitch-Streamer ein klein wenig entspannter mit sensiblen Daten umgehen.

Ich habe nun Abende daran gearbeitet, aber habe es nicht hinbekommen.
Ich will zu meiner Verteidigung aber auch bemerken, dass ich kein apache2-Experte bin.
Die Apache2 conf's sind aber auch lange nicht so kompliziert wie eine sendmail-config.
Als Systemadministrator sage ich gerne zu meinen Azubis:

"Du darfst Dich nur SysAdmin nennen, wenn Du eine Sendmail-Conf von Hand eingegeben hast. Aber auch selber Schuld bist, wenn Du es ein zweites mal machst"

Jetzt meine Frage: "Ist diese Aufgabe/Idee überhaut so machbar?

Aba Kus

[uname]

Ich denke du verfolgst den falschen Ansatz. Erst mal solltest du davon ausgehen, dass eine aktuelle und korrekt konfigurierte Software keine für deinen Anwendungsfall relevanten Sicherheitsrisiken hat. Das Problem des Passwortes kannst du auch auf andere Bereiche übertragen. Dort besteht deine Forderung auch nicht. Bzgl. Verbesserung von Authentisierung gegenüber Passwörtern wird meist 2FA oder Client-Zertifikate verwendet. Alles andere ist eher nur eine Verscheierung eines möglichen Sicherheitsrisiko. Und wenn wirklich was passiert bleibt sowieso nur eins: abschalten

Frag dich lieber, ob Passwörter grundsätzlich ausreichend sind. Wenn nicht setze auf bessere Verfahren.

Statt Webseiten umzuleiten kannst du per .htaccess auch einfach den Zugriff zu der Seite unterbinden. Besser ist aber den virtuellen Webserver zu stoppen.

[hikaru]

Ich sehe Ähnliches als reiner Zuschauer gelegentlich auf eher wenig technisch orientierten Kanälen und frage mich dann immer, warum der Streamer Aktionen die der Zuschauer nicht sehen soll nicht in einem Fenster auf einem zweiten Monitor ausführt, der nicht gestreamt wird.

[TRex]

Ich schließe mich einerseits den Vorrednern an: du solltest öffentlich erreichbare Ressourcen absichern, egal ob wer zuschaut oder nicht. Wenn du dafür verantwortlich bist, ist das deine Verantwortung ( ).

Aber: natürlich ists kein Problem, einen lokalen Reverse-Proxy einzurichten, und deine Webseite darüber anzusprechen. Aber von deinem Wissensstand ausgehend wird das nochn bisschen Arbeit sein. Manchmal reicht auch nur ein lokaler DNS-Eintrag.

[Abakus]

Ich sehe Ähnliches als reiner Zuschauer gelegentlich auf eher wenig technisch orientierten Kanälen und frage mich dann immer, warum der Streamer Aktionen die der Zuschauer nicht sehen soll nicht in einem Fenster auf einem zweiten Monitor ausführt, der nicht gestreamt wird.

Ich lebe, liebe wohne, arbeite, .... seit 3 Jahren durchgängig in einem Fiat-Ducato-Wohnmobil.
Ich würde gerne (wie früher ) ein Multimonitor-System verwenden.Aber:
Dafür habe ich keinen Platz!

[Abakus]

Ich danke für eure sicherlich gut gemeinten Ideen und Vorschläge.
Aber das sind alles Antworten auf Fragen die ich nicht gefragt habe!

[oln]

Moin,
TRex hatte dir ein Stichwort " Reverse-Proxy" gegeben. Damit ist es umsetzbar.

[Abakus]

Weil ich immer zuerst an Gute in den anderen Menschen sehe, investiere ich mal noch etwas von meiner Lebenszeit für euch:

Ja ich kann eure Gedanken nachvollziehen und gebe im Grunde recht.
Aber wenn Du z.B. auf Twitch.tv täglich zwischen 8 und 15 Stunden (theoretisch ) live Online auf einem Server und Deinem eigenen Rechner bist, passieren "Unfälle". Ja man kann Maßnahmen einsetzten den Bildschirm temporär mit einem "Overlay"-Frame zu bedecken, usw. ... aber schnell öffnet man mal eine php.ini wo ein Passwort oder Deine private Email drinsteckt. Du hast recht wenn man es "schafft" versehentlich ein Passwort zu leaken, bin ich selber schuld. Punkt! Aber oft gibt es auf Deinem Rechner mal anderer Informationen zu sehen, die Du nicht live mit der ganzen Welt teilen willst. Dein (Anmelde-) Name, Email, usw. in Foren, weil Du "auf debianforum.de" nach Hilfe gefragt hast.
Stelle Dir vor die ganze Welt schaut Dir über die Schulter, auf DEINEN Bildschirm. Pasuenlos. Du kannst Deinen Kollegen nicht bitten mal bitte kurz die Augen zu schließen, während Du eine Email lesen willst. Auf wenn es nur für einen Sekundenbruchteil ist. Die Streams werden automatisch auch aufgezeichnet, damit die Community nachträglich wiederholen kann. Ich streame erst seit kurzem, und habe selber noch nicht vollständig erfasst, welche Umstände und noch nie gemachte "Sicherheitsmaßnahmen" vielleicht notwendig ist. Ich lerne noch und will mich entwickeln. Ein Schritt dieser Entwicklung ist/sei diese lokale Web-Proxy Idee.

Und noch ein Unterschied zu den streamenden Gamern. Die haben es sehr viel leichter. Hier wird einfach nur das "Game-Fenster" freigegeben. Da besteht keine Gefahr etwas schnell zu leaken.
Wenn Du "SysAdmin" streamen willst musst Du Deinen ganzen Bildschirm, mit allem freigeben.
Ja man kann auch jedes Fenster einzeln freigeben wenn man es braucht. Ich habe es versucht. Aber Du verbrauchst 70% der Zeit damit zwischen Fensterfreigaben hin- und her- zu schalten. Das ist zu umständlich. So kann man nicht fließend arbeiten.

[uname]

Welche Software nutzt du eigentlich? Kannst du nicht sowas wie fertige WebRTC verwenden? Gibt doch bestimmt fertige und sichere Lösungen.

[TRex]

Weil ich immer zuerst an Gute in den anderen Menschen sehe, investiere ich mal noch etwas von meiner Lebenszeit für euch:

Wie großzügig von dir Aber nachdem du nun drauf hingewiesen wurdest, dass ich dir nicht nur gesagt habe, was du scheinbar nicht hören wolltest, sondern auch das, was du hören wolltest... magst du dazu Beratung oder findest du das alleine raus?

[Abakus]

Weil ich immer zuerst an Gute in den anderen Menschen sehe, investiere ich mal noch etwas von meiner Lebenszeit für euch:

Wie großzügig von dir Aber nachdem du nun drauf hingewiesen wurdest, dass ich dir nicht nur gesagt habe, was du scheinbar nicht hören wolltest, sondern auch das, was du hören wolltest... magst du dazu Beratung oder findest du das alleine raus?

Sehr schön. Danke.
Ich habe noch ein paar "Versuche" frei
Ich war halt etwas verunsichert, ob es am SSL/https liegt, dass ein solches Setup gar nicht funktionieren kann (darf).
Weil die "Umleitung" an sich hat geklappt, aber das REWRITE funzte nicht immer, und das verwirrendste war, dass ich nicht auf die "Ziel" Subdomain geleitet wurde, sondern immer (ausnahmslos) auf eine andere Subdomain des webservers gelenkt wurde.
Ich melde mich später noch einmal.

Wenn ich es nicht schaffe, komme ich mit genauen Setup-Daten und confs gerne zu euch (Dir) zurück.
Und auch auch wenn ich es erfolgreich lösen konnte.

[buddy67]

Weil ich immer zuerst an Gute in den anderen Menschen sehe, investiere ich mal noch etwas von meiner Lebenszeit für euch:

*i** dich

[GregorS]

Wenn ich es nicht schaffe, komme ich mit genauen Setup-Daten und confs gerne zu euch (Dir) zurück.
Und auch auch wenn ich es erfolgreich lösen konnte.

Ja, bitte mach' das. Auch wenn es mich gerade nicht betrifft, bin ich an der ggf. gefundenen/umgesetzten Lösung interresiert.

[hikaru]

Ich lebe, liebe wohne, arbeite, .... seit 3 Jahren durchgängig in einem Fiat-Ducato-Wohnmobil.
Ich würde gerne (wie früher ) ein Multimonitor-System verwenden.Aber:
Dafür habe ich keinen Platz!

Verstehe! Ich nehme an, du streamst dann von einem Notebook aus, am "Esstisch" sitzend.

Nur als Hinweis, nicht als Lösungsvorschlag:
Es gibt Monitore, die für den mobilen Einsatz gedacht, und daher vielleicht "wohnmobiltauglich" sind. [1] Ich hatte kurzzeitig Einen davon , der im Prinzip gut funktionierte.
Aber da das für mich ein "Testballon" war, hatte ich den Billigsten genommen den es gab (nicht mehr auf dem Markt), und da war das Panel so grottig schlecht, das ich ihn wieder zurückgeschickt habe. Es gibt aber wohl auch gute Monitore in der Kategorie. Über Lenovo hattee ich damals z.B. überwiegend Gutes gelesen. Leider weiß ich nicht mehr zu welchem Modell.


[1] https://geizhals.de/?cat=monlcd19wide&xf=11940_15.6

[TRex]

Weil ich immer zuerst an Gute in den anderen Menschen sehe, investiere ich mal noch etwas von meiner Lebenszeit für euch:

*i** dich

Es war extrem arrogant, aber nicht diese Antwort wert.

[Abakus]

Ok, ich habe nun wwiederholt Erfahrungen gemacht, aber leider nicht die erwarteten:

Ok es funktioniert ein bißchen, aber nicht wie erwartet:

Ich rufe im browser: "localhost" auf.
Der lokale reverse proxy reagiert, und leitet mich weiter auf meinen uhbee.de Server im Netz.
Das seltsame aber ist, dass er mich auf eine andere Subdomain leitet: "git.uhbee.de"
Die rewrite Regel scheint er zu ignorieren.

zusammengefasst:

URL: im Browser: "localhost" ---> "git.uhbee.de"

Meine erste Frage: warum geht der auf "git.uhbee.de" ??? und nicht auf "moodle.uhbee.de"

warum er die rewrite regeln nicht verwendet, frage ich noch erst nicht

Meine Frage:
Was macht der reverse Proxy?
ok, er lleitet mich weiter! das ist klar.
Ich bekomme eine Anzeige im Browser, mit der echten URL der Webseite.
Ist in diesem Moment dieser Umweg noch aktiv, oder bin ich nun in einer "Direktverbindung" auf "git.uhbee.de" ?

Ich komme nicht weiter!
Würde gerne wissen was ich falsch mache.
Und/Oder wie es richtig wäre.

Gruß Aba Kus

Zum Setup:
Ich habe einen Tuxedo Laptop Stellaris 17:
64 GB RAM, Intel Core i9-13900HX, NVIDIA RTX 4070
mit Tuxedo-OS (Ubuntu-basiert)

Der Server im Netz ist ein gemieteter root-Server mit einem frisch installiertem Debian12.
Ich habe mit dem Apache2, einige subdomains (Let's Encrypt Certs) eingerichtet.
Auf diesen Subdomains sind im Moment ein Moodle-System und ein Forgejo zuhause.
Demnächst soll noch eine nextcloud drauf.

Einige Leute rauchen, angeln, sammeln Briefmarken, ... ich spiele gerne mit Servern im Netz.
Dediziert für meine neuen Twitch-Stream-Bemühungen soll dieser Server verwendet werden.
Wenn er "kaputtkonfiguriert" ist, lasse ich ihn einfach neu aufsetzten.

hier meine locale conf,
tuxedo/etc/apache2/sites-evailable/000-default.conf:

<VirtualHost *:80>
ServerName localhost

ProxyPreserveHost On
ProxyPass / http://moodle.uhbee.de/
ProxyPassReverse / http://moodle.uhbee.de/

RewriteEngine On
RewriteCond %{HTTP_HOST} ^localhost$ [NC]
RewriteRule ^/(.*)$ http://moodle.uhbee.de/$1 [P,L]
</VirtualHost>

Edith: Ob ich hier
http oder https ist egal. Keine Änderung am Ergebnis


und die conf's vom remote Server:

# ls -l /etc/apache2/sites-enabled/
insgesamt 0
lrwxrwxrwx 1 root root 36 13. Aug 23:25 git.uhbee.de.conf -> ../sites-available/git.uhbee.de.conf
lrwxrwxrwx 1 root root 40 13. Aug 23:37 git.uhbee.de-ssl.conf -> ../sites-available/git.uhbee.de-ssl.conf
lrwxrwxrwx 1 root root 39 4. Aug 02:20 moodle.uhbee.de.conf -> ../sites-available/moodle.uhbee.de.conf
lrwxrwxrwx 1 root root 43 4. Aug 02:56 moodle.uhbee.de-ssl.conf -> ../sites-available/moodle.uhbee.de-ssl.conf
lrwxrwxrwx 1 root root 32 4. Aug 01:35 uhbee.de.conf -> ../sites-available/uhbee.de.conf
lrwxrwxrwx 1 root root 36 4. Aug 02:28 uhbee.de-ssl.conf -> ../sites-available/uhbee.de-ssl.conf
root@s216:~#

moodle.uhbee.de.conf:

# cat /etc/apache2/sites-enabled/moodle.uhbee.de.conf
<VirtualHost *:80>
ServerName moodle.uhbee.de
Redirect permanent / https://moodle.uhbee.de/
</VirtualHost>

root@s216:~# cat /etc/apache2/sites-enabled/moodle.uhbee.de-ssl.conf

<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerName moodle.uhbee.de
DocumentRoot /var/www/moodle

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

ErrorLog ${APACHE_LOG_DIR}/moodle.uhbee.de-error.log
CustomLog ${APACHE_LOG_DIR}/moodle.uhbee.de-access.log combined

SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/moodle.uhbee.de/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/moodle.uhbee.de/privkey.pem
Include /etc/letsencrypt/options-ssl-apache.conf

# HSTS (optional but recommended)
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
</VirtualHost>
</IfModule>
root@s216:~#

usw.

[TRex]

Ich hab mal etwas rumprobiert (apache lese ich nicht so flüssig wie nginx) und folgendes entdeckt:

Code: Alles auswählen

$ curl http://91.109.28.62
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://git.uhbee.de/">here</a>.</p>
<hr>
<address>Apache/2.4.61 (Debian) Server at 91.109.28.62 Port 80</address>
</body></html>

soll heißen: wenn man den Server nicht über den Hostnamen aufruft bzw diesen als Header mitgibt, "gewinnt" die git-Subdomain. Daher nun meine Annahme, dass die lokale Konfiguration noch nicht vollständig ist. Also investiere ich ebenfalls meine kostbare Zeit und installiere apache und deine reverse proxy config, und tcpdump (-v) sagt mir beim ausgehenden Traffic ans Ziel:

Code: Alles auswählen

	GET / HTTP/1.1
	Host: localhost
	User-Agent: curl/8.9.1
	Accept: */*
	X-Forwarded-For: ::1
	X-Forwarded-Host: localhost
	X-Forwarded-Server: localhost
	Connection: Keep-Alive

Bei host sollte halt eben nicht mehr localhost stehen. Auf Verdacht hab ich dann mal ProxyPreserveHost auf Off gestellt und siehe da, es funktioniert.

[TRex]

Es ist übrigens nicht nett, mehrere Foren unabhängig voneinander mit dem gleichen Thema zu beschäftigen (und ihre kostbare Zeit zu beanspruchen), ohne sie voneinander wissen zu lassen: https://forum.linuxguides.de/index.php? ... tID=101239

[uname]

Kostbare Zeit sehe ich weniger. Aber Crossposting sollte man bekanntgeben.

Ich habe nicht alles gelesen aber eine neue Idee. Kann die Streamer-Verbindung nicht durch Local SSH Portforwarding gezogen und erzwungen werden?

4 Dinge sind nötig:
1) Horchen nur auf Localhost (80, 443, ...) am Server für Streamer erlauben
2) Aktivierung SSH Port Forwarding auf dem Server
3) SSH-Zugang mit /bin/false reicht, evtl. gemeinsamer User mit Passwort oder SSH-Key
4) Streamer muss wissen wie er damit umgeht. Für Windows rate ich zu "plink.exe".

Nicht alles wie z.B. Websockets werden evtl. nicht durch den Tunnel geleitet. Ist hoffentlich egal.

[Abakus]

Ich bin gerade nicht am Laptop, aber versuche mal zu spiegeln und wiederholen und zu lernern:

@Trex:
Mit dem curl Aufruf hast Du den Zielserver mit seiner IP "angerufen"
Der remote Apache2 entscheidet also anhand des "Host"-Headers, welche der Web-Seite angezeigt werden soll.
Der "remote" apache2 Server generierte die "301 Moved Permanently" Meldung, die dann beim "curl" ankommt.
Und der apache sendet dafür ein git.uhbee.de zurück an den curl.

Soweit habe ich das jetzt verstanden:
Nämlich der remote Apache will einen gültigen "Host"-Header haben!

Ok. Nächster Schritt:
Um diesen gültigen "Host"-Header an den remote Apache zu senden, wird die Einstellung des lokalen reverse-proxy geändert:
Du schlägt vor, ProxyPreserveHost auf Off zu setzen. Dadurch wird der Host-Header so geändert, dass er den richtigen Hostnamen des Zielservers enthält (z.B. moodle.uhbee.de). Dies stellt sicher, dass der Zielserver die Anfragen korrekt verarbeitet.

Soweit vielen Dank! <3

Ich werde es später testen.
Meine Annahme warum der "git" "gewinnt":
weil er alphabetisch die erste virtuelle Subdomain ist.
Ich werde mal die "Reihenfolge" mit den typischen nummern 00n-xxxx.conf verdrehen.

[Abakus]

Es ist übrigens nicht nett, mehrere Foren unabhängig voneinander mit dem gleichen Thema zu beschäftigen (und ihre kostbare Zeit zu beanspruchen), ohne sie voneinander wissen zu lassen: https://forum.linuxguides.de/index.php? ... tID=101239

im sorry.
Ich war müde. es war mitten in der Nacht. Und ungeduldig.
kein herausreden, eine Entschuldigung.

[Abakus]

@uname:

Ja die Idee ist super, ich habe mir diesen Weg, in meine "Möglichkeiten-Liste" eingefügt.
Das wäre ein gesicherter "Exclusiv-Zugang" zum Server.

Aber das geht mir zu "weit" in diese Richtung.
Der Server und die Web-Dienste sollen ja schon noch für "Andere" zur Verfügung stehen.

Vielleicht denke ich etwas "verquer", weil es sich mit meinen "Bedenken" widerspricht, aber ich würde es gerne trotzdem so haben!

Danke

[Abakus]

... schnelles update:
Der erste richtige Schritt war dieser Schalter:

Code: Alles auswählen

<VirtualHost *:80>
    ServerName localhost

    ProxyPreserveHost Off
    #ProxyPreserveHost On
    ProxyPass / http://moodle.uhbee.de/
    ProxyPassReverse / http://moodle.uhbee.de/

    RewriteEngine On
    RewriteCond %{HTTP_HOST} ^localhost$ [NC]
    RewriteRule ^/(.*)$ https://moodle.uhbee.de/$1 [P,L]
</VirtualHost>

Wenn ich nun in meinem lokalen Browser "localhost" eingebe, springt er nach
https://moodle.uhbee.de

Zumindest geht er jetzt auf die richtige Subdomain. schön!
Aber, in der Browser-URL-Leiste steht dann nach der Auswahl eines Kurses:

https://moodle.uhbee.de/course/view.php?id=5
Das hätte ich auch ohne Umleitung so haben können!
Mein Ziel soll sein, dass dort steht:

http://localhost/course/view.php?id=5

Wie bitte komme ich dahin?

Danke, Aba_Kus

[oln]

Moin,
Rewrite != Proxy !
Das erst einmal vorne wg.
Mit diesen Schaltern läuft bei mir seit Jahren der Proxy:

Code: Alles auswählen

                
                ProxyRequests           On
                ProxyPass               /       https://$externlhost/
                ProxyPassReverse        /       https://$externalhost/

[Abakus]

..... da habe ich mir was ausgedacht, manno man.
Ganz so einfach ist das doch nicht.

Weil der "proxy" muss mit Sessions, mit cookies, und anderen HTTP-Features klarkommen.

...working on progress ....

Grüße
Aba Kus