Hello,

I have read all the threads about telnet and how unscure it really is like people browsing the server and other users directories.

But what I read most is that people can write (or actualy allready exist) scripts in perl or php or whatever to upload to there own directory so they can brwose the server with them.

I have NEVER seen such a script and I really would like to have them so I can test our server that way and see what is in them to help me secure the server.
Please send me any script like this you have to me or if you have some links about it PM them to me. Don't post them on the board! We all know why I guess.

Thank you!

I would recommend learning a bit about how file permissions work on Unix systems. Once you have an understanding, things like this will become obvious.

All it takes is a few lines of Perl to open/read files on the server. That's why scripts should be run under the domain owner's userid (ala suEXEC). PHP has built-in safe-guards (open_basedir and safe_mode) to help with this situation.

As long as scripts are run under the domain-owner's userid, the scripts will have the same abilities as the user -- thus they will only be able to read files they would normally be able to read via Telnet. Whatever security measures (file/directory permissions, etc) you have in place for Telnet/SSH access will apply to their scripts as well.

You might be interested in an article I wrote (http://www.jm4n.com/security.php) on the subject (I'm working on a few security articles, this one relates to running a server).

I won't give example scripts to exploit the problem, but the article above will give you tips to help prevent it.

<EDIT>
I just re-read your post... have you simply disabled shell access, in hopes that this will keep people from reading files? That's really the wrong approach to security...

If this is the case, I will stress again to learn about file permissions, as this is exactly what they are for. With proper permission settings, users will not be able to read other user's files...

The article I link to covers this, but you might want to find a primer first if you aren't familiar with Unix file permissions.
</EDIT>

Good articles. Need more detail tho ;-)

Fortunately we are doing everything you covered in your articles already :D

Originally posted by Jm4n
As long as scripts are run under the domain-owner's userid, the scripts will have the same abilities as the user -- thus they will only be able to read files they would normally be able to read via Telnet. Whatever security measures (file/directory permissions, etc) you have in place for Telnet/SSH access will apply to their scripts as well.

Correct me if I'm wrong, but php scripts running in php as an apache module will run as the apache user (usually nobody:nobody).

Thanks for the reaction.

We disabled telnet but people can use SSH. I really know that removing shell access is not the way to approach this. I know about the file permissions but the problem is that we have servers running Cpanel.
I see most solutions are for a standard linux box but not one that runs Cpanel. Cpanel just stops running after applying some file permissions. I am not new to this but I'm not a security expert either but I'm learning everyday. I hope some people here can help me with this because I really do take security seriously. I'm pretty much sure that we have taken care of the outside (tested by some well know white hat hackers)but now I want to do the inside and keep EXISTING customers out of the server and other users directories.

Cpanel is a pain in the ass regarding security I think.

Good articles. Need more detail tho ;-)
Thanks, I do appreciate it. I've really been getting into security, and I'll be writing more articles as I learn more myself.

Out of curiosity, what sort of detail is missing? My goal with the articles so far has been to simply offer some simple guidance, not so much a HowTo... because every system is different, everyone's needs are different. But the general guidelines can be applied anywhere.
Correct me if I'm wrong, but php scripts running in php as an apache module will run as the apache user (usually nobody:nobody).
First, never run apache as 'nobody' (I should add that to my articles). "nobody" really is somebody these days, when you run everything as nobody. Gain access to 'nobody', and you're really somebody, as you'll be able to access anything owned by 'nobody'.

The original intent of the "nobody" user is pretty much lost these days. I always create a separate unpriveledged user for each system service -- apache runs as "apache", Qmail runs as "qmail", and so on.

Second, PHP has safe_mode, and if you set the open_basedir directive to each user's home directory, you're all set. Users can't open a file outside their own directory, and safe_mode itself prevents opening any file now owned by the correct user. I did touch on this in the article.
...but the problem is that we have servers running Cpanel.
I don't want to sound like I'm knocking control panels, I'm sure they're great... but you cannot run a secure system using a web-based control panel (as is evident by your statement that it breaks when you try to secure the system).

