Page 2 of 4 FirstFirst 1234 LastLast
Results 26 to 50 of 92
  1. #26
    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()
    What will you do this time to stop me? You tell me, and I'll tell you what I can do to get the contents of that file.

    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.
    Ahmad Alhashemi
    PHP, Apache, C, Python, Perl, SQL
    18 related BrainBench certificates

  2. #27
    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.
    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.

  3. #28
    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?

  4. #29
    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.
    I think it has been shown repeatedly when this topic comes up that many hosts desperately need that false sense of confidence. I'm not one to complain - people can run their hosting service any way they want to, and some people might even be aware of what they are restricting and the implications - but most just want to flip a knob or twiddle a dial and "bingo you're secure". It's really more like sticking one's head in the sand and thinking no one can see you.

    Kevin

  5. #30
    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 agree that they can do whatever they want. They can block SSH access if they want. But what I disagree with is being dishonest with customers when it comes to this issue. The virtual hosting business have grown dependant on a flawed security model and blocking SSH access is being used as a cover up.

    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.
    Ahmad Alhashemi
    PHP, Apache, C, Python, Perl, SQL
    18 related BrainBench certificates

  6. #31
    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.

  7. #32
    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.
    Yes, but that is completely useless if you offer some kind of programmatic interface, such as Perl, Python or PHP, which can execute shell commands anyways.

  8. #33
    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"

  9. #34
    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.

  10. #35
    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.
    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).

    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.

  11. #36
    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.
    Yeah, hosts that do that are really popular now.

    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).
    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?

  12. #37
    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.

  13. #38
    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?
    No, you set a security perimeter and you enforce it. Activities which fall on one side are fine and are all essentially the same. Activities which fall inside are disallowed. Obviously root access would be on the inside. Then you do everything possible to protect that perimeter.

    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

  14. #39
    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?
    I never said you did, I just said that if you wanted to ever work on one.

  15. #40
    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.

    (...)
    yes...
    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)

  16. #41
    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

  17. #42
    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?
    Dont grant shell access.

    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)
    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
    "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"

  18. #43
    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
    sorry, but it doesn't make any sense

    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");
    and this "whoami" would be executed exactly the same way if the user logged to SSH and typed "whoami"

    change "whoami" for whatever you want and hey... you have a "shell" made in perl...

  19. #44
    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 perl
    Steven 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

  20. #45
    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"

  21. #46
    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.
    dude
    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?

  22. #47
    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.
    Umm GRsecurity has a big list of features but that does not stop someone from defacing all the websites on the server using php or perl. You are silly if you are relying on grsecurity for your protection. GrSecurity will not protect you if you have one unpatched service.

    I challenge you to find a system command that can be executed that will compromise the system.
    there is no system compromise command.



    root@w00t # compromisesystem
    bash - command not found

    hehe
    Steven 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

  23. #48
    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/


  24. #49
    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/

    cool

    do you know if it will chroot everything runned as CGI (like PHP with phpsuexec), and if it works well with cpanel?

    thanks

  25. #50
    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.

Page 2 of 4 FirstFirst 1234 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •