Greetings,

I work for an ISP as a Systems Administrator. We don't as a rule
allow clients to telnet nor ssh into our Cobalt RaQ Servers. The security is not the main concern as we are well protected. The main issue is with clients who don't know linux that well and the recovery of sites that we have to do if they mess up.

Do you think as an ISP we should allow clients to ssh in as a rule of thumb?

SithLord

um, yes but be very careful..

we do not allow it by default but if we have spoken to the customer a few times and they seem to know what there doing we do allow it.. I would suggest just not allowing it as default..

I manage all my clients websites through ftp, theres no need for SSH for most people.

I was going to allow ssh but decided there was really no need for it especially with great utilities like PHPMyAdmin and so on. On a case by case basis if they request it I will approve it but otherwise not.

I wouldn't go with any host that didn't allow me SSH, although I might actually prefer a host that allowed SSH but didn't give it out by default.

How do people use SSH? I have used telnet before but never tried SSH

Originally posted by archie2
How do people use SSH? I have used telnet before but never tried SSH

To use SSH from a windows box, there's a nice little utility called Putty. SSH is far more secure than telnet, as with telnet your username/password are transmitted in plain text.

The main issue is with clients who don't know linux that well and the recovery of sites that we have to do if they mess up.

Do you think as an ISP we should allow clients to ssh in as a rule of thumb? As a client I would require SSH to be available from my host and this is why we do offer and recommend offering it. As long as you are staying on top of security issues it's nice to allow your clients to do the same. With that said, I also do not see anything wrong with being sure to add the note of "You break it you buy it". If the client messes up their account then it wouldn't be too much to ask for them to pay a fee for you having to fix it...especially if the problem is repetitive... That's a simple accountability issue. It's nice to be nice, but for those who just can't resist pushing buttons blindly the fee helps...

i just like have a remote server i can always login into from anywhere in the world, store some files if i need to :stickout , pick them up from somewhere else. like everyone else said before, you shouldnt say anything about it unless they ask you. also remember to look out for weird processes and connections..;)

Allowing SSH ot Telnet can be (may be) as dangerous some times as telling ppl "Come Hack My Server" lol

Originally posted by Deb
a simple accountability issue. It's nice to be nice, but for those who just can't resist pushing buttons blindly the fee helps... Good point, but... people who blindly push buttons they don't understand will have no trouble screwing their accounts up with ftp, or any kind of control panel file manager, or whatever tool you do put in front of them.

How many hosts haven't had clients delete their own "htdocs" or "www" directory?

Disallowing Telnet/SSH doesn't really eliminate the problem, just as it doesn't mean you no longer have to worry about security!

If you are woried about people messing up their site and wasting your time restoring backups, then charge for restoring the sites.

I would be very careful allowing even ssh access to your servers. Even though you authenticate the users, get their drivers license etc. It can still be hacked.

What if the user use a really stupid password? Thats so easy to crack?

It would be wise if you did decide on allowing ssh, to add their ip range to the server and deny everyone elses. It would make it way more secure.

How insecure is SSH that so many of you are so hesitant to allow users to use it? Of course the bit about people screwing their sites over.. But how insecure is it when it comes to hax0rs?

If they get in, you are sqrewed! Thats how insecure it is.

It's standard policy on our server not to allow telnet or SSH. then again we are slightly paranoid and run L0pht Crack against all the passwords and a few other things.

Security of the system is upmost. the closer to root the higher the probability of root.

Let us not forget the clasic example of what happened to MChost and the gentleman from england. ( which by the way both parties were innocent of commiting any wrong doing ). Where as someone using MChost server was able to enter the other host server in england and run a scritp that would reduce the effectiveness of the server.

Sorry I can not recall the other host name but is considered a very good host. company starts with an "S"

Mike

Dunno if you're trying to avoid opening bad wounds (if you are, I'm sorry) but I believe that was Splashhost you are referring to, no?

what happened with splashhost and mchost?
another catfight? :)

Originally posted by lightnin
Dunno if you're trying to avoid opening bad wounds (if you are, I'm sorry) but I believe that was Splashhost you are referring to, no?

yes I was trying to avoid the woundings, but I wanted the moral of the story, about weakness of a system, hurting the names of 2 parties.

mike

Really SSH isn't that insecure....

Users can only run things as their own user...

Now with CGI-Perl/Python/PHP, they can run things as another user and cause alot more havoc...

I wouldn't allow shell by default, but if requested yes...

I don't know how you guys look at it. Having SSH enabled is just as risky as having a simple knife in the home. It's a tool if used wisely but in the wrong hands it could be a weapon to kill.

Try eliminating knives from your home for a while and you will understand, likewise eliminating SSH an essential tool to your users will be too naive and reflects the Host's ignorance or competency to manage the server's reliability or security for its SSH users.

