Junos 20.1r1 was released recently, and with it came a rather exciting feature – the ability to configure IPFIX flow export on the SRX Branch series! This update also includes the ability to support flow record exports in chassis clusters as well. This is a great feature to support traffic analysis through a myriad of tools, and even support basic Denial of Service Attack detection. With the addition of IPFIX we can also generate flow data for IPv6 traffic which previously was not supported on the SRX. Without further ado, let’s configure IPFIX!
I wrote a script a few years ago that would check to see if address entries existed in the more than one address-set. It works well, but it was missing one key component – what happens if an address-set entry contains another address-set?
I’ve since updated the script with a little bit of logic to include tracking this very scenario, and I’ll explain the changes below. The script is still available on GitHub if you want to download a copy and use it for your operations!
It required the use of ephemeral IP address, which can be a waste of IP space
It only worked if there was one destination network, as Next-Hop Tunnel Bindings (NHTBs) did not address which source network traffic came from
Traffic selectors were introduced as feature starting in Junos 12.1X46-D10 (SRX200, SRX1400, and SRX3k series) and Junos 17.3R1 (SRX300, SRX1500, SRX4k, and SRX5k series) for IKEv1. IKEv2 support was added in Junos 15.1X49-D100, meaning this is only available for the SRX300, SRX1500, SRX4k, and SRX5k series.
One of the things I like to standardize in firewall configs is addresses and address-sets. I always recommend creating address-sets and binding address entries into the address-set. From there, we could reference the address-set inside the security policy configuration. This makes it easier to automate changes as we no longer have to hunt inside the security policies to add or remove entries.
Recently I had a situation where I needed to parse through several thousand lines of configuration in a SRX Firewall to determine if address book entries were bound to more than one address-set. In many environments it is very likely that an address book entry is bound to more than one address-set. When that happens there are often unintended consequences that affect traffic flow through the firewall. A host may fall victim to a blocking policy; or worse yet allow more permissive access to sensitive systems!
Since I needed a quick way to do this repeatedly I wrote a simple script in python to parse through a SRX configuration. Read on to see the script!
I was hoping that title would catch your attention.
First and foremost this is a technical blog to discuss neat tricks and tips that I use daily, but sometime it’s a good idea to jump off the path and take a look at what is going on in the tech world. It is high time we start looking past traditional security firewalls or Next-Generation Firewalls and see where the path takes us.
For starters, I was recently at the Juniper Ambassador’s Conference and got to speak with the brilliant minds at Juniper Networks. I am quite sure everyone has heard about the significant changes that has been occurring at Juniper, and like many of you I had my concerns/reservations. While it is important to note is that there are still plenty of opportunities to improve the realm of Junos security in the short term I am excited for what is to come.
I feel that there is always going to be a need for traditional hardware firewalls in the network. Certain features make it extremely tough to remove hardware appliances completely; in particular I am talking about the edge firewalls that handle massive amounts of IPSEC tunnels or NATing public/private IP’s. In the future it would not be a long shot to put security functions in other parts of the network. As an example by moving firewall functions to the hypervisor then we can reduce the need of massive firewalls at the head end.
Let’s look at this idea for a moment. Consider the following traditional network:
Typically you would have your network segments trunked to an interface on a firewall, or a unique interface per vlan directly connected to the firewall. This works great until you run out of interfaces, bandwidth, or processing power of the firewall – especially for that pesky intra-zone traffic!
Now consider adding security features to the hypervisor, such as a virtual firewall that connects its external interface to a flat vlan, and its internal interface to a specific vlan on the virtual switch. A diagram of such an idea is shown below:
By offloading basic firewall or even IPS features to the hypervisor (which has far more compute power than that of a single hardware firewall) we can now free up the firewall to do more important tasks, and increase our scalability significantly! Combining this solution with some of the cool tools like Firefly Packer to help with automating these deployments you can have a significantly faster turnaround time for the needs of your network. This type of design also helps with reducing the failure domain of the network – if an issue crops up one of the hypervisor firewalls it only affects one group of devices, instead of causing an entire network outage. Smaller failure domains = higher overall stability.
Now certainly there are still a bunch of unanswered questions about designs like these, but this is the start of a significant change in how we all can view security and its application to the network. Sometimes it helps to take a step back from what features are missing in a device, and instead look at the opportunities that exist today and in the future.
Clay Haynes 