[RaQ+telnet]: gebruiker kan andere bestanden bekijken

[Ctrl-Alt]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

Deimos: om .htaccess te gebruiken en om cronjobs in te stellen misschien :?

[Domenico]

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]

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]

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]

Hmmm sftp en apop -- ik ben benieuwd hoe snel klanten dat in de gaten hebben.