Python-Shell und Portscan beim Webhoster

[droptix]

Mein Webhoster bietet mir keinen Shell-Zugang. Ich kann zwar mühselig mit einer PHP-Shell arbeiten, aber PHP wird unter dem Account des Webservers ausgeführt. Also jede Datei die neu angelegt wird gehört dem Webserver-Benutzer und nicht mir. Daher kann ich sie über FTP auch nicht löschen, sondern wieder nur über PHP. Alles nicht so der Hammer...

Daher habe ich mir eine simple Python-Shell gebastelt. Auf dem Webserver muss sie als XML-RPC-Server gestartet werden. Daheim möchte ich mich dann als Client verbinden. Ich schicke lediglich Befehle rüber und der Server schickt mir die Ausgabe zurück.

Damit das alles noch unter meinem Account läuft, kann ich Python-Programme als Cronjob starten. Der XML-RPC-Server soll also auf dem Webserver per Cronjob angeworfen werden. Soweit so gut.

Für die Kommunikation brauche ich einen Port. Wie kriege ich raus, welchen Port ich dafür benutzen kann. Es gibt ja Portscanner (hab hier auch schon einige in Python geschriebene gefunden).

Außerdem: Ich brauche ja auch noch einen Host. Nun kenne ich zwar meine Web-Adresse und auch die IP des Servers, aber ist das dann auch gleichzeitig mein Host?

[jens]

Warum das ganze so aufwendig? Eine Shell bekommst du schon schon als einfaches CGI hin. Ohne XML-RPC und cronjobs...

Ich hab sowas mal als Plugin für PyLucid geschrieben, sollte sich relativ einfach auch als einfaches CGI umformen lassen: http://pylucid.net/trac/browser/PyLucid ... vilEval.py

[droptix]

Hmmm. Deine Python-App produziert HTML-Code... ich möchte aber lieber eine schwarze Konsole As simple as possible.

Der Umweg über Cronjobs muss nur deshalb sein, weil alles was über den Webserver läuft unter dem Webserver-Account gestartet wird. Bei PHP weiß ich es ganz sicher. Die Hoster setzen kein suPHP oder PHP über FastCGI ein, wo die Skripte über meinen Account gehen. Ein Cronjob wird aber unter meinem Account gestartet. Ich muss den XML-RPC-Server ja nur einmal anschubsen.

Mit CGI kenne ich mich Null aus (ja, es ist eine Schnittstelle). Mit Python schon eher... Was mich reizt ist dass ich auf der Serverseite kein CGI voraussetzen muss, sondern nur Python. Das funzt auf einem PC ohne Webserver ebenso wie auf einem (Symbian)-Handy oder Windows CE PDA. Daher hätte ich gern einen SimpleXMLRPCServer.

[jens]

Ich denke es geht darum, das du bei deinem WebHoster dir einen "Zugang" baust?
IMHO musst du dann immer damit leben, das dein Skript mit User/Gruppe des WebServers ausgeführt wird.

Wenn der WebServer richtig eingerichtet bzw. abgesichert ist, solltest du eigentlich auch nicht so einfach einen Dienst auf einem Port öffnen können.

[lunar]

Ich glaube kaum, dass die Gateway-Firewall des Anbieters für deinen Server irgendeinen obskuren Port durchlassen wird. Zudem könntest du ein ganz kleines bisschen Ärger mit dem Anbieter bekommen. Tunnel nach außen graben ist im Vertrag wohl kaum erlauben und ergo ein Kündigungsgrund.

Wenn du Shellzugang willst, dann solltest du erwähnte Webvariante verwenden oder lieber gleich zu einem vernünftigen Anbieter wechseln.

Webserver sind halt Webserver und keine Rootserver Deswegen gibts auch nur Web und keine Shell...

Edit: Wenn du's trotzdem probieren willst, Ports > 1000 sollten eigentlich offen sein. Du könntest drei zufällige Ports zwischen 1000 und 10000 definieren. Der erste ist Standard, die zwei anderen dienen als Fallback für den Fall, dass ein Port bereits belegt ist. Dein Client versucht dann, sich nacheinander mit allen drei Ports zu verbinden. Kommt von einem Port was sinnvolles zurück, dann passts, wenn nicht, dann läuft der Server höchstwahrscheinlich auch nicht und die Anwendung hat eventuell nur mit einem anderen Server gesprochen ...

