Cisco FTD design and deployment implementation involves setting up firewall, SSL inspection, NAT, IPS and active/standby HA. Deployment model determines placement of FirePower into the network as Firewall/IPS device or as an IPS only device. In Firewall/IPS mode you have the option to choose between routed and transparent mode and in IPS only devices you can choose between inline and passive mode.

In today’s blog we will cover in detail about FTD deployment modes, differences between each of the modes, and use cases.

Cisco FTD Deployment 

Cisco FTD interface could be deployed in

• Regular firewall mode and
• IPS only mode

We can include both firewall and IPS only interfaces on the same device. 

FTD Deployment Modes: Regular Firewall Mode

Regular firewall mode interface subject traffic to firewall functions such as maintain flows, track flow states at IP and TCP layer, IP defragmentation, TCP normalization. IPS functions can be configured optionally for traffic according to security policy. The type of firewall interfaces one can configure based on firewall mode set for the device: routed or transparent mode. 

FTD Routed Mode Deployment

Routed mode interfaces routed firewall mode only, each interface that you want to route between is on a different subnet.

FTD Transparent Mode Deployment 

In transparent mode the firewall is configured as a switch and no IP address is assigned to any interface except to the firewall itself.

Limitations of FTD transparent mode (Firewalls)

• No unicast/ multicast routing
• No DHCP relay
• No VPN termination
• LAN cannot be used as an enterprise gateway

However, NAT feature can be enabled in transparent mode 

To configure a transparent firewall, we have to configure the bridge group and add interfaces to that bridge group.  In transparent mode each bridge group is separate and not communicate with each other. FirePower threat defence (FTD) system use bridging technique to pass traffic between interfaces. Each bridge group includes Bridge virtual interface (BVI) to which IP address is assigned on network. In routed mode FTD routes between BVI and regular routed interfaces. 

Access rules in transparent firewall mode 

• ARP is allowed by default and can be controlled with ARP inspection
• IPv6 neighbour discovery is not allowed by default
• Multicast and broadcast (RIP/OSPF/EIGRP) traffic not allowed by default
• STP BPDU is allowed by default to prevent loop 

FTD Deployment Modes: IPS Only Mode

IPS only mode can be deployed in three ways. Let us understand each one of them more in detail. 

Inline Mode

Inline Mode (without tap) – When it comes to inline mode, only two interfaces can be connected for each pair. Whatever is received on either of the interfaces will be checked and then transmitted to the other interface without any MAC switching or IP routing. It functions similarly to a wire with an inspection module in the middle.

When compared to transparent mode, inline mode has a different function as multiple interfaces may be incorporated into each bridge group, making each bridge group behave like a separate switch.

Inline with Tap Mode

In tap mode however, traffic itself is not inspected but its copy is inspected. So, it is not possible to drop intrusions in this mode but only alerts can be received. FTD will make a copy of each packet so it can analyse it. This is ideal where you want to fine tune your intrusion policy and add drop rules which best protect your network without hampering its efficiency. Once you are ready to deploy FTD online you can disable tap mode. 

Passive Mode

In this mode FTD will not sit physically inserted into the path. Copy of traffic will be sent to IPS with the help of SPAN/RSPAN/ERSPAN technology.

Passive Span Mode

Passive interface monitors traffic flow across the network using a switch SPAN or mirror port. The SPAN or mirror port allows for traffic to be copied from other ports on switch. FTD cannot take actions such as blocking or shaping traffic in passive mode.

Passive ERSPAN Mode

Encapsulated remote switched port analyzer (ERSPAN) interfaces allow monitoring traffic from source ports and uses GRE to encapsulate traffic. In routed firewall mode only ERSPAN interfaces are allowed. 

Continue Reading:

Palo Alto Interface Types & Deployment Modes Explained

Understanding Checkpoint 3-Tier Architecture: Components & Deployment

Today we look more in detail about their features, use cases and comparison Cisco ASA vs Cisco FTD, i.e. how they are different from each other. 

What is  Cisco ASA? 

Cisco ASA is a network security appliance which gives firewall, VPN, and Intrusion prevention functionality. It has extra layers of security feature by application of advanced threat protection and behaviour analysis. It can detect threats in real time and block them before they cause damage to the network. Well suite for small and large enterprises as well as wired and wireless networks both. It has high throughput and low latency. 

Cisco ASA firewalls were designed to prevent all external traffic from entering into the network. ASA allows stateful inspection by saving session information so that when a valid response comes back, it can recognize and permit traffic. In addition, they provide network address translation or port address translation for network protection. 

Features of Cisco ASA

• Cisco ASA provides stateful tracking of packet if it is generated from higher security level to low security level
• It can perform static routing, default routing and dynamic routing using EIGRP, OSPF and RIP protocols
• It can operate in routed mode where it acts like a layer 3 device and need to have 2 different IP addresses on its interface and in transparent mode where it operates at layer 2 and need only single IP address
• It supports AAA services using local database or using an external server like ACS 
• VPN support is also given by Cisco ASA firewall like Point to Point, IPSec VPN and SSL based VPNs
• It new version supports IPv6 protocol routing (Static and dynamic)
• It provides high availability for pair of ASA firewalls 
• Advanced Malware protection 
• Modular policy framework supports policy definitions at traffic flow levels 

