SVN Redirect auf HTTP

[Virsacer]

Hi,
ich weiß es passt eigentlich nicht ganz hier rein, aber im Developer-Bereich kann ich nicht posten...

Ich checke den Quellcode immer über git-svn aus, aber da kommt plötzlich ein ein Fehler:

Code Auswählen Erweitern

Can't create session: Unable to connect to a repository at URL 'https://svn.fhem.de/fhem/trunk/fhem': Access to '/fhem/trunk/fhem' forbidden at /usr/share/perl5/Git/SVN.pm line 148.
Ich hab dann mal mit wget versucht und da sehe ich, dass wegen dem fehlenden "/" am Ende ein Redirect von HTTPS auf HTTP (und dann wieder auf HTTPS) stattfindet:

Code Auswählen Erweitern

--2025-02-09 11:57:47--  https://svn.fhem.de/fhem/trunk/fhem
Resolving svn.fhem.de (svn.fhem.de)... 2a01:4f8:221:1b5a::2, 188.40.131.57
Connecting to svn.fhem.de (svn.fhem.de)|2a01:4f8:221:1b5a::2|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://svn.fhem.de/fhem/trunk/fhem/ [following]
--2025-02-09 11:57:47--  http://svn.fhem.de/fhem/trunk/fhem/
Connecting to svn.fhem.de (svn.fhem.de)|2a01:4f8:221:1b5a::2|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://svn.fhem.de/fhem/trunk/fhem/ [following]
--2025-02-09 11:57:47--  https://svn.fhem.de/fhem/trunk/fhem/
Connecting to svn.fhem.de (svn.fhem.de)|2a01:4f8:221:1b5a::2|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1401 (1.4K) [text/html]
Saving to: 'fhem'
In meinem Repo ist die URL mit "/" am Ende hinterlegt, wird aber anscheinend erstmal ignoriert.

Ich weiß nicht, ob der Redirect jetzt auch die Ursache für meinen Fehler ist, aber der Umweg über HTTP ist aus Security-Sicht definitiv ungünstig und sollte behoben werden...

[Otto123]

Hi,
ich schau mir das mal und werde versuchen es nachzuvollziehen.

da kommt plötzlich ein ein Fehler:

bedeutet plötzlich vorgestern ging es noch? Hintergrund meiner Frage: wir haben immer mal wieder, aber seit gestern ziemlich extrem, "wütende" Zugriffe auf das SVN. Wir haben versucht diese Bots auszusperren, es gab also Änderungen.

Gruß Otto

[rudolfkoenig]

Diese wuetenden Zugriffe wurden von Clients verursacht, die sich mit dem Useragent serf gemeldet haben, ich habe gestern deswegen diesem UserAgent den Zugriff untersagt.

Stellt sich raus, das serf die Bibliothek ist, die von dem svn Kommando selbst verwendet wird, und ein SVN checkout gerne 8-10 httpd Prozesse auf einmal beschaeftigt.
Gerade eben waren 128 unterwegs (trotz serf Verbot), was fuer unsere VM auf Dauer zu viel ist.

Ich habe jetzt serf wieder aktiviert (svn checkout via https geht wieder), und die Anzahl der httpd Prozesse auf 32 begrenzt.
Schauen wir mal, ob die Ueberwachung der VM sich beruhigt.

Als Detail zu "wuetend": Gestern Nachmittag wurde z.Bsp FHEM innerhalb von einer halben Stunde 72-mal ausgecheckt.
Die Anfragen kamen parallel von zwei IPs, die grossen Providern aus der Uebersee zuzuordnen sind.

[Virsacer]

Ah, das erklärts
Jetzt geht der Zugriff wieder
Danke

Aber den Redirect solltet ihr trotzdem noch überarbeiten

[rudolfkoenig]

Aber den Redirect solltet ihr trotzdem noch überarbeiten

Das war meine Methode von "UserAgent untersagen".

[Virsacer]

Hm, das ist aber in wget immernoch:

https://svn.fhem.de/fhem/trunk/fhem 301 Moved Permanently
http://svn.fhem.de/fhem/trunk/fhem/ 301 Moved Permanently
https://svn.fhem.de/fhem/trunk/fhem/ 200 OK

Und im Firefox genauso, siehe Anhang

[Otto123]

@virsacer Ich versuche es derzeit zu verstehen, gewollt und bewusst eingerichtet ist es nicht. Danke für den Hinweis.

[rudolfkoenig]

Das war meine Methode von "UserAgent untersagen".

Sorry, das wahr wohl eine falsche Behauptung.

der Umweg über HTTP ist aus Security-Sicht definitiv ungünstig und sollte behoben werden...

Abgesehen davon, dass es einen zusaetzlichen sinnlosen redirect erzeugt: inwieweit ist es ein Problem auf Security-Sicht?

[Virsacer]

inwieweit ist es ein Problem auf Security-Sicht?

Na, HTTP ist unverschlüsselt...

Also theoretisch auf dem Weg zwischen Server und Client mitles- und veränderbar (z.B. den Redirect auf eine bösartige Seite ändern)

[Otto123]

Ich denke das passiert nicht. Der Request pendelt kurz intern zwischen Proxy und Backend - zumindest verstehe ich das so. Aber er ist mMn unnötig.

[Virsacer]

Wenn es intern wäre, würde ich es nicht sehen

Vom Proxy wird sowas durchgereicht
Kann aber natürlich auch vom Proxy selbst stammen

[rudolfkoenig]

Also theoretisch auf dem Weg zwischen Server und Client mitles- und veränderbar (z.B. den Redirect auf eine bösartige Seite ändern)

Sehe ich ein.
Wenn ich rausfinde, wie man das Problem behebt, werde ich machen.
Ist aber z.Zt. low Prio, bzw. nur wenn es ueber den Weg laeuft.

[Otto123]

Das "Problem" tritt aber "nur" bei nicht vorhandene Dateien bzw. unvollständigen Pfadangaben auf. Also
Keine Weiterleitung
wget https://svn.fhem.de/fhem/trunk/fhem/controls_fhem.txt
wget https://svn.fhem.de/fhem/trunk/fhem/
wget https://svn.fhem.de/fhem/trunk/

Weiterleitung
wget https://svn.fhem.de/fhem/trunk/fhem
wget https://svn.fhem.de/fhem/trunk
wget https://svn.fhem.de/fhem

[Nestor]

Wird der Zugriff auf SVN wiederhergestellt oder aufgrund von DDOS für immer deaktiviert?

Code Auswählen Erweitern

svn info https://svn.fhem.de/fhem/
svn: E175013: Zugriff auf '/fhem' verboten

[Otto123]

Eine erkannte "Attacke" gilt derzeit für 50 sec. Was genau hast Du getan?