Configuring WebVPN (Clientless SSL VPN) on Cisco ASA

This is a quick and easy way to give access to an internal resource from outside using SSL type of VPN without a vpn client.

Configuration on ASA will be like the following,

Assuming basic configuration is done, 

webvpn

 enable OUTSIDE

group-policy WEBVPN internal

group-policy WEBVPN attributes

 banner value "Unauthorized Access Denied"

 vpn-tunnel-protocol ssl-clientless

 

username cisco password cisco123

username cisco attributes

 vpn-group-policy WEBVPN

OUTSIDE is the G0/0 interface name, what I have done over there is that the group-policy and it's attributes were defined and the group policy is specified under username attributes.

When the user opens his web browser and browse the OUTSIDE interface IP, 

The banner will be displayed after entering the username. In this example it is cisco and password is cisco123.

You can see that the following services will be accessible.

If the routing is available from ASA to the server, the user will be able to gain access without the need of any access control entry.

What happens at the backend actually is a new IP will be assigned to the user session from ASA. The server will see that IP, not the real user IP.

Port Forwarding with WebVPN

As you can see on the dropdown, only http, https, cifs and ftp are the capable protocols. But if you need to do any other protocol like telnet, ssh etc, you will do a port forward in WebVPN.

webvpn

 port-forward APPS 30001 192.168.10.10 23

group-policy WEBVPN attributes

 webvpn

  port-forward value APPS

Anyone in the WebVPN group will have this access..

Now log off and login again will show another new icon "Application Access".

If JRE1.4 is working well on the users PC, you will get the dialog box to access. Because of Java issues, will not be possible to run on most machines. Even the later versions of JRE would not work.

Clearing the Confusion of CLI & GUI Admins of Cisco ISE

Cisco ISE is an application developed on top of Cisco ADE-OS (Application Development Engine).  Because of that, it cannot be accessed through it's CLI. When we log in to the so called ISE CLI, it's actually the ADE-OS CLI where we can configure interface IPs, routing etc. Also we use that interface  to see the status of the Cisco ISE application by the following famous command, show application status ise.

So the CLI admin account has nothing to do with the ISE application admin account.

This CLI admin account password is asked to change during the initial login to the device. If you want to change it later on, use the following command,

password

Confusion comes with the account name "admin" is being same for the ISE default application but with a password you need to set additionally with the following command,

application reset-passwd ise admin

Use this admin account/password to log in to the ISE through Web UI.

A Backdoor Access to Cisco FTD LINA Configure Mode from CLI

Normally you are not allowed to go to configure mode via CLI of a Cisco FTD which is managed by FMC. But following commands will enable a backdoor access to do that. Here is an example configuration adding to increase the mac address aging time which is not even supported by FMC Flex Configs currently.

Go to the LINA mode and get the serial number

> system support diagnostic-cli

Firepower> enable

Firepower# show version

Enter to FTD expert mode and gain sudo su access

> expert

$ sudo su

#

Enter command below command. Where "XXXXXXXX" is the serial number you found from "show version". Replace XXXXXXXX with the collected serial number from step 1.

# echo -n "1111222233334444XXXXXXXX" | md5sum > /mnt/disk0/enable_configure 

Go back to LINA and enter "debug menu file-system 7" command 

> system support-diagnostic-cli

Firepower> enable

Firepower# debug menu file-system 7

Now you are able to go to Configure mode just like in a regular ASA.

I am just changing the mac-address aging timer 

configure terminal

mac-address-table aging-time 720

exit

wr

Go back to expert mode and run the following command:

> expert

$ sudo su

# rm /mnt/disk0/enable_configure

Notes

This is a temporary fix to a problem where this will be flushed once a new policy deployed from FMC.

Use this for troubleshooting purposes only.

Application and Interrelationship of Cisco FMC Policies

There are many policies we hear when we deal with Cisco FMC which makes it confusing where to find and where to apply. In this post, I'm going to make a brief note on all of them and and their interrelationship.

