A REST application to dynamically update firewalld rules on a linux server.
Firewalld is a firewall management tool for Linux operating systems.
If you have seen this message when you login to your linux server:
There were 534 failed login attempts since the last successful login.
Then this idea 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 interacting with the same REST application, and it changes rules in firewalld, shutting off SSH access and isolating the system again.
This repo takes a proactive approach rather than a reactive approach taken by fail2ban. fail2ban dynamically alters the firewall rules to ban addresses that have unsuccessfully attempted to login a certain number of times. It is reactive - it allows people to try and login to the server, but bans those who are unsuccessful in doing so after a certain number of times. It is like appointing a guard (aka firewall) outside a locked building who checks for suspicious activity and the guard is told by fail2ban to ban anyone who tries to open the lock unsuccessfully many times.
Firewalld-rest is more of a proactive approach. Let me explain.
By using the approach presented in this repo, you still add a guard (aka firewall) like you did for fail2ban in front of your locked building (aka the server). But there are 2 main differences here:
- This guard is told to not let anyone come near the building by default, so that no one is ever close enough to the lock to try their keys. (This means that the default firewall rules are set up by default in such a way so that no one can even try to SSH to the server).
- You can talk to the guard (aka firewall) using this repo, and convince the guard to allow you near the building, provided you possess a certain key (an RS256 type, covered later). (This means that using the REST interface provided by this repo, you proactively alter firewall rules to allow ONLY your IP to try and login to the server)
Note: Once you are allowed through by the firewall, you still need to have the key to login to the server.
It is proactive - You proactively talk to the REST interface and alter the firewall rules to allow your IP to try and login.
TL;DR
fail2ban |
firewalld-rest |
|---|---|
dynamically alters firewall rules to ban IP addresses that have unsuccessfully attempted to login to server a certain number of times. |
provides REST interface to manually alter firewall rules to allow ONLY your IP to try and login to server. No IP apart from yours can even try to login to server. |
Reactive - it alters firewall rules after unsuccessfully attempts |
Proactive - you alter firewall rules before trying to login to server |
Note: I am not saying one approach is better than the other. They are just different approaches to the same problem.
- Purpose
- Comparison with fail2ban
- Table of Contents
- 1. Pre-requisites
- 2. About the application
- 3. How to install and use on server
- 4. Helpful tips/links
- 5. Commands for generating public/private key
- 6. Possible enhancements
This repo assumes you have:
- A linux server with
firewalldinstalled. rootaccess to the server. (withoutrootaccess, the application will not be able to run thefirewall-cmdcommands 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 service)
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.
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.
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 this 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).
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!)
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, see the section on generating your own public/private key. 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.
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.
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.
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.
The REST application can be exposed in a number of different ways, I have 2 examples on how it can be exposed:
For a single-node cluster, see the kubernetes service example here. 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.
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 the example here. 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.
The second step is the ingress resource. It redirects different routes to different nodes in the cluster. 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.
See this for an example of a linux systemd service.
The .service file should be placed under etc/systemd/system directory.
Note: This service assumes your binary is at /root/rest/firewalld-rest. You can change that in the file above.
Start
systemctl start firewalld-rest
Logs
You can see the logs for the service using:
journalctl -r
Enable
systemctl enable firewalld-rest
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"`
}
route{
"Index Page",
"GET",
"/",
}
curl --location --request GET '<SERVER_IP>:8080/m1' \
--header 'Authorization: Bearer <jwt>'
route{
"Show all IPs present",
"GET",
"/ip",
}
curl --location --request GET '<SERVER_IP>:8080/m1/ip' \
--header 'Authorization: Bearer <jwt>'
route{
"Add New IP",
"POST",
"/ip",
}
curl --location --request POST '<SERVER_IP>:8080/m1/ip' \
--header 'Authorization: Bearer <jwt>' \
--header 'Content-Type: application/json' \
--data-raw '{"ip":"10.xx.xx.xx","domain":"example.com"}'
route{
"Show if particular IP is present",
"GET",
"/ip/{ip}",
}
curl --location --request GET '<SERVER_IP>:8080/m1/ip/10.xx.xx.xx' \
--header 'Authorization: Bearer <jwt>'
route{
"Delete IP",
"DELETE",
"/ip/{ip}",
}
curl --location --request DELETE '<SERVER_IP>:8080/m1/ip/10.xx.xx.xx' \
--header 'Authorization: Bearer <jwt>'
-
firewall-cmd --get-default-zone firewall-cmd --get-active-zones firewall-cmd --list-all-zones | less firewall-cmd --zone=public --list-sources firewall-cmd --zone=public --list-services firewall-cmd --zone=public --list-all firewall-cmd --zone=public --add-service=ssh --permanent firewall-cmd --zone=internal --add-source=70.xx.xx.xxx/32 --permanent firewall-cmd --reloadfirewall-cmd --permanent --zone=public --list-rich-rulesfirewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="10.10.99.10/32" port protocol="tcp" port="22" accept'firewall-cmd --permanent --zone=public --add-rich-rule='rule family="ipv4" source address="192.168.100.0/24" invert="True" drop'Reject will reply back with an ICMP packet noting the rejection, while a drop will just silently drop the traffic and do nothing else, so a drop may be preferable in terms of security as a reject response confirms the existence of the system as it is rejecting the request.
--add-source=IP can be used to add an IP address or range of addresses to a zone. This will mean that if any source traffic enters the systems that matches this, the zone that we have set will be applied to that traffic. In this case we set the ‘testing’ zone to be associated with traffic from the 10.10.10.0/24 range.
[root@centos7 ~]# firewall-cmd --permanent --zone=testing --add-source=10.10.10.0/24 success
openssl genrsa -key private-key-sc.pem
openssl req -new -x509 -key private-key-sc.pem -out public.cert
- Rate limiting the number of requests that can be made to the application