Security Best Practices + Klocwork

Security best practices are essential to follow when installing any web-based application. Here, we outline the steps for setting up Klocwork, a static analysis and SAST tool, for secure operations. This process is generally on-premises and behind a firewall. There should be additional precautions taken in the case of exposing anything on the internet.

Read along or jump ahead to the section that interests you the most:

• Security Best Practices with Klocwork Overview
• STEP 1: SSL/TSL
• STEP 2: Open Ports and Routes
• STEP 3: Authentication

➡️ Try Klocwork Now for software security

Security Best Practices with Klocwork Overview

Klocwork portals receive analysis results to prepare big-picture reports on compliance, trends, and issue details.  You can log in to view the reports, triage issues, and configure analysis settings. In addition, Klocwork portals are deployed on-premises or here in the cloud. They can run on bare metal, within VMs, or in containers.

Klocwork’s out-of-the-box authentication and security settings are configured to make it easy to set up and get familiar with it in a test setting, but using it in a production environment, where the portal is handling important data, requires changes to its configuration.

Key areas to configure are:

1. Move to HTTPS (SSL/TSL settings)
2. Open selective ports and routes
3. Authentication and SSO

From a security perspective, here are the Klocwork components. These are the default port numbers for simplicity — all of which are configurable.

Klocwork’s server-side components can reside on the same VM or the license service can run on a separate VM. Three ports must be open:

1. License service common (27000)
2. License service Klocwork daemon (33133)
3. Klocwork portal (443).

The license service common port and the Klocwork portal port are used when configuring client tools.

There are two basic techniques for encrypting the communication between the Klocwork portal and Klocwork client tools or browsers:

1. Use a reverse proxy
2. Configure the Klocwork portal for SSL/TSL

Using a reverse proxy is often the choice of IT departments because they are familiar with their installation and configurations and they work well.  A reverse proxy is required if you wish to deploy the Klocwork portal on port 443 on a Linux host. 

Configuring Klocwork itself to run as an SSL/TSL (https) service can be done in three simple steps:

1. Request a signed SSL/TSL certificate from your corporate signing authority for the host running a Klocwork portal.  While waiting you can use an unsigned certificate generated by kwauthconfig.
2. Run kwauthconfig to configure the portal for https connections.
3. Notify your users to use https and update their IDE’s Klocwork plugin configuration with “use secure connection” and the new port number.

Requesting a Signed SSL/TSL Certificate

Here’s an example of openssl commands to generate the key pair and the certificate signing request file (.csr). Only the portal.csr file is sent to the signing authority.

