Results 26 to 50 of 92
Thread: is ssh access on the way out?
-
05-27-2004, 10:22 AM #26Web Hosting Master
- Join Date
- Jan 2002
- Location
- Kuwait
- Posts
- 679
Restricting SSH usage provides nothing but incovenience to senior users and a false feeling of security to junior ones.
What are you afraid of? You make clients files readable by all at the system level, then you try to block others from reading them at the application level. This is bad practice.
You block SSH to prevent me from doing: "cat /home/someuser/www/vb/includes/config.php", but I can always write this python script:
Code:# /usr/bin/python print "Content-type: text/plain" print print open('/home/someuser/www/vb/includes/config.php').readall()
This whole thing is becoming like a cat and mouse game between hosting companies and customers with little information about security.
System administrators and security experts know very well that there is no security benifit from this practice, but they will block SSH as a PR thing.
The UNIX operating system was designed to be a true multi-user system, but it is being mis-used by software companies to get certain performance gains. That's why some would percieve that anyone who needs SSH should actually get a dedicated server, as a personal machine, because they do not see a UNIX as a multi-user system.
Someone might claim that shared hosting clients are paying too little to get all the multi-user security features of UNIX, and I agree on that. But clients should be told the truth about that. It should be explained to them that, for the money they are paying, their data is being served by a shared httpd process, which means that their files can be read by anyone on the machine.
If they want to pay what it costs, they can always get their own httpd process serving their files. This way their files can be properly protected.
But to prevent legitimate SSH usage and claim that this is enought to protect clients files is not being honest.
-
05-27-2004, 10:34 AM #27Newbie
- Join Date
- May 2004
- Location
- Sweden
- Posts
- 21
Originally posted by Rich2k
Fine, just don't go trying to do that if you work on medium to large coporate websites. I still have never used the shell to edit website files, only to run server side scripts or standard server maintainence.
And, furthermore, as the previous commenter suggested. Not providing shell access, while providing PHP access, or access to any other programming language, is a very false sense of security.
Thus, not providing shell access doesn't stop anyone from being malicious if they really want to be, and it doesn't change the fact that shell access is something many customers want from a provider. And it doesn't change the fact that customers don't have to settle for less than they want.
-
05-27-2004, 10:36 AM #28Junior Guru Wannabe
- Join Date
- May 2004
- Location
- India
- Posts
- 91
You are right Ahmad
Ahmad is perfectly right, even a PHP shell like besys.cgi and other can be used if someone really want to do some bad stuffs . So, not giving Shell access for incresing the security is a fake practice really. Only brings some fake confidence. Personally me, I really like to have shell access to edit my file online. Because i don;t have net in my home, and use Internet from cafe. So, I can't always take the backup in some media when coming again in the cafe. I asked shell acccess from my last Webhoster, and they told they can;t give it for Seucurity Reasons .... Is it the way to prevent ? EXIM exploit is on the fly, still not public, buit some hacker already got it, if they try to get access for cPanel servers and DirecAdmin servers who uses EXIM in a mass, what the Webhost Security Managers will do ? Even they haven't gave anyone shell access to Security Reason ... Heh ..
Helpdesk : Sir, you need to add 10GB space to your HD , Customer : Could you please tell where I can download that?
-
05-27-2004, 10:39 AM #29Web Hosting Master
- Join Date
- Apr 2001
- Location
- Pittsburgh, PA
- Posts
- 1,306
Re: You are right Ahmad
Originally posted by bidhata
So, not giving Shell access for incresing the security is a fake practice really. Only brings some fake confidence.
Kevin
-
05-27-2004, 10:58 AM #30Web Hosting Master
- Join Date
- Jan 2002
- Location
- Kuwait
- Posts
- 679
Re: Re: You are right Ahmad
Originally posted by sigma
I'm not one to complain - people can run their hosting service any way they want to
I've seen in many cases before clients anxious about whether SSH was enabled on the server or not, and hosting companies would assure them that it is not. A sigh of relief from the client would then come, followed by ordering hosting from the company.
I see this as un-ethical. The client should have been told the truth, that even after restricting SSH, the flaw still exists.
-
05-27-2004, 01:46 PM #31Junior Guru Wannabe
- Join Date
- Apr 2003
- Posts
- 71
Security is done in layers -
Disabling or restricting shell access is one layer. Preventing server-side scripts from executing dangerous system commands or reading other system files is another.
Disabling shell access does serve a purpose. It blocks access to thousands of commands available on your server which can aid a potential hacker. Commands which can do much more than read a file. Disabling shell access is not 'sticking one's head in the sand' so far as the host goes to lengths to prevent other avenues of shell access, such as server side script commands which can do the same thing.
-
05-27-2004, 02:24 PM #32Newbie
- Join Date
- May 2004
- Location
- Sweden
- Posts
- 21
Originally posted by ericfire
Disabling shell access does serve a purpose. It blocks access to thousands of commands available on your server which can aid a potential hacker.
-
05-27-2004, 02:32 PM #33Web Hosting Master
- Join Date
- Dec 2002
- Posts
- 1,304
There are many ways to block certain attacks but not one way to block them all combined.
That being said, you might as well give out your root password because someone can probably hack it anyway right?
That is backward thinking.
Undeniably there are risks in granting users SSH access. Undeniably there can be risks in php/perl/python scripts.
To stop the SSH risk, dont grant it. To stop php risk, use openbasedir / safemode, mod_security etc. Security is applied in layers.
Each host has to decide where there comfort level lies, and execute their business along those lines.
If you dont like it, go elsewhere. Obviously SSH is NOT universally demanded, and until it is some hosts will not offer it. Why cry about it?"The only difference between a poor person and a rich person is what they do in their spare time."
"If youth is wasted on the young, then retirement is wasted on the old"
-
05-27-2004, 02:34 PM #34Junior Guru Wannabe
- Join Date
- Apr 2003
- Posts
- 71
If you read my post, you'll find that I've already stated that.
Restricting or securing shell access is one step. Securing, restricting improper file system access, disabling functions or even completely disabling perl, php and other server-side scripting is another.
However, if you go by the methodology and allow yourself to enable everything on your server just because you reason that 'it can be done another way', then you are only opening yourself to more avenues of attack. Security is done in layers.
-
05-27-2004, 02:35 PM #35Web Hosting Master
- Join Date
- May 2002
- Location
- UK
- Posts
- 2,997
Originally posted by tjogin
Again, it doesn't matter what the best practices are. It is completely and utterly irrelevant. What matters is that there are people out there who wants shell access from their hosting provider, regardless of what you think they should or should not be doing. Telling them that "you don't need it", or "you are doing it all wrong" isn't going to change their minds, they _know_ what a shell is and they _know_ that they want it. They don't have to settle for less.
And, furthermore, as the previous commenter suggested. Not providing shell access, while providing PHP access, or access to any other programming language, is a very false sense of security.
Thus, not providing shell access doesn't stop anyone from being malicious if they really want to be, and it doesn't change the fact that shell access is something many customers want from a provider. And it doesn't change the fact that customers don't have to settle for less than they want.
The point isn't to work on a copy on the same server, the point is to test scripts which could possibly cause damage to live systems, uptimes and data. That's why you have staging servers.
-
05-27-2004, 02:36 PM #36Newbie
- Join Date
- May 2004
- Location
- Sweden
- Posts
- 21
Originally posted by ericfire
Securing, restricting improper file system access, disabling functions or even completely disabling perl, php and other server-side scripting is another.
Originally posted by Rich2k
[B]As I say fine, just don't expect to try to work on many professional corporate websites with that type of practice... it simply isn't done (if that's what you want to do).
-
05-27-2004, 02:40 PM #37Junior Guru Wannabe
- Join Date
- Apr 2003
- Posts
- 71
Most popular hosts today do have openbase_dir, safe mode, php functions disabled, mod_security, disabled or chrooted cgi, phpsuexec, chrooted users, any combination thereof and more security measures in place. And if you are a sole user of a dedicated server that does not need php or cgi, then disabling it altogether is a good idea.
-
05-27-2004, 04:14 PM #38Web Hosting Master
- Join Date
- Apr 2001
- Location
- Pittsburgh, PA
- Posts
- 1,306
Originally posted by innova
That being said, you might as well give out your root password because someone can probably hack it anyway right?
Various tricks to prevent people from executing anything on the server will do wonders to frustrate Joe Kiddie Hacker. But nothing will be achieved versus Sally Serious Intruder; if anything, the host might be worse off if they have assumed they didn't have to worry about anyone executing anything.
How many setuid-root binaries are installed on a typical hosting server? How many daemons or services are running that aren't needed? How little auditing of processes, filespace, network listeners, etc, is being performed?
Kevin
-
05-27-2004, 06:46 PM #39Web Hosting Master
- Join Date
- May 2002
- Location
- UK
- Posts
- 2,997
Originally posted by tjogin
Yeah, hosts that do that are really popular now.
I've never said I tend to use bad practices on corporate websites, have I? And even if I did, is that not completely, utterly and totally irrelevant?
-
05-27-2004, 09:07 PM #40Web Hosting Master
- Join Date
- Feb 2004
- Posts
- 1,269
Originally posted by innova
Undeniably there are risks in granting users SSH access. Undeniably there can be risks in php/perl/python scripts.
To stop the SSH risk, dont grant it. To stop php risk, use openbasedir / safemode, mod_security etc. Security is applied in layers.
(...)
and how to stop perl/python?
check bugtraq for example and you'll see that at least 90% of exploits are made in Perl or C (chmod 000 your gcc and let your users upload the already staticaly compiled program)
-
05-27-2004, 10:50 PM #41Junior Guru
- Join Date
- Nov 2002
- Posts
- 202
just go for a cheap vps account and have full root if u want ssh with no1 saying nothing. just abide by the vps host's aup and u'll be fine
-
05-27-2004, 11:32 PM #42Web Hosting Master
- Join Date
- Dec 2002
- Posts
- 1,304
Sigma,
I wasnt REALLY implying you give out root THat was the extreme example of "well, you cant do anything about hackers anyway, so..."
and how to stop perl/python?
Use proper permissions and strong passwords.
check bugtraq for example and you'll see that at least 90% of exploits are made in Perl or C (chmod 000 your gcc and let your users upload the already staticaly compiled program)
But, shut down SSH and it all goes away"The only difference between a poor person and a rich person is what they do in their spare time."
"If youth is wasted on the young, then retirement is wasted on the old"
-
05-27-2004, 11:36 PM #43Web Hosting Master
- Join Date
- Feb 2004
- Posts
- 1,269
Originally posted by innova
Sigma,
I wasnt REALLY implying you give out root THat was the extreme example of "well, you cant do anything about hackers anyway, so..."
Dont grant shell access.
Use proper permissions and strong passwords.
What is this code (hack) doing? Probably something that is a local root exploit, which you should be patched against anyway.
But, shut down SSH and it all goes away
how would you avoid some user from uploading a script called "hack.pl" (made in perl), setting permission 775 to it and execute it?
this script can contain:
Code:#!/usr/bin/perl print "Content-type: text/html\n\n"; system("whoami");
change "whoami" for whatever you want and hey... you have a "shell" made in perl...
-
05-27-2004, 11:38 PM #44Problem Solver
- Join Date
- Mar 2003
- Location
- California USA
- Posts
- 13,681
Originally posted by innova
Sigma,
I wasnt REALLY implying you give out root THat was the extreme example of "well, you cant do anything about hackers anyway, so..."
Dont grant shell access.
Use proper permissions and strong passwords.
What is this code (hack) doing? Probably something that is a local root exploit, which you should be patched against anyway.
But, shut down SSH and it all goes away
Big negative, like said earlier you can everything done with ssh with php or perlSteven Ciaburri | Industry's Best Server Management - Rack911.com
Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance
-
05-27-2004, 11:41 PM #45Web Hosting Master
- Join Date
- Dec 2002
- Posts
- 1,304
I challenge you to find a system command that can be executed that will compromise the system.
It can certainly be annoying if someone does a fork bomb script, but then you simply terminate their account.
GRsecurity can help a lot with some of these things."The only difference between a poor person and a rich person is what they do in their spare time."
"If youth is wasted on the young, then retirement is wasted on the old"
-
05-27-2004, 11:57 PM #46Web Hosting Master
- Join Date
- Feb 2004
- Posts
- 1,269
Originally posted by innova
I challenge you to find a system command that can be executed that will compromise the system.
It can certainly be annoying if someone does a fork bomb script, but then you simply terminate their account.
GRsecurity can help a lot with some of these things.
then you can enable shell...
the point here is "I can do with perl anything that I could do if I had shell"
so if someone can hack your system having shell
if you disable it
this person would still be able to hack your system using perl (just an example... he could use C or python too)
got it?
-
05-28-2004, 12:14 AM #47Problem Solver
- Join Date
- Mar 2003
- Location
- California USA
- Posts
- 13,681
Originally posted by innova
I challenge you to find a system command that can be executed that will compromise the system.
It can certainly be annoying if someone does a fork bomb script, but then you simply terminate their account.
GRsecurity can help a lot with some of these things.
I challenge you to find a system command that can be executed that will compromise the system.
root@w00t # compromisesystem
bash - command not found
heheSteven Ciaburri | Industry's Best Server Management - Rack911.com
Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance
-
05-28-2004, 12:28 AM #48Junior Guru Wannabe
- Join Date
- Apr 2003
- Posts
- 71
In case anybody's interested, you can chroot your cgi-bin using sbox. Meaning cgi scripts are not allowed to access files/directories outside the changed home directory. Sbox also restricts cpu access to cgi scripts. Chroots are not failproof, (they can be broken) but then again, nothing is failproof. It just adds another layer of protection. Of course, once somebody gets past all of the layers you have, you want to make sure that your file permissions are correct. Anyways, here's the link:
http://stein.cshl.org/software/sbox/
-
05-28-2004, 12:30 AM #49Web Hosting Master
- Join Date
- Feb 2004
- Posts
- 1,269
Originally posted by ericfire
In case anybody's interested, you can chroot your cgi-bin using sbox. Meaning cgi scripts are not allowed to access files/directories outside the changed home directory. Sbox also restricts cpu access to cgi scripts. Chroots are not failproof, (they can be broken) but then again, nothing is failproof. It just adds another layer of protection. Of course, once somebody gets past all of the layers you have, you want to make sure that your file permissions are correct. Anyways, here's the link:
http://stein.cshl.org/software/sbox/
do you know if it will chroot everything runned as CGI (like PHP with phpsuexec), and if it works well with cpanel?
thanks
-
05-28-2004, 12:38 AM #50Junior Guru Wannabe
- Join Date
- Apr 2003
- Posts
- 71
I have used this on cpanel without problems for several months. I have not tried it for use with php scripts on php running as suexec yet, however.