Well for a start, the previous time it happened it was on the same server with exactly the same system setup, I merely removed my own home baked website, and swapped it for a DNN one.  Then within 5 months, everything was lost.  Bare in mind that my own site had been running nicely for well over a year without any such incident occurring.  These attacks look very automated as they are extremely regimental and apparently seem to try anyone with a DotNetNuke system, if DNN wasn't the case why would the robot have even been created?  I'm looking at the most obvious cases here and I really can't see that enabling PHP on a web server could cause it to be hacked so easily.

I was not using PHP for anything, I just noticed that it was enabled, I don't need/want PHP, that's why I'm using DNN.  I'm a dotnet developer and prefer it to all the other web technologies available.

My new site has only been up and running (fresh VPS) since June/July 2008 some time, so you are suggesting that a security hole found in 2007 was still present on my system?  I shall have a check but will be quite surprised.

What I find quite amusing is that I have said I disabled PHP, but not proved what was the cause of my site being hacked, as I am treating it the same as all other custom modules, you are really willing to blame PHP, yet do not even want me to suggest that a DNN module is at fault, do you not think that's a little bit hypocritical?  I have to look at the entire picture, which is what I'm doing.

I've already explained why this isnt a dotnetnuke issue @ http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/30/threadid/252359/scope/posts/threadpage/2/Default.aspx ,but i did some subsequent research and noticed that include_path (the querystring value in your original url) is an administration value used by plesk's Horde webmail (see http://robotterror.com/site/wiki/quick_patch_for_php_5_2_5_breaking_horde_on_plesk_8_2_1_and_earlier ) .Due to a bug in versions of php prior to 5.2.5 , associated applications were able to override php values (this would be the rough equivalent of bad asp.net code being able to set IIS values - scary stuff).

I've worked in internet security for a number of years and during that time php & mysql were always regarded as easy targets - mainly due to php code being scripting code (and not compiled classes) and mysql code usually being dynamic sql (before v5 added support for stored procedures. In addition the php engine itself was prone to a lot of major security issues -just like asp was back in the days before Microsoft got their house in order. Whilst php/mysql has got a lot better, there is still a legacy of a lot of code implemented with bad practices and I would recommend if possible you run any php app's on a seperate server, as you are much more likely to have a hack caused by php/mysql that asp.net/sql server (note: apache is a superb webserver so immune from any criticism here). The other major problem is that if you have a hack caused by an error in php itself or an application written in php, then as there is no sandbox of permissions (like .net's code access security), many hacks can escalate above the site itself.

Cathal