| home / internet / security / apache / chap5 / 3 | [previous] [next] |
|
Run ./go. Exit from your browser on the client
machine, and reload it to make sure it does password checking
properly (you will probably need to do this every time you make a
change throughout this exercise). If you access the
salespeople's site again with the user ID
guest, anonymous, or
air-head and any password you like
(fff or 23 or
rubbish), you will get access. It seems rather
silly, but you must give a password of some sort.
Set:
Anonymous_NoUserID on
This time you can leave both the ID and password fields empty. If you enter a valid username (bill, ben, sonia, or gloria), you must follow through with a valid password.
Set:
Anonymous_NoUserID off
Anonymous_VerifyEmail on
Anonymous_LogEmail on
The effect here is that the user ID has to look something like an email address, with (according to the documentation) at least one "@" and one ".". However, we found that one "." orone "@" would do. Email is logged in the error log, not the access log as you might expect.
Set:
Anonymous_VerifyEmail off
Anonymous_LogEmail off
Anonymous_Authoritative on
The effect here is that if an access attempt fails, it is not now
passed on to the other methods. Up to now we have always been able to
enter as bill, password
theft, but no more. Change the
Anonymous section to look like this:
Anonymous_Authoritative off
Anonymous_MustGiveEmail on
Finally:
Anonymous guest anonymous air-head
Anonymous_NoUserID off
Anonymous_VerifyEmail off
Anonymous_Authoritative off
Anonymous_LogEmail on
Anonymous_MustGiveEmail on
The documentation says that
Anonymous_MustGiveEmail forces the user to give
some sort of password. In fact, it seems to have the same effect as
VerifyEmail:. A
"." or
"@" will do.
In the first edition of this book we said that if you wrote your httpd.conf file as shown earlier, but also created .../conf/access.conf containing directives as innocuous as:
<Directory /usr/www/APACHE3/site.anon/htdocs/salesmen>
</Directory>
security in the salespeople's site would disappear. This bug seems to have been fixed in Apache v1.3.
This is all great fun, but we are trying to run a business here. Our salespeople are logging in because they want to place orders, and we ought to be able to detect who they are so we can send the goods to them automatically. This can be done by looking at the environment variable REMOTE_USER, which will be set to the current username. Just for the sake of completeness, we should note another directive here.
The IdentityCheck directive causes the server to
attempt to identify the client's user by querying
the identd daemon of the client host. (See RFC
1413 for details, but the short explanation is that
identd will, when given a socket number, reveal
which user created that socket — that is, the username of the
client on his home machine.)
IdentityCheck [on|off]
If successful, the user ID is logged in the access log. However, as
the Apache manual austerely remarks, you should "not
trust this information in any way except for rudimentary usage
tracking." Furthermore (or perhaps, furtherless),
this extra logging slows Apache down, and many machines do not run an
identd daemon, or if they do, they prevent
external access to it. Even if the client's machine
is running identd, the information it provides
is entirely under the control of the remote machine. Many providers
find that it is not worth the trouble to use
IdentityCheck.
| home / internet / security / apache / chap5 / 3 | [previous] [next] |
Created: March 10, 2003
Revised: March 10, 2003
URL: http://webreference.com/internet/apache/chap5/3/5.html