translated by Google

Machine-translated page for increased accessibility for English questioners.

Page in original, Czech language.
This page can be used as a stepping stone in implementing site access restrictions. If you are serious about security, it is necessary to study the issue in more detail, at least on the Apache website .

Password protection of sites

Create a file in the directory whose contents you want to password protect .htaccess . Include the following items in it:

First, we force an encrypted connection so that the password is not transmitted as plain text. We will achieve this with a directive SSLRequireSSL : 

SSLRequireSSL
The second option is to redirect unencrypted requests to encrypted: 
RewriteEngine On
RewriteBase /
RewriteCond %{HTTPS} !=on                             
RewriteRule ^.*$ https://%{SERVER_NAME}%{REQUEST_URI} [R,L]
The next content of the file will then be: 
AuthName "
jmeno oblasti"
AuthType Basic
AuthUserFile 
/cesta/k/souboru/s/hesly
require valid-user
Item AuthName specifies the name of the protected area that will be displayed to accessing clients when querying the password (the multiword string must be enclosed in quotation marks ). Item AuthUserFile refers to a file where all allowed accessnames and passwords are defined. To illustrate, suppose that .htaccess with the following contents is located in the directory /home/xnovak99/public_html/censored : 
AuthName "Libri prohibiti"
AuthType Basic
AuthUserFile /home/xnovak99/public_html/.htpasswd
require valid-user
It is then specified to access the files in the subtree security (URL starts with https://www.fi.muni.cz/~xnovak99/security) is authorized only after entering a valid name and password according to the data in the file .htpasswd .

File linked through AuthUserFile has the following text form: 


jmeno1: 
zakodovane_heslo1

jmeno2: 
zakodovane_heslo2
...
Passwords for individual valid login names must be encoded with a classic Unix cipher crypt ; to generate it, for example, a Perl or C function can be used crypt() or utility htpasswd . Example of the contents of the password file: 
bond:Xy9KgHmOmCESc
trubka:qWKFFmkF7LPjQ
Therefore, if an applicant for a protected area reports with the name "bond" and the password "James" or with the name "trumpet" and the password "dcs.48", he will be granted access.

The password file must be accessible to the WWW server, ie readable by the user apachefi . In your case, therefore, it can be implemented by authorization r for others and must be in a directory that has been at the root ( / ) through permissions x for others. A safer way to use an ACL is: setfacl -m u:apachefi:r .htaccess . Of course, the same is true for files in a password-protected area - they must be accessible on the file system, as must insecure sites. It is therefore clear that this type of protection only applies to people who do not have a Unix account on FI. If you want to protect something from these users, you can use the mentioned ACL or other more sophisticated methods.

Kerberos

One of them is the use of Kerberos. This system is used on faculty machines or on Fadmin to authenticate users. There is nothing stopping you from using it to authenticate users of your site. The only restriction is that it must have a valid login. The password will be used by the faculty.

Configuration example .htaccess : 
AuthType Kerberos
AuthName "Kerberos Login"
KrbAuthRealm FI.MUNI.CZ
KrbMethodNegotiate off
KrbVerifyKDC on
Krb5Keytab /etc/httpd/kerberos/httpd.keytab
require user login1@FI.MUNI.CZ login2@FI.MUNI.CZ
Use require valid-user would successfully authenticate anyone with a valid FI login.

Kerberos + LDAP

If you want to make the page available to members of some faculty groups (there must be a Unix group, see aisa$ getent group ), LDAP authentication must be used (authentication remains Kerberos).

The configuration for Kerberos looks the same as in the previous example, just add this line: 

KrbLocalUserMapping on

LDAP authorization configuration: 

AuthLDAPUrl "ldaps://ldap.fi.muni.cz ldap1.fi.muni.cz/ou=People,dc=fi,dc=muni,dc=cz?uid"
AuthLDAPGroupAttribute memberUid
AuthLDAPGroupAttributeIsDN off

Access to groups or individual users can then be added using a combination RequireAny , Require ldap-user and Require ldap-group , for example 

<RequireAny>
    Require ldap-group cn=
JMENO_SKUPINY,ou=Group,dc=fi,dc=muni,dc=cz
    Require ldap-group cn=
JMENO_JINE_SKUPINY,ou=Group,dc=fi,dc=muni,dc=cz
    Require ldap-user 
LOGIN_UZIVATELE
</RequireAny>

Site access control by client address / name

Create a file in the directory that you want to treat this way .htaccess and add the following lines to it: 

Require ip 
IP1 IP2 …
Require host 
hostname1 hostname2 …

Only clients explicitly stake out using Require … they will have access to the given site subtree. There can be any number of parameters (separated by a space). The parameter can be

  • For Require ip
    • IP address: 10.0.0.240
    • address prefix: 10.0.0 (same meaning as 10.0.0.0/24 )
    • IP address with mask: 10.0.0.0/255.0.0.0
    • CIDR syntax address: 10.0.0.0/8
    • IPv6 address: 2001:718:801:235::b
    • IPv6 address with mask: 2001:718:801:230::/64
  • For Require host
    • domain name or its suffix: fi.muni.cz (therefore corresponds to clients " fi.muni.cz "," node2.fi.muni.cz "but does not match" fifi.muni.cz "- an imaginary dot is always considered before the specified suffix, unless it is explicitly stated there)

If, on the other hand, you need to allow access to everyone except some selected machines / domains, a directive is available <RequireAll> . Restrict access from the domain nekde.cz would look like this: 

<RequireAll>
    Require not host nekde.cz
    Require all granted
</RequireAll>

For more detailed information see Apache 2.4 documentation .