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.
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%
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?
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.
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!
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.
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.
>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...
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.
by Anonymous Coward writes:
on Wednesday September 01, 2004 @03:29PM (#10131507)
If security is not a concern, installing the Apache web server is a simple task even for an inexperienced system administrator
Yet I still preffer IIS, according to research, it's more easy to install, and up to 70% more secure; according to research that is.
and it's not that they haven't tried feeding the patches back, either. the ASF is being utterly retarded about accepting them. more [google.com] and more [google.com]
That whole thread on "no more apache updates [theaimsgroup.com]" had nothing to do with security. It had everything to do with the OpenBSD team deciding not to keep using Apache HTTPD because of the new ASL 2.0 license. Personally I think the OpenBSD team is completely wrong on this issue and their attitude is incredibly offensive. Moreover, if you read the whole thread you'd find this response [theaimsgroup.com] that the apache group has been responsive to the patches but that many of them are BSD specific and that's why they were not pu
Don't let not knowing about security hold you back from hosting your own site. Experiment, learn, have fun. Put an apache box up on a DMZ, put stupid content on it, see what happens. Look at your logs, see what's going on, learn from any mistakes you make along the way.
If you're in this industry, and are afraid to be the "fall guy" who has do deal with the inevitable attacks, or the "fall guy" in general, you'd better fasten your seat belt...you're in for a bumpy ride.
Roflmao I did that once -> used apache as a reverse proxy. I love the simplicity of it, and the increased security. You can block a tonne of attacks using mod_security, and keep them from hitting your real web server.
Thing is, I forgot to lock down the allowable hosts.
Soon, I was seeing scripting engines requesting ads from various web servers in my logs. Took over a year for those scripts to stop.
Didn't take long for me to find it, but once you're on an open proxy list.... You're screwed.
Basic security is not difficult. If you know the rule of "If you don't need it, turn it off," you know everything you need to about basic security. Hackers, like just about all criminals, go for the path of least resistance. If you take basic precautions, you'll defend yourself against everyone who isn't out to get you personally.
In short, find a hosting company with a lot of Windows servers nearby IP-wise. This is, sadly, not a troll or flamebait, it's my experience. Apache is not what you have to w
Heh. I plan to serve my own site to gain the experience of log-reading, config-file twitching, and all that; I want to break into the Web field, and see this as a good opportunity to learn about webserver/OS hardening by fire, as well as being just plain fun:)
I'll also ask a buddy of mine who's a security consultant to attack the server. Better to have a friend attack and tell me my mistakes than some pimply-faced kid 0wneR my machine.
Picked up Maximum Apache Security at Apache-Con last year and it has proven very useful. But any Apache administrator worth his salt knows most of this already. I don't see why you say it's fragmented and hard to find.
The creators of Apache Server came up with the name due to it being based on a series of patches for httpd. "A Patchy Server." Get it? The name itself suggests its fragmented beginnings.
Um... your point? What beginning project DIDN'T start out fragmented and crapped? Are you saying the first version of Windows was polished? Are you saying IIS was perfect from the start?
Compare the final product... I think you'll see why Apache has and always will have the dominant market share.
Actually I can think of plenty of projects that haven't started out fragmented. Both open and closed source. Projects that aren't meant to be add-on fixes typically start out with some sort of focus. My reply was more of a tongue-in-cheek take and wasn't meant to be an IT directive. Geez, touchy, touchy...
Stronghold began as a commerial SSL-enabled version of Apache, when zero-cost SSL modules were non-existant and/or crappy. At some point RH bought out Stronghold-Inc. Im supprised that RedHat still supports Stronghold at all, frankly. It is unclear if the latest version is still a sepearate product, or comes with RHEL 3 only. Beh.
I wish web servers wouldn't advertise their version number be default (e.g. in directory listings or HTTP headers). It's like giving an attacker an exact list of the exploits that will work on your server.
You can turn this off when you compile apache, it's just a matter of editting a.h file, I believe, and putting in whatever you want. You could, for instance, create a "Joe Schmoe's webserver version 11000!" or something of that ilk.
However, when it comes to exploits that deal with knowing version numbers, most of it is script kiddy stuff, so it's [ the script ] is going ot just run default exploit attempts against the webserver regardless of what is returned about the webserver.
Might help a little bit. As I saw so eloquently stated somewhere...
This would not stop skilled bad guys, but would slow down those kiddies playing around.
Should this perhaps be the default? Maybe. But the bottom line is, you don't have the right to put a machine online without knowing about the details.
This would not stop skilled bad guys, but would slow down those kiddies playing around.
Not in the least. My logs show tons of IIS and ancient Apache exploit attempts. Kiddies just mindlessly launch every exploit they know against any server they can find and hope to get lucky.
There is a fundamental flaw with security hardening being in a separate book, sold by advertising and word of mouth, read separately and in a different medium than installation documentation, updated asynchronously, and expected to work. Would you accept a word processor with a separate book on "Master's Secrets on Keeping Your Word Processor From Crashing"?
With any luck, many hardening techniques will migrate towards the Apache installation process, or at least the Apache documentation.
Simple. Dip it in tree resin and let it fossilize. It should harden into amber in . . . oh, a few million years or so. Don't be impatient, though, or all you'll get is copal.
I do most of my work on a Domino server (say what you will, but its very secure and stable and I build customer apps really inexpensively) but Apache based servers (and they are myriad) keep intruding into my happy little world.
A year ago I wanted to put one public but found information on hardening it extremely limited -- or perhaps extremely disconnected.
Apache is extremely complicated and therefore a potentail rats nest of potential security holes. Please don't get me wrong here: I like Apache very much for its great flexibility, yet I helped a lot of security aware companies to migrate to thttpd [acme.com] because they wanted a code base that could be scrutinized in a reasonable amount of time. Most web apps really don't need the flexibility of Apache anyway, and those who do, will have to be run in secure environments like, say, jails [freebsd.org] or other virtualized environme
Apache is nice, and Apache is popular, but the simple fact that it's popular means that it attracts attention. If you don't need a module that's specifically for Apache, you can use a different webserver package (take a look at Freshmeat, there's a bunch) and you gain some security through obscurity.
Now, you still have to learn how to set up that package right, and keep up on updates, but diversity is a nice thing. Even if you just move some files (e.g. static content like images) off onto a side server, there's less to secure on the Apache box, so it's usually simpler.
There is one thing that makes apache very unsecure. Suppose that you have few users each having it's own virtual host. Apache is running from exactly the same UID/GID for each virtual host! There is no way in pure apache to prevent user A from looking into user B vhost files (containing for example php scripts, password to sql databases etc).
You would need to run multiple apaches running from different UIDs for each user:/
That's bad. suexec it's not a option - it doesn't work with mod_python and other apache modules.
perchild MPM module that should do it doesn't work and apache developers are not interested in fixing that. No idea why.
metuxmpm MPM module was written instead perchild by external developers but it also doesn't work well unfortunately (for me it doesn't work at all).
Gee - you get this massive file to edit to get Apache up and running which is fine for some of geeky land (like the slash-dot crowd) but it creates a hurdle for your basic person who wants to have a running web site.
So why not create a smart program to generate the config file either as a script or as a GUI application that will have enough smarts to get your normal site up and running but with the possible security holes turned OFF and massive warnings written into the file so that when someone goes to ed
That, of course, isn't the point. The point being that if a program can provide the smarts to create the file, or check the file, for security then it might be a more secure way to do things. It's a dealing with complexity issue.
Of course it does... it couldn't bind to port 80 if it didn't start up as root. You are correct that it is the children that run with decreased privileges.
If somebody has gotten enough access to your box to add an arbitrary module to your httpd config, you're in pretty big trouble anyhow...
I have ping disabled on our system for machines outside of my subnet. It is something I don't need. It might be something someone else needs, but I don't care.
#ICMP traffic
einfo "Creating icmp chain"
$IPTABLES -N icmp_allowed
$IPTABLES -F icmp_allowed
$IPTABLES -A icmp_allowed -p icmp -s $NETWORK -j ACCEPT
$IPTABLES -A icmp_allowed -p icmp -s 127.0.0.1 -j ACCEPT
$IPTABLES -A icmp_allowed -m state --state ESTABLISHED,RELATED -p icmp --icmp-type echo-reply -j ACCEPT
$IPTABLES -A icmp_allowe
I actually like ping, I leave it on since my cablemodem isn't all that reliable and it's a nice easy way to check if it's up when I'm at work. If port 23456 stops responding, I can ping to see if it's just the application or the connection.
I also use it as a monitor from another location so I can redirect certian traffic if it stops responding.
Sure, I could go firewall nazi and only allow ping from certain locations, but hell, it's only ping.
Not to say you MUST use it, but I find nothing particularly e
I designed the backend of www.babiesfirstchoice.com and we used apache 2. Its been hugely stable for us (the downtime we've seen was not due to apache problems) and lets us do everything we need to do on it. An IIS box would of cost thousands more due to licensing and the extra hardware needed to push M$ solutions (BFC currently runs on a athlon 1700xp with 512 megs of ddr and a basic ide hard drive, nothing fancy).
I started using solely linux around 4 years ago. One of the first things I did was install apache and play around with that. I got it working with a little effort. After that I always built it from scratch. I eventually decided to try using apache out of the portage tree and it was set up as soon as I ran emerge and setup the configs in/etc/conf.d I've been using the gentoo build ever since then.
Anyways I had to develop some webapp and my boss wante
Similar to the anecdotes that I like to tell. I've been on a number of projects where the official decree was to use web server Brand X (where X is any of the Usual Suspects). After some weeks of futzing around trying to get it working sanely, I'd decide that I'd had enough of it. So I'd set aside a half hour to grab the latest apache, compile it, config it, fire it up, and link all our stufff into its htdocs directory. This never took the full half hour, and invariably it worked like a charm, never cra
There seemed to be little in the way of practical material that gave specific and step-by-step instructions for installing and running Apache on Linux.
Maybe you missed the "documentation" section at the apache.org website? Or, do a google search for "linux apache howto". Tons of good stuff out there.
Apache on Linux requires you to spend 8 hours per day just to keep it up and running,
On what planet is this true? There's about 4 things to change from one webserver to another; you build one config file for your environment, and for the next one modify the listen, the user if you want, the document_root, and maybe servlet mapping if you're using that. Trivial and one-time.
and while its performance and security is fine if you have the time and staff for it, there is no way to just set it up and let it sit while installing patches when needed.
Our experience differs profoundly. Perhaps someone like you needs to hire someone like me to help you get set up. It's a trivial setup, configuration is well documented, and once it's up and running a webserver doesn't need any attention whatsoever until the next version comes out or you decide you want to change what it does.
Arguing against Apache on actual factual grounds would be one thing, but "it's hard to set up and lots of work to keep running" is demonstrably false.
I'm wondering where you got that '8 hours per day' maintenance idea. Seriously, do you adjust your configuration for 8 hours a day, 5 days a week, year round, or what? What exactly requires your interaction with the system, once it's been set up? Occasional patching does not take 8 hours per day, every day. Ohh, and you do know that on unix you can remove a binary of a program that's running, put a new one in, and do a quick kill/start? Almost no downtime in that case, and there are tons of other ways to do
Ohh, and you do know that on unix you can remove a binary of a program that's running, put a new one in, and do a quick kill/start?
Actually, for most of the configuration changes (short of an actual version upgrade or SSL cert change), you can do an 'apachectl graceful' and it applies your changes to the _new_ sessions, while letting the existing sessions close in the natural flow of the users' use of your site. Nice for minor tweaks on the fly during the day, with zero downtime.
Definitely, apachectl graceful is very useful. I was only talking about apache upgrades. By the way, if you add more ssl vhosts, you also have to do restart rather than graceful.
Sigh, there are several ways to approach setting up an Apache server. All of them are easy.
First one is to start with an empty configuration file and then cut and past in portions of the standard file until you get a minimally working server.
The good part about this approach is that you get the least amount of bells and whistles added. Security via a small footprint is a good thing. The bad part about this approach is that you end up with a minimal server that may need more tweaking to get everythin
You are fucking stupid because you are willing to live with shitty software that requires an expert to make "secure". The consequence of that sort of design is that Apache will get the same reputation for lack of security as Microsoft, and for the same reason.
Dude! Shut the fuck up! I need to get a job when I'm out of college... if apache is 'secure by default' then what is stopping the janitor at my old high school from becoming an admin!
The more mysterious we keep the silicon, the more I get paid!
(
"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: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:2, Insightful)
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: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:One of the unfortunate things about Apache... (Score:2)
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: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: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: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: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: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.
secure (Score:4, Funny)
Don't forget (Score:4, Informative)
Umm. (Score:5, Interesting)
OpenBSD's [openbsd.org] Apache has a diff of 3 or 4 thousand lines over "stock" Apache. Why not just use that?
Re:Umm. (Score:5, Interesting)
and it's not that they haven't tried feeding the patches back, either. the ASF is being utterly retarded about accepting them. more [google.com] and more [google.com]
it's specific to OpenBSD (Score:3, Informative)
Re:it's specific to OpenBSD (Score:2, Informative)
Re:Umm. (Score:2, Informative)
step 2: search on 'no more apache updates group:lucky.openbsd.misc' (no quotes)
read that. this [google.com] one in particular to answer your question. it was also covered here on
Wait a second! FUD Alert! (Score:3, Interesting)
Comment removed (Score:4, Interesting)
Re:Interesting (Score:4, Insightful)
Don't let not knowing about security hold you back from hosting your own site. Experiment, learn, have fun. Put an apache box up on a DMZ, put stupid content on it, see what happens. Look at your logs, see what's going on, learn from any mistakes you make along the way.
If you're in this industry, and are afraid to be the "fall guy" who has do deal with the inevitable attacks, or the "fall guy" in general, you'd better fasten your seat belt...you're in for a bumpy ride.
He who makes no mistakes makes nothing at all
Re:Interesting (Score:2)
Thing is, I forgot to lock down the allowable hosts.
Soon, I was seeing scripting engines requesting ads from various web servers in my logs. Took over a year for those scripts to stop.
Didn't take long for me to find it, but once you're on an open proxy list.... You're screwed.
Re:Interesting (Score:3, Insightful)
In short, find a hosting company with a lot of Windows servers nearby IP-wise. This is, sadly, not a troll or flamebait, it's my experience. Apache is not what you have to w
Re:Interesting (Score:2)
Heh. I plan to serve my own site to gain the experience of log-reading, config-file twitching, and all that; I want to break into the Web field, and see this as a good opportunity to learn about webserver/OS hardening by fire, as well as being just plain fun :)
I'll also ask a buddy of mine who's a security consultant to attack the server. Better to have a friend attack and tell me my mistakes than some pimply-faced kid 0wneR my machine.
Re:Interesting (Score:2, Interesting)
I think the book would be great for you. If you do buy it, let me know what you think of it!
Merc.
(The book's author)
Devil's Advocate (Score:5, Informative)
Re:Devil's Advocate (Score:5, Funny)
Re:Devil's Advocate (Score:2)
Re:Devil's Advocate (Score:4, Funny)
j/k
Re:Devil's Advocate (Score:2)
Answer: None [secunia.com].
Re:Devil's Advocate (Score:2)
This [secunia.com] one is labeled "Moderately Critical".
The best way to harden IIS (Score:2)
Ctrl-Alt-Del
Is that anything like... (Score:5, Funny)
Well (Score:3, Funny)
*I apologize*
Re:Well (Score:5, Funny)
Maximum Apache Security (Score:4, Interesting)
Fragmented Justification (Score:4, Interesting)
Re:Fragmented Justification (Score:2)
Compare the final product... I think you'll see why Apache has and always will have the dominant market share.
Re:Fragmented Justification (Score:2)
Re:Fragmented Justification (Score:2)
Re:Fragmented Justification (Score:2, Funny)
Stronghold (Score:2)
Re:Stronghold (Score:2)
Short answer, likely not.
Don't advertise version number (Score:5, Insightful)
Re:Don't advertise version number (Score:2, Informative)
However, when it comes to exploits that deal with knowing version numbers, most of it is script kiddy stuff, so it's [ the script ] is going ot just run default exploit attempts against the webserver regardless of what is returned about the webserver.
ServerTokens Min (Score:2)
It's all in the docs.
Re:Don't advertise version number (Score:2, Informative)
Might help a little bit. As I saw so eloquently stated somewhere...
This would not stop skilled bad guys, but would slow down those kiddies playing around.
Should this perhaps be the default? Maybe. But the bottom line is, you don't have the right to put a machine online without knowing about the details.
Re:Don't advertise version number (Score:2)
Not in the least. My logs show tons of IIS and ancient Apache exploit attempts. Kiddies just mindlessly launch every exploit they know against any server they can find and hope to get lucky.
Re:Don't advertise version number (Score:2)
Re:Don't advertise version number (Score:3, Informative)
I've seen removing the version number being advocated by the Nessus folks, but I haven't done it.... It feels somewhat like security by obscurity....
Great. Another Book of The Arcane. (Score:5, Insightful)
With any luck, many hardening techniques will migrate towards the Apache installation process, or at least the Apache documentation.
just put an IIS server in front of it (Score:5, Funny)
Hardening apache? (Score:3, Funny)
logging (Score:2, Informative)
Thanks for posting. I could will look for it... (Score:2)
A year ago I wanted to put one public but found information on hardening it extremely limited -- or perhaps extremely disconnected.
If the book is indeed concise, it will be useful.
thttpd (Score:2)
Apache is extremely complicated and therefore a potentail rats nest of potential security holes. Please don't get me wrong here: I like Apache very much for its great flexibility, yet I helped a lot of security aware companies to migrate to thttpd [acme.com] because they wanted a code base that could be scrutinized in a reasonable amount of time. Most web apps really don't need the flexibility of Apache anyway, and those who do, will have to be run in secure environments like, say, jails [freebsd.org] or other virtualized environme
If possible, use a different httpd (Score:3, Interesting)
Now, you still have to learn how to set up that package right, and keep up on updates, but diversity is a nice thing. Even if you just move some files (e.g. static content like images) off onto a side server, there's less to secure on the Apache box, so it's usually simpler.
Lack of security between users/virtual hosts (Score:3, Insightful)
You would need to run multiple apaches running from different UIDs for each user
That's bad. suexec it's not a option - it doesn't work with mod_python and other apache modules.
perchild MPM module that should do it doesn't work and apache developers are not interested in fixing that. No idea why.
metuxmpm MPM module was written instead perchild by external developers but it also doesn't work well unfortunately (for me it doesn't work at all).
NIce Defcon Presentation (Score:2, Informative)
So why not do things differently? (Score:2, Interesting)
So why not create a smart program to generate the config file either as a script or as a GUI application that will have enough smarts to get your normal site up and running but with the possible security holes turned OFF and massive warnings written into the file so that when someone goes to ed
Re:So why not do things differently? (Score:2, Informative)
Re:So why not do things differently? (Score:2)
Re:Stupid is a Stupid does (Score:5, Funny)
%su
%httpd start
when we all know it should be
%su
#httpd start
Re:Stupid is a Stupid does (Score:2)
%su
#httpd start
when we ALL know it should be
%su -
#httpd start
Re:Stupid is a Stupid does (Score:2)
#httpd start
This implies:
%which su
alias su='sudo su'
and
Re:Stupid is a Stupid does (Score:3, Informative)
Re:Stupid is a Stupid does (Score:2)
If somebody has gotten enough access to your box to add an arbitrary module to your httpd config, you're in pretty big trouble anyhow...
NO IT'S NOT (Score:2)
What, me Rush fan?
Whaddayamean "who cares"?
Re:Stupid is a Stupid does (Score:2)
#ICMP traffic
einfo "Creating icmp chain"
$IPTABLES -N icmp_allowed
$IPTABLES -F icmp_allowed
$IPTABLES -A icmp_allowed -p icmp -s $NETWORK -j ACCEPT
$IPTABLES -A icmp_allowed -p icmp -s 127.0.0.1 -j ACCEPT
$IPTABLES -A icmp_allowed -m state --state ESTABLISHED,RELATED -p icmp --icmp-type echo-reply -j ACCEPT
$IPTABLES -A icmp_allowe
Re:Stupid is a Stupid does (Score:3, Insightful)
If you have a specific need to know I am here... it should be a part of your protocol.
Because, other than those things I want to work... my machine does not exist.
In short: I don't need ping replies to work. So, my machine does not do it.
Re:Stupid is a Stupid does (Score:3, Interesting)
I also use it as a monitor from another location so I can redirect certian traffic if it stops responding.
Sure, I could go firewall nazi and only allow ping from certain locations, but hell, it's only ping.
Not to say you MUST use it, but I find nothing particularly e
Re:Problems (Score:2)
thats not been my experience (Score:3, Informative)
Re:Problems (Score:2, Interesting)
I started using solely linux around 4 years ago. One of the first things I did was install apache and play around with that. I got it working with a little effort. After that I always built it from scratch. I eventually decided to try using apache out of the portage tree and it was set up as soon as I ran emerge and setup the configs in
Anyways I had to develop some webapp and my boss wante
Re:Problems (Score:2)
Are we talking about the same Apache webserver? (Score:4, Informative)
Maybe you missed the "documentation" section at the apache.org website? Or, do a google search for "linux apache howto". Tons of good stuff out there.
Apache on Linux requires you to spend 8 hours per day just to keep it up and running,
On what planet is this true? There's about 4 things to change from one webserver to another; you build one config file for your environment, and for the next one modify the listen, the user if you want, the document_root, and maybe servlet mapping if you're using that. Trivial and one-time.
and while its performance and security is fine if you have the time and staff for it, there is no way to just set it up and let it sit while installing patches when needed.
Our experience differs profoundly. Perhaps someone like you needs to hire someone like me to help you get set up. It's a trivial setup, configuration is well documented, and once it's up and running a webserver doesn't need any attention whatsoever until the next version comes out or you decide you want to change what it does. Arguing against Apache on actual factual grounds would be one thing, but "it's hard to set up and lots of work to keep running" is demonstrably false.
Re:Are we talking about the same Apache webserver? (Score:2)
Re:Problems (Score:2)
Re:Problems (Score:5, Informative)
Actually, for most of the configuration changes (short of an actual version upgrade or SSL cert change), you can do an 'apachectl graceful' and it applies your changes to the _new_ sessions, while letting the existing sessions close in the natural flow of the users' use of your site. Nice for minor tweaks on the fly during the day, with zero downtime.
Re:Problems (Score:2)
Re:Problems (Score:3, Informative)
Sigh, there are several ways to approach setting up an Apache server. All of them are easy.
First one is to start with an empty configuration file and then cut and past in portions of the standard file until you get a minimally working server.
The good part about this approach is that you get the least amount of bells and whistles added. Security via a small footprint is a good thing. The bad part about this approach is that you end up with a minimal server that may need more tweaking to get everythin
Re:Lead-in [OT, sorta] (Score:2)
Very briefly:
Who is nominative
Whom is accusative
Whose is genative/possessive
Whoms (should probably be whom's, if it were a real word) does not exist
I know I'll get flamed for being a grammar nazi, but whoms is such a very, very bad neologism...
Re:it should be secure out of the box (Score:2)
Dude! Shut the fuck up! I need to get a job when I'm out of college... if apache is 'secure by default' then what is stopping the janitor at my old high school from becoming an admin!
The more mysterious we keep the silicon, the more I get paid!
(