Checking Open Ports (Telnetting, TCPING & Scanners)

You can use various methods to check open ports of a server. Old school Telnet is the command prompt tool you can use easily for a 1 targeted host.

Telnet

Let's say I need to know whether https (TCP port 443) is available at facebook.com

The command would be;

telnet facebook.com 443

If it is open, it will give an output telling connecting... and then the screen will be totally black..

To quit from  the connection, you should hit Ctrl + ] keys and type quit.

Now let's try the same thing from Cisco CLI;

To quit from the session, you should hit Ctrl + Shift + 6 and release and enter X

It will go back to the Cisco CLI again but will not really disconnect the session, If you hit Enter it will continue the session again. So you need to type disconnect and hit enter..

TCPING

TCPING is a small Windows command prompt tool I use which does basically the same thing in a different way. You can download it from their official site

https://www.elifulkerson.com/projects/tcping.php

I have unzipped the folder and pasted the contents into the System32 folder.

It is simple; tcping facebook.com 443 command will show the replies if open.

Scanners

If you need to scan an entire network/subnet for open ports, you should use a network scanner. There are plenty of them and they are very easy to use. One I use in Windows is Advanced IP Scanner..

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 PaloAlto 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 PaloAlto 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 PaloAlto 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..