TacAck – My security journey!

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