The steps to be accomplished are:

• create a table in the database to store the download counters for the products;
• create an .htaccess in Helicon Ape which will make records into the table upon each download with the help of mod_dbd module;
• create a simple aspx-page to show downloads statictics.

Preconditions

In the root of your site you have a downloads folder containing files for download (e.g., AudioCoder.msi, AudioDecoder.msi, AdditionalCodes.zip).
You have Helicon Ape installed on your Windows Server 2008 (IIS7).
You have SQL Server that will store the DB with downloads statistics.

Table for storing statistics

Run Microsoft SQL Server Management Studio and connect to your SQL server.

Right click on ‘Databases’, select ‘Create Database’, enter database name (for example ‘DownloadsCounter’) and click ‘OK’.

Now we’ll create the table itself:
Unfold the DownloadsCounter in Object Explorer, right click on ‘Tables’ and select ‘New Table…’. Name the table ‘Downloads’ and add 4 fields: id (int), moment (datetime), filename (nvarchar(50)) and ipaddress (nvarchar(50)) as shown on the pic below. You can find sql script to create table in attached DownloadsCounterExample.zip.

Done with the table!

mod_dbd configuration

Start Helicon Ape Manager, select your site from the tree and click on ‘downloads’ folder. Now write the following config in .htaccess on the right.

The config instructs mod_dbd to connect to DB, catches data from request (filename and client ip-address) and writes them into the DB.

# Helicon Ape version 3.0.0.59

# Connection settings
DBDriver mssql
DBDParams "Data Source=db2003\MSSQLSERVER2008;Initial Catalog=DownloadsCounter;\
           User ID=sa;Password=123123"

# Save Filename (for .msi & .zip files only)
SetEnvIfNoCase REQUEST_URI ^/downloads/(.+\.(?:msi|zip))$ FileNameENV=$1
SetEnvIfNoCase REMOTE_ADDR ^(.*)$ IpAddrENV=$1

# Sql query to save download event
DBDPrepareSQL "INSERT INTO DownloadsCounter.dbo.Downloads\
    (moment, filename, ipaddress)\
    VALUES (\
        GETDATE(),\
        '%{FileNameENV}e',\
        '%{IpAddrENV}e'\
    )\
" InsertDownload

# Execute sql query if request uri is .msi or .zip file
SetEnvIf request_uri \.(?:msi|zip)$ dbd_execute=InsertDownload

# limit access to statistics page to localhost only
<Files stat.aspx>
Order Deny,Allow
Deny from all
Allow from ::1 127.0.0.1 localhost
</Files>

Save your .htaccess and try to download something from the browser. If you now throw a glimpse at the ‘downloads’ table in SQL Server Management Studio, you’ll see the records appearing in it:

How it works?

Helicon Ape module is processing all requests coming to /downloads/ folder. If .zip or .msi file is requested, Ape memorizes the filename (FileNameENV) and client IP (IpAddrEnv), from which the file was requested, and inserts these data into the table by means of SQL query.

Statistics viewer

The archive attached to the article includes stat.aspx which does a very simple task—shows records from ‘downloads’ table.

Of course, that’s not the sort of viewer you need, as it must be capable of showing statistics by days, months, products etc. But designing a real-life solution is beyond the scope of this article, so feel free to advance stat.aspx by yourself.

Resulting archive

Below is the archive DownloadsCounterExample.zip containing all files from this article. To do some testing just unzip it into the root of your site and replace the database password from ‘123123’ to the one you have in both .htaccess and web.config.

DownloadsCounterExample.zip

Why is this option better?

As we already noticed, Google Analytics and like services are based on JavaScript working on the page. They know nothing about static content and other files loaded from the server.

Another option (yet another extreme) is server logs. They are not always accessible, not always enabled, besides, they require writing of special parsers or analyzers. Moreover, server logs do not provide live (current moment) info. Usually log file is created daily so their analysis is only possible at the beginning of the next day.

Summing up

