A REST application to dynamically update firewalld rules on a linux server

Firewalld is a firewall management tool for Linux operating systems.

There were 534 failed login attempts since the last successful login.

If you have seen the above message when you log into your linux server, then this article is for you.

The simple idea behind this is to have a completely isolated system, a system running Firewalld that does not permit SSH access to any IP address by default so there are no brute-force attacks. The only way to access the system is by communicating with a REST application running on the server through a valid request containing your public IP address.

The REST application validates your request (it checks for a valid JWT, covered later), and if the request is valid, it will add your IP to the firewalld rule for the public zone for SSH, which gives only your IP SSH access to the machine.

Once you are done using the machine, you can remove your IP by interacting with the same REST application, and it changes rules in firewalld, removing your IP, shutting off SSH access and thereby isolating the system again.

Layman’s explanation

Imagine the server being your house, and the SSH password as a lock on the main door of your house. Only you have the key to open the lock and enter your house, but you cannot prevent anyone walking in front of your house to see the lock, neither can you prevent someone to try a brute force method to open the lock by using randomly generated keys (hence the numerous failed login attempts that you see).

By using the approach presented in this repo, you are adding a gate in front of your house (namely firewalld). The gate prevents bad folks from getting too close to the house, so that they cannot even look at the lock to try randomly generated keys. And the REST application is the only way to open or close that gate. Also, to communicate with this REST application, you need to possess a certain key (an RS256 type, covered later), without which you cannot even talk to it (Good luck brute forcing that).

So, in short, you need to possess a key to talk to the REST application, which opens the gate for you to access the lock. After that, you use your key to open the lock and get into your house.

Safe and secure.

Github repo: github.com/prashantgupta24/firewalld-rest

1. Pre-requisites

This repo assumes you have:

1. A linux server with firewalld installed.
2. root access to the server. (without root access, the application will not be able to run the firewall-cmd commands needed to add the rule for SSH access)
3. Some way of exposing the application externally (there are examples in this repo on how to use Kubernetes to expose the application)

2. About the application

2.1 Firewall-cmd

Firewall-cmd is the command line client of the firewalld daemon. Through this, the REST application adds the rule specific to the IP address sent in the request.

The syntax of adding a rule for an IP address is:

firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="10.xx.xx.xx/32" port protocol="tcp" port="22" accept'

Once the rule for the IP address has been added, the IP address is stored in a database (covered next). The database is just to keep track of all IPs that have rules created for them.

2.2 Database

The database for the application stores the list of IP addresses that have rules created for them which allow SSH access for those IPs. Once you interact with the REST application and the application creates a firewalld rule specific to your IP address, then your IP address is stored in the database. It is important that the database is maintained during server restarts, otherwise there may be discrepancy between the IP addresses having firewalld rules and IP addresses stored in the database.

Note: Having an IP in the database does not mean that IP address will be given SSH access. The database is just a way to reference all the IPs with rules created in firewalld.

The application uses a file type database for now. The architecture of the code allows easy integration of any other type of databases. The interface in db.go is what is required to be fulfilled to introduce a new type of database.

2.3 Authorization

The application uses RS256 type algorithm to verify the incoming requests.

RS256 (RSA Signature with SHA-256) is an asymmetric algorithm, and it uses a public/private key pair: the identity provider has a private (secret) key used to generate the signature, and the consumer of the JWT gets a public key to validate the signature.

The public certificate is in the file publicCert.go, which is something that will have to be changed before you can use it. (more information on how to create a new one later).

2.4 Tests

The tests can be run using make test. The emphasis has been given to testing the handler functions and making sure that IPs get added and removed successfully from the database. I still have to figure out how to actually automate the tests for the firewalld rules (contributions are welcome!)

3. How to install and use on server

3.1 Generate JWT

Update the file publicCert.go with your own public cert for which you have the private key.

If you want to create a new set:

openssl genrsa -key private-key-sc.pem
openssl req -new -x509 -key private-key-sc.pem -out public.cert

