Security

Intro
Installation
SysAdmin 
HTTP 
Logs 
Protection 
Security
Scalability 
Listeners 
Alerts 
SNMP 
Dialup 
CLI/API 
Objects
Transfer
Access
Directory
Data Files
Clusters
WebMail
Miscellaneous
Licensing
HowTo

The CommuniGate Pro Server ensures that only certain users are allowed to access certain resources.

The CommuniGate Pro Server can authenticate the users, and can also reject connections from outside of the "client networks".


Authentication Methods

The CommuniGate Pro Server supports both clear-text and secure SASL authentication methods for the following protocols:

These secure methods allow mail clients to send encrypted passwords over non-encrypted and insecure links. If anybody can monitor your network traffic, SASL methods ensure that the real passwords cannot be detected by watching the client-server network traffic.

As an alternative to SASL methods, secure links (SSL/TLS) can be used between the client mailer and the server. When an SSL link is established, the entire network traffic between the server and the client is encrypted, and passwords can be sent in clear text over these secure links.

You can force an account user to use either a SASL authentication method or SSL/TLS links if you enable the Secure Method Required option in the Account Settings. When this option is enabled, the Server rejects all authentication requests that send passwords in the clear text format over insecure links.

The CommuniGate Pro Server supports the following secure SASL authentication methods:

The CommuniGate Pro Server supports the following insecure SASL authentication methods:

Besides, the CommuniGate Pro supports the secure APOP authentication method (used mostly for the POP protocol), and the insecure "regular login" method for the protocols that support Clear Text Login.


Account Passwords

The CommuniGate Pro Server supports several passwords for each account.

One password is the CommuniGate Pro's "own password ". This password is stored as an element of the Account Settings, and it can be used with the CommuniGate Pro Server only.

The other password is the "OS password". The user may be registered with the Server OS and the CommuniGate Pro Server can check the supplied password against the password set in the Server OS registration information for this user.

An account can have the External Password option enabled. In this case, user authentication is done using any custom authentication program running as a separate process (see below).

The system administrator can enable any set of password for any user account. On larger sites, it is better to enable these options using the Server-wide or Domain-wide Default Account Settings.

When several passwords are enabled for an account, the Server first checks the CommuniGate (internal) password, then the OS password, and then tries to use the External Authentication program. If at least one of these passwords matches the password presented with the client application, the application is granted access to that account.


CommuniGate Passwords

CommuniGate passwords are strings stored in the Account Settings. Password strings can be stored in the clear-text format or in encoded format. The Password Encryption Account Setting specifies the encryption to use when updating account passwords.

On Unix systems, the U-crpt Password Encryption option is available. If it is selected, the CommuniGate passwords are stored using the standard Unix crypt routine. Since this is a one-way encryption, such passwords cannot be used for secure (SASL) Authentication Methods. Use this option only if you need compatibility with legacy password strings, but cannot use the OS passwords.

The U-crypted passwords can have some special format, so they are recognized as MD5- and SHA1- digested passwords, not as Unix-crypted passwords. See the Migration section for more details.

If the CommuniGate Password is absent or empty, it cannot be used to log into the account even if the Use CommuniGate Password option is enabled. But if the user has logged in using the OS Password or the External Authentication method, the user can specify (update) the account CommuniGate Password. This feature can be used to migrate users from legacy mail systems where you can not compose the list of accounts with non-crypted user passwords.


OS Passwords

When the Server checks the OS password, it composes the username string using the account domain OS User Name setting. When the default setting * is used, the composed user name is the same as the account name. By changing the OS User Name settings you can use different OS usernames for accounts in different CommuniGate Pro domains.

Server Operating System Notes about OS Passwords
Microsoft Windows 9x OS does not support passwords, the Use OS Password option does not work.
Microsoft Windows NT The Windows NT domain authentication system is used, the server account should have the Act as part of the operating system privilege.
Unix-based systems The passwd and shadow authentication mechanisms are used.

The OS passwords are one-way-encrypted passwords. As a result, they cannot be used for Secure Authentication Methods.


External Authentication

The CommuniGate Pro Server can use an external application (program) for user authentication. That program should be created by your own technical staff and it can implement authentication mechanisms required at your site but not supported directly with the CommuniGate Pro Server.

