Novell Network Management: NetWare 6

Chapter 6: Implement External Security Measures

 

Objectives:

This chapter concerns procedures to provide cryptographic security to NetWare services. The objectives important to this chapter are found on page 6-1:

  1. Describe Public Key Cryptography
  2. Identify How Public Key Cryptography Works
  3. Use Novell Certificate Server to Implement Public Key Cryptography
  4. (Self Study) Defend the Network Against Hacking and Denial of Service (DoS) Attacks
Concepts:
Introduction

Before beginning the discussion of Public Key cryptography, the chapter offers ideas about measures to enhance the internal security of your network. These ideas are common to both Novell and Microsoft network courses:

  • Develop a security policy - and publicize the things you want users to do and not do
  • Limit access to servers - lock the door of the server room
  • Restrict user access to the network
    • Disable unused accounts
    • Give temporary employee accounts an expiration date
    • Restrict login times to work schedules - and adjust this for overtime
    • Limit the number of user connections
    • Limit who can impose login restrictions
    • Assign rights to users - this avoids some inheritance problems
    • Set password properties - such as expiration cycles and length
    • Configure intruder lockout options - such as notifying an administrator when it happens
  • Restrict administrator access
  • Implement virus protection
  • Test security
  • Track security compromises with Novell Advanced Audit Server and BindViews

The chapter discusses what a firewall can and cannot do for the network. Firewalls can be implemented as software or software and hardware solutions. The text lists some features that might be found in a firewall:

  • Packet filtering
  • Network Address Translation (NAT) - this is commonly done even in a home network, by using a router
  • Circuit-level gateway
  • Application proxy
  • Virtual Private Network (VPN)
  • Caching

Firewalls are not effective protection against:

  • Attack from inside your network
  • Virus attacks
  • Attacks using new methods

The introduction continues with a discussion of why it is important to verify identity in a transaction that involves money. The identities of the buyer and the seller should both be verified. The verifications, credit card numbers, and other sensitive information should not be transmitted on a network unless a trusted means of encryption and decryption is used.

Messages sent across IP networks can easily be intercepted, and are subject to eavesdropping. It is a good idea to use encryption for any transmission of a financial or sensitive nature.

Describe Public Key Cryptography

Public key cryptography is an encoding scheme that assigns every user two keys. These keys are used to prove the identity of the sender of a message. This is called authentication. Keys are also used to encrypt and decrypt messages.

The public key method uses two different keys. Either of the keys can be used to encrypt a message. Whichever key is used to encrypt the message, the other key must be used to decrypt it. One of the two keys is called a user's public key. This key is delivered to anyone who needs it, and is used to decrypt messages that were encrypted with the user's other key, the private key. This method proves to message recipients that the message originated from the owner of the private key. Likewise, messages meant for the user can be encrypted with the public key, and can only be decrypted with the user's private key, ensuring security.

A definition of a key is given in the text: "a numeric value used by an algorithm to alter information, making that information secure and visible only to individuals who have the corresponding key to recover the information". Remember that when using key pairs, either key can be used for encrypting, but the other must be used for decrypting.

The process of delivering public keys to people who need them presents a problem. How do you know that the proof you are accepting is reliable? Public keys need to be verified by a Certificate Authority (CA). The text offers the names of some common public Certificate Authorities: Verisign, EnTrust Inc., and Digital Signature Trust Co. Inc.

Some terms regarding CA services are presented:

  • Public Key Certificate - this could authenticate a specific user, or a specific server on a network
  • Digital signature - typically an electronic signature, perhaps on an email, that can be verified to prove who sent a message
  • Encryption and decryption - these terms have been used already. At this point the text wants you to be familiar with the idea that a message encrypted with a public key can only be decrypted with the matching private key, and vice versa.
  • Secure channels - not well defined in the text. They mean that the server certificate will allow you to access and trust the security of the channel to your server. A web browser typically will show a closed padlock icon to indicate that a secure, encrypted channel to the server is in use, typically using Secure Sockets Layer (SSL).

Novell provides a CA in its Certificate Server. Using the terminology above, a message may be sent to a server/provider with a digital signature. A user will create a digital signature with their private key, and register that digital signature with a Certificate Authority. The signature may also be created by the CA, since the CA may be the source of both of the user's keys.

