Ankündigung

Einklappen
Keine Ankündigung bisher.

htaccess-Code gegen Hotlinking

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

    #31
    Zitat von Martin11 Beitrag anzeigen
    Folglich müsste ich bis zur eigenen https-Umstellung die erste Referrerzeile eigentlich auskommentieren, ansonsten kann fast jeder Hotlinking betreiben. Oder gibt es eine Code-Möglichkeit, beides abzudecken: Egal, ob Referrer vorhanden oder nicht, das Rewrite soll in jedem Fall immer greifen? Oder existiert diese Möglichkeit bereits durch das Auskommentieren/Verzichten auf die Referrerzeile, d.h., es wird beides abgedeckt?
    Es kann wie gesagt auch andere Gründe geben. Entscheidet sich jemand, den Refer(r)er zu blocken (also z. B. in der Browserkonfiguration zu deaktivieren), weil er meint, dass es einen Websitebetreiber einen feuchten Käse angeht, über welchen Link er auf die Site gekommen ist, ist das IMHO völlig legitim. Dieser Besucher würde dann aber auch auf Deiner Site keine Bilder sehen. Das mag nur wenige Besucher betreffen, ist aber der Grund dafür, einen leeren Referer immer zuzulassen, auch wenn man dadurch ein paar unerwünschte Zugriffe in Kauf nimmt.

    Entscheiden kannst Du das natürlich selbst.

    Bleibt die Zeile auskommentiert, hast Du ja genau das, was Du beschreibst - die Bilder werden auch dann geblockt, wenn der Referer leer bleibt. Dass das funktioniert, hast Du ja bereits ausprobiert.

    Zitat von Martin11 Beitrag anzeigen
    2. Mit aktivierter Referrerzeile würde der Code dann das Hotlinking wie gewünscht unterbinden, wenn ich von einer anderen http-Site von mir mich selbst testweise "hotlinken" würde. Oder gibt es noch einen anderen Grund, warum das dann trotzdem nicht klappen sollte?
    Mir fällt kein anderer Grund ein.

    Aber masterframe hat natürlich Recht - ein Zertifikat kostet nicht die Welt, also warum gönnst Du Dir nicht einfach eines?

    Gruß
    Jan
    Two hours of trial and error can save ten minutes of manual reading.

    Kommentar


      #32
      Zitat von Enigma Beitrag anzeigen

      Es kann wie gesagt auch andere Gründe geben. Entscheidet sich jemand, den Refer(r)er zu blocken (also z. B. in der Browserkonfiguration zu deaktivieren), weil er meint, dass es einen Websitebetreiber einen feuchten Käse angeht, über welchen Link er auf die Site gekommen ist, ist das IMHO völlig legitim. Dieser Besucher würde dann aber auch auf Deiner Site keine Bilder sehen. Das mag nur wenige Besucher betreffen, ist aber der Grund dafür, einen leeren Referer immer zuzulassen, auch wenn man dadurch ein paar unerwünschte Zugriffe in Kauf nimmt.

      Entscheiden kannst Du das natürlich selbst.

      Bleibt die Zeile auskommentiert, hast Du ja genau das, was Du beschreibst - die Bilder werden auch dann geblockt, wenn der Referer leer bleibt. Dass das funktioniert, hast Du ja bereits ausprobiert.

      Verstehe. Dann habe ich die Wahl zwischen auskommentierter Zeile mit umfassendem Hotlinking-Schutz, aber evtl. einige wenige Besucher, die ihren Referer absichtlich deaktiviert haben und dann keine Bilder sehen. Wobei meine Klientel wenig technikaffin ist und ich nicht glaube, dass das nennenswert viele wären. Vielleicht einige ganz wenige, die im Browser ein Add-On nutzen, das per einfachem Klick solche Einstellungen zwecks Datenschutz herstellt.
      Oder mit aktivierter Zeile, aber dann habe ich, solange ich http habe, praktisch keinen Hotlinking-Schutz und könnte mir das Ganze auch gleich sparen.

      Zitat von Enigma Beitrag anzeigen



      Aber masterframe hat natürlich Recht - ein Zertifikat kostet nicht die Welt, also warum gönnst Du Dir nicht einfach eines?
      Im Tarif ist nur eines dabei und ich habe drei Sites. Wenn, dann möchte ich alle drei auf https umstellen. Da mein Tarif (als einziger) kürzlich teurer geworden ist, was mich ein wenig ärgert, geht es mir gegen den Strich, jetzt auch noch Zertifikate dazu zu kaufen, zumal es die mittlerweile bei fast allen Hostern im Tarifpaket mit dazu gibt (also mehr als nur eines).

      Der wichtigere Grund ist aber, dass ich mich dann als Webmaster und Techniklaie mit der Umstellung wieder mit der ganzen Thematik auseinandersetzen muss, insbesondere: Wo muss oder sollte ich meine URLs (und Codes) auf https anpassen. In Frage kommen hier:
      - htaccess
      - Wordpress-Einstellungen
      - Theme-Einstellungen
      - DF-Einstellungen im Kundenmenü
      - robots.txt
      - in der Webseiten selbst
      - Google Search Console
      + weitere? Das sind nur die Sachen, die mir jetzt ganz spontan einfallen. Wahrscheinlich kann ich an vielen Stellen http lassen, an einigen kann ich es belassen, aber es wäre vielleicht besser, manuell auf https anzupassen, z.B. Verlinkungen zwischen meinen Seiten.
      Alleine das alles rauszufinden, ist schon wieder ein Act für mich. Das werden dann ungefähr fünf solcher langer Forumsdiskussionen , mit Ausprobieren und Hin und Her, weil dann doch etwas nicht gleich klappt usw. usw.

      Und das alles, obwohl ich eh schon am Überlegen bin, den Hoster zu wechseln... und dort dann wieder eine ganz andere Zertifikate-Situation hätte. Das wäre dann der dritte Grund, wobei mir das im Moment auch zu viel Stress ist.
      Grüße,

      Martin

      Kommentar


        #33
        So, ich hab's jetzt mal mit auskommentierter Referrerzeile gemacht, damit der Hotlinkingschutz umfassend gilt.

        Ich hätte noch zwei Verständnisfragen, also falls du noch da bist, Enigma und Lust hast.

        1. Erfasst der Code entsprechend der "Conditions" eigentlich nicht alle Anfragen, anstatt sich nur auf Bilder zu beschränken?
        Müsste man da eigentlich nicht am Anfang eine Bedingung haben, die besagt "wenn Anfragen für Bilder (.jpg ect.) kommen"?
        Ich sehe schon, dass das in der RewriteRule am Schluss mitdrinsteckt, fände es aber irgendwie naheliegend, das (auch oder stattdessen) in den Conditions zu haben.

        2. Müsste der Code nicht eigentlich auch bei Bilderanfragen von normalen Besuchern greifen?
        Es gibt so Analysetools wie ScreamingFrog, die die Website crawlen und statistisch auswerten. Die Bilder haben da alle ein 403. Das Tool betreibt kein Hotlinking in dem Sinne, sendet aber natürlich Bilderanfragen an den Server.

        Das bringt mich auf Folgendes: Wenn der htaccess-Code im Grunde bei "allen Bilderanfragen an den Server" greift , was ist dann der Unterschied zu all den Bilderanfragen, die von ganz normalen Besuchern im Web kommen? Ich habe ein paar Ausnahmen definiert, o.k., aber es gibt ja viele Wege, wie und von wo die Seiten mit den Bilder-URLs aufgerufen werden können. Manche klicken z.B. auf irgendeiner Site einen Link zu mir, manche tippen die URL manuell in den Browser, manche kommen über kleine unbekannte Sumas, manche nutzen Bookmarks usw. usw. Und es ist immer die gleiche Bild-URL, mit der am Server angefragt wird...

        Wo ist mein Denkfehler und warum bestätigt ScreamingFrog meinen Denkfehler?
        Zuletzt geändert von Martin11; 22.11.2019, 12:01.
        Grüße,

        Martin

        Kommentar


          #34
          Ich glaube, ich habe meinen Denkfehler zur 2. Frage gerade selbst entdeckt: Normale Besucheranfragen gelten zunächst mal der Seite, also der Seiten-URL, nicht direkt den Bilder-URLs. Zwar werden dann im nächsten Schritt die Bilder-URLs aufgerufen, aber das kommt dann sozusagen von mir selbst und ist von der ersten Ausnahme im Code erfasst.
          ScreamingFrog wird vermutlich die Seite aufrufen, die Bilder-URLs feststellen und dann gesondert diese über deren Bilder-URL aufrufen wollen. Dieser gesonderte Aufruf ist dann eine direkte Serveranfrage von außen und ergibt 403. Vermute ich.
          Grüße,

          Martin

          Kommentar


            #35
            Zitat von Martin11 Beitrag anzeigen
            1. Erfasst der Code entsprechend der "Conditions" eigentlich nicht alle Anfragen, anstatt sich nur auf Bilder zu beschränken?
            Müsste man da eigentlich nicht am Anfang eine Bedingung haben, die besagt "wenn Anfragen für Bilder (.jpg ect.) kommen"?
            Ich sehe schon, dass das in der RewriteRule am Schluss mitdrinsteckt, fände es aber irgendwie naheliegend, das (auch oder stattdessen) in den Conditions zu haben.
            Du könntest das einfügen, aber das hätte keinen Mehrwert. Die RewriteRule regelt das, und da die RewriteCond-Zeilen extrem schnell abgearbeitet werden, macht das auch performancemäßig kaum einen Unterschied. Möchtest Du partout wenige (!) Millisekunden einsparen, könntest Du als erste Zeile des Blocks

            Code:
            RewriteCond %{REQUEST_URI} \.(jpe?g|png|gif|svg|pdf|mp3)$ [NC]
            hinzufügen. Damit Du bei Änderungen (z. B. beim Hinzufügen weiterer Dateiendungen) nicht immer zwei Zeilen ändern musst, solltest Du die RewriteRule dann in

            Code:
            RewriteRule ^.*$ - [F]
            ändern. Falls Du die bisherige Variante beibehalten möchtest, solltest Du übrigens vorsichtshalber das NoCase-Flag zur RewriteRule hinzufügen (habe ich bisher übersehen):

            Code:
            RewriteRule \.(jpe?g|png|gif|svg|pdf|mp3)$ - [NC,F]
            Zitat von Martin11 Beitrag anzeigen
            2. Müsste der Code nicht eigentlich auch bei Bilderanfragen von normalen Besuchern greifen?
            Diese Frage hast Du Dir ja bereits selbst beantwortet.

            Gruß
            Jan
            Two hours of trial and error can save ten minutes of manual reading.

            Kommentar


              #36
              Zitat von Enigma Beitrag anzeigen

              Du könntest das einfügen, aber das hätte keinen Mehrwert. Die RewriteRule regelt das, und da die RewriteCond-Zeilen extrem schnell abgearbeitet werden, macht das auch performancemäßig kaum einen Unterschied. Möchtest Du partout wenige (!) Millisekunden einsparen, könntest Du als erste Zeile des Blocks

              Code:
              RewriteCond %{REQUEST_URI} \.(jpe?g|png|gif|svg|pdf|mp3)$ [NC]
              hinzufügen. Damit Du bei Änderungen (z. B. beim Hinzufügen weiterer Dateiendungen) nicht immer zwei Zeilen ändern musst, solltest Du die RewriteRule dann in

              Code:
              RewriteRule ^.*$ - [F]
              ändern. Falls Du die bisherige Variante beibehalten möchtest, solltest Du übrigens vorsichtshalber das NoCase-Flag zur RewriteRule hinzufügen (habe ich bisher übersehen):

              Code:
              RewriteRule \.(jpe?g|png|gif|svg|pdf|mp3)$ - [NC,F]
              Nein, um die Millisekunden geht es mir nicht, dann lasse ich das so, wie es offenbar auch alle anderen haben.
              Mir schien es nur irgendwie logischer, das in die Bedingungen reinzupacken, um von vorneherein alle anderen (nicht anvisierten) Anfragen aus dem Spiel rauszunehmen.

              Das NoCaseFlag nur bei der RewriteRule ergänzen?
              Was ich auf die Schnelle gegoogelt habe: deckt den nicht auszuschließenden Fall ab, dass die URL in Großbuchstaben ankommt?



              Wegen der 2. Frage: Das ist "aktives Lernen" , für das ich noch nicht zu alt bin. Laut sprechen und schreiben aktiviert mehr Verknüpfungen im Gehirn und so bin ich irgendwie drauf gekommen, kurz nach dem Schreiben und nochmal Lesen.
              Da mir der Ablauf einer Serveranfrage als autodidaktischer Gelegenheitswebmaster aber nicht geläufig ist, war es nur eine Vermutung.

              Grüße,

              Martin

              Kommentar


                #37
                Zitat von Martin11 Beitrag anzeigen
                Das NoCaseFlag nur bei der RewriteRule ergänzen?
                Ja, die RewriteCond-Zeilen haben es schon.

                Zitat von Martin11 Beitrag anzeigen
                Was ich auf die Schnelle gegoogelt habe: deckt den nicht auszuschließenden Fall ab, dass die URL in Großbuchstaben ankommt?
                Ja, in diesem speziellen Fall werden somit auch Dateien abgedeckt, deren Dateierweiterungen Großbuchstaben enthalten.

                Gruß
                Jan
                Two hours of trial and error can save ten minutes of manual reading.

                Kommentar


                  #38
                  Okidoki, danke für deine Geduld.
                  Grüße,

                  Martin

                  Kommentar


                    #39
                    Enigma ist leider nicht mehr da, aber der schlussendliche Code, der grundsätzlich funktioniert, scheint Google und Bing nicht als Ausnahmen zu berücksichtigen.
                    Jedenfalls werden die Bilder nicht indexiert.

                    Kann jemand sehen, was an den Ausnahmen evtl. doch nicht stimmt?

                    Code:
                    # BEGIN Hotlinking unterbinden
                    <IfModule mod_rewrite.c>
                    #RewriteCond %{HTTP_REFERER} !^$
                    RewriteCond %{HTTP_REFERER} !^https?://(www\.)?der-weg-nach-hause\.de(/.*)?$ [NC]
                    RewriteCond %{HTTP_REFERER} !^https?://(www\.)?google\.[^/]+(/.*)?$ [NC]
                    RewriteCond %{HTTP_REFERER} !^https?://(www\.)?bing\.[^/]+(/.*)?$ [NC]
                    RewriteCond %{HTTP_REFERER} !^https?://(www\.)?facebook\.com(/.*)?$ [NC]
                    RewriteCond %{HTTP_REFERER} !^https?://(www\.)?twitter\.com(/.*)?$ [NC]
                    RewriteCond %{HTTP_REFERER} !^https?://(www\.)?pinterest\.com(/.*)?$ [NC]
                    RewriteCond %{HTTP_REFERER} !^https?://(www\.)?xing\.com(/.*)?$ [NC]
                    RewriteRule \.(jpe?g|png|gif|svg|pdf|mp3)$ - [NC,F]
                    </IfModule>
                    # END Hotlinking unterbinden
                    Grüße,

                    Martin

                    Kommentar


                      #40
                      Zitat von Martin11 Beitrag anzeigen
                      Kann jemand sehen, was an den Ausnahmen evtl. doch nicht stimmt?
                      Bist du dir denn sicher, dass die Bots die Bilder auch wirklich über die zugelassen URLs indizieren?


                      MfG,
                      masterframe

                      Kommentar


                        #41
                        Zitat von Martin11 Beitrag anzeigen
                        Enigma ist leider nicht mehr da, aber der schlussendliche Code, der grundsätzlich funktioniert, scheint Google und Bing nicht als Ausnahmen zu berücksichtigen.
                        Jedenfalls werden die Bilder nicht indexiert.
                        Mit den obigen RewriteConditions erlaubst Du u.a. das Hot-Linking in der Google-Bildersuche. Das Bild wird auch ausgeliefert, wenn der Referer ein leerer String ist. Der Google(Image)Bot sendet aber überhaupt keinen Referer-Header und dann führt obiger Code auch zu einem 403. Der Google(Image)Bot darf das Bild also nicht indizieren.

                        Du kannst zusätzliche RewriteConditions einfügen, in denen Du auf den UserAgent filterst und dann eben für den GoogleBot und andere Suchmaschinenbots das Ausliefern des Bildes zulässt. Ich habe keine Ahnung von SEO und mit welchem UserAgent die ganzen Bots sich aktuell ausweisen, weiß ich nicht. Das musst Du selbst mal recherchieren und dann entsprechende Conditions einbauen.
                        Code:
                        RewriteCond !%{HTTP_USER_AGENT} <BotUserAgentName>
                        Eventuell auch noch mal überlegen, ob der ganze Aufwand lohnt. Ich weiß nicht, ob es um den intellektuellen Schutz Deiner Bilder geht oder Du die Last nicht auf dem Server haben willst. Es kommt ja offenbar Nginx als Reverse Proxy zum Einsatz? Der ist - richtig konfiguriert - beim Ausliefern statischer Inhalte sehr effizient. Die Bilder einfach direkt durch Nginx auszuliefern ist eventuell effizienter, als wenn der lahme Apache bei jedem HTTP-Request jedes mal endlos Regeln abarbeiten muss. Die oben aufgeführten Regeln muss der Apache nun schließlich auch bei jedem Request gegen eine PHP-Datei, CSS, Javascript, Fonts, etc. abarbeiten.




                        Zuletzt geändert von rp_df; 18.03.2020, 15:17. Grund: Formatierung

                        Kommentar


                          #42
                          Zitat von masterframe Beitrag anzeigen

                          Bist du dir denn sicher, dass die Bots die Bilder auch wirklich über die zugelassen URLs indizieren?

                          Dass ein Hotlinkingverbot die Bildersuche von Sumas betrifft und diese die Bilder dann nicht aufnehmen ist sicher. Deswegen gibt es ja in dem Zusammenhang, also beim Thema "Hotlinking", immer die zusätzliche Empfehlung, Sumas explizit zuzulassen. Und das scheint bei allen/vielen dann auch so zu klappen, mit dem obigen oder einem ähnlichen Code. Das heißt, es wird Hotlinking unterbunden (was bei mir auch klappt), aber Sumas dürfen zugreifen.

                          Beim Hotlinking geht es um die src-Referenz von außen direkt auf meinen Webspace.

                          Nach allem, was ich weiß, kann ich deine Frage nur mit Ja beantworten.
                          Zuletzt geändert von Martin11; 18.03.2020, 16:13.
                          Grüße,

                          Martin

                          Kommentar


                            #43
                            Zitat von rp_df Beitrag anzeigen

                            Mit den obigen RewriteConditions erlaubst Du u.a. das Hot-Linking in der Google-Bildersuche. Das Bild wird auch ausgeliefert, wenn der Referer ein leerer String ist. Der Google(Image)Bot sendet aber überhaupt keinen Referer-Header und dann führt obiger Code auch zu einem 403. Der Google(Image)Bot darf das Bild also nicht indizieren.
                            Du spielst auf die Zeile

                            Code:
                            #RewriteCond %{HTTP_REFERER} !^$
                            an? Genauer gesagt, auf deren Auskommentierung/Deaktivierung?
                            Das hängt damit zusammen, dass ich noch http habe und wie die Browser damit umgehen. Der Code würde sonst fast immer ins Leere laufen, das kam hier im Thread auch zur Sprache.
                            Dass nach dieser ersten deaktivierten Bedingung die eigentliche "Ausnahmebedingung" für G nicht mehr greift und dann 403 rauskommt, verstehe ich allerdings nicht. Müsste die Ausnahmebedingung nicht trotzdem greifen? Oder kann sie nicht greifen, weil gar nicht mehr erkannt wird, dass es G ist, der das Bild will?



                            Zitat von rp_df Beitrag anzeigen



                            Du kannst zusätzliche RewriteConditions einfügen, in denen Du auf den UserAgent filterst und dann eben für den GoogleBot und andere Suchmaschinenbots das Ausliefern des Bildes zulässt. Ich habe keine Ahnung von SEO und mit welchem UserAgent die ganzen Bots sich aktuell ausweisen, weiß ich nicht. Das musst Du selbst mal recherchieren und dann entsprechende Conditions einbauen.
                            Code:
                            RewriteCond !%{HTTP_USER_AGENT} <BotUserAgentName>
                            Auf https://www.codepalm.de/post/apache-...ng-protection/ habe ich das gefunden:
                            RewriteCond %{HTTP_USER_AGENT} !^(.*)Googlebot(.*)$ [NC]

                            Ist nicht derselbe Code wie bei dir, aber grundsätzlich wohl das, was du meinst.




                            Zitat von rp_df Beitrag anzeigen

                            Eventuell auch noch mal überlegen, ob der ganze Aufwand lohnt. Ich weiß nicht, ob es um den intellektuellen Schutz Deiner Bilder geht oder Du die Last nicht auf dem Server haben willst. Es kommt ja offenbar Nginx als Reverse Proxy zum Einsatz? Der ist - richtig konfiguriert - beim Ausliefern statischer Inhalte sehr effizient. Die Bilder einfach direkt durch Nginx auszuliefern ist eventuell effizienter, als wenn der lahme Apache bei jedem HTTP-Request jedes mal endlos Regeln abarbeiten muss. Die oben aufgeführten Regeln muss der Apache nun schließlich auch bei jedem Request gegen eine PHP-Datei, CSS, Javascript, Fonts, etc. abarbeiten.
                            Momentan habe ich noch den normalen Basic-Tarif im shared hosting. Keine Ahnung, ob da Nginx als Reverse Proxy eingesetzt wird.
                            Hatte bisher immer gedacht, dass auch das normale Apache-System beim Abarbeiten von Zeilen in der htacess sehr schnell ist und Performance da eigentlich keine Rolle spielt.


                            Grundsätzlich ist so ein Hotlinkingverbot schon sinnvoll. Dass andere meinen Webserver nutzen und belasten, ist die eine Sache. Wie sehr das den Server und speziell die performance meiner eigenen Site beeinträchtigt ist schwer zu sagen. Ich würde mal vermuten, dass Hotlinking keine großen, bekannten Sites machen, die am Tag bei einer Webseite 10000 Aufrufe oder so haben. Es müssen aber Webmaster sein, die zumindest keine absoluten Laien sind weil sie im Quellcode die src ablesen. Die machen es dann jedenfalls absichtlich.
                            Ich habe halt keine Lust, regelmäßig nachzuschauen und dann irgendwie reagieren zu müssen.

                            Hinzu kommt, dass Hotlinking sehr einfach ist, man macht es dem Betreffenden also sehr leicht. Ein Bild kopierend klauen, bearbeiten und irgendwie ins eigene Seitensystem einbinden ist demgegenüber wahrscheinlich vielen zu aufwendig.

                            Der dritte Grund ist die Bildersuche selbst, die nach bestimmten SEO-Kriterien entscheidet, welche Seite von z.B. dreien, die alle das gleiche Bild verwenden, in der Bildersuche ausgespielt wird. Es kann also durchaus sein, dass die "Übeltäter" auch noch belohnt werden und statt meiner Website dann in der Bildersuche erscheinen.

                            Ich könnte es vielleicht mal ein paar Monate ausprobieren, also ohne Hotlinkingverbot, aber grundsätzlich macht das schon Sinn.
                            Zuletzt geändert von Martin11; 18.03.2020, 16:57.
                            Grüße,

                            Martin

                            Kommentar


                              #44
                              rp_df ist scheinbar nicht mehr da, aber ich habe es jetzt mit neuen Ausnahmen probiert, die auf den user-agent abstellen.
                              Google hat schon ein parr Bilder indexiert, Bing noch nichts.

                              Die Namen der Crawler lassen sich Web schon finden, aber im Code sind Sie immer unterschiedlich geschrieben, also z.B.

                              Code:
                              RewriteCond %{HTTP_USER_AGENT} !^(.*)MSNBot-Media(.*)$ [NC]
                              oder
                              Code:
                              RewriteCond %{HTTP_USER_AGENT} !^(.*)msnbot-media(.*)$ [NC]
                              Ich vermute mal, es spielt keine Rolle und beides ist o.k., zumindest dann, wenn NC dahinter steht? Ist das für genau solche Fälle?
                              Grüße,

                              Martin

                              Kommentar


                                #45
                                Zitat von Martin11 Beitrag anzeigen
                                rp_df ist scheinbar nicht mehr da, aber ich habe es jetzt mit neuen Ausnahmen probiert, die auf den user-agent abstellen.
                                Fachlich stecke ich da leider nicht so tief aktuell drin, aber warum sollte rp_df nicht mehr da sein wenn es gerade mal wenige Tage her ist? In turbulenten Zeiten wie diesen mag es zwischendurch ja auch mal etwas wichtigeres geben als hier direkt im Forum zu sein! Er wird sicher wieder herkommen

                                Mit freundlichen Grüßen

                                Nils Dornblut
                                Blog - Facebook - Twitter
                                Communitybetreiber: domainfactory GmbH
                                Impressum / Pflichtangaben

                                Kommentar

                                Lädt...
                                X