What is NFVIS?

NFVIS is an operating system developed by Cisco which is intended to be deployed at branch office locations - and allow for quick deployment of network services in lightweight VMs. For example, we might want to reduce cost and hardware footprint by deploying a single ENCS machine, then deploy our typical branch services on top of that (DNS, Firewalls, SDWAN, etc). Under the hood, NFVIS is built on top of CentOS and KVM.

In the image below, we have an ENCS unit that is running ISRv, FTDv, and a vEdge Cloud. NFVIS has the ability to build out traffic flows for service chaining. In this particular setup, we could have all branch traffic receive a default route up to our ISRv. The ISRv forwards traffic to a Firepower VM (FTDv) which performs some traffic inspection before passing everything up to the vEdge Cloud.

We’ll be coming back to this diagram later to see how we can build out this flow of services. For now, let’s dive into how we can get NFVIS up and running.

Installing NFVIS

Lucky for us - the installation of NFVIS is fairly straightforward!

1. Create a bootable USB - or mount the installation ISO via CIMC
2. Upon boot, select “Install Cisco NFV Infrastructure Software”:

3. Wait. A while. Install time can vary depending on your hardware.
4. Once completed, log into the CLI: Default login = admin/Admin123#
5. You’ll be prompted to change the default admin password immediately:

Install completed! Now let’s look at some of our base configuration..

Initial Configuration

By default the NFVIS install will have a LAN and WAN bridge (lan-br and wan-br, respectively). The LAN config will be set up with a static IP of 192.168.1.1/24, and the WAN will be set for DHCP. We can check the current network settings by running the show system settingscommand:

In this case, my WAN interface is able to get an IP via DHCP. We’re likely going to want to change this to a static IP address - which we can do from the CLI or web interface. Let’s start by trying this from the CLI:

config t
system settings wan ip address <ip addr> <netmask>
system settings default-gw <gateway addr>
system settings hostname <hostname>

Changes can then be applied using the commit command

We can verify these settings by repeating the show system settings command we used earlier.

Let’s go ahead and log into the web interface to see what the network configuration looks like there:

1. If we know our WAN or LAN IP from earlier, we can just pop that in our web browser.
2. Go ahead and log in using the new admin credentials we just created:

3. We’ll be taken to the primary NFVIS dashboard, which will currently show no active VMs deployed:

4. In the left-hand menu, expand Hostthen click on Settings:

Here we can see that we already configured our IP Addressing/hostname - but we could use the Edit button at the bottom to change any of these values. For example - I’m going to go ahead and select Static for both the Management (LAN) and WAN IP addresses.

Another quick tip - if we need to modify which physical network adapters are tied to an internal network bridge, we can find that under VM Life Cycle > Networking:

That’s all for this time. In the next post, we’ll take a look at how to package VM images and deploy our service chain.

The future is APIs! SD-EVERYTHING! Automation! Orchestration! Artificial Intelligence and Machine Learning! Sound familiar? It’s all part of the messaging going around in just about everything IT-related. With as much as you keep hearing about it, you might think that it’s all anyone is doing anymore. Yet it still just seems like not a whole lot of people are really getting into it in my area. Every vendor event I’ve gone to this year has asked attendees the same questions: “How many of you are leveraging the APIs in your network hardware/software?”. And every time the same answer - maybe two or three people in a room of 40 raise their hands.

So where is the problem? Is all of this just marketing fluff or am I just talking to the wrong people?

Let’s think about this from a typical network admin’s perspective. Shifting from traditional CLI to automation and APIs can seem difficult or overwhelming. Let’s say I want to automate a new VLAN deployment. Oh, you’re telling me I need to stop and learn vendor APIs… but before that I need to understand how to write scripts. But I’ve never even programmed something before. There are dozens of languages - how do I pick one? How much fundamental programming knowledge do I really need to have before starting? I don’t want to be a developer!