Encryption can also be done strictly with public and private keys, without a CA. This is less secure and less reliable. For example, a person could be buying something online, using a web browser. The buyer is sent the public key of the store through the browser. The browser encrypts the buyer's credit card data, and sends to the store's server. The server decrypts the data using the store's private key. (A problem exists here: the store has no way to send encrypted data back to the buyer, unless the buyer has a public and private key of his/her own.)

More terminology: a public key certificate is a digital message signed with a private key. A public key certificate is generated by a trusted entity, as described above, called a certificate authority (CA). Public key certificates can also be called digital public key certificates, digital IDs, digital passports, or certificates.

So Certificate Authorities can issue certificates, issue keys, revoke keys and certificates, publish public keys, and offer insurance against losses incurred due to their errors.

You may use either an Organizational CA, an external CA, or both. Be aware that you must use an Organizational CA to sign user certificates in this version of NetWare.

Benefits of using the NetWare Organizational CA:

  • Cost savings - You can create an unlimited number of public key certificates at no cost; a single public key certificate through an external CA might cost hundreds of dollars.
  • Certificate attribute and content control - An Organizational CA is managed by the network administrator, who decides attributes such as certificate life span, key size, and signature algorithm
  • Simplified management - there is no need to deal with external CAs.

Benefits of using an External CA:

  • Web site hosting - An external CA will be more recognizable to your customers when you are selling a product on the web.
  • Liability - An external CA might offer some liability protection if, through the fault of the CA, your private key was exposed or your public key certificate was misrepresented
  • Availability - An external CA might be more widely available and compatible

The text discusses the idea that you can examine the web browser on a workstation to see what Intermediate CAs it recognizes. An Intermediate CA is one that vouches for another one. On my workstation, I can click Start | Settings | Control Panel | Internet Options | Content (tab) | Certificates (button) | Intermediate Certification Authorities (tab).

The text discusses six properties that you may find in a Public Key Certificate. They must have a public key, a subject name, and a CA-generated signature. Usually, they contain an expiration date, the name of the CA that issued the public key certificate, and the serial number of the public key certificate.

To use public key cryptography, typically you will begin by obtaining a public key certificate from a CA. To obtain a certificate for a user:

  1. User contacts the CA, usually with a browser, requesting the certificate.
  2. CA sends data to the the browser on the workstation, causing the browser to create a public-private key pair.
  3. The private key is created and stored in encrypted form on the workstation hard drive. The public key is likewise created and sent to the CA.
  4. The CA receives the public key, and compares information in it to your application for the certificate.
  5. If the information is verified, the CA creates a public key certificate for the user. A password to access that certificate may be emailed to the user.

To obtain a certificate for a server:

  1. At your web server, create a Certificate Signing Request (CSR). This must contain your organization's public key, name, location, and URL.
  2. Your web server must have created a public-private key pair to send the CSR. The process of creating a CSR should do this.
  3. The CSR creation process will prompt you for the CA to send to.
  4. The CA verifies your information, and creates a server certificate.
  5. Upon receiving the certificate, your public key system can use the key pairs, and provide URL of the CA to users who wish verification.
Identify How Public Key Cryptography Works

A system that uses public key cryptography will use its public and private keys, and the certificates issued to it. Certificates provide authentication, proof that an entity on the network is who they say they are. Once entities are authenticated, they can exchange public keys, enabling them to send encrypted messages only the intended receiver of each message can decrypt.

These concepts apply to web commerce, banking, and the simple act of logging on to a network.

Use Novell Certificate Server to Implement Public Key Cryptography

Novell Certificate Server protects the transmissions in your network by creating, issuing, and managing user and server certificates.

As a continuation of the previous topics, the text outlines several instance in which certificates are used:

  • When a user logs in to a network
  • When email users use digital signatures
  • When users encrypt and decrypt messages
  • When users access a web server on the Internet that uses certificates
  • When an administrator uses Remote Manager
  • When an administrator uses iManager

A list of features of the Certificate Server is provided in the chapter:

  • You can create your own CA (referred to as an Organizational CA) or use an external provider.
  • Your CA can generate key pairs, saving the cost of going to a commercial provider
  • Novell's Certificate Server works with eDirectory, so you can rely on replication and on the familiarity of using eDirectory rights and security
  • Private keys are encrypted with Novell International Cryptographic Infrastructure (NICI). They are only available to internal processes, but they are backed up when you back up eDirectory.
  • You can manage certificates with ConsoleOne
  • The Novell Certificate Console utility allows users to export their keys to applications that use encryption without involving the system administrator
  • Novell Certificate Server supports GroupWise 6, Microsoft Outlook 98 and Outlook 2000, Netscape Messenger, Netscape Navigator and Microsoft Internet Explorer.

