This Issue

From the President
Tech-Talk
Advisories
News and Events
From the Forum
Latest Product Releases

From the President

Issue No. 2

Greetings to all readers, new and old, of The Sentinel. The Sentinel is The Software Group's bimonthly newsletter. This issue is going to all clients and customers we have had the privilege of serving. If you enjoy this introductory copy, please follow the directions at the end of this message to subscribe. If you are not currently subscribed and do not wish another issue, you need do nothing. This is a one-time-only mailing.

In this issue we have some interesting articles and an announcement about our newest SentiNet options. Tech-Talk this month contains an in-depth look at certificates and SSL for a secure web site. There is a summary on a Linux vulnerability in Advisories and From the Forum answers a question about how to get your web sites to be visible internally and externally.

I hope you enjoy this month's newsletter.

Derek Vair
President, The Software Group Limited

Tech-Talk

Hosting A Secure Web Site - Part 2

By Barbara Stuhlemmer
Technical Documentation Specialist

How do I get my site certified?

It is possible for someone to intercept and read data sent over the Internet. If you are exchanging sensitive information, it should be encrypted. Yet it is not enough just to provide 128-bit encryption on your secured site. You must be able to prove to buyers or any person providing private information that you are whom you claim to be and that their private information cannot be opened by anyone other than you. To do this you must use a third party to provide certified authentication.

The prevailing standard in encryption is to use a Public Key Infrastructure (PKI). This technology is based on using two encryption keys. One key is generally known. This is the public key. Anything encrypted with the public key can only be decrypted with the complementary key, known as the private key. The private key is kept secret and known only to you (or more likely, known only to your computer). Anyone may use the public key to encrypt data, but only your computer will be able to decrypt it. Similarly, anything encrypted with the private key can only be decrypted with the public key. This latter fact provides the authentication. If a client can decrypt the encoded data with your public key, the client can be sure it was encrypted with your private key, and hence must have originated with you.

