ASA drop packets unexpectively

We have the following scenario for connection:

A ——– outside inte–ASA–inside inte———B

A has TCP conntion with B, but connection was interrupted sometime during the communicaiton. I did packet capture on both inside and outside interfaces of ASA in order to find out what was going on during this communcation. And I found that some packets on inside interface of ASA has been dropped:
those packets showed up in inside interfaces, but did not present in outside interfaces, instead, ASA reply to B on behave of A. That leads to the issue that A keep sending
retransmission packets but got no reply, when timeout A send Fin packet to close the connection, on the other side B was communicating all the time until got Fin packets from A, in response B send back ACK and FIN packets too, still, this AC &FIN packets was caught by ASA and dropped:

A ———————–ASA———————–B
—->packet1————|——-packet1———>
<—–packetBtoA——–|—–packetBtoA<——–
……..
—–>pktAtoB n———|—–pktAtoB n———–>
——–no traffic——- |<—-pktBtoA n+1———
——–no traffi——– |—->pktAtoB n repeat—>
—–>pketAtoB retrans—|—->pktAto B retrans—>
——-no traffic———|<—-pktBtoA n+1———
——-no traffic———|—->pktAtoB n repeat—-
……..
after 5 retransmission or timeout
—–>FIN—————|——->FIN————->
—–no traffic———–|<——ACK—————
—–no traffic———–|<——FIN—————-

A closed the connection because got no reply from B, B close the connections too after receiving FIN(supposelly after timeout for half-closing tcp connection)
While ASA still keep this connection in the connection table until idle timeout.

In order to find out the reason why ASA dropped the packet, we may use capture with the following command:
ASA>capture drop type asp-drop all

asp-drop Capture packets dropped with a particular reason

This will capture all the dropped packets by ASA, at most cases if there is a drop-reason “tcp-paws-fail” as example, ASA will print the drop-reason for one packet, other packets that match this connection and dropped for the same reason will be in the outputs with no drop reason until another drop reason appear.

In our case, we have hit the ASA bug ‘ASA drops packet as PAWS failure’, and after consulting Cisco engineer, we got the info that”to know if your version is affected or not, you need to look at the known fixed releases. So, since version 9.1.(7.12) is the first version in the train 9.1.7 that fixed this bug, this mean all other versions before 9.1.7.12 in the same train 9.1.7 are affected with this bug.”

Advertisements

300-206 SENSS study notes

1.0 Threat Defense

25%

1.1 Implement firewall (ASA or IOS depending on which supports the implementation)

  • 1.1.a Implement ACLs
  • 1.1.b Implement static/dynamic NAT/PAT
  • 1.1.c Implement object groups
  • 1.1.d Describe threat detection features

http://www.cisco.com/c/en/us/support/docs/security/asa-5500-x-series-next-generation-firewalls/113685-asa-threat-detection.html
basic threat detection
ciscoasa(config)# threat-detection basic-threat
ciscoasa(config)# show run all threat-detection
threat-detection rate dos-drop rate-interval 600 average-rate 100 burst-rate 400
threat-detection rate dos-drop rate-interval 3600 average-rate 80 burst-rate 320
threat-detection rate bad-packet-drop rate-interval 600 average-rate 100 burst-rate 400
threat-detection rate bad-packet-drop rate-interval 3600 average-rate 80 burst-rate 320
threat-detection rate acl-drop rate-interval 600 average-rate 400 burst-rate 800
threat-detection rate acl-drop rate-interval 3600 average-rate 320 burst-rate 640
threat-detection rate conn-limit-drop rate-interval 600 average-rate 100 burst-rate 400
threat-detection rate conn-limit-drop rate-interval 3600 average-rate 80 burst-rate 320
threat-detection rate icmp-drop rate-interval 600 average-rate 100 burst-rate 400
threat-detection rate icmp-drop rate-interval 3600 average-rate 80 burst-rate 320
threat-detection rate scanning-threat rate-interval 600 average-rate 5 burst-rate 1
advanced threat detection
scanning threst detection
In order to enable Scanning Threat Detection, use the threat-detection scanning-threat command.
ciscoasa(config)# threat-detection scanning-threat

  • 1.1.e Implement botnet traffic filtering

http://www.cisco.com/c/en/us/td/docs/security/asa/special/botnet/guide/asa-botnet.html

Example 1-2 Multiple Mode Botnet Traffic Filter Recommended Example

