Service Applications

Service applications

Some Checkpoint applications can be described as "services". Typically these are long-running applications which talk to multiple users and are normally started at boot time; for example, Chameleon and Chainmail count as service applications. Checkpoint does not treat these any differently from ordinary single-user / short-lifetime applications, but there are some best-practice and configurational issues to consider. We try to make our applications all behave in the same way as far as applicable. In particular, this section applies equally to our products Chameleon, Chainmail and Dumper (but is not limited to these three).

[Note] These service applications should not be confused with the use of the term service inside phrases like "web services". Service applications talk directly to end users, whereas services are lower-level facilities which are intended to be used by applications (or by other services), and which are inaccessible to users. Checkpoint provides a range of services to its applications.

Where to install a service application

If the service application needs to be accessed from outside your LAN, then it should be installed, under Checkpoint, on a DMZ (DeMilitarised Zone) host. This is on a special, separate network attached to your firewall. Instead of attempting to connect to the DMZ host directly (the firewall should prohibit this) users connect to the firewall instead; the firewall then "port-forwards" the connection to a suitable port on the DMZ host.

This setup usually treats connections from hosts on your LAN in the same way as those from hosts on the external Internet. You'll need to use the name or IP address by which your firewall is known on the external Internet ("red interface", in firewall-speak) rather than the local name or IP address by which it's known on your LAN ("green interface"). Talk to your firewall admin if you have one.

If the service application only needs to be accessed from within your LAN, and your LAN hosts are reasonably trusted, you can install the service on one of the LAN hosts. Try to choose one which isn't intensively used for other purposes, and which isn't likely to need to be rebooted too often.

This is not a good idea in an educational institution! Machines which are under the influence of pupils, students, other potential larval-stage hackers, or script kiddies, should not be trusted.

If the service application needs to be accessed from outside your LAN, your LAN hosts are reasonably trusted, and you absolutely cannot afford a DMZ host, then at a pinch you might get away with putting the service on a suitable LAN host and port-forwarding to it from the firewall. Not recommended. Get a DMZ host as soon as you can.

Initial Installation

This procedure is for installation on a workstation or headful server (ie. a server which supports a GUI, even if there happens to be no monitor or keyboard attached to it most of the time). To install on a headless server (no GUI support) requires an extended procedure.

Before you can install your Checkpoint Application, you must have first installed Checkpoint. Doing this on your particular platform is covered in a separate, platform-specific guide: currently we support Windows and Linux (x86). Once you've done that:

1. There are platform-specific issues which need to be taken into account in order to ensure security best practice. Read up on this first, for your chosen platform:
   • Windows
   • Linux (x86)
2. Login to the Checkpoint Command Centre. The rest of this procedure takes place inside.
3. Decide how you want to start the service. If you want the service to start automatically, you'll need to allow it to login to Checkpoint without a token. If you don't mind starting it manually, you can mandate the use of a token. The latter is quite a lot more secure, but in many situations the convenience of automatic restart will be felt to outweigh this.
4. If appropriate, create a new Checkpoint subject for the service. Generally you'll want one Checkpoint subject for each product (eg. one Checkpoint subject for all Chameleon installations, and another for a Chainmail installation); you may want one Checkpoint subject per installation, although this is usually excessive. This subject should have a token or not, depending on your decision in the previous step.
5. Give the Checkpoint subject (generally via the user ID DN) the required permissions. Usually these are:
   • Login enabled (without this enabled for the DN which is passed to the application, the application won't be able to login to the Checkpoint Daemon, and won't start)
   • May install code (minor potential security risk, but it'll make your life a good deal easier; it's a fair tradeoff. If you're feeling paranoid, disable this for normal use and enable it only when upgrading)
   • May list existing subjects (most service applications have an optional feature to allow new users to register automatically. In order for this to work, the service application itself needs this privilege)
   • May create new subjects (ditto)
6. Create a new Checkpoint subsystem for the service, if necessary. Assign the subsystem to the Checkpoint subject you created in step 4. In order to do this, you must be logged into Checkpoint with the "Create subsystem" privilege. [In general, a service application installation can share its subsystem with other service applications, but not with other installations of the same application.]
7. Log into the subsystem you created in step 6, as the subject you created in step 4. Verify that you are the subsystem owner.
8. When a user logs into the service application, they ipso facto log into the subsystem as well. Therefore you need to set the subsystem security settings to permit this. This means either ACL entries or an open subsystem.
9. Install the application modules. Typically a Checkpoint application will have four modules: code, chrome, skeleton and documentation. If the application is called baz then you can expect to find modules named baz-a.b.c.cpm (code), baz.chrome-d.e.f.cpm (chrome), baz.skel-g.h.j.cpm (skeleton) and baz.docs-k.m.n.cpm (documentation). For a new installation you install the code module yourself and let the InstallMage pick up the rest as dependencies, which it will install for you. For upgrades, you probably only want some subset of the modules; see the application's release notes for details. NB. for an upgrade, you usually DON'T want the skeleton.
10. Configure the application. The procedure for this is application-specific - see the application documentation for details.

How to run a service application

Service applications can be run from Checkpoint Command Centre in the same way as ordinary applications. This is the easiest approach, and allows two-factor authentication for the service's login. This means that it's also potentially the most secure. However, it prevents the service application from starting automatically on boot; it requires manual intervention at the console.

Alternatively, you may go for a scripted startup, or launch from the desktop. In this situation, you will need to supply login credentials for the application as command-line parameters; this requires the application's login DN to be able to login without a token. The three parameters must be, in order:

1. Login DN
2. Password
3. Subsystem ID

These parameters must come last on the command line. In particular, any -conf flag (and its parameter) must come before these three.

How to shut down a service application

Well-written Checkpoint service applications generally don't mind being terminated abruptly, provided that they're idle at the time; however, if the termination happens during the middle of a transaction there may be trouble.

If there's no disk or network activity, and there hasn't been any for ten seconds or so, and none appears while you're doing this, hee hee, then the service is idle. In this state, it's safe to simply kill the process, as for a generic application. The procedure for doing this is platform-specific [Windows, Linux (x86) ].

If the service is heavily loaded, or you don't feel confident that a new transaction will not suddenly appear during the killoff, then you must shut down the service properly. There are two ways to do this.

1. Use the service's administration interface. This generally involves logging into the service as a user who has the requisite privileges and shutting it down via that interface. This will know how to shut the service down cleanly. This may feel somewhat long-winded (especially if you need to shut down a host running several service applications, and you're in a hurry) but can be done remotely.
2. Web-based service applications, or service applications which at least have a web-based administration interface, probably use Checkpoint's "Pasiphae" toolkit. These can usually be cleanly shut down using the pasistop utility bundled with Checkpoint. This is easier, but can only be done from the console of the host (machine) running the service application.

Installation on a headless server

This is an advanced technique which is only supported on Linux. See the platform-specific guide.