Update Cisco ASA 5506-X with Firepower

A customer bought a Cisco 5506-X with Firepower. It was delivered with Firepower version 5.4.1 (221). The upgrade process of a Cisco ASA is normally pretty straightforward. So I thought maybe a Firepower (FP) module is as easy to upgrade as an ASA box. I thought wrong.
Within ASDM it is possible to manage and upgrade the FP module. The first thing to stick out is the fact that ASDM on numerous occasions couldn’t contact the FP module. So after serveral tries I was able to manage the module from ASDM.
According to the Cisco manual it is possible to download the updates from within the ASDM. But after several tries and a lot of error messages I gave up on ASDM. So then there is only one solution. Go back to the good old CLI!

First of all I had to get the image file to the ASA box.This time I used a http server, the code looks like beneath:

Firewall# copy <interface> http flash:
Address or name of remote host []? <ip address>
Source filename []? asasfr-5500x-boot-6.0.0-1005.img
Destination filename [asasfr-5500x-boot-6.0.0-1005.img]? 

Now the FP module has to be rebooted with a new image, this can be done from the ASA cli:

Firewall(config)# sw-module module sfr recover configure image disk0:/asasf$
Firewall(config)# sw module sfr recover boot
Module sfr will be recovered. This may erase all configuration and all data
on that device and attempt to download/install a new image for it. This may take
several minutes.

Recover module sfr? [confirm]
Recover issued for module sfr. 

To monitor what’s going on, you have to enable debugging:

Firewall(config)# debug module-boot
debug module-boot  enabled at level 1

This step will take a while. I waited for about 20 minutes. After that you have to configure the FP module again. So login to the module and run the setup:

Firewall(config)# session sfr console 
Opening console session with module sfr.
Connected to module sfr. Escape character sequence is 'CTRL-^X'.


Cisco FirePOWER Services Boot Image 6.0.0

asasfr login: admin
Password: Admin123


Cisco FirePOWER Services Boot 6.0.0 (1005)
Type ? for list of commands
asasfr-boot>setup


Welcome to Cisco FirePOWER Services Setup 
 [hit Ctrl-C to abort]
Default values are inside []

Enter a hostname [asasfr]: <Name>
Do you want to configure IPv4 address on management interface?(y/n) [Y]: Y
Do you want to enable DHCP for IPv4 address assignment on management interface?(y/n) [N]: N
Enter an IPv4 address [192.168.8.8]: <IP address>
Enter the netmask [255.255.255.0]: <Netmask>
Enter the gateway [192.168.8.1]: <Default Gateway>
Do you want to configure static IPv6 address on management interface?(y/n) [N]: N
Stateless autoconfiguration will be enabled for IPv6 addresses.
Enter the primary DNS server IP address: <DNS server>
Do you want to configure Secondary DNS Server? (y/n) [n]: N
Do you want to configure Local Domain Name? (y/n) [n]: Y
Enter the local domain name: <domain name>
Do you want to configure Search domains? (y/n) [n]: Y
Enter the comma separated list for search domains: <Domain name>
Do you want to enable the NTP service? [Y]: Y
Enter the NTP servers separated by commas: <NTP pool>
Do you want to enable the NTP symmetric key authentication? [N]: N
Please review the final configuration:


Hostname:Firewall
Management Interface Configuration

IPv4 Configuration:static
IP Address:<IP address>
Netmask:<Netmask>
Gateway:<Default Gateway>

IPv6 Configuration:Stateless autoconfiguration

DNS Configuration:
Domain:<Domain>
Search:<Domain>
DNS Server:<DNS server>
NTP configuration: <NTP pool>
CAUTION:
You have selected IPv6 stateless autoconfiguration, which assigns a global address
based on network prefix and a device identifier. Although this address is unlikely
to change, if it does change, the system will stop functioning correctly.
We suggest you use static addressing instead.

Apply the changes?(y,n) [Y]: Y
Configuration saved successfully!
Applying...
Restarting network services...
Restarting NTP service...
Done.
Press ENTER to continue...{Enter}


After the previous step it’s time to get the new FP version on the FP module:

asasfr-boot>system install http://<ip address>/asasfr-sys-6.0.0-1005.pkg
   
Verifying.    .. 
Downloading.    ..   
Extracting.    ..  
Package Detail
Description:Cisco ASA-SFR 6.0.0-1005 System Install
Requires reboot:Yes 

