Custom Pages in Zenoss

In a previous post I talked about how to create custom navigation links in Zenoss using a ZenPack. However we didn't get to creating the custom pages that these links would link to. This is what we will learn today.

Page Viewlets

Previously we created navigation item viewlets, this time we will be creating page viewlets. These type of viewlets allow us to create and insert new custom pages into Zenoss where we can display custom content. To create a new page, we add the following code to browser/configure.zcml:

<browser:page
  name="secondaryPage"
  for="*"
  permission="zenoss.View"
  template="templates/my_template.pt"
  />

It is important that the name attribute matches the URL of the navigation link we created previously. Another important attribute is the template attribute, this is a special file that will represent the base markup of the page using a combination of HTML, TAL, and METAL.

Also let's not forget to create a necessary python init file:

touch browser/__init__.py

Cracking Passwords With aircrack-ng

aircrack-ng is a powerful suite of tools that allows to assess wireless network security. The tools in the suite allows us to perform various actions such as packet monitoring in the environment, montoring of specific access points, de-authentication attacks on access points, and cracking of WEP and WPA PSK (WPA 1 and 2) passwords.

In this post I will explain on how to perform these actions.

Wireless Card Monitor Mode

Before we begin it is crucial that we change the mode of our wireless network card to monitor mode. BY default, our wireless network card's mode is managed mode. In managed mode, the network card generally only listens to packets addressed to the card, whereas in monitor mode it will hear every packet in the air. Additionally, monitor mode will also allows us to perform packet injection attacks (i.e. de-authentication attacks).

To set our network card into monitor mode, we can run the following commands in a terminal:

Extending Zenoss Navigation Bars

It is possible to extend the functionality of Zenoss's navigations from within our custom ZenPacks. This means that we can add or remove links to the navigation bars we frequently use to access the infrastructure page or event console.

configure.zcml

Zenoss ZenPacks can contain a file in the ZenPack top directory called configure.zcml. I've mentioned and talked about this particular file in previous posts. This file basically acts as a configuration glue between back-end functions and front-end components.

It is in this file where we will declare and create new navigational links from our ZenPack.

~> In this post we assume that the ZenPack is created using zenpacklib, which is a Python library that makes creating ZenPacks much easier. Zenpacklib also makes the integration between the back-end and front-end much easier as well.

Usually this file begins with some required boilerplate code:

configure.zcml:

<?xml version="1.0" encoding="utf-8"?>
<configure
  xmlns="http://namespaces.zope.org/zope"
  xmlns:browser="http://namespaces.zope.org/browser"
  xmlns:zcml="http://namespaces.zope.org/zcml">

  <!-- Our custom code here -->
  <include package=".browser" />
</configure>

Custom Zenoss API Endpoints

In a previous post I went over the Zenoss JSON API and how it works inside the Zenoss Core. In this post we will apply the concepts learned in that post in order to create custom API endpoints within Zenoss, which can be accessed by the JavaScript front-end, curl, API clients, etc. All this new functionality added from a basic ZenPack.

Creating an Endpoint

Assuming that we are starting with a new and fresh ZenPack created with zenpacklib, we will proceed to create a simple endpoint.

Let's go ahead and create a file named api.py (can be any name) under the ZenPack's top directory. In this file we will import necessary modules, implement interfaces, and define our routers and facades. If you still don't know what routers and facades are and what they do, I suggest you first take a look at The Zenoss JSON API post.

First, let's take a quick look at the imports:

import os.path
from urlparse import urlparse
import subprocess

from zope.event import notify
from zope.interface import implements
from ZODB.transact import transact

from Products.ZenUtils.Ext import DirectRouter, DirectResponse
from Products import Zuul
from Products.Zuul.catalog.events import IndexingEvent
from Products.Zuul.facades import ZuulFacade
from Products.Zuul.interfaces import IFacade
from Products.Zuul.utils import ZuulMessageFactory as _t
from Products.ZenUtils.Utils import zenPath

Some imports are probably not needed, but the ones that are of our interest are imports such as DirectRouter and DirectResponse, which you might remember from the previous post. Additionally we are also importing the necessary facade, events, and interfaces imports.

SSH Monitoring in ZenPacks

Zenoss usually monitors and collects information using SNMP and SSH methods. A good example of is the linux monitor ZenPack which can collect information such as hard disks, interfaces, and file systems using both methods.

SNMP works by installing and configuring an SNMP agent on the machine we want to monitor. This agent will poll the machine for data, and this data can be retrieved by Zenoss using net-snmp.

On the other hand, SSH works by configuring a username and password or a path to an SSH key zProperties. This will allow Zenoss to remotely access the host using SSH and execute the corresponding commands and return the corresponding information.

When developing ZenPacks, data collection using SNMP is a relatively common practice. There is even a very good tutorial on SNMP monitoring using zenpacklib. When using SNMP, the modeler plugins are SnmpPlugin plugins that typically work using a set of OIDs to determine exactly which data is to be modeled.

SSH in Modeler Plugins

In order to make a modeler plugin utilize SSH as it's polling method we need to use a different type of plugin, the CommandPlugin plugin. The structure of this type of plugin is very similar to the SnmpPlugin, however there is one critical variable that must be implemented.