ASA Failover and Redundancy

The following must be identical:

  1. Model (5505 or 5510 or 5520, etc)
  2. Amount of RAM
  3. Number of Interfaces (should be the same type as well)
  4. External Modules (CSC-SSM or IPS-SSM)
  5. Activation key with the same features
  • Failover mode
  • Encryption Level
  • Number of VPN peers

*** Same size Flash is not required ****


Active -> Responsibel for creating the state and translation tables, transferring the data packets and monitoring the other units.

Standby -> reponsible for monitoring the status of the active unit

The active and standby units are connected through a dedicated network link and send failover-related messages to each other. This connection, known as theFAILOVER CONTROL LINK is established over a dedicated failover LAN interface.

*** When failover occurs, the standby unit takes over the IP and MAC address that were used by the previous unit


  • Unit state (active or standby)
  • Network link status
  • Hello or keepalive messages (which are sent on all interfaces. This protocol uses IP 105)
  • MAC address exchange
  • Configuration replication from the active to standby

Conditions that trigger failover:

  • – Administrator has manually switched over from active to standby

-> “no failover active” on the active unit

-> “failover active” on the standby unit

  • – Active unit has lost power or crashed due to a hardware or software defect
  • – Standby unit has stopped receiving hello (or keepalive) packets on the failover interface
  • If 3 consecutive hello packets are missed, additional testing packets are sent to the remaining data-passing interfaces. If it still does not receive a response from the active unit, it assumes that a failure has occured and takes over
  • – The failover control link is down
  • The ASA sends additional testing packets to the remaining interfaces to determine where the peer’s control interface is also down. If the peer’s control interface is also down, then failover does not occure and the failed interface is marked as “Failed”. However, if the peer’s control interface is not down, then failover occurs because the standby unit is deemed healthier than the current active.
  • – The link state of the data-passing interface is down
  • The ASA marks the interface as “Failed” and initiates the failover process. Additionally, if the standby unit does not receive the hello packets for two consecutive polling period on an interface, the appliance goes through a series of additional tests on the interface to determine the root cause of the problem



  1. Link up/down tests -> status of the NIC. For example hardware port failure, unplugged cable and a failure on the hub or switch to which the interfaces are connected
  2. Network Activity Test -> All packets received are counted for up to 5 seconds. If any packets are received, the interface is marked as operational
  3. ARP Test -> ARP table is read for the last 10 entries. It sends an ARP request to those machines one at a time and then counts packets for up to 5 seconds. If any packets are received, the interface is marked as operational
  4. Broadcast Ping Test -> Sends a broadcast ping request and then counts all received packets for up to 5 seconds. If any packets are received, the interface is operational.

*** If both active and standby interfaces fail all tests, then both interfaces go into the “unknown state”. The interface with the unknown state do not count toward the monitored inteface failover limit ***

CONNECTION TABLE: Connection entries include the source and destination IP address, protocol used, current state of the connection, the interface to which it is tied and the number of bytes transferred.

In stateful failover, the active unit sends updates to the standby unit whenever these is a change in the state table. In this mode, the active unit sends stateful updates over a dedicated link to the the standby unit. When the standby unit becomes active, it does not need to build any connection entries because all the entries already exist in its database.

*** You can use the same physical interface for both failover control and stateful link. However it is not recommended if your appliances generate a lot of state updates. Additionally, it is recommended that you use the fastest interface as the stateful link and that the latency for the link should be less than 10 ms to avoid performance degradation. ****

What is not replicated in stateful failover:

  1. Uauth cache
  2. URL Filtering cache
  3. TCP Intercept
  4. SNMP Firewall MIB
  5. Routing Table
  6. State Info for SSM
  7. Phone Proxy sessions
  8. IPv6 sessions

Types of failover -> Device-level failover and interface-level failover

Device-level failover -> Active/Standby and Active/Active

Active/Standby Failover:

  • Active unit passes traffic
  • Standby unit monitors active unit
  • Both units send hello messages to monitor each other’s state



  1. When both are up and running, one unit assumes the role of active while the other unit assumes the standby role
  2. If both units boot up simultenously, the primary unit takes over the active role and the secondary goes into standby. The primary unit uses the active IP address and its MAC address as the Layer 3 and Layer 2 respectively. If failover occurs, the secondary keeps using the IP address and the primary’s MAC addrss as the active
  3. If one of the units boots up and detects an active failover unit, it goes into standby regardless of the primary or secondary designation
  4. If one of the units boots up and doesn’t detect an active failover unit, it goes into the active state regardless of its primary or secondary designation
  5. In case both appliances become active, the secondary changes its state to standby as soon as it discovers another active primary firewall while the primary remains active
  6. In case both units become standby, the primary changes its state to active, while the secondary remains standby after they detect each other’s state


  • Both units pass traffic actively
  • Only supported in multimode
  • Needs at least two user context to work properly
  • With stateful failover, both stand connection tables are replicated
  • Uses per-failover groups instead of per-context

