Tuesday, July 5, 2016

Kolab SSL Certificate configuration

HOWTO: Secure all Kolab Services

This HOWTO is based on Centos 6 with some notes for Debian 7.
The configuration on Debian(-based distributions) is similar, but the base path for the certifcates storage is different, and Debian already has a group called ssl-cert to which the user accounts for applications like Cyrus IMAP or Postfix are added by default.
On CentOS, this group is called mail.
Warning
This guide provides general information about how to enable ssl/tls and the majority of your kolab services. This guide is by no means 100% complete nor will it get’s updated everytime ciphers or protocols get deprecated.If you want to know more get deeper knowledge about securing a particular service please consult the corresponding software documentation or other projects that take care about hardening your server.
Example:

Prerequisites

Prepare your certificates! You’ll need your certificate, your key, the CA and intermediate CA certificates. This tutorial is based on the StartCom SSL CA. Feel free to use any other Certificate Authority to your liking.
In this case the certificate is a wildcard *.example.org certificate, which makes it easier to cover various hostnames (like smtp.example.orgimap.example.org andwebmail.example.org).
  1. Copy your personal SSL certificates on your new Kolab server.
    On Debian the default location is /etc/ssl/ instead of /etc/pki/tls/.
    # scp example.org.key kolab.example.org:/etc/pki/tls/private/
    # scp example.org.crt kolab.example.org:/etc/pki/tls/certs/
    
    On Debian: Make sure the files have the correct permissions: * /etc/ssl/private/example.org.key: owner root, group ssl-cert and mode 0640 */etc/ssl/certs/example.org.crt: owner root, group root and mode 0666
  2. You should have obtained a CA certificate or CA certificate chain from your SSL certificate issuer.
    If you have not, obtain the root and chain certificates from your certification authority. Make sure the source of the certificate is verifiable and trusted.
    For example:
    # wget https://www.startssl.com/certs/ca.pem \
        -O /etc/pki/tls/certs/startcom-ca.pem
    
    # wget https://www.startssl.com/certs/sub.class2.server.ca.pem \
        -O /etc/pki/tls/certs/startcom-sub.class2.server.ca.pem
    
  3. Lets build some bundle files we can use later
    # cat /etc/pki/tls/certs/example.org.crt \
          /etc/pki/tls/private/example.org.key \
          /etc/pki/tls/certs/startcom-sub.class2.server.ca.pem \
          /etc/pki/tls/certs/startcom-ca.pem \
          > /etc/pki/tls/private/example.org.bundle.pem
    
    # cat /etc/pki/tls/certs/startcom-ca.pem \
          /etc/pki/tls/certs/startcom-sub.class2.server.ca.pem \
          > /etc/pki/tls/certs/example.org.ca-chain.pem
    
  4. Add an SSL group. Only members of this group should be able to access your private key, etc.
    On Debian the usergroup is not needed.
    # chmod 640 /etc/pki/tls/private/* \
        /etc/pki/tls/certs/*
    
    # chown root:mail /etc/pki/tls/private/example.org.key
    
  5. Add the CA to system’s CA bundle.
    Other applications and scripts that want to communicate via SSL should point to the cabundle in case they want check if your own certificate is trusted.
    For RedHat/Centos based systems:
    # cp /etc/pki/tls/certs/startcom-ca.pem /etc/pki/ca-trust/source/anchors/startcom-ca.pem
    # update-ca-trust
    
    On Debian based systems you’ve a different location/command, but the rest is the same.
    # cp /etc/ssl/certs/startcom-ca.pem /usr/local/share/ca-certificates/startcom-ca.crt
    # update-ca-certificates
    

Applications

Cyrus IMAPD

  1. Configure SSL certificates
    Cyris 2.5 (Kolab 3.2+):
    # sed -r -i \
          -e 's|^tls_server_cert.*|tls_server_cert /etc/pki/tls/certs/example.org.crt|g' \
          -e 's|^tls_server_key.*|tls_server_key /etc/pki/tls/private/example.org.key|g' \
          -e 's|^tls_server_ca_file.*|tls_server_ca_file /etc/pki/tls/certs/example.org.ca-chain.pem|g' \
          /etc/imapd.conf
    
    Cyrus 2.4 (Kolab 3.0 + 3.1):
    # sed -r -i \
          -e 's|^tls_cert_file:.*|tls_cert_file: /etc/pki/tls/certs/example.org.crt|g' \
          -e 's|^tls_key_file:.*|tls_key_file: /etc/pki/tls/private/example.org.key|g' \
          -e 's|^tls_ca_file:.*|tls_ca_file: /etc/pki/tls/certs/example.org.ca-chain.pem|g' \
          /etc/imapd.conf
    
    On Debian: Change the paths according to the Debian file structure (replace /etc/pki/tls with /etc/ssl. Make sure that the user cyrus is part of the ssl-certs group.
    Bonus:
    You can get bonus points to disable weak ciphers like so:
    # Cyrus 2.5 (imapd.conf)
    tls_ciphers: EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
    
    # Cyrus 2.4 (imapd.conf)
    tls_ciphers_list: EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
  2. Restart and verify
    # service cyrus-imapd restart
    # sslscan --no-failed localhost:993
    # openssl s_client -showcerts -connect localhost:993
    

Postfix

  1. Configure SSL certificates
    # postconf -e smtpd_tls_key_file=/etc/pki/tls/private/example.org.key
    # postconf -e smtpd_tls_cert_file=/etc/pki/tls/certs/example.org.crt
    # postconf -e smtpd_tls_CAfile=/etc/pki/tls/certs/example.org.ca-chain.pem
    # postconf -e smtp_tls_mandatory_protocols='!SSLv2,!SSLv3'
    # postconf -e smtp_tls_protocols='!SSLv2,!SSLv3'
    # postconf -e smtpd_tls_mandatory_protocols='!SSLv2,!SSLv3'
    # postconf -e smtpd_tls_protocols='!SSLv2,!SSLv3'
    # postconf -e smtpd_tls_mandatory_ciphers=high
    # postconf -e smtpd_tls_eecdh_grade=ultra
    # postconf -e tls_preempt_cipherlist=yes
    # postconf -e tls_high_cipherlist=EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA
    
    On Debian: Change the paths according to the Debian file structure (replace /etc/pki/tls with /etc/ssl. Make sure that the user postfix is part of the ssl-certs group.
  2. Restart
    # service postfix restart
    # sslscan --starttls --no-failed localhost:587
    

Apache2

Apache offers 2 modules that provide SSL support.
The wildly used mod_ssl and mod_nss. Since mod_nss was already installed and loaded through some dependency I’ll cover this.

mod_ssl

This is the prefered way and it’s easier to work with.
  1. Install mod_ssl
    # yum install mod_ssl
    
  2. Set your ssl certificates
    # sed -i -e 's/^SSLCertificateFile.*/SSLCertificateFile /etc/pki/tls/certs/example.org.crt/' /etc/httpd/conf.d/ssl.conf
    # sed -i -e 's/^SSLCertificateKeyFile.*/SSLCertificateKeyFile /etc/pki/tls/private/example.org.key/' /etc/httpd/conf.d/ssl.conf
    # sed -i -e 's/^#?SSLCertificateChainFile.*/SSLCertificateChainFile /etc/pki/tls/certs/example.org.ca-chain.pem/' /etc/httpd/conf.d/ssl.conf
    
  3. Fine tune your ssl/tls ciphers and protocols
    # sed -i -e 's/^SSLProtocol.*/SSLProtocol All -SSLv2 -SSLv3/' /etc/httpd/conf.d/ssl.conf
    # sed -i -e "s/^SSLProtocol/SSLHonorCipherOrder on\nSSLProtocol/" /etc/httpd/conf.d/ssl.conf
    # sed -i -e 's/^SSLCipherSuite.*/SSLCipherSuite "EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA"/' /etc/httpd/conf.d/ssl.conf
    
  4. Create a vhost for http (:80) to redirect everything to https
    # cat >> /etc/httpd/conf/httpd.conf << EOF
    
    <VirtualHost _default_:80>
        RewriteEngine On
        RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
    </VirtualHost>
    EOF
    
  5. Restart and verify
    # service httpd restart
    # openssl s_client -showcerts -connect localhost:443
    

