Tims Blog

I’m putting the finishing touches on a setup process for nessquik. Without it you’d be hard-pressed to actually install the software

• 25 cutest jquery plugins
• exposing service apis via zend framework

Surprisingly, today I managed to clear the CIDR exclusion hurdle that has been irking me for some time. I found a python library a while ago that did exactly what I wanted, but the effort of porting the library to PHP was far too much to justify the functionality gained.

So I looked at what the library was doing, and after a bit of tweaking this morning before I headed to my dad’s for the Bears game, I created a function that did exactly what I need. Cool!

• pcapr trends
• multi-dimensional data visualization
• google motion chart
• repairclinic

Preparing new code for release takes so much time the first time you do it. bleh

• writing command line utilities with python and optparse
• infinite scrolling with jquery
• splunkreplay
• gltail and chipmunk
• circos
• fofix
• ufo alien invasion
• hedgewars
• raphael
• firefinder

I tell ya, I have the best luck.

It would appear that there is a banner flag you can send to the Nessus server to give you the needed timestamps. It’s called, obviously, “timestamps”.

Where my luck really shines though is with libraries. Part of setting up these scans is writing a fairly large chunk of data over the network to Nessus. Something gets screwed up along the way though with PHP and somebody, probably PHP, starts throwing these SSL3_WRITE_PENDING: bad write retry errors.

Googleing around, I can’t pin down a cause; great. If it’s openssl, I wouldn’t be surprised. The version available on server dates back to 2006, and that’s with the most recent distro of the OS!

I’m going to try to write the data in small chunks and see if that helps. Maybe there is just too much crap being crammed down too small of a pipe

I just finished putting the final touches on the scheduling functionality that exists in the nessquik maintenance plugin framework.

Part of the work included the need to create a class to parse and correctly interpret a crontab string. I understand how crontab entries work, but it wasn’t clear how to go about determining when an actual string applied to the current time.

I started by considering some existing classes that apparently do it. There are two PHP classes that I found, but they were quite old (2005) and they looked poorly written; more like proof-of-concept.

So I wrote my own. It uses the existing Zend_Date classes that I use in nessquik, supports the standard crontab fields, and also the crontab shorthad @ entries.

It supports the range, comma and slash syntax as well. At this point in time it does not support named months or days of weeks (ie, Aug, Wed, etc) but for the 2.6 release, it doesn’t need to; it already does enough.

As I was debugging it, I was only running 1 plugin (using the “every minute” syntax) and while watching the logging output, I noticed that another one of the plugins was run. At first I said “oh great, a bug” but then I noticed the time on the clock and realized that the Cron code had actually worked…and worked correctly :p

While at R/P this weekend, I walked through the target inclusion/exclusion code and frontend stuff for targets and cleaned it all up and tested the rest of it to make sure it works. I also added the report viewing and deletion code. I’ve been able to generate proper XML to created reports using XSL stylesheets too, so I was going to plug that in to the code very soon to complete the whole audit cycle.

I was sitting at the conference thinking about how I save the data that is used to generate the reports and I’m kinda scratching my head. I jotted down some pros and cons of each, but I’m going to pick Marc’s brain on Monday to get some more feedback.

So this weekend I’ll be at the Reflections/Projections conference at U of I in Urbana. It’s usually a pretty neat conference where they have lectures about current technology and future technology. This is also one of the conferences that I attended each year during college so, if they show up, I’ll probably meet up with professors and students from school.

During the development of the report generating code for nessquik I came across some quirks in Nessus that just bug me.

The reports contain two fields for each report host called startTime and stopTime which, I’m assuming, are the timestamps for when Nessus started scanning and stopped scanning a particular host.

Now, the Nessus server emits messages via it’s protocol that more or less give you most of the information you would need to build a report in the .nessus XML format. “More or less” are the key words here though. While this information is generated by the server, Tenable has decided that the Nessus client software should add some extra bits to the .nessus format; in particular severity counts, hostname resolution, netbios address, hardware address, and start and stop times for each host.

That data is not provided by the server via any messages that it emits back to the client, and this mixing of fat and thin client functionality pisses me off because my otherwise thin clients that I am writing now must maintain certain levels of state, and converse with my own web software to provide the same functionality as the stock Nessus clients.

It’s my personal opinion that the Nessus server, seeing as how it _is_ the one doing the scanning, should be able to figure out all this stuff on its’ own and emit that data as messages back to any interested clients. This would trim the fat on any client that needs to be made as they would become just parsers of NTP; adding bells, whistles, and magic as they see fit to enhance functionality.

Including those fields as known output in the .nessus files is lousy though. It would be ok if the server provided the values to fill in the blanks with; but it doesn’t.