The program name and its optional parameters should be specified using the WebAdmin Obscure Settings page:

External Authentication
Log: Program Path:

When the External Authenticator option is enabled, the Server starts the specified program as a separate OS process.

When a user should be authenticated using the clear text method, the Server places the following line into the external authenticator standard input:
nnnnnn VRFY name@domain password EOL
where:

nnnnnn
a unique sequence number for this request
name
user account name
domain
user account domain name
password
password string to verify
EOL
the End Of Line symbol(s)

When a user should be authenticated using a secure SASL method, the Server places the following line into the external authenticator standard input:
nnnnnn SASL(method) name@domain password key EOL
where:

method
the name of the secure SASL method used (CRAM-MD5, APOP)
key
the challenge string sent to the client mailer.

The External Authentication program should place a response line into its standard output. If the password is accepted, the positive response line should be used:
nnnnnn OK EOL

if the password was not accepted for the specified account, a negative response line should be sent:
nnnnnn ERROR optional-error-message EOL

Sample session (I: - server commands sent to the program standard input, O: - responses the program writes to its standard output):

I: 00010 VRFY user1@domain1.com dsyui134
O: 00010 OK
I: 00011 VRFY user2@domain2.com jskj23#45
O: 00011 ERROR incorrect password
I: 00012 SASL(CRAM-MD5) user4@domain2.com hdkj547812329394055 <pop-23456@mydomain.com>
O: 00012 ERROR unsupported SASL method

When the server shuts down or when it needs to stop the external authentication program, it closes the program standard input. The external authentication program detects the end-of-file condition and it should quit within 5 seconds.

Log
Use this setting to specify what kind of information the External Authentication module should put in the Server Log. The module records in the System Log are marked with the EXTAUTH tag.


Granting Access Rights to Users

In order to control, monitor, and maintain the CommuniGate Pro Server, one Postmaster account is usually enough. But you may want to allow other users to connect to the CommuniGate Pro Server: for example, you may want to allow an operator to monitor the Logs, but you do not want to grant that operator all Postmaster access rights.

You should be logged in as the Postmaster, or you should have the "Can Modify Access Rights" right in order to assign access rights.

To grant access rights to a user and/or to revoke those rights, open that user Account (the Account Setting page), and click the Access Rights link. The Access Rights page will appear.

The page lists all Access Rights and the rights granted to the selected user are marked.

The following access rights can be granted only to the users (accounts) in the main domain:

Can Modify Access Rights (unlimited access):
This setting specifies if the user is allowed to modify Access Rights of CommuniGate Pro users. If some users are granted this right, they can access all Server settings and pages (i.e., all other rights are granted, too).
Can Modify User Accounts
This setting specifies if the user is allowed to create, remove and delete Accounts and Domains, and to change Account and Domain Settings.
Can Modify Server Settings
This setting specifies if the user is allowed to change configurations of CommuniGate Pro services (SMTP, POP, Router, etc.).
Can Monitor Server
This setting specifies if the user is allowed to view Server Logs, to monitor Server Queues, etc.

The following access rights can be granted to users in any domain:

Can Modify This Domain and its Account Settings:
This setting specifies if the user is allowed to create, remove and delete Accounts within its own domain, and to change some of the Domain Settings. You usually assign this right to a user ("domain master") who will manage the domain.

Initially, the user Postmaster in the main domain has the Unlimited Access right.

Select the desired Access Rights and click the Update button.

The Access Rights are stored in one file for each domain, the Access.settings file stored in the Settings subdirectory of the domain directory. This makes it easy to check to whom the Server administration rights are granted.


Restricting Access

If you do not plan to support mobile users, you may want to restrict access to the Server accounts. Use the following option on the Protection page:

Grant Access to Clients Only
When this option is selected, all Access (POP, IMAP, WebUser Interface, ACAP, PWD, etc.) connections are accepted only from the Server computer itself, and from the computers (network addresses) included into the Client Addresses list.

When an access module accepts a connection from an unlisted network address, and this option is selected, the module sends an error code to the client application, and the connection is closed immediately. Links with the rest of the Internet will be used only for mail Transfer and access to Personal Web Sites.

When this option is selected, the SMTP AUTH operation can be used only if a client mailer or server connects from the network address included into Client Addresses list.

