Help turning on mod_rewrite

[subduck]

My localhost system: Apache/2.0.50 (Win32) PHP/5.0.0

I've opened httpd.conf and removed the # for this line:
LoadModule rewrite_module modules/mod_rewrite.so

I made sure the file mod_rewrite.so exists in the modules directory.

Restarted apache 2 without any errors.

phpinfo confirms mod_rewrite is loaded.

I then created a .htaccess file in my root directory (links to [localhost...]

I create a few simple lines in the .htaccess file:
RewriteEngine On
RewriteBase /
Redirect /google.html [google.com...]

However I get a 'Not Found' message when typing this:
[localhost...]

The apache error log only has this line:
[Tue Mar 15 19:14:19 2005] [error] [client 127.0.0.1] File does not exist: C:/Program Files/Apache Group/Apache2/htdocs/google.html

Any help will be great :)

[subduck]

bump :(

[subduck]

Got it working! My Solution:

Open up the httpd.conf and find these lines:

#
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
# Options FileInfo AuthConfig Limit
#
AllowOverride None

And change it to 'All' (wihout quotes)

[coopster]

Welcome to WebmasterWorld, subduck.

Nice work, glad you nailed it.

[subduck]

Thanks coopster :)

[sitz]

Open up the httpd.conf and find these lines:

#
# AllowOverride controls what directives may be placed in .htaccess files.
# It can be "All", "None", or any combination of the keywords:
# Options FileInfo AuthConfig Limit
#
AllowOverride None

And change it to 'All' (wihout quotes)

Actually this is either a bad idea or a REALLY bad idea, depending on your setup. 'All' relinquishes a LOT of control to any users you may have (if you don't have any users, it's /still/ a bad idea, but I'll get to that in a minute). Reading from [httpd.apache.org ], by using 'All', you've essentially done this:

AllowOverride AuthConfig FileInfo Indexes Limit Options

This allows users to place directives whose override falls into ANY of those categories in .htaccess files, possibly overriding settings in httpd.conf. The most dangerous of these categories, is 'Options', since this can allow users to enable server-side includes (if the server-parsed handler is on in your httpd.conf) and /will/ allow them to run CGI scripts in their directories. Allowing users to run their own CGIs (unaudited, by someone who knows how to do this sort of thing), is either bad, or REALLY REALLY bad; CGIs can do anything to your server that the user the script runs as (generally the user the webserver is running as). This includes accessing your webserver's logfiles, possibly your system's logfiles, possibly user's home directories.

If you don't have any users (or are close personal friends with all of them) there's something else to consider; if AllowOverride is set to anything other than 'none' (let's use your example and set it to 'all' in the DocumentRoot), and a request comes in for:

http://www.example.com/foo/bar/baz/bing/quux/thingy/blatt/mypage.html

Apache has to check for a .htaccess file in *8* directories; this means 8 additional stat(2) calls, which you wouldn't otherwise have had. This behavior is documented in the AllowOverride portion of [httpd.apache.org ], along with examples of how better to configure your AllowOverride directives if you do, in fact, actually need them.

For the record, checking the docs for the docs for the RewriteEngine directive at [httpd.apache.org ]
would have shown you *which* override you need to enable for RewriteEngine to work in a .htaccess file; the Apache docs list the applicable Override in the first portion of the documentation for each directive.

One other thing to note; I see a LOT of folks on this board using .htaccess files for their mod_rewrite directives. I also know that some (perhaps even most) of the people who do have no choice, as they are users on someone else's system. Those of you who *run* servers should *not* be using .htaccess files for mod_rewrite directives unless there's an overriding reason to do so; there's a measureable performance impact for doing so, which is mentioned in the mod_rewrite docs:

[httpd.apache.org ]

Right there, at the second bullet point. =)

[AlwaysSayNever]

"setting AllowOverride all is a really really really really bad idea"

Yes, so you've said several times. For proof you've provided a handful of urls. Call my a flying monkey but I think you've left out the middle of your argument. Aside from that, this url

[httpd.apache.org...]

suggests the opposite:

"Default: AllowOverride All"

Soooo could you break it down into bite sized pieces exactly why this is a bad idea? :D

I run apache2triad under WinXP Pro to play with PHP applications before uploading them. I like .htaccess -- mainly because up until now I was complete unaware that I could use httpd.conf -- but also because on a shared webserver elsewhere I don't have control over httpd.conf. So that brings me back to needing .htaccess and seemingly needing 'all'

Thanks much for your patience and willingness to share your experience

:)

