Pages

Monday, July 6, 2015

CCIE Security Notes

-->
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