Kommentare zu folgendem Beitrag: Seedbox-Server mit VPN für Bittorrent einrichten (Tutorial)
1 „Gefällt mir“
Da ich unterwegs bin, habe ich grade nicht die Zeit für die ganzen Gründe (das folgt aber) zu meiner Aussage jetzt! Warum? Ganz einfach, weil ich diese Bastelbüchse für gemeingefährlich halte, in der gesamten Konfiguration !!
Hinzu kommt auch noch, dass aus Gründen des verwendeten qBittorrent, 90% aller ALTs nicht mit der Büchse kommunizieren werden !!!
Seit Monaten werden die qBittorent-Clients auf den ALTs, zu den nicht erlaubten Clients gelistet…Und sollte doch noch dieser Client vertreten sein, dann ausschließlich in ein oder zwei ganz speziellen (geprüften) Versionen! Und diese hier aus dem Tut, gehört nicht dazu!
Ergo → Die Announce wird eine Verbindung mit dieser Büchse nicht zulassen - aus die Maus 
Der Rest zu dem Thema „gemeingefährlich“ folgt später, wenn ich wieder Zeit habe!! 
1 „Gefällt mir“
Der Tut wurde ja auch für die öffentliche Torrenting geschrieben, etvl muss der Hinweis dazugeschrieben werden, es war mir nicht bekannt dass ALTs schon qBittorrent blocken. Als Alternative gibt ja den guten rtorrent.
Eine Abmahnanwalt kann zum Host gehen und den Daten abfragen, der hinter Server-IP steht… Providern wie z.b OVH und Hetzner geben wirklich alles raus, jede Payment, etc. Das VPN-Verwendung unterbindet das.
ALTs brauchen auch nicht unbedingt VPNs zum saugen, aber wenn mal da eine Ermittler drin ist, kann er so die Torrentnutzern protokollieren.
Danke für das Tutorial.
Ich persönlich verwende ein ähnliches Setup. Es besteht aus einem sehr günstigen Server bei OVH (kimsufi): https://www.kimsufi.com/de/. Dort läuft ein VPN-Tunnel von OVPN: https://www.ovpn.com/de. qBittorrent wurde so konfiguriert das es nur auf den VPN Tunnel lauscht. Als Krönung wurde die lokale IP „abgeschaltet“ und es wird via Tailscale/Wireguard auf die IP von Tailscale zugegriffen.
Dennoch, nettes Tut, thnx 4 that.
1 „Gefällt mir“
qBittorrent 4.3.x sind überall kein Problem. 4.4.x ist etwas heikel, das stimmt.
1 „Gefällt mir“
Okay, das mit qBittorrent habe ich ergänzt. Zu allem anderen wird Firecooler Rede und Antwort stehen.
Ich bin erst seit 30 Minuten wieder @home und hab schon drei DINA4-Seiten voll! 
Ich denke, dass ich in der nächsten Stunde antworten werde!
Es ging mir hierbei nicht nur um ein paar Kleinigkeiten, sondern das das Tut in der Config schon leicht gefährdent ist…ich reiss doch keinem den Kopf ab! Allerdings baue ich Roots und Seedboxen fasdt schon 20 Jahre, egal wie konfiguriert - egal, ob manuell oder autom. etc
OK…vorab einmal ! Ich hab ja nicht gesagt, dass alle QB Mist sind…höchtens 95% 
Zweitens wollen die ALTs, die ALLE nicht mehr haben!
Jetzt kommt erst der wichtige Teil !! qBittorrent ist eine reine Client-Software und wurde nie für den Server-Betrieb oder erst recht nicht für den Seedbox-Betrieb konzipiert 
Unter anderem deswegen muss man laut Tut ja auch noch eine GUI etablieren, weil man ohne diese NIEMALS an den QB rankommen könnte!
Sooo, ich schreibe jetzt an dem eigtl. Text weiter…da steht das alles mit drin
So denn…nun mal die Gründe, die mich zu meiner Aussage gebracht haben:
Wenn man sich schon für Ubuntu als Server-System entscheidet, sollte man zumindest eine LTS-Version einsetzen! Das haben die letzten Jahre eindeutig gezeigt! Nicht nur, dass mindestens 5 Jahre Updates (bei 1804 sogar 10 Jahre!) bei LTS garantiert werden…die LTS-Rels sind auch umfangreicher, da diese speziell für Produktiv-Server entwickelt werden. Hier wäre also 2004 ratsam gewesen und dann in ca. zwei Monaten das Upgrade zu 2204.
Im Normalfall werden für Server-Installationen zum Seedbox-Aufbau, immer nur Debian, Gentoo, CentOS, Feodora von den Entwicklern (siehe z.B. Github) empfohlen! Beziehungsweise hat Ubuntu nur Glück, dass es auf Debian basiert und NUR deswegen mit ein paar Seedbox-Skripten klarkommt. Bei den Entwicklern aus der Community bzw. bei den Seedbox-Providern (Business) stehtr eigentlich immer → Tested with Debian (User-Support granted)
Bei Ubuntu wird grundsätzlich kein Support gegeben!! Ubuntu ist nach wie vor eigentich nur ein Linux, nach dem Windows-Prinzip! ^^ Bei der Entwicklung von Ubuntu, wurden nämlich einfach viel Code aus dem Debian nicht übernommen, wegen der Datenmenge dasmals - unter anderem auch für den Betrieb eines vernünftigen Root bzw. einer Seedbox usw.
Was als nächstes im Tutorial grob fahrlässig ist, wäre die Tatsache, dass bei der OS-Install in keinster Weise daran gedacht wurde, die Standard-Ports für SSH / FTP (mind. 21 / 22) auf andere, zufällige Ports umzulegen?! Anderenfalls stehen die Server sonst, ein paar Stunden später, schon bei Shodan, Censys, Thingful etc. pp. in den Datenbanken. Und noch schlimmer wird es, wenn dann die ganzen kriminellen Hacker, Ransomware-Groups, Malware / Bot - Entwickler am laufenden Band das Netz nach diesen offenen Ports crawlen! Mindestens 50% der C&Cs in Bot-Netzen bestehen aus ehemaligen Seedboxen und anderen ungeschützten Servern, die übernommen wurden! BTW: Behörden scannen das Netz auch nicht anders…!
Seedbox-Skripte ändern diese verdächtigen Ports entweder automatisch oder brechen an dem Punkt einfach die Installation ab - gnadenlos, weils halt wichtig ist!
Jetzt komme ich mal zum Thema VPN:
Damit der User sich vor Abmahnungen schützen kann, ist ein VPN als Idee ja grundsätzlich i.O. Aber dieser sollte sich auf dem Client befinden und nicht unbedingt auf dem Server. Die Kosten für den VPN-Account sind in beiden Fällen gleich. Auf dem Server kostet das nur unnötig Ressourcen und bei einer Fehlkonfiguration den Server komplett, wenn man Pech hat! Bei der Konstellation mit einer Hetzner-Büchse, sowieso höchst kontraproduktiv, was man ja eindeutig an den zusätzlichen Routen über manuelle IPTables sehen kann! Viel schlimmer noch, die zusätzlichen Routen machen nicht nur ein paar Löcher in den VPN-Dienst (da konnte ich mir den Schenkelklopfer nicht mehr verkneifen!) Sie weichen die Schutzleistung des VPN für den User einfach extrem auf… In mind. 95% der Anfragen von aussen, wird dies DNS-Leaks zur Folge haben inklusive aller am Rande auftretenden Fehler. Das hätte man, wenn es denn s sein soll, viel besser und ungefährlicher mit „dnsmasq“ einrichten können! DNS-Leaks wären somit auch keine vorhanden, da man mit der Maskierung „Umleiten und Manipulieren von DNS-Abfragen“ integriert hat und seine Zusatz-Routen trotzdem festgelegt hat.
Ich kenne keinen Coder oder Script-Provider, der einen VPN in seinen automatischen oder halbautomatischen Skripten, mit integriert hat. Eigentlich nur einige Seedbox-Provider (z.B. ultra.cc usw.) haben den Dienst bei einer Box mit im Angbot aus folgenden Gründen:
- Wenn der User keinen eigenen VPN besitzt (Verhinderung von doppelten Kosten / pro Kunde)
- Die dortigen professionellen VPN, werden für ganze Server-Cluster zur Verfügung gestellt unter ganz anderen technischen Voraussetzungen!
- Entweder laufen dafür eigenständige Maschinen, VMs oder halt direkt auf dem Router oder managed Switch!
Ich komme jetzt mal langsam zum nächsten, größeren sicherheitsrelevanten Punkt:
- a) Zuerst die obligatorische Frage: WARUM installiert und konfiguriert man sich zuerst einen weg, um einen Linux-Server aufzusetzen und „spendiert“ diesem danach danach eine GUI ??? Dann könnte man auch gleich einen KVM-Server mit einem MS-System aufsetzen…!!
- b) Jetzt macht sich jmd. die Mühe (auch wenns nicht unbedingt erfolgreich war) um einen sicheren Linux-Server ins Internet zu setzen, der auch noch die User schützen soll. Und zum Schluß im Tutorial, in den letzten beiden Aktionen, macht man dann die beiden schwerwiegensten Fehler, die einen wieder zurück in die Steinzeit katapultieren! → GUI & xRDP
Warum gibt es im Netz so gut wie keine Linux-Server mit GUI ??? Genau, weil diese brandgefährlich sind aus diversen Gründen!
Zwei Hauptgründe dazu wären:
-
Ein Bash-basierter Linux-Server im Internet, wird durch eine GUI quasi seinen SAFE - Status gegen Null fahren! Die theoretische Angriffsfläche wird durch die GUi mindestens um den Faktor 1000 vergrößert…Grafische Oberflächen bieten einem Hacker oder auch einer Behörde (what ever!!), die relevanten Angriffspunkte, an die sich auch jeder dämliche Virus festbeissen würde und die sonst schlichtweg gar nicht erst vorhanden wären. Verschiedene Programmiersprachen, Fonts und diverse Sheets wie PHP, Java, HTML etc. pp. können sofort genutzt werden, um so direkt bis auf Kernel-Ebene und HALs alles nutzen zu können!
-
Um überhaupt Zugang zur GUI als User zu bekommen, sagt das Tutorial zwar richtig aus, dass man dafür einen Remote-Desktop nutzen muss!!
Und genau dieser Punkt hat mir den Todesstoß versetzt >>> xRDP
Rhetorische Frage in die Runde:
Was wird bei fast allen Vulnerability Scanner, Crawler, Bots, Spider, Exploit-Scanner immer als erstes abgefragt ?? Richtig, RDP & xRDP Deswegen bekommt man auf irgendwelchen Marktplätzen, wo Combos, Account-Dumps und ähnliches vertickt werden im Überfluss Zugänge über RDP-Protokolle!!
Das man zu Hauf die geklauten Zugänge zum gesmten System über RDPs dort findet, liegt in der Natur der Sache an sich. Diese Remote-Protokolle sind uralt und waren noch nie sicher und werden es auch nicht mehr! Wegen diesem Schrott war auch Microsoft schon zig mal vor Gericht. Und sie verweigern sich konsequent seit Windows NT 3.5.1 zu Bugfixes, neue Protokolle, revidierte Protokolle…warum auch immer!
Fazit auf das Tut bezogen:
Mit einem Root und / oder Seedbox (Dedi, VPS, KVM etc.) verbindet man sich ausschliesslich über:
FTP / SFTP / FTPS / SSH (neue Versionen) / HTTPS mit SSL - das wars schon!
Dabei spielt es keine Rolle, ob selber konfiguriert oder vom Provider gemietet. Konfiguration auch egal, ob über automatisches Skript, manuelles Tutorial, oder sogar über die Skripte von Entwicklern, für die Seedbox-Provider / Reseller !
Genannt wären da zum Beispiel:
- Swizzin Ltd.
- Quickbox (Business / Community)
- Oder auch der Lieblings-Coder solcher Skripte im P2P → arakasi72 und seine Kollegen
P.S. @Firecooler THXXX FOR TUTORIAL…Sorry, ich weiß ja, das dies viel Arbeit ist, aber da musste ich so !
1 „Gefällt mir“
Du machst dir zuviele Sorgen, zumal dass es sehr viele Uploadern gibt, die mit Windows Server OS rumläuft.
Die Tutorial geht es um den VPN-Anwendung direkt im Server. Dass man dafür extra Routen hinzufügt, ist es auch richtig, da man sonst den Server-IP mitsamt Dienste darauf nicht von außen erreichbar sind.
DNS-Abfragen laufen weiterhin über VPN, sobald die VPN-Verbindung erfolgt sind.
Einsatz von LTS-Versionen findet in Unternehmen Sinn, xRDP ist kein offizielles Windows-Terminal-Programm und dafür gibt es sehr wenige gemeldete Sicherheitslücken, was postiv ist.
Debian/Ubuntu Vergleiche kannst du gerne lassen, du kannst z.b. Debian installieren, mir ist das egal. Der größten Streamhoster damals hat Ubuntu auf allen seinen Servern benutzt und niemand beschwerts.
qBittorrent wurde von mir auf Herz und Nieren geprüft, da es im Gegensatz zu anderen Torrentclients wie z.b rtorrent bei mehr als 3000 Torrents in der Liste nicht abstürzt und keine Bottlenecks in der Process Scheduler gibt.
Außerdem hat qBittorrent auch eine Webinterface, dass man selber konfigurieren muss.
rTorrent bzw ruTorrent stürzt ab und zu ab, wenn zufällig ein Fehler aufgetreten ist und hängt gerne bei mehr als ~1000 Torrents fest, dann muss man ihn neu starten. Die ständigen Neu-Überprüfungen der Daten sind auch zeitraubend.
Sicherlich will der Nutzer nicht nur Torrents mit seine Server machen oder nebenbei Scripts nach Downloads laufen lassen…
Gerne kannst du eine unendlich langes Tutorial mit allen Know-hows für Absicherungen schreiben, aber ich habe nicht die Zeit dafür. Danke für die Blumen.
1 „Gefällt mir“
Mein Kommentar bezog sich allein auf die Whitelisten der Trackerbetreiber, qBit 4.3.x wirst du da fast immer finden. Ob qB jetzt für Server perfekt geeignet ist, muss jeder selbst wissen. Meiner Erfahrung nach sind ca. 1/3 aller Seedboxen mit qBit unterwegs und einige Trackerbetreiber pushen qBit sogar explizit. Die Masse macht natürlich nach wie vor r(u)Torrent aus, aber das würde ich bei einer vierstelligen Anzahl an Torrents nicht mehr empfehlen. qBit lässt sich auch aus der Ferne steuern, siehe GitHub-Wiki von qBit. Leider kann man hier nicht direkt auf GitHub verlinken, warum auch immer.
Die letzten 5 Jahre bei 18.04 dürften dabei aber nur Paid Support sein.
Ich persönlich würde immer die Linux-Distro empfehlen, mit der man die meiste Erfahrung hat. Und irgendwas bekanntes, was in ein paar Jahren immer noch gewartet wird. Und kein Rolling-Release-Distros wie Arch.
Na ja, so wichtig ist ein Portwechsel auch nicht. Ich habe es bei meinen VPS gemacht, aber nur um Fail2Ban etwas Arbeit zu ersparen. Den richtigen SSH-Port bekomme ich nach einem kurzen Scan sowieso raus. Sicherheitstechnisch bringt das wenig bis gar nichts, es reduziert nur ein bisschen die Anfragen.
Über SSH nutzt man am besten einen Schlüssel und deaktiviert dabei auch gleich noch die Anmeldung via Passwort. Ich kann nicht glauben, dass das bei Seedbox-Anbietern heutzutage kein Standard ist. Dann ist der SSH-Port ohnehin komplett egal.
Ich halte die komplette im Tutorial beschriebene Vorgehensweise für veraltet. Das hat man vor 10 Jahren vielleicht so gemacht, aber heute würde ich es anders machen:
VPS (IaaS) mit root mieten
Lieblingslangzeitlinuxdistro drauf
Firewall drauf
Fail2Ban drauf
SSH nur via KeyPair, Passwortzugang deaktivieren
automatische Updates aktivieren
ggf. automatische Backups aktivieren
alles runterschmeißen was nicht benötigt wird
Container Orchestration Software drauf (Docker-Compose/Kubernetes)
Reverse-Proxy als Container laufen lassen (NginX oder Traefik)
Torrent- & ggf. Usenetsoftware als Container laufen lassen (mit ausschließlicher Kommunikationsmöglichkeit nach außen via Wireguard), z. B. docker-qbittorrentvpn
ggf. weitere Container für Datentransfer (der Reverse-Proxy kümmert sich dabei auch noch um Let’s Encrypt Zertifikate für HTTPS-Zugänge auf die Dateien & WebUI)
ggf. weitere Container wie Plex/Jellyfin
2 „Gefällt mir“
Mit 40 €/Monat plus Kosten für VPN ein recht teueres Hobby. Dazu noch kompliziert, wenn man seitenlange Anleitungen dafür braucht.
Ich hatte ~2005 eine Seedbox bei Hetzner gemietet, da lief ein eDonkey Client darauf, damals noch ohne VPN weil Abmahnanwälte gab es da noch nicht. Auch damals schon komplizierter einzurichten als so ein lokaler eMule Client mit grafischer Oberfläche, aber nicht ganz so schlimm wie hier beschrieben. An Abstürze kann ich mich ebenfalls erinnern, ich habe dann einen CRON Job aufgesetzt der das einmal pro Tag gekillt und neu gestartet hat.
Der Zweck des Ganzen war aber nicht, neue Inhalte zum Konsumieren zu bekommen, sondern als leidenschaftlicher Blümchenfan meine digitalisierten Videos von Fernsehauftritten zu verbreiten, also zu seeden. Mit einer lahmen 1.0/0.13 Mbps lokalen Internetleitung blieb mir auch gar nix anderes übrig.
Heute bin ich kein Fan mehr, will niemanden mehr missionieren und die Internetleitung wurde auch nur etwas schneller, 2.4/1.7 Mbps sind es inzwischen. Damit würde ein aus Sicherheitsgründen lokal eingerichtetes VPN bei mir zum Flaschenhals werden.
Würde ich mit so einer langsamen Leitung heute noch Inhalte haben wollen, würde ich mir den 3 €/Monat Account von diesem holländischen Usenetprovider zulegen, eventuell bisschen was noch an ein Usenet Forum spenden. Aber keine teuere und komplizierte Seedbox mehr.
Diese und ähnliche Server-Konfigurationen, würde ich da auch bevorzugen - sieht vernünftig aus!
Wenn man somit also bei ca. 45€ / Monat liegt und sich trotzdem um alles selber kümmern muss, kann man sich natürlich besser auch eine fertige und dicke Seedbox, bei einem prof. Anbieter mieten, was sogar weitaus günstiger ist! Hier mal ein paar Anbieter (es geht aber auch noch günstiger!):
Eine Standard-Büchse, die für den „normalen“ p2p-User ausreichend ist, bekommt man sogar schon für weit unter 10€. Nur als Beispiel sei hier mal Rapidseedbox genannt…
…oder hier von Seedboxio:
1 „Gefällt mir“
Schlimm genug an sich, daher besser no comment!
Habe ich dir ja auch recht gegeben. Mein Hinweis bezog sich darauf, wie diese Routen eingepflegt wurden - anstatt normale IP-Tables zu kreieren, besser mit dnsmasq das Ganze konfigurieren. Letztlich greift man bei beiden auf /etc/hosts zu, aber dnsmasq lässt dabei halt das Umleiten und Manipulieren von DNS-Abfragen zu und cached dabei auch selber.
xRDP ist genauso wenig wie RDP ein Windows-Terminalprogramm! In beiden Fällen handelt es sich schlichtweg nur um ein Übertragungsprotokoll. Bei xrdp handelt es sich um eine Open-Source-Implementierung des Remote-Desktop-Protokolls, das die Windows Terminal Services (RDS) verwenden, um sich mit Windows-Desktops zu verbinden. Das xrdp-Paket bringt das RDP-Protokoll auf den Linux-Rechner, indem es einen X-Server bereitstellt, der Verbindungen vom Windows-Terminalserver-Clients (mstsc) akzeptiert.
Das kann passieren bei ca. 1000 Torrents, muss aber nicht zwingend - kommt auf die Konfiguration von libtorrent an! Im Übrigen hatte qBittorrent ein fast identisches Problem bei ca. 1500+ Torrents…
Ich habe ja nicht behauptet, dass es nicht so ist! Ich gebe nur zu bedenken, dass qBittorrent das Qt-Framework als Grundlage für seine GUI verwendet.
- qBittorrent 4.3.x erfordert mindestens Qt 5.11.
- Zum Zeitpunkt des Schreibens erfordert der aktuelle
masterZweig mindestens Qt 5.15.2.
Viele Distributionen, insbesondere Debian, Ubuntu (insbesondere LTS-Releases) und ihre Derivate, bieten keine aktuellen Qt-Pakete in ihren Repositories oder aktualisieren sie nur sehr langsam. In solchen Fällen müssen Sie sie von einer anderen Stelle beziehen, z. B. vom offiziellen Installationsprogramm von der Qt-Website! Wie du siehst, kann es gar nicht egal sein, welche Distri man nutzt. Es kann also durchaus passieren, dass deine GUI ohne zusätzliche Installationsarbeit zum Framework, erst gar nicht funktioniert - davon finde ich leider nichts im Tut…?
Das weiss ich nicht, ist aber auch völlig egal, wenn es um das Tutorial geht. Dort geht es doch nur um die Funktion als Seedbox!
Laufzeitabhängigkeiten des qBittorrent bzw. eigentlich aller Clients, sind meist von Python abhängig! Eine aktuellere Python-Version fixed diese Einbrüche, wenn diese vorhanden sein sollten!