I would agree that giving shell access, is not a very good idea.

We almost always build web interfaces for the customer, and then only in Java servlet code, specifically due to the fact that Java plays nicely in its own sand box with no possibility of any buffer overflow attack, no matter how hard the guy tries.

If they can't pay us to build a web interface, then we tell them they need to seek another provider for the service.

Both of you overlooked the fact that shell access can also be used to load and configure software as well, to launch attacks on internal to your systems or other systems on the net.

Then of course you are looking at specific firewall configurations per shell, per virtual interface that the customer/hacker connects too. Although impossible to do with the 2.2 kernels, 2.4 does offer that kind of support so it would be possible to do. (Stateful firewall inspection coupled to a shell login.) Then of course, your work is further cut out for you as you then have to hide ever binary from the shell that you don't want the user to have access too.

But like I said, that only works if you don't give the user the ability to FTP as they could then load, compile, link and run thier own programs. With a stateful firewall connected to the front door at least you can restrict the IP address where this specific login event can take place from on the internet.

If the customer doesn't use DHCP to connect to the shell account, and they don't connect from behind a NAT based firewall, this might be an acceptable solution. (However, if someone breaks into THAT machine, they could attempt a valid login to YOUR IP secured shell.)

You are already talking about far more work (I wouldn't want to do the above if I had 100 shell accounts for example) than I would care to even think about in managing a couple 100, let alone thousands of customers, who claim they need shell access.

Besides, there is almost never a good reason to give a third party direct access to a machine, build a web admin interface to the application, and if at all possible use Java servlets, don't use any sort of native executable code/service for programming other than the web server on your sites that is compiled or linked with the glibc libraries. (i.e. don't use any form of CGI, Server Side Includes etc.).

Obviously, the liability in supporting shell machines includes what sort of contigency plans you will have both legally and technically should one of the script kiddies get in and use it for a mass DOS attack on someone who has deep pockets, and decides to name you in a legal suit so they can collect damages.

-gc

Tim Pierce wrote:

In article 87593.990543718@ma-1.rootsweb.com, Charlie Summers charlie@lofcom.com writes:

...

At 9:51 AM -0400 5/22/01, Tim Pierce is rumored to have typed:

...

Among other reasons, because giving shell access to relative randoms a recipe for disaster. You might as well hand out the root password while you're at it.

It's hardly the same thing, and you certainly know it; you're throwing up a smoke screen.

It's almost exactly the same thing.

...

If you lease virtual domains, the user should have FTP and shell/SSH access - that's what they're paying you for.

We do virtual domains and give the users FTP access. We do mailing lists and let the users administer lists via the Web. We don't provide shell access for anyone under any circumstances. They don't pay us for that and we don't offer it.

...

To equate being a user on a machine to running root is asinine, unless of course the root user doesn't have the ability to set up his machine correctly.

A knowledgable cracker who can get shell access on a machine can typically get to root inside of about ten minutes. It is *extremely* difficult to secure a general-use box against every possible attack, especially with the rate at which new exploits get discovered. I know I am not capable of it, and I strongly doubt that you are either.

---

Smartlist mailing list Smartlist@lists.RWTH-Aachen.DE http://MailMan.RWTH-Aachen.DE/mailman/listinfo/smartlist

.