Its configuration is unusually complex for a webserver. I wouldn't be surprised if many of its so-called "security holes" actually came about because of misconfiguration by an administrator who was confused by the layout of the documentation or config files.
In a way, Internet Information Services provides a more secure environment because an administrator gets a wealth of help and a decent initial configuration. In the end it's all about knowing your product, but it helps if the product helps you.
It could be better (chroot), but the conf files are clean and easy to work with. Also, it's nice to be able to get up to date by simply typing 'emerge sync && emerge apache'.
Sorry but IIS has more critical exploits in any given month than Apache has all YEAR! Why do you think Apache owns 70% of the web? Microsoft made a push in 2001 but could only get as high as 35%... at which point it tanked back to it's previous high of about 22%
apache might own 70% of individual, personal web sites, since they are free.
PC domains like marketwatch.com which handles hundreds of millions of hits every day is behind a router of a PC farm of IIS, which those "survey" doesnot account for.
Yep and I can still name 7 for every one of yours. How about Microsoft huh? Everytime a DDOS attack comes, gues who they duck and cover behind? LINUX and APACHE!!!:)
Do a check on Netcraft for *.microsoft.com sometimes and check the first couple hundred servers for what they are running. If IIS is so damn good, how come Microsoft is always duck and covering behind open source?:)
Here you go... check out all those url's ending in Microsoft and then check what they are running:)
Linux on all of them:)
If that's not what you meant and you just want to see a Windows machine running Apache, they are all over the place. Check out www.proclub.com for starters; they're Microsofts health club and they run Apache.
Yes. LOAD distribution. Notice they don't rely on Windiows servers for that. Why not Windows Servers? Because they can't handle the load. Same thing with DDOS attacks and the like... they keep falling back onto Linux.:)
MS used/use Akamai to reduce the impact of any attempted DDOSs. I'm sure you can imagine how many people are regularly trying to attack MS. MS's own servers are all running IIS, which is hardly surprising, its merely their outsourced caching that use Apache, and MS won't have much control over what their outsourcers choose to do. If MS started throwing its weight around when trying to get caching services I'm sure doors would just slam in their faces, rather than co-operate. Regarding the 'duck and cover
Actually, Microsoft has the money to EASILY handle this themselves. But their OS can't handle it. So what does Microsoft do? Spend money on a bunch of Linux machines themselves (which would REALLY look bad) or pay an outside company to do it? Ding ding! You guessed right!
The fact remains that Microsoft could NOT do this with their own OS. If they could, they would have by now.
Horseshit, troll. Plenty of other sites use Akamai for CONTENT distribution to save bandwidth at their main sites. Have a look at Akamai's customer list sometime, especially take note of Yahoo!, which runs on some form of Unix.
The fact remains that Microsoft could NOT do this with their own OS. If they could, they would have by now.
That is, even by/. standards a rather specious anti-MS argument. Just because you can afford to do something doesn't mean you necessrily should, nor does it mean it makes economical sense. Why would Microsoft want to fork out money on a whole series of servers (and associated maintenance / upgrade costs), based in several different geographical locations, pay for employment and training costs of
Well considering how last time this happened and it was in all the papers saying that Microsoft was running Linux, they tend not to like that sort of thing... I should know, I'm a webdeveloper for a vendor for Microsoft whose offices are right across the street from them in Redmond.
They switched all their hotmail servers off Linux, they switched all others istes off BSD. They want everything Microsoft running on Microsoft products; it's their motto: eat your own dogfood.
If you weren't so obsessed with being right, you'd notice that you're dead wrong.
They don't get to pick which OS the company they hired to host their sites uses. If they tried to FORCE them to use a microsoft product, they would get doors slammed in their faces.
Your logic (if that's what you call it) can be applied to yourself in the wrong dept.
Microsoft researchs it's companies well, especially companies that supply it with tech services. The company that they are reselling web hosting through uses only Windows and IIS; it's PART OF THEIR CONTRACT! A contract is a piece of paper that is legally binding in a court of law. You still with me?
They do this with ALL vendors who supply Microsoft with technical services.... ALL VENDORS! Lots of people are willing to su
You need to realize something: Microsoft is a company. Companies do things to make money.
They picked this media hosting service because of their record.
If Microsoft asked them to change how they did their hosting, the hosting company would have to purchase new hardware and software. They would have to hire or train people on how to use it.
This would take too much time.
Microsoft went with them because they needed a QUICK solution to a fast approaching problem.
I'd stop wasting your time if I were you. He's a died in the wool Slashdot educated MS hater. (for the record, I don't like MS) There can be no circumstances underwhich MS can possibly be defended, they should all burn and die a horrible death, along with anyone that happens to even remotely defend them etc.. etc.. etc..
I see evolution has left you behind. How sad. When you learn what your brain is for, you may realize that Microsoft is about making money... EVENTUALLY!X-box, Microsoft games, CRM, they are all in the red still. Oh you thought red ink was for profits? Come down from the tree sometime monkeyboy, I have a few trciks to show you.
As for it taking too much time, wouldn't creating a new gaming platform take too much time, wouldn't cvreating web TV take too much time? I can go on and on about how your logic fails
Having recently left a fairly major ISP in my country, I feel obligated to correct both the Microsoft bashers and the Microsoft sympathizers on some of the key points.
The thing is this: Microsoft Servers are Win2k3/IIS (for the most part. There may be some left on Win2k).
In part it has to do with bandwidth distribution, particularly when dealing with international downloads.
What happens when a million users (conservative estimate) go to download a 170MB file, such as Service Pack 2 (redist) all at once? R
Sorry but IIS has more critical exploits in any given month than Apache has all YEAR!
Could I ask you to list all of these vulnerabilities for IIS? Secunia only returned eight vulnerabilites (I searched on "IIS vulnerabilities") and four of those don't appear to be issue with IIS itself. The other four don't appear to affect Microsoft's latest version (6.0). A search on "apache vulnerabilities" returned 63 alerts. I'm not going to search through all 63 alerts but on the surface it appears that Apache has
An ALERT is not the same thing as a CRITICAL EXPLOIT... duh! Check my wording more carefully next time. If you think an alert is the same thing as a CRITICAL EXPLOIT, then Microsoft has a huge jumpstart on EVERYONE!
Yeah... nice try. Using your logic, 500 traffic tickets for Linux would be equivalent to 50 murders by Windows.
Also try to keep in mind that Microsoft is OFTEN told of these exploits 6 months to a year in advance and they STILL remain out in the wild until someone actually builds the tool to take advantage of the exploit. At which point millions of machines must first suffer before they will take care of the problem.
If there were a prize for talking out your ass, you'd win a blue ribbon, baby.
And just to make sure your mouth stays shut and you start redirected your shit out of it's regular hole, how about a nice long list of exploits (with actual show of code used to make said exploit work)
Wow. Windows sure looks secure to me... NOT! Surf around, you can use those code samples all day long exploiting Windows machines. Now how about you give me a sample that is current and
Bzzzzt! Wrong...
How many exploits have been found for IIS 6 in the year + it has been available? That would be 0. IIS 5 is a just plain bad application, but IIS 6 has been rock solid so far.
Why is it you FOSS mouthpieces ignore this fact when spouting off your party line?
In "Apache: The Definitive Guide", Ben and Peter Laurie suggest a way to learn how to build an Apache config file - start with a blank file, and start Apache. Oops, it won't start. OK, so what's it missing? Check the log files. It needs a User directive - OK, add that. Try to start. Hm, it started, but where do I put my HTML? Ah, add a DocumentRoot. And so forth.
This really doesn't take as long as it sounds - and after about 10 minutes of adding directives and restarting Apache, you'll have a lean configuration file that has just what you need in it - and you'll know how you got there, where the error logs are, and so on.
you'll also have a gimpy, crapped-up config file that other admins have to wade through after you get fired.
the best thing about the pre-built apache config files is the degree to which they are self-documenting. you can learn everything you need to know about apache just by reading through the comments. the second-best thing about them is that they're the same on all of your servers. the third best thing about them is that you don't have to read through a bunch of documentation to find out-of-date and non-working examples of config stanzas, because they're already there, commented out and waiting for some s/ action.
Hm. I find smaller configuration files to have both a lower gimp quotient and a reduced crapification level.
> they are self-documenting.
True, although there's a ton of stuff in there most folks won't use - content negotiation and such-like.
> they're the same on all of your servers
Hm. Most of my servers have different config files - different vhost names, different modules, etc. Perhaps if they were all fronting one application that might be different...
This guy should get more + moderation! That method is one of the best ways to keep your apache configs sane, especially if you've got a whole bunch of servers that aren't part of a cluster or whatever (i.e. identical configs for all).
We actually take it a step further and do "Include conf.d/" from the httpd.conf, where conf.d is a subdirectory with configuration "containers" that are automatically included on startup/reload. That way we just drop individual vhost co
Yeah but if only editors (vi or emacs in my case) had a 'fold away the comments' mode; in many cases in order to find whats actually configured, its easier to just;
grep -v "^#\|^$"/etc/apache/httpd.conf
so that I can see the woods through the trees so to speak.
you'll also have a gimpy, crapped-up config file that other admins have to wade through after you get fired.
A small, custom config file takes much less wading than the default! A method I've found works wonders when I inherit an Apache server is to strip out all the comments with something like
perl -ni.old -e 'print unless/^#/' apache.conf
Suddenly, like magic, you have a config file that you can see what it does. You then have a headstart on removing cruft, bugs, obsolete and redundant stuff.
That's a good suggestion. Once you get the barebones config the way you want, save it and use it for every server you deploy (with the necessary modifications/additions, of course).
I spent about 3 hours years ago making my Apache config, and I haven't had to do it again. I have a second one I made last year for Apache 2, and I expect it to last me just as long.
That's a really good idea. I've got to do that at some point.
Actually, that'd be a really good way to approach any complex piece of software: BIND, MySQL, SSH...sure, a lot of it would depend on how good the logging is, but boy, would you ever learn it from the ground up.
>In "Apache: The Definitive Guide", Ben and Peter Laurie suggest a way to learn how to build an Apache config file - start with a blank file, and start Apache.
I'm not a sysadmin or worked with Apache, but doesn't this sound a bit crude to figure out a configuration of a system?
Its like going through the Apache source code to see what strings in the config file they are looking for.
Of course, you could reinterpret "start with a blank file" to mean "Add a '#' to the start of every line in the sample httpd.conf file". That would give you a "blank" file, but with all the documentation and examples very easily available.
The point is that if you write your config file by hand, then you HAVE TO know each directive (well, sort of). That's part of the reason why I wrote the first chapter that way...
That won't do me much good on a production server that I'm trying to harden. Clearly I can't do that live. I don't know how much time it would take me to produce something that I could migrate to a live system without having nightmares about downtime using this methodology.
Don't get me wrong - the idea is fabulous if you're learning or starting on a new system.
In "Apache: The Definitive Guide", Ben and Peter Laurie suggest a way to learn how to build an Apache config file - start with a blank file, and start Apache. Oops, it won't start. OK, so what's it missing? Check the log files. It needs a User directive - OK, add that. Try to start. Hm, it started, but where do I put my HTML? Ah, add a DocumentRoot. And so forth.
No, its not add that. Its copy that and the associated comment from the original stock config file apache provides. Now your lean config file is documented, looks just like apache's and won't confuse your successor. I generally do this with any new daemon I install that requires a config file. Note that from a security standpoint this may not be good enough if the daemon's secure options are turned off by default since you may not see any warnings in the logs.
In "Apache: The Definitive Guide", Ben and Peter Laurie suggest a way to learn how to build an Apache config file - start with a blank file, and start Apache. Oops, it won't start. OK, so what's it missing? Check the log files. It needs a User directive - OK, add that. Try to start. Hm, it started, but where do I put my HTML? Ah, add a DocumentRoot. And so forth.
That is a good start, but also make sure you start from a completely blank file tree, delete all the default cgi scripts etc. A lot of exploits
When I've used Apache2, it's configuration setup seems a lot more organized and structured. It's still text files, but they make more sense and they are modularized better.
Granted, that's just the in the distribution, not the server version... but at least it shows it's getting better at that. Now if only more people used Apache2, things would just fix themselves;-) -N
Its configuration is unusually complex for a webserver.
Really? I never found it all that hard. Most of the complex stuff is inserted in the default file, but is not insecure in of itself. You just have to think about everything you do after that.
I wouldn't be surprised if many of its so-called "security holes" actually came about because of misconfiguration by an administrator who was confused by the layout of the documentation or config files.
In my experience, most Apache security issues are related to giving access to files that shouldn't be on the web. Doing things like symlinking directories is very powerful, but it's also very dangerous. Also keep in mind that if an attacker can upload a script, he already has access to your system. These sorts of problems (as well as undiscovered buffer overflow issues) can be mitigated by the use of Jails. When you jail Apache, you ensure that any attacker that does gain access, will only have access to Apache files.
A typical Apache security problem would be something like an FTP server that has an anonymous account with access to a web-sharable directory. An attacker uploads a PHP script to the web-share, and it's game over for your machine/network.
Its configuration is unusually complex for a webserver.
Have you tried to configure netscape's webserver, or its successors from Sun/iPlanet? That is what I consider "unusually complex" in configuration for a webserver.
The money invested in a product that bundles
Apache is well spent ie: SUSE pro
I haven't seen many breaches of the
out of the box - patched SUSE machines.
There's definitely room for misadventure
on a manual install....
Interesting that you mention this, since the reason there are so damn many compromised IIS boxes out there is directly related to it's being too easy. And here you are talking about "apache security holes" as if it were anywhere near the problem of all those auto-hacked IIS boxes.
"It is easier to fight for principles than to live up to them."
-- Alfred Adler
One of the unfortunate things about Apache... (Score:4, Insightful)
In a way, Internet Information Services provides a more secure environment because an administrator gets a wealth of help and a decent initial configuration. In the end it's all about knowing your product, but it helps if the product helps you.
Re:One of the unfortunate things about Apache... (Score:1)
Gentoo (Score:1)
Re:One of the unfortunate things about Apache... (Score:3, Interesting)
Re:One of the unfortunate things about Apache... (Score:2)
the default config in 2k3 is very pessimistic. can't say that i've had one of those work since the orginal code red.
Re:One of the unfortunate things about Apache... (Score:5, Informative)
Re:One of the unfortunate things about Apache... (Score:1)
PC domains like marketwatch.com which handles hundreds of millions of hits every day is behind a router of a PC farm of IIS, which those "survey" doesnot account for.
Re:One of the unfortunate things about Apache... (Score:4, Interesting)
Do a check on Netcraft for *.microsoft.com sometimes and check the first couple hundred servers for what they are running. If IIS is so damn good, how come Microsoft is always duck and covering behind open source?
Re:One of the unfortunate things about Apache... (Score:1)
Re:One of the unfortunate things about Apache... (Score:2)
Linux on all of them
If that's not what you meant and you just want to see a Windows machine running Apache, they are all over the place. Check out www.proclub.com for starters; they're Microsofts health club and they run Apache.
Re:One of the unfortunate things about Apache... (Score:3, Interesting)
Those results are skewed because of Akamai (Score:2)
Non-authoritative answer:
Name: a1076.g.akamai.net
Addresses: 199.44.34.70, 199.44.34.68
Aliases: autoupdate.microsoft.com, codecs.microsoft.com
codecs.windowsmedia.com.akadns.net, codecs.windowsmedia.com.edgesuite.net
MS uses Akamai for distribution, Akamai runs Linux. Side note, thank $_DEITY that MS does not use Connexion any more. Holy dog crap they were SLOW!
Re:Those results are skewed because of Akamai (Score:2)
Re:Those results are skewed because of Akamai (Score:1)
MS used/use Akamai to reduce the impact of any attempted DDOSs. I'm sure you can imagine how many people are regularly trying to attack MS. MS's own servers are all running IIS, which is hardly surprising, its merely their outsourced caching that use Apache, and MS won't have much control over what their outsourcers choose to do. If MS started throwing its weight around when trying to get caching services I'm sure doors would just slam in their faces, rather than co-operate. Regarding the 'duck and cover
Re:Those results are skewed because of Akamai (Score:1)
Re:Those results are skewed because of Akamai (Score:2)
The fact remains that Microsoft could NOT do this with their own OS. If they could, they would have by now.
Re:Those results are skewed because of Akamai (Score:2)
Re:Those results are skewed because of Akamai (Score:1)
The fact remains that Microsoft could NOT do this with their own OS. If they could, they would have by now.
That is, even by /. standards a rather specious anti-MS argument. Just because you can afford to do something doesn't mean you necessrily should, nor does it mean it makes economical sense. Why would Microsoft want to fork out money on a whole series of servers (and associated maintenance / upgrade costs), based in several different geographical locations, pay for employment and training costs of
Re:Those results are skewed because of Akamai (Score:2)
They switched all their hotmail servers off Linux, they switched all others istes off BSD. They want everything Microsoft running on Microsoft products; it's their motto: eat your own dogfood.
So why is their load distribution b
Re:Those results are skewed because of Akamai (Score:2)
They don't get to pick which OS the company they hired to host their sites uses. If they tried to FORCE them to use a microsoft product, they would get doors slammed in their faces.
Re:Those results are skewed because of Akamai (Score:2)
Microsoft researchs it's companies well, especially companies that supply it with tech services. The company that they are reselling web hosting through uses only Windows and IIS; it's PART OF THEIR CONTRACT! A contract is a piece of paper that is legally binding in a court of law. You still with me?
They do this with ALL vendors who supply Microsoft with technical services.... ALL VENDORS! Lots of people are willing to su
Re:Those results are skewed because of Akamai (Score:2)
They picked this media hosting service because of their record.
If Microsoft asked them to change how they did their hosting, the hosting company would have to purchase new hardware and software. They would have to hire or train people on how to use it.
This would take too much time.
Microsoft went with them because they needed a QUICK solution to a fast approaching problem.
Jesus Hell, man. You need to stop being
Re:Those results are skewed because of Akamai (Score:1)
Re:Those results are skewed because of Akamai (Score:2)
As for it taking too much time, wouldn't creating a new gaming platform take too much time, wouldn't cvreating web TV take too much time? I can go on and on about how your logic fails
Re:Those results are skewed because of Akamai (Score:1)
Re:One of the unfortunate things about Apache... (Score:1)
Akamai partnerships. (Score:1)
The thing is this:
Microsoft Servers are Win2k3/IIS (for the most part. There may be some left on Win2k).
In part it has to do with bandwidth distribution, particularly when dealing with international downloads.
What happens when a million users (conservative estimate) go to download a 170MB file, such as Service Pack 2 (redist) all at once? R
Re:One of the unfortunate things about Apache... (Score:1, Insightful)
Sorry but IIS has more critical exploits in any given month than Apache has all YEAR!
Could I ask you to list all of these vulnerabilities for IIS? Secunia only returned eight vulnerabilites (I searched on "IIS vulnerabilities") and four of those don't appear to be issue with IIS itself. The other four don't appear to affect Microsoft's latest version (6.0). A search on "apache vulnerabilities" returned 63 alerts. I'm not going to search through all 63 alerts but on the surface it appears that Apache has
Re:One of the unfortunate things about Apache... (Score:2)
Re:One of the unfortunate things about Apache... (Score:2)
Also try to keep in mind that Microsoft is OFTEN told of these exploits 6 months to a year in advance and they STILL remain out in the wild until someone actually builds the tool to take advantage of the exploit. At which point millions of machines must first suffer before they will take care of the problem.
If there were a prize for talking out your ass, you'd win a blue ribbon, baby.
Re:One of the unfortunate things about Apache... (Score:2)
http://www.malware.com/
http://www.malware.com / index2.html
http://www.safecenter.net/UMBRELLAWEB V4/ie_unpatch ed/index.html
Wow. Windows sure looks secure to me... NOT! Surf around, you can use those code samples all day long exploiting Windows machines. Now how about you give me a sample that is current and
Re:One of the unfortunate things about Apache... (Score:2, Insightful)
Sorry (Score:2)
Re:One of the unfortunate things about Apache... (Score:5, Informative)
In "Apache: The Definitive Guide", Ben and Peter Laurie suggest a way to learn how to build an Apache config file - start with a blank file, and start Apache. Oops, it won't start. OK, so what's it missing? Check the log files. It needs a User directive - OK, add that. Try to start. Hm, it started, but where do I put my HTML? Ah, add a DocumentRoot. And so forth.
This really doesn't take as long as it sounds - and after about 10 minutes of adding directives and restarting Apache, you'll have a lean configuration file that has just what you need in it - and you'll know how you got there, where the error logs are, and so on.
Re:One of the unfortunate things about Apache... (Score:5, Insightful)
the best thing about the pre-built apache config files is the degree to which they are self-documenting. you can learn everything you need to know about apache just by reading through the comments. the second-best thing about them is that they're the same on all of your servers. the third best thing about them is that you don't have to read through a bunch of documentation to find out-of-date and non-working examples of config stanzas, because they're already there, commented out and waiting for some s/ action.
Re:One of the unfortunate things about Apache... (Score:5, Insightful)
Hm. I find smaller configuration files to have both a lower gimp quotient and a reduced crapification level.
> they are self-documenting.
True, although there's a ton of stuff in there most folks won't use - content negotiation and such-like.
> they're the same on all of your servers
Hm. Most of my servers have different config files - different vhost names, different modules, etc. Perhaps if they were all fronting one application that might be different...
Re:One of the unfortunate things about Apache... (Score:3, Informative)
Re:One of the unfortunate things about Apache... (Score:3, Interesting)
This guy should get more + moderation! That method is one of the best ways to keep your apache configs sane, especially if you've got a whole bunch of servers that aren't part of a cluster or whatever (i.e. identical configs for all).
We actually take it a step further and do "Include conf.d/" from the httpd.conf, where conf.d is a subdirectory with configuration "containers" that are automatically included on startup/reload. That way we just drop individual vhost co
Re:One of the unfortunate things about Apache... (Score:2)
C'mon, surely you know the difference between "learning exercise" and "what I leave behind for my successors"!
Re:One of the unfortunate things about Apache... (Score:2)
grep -v "^#\|^$"
so that I can see the woods through the trees so to speak.
Comments arn't always good.
Re:One of the unfortunate things about Apache... (Score:1)
A small, custom config file takes much less wading than the default! A method I've found works wonders when I inherit an Apache server is to strip out all the comments with something like
/^#/' apache.conf
perl -ni.old -e 'print unless
Suddenly, like magic, you have a config file that you can see what it does. You then have a headstart on removing cruft, bugs, obsolete and redundant stuff.
Finall
Re:One of the unfortunate things about Apache... (Score:2)
I spent about 3 hours years ago making my Apache config, and I haven't had to do it again. I have a second one I made last year for Apache 2, and I expect it to last me just as long.
Re:One of the unfortunate things about Apache... (Score:1)
Actually, that'd be a really good way to approach any complex piece of software: BIND, MySQL, SSH...sure, a lot of it would depend on how good the logging is, but boy, would you ever learn it from the ground up.
Re:One of the unfortunate things about Apache... (Score:2, Insightful)
> the ground up
Right on. And you'd know what all the funky error messages look like, too, which is nice...
Re:One of the unfortunate things about Apache... (Score:2)
I'm not a sysadmin or worked with Apache, but doesn't this sound a bit crude to figure out a configuration of a system?
Its like going through the Apache source code to see what strings in the config file they are looking for.
Re:One of the unfortunate things about Apache... (Score:5, Insightful)
Re:One of the unfortunate things about Apache... (Score:5, Interesting)
The point is that if you write your config file by hand, then you HAVE TO know each directive (well, sort of).
That's part of the reason why I wrote the first chapter that way...
Merc.
(The book's author)
Re:One of the unfortunate things about Apache... (Score:1)
Re:One of the unfortunate things about Apache... (Score:5, Insightful)
No, its not add that. Its copy that and the associated comment from the original stock config file apache provides. Now your lean config file is documented, looks just like apache's and won't confuse your successor. I generally do this with any new daemon I install that requires a config file. Note that from a security standpoint this may not be good enough if the daemon's secure options are turned off by default since you may not see any warnings in the logs.
Re:One of the unfortunate things about Apache... (Score:2)
Why doesn't Apache just ship a leaner default config file?
Re:One of the unfortunate things about Apache... (Score:2)
That is a good start, but also make sure you start from a completely blank file tree, delete all the default cgi scripts etc. A lot of exploits
Re:One of the unfortunate things about Apache... (Score:5, Interesting)
Granted, that's just the in the distribution, not the server version... but at least it shows it's getting better at that. Now if only more people used Apache2, things would just fix themselves
-N
Re:One of the unfortunate things about Apache... (Score:5, Informative)
Really? I never found it all that hard. Most of the complex stuff is inserted in the default file, but is not insecure in of itself. You just have to think about everything you do after that.
I wouldn't be surprised if many of its so-called "security holes" actually came about because of misconfiguration by an administrator who was confused by the layout of the documentation or config files.
In my experience, most Apache security issues are related to giving access to files that shouldn't be on the web. Doing things like symlinking directories is very powerful, but it's also very dangerous. Also keep in mind that if an attacker can upload a script, he already has access to your system. These sorts of problems (as well as undiscovered buffer overflow issues) can be mitigated by the use of Jails. When you jail Apache, you ensure that any attacker that does gain access, will only have access to Apache files.
A typical Apache security problem would be something like an FTP server that has an anonymous account with access to a web-sharable directory. An attacker uploads a PHP script to the web-share, and it's game over for your machine/network.
Re:One of the unfortunate things about Apache... (Score:1)
Have you tried to configure netscape's webserver, or its successors from Sun/iPlanet? That is what I consider "unusually complex" in configuration for a webserver.
Re:One of the unfortunate things about Apache... (Score:1)
Re:One of the unfortunate things about Apache... (Score:2)