Linux zombies show platforms don't matter

Building competence in systems administration and disciplined coding practices is the key to a secure infrastructure. It's not a question of which platform is best, it's a question of the right platform for the right organization and it's perfectly normal for various organizations to differ. Picking a platform whether it's open or closed source by catering to an organization's existing pool of IT talent is the most pragmatic and safest thing to do.

[Updated 4/17/2006:]  When fellow blogger Richard Stiennon posted this blog/podcast about new types of alarming DDoS (Distributed Denial of Service) attacks where an army of Linux zombies were used, he got a bit of a bashing by some of the Linux fans.  Ironically, Richard himself has recently bashed the entire Windows Platform and stated unequivocally as an "IT Commandment" but that the Windows Platform should be avoided entirely.  But that doesn't seem to matter and he's now accused of being a Microsoft "fanboy" by a barrage of negative feedback and somehow incompetent for simply reporting the fact that a group of Linux servers running PHP were turned in to zombies by a clever hacker.  While I'm no stranger to this type of feedback, I do find it ironic that Linux zealots would attack someone who has a history of being anti-Microsoft and sympathetic to UNIX and Linux.

As all the evidence indicates, the platform (Operating System and Web Server) really doesn't matter.  This 2005 report of confirmed website defacements by Zone-H shows that even though Linux and Apache were defaced more than Windows and IIS (contrary to popular misconception), it wasn't the OS or Web Server that accounted for the biggest factor but the skill the PHP/ASP programmer or the Server Administrator or the Application Server platform.  Looking at the results for attack method on page 17 of the Zone-H 2005 report, "FTP inclusion" and "file inclusion" were two of the biggest factors for server compromise and stolen administrative credentials along with Application Server bugs were the next big factors.  File inclusion exploits can occur when sloppy PHP or ASP coding is done and it isn't the PHP or ASP language itself that's being exploited.  There is no way a firewall can prevent this sort of application-level attack and even Application Layer Firewalls would have a hard time distinguishing a legitimate application call to a malicious one.

This tends to prove that the focus on platform choice and the whole Monoculture fear is blown out of proportion.  If anything, the added complexity of managing multiple platforms will cause even more configuration and coding errors not to mention that it suffers the combined software flaws of multiple platforms.  I find it ludicrous for the anti-Monoculture crowd to promote the use of multiple platforms for a single website.  Operating Systems and Web Servers can certainly be a small factor, but they can easily be locked down and patched for exploits using automated patching tools but looking for sloppy coding isn't so trivial.  Building competence in systems administration and disciplined coding practices is the key to a secure infrastructure.  It's not a question of which platform is best, it's a question of the right platform for the right organization and it's perfectly normal for various organizations to differ.  Picking a platform whether it's open or closed source by catering to an organization's existing pool of IT talent is the most pragmatic and safest thing to do.

[Updated 4/17/2006:]  For those who still Apache is fundamentally superior to IIS, take a look at these vulnerability statistics.  There are no critical vulnerabilities for IIS 6.0 since its release in 2003 and that is rather amazing.  Apache 2.0.x has far more vulnerabilities including 2 critical ones.  This information is not sufficient to prove that IIS 6.0 is better than Apache 2.0.x, but it certainly shows how silly it is for people to insist that Apache is better or that Microsoft's solution is fundamentally flawed.

Newsletters

You have been successfully signed up. To sign up for more newsletters or to manage your account, visit the Newsletter Subscription Center.
See All
See All