The method explained above is a quick and effortless way to screw downloads counter to your site using Helicon Ape mod_dbd. The example is easily expendable, e.g. you can add more fields to the table to save Referer, User-Agent, etc., or develop a customizable statistics viewer.

We’ve just given you the basement, now it’s time for you to build a house.

Best regards,
Ruslan—Helicon Tech Team

DoS is not an Operating System:)

In the security circles, familiar acronym «DoS» has nothing to do with well-known operating system. It stands for «Denial-Of-Service» and means an attempt to make a computer resource unavailable to its intended users.Also there is another term – «Distributed Denial-Of-Service attack» (DDoS attack).

As opposed to DoS, brute-force attack is commonly aimed at getting some access to a protected resource. For example, a computer hacker is trying a large number of possible passwords to crack a needed user account. In fact, lots of users use very simple passwords and hackers are gathering these passwords in special databases to use during brute-force attack.
More information may be found here:

• Denial-of-service
• Brute force attack

mod_evasive

The module was originally written for Apache and we tried to support its syntax to the maximum extent. Moreover, Ape implementation has a potential for further developmentand we are waiting for your suggestions and criticism.

To enable the module you should open Helicon Ape server configuration (httpd.conf file) and comment out LoadModule directive corresponding to mod_evasive:

Now we are ready to write mod_evasive configuration. The module directives should be written only inside httpd.conf file (per VirtualHost configuration is also supported).

There are five directives which have to be configured, otherwise the module won’t work. We haven’t set any default values forthese directives because their configuration is highly dependant on your server’s characteristics. Here are the five required directives:

• DOSPageInterval —  Sets a minimum accessible interval between two requests to a page from the same IP.
• DOSSiteInterval —  Sets a minimum accessible interval between two requests to a site from the same IP.
• DOSPageCount —  Sets the limit for a number of too short requests to the same page
• DOSSiteCount —  Sets the limit for a number of too short requests to the same site
• DOSBlockingPeriod —  How much time bad IP should be blocked.