**** It is recommended that you don’t oversubscribe the firewalls in active/active failover as during failover, one of the units has to pass all traffic

In active/active failover, it is possible that packets can leave one active unit and can return to the other active unit. The ASA implements a feature known as “asymmetric routing” to guide packets back to the context from which they originated.


  • Multiple ISPs or remote locations
  • Load-balancing or backup
  • ** only supported in multimode

If the asymmetric routing feature is enabled, the units restore asymmetric routed packets to the correct interface. The unit that sent the original SYN packet will replicate the connection table entry for the SYN packet to the standby unit over the stateful failover link. When the standby unit receives a packet but does not have an active connection, it checks other interfaces that are in the same asymmetric routing group for the corresponding connection. The Layer 2 information is written and forwarded to the original unit.


During traditional device-level failover, traffic gets disrupted even when stateful failover is enabled.


  • All incomplete TCP sessions
  • Routing tables (OSPF, RIP, EIGRP, etc)
  • Most Inspection Engines

Interface-level failover is used to avoid device-level switchover which is much more disruptive

Redundant interfaces are only supported in version 8.0 and higher.


  • All interfaces supported except Ma0/0 or Ma0/1
  • Up to 8 redundant interfaces
  • Network-related commands go on the redundant interface (nameif, security-level, IP address, etc)
  • Speed, duplex and shutdown go on the physical inteface
  • Link status for the physical is monitored by default
  • The standby interface drops all inbound packets and does not send any outbound packets
  • Interface stats on the redundant interface are a summation of the active and standby interfaces. As soon as a physical interface becomes a member of the redundant interface, its interface stats are cleared
  • Redundant interfaces use the MAC address of the first member physical interface unless you are manaully assigning a unique virtual MAC address on the redundant interface
  • *** The physical interfaces in the redundant interface must both be of the same physical type

*** The redundant interfaces can be configured with or without device-level failover


  1. Select the failover link
  2. Assign failover IP address
  3. Set the failover key (optional)
  4. Designate the primary unit
  5. Enable the stateful failover (optional)
  6. Enable failover globally
  7. Configure failover on the secondary unit

*** There can’t be a “nameif” command on an interface when configuring failover on it. Also “managment-only” needs to be removed.

You can use the “failover exec” command to send commands to the correct unit.

Failover link is used for failover control messages

*** If a failover key is not used, the active appliance sends all information in clear text, including the TCP/UDP states, the user credentials and VPN-related information.

You must designate the primary and secondary status through software configureation

If you want to use the failover control interface as the stateful failover link, use the “failover link” command without specifying the physical interface


Enable the failover control interface

“no shutdown”

Failover designation as secondary

“failover lan unit secondary”

  • Failover link interace
  • “failover lan interface failover Gi0/1”
  • Same failover interface IP addresses
  • “failover interface ip failover standby”
  • Same failover shared key
  • “failover key cisco 123”
  • Failover enable (enabled globally)
  • “failover”



  • Select the failover link
  • Assign failover interface IP addresses
  • Set the failover key (optional)
  • Desginate the primary unit
  • Enable stateful failover (optional)
  • Set up failover group
  • Assign failover-group membership
  • “join-failover-group”
  • Assign interface IP addresses
  • Set up asymmetric routing (optional)
  • Enable failover globally
  • Configure failover on the secondary

**** Connection and translation tables are sent over the stateful failover link. So is the asymmetric routing updates


  • Interface-policy
  • MAC address
  • polltime
  • Preempt
  • Primary
  • Replication
  • Secondary

**** You must enable HTTP inspection to allow the HTTP traffic to work in the Active/Active setup with asymmetric routing

*** The Admin context is always a part of failover group 1. If you don’t explicitly map a context to a failover group, then it is automatically assigned to group 1.

*** The “http replication” command in the failover group overrides the global “http replication” command


Specify failover MAC address – in Active/Active failover, during failover, the IP addresses ad MAC addresses are swapped between units. The new active unit sends out a gratuitous ARP on the network. Using gratuitious ARP, the Layer 2 devices including bridges and switches, also update the CAM tables with the MAC address and the updated switch port information. The use of virtual MAC addresses is useful to avoid disruptions. With the virtual MAC address, the appliances do not need to swap the MAC address.


  • Use the virtual MAC cofigured on the interfaces (physical, logical or subinterface)
  • Use the “failover mac address ” configured globally
  • Use the burned-in MAC address


  • Use the virtual MAC at the interface level (physical, logical or subinterface)
  • Use the “mac address” in the failover group configuration mode
  • Use the “mac address auto” in the System Execution Space
  • Use the burned-in MAC on the physical interface

**** In Active/Active setup, the failover “mac address” command has no effect if issues in the global configuration mode


  • Status of all interfaces monitored
  • If one of the interfaces fails to repsond, failover occurs

If you want to change this behavior, use the “criteria” tab in the ASDM

*** This setting is applied to the failover group in Active/Active


By default, ASA sends periodic keepalives (hello) packets to check the status of the peer failover unit. If the standby unit does not receive acknowledgement packets for the keepalives sent out, it initiates a failover only if it deems itself healthier than the current unit.

Two types of failover hello messages -> Unit (sent every second)

-> Interface (every 15 seconds)

In active/active failover, unit failover timers are changed in the System Execution Space. The interface failover timers are changed in the failover group policy.

*** When an ASA is configured for failover, whether active/standby or active/active, it monitors the status of all the main physical interfaces that have a “nameif” and an IP address configured.

*** Interface monitoring is disabled by default on all subinterfaces until you explicitly enable it.

*** Stateful failover is mandatory for a zero-downtime software upgrade.


Cisco ASA Firewall Active / Standby Failover

The Cisco ASA firewall is often an important device in the network. We use it for (remote access) VPNs, NAT/PAT, filtering and more. Since it’s such an important device it’s a good idea to have a second ASA in case the first one fails.

The ASA supports active/standby failover which means one ASA becomes the active device, it handles everything while the backup ASA is the standby device. It doesn’t do anything unless the active ASA fails.

The failover mechanism is stateful which means that the active ASA sends all stateful connection information state to the standby ASA. This includes TCP/UDP states, NAT translation tables, ARP table, VPN information and more.

When the active ASA fails, the standby ASA will take over and since it has all connection information, your users won’t notice anything…

There are a number of requirements if you want to use failover:

  • Platform has to be the same: for example 2x ASA 5510 or 2x ASA 5520.
  • Hardware must be the same: same number and type of interfaces. Flash memory and RAM has to be the same.
  • Same operating mode: routed or transparent mode and single or multiple context mode.
  • License has to be the same..number of VPN peers, encryption supported, etc.
  • Correct license. Some of the “lower” models require the Security Plus license for failover (the ASA 5510 is an example).

In this lesson we’ll take a look how to configure active/standby failover. Here’s the topology I will use:

ASA1 ASA2 Active Standby Failover

We have two ASA firewalls…ASA1 and ASA2. ASA1 will be the active firewall and ASA2 will be in standby mode. Their Ethernet 0/0 interfaces are connected to the “INSIDE” security zone while the Ethernet 0/1 interfaces are connected to the “OUTSIDE” security zone. The Ethernet 0/3 interface in the middle will be used to synchronize connection information for failover. R1 and R2 are only used so we can generate some traffic.


We will start with the failover interface on ASA1. Make sure it’s not shut:

ASA1(config)# interface Ethernet 0/3
ASA1(config-if)# no shutdown

And then we configure this ASA to be the active (primary) device:

ASA1(config)# failover lan unit primary

Now we will configure Ethernet 0/3 to be the failover interface:

ASA1(config)# failover lan interface FAILOVER Ethernet 0/3 
INFO: Non-failover interface config is cleared on Ethernet0/3 and its sub-interfaces

And we’ll tell the ASA to use this interface for stateful failover:

ASA1(config)# failover link FAILOVER Ethernet 0/3

We can now configure the IP addresses on the failover interface. We need to use a dedicated subnet for this:

ASA1(config)# failover interface ip FAILOVER standby

ASA1 (active) will use IP address and ASA2 (standby) will use Now we can enable failover:

ASA1(config)# failover

Failover is now configured on ASA1. Let’s configure some security zones and IP addresses on the “normal” Interfaces:

ASA1(config)# interface Ethernet 0/0
ASA1(config-if)# no shutdown
ASA1(config-if)# nameif INSIDE
ASA1(config-if)# ip address standby
ASA1(config)# interface Ethernet 0/1
ASA1(config-if)# nameif OUTSIDE
ASA1(config-if)# ip address standby

The ASA requires something that triggers the failover mechanism. An interface that fails is a good trigger. When the inside or outside interface fails, we should failover. By default all physical interfaces are monitored but let me show you the command anyway:

ASA1(config)# monitor-interface INSIDE
ASA1(config)# monitor-interface OUTSIDE

This is all we have to configure. We can now configure ASA2:

ASA2(config)# failover lan unit secondary
ASA2(config)# failover lan interface FAILOVER Ethernet 0/3
ASA2(config)# failover link FAILOVER Ethernet 0/3
ASA2(config)# failover interface ip FAILOVER standby
ASA2(config)# failover

We configure ASA2 to be the standby device, its Ethernet 0/3 interface will be used for failover and we configure the active and standby IP addresses. Let’s enable this interface so that the ASA’s can talk with each other:

ASA2(config)# interface Ethernet 0/3
ASA2(config-if)# no shutdown

This is what you will see on ASA1 and ASA2:

Beginning configuration replication: Sending to mate.
End Configuration Replication to mate
Failover LAN became OK
Switchover enabled
Configuration has changed, replicate to mate.

State check detected an Active mate
Beginning configuration replication from mate.
End configuration replication from mate.

Switching to Standby

Failover is up and running, the configuration has been replicated from ASA1 to ASA2. Whenever you make changes to the configuration, you only have to save on the active ASA and it will be replicated to the standby ASA:

ASA1# write memory 
Building configuration...
Cryptochecksum: 690a4de8 e1179377 f8eabae6 8cf5242e 

3372 bytes copied in 3.240 secs (1124 bytes/sec)

After saving the configuration you will see this on the standby ASA:

ASA1# Cryptochecksum: 5739e8f7 32355bc0 a97e7dfa dd54ad71 

3373 bytes copied in 3.240 secs (1124 bytes/sec)

Let’s see if failover is really working shall we?


A simple method to verify if its working is to check the show failover command:

