1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
|
<!--#if expr="$FAQMASTER" -->
<!--#set var="STANDALONE" value="" -->
<!--#set var="INCLUDED" value="YES" -->
<!--#if expr="$QUERY_STRING = TOC" -->
<!--#set var="TOC" value="YES" -->
<!--#set var="CONTENT" value="" -->
<!--#else -->
<!--#set var="TOC" value="" -->
<!--#set var="CONTENT" value="YES" -->
<!--#endif -->
<!--#else -->
<!--#set var="STANDALONE" value="YES" -->
<!--#set var="INCLUDED" value="" -->
<!--#set var="TOC" value="" -->
<!--#set var="CONTENT" value="" -->
<!--#endif -->
<!--#if expr="$STANDALONE" -->
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org" />
<title>Apache Server Frequently Asked Questions</title>
</head>
<!-- Background white, links blue (unvisited), navy (visited), red (active) -->
<body bgcolor="#FFFFFF" text="#000000" link="#0000FF"
vlink="#000080" alink="#FF0000">
<!--#include virtual="header.html" -->
<h1 align="CENTER">Apache Server Frequently Asked
Questions</h1>
<p>$Revision: 1.11 $ ($Date: 2003/01/13 03:29:32 $)</p>
<p>The latest version of this FAQ is always available from the
main Apache web site, at <<a
href="http://httpd.apache.org/docs/1.3/misc/FAQ.html"
rel="Help"><samp>http://httpd.apache.org/docs/1.3/misc/FAQ.html</samp></a>>.</p>
<!-- Notes about changes: -->
<!-- - If adding a relative link to another part of the -->
<!-- documentation, *do* include the ".html" portion. There's a -->
<!-- good chance that the user will be reading the documentation -->
<!-- on his own system, which may not be configured for -->
<!-- multiviews. -->
<!-- - When adding items, make sure they're put in the right place -->
<!-- - verify that the numbering matches up. -->
<!-- - *Don't* use <PRE></PRE> blocks - they don't appear -->
<!-- correctly in a reliable way when this is converted to text -->
<!-- with Lynx. Use <DL><DD><CODE>xxx<BR>xx</CODE></DD></DL> -->
<!-- blocks inside a <P></P> instead. This is necessary to get -->
<!-- the horizontal and vertical indenting right. -->
<!-- - Don't forget to include an HR tag after the last /P tag -->
<!-- but before the /LI in an item. -->
<p>If you are reading a text-only version of this FAQ, you may
find numbers enclosed in brackets (such as "[12]"). These refer
to the list of reference URLs to be found at the end of the
document. These references do not appear, and are not needed,
for the hypertext version.</p>
<h2>The Questions</h2>
<ol type="A">
<!--#endif -->
<!--#if expr="$TOC || $STANDALONE" -->
<li value="7">
<strong>Authentication and Access Restrictions</strong>
<ol>
<li><a href="#dnsauth">Why isn't restricting access by
host or domain name working correctly?</a></li>
<li><a href="#user-authentication">How do I set up Apache
to require a username and password to access certain
documents?</a></li>
<li><a href="#remote-auth-only">How do I set up Apache to
allow access to certain documents only if a site is
either a local site <em>or</em> the user supplies a
password and username?</a></li>
<li><a href="#authauthoritative">Why does my
authentication give me a server error?</a></li>
<li><a href="#auth-on-same-machine">Do I have to keep the
(mSQL) authentication information on the same
machine?</a></li>
<li><a href="#msql-slow">Why is my mSQL authentication
terribly slow?</a></li>
<li><a href="#passwdauth">Can I use my
<samp>/etc/passwd</samp> file for Web page
authentication?</a></li>
<li><a href="#prompted-twice">Why does Apache ask for my
password twice before serving a file?</a></li>
<li><a href="#image-theft">How can I prevent people from
"stealing" the images from my web site?</a></li>
</ol>
</li>
<!--#endif -->
<!--#if expr="$STANDALONE" -->
</ol>
<hr />
<h2>The Answers</h2>
<!--#endif -->
<!--#if expr="! $TOC" -->
<h3>G. Authentication and Access Restrictions</h3>
<ol>
<li>
<a id="dnsauth" name="dnsauth"><strong>Why isn't
restricting access by host or domain name working
correctly?</strong></a>
<p>Two of the most common causes of this are:</p>
<ol>
<li><strong>An error, inconsistency, or unexpected
mapping in the DNS registration</strong><br />
This happens frequently: your configuration restricts
access to <samp>Host.FooBar.Com</samp>, but you can't get
in from that host. The usual reason for this is that
<samp>Host.FooBar.Com</samp> is actually an alias for
another name, and when Apache performs the
address-to-name lookup it's getting the <em>real</em>
name, not <samp>Host.FooBar.Com</samp>. You can verify
this by checking the reverse lookup yourself. The easiest
way to work around it is to specify the correct host name
in your configuration.</li>
<li>
<strong>Inadequate checking and verification in your
configuration of Apache</strong><br />
If you intend to perform access checking and
restriction based upon the client's host or domain
name, you really need to configure Apache to
double-check the origin information it's supplied. You
do this by adding the <samp>-DMAXIMUM_DNS</samp> clause
to the <samp>EXTRA_CFLAGS</samp> definition in your
<samp>Configuration</samp> file. For example:
<dl>
<dd><code>EXTRA_CFLAGS=-DMAXIMUM_DNS</code></dd>
</dl>
<p>This will cause Apache to be very paranoid about
making sure a particular host address is
<em>really</em> assigned to the name it claims to be.
Note that this <em>can</em> incur a significant
performance penalty, however, because of all the name
resolution requests being sent to a nameserver.</p>
</li>
</ol>
<hr />
</li>
<li>
<a id="user-authentication"
name="user-authentication"><strong>How do I set up Apache
to require a username and password to access certain
documents?</strong></a>
<p>There are several ways to do this; some of the more
popular ones are to use the <a
href="../mod/mod_auth.html">mod_auth</a>, <a
href="../mod/mod_auth_db.html">mod_auth_db</a>, or <a
href="../mod/mod_auth_dbm.html">mod_auth_dbm</a>
modules.</p>
<p>For an explanation on how to implement these
restrictions, see <a
href="http://www.apacheweek.com/"><cite>Apache
Week</cite></a>'s articles on <a
href="http://www.apacheweek.com/features/userauth"><cite>Using
User Authentication</cite></a> or <a
href="http://www.apacheweek.com/features/dbmauth"><cite>DBM
User Authentication</cite></a>, or see the <a
href="../howto/auth.html">authentication tutorial</a> in the
Apache documentation.</p>
<hr />
</li>
<li>
<a id="remote-auth-only"
name="remote-auth-only"><strong>How do I set up Apache to
allow access to certain documents only if a site is either
a local site <em>or</em> the user supplies a password and
username?</strong></a>
<p>Use the <a href="../mod/core.html#satisfy">Satisfy</a>
directive, in particular the <code>Satisfy Any</code>
directive, to require that only one of the access
restrictions be met. For example, adding the following
configuration to a <samp>.htaccess</samp> or server
configuration file would restrict access to people who
either are accessing the site from a host under domain.com
or who can supply a valid username and password:</p>
<dl>
<dd><code>Deny from all<br />
Allow from .domain.com<br />
AuthType Basic<br />
AuthUserFile /usr/local/apache/conf/htpasswd.users<br />
AuthName "special directory"<br />
Require valid-user<br />
Satisfy any</code></dd>
</dl>
<p>See the <a href="#user-authentication">user
authentication</a> question and the <a
href="../mod/mod_access.html">mod_access</a> module for
details on how the above directives work.</p>
<hr />
</li>
<li>
<a id="authauthoritative"
name="authauthoritative"><strong>Why does my authentication
give me a server error?</strong></a>
<p>Under normal circumstances, the Apache access control
modules will pass unrecognized user IDs on to the next
access control module in line. Only if the user ID is
recognized and the password is validated (or not) will it
give the usual success or "authentication failed"
messages.</p>
<p>However, if the last access module in line 'declines'
the validation request (because it has never heard of the
user ID or because it is not configured), the
<samp>http_request</samp> handler will give one of the
following, confusing, errors:</p>
<ul>
<li><samp>check access</samp></li>
<li><samp>check user. No user file?</samp></li>
<li><samp>check access. No groups file?</samp></li>
</ul>
<p>This does <em>not</em> mean that you have to add an
'<samp>AuthUserFile /dev/null</samp>' line as some
magazines suggest!</p>
<p>The solution is to ensure that at least the last module
is authoritative and <strong>CONFIGURED</strong>. By
default, <samp>mod_auth</samp> is authoritative and will
give an OK/Denied, but only if it is configured with the
proper <samp>AuthUserFile</samp>. Likewise, if a valid
group is required. (Remember that the modules are processed
in the reverse order from that in which they appear in your
compile-time <samp>Configuration</samp> file.)</p>
<p>A typical situation for this error is when you are using
the <samp>mod_auth_dbm</samp>, <samp>mod_auth_msql</samp>,
<samp>mod_auth_mysql</samp>, <samp>mod_auth_anon</samp> or
<samp>mod_auth_cookie</samp> modules on their own. These
are by default <strong>not</strong> authoritative, and this
will pass the buck on to the (non-existent) next
authentication module when the user ID is not in their
respective database. Just add the appropriate
'<samp><em>XXX</em>Authoritative yes</samp>' line to the
configuration.</p>
<p>In general it is a good idea (though not terribly
efficient) to have the file-based <samp>mod_auth</samp> a
module of last resort. This allows you to access the web
server with a few special passwords even if the databases
are down or corrupted. This does cost a file
open/seek/close for each request in a protected area.</p>
<hr />
</li>
<li>
<a id="auth-on-same-machine"
name="auth-on-same-machine"><strong>Do I have to keep the
(mSQL) authentication information on the same
machine?</strong></a>
<p>Some organizations feel very strongly about keeping the
authentication information on a different machine than the
webserver. With the <samp>mod_auth_msql</samp>,
<samp>mod_auth_mysql</samp>, and other SQL modules
connecting to (R)DBMses this is quite possible. Just
configure an explicit host to contact.</p>
<p>Be aware that with mSQL and Oracle, opening and closing
these database connections is very expensive and time
consuming. You might want to look at the code in the
<samp>auth_*</samp> modules and play with the compile time
flags to alleviate this somewhat, if your RDBMS licences
allow for it.</p>
<hr />
</li>
<li>
<a id="msql-slow" name="msql-slow"><strong>Why is my mSQL
authentication terribly slow?</strong></a>
<p>You have probably configured the Host by specifying a
FQHN, and thus the <samp>libmsql</samp> will use a full
blown TCP/IP socket to talk to the database, rather than a
fast internal device. The <samp>libmsql</samp>, the mSQL
FAQ, and the <samp>mod_auth_msql</samp> documentation warn
you about this. If you have to use different hosts, check
out the <samp>mod_auth_msql</samp> code for some compile
time flags which might - or might not - suit you.</p>
<hr />
</li>
<li>
<a id="passwdauth" name="passwdauth"><strong>Can I use my
<samp>/etc/passwd</samp> file for Web page
authentication?</strong></a>
<p>Yes, you can - but it's a <strong>very bad
idea</strong>. Here are some of the reasons:</p>
<ul>
<li>The Web technology provides no governors on how often
or how rapidly password (authentication failure) retries
can be made. That means that someone can hammer away at
your system's <samp>root</samp> password using the Web,
using a dictionary or similar mass attack, just as fast
as the wire and your server can handle the requests. Most
operating systems these days include attack detection
(such as <em>n</em> failed passwords for the same account
within <em>m</em> seconds) and evasion (breaking the
connection, disabling the account under attack, disabling
<em>all</em> logins from that source, <em>et
cetera</em>), but the Web does not.</li>
<li>An account under attack isn't notified (unless the
server is heavily modified); there's no "You have 19483
login failures" message when the legitimate owner logs
in.</li>
<li>Without an exhaustive and error-prone examination of
the server logs, you can't tell whether an account has
been compromised. Detecting that an attack has occurred,
or is in progress, is fairly obvious, though -
<em>if</em> you look at the logs.</li>
<li>Web authentication passwords (at least for Basic
authentication) generally fly across the wire, and
through intermediate proxy systems, in what amounts to
plain text. "O'er the net we go/Caching all the way;/O
what fun it is to surf/Giving my password away!"</li>
<li>Since HTTP is stateless, information about the
authentication is transmitted <em>each and every
time</em> a request is made to the server. Essentially,
the client caches it after the first successful access,
and transmits it without asking for all subsequent
requests to the same server.</li>
<li>It's relatively trivial for someone on your system to
put up a page that will steal the cached password from a
client's cache without them knowing. Can you say
"password grabber"?</li>
</ul>
<p>If you still want to do this in light of the above
disadvantages, the method is left as an exercise for the
reader. It'll void your Apache warranty, though, and you'll
lose all accumulated UNIX guru points.</p>
<hr />
</li>
<li>
<a id="prompted-twice" name="prompted-twice"><strong>Why
does Apache ask for my password twice before serving a
file?</strong></a>
<p>If the hostname under which you are accessing the server
is different than the hostname specified in the <a
href="../mod/core.html#servername"><code>ServerName</code></a>
directive, then depending on the setting of the <a
href="../mod/core.html#usecanonicalname"><code>UseCanonicalName</code></a>
directive, Apache will redirect you to a new hostname when
constructing self-referential URLs. This happens, for
example, in the case where you request a directory without
including the trailing slash.</p>
<p>When this happens, Apache will ask for authentication
once under the original hostname, perform the redirect, and
then ask again under the new hostname. For security
reasons, the browser must prompt again for the password
when the host name changes.</p>
<p>To eliminate this problem you should</p>
<ol>
<li>Always use the trailing slash when requesting
directories;</li>
<li>Change the <code>ServerName</code> to match the name
you are using in the URL; and/or</li>
<li>Set <code>UseCanonicalName off</code>.</li>
</ol>
<hr />
</li>
<li>
<a id="image-theft" name="image-theft"><strong>How can I prevent
people from "stealing" the images from my web site?</strong></a>
<p>The goal here is to prevent people from inlining your images
directly from their web site, but accessing them only if they
appear inline in your pages.<p>
<p>This can be accomplished with a combination of SetEnvIf and
the Deny and Allow directives. However, it is important to
understand that any access restriction based on the REFERER
header is intrinsically problematic due to the fact that
browsers can send an incorrect REFERER, either because they
want to circumvent your restriction or simply because they don't
send the right thing (or anything at all).</p>
<p>The following configuration will produce the desired effect
if the browser passes correct REFERER headers.</p>
<pre>
SetEnvIf REFERER "www\.mydomain\.com" linked_from_here
SetEnvIf REFERER "^$" linked_from_here
<Directory /www/images>
Order deny,allow
Deny from all
Allow from env=linked_from_here
</Directory>
</pre>
<p>Further examples can be found in the <a
href="../env.html#examples">Environment Variables</a> documentation.</p>
<hr />
</li>
</ol>
<!--#endif -->
<!--#if expr="$STANDALONE" -->
<!-- Don't forget to add HR tags at the end of each list item.. -->
<!--#include virtual="footer.html" -->
<!--#endif -->
</body>
</html>
|
