Installing and configuring Janus Network Security: Difference between revisions
m (link repair) |
|||
Line 53: | Line 53: | ||
<var class="product">Sirius Mods</var>. | <var class="product">Sirius Mods</var>. | ||
==<b id="insulsp"></b>Install or update RKTools== | |||
A base portion of <var class="product">RKTools</var> is required for <var class="product">Janus Network Security</var>, so <var class="product">RKTools</var> | A base portion of <var class="product">RKTools</var> is 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. |
Revision as of 16:15, 14 April 2017
Before you can start using secured communications with Janus Network Security, preliminary tasks must be completed. Some of these tasks may be performed by different people, but they should occur in the following sequence:
- Install Janus TCP/IP Base
- 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.
- Install or update RKTools.
Step 1 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 for support of Janus Network Security.
- Install the Sirius Mods, which contains Janus Network Security support.
- Make an initial connection to a port that uses the
Rocket-provided internal certificate.
- Define and start the SSL port.
- Give appropriate user(s) correct privileges.
- Download internal certificate as CA to browser.
In step 2 you test the success of your first connection, using the Rocket-provided internal certificate (discussed in Self-signed certificates).
Each of these steps is further described below.
Install Janus TCP/IP Base
As mentioned earlier, Janus Network Security is generally installed as an addition to Janus Web Server. It can also be installed without it, for use by other non-web Janus products. In either case, some of the steps in the following subsections may have already been completed. You should confirm each one before proceeding to the next step.
Install Sirius Mods
Note: This requirement does not apply to versions of Model 204 after 7.4.
The Sirius Mods are a combination of features which provide a base of support for most Sirius products, and they must be installed prior to proceeding.
You can confirm whether the Sirius Mods are installed and at the current release by entering the following command at the Model 204 command line:
SIRIUS
This will display various information regarding the configuration of Sirius products in this online, including the current release of the Sirius Mods.
Install or update RKTools
A base portion of RKTools is 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, you should allocate and initialize a file called JANSSL
, which
has the correct characteristics for storing an SSL private key.
The JANSSL
file should be a minimum of 1050 pages;
the RKTools SIRIUS
file contains a sample CREATE.JANSSL
deck.
RKTools installation also creates a subsystem called JANSSL
, which provides
components for the certificate management application.
The SIRIUS
file that contains the definition is SUBSYS.DEF.JANSSL
.
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 the success of your first SSL connection, you can use the Rocket-provided internal certificate, which was distributed with the Janus Network Security tape (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 steps in the subsections that follow describe how to set up
and connect to a Janus Web Server server port.
If you are configuring a Janus CLSOCK SSL port, for example,
the same sequence of steps apply (except for the last subsection),
but the keywords WEB
and WEBSERV
in the JANUS
command examples must be replaced as necessary by CLSOCK
.
Define and start an SSL port
Your SSL port definition indicates that connections to the port 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:
JANUS DEFINE SSLWEB 443 WEBSERV 5 SSL *
where:
SSLWEB
can be replaced by an arbitrary port name.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.SSL *
indicates that the internal certificate and private key is to be used. When a certificate from a certifying authority is being used, you replace the*
with the location and name of the procedure that contains the certificate, 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 that 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 SSL thread as shipped by Rocket. (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 makes you feel confident that this is not a problem, and for some reason, it is impossible to get your browser working 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 simply specify "https" rather than "http" in the URL that points to your server.
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."