Policies are reusable set of rules/conditions. The different kinds of policies in FMC are Access Control Policy, Intrusion Policy, Malware & File Policy, DNS Policy, Identity Policy, SSL Policy, Prefilter Policy, Network Analysis Policy, Network Discovery Policy, NAT Policy, QoS Policy,  Settings Policy, Correlation Policy and Health Policy. 😵 I think I named all..

Following are short descriptions for the above rules.

Access Control Policy - From all of above, the Access Control Policy (ACP) is the main type of policy which most of other policies are packaged in.

1 FTD can only have 1 Access Control Policy

Access Control Policy rules have it's legacy firewall rule functionality with added next-generation features which are defined in most of other types of polices.

Intrusion Policy - This defines set of intrusion detection and prevention configurations which inspect traffic for security violations and, in inline deployments, can block or alter malicious traffic.

Malware & File Policy - This is a set of configurations that the system uses to perform malware protection and file control, as part of your overall access control configuration.

DNS Policy - DNS based Security Intelligence allows you to whitelist or blacklist traffic based on the domain name requested by a client.

Identity Policy - Identity policies contain identity rules. Identity rules associate sets of traffic with a realm and an authentication method: passive authentication, active authentication, or no authentication.
This is a requirement when we plan to use the users or group in our Access Control Policy

SSL Policy - An SSL policy determines how the system handles encrypted SSL traffic (https etc) on your network. 

Prefilter Policy - This is basically to drop traffic or bypass the firewall inspections totally which is unwanted even to go through the FTD.

Network Analysis Policy - These are for traffic preprocessing options. Cisco is saying that Network analysis-related preprocessing occurs after Security Intelligence blacklisting and SSL decryption, but before intrusion or file inspection begins.

Network Discovery Policy -  This is there to identify what are attached to the network.
It is used to build Host Profiles of devices including information like OS, services, web apps, protocols, users, IOC tags, VLAN tags, malware events, vulnerabilities, scan results, hostname, mac address, scan results and much more..

NAT Policy - This is to configure the Network Address Translation settings of a FTD.

QoS Policy - This is to configure the QoS settings for a FTD.

Settings Policy - This is where you configure the basic settings of a FTD like ARP Inspection, Banner etc.

Correlation Policy - This is basically If This --> Then That functionality of the FMC. It can be used to respond in real-time to threats / specific event types/ specific hosts / specific users or network traffic conditions.

Health Policy - This is to monitor overall functionality and performance of the whole Firepower system. So this policy can apply to both FMC itself and to FTDs.

Now let's look the interrelationship of the above polices.

When you click on Policies tab, the 1st menu is the Access Control and the default selection is Access Control menu item. In line to Access Control, you can see Network Discovery and Correlation are there. Those 2 are also types of policies you can configure in FMC which is for FMC.

"in FMC which is for FMC" means the policies used in FMC itself, not to deploy in FTDs..

The items you can see in the Access Control drop down are the policies which can be attached to Access Control Policies or to Access Control Policy rules.

Following is an example output in Access Control Page where the ACPs are listed.

(click on the image to view in full size)

Here you can see that there are 4 Access Control Polices created on the FMC and the ACPs can be configured hierarchically. Also notice the rounded tab which is the place to create Network Analysis Policies. 

Let's go inside the ACP.

Shield is for IPS Policy (Intrusion) and Files mark is for Malware & File Policy.. So you can see that they are attached to the Rule 01 but Prefilter, SSL & Identity Policies are attached to whole Access Control Policy not to a particular Access Control Rule. 

If you go to Edit rule (via pencil) you will find the places to add the IPS and Malware & File Policy.

You can see the place to attach DNS Policy under Security Intelligence tab in ACP.

In Advanced Tab, you can see the place to bind the Network Analysis Policy.

You can find the Settings Policy under Devices > Platform Settings

Following are the things you can change in it.

Health Policy is bit different from other policies because it can be used to monitor both FMC and FTDs. You can find it on System > Health > Policy and assign it to a device by clicking the  in front of the policy. Also you can do the same thing by Devices > Choose the device then click Device, there you will see the applied Health Policy.

Summary

Allow Pings (ICMP) & Traceroutes through Cisco ASA Firewalls

ASA Firewalls does not allow ICMP traffic to pass through it's interfaces by default. For real scenarios it is better that way in terms of security concerns. But for lab purposes and to verify implementations you will need it to be allowed from Firewall.

Why ICMP is blocked by ASA?

Short answer is because it is not in the list of state full inspection protocols. 

You can see the default inspection protocols list on the capture.

So you may need to configure access-control rules for both source and destination interfaces but it will bypass the firewall functionality. Firewall should remember the legitimate ICMP traffic and allow only the return traffic to pass through.

So you will need to add ICMP to the default inspection policy in global policy which is under the service policies.

Doing it in CLI is simple;

policy-map global_policy

 class inspection_default

  inspect icmp

  inspect icmp error

Make ASA Visible in Traceroutes

By default ASA is not visible in traceroutes as it does not decrement the TTL. To make it visible in a traceroute, we will need to add the following configuration to the default class in global policy.

policy-map global_policy

 class class-default

  set connection decrement-ttl

Switching to CLISH, Firepower Linux CLI & LINA in Cisco FTD Software

Last month I documented a practical about some basic understanding of ASA Engine and the Firepower Engine of Cisco FTD. 

You can go through it from here. Anyhow I believe one more dedicated post is required to show how we can move back and forth from 3 CLIs.

The 3 CLIs in Cisco FTD are;

1. Converged FTD CLISH (Command Line Interface Shell)
2. Firepower Linux CLI (Snort CLI)
3. LINA (Linux on ASA)

Converged FTD CLISH inherits some Firepower Linux management plane commands and most of the data plane related Cisco ASA commands.

Firepower Linux CLI is just plain Linux access to the Firepower Engine. You will need this to view the Management Plane routing stuff for Cisco FMC.

LINA is just classic Cisco ASA privilege level commands without config mode. This is where the Data Plane routing stuff is in.

Let's start exploring the commands and finally summarize with a graph..

When you SSH to the FTD, initially you will go to the Converged FTD CLISH cli with the user mode you logged in.

It shows just a ' > ' which indicates the very basic mode of operation in CLISH cli.

If you want to go to the LINA cli from here you can enter the following command.

system support diagnostic-cli

Now you can go to privilege mode by command enable, just like in classic ASA cli.

If you want to jump back to the CLISH mode from here, you can use a key sequence

Ctrl + A then release the keys and enter D

Or just you can type exit 2 times in LINA cli to logoff and to detach from it, which will lead back to CLISH cli.

If you want to go to the Firepower Linux shell from here you can enter expert and proceed. This is also called the expert mode which is advanced Linux access.

To go to the root, enter sudo su and the password just like in other Linux distros.

You can go to the LINA cli from here just by entering the following command.

sfconsole

If you enter the Ctrl + A then D sequence now, this will lead you to the Firepower Linux cli because you were there before switching to LINA.

You can also type lina_cli to go to LINA cli, but this command is deprecated in newer FTDs.

You can also type clish to go back to to the CLISH cli from root. But keep in mind that this mode is pretty useless. (useless than the default converged CLISH cli of user mode). You will see you can't even enter system support diagnostic-cli command from here.

If you exit from here now, it will go back to the root's advanced cli where you were in expert mode.

Following is a summary of the modes and commands for a quick reference.

Note:-

There is another CLI you will very rarely meet in FTDs. This is in Firepower Appliances and we call it FXOS. It is just like the LINA so you may get confused just by seeing it. To go to the Service Module 1 where the FTD software (Converged CLISH) is installed, you can type the following command..

FXOS# connect module 1 console

It will navigate to the following  looking CLI which is the service module. You should enter the following command to go to the FTD software ( the Converged CLISH we know)

Firepower-Module1> connect ftd

Now you are in the FTD software and all the above things we discussed will be working..