I probably sound like a broken record by now, but seriously, control panels are for end user IMO. Administrators should never be afraid of the command line, editing text files, compiling things, etc. You should know your system inside-out. A control panel will not give you this.

I know a person who has had a Raq3 for about 3 years. He once had a problem with SPAM being bounced through his server, so I logged in (after explaining to him what "telnet" was), and did some investigation.

Turns out, he'd been rooted over a year ago. Someone had been using his box to run EggDrop, and kept a low profile. It wasn't until they decided to relay spam that any attention was brought to it. The Raq3 control panel did not tell him this was going on, of course.

The person gained root via (I think) an rpc.statd exploit that hadn't been patched, and they set up a nice little shop. The person had his own little home directory, a suid copy of bash, and some other nifty tools. He did not attempt to replace 'ps', 'top', 'netstat', etc, because he probably knew that, being a Raq, the owner would never know to look for these things. He even had a full .bash_history detailing every action he did.

Just to self-promote a little more, one thing my article mentions is that every piece of software should be evaluated for security concerns. You should force your software to work within your own security policy, and if it will not, find something else. Apparently CPanel fails this test (in my personal opinion).

I could go on for days about security (maybe I should write a book lol)... but the fact is, it takes a competant administrator, a good security policy, and experience.

BTW, Domenico, I sent you an email and will send you a Perl script as soon as I hear back from you.

Yes, Cpanel and Security are two different things. Too bad the developers don't have security in mind while developing it.
We can only hope that Nocsoft is more security friendly.

Don't worry about me not knowing how to work with a prompt though ;-)

I owned a RAQ in a far past and loved it at that time but that also didn't stop me from entering it through SSH to change things not using the dreadfull CP. i agree with you that CP's are for the end user but it is also handy for the sysadmin offcourse. What is important to know what is behind your mouseclicks (for the sysadmin) just as it is in windows. Really, I like to make websites using a text editor like notepad but while I know how to do it by typing it in I prefer creating 200 tables in dreamweaver with a few mouseclicks. Point; I use both just like a CP and a command prompt.

I'm learning every day and I know NO box is safe (some hacker showed me how too break through the default apache screen. The one you see after you have installed apache webserver successfully) but you can make it more difficult to succeed and that is what i'm trying to do.

These forums keep changing today. I liked the fixed-width font in the text boxes earlier; please bring this back (Mozilla on Linux makes whatever this font is very small).

You've learned lesson number 1: No box is completely secure. Good :)

I am glad to hear you say that about using the command line for some things (I didn't read this post before sending my last email to you). I know too many people who rely only on the control panel; personally I won't use them period, because as soon as you change your configuration, the panel would need to be updated to work with the new configuration.

What I've done on my servers (and I normally wouldn't share this much info...) was I created several Perl scripts to handle certain tasks.

For example, each account on the server has a special config file I came up with. It contains their username, domain name(s), subdomain(s), whether or not they have MySQL, and so on.

I then have a script library which modifies these files, and works with them. If I run 'makeconfigs', it rebuilds configuration files for Apache, Qmail, TinyDNS, etc.

This is what allows me to, for example, set an 'open_basedir' for each domain; the script does this for me. I can deactivate or reactivate a domain with one command ("deactivate username"), we can offer instant account activations, etc. Most importantly, if I make a global change in how things are done (like say I decide to add a "pop.domain.com" alias to every domain), I edit one script, run 'makeconfigs', and I'm done.

And of course I know exactly what's going on behind the scenes because I wrote the system, and it's very specific to my particular servers (eg, I use Qmail and TinyDNS; most control panels assume Sendmail and Bind)...