Use cases of Cisco ASA

• VPN logging
• Startup and running configuration change
• TCP port scanning
• Permitted / denied blacklisted source management 
• Permitted/ denied blacklisted destination management 

What is Cisco FTD?

Cisco FTD is a high end firewall appliance which is used to protect networks from intrusion attacks. It offers an extra layer of security to data centers and enterprises. Cisco FTD enables service level agreements (SLAs) to support real time in service monitoring, analysis and control of the network for optimization of performance on mobile applications. 

Features of Cisco FTD

• Continuous visibility across attack landscape 
• Maintains data integrity and confidentiality of enterprise network with out of band segmentation
• Includes advanced threat prevention from malware, ransomware, phishing attacks, and other exploits. 
• Architecture to support multi-tenant deployments
• Network protection from insider attack using Cisco Identity services engine (ISE). 

Use cases of Cisco FTD

• Logging security events
• Intrusion detection and prevention 
• URL filtering
• Malware protection 

Comparison: Cisco ASA and Cisco FTD

Below table summarizes the differences between the two types of Network Security Appliances:

Download the comparison table: Cisco ASA vs Cisco FTD

Final Words

The primary dissimilarity between Cisco FTD and ASA is that while ASA allows users to access VPN, IDS, IPS, anti-malware, and anti-virus facilities, these amenities are absent in Cisco FTD. However, when it comes to performance, FTD is capable of replacing ASA with ease.

Continue Reading:

Cisco PIX vs Cisco ASA Firewall

Intro to Cisco FTD Firewall (Firepower Threat Defense)

Are you preparing for your next interview?

Please check our e-store for e-book on Cisco ASA Interview Q&A. All the e-books are in easy to understand PDF Format, explained with relevant Diagrams (where required) for better ease of understanding.

An IP address is the basis of every communication over the network and Internet. Each computer device is assigned an IP address within an IP network which identifies the host as a unique entity. But due to shortage of IPv4 addresses most of the IP addresses are private and not routable anywhere outside of private enterprise networks. NAT or network address translation enables private IP addresses to connect to the Internet. NAT converges on public addresses because it can be configured to advertise at a minimum only one public IP address for the entire network to the external world. 

In today’s blog we will cover in detail about how NAT can be configured on FirePower Threat Defence.

Examples of types of NAT can be configured on FTD

Cisco NAT is one of the most basic functions for any device like a firewall. With NAT it is possible to access the Internet with a private IP address or give access from the Internet to the services with a private IP address. Cisco FTD NAT can be configured in many ways as under:

• With Source NAT for internal users having private IP address to connect to Internet
• With Destination NAT for users on Internet, connect to organization servers with private IP address
• With Static NAT and dynamic NAT having one to one mapping between real address and translated address or many real addresses translated to one or few addresses
• With Policy NAT – match traffic based on specific source and destination address and port number 
• With identity NAT exclude some traffic to translate over VPN tunnels

Cisco FTD NAT Configuration 

We will use below table example to demonstrate Cisco FTD NAT configuration 

Source NAT: Static NAT 

We configure to translate IP address 190.162.10.11 in the inside zone to 190.162.1.1. Static NAT is bi-directional by default and if both static and dynamic NATs are configured, static NAT has higher priority to take precedence. 

To implement NAT for the first time, create a policy and choose an FTD device on which we will configure NAT rules. 

Devices -> NAT -> New Policy -> Threat Defence NAT -> New policy 

To implement static NAT create and Auto NAT rule and mention ‘Source interface’ and ‘destination interface’ IP address 

Source Interface – real address ‘190.162.10.11’

Destination interface – translated address ‘190.162.1.11’ 

To test this configuration, send ping traffic from system behind FTD with address 190.162.10.11 to address 8.8.8.8 where source address will be translated to 190.162.1.11 when it is forwarded by FTD.

Source NAT: Dynamic NAT 

It is almost the same as static NAT except the translated address is chosen from a pool. Let’s create two lists one with a real IP address range from 190.162.10.2-5 and 190.162.1.2-5 range for translated address.

When you send a ping from IP address 190.162.10.2 it will be translated to 190.162.1.2 and when you ping from 190.162.10.4 then it will be translated to 190.162.1.4.

Source NAT: PAT NAT 

In PAT many addresses can be mapped to a single or few addresses. We will configure IP address range 190.162. 10.5-11 to a single FTD outside IP interface address 190.162.1.101. Enable PAT pool and Auto NAT rule.

To verify ping 190.162.1.8 and 190.162.1.9 will be translated to 190.162.1.101 which is IP address of FTD outside interface 

Destination NAT: Static NAT

In an earlier created static rule we mapped IP address 190.162.10.11 inside zone to IP address 190.162.1.11 in outside zone since static NAT is bi-directional this mapping will work vice versa also. so, when you access 190.162.1.11 from outside zone you will be connected to 190.162.10.11

Destination NAT: PAT NAT

When you access 190.162.1.101 and port 23 from the outside zone you will be connected to a server with IP address 190.162.10.10 with the same port number inside the zone. 

When you access 190.162.1.101 and port 22 you will be connected to a server with IP address 190.162.10.12 with the same port number inside the zone. 