Now we need to explain you mod_evasive logic. The module counts how many «too short» requests are made from same IP to various URLs and to the whole site. «Too short» means less than accessible interval set by DOSPageInterval and DOSSiteInterval directives. When an IP exceeds the count threshold, it will be blocked during a period set by DOSBlockingPerioddirective. DOSPageInterval, DOSSiteInterval and DOSBlockingPeriod values should be specified in seconds (real numbers are also supported to define more accurate intervals.

Note! You should carefully set mod_evasive configuration according to your server load! In case of incorrect configuration, legal users might be blocked.Here is an example of a minimal possible mod_evasive configuration. Please don’t use it without testing!

<IfModule evasive_module>
        DOSPageInterval 1
        DOSSiteInterval 1
        DOSPageCount 10
        DOSSiteCount 200
        DOSBlockingPeriod 60
</IfModule>

This configuration is enough to start blocking attackers. On the next step we will tell you about the blocking behavior.

What happens to bad guys

According to original mod_evasive behaviour, the module sends 403 (Forbidden) code. Actually the blocked responseis faster than the common one, because Ape stops request at this point and IIS processes only BeginRequest and EndRequest notification event.

In addition we’ve invented DOSCloseSocket directive (not supported in Apache) which is disabled by default. If you enable this directive, mod_evasive will send 403 code and close connection socket. It means an attacker should create a new connection and it’s pretty good for you as long as this process takes some time.

How to manage a hit list

There are two directives to manage hit list. The first one is DOSHashTableSize which allows you to set a maximum size of the list. Default value is 1024. Each item in the hit list corresponds to an IP address and you might dynamically change this value during DoS attack. Justmodify DOSHashTableSize value in httpd.conf and Ape will automatically update mod_evasive configuration. Just FYI, the module is usingspecial cleanup algorithm in case of overflow.Another way to manage hit list is DOSWhiteList directive. Itallows to specify IPs which should never be blocked. Both IPv4 and IPv6 formats are supported, moreover, you may use wildcard to add a group of IPaddresses into the list. Example:

DOSWhiteList 127.0.0.1 10.0.0.*

Connection with a system (for advanced users only)

There is one more useful feature in mod_evasive. It is DOSSystemCommand directive which gives you a chance to communicate with OS through command execution. You should be careful with this feature because it might beinsecure and might cause NTFS permissions issue.So, a command delivered to mod_evasive through DOSSystemCommand directive, will execute each time the module decides that an IP is bad. So, the command will be executed not for all 403 responses, but only for those given in response to malicious requests.


We should notice again that the user running the Application pool should have sufficient rights to execute the command. In most cases it’s pretty hard because web-servicesare run by non-previleged user with limited skills. In this case you should execute a command under another account (e.g. Administrator).Windows has runas command which provides needed functional with one disadvandage — it can’t get password through arguments. But, there are a few solutions to this problem. For example, you may use the following script to run the command(s) on behalf of another user specifying his username and password:
>

' *********************************************************************************
' * THIS PROGRAM IS OFFERED AS IS AND MAY BE FREELY MODIFIED OR ALTERED AS *
' * NECESSARY TO MEET YOUR NEEDS. THE AUTHOR MAKES NO GUARANTEES OR WARRANTIES, *
' * EXPRESS, IMPLIED OR OF ANY OTHER KIND TO THIS CODE OR ANY USER MODIFICATIONS. *
' * DO NOT USE IN A PRODUCTION ENVIRONMENT UNTIL YOU HAVE TESTED IN A SECURED LAB *
' * ENVIRONMENT. USE AT YOUR OWN RISK. *
' *********************************************************************************
 
On Error Resume Next
dim WshShell,oArgs,FSO
 
set oArgs=wscript.Arguments
 
if InStr(oArgs(0),"?")<>0 then
wscript.echo VBCRLF & "? HELP ?" & VBCRLF
Usage
end if
 
if oArgs.Count <3 then
wscript.echo VBCRLF & "! Usage Error !" & VBCRLF
Usage
end if
 
sUser=oArgs(0)
sPass=oArgs(1)&VBCRLF
sCmd=oArgs(2)
 
set WshShell = CreateObject("WScript.Shell")
set WshEnv = WshShell.Environment("Process")
WinPath = WshEnv("SystemRoot")&"\System32\runas.exe"
set FSO = CreateObject("Scripting.FileSystemObject")
 
if FSO.FileExists(winpath) then
'wscript.echo winpath & " " & "verified"
else
wscript.echo "!! ERROR !!" & VBCRLF & "Can't find or verify " & winpath &"." & /
VBCRLF & "You must be running Windows 2000 for this script to work."
set WshShell=Nothing
set WshEnv=Nothing
set oArgs=Nothing
set FSO=Nothing
wscript.quit
end if
 
rc=WshShell.Run("runas /user:" & sUser & " " & CHR(34) & sCmd & CHR(34), 2, FALSE)
Wscript.Sleep 30 'need to give time for window to open.
WshShell.AppActivate(WinPath) 'make sure we grab the right window /
to send password to
WshShell.SendKeys sPass 'send the password to the waiting window.
 
set WshShell=Nothing
set oArgs=Nothing
set WshEnv=Nothing
set FSO=Nothing
 
wscript.quit
 
'************************
'* Usage Subroutine *
'************************
Sub Usage()
On Error Resume Next
msg="Usage: cscript|wscript vbrunas.vbs Username Password Command" /
& VBCRLF & VBCRLF & "You should use the full path /
where necessary and put long file names or commands" & VBCRLF & /
"with parameters in quotes" & VBCRLF & VBCRLF &/
"For example:" & VBCRLF &" cscript vbrunas.vbs /
quilogy\jhicks luckydog e:\scripts\admin.vbs" & VBCRLF & /
VBCRLF &" cscript vbrunas.vbs quilogy\jhicks luckydog " & /
CHR(34) &"e:\program files\scripts\admin.vbs 1stParameter 2ndParameter" & /
CHR(34)& VBCRLF & VBCRLF & VBCLRF & "cscript vbrunas.vbs/
 /?|-? will display this message."
 
wscript.echo msg
 
wscript.quit
 
end sub

With the above script being used, mod_evasive can be configured as follows:

DOSSystemCommand "cscript ra.vbs user password command"

It is considered good practice to add Windows firewall rule for bad IP addresses. Here is a possible solution:

DOSSystemCommand "cscript ra.vbs mod_evasive_user pwd \"netsh advfirewall firewalladd rule \
    name=\"mod_evasive %s blocking\" dir=in protocol=TCP localport=80remoteip=%s action=block\""

Please notice that %s variable contains a string representation of blocking IP.

That’s all

We hope the article will help you create correct configuration and enjoy mod_evasive. But we wish your server never face the situationswhere mod_evasive is needed

Yours sincerely,
HeliconTech Team

We are happy to inform you that Helicon Ape 1.0.0.15 and newer may boast additional functionality and especially mod_hotlink module. And for you to feel its power we offer a brief overview reinforced by real practical examples.

mod_hotlink module is aimed at protecting your web server from people stealing your traffic by directly linking to the content on your server. This is especially important for those having image, video, documents archives and other downloadable content.

After enabling mod_hotlink your site will work as if nothing happened, all search engines and backward links will still be valid, all user’s favorites will remain working. But if someone tries to embed your stuff directly on their site, they will only see an error message or your site’s logo. You can save tons of traffic and thus money. You can even turn these hotlinks into real visitors by redirecting hotlink request to your site’s homepage.

Protection methods

mod_hotlink offers three protection methods each having it’s advantages and peculiarities:

LINK: This is the most comprehensive and powerful protection method. In this mode mod_hotlink edits each link to protected content on your site by adding special cryptographic signature. You specify expiration time for the signature on the expiry of which link becomes invalid (e.g. 30 minutes after it was requested). LINK method is not sensitive to HTTP Referer modifications, disabled cookies or JavaScripts in user’s browsers. mod_hotlink is capable of protecting any file types including streaming media and embedded content.

REFERER: Simply checks HTTP Referer header and rejects all requests to the protected content from unknown sites. You may use white and black lists based on Referer and User-Agent values to allow friendly sites requests and protect against some ugly hacks. This method does not require any configuration or modification to your site and is a convenient way to protect image archives.

REDIRECT: Checks Referer header value but performs a redirect to a temporary signed link instead of returning content. It may be difficult to understand the theory of this method, but the only thing you need to know is that it provides moderate protection level to preserve some embedded content that cannot be protected by REFERER method – content like PDF files, Flash and Media Player movies, audio and so on. Just as in the previous method you don’t have to change anything – just enable mod_hotlink and specify a protection folder.

Examples

Enough of theory and it’s time for examples we’ve promised before. Following are examples for each protection method with thorough explanation.

1. Referer protection method

The task is to protect all images from hotlinking; allow referers from your own site and empty referers.

The solution using mod_rewrite is:

RewriteEngine on
RewriteCond %{HTTP_REFERER} !^$
RewriteCond %{HTTP_REFERER} !^https?://(?:www\.)?yourdomain.com [NC]
RewriteRule \.(jpg|jpeg|png|gif)$ - [NC,F]

The same solution using mod_hotlink looks like:

<FilesMatch \.(jpg|jpeg|png|gif)$>
  HotlinkProtect / [Referer]
  HotlinkAllow Referer ^$
  HotlinkAllow Referer ^https?://(?:www\.)?yourdomain.com
</Files>

How it works:

When a browser makes a request, it passes Referer header that shows the URL of the page with the requested resource.

Say you have a page default.html on your site www.yourdomain.com and there’s also a link <a href=”/img/picture.gif”>picture</a>. If you click on this link, the browser generates the following request:

GET /img/picture.gif HTTP/1.1
Host: www.yourdomain.com
Referer:  http://www.yourdomain.com/default.html

Note! If you directly put the address of the resource into the browser address bar (e.g. http://www.yourdomain.com/img/picture.gif), Referer header is not passed.

• Referer header value is verified for specified file types, i.e. jpg|jpeg|png|gif.
• HotlinkAllow Referer ^$ – allows access if Referer header is empty or missing.
• HotlinkAllow Referer ^http(s)?://(www\.)?yourdomain.com – allows access if Referer header starts with your domain name.
• All others will get “403 Forbidden” for this request.

2. Redirect protection method

Redirect method is usually used to protect .pdf and .swf files as Internet Explorer sets incorrect Referer header for such files when the user clicks “Save As…”

<FilesMatch \.(?:pdf|swf)$ >
  HotlinkSignature password
  HotlinkProtect / [Redirect]
  HotlinkAllow Referer ^$
  HotlinkAllow  Referer ^https?://(?:www\.)?yourdomain.com
</Files>

How it works:

• The user requests the page (e.g. default.html). This page has a tag <a href="/doc/test.pdf">pdf</a>.
• The browser requests http://www.yourdomain.com/doc/test.pdf and passes Referer http://www.yourdomain.com/default.html.
• mod_hotlink checks the rules (given above).
• HotlinkAllow Referer ^http(s)?://(www\.)?yourdomain.com – allows further procesing.
• Instead of granting direct access to test.pdf mod_hotlink performs redirect to a dynamically generated address http://www.yourdomain.com/doc/90f630427786fd84/test.pdf.
• Browser requests http://www.yourdomain.com/doc/90f630427786fd84/test.pdf.
• mod_hotlink verifies signature validity and then grants access to test.pdf.

All this stuff is necessary to bypass noncompliance of some browsers with the standards (especially this refers to Internet Explorer) as they sometimes don’t set Referer header for successive requests to the same resource.

3. Link protection method

Link protection is completely independent on Referer header. But it requires manual links correction on pages.

For this example we need the following files in the root of the site:

• default.html
• .htaccess
• test.pdf

default.html page should have the following tag:

<object  data='xxxxxxxxxxxxxxxx/test.pdf' type='application/pdf' > </object>

.htaccess must be configured as follows:

SetEnv mod_hotlink
HotlinkSignature password
<Files *.pdf>
  HotlinkProtect / [Link]
</Files>

When the user requests default.html mod_hotlink replaces Xs in the tag with specifically generated sequence:

<object data='90f630427786fd84/test.pdf' type='application/pdf'> </object>

How it works:

• The user requests the page (e.g. default.html).
• mod_hotlink replaces xxxxxxxxxxxxxxxx in the tag with dynamically generated signature.
• The browser finds the tag <object data='90f630427786fd84/test.pdf' type='application/pdf' > </object> and makes a subrequest http:// www.yourdomain.com/90f630427786fd84/test.pdf (no matter Referer is passed or not).
• mod_hotlink verifies signature validity and then grants access to test.pdf.

Well, that’s all for today. Hope you’ve got some understnding of mod_hotlink capabilities and see what you can apply them to. Looking forward to your comments after first steps with mod_hotlink. Don’t give leechers a single chance!

Best regards,

HeliconTech Team

Task specification

Protect secret directory in the root of the site via basic authentication. The directory contains index.html file that is displayed upon request http://localhost/secret/.Allow access to this directory to users bill, george and barack. Set passwords for these users.

Enabling necessary modules

For this task we’ll need mod_auth_basic,mod_authn_file and mod_authz_user modules.To enable them you simply need to uncomment corresponding lines in httpd.conf – Helicon Ape global configuration file:

LoadModule auth_basic_module    modules/mod_auth_basic.so
LoadModule authn_file_module    modules/mod_authn_file.so
LoadModule authz_user_module    modules/mod_authz_user.so

This may be accomplished in Helicon Ape Manager.

Editing .htaccess

In Helicon Ape Manager find and click on secret directory in IIS tree. Empty .htaccess will be created and opened for this directory. We’ll add the following lines:

# Authentication type
AuthType Basic
# Name of area authentication will be used for (aka realm)
AuthName "secret area"

# Authentication provider. Here - mod_authn_file
AuthBasicProvider file
# Info for mod_authn_file - path to password file
AuthUserFile c:\inetpub\.htpasswds
# Access will be granted to all authenticated users
Require valid-user

Creating passwords file

Create a new file in Helicon Ape Manager (Ctrl+N). Run the Password generator utility:Options -> Insert User Password… (or F5). Enter user name and password with confirmation.

To paste resulting string with username and password press Ctrl+Enter.Repeat this procedure for all users (remember: bill, george and barack?). Here’s what you should get:

Now save the file with the name specified in AuthUserFile directive: c:\inetpub\.htpasswds.

Testing

For testing let’s put http://localhost/secret/ into the address bar. This may be done faster by right-clicking on secret folder in IIS tree (in Helicon Ape Manager) and selecting “Browse *:80 (http)“.

The browser will prompt us to enter user credentials (username and password).

If the data you entered are correct, the server will give you the content of index.html page from secret directory.

Conclusion

Having performed such unsophisticated actions we have protected secret directory using basic authentication. We have created users by ourselves in c:\inetpub\.htpasswds file and you may add as many of them as you like. These users have nothing to do with Windows users. The name of authenticated user is accessible from server scripts (e.g., ASP or PHP) via AUTH_USER server variable.

Important note!

Authentication data (user name and password) are transfered through the network in non-encrypted form, so it’s not really safe. Secure authentication is either basic authentication via secured http (https) ordigest authentication via http.

• Authentication or authenticity check is a comparison of person’s real credentials with the ones he enters (e.g. login and password).
• Authorization is the process of granting rights to a user (or a group of users) to perform specific actions based on evaluation of necessary parameters.

Helicon Ape (as well as Apache) uses the following authorization and authentication modules:
For authentication types (AuthType directive):

• mod_auth_basic (Basic authentication)
• mod_auth_digest (Digest authentication)

For authentication providers (login/password verification):

• mod_authn_alias
• mod_authn_anon
• mod_authn_dbd
• mod_authn_default
• mod_authn_file

For authorizators (Require directive; verify if authenticated user is allowed to access):

• mod_authz_default
• mod_authz_groupfile
• mod_authz_owner
• mod_authz_user

Authentication and authorization – how they work?

Authentication/authorization process happens in 3 steps:
Receipt of authentication data. On this stage mod_auth_basic or mod_auth_digest is operating. They read Authentication request header and retrieve authentication credentials. For Basic authentication it’s just a username:password pair in base64 encoding. For Digest authentication it’s MD5-Digest of username, password, authname and other parameters that we’ll mention later in more details.
Authentication (verification of authentication data). On this step mod_authn_*** modules verify authentication data. mod_authn_file module, for instance, looks for username:password pair in the text file. The result may be: authenticated successfully (AUTH_GRANTED), access denied (AUTH_DENIED) or user not found (AUTH_USER_NOT_FOUND).
Authorization (rights granting). On this final stage mod_authz_*** modules verify if authenticated user may access the resource. For example, having Require user tomas specified in the config, mod_authz_user will concede access only to tomas user and will deny it for anyone else. If Require valid-user is set, mod_authz_user will grant to access to all successfully authenticated users.

Basic authentication: mod_auth_basic

Now we’ll look more closely at mod_auth_basic module. Here’s the content of .htaccess in c:\inetpub\wwwroot\private\ corresponding to URI /private/:

# Authentication type
AuthType Basic
# Name of zone authentication will be used for (aka realm)
AuthName "private zone"

# Authentication provider. Here - mod_authn_file
AuthBasicProvider file
# Info for mod_authn_file - path to password file
AuthUserFile c:\inetpub\secured\.htpasswds
# Access will be granted to authenticated user john,
# i.e. only john will be authorized
Require user john

Here comes request to /private/. During request processing mod_auth_basic verifies whether requested resource may be accessed by this user. It searches Authentication header in the request. If there’s no such header, module stops request processing and server gives out “401 Unauthorized” response with WWW-Authenticate: Basic realm="private zone" header. Having received such response browser prompts to enter username and password for ‘private zone’. After the necessary data was entered the browser sends the same request with Authentication header. Username and password are encoded using base64 and look as follows:

base64encode('john:secret') -> 'am9objpzZWNyZXQ='

Authentication header looks like:

Authentication: Basic am9objpzZWNyZXQ=

Now during request processing mod_auth_basic will retrieve authentication data from Authentication header:

base64decode('am9objpzZWNyZXQ=') -> 'john:secret'

These username and password are then passed by mod_auth_basic to authentication provider (in the above example it’s mod_authn_file) for verification. In case of successful verification request processing goes on, in the event of failure mod_auth_basic stops request processing and server gives out 401 Unauthorized.

Authentication provider: mod_authn_file

Let’s now have a look at mod_authn_file. This module is an authentication provider for mod_auth_basic and mod_auth_digest. mod_authn_file performs a search of username:password pair in the text file. The file may be created manually or using Password utility included to Helicon Ape Manager (Options -> Insert user password…).



To enable authentication via mod_authn_file module you should specify

# for Basic
AuthBasicProvider file
# or for Digest
AuthDigestProvider file

and path to password file

AuthUserFile c:\inetpub\secured\.htpasswd

Note! Path may be absolute or .htaccess-relative.
This authentication provider is the most used one as it’s fast and easy to use. Besides, password file may be edited manually (e.g. comment out some user using # character). The drawback is slow processing of large password files. For security reasons it is not advisable to put password file to the root of the site.

Authorization: mod_authz_user

mod_authz_user is used to authorize authenticated user. In other words the user that was successfully authenticated (username:password matched) is granted or prohibited access to the requested resource.
This module performs a check of Require directive. The line

Require valid-user

means that the module will authorize (grant access) all authenticated users. The line

Require user john tom

says that the module will only authorize john and de>tom users.

Host-dependent authorization: mod_authz_host

mod_authz_host module stands detached from other authorization modules. During request processing this module is invoked earlier than other authentication/authorization modules and is used to control access based on client host data (host name, address) and request parameters (via environment variables). This is probably the most popular Apache module for access control.
The module uses 3 directives: Order, Allow, Deny. Order directive defines the sequence of rules validation:

Order allow,deny

means that Allow rules will be checked first and Deny rules will be checked after. If no rules are specified, the default action is Deny all. Directive

Order deny,allow

means the opposite. Deny rules will be checked first and Allow rules will be checked after. Default action is Allow all. Allow and Deny directives define the rules for the check:

# allow all clients from  .org zone
Allow from .org
# three identical rules: allow from 192.168 subnet
Allow from 192.168
Allow from 192.168.0.0/16
Allow from 192.168.0.0/255.255.0.0
# deny from the following IPv6 adress
Deny from 2001:db8::a00:20ff:fea7:ccea

The rules are checked until the first match. The rule gets matched if it corresponds to the client info. If Allow rule gets matched, access is granted; if Deny one, access is denied.

User group authorization: mod_authz_groupfile

mod_authz_groupfile module provides athorization of authenticated user based on its membership in some group. Example:

Require group developers managers

Groups and their members are defined in a plain text file: each line starts with a group name: and a space- or tab-separated list of group members. Example:

# file c:\inetpub\secured\groupfile.txt
testers: tom tony
developers: jack john
managers: jane bill

File path is set by AuthGroupFile directive:

AuthGroupFile c:\inetpub\secured\groupfile.txt

The aforementioned syntax of Require directive may be rewritten in the following way:

Require user tom tony jack john jane bill

Utilization of mod_authz_groupfile allows to group users and then apply group-based access policies.

Anonymous authorization: mod_authn_anon

mod_authn_anon provides authentication of anonymous users. The username is usually represented by anonymous (but may be different) and password is user’s email. This email may be saved to log. Together with other authentication providers (e.g., mod_authn_file) mod_authn_anon makes it possible to monitor access of registered users and have the site opened for non-registered users as well. Here’s an example of mod_authn_anon config:

AuthName "Protected area"
# authentication type
AuthType Basic
# list of authentication providers, applied sequentially
AuthBasicProvider file anon
# path to password file for mod_authn_file
AuthUserFile c:\inetpub\secured\.htpasswd
# mod_authn_anon parameters
# can the name fiels be empty or any (on or off)
Anonymous_NoUserID off
# can the password (email) be empty (on or off)
Anonymous_MustGiveEmail on
# check if the password is email (on or off)
Anonymous_VerifyEmail on
# log email (on or off)
Anonymous_LogEmail on
# list of anonymous users
Anonymous anonymous guest www test welcome
Require valid-user

Note! mod_authn_anon can work only with Basic authentication. Email check (enabled by Anonymous_MustGiveEmail on directive) is rather trivial – the line must contain ‘@’ and ‘.’ characters.

Authentication and Authorization fallbacks

mod_authn_default module is the last, fallback module in authentication process. If no authentication module is configured for the requested resource (e.g., mod_auth_basic with AuthType Basic etc.), mod_authn_default simply rejects any authentication data and terminates request prosessing with the result 401 Authorization Required. This may happen if mod_auth_basic is not authoritative (AuthBasicAuthoritative Off – see next chapter) and cannot authenticate the user.
mod_authz_default module is the last, fallback module in authorization process. If no authorization module fired for the request (e.g., mod_authz_user with Require user john), and that is possible if Require contains some unidentified values (e.g., Require unknown requirement), mod_authz_default simply terminates request prosessing with the result 401 Authorization Required.

Authoritative modules

Authentication (mod_auth_basic, mod_auth_digest) and authorization (mod_authz_user, mod_authz_groupfile) modules have directives that define their authoritarianism: AuthBasicAuthoritative On|Off, AuthzUserAuthoritative On|Off, AuthzGroupFileAuthoritative On|Off. These directives entitle consequent modules to continue authentication/authorization process. By default the modules are autoritative – Auth*Authoritative On.
In mod_auth_basic authoritarianism works in the following manner. As a rule each authentication provider listed in AuthBasicProvider directive attempts to authenticate the user and if the user isn’t found by the module, access will be denied saying 401 Authorization Required. Disabling module authoritarianism – AuthBasicAuthoritative Off – in such cases gives other modules (e.g. third-party modules that cannot be defined in AuthBasicProvider directive) a chance to authenticate user and not deny access immediately. Request processing order for these modules is not configured and is defined in their source code.
Disabling authoritarianism for mod_authz_user – AuthzUserAuthoritative Off – allows other modules (e.g., mod_authz_groupfile) continue authorization if mod_authz_user failed to find information about authenticated user. Example:

...
AuthzUserAuthoritative Off
Require user john group developers

mod_authz_user can’t authorize tom user (as only john user is mentioned in Require statement) but as it’s not authoritative, it gives mod_authz_groupfile an opportunity to check whether tom belongs to developers group.
If none of the modules (being non-authoritative) has managed to authorize the user, the last in the queue will be mod_authz_default that will give out 401 Authorization Required.

Conclusion

In this article we tried to cover all basic aspects of authentication and authorization processes, help you gain clear understanding of these matters with our easy-to-grasp examples and tell about some non-evident issues. If someone has found at least some bytes of helpful info in our article, our efforts were not vain, ’cause it’s a great pleasure to be able to do something for you.