According to a recent Forrester research, a lot of large companies in the US are monitoring their employees' outgoing e-mail. In fact, they're recruiting special staff just for this job. The justification offered: to reduce the financial and legal risks associated with outbound e-mail.
If this is happening in the US, there's no guarantee that this sort of a practice won't happen in India. Whether this is right or not on moral grounds is another story. The point here is that someone sitting at your mail server can easily read all your mail without your knowing about it. Moreover, when you send out e-mail, it travels from your mail server and passes through various SMTP servers over the Internet. This means that anybody with access to those servers can read your mail! Your firewall can't do anything about it because it's only limited to protecting your network's boundaries. Anything that goes out of it is beyond the firewall's control.
To add insult to injury, the same thing can happen for a chat session, Web access or even file access from your file server. In all cases, it's not your desktop, server or network that's vulnerable. You're anyways supposed to take measures to protect them through firewalls, update servers and what not. It's the information you're sending through these various channels that's under attack. Welcome to the wonderful world of information insecurity!
What are the choices?
While this may seem scary, things are not out of your control. There are ways and means of protecting your information, and no prizes for guessing the most well-known one-encryption. You can encrypt information traveling over all communication channels that you use. Encryption alone, however, doesn't resolve the problem. How do you know that the person or website at the other end is indeed the right one and not an impostor? Take an online transaction, be it with a bank or an e-commerce site. How do you know that your transactions are safe? Moreover, how does the bank or e-commerce site know that you are who you claim to be? Both parties must know each other's identity in order to transact. Enter identity management.
|
All this may sound simple, but the implementation of information-security solutions is not. For instance, which encryption algorithm should you use when sending out mail and which one for stored data? Is SSL encryption sufficient for your e-commerce site? What should you check with your ISP when setting up a VPN connection between your various offices? How do you provide a unique identity to all your employees, customers and partners? Where do digital certificates and certification authorities fit in? These are just some of the questions you need to answer when implementing information security.
It's a growing market
|
What are some of the factors that are driving the growth of information-security solutions in India? One, of course, is the increasing number of online transactions. More companies are finding the need to do this in order to be more competitive. Another surprising factor are government policies. Many government departments have adopted PKI and digital signatures for all government transactions, and a classic example is the DGFT (Directorate General of Foreign Trade). The department is responsible for handling all annual trade returns on imports/exports. It gives a 50 percent reduction in license fee if applications are submitted online. Now, it has made it possible to pay license fees online as well, for which you must obtain a digital certificate. This makes the transactions faster, cheaper and safer, thereby tempting the exim community to buy digital certificates. Similarly, other government bodies are also following suit. Anybody wanting to engage in any kind of electronic transaction with the government must obtain a digital certificate.
So information security is a growing market, and is slowly picking up. In this story, we've explained how you can protect all common online communication channels, such as e-mail, instant messengers, VPN links, e-commerce sites and even your file servers. We've shown how to actually do some of it, and explained critical considerations to keep in mind for others.
Lastly, since privacy of information is important, you may be tempted to secure all channels. But remember that all information isn't equally important. Protect what's critical for your business.
|
Security measures in VPNs
Many companies have facilities spread out across the country or around the world, and there is one thing that all of them need: a way to maintain fast, secure and reliable communication wherever their offices are. VPN is a good candidate for the task, but since it uses the Internet to connect them, it has to be secure. To maintain confidentiality and integrity, a VPN inherently must have a very strong encryption and authentication mechanism.
|
VPN technology is based on tunneling. This involves establishing and maintaining a logical network connection between two points; this may or may not contain a number of intermediate hops. Several interesting network protocols have been designed and implemented specifically for use with VPN tunnels. One of the four protocols below is generally used.
PPTP: The Point to Point Tunneling Protocol is best suited for remote access VPN applications, but it also supports LAN Internet working. It operates at Layer 2 of the OSI model, and supports authentication, encryption and packet filtering. PPTP authentication uses PPP-based protocols such as EAP, CHAP and PAP. It supports packet filtering on VPN servers; intermediate routers and other firewalls can also be configured to selectively filter PPTP traffic. A few drawbacks of PPTP are its failure to choose a single standard for authentication and encryption. Also, the inability to create split tunnels limits its utility in enterprise-wide VPN architectures.
L2TP: The original competitor to PPTP for VPN tunneling was L2F, a protocol implemented primarily in Cisco products. In an attempt to improve on L2F, the best features of it and PPTP were combined to create a new standard called L2TP. Like PPTP, L2TP exists at the data link layer (Layer 2) in the OSI model - thus the origin of its name.
IPSec: The security protocol most commonly associated with a VPN is an encryption protocol that provides for secure encrypted data transmission at the network layer across a public network such as the Internet. Two parties who wish to create an IPSec tunnel must first negotiate on a standard way to communicate. Since IPSec supports several modes of operation, both sides must first decide on the security policy and mode to use, which encryption algorithms they wish to communicate with and what type of authenticate method to use. In IPSec, all protocols that sit upon the network layer are encrypted (once an IPSec tunnel is created) between the two communicating parties. TCP, UDP, SNMP, HTTP, POP, AIM and KaZaa are all encrypted. IPSec VPN is the most robust remote-access technology. It extends almost any data, voice or video application available in the office environment to remote users. An IPSec VPN client on the remote system enables a user experience and workflow consistent with the office environment because of its ability to transparently support virtually any IP application. This 'any application access' has made IPSec VPN the de facto standard for extending connectivity to home offices, traveling employees, remote workers and day extenders.
|
SSL VPN: SSL is an application-layer protocol used most often to secure Web-based communications over the Internet. It uses encryption and authentication much like IPSec. Originally SSL protocol encrypted the traffic between two applications that wished to speak to each other but did not encrypt all the traffic from one host to another. However, with progress in technology, SSL VPNs now can be used to encrypt all traffic between a client and a server with SSL VPNs similar to IPSec client's encryption, except that with SSL VPNs there is no requirement for a 'fat client'. Any client-side software that may be needed to support network-layer encryption is downloaded on the fly using ActiveX technology or Java after the user has been successfully authenticated and authorized. This makes it a 'touchless' technology allowing for centralized management and control since the lightweight clients are intelligent and are driven by the centralized access-control gateway.
SSL-based VPN is an emerging technology that provides remote-access connectivity from almost any Internet-enabled location using a Web browser and its native SSL encryption. Although application accessibility is constrained relative to IPSec VPNs, SSL-based VPNs allow access to a growing set of common software applications, including Web page access and Web-enabled services such as file access, e-mail and TCP-based applications (by way of a downloadable thin-client applet).
SSL-based VPN requires slight changes to user workflow, as some applications are presented through a Web-browser interface, not through their native GUI. Using proven Web technology for secure connectivity allows accessibility from almost any system without needing to install additional desktop software.
|
What protocol to use?
Once an organization has decided to deploy a VPN, it is faced with an array of implementation options. One is to standardize on a particular VPN protocol. This is typically governed by the business needs, and depends on what kind of applications would be running over the VPN connection. Typically, the choice would be between IPSec and SSL-based VPNs. The choice of encryption mechanism comes next, which is typically governed by the sensitivity of data that would be flowing through the VPN pipes. Highly sensitive data would demand 3DES encryption (256 bits of encryption) and less sensitive data can be sent using DES or AES encryption standards.
Deployment concerns
Should an organization deploy VPN in-house or deal with a third party to create and maintain its infrastructure? This depends more upon business fundamentals than technology insights. An organization first needs to look into the necessary skill sets required to build and maintain a VPN infrastructure. The necessary skill sets required for running a VPN are not easily found, so they have to evaluate between the cost of retaining those skill sets in-house and outsourcing them to a strategic partner. Another line of thought is the sensitivity of data that would be traversing through their VPN network. If it is highly classified, would you be comfortable to outsource the security of that data to another organization or would you like to keep your pass phrases and encryption mechanisms a secret by keeping them in-house.
|
Protecting your portal with SSL using IIS and certificate server
It's easy for anyone to capture the data flow that happens between a website and a user, unless it's been secured in some manner. So if you have a Web portal and plan to have sensitive transactions with your customers on it, there's no way you can afford not to secure it. The most popular method of securing Web transactions is to use secure HTTP, which basically uses SSL. To do this you have to certify your Web server and then set up SSL sessions, which will be authenticated by these certificates. Here we'll explain this entire process using Internet Information Server.
Get certified
There are two ways of getting certified. One is to request a public certification authority for it. There are seven CAs who've been given the license to operate in India (see box) whom you can contact. This would cost you money, depending upon what kind of a certificate you're going for. For instance, a typical Web server certificate can cost around Rs 17,000 for the first time and a renewal fee of about Rs 12,000 per year. The other option is to set up your own CA using software like Microsoft Certificate Services, if you plan to use it internally or for a B2B portal, where your customers and partners are well known to you. The Certificate Services are a part of Windows 2000/2003 Servers.
Generate a certificate request for IIS
Weather you are planning to go for a third party certificate or local certification, you'll need to first generate a certification request, which will then be sent to the CA. To do this, you should have IIS 5 installed and configured. Then open Internet Information Services and click on the '+' button and expand your website. Then right click on the name of the website for which you want to request the certificate, click on properties and go to the 'Directory Security' tab. From here, click on the 'Server certificate' button. It will start a wizard, which will give you three options. Select the first one which says 'Create a New Certificate' and press Next. Then select the option 'Prepare the Request Now' and proceed. In the next screen it will ask you to enter the name of your website and select the encryption bit length. After selecting the right options, hit Enter. It will then ask you to enter your organization's name and the organizational unit. Entering your country, state and city information follows this. Finally enter a path where it will generate the requested file and save it. By default it saves the file into your C:\ drive as certreq.txt. If you want to go to a licensed CA, then you can mail this information to them. Else, if you want to create your own local CA, then read on.
|
Install and configure Microsoft Certificate Server
This is pretty simple. Go to Control Panel, and run the 'Add/Remove Windows Component' program. Select 'Certificate Services', and it will automatically start a wizard. Then select the first option (if this is the only or the first certification server in your network). In the next screen fill up the form, which will ask you for all the details such as the Name of the CA, Organization, OU, Address, etc. It will take two more clicks and the server will be installed and configured.
Posting a certification request to the local CA
Go to the machine I on which you have installed IIS and created the certification request and open up a Web browser. Now go to the link http://"ip_of _ the_CA_machine " . certsrv. It will open a Web page from where you can submit the request to the Local CA, which you have just created. To do so, select the second option at the first screen of the Webpage that says 'Request a certificate' and press Next. At the next screen select the 'Advanced request' option and continue. In this screen select the second option, which asks you to submit the request in base64 encoded format and again click on Next. Select the Browse link and select the text file, which contains the request (the file we created in the first step and the name was certreq.txt) and press the Read button. Click on the Submit button.
Issue and allow the request
Come back to your Certification Server and open up the 'Certification Authority' console from the 'Administrative Tools' and expand your machine's name from there. Here click on the 'Pending request' option and you will see the request which you have just sent from the IIS machine. Right click on the request and select 'All Tasks'. Then click on the issue option and you are done. Now the only thing, which is left is to install the certificate which has been just issued to you. To do so go back to the IIS machine and again open up the same link http"ip_of_the_CA_machine" .certsrv. This time, select the last option, which say's 'Check on a pending Certificate' and proceed. It will then show you the issued certificate. Select it and proceed by hitting Next. At the next screen you will get a download link. Click on it and save the file in any continent place.
Now again go to your web-site's properties using the IIS console and select the same 'Directory Security' tab and click on the 'Server Certification' button. Then just follow the wizard , which comes up. At the first screen select the option that says 'Process the pending request'. In the next screen browse and select the certificate, which you have just downloaded and press next until the wizard finishes. Your locally certified Web portal is now ready. The only thing you now have to keep in mind is that you have to use 'https' instead of 'http' when accessing
yourdomain.com.
|
Securing e-mail and instant messengers
It may come to you as a surprise that all e-mail communication is insecure by default. Messages sent and received by you can be eavesdropped upon by anyone and even the messages you thought you had deleted could be sitting on servers, years after having been sent. Anyone can read, modify your messages in transit and retrieve your passwords, which you thought were known only to you. Let's look at how insecure e-mail really is, and the ways and means of making it secure.
No matter what method you use (Web mail, SMTP, POP, IMAP) for sending and receiving e-mail, all your data and passwords are susceptible to hacking. The screenshot shows the content of a mail that was read off the network using a network
sniffer.
Even messages stored on the server can be read, altered and deleted by anyone. If you use Web-based e-mail and the connection between you and your server is not secure, ie, it uses normal http connection, then all data and passwords are sent in clear text and anyone can read them. Similarly, SMTP, POP and IMAP are all insecure data transmission protocols and a hacker can easily read your confidential data and passwords. Additionally, e-mail messages are stored in plain text on e-mail servers. Anyone breaking into the server, or even the system administrator, can get access to your messages. Backups of e-mail data are made by most servers, in which case copies of important data lie in plain text for anyone to read and modify.
|
Another big problem with insecure e-mail is repudiation. Since e-mail messages can be easily forged, there is no way that you can prove that a particular message was sent by someone, even if he has. This can lead to business implications for organizations that take important business decisions based on e-mail communication.
Security measures for e-mail
There are basically two mechanisms that one can employ to make e-mail data and passwords secure from prying eyes. The first step that an organization should take is to have SSL (Secure Socket Layer) connections for users connecting to the mail server, using whatever method (Web mail, SMTP, POP and IMAP). This way whenever the user connects to the mail server for sending or receiving e-mail, all communication between the two is encrypted and nobody can see the user's passwords and e-mail data. However, this method solves only one part of the problem. The message still resides unencrypted on the server and is still sent unencrypted over the Internet to the recipient. To solve these problems, the users should encrypt the e-mail data itself before sending. Encryption should be used along with SSL so that username and passwords are also protected. There are two forms of encrypting e-mail data: PGP and S/MIME. Both provide a way to encrypt and sign all e-mail messages, so that nobody can read the message data and the receiver can easily verify that the mail has been sent by you only. Both PGP and S/MIME use the concept of public and private keys for encryption and signing messages. Out of the two PGP is an Internet standard and has been around for a long time. Majority of e-mail users use PGP for encrypting messages. More information on encrypting messages using gnuGP can be found in the October issue of
PCQuest.
Using PGP to encrypt mail
PGP is the most widely used encryption mechanism for e-mail and uses the concept of public and private keys to send encrypted messages. There are several free (OpenPGP) as well as commercial solutions available for PGP (pgp.com). Whatever be the solution, the basic working remains the same. All these software provide PGP plug-ins for popular e-mail applications like Outlook, Outlook Express and Eudora. The plug in then lets you generate public and private keys. Now after you have your keys, you should make your public key known to all users whom you wish to receive mail from. And in order for you to send encrypted mail to them, you should have their public keys. Whenever you wish to send an encrypted mail to somebody, you encrypt it using his public key. Now only the intended recipient can read the content of the mail because only he can decrypt the mail using his private key. Similarly, whenever you receive a mail encrypted with your public key, only you can decrypt it as you have the private key for it.
Securing your chat conversations
Using public instant messengers is one of the most insecure forms of communication. That's because all the popular public IMs that you use, like Yahoo! or MSN send chat conversations in clear text. So anybody with malicious intent can easily capture this information and read your entire chat dialogue. The way out is to either use a private instant messenger that uses encryption, like Lotus SameTime, or use tools to encrypt conversations over public IMs. Let's see how to secure your chat sessions over Yahoo! IM. We'll use a software called SIMP (Secway instant messaging), which is capable of working with other messengers as well, like Trillian, MSN, ICQ and AIM. It is free for personal use and can be downloaded from
http://www.secway.fr/products/simplite_yahoo/.
For using it in an organization, you will have to pay $25 per client, and payments can be made online with a credit card.
|
Installing it is as easy as installing any Windows installable. Just double click on the executable file and follow the wizard. After installation, it will automatically start a configuration agent, which will ask what IM you are using, the connection method such as direct or through a proxy server. Finally it will ask you to move your mouse on the desktop randomly to generate a random number for your code. After it has created the key, it will restart Yahoo! automatically. The same has to be done on all machines having Yahoo! Installed. So next time you send a message to another Yahoo! comrad having SIMP installed, it will automatically prompt you to accept and install the public key of that person. When you select yes, a confirmation pops up at the other end. Similarly, your public key will be exchanged with the other person. Once this is done, all conversation between these two machines will be encrypted.
Implement your own secure IM server
If you're not interested in using a public IM, and are interested in setting up your own free and secure IM server, then try Jabber. We did an article on installing Jabber from its source in our May 2004 issue. You can also check out
https://www.pcquest.com/content/linux/2004/104050802.asp
for it. Follow the same instructions for installing Jabber, with one change. Instead of running './configure -prefix=/usr -sysconfdir=/etc' you have to run the following command:
#./configure -prefix=/usr -sysconfdir=/etc
-enable-ssl
After installation, run the following commands to generate your keys
#openssl req -new -x509 -newkey rsa:1024 -days 3650 -keyout privkey.pem -out key.pem
#openssl rsa -in privkey.pem -out privkey.pem
#cat privkey.pem >> key.pem
#rm -rf privkey.pem
Now open /etc/ jabber/jabber
.xml and scroll down to the section called
here replace 'yur-ip-address' to the address of your Jabber server. Then scroll down to the
Now restart your jabber server and you are done. To check the configuratons start any Coccinella client and while logging in, enable the check box which says 'use SSL for security' and login to the server.
Encrypting files in Win 2k/XP desktops
You've secured all your communication links, so that nobody can capture your critical information when it's traveling. There still remains one more challenge of protecting your files when they reside on your servers. The most basic method of course is password protection. But if somebody manages to get hold of the administrator password, then he/she has access to all files and folders on that system. Enter file encryption on the server. Windows systems have had this feature ever since they introduced version 5 of their NTFS file system. Unfortunately, there were many issues with that. For instance, in Windows 2000 Professional, if a user encrypts a folder that does not contain any files, and when that user adds some files to that folder, they will automatically be encrypted. But if some other use adds a file to that encrypted folder, then that file will not be encrypted. Another problem is that one cannot encrypt and compress a file at the same time, or if a file is compressed then it cannot be encrypted and vice versa.
|
Windows 2000 Professional and XP support file or folder encryption by default, and it's fairly easy to do. Just do the following:
- Open Windows Explorer, right click on a file or folder that you want to encrypt, choose its properties.
- Under the General tab, click on the Advance button and a new window opens. Here, check the box, which says
'Encrypt Contents to secure data'. - Now a new window will open asking you whether you want to encrypt only the folder or the files and sub folders contained inside the folder as well. Choose the appropriate option as per your requirement.
- You can even copy the encrypted files or folder to a file server, and the content will remain encrypted. If anybody other than the owner of that file tries to access it, that person will get an 'access denied' message. In fact, other users won't even be able to copy those files and folders to another location. This even prevents anybody from stealing your confidential information.
Another interesting thing to note here is that you can go to any other machine on the network and login with the username and password of the user who encrypted the files/folders. You'll then be able to access these from that location.
Now that you have learnt how to encrypt files/folders in an NTFS file system, it is our duty to warn you of the possible hazards of using file encryption. Consider a scenario where a disgruntled employee of the organization encrypts a few files that are critical for your organization and leaves. If the user hasn't decrypted them, then there's no way that anybody else can read them. So, you must take measures to prevent this sort of a thing from happening. One way of course is to check the user rights they have on their Windows 2000 or XP machines.
Anil Chopra, Ankit Kawatra, Anoop Mangla and Anindya Roy
Content on VPN by
Akshay Lamba, Enterprise Architect, Infrastructure and Security Development, Bharti Group.
All views expressed in that piece are the author's and do not represent the views of the
employer in part or in whole