[sitz]

I'm going to try not to restate my arguments against 'AllowOverride all' listed above in this post (although I suspect I'll fail). Some of the reasons for my opinion on this is Culture and some of this is what I consider to be Best Practices.

Culture:
--------------------

Just to give you some background so you know where I'm coming from; in my current job, I run medium-scale server farms (multiple farms of 12-30 hosts each) which, by a conservative estimate, serve several million hits a day per farm. In my previous job, I ran a small farm (half a dozen hosts), which provided web services for 50-60k users and roughly 9k domains which averaged hundreds of thousands to millions of hits each day. In jobs such as these, two things need to be kept in mind (well, a lot more than two things, but we'll discuss two here). Is your environment like mine? Most likely not. This doesn't mean you can't (or shouldn't be) keeping some/all of the items below in mind.

1) The servers need to be up all the time. Full stop.

Most of the folks on this board run smaller sites. Maybe they're the only user of their site. Maybe they're paying for web hosting but have no root, maybe they have root on the one host they run for their personal site, or maybe they re-sell webservices. In all these cases, you (obviously) want your servers up all the time. In a single-site environment, accomplishing this isn't a huge deal; you control all the host-based variables and with this type of environment comes a certain degree of freedom; config files (and the server installation itself) don't have to be /as/ secure as some larger environments, because no one else has access. This also makes keeping the system up a bit easier, since you're the only one (or one of only a few people) making changes.

Now take an environment such as my previous job; I've got 50-60k users using my systems. Which leads into my next point:

2) You can't trust anyone...

...not at all. Not even a little bit.

OK, that's overstating it. slightly. Do I think my neighbors are out to get me? Is that cat under CIA control [mprofaca.cro.net]? Of course not. Are every one of my users out to do me harm? Of course not. The overwhelming majority of them are basically nice folks, with varying degrees of Clue(tm), who simply want their website up.

A few (ok, more than a few) are ignorant. They don't know anything about How Stuff Works(tm), but they know they can Do Cool Stuff if they follow the helpful directions on $WEBSITE. Sometimes $WEBSITE is dead wrong. Sometimes they (and 'they' can very easily be the person you've just paid $20k to build your website for you) have skipped step #6 because they thought it didn't apply, or it didn't make sense to them. Sometimes $WEBSITE has posted bad data on purpose. And a very few are just plain out to get you. Or rather, your systems. They'll do anything and everything they can to do damage to you, your systems, your network, and so forth.

And you have NO WAY to tell the bad guys from the good guys until it's too late. This means that in order to ensure that your systems are up All The Time(tm), you need take steps to ensure that the ignorant good guys and the malicious bad guys, all of whom are, willfully or not, out to do you harm, won't take down your systems.

Best Practices
--------------------

(note: these are mine. They have evolved over time, and will continue to do so as I learn more. They are not cast in stone; more like whipping cream. They will not work for everyone. They do not solve all problems. Some of these you may not want to use. Some of these you shouldn't use until you learn more about the pitfalls of doing so. Some of you may know exactly what those pitfalls are, and have been down this road before. Caveat Administrator. Do not taunt Happy Fun Ball, etc, etc, etc....)

"lock down *everything* that isn't absolutely *required* for the the server to run." Don't need mod_imap.so? Comment it (and any other modules that you and your users don't need) out; you'll save a few CPU cycles that you'll need when your site gets hugely popular. Remember: Apache burns cycles for every module loaded, even if it's never used. Likewise any other module you (or your users) don't need. And speaking of performance, you have read the Apache documentation regarding performance tuning [httpd.apache.org], haven't you? =)

Does that httpd.conf file REALLY need to be world-readable? Why? If an unfriendly user was able to read your configuration file, what would they learn about your system? Do your log files need to be world-readable? Really? You sure about that? What kind of data is appearing in your error log anyway? Great heavens, is that a database password?