Policy NAT 

Policy NAT is implemented by manual NAT to have more flexibility to match and translate or just not translate any source or destination IP address. There are two options in policy NAT – ‘Before Auto NAT’ and ‘After Auto NAT’.

With ‘Before Auto NAT’ manual rules takes precedence in processing and with ‘After Auto NAT’ there priority is lesser and will be processed if traffic do not match Auto NAT rules.

The src IP address 190.162.10.11 will only be translated to 190.162.1.177 only when the destination of the traffic is 190.162.1.111 else it will match static rule which translate source IP address 190.162.10.11 to IP address 190.162.1.11. 

Identity NAT

In this NAT there is an option to exclude the traffic. Usually it is implemented over VPN connections since traffic over VPN does not require translation; moreover VPN and NAT are also not compatible technologies. 

Traffic between 190.162.0.0/16 in the inside zone and 190.162.0.0/16 in the outside zone are exempted from NAT because they are internal subnets. 

Cisco FTD NAT Implementation 

Cisco FTD NAT is implemented in two different ways. Source and destination Network Address Translation (NAT) are implemented using Automated NAT. Policy NAT and Identity NAT, on the other hand, are implemented by means of Manual NAT.

Auto NAT

As we know, source NAT & destination NAT are implemented by Auto NAT. Both source and destination NAT can also be implemented using Manual NAT, however, the opposite is not possible. Complicated NAT scenarios cannot be implemented when using Auto NAT. When using Auto-NAT, the translation is associated to an object that has either the actual source addresses or the destination addresses, not both together. Auto NAT is not compatible with object group.

Manual NAT

With Manual NAT, you have the option to modify or keep the source and destination address unchanged together. Moreover, you can opt for either an individual object or an object group for both the real address and the translated address. Therefore, it is much more flexible.

Continue Reading:

Checkpoint NAT Policy: Types & Configuration

NAT Configuration & NAT Types – Palo Alto

As more and more systems are Internet facing due to high penetration of cloud and associates’ applications and services, the need for a very strong security system at perimeter or gateway to enterprises is becoming more and more crucial.

Earlier firewalls provided basic normal traffic filtering, and then intrusion detection systems were deployed by enterprises, soon they were replaced by intrusion prevention systems and now New generation firewalls with integrated threat management capabilities started their penetration, the boundary between hardware and software started to diminish and now integrative software image combining features of firewall, Intrusion detection / prevention came into existence. 

In today’s blog, we will cover in detail about Cisco Firepower threat defence NGIPS systems and how packet flow works in them.

Cisco FTD Firewall Packet Flow

Cisco FTD as NGIPS shares a management console with Cisco firewall offering known as Firepower management center. Cisco had acquired SourceFire in November 2013 and rebranded it as SourceFire to FirePower on ASA platform. (Which is Cisco’s own firewall). FirePower on ASA  is a next generation firewall with Anti-malware protection (AMP) for networks, next generation firewall on an existing platform.

The FirePower appliances run a special operating system known as FXOS. FXOS let you configure applications and decorators to interfaces. Apart from ASA application this also introduced a new application called FirePower threat defence or FTD as we know it in short. 

The number of available security modules is dependent on FirePower appliance platform or ASA platform. The below figure depicts its architecture.

figure:2

FTD is when run on the FXOS environment, packet traverses through firewall in a different way and actually ASA features are like a service module inside the FTD environment. Understanding packet flow helps to troubleshoot and create true policy and help to analyse data and fine tune the security appliance. 

There are two engines in the FTD unified software image ; Lina and Snort.

• Lina is the ASA code on which FTD runs on and
• Snort is the network analysis of packets which goes through Security Intelligence (SI) via ACP inspection of traffic by snort IPS rules. 

Cisco FTD: Packet Flow

Cisco FTD firewall Packet flow goes like this:

• LINA engine handle packet which enters via ingress interface
• Packet inspection is performed by Snort so this can include inspections like SI, IPS, AMP, URL filtering etc. 
• The Snort engine returns the result 
• Snort engine does not drop anything but instead marks packet drop or forward based on snort analysis result 

figure:3

Lina performs layer 2 processing, routing, NAT, VPN, Pre filter, and layer 3 – 4 access control policy rules check before Snort takes over. The Lina code takes over again after default action of Access control rule (ACP) and performs layer 2 routing, NAT , VPN etc.

Once a packet passes through Lina survived by Pre Filter or layer 3-4 ACP it will traverse the Snort process and go through layer 3 security intelligence white and blacklist post which application detection takes place if packet does not fall under blacklist or whitelist either. (Refer figure:1)

Packet will go further to L7 SI URL and DNS list and feed for authentication. Packets are finally compared to the rules in the main access control policy (L7 ACL) and from here they can be dropped, passed, or trusted and sent to the Egress engine. Based on configuration URL filtering and Malware policy will be enforced as well as the IPS rules on traffic. The packets are finally handed over to the Lina process for layer 2 routing, NAT, VPN etc. 

Continue Reading:

Packet Flow in Checkpoint Firewall

Packet Flow in Palo Alto – Detailed Explanation

Are you preparing for your next interview?

