Secure Access

1. Secure Access • There are three distinct forms of secure access • authentication – verifying a user’s identity • user log in via some mechanism (typically account name and password) • authorization –verifying that the user should have access to the given resource • should this user be able to access the requested file? • we control access in Linux through file permissions • this won’t help in apache where either a file is accessible to the world or not (too limited) • we can also control access via allow/deny but again, this is too limited as we can only enforce it based on partial or full IP address • encryption –taking data and placing it in a code that is [nearly] unbreakable • we explore each of these in chapter 9

2. Authentication • Simplest and most common mechanism for authentication is to provide each user with an account name & password • Linux has a number of readily available programs for this • our decision of which to use will be based in part on how secure we want to make the password file and whether we need a full blown database or can get back with a simple encrypted text file • the database would make for more efficient access when we are dealing with hundreds or thousands of passwords • We will need • a program that can get the user to input their username and password • a file that stores all known usernames and passwords • possibly an encryption program to encrypt and decrypt passwords • We will study several programs but we start with the simplest first

3. Basic Authentication • You can get simple authentication using the built-in module mod_auth_basic which has the following directives • AuthType Basic • in this type, while passwords are encrypted in the password file, the password file is simple text, which might make for an inefficient access if there are a lot of entries, and the password is not encrypted when transmitted over the Internet • AuthName name • name is the “domain”, this is presented to the user in a pop-up window so the user knows which domain is asking for user name and password • if the name contains spaces enclose it in quote marks as in “CIT 436” as opposed to CIT 436 • AuthUserFile filename • the user password file, which should not be stored in the same directory as the files to be accessed (in fact, it shouldn’t be stored anywhere under DocumentRoot) • if the file is not in the same directory, then the filename must be specified as a full path starting from Linux root (/) • These directives are placed in a directory container or .htaccess file) of the directory with files requiring authentication

4. AuthUserFile • The basic authentication uses the linux program htpasswd to interact with the AuthUserFile • part of the mod_authn_file module (part of Apache’s base) • file must already exist and have the user names and passwords in it • the htpasswd program by default uses Linux’s crypt( ) program to encrypt/decrypt passwords in the file • The program works like this: • htpasswd [params] filename username • the param –c creates the file and inserts username into it • the user is then asked to enter a new password and verify it • if the file already exists, it is overwritten, and the program does not check first to see if you want to overwrite it • without a parameter, htpasswd assumes the file already exists and the user is asked for a new password • if the user already exists then their password is changed, otherwise the new user is added to the file

5. More on htpasswd • Other parameters for htpasswd include • –m to use MD5 encryption • –s to use SHA encryption • –p to use a plain text file with no encryption • Apache itself cannot be used to add new users names and passwords to the password file, it is done through the htpasswd program, so you need additional functionality, a script • to call htpassword from a shell script, add the parameter –b (for batch) • when using –b, place the password on the command line as another parameter • the shell script will input the user’s name and password, and add them to the script instruction as parameters • this can be a problem in that this information can be seen from the command line prompt, so you want to make sure that the script is running on a secure computer, perhaps with the monitor off! • The htpassword program, when run from a script, returns a status code which your script might use for error checking (see page 250)

6. Authorization • So now we have implemented authentication – we can obtain the user’s account name and password • how do we control access to the files in the directory? • we need authorization • In apache, this is done by the Require directive • Require authorization_type [authorization_list] • where authorization_type is one of user, group, or valid-users • if you use either user or group, then you follow it with a list of specific usernames or groupnames • Require user foxrfrankcnewellgwaldenj • Require group cit436 cit370 cit383 • using valid-users means that any user who is properly authenticated can gain access, this would be the most typical approach • Allow/Deny statements can also be included in the <Directory> or .htaccess, in which case you have to add a Satisfy directive • Satisfy All – user must pass both Require and Allow • this is the default if the Satisfy directive is omitted • Satisfy Any – user gains access if they satisfy either Require or Allow

7. Example <Directory /usr/local/Apache2/htdocs/secure> AuthType Basic AuthName “cit 436” AuthUserFile /usr/local/Apache2/password_files/cit436.passwd Require valid-user Order deny,allow Deny from all Allow from 10.11.255.1 Satisfy Any </Directory> In this example, we use the htpasswd program to set up the file cit436.passwd in the directory /usr/local/Apache2/password_files (notice that this is not under DocumentRoot) When the user is asked to authenticate, they are told that the domain is “cit 436” However, if they are at IP address 10.11.255.1 then they gain access without having to authenticate NOTE: we could move the entire contents of the above (except for the <Directory> tags) into an .htaccess file for this directory, but we would need to include the AllowOverride AuthoConfig statement in our httpd.conf file