Once you have your own public and private key pair, then after updating the file above, you can go to jwt.io and generate a valid JWT using RS256 algorithm (the payload doesn't matter). You will be using that JWT to make calls to the REST application, so keep the JWT safe.

3.2 Build the application

Run the command:

make build-linux DB_PATH=/dir/to/db/

It will create a binary under the build directory, called firewalld-rest. The DB_PATH=/dir/to/keep/db statement sets the path where the .db file will be saved on the server. It should be saved in a protected location such that it is not accidentally deleted on server restart or by any other user. A good place for it could be the same directory where you will copy the binary over to (in the next step). That way you will not forget where it is.

If DB_PATH variable is not set, the db file will be created by default under /. (This happens because the binary is run by systemd. If we manually ran the binary file on the server, the db file would be created in the same directory.)

Once the binary is built, it should contain everything required to run the application on a linux based server.

3.3 Copy binary file over to server

scp build/firewalld-rest root@<server>:/root/rest

Note: if you want to change the directory where you want to keep the binary, then make sure you edit the firewalld-rest.service file, as the linux systemd service definition example in this repo expects the location of the binary to be /root/rest.

3.4 Remove SSH service from public firewalld zone

This is to remove SSH access from the public zone, which will cease SSH access from everywhere.

SSH into the server, and run the following command:

firewall-cmd --zone=public --remove-service=ssh --permanent

then reload (since we are using --permanent):

firewall-cmd --reload

This removes ssh access for everyone. This is where the application will come into play, and we enable access based on IP.

Confirmation for the step:

firewall-cmd --zone=public --list-all

Notice the ssh service will not be listed in public zone anymore.

Also try SSH access into the server from another terminal. It should reject the attempt.

3.5 Expose the REST application

The REST application can be exposed in a number of different ways, I have 2 examples on how it can be exposed:.

1. Using a NodePort kubernetes service (link)
2. Using ingress along with a kubernetes service (link)

3.5.1 Single node cluster

For a single-node cluster, you can use a NodePort service, something like this:

apiVersion: v1
kind: Service
metadata:
  name: external-rest
spec:
  externalIPs:
  - 169.xx.xx.xxx # public IP of the server
  type: NodePort
  ports:
  - name: firewalld
    protocol: TCP
    port: 8080
    targetPort: 8080
---
apiVersion: v1
kind: Endpoints
metadata:
  name: external-rest
subsets:
  - addresses:
      - ip: 10.xx.xx.xx #private IP of server
    ports:
      - port: 8080
        name: firewalld

The important thing to note is that we manually add the Endpoints resource for the service, which points to our node's private IP address and port 8080.

Once deployed, your service might look like this:

kubernetes get svc
external-rest | NodePort | 10.xx.xx.xx | 169.xx.xx.xx | 8080:31519/TCP

Now, you can interact with the application on:

169.xx.xx.xx:31519/m1/

Note: Since there’s only 1 node in the cluster, you will only ever use /m1. For more than 1 node, see the next section.

3.5.2 Multi-node cluster

For a multi-node cluster, an ingress resource would be highly beneficial.

The first step would be to create the kubernetes service in each individual node, using this service definition (link here):

apiVersion: v1
kind: Service
metadata:
  name: external-rest #external-rest-2 for 2nd machine and so on
spec:
  ports:
  - name: firewalld
    protocol: TCP
    port: 80
    targetPort: 8080
---
apiVersion: v1
kind: Endpoints
metadata:
  name: external-rest #external-rest-2 for 2nd machine and so on
subsets:
  - addresses:
      - ip: 10.xx.xx.xx #private IP of node
    ports:
      - port: 8080
        name: firewalld

The important thing to note is that we manually add the Endpoints resource for the service, which points to that node's private IP address and port 8080.

The second step is the ingress resource (link here). It redirects different routes to different nodes in the cluster.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
 name: firewalld-ingress
spec:
 rules:
 - host: <your-host-name>
   http:
    #different paths for different hosts under the same k8s config
     paths:
     - path: /m1
       backend:
         serviceName: external-rest
         servicePort: 80
     - path: /m2
       backend:
         serviceName: external-rest-2
         servicePort: 80
     - path: /m3
       backend:
         serviceName: external-rest-3
         servicePort: 80

For example, in the ingress file above:

a request to /m1 will be redirected to the first node, a request to /m2 will be redirected to the second node, and so on. This will let you control each node's individual SSH access through a single endpoint.

3.6 Configure linux systemd service

An example of a linux systemd service file (link here):

[Unit]
Description=Firewalld rest service
After=network.target
[Service]
Type=simple
Restart=always
RestartSec=1
User=root
ExecStart=/root/rest/firewalld-rest
[Install]
WantedBy=multi-user.target

This file should be called firewalld-rest.service and should be placed inside the etc/systemd/system directory.

Note: This example assumes your binary is at /root/rest/firewalld-rest. You can change ExecStart to point to your binary file location on the server.

3.7 Start and enable systemd service.

Start

systemctl start firewalld-rest

Logs

You can see the logs for the service using:

journalctl -r

Enable

systemctl enable firewalld-rest

3.8 IP JSON

This is how the IP JSON looks like, so that you know how you have to pass your IP and domain to the application:

type IP struct {
	IP     string `json:"ip"`
	Domain string `json:"domain"`
}

3.9 Interacting with the REST application

3.9.1 Index page

route{
    "Index Page",
    "GET",
    "/",
}

Sample query

curl --location --request GET '<SERVER_IP>:<port>/m1' \
--header 'Authorization: Bearer <jwt>'

3.9.2 Show all IPs

route{
    "Show all IPs present",
    "GET",
    "/ip",
}

Sample query

curl --location --request GET '<SERVER_IP>:<port>/m1/ip' \
--header 'Authorization: Bearer <jwt>'

3.9.3 Add new IP

route{
    "Add New IP",
    "POST",
    "/ip",
}

Sample query

curl --location --request POST '<SERVER_IP>:<port>/m1/ip' \
--header 'Authorization: Bearer <jwt>' \
--header 'Content-Type: application/json' \
--data-raw '{"ip":"10.xx.xx.xx","domain":"example.com"}'

3.9.4 Show if IP is present

route{
    "Show if particular IP is present",
    "GET",
    "/ip/{ip}",
}

Sample query

curl --location --request GET '<SERVER_IP>:<port>/m1/ip/10.xx.xx.xx' \
--header 'Authorization: Bearer <jwt>'

3.9.5 Delete IP

route{
    "Delete IP",
    "DELETE",
    "/ip/{ip}",
}

Sample query

curl --location --request DELETE '<SERVER_IP>:<port>/m1/ip/10.xx.xx.xx' \
--header 'Authorization: Bearer <jwt>'