Apache Access Controls

1. Apache Access Controls

2. Ways to control • Allow/Deny access control • By IP • By domain name • Password • Apache managed passwords • Realms

3. Allow / Deny Control

4. Allow Deny Order • Three basic directives • Order • Allow and Deny directives • Order states which to process first (regardless of physical order) • Subsequent directives provide exceptions • Define by IP or domain name • Reverse dns must be working for dns restriction • Easiest to see with examples

5. Default Rules ALLOW DENY Deny is the default DENY ALLOW Allow is the default

6. Example 1 Default is to allow, so lack of a rule says to allow access Search through the file and apply all deny directives first Order deny,allowDeny from allAllow from dev.example.com Begin by denying everyone Later directives provide exceptions, so anyone from dev.example.com WILL be allowed access Only dev.example.com allowed!

7. Example 2 Default is to deny, so lack of a rule says to deny access Search through the file and apply all allow directives first Order allow,denyAllow from cnu.eduDeny from pcs.cnu.edu Begin by allowing all cnu.edu Later directives provide exceptions, so anyone from pcs.cnu.edu will be denied access xyz.cnu.edu -> allowed abc.pcs.cnu.edu -> denied abc.com -> denied (default)

8. Example 3 Default is to deny, so lack of a rule says to deny access Search through the file and apply all allow directives first Begin by allowing all cnu.edu and Various subnets Order allow,denyAllow from cnu.eduAllow 216.17.28 Allow 139.117.0.0/255.255.0.0 Deny from pcs.cnu.edu Later directives provide exceptions, so anyone from pcs.cnu.edu will be denied access xyz.cnu.edu -> allowed abc.pcs.cnu.edu -> denied abc.com -> denied (default) 217.17.38.17 ->not allowed (in 38 not 28) 139.117.2.1 -> allowed (if one of those IPs are from the “pcs” domain-> deny)

9. Password Control

10. Controlling access via passwords • Not the system password • Internally managed password files • Files can be located anywhere • Each directory will dictate which file to use for authentication • Can be managed by the individual if the sys admin allows.

11. Steps to use passwords • Create a user and password entry in the password file of your choosing • Associate the password file with a directory (, file or location) • Indicate whether you want encrypted or plain text exchange • Further restrict the set of users (more than what is in the file) if desired

12. Example 1. Create password in file {Directory /home/dgame/www/private} AuthType Basic AuthName "Restricted Files“ AuthUserFile /usr/local/any/where/passwords Require user dgame {/Directory} # htpasswd -c /usr/local/any/where/passwords dgameNew password: mypasswordRe-type new password: mypasswordAdding password for user dgame # 2. Associate file with directory 3. Select plain text password exchange 4. Restrict users (here to only allow dgame)

13. Create a password # htpasswd -c /usr/local/any/where/passwords dgameNew password: mypasswordRe-type new password: mypasswordAdding password for user dgame # • htpasswd is probably in /usr/local/apache/bin • This is a utility available for password creation. • Use the –c option to create the file the first time, but after that do not include the –c so that the new password will be appended • Inclusion of multiple password files can create a management problem • One file can be used to manage many directories but should be placed in a location separate from the protected directory. • Must be readable by the web server • Each user would likely have his/her own file

14. Associate with a directory {Directory /home/dgame/www/private} … {/Directory} • Refer to the instructions on • Directory • Directory match • Files • Files match • Location • Location match • This will help detemine where to put this specification • If for a user, one can also manage by using .htaccess files for providing specifications.

15. Example .htaccess AuthName "Test: Password Required" AuthUserFile /home/dgame/wwwpassfile Require user justthisuser

16. Password authentication mypassword OR Browser Server #45%werR8234 • Client must be able to support the encrypted approach • All clients can’t • Use either • AuthType Basic • AuthType Digest

17. Restricting Users Require user dgame bsmith Only these two users can access the directory regardless of what is in the password file. Require valid-user Any user in the password file can be accepted. Require group facultygroup administrativegroup Any user in the listed groups can be accepted. Must have a file to define groups AuthGroupFile /home/mygroups Text file formatted as: mygroup: billy mary bob sally

18. Realms • Define part of the prompt for the user • Any other part of the system in the same realm will automatically test the previous password. • Not sure if realm prompt managed by client or server {Directory /home/dgame/www/private} AuthType Basic AuthName “Test: Password Required“ AuthUserFile /usr/local/any/where/passwords Require user dgame {/Directory}

19. Example {Directory /home/dgame/www/private} AuthType Basic AuthName “Test: Password Required“ AuthUserFile /usr/local/any/where/passwords Require user dgame {/Directory} BUT IT’S MORE THAN THAT!

20. How I think it works 1. AuthName “Test: Password Required“ Browser Server 2. Check List of old Name/pass And send If already authorized 3a. Send if already authorized or 3b.2. Send prompt response 3b.1. Prompt user (shown in previous overhead) user

21. More sophisticated Password Management • Use dbmanage utility • Provides convenient hooks to interact with applications in different languages • dbm formats vary some but libraries are widely available • Use AuthDBMUserFile directive

22. Unix Permissions • The web server runs as a user, typically not root. Assume that it is “http”. • Remove general read permissions from the protected directory. If you do not, anyone who has an account on the machine can “cd” to it and view files. • Determine the GROUP of http and set your files to be in that group. • Give that group general read permissions.

23. Example {dgame@puritan:~ } cd www {dgame@puritan:~/www } ls -l test total 2 -rwxr-x--- 1 dgame nobody 260 Feb 9 11:09 home.html {dgame@puritan:~/www } cd test {dgame@puritan:~/www/test } ls -l total 2 -rwxr-x--- 1 dgame nobody 260 Feb 9 11:09 home.html {dgame@puritan:~/www/test } On our Hunter Creech network, the web server runs as “nobody”. The nobody user is also in the “nobody” group. These files and directories are modified to be in the nobody group. Also notice work permissions as none.