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.

Continue reading “FTD CLI ACCESS WITH RADIUS”

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.

Continue reading “PACKET CAPTURE IN FMC”

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 🙂