When it's OSS it's improperly configured. When it's Windows it's piss poor development and insecure by default.

Having multiple website on one installation of a web server where a bit of software can infect all sites sounds like more than just a bit of bad configuration.

Where's the secure-by-default, safe out of the box hype from the OSS crew? It's all crap, closed source, open source. All have holes, some call them poor configuration, others call it insecure by default.

Bottom line is that every application is secure. (IIS, Apache, Windows, RH, Office, OpenOffice). It's the admin that buggers it up - not if it's open or closed sourced software. If Windows admin's woke up, read up and then ACTED on best pratice and common sense then Windows would be able to hold it's head high. Nice to know that shit administrators exist outside of MS networks.

"Poor configuration of Apache servers allowed ..."

True up to a point, but the real culprit is PHP. Together with failure to take advantage of a number of protections.

"Check if your hosting company uses chroot and/or suExec because that is the only way to make sure that your own web site will not be compromised by other users sharing the same physical server."

That's not true at all. chroot is not relevant to this issue. suexec is one of a number of options that is relevant, but very few PHP hosts use it (a few more are prepared to use FastCGI, which serves a similar purpose). There are also quite a few assumptions underlying the claim.

And to Steven Hewittt - have you seen any of the press PHP has got from within "the OSS crew"? It's been known for years to be a security minefield. You'll find me on record comparing it to Microsoft, as both have put "attractive to dumb users" ahead of security. Google Stefan Esser for comment from the heart of "PHP security".

Do you actually know what you're talking about? Just in case this is ignorance and not actually trolling, let me explain.

On Linux servers, each user has an account, and the files on their accounts have permissions. The Web server uses the data from those accounts to serve up pages.

Typically, the server will automatically switch to the proper user account (using the techniques mentioned in the article, including suExec) and grab the proper files.

On a badly-configured server, these user directories will all have the same owner (be it 'root' or 'nobody'), and, as such, they'll be writable by that account. Since they're all running as the same account, an exploit that hits one of them can make modifications to others. And I'm reasonably sure that that's the problem here.

Note that this isn't a problem with Apache, just like it wouldn't be a problem if it was IIS; the problem is allowing different Web sites to modify each other. In other words, it's a configuration problem, not a software problem. If permissions are set properly, this won't happen.

Hope that explains the problem, and if that was indeed a troll, I hope you enjoyed my response. Maybe somebody else will even learn from it, who knows? :)

Hewittt, your post was OK until the last paragraph. You're quite right, PHP must have some crap code if someone was able to root it.

Every application is NOT secure. Obviously some Apache/PHP combination isn't secure 8-). If it was they would never have had this problem. Also, not commenting on recent versions, but old IIS versions for instance, were assuredly NOT secure. The administrator could in fact turn of insecure features within IIS, it'd tell the admin they were off, but would actually run about half way through those code paths for those features before checking if they are "off" or not.. plenty far to hit multiple buffer overflows in these supposedly shut off features.

Quite simply, best practice for securing a Windows machine is FAR more complicated than locking down most other systems. These guys couldn't even properly secure a Linux box, which is quite sad 8-).

I've found three sites selling it. All want credit cards, which means you have to steal a credit card number, first. It's circular logic.

PHP is not the most easily subverted

scripting language Perl is I know

because I installed it and it did

things PHP refused to do basically

there really is no security at shared

hosting no matter the server or scripting

languages if they don't break in they

bribe someone who works there.

Sorry, I mean: "Bottom line is that every application CAN BE MADE secure.". Not 100%, but to be honest most system downtime is human errror rather than actual bugs in the apps.

If admins (regardless of platform) took thing seriously and adopted best practice then these sort of issue would be reduced.

The point I was making with my comments was that admins, generally, are the weakest link, and this article makes a big point that it was misconfigured.

If you followed MS instructions for every deployment then the world would be a much happier place - just seems to be bad configuration when it's Apache and insecure by default for IIS, even if it's the same issue.

Bias reporting that's all.

Ron - it's was more of a bitch at bias reporting. I'm the network admin at a web dev company that hosts testing environments for some very large clients (banks etc.) Some are IIS, some are Apache (Apache is my personal preferance). I'm aware of the technical aspect, but just trying to get a point across that it could easily be taken as a Apache or PHP security issue (comparable to IIS/.Net) when it's not - bad administration.

That's always been my gripe with Windows. Not the software, just the admins.

:-)

You hit the nail on the head when OSS fucks up it's "poor configuration" and when WIndows fucks up it's just crap software. The thing is, as Apache fans keep reminding us, if they really are the most popular web server in the world then they probably are peddling most malware too, from "poorly configured" servers. Then again, we all know zealots/Evangelists are bigots and hypocrites, so no change there, then?

"basically there really is no security at shared hosting no matter the server or scripting languages if they don't break in they bribe someone who works there."

Good security is more likely to arise from employing skilled professionals who earn more from things going the way customers expect than by trying to do and know everything yourself because you are unable to bring yourself to trust anyone else. If you are prepared to evaluate and pay for the best then you have no reason to expect the worst.

If my needs grow to where I require dedicated as opposed to shared (currently virtual machine) hosting, my server security will still be just as dependent upon the skills and ethics of others and my ability to choose contractors, dedicated hosting and co-location businesses carefully.