Anyway, the point is, I suppose there's nothing wrong with a control panel as long as you do know what it's doing. A web-based control panel isn't much different from my command-line based scripts, in a way (assuming you are using only SSL). The only reason I'm able to make configuration changes without breaking the system is because I wrote the system. I have a habit of writing things myself when I don't find a suitable alternative already available (I'm impatient, I trust noone, and I'm a fast programmer ;))

If anyone is interested, I'm planning a lot more articles on security, thanks in part to this discussion; it's really got me thinking on a lot of these issues, which I think is a good thing.

Originally posted by Jm4n
I have a habit of writing things myself when I don't find a suitable alternative already available

Not everyone has the time and money to do so - why don't you generalize your "control panel" and release it to public?

If anyone is interested, I'm planning a lot more articles on security, thanks in part to this discussion; it's really got me thinking on a lot of these issues, which I think is a good thing.

Yes, definitely sounds interesting. Keep on going!

Not everyone has the time and money to do so - why don't you generalize your "control panel" and release it to public?
I have been considering doing just that. It would be basically a command-line based control panel.

I'm pretty good with text-based interfaces (menu driven, like Midnight-Commander or the Linux kernel's 'menuconfig'), and was thinking about making something like that. Completely menu-driven, and usable from any Telnet/SSH client, and of course open-source.

Potentially I could make it web-based, offering security features that other vendors don't seem to offer, and making it configurable to work with many different systems (and offer installation/configuration support).

However, I may not have time for that in the near future:
I could go on for days about security (maybe I should write a book lol)...
As they say, be careful what you wish.

Have you ever said something jokingly and for some reason, you can't get the idea out of your head? Well... without giving too many details, I'm currently talking with two different publishers... ;) It's too early to get all excited, but I would absolutely love the opportunity if things go well...

I presume you will send us all autographed copies when it's done ?

:D

There's no reason in the world why a control panel can't be adaptable -- or rather, to make it not require any changes when you make a change to the configuration, setup, etc. The problem is that instead of control panel's simply providing a graphical dummy interface, they are taking over the servers functions. I.e., the email or shopping carts or other things won't work if the control panel is disabled. Or, you can't implement the SuEXEC CGI wrapper, because how the control panel works. The "control panel" shouldn't be getting in the way of securing a server or configuring it properly -- but poor design and inexperienced developers come into play and hence the problem.

In reality, it does not need to interfere so much and although many control panel's do seem to get in the way or cause these problems outlined above, they certainly don't need to and user's seem to rely on them, most definitely. The days of only experienced, qualified client hosting, have been long, long, long gone -- so control panel's are needed to stay in business, unfortunately. People don't have the time or desire to learn anything and just want to click buttons and have the control panel's interface do all the work. That's fine, but not if the control panel poses problems as described in this thread. Therefore, it greatly can depend on what control panel you're using, but I'd personally not use a control panel if that was the case -- but it's not always my choice either.

This article was well worded, I usually get too detailed and confuse people with elaboration's, explanations and examples. However, you neglected, as far as I could tell anyway, to guide people as to what permissions settings they should have. I.e., set them to 750, 710, or whatever need be, for the user's account directory. You neglected to mention that it's only to be set on their main directory and not have the apache user be the group user on all their directories and files. Also, the lack of an explanation of why and how this works -- not as a teaching tool, but so they understand why and how it's being done to prevent user's from viewing other user's files and directories.

Finally with the permissions issue, the mention of the sticky bit should, in my opinion, have been either left out or elaborated on a little more for the user's benefit that's reading it. I know it's difficult to explain things simply and concisely to not confuse the readers, yet still guide them, instruct them and explain how and why, because most people that need to read that sort of thing, are not going to know or understand it from the same stand point that you or I would. I'm sure you agree on that, and although I don't always know the best way to outline or word things, I can often see where it's lacking from a user's point of view, and I noticed that you didn't mention anything but permissions and not what to set them at or any suggestions. I think you should perhaps at least give some examples.

