After each release I like to let users know where things are headed so this is one of those posts.
Before v0.4.2 my 2 big goals were a new web interface (for v0.4.2) and support for JS/DOM/AJAX (for v0.5). Now that the first goal has been achieved the focus has shifted to the second one. However, in order for the transition to be smooth there are a few supporting goals that need to be reached.
High-performance/multi-process scans need to leave their experimental state and become stable features
When in a Grid setup the Dispatchers should automatically load-balance
The Grid has some great features:
- Extremely easy setup — Only requirement is specifying an existing Grid member as a neighbour.
- Self-healing — Dispatchers who disappear (for whatever reason) are blacklisted and become members again should they re-appear.
- Self-maintenance — Changes are automatically propagated to all Grid members.
- Adjustable preference for nodes — You can specify a float to act as a weight in order to influence the preference/load score.
Those are great features for a load-balancing cluster but thus far it only supported high-performance, multi-Instance scans. Indeed, the Instance selection for those scans was being load-balanced but when performing regular scans the Dispatcher you were talking to was the one providing the Instance — as usual.
If you wanted to perform simple load balancing (run a regular scan but get an Instance from the least-burdened node) and you were not using the WebUI you were encouraged to RYO. That wasn’t bad advice for SaaS providers because they would already have their job queues in place anyway, but for people who don’t care about that, like companies performing internal security tests, this wasn’t necessary.
This goal is simple:
No-matter which Dispatcher receives the dispatch call, the Instance should be provided by the least burdened member of the grid. Fortunately, in preparation of the relevant WebUI feature this has become very easy to implement. :)
Initially, the JS-related features will surely be buggy. A great deal of re-writes will need to take place and new code means immature/untested code. Thus, there must be a way for users to effortlessly receive updates as soon as they become available and not have to monitor this blog or the Twitter feed for updates and then download whole new packages.
A design draft for this mechanism is already available (i.e. I jotted some stuff down in the middle of the night yesterday).
Fingerprint pages and adjust audit payloads on the fly
Surprisingly, this hadn’t occurred to me before recently, when a user asked for this feature. Right now, Arachni gives blindigly the web page everything it’s got and it really shouldn’t. For example, if the server runs on *nix it shouldn’t send it MS Windows payloads.
Once implemented, this feature will severely decrease scan times..and I mean SEVERELY.
There are a few more smaller features and bugfixes scheduled but these are the more important ones that will pave the way for v0.5.