Non-Interactive SSH use case with Python

Sometimes the best way to learn to do something useful with a scripting language is with a starting point and a real world use case. While I don’t consider myself a Python expert, I can usually figure out how to put things together and get a task accomplished. For this article I challenged myself to create a simple script that performs the following:

• Open a file for a list of devices and credentials
• Log in to each device in the file using the credentials found
• Remove the current NTP server (1.1.1.1)
• Add a new NTP server (2.2.2.2)
• Save the configuration

I am sharing the script below as an example. Note this Python file uses paramiko. Therefore that library needs to be installed (MAC users – sudo pip install paramiko)

NTPChange.py

import paramiko

####devices.txt format
#### username,password,host
#### username,password,host

qbfile = open("devices.txt", "r")

for aline in qbfile:
    values = aline.split(",")
    myuser = values[0]
    mypass = values[1]
    myhost = values[2].rstrip()
    ssh = paramiko.SSHClient()
    ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
    ssh.connect(myhost, username=myuser, password=mypass)
    channel = ssh.invoke_shell()
    stdin = channel.makefile('wb')
    stdout = channel.makefile('rb')
    stdin.write('''
    conf t
    no ntp server  Continue reading

SSH is a BAD API

Okay, so its not meant to be an API. I get that. I’ve been watching a rather good video about executing interactive commands with Parimiko and two thoughts came to my mind.

• Very powerful/flexible way to do tasks across many devices
• This could be a LOT easier if we simply had the RESTful API’s we want everywhere

In any case, I think the video below is a worthwhile watch if you’re struggle to leverage Python and SSH to make a modification across a large number of devices.

Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may does not reflect the position of past, present or future employers.

The post SSH is a BAD API appeared first on PacketU.

VRF Series Article 5 – Stateful Inter-Vrf connectivity

This is the fifth and final article in a series that focused on Segmenting Layer 3 Networks with VRFs. In the third article, we discussed creating a shared services VRF and using it within the otherwise segmented network. In that article I alluded to the fact that we would later cover a way to securely allow traffic to flow between security zones. That is the intent of this article.

In this article, I am going to attach two sub interfaces between asav-1 and Main. One will attach into data and the other into pci. We will apply a simple policy that denies all traffic from data to pci, but allows telnet from pci to data (bad security example, but easy to demonstrate).

Before we jump into the configuration, I want to share the entire topology and give a summary of the current configuration status.

Current Configuration

In the above topology, anything that starts with “data” is in the data VRF. Likewise, anything that starts with “pci” is in the pci VRF. Everything within a given VRF can communicate with everything else in that same VRF. Both pci and data can communicate with the shared VRF (test IP address is Continue reading

VRF Series Article 4 – VRF-lite in a DMVPN Network

As we’ve progressed through the Segmenting Layer 3 Networks with VRFs series, we have continued to build out a network that looks more like what we would see within an enterprise environment. This post takes it one step further and leverages the DMVPN (dynamic multipoint VPN) functionality to extend the network securely over the public Internet. In the examples here, we actually go one step beyond a typical DMVPN and map VRFs to tunnels using the tunnel key. This allows the pci and data VRFs to maintain isolation across the VPN.

One more thing that we will do that isn’t related to the core requirement of segmenting pci from data is leveraging a F-VRF (or front side vrf) on the DMVPN routers to isolate the Internet facing interfaces that connect them to the public cloud. This is my preferred method for DMVPN deployment if I’m not doing split tunnelling (i.e. I am back-hauling all traffic to a central location).

As a prerequisite, I will go ahead and build out the Internet router and the interface on Main that connects to DMVPN-hub.

Internet

hostname Internet

interface gig2
 description to DMVPN-hub
 ip address 1.1.1.1 255.255.255. Continue reading

VRF Series Article 3 – Creating a Shared Services VRF

For those following the VRF Series, we currently have a topology built that consists of a segmented Layer 3 first hop network and remotely networked by carrying the isolation from the BrWan router to Main. This article covers, shared services, the next step in our journey to understanding VRFs for Segmented Layer 3 Networks.

The configuration focus is solely on the router Main. The shared services VRF that will be created could serve as a place to connect something that all other VRFs must have access to. Organizations should evaluate their requirements closely before deploying this configuration.

An organization that requires stateful inspection between two areas may choose to connect two or more VRFs together using an L4 or Next Generation Firewall (we will cover this in Article 5). The security ramification of having a shared services VRF, as described in this article, is that devices connected in this area could be used as a proxy into other areas. Therefore, careful planning and proper device level security is important prior to deploying this type of architecture.

The technologies covered here include:

• IGP w/ Route Redistribution (EIGRP)
• BGP w/ Route Redistribution
• VRFs with Route Targets/Route Distinguisher vlaues

The logic of Continue reading

VRF Series Article 2 – Extending L3 Segmentation with VRF-lite

In the last article, we took an initial look at L3 segmentation with VRFs. In that case, we created a basic first hop configuration that had isolated pci and data segments. In reality, most networks are far larger and more complex. This article continues down that same path by building proper layer 3 links and IGP adjacency with a Headquarter (Main) location. The starting point from a configuration standpoint is where we left off in Article 1 of this series.

Specifically in this article, we will configure subinterfaces to connect BrWan to Main for each VRF. We will also create a loopback on Main in each VRF to act as a test point that should be reachable from each host. From a routing protocol perspective, we will leverage EIGRP in Named Mode. This mode is a requirement because it is the method that allows the address family command to identify VRFs.

Note: I am working from some VIRL defaults, so I will be including the removal of unnecessary items. Also, I will be shutting down Gigabit 2 since the rest of the topology is out of scope for this article.

Main – HQ Router

//removing unnecessary routing  Continue reading

VRF Series Article 1 – Basic L3 Segmentation with VRFs

Network engineers are well aware of the Layer 2 isolation properties of VLANs. Their use is so pervasive that they are second nature to most. This article is the first in a series that outlines specifically how VRFs can be used to provide the same type of end to end isolation for Layer 3 that VLANs provide for Layer 2.

In this example, we will work with a subset of the overall topology that I previously shared. Specifically, we are going to configure a router that I’ll call BrWan, a Layer 2 switch, and 3

routers that I’m using to emulate connected hosts (data-x/pci-x).

BrWan will contain the technology configuration that is the primary focus of the article. The other components are configured somewhat generically and using technologies that most are very familiar with.

At the end of this exercise, the requirement is that anything related to “data” can only reach other parts of the “data” network. Similar requirements exist for “pci”. There will be no ACLs used to prevent communication between pci and data, but the isolation requirement is strict. These concepts will be carried forward throughout the series. Later examples will provide a mechanism for some traffic between Continue reading

Segmenting Layer 3 Networks with VRFs

I am creating a multi-part series that focuses on Layer 3 network segmentation. This post serves as a landing point and aggregation place for these topics. As the series is built out, the individual links will be available below.

Articles in this Series

• Article 1 – Basic L3 Segmentation with VRFs
• Article 2 – Extending L3 Segmentation with VRF-lite
• Article 3 – Creating a Shared Services VRF
• Article 4 – VRF-lite in a DMVPN Network
• Article 5 – Stateful Inter-Vrf connectivity

The basic topology is shown below. Each article will consist of the configuration information and relevant validation. This should serve as a very good starting point for anyone struggling with building out a common network with strict security zones requiring areas of isolation.

Other Articles about VRFs

• VRFing 101, Understing VRF Basics
• VRFing 102, Providing Internet Access With Dynamic PAT
• VRFing 103, Using NAT Virtual Interfaces for Global Reachability
• Using a GRE Tunnel VRF to Separate the Physical Interface
• Combining GRE and IPSec with a Front Side VRF
• ce Gateway and Voice VRF – Caveats

Disclaimer: This article includes the independent thoughts, opinions, commentary or technical detail of Paul Stewart. This may or may does not reflect the position Continue reading

APIC-EM Data Export

I was at a Cisco DNA customer event on Thursday. Someone in the audience asked a very good question. Basically they wanted to know if there was a way to extrapolate data from the APIC-EM network management tool. At first glance it didn’t seem to be something that was available in the UI. One of the Cisco representatives quickly and correctly stated that it is all available from the API.

My initial thought was that this was a product weakness. Why can’t we just manually extract this stuff to a CSV and import it wherever we want to? Whether due to intentional omission or strategic direction, an API first approach is better. It is better because it allows systems to be glued together and more of our mindless tasks to be automated. So the counter argument to that really revolves around use cases, initial effort and skills gaps. The examples I’m about to provide should help alleviate some of those concerns.

TL;DR — Looking to get APIC-EM data into an Excel spreadsheet? Python can easily grab Host and Device Data and provide it in a format that is easily consumable such as Text, Tab, CSV or other format of choice.

Continue reading

ASA Pro Tip — A Better Prompt

The Cisco ASA FW has a simple and robust failover mechanism. It works so well that sometimes an administrator may not realize that the load has moved from the primary device to the secondary device. When connecting to the IP address, the primary IP address for the interface follows the active unit. So it is even possible to be logged in to a different Firewall than the administrator thinks they are in.

This can easily be determined by doing a show failover.  In the output, it is easy to see if the unit is the Primary or Secondary (configured state) and Active or Standby (operational state). Since the ASA Failover is not preemptive, any glitch moving the load to standby will result in the load remaining there (unless there is a subsequent failure or manual failback).

Given the fact that I am a huge fan of situational awareness, I like to reflect the state in the CLI prompt. This is a simple configuration change.

asav-1# 
asav-1# conf t
asav-1(config)# prompt hostname priority state 
asav-1/pri/act(config)# exit
asav-1/pri/act# 

As can be seen above, a simple configuration change results in the ASA displaying its hostname, configured priority and operational state.

Disclaimer: This Continue reading

ASA Active/Standby with BDI/BVI

I see a lot of ASA designs and they are typically flanked with switches. One of the reasons for this is that the failover requirements typically dictate that the devices to be layer 2 adjacent in each security zone. There is obviously the requirement to be L3 directly connected to their next hop. The result of this requirement that an ASA can’t typically be directly connected directly to an L3 only device and it is often the case that a switch is sandwiched between the FW and the next L3 device.

This article is meant to outline a possible work around with IOS and IOS-XE based routers to provide the L2 two adjacency using inherit L2 features. Readers may use these sample configurations to build out there own labs and more fully validate the applicability the their environment.

TL;DR–BDI and BVI allow ASA A/S to function properly in my testing.

The Topology

Below is the topology that used for validating this. In a real world scenario it is less likely that routers would be the connection point on all interfaces. The reason I positioned them here is to demonstrate both IOS and IOS-XE techniques in the same lab.

Solution Overview

Continue reading

Quickly Adding an NMS to VIRL

I’ve spent the last few days experimenting with APIC-EM and the path trace capabilities. My lab environment is currently leveraging VIRL (Virtual Internet Routing LAB). Since it wasn’t obvious how to integrate APIC-EM with the lab platform, I wanted to share my configuration.

TL;DR–When building the topology, click the background and view the properties for the Topology. Change the Management Network to “Shared flat network”. This will put the all of the devices ‘Mgmt-intf’ vrf on the ‘flat’ (172.16.1.0/24 by default) network when the topology is built. 

When I started this process, I really didn’t realize how easy it could be. I actually tried to leverage a manual connection to L2 External (FLAT) to do the management in-band for the topology. This is certainly possible, but there is a much easier way. As most VIRL users have noticed, there is a management IP address that gets assigned to each device. There is a simple configuration change that will allow that address to be one from the ‘FLAT’ pool and connected externally to the ‘L2 External (FLAT)’ network.

My configuration 

1. APIC-EM built with IP address 172.16.1.2/24 (172.16.1.2-49 are unassigned and part of the Continue reading

A Broken Process Placing Consumers at Risk

Below is a chat session I had with Pearson Vue several months ago as I attempted to schedule a recertification exam. Apparently, I have two accounts with them and that prevents next day test scheduling. To put it mildly, I don’t think they adequately explain how they could possibly guarantee non-disclosure of data with email as a transport. Moreover, this seems to indicate a serious disconnect between security and business operations.

Image Link – for FULL Size View

I’m not going to explain the problems with this, PacketU readers understand why email is not [in and of itself] a secure method for file transport. When I experience an exchange like this, I see how segregated business practices can be and what a negative impact it can have from an information security perspective. Its not a matter of if, but a matter of when, bad things will happen as a result of not taking security seriously.

The post A Broken Process Placing Consumers at Risk appeared Continue reading

APIC-EM Path Trace Examples – Overlay Networks

Since seeing the APIC-EM Path Trace demo for the first time and seeing how it represents CAPWAP, I’ve been curious how well it deals with other types of overlay/underlay networking. This article is a brief synopsis of that testing and provides some visuals around what was produced with this free management tool.

TL;DR–APIC-EM adds value to most network path traces and typically represents what it knows. The single exception is with MPLS VPNv4. If the MPLS PE nodes are pulled into the device inventory, path trace has a total lack of understanding around the recursive lookup into the global vrf that is required for VPNv4 functionality.

CAPWAP Representation — The Gold Standard

I wanted to start out by showing what an ideal representation of an overlay network would be for a tool like this. Path Trace understands AND clearly represents both the underlay and the overlay network for traffic flowing through a CAPWAP tunnel. The image below shows the extent of the tunnel (darker gray) and the physical components that are responsible for delivery (both through the tunnel and outside of the tunnel).

Testing Topology

For the additional testing, I built the following topology and integrated APIC-EM into my Continue reading

Voice Gateway and Voice VRF – Caveats

ACL Trace in APIC EM

I wanted to take just a moment to share the output of an APIC-EM ACL Trace (option in Path Trace). For this example, I have built out the topology below.

The applicable configuration for CSR1000v-2 is as follows–

ip access-list extended TESTING
 permit ospf any any
 permit icmp any any
 permit tcp any any eq telnet
 deny   tcp any any eq 22
 permit ip any any
!
interface GigabitEthernet2
 description to csr1000v-1
 ip address 10.0.0.6 255.255.255.252
 ip access-group TESTING in
 ip ospf cost 1
 negotiation auto
 cdp enable

For testing it is possible to run a path trace from 10.1.1.1 (LAN interface on CSR1000v-1) to 10.1.2.1 (LAN interface on CSR1000v-2) with TCP Ports. To expose the layer 4 options, it is necessary to choose more options. The check mark in the “ACL Trace” instructs APIC-EM to evaluate ACLs.

The output indicates a successful trace AND an allowed match through the ACL.

Adjusting the path trace to target TCP port 22 demonstrates how a blocked flow is represented in APIC-EM.

The one caveat I have found is that this is only ‘semi’ real time. APIC-EM downloads the configuration from its Continue reading

FLAT Networks in VIRL Require Promiscuous Mode

So I’m sure this is in the documentation somewhere. But for anyone else out there who is getting inconsistent results with FLAT interfaces in VIRL, Promiscuous Mode support in ESXi seems to be a requirement. Definitely something to check…

The post FLAT Networks in VIRL Require Promiscuous Mode appeared first on PacketU.

Connecting VIRL to the Outside World

I’ve been leveraging VIRL for some time to build and test self-contained labs. I’ve always known that there was some ability to connect to the world outside of this environment. Recently, I decided to configure this functionality and I wanted to take just a moment to share what I found.

First and foremost, this isn’t anything difficult or time consuming. So if you have a need to leverage physical devices with your VIRL deployment, don’t hesitate before building it out.

There are two mechanisms for outside connectivity. The first mechanism is called SNAT. This method basically builds static NAT in and out of the environment. I get how this could be beneficial, but I would typically prefer to keep any NAT configuration contained to an environment that I am very familiar with (possibly an ASA or IOS instance outside the lab when an additional NAT layer is required).

The second method, and configuration we will be testing is called FLAT. In this configuration, VIRL connects a L2 broadcast domain between a lab device and an Ethernet interface. In my example I am running the VIRL components in a VM environment on ESXi. So this is a virtual interface that needs Continue reading

Hairpinning traffic through ASA with State Bypass

Several years ago I wrote an article about the Woes of Using an ASA as a Default Gateway. I have received a lot of feedback about this post and recently had a request for an update around ASA > 8.3. When building this scenario out with current ASA code, I found that the base NAT configuration (internet only PAT) had no bearing on the hairpin configuration. As expected, I found the same challenge around state bypass. I wanted to share a current post that demonstrates the challenges and solutions when traffic is bounced off the inside interface of the ASA.

The requirements of the configuration are as follows–

• TestHost must be able to Telnet and Ping to Internet and PartnerHost
• The inside interface of asav-1 must be the default gateway for TestHost
• asav-1 is doing PAT for Internet destined traffic
• PartnerRTR and ParnterHost have been preconfigured as shown above

The following are the base configurations for all of the devices. The configuration of asav-1 does not seem to allow communication from TestHost to PartnerHost (100.1.1.0/24 network).

TestHost Configuration

hostname TestHost
!
interface GigabitEthernet2
 description to iosvl2-1
 ip address 10.1.1.5 255.255.255.0
!
ip route 0.0. Continue reading

Creating a Firepower Peer to Peer Dashboard

Peer to peer applications are a significant challenge for policy enforcement solutions. Any flows that slip through as an undetermined application type may allow the file sharing app to function. The first key to addressing this challenge is simple visibility into which hosts or users may be abusing the AUP with these types of applications. This article shows a quick and easy way to create Peer to Peer dashboard in the Firepower Management Console.

For those that have already attempted this, there are a number of challenges that may have surfaced. First there are no readily available widgets or criteria that will show the desired information. Experimenting with search constraints and the connection table quickly reveals that the desired information can be easily accessed by using the “peer to peer” Application Protocol Category search criteria. Unfortunately, the Connection Table is not readily available to the Dashboard Widgets. The Connection Summary table is available, but it does not have the Application Protocol Category (required for the search constraints).

My goal was to build a few dashboard widgets to give visibility into Peer to Peer activity. For this article I will demonstrate the steps required to build those widgets. The first widget will provide Continue reading