Secure your Linux Web Server

Your Internet or intranet websites often prompt visitors to enter information such as their e-mail address, login-password or credit-card number. Such details are usually captured using HTML forms and sent to a server-side or CGI (Common Gateway Interface) script for processing. The alarming fact is that all the data that flows between the Web browser and Web server is in plain text. Moreover, the password field on an HTML form, which elegantly masks (using asterisks) the typed password, cannot protect the password data on transmission. It protects the password from just a prying eye, not from a prying sniffer. All one needs to do is to launch a sniffer to get to know all the sensitive information and authentication tokens.

The solution? Encrypt the password or sensitive information before dispatching it to the Web server. At times, even the server may send back sensitive information to the browser, which again must be encrypted. The de-facto solution to achieve all this is to SSL (Secure Socket Layer)-enable your Web server and browser. The latest browsers support SSL, which leaves us with setting up SSL on the Web server. 

SSL in a nutshell 



If the Web server and the client (browser) are SSL enabled, then data between them is never transmitted in clear text. An SSL communication between the server and the browser involves asymmetric (public key) as well as symmetric (private key) encryption. 

At the beginning of an SSL transaction, public-key encryption is used to create a private key for the rest of the transaction. This is because private-key encryption, though less secure, is faster that public-key encryption. In asymmetric encryption, data encrypted using a public key can be decrypted only through a private key. 

During the initial phase of an SSL connection, the server generates a public-private key pair and sends the public key to the client through a digital certificate. A digital certificate, usually issued by certificate authorities, proves that the public key in the certificate is indeed from an authentic server. The browser uses the public key to encrypt a random chuck of data (call it D1) and sends the encrypted data back to the server. 

The server, which alone has the private key capable of decrypting the data, gets the original chuck of data (D1). Now, the server and client both apply the same algorithm on D1 and generate data called private key. Any data encrypted using private key can be decrypted only using the same key. This is called symmetric encryption. 

Henceforth, the browser sends the data (such as the login and password) encrypted with the private key. Though a sniffer can still sniff the data, all that it will get is encrypted chunks. A sniffer will not have the same private key for decryption. Only the server, which has the correct private key, can decrypt the encrypted login and password data. Similarly, encrypted data sent by the server can be decrypted only by the private key possessed by

the browser. 

SSL enabling Apache



Now, let us set up SSL on an Apache Web server running on a PCQLinux 8.0 distribution (given out with March 2003 issue of PCQuest). SSL enabling Apache on PCQLinux is as easy as installing an RPM named mod_ssl-2.0.40-8.i386.rpm. You can download this RPM from ftp://rpmfind.net/ linux/redhat/8.0/en/os/i386/RedHat/RPMS/mod_ssl-2.0.40-8.i386.rpm. Once downloaded, install the RPM as

rpm —ivh mod_ssl-2.0.40-8.i386.rpm

The mod_ssl installation generates a dummy digital certificate for immediate use. Restart Apache. 

Now, using a Web browser (say, IE on Windows), access a website using https instead of http, ie, https://. You will be shown a Security Alert window with two warning messages. The first warning shows up if the dummy certificate got by the browser is not issued by a trusted certificate authority. The second warning shows up if you are accessing the page using an IP address or a name other than the hostname of the Linux machine.

We will tackle with these two warnings later.

Clicking on Yes on the warning window will show up an icon of a lock near the browser’s status bar, indicating that the transaction is secure. Henceforth, if you log in, a person sniffing your Web server will only get gibberish. 

Creating your own certificate



If you view the details of the digital certificate (by clicking on the View Certificate>Details on the warning window shown before), you will find that it uses someOrganization, someCity, someState, root@, etc. for organization details and e-mail addresses. You may like to customize this information according to your organization. For this you must create a new certificate as per the following procedure.

Issue the following command.

openssl req -new -out server.csr

When prompted for, enter any passphrase (password). Remember the passphrase you enter because it will be used later. For Country name, enter IN for India. Enter other details (such as your company department and e-mail) as prompted. Note that when prompted for the Common Name, you must enter a hostname using which you can access your Linux server. Accessing the Linux server using the same hostname will eliminate one of the Security Alert messages that warns about the name on the certificate not matching the name of the site.

The above command will generate a file called server.csr. Copy the file to the directory /etc/ httpd/conf/ssl.csr. Next, issue the following command.

openssl rsa -in privkey.pem -out server.key

When prompted, enter the same passphrase that you typed before. Copy the file server.key to /etc/httpd/conf/ssl.key directory. Issue 

openssl x509 -in server.csr -out server.crt -req -signkey server.key —days 365

The above generated a certificate valid for a year (365 days). Copy the file server.crt to /etc/httpd/conf/ssl.crt. Restart Apache.

Now, access your website using the resolvable hostname that you had specified for the Common Name above. You will be again shown the Security Alert window, but with only one warning. 

Click on View Certificate>General>Install Certificate. Click on Next on the Certificate Import wizard and select ‘Place all certificates in the following store’. Click on Browse and select ‘Trusted Root Certification Authority’. Select Yes when prompted by a message asking to add the certificate to the root store. Henceforth, you won’t get any warning messages. 

For intranet use, you may like to install your custom certificate on your networked machines using the above method.

However, a visitor of your Internet site may not choose to trust your custom certificate. So, for Internet use, you should procure a digital certificate from a standard certificate authority like VeriSign Inc

(www.verisign.com). 

Shekhar Govindarajan