Saturday, April 12, 2008

Tutorial: Using SSL

This page explains how to set up SSL to send and receive files securely via FTP. For more detailed information on what each option of the 'Security' dialog performs please read the Security section.
What is SSL? The Secure Socket Layer (SSL) is used to encrypt data as it is sent down a connection. This protects data from being intercepted for malicious use via what is referred to as a 'man in the middle' attack. With SSL, if any information is intercepted it will be useless without the relevant information needed to decrypt it. Therefore, when using SSL, you have a guarantee that the files you send and receive are always safe and secure.
CertificatesSSL also deals with authenticating both client and server by using certificates to validate their identity. This is especially important with FTP for preventing a 'masquerade' attack. This is where a third party can actually pretend to be your server in order to gain sensitive material or send harmful viruses to your users. SSL certificates ensure that the server you are connecting to, is the server that you intended to connect to.

Configuring SSLWhen using SSL with Ability FTP Server, there are a few things that you need to understand in order to configure your server correctly. First of all, the server must have a default certificate set which the SSL connections will use. This is also used to validate the servers identity to clients. It is also important to realize that FTP uses two connections; one for commands and a separate connection for file transfers. Ability FTP Server supports two different modes for which SSL can be used, these are 'Explicit SSL' and 'Implicit SSL'.
Explicit SSLExplicit SSL operates such that a connection to the server is made on the normal FTP port (default port 21). Communication initially starts in plain text until the client issues an 'AUTH SSL' or 'AUTH TLS' command, which then leads to certificate verification and a secure SSL connection being negotiated. If all goes well, then the server and client will proceed to send all further commands and replies encrypted using SSL.
Implicit SSLThis allows the server to specify a different port for SSL communication (default port 990). Any connections made to this port require immediate negotiation of certificates and SSL, avoiding any communication in plain text whatsoever.
Data Channel EncryptionThe security standard for FTP states that the data channel remains insecure by default. This means that SSL encryption would usually only be enabled on the command channel. Although this would protect from eavesdropping of user names, passwords and file locations, the uploaded and downloaded files would remain vulnerable. By setting the data channel to be encrypted by default, the FTP client does not have to implicitly state encryption of the data channel. However, you must ensure that the FTP client is able to deal with an automatically encrypted data channel.
CertificatesOn the Security tab of the settings dialog for Ability FTP Server, there is a button that will take you to the certificate management area. This area allows you to create and also import certificates to be used with the server's SSL communication. To use SSL, you must have at least one certificate installed in Ability FTP Server and you must also select one certificate as the default.
Creating CertificatesCreating new certificates is the simplest method of acquiring a certificate. Simply click 'Create' and fill in the necessary information. If you are unsure of any field, you can always press F1 on any open dialog to open the manual on the relevant page. All certificates require a private key and Ability FTP Server will either create a 512 bit key or 1024 bit key depending on your selection. Larger private keys will provide stronger security on your connections and so a 1024 bit key is recommended. Once all fields are completed, simply click 'Create' again and your new certificate will be generated and ready to use.Certificate Signing Requests (CSR)When you create a new certificate using Ability FTP Server, three files related to that certificate are generated in the 'certs' folder (usually C:\Program Files\Code-Crafters\Ability FTP Server\certs). These include a private key (.key) file, a certificate signing request (.csr) and a self signed certificate (.crt). Normally, you use the self signed certificate and corresponding private key for SSL communication. However, if you want to have your certificates signed by a trusted certificate authority, such as VeriSign, you will need to send them the certificate signing request (.csr) file. They can then sign this and send you back a new certificate (.crt or .cer) file. To use this new certificate you must import this back into Ability FTP Server using the original private key (.key) and newly signed certificate (.crt or .cer). For more details on importing certificates please read the next section.
Importing CertificatesIf you choose to import an existing certificate, you must have access to the certificate file and the relevant private key used to create it. These can be in a range of formats. Usually a private key is contained in a .key file and the certificate in either a .crt or .cer file. However, it is also common to produce a combined private key / certificate pair in a single file suffixed .pem. Ability FTP Server can take any known format of RSA base64 encoded private keys and certificates. It then loads in the pair and checks the integrity to ensure that they match each other. Once the pair have been successfully checked, they are copied to the 'certs' folder in the .key and .crt format for later use. If the files have different names (e.g. cert2.key / bobscert.crt) then the key is renamed to match the certificate (i.e. bobscert.key / bobscert.crt). You can also specify an entirely new name for both to be renamed to.