mod_nss

This is an alternative to mod_ssl.
  1. Import your CA into NSS Cert Database for Apache
    # certutil -d /etc/httpd/alias -A  -t "CT,," \
        -n "StartCom Certification Authority" \
        -i /etc/pki/tls/certs/startcom-ca.pem
    
  2. Convert and import your personal certificate into NSS DB
    # openssl pkcs12 -export \
        -in /etc/pki/tls/certs/example.org.crt \
        -inkey /etc/pki/tls/private/example.org.key \
        -out /tmp/example.p12 -name Server-Cert -passout pass:foo
    
    # echo "foo" > /tmp/foo
    # pk12util -i /tmp/example.p12 -d /etc/httpd/alias -w /tmp/foo -k /dev/null
    # rm /tmp/foo
    # rm /tmp/example.p12
    
  3. You should now be able to see all the imported certificates
    # certutil -L -d /etc/httpd/alias
    # certutil -V -u V -d /etc/httpd/alias -n "Server-Cert"
    
  4. Move mod_nss from port 8443 to 443 and configure the certificate that mod_nss should use.
    # sed -i -e 's/8443/443/' /etc/httpd/conf.d/nss.conf
    # sed -i -e 's/NSSNickname.*/NSSNickname Server-Cert/' \
        /etc/httpd/conf.d/nss.conf
    
  5. Create a vhost for http (:80) to redirect everything to https
    # cat >> /etc/httpd/conf/httpd.conf << EOF
    
    <VirtualHost _default_:80>
        RewriteEngine On
        RewriteRule ^(.*)$ https://%{HTTP_HOST}$1 [R=301,L]
    </VirtualHost>
    EOF
    
  6. Restart and verify
    # service httpd restart
    # openssl s_client -showcerts -connect localhost:443
    

389 Directory Server

Note
Unless you want to make your LDAP Service available to other services on other servers you can safely skip this section. There’s no need to enable SSL/TLS if you only use LDAP on localhost.
If you’ve more question please refer the the documentation of the 389 directory server.
Enable SSL/TLS
  1. First you must import your PEM File into the certutil certificate store (identical to Apache with mod_nss)
    # certutil -d /etc/dirsrv/slapd-$(hostname -s)/ -A  -t "CT,," \
        -n "StartCom Certification Authority" \
        -i /etc/pki/tls/certs/startcom-ca.pem
    
    # openssl pkcs12 -export \
        -in /etc/pki/tls/certs/example.org.crt \
        -inkey /etc/pki/tls/private/example.org.key \
        -out /tmp/example.p12 -name Server-Cert -passout pass:foo
    
    # echo "foo" > /tmp/foo
    # pk12util -i /tmp/example.p12 -d /etc/dirsrv/slapd-$(hostname -s)/ \
        -w /tmp/foo -k /dev/null
    # rm /tmp/foo
    # rm /tmp/example.p12
    
  2. Enable SSL Support
    Since all the configuration for 389ds is being done live, changing and adding SSL support will require some LDAP commands to modify the server configuration.
    # passwd=$(grep ^bind_pw /etc/kolab/kolab.conf | cut -d '=' -f2- | sed -e 's/\s*//g')
    # ldapmodify -x -h localhost -p 389 \
        -D "cn=Directory Manager" -w "${passwd}" << EOF
    dn: cn=encryption,cn=config
    changetype: modify
    replace: nsSSL2
    nsSSL2: off
    -
    replace: nsSSL3
    nsSSL3: off
    -
    replace: nsTLS1
    nsTLS1: on
    -
    replace: nsSSLClientAuth
    nsSSLClientAuth: allowed
    
    dn: cn=config
    changetype: modify
    add: nsslapd-security
    nsslapd-security: on
    -
    replace: nsslapd-ssl-check-hostname
    nsslapd-ssl-check-hostname: off
    -
    replace: nsslapd-secureport
    nsslapd-secureport: 636
    
    dn: cn=RSA,cn=encryption,cn=config
    changetype: add
    objectclass: top
    objectclass: nsEncryptionModule
    cn: RSA
    nsSSLPersonalitySSL: Server-Cert
    nsSSLToken: internal (software)
    nsSSLActivation: on
    EOF
    
  3. Next, restart the LDAP service:
    # service dirsrv restart
    # openssl s_client -connect localhost:636
    
  4. You can test if your LDAP over SSL is configured correctly via the openssl s_client -connect localhost:636 command, or just making a query using ldapsearch:
    Test non-SSL connection
    # ldapsearch -x -H ldap://kolab.example.org \
        -b "cn=kolab,cn=config" -D "cn=Directory Manager" \
        -w "${passwd}"
    
    Test SSL connection
    # ldapsearch -x -H ldaps://kolab.example.org \
        -b "cn=kolab,cn=config" -D "cn=Directory Manager" \
        -w "${passwd}"
    

Kolab Components

kolab-cli

With the HTTP Service configured to force SSL communication you must add/update your kolab-cli API url.
# sed -r -i \
      -e '/api_url/d' \
      -e "s#\[kolab_wap\]#[kolab_wap]\napi_url = https://kolab.example.org/kolab-webadmin/api#g" \
      /etc/kolab/kolab.conf

Roundcube/Plugins

Set correct SSL parameters for HTTP_Request2. This will ensure the kolab_files plugin and Chwala can talk over HTTPS.
  1. Change freebusy API url in the libkolab plugin configuration:
    # sed -i -e 's/http:/https:/' /etc/roundcubemail/libkolab.inc.php
    
  2. Change Chwala API url in the kolab_files plugin configuration:
    # sed -i -e 's/http:/https:/' /etc/roundcubemail/kolab_files.inc.php
    
  3. Lets remove the php-close tag line as a quick hack to make it easier for us to extend the /etc/roundcubemail/config.inc.php:
    # sed -i -e '/^?>/d' /etc/roundcubemail/config.inc.php
    
  4. Tell the webclient the SSL iRony URLs for CalDAV and CardDAV:
    # cat >> /etc/roundcubemail/config.inc.php << EOF
    # caldav/webdav
    \$config['calendar_caldav_url']             = "https://%h/iRony/calendars/%u/%i";
    \$config['kolab_addressbook_carddav_url']   = 'https://%h/iRony/addressbooks/%u/%i';
    EOF
    
  5. Additionaly, you can redirect all http traffic to https:
    # cat >> /etc/roundcubemail/config.inc.php << EOF
    # Force https redirect for http requests
    \$config['force_https'] = true;
    EOF
    
  6. Optional: Switch to verified ssl connections
    This will enable the ssl-verification for internal api calls between kolab php components (like roundcube <> chwala). If you care about this you’re free to do so, but don’t forget the parts of python/kolab.conf as well.
    Usually these calls are internal (on localhost) and therefore don’t really need to to trust the ssl endpoint.
    1. Remove old-style SSL configuration parameters
      # sed -i -e '/kolab_ssl/d' /etc/roundcubemail/libkolab.inc.php
      
    2. Enable SSL verification against our extended CA bundle.
      # cat >> /etc/roundcubemail/config.inc.php << EOF
      \$config['kolab_http_request'] = array(
              'ssl_verify_peer'       => true,
              'ssl_verify_host'       => true,
              'ssl_cafile'            => '/etc/pki/tls/certs/ca-bundle.crt'
      );
      EOF

Monday, June 20, 2016

Apache Web server configuraiton

Installation of Apache



Two packages are required for Apache server

  • httpd
  • mod_ssl
  • elinks
