nicht angemeldet
Daten und Script klauen bei Multihost Providern?!?
Man Man Man,
wer hätte das gedacht, wenn Micha mal Langeweile hat...
Mir ist mal ein Gedanke gekommen ob der Server bei meinem Provider
denn ich mir mit ca. 1500 anderen Teile (Webspacepakete) es zu lässt,
wenn ich mittels Perl mal die anderen Accounts durchsuche und event.
Scripte kopiere zum Runterladen, oder andere Daten.
SCHRECK ...... ES GEHT.
Ich habe ein kleines Script geschrieben mit dem ich die Server
konfiguration auslesse und so erfahre wo die anderen Accounts liegen,
und such in diesen nach z.B. .pl,.cgi,.php etc. und wenn er was findet
sagt er mir was und fragt ob es kopiert werden soll, und auch das
geht ohne Probleme.
Also mit anderen Worten ich kann da mittels Perl auf dem gesamten
Server zugreifen, ohne Probleme.
(spass:) Braucht jemand CONFIXX Pro, kann ich kopieren vom Server?!?
Also sowas darf nicht sein ich tippe mir die Finger bunt und investiere
viel Geld in Bier und Zigaretten, und jemand anderes der genau so
langeweile hatte wie ich, holt erst mal locker meine Scripte.
Diese Mglichkeit muß verhindert werden, wie ist eure Meinung dazu??
grüße Micha
-
Hi Promicha,
ist ne Schlamperei, das ist klar. Hast Du die Brüder mal angeschrieben?
Viele Grüße
Mathias Bigge-
Hi,
ist ne Schlamperei, das ist klar. Hast Du die Brüder mal angeschrieben?
noch nicht, ich sende dennen Montag nen bösen aber höflichen Fax.
gruß Micha
-
Hi,
ist ne Schlamperei, das ist klar. Hast Du die Brüder mal angeschrieben?
Nein, dass ist ein typischer Anfängerfehler, vor dem auch gerade grosse Provider nicht gefeit sind.
noch nicht, ich sende dennen Montag nen bösen aber höflichen Fax.
Du solltest aber bedenken, dass die meisten Provider nur deswegen so günstig sind, weil die nicht so einen tollen Service bieten.
Man kann nicht erwarten, für nen Euro im Monat einen tollen Sysadmin zu haben, der den Server bombenfest halten kann.Höhere Sicherheit geht auch meist zu Last der Usability.
Ganz im ernst: Alle Provider, die FTP anbieten sind potentiell unsicher.
Aber derzeit kann man als Provider auch kein Geschäft machen, wenn man den Kunden abverlangt, sich ein Programm für sichere Dateiübertragung zu kaufen.
Die Antwort des Kundens ist dann: "Was Sie bieten kein FTP? Woanders krieg ich das ja auch und die sind wohl auch sicher! Und dann wollen Sie auch noch mehr Geld haben???! Ihr habt wohl nen Knall!"Das kannst du nur dann von einem Kunden abverlangen, wenn du den in ein größeres Softwareprojekt eingebunden hast, wo Sicherheit und Internetanbindung eine Rolle spielt.
Ciao,
Wolfgang-
Hallo!
Aber derzeit kann man als Provider auch kein Geschäft machen, wenn man den Kunden abverlangt, sich ein Programm für sichere Dateiübertragung zu kaufen.
Unwissende Frage: Was gibt es denn da für Programme und Techniken? Tut mir leid, ich weiß es wirklich nicht.
Marko
-
Hi,
Aber derzeit kann man als Provider auch kein Geschäft machen, wenn man den Kunden abverlangt, sich ein Programm für sichere Dateiübertragung zu kaufen.
Unwissende Frage: Was gibt es denn da für Programme und Techniken? Tut mir leid, ich weiß es wirklich nicht.
Unter Unix, Linux und MacOS: "ssh" aufrufen. Ist bei den meisten
Distributionen schon vorinstalliert.Unter Windows muss man sich sowas jedoch meist noch kaufen, es sei denn man such sich ein Freewaretool, wie "putty".
EIn gutes kommerzielles Produkt ist aber "ssh" von der Firma, die auch hinter ssh.com steht.Hintergrudn bei allem: Die Uebertragung wird verschluesselt.
Dabei auch Kennung und Passwort.Bei FTP und TELNET dagegen wird alles im Klartext uebers Netz gesandt.
Ciao,
Wolfgang-
Hi xwolf,
für Windosen gibt's für lau WINSCP2, auch nicht schlecht.
Viele Grüße
Mathias Bigge -
Aber derzeit kann man als Provider auch kein Geschäft machen, wenn man den Kunden abverlangt, sich ein Programm für sichere Dateiübertragung zu kaufen.
Unter Unix, Linux und MacOS: "ssh" aufrufen.
Hintergrudn bei allem: Die Uebertragung wird verschluesselt.
Dabei auch Kennung und Passwort.Möglicherweise blöde Frage: FTP ist für Dateiübertragung, ssh für einen Shellzugang. Wo ist denn da der Zusammenhang? Der Hoster möchte seinen Kunden doch wohl eher lediglich die Möglichkeit bieten, Dateien abzulegen, als das Risiko einer ausgewachsenen Shell einzugehen?
Davon mal abgesehen verhindert ssh in keinster Weise das Problem, daß Promicha beschrieben hat. In den Linux-Distributionen, die mir bis dato untergekommen sind, war der komplette Verzeichnisbaum für alle Anwender standardmäßig lesbar. Deshalb ist es auch nicht verwunderlich, daß er per CGI (suexec oder nicht) das System durchwühlen konnte - das ist garantiert bei fast allen Hostern so.
Die passende Sicherungsmaßnahme wäre das simple Löschen der allgemeinen Zugriffsrechte; will man auch die (trotzdem immer noch offenen) Benutzer-HTML-Verzeichnisse sperren, kommt man um einen Eingriff in den Kernelcode nicht drumrum.
Gruß,
soenk.e-
Hallo,
Möglicherweise blöde Frage: FTP ist für Dateiübertragung, ssh für einen Shellzugang. Wo ist denn da der Zusammenhang? Der Hoster möchte seinen Kunden doch wohl eher lediglich die Möglichkeit bieten, Dateien abzulegen, als das Risiko einer ausgewachsenen Shell einzugehen?
es gibt "scp" und "sftp", ersteres ist ziemlich unbequem (man muss den genauen Pfad der Datei auf dem Zielrechner kennen), das zweite funktioniert wie ftp mit put, get, ... .
Gruss
Thomas
-
-
-
-
Hallo xwolf,
Nein, dass ist ein typischer Anfängerfehler, vor dem auch
gerade grosse Provider nicht gefeit sind.Das ist nicht nur ein Anfaengerfehler, sondern ein ziemliches
Problem. Denn richtet man das anders ein, braucht man entweder
viele IPs und viel HD-Platz, oder man nimmt in Kauf, dass bei
einem CGI-Script zwei Programme gestartet werden (CGI-Wrapper
(z. B. suExec)). Erst bei Apache 2 soll sich das aendern.
Es gibt zwar ein Apache1.3-Modul, dass die Aufgaben eines
CGI-Wrappers uebernimmt, aber dafuer muss a) der Apache mit
root-Rechten laufen und b) bremst das ziemlich aus (vor jedem
Request ein seteuid() und ein setegid() und danach nochmal).Gruesse,
CK-
use Mosche;
Nein, dass ist ein typischer Anfängerfehler, vor dem auch
gerade grosse Provider nicht gefeit sind.Das ist nicht nur ein Anfaengerfehler, sondern ein ziemliches
Problem. Denn richtet man das anders ein, braucht man entweder
viele IPs und viel HD-Platz, oder man nimmt in Kauf, dass bei
einem CGI-Script zwei Programme gestartet werden (CGI-Wrapper
(z. B. suExec)).Wodurch ist das Problem begründet?
Bei meinem lokalen Server läuft der Apache mit meiner User-ID, d.h. er kann alle meine Verzeichnisse lesen, aber nur bedingt Dateien von anderen Usern (soweit diese dies zulassen). IMHO kann ein Apache-Prozeß aber nur eine User-Kennung haben, d.h. man müßte für jeden User einen eigenen Prozeß starten, um das Problem zu lösen.
Soweit ich weiss, kann man den Apache auch so konfigurieren, dass er seinen Document-Root im Homeverzeichnis der User hat. Muss er dann als root laufen? Kann ein einzelner User mit diesem Trick (den ich vor etwa 2 Jahren auch bei einem Provider (leider) "erfogreich" ausführen konnte (woraufhin ich gewechselt habe)) dann alle Homeverzeichnisse lesen?
Fragen über Fragen :-)
use Tschoe qw(Matti);
--
$a=n(1001010);print chr($a+=$_)for(0,43,-2,1,-84,65,13,1,5,
-12,-3,13,-82,48,21,13,-6,-76,72,-7,2,8,-6,13,-104);sub n{
$b=0;$_=0;for($c=length$_[0];$c;--$c){$_+=_($b)if substr$_
[0],$c-1,1;$b++;}$_}sub _{($d)=@_;for($e=1;$d--;$e*=2){}$e}-
Sup!
Natürlich könnte man für jeden User einen eigenen Apache-Server laufen lassen (damit der sein Document Root im Verzeichnis des Users hat), aber dann... bräuchte, wie CK IMHO angedeutet hat, jeder User eine eigene IP, ausserdem würde das recht viel Ressourcen (vor allem RAM) kosten.
Gruesse,
Bio
-
Hallo Matti,
Wodurch ist das Problem begründet?
Durch die Rechtestruktur unter Unix :)
IMHO kann ein Apache-Prozeß aber nur eine User-Kennung
haben,Eben.
d.h. man müßte für jeden User einen eigenen Prozeß
starten, um das Problem zu lösen.Ja. Und deshalb braeuchte man fuer jeden User eine eigene IP.
Soweit ich weiss, kann man den Apache auch so
konfigurieren, dass er seinen Document-Root im
Homeverzeichnis der User hat.Was hat das mit den Rechten zu tun? :)
Muss er dann als root laufen?
Nein. Aber der Apache-User muss Zugriff haben.
Kann ein einzelner User mit diesem Trick (den ich vor etwa
2 Jahren auch bei einem Provider (leider) "erfogreich"
ausführen konnte (woraufhin ich gewechselt habe)) dann
alle Homeverzeichnisse lesen?Ja.
Wenn man es generell loesen will muesste man halt vor jedem
Request ein seteuid() bzw. ein setegid() machen und nach
Verarbeitung des Requests die alten User-Rechte wieder
zurueckholen. Aber seteuid() und setegid() kann nur der root.Gruesse,
CK
-
-
-
-
-