Okay, okay - just stop there for a second. No one is asking you to drop networking and write code for a living. The end goal of all this programmability stuff isn’t to turn networkers into developers - It’s to enable network/systems admins to be more efficient at their jobs. Why  copy/paste the same config change to 100+ devices, if you can mass-deploy the change via an API? That’s a lot of time savings that could be used toward educating yourself on new products, planning other projects, or thinking about your ideal network design.

I’ve heard a lot of the same things over the past few years:

“Programming is difficult” or “I don’t know where to start”

Try learning Python. It’s simple to get started and you can build from there.

“I don’t know what an API is or how to use it”

Don’t worry about that yet - start with learning the basics and APIs will make sense later.

“I’m not a developer”

No one is asking you to be one! But learning the basics of scripting and automation gives you a whole new toolset to solve problems.

For me personally - I would never want to be a developer. I can’t stand the thought of coming into work every day and just writing code. Some people might enjoy that, but for me it doesn’t sound like fun. However - I enjoy writing scripts to solve problems, especially when it ends up making my job easier. I think that’s the part where some people tend to get stuck though. A lot of automation sounds like I need to be able to develop a huge 10,000+ line application to pull data from 15 sources and aggregate it to make intelligent network changes. Ehhh… Nope, not really. But what about just a quick script that runs every 5 minutes to check an interface statistic, and email you when a particular threshold is exceeded? Realistically that could be done in less than 50-100 lines of a script and maybe 30 minutes worth of work.

Still not interested? That’s okay too. Traditional networking isn’t going away any time soon, and over time the vendors will write all of that automation for you. They will package it up in a pretty GUI and sell it off to companies that want it. In fact, this has already happening and has been for quite some time. This isn’t a bad thing - vendors need to make money, and not all companies will have the time or skilled resources to automate all the things. However, a network admin who can write their own scripts/automation won’t be exclusively tied to a vendor to help them - and instead they will be empowered to solve more problems themselves.

Where do you get started? I already wrote a bit earlier this year on a few resources for learning Python - which you can find here. I also wanted to point out some other great resources that are a bit more specific to using those skills for network automation:

• Python For Network Engineers - Don’t know anything about Python yet? Start here! This is a free course provided by Kirk Byers for anyone who is interested in using Python for network automation. Once a week you’ll get an email with all the great free content, but it will be up to you to spend time going through it. Go sign up, and set aside an hour or two each week to practice.

• Cisco DevNet - There is a ton of great content here. While DevNet does offer some tutorials on basic Python fundamentals,  the real value here is examples on how to use some network APIs (NX-OS, Meraki, UCS, etc). Also - one of the best parts about DevNet is the sandboxes they offer. Want to write scripts against the FirePower Management Center, but you don’t have one to test with? Well with DevNet you can get access to one!  Get familiar with your Python basics, then come here to see where you can start using those skills with your existing infrastructure.

• Network Programmability and Automation - This is a fantastic book. Not free, but it is well worth the ~$30. Once you have a good handle on how to write some basic network automation with Python, I highly recommend picking this up. While Python is covered here, the book does a great job of introducing you to all of the other toolsets available. Curious about how Linux or Ansible fit into network automation? You can find out here - and learn about APIs and source control systems too!

So - What are you waiting for? Go get started, and see what you can accomplish. Learn the basics - and keep an open mind for opportunities to use those skills.

Have suggestions on where else to learn? Comment below!

The config I used is based on this blog post. It’s a great write-up on how to back up F5 configurations using CatTools. I don’t want to replicate what was written over there - but I did hit some issues that were specific to my use-case that I wanted to share.

While I was happy to find the article linked above, the immediate results didn’t work so smooth for me. This may be due to some key configuration differences that I face in my network:

• All the F5’s are LDAP integrated - so there isn’t an easy way to provide LDAP users with direct bash access
• All of my F5’s are remote appliances, where the backup configuration is being copied across the WAN