[droptix]

Jepp, das trifft es: ich "baue" mir einen Zugang. Da ich Cronjobs habe, kann ich prinzipiell alles tun, wozu ich berechtigt bin. Also schreibe ich mir momentan immer Python-Skripte mit `os.system()`-Befehlen, um z.B. Tar-Archive auszupacken. Würde ich das über die PHP-Shell machen, startet der tar-Prozess unter dem Webserver-Account. Alle entpackten Dateien gehören dann nicht mehr mir -> Löschen und Bearbeiten geht dann nur noch über die PHP-Shell und nicht über FTP.

Es ist ein Workaround der gut funktioniert, aber nervt. Ich muss z.B. immer sowas hier machen:

Code: Alles auswählen

#!/usr/bin/python
import os
os.chdir("/srv/www/htdocs/web123/html")
if not os.path.exists("foo"):
    os.system("tar xfvz foo.tar.gz")

Der Cronjob wiederholt sich jede Minute, damit ich einfach nur die zugehörige Python-Datei ändern muss. Also muss ich auch checken, ob eine Aktion nicht schonmal durhcgeführt wurde... extreeem nervig.

Daher möchte ich wenigstens probieren, ein Python-Skript als Server zu starten. Mir fehlen allerdings ein paar Vorkenntnisse -> hat jemand nen Vorschlag welche Ports so üblicherweise offen sind oder wie ich das rauskriegen kann?

[Y0Gi]

Nix für ungut, aber aus eigener Erfahrung kann ich nur sagen, dass es sich wirklich lohnt, einen vernünftigen Shell-Zugang zu haben. Mein Tipp: Wechsel auf ein umfassenderes Angebot, und wenn es ein Root-Server ist.

[nkoehring]

das mit den offenen ports ist kein großes ding.
du koenntest einfach netcat im servermodus starten und schauen ob du connecten kannst... und damit hast du dann auch ne moeglichkeit fuer eine konsole (falls netcat mit der option GAPING_SECURITY_HOLE compiliert wurde). ansonsten kannst du aber wenigstens die ports durchprobieren.

geht natuerlich auch mit python... schau dir einfach mal das "socket"-modul an.

ich geh jetzt schlafen... gut nacht

[droptix]

Nix für ungut, aber aus eigener Erfahrung kann ich nur sagen, dass es sich wirklich lohnt, einen vernünftigen Shell-Zugang zu haben. Mein Tipp: Wechsel auf ein umfassenderes Angebot, und wenn es ein Root-Server ist.

Einen Root-Server will ich nicht pflegen, wenn dann schon eher ein Dedicated Root Server... Ansonsten habe ich lange nach einem passenden Hoster gesucht und bin recht zufrieden, außer:

1) kein suPHP (hat aber keiner in der Preisklasse)
2) keine Shell (haben auch nur die wenigsten)

Dafür unterstützt mein Hoster Symlinks. Das ist mir sehr wichtig. Bei vielen anderen Anbietern (die dann z.B. eine Shell haben) sind Symlinks verboten. Wäre suPHP vorhanden, dann könnte ich auch mit einer PHP-Shell leben.

Zum `socket`-Modul. Ich hab schonmal eine Server-/Client-Software mit Python und dem `socket`-Modul gebaut, fand es jedoch wesentlich umständlicher als einen SimpleXMLRPCServer aufzusetzen.

[Leonidas]

Einen Root-Server will ich nicht pflegen, wenn dann schon eher ein Dedicated Root Server...

Du meinst wohl Managed? Na, die sind dann "etwas" teurer.

[droptix]

Du meinst wohl Managed?

Ja da hast du wohl recht... verirrt im Webserver-Wirrwarr

Preis spielt halt auch eine Rolle. Daher "nur" ein normales Webhosting-Paket ohne Root- oder Managed Server.

[Y0Gi]

