Using jrctl To Perform Privileged Actions

January 7, 2022
January 7, 2022
Samantha Vercillo

About

The JetRails jrctl tool provides access to unprivileged (non root) users to make changes to the firewall and grants ability to restart system services. With access to jrctl, your team has access to commonly needed tools without escalating to server admins.

Interacting with the firewall

You can use jrctl to interact with a server’s firewall. This is helpful when reviewing existing firewall entries and whitelisting/blocking IPs. Run the following command to list current firewall entries for all configured servers (standalone servers and clusters) in your deployment:

Listing firewall entries

$ jrctl firewall list

SERVER     RESPONSE
127.0.0.1  Found 0 whitelist entries.

No firewall entries found.

Allowing new IP

To whitelist a developer or admin user’s IP address 1.1.1.1 to your server/cluster on web ports 80 and 443:

$ jrctl firewall allow -a 1.1.1.1 -p 80,443

Executed only on "localhost" server(s):

SERVER     RESPONSE
127.0.0.1  Successfully added allow entry for 1.1.1.1 on ports [80 443].

Notice that the SERVER field lists 127.0.0.1 which means that jrctl is interacting with the local server. If you were managing a cluster, it would display the IP addresses of the systems which are being modified.

After making changes, you should also check to make sure the changes made are in place. We will do so by listing the current firewall entries again:

$ jrctl firewall list

SERVER     RESPONSE
127.0.0.1  Found 2 whitelist entries.

SERVER     ACTION  IPV4/CIDR  PORT(S)  PROTOCOL(S)  COMMENT
127.0.0.1  ALLOW   1.1.1.1    80       tcp          "None"
127.0.0.1  ALLOW   1.1.1.1    443      tcp          "None"

Note: Notice that there are two entries created, one for every port.

Disallowing existing IP

You may find that you need to remove a previously allowed user’s access to your deployment. This might happen if a developer no longer works on your site, or an admin user is no longer working for the company. Below is an example that will unallow1.1.1.1 on www ports 80 and 443.

$ jrctl firewall unallow -a 1.1.1.1 -p 80

Executed only on "localhost" server(s):

SERVER     RESPONSE
127.0.0.1  Successfully removed allow entry for 1.1.1.1 on ports 80.

$ jrctl firewall unallow -a 1.1.1.1 -p 443

Executed only on "localhost" server(s):

SERVER     RESPONSE
127.0.0.1  Successfully removed allow entry for 1.1.1.1 on ports 443.

Again, when making changes to the firewall, we recommend to list the current rules before and after making changes. Following the aforementioned advice, you can see that there are no more entries in place.

$ jrctl firewall list

SERVER     RESPONSE
127.0.0.1  Found 0 whitelist entries.

No firewall entries found.

Additional abilities: Deny and Undeny

We just showed how you use the allow and unallow commands. You may also use the deny and undeny commands in a similar way. Since most servers are setup with the firewall being deny-all-first, these commands will be used rarely.

Allowing Cloudflare IP blocks

Finally, if your site is behind Cloudflare, you need to give server access to Cloudflare’s IP addresses. You can manually download the list of IP addresses that Cloudflare provides, or you can do it with jrctl. You can simply allow all of Cloudflare’s IPs by running the following:

$ jrctl firewall allow cloudflare

Executed only on "localhost" server(s):

SERVER     RESPONSE
127.0.0.1  Allowed 30 new Cloudflare IP(s).

Just as easily, you can remove those entries with the following command:

$ jrctl firewall unallow cloudflare

Executed only on "localhost" server(s):

SERVER     RESPONSE
127.0.0.1  Un-Allowed 30 Cloudflare IP(s).

Restarting services

Once configured, jrctl has the ability to restart services on the local server as well as on an entire Tier of service such as Web Tier, Caching Tier, SQL Tier, etc. This is an advanced configuration which needs to be configured by the JetRails support team.

When pushing site changes, occasionally some services may need to be restarted in order to view the change on your live or dev site. You can run the following command to show what services are available to be restarted on your server or cluster:

$ jrctl server list

SERVER       TYPE(S)    SERVICE(S)
192.168.0.2  localhost  nginx, php-fpm-7.2, varnish
192.168.0.3  www        php-fpm-7.1, php-fpm-7.2
192.168.0.4  www        php-fpm-7.1, php-fpm-7.2

Restarting services is common practice for when changes need to be made, not only to the environment but also to your website. Below is an example of how to restart php-fpm-7.2 and nginx.

You are allowed to restart more than one service at a time. Services will be restarted in the order in which they are listed. In this example, php-fpm-7.2 will be restarted first, followed by nginx.

$ jrctl server restart php-fpm-7.2 nginx

Executed only on "localhost" server(s):

SERVER     SERVICE  RESPONSE
192.168.0.2  php-fpm-7.2 Successfully validated config and restarted "php-fpm-7.2".
192.168.0.3  php-fpm-7.2 Successfully validated config and restarted "php-fpm-7.2".
192.168.0.4  php-fpm-7.2 Successfully validated config and restarted "php-fpm-7.2".
192.168.0.2  nginx  Successfully validated config and restarted "nginx".

Note: Specifying duplicate arguments to the restart command will restart those services again and execution will occur in the order that said arguments appear in.

Running security audit

This functionality gives you the ability to view all SSH activity that occurs on your servers. In addition, the report returns a list of firewall rules that are active on your servers. This report captures information on who, when, where, and how the server(s) were accessed. As a way to keep your servers and sites compliant and secure, it is recommended to regularly review users and connections on your servers. You can access this report by running the following command:

$ jrctl report audit

One-Time Secret

Share sensitive information such as passwords and keys securely via our One-Time Secret service. This service allows users to (optionally) password protect sensitive information and encrypt it during transfer. A unique link is generated to distribute the secret. Once the secret is opened once, it is “burned” and no longer available to view again. If the secret is never viewed, it expires by itself.

The JetRails team does not have a way to view, or recover, or decrypt your secret payload! Be sure you have a copy of whatever you are sending.

Note: For a more detailed explanation of how to interact with this service, please refer to this article.

Additional information

The jrctl CLI tool is now available and accessible through your jump host server. If you have any questions, please reach out to a member of our support team.