Getting around the first problem was my biggest challenge. CatTools is a very command/response-oriented application. Any remote LDAP authenticated users are immediately dropped into F5’s shell: tmsh. To get from there to their ‘advanced shell’ is as simple as typing bash. However, When the terminal prompt changes, it often throws CatTools into a state of “I didn’t receive the response prompt I expected, therefore kill the job - something went wrong”. I spent a bit more time on this than I wanted to - but the underlying problem was that the “F5.BigIP” device type was specifically looking for the tmsh shell and couldn’t handle the prompt change. The fix? Switch the device type to “Linux.RedHat.Bash”, then add the bash command to the first line of your backup script.

The next problem was using TFTP to copy the backup archives over the WAN. Even some of the new F5’s with minimal configuration still generate a 10Mb file. Doesn’t seem like much, but when you’re copying that over a WAN between two datacenters, that turns into a ~5 minute file transfer. CatTools by default will only wait 30 seconds after executing a command before it expects a response. So every time I tried to run the job, CatTools would kill it only 30-seconds into the file transfer. Luckily enough, they support a utility command that can alter the normal timeout:

%ctUM: Timeout 600
tftp -m binary 192.168.1.10 -c put $filename
%ctUM: Timeout 0

The command %ctUM: Timeout 600 changes the timeout value to 600 seconds, or 10 minutes. The TFTP file transfer command is next, which is now permitted up to 10 minutes to finish. The last command resets the timeout back to the default (30 seconds).

I also realized that the original script doesn’t purge the backup archive afterwards. For my use case, I would much rather automatically clean up the backup files once they’ve been transferred to a central location.

So after all that, here is the version of that script that I’m using:

export date=`date +"%y%m%d"​`
export filename=$HOSTNAME.$date.ucs
tmsh save /sys ucs /var/local/ucs/$filename
cd /var/local/ucs
%ctUM: Timeout 600
tftp -m binary 192.168.1.10 -c put $filename
%ctUM: Timeout 0
rm -f $filename

Thanks again to the original blog post for getting me on the right track with this! I hope that my ramblings here are helpful to anyone with a similar deployment scenario.

Earlier today, Cisco released their 2018 Annual Cyber Security Report. I’ve spent some time digging through the report and thinking about what they’ve written. It’s interesting to read through the trends and survey results, and try to get an idea of where security efforts should be focused for the coming year. This post is going to cover just a subset of what’s in the complete report. I’ll be covering the topics that I found particularly interesting, and give my own thoughts/views on them.

The Encrypted Web is Great… For Attackers

Unsurprisingly, Cisco reports a growing trend in attacks and exploits that are taking advantage of encrypted transport. As a lot of large companies and Internet bodies are pushing for a 100% encrypted web, should we be surprised? Nah, it’s the logical next step. Users want encryption because it means privacy - but that privacy also brings a method of concealing attacks.

New exploits and malware are heavily leveraging encrypted transport to bypass all of the security we put in place to detect them. Typical defense technologies like intrusion prevention systems (IPS) are fantastic, but only when they can actually read the data. If a user download’s malware through an HTTPS call, IPS won’t usually catch it. And when that malware can now take advantage of SSL to reach back out to a command & control server? Yeah, IPS might not help us there either.

There are technologies out there that allow enterprises to see this traffic - but maybe not enough of us are adopting it yet. A forward proxy for outbound web filtering is great. One that implements SSL decryption and inspection is even better. If your company isn’t already decrypting outbound web traffic, then this needs to be a priority.

Inbound web traffic can be just as dangerous. New IIS vulnerability? Sure, let’s grab the latest IPS signatures and … Oh wait, our IPS runs on our edge firewall, which sits in front of those web servers - which are all using SSL for encryption. That means any malicious traffic is going to slide right through our IPS undetected and land on our unpatched web servers. Get a Web Application Firewall (WAF), and let it front-end your SSL traffic. These things can be expensive and a nightmare to configure and tune properly, but right now they are one of your best options for inspecting web traffic.

Old Attacks Aren’t Going Away - They’re Just Getting an Upgrade

This year’s report highlighted that much of the older attacks are still here, and they’re not giving up yet. Attacks via email are still present and doing more damage than you would hope. We’re certainly getting better about implementing spam filters with reputation filtering, but attackers aren’t giving up yet.

