PDA

Bekijk Volledige Versie : [RaQ+telnet]: gebruiker kan andere bestanden bekijken



Ctrl-Alt
13/10/02, 23:41
Onder de webhosters is het algemeen bekend dat een klant op een Cobalt RaQ via SSH telnet ook bestanden van andere klanten kan inzien (maar niet wijzigen uiteraard).

Is er niet een oplossing om dit te voorkomen? Oplossingen zoals een 'jail' en dergelijke zijn wat mij betreft niet interessant. Daarom de vraag hoe jullie dit eventueel hebben opgelost. Telnet volledig uitschakelen is ook geen optie, vind ik althans. Alvast bedankt!

Deimos
14/10/02, 01:23
in de tijd dat ik nog gebruik maakte van een raq3 had ik de perl script geedit en een php shell script geschreven dat alle dir's dicht chmodden. (dit was de beste oplossing die ik kon vinden).

Ik zal eens kijken of ik beide scripts nog ergens heb maar kan helaas niets beloven aangezien de raq gelukkig weer bijna een jaar verleden tijd is.

uFx
14/10/02, 09:44
Zoiets is heel moeilijk te beveiligen; niet alleen op een Sun Cobalt RAQ, maar ook op een gemiddeld linux machine. Omdat je html bestanden op 'world-read' moeten staan, wordt het vrij gevaarlijk als je met chmod gaat werken..

Ik ken het scriptje van Deimos wel, en het schijnt gedeeltelijk te werken. Maar pas op voor eventuele complicaties... Deimos: als je het script nog gevonden krijgt, zou je het mij dan ook toe willen sturen? Ik heb het helaas ook niet meer..

De enige optie is Telnet/SSH niet aanbieden, maar een alternatief. Wat wil de klant via SSH doen? Er zijn tegenwoordig veel webbased applicaties die hetzelfde doen :)

superior-is
14/10/02, 11:07
Of maar een select aantal klanten SSH aanbieden. Zoals uFx al zegt -- wie heeft er nu eigenlijk nog SSH nodig. En telnet zou eigenlijk een banned woord moeten worden op webhostingtalk.nl ;).

RobbertC
14/10/02, 11:18
Ik denk dat het zomaar uitschakelen van SSH voor Ctrl-Alt geen optie is. Klanten hebben immers een contract, en het pakket dat ze voor een jaar gekocht hebben, zit SSH bij. SSH uitschakelen = contractbreuk = probleem.

Domenico
14/10/02, 11:25
Eigenlijk moet je helemaal geen SSH standaard in een van je paketten hebben. Als er toch een klant om vraagt moet je vragen waarom deze klant eigenlijk SSH toegang wil hebben. En als je dan toch besluit SSH toegang toe te kennen weet je in ieder geval wie er access heeft en de SSH toegang ook gebruikt.

Er zijn verschillende manieren om het een en ander wat veiliger te maken (chmod, chroot jail) maar het beste wat je kunt doen is gewoon alert blijven want al de beveiligingen zijn gemakkelijk te omzeilen door iemand die weet wat hij doet.

Deimos
14/10/02, 16:46
HEb mijn chmod script gevonden. Deze liet ik ieder nacht draaien. IS niet 100% veilig maar beste wat ik toendertijd kon vinden:



#!/usr/local/bin/php -q
<?php
$handle=opendir('.');
while (false!==($file = readdir($handle))) {
$begin = $file;
$in = substr("$begin", 0, 4);
if ($file != "." && $file != ".." && $in == "site"){

system("chown httpd /home/sites/$file/web");
system("chmod 771 /home/sites/$file/web");

}
}
closedir($handle);
?>


Voor het script dien je php als cgi executabel op je server te hebben. Bestand zelf stond in mijn geval in /home/ indien je eht ergens anders neerzet, pas dan de variabele $handle aan.

Pas wel op het script draait als root. Let erook op dat je apache wel als user httpd dient te draaien wanneer je het gebruik anders ben je zwaar de klos.

Moet ook nog ergens een code hebben die standaard wildcards aanmaakt in de httpd.conf en in de DNS records op een raq. Zal die ook eens zoeken.