CGIs. Oh, how to I hate thee, let me count the ways. Putting aside for the moment the fact that they Do Not Scale(tm) (believe me on this; I've seen multi-server farms melt because CGIs were deployed rather than an embedded alternative, such as PHP or mod_perl. They'll work fine for smaller sites, but for larger stuff? Forget it.), in an untrusted environment (read: you have users you don't personally know and trust), CGIs can be used is all /kinds/ of nasty ways. I've seen CGIs used to read password files, webserver log files, and (once) to give a malicious user a pseudo-shell on the webserver. Think the malicious folks won't find you? Think again:

The fastest time for a server to be hacked is fifteen minutes after it was plugged into the network.

-- [securitydocs.com ]

One way to secure a system is to turn on CGI capability in one particular directory, make it so no one except you can place files there, and make your users submit CGIs for your inspection before deploying them. Of course, this doesn't scale all that well, and you're assuming (perhaps correctly, perhaps not) that you know more perl/python/C++ (or even shell script. You laugh, I've seen them) than the person who send you the code.

Some folks just disable CGIs completely. At least PHP allows you to restrict which functions get used, which paths you'll let let opened (do you really want someone open()'ing /etc/passwd on your system and perusing it? Sure, no passwords are stored there (you *have* enabled shadowed passwords, right?), but the usernames are, which is half the battle. I tell you three times and what I tell you three times is true; *any* information an attacker gets about your system, no matter how insignificant, is a weakening of your security. "Eh. it's just my httpd.conf; there's no sensitive information in there, like passwords". Probably true. The attacker does, however, now know what sites are hosted with you, how you have your filesystem laid out, where your documentroot is, etc, etc. This is all potentially useful information.) Have I used CGIs? Sure. I've written them. I administer them. But the Right Tool For The Right Job, and a fork()'d CGI is, in my opinion, rarely the Right Tool.

So, let's say you disable CGI access completely, but you have 'AllowOverride all' in your httpd.conf. Guess what? CGIs aren't as disabled you thought they were. Or, let's (potentially) hit a little closer to home. Let's say your selling webspace to folks, but charge a premium for the ability to run CGIs? Guess what? You're losing money. Likewise for Server-side Includes; AllowOverride All allows any user to turn these on. Or, let's say you've disable CGIs, but enabled server-side includes. AllowOverride All means that users can set 'Options +Includes', which (unlike 'Options IncludesNOEXEC') allows them to exec CGIs from an SSI-enabled page. Woops. And then there's FollowSymLinks vs SymlinksIfOwnerMatch. Mmmmm...more chaos...

Run your webserver in a chroot() jail. This is NOT foolproof, as there *are* ways to break out of a chroot jail, but it's non-trivial. If you're also running a hardened kernel (GRSecurity [grsecurity.net] is an example; SELinux [nsa.gov] is another), chroot jails can be made even more secure. Want to know more about chroot()? Check the man [die.net] pages [die.net] and Google [google.com].

Files in your DocumentRoot should never be writable by the webserver (unless you REALLY REALLY know what you're doing). This means the files should not be owned by the same user the webserver runs as, nor should the files ever be mode o+w (mode 666 for files, mode 777 for directories). Unless you REALLY REALLY know what you're doing. If you're doing that, there is almost always another way to get the same thing done, and it's generally a better way.

Files containing sensitive data, such as database passwords and the like, should be stored OUTSIDE the document root whenever possible. I once kicked an application back to my developers to have sections re-coded for just this purpose. If sensitive data is in the documentroot, the webserver can potentially serve it. Likely? Nope. Possible? You bet. And I know which side I'm erring on. =)

In summary:
--------------------

Is using AllowOverride All going to harm most folks in here, really? If they know everyone involved with their site, *and* trust that the password used for uploading content won't be compromised, probably not. You *do* rotate your passwords, don't you? Did you know that there are SSL-aware FTP servers out there? Did you know that you can upload content over HTTP, using DAV [webdav.org]? This can also be made SSL-aware).

Flip the question around; why do you want it enabled? Best Practices (and not just mine) states that you disallow EVERYTHING and only allow what's REQUIRED. This applied to the filesystem, your application, and your network. While it's much more important to follow these rules in larger environments, why not get into the habit of Thinking Securely(tm)? If you have write access to httpd.conf, I'm hard-pressed to come up with a valid reason for using AllowOverride All; AFAIK, it doesn't get you anything that can't be accomplished in other, more secure, ways But hey, if you've got one, I'm all ears. =)

[jd01]

Keep thinking about this one...

If we are not the server admin, should we adjust settings to conform to these standards, as much as possible, on a per directory basis through the use of .htaccess?

If so, which one(s) should we implement, and what impact will they possibly have on server load/serve time?

Justin

This might seem a 'lazy post' but I think the points made in this thread only strengthen the forum information as a whole.