Please check our e-store for e-book on Cisco FTD Interview Q&A. All the e-books are in easy to understand PDF Format, explained with relevant Diagrams (where required) for better ease of understanding.

In today’s blog we will cover in detail about how site to site VPN is configured on FTD devices. 

Site to Site VPN Configuration on FTD

To configure a site to site VPN on FTD the first step is to configure FTD on FDM. 

Define protected networks

Navigate to Objects -> Networks -> Add New Network 

Configure objects for LAN networks from FDM graphic user interface (GUI).

I. Create an object 

Create an object for the local area network behind the FDM device as shown in figure above.

Create an object for remote network behind ASA device.

II. Configure site to site VPN 

Navigate to Site-to-site VPN -> create Site-to-Site VPN connection

Use Site-to-site wizard on FDM as depicted below:

Give name to Site-to-site VPN connection a profile name. Select the external interface for the FTD and then choose a local network that will need to be encrypted across site-to-site VPN.

Set the public interface of remote peer. Then choose the remote peer’s network that will be encrypted across site-to-site VPN.

On next page select ‘Edit’ and set the Internet Key Exchange (IKE) parameters.

Select ‘create new IKE policy’ and add parameters related to Encryption ‘AES256’; Integrity hash ‘SHA256’; Pseudo random function (PRF) hash ‘SHA256’. 

Post this, create new IPSec proposal. 

Set the authentication to a pre-shared key and enter the pre-shared key (PSK) which will be used on both sides. 

Set internal NAT exempt interface. If multiple inside interfaces that will be in use a manual exempt NAT rule will be created under policies -> NAT 

A summary of site-to-site will be displayed. 

To deploy the new site-to-site VPN 

Click Deployment -> Deploy Now.

You can also use FTD CLI commands to view Site-to-Site VPN SA and traffic statistics.

> show running-config crypto

> show isakmp

> show isakmp sa

> show ipsec

> show ipsec sa

> show isakmp stats

> show ipsec stats

III. Setup ASA configuration 

Enable IKEv2 on the outside interface of ASA.

Crypto ikev2 enable outside

Create ikev2 policy to define same parameters as configured on FTD.

Crypto ikev2 policy 1

Encryption aes-256

Integrity sha256

Group 14

Prf sha256

Lifetime seconds 86400

Create a group policy to allow IKEv2 protocol.

Group-policy FDM_GP internal
Group-policy FDM_GP attributes
Vpn-tunnel-protocol ikev2

Create a tunnel group for peer FTD public IP address.

Tunnel-group 192.168.100.10 type ipsec-l2l

Tunnel-group 192.168.100.10 general-attributes

Default-group-policy FDM_GP

Tunnel-group 192.168.100.10 ipsec-attributes

ikev2 local-authentication pre-shared-key cisco

ikev2 remote-authentication pre-shared-key cisco

Create an access-list that defines the traffic to be encrypted.

Create an IKEv2 IPsec-proposal that references the algorithms specified on the FTD.

Crypto ipsec ikev2 ipsec-proposal FDM

Protocol esp encryption aes-256

Protocol esp integrity sha-256

Create a crypto map entry to tie configuration.

Create a NAT exemption statement to prevent VPN traffic from being natted by firewall.

Continue Reading:

Cisco FTD Deployment Modes

Cisco FTD NAT: Configure and Verify NAT on FTD

In this blog, we will cover in detail about the FTD user identity feature, how it works and its architecture and configuration. 

Cisco FTD User Identity 

When we configure an access control policy, we can permit specific types of service for special users instead of IP addresses. The users then have to be authenticated before they are allowed to access a specific type of service. Identity policy authenticates network users and binds their IP address to username while authenticating new users.

If a deny or permit is applied for a specific service to a specific user, it will be applied to an IP address bound to that user. Let us understand this with an example:

• When we write an access control policy that User A is allowed to access service ‘X’, then we write an identity policy to authenticate users for specific type of traffic.
• User A is authenticated and its IP address 192.168.1.10 is mapped to User A username – from now IP address 192.168.1.10 is allowed to access service ‘X’ until the user is idle.

Username to IP address bindings is applied using passive or active authentication in Cisco FTD identity policy. 

Passive Authentication 

Passive authentication requires other tools which authenticate users and then give outcome to FTD. It is done through Cisco ISE dot1x authentication and pxGrid technology.  

FirePower user agent queries the active directory (AD) security event logs for user logon/ logoff events and sends them to FMC. Passive authentication is transparent to all users.

Active Authentication

The user logs into a FirePower captive portal webpage, which authenticates users against LDAP/AD. When authentication is successful then the user IP address will be mapped to user name.

A ‘Realm’ must be configured on FirePower management console (FMC) to download from the LDAP/Active directory the user / group.

An ‘Identity’ policy has identity rules which associate the traffic (Source / destination network zones) with the Realm and authentication method (active, passive or no authentication). The identity policy is referenced within Access control policy and implemented on FTD. FTD is sent the user / IP bindings and group memberships. 

No Authentication 

With this option we can ignore some traffic with ‘no authentication’ option.

Cisco FTD User Identity Configuration (Passive)

Let us look at steps to configure passive authentication using a Realm and identity policy. 

I. Configure Realms 

Login to FirePower Management console (FMC)

Navigate to System -> Integration -> Realms 