Wednesday, April 9, 2008

System Management Concepts: Operating System and Devices

Mounting Overview

Mounting makes file systems, files, directories, devices, and special files available for use at a particular location. It is the only way a file system is made accessible. The mount command instructs the operating system to attach a file system at a specified directory.
You can mount a file or directory if you have access to the file or directory being mounted and write permission for the mount point. Members of the system group can also perform device mounts (in which devices or file systems are mounted over directories) and the mounts described in the /etc/filesystems file. A user operating with root user authority can mount a file system arbitrarily by naming both the device and the directory on the command line. The /etc/filesystems file is used to define mounts to be automatic at system initialization. The mount command is used to mount after system startup.

Understanding Mount Points
A mount point is a directory or file at which a new file system, directory, or file is made accessible. To mount a file system or a directory, the mount point must be a directory; and to mount a file, the mount point must be a file.
Typically, a file system, directory, or file is mounted over an empty mount point, but that is not required. If the file or directory that serves as the mount point contains any data, that data is not accessible while it is mounted over by another file or directory. In effect, the mounted file or directory covers what was previously in that directory. The original directory or file that has been mounted over is accessible again once the mount over it is undone.
When a file system is mounted over a directory, the permissions of the root directory of the mounted file system take precedence over the permissions of the mount point. The one exception involves the .. (dot dot) parent directory entry in the mounted-over directory. In order for the operating system to access the new file system, the mount point parent directory information must be available.
For example, if the current working directory is /home/frank, the command cd .. changes the working directory to /home. If /home/frank directory is the root of a mounted file system, the operating system must find the parent directory information in the /home/frank directory in order for the cd .. command to succeed.
For any command that requires parent directory information in order to succeed, users must have search permission in the mounted-over directory. Failure of the mounted-over directory to grant search permission can have unpredictable results, especially since the mounted-over directory permissions are not visible. A common problem is failure of the pwd command. Without search permission in the mounted-over directory, the pwd command returns this message:
pwd: Permission denied
This problem can be avoided by always setting the permissions of the mounted-over directory to at least 111.
Mounting File Systems, Directories, and Files
There are two types of mounts, a remote mount and a local mount. Remote mounts are done on a remote system on which data is transmitted over a telecommunication line. Remote file systems, such as Network File System (NFS), require that the files be exported before they can be mounted. Local mounts are mounts done on your local system.
Each file system is associated with a different device (logical volume). Before you can use a file system, it must be connected to the existing directory structure (either the root file system or to another file system that is already connected). The mount command makes this connection.
The same file system, directory, or file can be accessed by multiple paths. For example, if you have one database and several users using this database, it can be useful to have several mounts of the same database. Each mount should have its own name and password for tracking and job-separating purposes. This is accomplished by mounting the same file system on different mount points. For example, you can mount from /home/server/database to the mount point specified as /home/user1, /home/user2, and /home/user3:
/home/server/database /home/user1
/home/server/database /home/user2
/home/server/database /home/user3
A file system, directory, or file can be made available to various users through the use of symbolic links. Symbolic links are created with the ln -s command. Linking multiple users to a central file ensures that all changes to the file are reflected each time a user accesses the file.
Controlling Automatic Mounts
Mounts can be set to occur automatically during system initialization. There are two types of automatic mounts. The first type consists of those mounts that are required to boot and run the system. These file systems are explicitly mounted by the boot process. The stanzas of such file systems in the /etc/filesystems file have mount = automatic. The second type of automatic mount is user-controlled. These file systems are mounted by the /etc/rc script when it issues the mount all command. The stanzas of user-controlled automatic mounts have mount = true in /etc/filesystems.
The /etc/filesystems file controls automatic mounts; they are done hierarchically, one mount point at a time. They can also be placed in a specific order that can be changed and rearranged.
The /etc/filesystems file is organized into stanzas, one for each mount. A stanza describes the attributes of the corresponding file system and how it is mounted. The system mounts file systems in the order they appear in the /etc/filesystems file. The following is an example of stanzas within the /etc/filesystems file:


You can edit the /etc/filesystems file to control the order in which mounts occur. If a mount is unsuccessful, any of the following mounts defined in the /etc/filesystems file continue to mount. For example, if the mount of the /home file system is unsuccessful, the mount for the /usr file system continues and be mounted. Mounts can be unsuccessful for reasons such as typographical errors, dependency, or a system problem.
The ln command, mount command, umount command.
The filesystems file centralizes file system characteristics.