After nearly 8 months of on-and-off development (mostly off, day-job work keeps my busy), I’m proud to announce that pyTenable has hit version 0.1.0. While this may not seem like much, it’s been a lot of work to bring it across this line in the journey so far. All of the Tenable.io Vulnerability Management API are now pythonized. Further everything in the tenable_io module has been tested out (519 tests!). Tenable has also seen fit to link to pyTenable as an official module for working with our products.
Considering there wasn’t any Nessus Network Monitor docker images that I could find, I decided I’d create one. Using the Nessus Scanner image as a starting point, this image should have a lot of the most common things parameterized out already. As for sniffing traffic, I’d highly encourage you to take a look at one of the earlier posts covering Docker & packet sniffing. Deploying the sensor should be a simple matter of setting up a volume for the sensor data (for persistence), linking it to a promiscuous interface, and then instantiating it:
A lot of the Nessus Scanner docker images in Docker Hub don’t appear to be properly parameterizing a lot (or in many cases, any) of the required inputs to really get the scanner to run and connect up in an automated fashion. Further most of the images that I’ve seen out there aren’t cleaning up the identifying information the scanner created as part of install (such as the UUID, the master encryption key, etc.
With all of the materials out there on the web revolving around docker containers, I thought that getting some sort of a docker network that containers could promiscuously sniff would have been a relatively easy thing to find. I was shocked to find out that, not only was this not the case, but that the general consensus was that you need to use either Docker’s host networking (which means that these containers can’t exist in other network name-spaces), use pass-through networking (which unless you have hardware that support SR-IOV, your out of luck), or that you resort to some serious host hacking to get the interface into the container.
TrafficWatch is a simple node.js app I wrote after trying to get Ian Harmon’s traffic time-lapse-helper project working in Python for 30min or so on MacOS, I gave up and wrote TrafficWatch in about an hour. There are some arguments that you can specity as well if you want look at somethign other than Chicago traffic: –name / -n Name for the GIF in the upper-left corner –url / -u URL String for that we will be time-lapsing –interval / -i The time interval (in minutes) –duration / -d The number of minutes to run –gifout / -g The output filename for the GIF –xoffset X Offset for the crop (0 means centered) –yoffset Y Offset for the crop (0 means centered) –font Font for the name and time display in the upper-left corner (default is Arial) –fontsize Size of the text (default is 32) –fontcolor Color of the text (default is #000000b0) –directory Path for the individual screencaps (default is screenshots) –gifdelay The ms delay timer for the GIF animation (default 500) An example output would look something like this:
So I got a couple of these fantastic little embedded systems from Next Thing, and started to try to set one of them up how I would like to see it setup. Basically I was looking for a web browser, SSH installed, and a few aliases to make things easy to work with. NOTE: All of the operations below assume a basic understanding of terminal commands! Updating the PocketCHIP and installing the software To start off, the PocketCHIP OS is slightly out of date as it’s currently being flashed, so the first thing we need to do is update the OS to current:
Aside from a few hiccups that delayed getting Dofler installed and fully functional until mid-day Saturday, Dofler was a fantastical success at CircleCityCon! We discovered that the new codebase Dofler sits on was catching more entertainment than ever, including some MJPEG-based webcams: GREAT JOB to whomever is checking their MJPEG home security system via HTTP on the con network. #dofler pic.twitter.com/MiD6jSR8lz — Circle City Con (@CircleCityCon) June 11, 2016
I have started working through all of the various fabric files I have and started centralizing them and cleaning them up for general consumption. These fabric scripts cover a variety of tasks from deployment and maintenance of various products to deploying some of my code. I will be updating the repository as needs arise, and as always am welcome to any input. Using my fabric files is actually pretty simple, however you need to have fabric installed on your workstation before anything will work.
After running CUGNet for a dozen or so years and having yet to break even, last week I made the hard decision to close down CUGNet’s VPS services. It was a hard choice to make, as its something that I have done for many years, however with the propensity of cloud services and VPS providers out there, What I can offer is simply not competitive and the I need to start cutting down on the number of side projects that I have been running in order to keep my own sanity.
I’m proud to announce the general availability for pySecurityCenter version 2.1.x accessible from PyPI immediately. pySC 2.1 supports connectivity to SecurityCenter 5, which leverages a completely new RESTful API. Because of this, the pySC SecurityCenter 5 support will be an evolving process. Whats implemented today will not be changing, however many of the convenience functions that pySecurityCenter has for SecurityCenter 4.x have not been coded into the SC5 module, as enumeration for the API is still active.