Click New Realm

Add domain details and click Ok.

Click ‘Add directory’ 

Add hostname / IP address of domain controller, port, and encryption 

Click ok 

Click ‘User download’ 

Select Download users and groups 

If connectivity is ok the FMC should query and download the groups. Select groups to include and use in access control policy. 

Click on ‘Save’

Click the ‘download now’ button to download groups and users within the group

Set a schedule to download users / groups as required 

II. Create an identity policy 

Navigate to Policies -> Access control -> Identity

Click ‘Add new policy’

Name the policy

Click ‘Add rule’

Name the rule

Define the Action as ‘Passive authentication’

Ensure ‘Enabled’ is selected

Define Zone and Networks

Click Realms & settings

From the Realm drop down choose Realm used previously 

Click ‘Save’ 

III. Modify Access Control Policy

Access control policy is to be configured to use identity policy and define the rules used for user authentication

Navigate to Policies -> Access control -> Access control 

Select existing access control policy

Click the ‘Advanced’ tab

Edit the identity Policy settings

From drop down select the identity policy

Click ‘Rules’

Create a new rule or modify an existing rule

Click the ‘Users’ tab

Click the Realm name , this should list all available users within the group and groups

Select the group to add rule

Click ‘Save’ 

Deploy the policy on FTD 

To verify login in CLI Expert mode and type

User_map_query.pl -I <IP address> – This command determines which user is associated to said IP address

Run command cat.ngfw.rules to view the Access control policy 

Run command cat user_identity.dump to view all active users with session on FTD 

Cisco FTD User Identity Configuration (Active)

Let us look at steps to configure active authentication via Identity policy configuration.

I. Cisco FTD identity policy configuration

• First create a new identity policy
• Create a rule to authenticate users for specific service traffic for example we choose all traffic from inside zone to outside zone to be authenticated 
• Choose ‘active authentication’ as method

Configure and authentication database in ‘Realms & Settings’ tab. 

• Click ‘save’ to save the rule, we will be asked to configure a certificate for captive portal authentication.

• Configured identity policy to be activated in access control policy.

• Give permission for some specific services to specific users or groups configured in active directory.

Continue Reading:

USER ID – Palo Alto Networks

Cisco FTD NAT: Configure and Verify NAT on FTD

URL filtering or content filtering is one of the key features of firewalls. It helps to prevent access to harmful and malicious content which could cause data loss, system crash, virus or worm infestation and provides employees access to good and reliable websites relevant for the business. Cisco URL filtering works in a similar way and based on the reputation rating or general classification of the website, risk level provides controlled access to Internet websites by configuring URL based policies and filters on the FTD.

In today’s lesson we will cover in detail about how Cisco FTD URL filtering functionality works, how it is configured and used.

Cisco FTD URL Filtering

URL filtering feature lets you control websites which users’ access on the network. URL filtering is majorly based on category and reputation or you can also opt for manual filtering where you can manually specify individual URLs, group of URLs, URL lists and feeds to achieve a more granular level of custom control over web traffic. 

