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:
- A linux server with
firewalld
installed. root
access to the server. (withoutroot
access, the application will not be able to run thefirewall-cmd
commands needed to add the rule for SSH access)- 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:.
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 svcexternal-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>'