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 this blog post I would like to share the configuration I have been trying out with Airwall from Tempered Networks over the past months. Airwall is a new approach to security leveraging the HIP protocol defined in RFC7401.
The following topology describes how I have included the Airwall gateway in my home network.
In this setup, I created a seperate VLAN for the untrusted VLAN that is effectively a subinterface on my FTD device. It allows traffic to the outside only. I have configured PAT to allow the necessary inbound Airwall communication ports.
The trusted port of the Airwall gateway is directly connected to the client VLAN in my network. Why? I wanted to test out bonjour and L2 extension / forwarding too.
Secure remote access
Probably one of the most visible use cases for Airwall is allowing secure access as if it was a VPN/SASE client allowing your users connecting securely to inside resources. And that is definitely possible with Airwall. You can leverage the gateway function to effectively connect secure (inside) hosts and networks via the secure ports.
For this use case, I want to securely allow access from my laptop to several management IP’s in my internal network, being:
- Firepower Management Center (FMC)
- C9800 Wireless Controller
- My Raspberry PI with Domoticz to see real-time power consumption
- My laser printer
- My distribution switch (SSH)
As the gateway has its secure port to my clients VLAN, I just need to define these devices (and yes, IP scanning is possible) as local devices and add static routing for my network management. All this is configured for the specific Airwall via the Conductor (Airwalls -> Select the right Airwall).
Add local devices to an Airwall gateway
Configure Overlay IP routing via the gateway.
I had some connectivity issues when I had my Mac conencted to the same VLAN and was not able to connect to my FMC. This is solvable by either setting a different overlay IP address on my Airwall Agents or configure PAT on the gateway. I’ve chosen the first option, and it has worked quite well.
Now that the Airwall components have the right (local) connectivity, it is time to configure a security policy for secure access. Within Airwalls paradigm, these security policies are overlay networks. And they work very easy. Within the conductor the tab “Overlays” is where you’ll configure all overlay networks. I have created a hub-spoke overlay network with my own devices (which I grouped) as hub. Why would I do that? It means that all the other devices are spokes and I can automatically communicate with them, once I add them.
Adding/Removing devices is like really easy. Just hit the plus and add any device you have defined in the Conductor, and that’s it.
Once I add a device in the overlay, it can communicate with the hub. And when I am outside, or even when I’m at home, I am actually connecting to these devices via the Airwall secure network, as can be seen via the below traceroute.
In summary, I have been very satisfied with the way Airwall is working. This common use case is really easy to configure and manage. And as long as the underlay ports can communicate, it is fast and reliable. But you can do more with Airwall. One of the things from Security Field Day that got me triggered was the full programmability, which I will describe in another post.
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.
The Cisco FirePower 1010 appliance (FP1010,
Time to get started with the upgrade. In this blog
- Laptop with FTP/SCP/SFTP server (TFTP is possible, I had issues with USB); I used my MacBookPro for this
- Laptop connected to the management interface of the FP1010
The upgrade image, in my case: cisco-
Once you have everything ready, the following steps can be used to upgrade the FP1010 appliance:
Firepower appliances are really a different platform to the trusty old ASA platform. One of the architectural differences is that the appliance is running FXOS as the operating system and the security services you want to run (FTD or ASA) are installed as an instance. I think the best to compare it with is VMWare and running virtual services. FXOS looks a lot in its command set to the NFVIS operating system that runs on the ENCS series. It is based on the UCS platform and uses quite a different CLI then you are familiar with in the ASA world.
The larger appliances (FP4100 and FP9300) FXOS and the security instances are separated, which means that you first configure FXOS and then you can load the security instance on it. The smaller Firepower appliances, such as the FP2100, FP1100 and the FP1000 series have FXOS and the security instance bundled in a single release. This means that you always run a specific FXOS system with a specific ASA or FTD version.
1. Connect the console of the FP1010 to the laptop and power on the appliance
2. Connect a network cable from the mgmt interface to your laptop
4. Type the command “connect ftd” and run through the initial setup wizard. If you do not accept the EULA and run through the setup, somehow the network is not working as expected and you cannot download the software. And yes, that took me some hours to figure out…
You must accept the EULA to continue.Press <ENTER> to display the EULA: End User License Agreement Effective: May 22, 2017 *** SNIP*** Please enter 'YES' or press
to AGREE to the EULA: YES System initialization in progress. Please stand by. You must change the password for 'admin' to continue. Enter new password: Confirm new password: You must configure the network to continue. You must configure at least one of IPv4 or IPv6. Do you want to configure IPv4? (y/n) [y]: y Do you want to configure IPv6? (y/n) [n]: n Configure IPv4 via DHCP or manually? (dhcp/manual) [manual]: Enter an IPv4 address for the management interface [192.168.45.45]: Enter an IPv4 netmask for the management interface [255.255.255.0]: Enter the IPv4 default gateway for the management interface [data-interfaces]: Enter a fully qualified hostname for this system [firepower]: Enter a comma-separated list of DNS servers or 'none' [188.8.131.52,184.108.40.206]: Enter a comma-separated list of search domains or 'none' : If your networking information has changed, you will need to reconnect. Setting DNS servers: 220.127.116.11 18.104.22.168 No domain name specified to configure. Setting hostname as firepower DHCP server is enabled with pool: 192.168.45.46-192.168.45.254. You may disable with configure network ipv4 dhcp-server-disable Setting static IPv4: 192.168.45.45 netmask: 255.255.255.0 gateway: data on management0 Updating routing tables, please wait... All configurations applied to the system. Took 3 Seconds. Saving a copy of running network configuration to local disk. For HTTP Proxy configuration, run 'configure network http-proxy' Manage the device locally? (yes/no) [yes]: yes Configuring firewall mode to routed Update policy deployment information - add device configuration Successfully performed firstboot initial configuration steps for Firepower Device Manager for Firepower Threat Defense.
5. After the setup, the console will have a very empty prompt: “>” Now type exit The prompt will now look like firepower#
Enter the command scope
download image sftp://userid@iplaptop/path/to-image/cisco-ftd-fp1k.6.5.0-115.SPA
I have used
download image sftp://firstname.lastname@example.org/Users/myuserid/Downloads/cisco-ftd-fp1k.6.5.0-115.SPA
The console will now prompt for your password and then it will initiate a download task:
firepower /firmware # download image scp://email@example.com:/Users/myuserid/Downloads/cisco-ftd-fp1k.6.5.0-115.SPA Password: Please use the command 'show download-task' or 'show download-task detail' to check download progress.
You can use the “show download-task detail” to show the details, which has
File Name: cisco-ftd-fp1k.6.5.0-115.SPA
Downloaded Image Size (KB): 59264
Time stamp: 2019-10-07T06:48:09.268
Status: Downloading the image
Transfer Rate (KB/s): 29632.000000
Current Task: downloading image cisco-ftd-fp1k.6.5.0-115.SPA from 192.168.45
However, if there is a failure, it will only show “failed“. I found out that the command
show event provides much more information, but requires a bit decoding. The following output is from a successful download:
Creation Time ID Code Description ------------------------ -------- -------- ----------- 2019-10-07T06:48:09.269 27339 E4195702 [FSM:STAGE:END]: (FSM-STAGE:sam:dme:F irmwareDownloaderDownload:begin) 2019-10-07T06:48:09.269 27340 E4195703 [FSM:STAGE:END]: checking pending man agement network config(FSM-STAGE:sam:dme:FirmwareDownloaderDownload:CheckPending NetworkConfig) 2019-10-07T06:48:09.269 27341 E4195704 [FSM:STAGE:ASYNC]: downloading image cisco-ftd-fp1k.6.5.0-115.SPA from 192.168.45.46(FSM-STAGE:sam:dme:FirmwareDownlo aderDownload:Local)
2019-10-07T06:47:40.120 27329 E4195706 [FSM:STAGE:REMOTE-ERROR]: Result: end -point-failed Code: ERR-DNLD-no-file Message: No such file#(sam:dme:FirmwareDown loaderDownload:DeleteLocal)
It tells you it couldn’t find the file. The show event is quite handy.
Once the download is completed, the show detail command would look like this:
Download task: File Name: cisco-ftd-fp1k.6.5.0-115.SPA Protocol: Sftp Server: 192.168.45.46 Port: 0 Userid: nefkensp Path: /Users/nefkensp/Downloads Downloaded Image Size (KB): 1031174 Time stamp: 2019-10-07T06:48:09.268 State: Downloading Status: validating and unpacking the image Transfer Rate (KB/s): 32224.187500 Current Task: unpacking image cisco-ftd-fp1k.6.5.0-115.SPA on primary(FSM-ST
8. Now that the software is downloaded, it is time to validate if the package is available. Use the command show package to check for that:
firepower /firmware # show package
firepower /firmware # scope auto-install firepower /firmware/auto-install #
10. and install the package via the install security-pack version command:
firepower /firmware/auto-install # install security-pack version 6.5.0-115 The system is currently installed with security software package 6.4.0-102, which has: - The platform version: 22.214.171.124 - The CSP (ftd) version: 126.96.36.199 If you proceed with the upgrade 6.5.0-115, it will do the following: - upgrade to the new platform version 188.8.131.52 During the upgrade, the system will be reboot Do you want to proceed ? (yes/no):yes This operation upgrades firmware and software on Security Platform Components Here is the checklist of things that are recommended before starting Auto-Install (1) Review current critical/major faults (2) Initiate a configuration backup Do you want to proceed? (yes/no):yes Triggered the install of software package version 6.5.0-115 Install started. This will take several minutes. For monitoring the upgrade progress, please enter 'show' or 'show detail' command.
11. Now let’s wait for the upgrade or use the “show” command to check the status:
firepower /firmware/auto-install # show Firmware Auto-Install: Package-Vers Oper State Upgrade State ------------ ---------------------------- ------------- 6.5.0-115 Scheduled Ready firepower /firmware/auto-install #
12. And after waiting for some 20-30 minutes, FTD has been upgraded. Congratulations!