Category Archives: Security – CCNA / CCNP Security
ASA ASDM basic config:
Cisco 861/871 basic router configuration:
Cisco IOS DHCP Configuration:
IOS Zone based Firewall configuration:
IOS Site-to-Site IPSec VPN Configuration:
ASA Site-to-Site IPSec VPN:
Cisco VPN Client Configuration – Setup for IOS Router:
CONFIGURING CISCO SSL VPN ANYCONNECT (WEBVPN) ON CISCO IOS ROUTERS:
Cisco Tools and Applications:
ESP encrypts all critical information, encapsulating the entire inner TCP/UDP datagram within an ESP header. ESP is an IP protocol in the same sense that TCP and UDP are IP protocols (OSI Network Layer 3), but it does not have any port information like TCP/UDP (OSI Transport Layer 4). This is a difference from ISAKMP which uses UDP port 500 as its transport layer.
Why can’t an ESP packet pass through a PAT device?
It is precisely because ESP is a protocol without ports that prevents it from passing through PAT devices. Because there is no port to change in the ESP packet, the binding database can’t assign a unique port to the packet at the time it changes its RFC 1918 address to the publically routable address. If the packet can’t be assigned a unique port then the database binding won’t complete and there is no way to tell which inside host sourced this packet. As a result there is no way for the return traffic to be untranslated successfully.
How does NAT-T work with ISAKMP/IPsec?
NAT Traversal performs two tasks:
Detects if both ends support NAT-T
Detects NAT devices along the transmission path (NAT-Discovery)
Step one occurs in ISAKMP Main Mode messages one and two. If both devices support NAT-T, then NAT-Discovery is performed in ISKAMP Main Mode messages (packets) three and four. THe NAT-D payload sent is a hash of the original IP address and port. Devices exchange two NAT-D packets, one with source IP and port, and another with destination IP and port. The receiving device recalculates the hash and compares it with the hash it received; if they don’t match a NAT device exists.
If a NAT device has been determined to exist, NAT-T will change the ISAKMP transport with ISAKMP Main Mode messages five and six, at which point all ISAKMP packets change from UDP port 500 to UDP port 4500. NAT-T encapsulates the Quick Mode (IPsec Phase 2) exchange inside UDP 4500 as well. After Quick Mode completes data that gets encrypted on the IPsec Security Association is encapsulated inside UDP port 4500 as well, thus providing a port to be used in the PAT device for translation.
To visualize how this works and how the IP packet is encapsulated:
Clear text packet will be encrypted/encapsulated inside an ESP packet
ESP packet will be encapsulated inside a UDP/4500 packet.
NAT-T encapsulates ESP packets inside UDP and assigns both the Source and Destination ports as 4500. After this encapsulation there is enough information for the PAT database binding to build successfully. Now ESP packets can be translated through a PAT device.
When a packet with source and destination port of 4500 is sent through a PAT device (from inside to outside), the PAT device will change the source port from 4500 to a random high port, while keeping the destination port of 4500. When a different NAT-T session passes through the PAT device, it will change the source port from 4500 to a different random high port, and so on. This way each local host has a unique database entry in the PAT devices mapping its RFC1918 ip address/port4500 to the public ip address/high-port.
What is the difference between NAT-T and IPSec-over-UDP ?
Although both these protocols work similiar, there are two main differences.
When NAT-T is enabled, it encapsulates the ESP packet with UDP only when it encounters a NAT device. Otherwise, no UDP encapsulation is done. But, IPSec Over UDP, always encapsulates the packet with UDP.
NAT-T always use the standard port, UDP-4500. It is not configurable. IPSec over UDP normally uses UDP-10000 but this could be any other port based on the configuration on the VPN server.
- CAM Table OverFlow Attack (DoS attack)(macof –i eth0): Port-Security
- DHCP Starvation Attack (DoS attack): Port-Security and Rate-limiting requests.
- DHCP Spoofing/Rogue DHCP Attack (Mitm attack): DHCP Snooping
- VLAN Hopping attack (negotiate trunk using DTP)(yersinia -G): set all the ports not connected to switches to no-negotiate and access ports, as by default they are set to negotiate i.e. ‘dynamic-auto’.
Also don’t use vlan1 as native vlan.
- Rogue Switch Attack (Switch Mitm i.e. becomes the root bridge): portfast and BPDU Guard (turned ON globally if the port is an access port)(shuts the port down).
BPDU Filter (Doesn’t allow BPDUs, but doesn’t shut the port down).
Root Guard (tell the switch that certain ports can’t be root ports i.e. if you are connected to legitimate switches).
- Arp Spoofing/ARP Poisoning attack (Gratuitous ARP) (Mitm attack): DAI (Dynamic Arp Inspection)
The following must be identical:
- Model (5505 or 5510 or 5520, etc)
- Amount of RAM
- Number of Interfaces (should be the same type as well)
- External Modules (CSC-SSM or IPS-SSM)
- 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
FAILOVER CONTROL LINK communicates:
- 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
FAILOVER INTERFACE TESTS:
- 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
- Network Activity Test -> All packets received are counted for up to 5 seconds. If any packets are received, the interface is marked as operational
- 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
- 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:
- Uauth cache
- URL Filtering cache
- TCP Intercept
- SNMP Firewall MIB
- Routing Table
- State Info for SSM
- Phone Proxy sessions
- IPv6 sessions
Types of failover -> Device-level failover and interface-level failover
Device-level failover -> Active/Standby and Active/Active
- Active unit passes traffic
- Standby unit monitors active unit
- Both units send hello messages to monitor each other’s state
- When both are up and running, one unit assumes the role of active while the other unit assumes the standby role
- 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
- If one of the units boots up and detects an active failover unit, it goes into standby regardless of the primary or secondary designation
- 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
- 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
- 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.
ACTIVE/ACTIVE FAILOVER AND ASYMMETRIC ROUTING
- 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.
INTERFACE-LEVEL FAILOVER – REDUNDANT INTERFACES
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
ACTIVE/STANDBY FAILOVER CONFIG
- Select the failover link
- Assign failover IP address
- Set the failover key (optional)
- Designate the primary unit
- Enable the stateful failover (optional)
- Enable failover globally
- 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
BOOTSTRAP CONFIG ON SECONDARY
Enable the failover control interface
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 22.214.171.124 255.255.255.0 standby 126.96.36.199”
- Same failover shared key
“failover key cisco 123”
- Failover enable (enabled globally)
ACTIVE/ACTIVE FAILOVER CONFIG
- 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
- 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
OPTIONS FOR FAILOVER GROUPS
- MAC address
**** 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
OPTIONAL FAILOVER COMMANDS
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.
ACTIVE/STANDBY MAC ADDRESS PRIORITY LIST
- 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
ACTIVE/ACTIVE MAC ADDRESS PRIORITY LIST
- 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.