I’m going to miss Marvin Here are the notes for the final day of the bootcamp .

My Grandmom passed on yesterday. She was 93 and she passed away painlessly. She lived a full life and she’s with her maker. Love you gran :*

After this , i got back on the CCIE bus and i finished Day -4 of the bootcamp. Again a very productive day. Here are the notes :

MANAGEMENT – PART 1

• Port filter service policy takes care of “early” drop of traffic to closed/ non listed ports. This ensures that the packets don’t have to go till the CPU to get dropped ( saves resources )
• Logging type class-maps match packets that are permitted / dropped.
• IP-options traffic is always sent to the control-plane( processor )
• Control Plane Protection
  • host subinterface : Routing traffic destined to the router,etc
  • Transit subinterrface : Non – terminating tunnels,etc
  • CEF exception subinterface : ARP, L2 keepalives ,etc
• Ensure that during policing , we don’t misconfigure the “burst” value (I’ve done this before )
• Ensure that when configuring droppping traffic going to closed-ports, ensure that all the necessary ports that we need are open.
• FPM
  • PHDF -> Protocol header definition file
  • If we don’t load the PHDF files, we won’t have access to the protocol structures, we have to match using offsets from L2 , L3 start, etc
  • Use nested policy maps judiciously
  • Do not change the current directory that you are working on using the “CD” command ( ‘coz after reloading you always go back to the original directory. So for “load protocol” command, use the full path of thePHDF files.

MANAGEMENT – PART 2

• SNMP v3
  • Additional security features compared to v1 and v2
  • Version 1 , communities, ACL’s
  • Version 2 has views as a security feature
  • v3 adds the different security levels.
    • noAuthnoPriv
    • AuthNoPriv
    • AuthPriv
  • SNMP v3 has groups defined. Individual users within a group have different credentials
  • Sample config
    • access-list 99 permit 10.0.0.100
    • snmp-server view NORMVW iso included
    • snmp-server view RESTVW ifENTR.*.3 included
    • snmp-server group NORMGRP v3 priv read NORMVW write NORMVW
    • snmp-server user NORMUSER NORMGRP v3 auth sha CISCO priv des56 CISCO
  • For the write and notify views, without a view configured, we can’t access the views (unlike the “read” view which is read everything by default )
  • Notify view gets autogen after the “snmp-server host” command
  • Note : the user information doesn’t come up in the “sh run “
  • RMON
    • custom Log, trap intries based on SNMP values
    • Under the “Technologies” section of the DocCD
• FLEXIBLE NETFLOW
  • flow monitor TEST
  • statistics packet protocol
  • statistics packet size
  • record netflow ipv4 protocol-port-tos
  • int fa 0/1
  • ip flow monitor TEST output
  • This is more granular than the old netflow ( Read more )
• IP ACCOUNTING
  • int fa 0/1
  • ip accounting output-packets
• ASA CAPTURE
  • Can look at traffic real-time
  • check what the order of the flow-capture events are

IPS

• Ensure that SPAN /RSPAN is configured on the switches correctly.
• Ensure that the RSPAN VLAN is allowed in the trunk between the swxs
• In Inline VLAN pairs, you don’t have to configure SPAN.
• Ensure that the traffic flow the IPS to the AAA server is allowed. ( HTTPS ACCESS )
• Ensure that if the management network is translated, then permit that translated address in the IPS

IOS IPS

• We use the 5.x signature formats
• Even if the -package is present locally, don’t forget to copy it onto IDCONF
• And remember to setup the key information prior to copying the pacage to the IDCONF
• The ASA IPS configuration is not on the blueprint

One more day to go!

Cheers,

TacACK

Hey!

Day 3 of the bootcamp is DONE. I’m glad i started this bootcamp , ‘coz there are many things i’m learning as i go along. Here are Day 3 notes!

GETVPN

• IP Header preservation
• Protocols used
  • UDP 848 -> GDOI
  • Protocol 50 -> ESP
• It keeps the original header and ecrypts only the payload
• So the intermediate routers will see the packet with a source of the original host who sent it and the destination as the destination router ( not the IPSEC peers )
• Make sure that we permit this traffic ( ‘coz this is a little different from theconventional VPN methodologies )
• The concept of KS and GM’s help reduces misconfiguration.
• In a L2L VPN, we see two separate unidirectional SPI’s in each IPsec peer, here we use 1 SPI
• If there is a change in the SA information on the KS, then the KS can push out these configurations to the GMs immediately. It won’t till the rekey timer expires.
• Ensure that the rekey messages are also allowed by the firewalls/routers in between the KS-GM
• Double check rekeying
• We need to have 2 ACL’s for each pair, for both directions.
• The “server address” order under the GM configuration defines who is primary and who is the failover
• GETVPN also supports multicast traffic encryption

WEBVPN & SSL VPN

• ASA Webvn structure
  • • WEBVPN
      • enable outside
      • tunnel-group-list enable
    • GROUP POLICY
    • TUNNEL GROUP
    • If using local authentication add this to the username attributes
    • username <test> attributes
      • service-type remote-access
  • TIP : Use a “sh run all”
    • SSLVPN extendeds WEVPN by allowing an SVC to be downloaded automagically.
    • Uses normal RRI / Address allocation like EZVPN
    • #webvpn
      • #enable outside
      • #tunnel-group-list enable
      • #svc image <path>
      • #svc enable
    • #group-policy
      • #vpn-tunnel-protocol webvpn
      • #split-tunel-policy..
      • #split-tunnel-network-list value [acl]
      • #webvpn
      • #svc required < Forces users to download the SVC >
    • #tunnel-group
      • #default-group-policy
• IOS SSL VPN structure
  • GATEWAY
    • termination info, etc
    • Trustpoint
  • CONTEXT
    • Terminates VPN / establishes user session
    • contains user policies
  • POLICY GROUP
    • Set policy information
  • DEFAULT GROUP POLICY
  • Don’t forget the “inservice” commands to turn on the various configuration elements
  • Even if we don’t generate the trust point for the gateways, it would be self-generated.
  • We use the “domain” keyword after the “gateway < gateway > in the context configuration ”
    • This is used to differentiate users logging into the same gateway.
    • Suppose we use the command “gateway gateway1 domain INE”
    • Then the users connecting to the gateway will have to use ” https://<GATEWAY IP>/INE”
    • This way we can use the same gateway for more than 1 contexts
  • To turn on SVC , we use “functions svc-enabled” under the policy-group configuration
• Ensure that in the real-lab, always use a Split tunnelling ACL when trying to connect from the Test-PC ( ‘coz if you don’t have any, you might lock yourself out )
• Enter the “set isakmp-profile” command under the “crypto ipsec profile” configuration

AAA PASSWORDS/PRIVILEGES

• The user needs to be at a level “higher or equal” to the command level, to be able to run it
• “sh run” will only sh commands that you have permission to configure. This is assuming we have permission to run “sh run” to in the first place
• If we have just a “username xxx privi 7 password cisco” ( without any aaa new-model ), the user would be authenticatied and authorized locally , and he would be set at privi 7.
• If we ‘ve configured the aaa-newmodel, then authentication and authorization is done separately.’coz separate commands are now needed.

ADVANCED AAA

• On the actual lab, the access to the AAA server , would be via browser only ( we woulnd’t be able to RDP into it )
• Dynamic ACLs are not scalable , “access enable” opens up all dynamic ACL
• Using auth-proxy, per-user-ACL’s can be put into place.
• AUTH-PROXY
  • User should be denied access via a Static ACL
  • Make sure you don’t lock yourself out after configuring “AAA authentication” . Try and insert a local fallback in the authentication command
  • Use the command “aaa authorization auth-proxy”
  • Enable the HTTP server
  • Deny all traffic inbound , except the traffic which you need to trigger the Auth-proxy
  • Specify the triggerring ACL and add it to the “auth-proxy” command, and don’t forget to turn pn auth-proxy on the interface
  • Remember the issue regarding local auth-proxy ( read blog )
  • For radius, we use the Cisco AV Pairs : “auth-proxy : priv-lvl = 15 “, etc. The only difference between RADIUS and TACACS+ is the “auth-proxy” keyword
• CUT-THRU-PROXY
  • IN ASA , using HTTP/HTTPS , FTP , TELNET , the asa can do in-line cut-though for these protocols
  • For others, we cannot do the authentication in-stream.
  • If you wanna add ACL entries in the “outside” acl, then we need the “per-user-override” acl
  • For inside to outside, you just need the authentication, no need for acls
  • Must configure this
• ASA-LDAP
  • Configure the LDAP server
  • aaa-server test protocol ldap
  • aaa-server test host 10.0.0.100
  • <parameters>
  • Attribute map
    • ldap attribute-map MYMAP
    • Is used to determine what group a user gets put into, based on the group-membership returned from the LDAP server
    • We then apply the LDAP attribute map to the LDAP server configuration
    • Based on the different group-policies specified in the Attribute map, we should configure different group-policies on the ASA

Next, Day 4!

Cheers,

TacACK

Done with day 2!   I was wrong, totally wrong, when i started the bootcamp thinking that this would not be useful . I am learning every minute of this bootcamp and i’m really happy i decided to try it out !

Here are the notes for Bootcamp- Day 2 . Hope you find it useful

ZONE BASED FIREWALL

• An interface can only be in a single zone
• Unless we have a policy on the self-zone, the default behavior is that the traffic destined to the router, is permitted
• Traffic cannot flow between a zone-member and a non zone-member
• The ZPF service policies have the following actiobns
  • pass -> permit unidirectional traffic
  • inspect -> stateful inspection
  • drop -> block
• You can’t configure SPI(CBAC) and ZPF for the same set of interfaces. But you can do it for different sets
• Auth-proxy and stuff arent supported by the ZPF, they’re still done using SPI
• IN ZPF, if we have interface ACL’s, then the ZPF doesn’t open “pinholes’in them. If the ACL’s are configured for block, then the traffic is blocked.
• We use a class-map of the type “inspect” to tell the IOS that this is a class-map to be used with ZPF
• You can test by putting both the interfaces in the same-zone ( all traffic will be permitted )
• Understand the difference between ” sh ip port-map ” and “sh ip nbar port-map”
• By specifying an ACL at the end of the “ip port-map ” command, we can specify the destination IP which has to be accessed using the special ports
  • ex : ip port-map http port tcp 8080 list 10
• For overriding the default port, we require a host-specific PAM mapping
  • ex : access-list 10 permit host 192.168.1.1
  • ip port-map http port 25 list 10
• Here, only for host 192.168.1.1 , HTTP runs on tcp port 25
• After I finished this section, I read this document. It was very helpfulJ http://www.cisco.com/en/US/docs/ios/sec_data_plane/configuration/guide/sec_zone_polcy_firew_ps6441_TSD_Products_Configuration_Guide_Chapter.html#wp1055217

IPSEC VPNs

• Why IPSec VPNs over other type of VPNs?
  • Does not need static SP provisioning like FR/ATM/MPLS
  • Independant of SP access method
  • Allows both site-to-site and remote-accesss ( IPsec is always on, v/s dial-on-demand )
  • Data is protected. ( main motivation )
• IPSec as a suite offers
  • Data origin authentication
  • Data integrity
  • Data confidentiality
  • Anti-replay
• The advantage of using UDP 500 for both the source and destination ports, is useful during NAT-D
• ISAKMP peers must agree on
  • Authentication method
  • Encryption type
  • hash algo
  • DH group
• Lifetimes need not match ( the lower one is dynamically chosen )
• Remember, the phase 1 config is only used to setup a secure channel through the network for the exchange of IPSec configuration data.
• Default policy : 65535
• IPSec peers ( IPSec sa a.k.a IKE Phase 2 ) must agree on
  • Transform set to match
  • In an L2L Vpn, the VPN_ACLs are exchanged and they need to match.( they need to be mirror images of each other )
• Do not use “any any” for the ACL. Always try and specify the exact networks
• IPSec SA rekeying can also include PFS
  • Runs another DH exchange ( more secure )
• During configuration on the lab, make sure that the traffic ( both UDP 500 and ESP ) between the 2 VPN routers passes freely .( take care of any Firewalls , IOS FW , SPI configured in previous tasks )
• Ensure that we can have the VPN initiate from both sides ( testing before moving on to the next task. If you have a doubt, as the proctor )
• Certificate based authentication
  • If Certificate based Authentictation is’nt working, try doing PSK auth and see if it works
  • When using certificates for ISAKMP authentication, ensure that CA server (port 80) is reachable by the clients and ensure that the time is synced.
  • If you don’t have NTP, ensure that the client is set to a time, slightly ahead of the server. ( if you can’t exactly sync them )
  • Also check the time-zones

MISCELLANEOUS FEATURES

• Advantage of using GRE for VPN’s -> passing multicast(routing) traffic
• Disadvantage -> Overhead
• Solution -> VTI
  • also better interop with other vendors not supporting GRE
  • less overhead
• Dynamic VTI
  • virtual template configured with interface type “tunnel”
  • The virtual template acts as a logical interface
• In case of ZBF, the virtual template can be assigned to zones ( this just acts like a normal interface )
• IPSEC HA
  • Link resiliency
    • If i have 2 devices, and 2 links between them, if one fails, traffic can flow through the other links
  • Backup peers
    • if one peer fails, the secondary peer is used
  • HSRP / RRI
    • if this is configured, then the HSRP address is used instead of the peer IP.
  • GRE w/IPSEC, dynamic routing
• QOS for VPN
  • QOS for encrypted traffic
    • This is the default type of QOS
  • QOS for unencrypted traffic
    • we use the QOS pre-classify configured on the virtual template, crypto map or GRE tunnel to classify the traffic prior to encryption
• We can encrypt the ISAKMP keys ( to prevent them from being seen in the running-config in plaintext)
  • “password encryption aes”
  • “key config-key password-encrypt”
• Encrypts the ISAKMP keys using Type-6 AES
• We can also configure Certificate MAPS to ignore revocation checks as well as expired certificates. This can be configured when we “match” the certificate MAP under the trustpoint
  • match certificate TEST allow expired-certificate
  • match certificate TEST skip revocation-check
• This scenario is useful when the CA to be used by one peer is behind the remote-peer and it can be reached only after establishing the VPN
• In this situation, we can configure the certificate MAP to allow expired-certificates,ignore revocation checks
• Clearing the DF bit
  • We can set/clear the DF bit on the IPSec traffic ( to allow/deny fragmentation of the traffic )
  • This is for the traffic passing through the Router
  • can be done globally or on an interface
• Fragmentation
  • We can fragment before/after we encrypt
    • Depends on who has to do the reassembly / decryption
      • if we fragment before encryption, at the other end the little fragmented packets get decypted and sent on to the remote-networks
        • crypto ipsec fragmentation before-encryption
      • if we fragment after encryption, then the other end ( remote peer ) has to do both reassembly and decryption
        • crypto ipsec fragmentation after-encryption
• Anti-replay
  • Keeps track of sequence numbers. Default window size is 64
  • crypto ipsec security-association replay [disable | window size XX ]
  • (or )
  • crypto map MYMAP
    • set security-association replay [disable | window size XX ]

DMVPN

• It allows an on-demand full mesh IPSec tunnels
• Instead of n*(n-1)/2 static tunnel configurations, we have 1 mGRE interface for all connections
• Always remember, ISAKMP Phase 1 is still required.
• In case of the HUB mgre interface, we have Tunnel source.
• If we wanna force all the spokes to send traffic through the HUB ( DMVPN type 1 ) , then we can also specify the tunnel destination
• The IGP which we will be using here is an OVERLAY network ( independant of the real routing protocols running in the network )
• If you’re using OSPF , use the same network types for the hubs and the spokes
  • if there is a DR election, ensure that the Hub becomes the DR.
  • This is achieved by setting the “priority” to 0 on the spokes.
• With EIGRP
  • One of the issues is split-horizon , on the mgre interface . Issue the “no ip split-horizon eigrp # “
  • Hub by default re-writes the next-hop for all the advertised routes to itself.
  • So if we want spoke-to-spoke tunnels, disable this feature by using ” no ip next-hop-self eigrp # “
• Phase 3 DMVPN
  • Configuration
    • ip nhrp redirect
    • ip nhrp shortcut
  • creates NHRP entries for remote networks
• Interesting traffic
  • we can define an ACL on the tunnel interface, this sets up interesting traffic for the NHRP requests ( restricting what traffic can bring up a spoke-spoke tunnel )
    • ip nhrp interest 101
• Groups
  • ip nhrp group A ( spoke )
  • ip nhrp map group A service-policy output TEST ( hub )
  • can have separate service policies configured outbound for different hosts.
• Watch out for recursive routing issues.

Day 3 , here i come!

Cheers,

TacACK

Hello all!
I’m really excited! ‘coz i’m finally doing the bootcamps that i purchased a couple of months back . I started the bootcamp yesterday and i went through Day 1 and i took notes on WAVE.I must say, i was pleasantly surprised by the content covered on the first day. I expected it to be very basic, but Marvin did dive into some advanced stuff ( but no configuration ).

Here are the notes and i hope you find them useful :

ASA

• Make sure you don’t block traffic flows as we configure tasks ( don’t screw up earlier tasks )
• Marvin’s of the opinion that it’ll mostly be 8.0 running on the ASA on the lab
• It’s a good idea to read through the lab once before we start configuring ( helpful in changing firewall modes, contexts ,etc )
• Add a “description” on the catalysts if necessary ( to identify the interfaces connected to the switch ). Make this a habit. ( helps )
• Redundant interfaces
  • Multiple interfaces grouped together
  • order of configuration determines preference
• We can use both Subinterfaces and the real interface on the ASA. In case of the sub-interfaces ( e 0/1.100 VLAN 100 ), the ASA would send the packets with a dot1q tag on, in case of the interface with the actual interface ( ex : e 0/1 ), it would send it untagged.
  • So we have to program the switch to accept untagged packets in the trunk link. This can be done using native-vlans.
• Addresses, protocols and ports can be found under the “references section” of any Configuration guide for 8.X . This is cool!
• Draw out network flows for protocols running in the network to visualize what needs to be allowed.
• Routing protocols
  • ASA supports the following routing protocols :
    • static
    • Rip v1/v2
    • OSPF
    • EIGRP
  • Different OSPF areas in a firewall, can be configured under a signle process or multiple processes
  • Configuring them under one process will alow routing information to pass from one OSPF area to the other freely
  • configuring them as 2 separate processes, will logically isolate the areas. To exchange routes, we need to explicitly redistribute.
  • So be careful when you configure them under 1/separate OSPF processes.
  • Having an exact OSPF match, can be a good thing to check if we have configured the addresses correctly.
• NAT
  • Nat 0 -> Nat exemption
  • Options in NAT configuration
    • TCP/UDP maximum connection limits
    • TCP Half-open connections
    • DNS rewrite
    • Disable randomizing sequence numbers
  • By default, NAT-control is disabled.
  • NAT-control only applies for traffic between 2 interfaces of “different” security levels.
• In transparent firewall, TCP , UDP traffic is inspected by default
• “allocate-interface redundant1.3 int1 ”
• There are sample ASA configurations under the “references”section in the ASA configuration guides! -> AWESOME!
• Good practice is to save the config in a notepad file before we start Failover configuration.

IOS F/w

• The log-input command in ACL logging , logs the following info
  • list name/number
  • permit/deny
  • protocol name/number
  • source/destination IP
  • port numbers
  • MAC addresses
  • Input VC
• The first 5 are also logged when you do the “log” option instead of log-input
• The routing protocols use a “distribute-list” to filter routes
• The autocommand for Dynamic ACL’s configured on the LINE VTY 0 4 lines, blocks also legitimate management traffic
• By using the “host” keyword, the “any” in the source address portion of the ACL is replaced by the host that underwent the authentication.
  
• Thing to remember is “reflexive” ACL’s don’t wory for locally generated trarffic
• So we need to statically permit required traffic back in
• or configure local policy-routing
• we can use the “router-traffic” keyword in the CBAC inspect commands, to inspect locally generated traffic

I’m going to be starting Day 2 of the bootcamp in about 30 mins . Surf with me on the WAVE

Cheers,

TacACK