This blog was originally started to better help me understand the technologies in the CCIE R&S blueprint; after completing the R&S track I have decided to transition the blog into a technology blog.

CCIE #29033

This blog will continue to include questions, troubleshooting scenarios, and references to existing and new technologies but will grow to include a variety of different platforms and technologies. Currently I have created over 185 questions/answers in regards to the CCIE R&S track!! Note: answers are in the comment field or within "Read More" section.

You can also follow me on twitter @FE80CC1E


Saturday, June 28, 2014

DNS Packet

The Naked DNS Packet







The above shows the DNS Opcodes in a DNS request.








Additional insight into the packet - As you can see that the DNS server responding was not authoritative and supported recursion.

Sunday, January 12, 2014

The Journey Starts 2014 - CCIE Security - Blog Post1

Well it is time to buckle down and make it happen in 2014. The goal is to become a dual CCIE by the end of 2014. I have previously passed the CCIE Sec written in version 3 but I did not have the time to actually sit for the lab and I also wanted to refresh to the latest version of the track. That said I am taking a small step back to refresh and reinforce the theory. The plan is to go through the NP Security track while labbing but also taking the respective NP exam followed by the written and then ultimately sit for the lab.

Here is the order as it stands today:
  • 642-627 IPS - Implementing Cisco Intrusion Prevention System 
  • 642-618 FIREWALL - Deploying Cisco ASA Firewall Solutions 
  • 642-648 VPN - Deploying Cisco ASA VPN Solutions 
  • 642-637 SECURE - Securing Networks with Cisco Routers and Switches
  • ISE and WSA 
  • CCIE Written 
  • CCIE Lab
The primary partner that I am leveraging is CiscoPress and Cisco Docs for the theory and iPexpert for all the heavy labbing. 

The great thing about this journey is that I already eat, sleep, and breath Cisco .:|:.:|:.

Twitter: FE80CC1E

Wednesday, November 27, 2013

ASA-CX - 15 Minutes to Configure ASA-CX in a PoC

Just finished building/validating a ASA-CX PoC script. Ran 27K web sites through it using a script on BT5R3. 15min and I was up and running.

Sceenshot of PRSM and Backtrack5 running the script
























In the future I may posts the steps required to get this up and running.

Saturday, July 6, 2013

Control Plan and Data Plan - Answer provided by Keith Barker

I came across this great answer to a question from Keith Barker and felt it needed to be shared. Great analogy Keith.


Hello Vijay-

Great question.

Let's say you and I are in charge of public transportation for a small city.

transportation routes.gif


Before we send bus drivers out, we need to have a plan.

Control Plane = Learning what we will do


Our planning stage, which includes learning  which paths the buses will take, is similar to the control plane in the network.   We haven't picked up people yet, nor have we dropped them off, but we do know the paths and stops due to our plan.  The control plane is primarily about the learning of routes.

In a routed network, this planning and learning can be done through static routes, where we train the router about remote networks, and how to get there.   We also can use dynamic routing protocols, like RIP, OSPF and EIGRP to allow the routers to train each other regarding how to reach remote networks.   This is all the control plane.

Data Plane = Actually moving the packets based on what we learned.


Now, after the routers know how to route for remote networks, along comes a customers packet and BAM! this is were the data plane begins.   The data plane is the actual movement of the customers data packets over the transit path.   (We learned the path to use in the control plane stage earlier).

Best wishes,

Keith



The original post can be found here https://learningnetwork.cisco.com/thread/33735

Monday, June 17, 2013

RFC 3330 Filtering Using Network Objects

RFC3330 Special-User IPv4 Addresses

Below is a list of special use IPv4 address assigned by IANA and should be blocked inbound on external connections. Most security administrators block RFC1918 but do not realize that RFC3330 includes special use addresses that should not be traversing the internet. RFC3330 includes addresses referenced in multiple RFC's including RFC1918.

   Address Block             Present Use      
   --------------------------------------------------
   0.0.0.0/8            "This" Network              
   10.0.0.0/8           Private-Use Networks                  
   14.0.0.0/8           Public-Data Networks        
   24.0.0.0/8           Cable Television Networks                
   39.0.0.0/8           Reserved but subject to allocation                              
   127.0.0.0/8          Loopback                      
   128.0.0.0/16         Reserved but subject to allocation                              
   169.254.0.0/16       Link Local                                
   172.16.0.0/12        Private-Use Networks                  
   191.255.0.0/16       Reserved but subject to allocation
   192.0.0.0/24         Reserved but subject to allocation
   192.0.2.0/24         Test-Net
   192.88.99.0/24       6to4 Relay Anycast                    
   192.168.0.0/16       Private-Use Networks                
   198.18.0.0/15        Network Interconnect Device Benchmark Testing          
   223.255.255.0/24     Reserved but subject to allocation                          
   224.0.0.0/4          Multicast                          
   240.0.0.0/4          Reserved for Future Use


To block these addresses on an ASA you can leverage network objects. See below:

CREATE OBJECT GROUP
"object-group network RFC3330"
   "network-object 0.0.0.0 255.0.0.0"
   "network-object 10.0.0.0 255.0.0.0"
   "network-object 14.0.0.0 255.0.0.0"
   "network-object 24.0.0.0 255.0.0.0"
   "network-object 39.0.0.0 255.0.0.0"
   "network-object 127.0.0.0 255.0.0.0"
   "network-object 128.0.0.0 255.255.0.0"
   "network-object 169.254.0.0 255.255.0.0"
   "network-object 172.16.0.0 255.240.0.0"
   "network-object 191.255.0.0 255.255.0.0"
   "network-object 192.0.0.0 255.255.255.0"
   "network-object 192.0.2.0 255.255.255.0"
   "network-object 192.88.99.0 255.255.255.0"
   "network-object 192.168.0.0 255.255.0.0"
   "network-object 198.18.0.0 255.254.0.0"
   "network-object 223.255.255.0 255.255.255.0"
   "network-object 224.0.0.0 240.0.0.0"
   "network-object 240.0.0.0 240.0.0.0"

CREATE ACCESSLIST
"access-list outside_inbound deny ip object-group RFC3330 any"

APPLY ACCESS CONTROL LIST TO THE INTERFACE - (Note: you can also be a good internet citizen and block these addresses outbound). In this example we are preventing RFC3330 inbound on the outside interface
"access-group outside_inbound in interface outside"

If you use the above remove the quotes.

Sunday, April 21, 2013

HP Route Preference (Administrative Distance)

When building networks leveraging a variety of products you need to consider interoperability and configuration consistency. When leveraging HP A-Series switches in a Cisco environment considerations need to be made in regards to administrative distance (Cisco's term) or route preference (HP's term). In order to ensure that you maintain consistent behavior it is recommended that you modify one or the other and make them consistent with each other. I would recommend following Cisco's administrative preference instead of HP's route preference.

HP's default route preference



Cisco's default administrative distance


Don't get caught with unexpected routing behaviors. Have fun!

Sunday, March 24, 2013

IDP - FN, TN, TP, FP

I have talked with a few security administrators that seem to struggle with the understanding of FN, TN, FP, TP. I have decided to try to create a simple method to remember.

True/False = This either CORRECTLY or INCORRECTLY identifies an attack
Positive/Negative = This performs and event that takes an ACTION or is ACTION-LESS

True Positive (TP) - A legitimate attack (CORRECTLY) which triggers an IDP to produce and alarm/alert or mitigate the risk (ACTION)

False Positive (FP) - An IDP believes there is an attack taking place (INCORRECTLY) and produces an alarm/alert or mitigates the risk (ACTION).This can cause disrupt legitimate traffic and flood your IDP with alerts drowning real alerts that may be taking place. Some traffic that may cause false positives include:

  • Legitimate applications that do not follow RFC's 
  • Legitimate traffic in one part of an organization that may not follow normal behaviors in another part of the organization causing alerts. 
  • Signatures that we written poorly and identify both legitimate and illegitimate traffic. 

False Negative (FN) - There is an attack that has NOT been identified (INCORRECTLY) and no alarm/alert/mitigation was raised (ACTION-LESS). This causes a false sense of security. This can be caused for a variety of reason which may include:

  • Signatures miss variations or poorly written
  • Obfuscation of an attack on the fly -zero day
  • Overloaded IDP 

True Negative - (TN) No attack has taken place (CORRECTLY) and no alarm raised (ACTION-LESS).

Saturday, March 23, 2013

Testing AAA Authentication with ACS - Part 1

Confirming that local authentication on the switch and ACS is working after you finished your configuration perform the following:

Run the "test" command on the switch
sw1#test aaa group tacacs+ ro PASSWORD legacy
Attempting authentication test to server-group tacacs+ using tacacs+
User was successfully authenticated.

sw1#test aaa group tacacs+ admin99 PASSWORD legacy
Attempting authentication test to server-group tacacs+ using tacacs+
User authentication request was rejected by server.

Even though the second attempt was rejected it still confirms that ACS rejected the request and is fully operational.

Step 1. Lets have a look at the ACS server. Once logged in navigate to "Monitoring and Reports" and click  "Launch Monitoring and Report Viewer"












Step 2. A new window pops up. Navigate to "Reports", "Catalog", and click "AAA Protocols".




















Step 3. On the right pain under reports click "TACACS Authentication. As you can see the first 2 entries correlate to what was seen on the switch. A pass and a fail.





Step 4. Lets look at some more details by clicking the magnifying glass under details. Lets look at the authentication that passed. As you can see there is alot of details. The big thing here is the "Status"









Step 5. Lets look at the authentication that was rejected. You can see the reason is identified. Wrong password :/











I will be adding a few more of these types of posts over the next week or so. Quick posts that provide specific detail on a particular topic.

Wednesday, March 20, 2013

VPN-IPSEC

Its been a while but I am going to try to post weekly.

Here is a sample configuration for IPSEC VPN between in 2 routers.
Note: 172.16.1.X/32 are loopback interfaces.








