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

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

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

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

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)

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 foxr frankc newellg waldenj• 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

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 htpasswdprogram to set up the file cit436.passwdin 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.1then 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

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

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 AuthBasicProvider dbm (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

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

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

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

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

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

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!

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

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

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

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

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

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?

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