Ctrl-Alt
14/10/02, 17:22
Bedankt voor de reacties. Hier m'n antwoord:


Origineel geplaatst door RobbertC
Ik denk dat het zomaar uitschakelen van SSH voor Ctrl-Alt geen optie is. Klanten hebben immers een contract, en het pakket dat ze voor een jaar gekocht hebben, zit SSH bij. SSH uitschakelen = contractbreuk = probleem.
Geheel SSH uitschakelen is inderdaad niet een goede oplossing aangezien sommigen het toch echt nodig hebben. Misschien zijn webbased scripts een oplossing daarvoor, maar ik vraag me af of die niet beperkt zijn wat mogelijkheden betreft.


Origineel geplaatst door Domenico
Eigenlijk moet je helemaal geen SSH standaard in een van je paketten hebben. Als er toch een klant om vraagt moet je vragen waarom deze klant eigenlijk SSH toegang wil hebben. En als je dan toch besluit SSH toegang toe te kennen weet je in ieder geval wie er access heeft en de SSH toegang ook gebruikt.
Op deze manier werken we al, het lijkt me inderdaad een goede oplossing. Maar het probleem dat andere bestanden zichtbaar zijn, is daarmee niet opgelost.


Origineel geplaatst door Deimos
HEb mijn chmod script gevonden. Deze liet ik ieder nacht draaien. IS niet 100% veilig maar beste wat ik toendertijd kon vinden:
Deimos, bedankt voor het script. Maar ik zal eerst kijken of de webbased scripts een oplossing zijn om vervolgens SSH volledig af te sluiten.

Deimos
14/10/02, 17:42
Ben niet nieuwsgierig hoor maar waarvoor hebben sommige klanten specifiek shell access nodig? Kan me namelijk eigenlijk niets indenken waarvoor die het nodig kunnen hebben :S

superior-is
14/10/02, 17:49
Ctrl-Alt kijk 'ns naar Fileman:
http://www.gossamer-threads.com/scripts/fileman/

Er is volgens mij zelfs een gratis versie te vinden wanneer je een Sun Cobalt hebt.

RobbertC
14/10/02, 18:07
Deimos: om .htaccess te gebruiken en om cronjobs in te stellen misschien :?

Domenico
14/10/02, 18:35
Origineel geplaatst door Ctrl-Alt
Deimos, bedankt voor het script. Maar ik zal eerst kijken of de webbased scripts een oplossing zijn om vervolgens SSH volledig af te sluiten.

Hmm, als het gaat om veiligheid moet ik je teleurstellen want geen van de webbased producten heeft de hacker testen doorstaan van een vriend van mij.

Mindterm (http://www.appgate.com/products/mindterm/index.html) bijvoorbeeld was binnen een kwartiertje gekraakt (root access!).

Deimos
14/10/02, 19:00
Origineel geplaatst door RobbertC
Deimos: om .htaccess te gebruiken en om cronjobs in te stellen misschien :?

.htaccess password files neem ik aan. Kan je ook doen zonder ssh access met 1 simpel phpscriptje :). Verder cronjobs waarom die standaard toestaan.

Ik laat deze toe mits goedgekeurd door mezelf. Je weet namelijk nooit wat voor load een cronjob gaat vergen. En ik heb een paar newby's met cronjobs gezien en het effect op de server was nou niet bepaald gezond.....

Hans
17/10/02, 21:35
Ik snap echt niet waarom iedereen zegt dat eventuele shell toegang alleen via SSH mag lopen en niet via telnet, terwijl 90% van de hosts hun control panel nog vrolijk via gewone http laat lopen, files nog steeds via ftp laat uploaden en mail nog steeds over gewone pop3 laat ophalen door klanten.
Als je telnet eruit mikt, zorg dan dat je je control panel over een SSL verbinding laat werken, je klanten via sftp laat uploaden en mail via pop3-over-SSL of imap-over-SSL laat ophalen :)

superior-is
17/10/02, 23:26
Hmmm sftp en apop -- ik ben benieuwd hoe snel klanten dat in de gaten hebben.

