-->
ASA Overview :
Stateful firewall filtering
-supports application aware Inspection
VPN termination
-Supports both IKEv1/IKEv2 IPsec and SSL VPNs
Intrusion Prevention systems (IPS)
-IPS on advanced inspection and prevention (AIP) Security service module (SSM) for ASA5500 models
-Ips built-in software module for ASA5500-X models
Content Filtering(URL Filtering, AVC, Virus, Spyware, Spam, etc.)
-Content Security and Control (CSC) Security Services Module (SSM) for ASA 5500 models
-ASA-CX built-in software module for ASA5500-x Module
ASA Security Levels
ASA classifies the level of “Trust” of an interface by its security-level
-Range of 0-100
100 is the most trusted interface
-Assigned to interface “inside” by default
0 is the most untrusted interface
-assigned to all other interfaces by default
ASA interfaces can only pass traffic if both nameif and security-level are defined
Traffic from higher to lower security level..
-permit by default
-eg inside to outside
traffic from lower to higher security level..
-permit if state already exists
-deny if no state by default
-eg outside to inside
Traffic between interfaces of same security
-deny by default
-Exception with same-security-traffic permit inter-interface
-same-security –traffic permit intra-interface is NOT related to security-levels, allows traffic hairpining
Security-levels are bypassed by inbound or global ACL’s
ASA Stateful Firewall Filtering
-enabled by default for TCP/UDP traffic and cannot be disabled
-track traffic that moves from trusted network to untrusted network
-eg inside to outside interface
Create an entry in the state table for the traffic flow
-eg TCP port 80 http session from client A to server B
Track traffic that tries to enter the untrusted network to the trusted network
-if an entry exists in the state table, permit it
eg the return http flow from server B to client A
-if no entry exists in the state table, deny it
eg NMAP port scan from the outside network
ASA Traffic Inspection
Modular Policy framework(MPF) used to control how traffic is inspected
MPF controls ..
-What traffic is inspected
.basic layer 3 &4 inspection of TCP, UDP and ICMP
.application aware inspection of Http, smtp, dns, sip, etc
-how traffic is inspected
connection limits, Qos parameters, etc
-Direction of inspection
eg inside to outside vs inside to DMZ vs outside to DMZ etc
Access control lists are used to exempt or include traffic into MPF engine
ASA Context Modes
ASA supports two different context modes of operation
-single context mode
-multiple context mode (Virtual Firewall)
Single context mode
-shared configuration for all interfaces, security policies, routing table, administrators , etc.
Multiple context mode
-separate configuration, interfaces, policies per virtual context
-allows for multiple virtual firewalls for managed services or policy separation
ASA Firewall Modes
ASA supports two different Firewall modes of operation
-routed firewall
-transparent firewall
Routed firewall
-interfaces are in different subnets and different vlans
-traffic is routed between interfaces
implies the need for static or dynamic routing protocols
Transparent firewall
-interfaces are in same subnet but different VLANSs
-traffic is bridged between interfaces
-only one bridge-group can be created between two interfaces
-upto 8 bridge-groups with 4 interfaces per bridge-group starting with 8.4
ASA Context Modes and Firewall Modes
Context Modes and Firewall Modes can run in any combination
-single context mode routed firewall
-single context mode transparent firewall
-multiple context mode routed firewall
-multiple context mode transparent firewall
Mixed transparent/routed contexts are not supported in 8.x code
ASA VPN Termination
Supports both IKE1/IKE2 Ipsec and SSL VPN termination
-Ipsec with ESP, ESP over UDP and TCP
-SSL over TCP(TLS) and UDP (DTLS)
-AH not supported
Supports both LAN to LAN and remote access vpns
-ipsec lan to lan
aka site to site
-ipsec remote access
aka easy vpn server/client
-ssl remote access
client vpn (web vpn)
anyconnect ssl vpn client
ASA initialization
ASA management methods
Basic ASA initialization
ASA supports two methods of management
-command line interface CLI
-cisco adaptive security device manager (ASDM)
-both supported in the current CCIE SCv4 Blueprint
CLI Management
-local via console port
-remote via telnet and ssh
ASDM Management
-remote via https
-there are certain tasks which can only be completed using the GUI
(SSL VPN Bookmarks, Anyconnect Client profiles, DAP policies)
Basic ASA initialization
Connect to console
Clear existing config
-write erase or clear startup-config
-clear configure all
.does not prompt for confirmation
show running-config all policy-map
show run all group-policy
show run all tunnel-group
To check vpn template:
ASA(config)#vpnsetup site-to-site steps
1. Configure interfaces
2. Configure ISAKMP policy
3. Configure transform-set
4. Configure ACL
5. Configure Tunnel group
6. Configure crypto map to attach to interface
7. Enable isakmp on interface
So no need to memorize all these steps
Basic ASA Initialization
Initialize interfaces
-Enable interfaces
no shut
-choose trunk or access mode
create subinterface and apply vlan for trunking
-assign security levels
security-level number
-assign interface’s name
nameif name
-assign Ip addressing
ip address ip_address mask standby ip _adddress
ASA supports dynamic routing protocols
Traffic from high to low -> allow
Traffic from low to high
-check state table
-check acl
-check drop
ASA Routing
ASA routing overview
ASA Static routing example
ASA dynamic routing example
ASA route tracking example
ASA supports IPv4 Routing via..
-Static routes
-RIPv1/RIPv2 maximum one process
-OSPF maximum two process
-EIGRP maximum one process
-Per protocol functionalities are not as advanced as in IOS code
ASA miscellaneous routing features..
-Multiple routing processes
-routing authentication
-route filtering
-redistribution
-redistribution filtering
-equal cost multipath
supported over the same interface only
-Route tracking
-multicast routing
Note: in case of ACL and ospf network we used to use inverse mask in IOS but in ASA we use subnet mask.
Reliable static routes on ASA
Like IOS, used two parts..
-service level agreement (SLA)/ Response Time reporter (RTR)
checks reachability with ICMP echo (ping)
No advanced SLA metrics like in IOS
-Enhanced object tracking
object reference SLA instance
if SLA instance PING is successful, object is up
If SLA instance PING fails, object is down
Static route references object
-route can only be installed if object is up
-allows for reliable floating static routes
Note : ASA does not support ISIS and BGP
Multicast only support sparse mode. Dense mode is not supported.
ASA Access control list
Asa object groups and objects
By default ASA allows ..
-traffic from higher security to lower security
-traffic from lower security to higher security if state already exists
Not all traffic is actually inspected by default
ACL allow manual inspection to inspected traffic
Inbound ACL’s and global ACL’s bypass security level functionality
There can be one inbound and one outbound ACL per interface, along with one global
Order of processing: from outside to inside
State table
Acl
If no match deny
-inbound acl
-global acl
-outbound acl
When global ACL is configured, the implicit deny from the inbound ACL is automatically removed
When both inbound ACL and global ACL are used, then the rule is :
- rules from both ACL’s are merged
- first are processed rules from the inbound ACL
- second are processed rules from the global ACLs
- Only global ACL has the default implicit deny
Like in IOS, ASA match traffic based on ..
- source ip address
- destination ip address
- ip protocol number
- tcp and udp ports
- icmp type codes
- time range
Like in IOS, ACLs always end in implicit deny
Unlike in IOS, ASA acls..
- Use the same naming convention for standard and extended cannot mix both in the same list
Object Groups
Object groups simplify acl management by grouping similar objects together
-eg : public_web_servers_group
Allows for more modular changes
- change to object group affects all ACEs that reference the group
Four types of Object Groups
- protocol
eg tcp, udp,esp,gre etc.
- network
eg: ip address, subnet address etc.
- service
tcp and udp port numbers
- icmp type
echo, echo reply, unreachable etc.
Objects:
Added along with NAT changes in 8.3
Different than object-groups
Required for Object-NAT
Can contain a single entry/definition
- network
subnet, range, host
- service
protocol, tcp/udp source/destination ports
TCP/UDP ports can only be used in Twice NAT
Object groups vs Objects:
Object groups can contain one or more entries
Eg multiple hosts, ports etc.
Object can contain only one entry
Eg: single host, subnet, port, etc.
Why use both?
Object is called from both ACL and NAT in newer code
Allows NAT and ACL config changes to be synchronized
Eg: web server moves to a new internal address; change the object and both NAT and ACLs are updated.
HA
Rem: ASA HA doesn’t support equal cost multipath. It supports load balancing in single interface.
Link high availability
-dynamic routing
generic solution relying on infrastructure redundancy
-reliable static routing
tracing next-hop reachability
-redundant interfaces
building multiple physical interfaces
Node High availability
- failover
Redundant interfaces
Group multiple physical interfaces into one logical interface
-interface redundant [num]
Only one interface is active
-not like etherchannel in catalyst switching
Physical interfaces should only have physical parameters
- speed, duplex, no shutdown, etc.
Redundant interfaces has logical parameters
- nameif, security-level, ip address etc
Mac address taken from first member
- mac should be encoded manually.
ASA failover overview
ASA supports two types of failover
-Active/Standby
Active unit passes traffic
Standby unit waits
-Active/Active
Both units forward traffic
Only supported in multiple context mode
Different contexts active in same or different units
Active/Standby supports..
Single context mode routed firewall
Single context mode transparent fw
Active/Active Supports..
Multiple context mode routed fw
Multiple context mode transparent fw
Health Monitoring :
Failover polling detects unit failure
-timeout via failover polltime..
Interface fault detected by interface polling
-enabled by default for all interfaces but not for sub interfaces
-interface needs an ip address for monitoring
-define interfaces with [no] monitor-interface ..
-timeout by failover ppolltime interface..
Interface monitoring policy
-failover interface-policy {N/%}
-falover if this many interfaces have failed (1 by default)
Multiple context overview
System, admin and user contexts
Interface sharing
Classification rules
Context resources
Routing in multi context mode
ASA context modes
ASA supports two different context modes of operation
-single context mode
-multiple context mode (Virtual fw)
Single context mode:
-shared configuration for all interfaces, security policies, routing table, administrators etc.
Multiple context mode:
-separate configuration, interfaces, policies per virtual context
-allows for multiple virtual firewalls for managed services or policy separation
Separates ASA into multiple virtual firewalls
Each context is assigned
-Interface
physical or 802.1q subinterfaces
-resource limits
number of connections, hosts, xlates, etc
-Firewall policy
MPF inspections, ACLs, NAT, etc
When in multi-conetxt mode ASA supports..
-routed firewall
-transparent firewall
-Active/Active failover
primary forwards for one context
secondary forwards
In version 8, in multi-context mode ASA does not support …
-VPN termination
-dynamic routing protocols
-QOs features
Three types of context ..in multiple context
-system context
-admin context
-user defined context
System context
Used to create new contexts and define context parameters
-interface to context assignments
-resource allocation
-configuration file location
Allows changing between contexts for management
-changeto context [name]
initially only accessible via the console
Admin context
Used for remote access to system context
-only context that remotely supports changeto system command
Automatically created when multiple context mode enables
-used configuration fiel admin.cfg by default
Like other contexts, has no resources allocated by default
-for management access u must..
allocate an interface
assign nameif, security level, and ip address
enable telnet, ssh or ASDM access
User defines context:
Used for logical separation of traffic flows
Created under system contexts by ..
-specifying context name
-allocating interfaces
-alllocating resources
-allocating configuration file
All additional configuration occurs in the user context mode
-changeto context [name] form system or admin context
management connections to user defined contexts can only access themselves
-changeto command not available
Context interface allocation
Contexts can have interfaces allocated three ways..
-unique physical interfaces per context
-unique subinterfaces per context
-shared interfaces between contexts
eg shared outside interface
Physical interface parameters defined in system context
-eg speed, duplex, no shutdown
Logical interface parameters defined in admin/user context
-eg nameif, security-level, ip address , etc
Shared interfaces must conform to classifier rules
Context classification rules:
ASA must be able to associate inbound traffic with the correct context
Three possible ways to classify traffic..
-unique physical interfaces or subinterfaces
-unique mac address per context for shared interfaces
shared interfaces use same mac address by default
make address unique with ..
. mac-address auto command in system context
. interface level mac-address in user contexts
-uniques NAT translation per-context for shared interfaces
Static or Dynamic NAT/PAT
. Allows for overlapping inside addresses between contexts
. Outside address must still be unique per context
-identity nat
.inside and outside addresses must be unique per context
Context resources
Resources can be limited on a per context basis
-connections
-translations (xlates)
-mac addresses
-management sessions
Critical if you have licensing limitations
Resources defined by class in system context
-limit-resource [ASDM | All | Conns | ..]
Assign resource class in context subconfiguration mode
-member [class]
Multiple context configuration
Enable multiple context mode
-# mode multiple
-requires reboot and configuration erase
Define contexts
-ASA(config) # context ABC
Assign interfaces to context
# allocate-interface
Specify configuration file storage
# config-url
Complete configuration in user context mode
# changeto context ABC
ASA/ABC#
Active/Active Failover
In this 8.0 limitation is either all the modes should be in routed or in transparent. There cannot be mismatch
One unit is active for group of contexts
Another unit is active for a different group of contexts
Uses the concept of failover groups
Define in system context
There are only 2 failover groups, it makes no sense to have more
Admin context is always member of failover group1 and its non-configurable
ASA Firewall modes :
Routed Firewall
-Interfaces are in different subnets and different VLANs
-Traffic is layer3 routed between interfaces based on routing table
Transparent firewall
-Interfaces are in same subnet but different VLANS
-traffic is layer2 bridged between interfaces based on CAM table
limitations
-VPNs not supported for transit traffic
supports local management via site-t-site IKEv1/IKEv2 Ipsec tunnel
-Only static routing supported
eg default route
-multicast IP routing
multicast traffic can be allowed through ACL
-Qos not supported
-DHCP relay agent not supported, but DHCP server is
Inspection engine works as in routed mode
Before 8.4
-maximum two interfaces/vlans used for bridgingg traffic
-one additional interface/vlan used for failover
-mgmt interface can be dedicated for mgmt.
-global ipv4 address required for ipv4 traffic to be beidged, optionally configure the mgmt. interface with IPv4 address
After 8.4
-Interfaces can be paired into bridge-groups
-No direct traffic allowed between bridge-groups, similar to multi-context mode
-Maximum 8 bridge-groups supported with maximum 4 interfaces per bridge-group
-Mgmt int can be dedicated for management
-eacj bridge-group requires an IPV4 address to bridge IPv4 traffic, optionally configure the mgmt. interface with IPV4 address.
Starting with 8.2 IOv6 trafffic supported in transparent mode
-link local ipv6 address is good enough for ipv6 traffic bridging
ASA Transparent Firewall
Traffic forwarding policy differs from routed firewall
Inside to Outside
-high security to low security level
-permit ARP
-permit broadcasts
-permit inspected unicast
tcp, udp, default inspection class
-most control plane protocols denied
ospf, eigrp, pim, cdp, vtp, etc
use ACL deny logging if you are not sure
Outside to Inside
-lower security to higher security
-permit return of inspected traffic
most control plane protocol are not inspected
-deny all others
ACL exceptions may be needed for inside to outside as well as outside to inside
-ethertype ACLs needed to permit non-IP packets
-ethertype ACLs are not stateful
-ARP and BPDU are allowed by default
Transparent fw config 8.4
Enable transparent fw
-[no] firewall transparent
Enable interfcaes
-no shutdown
Assign names
-nameif [name]
Assign security levels
-security-level [num]
Assign interface to a bridge-group
-bridge-group [num]
Configure bridge-group ip address
-interface BVI [num]
-ip address standby
Configure optional mamangement
-interface mgmt0/0
-management-only
-nameif [name]
-ip address standby
Transparent fw and NAT
NAT is supported in transparent fw mode as of 8.0.2
NAT caveats..
-inside and outside are on the same IP subnet
-translation to pool not on the subnet is supported, but routing must be taken into account
-interface PAT is not supported because there is no interface IP address
-ARP inspection not supported.
No comments:
Post a Comment