Secure Access by wuyunqing


									                      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
   – 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
   – encryption –taking data and placing it in a code that is
     [nearly] unbreakable
      • we explore each of these in chapter 9
• 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
   – a file that stores all known usernames and passwords
   – possibly an encryption program to encrypt and decrypt
• 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
       • 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
• 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
   – when using –b, place the password on the command line as another
       • 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)
• 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
<Directory /usr/local/Apache2/htdocs/secure>
 AuthType Basic
 AuthName “cit 436”
 AuthUserFile /usr/local/Apache2/password_files/cit436.passwd
 Require valid-user
                            In this example, we use the htpasswd
 Order deny,allow           program to set up the file cit436.passwd
 Deny from all              in the directory /usr/local/Apache2/password_files
 Allow from     (notice that this is not under DocumentRoot)
 Satisfy Any
</Directory>                When the user is asked to authenticate, they
                               are told that the domain is “cit 436”

                               However, if they are at IP address
                               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
              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
• 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
   – 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,
   – 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
   – 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
• 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
• 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
   – 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
      • 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
   – that is, can you trust the site in spite of the incorrect or lacking
       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

To top