8. Digest Authentication • The basic authentication is convenient but not secure because passwords are sent over the network as normal text (not encrypted) • the crypt( ) program, used by htpasswd, only encrypts the passwords in the file itself • You could choose instead to use shtml and SSL but that solution is not always practical • we cover these later in this chapter • A better solution is to use Digest authentication instead of Basic (AuthType Digest) • this is available in the mod_auth_digest module • this requires that you also add directives for AuthDigestDomain and AuthDigestProvider • AuthDigestDomain URI [more URIs] • AuthDigestProvider filename • Digest uses the MD5 encryption algorithm

9. Using a Database for Passwords • If the htpasswd file gets too large, it becomes inefficient to access as a text file • It is better to create an actual database • for this, you need the mod_authn_dbm module • this module provides the AuthDBMUserFile directive (used in place of AuthUserFile) and AuthBasicProviderdbm (that is, specify dbm as the argument to this directive) • Because the file accessed is a database and not a normal text file, we have to create and manipulate it through a program other than htpasswd, use htdbm • Linux also provides dbmmanage but this is considered obsolete • The form is much like htpasswd • htdbm [params] filename username • Params are similar to htpasswd (see page 252) • -b for command line -c to create • -m to use MD5 (the default) -s for SHA • -p for a plain text database file • NOTE: we are skipping the section on Lightweight LDAP

10. Secure Access Writing to Servers • It makes little sense to have secure access to obtaining files from the server if our server is not well protected • someone could hack into the server and gain access to password files or secure files directly • Therefore, the web administrators and the web developers need to access the server through secure means • ssh – secure shell – to manage the server remotely • scp – secure copy – to upload content to the web server • sftp – secure ftp – older than scp and so more primitive, but some development (programming) tools may not support scp so sftp can be used • These secure programs use encryption on data transmitted between client and server • Additionally, to prevent hacking into the server, typical security measures should be in place • strong passwords and policies that require frequent password changing • firewall software or hardware • system administrators who monitor for suspicious behavior

11. Encryption Technology • Any form of encryption requires a key • the key is some mathematical formula + numeric values that take an input file and transform it into a new file • the new file is transmitted and if intercepted, looks like nonsense • it requires a key to decrypt (transform back) the file to be read • for encryption to be useful, the key must be chosen so that decrypting the transmitted file is impractical (takes too much time) and thus the code is “unbreakable” • with modern encryption technology, breaking a code could take a supercomputer trillions of years • The problem is that if a sender has the key to encrypt, the sender can also use the key to decrypt • this is the case with private key encryption • and so the key should only be shared among a few, trusted, individuals • this approach does not work in general for such applications as ssh and sftp

12. Public Key Encryption • The idea here is that there are two keys • the public key is only used for encrypting • the private key is only used for decrypting • Given the public key, you cannot decrypt the message nor create the private key • the private keys are generated first, and from them, we can create the public keys • Thus, anyone can have the public key to encrypt their messages and send them securely • if intercepted, no one should be able to break the code • only the server has the private key for decryption • Public key encryption was first discussed (called asymmetric key encryption) in the late 1800s and the first known algorithm published in 1976 but it was not used for telecommunications until 1997 • it has permitted secure communication which was needed for E-commerce to take place over the Internet

13. How It Works: An Example • Key: 1, 4, 6, 12, 25, 51, 105, 210, 421, 850 • notice that each number is greater than the sum of all previous numbers (e.g., 12 > 1 + 4 + 6) • Given a message in binary, break the message into 10-bit segments • e.g., 1001100001 0010011010 … • compute the sum of the numbers in the key for each 1 bit • 1001100001 = 1 + 12 + 25 + 850 = 888 • 0010011010 = 6 + 51 + 105 + 421 = 583 • transmit each integer value • Now the recipient receives 888, 583, … • to decrypt, find which numbers in the key equal the value • this is trivially easy since the numbers are increasing so that one value is >= the sum of the previous values • 888 must have an 850 since 421 + 210 + 105 + … + 1 < 850 • Therefore, we know 888 has 850 in it, leaving 38, so it must also have a 25 in it, leaving 13, so it must have a 12 in it, leaving 1, so it must have a 1 in it, 888 = 850 + 25 + 12 + 1, these are the only four values in our key that can sum up to 888

14. Public and Private Key Numbers • The list of numbers on the last slide make up the private key • We now need to create the public key • we do this from the private key by taking each private key number, multiplying it by a special value and modding it by another value, our two “special values” will be 642 and 2311 • for instance, we do 850 * 642 % 2311 = 304 • we do this for each value in our private key giving us a public key of 642, 57, 1541, 771, 2184, 388, 391, 782, 2206, 304 • notice this list does not have that same property as the previous list – any given number is no longer > the sum of all prior numbers • now we use the above numbers to encode a 10-bit segment • 1001100001 becomes 642 + 771 + 2184 + 304 = 3901, so we transmit 3901 instead of 888 • we cannot decode 3901 using the above sequence of numbers because there is no “easy” way to figure out the sum since the keys’ numbers are no longer in that increasing order • it would take 1024 (2^10) different combinations to figure it out