Note: Before you enable this option, make sure that the address you are using is included into the Client Addresses list: otherwise you will immediately lose access to the Server.

You can also specify the access restrictions on the lower (TCP) connection level. For each service (module), open the Listener page and specify the addresses the service (module) should or should not accept connections from. If a connection comes from an address that is not included into the Grant list or is included into the Deny list, the connection is closed immediately, and no module-level operations are performed.


Using SSL/TLS Secure Connections

The CommuniGate Pro Server supports secure (encrypted) connection for all its services and modules. Secure connections can be established in two ways:

To specify the server SSL/TLS processing parameters, open the Obscure page in the Settings section of the WebAdmin Interface:

TLS Sessions
Log: Time To Live:

Log
Use this setting to specify what kind of information the TLS module should put in the Server Log. The TLS module records in the System Log are marked with the TLS tag.

Time To Live
This setting specifies the cache time for TLS sessions. When all connections using the same TLS session are closed, the Server waits for the specified time before deleting the TLS session parameters. This feature allows clients to open new connections resuming the old TLS sessions. It increases connection speeds and decreases the Server CPU load. This feature is especially important for HTTP clients that open and close connections very often.


Certificates and Private Keys

When a secure connection is being established (using the TLS/SSL protocol), a public key cryptography is used to:

A server must possess a so-called "private key" and a "certificate" that contains a public key. When a client starts to establish a secure connection, the server sends its certificate to the client. The client:

The Certificates themselves use the Public Key cryptography, too. The Certificate contains the information about the server and the information about the organization or entity that has issued the Certificate. The entire Certificate is digitally signed using the Private Key of the issuer, and it is practically impossible to forge a certificate without make the digital signature invalid.

Modern browsers and mail clients have the Public Keys of several "known authorities" (issuers) built-in. As a result, they can verify the digital signatures of the Certificates issued by those "known authorities". It is assumed that such "known authorities" take reasonable steps to ensure that they issue a Certificate for abc.def domain to the legal owner of that domain.


Domain Security Settings

CommuniGate Pro allows you to specify Private Keys and Certificates on the per-domain basis. The Keys and Certificates can be assigned only to the CommuniGate Pro Domains that have one or several assigned network (IP) addresses. This limitation comes from the secure versions of the mail protocols used today: when a client wants to initiate a secure connection, the Server has no information about the Domain the client wants to connect to, and only the local IP address to which the client has connected is known.

You can configure a CommuniGate Pro Domain to use a Server-wide Private Key and a Certificate - but you should use this feature for testing purposes only.

To enter the domain Private Key and Certificate, use the WebAdmin Interface and follow the Security link on the Domain Settings page. The Domain Security page will open:

Secure Certificate To Use:
This option allows you to specify which private keys and certificates the CommuniGate Pro Server should use when a client wants to establish a secure connection with this domain.

No
if this option is selected, secure communications with this domain are prohibited

Server
if this option is selected, the Server-wide Private key and Certificate are used for secure connections to this domain. You do not have to configure any other Domain Security options in this case. Use this mode for testing only.

Custom
if this option is selected, the Domain Private Key and Certificate are used to establish secure connections with this domain.
Private Key
Enter a PEM-encoded Private Key:

You should use any third-party program to generate a Private Key in the so-called PEM format (as shown above), copy the encoded key into the text field, and click the Set Key button to set the Private Key for the domain.

Note: Because of the export restrictions, some US-made products (such as Netscape 4.x) disable strong (more than 512 bit) cryptography for SSL/TLS "shared secret" exchange. Those products expect a server to send them a temporary 512-bit key instead, with the generated longer key being used for certificate validation only. If your users employ software products with disabled strong cryptography, generate and use 512-bit keys only: in this situation longer keys will only increase the server load without any increase in the security level.

If the encoded Key format is correct and the Key info can be used for public/private key cryptography, you will see the following panel:

Private Key
MIIBPAIBAAJBAKrbeqkuRk8V...
Key Test: Verification String is OK

Note:You will not see this panel if you have not entered a correct Private Key.

Use the Remove button to remove the entered Domain Private Key. Since the Domain Certificate is useless without the Private Key, the Certificate (if already exists) will be removed, too.

If the Key Test field indicates an error, the submitted Private Key cannot be used for public/private key cryptography.

