Zone Based Firewall Lab Tips

  • Define Zones – zone security WORD . This is where you define the zone. think of it as a container.
zone security IN (unique name)
zone security OUT (unique name)
  • Classify the Traffic – class-map type inspect WORD. Using MQC Logic and Class Maps to classify the traffic
class-map type inspect match-all HTTP (unique name)
 match protocol http
  • Define the Inspect Policy – policy-map type inspect  WORD. Using MQC traffic to specify how to treat the classified traffic. Here we are treating as a CBAC with the INSPECT key word. Other actions can be PASS, DROP etc
policy-map type inspect OUTBOUND_TRAFFIC (unique name)
 class type inspect HTTP (name of class-map above)
  inspect
  • Associate the Policy to the Zone to a Pair and specify the Service-Policy – Here we are saying what zones will be associated with this ‘security rule’
zone-pair security OUTBOUND (unique name) source IN (name of Zone above ) destination OUT (name of zone above)
 service-policy type inspect OUTBOUND_TRAFFIC (name of Policy-map above)
  • Associate the interfaces to a zone. Here we will specify what interfaces are what members of the zones we have defined.
interface Ethernet1/0
 zone-member security IN

interface Serial1/0
 zone-member security OUT
  • Verification 
show policy-map type inspect zone-pair session  This will show what is hitting the policy and what is defined
show class-map type inspect This will show all the class maps defined
show policy-map type inspect This will show the policy map actions against the class maps
Advertisements

Local Authorisation Lab Tips

  • Must grant ‘confiiguration‘ access for relevant components to show up in the running-configuration.
  • As long as they do not have access to conf t then allowing configuration access to other components will not matter and therefore will show up in the show run without letting them access it.
  • Verify with show privilege.

(config)#enable secret level 2 CICSO ——-> (prompts for password CISCO)

(config)#privilege exec level 2 show run ——-> (allows level 2 to issue show run)

(config)#privilege configure level 2 hostname

  • (allows level 2 to configure hostname, however as there no conf t access, this will only show up in show run

Reflexive Lists Lab Tips

  • Allows traffic from INSIDE > OUTSIDE to return back via the evaluate #TAG# command. This is the ACL applied inbound on the outside interface.
  • evaluate #TAG# command looks at the access list for traffic going out. This is the ACL applied outbound on the outside interface and uses permit traffic reflect #TAG#. e.g. permit tcp any any reflect MY_REFLECT
  • Generally apply these to the ‘outside’ interface to control both ‘outside’ and ‘inside’ interfaces. So anything in the ACL_OUT will then be inspected by the evaluate #TAG# in the ACL_IN and create dynamic ACL to allow that traffic in.
  • Verify by doing show ip access-list MY_REFLECT (#tag#) – You will see the dynamic ACL entry providing that you have triggered it.
  • If TCP traffic, such as Telnet, is allowed out then you may need to use the established key word in the ACL_OUT as this simulates a stateful inspection and will allow the return traffic based on the ACK bit.

IP Access List Written Notes

These are my ‘crib notes’ that I’ve made to serve as a last minute refresher. Please forgive the grammer / spelling as I did not develop these notes with publishing in mind

IP Access Lists

*** Theory ****

  • Access List: Runs top to bottom. Implicit deny at the end at stop at match like a FW. Put common rules at top for lesser overheads.
  • Standard list – Need to place as close to the destination router
  • Extended List: uses more specifics but more overheads and close to the source as possible. Extended is better as  it doesn’t waste bandwidth by going all the way to the destination
  • Named Access Lists: puts sequence numbers in access lists so you can add and remove when needed
    • Use “ip” so, ip access-list extended DEMO then hit return1
  • Dynamic Access List: access list that requires user to authenticate.
    • Access-list 101 permit tcp any host 192.168.1.3 eq telnet
      • Need to telnet in and authenticate
  • Access-list 101 dynamic DEMO timeout 120 (cuts them off even not idle) permit ip any any
  • Line vty # autocommand access-enable host timeout 1
    • Without the host keyword, it will allow the whole subnet through! Becareful!
    • Timeout is idle timeout
    • Time based access list: Can set a time
      • Config# time range HTTP_LUNCH
      • # absolute
      • # period – allowes for a number of times e.g. every Monday to Friday 12pm to 1pm
      • Then add time-range command to the access list

 

IPSec Crib Notes

These are my ‘crib notes’ that I’ve made to serve as a last minute refresher. Please forgive the grammer / spelling as I did not develop these notes with publishing in mind

IPSec

*** Theory ***

  • VPNs
    • Data origin ,e.g. AH, ESP
    • Encryption
      • (S) Symmetric Encryption – Same key for enc/decryption. Aka secret key.
      • (A) Asymmetric Encryption – 2 keys. Public and Private.  Encrypt with public, decrypt with private. Private always stay local.
      • DH – Allows the exchange of secret keys over a non-secure connection
        • (S) DES is 56bit
        • (S) 3DES is 3 DES keys on top of each other. So 3 x 56 = 168bit (really 112)
        • (A) AES is the best.
  • Data Integrity AH, ESP
  • Anti replay AH, ESP
    • Mitigate via sequence number on packet.
    • GRE – Encapsulate packet in an IP header. Has no encryption. GRE is multiprotocol. IPSec is really IP only. So GRE over IPSec makes sense.  Can use GRE to send routing protocols over IPSec etc. GRE Encaps first then IPSec encaps
    • L2TP/PPTP – No encryption
    • IPSec – Earlier versions could not carry multicast traffic.
      • Tunnel Mode – Transparent to end host
      • Transport Mode
      • AH (Protocol 51) – Method for authentication and securing data (protects payload of packet. AH less overhead than ESP
      • ESP (protocol 50) – It authenticates, secures and encrypts. Preferred over AH
      • IKE (UDP 500) – negotiates the security parameters and authentication keys
        • Phase 1 – Agreement on methods to exchange data aka SA (Security Association). 1 SA per tunnel.
          • Aggressive Mode – Faster, but not encrypted. 3 Messages,
          • Main Mode – 6 messages. R 1 “DES or 3DES? MD5 or SHA?” R2 “DES and MD5 please” etc DH Keys, Authenticate
    • Phase 1.5 – Known as XAUTH for security
    • Phase 2 – 2 SA per 1 tunnel.
      • Quick Mode – 3 messages
      • Crypto Access List – Defines interesting traffic that starts the IKE/ IPSec process
        • Steps on Cisco Router
          • 1) Create ISAKMP policy 2) Create IPSec transform set 3) Define interesting traffic with crypto access-list 4) Create Crypto Map and apply to interface
      • Dead Peer Detection (DPD) – Keepalive for IPSec.  Sends hello every 10 seconds unless it receives a hello from peer. This means overhead because of enc ry/decryption. Can use on-demand where router sends DPD hello only prior to sending data to peer.
        • Troubleshooting
          • MM_NO_STATE – Phase 1 attribute mismatch
          • MM_KEY_EXCH – Incorrect pre-shared key or peer IP address