Einen VServer gibt's schon für ~10€, soweit ich das richtig weiß.

[droptix]

Es gibt auch VServer ab 5,- EUR, aber billig ist echt nicht immer gleich gut. 10,- EUR/Monat reize ich nicht aus, weil mir da auch zuviel dabei ist. Ich bin derzeit bei 2,50 EUR

Wir driften hier aber vom Thema ab. Nicht dass es jetzt Preisempfehlungen hagelt...

1) ich möchte/kann meinen Anbieter nicht zu einem angemessenen Preis wechseln
2) ich hab außer bei Cronjobs keine Möglichkeit, Befehle unter meinem Benutzeraccount auszuführen
3) ich hab keinen Shell-Zugang, aber ich hätte gern einen

Die Frage ist löst eine Python-Shell dieses Problem und ist das legal?

[Y0Gi]

Am Besten fragst du deinen Hoster, ob er das toll findet.

[jens]

Genau aus dem Grunde habe ich die Seite [wiki]Python Webspace[/wiki]gemacht.

Ich bin z.Z. bei GPcom. Dort habe ich zwar einen shell Account, kann damit aber recht wenig machen. Der Server ist generell sehr konservativ Konfiguriert. Also an allen Ecken und Enden wird man eingeschränkt.

@droptix: Du sagst, das PHP mit den Webserver-Account läuft. Und Python??? Python CGI Skripte sollten eigentlich auch mit den Rechten der Webservers laufen.

Warum schaufelst du die Archiv Datei nicht direkt per Upload hoch? Ein Skript auf dem Server könnte es theoretisch entpacken und per FTP speichern. Ist zwar auch sehr umständlich, aber dann hast du keine Probleme mit den Dateirechten.

[droptix]

Du sagst, das PHP mit den Webserver-Account läuft. Und Python??? Python CGI Skripte sollten eigentlich auch mit den Rechten der Webservers laufen.

Python verarbeitet der Webserver nicht, also kann keine Python-Skripte als URL aufrufen. Aber ein Cronjob startet Befehle auf dem Betriebssystem (nicht dem Webserver). Cronjobs kann ich jede Minute starten. Daher habe ich eine Datei "cronjob.py" in meinem Speicher liegen, die jede Minute aufgerufen wird. Wenn ich die nun jede Minute bearbeite und einen neuen Befehl reinschreibe, habe ich eine 1-Minute-Shell Also rein technisch kann ich alles machen, nur eben seeehr langsam und aufwändig.

Warum schaufelst du die Archiv Datei nicht direkt per Upload hoch? Ein Skript auf dem Server könnte es theoretisch entpacken und per FTP speichern. Ist zwar auch sehr umständlich, aber dann hast du keine Probleme mit den Dateirechten.

Mach ich ja: ich schaufel beispielsweise das tar.gz-Archiv hoch und starte dann als Cronjob den tar-Befehl zum entpacken. Anschließend lösche ich das tar.gz-Archiv und leere den Cronjob.

[jens]

In dem Falle würde ich mal den Hoster wechseln

[droptix]

Was wie bereits gesagt für mich keinen Sinn macht.

1) Hab ich bei preislich vergleichbaren Anbietern keine Symlinks.
2) Nützt mir Python über CGI auch nichts, wenn die Skripte nicht unter meinem Account ausgeführt werden.

[jens]

Shell, Symlinks und fastCGI habe ich bei GPcom schon. Allerdings hast du recht, die Skripte werden mit den Rechten vom WebServer ausgeführt. Das ist IMHO bei allen Shared-Webhostern leider so

Ansonsten wäre das PyHosting Projekt was für sich: ##pyhosting @ irc.freenode.net Aber eigentlich ist der Server dort dicht.

[droptix]

Tja für CGI gibt's ja mod_suexec, um die unter Benutzerrechten auszuführen. Speziell für PHP gibt's suPHP.

Leider benutzt das kaum ein Webhoster. Zumindest kenne ich keinen. Die Webserver sollen angeblich ein wenig an Performance einbüßen, wenn man diese sinnvollen Möglichkeiten einsetzen würde.