To accept secure connections, the Domain must have a certificate issued to that domain. Please note that the clients compare the name in the Certificate to the name they used to connect to the Server. If a CommuniGate Pro domain has domain aliases, attempts to connect to the Server using a domain alias name will result in warning messages on the client workstations notifying users about the name mismatch.

To create a Certificate, fill the fields in the Certificate Attributes table:

Certificate
Common Name:
Country:
Province/State:
City/Town:
Organization Name:
Organization Unit:
Contact E-mail:

Common Name
Each certificate can contain only one Common Name, while a CommuniGate Pro domain can have many aliases. Client applications check that the Certificate Common Name matches the name the user has specified in the URL and/or in the mailer settings. If the domain.dom domain users have to specify the domain alias mail.domain.dom name to connect to that CommuniGate Pro domain (because the domain.dom name does not have a DNS A-record), then select the mail.domain.dom as the Certificate Common Name.

Contact E-mail
This field must contain a valid E-mail address, though that address does not have to be inside this CommuniGate Pro domain.

All other fields are optional.

You can create a Self-Signed Certificate if you do not want to use any external authority. Click the Generate Self-Signed button and the CommuniGate Pro Server creates a so-called self-signed certificate: the issuer will be same entity you have specified, and the entire certificate will be signed using the Domain Private Key. When a Domain has a Self-Signed Certificate, client applications will warn user that the addressed server has presented a certificate "issued by an unknown authority". Users can "install" self-signed certificates to avoid these warings.

To receive a Certificate from an external source ("trusted authority"), click the Generate Signing Request button. A text field containing the PEM-encoded CSR (Certificate Signing Request) will appear:

Certificate
Common Name:
Country:
Province/State:
City/Town:
Organization Name:
Organization Unit:
Contact E-mail:
Certificate Signing Request (CSR)

submit this request to a Certification Authority and paste the result below
Enter a PEM-encoded Certificate


Copy the CSR text and submit it to the Certification Authority (CA) of your choice. You can submit via E-mail or using a Web form on the CA site. The Certification Authority should send you back the signed Certificate in the PEM-format. Enter that Certificate into the bottom field and click the Set Certificate button.

If the Certificate is accepted, the Certificate information is displayed:

Certificate
Issued to:
Country:US
Province:CA
City:Sausalito
Organization:ACME Yacht Rentals, Inc.
Unit:On-line Services
Common Name:d1.stalker.com
Contact:bill@domain.company
Issued by:
Country:ZA
Province:FOR TESTING PURPOSES ONLY
Organization:Thawte Certification
Unit:TEST TEST TEST
Common Name:Thawte Test CA Root
Valid:
From:06-Jun-00Till:06-Jan-02
The Certificate panel shows the information about the issuer (the Certificate Authority), the information about the "subject" (the data you have entered and the domain name) and the validity period of this Certificate.

Note: the entered Private Key and Certificate will be used for domain-related communications ONLY if the Secure Certificate To Use option is set to Custom.

Note: the Certificate contains the domain name as a part of the "Subject" data. If you rename the CommuniGate Pro domain, the domain name in the certificate does not change, and the client applications may start to warn users about the name mismatch.

Click the Remove Certificate button to remove the Domain Certificate.


Using Default and Self-Signed Certificates

Web browsers and mailer programs check if the server certificate is issued by a "known authority". The list of "known authorities" is built into those programs. If a domain on your CommuniGate Pro server uses either a "Server" certificate, or a custom self-signed certificate, or a custom certificate signed by an authority not known to client browser or mailer, the client application will display an alert message every time it estaiblishes a secure connection with your Server domain.

Your users can "install" your Server domain certificates into their mailers and browsers. Once installed into the client software, a certificate becomes a "trusted" one. For some programs (such as Mac versions of Microsoft Outlook and Outlook Express) installing an "untrusted" certificate is the only way to enable secure communications.

To install a domain certificate, the user should use a browser application and connect to the login page of the WebUser Interface for the selected domain. If the domain has an enabled Certificate, the Secure Certificate link appears. The user should click on that link to download the domain certificate and "open" it. The browser should allow the user to verify the certificate and install it as a "trusted" certificate.


CommuniGate® Pro Guide. Copyright © 1998-2000, Stalker Software, Inc.