R1
Define IKE Phase 1 Policy (ISAKMP)
(config)#crytpo isakmp policy 10
(config-isakmp)#encryption aes 256
(config-isakmp)#authentication pre-share
(config-isakmp)#hash sha
(config-isakmp)#group 2

Define pre-shared key
(config)#crypto isakmp key 0 $pass@word$ address 192.168.1.2

Define IKE Phase 2 Policy (IPSEC)
(config)#crypto ipsec transform-set TRANS-R1-R2 esp-aes 256 esp-sha-hmac

Create ACL to match interesting traffic
(config)#access-list 150 permit ip 172.16.1.1 0.0.0.0 172.16.1.2 0.0.0.0

Create Crypto Map
(config)#crypto map VPN-MAP-R1-R2 10 ipsec-isakmp
(config-crypto-map)#set peer 192.168.1.2
(config-crypto-map)#set transform-set TRANS-R1-R2
(config-crypto-map)#match address 150

Apply Cypto Map to Interface
(config)#interface fas0
(config-if)#crypto map VPN-MAP-R1-R2

Create a route
(config)#ip route 172.16.1.2 255.255.255.255 fas0

R2
Define IKE Phase 1 Policy (ISAKMP)
(config)#crytpo isakmp policy 10
(config-isakmp)#encryption aes 256
(config-isakmp)#authentication pre-share
(config-isakmp)#hash sha
(config-isakmp)#group 2

Define pre-shared key
(config)#crypto isakmp kep 0 $pass@word$ address 192.168.1.1

Define IKE Phase 2 Policy (IPSEC)
(config)#crypto ipsec transform-set TRANS-R1-R2 esp-aes 256 esp-sha-hmac

Create ACL to match interesting traffic
(config)#access-list 150 permit 172.16.1.2 0.0.0.0 172.16.1.1 0.0.0.0

Create Crypto Map
(config)#crypto map VPN-MAP-R1-R2 10 ipsec-isakmp
(config-crypto-map)#set peer 192.168.1.1
(config-crypto-map)#set transform-set TRANS-R1-R2
(config-crypto-map)#match address 150

Apply Cypto Map to Interface
(config)#interface 0/1
(config-if)#crypto map VPN-MAP-R1-R2

Create a route
(config)#ip route 172.16.1.1 255.255.255.255 fas0


Sample Output from R2 - (After ping from R1 source lo0)

R2(config)#do show cry isa sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id slot status
192.168.1.2     192.168.1.1     QM_IDLE           1001    0 ACTIVE

IPv6 Crypto ISAKMP SA





R2(config)#do show cry ipsec sa

interface: FastEthernet0
    Crypto map tag: VPN-MAP-R1-R2, local addr 192.168.1.2

   protected vrf: (none)
   local  ident (addr/mask/prot/port): (172.16.1.2/255.255.255.255/0/0)
   remote ident (addr/mask/prot/port): (172.16.1.1/255.255.255.255/0/0)
   current_peer 192.168.1.1 port 500
     PERMIT, flags={origin_is_acl,}
    #pkts encaps: 24, #pkts encrypt: 24, #pkts digest: 24
    #pkts decaps: 47, #pkts decrypt: 47, #pkts verify: 47
    #pkts compressed: 0, #pkts decompressed: 0
    #pkts not compressed: 0, #pkts compr. failed: 0
    #pkts not decompressed: 0, #pkts decompress failed: 0
    #send errors 0, #recv errors 0

     local crypto endpt.: 192.168.1.2, remote crypto endpt.: 192.168.1.1
     path mtu 1500, ip mtu 1500, ip mtu idb FastEthernet0
     current outbound spi: 0x6F76C310(1870054160)

     inbound esp sas:
      spi: 0x1F2B01DC(522912220)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 1, flow_id: 1, crypto map: VPN-MAP-R1-R2
        sa timing: remaining key lifetime (k/sec): (4605243/2016)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     inbound ah sas:

     inbound pcp sas:

     outbound esp sas:
      spi: 0x6F76C310(1870054160)
        transform: esp-256-aes esp-sha-hmac ,
        in use settings ={Tunnel, }
        conn id: 2, flow_id: 2, crypto map: VPN-MAP-R1-R2
        sa timing: remaining key lifetime (k/sec): (4605245/2011)
        IV size: 16 bytes
        replay detection support: Y
        Status: ACTIVE

     outbound ah sas:

     outbound pcp sas:


Wireshark capture - Anything sourced from R1 L0 is encrypted (ESP) when not sourcing from R1 L0 the packets are sent in clear text.



Saturday, June 23, 2012

CCIE Security

I have just successfully passed the CCIE Security written exam at Cisco Live 2012. The exam was no cake walk and was very challenging. Although I studied all the material from the CCNP security track and read the Network Security Technologies and Solutions (CCIE Professional Development Series) book I did not take any of the CCNP Security exams. I took a little different approach to this CCIE then I took in the R&S track. I will be starting to do the practice labs and will go back to theory throughout the process to do each of the CCNP Security exams. I am hoping that this ensures that I perform the practice labs without fail and continue to cement the theory throughout the process.


Thoughts?