Installing and configuring Janus Network Security: Difference between revisions

From m204wiki
Jump to navigation Jump to search
No edit summary
No edit summary
Line 1: Line 1:
Before you can start using secured communications with <var class="product">Janus Network Security</var>,
Before you can start using secured communications with <var class="product">Janus Network Security</var>,
preliminary tasks must be completed.
some preliminary tasks must be completed.
Some of these tasks may be performed by different people, but they should occur in the following sequence:
The tasks should occur in the following sequence:
<ol>
<ol>
<li>Install the <var class="product">Sirius Mods</var>, which contains <var class="product">Janus Network Security</var> support.
<li>Install the <var class="product">Sirius Mods</var>, which contains <var class="product">Janus Network Security</var> support.
<p class="note"><b>Note:</b> This requirement does not apply if your version of <var class="product">Model 204</var> is 7.5 or higher.
<p class="note"><b>Note:</b> This requirement does not apply if your version of <var class="product">Model 204</var> is 7.5 or higher.


<p>
<p>This step would probably be done by the person responsible
This step would probably be done by the person responsible
for installing and supporting <var class="product">Model&nbsp;204</var> at your site.
for installing and supporting <var class="product">Model&nbsp;204</var> at your site.
If you are already running <var class="product">[[Janus Web Server]]</var>, this step involves
If you are already running <var class="product">[[Janus Web Server]]</var>, this step involves
Line 36: Line 35:
You can confirm whether the <var class="product">Sirius Mods</var> are installed and at the current release level
You can confirm whether the <var class="product">Sirius Mods</var> are installed and at the current release level
by entering the following at the <var class="product">Model&nbsp;204</var> command line:
by entering the following at the <var class="product">Model&nbsp;204</var> command line:
<p class="code"><nowiki>SIRIUS
<p class="code"><nowiki>SIRIUS</nowiki></p>
</nowiki></p>
The resulting display will include the current release of the
The resulting display will include the current release of the
<var class="product">Sirius Mods</var>.
<var class="product">Sirius Mods</var>.


==<b id="insulsp"></b>Install or update RKTools==
==<b id="insulsp"></b>Install or update RKTools==
A few components of <var class="product">RKTools</var> are required for <var class="product">Janus Network Security</var>, so <var class="product">RKTools</var>
A few components of <var class="product">RKTools</var> are required for <var class="product">Janus Network Security</var>, so <var class="product">RKTools</var> must be installed prior to proceeding.
must be installed prior to proceeding.
More information is available in [[RKTools installation]].
More information is available in [[RKTools installation]].
<p class="note"><b>Note:</b> As part of <var class="product">RKTools</var> installation, that <code>JANSSL</code> file should be allocated and initialized. <code>JANSSL</code> is used to store SSL certificates, certificate requests and private keys.
<p class="note"><b>Note:</b> As part of <var class="product">RKTools</var> installation, the <code>JANSSL</code> file should be allocated and initialized. <code>JANSSL</code> is used to store SSL certificates, certificate requests and private keys.


The <code>JANSSL</code> file should be a minimum of 1050 pages;
The <code>JANSSL</code> file should have a minimum of 1050 pages;
the <var class="product">[[RKTools]]</var> <code>SIRIUS</code> file contains a sample <code>CREATE.JANSSL</code> deck.
the <var class="product">[[RKTools]]</var> <code>SIRIUS</code> file contains a sample <code>CREATE.JANSSL</code> deck.


