• No results found

Failover Functionality Overview on the ASA

In document Molina-HLD-V1.0(Latest) (Page 58-62)

Inside Network Outside Network

4. Security Technologies

4.5 Failover Functionality Overview on the ASA

Recommenda

tion To allow contexts to share interfaces it is recommended that you assign unique MAC addresses to each context interface. The MAC address is used to classify packets within a context. If you share an interface, but do not have unique MAC addresses for the interface in each context, then the destination IP address is used to classify packets. The destination address is matched with the NAT configuration however this method does have some limitations when compared to the unique MAC address method. For this reason the Commander configuration the mac-address auto command will appear in the system.

4.5 Failover Functionality Overview on the ASA

The ASA failover feature allows a standby ASA to take over the functionality of a failed active ASA. When the active unit fails, it changes to the standby state, while the standby module changes to the active state. The two ASAs must have the same major and minor software version, license, and operating modes.

The failover configuration requires two identical security appliances connected to each other through a dedicated failover link and, optionally, a Stateful Failover link. The health of the active interfaces and units is monitored to determine if specific failover conditions are met. If those conditions are met, failover occurs. For the Emerson Network, Active/Standby failover will be used as opposed to Active/Active failover. With Active/Standby failover, only one unit passes traffic while the other unit waits in a standby state.

Each Firewall interface on the primary and secondary firewall is connected to each other using common VLANs i.e. the inside interface of the primary unit is connected to the inside interface of the failover unit. This is done by putting the primary and secondary interfaces in the same VLAN on the connected switches.

When the active unit fails, it changes state to the standby state while the standby unit changes to the active state. The unit that becomes active assumes the IP addresses and MAC addresses of the failed unit and begins passing traffic. The unit that is now in standby state takes over the standby IP addresses and MAC addresses. Because network devices see no change in the MAC to IP address pairing, no ARP entries change or time out on the network.

4.5.1 Stateful failover

During normal operation, the active module continually passes per-connection stateful information to the standby module every 10 seconds. After a failover occurs, the same connection information is available at the new active module. Supported end-user applications are not required to reconnect to keep the same communication session.

The state information passed to the standby module includes the following data:

• NAT translation table.

• TCP connection states.

• UDP connection states (for connections lasting at least 15 seconds).

• HTTP connection states (Optional).

• H.323, SIP, and MGCP UDP media connections.

• ARP table.

4.5.2 Failover and State Links

Two links between the ASAs are required for active/standby and stateful failover.

Failover Link - The two units constantly communicate over a failover link to determine the operating status of each module. Communications over the failover link include the following data:

• The module state (active or standby).

• Hello messages (also sent on all other interfaces).

• Configuration synchronization between the two modules.

State Link - To use stateful failover, a stateful failover link needs to be configured to pass all state information. This link can be the same as the failover link, but we recommend that a different link be used for the same. The state traffic can be large, and performance is improved with separate links.

The IP address and MAC address for the failover and state link do not change at failover. For multiple context mode, the failover and state links reside in the system configuration. These interfaces are the only configurable interfaces in the system configuration.

4.5.3 Intrusion Detection & Prevention

Intrusion detection products such as the Cisco Intrusion Detection System (IDS) appliance and the Cisco Catalyst 6500 IDS module, and intrusion prevention products such as the Cisco Security Agent (CSA) protect the server farm from attacks that exploit OS and application vulnerabilities. These technologies are complemented by the use of mirroring technologies such as VACLs and RSPAN that allow differentiating traffic on multiple sensors.

The Cisco Catalyst 6500 Series Switch combined with the Cisco IDS 4200 Series sensors can provide

multi-gigabit IDS analysis. IDS sensors can detect malicious activity in a server farm based on protocol or traffic anomalies, or based on the stateful matching of events described by signatures. An IDS sensor can detect an attack from its very beginning by identifying the probing activity, or it can identify the exploitation of well-known vulnerabilities.

Traffic distribution to multiple IDS sensors can be achieved by using mirroring technologies (RSPAN

and VACL) for multi-gigabit traffic analysis. The logical topology shows the IDS placement at the presentation tier and at the database tier. When a web/application server has been compromised and the hacker attacks the database, the second sensor reports the attack. In a consolidated data center environment, servers for the different tiers may be connected to the same physical infrastructure, and multiple IDS sensors can provide the same function as in the logical topology of Figure 4.3.

Figure 4.3 IDS PLACEMENT

In Figure 4.3, IDS1 monitors client-to-web server traffic and IDS2 monitors web/application

server-to-database traffic. When a hacker compromises the web/application tier, IDS1 reports an alarm; when a compromised web/application server attacks the database, IDS2 reports an alarm.

HTTPS traffic can be inspected if the IDS sensors are combined with a device that provides SSL offload.

Figure 4.4 WEB TO DATABASE SERVER TRAFFIC FLOW

The following sequence takes place:

1. The Multilayer Switch Feature Card (MSFC) receives client-to-server traffic from the data center core.

2. The ACE diverts traffic directed to the VIP address.

3. The ACE sends HTTPS client-to-server traffic to the SSLSM for decryption.

4. The SSLSM decrypts the traffic and sends it in clear text on an internal VLAN to the CSM.

5. The IDS sensor monitors traffic on this VLAN.

6. The ACE performs the load balancing decision and sends the traffic back to the SSLSM for

re-encryption.

In document Molina-HLD-V1.0(Latest) (Page 58-62)

Related documents