eDirectory requires some specific security objects for a Certificate Server to function:

  • Security container - This will contain the Organizational CA object and the Key Access Partition (KAP)
  • Key Access Partition (KAP) container - Contains an object called W0. It is a leaf, and it represents the security domain key, used to encrypt private keys.
  • Three objects created in the same container as the server: SSL CertificateDNS - server object, SSL CertificateIP - server object, SAS Service server object.
  • Four other objects, not described by the text, are listed as being created in the Security container: Login policy, Security policy, Authorized login methods, and Authorized post-login methods.

Server certificate objects are created in the same container as the server. They hold both private and public keys, public key certificate, and certificate chain for the server. (A certificate chain leads from this server to the CA that verifies its certificate.) Separate server certificates can be created for separate applications that use them, or you can use the same server certificate for all applications on that server that need a certificate. Server certificate objects are created with ConsoleOne, and they must be owned by the server. Ownership cannot be changed.

Another name for a server certificate object is Key Material Object (KMO). This is why the name of the server certificate object in eDirectory is actually NDSPKI:Key Material. (NDS is the old name for eDirectory, and PKI stands for Public Key Infrastructure.)

Novell Certificate Server is contained in PKI.NLM and a snap-in that allows it to be managed from ConsoleOne, which is run on a workstation. It cannot be managed from ConsoleOne running on a server.

Using ConsoleOne, you can:

  • Create an organizational CA object in eDirectory, if you did not already do so when you installed NetWare. You only get one CA object and CA server for each tree.
  • Create Server Certificate objects. Create these objects in the same container as the server that will host SSL services for applications. Multiple certificates per server are allowed for multiple applications. Multiple applications can share the same certificate, but the certificate cannot be shared across servers. Key pairs are stored in the certificates, and are assigned to applications by the name of the pair, not the name of the server or the certificate.
  • Request public key certificates.
  • Create User certificates. User certificates are created by the CA administrator. The certificates are stored in the security tab of the of the user object. Only the users (owners) can download and use the private keys in these certificates. Any user can download another user's public key.
  • Create a Trusted Root container and a Trusted Root object. This object must be placed in this container. It is used to validate certificates signed by the CA. The security container is placed near the top of the tree when you install Novell Secure Authentication Service (SAS).

Novell International Cryptographic Infrastructure (NICI) must be installed for Novell Certificate Server to work. NICI comes with Certificate Server, but must be installed and licensed manually, if the Certificate Server is not already running PKI services. You can check the version of NICI on your server from the GUI console. Click Novell | Install, and look for the NICI entry in the Installed Products list. The version information will be found there.

Users can use ConsoleOne or Novell Certificate Console to export a certificate and private key. The Certificate Console is an alternative, if you do not want your users to use ConsoleOne.

As stated above, one server in your tree will run the CA service. From it, you can create the Server Certificate objects to be used by servers that will host secure applications.

  1. When you create these certificates, you must name a key pair that will be stored in them. You also choose whether the certificate will be signed by your own CA or by one outside your tree (such as VeriSign).
  2. Your server can generate the key pair and store it in the Server Certificate object
  3. If you choose an external CA, your server will generate a Certificate Signing Request (CSR) that you will submit to that CA.
  4. A signed certificate will be returned to you by the CA, along with trusted root information.
  5. The trusted root and public key certificate are stored in the Server Certificate object using ConsoleOne.

Applications must be configured to use the Server Certificates.

Public key certificates expire in specific periods of time. The default period is two years for certificates signed by the Novell CA. Those signed by External CAs typically expire in one year. The certificate life span can be set to expire in 6 months, 1 year, 2 years, 5 years, or in the year 2036. (The year 2036 is a legacy from UNIX public key certificates.)

Life cycle of a key pair:

  • Key pair generation
  • Issuance of public key certificate by a CA
  • Key distribution: public key to public repository; private key to owner
  • Key pair activation
  • Use of the key pair
  • Public key certificate suspension, revocation, or expiration (delete from the tree if compromised)
  • Key pair termination

Public keys are available to anyone. If you suspect your private key has been compromised, request that it be revoked, and that a new key pair be generated.

The discusses symmetric cryptography, comparing it to public key methods. Symmetric cryptography is used when a document is encrypted, and the key (password) for the document must be distributed to users of the document. The greater the distribution, the higher the likelihood that security will become compromised. Interception of the key is a possibility that is minimized in public key systems. The user of a key pair never passes out his private key, and the public key is meant to be public.

