This post which depicts just why Windows is less secure than Linux has been moved to here.
Update: Stiennon’s blog has moved to here.
Threat Chaos
Richard StiennonWhy Windows is less secure than Linux
Kick off your day with ZDNet's daily e-mail newsletter. It's the freshest tech news and opinion, served hot. Get it.
More from “Threat Chaos”
Topics
Disclosure
Richard
http://blogs.zdnet.com/threatchaos/?page_id=455
Biography
Richard
A former ZDNet blogger, Richard Stiennon is an industry consultant. Most recently he was Chief Marketing Officer for Fortinet, Inc., the largest privately held security vendor. prior to that he was Chief Research Analyst at IT-Harvest. And before creating IT-Harvest, he was VP of threat research for Webroot Software, Inc. the leading commercial anti-spyware solution.
Previously, Richard was VP Research at Gartner, Inc. where he covered security topics including firewalls, intrusion detection, intrusion prevention, security consulting and managed security services for the Security and Privacy group. He is a holder of Gartner's Thought Leadership award for 2003 and was named "One of the 50 most powerful people in Networking" by NetworkWorld magazine. His speaking engagements have included conferences and meetings throughout North and South America, Hawaii, Tokyo, Tel Aviv, Istanbul, Milan, Munich, Hannover, Madrid, London, and Cannes.
Related Discussions on TechRepublic
Did you know you can take part in these discussions with your ZDNet membership?Just In
Like Mr. Stiennon said, a picture is worth a million words(I think it's supposed be a thousand, though). You don't even have to be a techie to appreciate the difference in the comparison. Modularity takes some effort, but it's worth it in the end. Microsoft should work on that, given the spiderweb-like interdependencies in IIS' function calls.
BTW, it looks like jmjames is trying to shoot the messenger, but the bullets(the links) appear to be blanks. "Uhh... ya got me, ya dirty rat!"
BTW, it looks like jmjames is trying to shoot the messenger, but the bullets(the links) appear to be blanks. "Uhh... ya got me, ya dirty rat!"
Blame it on ZDNet, not me. Their sucktacular software *inisists* (even with a pre tag in there!) on putting a space in the link because it is long.
J.Ja
J.Ja
Quite often when I put up a link, it gets wrapped to the next line. In fact, my first post here was supposed to be in two paragraphs. I did copy and paste the whole address now, so I can see your blog post in a new tab. It was a good blog, but I'm kinda interested in the part where you said that IIS does more out of the box than Apache, that's why there's so many function calls. I agree with that, but I think IIS shouldn't have that much functionality out of the box anyhow. It should be up to the programmer what extra functionality is required for his/her needs, but the spiderweb-like picture of IIS shows that some functionality can pop up when you least expect it. As I said before, IIS definitely needs to be more modular and lean.
PS- If you have looked at tic swayback's suggestion to the hyperlinking problem, here it is:
http://tinyurl.com/fafaa
PS- If you have looked at tic swayback's suggestion to the hyperlinking problem, here it is:
http://tinyurl.com/fafaa
Don't get me wrong; Apache is a great piece of software. But Mr. Stiennon's comparison as well as his "facts" are wildly inaccurate. If you compare what IIS is doing vs. what Apache is doing, of course their are more system calls. Apache, in a base configuration, is little more than a simple file server. You make a request, I send a file. IIS is doing a lot more. Apache when brought to the same level of functionality as IIS (add in PHP and a few other modules) probably makes just as many system calls. Furthermore, serving static HTML pages does not open you up to attacks. Server side scripting (particularly when done wrong) is the real problem. A programmer who doesn't validate data that will be used in a SQL statement will open you to SQL injection attacks, regardless of what web server, OS, or even RDBMS you are using.
J.Ja
J.Ja
System calls are the attack points for buffer overflow attempts. The system calls in these diagrams have nothing to do with the extra functionality of ISS. Those functions are not called in order to display a page of text with a single image. ISS is more complex, therfore has a greater "vulnerability surface area" to use Microsoft's term.
A succesful beffer overlow attack requires MSFT to issue a new patch, usually "critical". SQL insertion attacks come from poor coding practices, not a problem with Windows, Linux, or the web server.
A succesful beffer overlow attack requires MSFT to issue a new patch, usually "critical". SQL insertion attacks come from poor coding practices, not a problem with Windows, Linux, or the web server.
And again, just how does one go about doing a buffer overflow on a static HTML request? You are simply not getting the point here. There is virtually ZERO "vulnerable surface area" on a static HTML request (which your documents are about) since the only pieces of data that come from the user are HTTP headers. Because the web server executes zero ZERO ZERO processing of the output, and barely touches the input! I really don't know who taught you about these things, but they did not know what they were talking about. Now, if you said an ASP page (even one that did not actually contain any code, but just forced itself to run through the ASP ISAPI filter), I might agree with you, because then ISAPI would stick its grubby paws all over that user data. But a static HTML request just doesn't touch the input from the user except to process the HTTP headers, so a buffer overflow is next to impossible.
And as I already stated MANY MANY MANY times, application layer vulnerabilities are the real problem, not web server vulnerabilities. And that is my point. It doesn't matter how secure the server itself is, when the truly low hanging fruit is the applications anyways, and always will be, until people stop listening to people like and and thinking, "well, it's running on LAMP, so its secure". No. That does not make it secure. Proper programming makes something secure and people like you make the problem worse, so then companies like Webroot (your former employer) can then make money cleaning it up.
J.Ja
And as I already stated MANY MANY MANY times, application layer vulnerabilities are the real problem, not web server vulnerabilities. And that is my point. It doesn't matter how secure the server itself is, when the truly low hanging fruit is the applications anyways, and always will be, until people stop listening to people like and and thinking, "well, it's running on LAMP, so its secure". No. That does not make it secure. Proper programming makes something secure and people like you make the problem worse, so then companies like Webroot (your former employer) can then make money cleaning it up.
J.Ja
Is there something woderfully static about the 1,700 system calls ISS makes to deliver a single page of content? *Any* call to memory is an opportunity to inject a buffer overflow. If you are worrying about writing vs reading look at the dozens of writes IIS (or Apache) must make to log the http request.
The discussion at hand is about the difference in complexity between Linux-Apache and IIS-Windows. Thanks for your input on application layer security. I agree.
The discussion at hand is about the difference in complexity between Linux-Apache and IIS-Windows. Thanks for your input on application layer security. I agree.
there are two sides of security, one side is the
client that requests the page and the other side
is the insecure asp code on the server.
I don't think that securing the client side
requests is a serious problem nor it is
associated with all of those 1700 system calls
(I mean that it is just an http header that the
server gets). but for creating html code from
the asp code, the number of calls is a
serious issue. I don't believe that much of the
1700 system calls are associated for creating an
html document from the asp page. If so, it is a
serious problem. However, still I don't belive
that the number of calls for
creating the html page from asp is no more than
what apache has, simply by looking at that
picture. I don't believe that picture is showing
insecurity unless one tells me that all of those
complexity is for creating html code from asp
code. I mean that, I need more documentation to
believe that all of those 1700 calls are
associated with playing user input (e.g. the asp
code that a hacker has legally placed on a IIS
server) I might be totally wrong but I need more
evidence to believe that all of those 1700 calls
are associated with playing insecure user input.
client that requests the page and the other side
is the insecure asp code on the server.
I don't think that securing the client side
requests is a serious problem nor it is
associated with all of those 1700 system calls
(I mean that it is just an http header that the
server gets). but for creating html code from
the asp code, the number of calls is a
serious issue. I don't believe that much of the
1700 system calls are associated for creating an
html document from the asp page. If so, it is a
serious problem. However, still I don't belive
that the number of calls for
creating the html page from asp is no more than
what apache has, simply by looking at that
picture. I don't believe that picture is showing
insecurity unless one tells me that all of those
complexity is for creating html code from asp
code. I mean that, I need more documentation to
believe that all of those 1700 calls are
associated with playing user input (e.g. the asp
code that a hacker has legally placed on a IIS
server) I might be totally wrong but I need more
evidence to believe that all of those 1700 calls
are associated with playing insecure user input.
(Buzzer sounds: BZZZZZZZZZZZZZZZZZZZZZZZZzzzz...)
I am sorry. That was incorrect.
The answer is: Modularity
But we have a parting gift for you on your way out!
And now for a brief station break.
I am sorry. That was incorrect.
The answer is: Modularity
But we have a parting gift for you on your way out!
And now for a brief station break.
Dietrich, you are usually pretty good, but I think on this thread your reading comprehension is poor. I have stated quite a number of times, both in this thread and in my blog that modularity is exactly the reason why Apache cannot be compared to IIS, and why IIS makes so many more system calls. Apache, as a modular system, is not capable with default settings of doing anything other than serve static HTML, while IIS has a lot of non-removable, non-disablable functionality already in it. I have also mentioned a number of times that Apache, once brought up to the level of functionality of IIS through standard and non-standard extensions (mod_perl, mod_rewrite, PHP, etc.) probably makes just as many system calls as IIS. To compare the two on an out-of-the-box installation for just serving static HTML just isn't possible, it's like comparing a 1987 Monte Carlo to a new Corvette. Sure, I can make a 1987 Monte Carlo handle like a BMW 3 series and run a quarter mile in 10 seconds and still have the total cost be less than a Corvette, but the Monte Carlo needs a lot of add-ons to reach that level of functionality while the Corvette comes from the dealer with that level of performance.
J.Ja
J.Ja
Come now.
Have you lost your good sense of humor or, perhaps, did I strike a nerve?
I had to break out the dictionary and look up "non-disablable". Couldn't find it.
Is that anything like 'techno-babble'?
And, hey, thanks ALOT for helping me with my reading comprehension difficulties, but I don't see where car talk has any place in a ZDNet forum!!
Reheheally!
Is it me Folks!?
Have you lost your good sense of humor or, perhaps, did I strike a nerve?
I had to break out the dictionary and look up "non-disablable". Couldn't find it.
Is that anything like 'techno-babble'?
And, hey, thanks ALOT for helping me with my reading comprehension difficulties, but I don't see where car talk has any place in a ZDNet forum!!
Reheheally!
Is it me Folks!?
To be honest, my sense of humor was missing when I wrote that this morning. I know you were probably(?) kidding with the sarcasm, but I have just been very frustrated at seeing people not actually reading things before attacking them lately. Too many times lately I'm seeing stuff like:
Person A: Why is the water wet?
Person B: The sky is blue because of [insert long scientific explanation here]
It's a total shell game, and that's really what I was reacting against.
Also apologies for the language, I was not devoting 100% attention to my typing (on the phone) and I know better... like the time recently when I said something like "interpreted language run faster than compiled languages" when I know better...
J.Ja
Person A: Why is the water wet?
Person B: The sky is blue because of [insert long scientific explanation here]
It's a total shell game, and that's really what I was reacting against.
Also apologies for the language, I was not devoting 100% attention to my typing (on the phone) and I know better... like the time recently when I said something like "interpreted language run faster than compiled languages" when I know better...
J.Ja
Everything is fine in ZDNet-landia.
Vas Schtup?
Vee Double-U.
Verd Up.
Keep the TalkBacks coming!
Thanks J.Ja
Vas Schtup?
Vee Double-U.
Verd Up.
Keep the TalkBacks coming!
Thanks J.Ja
I wouldn't bother arguing with RS on this subject. His overly simple, 'more complicated == less insecure' argument sounds nice in theory, but falls flat on it's face if you decide to actually compare the two products objectively.
RS is a *nix evagenlist, so no amount of evidence or sound logic will sway him. For him, *nix is the answer to everything, and to suggest that *nix has security issues, or worse is rivaled by Windnows in certain areas of security is a matter of blasphemy.
Anyone who is interested in comparing the security of IIS and Apache might want to actually start by checking out some facts. Here is a good place to start.
Secunia Advisories on IIS5
Secunia Advisories on IIS6
Secunia Advisories on Apache 2.0
Secunia Advisories on Apache 1.3
But of course, *nix evangelists tend to claim that discovered vulnerabilities mean nothing when confronted with the above numbers. In that case, point them to Zone-H.org and tell them to look up defacement statistics from the last five years. You'll find that the last time IIS was shown to be compromized more than Apache was around 2002. That was four years ago. There are a million version of this quote, but it goes something like this: "This who live in the past have no future." Richard had already shown his inablility to let go of the past via his past articles, which all show a theme of quoting irrelevant (old) statistics or by hanging onto long obsolete factoids about products he doesn't like. In these very talkbacks he shows this by posting a link to a vulnerability in IIS from 2001.
RS is a *nix evagenlist, so no amount of evidence or sound logic will sway him. For him, *nix is the answer to everything, and to suggest that *nix has security issues, or worse is rivaled by Windnows in certain areas of security is a matter of blasphemy.
Anyone who is interested in comparing the security of IIS and Apache might want to actually start by checking out some facts. Here is a good place to start.
Secunia Advisories on IIS5
Secunia Advisories on IIS6
Secunia Advisories on Apache 2.0
Secunia Advisories on Apache 1.3
But of course, *nix evangelists tend to claim that discovered vulnerabilities mean nothing when confronted with the above numbers. In that case, point them to Zone-H.org and tell them to look up defacement statistics from the last five years. You'll find that the last time IIS was shown to be compromized more than Apache was around 2002. That was four years ago. There are a million version of this quote, but it goes something like this: "This who live in the past have no future." Richard had already shown his inablility to let go of the past via his past articles, which all show a theme of quoting irrelevant (old) statistics or by hanging onto long obsolete factoids about products he doesn't like. In these very talkbacks he shows this by posting a link to a vulnerability in IIS from 2001.
Mr. Stiennon has made some crucial mistakes in his "analysis". Let's see if ZDNet's lame comments system will let me post a link to the blog I wrote in response to this article:
Link
Or...
http://techrepublic.com.com/5254-6257-0.html?forumID=99&threadID=184332&messageID=1995023&id=2926438
Or...
http://techrepublic.com.com/5254-6257-0.html?forumID=99&threadID=184332&messageID=1995023&id=2926438
J.Ja
Link
Or...
http://techrepublic.com.com/5254-6257-0.html?forumID=99&threadID=184332&messageID=1995023&id=2926438
Or...
http://techrepublic.com.com/5254-6257-0.html?forumID=99&threadID=184332&messageID=1995023&id=2926438
J.Ja
If that's the list of hoops it jumps through for the simplest of tasks then what's going to happen when things get more complicated?? Is IIS suddenly going to start using fewer system calls? I think not...
An unexpected failure has occured. It has been logged and will be addressed by support.
Your URLs are broken, are you running Windows?
Your URLs are broken, are you running Windows?
I appreciate that you tried to follow the links. If you look at what I wrote, there is a SEVERE malfunction with ZDNet's comment system, it refuses to put the links up properly. It puts a space in them. Let me retry, with a pre tag on them:
J.Ja
http://techrepublic.com.com/5254-6257-0.html?forumID=99&threadID=184332&messageID=1995023&id=2926438
J.Ja
You need to paste the URL together, because ZDNet's commenting system sucks. That's "Powered by WordPress" for ya, can't blame that on Microsoft.
J.Ja
J.Ja
In your difficult to find post you claim that buffer overflow attacks against ISS are rare. But that is what we are talking about here. The whole debate of Apache vs ISS was ignited in 2001 when a vulnerability in ISS went unpatched by most sys admins.
Quoting from the CERT advisory: "remotely exploitable buffer overflow in one of the ISAPI extensions installed with most versions of IIS 4.0 and 5.0 (The specific Internet/Indexing Service Application Programming Interface extension is IDQ.DLL). An intruder exploiting this vulnerability may be able to execute arbitrary code in the Local System security context. This essentially can give the attacker complete control of the victim system.
See http://tinyurl.com/fj45h for the full advisory and links to the Microsoft alerts. Code Red and the subsequent Nimda that also exploited the same vulnerability were two of the most devestating worms to ever hit the Internet.
Quoting from the CERT advisory: "remotely exploitable buffer overflow in one of the ISAPI extensions installed with most versions of IIS 4.0 and 5.0 (The specific Internet/Indexing Service Application Programming Interface extension is IDQ.DLL). An intruder exploiting this vulnerability may be able to execute arbitrary code in the Local System security context. This essentially can give the attacker complete control of the victim system.
See http://tinyurl.com/fj45h for the full advisory and links to the Microsoft alerts. Code Red and the subsequent Nimda that also exploited the same vulnerability were two of the most devestating worms to ever hit the Internet.
"Quoting from the CERT advisory: "remotely exploitable buffer overflow in one of the ISAPI extensions installed with most versions of IIS 4.0 and 5.0 (The specific Internet/Indexing Service Application Programming Interface extension is IDQ.DLL)."
Hmm, that sure doesn't sound like a problem with "serving static HTML" pages to me, which is exactly what your blog post complains about. Do you even know what ISAPI is? Furthermore, read your own quote! An optional add on. "Option add ons" have nothing to do with serving static HTML.
Are you running for elected office? Because you keep trying to change the subject. Your use of static HTML pages as an example is indefensible. You bring up an advisory from 5 years ago that relates to versions of IIS that haven't been around for YEARS. That's like me bringing up problems in the Linux 2.2 kernel. Or the zlib problem. Or security flaws with BIND 8. I don't bring them up because they are no longer relevant. Even worse, your own quote shows the problem with what you said: "...when a vulnerability in IIS went unpatched by most sys admins". Like I say in my blog post, ignorant/lazy sys admins. The problem was fixed. Sys admins didn't apply the patch.
Personally, I like Apache, a lot, to be honest. But I simply do not compare Apache to IIS. I use IIS when an application requires ASP or ASP.Net or some other Windows/IIS specific technology. I use Apache in all other siutations, typically. I find them equally easy to administrate, and for the volume of Web traffic that servers I use handle, scalability is not a factor. But you are totally out to lunch on this one. Compare Apache to IIS on real, tangible things, and the only things they can be compared on is the scalability of static HTML serving, and ease of comfiguration. That is it. To compare anything other than that requires adding extensions to Apache which have nothing to do with Apache, such as Perl, PHP, Java, etc.
J.Ja
Hmm, that sure doesn't sound like a problem with "serving static HTML" pages to me, which is exactly what your blog post complains about. Do you even know what ISAPI is? Furthermore, read your own quote! An optional add on. "Option add ons" have nothing to do with serving static HTML.
Are you running for elected office? Because you keep trying to change the subject. Your use of static HTML pages as an example is indefensible. You bring up an advisory from 5 years ago that relates to versions of IIS that haven't been around for YEARS. That's like me bringing up problems in the Linux 2.2 kernel. Or the zlib problem. Or security flaws with BIND 8. I don't bring them up because they are no longer relevant. Even worse, your own quote shows the problem with what you said: "...when a vulnerability in IIS went unpatched by most sys admins". Like I say in my blog post, ignorant/lazy sys admins. The problem was fixed. Sys admins didn't apply the patch.
Personally, I like Apache, a lot, to be honest. But I simply do not compare Apache to IIS. I use IIS when an application requires ASP or ASP.Net or some other Windows/IIS specific technology. I use Apache in all other siutations, typically. I find them equally easy to administrate, and for the volume of Web traffic that servers I use handle, scalability is not a factor. But you are totally out to lunch on this one. Compare Apache to IIS on real, tangible things, and the only things they can be compared on is the scalability of static HTML serving, and ease of comfiguration. That is it. To compare anything other than that requires adding extensions to Apache which have nothing to do with Apache, such as Perl, PHP, Java, etc.
J.Ja
It's not Apache v/s IIS. It's how they interact with the OS to serve a request. And why are you bringing in ASP.NET and PHP, perl and other stuff?
You talk about IIS and then ramble something about linux 2.2... Application tied to OS v/s and OS. Are you that dumb? zlib effected all versions of Windows too (but, what was your point?)
At least debate on the topic and don't ramble on something you have heard somewhere...
You talk about IIS and then ramble something about linux 2.2... Application tied to OS v/s and OS. Are you that dumb? zlib effected all versions of Windows too (but, what was your point?)
At least debate on the topic and don't ramble on something you have heard somewhere...
ZDNet's awful forum software has issues with linewraps, so any URL that goes past the length of one line in their system gets broken up and no longer works. To get around this:
1) Go to http://www.tinyurl.com and get a short alias for the link you want to post.
2) Use html tags LinkName
Just be sure to use square brackets [] instead of the ones I used above
1) Go to http://www.tinyurl.com and get a short alias for the link you want to post.
2) Use html tags LinkName
Just be sure to use square brackets [] instead of the ones I used above
Thanks for the tips! I tried using the HTML tags, but it didn't work. Thought about tiny url a little while later. It's weird, I guess I am becoming more of a "typical user", but I would rather not post something at all than to deal with their lousy software. This is why I have been doing less and less comments lately. Seeing as I get zero utility from posting a comment here, and only frustration, why should I bother?
J.Ja
J.Ja
Do the tags have to be in square brackets, instead of angle brackets? Despite what the "Reply to ..." page says, it's not HTML if it's in square brackets, right?
PS- Thanks for the TinyUrl link! I've got it bookmarked now for all my future posts.
PS- Thanks for the TinyUrl link! I've got it bookmarked now for all my future posts.
...as my html skills are, to use the parlance, teh suck. But they should be in square brackets for ZDNet, not angled ones. On my "reply" pages it has a list of HTML tags that are supported and they're all shown in square brackets.
If you want to get owned, don't use TINY URL. You can obfuscate the destination, taking someone to a site that is Not Safe for Work... such as this link (NSFW-Or your brain) -> http://tinyurl.com/5hfse.
If you really want to shorten URL's, us http://minilink.org, as the same link in minilink form http://lnk.nu/encyclopediadramatica.com/dnl.jpg. If you don't know that Encyclopedia Dramatica is all about NSFW subjects...
If you really want to shorten URL's, us http://minilink.org, as the same link in minilink form http://lnk.nu/encyclopediadramatica.com/dnl.jpg. If you don't know that Encyclopedia Dramatica is all about NSFW subjects...
(Yes, we're listening to you, J.)
Simply pasting in the long link below:
http://techrepublic.com.com/5254-6257-0.html?forumID=99&threadID=184332&messageID=1995023&id=2926438
Simply pasting in the long link below:
http://techrepublic.com.com/5254-6257-0.html?forumID=99&threadID=184332&messageID=1995023&id=2926438
Is this bold?
Blogs Link
Blogs Link
We've tried using A HREF before and it works fine for shorter URLs. But if it's really long, it still injects a space in the middle of the URL breaking it.
{url=http://home.toadlife.net}Website{/url}
Just use square brackets instead of curly brackets and you'll be set.
Website
Just use square brackets instead of curly brackets and you'll be set.
Website
tic swayback already provided the 411 on linking here. But I think it should be in angle brackets, like how real HTML is. This just causes a lot of confusion for newbies.
PS- I read your blog. It's alright, and I like that you're making a Windows version of sudo. Very cool. I don't use Windows, but I truly hope your program becomes a big success. Any programs that help promote least privilege practices are good in my book.
PS- I read your blog. It's alright, and I like that you're making a Windows version of sudo. Very cool. I don't use Windows, but I truly hope your program becomes a big success. Any programs that help promote least privilege practices are good in my book.
http://blogs.zdnet.com/Ou/?p=191
Linux and Apache defaced more than Windows and IIS.
Linux and Apache defaced more than Windows and IIS.
You keep pointing to this report from Zone-H to support your argument that Linux-Apache is less secure than Windows-ISS based on number of attacks. The report itself says that the reults say nothing of the reletive merits of the two platforms. Besides these numbers are somehow collected from the *attackers* a very strange source of data.
They do not take into account the 250,000+ IIS servers that were infected by Code Red in mid-2001 or the millions of machines infected by Nimda later that year. (Yes, I know, Nimda used 5 different Windows vulnerabilities only one of which was in IIS). I made no claims as to which platform was more targeted in this post. I claim that IIS has more system calls than Apache. And I use pictures derived from a tool that Sana Security developed to demonstrate that graphically.
They do not take into account the 250,000+ IIS servers that were infected by Code Red in mid-2001 or the millions of machines infected by Nimda later that year. (Yes, I know, Nimda used 5 different Windows vulnerabilities only one of which was in IIS). I made no claims as to which platform was more targeted in this post. I claim that IIS has more system calls than Apache. And I use pictures derived from a tool that Sana Security developed to demonstrate that graphically.
A report from 2005 is not "old". You bringing up NIMDA from 2001 is old. Talking about the number of system calls is utter nonsense from a security point of view.
Fact is, IIS 6 since its inception 3 years ago has ONLY had 2 minor flaws which involve no code execution flaws.
http://secunia.com/product/1438/
Fact is, Apache 2.x has had way more flaws in any period of time including 7% unpatched and 4% critical.
http://secunia.com/product/73/
The fact that you would bring up IIS vs. Apache of all things to show how Windows is "inferior" is laughable. Maybe you think you?re making up with some red meat for the ABM zealot crowd after that last blog, but your blatant bias in this matter is ridiculous and your ?evidence? is laughable. If anything, the facts lean towards the opposite of what you?re promoting.
I don't tell people which platform is best, I tell people it really doesn't matter and that they should use what they love and know best.
Fact is, IIS 6 since its inception 3 years ago has ONLY had 2 minor flaws which involve no code execution flaws.
http://secunia.com/product/1438/
Fact is, Apache 2.x has had way more flaws in any period of time including 7% unpatched and 4% critical.
http://secunia.com/product/73/
The fact that you would bring up IIS vs. Apache of all things to show how Windows is "inferior" is laughable. Maybe you think you?re making up with some red meat for the ABM zealot crowd after that last blog, but your blatant bias in this matter is ridiculous and your ?evidence? is laughable. If anything, the facts lean towards the opposite of what you?re promoting.
I don't tell people which platform is best, I tell people it really doesn't matter and that they should use what they love and know best.
Hard to see with this font I know.
I tell people that if they continue to standardize on Windows they are going to incur more expense and more down time because when there is a Windows exploit it will hit everything not just their desktops, but their servers, PBX's, copiers, printers, building security systems, ATM's, manufacturing controllers, SCADA, media centers, medical equipment and cell phones. Not only is it OK to run different OS's for different applications it is *better* for your overall IT health.
If there were such a thing as a 100% Linux shop I would advice looking at something different for desktops. Diversify!
I tell people that if they continue to standardize on Windows they are going to incur more expense and more down time because when there is a Windows exploit it will hit everything not just their desktops, but their servers, PBX's, copiers, printers, building security systems, ATM's, manufacturing controllers, SCADA, media centers, medical equipment and cell phones. Not only is it OK to run different OS's for different applications it is *better* for your overall IT health.
If there were such a thing as a 100% Linux shop I would advice looking at something different for desktops. Diversify!
First of all, PBX - ATMs are a different animal more suited for stripped down customized operating systems, not full blown desktop or server OSes. It's not part of the IT discussion as far as I'm concerned.
Second, I know I misread "odd" for "old", but you really didn't answer a single point I raised with the superiority of IIS 6.0 quality control and lack of any critical vulnerabilities. That completely destroys any "evidence" you brought up.
Again, diversity for the sake of diversity only increases your likelihood of getting hacked. If you ran a website, it would be stupid to run two sets of web servers because you've just doubled your attack surface.
Second, I know I misread "odd" for "old", but you really didn't answer a single point I raised with the superiority of IIS 6.0 quality control and lack of any critical vulnerabilities. That completely destroys any "evidence" you brought up.
Again, diversity for the sake of diversity only increases your likelihood of getting hacked. If you ran a website, it would be stupid to run two sets of web servers because you've just doubled your attack surface.
Diversity is done not for the sake of diversity, but for the sake of not getting caught with your private parts dangling in the wind creating a nice, juicy target every time the internet sneezes. Diversity...you know, like making sure that both pilots eat from different sources...like making sure that your country doesn't just stock up on one flu vaccine, but two or more so that you are left with some population after a pandemic, or is that diversity for the sake of diversity?
There's probably something witty to be said here about you needing a clue-stick and lessons in auto-flagellation, but you're not going to understand, so I won't bother.
There's probably something witty to be said here about you needing a clue-stick and lessons in auto-flagellation, but you're not going to understand, so I won't bother.
There is no such thing as an "Internet sneeze" and if you're worried about up time, there is no good way to defend against a brute DDoS attack. You're so obsessed with the irrelevant survivability threat that you don't even recognize that you can't really defend against DoS anyways. But you're willing to double your attack-surface.
Need some coffee, George?
Okay, the point was (though not explicitly stated) that from a PROGRAMMER's perspective, Windows Apps are more difficult to secure than Linux Apps. This is in general true. The IIS vs Apache was given only as an example, and is not in itself the basis of the article. Also note, the article did not take in to account the amount of work that has been done to secure the apps or indeed which one is more secure. Windows IIS undoubtedly took more exhaustive programming to make it as secure as it is, and for what you have to pay for it, it had better be more secure.
Second, redundancy, irregardless of platform, is not always a bad idea, just in case one server STB, you're not dead in the water. However, unless you have redundant servers with different public IPs on separate networks, than doing it for security is a waste of time and resources. Diversity behind the same gateway is useless, because as George did point out, if an attack is going to close your network, the same attack is going to close off all your network, and it's not going to matter what platform you are running or how many of them; all you're doing is making more work for yourself, pre and post attack.
If the central artery suffers a major collapse, adding more on ramps is not going to relieve the traffic jam, and it's not going to matter if you're riding on cement or tarmac.
Okay, the point was (though not explicitly stated) that from a PROGRAMMER's perspective, Windows Apps are more difficult to secure than Linux Apps. This is in general true. The IIS vs Apache was given only as an example, and is not in itself the basis of the article. Also note, the article did not take in to account the amount of work that has been done to secure the apps or indeed which one is more secure. Windows IIS undoubtedly took more exhaustive programming to make it as secure as it is, and for what you have to pay for it, it had better be more secure.
Second, redundancy, irregardless of platform, is not always a bad idea, just in case one server STB, you're not dead in the water. However, unless you have redundant servers with different public IPs on separate networks, than doing it for security is a waste of time and resources. Diversity behind the same gateway is useless, because as George did point out, if an attack is going to close your network, the same attack is going to close off all your network, and it's not going to matter what platform you are running or how many of them; all you're doing is making more work for yourself, pre and post attack.
If the central artery suffers a major collapse, adding more on ramps is not going to relieve the traffic jam, and it's not going to matter if you're riding on cement or tarmac.
Once upon a time there was a Telephone Company.
And it bought a whole bunch of new servers, and there was Joy
in Mudville.
But then weird things started happening. And it turned out that
there was a bug in the server software that triggered a false
"overflow" condition.
The affected server then diverted it's traffic to it's neighboring
servers, which, being the same model, also went "overflow" and
diverted THEIR traffic.
The "domino effect" didn't stop until the traffic hit the older
model servers that hadn't been replaced yet.
The ripples from that snafu spread out for hundreds of miles:
even folks in neigboring States found they couldn't place a
simple call across their own State because of all the server
bottlenecks.
So, what's the lesson here ? Identical architecture means
identical weaknesses.
"Increasing attack surface" isn't it, folks. It's about hedging
your bets.
For example, having Macs in your company, or a few Linux
boxes, is nice insurance against the inevitable virus attacks
against Windows.
That way when Murphy comes calling, and the Windows boxes
crash, you're not totally out of business.
Of course, George will now insist that a clever hacker could
trigger attacks against all platforms you MIGHT use
simultaneously.
But I think that's less than likely. The brainiacs I know focus on
one platform to the exclusion of all others.
And it bought a whole bunch of new servers, and there was Joy
in Mudville.
But then weird things started happening. And it turned out that
there was a bug in the server software that triggered a false
"overflow" condition.
The affected server then diverted it's traffic to it's neighboring
servers, which, being the same model, also went "overflow" and
diverted THEIR traffic.
The "domino effect" didn't stop until the traffic hit the older
model servers that hadn't been replaced yet.
The ripples from that snafu spread out for hundreds of miles:
even folks in neigboring States found they couldn't place a
simple call across their own State because of all the server
bottlenecks.
So, what's the lesson here ? Identical architecture means
identical weaknesses.
"Increasing attack surface" isn't it, folks. It's about hedging
your bets.
For example, having Macs in your company, or a few Linux
boxes, is nice insurance against the inevitable virus attacks
against Windows.
That way when Murphy comes calling, and the Windows boxes
crash, you're not totally out of business.
Of course, George will now insist that a clever hacker could
trigger attacks against all platforms you MIGHT use
simultaneously.
But I think that's less than likely. The brainiacs I know focus on
one platform to the exclusion of all others.
Two system can be operating in parallel (acting as each other's backup) or in series (one depending on the other).
If two systems are running in parallel (such as a web site farm) diversity protects you against DOS attacks (as it is less likely that both systems will get hacked at the same time) and increases your exposure to disclosure, penetration or integrity attacks (as you double the number of vulnerabilities you expose and you double the chances of misconfiguration). It is generally accepted that DOS is a less serious damage than disclosure, integrity or penetration.
If two systems are in series both systems need to be working for the solution to work. Diversity then increases your exposure to all type of attack, as it is enough for one vulnerability on either of the platforms to get exploited and you are done.
Given that, I don't see how diversity can be a good thing. It increases the odds of damage in almost every possible scenario and increases management overhead, costs and error rates.
Analogy is a good tool for teachning, but a VERY bad tool for analysis. Using analogy to make decisions is not smart.
If two systems are running in parallel (such as a web site farm) diversity protects you against DOS attacks (as it is less likely that both systems will get hacked at the same time) and increases your exposure to disclosure, penetration or integrity attacks (as you double the number of vulnerabilities you expose and you double the chances of misconfiguration). It is generally accepted that DOS is a less serious damage than disclosure, integrity or penetration.
If two systems are in series both systems need to be working for the solution to work. Diversity then increases your exposure to all type of attack, as it is enough for one vulnerability on either of the platforms to get exploited and you are done.
Given that, I don't see how diversity can be a good thing. It increases the odds of damage in almost every possible scenario and increases management overhead, costs and error rates.
Analogy is a good tool for teachning, but a VERY bad tool for analysis. Using analogy to make decisions is not smart.
Always fun to hear George Ou accusing OTHER people of bias.
His proof:
1) Zone-H (Yeah, now THERE'S a rigorously tested source of statistics)
2) Security vulnerability listings
And what do these have in common? That both are lousy sources of statistics or proof.
The listing of security vulnerabilities is especially egregious, because everyone ought to know that the most secure vendors are the ones that are willing to publish the most vulnerabilities, and the least secure vendors are trying the hardest to keep their vulnerability count down. If anything, more vulnerabilities posted on a platform proves the vendors care more about their security.
In other words: don't confuse the number of vulnerabilities LISTED with the number of vulnerabilities EXISTING, because a lot of vendors try not to admit to their vulnerabilities.
His proof:
1) Zone-H (Yeah, now THERE'S a rigorously tested source of statistics)
2) Security vulnerability listings
And what do these have in common? That both are lousy sources of statistics or proof.
The listing of security vulnerabilities is especially egregious, because everyone ought to know that the most secure vendors are the ones that are willing to publish the most vulnerabilities, and the least secure vendors are trying the hardest to keep their vulnerability count down. If anything, more vulnerabilities posted on a platform proves the vendors care more about their security.
In other words: don't confuse the number of vulnerabilities LISTED with the number of vulnerabilities EXISTING, because a lot of vendors try not to admit to their vulnerabilities.
"Besides these numbers are somehow collected from the *attackers* a very strange source of data"
The data sourced from the attackers (defacers) is actually extremely accurate since their goal is get as much notoriety as possible. The results are automatically and 100% VERIFIED. All the hacker needs to do is modify the victim?s website with their own logo which is automatically verified by Zone-H. If we relied on the victim?s data, it would be about 99% unreliable since they don?t want the embarrassment of having to admit they were hacked. You make the same ignorant comments as some of my talkback people pertaining to zone-h and you?re simply all wrong.
The data sourced from the attackers (defacers) is actually extremely accurate since their goal is get as much notoriety as possible. The results are automatically and 100% VERIFIED. All the hacker needs to do is modify the victim?s website with their own logo which is automatically verified by Zone-H. If we relied on the victim?s data, it would be about 99% unreliable since they don?t want the embarrassment of having to admit they were hacked. You make the same ignorant comments as some of my talkback people pertaining to zone-h and you?re simply all wrong.
Here's some helpful advice for you.
Religious zealots are always boring and convince no one.
Religious zealots are always boring and convince no one.
Buzzer sounds again: BZZZZZZZZZZZZZZZZZZZZZZZZzzzz...)
I am sorry. I am afraid that was incorrect also.
The correct answer is: Modularity
But we have a parting gift for you as well on your way out!
I am sorry. I am afraid that was incorrect also.
The correct answer is: Modularity
But we have a parting gift for you as well on your way out!
Going to your 2005 report from Zone-H one can readily find in multiple locations the following disclaimers:
"Moreover, the graph is based on absolute values in Zone-H database therefore it is not weighted in relation to the real distribution of the installed Operating Systems on the Internet"
"NOTE: this graph cannot be used to determine 'what OS is more secure' as from the year 2004 most of the attacks are at application level, regardless the Operating System"
Essentially the report says over and over again, "don't attempt to draw any OS/WS security conclusions from this report." Yet that's exactly what you've done.
Richard's point is valid. More system calls directly translates into more opportunities to corrupt the system.
"Moreover, the graph is based on absolute values in Zone-H database therefore it is not weighted in relation to the real distribution of the installed Operating Systems on the Internet"
"NOTE: this graph cannot be used to determine 'what OS is more secure' as from the year 2004 most of the attacks are at application level, regardless the Operating System"
Essentially the report says over and over again, "don't attempt to draw any OS/WS security conclusions from this report." Yet that's exactly what you've done.
Richard's point is valid. More system calls directly translates into more opportunities to corrupt the system.
"Richard's point is valid. More system calls directly translates into more opportunities to corrupt the system."
I agree with this 100%. Unfortunately, the example shown is for a static HTML request, qhich outside of attacking the HTTP header processing system, offers no surface area of attack. And with the exception of sending some of the headers to a log file, the only use the Web server has for processing headers on a static HTML file is to determine the requested URI.
Now, if the diagram showed Apache with mod_perl and/or PHP loaded, mod_rewrite, and a semi-complex .htaccess file, then Apache would at least be doing everything that IIS does, even for a static HTML request (checking permissions, re-write rules, determining if the request needs to go through an external handler, etc.). Without those items loaded, Apache and IIS really cannot be properly compared in terms of the number of system calls, simply because Apache is an extremely modular system, and in its base configuration is little more than a system for mapping an URI request to a local file and then streaming that file across the HTTP port with the appropriate HTTP headers.
J.Ja
I agree with this 100%. Unfortunately, the example shown is for a static HTML request, qhich outside of attacking the HTTP header processing system, offers no surface area of attack. And with the exception of sending some of the headers to a log file, the only use the Web server has for processing headers on a static HTML file is to determine the requested URI.
Now, if the diagram showed Apache with mod_perl and/or PHP loaded, mod_rewrite, and a semi-complex .htaccess file, then Apache would at least be doing everything that IIS does, even for a static HTML request (checking permissions, re-write rules, determining if the request needs to go through an external handler, etc.). Without those items loaded, Apache and IIS really cannot be properly compared in terms of the number of system calls, simply because Apache is an extremely modular system, and in its base configuration is little more than a system for mapping an URI request to a local file and then streaming that file across the HTTP port with the appropriate HTTP headers.
J.Ja
A friend of mine told me that Linux is the safest OS that exists now because virus creators do not make viruses for it. They are concerned only about Windows because the majority of people work on Windows regardless of the people preferring MAC. I'm not really an expert at it but this seems logical that Windows is less secure because of the amount of virus attacks aimed at it.
Flac to mp3 converter http://freeflactomp3converter.com/
Flac to mp3 converter http://freeflactomp3converter.com/
Join the conversation!
The best of ZDNet, delivered
ZDNet Newsletters
Get the best of ZDNet delivered straight to your inbox
Vendor Showcase
Facebook Activity
Blog Roll
- All About Microsoft
- The Apple Core
- Between the Lines
- Big on Data
- BriefingsDirect
- Collaboration 2.0
- Consumerization: BYOD
- Dev Connection
- Digital Cameras & Camcorders
- DIY-IT
- The Ed Bott Report
- Emerging Tech
- Enterprise Web 2.0
- Five Nines: The Next Gen Datacenter
- Forrester Research
- Friending Facebook
- Gamification
- Googling Google
- GreenTech Pastures
- Hardware 2.0
- Home Theater
- Identity Matters
- iGeneration
- India IT
- Irregular Enterprise
- IT Project Failures
- Laptops & Desktops
- Linux and Open Source
- London Calling
- The Mobile Gadgeteer
- Mobile News
- Networking
- Pulp Tech
- Reference Desk
- SEO Whistleblower
- Service Oriented
- Small Business Matters
- Smartphones and Cell Phones
- Social Business
- Social CRM: The Conversation
- Software & Services Safari
- Software as Services
- Storage Bits
- Tech Broiler
- Tom Foremski: IMHO
- The ToyBox
- View from China
- Virtually Speaking
- ZDNet Education
- ZDNet Government
- ZDNet Health
- Zero Day
Blog Archive
White Papers, Webcasts, & Resources
-
Office 365 Migration Guide: Approaches, Techniques and ChallengesNo Headache, No Hassles Microsoft 365 Migration
Your company is ... (Quest Software)Download Now - Seven Keys to Success in Managing Your Business-Critical CloudNeed a few tips on how to manage your cloud infrastructure? Here are seven ... (Hewlett-Packard (HP))Download Now
- The Best Ways to Migrate Lotus Notes Applications to SharePoint and Office 365Migrating Notes to SharePoint Online/Microsoft Office ... (Quest Software)Download Now