Email attacks are relying more on social engineering and targeted phishing. These messages are also utilizing SSL to encrypt the malicious links within the emails. Infected attachments are surprisingly still a big issue, with Microsoft Office and PDF files still being the worst offenders. Just because attackers are finding new and exciting ways to hit us doesn’t mean they’re giving up on the tried and true methods. We still need to focus on all the standard attack vectors, like email. Implementing intelligent email/spam filters and providing user awareness training are the primary methods we have to combat this.

The Cloud is Secure! …We Think

This one I found particularly fun. Out of all the companies surveyed by Cisco for this report, 57% of them said they believe the cloud offers better security. Wait - Did I misread that? More than halfof respondents think that the cloud offers better security than their own infrastructure! This makes me wonder…

From my perspective, a cloud service provider is just another company. In most cases, they run just another network and hit a lot of the same challenges that non-cloud companies are facing. And we can only assume that cloud providers are prioritizing security and not just trying to turn a quick profit. Cloud companies have the advantage of being able to hire a dedicated security team that their customers can leverage. However, enterprises are complaining about lack of skilled security engineers, and I’ll bet it’s not because cloud providers are picking them all up.

Cloud definitely offers benefits - but this needs to be a well-calculated risk. For a smaller company without dedicated IT staff, a cloud solution would most likely offer security improvements over their own infrastructure. As companies scale, however, their security requirements do too. We need to make sure that the cloud providers we choose are also capable of adhering to those standards. Before you move to the cloud: ask questions about their security practices, get answers, and demand more information on the parts that are important to your business.

Another fun note from Cisco - some of the damage done by cloud providers is a simple mis-understanding of ownership. If you subscribe to a complete Software as a Service (SaaS) provider, chances are good that the provider worries about all of the critical security configurations. However, if you’re going to a cloud provider just for infrastructure (like AWS), then you are likely responsible. In the case of AWS, you’re being provided a server - and that’s where Amazon’s responsibilities end. It’s up to the enterprise to still make sure that those servers are patched, hardened, and audited. Treat the cloud as an extension of your own infrastructure and polices, not a separate entity.

Diversifying Risks? Maybe not

It used to be a somewhat well-established security practice to use multiple vendors. Have a need for two sets of firewalls? Make sure you use two vendors, so that a vulnerability in one doesn’t affect the other. Seems like sounds logic - until you have to train staff to be experts on multiple platforms, and keep up to date on all the latest patches from each vendor.

Cisco is finding that the more vendors a company has in their environment, the more problem we have maintaining everything. From my own experiences, I can say this is certainly a problem. In environments where I’ve had up to four vendors for firewalls and switching, it becomes difficult to work with. It’s hard on IT staff to maintain knowledge of configuration and best practices for each different vendor - and when a new vulnerability comes out, we end up spending way more time trying to track down each vendor’s responses and patches.

It makes sense that companies who have a more tightly integrated infrastructure might have an easier time managing it. Cisco might want you to buy 100% into their ecosystem (of course), but I do think there is value in consolidating your infrastructure. One or two vendors will be much easier to establish relationships with than half a dozen of them. Your IT staff can dedicate their focus to mastering only a couple of technologies, rather than spreading themselves over a dozen different platforms. And when that new vulnerability is released? It should be much more straightforward to patch all of your systems quickly.

There’s That Automation Thing Again

I think we’re finally beginning to reach a point where automation is really showing it’s value in the security realm. A typical company is going to have so many different systems and alerts that it doesn’t make sense for someone to manually review and act upon every one. This is where automation really begins to shine.

Cisco’s report shows that more companies are relying heavily on automation. This can be used for alert response, reporting, and behavioral analytics. Especially when I keep hearing that there is a skills shortage in security, we need to take advantage of what automation can offer. This doesn’t always have to be home-grown scripts either - there are a number of offerings already available.

Take a second look this year. Try to see where automation can fit into your infrastructure to help improve both operations and security.