ASA1# show failover 
Failover On 
Failover unit Primary
Failover LAN Interface: FAILOVER Ethernet0/3 (up)
Unit Poll frequency 1 seconds, holdtime 15 seconds
Interface Poll frequency 5 seconds, holdtime 25 seconds
Interface Policy 1
Monitored Interfaces 2 of 110 maximum
Version: Ours 9.1(5), Mate 9.1(5)
Last Failover at: 12:23:34 UTC Dec 19 2014
	This host: Primary - Active 
		Active time: 1664 (sec)
		slot 0: ASA5510 hw/sw rev (2.0/9.1(5)) status (Up Sys)
		  Interface INSIDE ( Normal (Monitored)
		  Interface OUTSIDE ( Normal (Monitored)
		slot 1: empty
	Other host: Secondary - Standby Ready 
		Active time: 31 (sec)
		slot 0: ASA5510 hw/sw rev (1.1/9.1(5)) status (Up Sys)
		  Interface INSIDE ( Normal (Monitored)
		  Interface OUTSIDE ( Normal (Monitored)
		slot 1: empty

Stateful Failover Logical Update Statistics
	Link : FAILOVER Ethernet0/3 (up)
	Stateful Obj 	xmit       xerr       rcv        rerr      
        General		90         0          89         0         
        sys cmd  	89         0          89         0         
        up time  	0          0          0          0         
        RPC services  	0          0          0          0         
        TCP conn 	0          0          0          0         
        UDP conn 	0          0          0          0         
        ARP tbl  	0          0          0          0         
        Xlate_Timeout  	0          0          0          0         
        IPv6 ND tbl  	0          0          0          0         
        VPN IKEv1 SA 	0          0          0          0         
        VPN IKEv1 P2 	0          0          0          0         
        VPN IKEv2 SA 	0          0          0          0         
        VPN IKEv2 P2 	0          0          0          0         
        VPN CTCP upd 	0          0          0          0         
        VPN SDI upd 	0          0          0          0         
        VPN DHCP upd 	0          0          0          0         
        SIP Session 	0          0          0          0         
        Route Session 	0          0          0          0         
        User-Identity 	1          0          0          0         
        CTS SGTNAME 	0          0          0          0         
        CTS PAC 	0          0          0          0         
        TrustSec-SXP 	0          0          0          0         
        IPv6 Route 	0          0          0          0         
        Logical Update Queue Information
                 	Cur 	Max 	Total
        Recv Q: 	0 	2 	91
        Xmit Q: 	0 	25 	482

This gives us a nice overview, you can see which device is active/standby but also what kind of stateful information is being exchanged. Let’s create some telnet traffic between R1 and R2 so that you can see that the firewalls are exchanging TCP connection information:

Trying ... Open

User Access Verification



When we check the show failover command again you will see this:

ASA1# show failover | include TCP
	TCP conn 	5          0          0          0

The connection information for my TCP session has been exchanged between the two ASAs. To really test our failover, we have to simulate a link failure. I’ll shut the interface on my switch that connects to the Ethernet 0/0 interface of ASA1:

SW1(config)#interface FastEthernet 0/14

Now you will see this on the active ASA:

Switching to Standby

And the standby ASA will tell us:

Switching to Active

Of course we can also check the show failover command again:

ASA1# show failover | include This host
	This host: Primary - Failed
ASA1# show failover | include This host
	This host: Secondary - Active

This proves that failover is working as it should, the standby ASA has become active after the link failure.

Active/standby failover does not use preemption. Once you enable the interface again, the currently active ASA will remain active.

That’s all there is for now! I hope you enjoyed this lesson, if you have any questions…feel free to leave a comment!

Martian Packet Messages

Occasionally, you might see messages like the following in your Linux kernel messages:

martian source from, on dev eth1<br />
        ll header: 52:54:00:98:99:d0:52:54:00:de:d8:10:08:00

There’s a lot of discussion out there about what this means, but not a lot about how to trace down the source.  Hopefully this will provide some insight into what the messages actually mean, and how to understand them.

What are martian packets?

A martian packet is one that comes from an “impossible source”.  For example, this might be from an RFC 1918 reserved netblock routed across the internet, or any packet with a “localnet” (, etc.) IP on an interface other than the loopback interface.  In other words, martian packets mean either something is misconfigured, or someone is trying to do something very sneaky.  RFC 1812 provides more detail about what is and is not a valid routable IPv4 address.

So what do those messages mean?

Let’s start with the first message: it contains the destination and source IP addresses, as set in the IPv4 packet, and the network interface on which the packet arrived.  Despite how it reads, the first address is NOT the source address in the packet — it is, in fact, the destination address!  The 2nd IP is the IP that was contained in the IPv4 packet, but this isn’t of very much help in finding the sending host — remember, the whole point of this message is an indication that the source of the packet is “suspect.”

Fortunately, the 2nd line contains a lot of information for us, but it’s printed in a format that’s very hard to read.  This is the link-layer header of the packet that contained the erroneous source address.  Almost all machines these days use physical connectivity that looks like ethernet, and the log entry above is based on an Ethernet Frame.  (PPP connections will probably look different, but I’ve never seen this message on anything but ethernet.)  The ethernet header is at least 14 bytes long, and most of us will only see 14 byte headers.  The longer headers are used with 802.1q VLANs, but most people will never see those, so we’re going to discuss only the 14 byte headers.

The 14 bytes above, printed in colon-separated hex, contain the destination MAC address, the source MAC address, and either the length or the ethertype code.  The MAC addresses are in standard notation, and the first 6 octets are the destination, with octets 7-12 representing the source.  These will help you track down where the packet came from (though it might be your upstream router, in which case you’ll need to do more investigative work).

The last 2 bytes take more explaining.  If the value is less than 0x0600, then it represents the length of the data field for 802.3 compliant ethernet frames.  Greater values, as seen above, are actually EtherType codes.  This will mostly be 0x0800, which means an IPv4 packet is contained in the data segment.  (After all, this error does come from an IPv4 issue.)  Other values might be 0x8100 (802.1q VLAN-tagged packet) or 0x0806 (ARP packet).  There are many more, but you’re unlikely to see them in this context.

Long Story Short

Look at bytes 7-12 of the link-layer header.  That’s the MAC of the last machine to touch the packet.  Look there for the cause (if it’s a router, look upstream from there, and then figure out why you’re not filtering the martian packets on your router).  Yes, the source MAC could be spoofed, but then someone’s playing games on your local network segment.  (Which probably means they have physical access, or you have a terribly designed network.  Remember, physical access=pwned.)

Deep Packet inspection (DPI) / Layer 7 application recognition / Network Based application recognition (NBAR)

Deep packet inspection (DPI) is an advanced method of packet filtering that functions at the Application layer of the OSI (Open Systems Interconnection) reference model. The use of DPI makes it possible to find, identify, classify, reroute or block packets with specific data or code payloads that conventional packet filtering, which examines only packet headers, cannot detect.

Network Based Application Recognition (NBAR) is the mechanism used by some Cisco routers and switches to recognize a dataflow by inspecting some packets sent.

The networking equipment which uses NBAR does a deep packet inspection on some of the packets in a dataflow, to determine which traffic category the flow belongs to. Used in conjunction with other features, it may then program the internal ASICs to handle this flow appropriately. The categorization may be done with OSI layer 4 info, packet content, signaling, and so on but some new applications have made it difficult on purpose to cling to this kind of tagging.

The NBAR approach is useful in dealing with malicious software using known ports to fake being “priority traffic”, as well as non-standard applications using dynamic ports. That’s why NBAR is also known as OSI layer 7 categorization.

On Cisco routers, NBAR is mainly used for Quality of Service and Security purposes.

How to use OpenPuff steganography to send sensitive info securely

How to use OpenPuff steganography to send sensitive info securely

Video link:

Former National Security Agency (NSA) contractor Edward Snowden’s revelations regarding the spying activities of the U.S. government and others dealta devastating blow to some of the bedrocks of information security, including the trustworthiness of encryption and virtual private networks (VPN). Now, organizations worldwide must deal with the reality of government entities viewing sensitive corporate secrets, and even the possibility of malicious actors uncovering the same backdoors used by the NSA to steal valuable data. What can enterprises do to protect data during transmission when encryption and VPNs aren’t bulletproof?

The OpenPuff steganography tool, created by engineer Cosimo Oliboni, can add an extra layer of protection for those sensitive documents. In this SearchSecurity screencast, Keith Barker, a Certified Information Systems Security Professional (CISSP) and trainer for CBT Nuggets LLC, explains how to use OpenPuff to hide encrypted data in other files when being sent. OpenPuff is a free tool that gives practically any organization the ability to utilize steganography.

Barker begins the OpenPuff tutorial with a useful overview of steganography and why it is used in addition to encryption. He then explains the process of encoding data in another file, known as the carrier. The sender simply fills in the information to form the key needed for decryption, which includes up to three passwords, the name of the carrier file and the bit option used to encode the data. In a matter of seconds, sensitive info can be hidden in an innocuous file such as .mp3, .jpg, Adobe documents and many other formats, with size being the only difference between the original and carrier files On the other end, the recipient only needs to know the same information used to form the key to unlock the hidden file. OpenPuff even provides the option of having multiple carriers so uncharacteristically large files can be hidden.

Shellshock (bash vulnerability/bash bug)(Deadly serious’ new vulnerability found)(All OS X and Linux systems wide open)

A new vulnerability has been found that potentially affects most versions of the Linux and Unix operating systems, in addition to Mac OS X (which is based around Unix). Known as the “Bash Bug” or “ShellShock,” the GNU Bash Remote Code Execution Vulnerability (CVE-2014-6271) could allow an attacker to gain control over a targeted computer if exploited successfully.

The vulnerability affects Bash, a common component known as a shell that appears in many versions of Linux and Unix. Bash acts as a command language interpreter. In other words, it allows the user to type commands into a simple text-based window, which the operating system will then run.

Bash can also be used to run commands passed to it by applications and it is this feature that the vulnerability affects. One type of command that can be sent to Bash allows environment variables to be set. Environment variables are dynamic, named values that affect the way processes are run on a computer. The vulnerability lies in the fact that an attacker can tack-on malicious code to the environment variable, which will run once the variable is received.

Symantec regards this vulnerability as critical, since Bash is widely used in Linux and Unix operating systems running on Internet-connected computers, such as Web servers. Although specific conditions need to be in place for the bug to be exploited, successful exploitation could enable remote code execution. This could not only allow an attacker to steal data from a compromised computer, but enable the attacker to gain control over the computer and potentially provide them with access to other computers on the affected network.

The following video provides an explanation of the Bash Bug vulnerability and demonstrates how a likely attack scenario through the CGI interface may work:

Has it been exploited yet?
There are limited reports of the vulnerability being used by attackers in the wild. Proof-of-concept scripts have already been developed by security researchers. In addition to this, a module has been created for the Metasploit Framework, which is used for penetration testing.

Once the vulnerability has been made public, it was only a matter of time before attackers attempted to find and exploit unpatched computers.

How can it be exploited?
While the vulnerability potentially affects any computer running Bash, it can only be exploited by a remote attacker in certain circumstances. For a successful attack to occur, an attacker needs to force an application to send a malicious environment variable to Bash.

The most likely route of attack is through Web servers utilizing CGI (Common Gateway Interface), the widely-used system for generating dynamic Web content. An attacker can potentially use CGI to send a malformed environment variable to a vulnerable Web server. Because the server uses Bash to interpret the variable, it will also run any malicious command tacked-on to it.

Figure 1. How a malicious command can be tacked-on to the end of a legitimate environment variable. Bash will run the malicious command first.

The consequences of an attacker successfully exploiting this vulnerability on a Web server are serious in nature. For example attackers may have the ability to dump password files or download malware on to infected computers. Once inside the victim’s firewall, the attackers could then compromise and infect other computers on the network.

Aside from Web servers, other vulnerable devices include Linux-based routers that have a Web interface that uses CGI. In the same manner as an attack against a Web server, it may be possible to use CGI to exploit the vulnerability and send a malicious command to the router.

Computers running Mac OS X are also potentially vulnerable until Apple releases a patch for the vulnerability. Again, attackers would need to find a way to pass malformed commands to Bash on the targeted Mac. The most likely avenue of attack against OS X would probably be through Secure Shell (SSH), a secure communications protocol. However, it appears that the attacker would need to have valid SSH credentials to perform the attack. In other words, they would already have to be logged in to an SSH session.

Internet of Things (IoT) and embedded devices such as routers may be vulnerable if they’re running Bash. However, many newer devices run a set of tools called BusyBox which offers an alternative to Bash. Devices running BusyBox are not vulnerable to the Bash Bug.

For website owners and businesses
Businesses, in particular website owners, are most at risk from this bug and should be aware that its exploitation may allow access to their data and provide attackers with a foothold on their network. Accordingly, it is of critical importance to apply any available patches immediately.

Linux vendors have issued security advisories for the newly discovered vulnerability including patching information.

*Red Hat has updated its advisory to include fixes for a number of remaining issues.

If a patch is unavailable for a specific distribution of Linux or Unix, it is recommended that users switch to an alternative shell until one becomes available.

For consumers
Consumers are advised to apply patches to routers and any other web-enabled devices as and when they become available from vendors. Users of Apple’s Mac OS X should be aware that the operating system currently ships with a vulnerable version of Bash. Mac users should apply any patches for OS X when they become available.

Symantec Protection
Symantec has created an Intrusion Prevention signature for protection against this vulnerability:

Symantec will continue to investigate this vulnerability and provide more details as they become available.

Understanding the Eight Basic Commands on a Cisco ASA Security Appliance

There are literally thousands of commands and sub-commands available to configure a Cisco security appliance.  As you gain knowledge of the appliance, you will use more and more of the commands.  Initially, however, there are just a few commands required to configure basic functionality on the appliance.  Basic functionality is defined as allowing inside hosts to access outside hosts, but not allowing outside hosts to access the inside hosts.  Additionally, management must be allowed from at least one inside host.  To enable basic functionality, there are eight basic commands (these commands are based on software version 8.3(1) or greater).

  • interface
  • nameif
  • security-level
  • ip address
  • switchport access
  • object network
  • nat
  • route

Sample Network Diagram

Cisco ASA Configuration Basic Diagram


The interface command identifies either the hardware interface or the Switch Virtual Interface (VLAN interface) that will be configured.  Once in interface configuration mode, you can assign physical interfaces to switchports and enable them (turn them on) or you can assign names and security levels to VLAN interfaces.


The nameif command gives the interface a name and assigns a security level.  Typical names are outside, inside, or DMZ.

basic eight int nameif sec level ip add


Security levels are numeric values, ranging from 0 to 100, used by the appliance to control traffic flow.  Traffic is permitted to flow from interfaces with higher security levels to interfaces with lower security levels, but not the other way.  Access-lists must be used to permit traffic to flow from lower security levels to higher security levels.  The default security level for an outside interface is 0.  For an inside interface, the default security level is 100.  In the following sample configuration, the interface command is first used to name the inside and outside VLAN interfaces, then the DMZ interface is named and a security level of 50 is assigned to it.

ciscoasa(config)# interface vlan1
ciscoasa(config-if)# nameif inside
INFO: Security level for “inside” set to 100 by default.
ciscoasa(config-if)# interface vlan2
ciscoasa(config-if)# nameif outside
INFO: Security level for “outside” set to 0 by default.
ciscoasa(config-if)# interface vlan3
ciscoasa(config-if)# nameif dmz
ciscoasa(config-if)# security-level 50

ip address

The ip address command assigns an IP address to a VLAN interface either statically or by making it a DHCP client.  With modern versions of security appliance software, it is not necessary to explicitly configure default subnet masks.  If you are using non-standard masks, you must explicitly configure the mask, otherwise, it is not necessary.

In the following sample configuration, an IP address is assigned to VLAN 1, the inside interface.

ciscoasa(config-if)# interface vlan 1
ciscoasa(config-if)# ip address

In the following sample configuration, an interface VLAN 2, the outside interface is configured as a DHCP client.  The use of the statement “setroute” tells the appliance to get its default route from the DHCP server.

ciscoasa(config-if)# interface vlan 2
ciscoasa(config-if)# ip address dhcp setroute

Configuring interfaces on 55×0 appliances

Notice on the screen capture from a Cisco ASA 5540 security appliance that the nameif command is used to name physical interfaces instead of VLAN interfaces.
interface g01 configuration

switchport access

The switchport access command on the ASA 5505 security appliance assigns a physical interface to a logical (VLAN) interface.  In the next example, the interface command is used to identify physical interfaces, assign them to switchports on the appliance, and enable them (turn them on).  This command is not used on the ASA 55×0 appliances.

ciscoasa(config-if)# interface ethernet 0/0
ciscoasa(config-if)# switchport access vlan 2
ciscoasa(config-if)# no shutdown
ciscoasa(config-if)# interface ethernet 0/1
ciscoasa(config-if)# switchport access vlan 1
ciscoasa(config-if)# no shutdown

object network net-192.168.106

The object network net-192.168.106 statement creates an object called “net-192.168.106”.  (You do not have to name the object “net-192.168.106”; that is a descriptive name, but you could just as easily name it “Juan”.)  The network option states that this particular object will be based on IP addresses.  The subnet command states that net-192.168.106 will affect any IP address beginning with 192.168.106.

ciscoasa(config-if)#object network net-196.168.106


The nat statement, as shown below, tells the firewall to allow all traffic flowing from the inside to the outside interface  to use whatever address is dynamically (DHCP) configured on the outside interface.

ciscoasa(config)#nat (inside,outside) dynamic interface


The route command, in its most basic form, assigns a default route for traffic, typically to an ISP’s router.  It can also be used in conjunction with access-lists to send specific types of traffic to specific hosts on specific subnets.

In this sample configuration, the route command is used to configure a default route to the ISP’s router at  The two zeroes before the ISP’s router address are shorthand for an IP address of and a mask of  The statement outside identifies the interface through which traffic will flow to reach the default route.

ciscoasa(config-if)# route outside 0 0

In place of the manual default route configuration, as mentioned previously, you could instead configure your outside interface as a DHCP client and include the “setroute” statement to obtain the default route from the ISP’s DHCP server.

The above commands create a very basic firewall.  A sophisticated firewall such as the Cisco ASA Security Appliance is capable of much greater functionality than what is shown here.  These commands, however, will provide a solid foundation for configuring additional services on your appliance.

Other commands you might use include hostname to identify the firewall, telnet or SSH to allow remote administration, DHCPD commands to allow the firewall to assign IP addresses to inside hosts, and static route and access-list commands to allow internal hosts such as DMZ Web servers or DMZ mail servers to be accessible to Internet hosts.  Of course, there are many more advanced commands that are explained in other how-to guides and in the book The Accidental Administrator: Cisco ASA Security Appliance: A Step-by-Step Configuration Guide.

Sample Base Configuration #1 (Static IP Address on Outside Interface)

ciscoasa(config)# interface vlan1
ciscoasa(config-if)# nameif inside
INFO: Security level for “inside” set to 100 by default.
ciscoasa(config-if)# interface vlan2
ciscoasa(config-if)# nameif outside
INFO: Security level for “outside” set to 0 by default.
ciscoasa(config-if)# interface ethernet 0/0
ciscoasa(config-if)# switchport access vlan 2
ciscoasa(config-if)# no shutdown
ciscoasa(config-if)# interface ethernet 0/1
ciscoasa(config-if)# switchport access vlan 1
ciscoasa(config-if)# no shutdown
ciscoasa(config-if)# interface vlan 2
ciscoasa(config-if)# ip address
ciscoasa(config-if)# interface vlan 1
ciscoasa(config-if)# ip address
ciscoasa(config-if)# route outside 0 0
ciscoasa(config-if)#object network net-192.168.106
ciscoasa(config)#nat (inside,outside) dynamic interface

Note in the above configuration that the outside interface address and default route are configured manually.  If your appliance’s outside interface is connected to a network with a DHCP server, such as an ISP, you could configured interface VLAN2 as a DHCP client with the command “ip address dhcp setroute”.  The use of the “setroute” statement also eliminates the need for the manual default route configuration (route outside 0 0

Sample Base Configuration #2 (DHCP-assigned IP Address on Outside Interface)

ciscoasa(config)# interface vlan1
ciscoasa(config-if)# nameif inside
INFO: Security level for “inside” set to 100 by default.
ciscoasa(config-if)# interface vlan2
ciscoasa(config-if)# nameif outside
INFO: Security level for “outside” set to 0 by default.
ciscoasa(config-if)# interface ethernet 0/0
ciscoasa(config-if)# switchport access vlan 2
ciscoasa(config-if)# no shutdown
ciscoasa(config-if)# interface ethernet 0/1
ciscoasa(config-if)# switchport access vlan 1
ciscoasa(config-if)# no shutdown
ciscoasa(config-if)# interface vlan 2
ciscoasa(config-if)# ip address dhcp setroute
ciscoasa(config-if)# interface vlan 1
ciscoasa(config-if)# ip address
ciscoasa(config-if)#object network net-192.168.106
ciscoasa(config)#nat (inside,outside) dynamic interface

Back to top