<var class="product">RKTools</var> installation also creates the <code>JANSSL</code> subsystem, which is the certificate management application.
<var class="product">RKTools</var> installation also creates the <code>JANSSL</code> subsystem, which is the certificate management application.
The procedure containing the <code>JANSSL</code> apsy definition is <code>SUBSYS.DEF.JANSSL</code> - it is in file <code>SIRIUS</code> for releases prior to RKTools 7.7, and in <code>M204PROC</code> for 7.7 and later.
The procedure containing the <code>JANSSL</code> apsy definition is <code>SUBSYS.DEF.JANSSL</code> - it is in file <code>SIRIUS</code> for releases prior to RKTools 7.7, and in <code>M204PROC</code> for 7.7 and later.
As described later ([[#givpriv|Add appropriate users to the JANSSL subsystem]]), you may need to update the subsystem.
As described later - ([[#givpriv|Add appropriate users to the JANSSL subsystem]]) - you may need to update the subsystem.
</p>
</p>


Line 64: Line 61:
later in [[Implementing a server certificate]].
later in [[Implementing a server certificate]].


The steps in the subsections that follow describe how to set up
The following subsections describe how to set up and connect to a <var class="product">Janus Web Server</var> port.
and connect to a <var class="product">Janus Web Server</var> port.
If you are configuring a different type of Janus port, like an SSL-protected client socket port, for example,
If you are configuring a Janus <var>CLSOCK</var> SSL port, for example,
the same sequence of steps would apply except for the last subsection,
the same sequence of steps apply except for the last subsection,
and the keywords denoting the port type - <code>WEB</code> and <code>WEBSERV</code> - in the <var>JANUS</var>
but the keywords denoting the port type - <code>WEB</code> and <code>WEBSERV</code> - in the <var>JANUS</var>
command examples would be replaced by <code>CLSOCK</code>.
command examples would be replaced by <code>CLSOCK</code>.


===<b id="sslport"></b>Define and start an SSL port===
===<b id="sslport"></b>Define and start an SSL port===
Your SSL port definition indicates that connections to the port
To define an initial SSL web port using the Rocket-provided internal certificate. a user with system manager or system administrator
are to use the Rocket-provided internal certificate.
In the server Online,
a user with system manager or system administrator
privileges must issue a command like:
privileges must issue a command like:
<p class="code">JANUS DEFINE SSLWEB 443 WEBSERV 5 SSL *
<p class="code">JANUS DEFINE [portName] 443 WEBSERV 5 SSL [sslInfo]
</p>
</p>
where:
where:
<ul>
<ul>
<li><code>SSLWEB</code>  can be replaced by an arbitrary port name. </li>
<li><code>[portName]</code>  can be replaced by an arbitrary port name up to 30 characters in length. </li>


<li><code>443</code>  can be replaced by an arbitrary port number
<li><code>443</code>  can be replaced by an arbitrary port number (although 443 is the default for HTTPS). </li>
(although 443 is the default for HTTPS). </li>


<li><code>5</code>  can be replaced by a different maximum thread value. </li>
<li><code>5</code>  can be replaced by a different maximum thread value. </li>


<li><code>SSL *</code>  indicates that the internal certificate and
<li><code>[sslInfo]</code> Using a '*' indicates that the internal, Rocket-generated, certificate and
private key is to be used.
private key is to be used. When a certificate from a certifying authority is being used,
When a certificate from a certifying authority is being used,
you replace the <code>[sslInfo]</code> with the file name and procedure name
you replace the <code>*</code> with the location and name of the procedure
that contains the certificate - so, something like, "SSL MYFILE MYCERTIFICATE.CERT" - as shown in [[Implementing a server certificate#portnew|Defining and starting a port]]. </li>
that contains the certificate, as shown in [[Implementing a server certificate#portnew|Defining and starting a port]]. </li>
</ul>
</ul>


Line 106: Line 97:
When the <var class="product">RKTools</var> installation is done, the user doing the install is given privileges to run <code>JANSSL</code>.
When the <var class="product">RKTools</var> installation is done, the user doing the install is given privileges to run <code>JANSSL</code>.
If the user that did the <var class="product">RKTools</var> installation is
If the user that did the <var class="product">RKTools</var> installation is
not the one that will manage certificates and private keys, the latter
not the one who will manage certificates and private keys, the latter
user must be added as a <code>JANSSL</code> subsystem user (probably using
user must be added as a <code>JANSSL</code> subsystem user (probably using
SUBSYSMGMT).
SUBSYSMGMT).
Line 144: Line 135:


Although it is not recommended, note that this rule does <i>not</i> expose a security hole: without being a
Although it is not recommended, note that this rule does <i>not</i> expose a security hole: without being a
JANSSL subsystem user, there is not much a user can do on the SSL
JANSSL subsystem user, there is not much a user can do on the SSLthread.
thread as shipped by Rocket.
(Remember, JANSSL is the subsystem installed with <var class="product">Janus Network Security</var> that provides
(Remember, JANSSL is the subsystem installed with <var class="product">Janus Network Security</var> that provides
support for the certificate management application.)
support for the certificate management application.)
Line 165: Line 155:
<var class="product">Model&nbsp; 204</var> passwords being sent over the network as JANSSL verifies access privileges.
<var class="product">Model&nbsp; 204</var> passwords being sent over the network as JANSSL verifies access privileges.


The only reason to allow access to JANSSL like this might be that there is local network security that makes you feel confident that this is not a
The only reason to allow access to JANSSL like this might be that there is local network security that allows you to feel confident that this is not a problem, and for some reason, it is not possible for your browser to
problem, and for some reason, it is impossible to get your browser
work with the internal Janus certificate.
working with the internal Janus certificate.


====<b id="webujan"></b>Making WEBUSER a JANSSL subsystem user====
====<b id="webujan"></b>Making WEBUSER a JANSSL subsystem user====
Line 193: Line 182:
in the URL sent from the browser.
in the URL sent from the browser.


To reach a secured port, you simply specify "https" rather than "http" in the URL that points to your server.
To reach a secured port, you specify "https" rather than "http" in the URL.


If you chose to define the port with a number other than the default
If you chose to define the port with a number other than the default
Line 205: Line 194:
In response, your browser will probably initially display
In response, your browser will probably initially display
one or more notices informing you that the default
one or more notices informing you that the default
Sirius certificate has expired, that Sirius is an unknown certifying authority, or that the domain name you specified does not match the name on
Sirius certificate has expired, that Sirius is an unknown certifying authority, or that the domain name you specified does not match the name on the certificate.
the certificate.
For more information about certificates and certificate authorities,
For more information about certificates and certificate authorities,
see [[Janus Network Security#certifs|Certificates]] and [[Janus Network Security#cerauth|Certifying authorities]].
see [[Janus Network Security#certifs|Certificates]] and [[Janus Network Security#cerauth|Certifying authorities]].

Revision as of 14:59, 17 April 2017

Before you can start using secured communications with Janus Network Security, some preliminary tasks must be completed. The tasks should occur in the following sequence:

  1. Install the Sirius Mods, which contains Janus Network Security support.

    Note: This requirement does not apply if your version of Model 204 is 7.5 or higher.

    This step would probably be done by the person responsible for installing and supporting Model 204 at your site. If you are already running Janus Web Server, this step involves some minor updates in support of Janus Network Security.

  2. Install or update RKTools.
  3. Make an initial connection to a port that uses the Rocket-provided internal certificate.
    1. Define and start the SSL port.
    2. Give appropriate user(s) access privileges.
    3. Download internal certificate as CA to browser.

    Your initial connection will be a test of the setup to this point, using the Rocket-provided internal certificate (discussed in Self-signed certificates).

Each of these steps is further described below.

Install Sirius Mods

Note: This requirement does not apply to versions of Model 204 after 7.4.

The Sirius Mods are a set of features providing a base of support for most the products formerly owned by Sirius - they must be installed before proceeding.

You can confirm whether the Sirius Mods are installed and at the current release level by entering the following at the Model 204 command line:

SIRIUS

The resulting display will include the current release of the Sirius Mods.

Install or update RKTools

A few components of RKTools are required for Janus Network Security, so RKTools must be installed prior to proceeding. More information is available in RKTools installation.

Note: As part of RKTools installation, the JANSSL file should be allocated and initialized. JANSSL is used to store SSL certificates, certificate requests and private keys. The JANSSL file should have a minimum of 1050 pages; the RKTools SIRIUS file contains a sample CREATE.JANSSL deck. RKTools installation also creates the JANSSL subsystem, which is the certificate management application. The procedure containing the JANSSL apsy definition is SUBSYS.DEF.JANSSL - it is in file SIRIUS for releases prior to RKTools 7.7, and in M204PROC for 7.7 and later. As described later - (Add appropriate users to the JANSSL subsystem) - you may need to update the subsystem.

Make an initial SSL connection

In order to implement and test your first SSL connection, you can use the Rocket-provided internal certificate, which was distributed with Janus Network Security (and discussed further in Self-signed certificates Ultimately, you will probably want to arrange to receive a certificate from a commercial certifying authority, as described later in Implementing a server certificate.

The following subsections describe how to set up and connect to a Janus Web Server port. If you are configuring a different type of Janus port, like an SSL-protected client socket port, for example, the same sequence of steps would apply except for the last subsection, and the keywords denoting the port type - WEB and WEBSERV - in the JANUS command examples would be replaced by CLSOCK.

Define and start an SSL port

To define an initial SSL web port using the Rocket-provided internal certificate. a user with system manager or system administrator privileges must issue a command like:

JANUS DEFINE [portName] 443 WEBSERV 5 SSL [sslInfo]

where:

  • [portName] can be replaced by an arbitrary port name up to 30 characters in length.
  • 443 can be replaced by an arbitrary port number (although 443 is the default for HTTPS).
  • 5 can be replaced by a different maximum thread value.
  • [sslInfo] Using a '*' indicates that the internal, Rocket-generated, certificate and private key is to be used. When a certificate from a certifying authority is being used, you replace the [sslInfo] with the file name and procedure name that contains the certificate - so, something like, "SSL MYFILE MYCERTIFICATE.CERT" - as shown in Defining and starting a port.

For more information about the JANUS DEFINE command, see JANUS DEFINE.

To start the port, enter:

JANUS START SSLWEB

where SSLWEB is the port name specified on the JANUS DEFINE command. The port is started and SSL is enabled.

Add appropriate users to the JANSSL subsystem

When the RKTools installation is done, the user doing the install is given privileges to run JANSSL. If the user that did the RKTools installation is not the one who will manage certificates and private keys, the latter user must be added as a JANSSL subsystem user (probably using SUBSYSMGMT). For example, if MARY installed RKTools but CURTIS is going to manage certificates, CURTIS must be added as a JANSSL subsystem user.

In addition, while using SUBSYSMGMT, make sure that the JANSSL subsystem communication global is NEXT, the exit value is LOG, and the procedure file is SIRIUS.

Add web rule to authorize user access to the port

When the web port using the internal private key is defined, Janus Web Server rules are automatically created so that the defining user can access any resource on the SSL port. If the user that issued the JANUS DEFINE command (in Define and start an SSL port) is not the one that will manage certificates and private keys, a rule must be added to allow the latter user to access resources on the SSL port.

For example, if MORT issued the JANUS DEFINE command for the SSL port but TAMARA is going to manage certificates, add a rule like the following to the SSL port definition to allow TAMARA to access resources on that port:

JANUS WEB SSLWEB ALLOW * USER TAMARA

This is the best way to protect the server. The following subsections describe three other ways that you can authorize users to access the SSL port. Though you may be tempted to use them, each of the following is discouraged, as described below. For additional comments about access, see Many alternatives for restricting or permitting access.

Allowing any valid logged-in user

The preceding paragraphs described how to add a web server rule to authorize an individual user to access the secured port. An even simpler approach is to modify the rule as follows to allow any valid userid to access data on the SSL port:

JANUS WEB SSLWEB ALLOW * USER *

Although it is not recommended, note that this rule does not expose a security hole: without being a JANSSL subsystem user, there is not much a user can do on the SSLthread. (Remember, JANSSL is the subsystem installed with Janus Network Security that provides support for the certificate management application.)

However, this degree of access might become an issue as you add your own applications to the SSL port, at which point it is up to you whether to enforce security through web rules, subsystem access rules, or internal application checks. The appropriate security mechanism for your site in this case is beyond the scope of this document.

Accessing JANSSL through non-SSL ports

It is possible to access the JANSSL subsystem through a non-SSL port by specifying a rule such as this:

JANUS WEB WEBPORT ALLOW /JANWEB/JANSSL* USER *

where WEBPORT is not your Janus SSL port. While possible, this is strongly discouraged, because the above web rule will result in unencrypted Model  204 passwords being sent over the network as JANSSL verifies access privileges.

The only reason to allow access to JANSSL like this might be that there is local network security that allows you to feel confident that this is not a problem, and for some reason, it is not possible for your browser to work with the internal Janus certificate.

Making WEBUSER a JANSSL subsystem user

Perhaps the worst way to provide access to the certificate management application is one of the following:

  • Define as a JANSSL subsystem user the default Model 204 account ID (normally WEBUSER) that is used for logons of URLs that require no user ID.
  • Make the JANSSL subsystem public.

These approaches let anyone with a browser generate (and overlay) private keys and certificates in the JANSSL file. Security is completely gone, and you might as well not use SSL. You could perhaps make this somewhat secure by limiting access to certain URLs based on IP address, but this is still considered risky from a security perspective.

Connect to the SSL port from a browser

Having defined and configured an SSL port, you can now attempt a connection. As described in How a browser should connect, the difference between connecting to an SSL-secured port and an unsecured one is in the designation of the service in the URL sent from the browser.

To reach a secured port, you specify "https" rather than "http" in the URL.

If you chose to define the port with a number other than the default of 443, you must specify that number as well. For example, for a site that is testing the secured port 8443, specify:

https://www.yourdomain.com:8443

If you have yet to generate an internal certificate, Janus Network Security produces by default an out of date Sirius self-signed certificate. In response, your browser will probably initially display one or more notices informing you that the default Sirius certificate has expired, that Sirius is an unknown certifying authority, or that the domain name you specified does not match the name on the certificate. For more information about certificates and certificate authorities, see Certificates and Certifying authorities.

At the browser, you can view the certificate for supporting evidence that it is indeed from Sirius, then choose to accept it. Next, you are prompted for your Model 204 user ID and password.

Finally, accessing this SSL port for the first time invokes the Default Janus Web Home Page. You are taken to this page as the result of default JANUS WEB ON rules supplied with the Janus Web Server (and viewable via the JANUS DISPLAYWEB command). You can change the default page by defining a JANUS WEB ON rule for your secured port that points to another page (see JANUS WEB ON for more information).

On the default home page, a link in the introduction ("configure and manage Janus SSL support") points to a page that describes Janus SSL and which restates much of the document you are now reading. This link and those in the Janus certificate application are also resolved by default JANUS WEB ON rules.

Implementing a server certificate describes how to get an SSL certificate for your site from a certifying authority. If you want to generate an update to the default Janus internal certificate, that is, generate a self-signed certificate that will bear your own site's current information and date, you also use the request form described in "Implementing a server certificate."

See also