Thanks for reading! Just as a friendly reminder - All of the opinions stated in this post (and all others here) are 100% my own, and do not represent any vendor or employer. Since security has become more of an important part of my job, reports like this are always very interesting to read. I’ve only covered a handful of what was in the report - just what was particularly interesting to me. If you’re interested in reading more, check out the full report here.

A lot of people take the beginning of the year to make new resolutions and goals for the coming months. So this year, I’m urging you to add one more to your list: Try and automate something that will make your life easier.

Where to Start

What you choose to automate doesn’t need to be extremely complex or elaborate, just anything that will save you a little bit of time. Never used a scripting language? I can’t recommend enough using Learn Python The Hard Way to start learning. This site is what I used about five years ago to get into scripting. Another great resource is CodeAcademy, where they have web-based interactive tutorials (also check out their specific module on Python and APIs).

Once you get a good handle on the basics, start thinking about repeatable tasks that are great candidates for automation. Start with something simple - maybe a script that prompts the user for information, then generates the command-line entries to configure new switch ports. Then someone can easily copy and paste the commands from the script output to achieve their desired configuration. Something like this might not immediately seem like a huge time savings, but it gives you a place to start and get familiar with what is possible. Once you get something like that working, it’s not too difficult to extend the script later and actually include calls to the switch APIs to automate the changes.

Is Python/scripting your only option? Not at all. There are also automation toolsets like Ansible, which can abstract the code layer a bit. For quite a number of systems that I deploy to an average datacenter, I already have Ansible playbooks written to handle that work. My actual time involved in deploying standard network monitoring applications and tools to a new datacenter went from hours to less than five minutes. For the purposes of this post, I’ll be speaking more to the Python/Scripting side. However, the important point is not necessarily which toolset you choose - it’s the fact that you try to use any one of these tools or others to automate something.

Stick with it

Learning a scripting language at first might seem like a very unnecessary and time consuming task. However, this is something that will pay off in the long run. When I started learning Python, all I wanted to do was parse data from several CSV files and combine the necessary data into one large file. Stupid simple script, but it saved me half an hour each day for a previously manual task.

I’m not at all a fantastic developer by any means, nor would I want to write code for a profession. I just really enjoy problem solving, and sometimes the best way to solve a problem is with a bit of custom scripting. What gets me excited is the process of finding something that wouldn’t normally be possible and knowing that I have the skills and ability to make it happen. Over the past five years, my basic level Python abilities have enabled me to work my way through a number of problems - or write various scripts to make my job easier.

You’ll need to dedicate some time and put in the effort up front to learn a new skill, but trust me it will be worth it.

Look for New Opportunities

Once you have learned the basics, start looking for ways to use your new skills. It’s a different way of thinking in some cases, and will likely take a bit of adjustment. Whats that? Your load balancer doesn’t have built-in reporting functionality to tell you how many server pools you have (and how many are actually fully functioning vs degraded)? Yep, they probably have an API which would be easy enough to pull that data from.

Over the years, I’ve built scripts to automate load balancer configurations, generate reports, alert on BGP peering changes, auto-remediate IPSec VPN disconnects, and even a full IPSec VPN dashboard (since the vendor doesn’t supply one). As a network administrator, having the automation skills in Python has allowed me to accomplish many tasks that my co-workers have stated aren’t possible (solely based on the functionality not being native to a product). Sure, I spend a bit of time up front writing and testing out scripts - but it not only saves me time/effort, but also my peers who I share the scripts with. For example, my team used to have a maintenance task that would take a full hour to complete on a monthly basis. About a week worth of my own effort to write a script, and all of that work is now automated into a 30 second process.

Think about how automation can help not just you, but your whole team.

The Future of Networking

If you follow practically any news source for computer networking, I’m sure you’ve heard this already. Over the next few years the role of a traditional network administrator can and will change. Businesses are evolving more rapidly to meet customer demands, and we need to ensure that our networks can keep up. The only way this is going to be possible is through automation, or hiring an ridiculous number of people.