dynamic-filter updater-client enable
changeto context context1
dynamic-filter use-database
class-map dynamic-filter_snoop_class
match port udp eq domain
policy-map dynamic-filter_snoop_policy
class dynamic-filter_snoop_class
inspect dns preset_dns_map dynamic-filter-snoop
service-policy dynamic-filter_snoop_policy interface outside
dynamic-filter enable interface outside
dynamic-filter drop blacklist interface outside
changeto context context2
dynamic-filter use-database
class-map dynamic-filter_snoop_class
match port udp eq domain
policy-map dynamic-filter_snoop_policy
class dynamic-filter_snoop_class
inspect dns preset_dns_map dynamic-filter-snoop
service-policy dynamic-filter_snoop_policy interface outside
dynamic-filter enable interface outside
dynamic-filter drop blacklist interface outside

  • 1.1.f Configure application filtering and protocol inspection

http://www.cisco.com/c/en/us/td/docs/security/asdm/6_2/user/guide/asdmconfig/inspctrl.html

When a user establishes a connection, the security appliance checks the packet against access lists, creates an address translation, and creates an entry for the session in the fast path, so that further packets can bypass time-consuming checks. However, the fast path relies on predictable port numbers and does not perform address translations inside a packet.
Many protocols open secondary TCP or UDP ports. The initial session on a well-known port is used to negotiate dynamically assigned port numbers.
Other applications embed an IP address in the packet that needs to match the source address that is normally translated when it goes through the security appliance.
If you use applications like these, then you need to enable application inspection.

http://www.cisco.com/c/en/us/td/docs/security/asa/asa72/configuration/guide/conf_gd/inspect.html

The default Layer 3/4 class map for through traffic is called “inspection_default.” It matches traffic using a special match command, match default-inspection-traffic, to match the default ports for each application protocol.

The default policy configuration includes the following commands:

class-map inspection_default
match default-inspection-traffic
policy-map type inspect dns preset_dns_map
parameters
message-length maximum 512
policy-map global_policy
class inspection_default
inspect dns preset_dns_map
inspect ftp
inspect h323 h225
inspect h323 ras
inspect rsh
inspect rtsp
inspect esmtp
inspect sqlnet
inspect skinny
inspect sunrpc
inspect xdmcp
inspect sip
inspect netbios
inspect tftp
service-policy global_policy global

You can specify a match access-list command along with the match default-inspection-traffic command to narrow the matched traffic to specific IP addresses. Because the match default-inspection-traffic command specifies the ports to match, any ports in the access list are ignored.

hostname(config)# access-list inspect extended permit ip 10.1.1.0 255.255.255.0 192.168.1.0 255.255.255.0
hostname(config)# class-map inspection_default
hostname(config-cmap)# match access-list inspect

  • 1.1.g Describe ASA security contexts

Multiple contexts configuration.

1.2 Implement Layer 2 Security

  • 1.2.a Configure DHCP snooping

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/snoodhcp.html#wp1120427

Display a binding table
Router# show ip dhcp snooping binding
Enable dhcp snooping globally
Router(config)# ip dhcp snooping
enable dhcp snooping option82
Router(config)# ip dhcp snooping information option
enable dhcp snooping on vlan
Router(config)# ip dhcp snooping vlan 10 12
Configuring the DHCP Trust State on Layer 2 LAN Interfaces
Router(config)# interface FastEthernet 5/12
Router(config-if)# ip dhcp snooping trust

  • 1.2.b Describe dynamic ARP inspection

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/25ew/configuration/guide/conf/dynarp.html

S1(config)# ip arp inspection vlan 1
S1(config)# in fa6/3
S1(config-if)# ip arp inspection trust

  • 1.2.c Describe storm control

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst6500/ios/12-2SX/configuration/guide/book/storm.html

Router# interface GigabitEthernet4/10
Router# switchport
Router# switchport mode access
Router# storm-control broadcast level 0.5
Router# storm-control multicast level 0.5
Router# spanning-tree portfast edge

  • 1.2.d Configure port security

http://www.cisco.com/c/en/us/td/docs/switches/lan/catalyst4500/12-2/25ew/configuration/guide/conf/port_sec.html

example of port security:

Switch(config-if)# switchport mode access
Switch(config-if)# switchport port-security
Switch(config-if)# switchport port-security maximum 5
Switch(config-if)# switchport port-security mac-address sticky
Switch(config-if)# end

  • 1.2.e Describe common Layer 2 threats and attacks and mitigation

http://www.networkpcworld.com/types-of-layer-2switch-security-attacks-and-mitigation-steps-in-brief/

Security Attacks against Switches or at Layer 2 can be grouped in four major Categories as follows:

1. MAC layer attacks
2. VLAN attacks
3. Spoofing attacks
4. Attacks on switch devices
1. MAC Layer Attacks Types

MAC address flooding 
Description :- Frames with unique, invalid source MAC addresses flood the switch, exhausting content addressable memory (CAM) table space, disallowing new entries from valid hosts. Traffic to valid hosts is subsequently flooded out all ports.
Mitigation Port security. MAC address VLAN access maps.
 
2. VLAN Attacks
i – VLAN hopping
By altering the VLAN ID on packets encapsulated for trunking, an attacking device can send or receive packets on various VLANs, bypassing Layer 3 security measures.
Mitigation  Tighten up trunk configurations and the negotiation state of unused ports. Place unused ports in a common VLAN.
 
ii – Attacks between devices on a common VLAN 
Devices might need protection from one another, even though they are on a common VLAN. This is especially true on service-provider segments that support devices from multiple customers.
Mitigation : – Implement private VLANs (PVLAN).
 
3. Spoofing Attacks
i – DHCP starvation and DHCP spoofing
An attacking device can exhaust the address space available to the DHCP servers for a period of time or establish itself as a DHCP server in man-in-themiddle attacks.
Mitigation :- Use DHCP snooping.
 
ii – Spanning-tree compromises 
Attacking device spoofs the root bridge in the STP topology. If successful, the network attacker can see a variety of frames.
Mitigation :- Proactively configure the primary and backup root devices. Enable root guard.
 
iii – MAC spoofing
Attacking device spoofs the MAC address of a valid host currently in the CAM table. The switch then forwards frames destined for the valid host to the attacking device.
Mitigation :- Use DHCP snooping, port security.
 
iv – Address Resolution Protocol (ARP) spoofing
Attacking device crafts ARP replies intended for valid hosts. The attacking device’s MAC address then becomes the destination address found in the Layer 2 frames sent by the valid network device.
Mitigation :- Use Dynamic ARP Inspection, DHCP snooping, port security.
 
4. Switch Device Attacks
i – Cisco Discovery Protocol (CDP) manipulation
Information sent through CDP is transmitted in clear text and unauthenticated, allowing it to be captured and divulge network topology information.
Mitigation :- Disable CDP on all ports where it is not intentionally used.
 
ii – Secure Shell Protocol (SSH) and Telnet attacks
Telnet packets can be read in clear text. SSH is an option but has security issues in version 1.
Mitigation : – Use SSH version 2. Use Telnet with vty ACLs.
  • 1.2.f Describe MACSec

http://www.cisco.com/c/en/us/products/collateral/ios-nx-os-software/identity-based-networking-services/deploy_guide_c17-663760.html#wp9000236

Before the 2010 revision of IEEE 802.1X, there was no mechanism to help ensure the confidentiality or integrity of the traffic sent after authentication. Because traffic was sent in the clear with no integrity checks, rogue users with physical access to the authenticated port could monitor, modify, and send traffic. In addition, source MAC address filtering could be circumvented by MAC address spoofing.
MACsec provides secure communication on wired LANs. When MACsec is used to secure the communication between endpoints on a LAN, each packet on the wire is encrypted using symmetric key cryptography so that communication cannot be monitored or altered on the wire.1.2.g Configure IP source verification

High-Level IEEE 802.1X and MACsec Sequence

During the session-key agreement stage, the switch and the supplicant advertise their capabilities and derive all the parameters needed for MACsec. These functions are accomplished by the MKA protocol, which is transported on the wire using a new EAPoL packet type 5 (EAPoL-MKA).
If the supplicant and the switch are capable of MACsec, the switch automatically becomes the key server. The key server is responsible for selecting and advertising a cipher suite. Cisco components all support the default cipher suite Galois/Counter Mode Advanced Encryption Standard 128 (GCM-AES-128).
The key server is also responsible for generating a secure association key (the SAK) from the CAK. The SAK is the secret key that is used to encrypt traffic on the wire for a given connection. The SAK is the actual key that is used to encrypt traffic for a session. Unlike the CAK, which is a long-term master key, the SAK is a transient key that can periodically be refreshed.

1.3 Configure device hardening per best practices

  • 1.3.a Routers

secure BGP, management ip, secure login, netflow monitor traffic, acls,

Routing Protocol Authentication and Verification with Message Digest 5
Passive-Interface Commands
Route Filtering

  1. 1.3.b Switches

Unicast RPF
IP Source Guard
Port Security
Dynamic ARP Inspection
Anti-Spoofing ACLs

 

  • 1.3.c Firewalls

Anti reverse path check; security level; mgmt interface;