Also, as I'm sure you're aware, safe_mode and open_basedir are not at all fool proof and can be bypassed to still accomplish the task of getting information and file content -- not to mention that they now can't use commands that point to certain programs/tools that they might be currently using in their PHP script (PHP script is one example of many type's), not without some modifications/changes anyway -- which can also pose a problem anyway still. In addition, you should probably cover SSI in regard to web server security and other such things to prevent web surfer's from having permission or the ability to do certain things -- as well as the other user's on the shared server (of course). Further, you should probably outline a little bit about SuEXEC, so people set it up with the correct paths, or people could still bypass it and run scripts from their accounts and have them default to the web server's global user and bypass the CGI wrapper to view file contents, etc.

Last, I'd also suggest you check into and guide people (and suggest) they chroot their web server, so that it prevents a lot of other problems that can be done -- which is relevant to the subject at hand too. Nonetheless, it's a good start, well formatted, but I think that people that seek out information/help from your site, will likely not be able to point out the problems or parts missing from your guide, since they don't know what they need -- they just follow it and test things and see it's still an issue, because of lack of examples like permissions and whatnot. Don't take my post the wrong way though. :-)

On a final note, Apache 2.x will solve all these particular problems at once (being Apache modules and the user they run under, as well as CGI in general), since all the stuff ran on someone's Vhost, will run as that user's UID/GID, just like SuEXEC does with CGI -- but it'll do this for their httpd, CGI, PHP, mod_whatever_you_can_think_of and run it under their user and group. So, all this will be solved immediately, you can have their home directory with the user's own user and group, set the permissions to 700 and no more worries, no more implementing wrappers or worrying about safe_mode, etc., since that will all be solved right there and then. Of course, good configurations and the like, are still and always needed, as well as knowledge about permissions and ownership, but this will be very much better once it's finally out of BETA -- that might be a while though. :-)

Thanks for the suggestions, Tim. Originally, the article as it stands was a first draft, and I had planned on expanding on quite a few issues.

However, now this book idea is still stuck in my head. I have a habit of getting extremely elaborate once I get started on a subject, and if I let myself go on that article I would end up with a book by the time it's over with.

I haven't signed anything yet, but I have gone ahead and started on the book. If I can get it published, that will be great; but if not, it may just end up being posted online. In either case I'll probably expand on the articles some more when I get a chance.

You do bring up some good points that I hadn't considered. I didn't know Apache 2.0 was going to handle this, and I will definately be doing some heavy testing with it. I'll cover some of it in the book, which may be a good selling point as well ;)

I did neglect SSI in the article, something which should have been mentioned. I also failed to mention chroot(), though I had planned this for the book.

On the subject of control panels, the problem I have is that the popular ones will not work properly once you do lock down your system for security. However, I can't say this with any authority, as I haven't used any of them personally. Since I'll be (very briefly) covering them in the book, I will probably install and test a few of the common ones. If I find one (or more) which doesn't break security settings, perhaps I'll recommend it.

And I do agree, there's nothing wrong with a control panel. On my own server, I've been working on some web-based scripts for my own purposes (and for that of my business partner, who knows nothing about Linux). These are all very specific to my configuration, but they fit in with my security settings with no problems.

Touching on PHP safe_mode, it does disable the exec() family of functions, but from what I've seen, most pre-canned PHP scripts function just fine without them. VBulletin works (you have to comment one line where it tries to obtain the load average), and PHP Nuke works flawlessly.

I'm even running "popper", a PHP webmail client, in safe_mode (in fact our own site is 100% PHP, and is in safe_mode). I haven't run into any issues with safe_mode as long as you code with this in mind, which I believe most PHP script authors do.

---

What I think I will do with regard to the articles is to first work on the book, and when I get time I'll rewrite the one article to be more of a summary of the book. Since I plan to do a lot of research (making sure every fact is accurate), and lots of testing, I can get a lot more detailed. I have many Linux boxes, a FreeBSD, and a Solaris box at my disposal for testing (I don't want to focus on any one OS), so I'll be busy verifying and testing everything.