Do you want to continue with upgrade? [y]: Y
Warning: Please do not interrupt the process or turn off the system.
Doing so might leave system in unusable state.


This really takes al long time. So don’t forget if you are performing this upgrade in a production environment to get an updateslot of at least three hours!
In my case it took 100 minutes before the FP module was in the UP state again.

Now you have to accept the new EULA en go trough the initial setup again.


Firewall# session sfr 
Opening command session with module sfr.
Connected to module sfr. Escape character sequence is 'CTRL-^X'.


Cisco ASA5506 v6.0.0 (build 1005)

firepower login: admin
Password: Admin123
Last login: Wed Nov  2 16:08:16 UTC 2016 on pts/0

Copyright 2004-2015, Cisco and/or its affiliates. All rights reserved. 
Cisco is a registered trademark of Cisco Systems, Inc. 
All other trademarks are property of their respective owners.

Cisco Fire Linux OS v6.0.0 (build 258)
Cisco ASA5506 v6.0.0 (build 1005)

Last login: Wed Nov  2 16:08:16 UTC 2016 on cron
Last login: Wed Nov  2 16:08:16 UTC 2016 on pts/0
You must accept the EULA to continue.
Press  to display the EULA: {Enter}
END USER LICENSE AGREEMENT

IMPORTANT: PLEASE READ THIS END USER LICENSE AGREEMENT CAREFULLY.  IT IS VERY
IMPORTANT THAT YOU CHECK THAT YOU ARE PURCHASING CISCO SOFTWARE OR EQUIPMENT
FROM AN APPROVED SOURCE AND THAT YOU, OR THE ENTITY YOU REPRESENT
(COLLECTIVELY, THE "CUSTOMER") HAVE BEEN REGISTERED AS THE END USER FOR THE

--Output Removed for the Sake of Brevity - Press Space Bar (A LOT!)--

Please enter 'YES' or press  to AGREE to the EULA:  YES

System initialization in progress.  Please stand by.  
You must change the password for 'admin' to continue.
Enter new password: Password123
Confirm new password: Password123
You must configure the network to continue.
You must configure at least one of IPv4 or IPv6.
Do you want to configure IPv4? (y/n) [y]: Y
Do you want to configure IPv6? (y/n) [n]: N
Configure IPv4 via DHCP or manually? (dhcp/manual) [manual]: {Enter}
Enter an IPv4 address for the management interface [192.168.45.45]: 
Enter an IPv4 netmask for the management interface [255.255.255.0]: 
Enter the IPv4 default gateway for the management interface []: 
Enter a fully qualified hostname for this system [firepower]: 
Enter a comma-separated list of DNS servers or 'none' []: 
Enter a comma-separated list of search domains or 'none' [example.net]: 
If your networking information has changed, you will need to reconnect.

For HTTP Proxy configuration, run 'configure network http-proxy'

Creating default Identity Policy.
Creating default SSL Policy.

Update policy deployment information
    - add device configuration
    - add network discovery
    - add system policy
    - add access control policy
    - applying access control policy

You can register the sensor to a Firepower Management Center and use the 
Firepower Management Center to manage it. Note that registering the sensor 
to a Firepower Management Center disables on-sensor Firepower Services 
management capabilities.

When registering the sensor to a Firepower Management Center, a unique 
alphanumeric registration key is always required.  In most cases, to register
a sensor to a Firepower Management Center, you must provide the hostname or 
the IP address along with the registration key.
'configure manager add [hostname | ip address ] [registration key ]'

However, if the sensor and the Firepower Management Center are separated by a
NAT device, you must enter a unique NAT ID, along with the unique registration
key.
'configure manager add DONTRESOLVE [registration key ] [ NAT ID ]'

Later, using the web interface on the Firepower Management Center, you must 
use the same registration key and, if necessary, the same NAT ID when you add 
this sensor to the Firepower Management Center.
> exit
Remote card closed command session. Press any key to continue.
 Command session with module sfr terminated.

Now login to your ASA via ASDM and you will see that your box is upgraded.

Advertisements

Backup ASA config with PowerShell

During my years in the networking business one of my frustrations is that it is very hard to backup the configuration of an ASA. There are some commercial products like Solarwinds that can accomplish this goal, but it costs money. An open source alternative like Rancid is also available but is pretty hard to configure.
Determined to find a solution I started searching the internet and came across some PowerShell scripts.  I’m not a PowerShell specialist, but I do know how to put together the separate scripts. So to be clear, I did not invent the scipts I just put them together.