Secure Sockets Layer (SSL)

This is a protocol that uses public and private keys on both ends of a session. For example, if you were to make a purchase from Amazon.com, you would begin an SSL session with their server by sending it your public key (keeping your private key to yourself), and receiving their public key (while they keep their private key hidden). In this way, transmissions from either end can only be decrypted by the intended receiver. Some terminology about SSL:

  • Your application may have a selection of key pairs to use. The public key chosen to be used in this session is called the session key.
  • Server and client are allowed to authenticate with each other when establishing the channel for the session. The process of authenicating on both ends is called mutual authentication.
Seting Up Novell Certificate Server

NetWare should create an Organizational CA for you when you install the Certificate Server service. To create the Organizational CA object manually:

  1. Log in to the eDirectory tree as an administrator with Supervisor rights to the Security container
  2. Start ConsoleOne
  3. Find the Security container object in the tree. You will create the CA inside it.
  4. Right-click the Security container object and select New | Object
  5. From the list in the New Object dialog, double-click NDSPKI:Certificate Authority. A wizard will run that will ask for required information.

You must choose a server in the tree to run the CA service. You are advised to choose one that is reliable and available, that runs the necessary protocols to communicate with all your other servers (IP, IPX, or both), and that only runs software you trust.

Server Certificate objects are created in the same container as the server they are associated with. As noted above, Server Certificate objects are also called Key Material objects. The schema name of the eDirectory object is NDSPKI:Key Material.

To create additional Server Certificate objects:

  1. Log in to the eDirectory tree as an administrator with Supervisor rights to the server container
  2. Start ConsoleOne
  3. Right-click the container object that contains the server that will run your cryptography-enabled applications; then select New | Object
  4. From the list in the New Objects dialog, select NDSPKI:Key Material and click OK to create a Server Certificate. This opens the Create a Server Certificate wizard that creates the Server Certificate object.

 

Detailed procedures are given in the text for creating user certificates, creating a trusted root container (in the Security container), creating a Trusted Root object (in the trusted root container), exporting a trusted root certificate, and replacing a trusted root certificate. You should practice all these procedures.

The process for configuring individual applications to use your CA varies from one product to another. You should check the documentation of the product. Some require that you export a public key certificate from your organizational CA, just as an external CA does.

To issue a public key certificate from your CA:

  1. Log in as a system administrator. You specifically need the Read right to the NDSPKI:Private Key object.
  2. Run ConsoleOne.
  3. Select a container.
  4. On the menu bar, left-click Tools | Issue Certificate.
  5. Browse to a CRS object, and open it in the dialog box that appears. Click Next.
  6. Select the Organizational CA object. This will sign the certificate. Click Next.
  7. Choose how the key will be used.
  8. Enter four parameters: subject name, validity period, effective date, and expiration date.
  9. Verify the parameters, and click Finish.

The Self-Signed Certificate is used for authentication. It is exported to entities that require verification of certificates signed by your CA. This is similar to the trusted root certificate that is exported by servers. You can begin the process of exporting a Self-Signed Certificate by clicking the Export button on its page.

When an external CA responds to your request (CSR) for a Server Certificate, it sends a signed public key certificate, which verifies your identity. It is like an ID card to show applications and secure users. (It also sends a trusted root certificate, which verifies the CA’s identity. This certificate proves the identity of the issuer of your public key certificate.)

When received, you must import the public key certificate(s) before they can be used. This can be done from either the General or Certificate tab of your Server Certificate object. You will be presented with a window in which you should paste text from the Server certificate you received. (The Server certificate from the CA is a text file.) Paste all lines between and including the lines that say “-----BEGIN CERTIFICATE-----” and “-----END CERTIFICATE-----”.

(Self Study) Defend the Network Against Hacking and Denial of Service (DoS) Attacks

The last section of the chapter begins with a discussion of methods of attacking a system. Some classic methods are:

  • Having a user name and password. Many users do not guard either.
  • Spoofed IP address. A hacker may use an IP address that belongs on your network, which may be assumed to be safe by the devices on the network.
  • A hacker may copy the DNS database from a server on your network. This will reveal all information about IP addresses and host names known to the DNs server.
  • FTP and Telnet protocols send passwords in clear text. Bad idea. Hackers eavesdropping on such traffic may find that such passwords also let users log in to the system.