httpd package install Apache web server.
mod_ssl is the additional package which required to create secure websites
elinks is the additional package for text based web browser.
If you have yum repository configured use following command to install Apache web server with additional package
# yum install –y httpd mod_ssl
yum-httpd
# yum install elinks
yum-elinks
Or you can do it in more simpler way by using groupinsatall. With following command you can install mandatory and all default packages.
# yum groupinstall "Web Server"
yum-groupinstall-httpd
If yum repository is not configured use rpm command to install necessary RPM. Mount installation disk of RHEL6 in media folder and move in Packages folder.
cd-media-packages
Run following command to install httpd
#rpm -ivh httpd* --nodeps --force
rpm-httpd
Run following command to install mod_ssl
#rpm -ivh mod_ssl* --nodeps --force
rpm-mod-ssl
Run following command to install elinks
#rpm -ivh elinks* --nodeps --force
rpm-elink
Verify that the packages were installed correctly
verfiy-rpm
Run following command to start service when the system boots
chkconfig-httpd-on
Start httpd service
arp-scok-add-fail
httpd service requires at least one active network connection, if it does not detect any active connection it will throw following message
Starting httpd: httpd: apr_sockaddr_info_get() failed for Server
httpd service try to resolve system IP with domain name. It will throw following error, If it fails to resolve.
httpd: Could not reliably determine the server's fully qualified domain name, using 127.0.0.1 for ServerName
In real world DNS Server are used to bind IP address with domain name. In LAB environment where we have limited systems , we can also use hosts file for this purpose.
Open /etc/sysconfig/network
etc-sysconfig-network
Change hostname to Server.example.com and save the file
sysconfig-entry
Reboot the system
reboot
Verify that hostname is changed
ipaddress-hostname-server
Before we update hosts file on server also verify the hostname and ip address of linuxclient
ipaddress-hostname-client
Now on server open /etc/hosts file
etc-hosts
Add entry for server and linuxclient system and save the file
hosts-entry
Verify the network card status
service-network-status
Now restart the httpd service
service-httpd-restart
Default versions of httpd create a generic web server service which is sufficient for most basic operations. Once httpd service is running start web browser and enter a URL http://localhost
apache-test-page-server
Same testing can be done form text based web browser ,If GUI is unavailable.
# elinks 127.0.0.1
elinks-localhost
We got Apache test page which confirm successful Apache configuration.
apache-test-page-command-line
Exit from the ELinks browser. Press Q, and when the Exit ELinks text menu appears, press Y to exit Elinks.
We have successfully installed Apache Web Server. So far its a generic web server service, to make it a regular and a secure web server, we need to configure it.

IPTABLES Firewall rules for web Server

Default installation of Apache web server use port 80 for HTTP traffic and 443 for HTTPS traffic.
You can create custom iptables rule to limit access to one or more networks or systems. For example following rules allows access to every computers on 192.168.1.0 network except one with IP address 192.168.1.25 over port 80.
-A INPUT -m state --state NEW -m tcp -p tcp -s 192.168.1.25 --dport 80 -j REJECT
-A INPUT -m state --state NEW -m tcp -p tcp -s 192.168.1.0/24 --dport 80 -j ACCEPT
We have a well written article for IPTABLES firewall, use that to create custom firewall rules for web server. For this article create rules to allow all traffic on port 80 and 443.
#iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
#iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
iptables-httpd-rules
Save the firewall rules you have just created and restart the iptables service
# service iptables save
# service iptables restart
iptables-save-restart
Until you change the value of DocumentRoot directive in httpd.conf file , Apache looks for web pages in default location /var/www/html directory.
To get your web server up and running, all you need to do is to transfer the web pages or websites in /var/www/html directory.
We will make two websites for testing. RHCE exam does not test your ability to make websites. Its only test your ability to configure and run web server. You can use most simple html web page for testing.
Make two directories mysite1 and mysite2 in /var/www/html folder
mkdir-mysite
Make a sample html page in both directories
cat-index-htm
Our sample websites are ready for use.

Configure SELinux for web server

Use following command to check all associated SELinux Booleans with httpd
getsebool-httpd
Most of these options are self explained and relate to interactions with other services. for example httpd_enable_ftp_server allow Apache to act as an FTP server, which is out of scope for this article.
getsebool-httpd-list
Default enabled SELinux options
BooleansDescriptions
httpd_builtin_scriptingUsed to provide permission for php content
httpd_dbus_avahiSupports access from HTTP services
httpd_enable_cgiAllows HTTP services to execute GCI scripts
httpd_tty_commEnables communication with controlling terminals
httpd_unifiedSupports read/write/execute access by httpd_t files
httpd_enable_homedirs supports access to files from user home directories, default value is off. We will enable it later in this article.
Default enabled options are sufficient to provide basic web services , you do not need to make any changes. But you need to configure SELinux contexts, user context is system_u and the type is http_sys_content_t.
Check the current context of the files
#ls -Z /var/www
#ls -Z /var/www/html
ls-z
We need to set context of any newly created file or directory for the web server user to be able to access it.
Use the chcon command to change the context
#chcon -R -u system_u /var/www/html
#chcon -R -t httpd_sys_content_t /var/www/html/
Verify that all the context fields have been changed correctly
#ls -Z /var/www/html
chcon
Test these websites form linuxclient system [make sure client system have elinks rpm installed]
elinks 192.168.1.1/mystie1/index.htm
start-elinks
Verify the site
elink-test
Close elinks
eixt-from-elink
On window client open browser and type 192.168.1.1/mysite2/index.htm
internet-explore
We have set up Apache web server with default configuration.
Back up the default httpd.conf file on a safe location.
mkdir-backup
Open the /etc/httpd/conf/httpd.conf
vi-httpd-conf
This is the main configuration file for httpd web service and completely usable right out of the box for generic web service.
This file is grouped in three sections and each section is well commented
  • Global environment directives that control the whole operation of Apache server process.
  • Directives that define the parameters of the main or default server, which responds to requests that are not handled by a virtual host. These directives also provide default values for the settings of all virtual hosts.
  • Settings for virtual hosts, which allow Web requests to be sent to different IP addresses or hostnames and have them handled by the same Apache server process.