FTD URL classification could be based on categories (classification) + reputation (risk level which can vary from High risk (1) to well known risk (5). If reputation level is set to ‘allow’ , all subsequent levels will be allowed also vice versa if reputation level is selected as ‘block’ , all subsequent levels also will be blocked.

URL filtering can be configured on HTTP, HTTPS, SSL.

HTTP filtering – URL filtering will be performed on plain text and configured in Access Control Policy (ACP) by matching application and configuring URL filter 

HTTPS filtering – FTD detect URL during SSL handshake from certificate CN , it disregards subdomains in CN and matches root domain only 

SSL filtering – Manual filtering is not supported and it is configured in SSL policy to match categories

Manual filtering – You can override URL categories and groups by manual URL configurations. But wildcard characters are not supported 

In FTD individual rules can be placed within categories and use to match based on zone, networks, VLANs tags, Users, Applications, Ports, URLs, SGTs. Based on rules actions can be considered to do when the match is available such as Allow, Trust, Monitor, Block, Block and Rest, Interactive block, interactive block with reset.

Limitations of FTD URL filtering

• Connection establishment with 3-way TCP handshake post receiving SSL exchange or HTTP request only FTD will be able to act
• Uncategorized URLs will pass thru unless they are blocked explicitly 
• It does not block search on blocked categories 
• Appliances with low memory perform more generic matches

How does the Cisco FTD URL lookup process work?

To accelerate the URL lookup process, URL filtering works on a local dataset installed on FirePower system locally. Availability of memory determines type of dataset availability as per below table.

Cisco FTD URL Filtering Configuration 

Prerequisites to be met:

• URL filtering licences for FirePower Threat defense devices
• URL filtering licenses for classic devices
• Assign URL filtering license to each managed device which will filter URLs
• At least one managed device must have URL filtering license assigned to it
• FirePower appliances are configured to connect to Internet on ports 443/tcp (HTTPS) and 80/TCP (HTTP) and to download or query URL category and reputation data 

Configure URL filtering with category and reputation.

Step 1: In access control rule editor, click URLs tab

Step 2: Click the Category tab in Categories and URLs list 

Step 3: Find and select categories of URL need to be added to the Category list. If you want to match web traffic irrespective of Category then choose Any category. Click on Search for a category prompt above Category list and type the category name. 

Note : Maximum of 50 items to the selected URLs can be added to match a single URL condition. 

Step 4: To qualify your category selections click a reputation level from Reputations list. If reputation level is not selected by default, it would be Any which means all levels. 

Step 5: Click Add to Rule to add selected items to Selected URLs list 

Step 6: Save to continue 

Example

Manual URL filtering 

Manual URL filtering is used to supplement or override URL filtering by category and reputation. We can control web traffic by manually specifying individual URLs, groups of URLs, or URL lists and feeds. This lets you do more granular control to block web traffic. 

Step 1: In access control rule editor, click URLs tab

Step 2: Click the URL tab in Categories and URLs list 

Step 3: Find and select URLs need to be added from URLs list. To search for URL objects, groups, global lists, custom lists and feeds or URL categories to add, click the Search for a URL prompt above URLs list, type either name of object or value of a URL or IP address in the object. The list updates as you type. To select object click it 

Note: Maximum of 50 items to the selected URLs can be added to match a single URL condition. 

Step 4: Click Add to Rule to add selected items to Selected URLs list 

Step 5: Save and continue

Continue Reading:

URL Filtering vs Proxy : Know the difference

What is URL Filtering?

FAQs

Is FTD a zone-based firewall?

As a firewall, FTD utilizes a zone-based system, the same security traffic CLI is not necessary for communication to take place between different interfaces.

What is URL Filtering in FTD?

The Cisco FTD URL Filtering feature provides the capability to regulate the websites that individuals on your network can view, depending on its category, reputation, a mixture of both category and reputation, as well as manually-entered URLs.

How Does URL Filtering Work?

URL filtering technology utilizes a database of URLs to determine whether or not web traffic should be allowed to pass through, depending on the details stored in the database.

What is the difference between URL Filtering and Domain Filtering?

In comparison to DNS filtering, which centers on blocking domains, URL filtering enables you to secure users by obstructing access to precise URLs. Furthermore, URL filtering concentrates on HTTP/HTTPS traffic and provides user-oriented rules for allowing, cautioning, or impeding access to web categories or particular URLs.

In today’s blog we will cover in detail about the Cisco FTD high availability feature, how it works and its architecture and configuration. 

Cisco FTD High Availability

Cisco FTD high availability configuration has some basic requirements to be met before they can be configured for failover as under. 

• Be it same model
• Have the same number and type of interfaces
• Have to be in same firewall mode (routed or transparent)
• Have same version of software
• Be in same domain or group on FMC (FirePower management console)
• Have same NTP configuration
• Fully deployed on FMC with no uncommitted changes
• Not have DHCP or PPPoE configuration on any of the interfaces
• FTD devices in HA must have same license
• HA configuration requires two smart license entitlements one for each device in the pair 
• FTD supports active standby mode 
• Latency must be less than 10ms, no more than 250ms
• HA is only supported for 2 FTD devices 

Failover link can be connected using a switch to a dedicated network segment (VLAN or broadcast domain) or could be direct connection between the two devices with the same Ethernet speed and Ethernet number. 

Configure High Availability in FTD

To configure FTD for high availability both devices required to be added to the FirePower management console (FMC) manually one by one. Verify version details etc. 

In FirePower management console to configure High availability navigate to Devices-> Device management -> Add -> Add high availability 

Enter details as below: 

Name: FTD-HA

Device type: FirePower Threat defence

Primary peer: FTDv1

Secondary peer: FTDv2 

Click to ‘Proceed’ 

Enter HA and ‘state link’ details as under (IPsec encryption is optional between HA and state links). Over state link, connection state information like session table and NAT table are synchronized, so that if a failover occurs, existing connections will not be disrupted. The active unit uses the state link to pass connection state information to the standby device.

High availability link 

Interface: Ga0/4

Logical name: HA-link

Primary IP: 172.16.31.1

Secondary IP: 172.16.32.2

Subnet Mask: 255.255.255.252

State link 

Interface: Ga0/5

Logical name: State-link

Primary IP: 172.16.31.5

Secondary IP: 172.16.31.5

Subnet Mask: 255.255.255.252

Click ‘ok’ to submit and wait for few minutes for HA pair to get deployed.

The HA setup is complete and FTDv1 is primary (active) and FTDv2 is secondary (standby). 

Continue Reading:

High Availability Palo Alto

Fortinet FortiGate HA (High Availability): Detailed Guide

Checkpoint HA Active/Standby and Load Sharing in ClusterXL

In today’s blog we will cover in detail about how Cisco FTD SSL decryption, how it works, its features and limitations.

Cisco FTD SSL Decryption

Connections go through access control policy to determine if they are allowed to pass or blocked. When SSL decryption policy is enabled, encrypted connections are first sent to SSL decryption policy to determine if they are allowed to remain encrypted and blocked or allowed to be decrypted. Any unblocked connections, go through access control policy for a final block or allow decision. 

Why is SSL Decryption Enabled?

Encrypted traffic like HTTPS connections is not possible to be inspected. Many connections which carry customer sensitive data such as banks and financial institutions connections to the FDM are encrypted. Also, users can hide undesirable traffic in encrypted connections. With the SSL decryption feature we can decrypt connections, inspect them to ensure they do not contain any threats or undesirable traffic and re-encrypt them before allowing them to proceed on to the network. The end objective is twofold here one is to apply access control policies and second , users need to protect sensitive information. 

SSL decryption rules can be configured to block encrypted traffic which you want to restrict. 

Actions associated with FTD SSL Decryption

Decrypt Re-sign  

If you decide to decrypt and re-sign traffic then the system acts as Man in the middle. When traffic reaches the FTD device, the device negotiates with the user and builds an SSL tunnel between user and FTD device. The device connects to the website and creates an SSL tunnel between server and FTD device. The user sees a CA certificate configured for the SSL decryption rule instead of a certificate from the website. The user must trust the certificate so as to complete the connection. The FTD device thus performs decryption/encryption in both directions for traffic between user and destination server.

Decrypt known key 

If you know the destination server, we can implement decryption with a known key. When the user opens a connection to the website, the user will see the actual certificate for the website which is presented by FTD device. Organization must be the owner of the domain and certificate. The main objective of decrypting with a known key is to decrypt traffic heading to your HTTPS server to protect it from external attacks.

Do not decrypt 

If you decide to bypass decryption for certain types of traffic , no processing will be done on traffic. The encrypted traffic proceeds to an access control policy where it is allowed or not allowed based on matching access control rules. 

Block 

We can simply block encrypted traffic which matches SSL decryption rules. Block at SSL decryption policy to prevent the connection from reaching access control policy.

Auto generation of FTD SSL decryption rules 

When you enable SSL decryption policy, the system automatically generates a Decrypt re-sign rule for each identity policy rule which implements active authentication. This is required to enable active authentication for HTTPS connections. 

Limitations of  FTD SSL Decryption

• Minimum supported SSL version is SSLV3
• The system does not recognize cipher suite for connection
• The system does not support decryption based on detected cypher suite
• System did not cache session identifier
• Errors occurring during SSL handshake negotiation

Continue Reading:

Palo Alto SSL Decryption

Fundamentals of FortiGate Firewall: Essential Guide

Are you preparing for your next interview?

Please check our e-store for e-book on Cisco FTD Interview Q&A. All the e-books are in easy to understand PDF Format, explained with relevant Diagrams (where required) for better ease of understanding.

In today’s blog we will cover in detail about how CLI works for Cisco FTD and what CLI commands are available in Cisco FTD.  

Overview of Command line interface (CLI)

You can use an SSH client to make a connection to the management IP address and log in using admin username (default password is admin 123) or another CLI user account. CLI supports local authentication only and you cannot access CLI using external authentication. Another option you can use is to connect directly to the console port via console cable. 

Cisco FTD Command Line Interface

The CLI in FirePower threat defence device has different modes. We will understand more about them in the upcoming section. 

• Regular CLI is used for threat defence management system configuration and troubleshooting.
• Diagnostic CLI is used for advanced troubleshooting as it has additional show and other commands. To login to this CLI use session wlan console command. To enter Privileged EXEC mode use system support diagnostic -cli command 

Expert mode is used only if a documented procedure tells you to do so or if the Cisco technical assistance center asks you to use it. Use ‘expert’ command to enter this mode. 

FXOS is also used for configuration and troubleshooting so from FXOS you can enter ‘connect’ command to enter into threat defence console

For all appliance mode models (other than FirePower 4100/9300) you can go to threat defence CLI to the FXOS CLI using connect fxos command 

Cisco FTD commands 

There is a huge list of CLI commands in Cisco FTD, we will look at some important commands and understand its usage.

Capture – to enable packet capturing capabilities for packet sniffing and network fault isolation you can use this command. 

Capture capture_name

FTD is capable of tracking all IP traffic that flows across it and of capturing all the IP traffic

To enable / disable automatic updates of CA certificates on FTD device use 

Configure cert-update auto-update {enable | disable} 

To clear HTTPS access list, configure device to reject HTTPS connection attempts from all IP addresses 

Configure disable-https-access

To clear SSH access list, configure device to reject SSH connection attempts from all IP addresses 

Configure disable-ssh-access

To configure FTD to accept HTTPS connections from specific IP address use

Configure https-access-list address_list

To enable or disable the default application protocol inspection engines, use

Configure inspection protocol {enable | disable}

To configure the DNS servers for the management interface, use

Configure network dns servers [ dnslist]

To view a brief status of the connection (tunnel) between the device and the managing management center, use

sftunnel-status-brief

Displays statistics about egress optimization

show asp inspect-dp egress optimization

To display the queue information for all snort instances (processes) aggregating all queues to the same instance

show asp inspect-dp snort queues [instance instance_id] [detail] [debug]

To display the automatic snapshots of when a snort queue exhaustion occurs, use

show asp inspect-dp snort queue-exhaustion [ snapshot snapshot_id] [ export location]

To determine the route packets will take to their destination through data interfaces, use

traceroute destination [ source { source_ip | source-interface}] [ numeric] [ timeout timeout_value] [ probe probe_num] [ ttl min_ttl max_ttl] [ port port_value] [ use-icmp]

**Important Tip**

When making changes to the configuration of your Secure Firewall Management Center or Secure Firewall device manager, avoid using the threat defense command line interface for commands that take a long time to execute (i.e. using ping with a large number of repetitions or size). Doing so could lead to deployment issues.

For the complete list of commands, you can refer this link 

https://www.cisco.com/c/en/us/td/docs/security/firepower/command_ref/b_Command_Reference_for_Firepower_Threat_Defense/c_2.html

Continue Reading:

Palo Alto Troubleshooting CLI Commands

Intro to Cisco FTD Firewall (Firepower Threat Defense)

In today’s blog we will cover in detail about Cisco Unified Firepower threat defence software, its features, use cases, architecture. 

Cisco FTD (Firepower Threat Defense)

Cisco acquired Sourcefire in the year 2013, they are the top leader in the cybersecurity industry with Intrusion detection systems, intrusion prevention systems, and Next generation firewalls. The Sourcefire is based on Snort which is an open-source network intrusion detection and prevention system. Cisco, after acquiring Sourcefire, leveraged its technology and released Firepower 2100 series, 4100 series and 9300 series. 

A Firepower system deployment comprises two appliance types: 

• a management appliance 
• a sensor appliance

Sensor inspects network traffic and sends any events to management appliance. Management appliance manages all kinds of security policies for the sensor.

In Firepower FTD Cisco converges all Sourcefire features such as ASA firewall, Intrusion prevention and detection system, Malware protection into a single unified storage image. The Firepower system gives many security features as described below:

• Firepower core software – is the core part of software including the snort engine for Intrusion detection and prevention , web server for GUI, database for event storage, hardware firmware. Core software image would depend on the hardware platform it is installed on.
• Snort / Sourcefire rules – Snort engine uses a special rule set to detect and prevent intrusion attempts. Each rule has a set of conditions based on which action is taken on the data packet.
• Vulnerability database (VD) – stores vulnerability information and fingerprints of several applications, services, and operating systems. Fingerprint is used to discover application, service and OS and correlate application and network discovery data with vulnerability information in database. 
• Geolocation database (GeoDB) – stores geographical information and its associated IP addresses. You can view the name and flag of the country that originated the intrusion attempt to take quick action.
• URL filtering database – websites can be categorized on the basis of their targeted audience and purpose. System enables control to access a certain type of website based on its reputation level. 
• Security intelligence feed (SIF) – Talos component shares intelligence data through security intelligence feed 
• Local malware detection – FTD can detect viruses in files. FTD uses the CalmAV engine for local analysis of files. 
• Integration – Firepower systems can be integrated with various technologies such as Cisco identity services engine (ISE), Microsoft Windows Active directory server, Event Streamer (eStreamer) , and syslog server. 

Cisco Firepower Features:

• Stateful firewall inspection capabilities
• Static and dynamic routing 
• Next generation intrusion prevention systems 
• URL filtering
• Application visibility and control
• Advanced malware protection
• SSL decryption
• Captive portal (Guest web portal)
• Multi domain management is supported
• Rate limit can be implemented
• Site to site VPN between FTD appliances and FTD to ASA
• Multicast routing shared NAT

Cisco FTD Installation

Use a valid CCO account to download software. 

Visit: Downloads Home>Products>Security>Firewalls>Next-Generation Firewalls (NGFW)>ASA 5500-X with Firepower series and choose Firepower Threat defense software.

Now, Select and download the latest boot image and system version.

Now reboot ASA appliance and during the boot process press Break or Esc to interrupt boot.

Boot interrupted.

Management0/0

Link is DOWN

MAC Address: 00f6.63da.e807

Use? for help.

rommon #1>

Once the boot is interrupted, we need to configure necessary parameters on ASA firewall to download the Cisco Firepower Threat Defense boot image. Connect to ASA console port and check that Cisco ASA is running rommon version v.1.1.8 or greater. If the version is lower than upgrade is required.

Issue tftpdnld command on rommon console to download boot image of the ASA firewall. 

rommon #7> tftpdnld

Post successful download of firewall and booting with boot image it is now ready to accept system image. 

FirewallCK-boot> setup

Welcome to Cisco FTD Setup

[hit Ctrl-C to abort]

Default values are inside []

Provide input for below 

Enter a hostname [FirewallCK]: FirewallCK FTD

Do you want to configure an IPv4 address on the management interface? (y/n) [Y]: y

Do you want to enable DHCP for IPv4 address assignment on the management interface? (y/n) [Y]: n

Enter an IPv4 address: 11.30.1.129

Enter the netmask: 255.255.255.0

Enter the gateway: 11.30.4.150

Do you want to configure a static IPv6 address on the management interface? (y/n) [N]: n

Stateless autoconfiguration will be enabled for IPv6 addresses

Enter the primary DNS server IP address: 11.30.4.150

Do you want to configure a Secondary DNS Server? (y/n) [n]: n

Do you want to configure Local Domain Name? (y/n) [n]: y

Enter the local domain name: firewall.ck

Do you want to configure Search domains? (y/n) [n]: n

Do you want to enable the NTP service? [Y]: n

Please review the final configuration and with this initial configuration complete and it is ready to download FTD system image and begin FTD installation. 

Continue Reading:

What is an ML Powered NGFW?

Types of Firewall: Network Security