If you want to go back to Service Module or FXOS, just hit type exit..

DMZ / INSIDE Server Access Through Palo Alto via Destination NAT

I have achieved the same result using Static NAT which can be also called Source NAT / One-to-One bidirectional NAT. Please click here to view that post.

This post is about how we can do the same thing using a destination NAT. 

Diagram and IPs are same; 

Imagine 10.1.1.10 and 10.1.1.11 are public IPs and 10.1.1.10 is the IP address of the physical interface.

Users from internet should be able to ping 10.1.1.11 which represents the DMZ server 100.2.2.10

This time, the NAT rule is like the following. (click on the images to view in full size)

Go to Policies > NAT

Both the Source IP and the Destination IP (10.1.1.11) are from OUTSIDE and the Destination IP of the original packet (which the user tries to access) is the public IP for the server which will be translated to the local IP of the server.

The Security Policy is just same as in the Source NAT example.

Go to Policies > Security

Remember that the destination address of the Security Policy here is the public IP, 

because: 

Security Policy Hits first , then NAT Policy & then Routing..

DMZ / INSIDE Server Access Through Palo Alto via Static Source NAT

Though this is a simple concept, I believe it needs a note because it is bit confusing which IP to use in the Firewall Policy. This is the method used in Palo Alto and other perimeter firewalls if you want to give access to an internal server via a public IP to the internet users.

Imagine 10.1.1.10 and 10.1.1.11 are public IPs and 10.1.1.10 is the ip address of the physical interface.

Users from internet should be able to ping 10.1.1.11 which represents the DMZ server 100.2.2.10

1st let's make sure DMZ SVR can access internet with a NAT IP 10.1.1.11

Go to Polices > NAT and configure the NAT rule should be like the following, 

(click on the image to view in full size)

This is a simple Static (one-to-one) NAT rule with a bi-directional config option. 

DMZ SVR IP (Source IP) 100.2.2.10 is translated to the Public IP. 

This NAT rule is just enough for the server to access internet as 10.1.1.11,  of course there should be a normal allowed Security Policy from DMZ to OUTSIDE with basic routing.

Now let's give access to 100.2.2.10 server from OUTSIDE via 10.1.1.11 by a Security policy,

Go to Policies > Security

Point to remember is that the destination address of the Security Policy here is the public IP.

Keep in mind,

Security Policy Hits first , then NAT Policy & then Routing..

Understanding Interfaces, Routing & CLIs of 2 Engines in Cisco FTD

By this post I am about to come up with a distinction to one of the most confusing concepts about Cisco FTD, the story of 2 Engines; how Firepower engine and ASA engine works together..

To know how to do an initial configuration of FMC and FTD please click here.

I am using the following lab topology for configurations but it has very little to do with this discussion.

Before we begin let's clarify the confusion of Command Line Interfaces we can see on Cisco FTD.

There are 3 CLIs

1. Converged FTD CLISH (Command Line Interface Shell)

2. Firepower Linux CLI

3. LINA (Linux on ASA)

Converged FTD CLISH can be seen as '>' and it inherits Firepower Linux management plane commands and most of the data plane related Cisco ASA commands.

Firepower Linux CLI is just plain Linux access to the Firepower Engine. You will need this to view the Management Plane routing stuff for Cisco FMC.

LINA is just classic Cisco ASA privilege level commands without config mode. This is where the Data Plane routing stuff is in.

Ok now to the practical..

If you remember in initial configuration, we have to give the IP address, mask and gateway of the management interface and that interface is not shown in the default CLI which is Converged FTD CLISH.

Note:- 

In the above diagram, You can see that interface as eth0/mgmnt. The IP gave for that was 172.16.10.10 as per the diagram.

Let's switch to the LINA CLI and see whether it is there.

Enter the command system support diagnostic-cli and then enable password, then show interface ip brief just like in Cisco ASA.

It is strange that there is a Management Interface defined in the ASA engine but it has nothing to do with the Management interface IP we configured.

No route can be seen in routing table too.