To make navigation easier, turn on line number ESC Key + : +set nu + Enter Key
set-nu

Host-Based Security

If server have multiple IP address, you can limit the IP address and port on which the server can listen for incoming connection. By default server listen on port 80, but can be update as well.
default-listen
For example to limit server only to listen on IP address 192.168.1.1 with port 80 Set Listen Directive
Listen 192.168.1.1:80
listen-changed
Now Server will listen only on the 192.168.1.1 IP address on port 80 for incoming requests.
Apache also let you configure the hosts which should be allow to access to web server. <Directory> section allow you to specify the hosts base security.
ValueExampleDescriptions
Allow from allDefault value, allow access from all hosts
Allow from [IP Address]Allow from 192.168.1.10To allow only a specific IP or host
Allow from [Host name]Allow from linuxclientTo allow only specific host
Allow from [Network]Allow from .example.comTo allow only example.com network
Allow from [Network]192.168.1.0/24
192.168.1.0/255.255.255.0
To allow only from 192.168.1.0 network
Deny from allDeny access from all hosts
Deny from [IP Address]Deny from 192.168.1.10To Deny only a specific IP or host
Deny from [Host name]Deny from linuxclientTo deny only specific host
Deny from [Network]Deny from .example.comTo deny only example.com network
Deny from [Network]192.168.1.0/24
192.168.1.0/255.255.255.0
To deny only from 192.168.1.0 network
For exam remember
  • If DNS service is unreliable use IP address.
  • When specify domain name to allow or deny from, make sure you include the leading dot[.]
  • When specify a subnet, there is no ending dot[.] at last octet.
  • Order play the most important role, when set allow or deny access.
  • If you set Order allow, deny Only those host names or IP addresses associated with allow directive are allowed access. All remaining hosts or IP address would be denied.
  • If you set Order deny, allow Only those host names or IP addresses associated with deny directive are denied access. All remaining hosts or IP address would be allowed.
Default value is Allow from all
default-allow-from-entry
In our LAB setup we have two clients linuxclient [192.168.1.10], and windowclient [192.168.1.20]. Lets allow access only to linuxclient system.
allow-from-entry
Save the file and restart the httpd service
httpd-service-restart
Try to access same websites again from both client systems. This time linuxclient system would be able to access web server as usual, but on windowsystem you will be denied
windowclient-error

User-Based Security

User based authentication provides a way to allow only certain users or group to access web server.
In exam you can use following options to configure user based authentication.
OptionsDescriptions
AuthTypeDefines the authentication method
AuthNameComment for the users
AuthUserFileFile used to define username and password
AuthGroupFileFile used to define groups
RequireSpecifies the users or groups that can log in
Open httpd.conf file again
vi-httpd-conf
In last practice we have restricted all hosts except one
allow-from-entry
Before we do this exercise lets allow all hosts to access the web server.
default-allow-from-entry
In < directory > section add following and save the file
AuthType Basic
AuthName “Password Restricted Area”
AuthUserFile /etc/httpd/userauthfile
Require user rhceuser01
require-user1
Use htpasswd command to create a userauthfile, that will be holds user accounts.
# htpasswd -cm /etc/httpd/userauthfile rhceuser01
useradd-rhceuser01
-c Create new file and populates it with first user and password.
-m Passwords will be encrypted in MD5 before saving
Do not use -c options for creating subsequent users, otherwise it will completely override the file. Use -c option only first time for first user, from second users do not use -c option.
Restart the web server
service-httpd-restart
Try again to access same sites from client, this time it will ask for user name and password
ask-for-pass
If you cancel or use wrong user name and password, access would be denied
auth-require
Use correct user name and password
type-pass
Upon successful authentication access would be granted
sucess-get