Practically all major networking vendors are integrating APIs into the new iterations of their device platforms. Some are fantastic, and some are less than ideal - but they’re all working on it. In some way or another these new APIs will become a part of your job - whether you’re writing the code to perform tasks or just using a script written by someone else. Does this mean we have an end to our careers in the future? No - the CLI will take a while to completely disappear. Even if it does go away completely, the role of a network admin will not be replaced, but evolve into something a bit different from what we know today. Even today, having the skills to automate tasks out of your daily job can allow you to spend your time on more important things (like a new network design, or that big project you haven’t had time to look at yet).

You can probably get away with not learning scripting and automation for quite some time yet - but don’t you want to make your life easier and be prepared for the future of your career? I know I do.

The problem here stemmed from the fact that there were no documented standards in place. An engineer was given a device to configure, and it was configured depending on who did it and what they felt needed configuring. In a few cases, this actually led to unnecessary security risks being introduced into the environment because something was left enabled. In one instance, this included open root SSH logins via the Internet to a production firewall. Scary, huh?

So how do we go about changing this? Here is a quick little guide I threw together on my method for tackling the situation:

1. Define a standard

Begin creating a baseline document, whether it be a spreadsheet, word doc, or a wiki page. Start small and choose a single system, like your external firewalls for example.

2. Research best practices

Check out the vendor’s website to see what they recommend. There are also some amazing free resources out there like the Center for Internet Security’s configuration benchmarks, Do your research - there is plenty available to help you.

3. Figure out what’s best for your network

Not all of the best practices or security hardening guides will be a perfect fit for your environment. So it will take a little manual review to see what actually fits. For example, many of these guides recommend disabling local authentication in exchange for something centralized like TACACS+ or RADIUS. But if you don’t have that available, then you’re going to stick with local authentication. This can still be a great time to find room for future improvement projects though.

4. Test

If you have a development or test environment available, then run a device or two through your checklist and make sure there are no big issues. If you don’t have a dedicated test area, then try and choose a low-impact device - where not much will be impacted if the changes go wrong.

5. Roll out the changes

Make sure you have a list of every device that needs to be touched, so that you have a way to validate. Then make the configuration changes to get each device into compliance with your new standards. Have a validation/testing checklist ready, so that you can quickly ensure that no production traffic was impacted

6. Train your peers

Configuration standards only work well as long as everyonefollows them. It only takes one person to ignore the checklist and potentially expose a vulnerability. So take an afternoon, schedule a training session with your team. Help them understand the importance of maintaining these standards, and train them on how to apply the changes (if necessary).

7. Automate

This part is optional, but highly recommended. If nothing else, spend the time to automate verification of the standards - which will make it easy to locate a device that falls out of compliance. If you or your team have the skill set, then automate the entire process from initial deployment to continuous validation. Why is this the last step, instead of being included with the roll out? I am a firm believer that you should completely understand how your device functions and reacts to changes before automating those changes.

So that’s more or less how I worked to implement a standardized configuration at my current job. I began with a completely new device platform that we were integrating into our environment, then began to go back to older device platforms. It might be a lot of upfront work, but it certainly helps me sleep better at night not having to wonder if there might be one device out there that’s misconfigured (and will cause an issue later, due to that misconfiguration).

So let me know in the comments below - have you ever implemented something like this? If so, what did you do differently? If not, then let me know if you give this a try!

This guide is written for CentOS 7. If you’re running another distro, find your dependencies here.

Last year we had to begin migrating off of some of our older Juniper SSG firewalls since we were beginning to push them to their throughput limits. We evaluated a couple of vendors but ultimately decided to stay with Juniper and purchase SRX 1500 firewalls, which are capable of up to 10G throughput. After a while of working with these firewalls, I have to say they’re pretty solid devices and I’m extremely happy with them. One of the main reasons I like them so much is the ease of automation, which is what we’re going to dive into today. If you need a device for lab/test - Amazon has the SRX 300 for less than $300. I’ll likely be picking one up in the near future for easier automation testing.