15. Continued • We want to apply the private key to decode the message but the numbers were encoded using a different key • we have to first transform each received number • take each transmitted number, * 18 and % 2311 • this computed number is “decoded” using the private key list • 3901 * 18 = 36018 % 2311 = 888 • we decode 888 using the private key (see two slides back) • The numbers 642, 2311 and 18 are “secret numbers” that make the code work • we keep these numbers and our private key secret but we can share the public key list with anyone/everyone • What makes public key encryption so hard to break? • this is a trivial example because a 10-bit key is easy to break (1024 different combinations per number transmitted would only take a computer milliseconds at most) • most public key encryption today uses 128 to 200 bit keys which would require 2^128 to 2^200 combinations to break! • 2^200 is 10^60, that is, 1 followed by 60 zeroes!

16. In Spite of Secure Communication… • There will no doubt be attempts to hack into your server, so there are other precautions you can take • change the port used by ssh • defaults to 20 but you can change this by modifying the port number in the /etc/ssh/sshd_config file • restrict who can access the server using scp/sftp/ssh by restricting IP addresses in your firewall over specific ports • unfortunately, if your IP address is generated dynamically, the server may not recognize you • the SOCKS program can get around this problem through the use of “proxy circuits” • port knocking is like a combination lock in that it can accept packets if they are sent over a certain combination of ports even if the sender has an unknown IP address • in this way, the developer or web administrator can still communicate through a firewall without using something like SOCKS

17. HTTPS • In order for users of a web site to send confidential information (e.g., credit card numbers), the user must have some way of being assured that the web site is legitimate and also needs to know the web site’s public key • This combination of tasks is done through the use of certificates • the communication with the web server and the sending of a certificate still use public key encryption but now we have to take an extra step and generate a certificate for the web site • this is done through some certificate authority on the Internet, a company whose job is to generate certificates • a web client connecting to an HTTPS site is sent that server’s certificate which includes a “signature” by the certificate authority that includes the web site’s name so that your computer can ensure that the certificate and the site match

18. Apache Support for Certificates • This is done through the mod_ssl module • if you are running virtual hosts who are running https, then you need to have a different certificate for each host • To request a certificate, you must send a certificate-signing request to a certificate authority • using openssl, create an encryption key pair (public & private keys) along with the request (which will contain information about your company) • encrypt the private key • delete the unencrypted private key • change the private key’s permissions to 400 • send the request to the certificate authority, which will return a certificate to you • openssl will allow you to view the private key and/or the certificate, see pages 261-264

19. How it Works • First, you have to have your certificate signed • create a certificate that includes your website’s name and possibly other identification information • for instance, location • you generate a public and private key • you submit your certificate and the public key to a certificate authority • the CA encodes your certificate with the public key along with your company’s name (and other identification information) and its own signature • now you have a signed certificate • A client (user) submits an https request to your site • Your site responds by sending both your signed certificate and the page’s content to the client • the client browser now examines the certificate to decide if the page should be displayed or not

20. Self-Signed Certificates • You can create your own self-signed certificate rather than one signed by a certificate authority • this might be useful if your certificates are used only “in house” • for instance, gaining access to NKU’s VPN where you do not need an authority, but both sides must agree to the legitimacy of the communication • this is also the case when logging into our vSphere server • if you plan on doing e-commerce from your site, a self-signed certificate will not be appropriate • The process is somewhat similar to the previous process: generate a private key, generate a certificate, enter a pass phrase for the certificate and “sign it” with the previously generated key • see pages 264-266 for the specific process

21. Authenticity for Certificates • Is the certificate signed by a legitimate CA? • Has the certificate expired yet? • certificates have lifetimes, which are established when created • temporary (they expire after 1 usage) • x days (usually 1 year) • unlimited or permanent • usually you would create a certificate that does not expire for some time to make it more efficient, but is not unlimited because you may at some point want to change certificates (e.g., names) • Does the certificate contain the proper identification information (is it the correct name for this site?) • If everything passes inspection, your browser can display the page’s content • if not, the user is asked if the page’s content should be displayed anyway • that is, can you trust the site in spite of the incorrect or lacking certificate?

22. Name-based Virtual Hosts • Recall in chapter 6 we examined virtual hosts • a name-based host means that all virtual hosts map to the same IP address and that the URL will contain a specific IP alias, not an IP address • as opposed to the IP-based host where each alias maps to its own unique IP address • You cannot run SSL on a virtual host using the name-based approach • because the header will be encrypted and so the apache server will not know which virtual machine the header is intended for • instead, each virtual host must have a unique IP address as seen in the incoming URL which is not encrypted