PoC: Use RPKI invalid route information as seed to dynamically modify the policies of remote firewalls...all of these is O-P-E-N S-O-U-R-C-E!!!
Hello friends,
first of all, as always, a musical recommendation .... in this case Elton John - I'm Still Standing, COME ON!!!, don't give up.
I'm going to take a break from proofs of concept with Wazuh...who has stolen my heart. In this case I'll describe a PoC I had to do. I think it's a interesting work in my opinion, but of course I'm not impartial, it's like when I look in the mirror...I see Brad Pitt...ha,ha,ha.
In a previous post, working-monitoring-some-aspects-rpki-lab-full, I described some aspects of RPKI, including RPKI deployment and monitoring, as well as the application of security policies such as blackholing and RPF. If you feel like taking a look at it.
As a reminder, the network under study is composed of 3 data centers, with multiple tenants or vrfs or L3VPNs (let me use this analogy tenants/vrfs/L3VPNs, please forgive me), interconnected through an SRv6 network. Why SRv6 as an underlay network?...because it is very easy to do it, because you only need IPv6 connectivity on the ISP side...
That solution is good and we protect the company by avoiding access to hijacked BGP prefixes when a central internet access is used:
But, what happens if the company also have other internet access(es) different from the main site where RPKI has been deployed?*, I mean isolated wifi internet access(es), “developer hub” internet access(es), public cloud access(es), etc... although these resources are restricted they are not free from the consequences of address hijacking. *Obviously maybe it is not the best design, but ...there are always restrictions, limitations, etc…
As indicated above, if the necessary routing information is available, it is possible to filter traffic to and from networks on the Internet with invalid RPKI status through a correct application of ROV-based routing, blackholing and uRPF RFC3704 techniques. The issue is that this information is not always available at the necessary “points”, usually perimeter rtr/firewalls in remote locations or for specific services. The objective of this PoC is the development of a solution that allows automating access policies based on RPKI status of source or destination.
The basic idea is to collect routes with invalid RPKI status from an RPKI-enabled router, and use that information to dynamically modify perimeter firewall rules as needed.
Firewalls and code
In order to make the solution as open and accessible as possible, nftables has been considered as a packet filtering tool in the network design. Nftables can be deployed on any linux system offering stateful firewall service and high performance packet filtering capabilities. All applications and plugins developed will be done with Python as programming language.
Of course the solution is perfectly valid with any firewall that offers the ability to modify security policies dynamically, such as Palo Alto, Cisco, etc ... in this post, Dropping traffic to invalid RPKI destinations, that I wrote some time ago I explain how to do it with a Palo Alto firewall.
Firewalls: Nftables
The application of filtering policies is mainly performed on the ingress hook (netdev). The ingress hook is the earliest stage in packet processing and offers the best performance, even doubling the performance of the prerouting hook.
It must be taken into account that firewalls may have different and extensive configurations, so policy automation must be carried out in such a way that it only applies where it is necessary. For this purpose, specific sets have been defined in each firewall to include the networks whose RPKI is invalid. These sets are used in the filtering rules of the ingress hook.
Traffic to or from any network included in a firewall's RPKI filtering set will be discarded.
The following example shows the sets for each address family (IPv4 and IPv6) applied in the ingress rules of the LocalSrv zone of the c_firewall02 firewall:
The policy automation process is responsible for retrieving all routes with invalid RPKI status, composing the necessary code and updating each set of each firewall.
Code: Process description
As I said, the firewall policy automation developed in this work aims to apply access protection measures to and from Internet networks with invalid RPKI status in all Internet accesses, and/or in those locations where there is no e/iBGP peering and/or routing filtering capability. The solution contemplates the possibility of applying the policies to all or part of the perimeter firewalls, in addition to the possibility of complete deletion of the RPKI-derived policies by address family if necessary, the rollback.
The developed application is executed from a central site, from a management system node, and it’s divided into 7 stages:
Stage 1:
Stage 2:
Stage 3:
Stage 4:
领英推荐
Stage 5:
Stage 6:
The following image identifies each of the stages:
The following shows how the total number of invalid routes in BR1001 (Master) is aggregated by each address family, compiled and sent to the kernel of each firewall:
IPv4: RPKI Invalid
IPv6: RPKI Invalid
Python code view
I won't show all the code because I'm like a pimply teenager, I don't look pretty enough yet...
Manage and monitor the service
I have integrated the described policy automation into the monitoring system, which allows for unattended execution, and/or even event-driven execution, such as changing the list of invalid RPKI routes. In this case I use nagios but it can be another one. If we configure correctly the application the monitoring systems will be able to interpret the outputs and therefore alert in case of execution failures or to the alarms that we define in our plugin (application), but this is material for another post. Here is the solution integrated in the management system:
Managed rollback
It is also important to have a mechanism that allows us to disable the deployed policies if necessary.
The management system includes manual execution scripts that allow us to disable the RPKI policies deployed in the firewalls by address family:
Checking the status of RPKI policies in firewalls
It is very important to monitor whether the automated deployment of policies has been carried out correctly, either by updating the policies or resetting them. Given that it is possible for both actions to be executed, we must provide a mechanism that allows us to know the status of a firewall with respect to the policies at any time, i.e., to know whether the RPKI policies are applied or not. Therefore, I have also included the development of a new script that will verify if the sets associated to the RPKI policies include objects or not and in what number.
Conclusion
Using RPKI information at remote sites to monitor or act on traffic helps us to improve security in our network. It is clear that RPKI is not the definitive solution to solve BGP hijacks but there is no doubt that it helps to eliminate or mitigate the consequences of many of them.
If you are close to networking or security...please get closer to programming.
If you deploy something ...remember, monitor it!.
Documentation
CCIEx2 #56439 - Aquitectura y Digitalización
2 年Sorry, I had some editing problems with the article (formats, spaces, etc...), linkedin editing tools are limited, it should be accessible again.