Recently I was a delegate of Security Field Day 7, where Keeper Security presented its solution. And as a security-minded guy, I have been using password managers for a long time, but I am also careful about using cloud-based password managers cause well, you store your passwords and other important secrets in that manager. What if there is a breach like recently happened to Okta and Microsoft? It means you have to be very quick to change all your passwords at all the different sites. Thus one of the big questions for me during their presentation was on storing my secret stuff on their storage (well, actually AWS via their services).
In a previous post I have already shared some information about the Airwall solution from Tempered Networks. In this blog, I will share my experiences in configuring and operating the Airwall solution. I have been running an Airwall setup to test for a number of months.
Before moving into the configuration aspect, let’s first describe the components of the Airwall solution.
The conductor is the “heart” of the Airwall solution. It is the SDN controller (running on-prem or in a cloud) with which you manage all Airwall components and configure the different policies.
The airwall agent is a software component that is running on your user endpoint devices, such as your smartphone, tablet, laptop or desktop. It is effectively the client that connects to gateways and Airwall Server agents.
Airwall Server agent
The Airwall Server agent is the software component that you can install on individual servers. You might say that it is comparable with the Airwall agent, except it runs faceless and is optimized for running on your servers. I have been running one on a virtual server I have hosted in the cloud.
The airwall gateway is a special component within the solution. You can use it to secure networks behind a gateway with agents. E.g., if you allow a connection from an agent to a gateway, you are able to securely connect from the agent through the gateway to multiple hosts or networks behind the gateway. The gateway comes in different flavors, a virtual machine, a cloud instance, a physical gateway for wired connections, and a phyisical gateway that connects to the unsecure networks via WiFi. The gateway is also capable of acting as a relay agent between agents that cannot communicate directly with each other, but only if you have specified and allow that communication in the conductor.
Overlay networks within Airwall are a bit different compared to the traditional overlay networks seen with VPN solutions, which is also what makes Airwall unique in its approach. An overlay network is basically a secured IP network that can be configured between agents, servers, and gateways. And the unique twist is that you can manage completely different overlay networks and configure a policy that a single agent can communicate via these different overlay networks.
My personal experience is that I initially misinterpreted overlay networks and thought of it as a single network with unique policies; it is easier to see each overlay network as a security policy that defines who can securely communicate with who at which moment in time.
The underlay networks is your regular network, or the Internet. It is the insecure network via which you connect the different Airwall components. The conductor of course needs to be reachable via the underlay network.
The team at Tempered networks was kind enough to provide me with a complete set of components to test with and try out use cases. My kit consisted of agents for my iOS devices, my laptops, 1 virtual gateway (Cloud), 2 physical gateways (one wired, one wireless), a server agent and a conductor.
Getting started with the conductor is pretty much straight forward, after running through the provisioning guide, you have the link to the conductor portal, which provides a good overview of your environment. The tab labels itself speak for itself. Now that the conductor is setup correctly, it is time to download and provision agents.
For the physical gateway, it was effectively the same setup. Hook a serial console to the device, configure the hostname and port for the conductor, activate the device and you can define your policies.
I used the provided download links to download an agent to my Mac and used the App-Store to download the iOS apps. Once they are downloaded, you provide the agent with a profile that contains the hostname and port to your conductor. It took me a while to figure out that I had to manually approve the license before further configuration was possible. So after you’ve configured your agent, go back to the conductor and hit the settings -> Licensing tab. Activate the just registered device and a license will be consumed. With that action, the airwall agent/gateway becomes active.
Remember, the gateway has different behavior compared to the agent with more functionality. Make sure that the communication ports you defined in the Conductor are available via the underlay networks. It took me a while to figure that out (I assumed too much routing in my mind), and once I had the PAT configured correctly, the gateway was working as expected and the agent on my mac could communicate with it. If you use NAT, you can configure the external IP address for the gateway via the conductor (auto-detect and auto-set would be great when you have dynamic outbound IP-addresses and relay on PAT). The screen shot below shows the setting for my gateway.
In my next post, I will give you a sample underlay network that I have been using very succesfull (including demos and firepower trainings) over the past months.
“Personal Note: Ok, this post has been lying around in my draft for quite some time. Sorry for that Tom, Ben, and Tempered. Too many reasons but one of them is also that the folks at Tempered were so kind to allow me a trial for a few months. I will share my experiences in a few posts to come. “
I don’t know if the organizers of Security Field Day 3 did this on purpose, but it looks like they kept a very innovative solution as encore with Tempered Networks. Their presentation was the last one in the line-up and presentations. And since I hadn’t heard about their company name, I looked them up in advance and was intrigued in how they could twist the tale on security without visibility. Todays common sensus in security is that you need to see and know what is happening on your network; Tempered says: what you cannot see, you cannot hack.
Personally I think their solution originated from the IoT/OT network environment where applying security to IoT devices is well, near impossible. The S of security is lacking in IoT for a reason. I can assure you, also from my own environment, that many IoT/OT devices do not follow RFC’s completely, let alone implement IEEE standards like Port-Based Network Access Control (IEEE 802.1X). Their paradigm is that if you place one or more sensors of such an OT network behind a device that basically hides / blinds them from the rest of the IT network, and create an overlay to wherever you have servers they need to connect to, again protected by either a hardware device or software, the communication between the two endpoints is both secure and hidden. Those ports, with often unencrypted traffic, are just not available to the generic IT network and thus less prone to intrusion events.
Their solution consists of Airwall agents that run on almost any client OS (ok, ChromeOS is a different story for any client) , hardware solutions (called gateways with also added functionality), Airwall Server agents that you can run on server OS like Linux, and a conductor from which you manage the clients and settings. Secure tunnels are created between two airwalls if traffic is allowed and defined in the conductor. That is quite similar to SD-WAN solutions or VPN solutions, isn’t it?
However, there is a big but in here too. Airwall gateways can also act / be configured as relay client. In other words, if two airwall clients (for example an agent and server) cannot contact each other directly (NAT, twice-NAT or port-blocking), and both airwall clients can connect to a third client, that third client will act as a relay point for the traffic between the two clients, it is like a smart SD-WAN Hub/Spoke and Mesh network combined! And I can share something with you, it really works.
The screenshot below shows a group I created to allow access to a virtual server with a relay VM that allows traffic between my mobile clients and that server.
In summary, I think that Airwall is one of the first true SASE clients out there, enabling end user devices (close to anyone) connectivity to any cloud, virtual server, or datacenter with some clicks inside the Conductor. I will be honest, the folks at Tempered have shared an evaluation license so that I can test out their software and solution for a few months. I have been testing it out over the past months and will share some use cases and setup experiences in a few upcoming posts.
Most of us probably have asked Siri, Alexa, Google some questions and answers over the past years; Smart assistants are one of those new interactions. And honestly, not that many questions you asked were probably related to networks, were they? And yet, after hearing Juniper present at Security Field Day 3, these type of questions might in the near future become a normal way to allow you to interact with the network. Sounds like something from Star Trek, and is just science fiction? I beg to differ for a number of reasons.
Before I dive into Juniper’s security strategy, let’s first review the current state of Artificial Intelligence (AI) and Machine Learning (ML) as a concept. To do that, I will explain what happens when you ask Siri to do something or a question like what is the date?.
First of all, after you’ve asked the question, that audio bit (which is just a record of frequencies) is guessed into a sentence. It is a form of translation, where Machine Learning is used to do well-calculated guesses in what kind of word you tried to pronounce. And I can tell you that if English is not your native tongue, some weird word-guesses come out.
Once there is a digital sentence, another process is used to narrow down your digital sentence into a single pattern-matched result. This allows you to say things like “create a meeting on date X, Y or z”.
The model uses the pattern “create a meeting” for the match and the other values are stored in variables.
After a pattern has been matched, the code corresponding to that pattern is executed. The result of that code will be a string/sentence. That sentence is then being translated to audio using Text-To-Speech and read out loud to you.
This is a perfect flow for a single sentence / command /question. But many of these smart assistents start to show real issues once you start to create related questions, like you can do with a toddler. And that is because the flow I described above does not have that much space for relaying context between flows. So most models in these smart assistents are built / designed for a single task, and if you put them in sequence, it appears as if the assistent is “smart”. But it is not (yet).
Yes, developments go fast, and I heard last year in San Jose a great story of self-learning models and also the core faults that are inside these models because of the way the models are designed and built. But that is a completely other discussion.
But if AI/ML is not that far ahead yet, how would you then be able to ask Juniper about the security state of the network? That how is one of the things Juniper told at Security Field Day 3.
They leverage the power of AI/ML (and that is to have more answers than just a yes or now) in their security solutions for only a predefined, supervised, set of options. Juniper uses models (they call them supervised models) to analyse metadata about the flows in your network to detect malware and other anomalies in your network, just like other network and security vendors have done. Juniper has adopted AI/ML on detecting anomalies or other weird behaviour on your network. And that can help you a lot in gaining more visibility and control in your network.
Because with everything connected to the network, increased security by leveraging encryption, more data in the cloud, we as a human are reaching our limits in finding anomalies or odd behaviors by hand. A simple computer, using a properly tuned model, can find those anomalies much faster. And because that model does that, you can focus on determining whether that anomaly is really an anomaly of yet another new application on the network.
And if you would trust those reports blindly, you can of course automate actions, but personally I am always careful with those. Suppose it is the CEO’s smartphone, you might want to call the CEO first before you throw him off the network.
Personally I do believe firmly in that AI/ML can help you in your daily job in finding those odd behaviors that without them you’d never be able to spot and help you in providing a better, smoother, more stable and secure network. But you do need to keep in mind that it is still a computer that presents you information from a lot of data and that presentation will be biased.
But definitely a good thing that Juniper has started to embrace that principle across their portfolio.
That can bring them quite a bit.
And to be able to ask Juniper about the security state of the network? That would be not that hard to implement, because JunOS has API’s from the start. Just build an application and integrate it with existing API’s for smart assistents. If you want to see a demo, just watch this video taken from a presentation where I asked Siri how many clients were connected to the network.
This is just a quick blog post for those that might have FDM issues after upgrading your FTD software.
I have recently updated my Firepower appliance from 6.5.0 to 126.96.36.199. One of the reasons to update is not only that 6.5.0 is a .0 release, but also that I noticed some failed rule-update deployments that set snort to block all traffic.
Unfortunately, after upgrading, FDM reported an error that it could not be launched with an application failure error. The suggested action was to remove the manager, add a new local manager and begin from scratch. This is the error: “The Firepower Device Manager application cannot be opened. Please try again”
While googling for a possible caveat of this behavior on 188.8.131.52, I came across a caveat in 6.2.3 that has the same behavior.
That caveat has supported me in fixing my solution. What I did was executing the following commands:
> expert ************************************************************** NOTICE - Shell access will be deprecated in future releases and will be replaced with a separate expert mode CLI. ************************************************************** admin@na-grm-ftd01:~$ sudo su - Password: root@my-ftd01:httpd# cd /ngfw/var/cisco/ngfwWebUi/ root@my-ftd01:ngfwWebUi# ls -a . .bootstrap-failed clifile deploy ha_pkg lina_cli_sqlite_stores pjb_output sslCiphers variables.ftd_onbox .. bin clisyncer ftd_onbox_184.108.40.206_previous libs ngfw_onbox_bootstrap.sh sru tomcat version root@my-ftd01:ngfwWebUi# rm .bootstrap-failed root@my-ftd01:pmtool disablebyid tomcat root@my-ftd01:pmtool enablebyid tomcat
Basically, you go into expert mode, find the tomcat directory used for FDM and then remove a status file and try to restart it.
With me, this worked and helped me get back access to FDM. Should you run into issues with FDM after an upgrade, this “hack” might help you.
Disclaimer: You are entering expert mode of FTD, it means you can DESTROY your FTD configuration and box. Be aware of what you are doing and make sure you have a backup.