Password protection using .htaccess (403 Forbidden)

And a shutdown problem with -k shutdown

[max4]

Hi,

I'm relatively new to using Apache server, so please bear with me. I am using Apache server 2.2.8 with PHP 5. I recently discovered that although I setup the server as a localhost, other people can still connect to it. I searched the net and came across a password protection method using .htaccess.

I followed their tutorial and succeeded. The only problem is that when I enter the user name and password, I am given a 403 forbidden error. Here is my setup:

httpd.conf:

DocumentRoot "C:/path/to/htdocs"
AccessFileName .htaccess (This wasn't in the document, I had to add it)

<Directory "C:/path/to/dir1">
AllowOverride All
Options None
Order deny,allow
</Directory>

<Directory "C:/path/to/dir2">
AllowOverride All
Options None
Order deny,allow
</Directory>

.htaccess:

AuthType Basic
AuthName "Private Server"
AuthUserFile C:/path/to/file
require valid-user

I just can't figure this out. What's worse is that I can not shut down apache server without having to restart my pc. httpd -k shutdown does not work for me, I receive an error that apache is not installed - when in fact it is.

Here are some errors from my log:

[Sat Jun 14 22:45:40 2008] [error] [client 127.0.0.1] File does not exist: C:/biz/webserver/htdocs/favicon.ico
[Sat Jun 14 22:48:09 2008] [error] [client 127.0.0.1] Directory index forbidden by Options directive: C:/biz/webserver/htdocs/ac/, referer: [localhost...]

Much thanks in advance,
Max

[jdMorgan]

It appears that you were trying to log in using the URL localhost/ac/, that this directory does not have an index page in it, and that "Options -Indexes" is set for that directory (or for directory levels above it). Therefore, you get the "Directory index forbidden by Options" error.

As for the shutdown problem, and not finding the Apache install, it sounds like the initial installation went bad somehow, or that you tried to move some files or diretories around after the install, and now Apache or the OS can't find them. You might want to consider a clean re-installation -- But make back-ups of all of your customizations first!

Jim

[max4]

Yes, you are correct Jim. I just found the solution to the first problem and logged on to tell you guys about it. Trying to directly access localhost/ac resulted in a 403 error, however; connecting to localhost/ac through the index.php document in htdocs worked. I was prompted for a user name and password and had access to what I had linked to the index.php page.

As for the bad install, I had expected as much. We're all bound to make mistakes at times, especially during learning curves.

My server had been up since Jan. I checked the access logs and found quite a few users who tried to get information from my service. I don't understand some of the messages. Most of these users received some sort of 4(00 or above) error, so they didn't get anything; but others received what they wanted fine (%>s read 200 level). I don't understand what they got. Some of the requests looked like this:

"CONNECT www.example.com:443 HTTP/1.0" 200 16962
"GET [google.com...] HTTP/1.1" 200 873
"GET / HTTP/1.0" 200 16962

What do those mean?

[edited by: jdMorgan at 3:11 pm (utc) on June 15, 2008]
[edit reason] example.com [/edit]

[jdMorgan]

From what I've seen, bad installs can "just happen" due to installer script errors or omissions... :(

On your logged requests:

The first was an attempt to create an SSL tunnel connection to "example.com" using your server as a proxy. You can check to see if it worked by comparing the byte count (16962) against the size of your own home page. If they match, then it didn't work. If they don't match, and that byte counts matches the size of the example.com home page, then it did work, meaning that your serve is an open proxy.

The second request was also an attempt to use your server as a proxy to fetch google's home page. The same diagnostic procedure applies as above. Of course there's nothing dangerous about proxying to google, but this was just a test to see if your server could be used as a proxy (for other -probably bad- purposes).

I can't tell what happened there, since a byte count of 873 seems too low for google's home page (today it's 2688 bytes). On the other hand, you say that your logging is set up with "%>s" rather than "%s", so that 200-OK status you've shown should be trustworthy. I dunno, maybe the client requested it in compressed format(?)

The last request appears to be a completely-normal request for your site's home page, and the good news is that the byte count indicates that the "CONNECT" request listed above failed, because your home page's byte count is 16962.

Only request #2 seems to need more investigation (or worry).

Jim

[max4]

I just looked up proxy server on wikipedia. I didn't know people could do that. If the bytes where different, would I be able to correct the problem by replacing the modified index.php with my backup?

You won't believe some of these other requests. Most of them tried to access non-existent folders such as admin, administrator, phpmyadmin (all versions). Others tried to access mysql, and database folders (all non existent so they all received 404 errors). It's simply ridiculous. One guy tried to access 636 non-existent files and folders. I really hope password protecting all directories will deter this malicious behavior.

Thanks for the explanation Jim, I will keep a keen eye on that access log.

Max

[jdMorgan]

I'm not sure why you're asking about replacing anything... Just return a 403-Forbidden to bogus/abuse requests.

Of course I *would* believe the requests you're seeing -- I get them all the time, and maybe more than you... :) Welcome to the "Wild, Wild, Web"!

If you run a very new or small site, more than 50% of the requests you'll see will be search engine spiders, scrapers, and exploit seekers. A lot of discussion here at WebmasterWorld concerns blocking junk requests, and reducing the bandwidth they waste.

Jim

[g1smd]

If the byte size were different, that would indicate that the user had pulled the index file from another site, using your server as a proxy. The log would indicate the size of the index file on the other site.

[max4]

I ask what I don't know, and I have no idea how to return a 403 to abusive requests. What I do know about apache is that I have a lot of reading ahead of me.

g1smd, what is involved in using another server as a proxy? How does one go about correcting that issue, given that my index file is not altered?

[jdMorgan]

It is not that someone's trying to use another server as a proxy, it's that they are trying to use your server as a proxy to reach another server. In other words, they are trying to "pipe" their requests through your server to another server (or perhaps to client machines -- other people's PCs).

This is often done to mask their original IP address, so that the target machine can't log it, or so the proxy requestor's ISP cannot log the actual site that they are trying to reach.

This is done both for "black" and "grey" reasons -- The black being malicious intent, and the grey being --perhaps-- avoidance of national censorship. But either way, you probably don't really want your server to have to handle any traffic not associated with your site, so it's common to simply block any and all requests.

One way to block requests of the form "GET http://www.google.com is to use mod_rewrite to check the client-requested URL-path; If it contains "http://" and does not contain "http://www.your-domain.com", then rewrite with an [F] flag to generate a 403-Forbidden response (See the Apache mod_rewrite documentation).

Jim

[max4]

Wow Jim, thanks for that explanation - it really cleared a lot up. I will read the docs on the issue and try to set something up. I'll post any questions as they arise.

Thanks,
Max