i wouldn't unless it was a request by a client for certain things.
There's alot of local root exploits out their and you really have to remain on top of things security wise by signing upto such lists as bugtraq, vuln-dev and checking out sites like securityfocus or even packetstorm to see if theres any 0sec exploit releases, But really if you keep on top of security then yes it would be OK.

I would say that although SSH access for your users should be relatively safe, it may not be on a cobalt RAQ.

Yes. We require some information on users before we grant them SSH access, and we have tweaked SSH a little to make it more secure, but we have no real qualms about giving users SSH access.

Originally posted by voxtreme-matt
Yes. We require some information on users before we grant them SSH access, and we have tweaked SSH a little to make it more secure, but we have no real qualms about giving users SSH access.

We do the same. SSH is available, just not by default.

Perl is more dangerous. Did you remove that too?

There is no need to be a Perl guru to:
- Translate all the available exploits and run them as CGI.
- Write a CGI script to be used as a minimal shell on your server (There are some available).
- Write a CGI to crash the apache server (sometimes by mistake).

I suppose that you secured your server enough to not allow any kind of exploit but how many of you had fun with a crazy CGI crashing your server?

You have the name and/or the credit card of the user and if he is mad enough to crash his own website/business than you have a way to make him pay. But if he sent his password in clear text with ftp (no Secure SHell) than there are great chances for a bad guy (no name, no credit card) to crash you server fast.

You can configure your server to limit the amount of resources a shell can use and running any fork bomb will have a small effect. What can you do with apache and its scripts?

Remove the dangerous Perl and after that think about how dangerous is PHP.

Don’t allow SSH for security reasons because your users have nothing better to do than to crash your server (or to check the load and uptime of your server ;) ). Let them send their password in clear text with “24/7 FTP” and “unlimited POP accounts” for a better hacker to do this job.

I don't think that it is a security issue at all! The users that we allow ssh access, have to specify what IP they are coming from each day they are wanting to login via ssh. So not only does a user have to have that IP address but also a username and password. I would say that an IP address would be pretty hard to spoof when working with ssh (as far as I know). If you know a way I would love to here it. :D I also don't know of a good way to run a password crack through ssh either, so maybe I'm just not a good hacker.:eek: :confused: Most clients are too intimidated by ssh anyways, for them just getting it to work is amazing. Guess it just depends on your client base and your target market. ie: Small businesses that don't even know how to check their e-mail don't really care if they have ssh access. I can't really think of any real good reasons that users need ssh as long as you have good tech support. I want to know what is being installed on my server and if it is a module that I would like all the other users to have or not. Most big modules should be installed by the root user anyways. Just a thought.

I agree with Nedani

I am some what of a security phreak. SSH is completely safe. I don’t care if a client SSH's in and screws up there entire site. Ill restore for free the 1'st time. But if they do it again, I am charging. As long as you keep your system up to date with the latest security patches for SSHD ECT you should be fine. I host my servers on mandrake and that makes it even easier. I schedule a crond job to do an “urpmi --auto-select” and security updates are installed automatically every day. Not to mention the Free IDS (intrusion detection system) by mandrake, AND the tool “MSEC” which checks your system every hour for world writeable files and other possible security holes, makes sure the permissions on everyone’s home directory is what it should be and then emails the to you the results. MSEC is installed on every mandrake system by default and is a very good tool.

Yes we do allow SSH access by default. You can tell SSHD to disconnect someone that has 5 bad logins in a row and lock them out, so password cracking isnt a good option for a hacker. As long as you know what you’re doing you should be ok, I think using mandrake as a server platform is a good option if you want security.

Mandrake is growing Six times faster then the web average see:
http://www.mandrakeforum.com/article.php?sid=2357&mode=thread&order=0&thold=0

Also the apache that comes with Mandrake is different from others. It is compeletey modular, if i need WebDAV support for apache i would simply install apache-webdav.rpm and wallla, no having to recompile apache with webdav built-in. Apache for mandrake does alot of other things and has alot of more features then the default apache that comes with RedHat. What's the main difference between the Advanced Extranet Server and other implementations of Apache?
http://www.advx.org/specs.php

I would say shell access is a must , for me at least . I would say offer it on request only , the people that dont know what it is , or cant find a use for it probably wont ask for it . More then likely (not every case though) the person asking for it has a clue of what they want to do with it

I have to agree with nedani. Although CGI access for your users should be relatively safe, it may not be on a cobalt RAQ. :)

If your going to give anyone shell access then you need to put thier shell in a chroot jail with a minimal safe toolset. Dont let shell users use network resources.

Hey Classics,

I've looked into chrooting shell users and it's not easy. In fact, the method I was thinking of using requires a LOT of work per customer. Can you detail the process you're using?

probe
probe@geekcorpse.com