Secure web server with .htaccess file

In previous exercise we have secured entire sites. However in real life you want to allow certain parts of site publicly accessible, while other by only authenticated users. For this we will use .htaccess file.
Open /etc/httpd/conf/httpd.conf file again
vi-httpd-conf
Change AllowOverride directive value to authconfig
allow-override-none
In previous example we did user base authentication
Remove that and save the file
allow-override-authconfig
Make a directory and file under mysite1
mkdir /var/www/html/mysite1/salary
mkdir-salary
Suppose that salary folder contains the salary sheet of employees and we want to allow only hr group to access it.
Create a .htaccess file in the salary folder
#vi /var/www/html/mysite1/salary/.htaccess
vi-htaccess
Add followings and save the file
AuthType Basic
AuthName “Password Restricted Area”
AuthGroupFile /etc/httpd/rhcegroupfile
Require group hr
htaccess-entry
Now only users from hr group, defined in /etc/httpd/rhcegroupfile can assess this.
Create few more accounts
useradd-hruser
Create rhcegroupfile, this file will hold entry for groups
vi-rhcegroup
Add user accounts in hr group and save file
rhcegroup-entry
Update the SELinux context of .htaccess file
chcon-htaccess
Restart the web server
httpd-service-restart
Try again to access site for client, access to other parts of site are allowed except salary
mysite-homepage
To access salary folder you need to provide user name and password
htaccess-ask-pass
Upon successful authentication access would be granted
salary-sheet-htm

httpd.conf file includes a commented directive UserDir public_html just under the default UserDir disable , when it's enabled, it allows users to browse and access the public_html directory within their home folder.
Open /etc/httpd/conf/httpd.conf file
vi-httpd-conf
Comment the default directive
userdir-disable
Uncomment the UserDir public_html directive and save the file
userdir-public-html
Now anyone will have access to web pages that a user puts in his ~/public_html directory. This option can be useful if you want each user to share files over the Web. For this option you need to make users home directory executable for world. You also need to make public_html readable and executable. By default this option is disable because this requires a bit of security compromise. So unless you need to be able to share content out of a users home directory, do not enable this option. If you have to enable it in real world, take all caution in setting up this option.
Create a new normal user
useradd-rh-user1
Make public_html folder under his home folder and create a test file in public_html folder
mkdir-public-html
Change file permission
chmod-public-html
Enable SELinux Boolean associated with home directory
set-bool-http-enable-homedir
Restart the web server
httpd-service-restart
Access it from client system by typing 192.168.1.1/~rh_user1/index.htm
access-home-dir

How to create virtual hosts

Virtual host feature of Apache allows you to define multiple web sites on single IP address. For Virtual hosts configuration following options are required
NameVirtualHostHostname or IP address of the virtual host
ServerAdminEmail address of the webmaster
DocumentRootLocation of the directory, which holds virtual host files
ServerNameURL of the virtual host
ErrorLogLocation for the error log
CustomLogLocation for a custom log
Suppose that we want to host a new website example.com in virtual host.
Make new directory which will hold our new site
mkdir-webdata
Make a sample file in new site
mkdir-webdata-cat-sample-file
Update SELinux context
chchon-webdata
Open main configuration file again
vi-httpd-conf
By default NameVirtualHost directive is disabled
namehost-commented
Enable it
namehost-uncomment
At the end of file in virtual host section add following lines and save the file
<VirtualHost *:80>
ServerAdmin webmaster@example.com
DocumentRoot /webdata/example.com
ServerName example.com
ErrorLog logs/example.com-error_log
CustomLog logs/example.com-access_log common
</VirtualHost>
virtual-host-entry
If you have DNS server configured update the zone files, otherwise update the hosts files . On server open the /etc/hosts file
etc-hosts
Add entry for new virtual host site and save the file
host-entry-server
Restart the httpd service
httpd-service-restart
On linuxclient system you also need to update the hosts file before testing. Open hosts file
vi-etc-host-linuxclient
Add entry for new virtual host site and save the file
hosts-entry-linuxclient
Now use elinks command to browse new site
elink-example-com
Test page confirms that we have successfully configured virtual host.
virtual-host-testing-client

