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.
Listing firewall entries
Run the following command to list current firewall entries for all configured servers (standalone servers and clusters) in your deployment:
$ 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 service list
Filtering servers that match the following type(s): localhost
HOSTNAME SERVER TYPE(S) RESPONSE
foo.jetrails.com 127.0.0.1 localhost found 4 service(s)
bar.jetrails.com 127.0.0.2 db found 4 service(s)
HOSTNAME SERVICE STATUS RESTART RELOAD ENABLE DISABLE
foo.jetrails.com nginx enabled ✔ ✔ ✔ ✔
foo.jetrails.com php-fpm-7.1 enabled ✔ ✔ ✔ ✔
foo.jetrails.com php-fpm-7.2 disabled ✔ ✔ ✔ ✔
bar.jetrails.com mysql disabled ✔ ✔ ✔ ✔
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 service restart php-fpm-7.2 nginx
Filtering servers that match the following type(s): localhost
SERVER SERVICE RESPONSE
127.0.0.1 php-fpm-7.2 successfully restarted "php-fpm-7.2"
127.0.0.1 nginx successfully 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.
Additional information
The jrctl CLI tool is available and accessible through your jump host server. If you have any questions, please reach out to a member of our support team. Also see Using jrctl In Clustered Environments