Juniper provides an awesome library for SRX management called PyEZ. Here is what we need to get the toolkit ready to use in our scripts:

Install dependencies

I run CentOS here, so I just needed to grab the following packages:

yum -y install python-devel libxml2-devel libxslt-devel gcc openssl openssl-devel libffi-devel

Just a quick note - Juniper’s web page doesn’t actually mention openssl-devel, but their tools will fail to install without it

Get pip

If you don’t have it already, then download the pip installer here. Then just run the following:

python get-pip.py

Install PyEZ

Once everything else is set, this is the easy part:

pip install junos-eznc

After all that is done, we can get to the exciting part: automating something so you don’t have to do it anymore! So here is what we’re going to throw in our script just to get started:

# Import the JunOS modules we need
from jnpr.junos import Device

# Define the login credentials and address for the target firewall

# Need to provide device address, user account, and password

# Note: Juniper also provides authentication via key-pair, which would be more secure than username/password

srx = Device('10.10.10.10', user='deviceuser', pass='devicepass')

# Open the connection

srx.open()

Once you have that going, it’s pretty easy to start making calls to collect data or change the configuration. In one of the first projects I used this for, I was making use of the API to reset VPN tunnels. This was due to an issue with a cross-vendor tunnel, which would occasionally break during VPN re-keys and only negotiate a uni-directional tunnel. So the script was written to detect a uni-directional flow of traffic, then log into the SRX and reset the VPN - which would force a renegotiation and fix the issue.

So in order to accomplish the SRX-side of that script, I used the following to reset the IKE and IPSec security associations:

# Clear IKE security association for a given peer
response = srx.rpc.clear_ike_security_association(peer_address='20.20.20.20')

# Check to see if command was accepted
if response == True: print "IKE SA Cleared"

# Clear IPSec security association for a given peer
# Note: In this case, you need to provide the index ID
# Get the index ID from running '*show security ipsec sa' *on the SRX
response = srx.rpc.clear_ipsec_security_association(index='123456')

# Same thing - Check to make sure the command succeeded
if response == True: print "IPSec SA Cleared"

This provides a pretty basic example of how easy it is to control the SRX via a Python script. You might be wondering: This is great, but how do I find the names of those calls? Well, Juniper made that extremely simple as well! Just take any command on the SRX and pipe it through display xml rpc and the device will tell you exactly what you need. For example:

root@SRX123> show security ipsec sa | display xml rpc
<rpc-reply xmlns:junos="http://xml.juniper.net/junos/15.1X49/junos">
    <rpc>
        <get-security-associations-information>
        </get-security-associations-information>
    </rpc>
    <cli>
        <banner>{primary:node0}</banner>
    </cli>
</rpc-reply>

In this case, we are running the command which would normally print all of the connected IPSec tunnels. So the section under rpc is where we want to look. Now just take the get-security-associations-information, and change the dashes to underscores. So to use this in a script we would call srx.rpc.get_security_associations_information(). I’ve actually used this command to build a VPN status dashboard using Python and Django, which I accomplished by just pulling all the IPSec tunnels and parsing them into a web table.

As a final note, I would highly recommend creating a separate service account on the SRX for scripting. A separate user account with limited permissions would be the recommended way to go here. It might seem like a pain to set up, but it’s worth it in terms of security. Here is what I have configured on my SRX firewalls for the API service account:

system {
    login {
        class api-class {
            permissions security-control;
            allow-commands "(clear security ike)|(clear security ipsec)";
            deny-commands "(clear)|(file)|(file show)|(help)|(load)|(monitor)|(op)|(request)|(save)|(set)|(start)|(test)";
        }
        user apiuser {
            full-name API_Service_Acct;
            uid 125;
            class api-class;
            authentication {
                encrypted-password *<encrypted string here>*
            }
        }
    }
}

So using the above example, you should only define the necessary commands in the allow-commands section. If the account is ever compromised, we are severely limiting the amount of damage that could be done. A little extra effort, but potentially a big payoff.

So what did you think of this tutorial? Helpful? Have questions? Let me know in the comments below!