So let’s take a look at the script:

Read-Host  “Enter Password” -AsSecureString | ConvertFrom-SecureString | Out-File c:\<map>\cred01.txt
–I don’t want to sent the password of the ASA user plain over the network. So with the above line I make sure the password is encrypted. It is possible to convert the password back to plain text, but then you’ll need access to the server. So it is not rocksollid save, but safer then sending the password in plain text over the internet. If you make sure that the useraccount only has minimal rights on the ASA, there is minimal change of getting unwanted guests on your ASA. The line converts the plain password to an encrypted password and writes it to a .txt file.

$ASApw = Get-Content “c:\<map>\cred01.txt” | ConvertTo-SecureString #-AsPlainText #-Force
$BSTR = [System.Runtime.InteropServices.Marshal]::SecureStringToBSTR($ASApw)
$ASApw = [System.Runtime.InteropServices.Marshal]::PtrToStringAuto($BSTR)
–The above three lines are needed to convert the encrypted password from the credentials file. This is needed because the ASA is unable to read an encrypted password.

$ASAIP = “<ip address>”
$ASAUser = “<username>”
$ASAEnablepw = $ASApw

#Modifies the ASA firewall
#Starts by writing a “commands” file#
echo en >>unicode.txt
echo $ASAEnablepw >>unicode.txt
echo “conf t” >>unicode.txt
echo “no pager” >>unicode.txt
echo “show run” >>unicode.txt
echo “pager 24” >>unicode.txt
echo “copy running-config startup-config” >>unicode.txt
echo “running-config” >>unicode.txt
echo exit >>unicode.txt
echo exit >>unicode.txt

#Converts the file to ASCII format (separate file)#
$lines = gc “unicode.txt”
$lines | out-file -encoding Ascii -filepath commands.txt
–The above lines writes the actual ASA commands to the commands.txt file.

#Using the command file and plink.exe connects and runs the commands#
c:/Windows/System32/plink.exe -ssh -l $ASAUser -pw $ASApw $ASAIP -m commands.txt > “c:\<map>\ASA.txt”
–To make things work you need to download the Plink tool. It is the command line version of Putty. It can be downloaded for free. I put the tool in de c:\windows\system32 folder, but you can place it everywhere you want. This line writes the configuration of the ASA to an .txt file.

#removes the files it created earlier#
del unicode.txt
del commands.txt

As you can see it’s actually a pretty easy script an above all it’s free.
To make a daily backup, create a task through “Task scheduler”.

GRE over IPsec tunnels (Part 2)

In my last post I wrote about GRE over IPsec, but only with static routes. One of the benefits of GRE over IPsec tunnels is that you can send multicast traffic  over the tunnel. With a plain IPsec tunnel this is not possible. So to prove that multicast traffic can cross the GRE over IPsec tunnel I took the topology of my last post and removed the static routes from the configuration of the HQ and Branch routers.
Below the used topology:
GRE_over_IPsec

Then configure the EIGRP configuration on both routers.

R1#sh run | se eigrp
router eigrp 10
network 10.10.10.0 0.0.0.255
network 172.18.2.0 0.0.0.255
no auto-summary
R1#

The syslog below confirms that the EIGRP adjacency is up and running:
EIGRP_adj

Then use the “debug ip packet detail” command to verify that multicast is used and allowed:
EIGRP_multicast

To prove the solution is working check the routing table.
sh_ip_route

And that’s all there to configure dynamic routing over a GRE over IPsec tunnel.

GRE over IPsec tunnels (Part 1)

Why a IPsec over a GRE tunnel? A couple of things come to mind. Things like encryption of tunneled traffic and the possibility to send multicast traffic over the tunnel.

GRE on itself only tunnels traffic by encsapsulating the traffic within an additional GRE and IP header. But if you Wireshark the traffic it’s just plain text and therefore readable. In a plain IPsec tunnel it is not possible to send multicast traffic over the IPsec tunnel. But if you’re using OSPF or EIGRP you need to be able to send multicast traffic over the IPsec tunnel.

To prove the above I created a case study. First I will show how to configure a normal GRE tunnel, after that a GRE over IPsec tunnel with static routes. In a separate post I will write about GRE over IPsec tunnel with dynamic routing.

So for this case study I used the topology as shown below.

GRE_over_IPsec

Below the configuration of the HQ router, the branch router is the same but use different IP addresses.

First configure the physical internet facing interface, the vlan interface for the internal subnet and the needed routes.

!
interface FastEthernet1/0
ip address 109.232.100.1 255.255.255.0
duplex auto
speed auto
!
!
interface Vlan10
ip address 10.10.10.1 255.255.255.0
!
ip route 10.10.11.0 255.255.255.0 172.18.2.1
!

Then create the tunnel interface

!
interface Tunnel0
ip address 172.18.2.2 255.255.255.0
ip mtu 1400
tunnel source FastEthernet1/0
tunnel destination 109.232.100.2
!
Don’t forget to change the MTU size to 1400, because of the overhead created by the GRE encapsulation.

Now it’s possible to ping from PC1 at HQ to PC3 at the bracnch office. If you look at the traffic you will see it’s encapsulated in a GRE packet, but there is no encryption:
GRE_capture

To create an IPsec connection do the following on the HQ and Branch routers:
!
crypto isakmp policy 1
authentication pre-share
crypto isakmp key sjiekismiechdat address 109.232.100.2
!
!
crypto ipsec transform-set test esp-3des esp-md5-hmac
!
!
access-list 101 permit gre host 109.232.100.1 host 109.232.100.2
!
!
crypto map s-2-s 10 ipsec-isakmp
set peer 109.232.100.2
set transform-set test
match address 101
!
!
interface Tunnel0
crypto map s-2-s
!
!
interface FastEthernet1/0
crypto map s-2-s
!

Now send some traffic from PC1 to PC3 and use the “show crypto session” command to verify that the GRE over IPsec connection is established:
crypto_session

Now we know the tunnel is up and it’s possible to exchange traffic between PC1 at the HQ and PC3 at the branch office. Now let’s look at the traffic with Wireshark.
ESP

As you can see there are only ESP packets, in other words the encryption of the IPsec tunnel is working.

In my next post I will talk about dynamic routing with GRE over IPsec.

 

Private vlan’s

This blogpost is about private vlan’s. For  my CCIE study I looked into PVLAN’s. First some terminology. When working with PVLAN’s words like primary vlan, secondary vlan, promiscuous port, isolated port and community port have to sound familiar. If not check the following summary:

  • Primary VLAN: Original vlan, used to forward the actual traffic
  • Secondary VLAN: is configured with one of the following types Isolated or Community
  • Isolated port: A switch port configured as Isolated is only able to communicate with the promiscuous port. It is not able to reach any other destination!
  • Community port: A switchport configured as Community is able to communicate with a server in the same community vlan and the promiscuous port. A community port is not able to communicate with an isolated port.

Below a drawing which describes the above summary.

PVLAN

In the configuration below two laptops are configured in an isolated vlan. Therefor they won’t be able to communicate with each other, but they are able to communicate with the promiscuous port.

PVLAN_isolated

 

In the next configuration the two laptops are configured in a community vlan. because of that they are able to ping each other.

PVLAN_community

 

As you probably noticed, the only configuration change is that the private-vlan host-association changed.

Private vlan’s are very useful to large ISP, because with isolated ports it’s possible to use the same subnets. There is virtually no limit to the number of customers and only one firewall is needed for a lot of customers. The only limiting option is the throughput of the used firewall!

 

** to build this topology I used a Cisco 3560 switch and a Cisco ASA 5505 firewall

Port Access-Lists (PACL)

A while ago I blogged about VACL or Vlan Access-Lists. PACL and VACL are really connected to each other. In this blogpost I will show you how PACL works and how to configure it on a Cisco switch.

First of all, what is PACL. PACL makes it possible to filter incoming traffic on a layer 2 interface using layer 3 or 4 information.

First some restrictions on PACL

  • There can only be one ACL applied to a layer 2 interface per direction
  • PACL don’t filter later 2 traffic like CDP, VTP, DTP, UDLD and STP because this traffic is handled by the Route Processor before the applied ACL takes effect
  • The number of ACL’s that can be configured as part of the PACL configuration is bounded by the hardware resources of the switch
  • A MAC ACL is not applied to IP, MPLS or ARP messages
  • Only named MAC ACL can be used

I spoke earlier about the interaction between PACL and VACL. When they are both used on the switch and the traffic is bridged, PACL will always be applied before VACL’s. PACL will even override a “normal” ACL that is applied to the same interface (for this situation is only one exception, if packets are forewarded in software by the RP. If this is true an ” normal” ACL will take precedence over the PACL). Summarizing the above:

  • PACL for the ingress port
  • VACL for the egress vlan
  • VACL vfor the egress vlan

Below a schematic of this.

*PACL_bridged

It’s fairly easy to configure this, below an example of my lab and how to configure this:

topology

PACL_portconfig

PACL_acl

 

It’s a little different when the traffic is routed. The next is true for routed packets:

  • PACL for the ingress port
  • VACL for the ingress vlan
  • Input Cisco IOS ACL
  • Output Cisco IOS ACL
  • VACL for the egress vlan

Below a schematic of the above:

*PACL_routed

 

PACL can come in handy when you want to deny access of a PC/Server to another PC/Server in the same vlan and you can’t change the vlan of the machines.

 

More information on this topic can be found on the Cisco site (http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SY/configuration/guide/sy_swcg/port_acls.pdf).
*=I found the used schematics on the Cisco site and borrowed them!

Protect your network against HSRP attacks!

As in my earlier post, I’m writing a series of postings to help protect your network against attacks. A good hacker will always find a way to hurt your network. But with the recommendations described in this series of postings it will be more difficult for the hacker to find a way in.

In this post I will describe the hacking of HSRP operations and off course I will describe a solution to this problem.

As always I use GNS3. Below the topology and the configuration of multilayer switch R2.
topology

R2
!
interface FastEthernet0/0
switchport mode trunk
!
interface FastEthernet0/5
switchport access vlan 13
no cdp enable
!
interface Vlan10
ip address 10.0.0.253 255.255.255.0
standby 10 ip 10.0.0.254
!
interface Vlan11
ip address 172.18.100.253 255.255.255.0
standby 11 ip 172.18.100.254
!
interface Vlan12
ip address 192.168.157.253 255.255.255.0
standby 12 ip 192.168.157.254
!
interface Vlan13
ip address 192.168.80.253 255.255.255.0
standby 13 ip 192.168.80.254
!

HSRP
The cisco.com website explains HSRP as follows:

“HSRP is Cisco’s standard method of providing high network availability by providing first-hop redundancy for IP hosts on an IEEE 802 LAN configured with a default gateway IP address. HSRP routes IP traffic without relying on the availability of any single router. It enables a set of router interfaces to work together to present the appearance of a single virtual router or default gateway to the hosts on a LAN. When HSRP is configured on a network or segment, it provides a virtual Media Access Control (MAC) address and an IP address that is shared among a group of configured routers. HSRP allows two or more HSRP-configured routers to use the MAC address and IP network address of a virtual router. The virtual router does not exist; it represents the common target for routers that are configured to provide backup to each other. One of the routers is selected to be the active router and another to be the standby router, which assumes control of the group MAC address and IP address should the designated active router fail.”

So in short, HSRP provides a virtual default gateway. And that’s the problem, when someone or something finds a way to hack into the HSRP operations it is possible to change the default gateway and reroute networktraffic or blackhole the networktraffic. This turns out to be very simple with Kali. Below a simple explanation how to change the behaviour of HSRP operations.

Start Kali, start yersinia, click the HSRP tab, choose to become active router, give in an ip address and that’s al there is:
hsrp_att

hsrp ip

 

When you have enable terminal monitor on your switch, you’ll see a state change
state change
Now check the HSRP settings with “show standby vlan 13” and you’ll see that the gateway has changed to 10.10.10.10
sh stand vlan 13

When you look closer to the config you’ll notice something else:
config change
For Yersinia to be able to take over the HSRP operations, it alters the config by entering a static entry to the mac address table!

Again this al there is to! To prevent this, make sure u use authetication on your HSRP interfaces as described in the following example:

First create a key-chain
key chain

 

Then configure the authentication on the vlan interface. If your are in a production network. First configure the standby unit, then the active unit. Otherwise the actions are disruptive!

 

stand auth

Now try the HSRP attack again and you’ll see it will not work this time!
stand vlan 13 auth

 

And to make it even more clear, when terminal monitor is enabled you’ll get the message depicted in the picture below
bad auth