But if you switch to the expert mode / Firepower Linux cli, you can see it is there.

Let's exit back to CLISH and go to Firepower Linux cli using expert expert command, then use Linux commands..

Br1 is the interface. You can see the routing table too.

You can ping FMC from here. What we have to conclude is that this interface is just a part of the Firepower engine which is used to connect to FMC.

After I added this FTD to FMC, I have configured some interfaces and a route for Data Plane. You can see that traffic is about to take G0/1 interface as per the design. Let's see that interface and those Data Plane routes belongs to which engine.

I am not going through in detail with the configuration but I hope the following snippets and the above topology diagram explains it all.

The Interfaces will be like the following,

The default route is configured like the following..

Deploying..

Now let's see on Converged CLISH CLI,

Let's go the LINA and see whether they are there or not.

So all the routes are there in LINA which means in ASA engine. If you go to the Firepower engine, you will see there is no change. So as a conclusion, all the routes and interfaces related to data plane is actually in the ASA engine itself while FMC connecting interface is in Firepower engine. This clarifies the idea of ASA engine handling up to Layer 4 and above Layer 4 is for Firepower engine to take care of.

Following figure from Cisco Firepower Threat Defense Book by Nazmul Rajib shows a correlation of these 2 engines inside a FTD when inspecting a traffic..

Note that the above LINA commands could be viewed in CLISH too, I have not showed that for the sake of clarity. To understand more about the 3 CLIs in FTD, please go here.

Running Cisco FMC + FTD Initially on EVE-NG

Well I am going to share my experience of FMC + FTD initial lab setup. You will have to have an EVE-NG server with a lot RAM otherwise it won't work.

32 GB RAM For FMC
8 GB RAM per FTD

It takes a long time to come up even with above amount of RAM.. more than 30 minutes perhaps!

Also remember to get FMC and FTD in same version.
ex:- If FMC is 6.2.0 the FTD must also be 6.2.0


I used 6.2.0 version, 6.3.0 was not working for me..

For both FMC & FTD, the default credentials are as follows..

username: admin

password: Admin123

If  it seems FMC or FTD is booted up but not accepting the credentials all the time, just give it some time and try, it must be still booting.. If it is not connecting and showing database connecting error or something, reboot it and hit enter when the red screen appears..

1st let's look at FMC,

After you enter the default login credentials just enter the following command and will go through the initial setup wizard..

sudo configure-network

As you can see, the Management IP address for FMC is 10.1.3.10

This is the IP I use to log in to FMC and also to register FTDs.

After the above are configured, you can access it through a web browser, It will go through a configuration verification page 1st time you login, where you will configure the new password..

Now it's time to register this in evaluation mode,

Go to System > Licenses > Smart Licenses and click on evaluation mode. 

This give you 90 days of full features.

Now to the FTD,

After you enter the default credentials you will be asked to accept the EULA (End User License Agreement) and then it will ask you to change the default password to something new and the wizard will come up then..

You can verify the configuration by the following command after this.

>show network

Now let's try adding the FTD to FMC.

Just add the FMC address at FTD by following command,

>configure manager add 10.1.3.10 cisco123

cisco123 was the key

Now you can verify the FMC address by following command,

>show managers

Now at FMC GUI, 

Go to Devices > Device Management > +Add Device

You will need to create an Access Policy because the FTD must have it before it is added.

Just create click on the drop down and create new one with action of network discovery like the following..

If it is successfully added, you will see it like the following,

Notes:-

You will notice on FTD that you cannot ping anywhere from it,

This is because there is no route to anywhere no ip address seen on Management interface,

This is because you are at the ASA engine, to go to the Firepower engine enter the following command,

>expert

Now you can see the gateway gave at the beginning and you should be able to ping FMC from here. Remember this is a Linux shell..

By the way, there is a command in Converged CLISH mode to ping the FMC,

ping system 10.1.3.10

If you ever needed to change the IP address of the FMC, you can do it via the following CLI command from expert mode,

sudo /usr/local/sf/bin/configure-network