A secure web site (https://), communicates with a browser via a secure socket layer (SSL). The web server sends the client browser its public key. The client browser creates a one time session key that will be used to encrypt data for the session. This key is itself encrypted with the server's public key and transmitted to the server. As only the server can decrypt this message, a mechanism is now in place to encrypt all data for the session (using the session key).

However all this is based on the browser client trusting the public key originally sent. This is where Certificate Authorities come in.

Every time a browser client accesses a page on your secured site you will send a package with a public key. The public key is signed by a Certificate Authority (CA) and has your corporate information in it, including the domain that was registered and the IP address where the key is valid. Browsers, such as Internet Explorer, expect the return of this key and will notify a user if the registration information is different than the provided key.

It is possible to have a secured SSL site without third party authentication. If the site is known to the users then authentication can be provided by the web site server using a self-signed key. This allows the local server to certify the site ownership. This is just as secure as having a third party authentication but the user must be sure they trust the owner of the site. This works well for employees accessing a corporate secured site.

There are five steps required to certifying your site and some questions that must first be answered.

• Who owns the web site?

  The owner of the domain name must be the person or business that applies for the certification. When you apply for certification you will be required to prove you are the rightful owner of the site. The CA will require a Dun and Bradstreet number, the article of incorporation, partnership papers or a business license.

• What level of encryption do I need?

  Although you can purchase 40-bit encryption certification, it has become standard by most users to accept only 128-bit encryption certification when using credit cards over the Internet.

• Does you Internet Service Provider offer SSL hosting?

  You will require an ISP that offers Secured Socket Layer (SSL) web site hosting. It must have the ability to serve https :// pages. See April's Newsletter for more information on Hosting a Secured Web Site.

Five Steps to Setting up Certification

1. Purchase domain name (e.g. www.wanware.com) and create your web site. Set up your non-secured site (http://www.wanware.com/index.html) and define the site location for your secured site (https://www1.wanware.com). You will need both http and https sites so you will have to discuss this with your Internet Service Provider before starting. For best security practices, it is recommended that the server that provided http:// hosting is a physically different server than the one that provides https:// hosting.

2. Choose a Certificate Authority like Verisign or Entrust Technologies. There are many out there so shop around for one that meets your needs.

3. Define a private key for your site and create the Certificate Signing Request (CSR). The private key is pasted into the CSR and submitted to the CA along with your corporate information. The CSR can be created right on a CA's web site. You will have to read the documentation requirements and application procedure on the chosen CA's site.

4. Create a self-signed key for your secured site. This will allow you to build, test and operate your site with complete encryption security. Your site will not yet have third party authentication.

5. When your certification key is provided by the CA, apply it to the web site. Be sure to make a copy of this key and keep the copy in a secured location. Your site will now be secured and authenticated.

Form more information on encryption and how the private keys and authentication works, see Entrust Technologies white papers and specifically "An Introduction to Cryptography".

Services mentioned in this article are not explicitly endorsed by The Software Group Limited. The Software Group Limited takes no responsibility for how these services do business. The example services mentioned were chosen based on their general popularity.

Back to top

Advisories

Exploit found for PoPToP PPTP server vulnerability April 9, 2003

Summary

This exploit of PPTP VPN was reported to the bugtraq security focus group.

PPTP packet headers contain information that specifies the full size of the packet. If the library in use allows packet length to be larger than the maximum size parameter it will result in unlimited amount of data being read into a buffer. This gives the attacking machine a return address on the buffer and then can allow them to bring up a reverse shell with privileges of the pptpd daemon (typically root) on the victim server.

The library used in Linux (GLIBC) allows this, making Linux vulnerable. Solaris and *BSD are not vulnerable.

Versions of PPTP affected are all after the latest stable version 1.0.1-1 and prior to 1.1.4-b3 and 1.1.3-20030409. SentiNet is shipped with the latest stable version and is not vulnerable to this attack

Back to top

News and Events

Win a Port Scan or Web Site Analysis

Sign up for The Software Group's newsletter "The Sentinel" and your name will be entered into a draw to win a security port scan of your network connection to the Internet or a web site functionality analysis (for up to 1000 links).

Port Scan - The Software Group will scan your exposed network ports and report on your vulnerability level.
Approximate value $200.

Web site analysis - This report will contain a summary of the functionality of your web site and provides a comparison to fortune 500 company web sites. Included is a list of broken links, missing attributes, slow pages, old content and link depth. Use this information to improve your customers' web experience.
Approximate value $300.

Draw to be held July 25, 2003 at The Software Group in Barrie, Ontario, Canada and winners will be notified by e-mail.

Back to top

From the Forum

Internally and Externally Visible Web Sites

Question - "In the configuration for a Virtual Web Server, instead of a drop-down box to choose what interface it's on, the SCM should have as many checkboxes as there are interfaces. Sometimes you might want your webserver on all interfaces (internal, external, ppp, whatever) rather than just one. Also, users should be allowed to have more than one virtual webserver on the same interface. There could be an option for using non-standard ports to make this possible."

Answer - Thanks for the feedback. The entire Virtual Web Server (VWS) setup could be made more clear and is something we are looking at.

The interface chosen is only meaningful if you choose LAN. In fact, as the VWS menu indicates, you are choosing the IP address that is associated with this web site. If you choose LAN, then the web site will not be accessible from the Internet. If you choose DMZ, or PPP, then the web site will be accessible both from the Internet and from your LAN (you will have to use the external IP address to see it). So choosing the interface is only restrictive if you choose LAN (and only because your LAN IP address is not visible to the Internet).

It is possible to run multiple virtual web sites without using non-standard port numbers. All modern browsers (anything released in the last four years) support the concept of a name-based web site. When you choose name-based, then different virtual web sites will be chosen based on the URL. For instance at The Software Group both www.sentinet.net and www.wanware.com resolve to the same IP address but are entirely different VWS (administered by different SentiNet users).

If you have more than one IP address available from your ISP, it is possible to run IP-based web sites. You need to configure an IP alias on your DMZ port and then two different web sites can run on two different IP addresses. This is unnecessary though, except when you have a secured web site (SSL, accessed through https://) - the security certificate, whether self-signed or purchased, must be associated with a specific IP address and there can be only one certificate per IP address.

I hope this makes this configuration more clear. Given this, do you think choosing the interface is still relevant? Would you wish to have a web site that is restricted only to the external port and not accessible to your in-house users even if they use the external IP address?

Regards,
Ragnar Paulson

Join The Software Group's Discussion Board Forums

Back to top

Product Releases

SyncSwitch (May, 2003)

Everyone knows they must eventually replace legacy networks. In some situations replacing functional legacy networks is not cost-effective nor logistically possible. SyncSwitch extends the life of your legacy networks while reducing the cost to run them until the benefit to replace them out-weighs the cost.

Another addition in our Legacy Communications product line, SyncSwitch encapsulates X.25, SNA or Synchronous protocols in IP packets allowing this traffic to pass over the Internet. The IP packets are read by another SyncSwitch at the other end, eliminating the expensive legacy networks infrastructure.

SentiNet Intrusion Prevention System (May, 2003)

SentiNet Intrusion Prevention System is a global prevention tool used to analyze and label network port scanning around the world. If confirmed as intrusive the IP address responsible is automatically blocked by the SentiNet firewall rules.

SentiNet Intrusion Prevention System is an optional add-on product that can be purchased for SentiNet IMS.

Back to top