How to deploy a basic CGI application

In this section we will deploy a basic CGI application. RHCE exam objective "Deploy a basic CGI application", does not test your programming skills, so you need not to worry about programming language. You only need to know the method.
Create a directory to hold your web application:
# mkdir /var/www/webapp
mkdir-webapp
Make a new sample perl file
vi-hello-pl
Add following in file and save the file. [This will make a sample perl script to print hello, world. Based on Apache manual]
#!/usr/bin/perl
print "Content-type: text/html\n\n";
print "Hello, World!";
hello-pl-entry
Update file permission and SELinux context
chmod-chcon-webapp
Open configuration file
vi-httpd-conf 
At end of file add following and save the file
ScriptAlias /webapp "/var/www/webapp"
<Directory "/var/www/webapp/">
Options ExecCGI FollowSymLinks
Order allow,deny
Allow from all
</Directory>
cgi-bin-entry
Restart the web server
httpd-service-restart
On client now you can access this CGI application.
webapp-testing

Configure secure virtual host

In this last section of tutorial we will configure a secure virtual host with self signed certificate. Make a directory to host our secure site
mkdir-secure-host1
Make a sample index.htm file in it
cat-secure-index
Change file permission and Update SELinux context
chcon-secure
Open main configuration file /etc/httpd/conf.d/ssl.conf
vi-ssl-conf
Make sure Listen Directive remain on
listen-443
Add new Directive NameVirtualHost *:443 just above the <VirtualHost _default_:443> and replace _default_ with * in <VirtualHost _default_:443> tag.Uncomment the DocumentRoot and ServerName directives.
namevirtualhost
Change the value of directives and save the file
ssl-uncomment-documentroot
Move in certificate holder directory /etc/pki/tls/certs and use genkey command to generate new certificate and private key for secure site
genkey
Select Next and press enter on Keypair generation window
keypair-next
During the exam always choose minimum available key size. Even smaller key size can take up to several minutes and in exam every minute is precious. Select 512 and move to Next tab and press enter
choose-key-size
Wait while key generates
genrating-key
Select No and press enter on Generate CSR window
genrate-crs
Keep default details and select Next and press Enter
details-for-certificate
We have sucessfully created the certificate ,now we to update the hosts file on server
host1-host-entry
Restart the httpd service
httpd-service-restart
On client updated the hosts file
linuxclient-host1-entry-host-file
To test secure site open the web browser and type https://host1.example.com/index.htm in URL
untursted-connection
You will see Untrusted connection screen Unless you purchase an actual certificate from a certificate authority (CA) such as VeriSign and Thawte. For RHCE exam we do not need third party certificate, as we have self signed certificate. Click on I Understand the Risks and Click on Add Exception
add-exception
Click on confirm security exception
confirm-security
Test page confirms that we have successfully configured the secure virtual host
secure-test-page
To test secure sites form elinks test based browser we need to comment two standard directives
open /etc/elinks.conf file
linuxclient-vi-elinks-conf
You need to comment these directives
linuxclient-elinks-conf-uncommented
Comment them and save the file
linuxclient-elinks-conf-commented
Now you can access secure sites form elinks as well
linuxclient-elinks-test-host-index
Test page confirms our secure web hosting
linuxclient-elinks-test-page
When you restarts the httpd service, restart process actually stop the service from running before starting it again. This process hardly take few seconds that is ok for exam purpose but in real life where thousands of people are hitting your site, you can't afford any outage even its in seconds. In that situation you can use reload option which allows the main configuration to reread without the actually bringing service down.
#service httpd reload
One more important option which should know for real world is graceful
#service httpd graceful
This option reread the new configuration file without disconnecting any currently connected users. Only drawback of this option is that the currently active connections use the old configuration file until they terminate their connection and reconnect.
One more cool options is configtest, when used , service parses the main config file for any errors and reports back if something is found. It's your helping hand during the exam to detect any syntax errors in configuration file.
# service httpd configtest
Syntax OK
If this command detect any syntax related error it return with that, otherwise it return with Syntax ok.