OnePK – Configuring and Assigning an ACL

During my research of the ACL module of OnePK I found some interesting behaviors. I think this feature isn’t fully cooked as it has some definite room for improvement. The ACL module (found in onep.policy) doesn’t have a way to interact with existing ACLs and ACEs on an IOS device. The ACLs seem to be intended for on-the-fly ACL configuration but with a couple caveats:

  • Applying an ACL to an interface overwrites the existing ACL for that direction. Interfaces must play by the rule: ‘One ACL per direction’.
  • Make sure to use OnepLifetime.ONEP_PERSISTENT to keep ACLs applied after the OneP session is disconnected.

First I’ll cover ACL management with OneP, and then I’ll use the onep.vty module to show how to workaround some of the shortcomings.

Continue reading

OnePK – Pulling information from an IOS device

The first logical step in controlling your network with python is to have a way of pulling important information from your network devices. This post will cover the gathering of interface and routing table information. In order to keep examples short and to the point, they  will use the one_connect.py script as a connection module as discussed in the second post of the series. My goal for these examples isn’t to show what you should have in your OnePk apps, but rather to introduce you to basic concepts so you can see how the different pieces work and how you might be able to get the information necessary in your applications. Continue reading

OnePK – Connecting to a Network Element

The first step in managing your network with Cisco’s OnePK is learning how to connect to a switch or router, what Cisco calls a Network Element. In the early OnePK days this was a very straightforward task using vanilla TCP but in the newest version of OnePK (1.3) and IOS (15.4), unencrypted communications were disabled and we are forced to use TLS. This makes sense from a network security point-of-view; it just makes it a little more difficult to get started.

Fortunately, amongst Cisco’s vast resources I found a document that helps outline a process that makes it easier to use TLS between our OnePK apps and Cisco IOS devices. The guide uses a technique called TLS pinning which allows our OnePK app to bypass certificates but still encrypt communications via TLS. Read more about this technique here: Cisco – TLS Pinning Guide. (Please note that this should not be used for production as it does not verify the endpoints. Certificates should be used for TLS in a production network.)

Continue reading

OnePK – Interacting with Interfaces

Getting information from your network devices is really helpful, but actually change device configurations is even more helpful! This post will have a few examples of how to do just that with scripts that will shutdown a specified interface and change an interface IP address. This is where the fun begins, so strap into your chairs and get ready for some network automation! Continue reading

Python and onePK Offer the Power of SDN Today

Cisco announced their entry into the Software Defined Networking (SDN) arena with OnePK in early 2013. If you haven’t heard of Cisco’s OnePK yet, please read their introductions before continuing (only because they do a better job of explaining it than I do):

It took Cisco a while to deliver something tangible after the initial announcement, but it was certainly worth the wait. Cisco has a large amount of resources for onePK that range from videos, tutorials, code examples, SDKs in 3 languages (Java, C, python), and full API docs. I’ve been digging through these resources and there is plenty of good info to get people started with SDN. Continue reading

PyShark – Using the packet Object

So far in this series we’ve done a lot with capturing packets and working with the capture object, but finally we’re going to get to the fun part and finally start playing with some PACKETS!!!!

When we have captured packets in a capture object, they are stored as a list of packet objects.  These packet objects will have methods and attributes that give us access to the header and payload info of each packet.  As stated in a previous post we have control for how much info about the packets we store in each packet option through the only_summaries argument in the LiveCapture and ReadCapture modules. Continue reading

PyShark – Using the capture Object

Before we get started you should read a few things in this post about the differences here between the current version of PyShark (0.3.3) and the documentation on the website. Everything I cover in this post will be things I’ve tested and confirmed work in the current version.

Now that we know how to use the FileCapture and LiveCapture modules to capture some packets, let’s see what options we have with the returned capture object (truncated list for brevity):

Continue reading

PyShark – FileCapture and LiveCapture modules

The two typical ways to start analyzing packets are via PyShark’s FileCapture and LiveCapture modules. The first will import packets from a saved capture file, and the latter will sniff from a network interface on the local machine. Running these modules will return a capture object which I will cover in depth in the next post. For now, let’s see what we can do with these two modules.

Both modules offer similar parameters that affect packets returned in the capture object. These definitions are taken directly out of the docstrings for these modules:

  • interface: [LiveCapture only] Name of the interface to sniff on. If not given, takes the first available.
  • bpf_filter: [LiveCapture only] A BPF (tcpdump) filter to apply on the cap before reading.
  • input_file: [FileCapture only] File path of the capture (PCAP, PCAPNG)
  • keep_packets: Whether to keep packets after reading them via next(). Used to conserve memory when reading large caps.
  • display_filter: A display (wireshark) filter to apply on the cap before reading it.
  • only_summaries: Only produce packet summaries, much faster but includes very little information.
  • decryption_key: Optional key used to encrypt and decrypt captured traffic.
  • encryption_type: Standard of encryption used in captured traffic (must be either ‘WEP’, ‘WPA-PWD’, or ‘WPA-PWK’. Defaults to WPA-PWK).

Continue reading

Intro to PyShark for Programmatic Packet Analysis

I can hardly believe it took me this long to find PyShark, but I am very glad I did! PyShark is a wrapper for the Wireshark CLI interface, tshark, so all of the Wireshark decoders are available to PyShark! It’s so amazing that I started a new project just so I could use this amazing new tool: Cloud-Pcap.

You can use PyShark to sniff from a interface or open a saved capture file, as the docs show on the overview page here:

Continue reading

Differences between PyShark 0.3.3 and Documentation

While working with Pyshark I’ve found that some of the documentation doesn’t quite line up so I’m writing this post to help people that might run into the same situation. The intro doc is found here and I’ll be comparing it to what actually happens when using the newest version (0.3.3) of Pyshark.

Continue reading