openssl genrsa -out portal.key 2048
openssl req -new -key portal.key -out portal.csr
 Country Name (2 letter code) []: US
 State or Province Name (full name) []: Minnesota
 Locality Name (eg, city) []: Minneapolis
 Organization Name (eg, company) []: mycompany Inc.
 Organizational Unit Name (eg, section) []: Defense
 Common Name (eg, your server's hostname) []: klocwork.mycompany.com
 Email Address []: [email protected]

The format of the certificate file you receive back may vary. It will likely contain the host’s certificate, any intermediate certificates, and the root certificate of the signing authority.  If it only contains the host certificate, you will need to download the intermediate and root certificates manually. What is required is that the private key is combined with all these certificates to form the keystore.

Here’s an example of the openssl commands when a p7b file is received.

openssl pkcs7 -print_certs -in myhost.p7b -out myhost.cer -inform der
openssl pkcs12 -export -in myhost.cer -inkey portal.key -out
        myhost_keystore.pfx -name tomcat
  Enter Export Password: changeit
  Verifying - Enter Export Password: changeit
openssl pkcs12 -nokeys -info -in myhost_keystore.pfx

The password and name are the default values used by the Klocwork portal, but you can use other names. However, you would then need to manually edit the tomcat server configuration information in the projects_root/tomcat/conf/server.template file. The last command outputs the contents of the keystore for verification.

The output file, myhost_keystore.pfx, is a pkcs12 keystore and must be copied to projects_root/tomcat/conf/.keystore for the Klocwork portal to find it.

SSL/TSL Connection Used to the LDAP Server

When an SSL/TSL connection is used to the LDAP server (i.e. ldaps://…), which is recommended, the server’s cerificates must ke saved in the portal’s trust store (<Klocwork server install>/_jvm/lib/security/cacerts).  The Klocwork installation includes the <Klocwork install>/_jvm/bin/keytool utility for this task. For example:

keytool -import -alias ldaproot -file rootca.cer -keystore cacerts
keytool -import -alias ldapInter -file inter.cer -keystore cacerts
keytool -import -alias ldap -file ldap.cer -keystore cacerts

Run kwauthconfig

While it is possible to manually edit the projects_root/config/admin.conf and projects_root/tomcat/conf/server.template files, the easier choice is usually to use the gui tool kwauthconfig. 

If your Klocwork portal service is hosted on a Linux OS, without a desktop, you will need to use an X11 server. kwauthconfig is included with the Klocwork server install package.

kwauthconfig is also used to configure the portal for authentication and email notifications. The following example just focuses on the SSL/TSL configuration.

It’s very important that you:

• Stop the Klocwork portal services before changing the configuration.
• Copy your keystore (e.g. myhost_keystore.pfx) to projects_root/tomcat/conf/.keystore before starting kwauthconfig if the keystore is available. If there is no .keystore file then kwauthconfig will create an unsigned certificate.

Kwauthconfig will open with the last projects_root configuration data or prompt for a projects_root directory.

The hostname, Organizational unit, and Organization fields can be left blank if you’ve copied your keystore to .keystore. Only the hostname is critical, it must match the hostname of the machine hosting the portal. Most installations don’t require smart card authentication but, if selected, you must supply the location and password for the trust store of client certificates.

No other data is required for kwauthconfig to complete the SSL/TSL setup. Click “Next” until you can click “Finish” then “OK” to exit kwauthconfig.

Optionally, you can change the Klocwork portal port before starting the services.

For example, to switch from the default port 8080 to 443, use the command:

 kwservice -r projects_root set-service-property klocwork port 443

Start the database and Klocwork services and browse to https://hostname:port.

➡️ FREE 7-DAY TRIAL

Inform Klocwork Users

The final step is to inform your Klocwork users so they can update their scripts with the new https url and check the “Use Secure Connect” checkbox in the IDE Klocwork plugins Options/Preferences.

Security Best Practices: Open Ports and Routes

A Klocwork installation requires:

• Three ports for inbound connections
• An internal database port
• Optional routes to three remote servers for authentication (e.g. Active Directory/LDAP), sending email notifications, and exporting data to bug tracking applications.

Any firewalls between client tools and the license/portal services must have ports 27000, 33133, and 8080 open for TCP/IP connections. No other ports are used for inbound connections.

These port numbers are configurable using the kwservice command and, for the license ports, edits to the license file. 

For example:

kwservice –projects-root <projects_root> set-service-property klocwork port 443

A typical re-assignment is to use port 443 for SSL/TSL to the Klocwork portal.  This is simple to do if your portal is running on a Windows OS; just use the kwservice command.  Under Linux OSes, you will need to use port 443 or, for port 443, a reverse proxy because port 443 is a reserved port and the Klocwork portal cannot be run as root.

Optionally, the Klocwork portal requires outbound connections to an authentication server, an SMTP server for email notifications, and a bug tracking server (e.g. JIRA). These external servers must be configured to accept connections from the Klocwork portal.

The database port (defaults to port 3306) must not be accessible by external applications.

Security Best Practices: Authentication

Klocwork’s out-of-the-box authentication configuration is “Authentication Disabled”.  This is great for initial setup and test, but is not suitable for a production environment.  As anyone that logs in will automatically have an account created every time.

Instead, you should use the next higher authentication configuration, “Basic”. In this mode, only those users that have a Klocwork portal user account can log on. 

The first account is created automatically using the username of the user who installed the server package.  To enable Basic authentication, you must go to the portal and click on the Authentication Disabled link on the Users page.

In the Authentication Disabled and Basic modes, Klocwork maintains a user and group database.  Users are assigned roles on projects, or all projects, which restrict what they can see and do while logged on.

To improve authentication security an external user database can be used.  Klocwork supports both NIS and LDAP servers. Klocwork can also be configured for Single sign-on for Active Directory users on Windows. Configuring a  Klocwork portal to use an external user database is done via kwauthconfig.

Kwauthconfig provides a default configuration when it detects an Active Directory  server. This works well as an initial configuration, but if the number of users in your external database is large, it is better to refine the user and group filters to reduce the response times.

The key kwauthconfig dialogs are:

1. Settings for accessing the server including the user account to log onto the server. Ideally, a service account is used that has a long-lived password. The default password for cacerts is "changeit".

2. Customizing the providers and filters. In this example, the user filter has been set to “(&(objectCategory=person)(sAMAccountName=*)(memberOf=CN=KlocworkUsers,OU=Groups,DC=klocwork,DC=com))”.

This requires users to be a member of the KlocworkUsers Active Directory Security Group. It is best to work with your IT department to optimize the provider and filter settings to minimize the workload on your LDAP server and the Klocwork portal.

3. Specifying which attributes are to be retrieved.

In this example, either a user’s cn or sAMAccountName attribute value can be used to log in. The left-most User Attribute is used to display the user’s name and to search for users on the Users portal page. If you have multiple users with identical cn values it is better to specify a unique attribute first.

4. Clicking “Finish” completes the configuration setup. To test the server connection click “Test Connection”.

Security Best Practices with Klocwork Review

Security best practices for Klocwork are as simple as:

1. Configure SSL/TSL
2. Open specific ports and routes
3. Enable authentication

After applying those configuration steps, you will have:

1. Controlled access points
2. Encrypted all Klocwork data and user credentials when they are passed between the portal and client tools
3. Controlled who can access data on the portal

If you would like to see for yourself how Klocwork SAST helps you to ensure software security, sign up for a free trial now.

➡️ START YOUR FREE KLOCWORK TRIAL