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 🙂
As we know, there is no preemption in IPsec site-to-site VPN on Cisco ASA to the primary peer. If you configure a crypto map with two peers, one as the primary, and another as the secondary, the ASA will try always to initiate the tunnel with the primary peer. If the primary peer fails and become unreachable, then the ASA will initiate the tunnel with the secondary peer. When the primary comes back online, the ASA will not do anything as long as the secondary is reachable. In other words, the primary peer will not take over the control from the secondary; instead the tunnel will remain initiated with the secondary peer. In a different scenario, that would be an issue, because maybe the secondary peer is located at the edge of a disaster recovery site where you don’t have a complete mirror of your primary site, or maybe the device has less resources, or maybe the link where it is connected is slow.
One of the security features Cisco ASA provides for new connections is to ensure the 3-Way Handshake is completed between two hosts before allowing any further tcp traffic between the two hosts. The 3-Way Handshake is simply exchanging the SYN, SYN-ACK and ACK between two hosts, each sends the relevant packets based if it acts as a sender or a receiver. If the ASA should see a SYN-ACK packet sent by a host to another before seeing the initial SYN packet, the traffic will be dropped. Similar if the ASA should see an ACK packet before seeing the previous two packets SYN and SYN-ACK exchanged between the two hosts. The ASA does this by inspecting each packet and creating a state for each connection. This a nice feature, however, in some legitimate scenarios it might create some issues and preventing the traffic from being delivered between the two hosts. Let’s see what would be an example scenario for this, and how to apply the fix.
In this post I’m going to talk about NAT exemption. As we know NAT plays a very important role in our networks today, however, with all the benefits we get from NAT’ing, sometimes we don’t need it, or more specifically we need to bypass it. A common case scenario would be for VPN traffic where we don’t want to translate the original IP addresses. In this post I’m going to show you how to exempt NAT by applying a tricky configuration on IOS without having to go through the common way of doing it.