Ctrl-Alt
17/10/02, 23:49
Inderdaad, inloggen via SSH is redelijk eenvoudig terwijl voor sftp en apop toch wat meer kennis nodig is. Het lijkt me ook niet klantvriendelijk als je de klant verplicht om via sftp en apop te werken aangezien dat niet door alle gangbare programma's wordt ondersteund.

Deimos
18/10/02, 08:52
SSH wordt vooral gebruikt voor het beheer van eens erver aangezien het niet zo heel erg verstandig is om je root password in plain text over het internet te sturen. En aangezien elke (verstandige) sysadmin enkel zijn root wachtwoord gebruikt voor SSH maakt het voor pop3 en ftp niet zo denderend veel uit (IMO).

Hans
18/10/02, 17:34
Natuurlijk, ik begrijp de bezwaren best. Maar als je shell toegang wilt geven kan je dat net zo goed via telnet als via ssh doen, omdat die wachtwoorden toch plain tekst over de lijn gaan voor ftp en pop.

En Deimos, het ging niet zozeer over het gebruik van telnet als beheerder van een server, want dat moet je uiteraard niet doen. Het ging erom dat webhosts die klanten shell toegang willen geven dat niet via telnet maar alleen via ssh zouden moeten doen en dat is een beetje onzinnig als toch ftp en pop gebruikt worden.

Deimos
18/10/02, 18:35
Hans wat dat betreft ben ik het helemaal met je eens. De reden dat telnet ook niet wordt gebruikt is dan ook dat het in het verleden zeer vulnerable is gebleken. En van SSH kan men dat niet bepaald zeggen. Dat is ook 1 van de redenen :).

Maar om het ww te beschermen maakt het idd niets uit. Gaat meer om de beveiliging van de server zelf (er vanuit gaande dat de user bijna helemaal zit opgesloten op zijn server).

babak
21/10/02, 02:38
Cronjab? NOOIT :D
Shell? NOOIT :D


Waarom zou je in godsnaam Shell of zelfs cronjab aanbieden?
Tenzij je snel je faillissement wil aankondigen
;)

jake
27/03/03, 18:41
misschien is dit wat voor je als je toch ssh toegang wilt verlenen.
Keb het vroeger onder linux welleens geinstalleerd en het werkte goed.


http://www.gsyc.inf.uc3m.es/~assman/jail/configuring/quickguide.html

Domenico
27/03/03, 19:10
Ook daar is uit te breken maar inderdaad, het is een extra hindernis die moeilijk te nemen is voor de meesten.

tom
27/03/03, 19:37
ik bied crontab en ssh al meer als één jaar, nog nooit problemen gehad :)

je moet wel je bak kunnen beveiligen :p

babak
27/03/03, 19:39
en als een van je klanten lekker zware scripts per cron draait?;)

almar
27/03/03, 23:53
Dan stuur je ze een mailtje, waarin je verwijst naar de algemene voorwaarden met de vraag of ze daarmee willen stoppen. Of een dedicated willen nemen.


Niet zo heel moeilijk. Het lijkt wel of iedereen hier licht in de stress raakt van het woord SSH.

babak
28/03/03, 00:38
Origineel geplaatst door almar
Dan stuur je ze een mailtje, waarin je verwijst naar de algemene voorwaarden met de vraag of ze daarmee willen stoppen. Of een dedicated willen nemen.


ja, maar waarom moeilijk doen als het makkelijk kan. :rolleyes:



Origineel geplaatst door almar

Niet zo heel moeilijk. Het lijkt wel of iedereen hier licht in de stress raakt van het woord SSH.

Van ssh weet ik niet, maar van cronjob krijg ik wel behoefte aan aspirientjes:D

tom
28/03/03, 02:43
Gewoon heel streng in zijn, wie een cronjob draait met een herhaling van minder als 6u, ff 24u afsluiten :)

Deimos
28/03/03, 08:03
Origineel geplaatst door tom
Gewoon heel streng in zijn, wie een cronjob draait met een herhaling van minder als 6u, ff 24u afsluiten :) Is naar mijn idee niet echt een oplossing. Aangezien ik genoeg scripts ken die tijdens zo'n cronjob een CPU gebruik hebben van zo'n 70-90%. Lijkt me nou niet echt bepaald fijn voor de load en stabiliteit van de machine.....