The article, as it is in it's current form, was meant mostly as a primer, not really an all-around solution. It was mostly to reiterate points I've made all over this forum, but in one location. The book will be that all-in-one solution, attempting to cover every security issue relating to web hosting.

About the sticky bit, I pondered that back and forth when I wrote that part. I didn't want to get too detailed, because it wasn't really relevant to the particular discussion, but I also didn't want to leave anything out either, so I simply tossed it out there. Re-reading it, and thinking as a reader, I can see where that little bit of teaser-information can be confusing.

What I'll probably do is remove that sentance and instead just mention that there are other permissions which aren't relevant to the discussion. The book will go into the sticky bit in more detail though, since it can have an impact on security.

I think I'll work on the spelling/grammar as well; I didn't pay much attention in that area in the article, but obviously a book needs to be a lot more perfect...

In any event, I have a full outline for the book, and I believe everything mentioned here is going to be covered (with the addition of Apache 2.0 just now). If anyone has any other ideas, I'd love to hear them. As it stands I'm estimating about 250 pages, but the more security topics (relating to Unix web servers and associated services), the better.

Jman, thanks for understanding the quick points i made. I visited your site, and I like what I saw. I like the idea and the basis of the business/hosting site you run. Although you didn't go into detail and didn't cover a lot (as you didn't intend to, obviously), it would be the type of host I'd have interest in looking into to host with... You have a good choice of the software you're running, with TinyDNS, Qmail, etc. Although I did notice that A: Your control panel didn't have SSL. B: Your web mail didn't use SSL. and C: Your _order/signup form_ didn't use SSL! So, of course I had to give you a hard time about it.

Anyway, that sounds fun (the book authoring). I too get way too carried away if I try and make it useful to the people new to the world of programming, security, administration or whatever else. It's not easy to do in a format that is short and to the point and still let them know how and why, rather than just a "do this" -- since the "do this" will rarely work with everyone. I could suggest a million things from initial partition schemes and mount options, to well, what we've been discussing in this thread, to add to a book -- but I'll spare you all that. I mean, then there's things like chroot that I mentioned earlier, it's not like it can't be circumvented, but it's a step.. one of many. I'd like to see an honest book about stuff like this. Not so I can learn from it -- that would be nice, but I'm not holding my breath -- but so people can learn properly and understand what people mean by there's no one solid thing to do or ay to do it, to secure a web server.

The control panel issue, I agree with. Currently, I'd not suggest any. When our control panel is released shortly, I'll likely suggest that, but it's going to be put through a rigorous test phase when it's ready, of course. This is specifically being built intelligently, and will not pose any problems. I completely agree and have experienced first hand, how you can't secure a server properly with a lot (or all) of the control panel's out there, especially Cpanel.. yuck! It's all about how it's built, but I've seen what you're talking about and I despise it. I couldn't agree more. Anyway, good luck on the book, I hope if it works out for you, that it's published by O'Reilly, Addison-Wesley or Printice Hall (but, please don't sell yourself short and make a "Secure your server in 12 hours" or some other "Sams" book!). :-)

Regarding SSL on our own web site, I haven't yet applied for a certificate. Once we get that in place, our order form and webmail will likely both be SSL. The order form doesn't ask for any payment information (that's done on a secure server), but I agree it should be SSL once we get that in place.

Our Control Panel is not, and probably will not be, since it runs on the user's domain (which would require a certificate on each domain). Though I could move that off to another domain, it makes it a bit more difficult (it must run under the domain owner's user ID, plus multiple servers would become an issue).

I've been sending my proposal to several publishers, including O'Reilly (of course) and quite a few others. I think I'll sit tight for the weekend and just work on the book itself now, and hope to hear from one or more of them next week. It seems like the more I talk about this idea, the more I want to do it, but I need to have patience :)