I was working recently on a project to upgrade a distributed ISE cube comprised of two PANs and four PSNs. The upgrade was from version 2.2 to 2.4, and I was doing it through CLI which is my favorite option over the GUI. The plan was to start upgrading the secondary PAN then the PSNs and finally the new secondary PAN which originally was the primary PAN. The upgrade was progressing without any major issues on all nodes with the exception of two of them. The two nodes that gave me some issues were one of the PSNs and the secondary PAN. The PSN got stuck at step 4 while doing the upgrade, and then after a long time the upgrade process failed.
As we know Cisco ISE does not support increasing the disk space, so if we run out of disk space, then the only option we would have in theory is to re-image the ISE node allocating more disk space. I said in theory because in reality you would be able to increase ISE disk space at the Linux level.
In this post I will share with you one caveat and its fix with redirect ACL with C9300 switches. In the last few months I was working on a project for a medium size customer. The main requirements were to implement Firepower IPS, dot1x, pxGrid, AnyConnect client provisioning and posture assessment for both VPN and local clients. The customer has a few sites spread across the globe, and all of them are connected through VPLS. There are different network devices that we were working on and in one of the sites we had a stack of Cisco C9300 switches. The customer has ISE deployed for identity management.
In my previous post “FMC external authentication with RADIUS” I showed you how to configure FMC access with RADIUS. In this post instead, I will show you how to configure FTD CLI access with RADIUS, we will use ISE as our RADIUS server. The configuration is very similar to what we have done in the FMC post, and the main difference will be how to bind the FMC External Authentication Object to the FTD device.
Recently I came across a command to reset Cisco C9000 switches to factory default. The command is factory-reset and it was introduced in IOS XE 16.8.1a. This command can be handy and harmful. It can be harmful if you use it without paying attention to what option you use with it.
In this post, I am going to show you how to set up FMC external authentication with RADIUS. Why we would need that?!, simply put, to have a scalable solution in our environment that will allow us to manage accesses to our FMC appliance. Even if we configure the FMC with an external authentication server, we do still have the local admin account enabled that we can use in case the external authentication server is down.
In this post, I am going to show you how to run a packet capture on Cisco Firepower Management Center (FMC). As we know, both FTD and FMC are Linux based which means we can rely on a few tools that are embedded in Linux operating system. In fact, when you log into the FMC or when you go into Expert mode on FTD, you will see that the majority of the commands you use are simply Linux commands.
In this post I am going to show you how to configure crypto keypair without configuring host name or domain name on Cisco devices. A few network admins still have some confusion about if configuring the domain name on Cisco devices is a requirement to generate a crypto keypair or not. I believe this confusion comes from the error we get when we try to create a crypto keypair on Cisco devices before we’ve configured the domain name. The error would explicitly ask us to define the domain name first to generate the crypto keypair.
What are Snort HOME_NET and EXTERNAL_NET Variables?! Snort rules rely on variables to know what traffic they should inspect and what to ignore. Each Snort rule has a header where a bunch of variables are defined such as the action to be taken, protocol, source IP, source port, destination IP and destination port. The most important two bits among these variables are the source and destination IP addresses. These two variables define what should be protected and what should not. In Snort language these two variables are called HOME_NET and EXTERNAL_NET. HOME_NET should include all the IP addresses that Firepower should protect which means all our IP addresses whether private or public, but what about the EXTERNAL_NET?! should it be anything else except our protected IP addresses defined in our HOME_NET?! or should it be anything including our HOME_NET?! let’s find out together :).
One of the limitations with Firepower Device Management (FDM) is that it does not allow creating multiple admin accounts for FDM GUI accesses. This means that all the admins will use the same admin account to log into the FTD, which leads to sharing the admin credentials between them. As security chaps we don’t like this, at least when possible. For CLI it is a bit different since we would be able to create multiple accounts, however, those accounts will only be valid for CLI accesses, not for GUI with the exception of the default admin account. The default admin account can interact with both CLI and GUI.
Now if we have the right tools in our environment that would allow us to workaround this limitation why not using them?!. To do so we need to rely on an external authentication (authC) and authorization (authZ) server and also on our AD to check against the interested AD group where the admin users would be located. The end result would be to have a centralized accesses through the external server for both SSH and HTTPS only if a user exists in a specific AD group. We will also create a read only HTTPS access in our lab. ISE is going to be our external RADIUS server which is already joined to a domain controller. let’s get started 🙂