Once inside your system, the hacker may load an NLM that will create an administrator account of his own. No, Novell does not create such NLMs, but hackers do. Some are called Burglar, Password, and Security.

Novell frequently tells us of the dangers of having accounts without passwords. Another hacker technique is to try to log in to all known accounts, without using a password, playing the odds that one of them was not configured to need a password. Have some of you changed your minds about requiring passwords for users?

NetWare Core Protocol packets are messages sent within the operating system itself. If a hacker can forge this sort of message, he may be able to do anything on the network. The way to avoid this is to enable NCP packet signatures, a form of authentication for these packets.

In networks that use non-NDPS printers, there are print servers, NLM programs that watch the net for print jobs, store them in queues, and send the jobs to printers. A rogue print server, loaded by a hacker, masquerades as one of the real print servers, and takes advantage of the fact that print servers become empowered with the network rights of the sender of a print job. When this program receives a job from a user with admin rights, it can perform stealth actions for the hacker.

So, what can you do to prevent these problems?

Four suggestions about server security:

  • Lock up the server - If the door to the server room is locked, only people with a key can get at it. Do not put a printer in the server room and give users access to it.
  • SECURE CONSOLE- this is a password protected command which keeps people who do not know the password from changing the server (The password should not be your login password.)
  • SCRSAVER.NLM - this is a password protected screen saver for the server
  • Use a password on remote console - both versions of the remote console program require you to supply a password.

As already noted, require users to use passwords, require that they change passwords periodically, and require that passwords be a minimum length. Use your own judgement here: if you require passwords that are too long, users will write them down instead of remembering them. The same goes for changing them too often.

As noted above, avoid forged NCP packet attacks by enabling digital signatures on NCP packets. Four levels of signature protection are possible:

  • 0 - the server does not sign packets
  • 1 - the server signs packets if the client requests it
  • 2 - the server signs packets if the client can sign packets
  • 3 - the server signs packets, and requires the client to sign them, too

The command to set these levels is:

SET NCP Packet Signature Option=Level

Level stands for one of the integer values above.

Rogue print servers can be defended against by requiring print server use encrypted passwords. Defend against the masquerade by limiting the number of simultaneous connections for print servers.

Denial of Service (DoS) attacks happen when a network or server is bombarded with request packets, usually from mulitple slave computers, keeping the system from functioning. The text divides these attacks into three types:

  • TCP/IP Implementation Attacks - These are attacks based on one or more weaknesses in the family of TCP/IP protocols. For example, as explained in class, it is possible to send a ping (an ICMP echo request) to an IP address with a packet that is too large for the network the address is on. This can cause the receiver to lock up, lose its IP stack, or reboot spontaneously. This is called the Ping of Death, because it can "kill" the receiver.
  • TCP/IP Standards Attacks - A spoofing attack (example: SYN) sends hundreds of messages to a server, requesting it to respond to a fake IP address. The server sends a response, and will then wait for a response to its response, which will never come, since there is no such IP address as the spoofed address. Other requests fill a queue on the server, and eventually all incoming requests are dropped. As a variation, the spoofed address can be the address of the server itself, causing the server to participate in flooding itself with traffic.
  • Brute Force Attacks - These attacks attempt to flood a network with traffic (as opposed to flooding a server). For example, the smurf attack sends a ping message to the broadcast address for a network from outside the network. The resultant ping traffic will clog both the network being pinged (the intermediary network) and the network that the ping pretends to be from (the victim network).

Defending against DoS attacks:

  • Most network operating systems can defend themselves against the Ping of Death, if they have been updated since the defense was created. If your system is old, download and install all necessary patches. Patch updates are recommended to defend against TCP/IP Implementation attacks.
  • Defend against SYN attacks by using a firewall. Set the firewall to make sure that packets leaving your network have addresses actually on your network.
  • Defend against some spoofing attacks with patches to the operating system. Also, configure your firewall to drop all packets with known bad IP addresses. For example, a packet coming into your network with the address of a device inside your network is a bad address. So is any packet coming into your network with a private address.
  • To defend against attacks like smurf, configure the network not to respond to pings sent to broadcast addresses. Configuring routers to deny IP-directed broadcasts can also be effective. Configure routers to drop packets leaving your network that show a source address outside your network.
  • The text indicates that you could disable all UDP services on each host in the network to avoid UDP flood problems. However, if you do so, you will disable all legitimate UDP traffic as well.